LLM开发经验

适合 LLM 的职责

LLM 适合做的两种事情：抉择+多样性(比如：生成搞笑的风格)。

先尽量让 LLM 少做点事情，然后逐步增加其占比。

LLM 不稳定的时候，让 LLM 做选择题，比如：这个属于 A 还是属于 B。

2024 年诺贝尔化学奖得主 Demis Hassabis 的看法

诺奖得主教皇科学院开讲：AI 是一项令人难以置信的技术，发展模式需重新思考

三个标准(用这种方式来思考和建模)：

  • 是否能够将问题描述为在一个庞大的组合搜索空间或解空间中的搜索问题；

  • 是否有一个明确的目标函数或评价指标，可以用来优化和不断改进；

  • 是否拥有大量的数据，或者至少是一个高效准确的模拟器，可以生成来自正确分布的合成数据。

AI 应用的分类

对话机器人

DSL 生成

代码生成

Agent

有多种方式可以为 LLM 提供代理。最具模型泛型的方法是 ReAct 范式。

LLM 大小的选择

POC 可以大模型，但是放量必须小模型(AIME 的 agent 全是 7B 的模型)。

Prompt

让 GPT 帮我们润色一下 Prompt

给出“完美 example”

Prompt 中的匹配度 0 和 1，LLM 可能识别不了，改为排序+解释

填充的内容要每次 random，不然很容易推第一个(多样性)

缺少 example，few-shot

上下文长度增加，是否会导致模型理解能力下降？

韩东明：
GPT 不会的。
Kimi 之类的，会做上游的压缩，再给到后面。

在讨论 Prompt 的上下文长度对模型理解能力的影响时，我们需要考虑几个因素：

模型的内存限制：
所有模型都有其处理输入的内存限制。对于像 GPT 这样的大型语言模型，这个限制可能相对较高，但仍然存在。如果上下文长度超过了模型的内存限制，模型将无法完全考虑所有信息，这可能导致理解能力下降。

注意力机制：
像 GPT 这样的模型使用自注意力机制来处理长序列。理论上，它们能够处理任意长度的上下文，但实际上，由于优化和计算效率的考虑，它们在实践中会使用一些策略（如截断、窗口化注意力等）来处理长上下文。

上下文的相关性：
上下文的长度并不总是与理解能力直接相关。如果增加的上下文与当前任务不相关，那么它可能会分散模型的注意力，导致理解能力下降。

模型的压缩策略：
如果上下文长度超过了处理能力，可能会采用压缩策略来减少上下文的大小。这种压缩可能会丢失一些信息，从而影响模型的理解能力。

信息过载：
如果上下文太长，模型可能会遇到信息过载的问题，导致它难以捕捉到关键信息，从而影响理解能力。

模型的训练：
模型在训练时看到的数据分布也会影响其对长上下文的处理能力。如果模型在训练时经常看到长上下文，它可能会更好地适应这种情况。

任务的复杂性：
对于一些复杂的任务，长上下文可能包含完成任务所需的关键信息。在这种情况下，增加上下文长度可能有助于提高模型的理解能力。

总的来说，上下文长度的增加并不总是导致模型理解能力下降，这取决于上下文的相关性、模型的处理能力、任务的复杂性以及模型的训练。在实际应用中，可能需要通过实验来确定最佳的上下文长度，以平衡信息量和模型的处理能力。

RAG

(TODO)Embedding 空间

Embedding(嵌入)：将文本数据转换成数值向量

1
2
3
4
5
6
7
8
做RAG时， 输入 和 rag里面的文档 的关系 embeding空间不一定相近

比如我的文档是
AAAAAAAAA1
AAAAAAAAA2
AAAAAAAAA3
AAAAAAAAA4
你问4，这上面三个都区分不出来

“空间”指的是嵌入空间（embedding space），这是一个高维空间，其中文本数据被转换成数值向量（嵌入）。这些嵌入向量能够捕捉文本的语义信息，使得语义上相似的文本在嵌入空间中的距离更近，而不相似的文本则距离较远。

空间分不开

“空间分不开”意味着在嵌入空间中，不同的文档（或文本）的嵌入向量之间的差异不足以将它们明显地区分开来。这通常发生在以下几种情况：

  • 相似性：如果文档内容非常相似，它们的嵌入向量可能也会非常接近，导致难以区分。

  • 维度不足：嵌入空间的维度可能不足以捕捉文档之间的细微差别。

  • 嵌入质量：使用的嵌入模型可能不够强大，无法有效地捕捉文档的语义差异。

  • 文档量少：如果 RAG 模型中的文档数量较少，模型可能没有足够的数据来学习区分不同文档的嵌入向量。

  • 训练不足：模型可能没有充分训练，或者训练数据不够多样化，导致模型无法学习到区分不同文档的特征。

