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 釋出！