1 Agent/Function Call 的定义
Overview of a LLM-powered autonomous agent system：
Agent学会调用外部应用程序接口，以获取模型权重中缺失的额外信息（预训练后通常难以更改），包括当前信息、代码执行能力、专有信息源访问权限等。
2 从去年到现在有什么进展?
Not a research seminar but good to know...
一些Datasets:
- 基础 Knowledge-intensive/Decision-making tasks: HotpotQA, AlfWorld Enve
- 行生 In-the-wild: Glaive-Function-Calling, InternLM/Agent-FLAN, THUDM/AgentTuning
一些Eval(NoTool/Retrieval-based/Action-based)
- Berkeley Gorilla Function Call Leaderboard, THUDM/AgentBench, CMU/WebArena
一些框架/产品/Demo：
- GPTs, Camel-Al, Modelscope-agent, Agent Hospital
优秀的工作很多，只是不完整的列举一部分
Agent 需要和现实世界的信息进行收集和交互。其核心本质严重依赖于LLM自身的Instruction Following, Complex Reasoning, Long Term Planning能力。
3 普惠智能体
- 从技术角度看，agent 是帮助人类做事的装置，提供便利、提高效率、节约成本、增加乐趣等
- 从经济角度看，agent 需要给人类提供明显的经济价值，需要可靠地执行繁琐的任务，结果精确可靠、充实、无害，并简单易用
满足普惠的 Agent 应当满足的要求： 1.能执行繁琐、繁重的任务(太轻松的任务不需要agent)。 2.能给出可靠、充实、无害的结果(错误率容忍度较低)。 3.易学易用，不需要使用说明(zero shot，不依赖于用户的prompt水平) 4.链路完整，使用场景不需要经常跳出(不能破碎)。 5.可以与外部工具和功能的交互，在没有人为干预的情况下完成多步骤的工作流程。 6.会学习与自我纠正，越用越聪明。
但现状是
智能体名词被滥用 Over promise,Under deliver：
- 简单的工具调用，本质上只是一个Instruction Following的问题
- 复杂推理 GPT4 还是爸爸(但 WebArena 依然只有不到3成的准确率)
- 给出指令并观察其执行。依然是 RPA 路线
- 简单的 demo nb，没有稳定的使用。严重依赖人工经验判断简单的
- 缺乏多模态理解，still LLM grounding (OSU Mind2Web)
- 面对缺少context和语言歧义的情况，依然会'硬答’
- 一些设计繁琐的agent产品，节约了做事的时间成本，却增加了学习成本，违背了初衷
- 甚至部分产品'图一乐’，严格意义上只能算 prompt engineering
简单易用，符合普惠对AI的想象即使名字里不带Agent，也可以是一个好产品。
4 收窄：RAG是一种信息Agent
初步认知：大模型作为信息容器
- 通过预训练注入：中高频、持久化信息(事实)
- 通过 Post Train注入：能力/套路,而不是事实
- 通过 context 注入：长尾、易变、符号化、数字化、和业务相关的数据
早期的初步认知：大模型之上
打造agent技术中，大模型并非处于最顶层，它上面还需要有针对agent的业务逻辑，称为SOP。只有SOP才能保证涉及多个步骤的agent的可靠性。SOP会生成指导大模型工作的计划planner。
RAG能增强模型context，在推理过程中增加辅助生成答案的材料(RAG)，使答案更加准确、充实、贴合场景。这种素材通常通过检索实现(广义讲是一些信息agent)，应满足：
- 提供LLM缺失的，和用户意图相关的素材
- 满足时间、空间等限定性要求
- 高精度的数据，精度需要高于搜索引擎提供的还需要用户筛选的内容
- 结构化的，能提供可靠的关系推演能力
- 专业的，满足产品创新需求
综上，为能打造agent，需要以大模型为中心，以数据结构化RAG为支撑(尤其是精确的结构化数据)，SOP为顶层抽象一个平台。
基于这个认知的架构
初步的技术实现
服务侧实现
- 分析用户的 prompt 和 context ,获取用户意图，表达为实体、关键词、向量
- 利用用户意图从搜索引擎/关系数据库召回相关素材
- 对素材进行相关性排序
- 对排序后的素材进行摘要(抠词)
- 将摘要作为 context 送入大模型，并生成结果
设计的算法和模型
用户意图分析模型
实体提取模型
句子分析和关键词提取模型
素材-意图相关性模型
高速摘要模型
数据侧实现
筛选优质语料，能提供事实、情节、数据等信息，精度较高
对语料进行预处理，切成片段
对片段进行结构化，提取实体、关键词、向量
对结构化内容进行改写，面向用户需求提取标签
需要抓取的数据
- 一般知识性数据，如百科 wiki 类
- 社区重要数据，如 twitter、知乎上的大V数据、机构数据
- 新闻源:质量和权威性很重要
- 学术文献，学术文献索引
- 产品和业务需要的数据，如ppt、ppt素材、故事情节、桥段
- 网络众投数据，如针对重点 query 的谷歌排序结果
5 好用的生产力工具
远不只一个 LLM + 搜索 API。平时搜集信息时，每人都有自己的习惯和一些相似点：
- 找政务/官宣/时效性 ->微信公众号
- 找生活攻略 ->小红书
- 看LLM相关研究->知乎/小红书/twitter
他能不能做到速度快？
他的知识深度与准确性，是否能够代替搜索引擎？
海量的优质知识文本(新闻，论文...)
分钟级索引更新，sub秒级查询相应
有效的把context控制在16k内
尽量接近大众对于AGI的想象，而不是尝试向用户解释幻觉/不擅长数学等。这听起来似乎是个 搜索推荐问题的Pro Max版本！
于是，架构又变成：
常见的用户问题类型
6 生产力场景，6种意图识别
Default：直接用 Yi 模型回答，不带RAG 知识RAG：通用知识/专业知识，百科/学术研究类数据， 新闻时事RAG：国内，国际，时政，财经，娱乐，体育，民生。并提供reference。 搜索引擎RAG：从搜索引擎获取摘要内容和网页内容，并提供reference。 Code/Math：CoT/PoT + Code Interpreter. PPT模式：创作PPT大纲,….
得到大致架构(简易示意)：
7 一些误解
Q：大模型拥有很强的能力理解用户的意图。 这点对GPT-4成立；对其他大模型，较困难！
Q：检索内容不相关时，大模型生成的内容质量也不应该变差。
大模型能分辨出内容是否相关的能力也是一个需要重点训练的能力。没有针对增强的LLM遇到不相关的检索内容，RAG结果会显著变差。
Q：高质量内容多，就能做好RAG。
内容质量不仅要高，要多，还得是用户需求的新鲜、准确、完整的内容。
Q：有了RAG就能消灭生成幻觉。
RAG确实能消除一部分幻觉，更重要的是让模型了解到它没有学过的内容，从而把无法回答的问题变得能够回答，而不是能够回答的问题回答变得更好。
8 一些弯路
通过小模型实现一个复杂的意图路由，结果将非常不准确。拆解出的用户意图通过不同技术路线实现，最后汇总成统一的聊天体验，也存在巨大挑战。
通过prompt调整通用大模型，让它能适应RAG的任务。无论生成内容的格式、内容相关性、篇幅都存在着巨大的不确定性，效果相当不稳定。
试图通过post-train对模型已有的能力进行增强，很不容易。
试图从0到1造一个搜索，直接满足RAG的需求，门槛非常高，光是索引有价值的内容一点就很难做。
结果要准，响应要快，成本要低 ->需要一个新鲜、完整的索引。但Google>Bing>自建库。
单个的信息点检索已经有不错的效果。但是回答综合性问题(比如胖猫事件始末),需要整理多方面的信息，并形成回答草稿，以供RAG回答好综合性问题。
9 多模态理解/检索/生成(以PPT为例)
利用多模态理解，对于目标文档生成完整的文字描述，理解PPT中的概念和关系。如果仅对PPT进行OCR来提取文本信息，可能丢失大量的上下文和视觉信息，导致检索结果不够准确或者缺乏深度。能够将文本和视觉信息结合起来，构建更加完整的内容表示。识别PPT之间的逻辑关系和内容流程，有助于构建知识图谱或上下文模型。
利用多模态生成，能够有效的规避版权侵权，召回图片不准，风格不统一。生成的内容与PPT的设计和布局相匹配，保持视觉一致性。
10 有了1M长文本能力，还要RAG吗？
有了大的context，就不用在检索相关性、摘要的精简准确方面做工作了。❌
1M 的context length技术上并不难达到，但需要：
- 更多的卡和推理成本
- 更慢的推理速度
- 更难从一大块文本内容中找到所需要的有效内容
所以长文本能力的提升，和RAG技术并不冲突，甚至可以互相促进。重要的是RAG提供什么内容能提升 LLM 的结果，而不是因为上下文长度不足，才不得已用RAG来截断筛选长文本信息。实验证明，不是提供的上下文越多，回答越好。更多的上下文中一定会有被遗漏的信息。所以怎样从中找到更重要的信息，压缩提供给LLM的prompt的长度，永远是值得被研究的技术，无论上下文窗口有多大。
11 FAQ
有Google搜索引擎，咋还自己搭建RAG搜索服务？
专用搜索引擎和通用搜索引擎的差异
通用搜索引擎为了保证能搜到一切，不得不容忍很多长尾的低效信息，同时在用户的特定场景中，Google并不知道场景信息。如若LLM主要针对学生或科研人员的场景中，搜索Transformer时，专用搜索引擎给出的都是学术科研相关的transformer算法或Huggingface的transformer库。但google给出的更可能是普通人更加熟悉的变形金刚相关/变压器的信息(这个例子只是示意通用搜索和专用搜索的差别，不是在讨论哪个结果是更加正确的)。
网页搜索和知识搜索的差异
真实的搜索引擎：搜索->打开链接->发现不是想要的内容->返回到搜索页面->打开新的链接->..->修改query重新搜索->.
理想的知识搜索：“我询问一个问题终于可以直接告诉我答案了。”既提供，将"google搜索+查看对应的网页内容+判断内容与问题的相关程度+自动修正query检索词”的工作打包合并后的信息。
难点：诸如幻觉、不准确、信息没有实时性等等问题，交互体验提升了，但真实使用体验依然没有办法跟有长期积累的传统搜索引擎想媲美。
更加先进的检索技术
知识搜索相比传统搜索的技术提升：
- 用户的Query改写
- 对引擎索引的内容，利用LLM生成补足更多的相关信息，包括不限于:实体提取、摘要生成生成用户可能的问题等等。这些信息都可以非常有效的提升用户搜索的精确度
- 对搜索召回的结果进行判别和加工，正常召回的是引擎中保存的原文信息，但是往往跟用户query相关的只是其中一部分的信息，甚至可能是意外召回的无关信息。有了LLM可以根据用户的query定向的对召回结果进行简单处理，提升召回结果的相关程度
和大模型Post train没关系了吧？
RAG需要SFT配合。传统LLM的SFT都是没有RAG信息的情况下，与人类进行校准。当模型可以获得RAG提供的信息后，如何更好的利用RAG的信息回答用户的问题，是需要进一步SFT的。包括RAG的流程中也还有很多需要利用LLM能力的地方，这些地方都是需要通过SFT将模型能力调整到更专业的程度，才能获得更好的效果。
但针对RAG和意图识别等进行针对性的调优，会损伤型的原有能力。
避免 cherry-pick，而是退一步优化整个大类别，否则容易按下葫芦起了瓢。
没提到向量检索 Vector-Search 啊?
Vector-Search只是在简单的本地化的RAG应用中(如针对特定文档的问答)，能更便捷提供RAG能力，从而成为当下较火热的技术。Vector-Search只是一种先进的文本相似度算法，但相比一套完整搜索引擎，计算相关性仅是其中的一个子问题，甚至很多时候都不是最关键问题。
搜索引擎的完整架构至少包括：索引(索引结构、全量更新、增量更新)、QP(query理解、意图判别/类目判别、query改写)、召回、粗排、精排(rank model,静态质量分)、打散(相似的内容不需要重复出)等等。而Vector-Search只为搜索引擎的架构中提供了精排中的文本相关性信息，是不足以撑起整个引擎架构的。早期的Google搜索，对结果影响更为重要的是PageRank,这个其实就是个静态质量分。一个引擎哪怕只利用关键词召回+PageRank,其结果也往往远好于Vector-Search。
12 成功的Al-native产品需三者兼顾
模型能力
Yi-Large 模型能力优秀。100B+的稠密模型，成本较低。Yi-Large 在国际公认的榜单上取得第一梯队的良好成绩。
➋ 模型 + Infra(模基共建)
模型的训练/服务/推理设计，与底层 Infra 架构和模型结构必须高度适配
多方面优化后，实现先进的 FP8 训练框架，模型训练成本同比降幅达一倍之多
自研性能/召回率最佳的向量数据库笛卡尔Descartes*，成本只需第三方18%
零一万物与 Google、Inflection Al一起入选24年3月 NVIDIA GTC 大会 FP8 最新成功案例； 自研全导航图向量数据库，权威榜单评测 6项第一。
3 模型 + 应用(模应一体)
去年在海外验证 TC-PMF，以真实用户体验，和模型迭代形成正循环
多模态理解与生成，结合真实场景，解锁2C应用的创新
单一产品上线9月，用户近干万，收入1亿，ROI接近1
使用量较大的2C类AI应用聚集在欧美Saas profitability 多模态 Vision 模型：结合LLM的读文档“截图提问”创新
大模型赛道从狂奔到长跑，取决于有效实现 TC-PMF
当前任何产品要实现大规模应用，需兼顾技术路径和推理成本
基于 Scaling Law，大模型能力快速增长，超过任何技术
大模型训练和推理的成本持续大幅下降(GPT价格年内多次下调)
需要顶级模型推理能力，才能实践最佳 Al-First 应用
但有些应用会先爆发，同时要考虑推理成本和商业模式的平衡
寻找 TC-PMF 难度远远大于 PMF,是大模型行业集体的挑战与机运
持续演进的技术所创造的商用价值和推理成本均是“移动目标”
与其坐等风来，不如成为造风者。需建立基建到应用的良性 ROI
双轨模型策略
闭源探索商业化及 AI-First + 开源赋能生态
搭建 AI 应用场景：
- 国内 platform.lingyiwanwu.com / 阿里云百炼
- 国际:platform.01.ai / Nvidia NlM / Fireworks.ai
关注我，紧跟本系列专栏文章，咱们下篇再续！
作者简介：魔都架构师，多家大厂后端一线研发经验，在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。
各大技术社区头部专家博主。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。
负责：
中央/分销预订系统性能优化
活动&券等营销中台建设
交易平台及数据中台等架构和开发设计
车联网核心平台-物联网连接平台、大数据平台架构设计及优化
LLM Agent应用开发
区块链应用开发
大数据开发挖掘经验
推荐系统项目
目前主攻市级软件项目设计、构建服务全社会的应用系统。
参考：
- 编程严选网
本文由博客一文多发平台 OpenWrite 发布！