在您的例子中，文档“AAAAAAAAA1”到“AAAAAAAAA4”内容非常相似，只是数字不同，这可能导致它们的嵌入向量在嵌入空间中非常接近，使得 RAG 模型难以区分它们。这种情况下，可能需要采取以下措施：

  • 增强嵌入模型：使用更复杂的嵌入模型，如 BERT、RoBERTa 等预训练语言模型，它们能够捕捉更细微的语义差异。

  • 增加上下文信息：在文档中加入更多的上下文信息，以帮助区分相似的文档。

  • 数据增强：通过数据增强技术，如同义词替换、回译等，增加训练数据的多样性。

  • 特征工程：手动添加一些能够区分不同文档的特征，如时间戳、作者信息等。

  • 后处理：在检索后对结果进行后处理，如重排序，以提高区分度。

  • 增加文档量：如果可能的话，增加 RAG 模型中的文档数量，以提供更多的学习样本。

通过这些方法，可以提高模型区分相似文档的能力，从而改善 RAG 模型的性能。

(TODO)关于“文档量少”这个，多少才算少、多少才合适呢？有什么方法能评估么？

多少文档量适合 RAG

做大模型应用时，多少文档量适合 RAG？多少上下文适合纯 Prompt？

文档量和上下文量的选择取决于多个因素，包括：

  • 模型的规模
  • 任务的复杂性
  • 可用的计算资源
  • 具体应用的需求

模型的规模

如果对于性能要求不是很高，文档也不是太多，则可以选择整个扔进 Prompt。
比如图表推荐这个需求，我们参考了 GPT-Vis 的 CKB，他这个一个图表的内容才 1000 字，所有加起来，全部都可以直接扔到模型上文。

上下文相关性

上下文的相关性比长度更重要。即使是短上下文，如果高度相关，也能提供很好的效果。
RAG 的关键就在于如何取到最相关的文档，作为 Prompt 的上下文输入。

基建

在“大模型应用研发”的过程中，用 AI 的方式，帮助用户做一些工作。
dev flow

AI 应用开发框架

提示词优化框架

DsPy

https://github.com/stanfordnlp/dspy

算法：APE ，APO，OPRO
技术框架：DsPy 提示词工程自动优化框架（一种自动优化提示词的方法）
GitHub - stanfordnlp/dspy: DSPy: The framework for programming—not prompting—foundation models
关于 DSPy | AI 工具中文文档

RAG

CoT

微调

Agent & MultiAgent

职责

responsible
四大职责：Decison（决策），Plan（规划），Action（执行），Result（结果）
Decision 决策：负责分析当前任务，理解输入和上下文，觉定要应用的系统能力，以及各项能力的具体应用方式。
Plan 规划：负责规划能力的具体实施方式，规划工作流程，并指导执行层有序开展工作。
Action 执行：负责具体任务的实施，完成每个原子单元的任务，并串联各个模块的工作，产生最终的执行结果。
Result 结果：负责汇集执行层的结果并反馈至决策层，作为决策层下一步工作的主要输入。

分类

agent

上图展示了系统的大致结构，整体分为 6 个 Agent 模块，每个模块包含多项模型能力，覆盖从模型能力研发到优化迭代的完整研发过程

综合调度 Agent：系统的决策中心，负责对输入进行理解并对任务进行分析和拆解，制定执行计划，并调度各个模块。
Prompt Agent：负责 Prompt 的编写和管理工作，结合 Prompt 框架完成编写，并结合效果不断优化。
模型训练 Agent：负责模型的训练，调度各类模型训练脚本，处理训练数据集，串联模型训练流程，完成模型训练。
能力调度 Agent：负责根据实际情况调度各种能力优化模型效果，如：RaG，CoT Reflection 等，每种子能力也作为执行 Agent，且支持横向扩展
插件调度 Agent：负责在各个环节调用外部插件，如：数据获取，格式转换。插件独立于模型研发过程，为系统提供额外的能力加持。
意见理解 Agent：负责理解评测结果，根据 BadCase 和认为修改意见给出修改建议，提供给综合调度 Agent，进行持续的优化迭代。

开源框架

MetaGPT：一种新颖的元编程框架，将高效的人工工作流融入到基于 LLM 的多智能体协作中。其将复杂的开发任务分解为分配给不同角色的特定可操作过程（例如 Product Manager, Architect, Engineer 等等）。
AutoGen：通过 Multi-agent 框架设置各类完成各种复杂任务，如论文中列举的：解数学题，检索增强问答，代码生成，国际象棋，等等。

