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為頂層抽象一個平臺。
基于這個認知的架構
圖片
初步的技術實現
服務側實現
- 分析用戶的 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
參考：
- 編程嚴選網
