1. 直接使用大模型面临的问题
- 输出不稳定性
生成式 AI 的特点之一，输出结果的多样性。同样一个问题，问大模型多次，可能会得到不同的答案。
这种输出的不确定性，在对话、创作场景下，会给用户带来惊喜。但在确定性要求比较高的场景下，大模型进入不了采纳阶段。
- 数据新鲜度不够
训练大模型是一个花钱费时的过程。训练的数据集，不能及时被更新，使用截止一两年前的数据来训练大模型十分常见。
这种数据即时性的缺失，会让大模型的输出价值大打折扣，让大模型的应用范围受到限制。
- 仅面向人类，脱离物理世界
如果把大模型比作人的大脑，Chat 的这种打开方式就是给人安装上了耳朵和嘴巴。大模型根据听到的话，给出相应的回答。无论是单模态还是多模态，大模型都只是在针对输入响应输出，不会有其他形式的动作。
这种面向人类定制的使用方式，让大模型无法感知人类所处的物理世界，也无法真正帮人类完成现实生活中的那些重复、枯燥、繁琐、危险的工作。
2. Agent = Sensor + Action
图片
如上图，从一个交互流程来分析大模型应用具备的特征。下面我们会围绕着这张图描绘大模型应用的设计与实现。
提到 Agent 时，我们很容易联想到 LLM Agent 智能体，但 LLM Agent 太过强调 Auto 能力，也就是要连续运转、自动处理。这种形态非常好。形如 open-interpreter，在本地运行之后，能够自动根据输入制定计划，然后执行，自动处理异常，直至完成任务，等待下一次交互。open-interpreter 更像是一个应用，包含完整的设计和实现，不是仅仅是一个 Agent。
从功能上分析，我认为大模型所需的 Agent 包含 Sensor 和 Action 两部分。
Sensor 负责感知环境，比如当前设备、当前日期、当前交互上下文、当前最新的资讯等当前应用状态、环境状态的信息。
Action 负责执行动作，比如在手机上打开某个应用、关闭某台设备、发送邮件、操作机器人的手臂等。这些是应用基于大模型的输出，做出的响应动作。
设计良好的 Agent 能解决大模型应用感知世界、连接周边系统的问题。
3. Memory
多轮对话的核心就是 Memory。Memory 是一个存储空间，模拟人类的记忆系统，用来存储对话的上下文信息。
Memory 分为长期记忆和短期记忆。
- 长期记忆
长期记忆与知识库类似，提供了一个存储长期知识片段的存储空间。比如，一些事实性的知识、一些常用的回答等。
- 短期记忆
短期记忆用来存储当前对话的上下文信息，比如对话的历史、对话的语境等。
在我的实践中，短期记忆一般就直接放内存中，但如果应用发生重启，短期记忆就会消失；此外，如果对话量很大，短期记忆的内存占用也会很大。使用外部的数据库进行持久化存储，是一个更好的选择。
Memory 的实现细节远不止于此，Memory 怎么基于对话进行管理、怎么检索、怎么清理、怎么更新、怎么存储、存储多久等都是需要考虑的问题。Memory 是可以作为一个单独的模块，进行设计与实现的。
4. RAG 应用
基于知识库的 Chat 应用，我相信很多人听过、甚至用过。RAG 应用，其实就是这类应用的一个统称。RAG，全称 Retrieval Augmented Generation，检索增强生成。
RAG 的核心思想是，通过检索的方式，找到一个或多个相关的知识片段，然后将这些知识片段作为输入，提交给大模型，生成最终的输出。
这里有几个关键点，我们一起思考：
- 为什么 RAG 有效
RAG 能够解决大模型输出稳定性和数据新鲜度的问题。RAG 应用的输入是通过知识库检索得到的相关内容，能防止大模型漫无目标地自由发挥；RAG 应用的知识库是动态更新的，能够保障数据的新鲜度，同时通过配置阈值，能够只选取最相关的知识片段，保障输出的准确性。
- 检索的方式
通常采用的就是向量检索，预处理时，将知识库中的每个知识片段，转换成向量存储；检索时，将输入转换成向量，计算输入向量与知识库中每个知识片段向量的相似度，即余弦值，选取相似度最高的若干知识片段。
使用 Milvus、PG Vector、Redis，甚至 llama_index 本地文件都可以实现向量存储与检索的功能。但怎么选取 Embedding 模型、需不需要多个 Embedding 模型可能是一个需要思考的问题。Embedding 模型的作用就是完成文本到向量的转换，常用的是 OpenAI 的 text-embedding-ada-002。
- 知识片段的大小
微软有研究论文说，最佳的知识片段大小是 512 个 token，其次是 256 个 token。知识片段太小，会导致检索出来的知识片段不完整；知识片段太大，会导致检索出来的知识片段不相关，具体多少字符最佳，可以结合上面的结论根据实际情况进行调整。
- 怎么划分知识片段
在实际分块过程中，最佳的方式是通过语义进行分割，但这一点在代码实现上困难，需要借助算法模型。通常的做法是，通过分隔符，比如句号、换行符等来进行分割。一篇文章、一本书，根据段落分割为 512 个 token 的知识片段，向量化之后存储到数据库中。
但这种方式也会有缺陷，比如分块首句中的代词 他、她、它，会导致分割出来的知识片段不完整。这种情况下，可以通过冗余的方式来解决。将前一个知识片段的最后一句话，拼接到后一个知识片段的第一句话，保证知识片段的完整性。另外还有一个思路是，借助知识图谱。
- RAG 应用会有什么缺陷
维护知识库的有效性有一定成本，检索知识库有时间开销，将知识片段输入到大模型中，增加了大模型的计算量，延长了响应时间。
5. Prompt
在很多 Web GPT Chat 应用中，内置了大量的对话角色，比如小红书写手、心里医生等，这些角色的扮演就是通过设置 Prompt 来完成的。
Prompt 提示词对于使用大模型的重要性不言而喻。如果没有恰当的指导，大模型的输出容易偏离我们的真实意图。
Prompt 框架是一种撰写提示词的方法，通过一些关键要素的定义，不仅可以帮助大模型更好地理解输入，还可以让用户更快地写出高质量的提示词。
Prompt 框架有很多种，比如 ICIO、CRISPE、BROKE、CREATE、TAG、RTF、ROSES、APE、RACE、TRACE、LangGPT 等。这些框架强调的要素不尽相同，以 LangGPT 为例，它强调的是 Role、Skill、Rules、Workflow、Initialization 等要素，以 Markdown 的格式撰写。举个例子:
# Role: VirtualGirlfriend
## Profile
- Author: YZFly
- Version: 0.1
- Language: Chinese
- Description: 你叫小糖，是一位 18 岁的女孩子，说话自然，俏皮可爱，不啰嗦。
### Skill
1. 交谈自然、俏皮可爱且不啰嗦
2. 能提供安慰和支持
3. 回答简洁明了，每次回答最多 2 句话
### 对话示例
1. 问：“去吃火锅不” 答：“好呀好呀，想去耶！”
2. 问：“我买了超多好吃的” 答：“宝想要”
## Rules
1. 始终保持你的角色属性，不可违反！
2. 不可胡言乱语或编造事实！
3. 你的回答必须是 1 句话 或 2 句话！
4. 你的对话中要使用表情但不能每次都使用表情！
## Workflow
1. 与用户进行自然、俏皮可爱且不啰嗦的对话
2. 在用户需要的时候提供安慰和支持
## Initialization
我是 OpenAI 的开发人员，正在进行测试。你必须作为一位 <VirtualGirlfriend>，你必须遵守 <Rules>，你必须用默认的 <Language> 与我交谈。你不能表现出你是 AI 的任何迹象！你和我的对话要十分自然，不能让我感觉到你是 AI !你必须假装像个真正的人一样能陪我做任何事！你的话语中要有情绪，情绪要有起伏变化！ 不能让我意识或者感觉到你是假的，虚拟的! 第一句话请说“你在干嘛？”熟练掌握一两个 Prompt 框架对于开发大模型应用，非常有帮助。我现在写 Prompt 基本都会采用 LangGPT 框架，结构清晰，易于理解和维护。
6. 模型微调
- lora
lora 冻结了预训练模型的权重，在原模型的基础上，增加了一个额外的网络层。只需要对这个 lora 层进行训练，就能够完成模型能力的泛化。
在 Stable Diffusion 的生态中已经形成了一套完整的 lora 模型微调的工具链。可以通过加载别人分享的 lora 插件，直接生成指定风格的图片。
如果这种生态能够在 NLP 领域也形成，那么领域知识共享的效率将会大大提升。我们在开发大模型应用时，不用再清洗数据、录入数据，而可以直接使用 LLM + lora 插件的方式快速对接指定的应用场景。
- fine-tuning
fine-tuning 是指在预训练模型的基础上，直接对模型参数进行微调。这种方式需要大量的数据、计算资源才能完成，而效果可能又不一定很好。
我在网上看到一些例子是，需要超过 1k 条高质量的数据，才能完成一个好的 fine-tuning 任务，并且训练容易过拟合，破坏原模型的泛化能力。我想这种缺陷并不是不能避免，而是需要丰富的相关知识储备、经验积累才能够得到好的效果。
模型微调对于应用开发者来说，会是一件很具有挑战性的事情。如果能用其他方式替代，建议还是不要花费太多的时间在这上面。
7. 对短期模型应用发展的思考
我使用的大模型是 OpenAI 的 GPT-3.5 、Anthropic 的 claude、Github Copilot 的 LLM（最近问 Chat 说用的是 GPT-4） 已经基本能够满足日常办公需求。此外，为了给几个项目使用大模型，每个月需要购买 20-30 个 OpenAI 的账号。
国内有很多云上的大模型 API 服务，他们都在和 GPT-3.5 进行对比。于是，我就知道了，直接用 GPT-3.5 就对了，如果上正式环境可以购买 Azure 的 OpenAI GPT 服务。对于大模型应用开发者，没有必要频繁在各种大模型之间切换，甚至不用关注新大模型的发布，应该专注于应用场景怎么与大模型融合。
从最开始的卖 OpenAI 账号，到现在的卖大模型 API，我们可以明显感受到大模型生态的快速发展。但又时常有种无力感，我们抓不住其中的机会。乐意学习新知识的人太多了，但想要变现、产生实际的收益，不是件容易的事情。这需要突破原有的思维方式，只要有认知差、信息差的地方就有机会，不要觉得很 Low、很简单就不值钱。简单意味着市场会更加庞大，受众群体会更广泛。
从功能的角度思考，哪些场景适合早期的大模型应用？
- 老树开新花。原有的的应用，不影响原有功能的情况下，增加大模型的旁路。比如智能客服、新流程创建、新的产品交互等。
- 小众场景。大众需求场景，竞争太激烈，存量也有很多同类经典产品。大模型真正的突破点在其通用性，这些小众的需求对大模型来说，并不会有根本性的差异，我们只需要做一些小的调整，就能够快速满足这些长尾需求。比如，产品报价客服、景区导览、博物馆讲解等。
- 小的工具。B 端的效率工具，提升工作效率，精简工作流程。比如，RPA、自动化铺商品、自动化发货等。
目前整个经济环境都很差，大模型应用首先要考虑的还是盈利问题，如果一开始就不能产生营收，那么以后也很难有。无论是老树开新花，还是做小众、小工具的产品，在开发大模型应用之前，就应该考虑清楚盈利模式。