效果评测

系统级的模型调度

原则

AIGC 产品第一步：别用 AI

叙事可视化的旁白生成的案例。
初期尽量程序化搞定(为了保证稳定性和质量，先淡化 AI)，后面再提升 AI 比例。

越复杂，越要拆解+引导

叙事可视化的旁白生成的案例。
拆解+每步用户确认/筛选，保证最终生成的和用户预期的是一致的。

先想清楚业务上解决什么问题/替代什么？

聚焦问题和业务，缩小范围，快速实验，小步快跑。

工程能力和数据的不足很关键

问题不完全出在模型推理能力不足上，问题还出在工程能力和数据的不足上。

越是需要详细描述需求的场景，LLM 表现越差

对需求的理解和描述不足是阻碍大模型落地的重要的原因，目前大模型落地比较好的反而是那种不需要描述需求的场景。

知识点

5 个 AI 时代的划分

时代 特征 代表产品
1 ChatGPT3.5
2 ChatGPT4
3 多模态 ChatGPT4o
4 世界模型 Genie2
5 AGI ?

合成扩增

标注数据只有几百条，相当于是种子数据

基于种子，去做数据的合成增广，来涵盖更多的场景。来给模型训练

开发流程

  1. 产品提需求，和算法讨论
  2. 设计解决方案、框架、策略：数据哪里来、怎么定义、怎么标注、怎么合成扩增、构建模型的输入输出让模型效果稳定准确。然后还要配合工程，来处理模型的输出输出。

开发模式

我们也在见证着一种新的产品形态：以 IDE 为平台，人和 AI 协作驱动，自然语言作为主要交流方式的产品形态。

参考资料

(精)腾讯-大模型开发工作手册详细指南：

https://mp.weixin.qq.com/s/2epsTaup1mvmtGT1MJXg4g

我们的基建应该是做一个AI应用研发框架。

整体的研发流程不仅是单一模块的工作，涉及 “数据”，“算法”，“工程” 等多个模块，包含 “数据准备”，“数据标注”，“问题建模”，“能力研发”，“效果评测”，“模型调试”，“上线部署”，“落地应用”，“优化迭代” 等多个阶段，是一项系统化的工程

Prompt 工程：通过优化 Prompt 框架，影响模型的输入，获得更好的效果。
模型训练：通过数据训练的方式，影响模型的参数，获得更好的效果。
RAG & 知识库：赋予模型检索外部数据的能力，以补充模型知识不足的问题，获得更好的效果。
Agent 系统：通过拓展模型的能力（记忆，插件，多模型调度），以及构建由多个模型组成的系统，获得更好的输出。

只有让领域内的专家（非算法开发人员）自己完成模型的应用，搭建类似开源的能力研发生态，才能真的做到模型能力的领域化，毕竟领域最重要的价值，是领域内的人，而并非纸面上的知识和技术。

基于目前大模型自身强大的能力，我们认为模型研发的 “第一性” 就是 “提升应用效果”，用户不需要也不应该了解模型研发背后的技术，只需要对当下的任务负责，对当前的效果负责即可，而比起提供若干的 Prompt 技巧，对“提升应用效果”更有帮助的问题或许是：

  1. 如何评估效果：目前的 Prompt 好不好，效果怎么样？

  2. 如何 debug：模型犯了某种错误，我该如何调试？

  3. 如何优化模型：模型某些方面的能力不够强，我该怎么办？

  4. 如何应用模型：我怎么把模型用到工作中？

我们最终把目标转向了模型研发流程的工具化，希望这个工具能让每个人能具备应用模型的能力。

(精)阿里内部观点：智能化研发一年复盘，我们离真正的 AI 开发还有多远？

https://mp.weixin.qq.com/s/JTpLy8Z0klokHVcaDZm2RQ

其他

(精)不同的产品开发和迭代方案：
https://mp.weixin.qq.com/s/uJBNWo8TWLW-heyzeSXUYw

研发模式：组件复用、低代码平台、D2C、P2C

可定制性从高到低
首次开发成本从高到低
维护迭代成本从低到高

进阶模式：P2C 协议化

把专业领域的重复劳动的问题和解决方案都抽象为文本，提供相应的领域知识库，可以用自然语言来描述专业领域问题，指定 AI 理解问题的思路以及解决问题流程，提供一些案例提高准确度，最后对生成内容校验。

依赖 AI 能力，页面逻辑复杂之后，后续维护和迭代的难度也会指数级别上升。

我们的图表推荐、Insight 推荐的策略。
业务方图表配置类的问题，也可以用这个思路解决。