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

參考：

• 編程嚴選網