简介（未完成）
Naive RAG方法在处理简单问题时表现良好，然而，当面对更复杂的问题时，Naive RAG的局限性就显现出来了。
- 总结性问题：例如，“给我一个公司10K年度报告的总结”，Naive RAG难以在不丢失重要信息的情况下生成全面的总结。
- 比较性问题：例如，“Milvus 2.4 与Milvus 2.3 区别有哪些”，Naive RAG难以有效地进行多文档比较。
- 结构化分析和语义搜索：例如，“告诉我美国表现最好的网约车公司的风险因素”，Naive RAG难以在复杂的语义搜索和结构化分析中表现出色。
- 一般性多部分问题：例如，“告诉我文章A中的支持X的论点，再告诉我文章B中支持Y的论点，按照我们的内部风格指南制作一个表格，然后基于这些事实生成你自己的结论”，Naive RAG难以处理多步骤、多部分的复杂任务。
Naive RAG上述痛点的原因
- 单次处理：Naive RAG通常是一次性处理查询，缺乏多步骤的推理能力。
- 缺乏查询理解和规划：Naive RAG无法深入理解查询的复杂性，也无法进行任务规划。
- 缺乏工具使用能力：Naive RAG无法调用外部工具或API来辅助完成任务。
- 缺乏反思和错误纠正：Naive RAG无法根据反馈进行自我改进。
路由 vs agent
- 路由 + 多链路，路由是最简单的Agent推理形式，路由器识别出来问题属于哪种，然后使用对应的链路来解决。
- 训练专门的分类器 https://github.com/starsuzi/Adaptive-RAG/ EfficientRAG
- 对于复杂问题，复杂问题的处理链路仍需单独训练。
- agentic chat，有一个很牛逼的 agent llm（难点也在这），未来新的链路是一个tool。实际上揉和了规划、调用、总结到一个llm。
- 从分层的角度将，最下层/基础的能力是一系列的tool，所以要有caller，上层是对问题的拆分（也就是规划）和汇总（summary）。
- 对于单步骤问题，tool的回答已经可以作为答案了，所以规划器除了输出final Answer也可以ignore_summary 来决定是否调用summary。
{ action: "ignore_summary" action_input: "tool1_name" # 表示只用tool1的输出作为answer就行了，不必再summary了。 }
agentic chat 优化
多智能体微调实践：α-UMi 开源它要求LLM不仅要准确理解用户的查询意图，还要具备高超的任务规划能力、精准的工具选择与调用技巧，以及出色的总结归纳技能。其中，任务规划依赖于模型的逻辑推理能力；工具的选择与调用，则考验模型能否准确无误地编写请求；而工具调用结果的总结，则是对模型归纳总结技能的一次全面检验。传统的方法往往试图在单个开源LLM框架内整合所有这些复杂的能力，这一做法在面对容量更小的小型开源LLM时，其性能局限性尤为突出。更为严峻的是，现实世界中的工具更新迭代速度极快，这意味着一旦外部工具发生变化，整个LLM系统可能都需要重新训练和调整，这不仅耗费大量资源，也给模型的维护和升级带来了前所未有的挑战。因此，如何设计出既能保持灵活性和适应性，又能有效应对工具更新带来的挑战的LLM代理系统，成为了当前研究亟待解决的关键问题。为了应对上述的挑战，通义实验室提出了一种名为“α-UMi”的多LLM工具调用智能体框架。“α-UMi”将单一LLM的能力分解为三个部分模型执行：规划器、调用器和总结器。每个部分由单个LLM执行，专注于特定的功能。规划器依据系统当前状态生成策略，决定是否选择调用器或总结器生成后续输出。调用器根据策略调用具体工具，而总结器则在规划器的指导下，根据执行轨迹构建最终的用户答案。这些组件协同工作，共同完成任务。与先前的方法相比，α-UMi框架具有三大优势：
- 每个组件针对特定角色进行训练，确保了各自功能的优化。
- 其次，模块化设计允许各组件按需独立更新，保证了系统的适应性和维护效率。
- 由于每个组件聚焦于单一功能，缓解了模型等容量限制，意味着可以在小型LLM对工具调用智能体进行部署。 PS: 好想法，就是工作量有点大，训练时为每个模型准备单独的样本？文中给出了代码框架和 基于一个base 模型微调后的规划器、调用器和总结器模型。