AI Agent应用出路到底在哪?-牛翰网

AI Agent应用出路到底在哪?

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为顶层抽象一个平台。

基于这个认知的架构

初步的技术实现

服务侧实现
  1. 分析用户的 prompt 和 context ,获取用户意图,表达为实体、关键词、向量
  2. 利用用户意图从搜索引擎/关系数据库召回相关素材
  3. 对素材进行相关性排序
  4. 对排序后的素材进行摘要(抠词)
  5. 将摘要作为 context 送入大模型,并生成结果
设计的算法和模型
  1. 用户意图分析模型
  2. 实体提取模型
  3. 句子分析和关键词提取模型
  4. 素材-意图相关性模型
  5. 高速摘要模型
数据侧实现
  1. 筛选优质语料,能提供事实、情节、数据等信息,精度较高
  2. 对语料进行预处理,切成片段
  3. 对片段进行结构化,提取实体、关键词、向量
  4. 对结构化内容进行改写,面向用户需求提取标签
需要抓取的数据
  1. 一般知识性数据,如百科 wiki 类
  2. 社区重要数据,如 twitter、知乎上的大V数据、机构数据
  3. 新闻源:质量和权威性很重要
  4. 学术文献,学术文献索引
  5. 产品和业务需要的数据,如ppt、ppt素材、故事情节、桥段
  6. 网络众投数据,如针对重点 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 发布!

请登录后发表评论

    没有回复内容