网站制作图书,设计师公司排名,wordpress周期,医院如何做网站策划?1 Agent/Function Call 的定义
Overview of a LLM-powered autonomous agent system#xff1a; Agent学会调用外部应用程序接口#xff0c;以获取模型权重中缺失的额外信息#xff08;预训练后通常难以更改#xff09;#xff0c;包括当前信息、代码执行能力、专有信息源…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/MathCoT/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的需求门槛非常高光是索引有价值的内容一点就很难做。
结果要准响应要快成本要低 -需要一个新鲜、完整的索引。但GoogleBing自建库。
单个的信息点检索已经有不错的效果。但是回答综合性问题(比如胖猫事件始末),需要整理多方面的信息并形成回答草稿以供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 发布
