本期討論會參與者：
陳將老師：Zilliz 生態和 AI 平臺負責人
唐飛虎老師：月之暗面研發工程師，開發者關系負責人
主持人：周默：共識粉碎機，前美元對沖基金投資人，曾在騰訊與微軟從事戰略與投資業務
準確率：通常情況下長文本優于RAG
長文本：可更加綜合的去分析所有相關的內容，提取相關數字，生成圖表，效果尚可。
長文本在準確性上表現好的原因，以及長度與準確性選擇
長文本處理之后，會做對齊和專門的Benchmark測試調整。比如說之前的大海撈針以及騰訊的數星星的Benchmark，這些是更難一些要求，不僅要找到相關的位置，還得把具體的數字給出來。
現在也出現了一些新的關于長文本模型的bench mark，比如legal bench，它就是專門測長文本模型的retrieval 和reasoning 的能力。然后如果大家對這個方面的推理有興趣的話，可以去搜，最近有一些論文是比較相關的。
從實際應用出發，其實幾十 k token的輸入量量并不算很多，現在一般的大語言模型都能滿足。用額外的輔助，就有點像為了10本書，去搞一個圖書館，可能不太需要。但是如果對這 10 本書有什么特殊的需求，沒準也需要搞一個圖書館，需要搞一個機器人去幫你拿書。比如說是10本某個偉人的手記。就是這個取決于具體的情況。
在現實情況中，只有十本書的情況畢竟不多。在數據量較大的場景，RAG還是非常適合。
而且基準是在變化，趨勢來看大語言模型的文本的 context window會變得越來越長的。如果它普遍的都變得特別長，如果推理的成本，做了很多優化，能夠顯著的降低，那可能就是這么小的文本可能真的不需要去再費功夫給它搞一個數據庫去做這個 efficient retrieval，靠模型本身就能高效地把這些信息全部掃一遍了。
長度與性能關系：RAG線性，長文本受限因素更多
長文本：受限的因素比較多。比如并發性能會隨著上下文長度的增加反比下降，預填充的延遲也是會隨上下文長度的增長平方級別的增長；解碼延遲和上下文切換的開銷也是會線性的增加；最成瓶頸的是預填充延遲，因為它是會平方級別的增長，這也是構成目前長上下文推理的主要難度。
展開看上下文長度對長文本成本、延遲的影響
目前主流的長文本推理，是根據 token 數去計算最后的價格，所以價格看起來是線性的關系。
但是背后的長文本模型，實際推理成本受很多因素影響。需要有一個推理集群，然后做優化。
Context window越大除了成本會增長之外，首 token 延遲會顯著的增加。比如128K的模型，如果全用滿，需要大概幾十秒鐘的時間才能返回首token。
部分廠商提供了更加長上下文的模型。比如月之暗面之前有一個 200 萬字的模型，包括像Claude也有一個更長的模型。這些模型，一次推理，可能延遲需要等幾分鐘。
上下文長度在長文本與RAG的邊界
有一些數值的參考坐標，如果講分chunk，大概就是500， 1000， 1500，甚至兩三千token，大概這個量級。所以如果是500個token，不需要搜索，搜索里邊的最小單元都比這個大。
幾十 k 處在中間狀態，大語言模型 context window，可能是幾十 k 這個量級16K、 64K 或者更多的。embedding 模型如果要做搜索的話，需要能夠把這一段片段塞到embedding 模型的窗口里邊。之前的embedding 模型跟大語言模型的架構有一些不同，然后現在有一些embedding模型直接用大語言模型的架構去實現。量級大概也就是典型的像 16K context window 的，然后長一點兒的，比如有64K，但沒有太長的。
長文本如何優化First Token延遲問題
工程層面：比如說Flash attention。
硬件層面：比如說英偉達有一些新的技術。
RAG的成本原理
輸入階段：輸入內容的大小、類型會有很大差別。在RAG環節也會分離線和在線。離線是預先所有內容用Embedding模型等處理一邊，切分然后生成向量入庫，甚至在中間還可以做數據挖掘提取各種標簽用于搜索中做過濾。在這其中，也可以將總結同步生成出來，是否要生成總結以及是否伴隨細節，都會對成本直接影響。
入庫成本的天花板：用小的Embedding模型把所有內容刷一遍，然后再用大模型把內容提取標簽或總結，所產生的成本基本是一次性入庫成本的天花板。
輸出階段（Serving）：每次的 serving 的服務成本，取決于retrieve 出來多少。這和業務邏輯設計的有關，可以是TOP3或者TOP5。然后取這里邊的乘積，比如說五個片段，每一個片段的平均長度是 1, 000 個tokens，那每一個平均的 context 長度就已經是 5, 000 個tokens。再加上用戶的query，一般情況下長度還是遠小于長文本方案的長度，按極限來說長文本是每次付出兩個 milliontoken 的推理成本，那 RAG 的方案可能就是 5, 000 個token，每次的推理成本大概是這么一個感覺，但還要考慮到 RAG 有一次性的入庫成本，包括除了入庫之外，存儲還有成本，但是存儲成本相對低。
其他成本：需要維護data pipelines，即需要長期的維護數據。做數據更新，即增刪改查，還有很多工程成本。
長文本的降本方向
具體的選擇比較需要看場景
單純從學術上，長文本跟RAG有非常大的差別，沒有太多互相之間比較的點。很多指標雖然是同樣的指標但是要求千差萬別。在AI場景里面，需要根據不同的場景分析特點。
需要從業務實際的情況去考慮，支持的業務的性質是什么？所需要工具有什么主要特點？比如關注延遲，關注整個系統的運維成本、機器成本？還是關注用戶體驗？比如問答愿意花 10 美金，只要這個問答能答對就有價值。
長文本是大語言模型能力增長非常好的體現，但是大語言模型肯定不只有這一個能力，那么即便是短文本里邊，比如 reasoning 能力，數理邏輯的感知，在實際業務中非常重要；然后 RAG雖然說是叫 retrieval augmented generation，其實大家主要的關注點是在retrieval上，功能類似于搜索。
RAG部署有許多系統化優化點
?
?
場景所需要的文檔量級會直接影響選擇，例如幾千字或者幾萬字規模適合長文本模型+上下文緩存的方式，不僅能優化價格，還可以優化First Token的延遲。
例如營銷群里的段問題，多數已經不需要人工介入，大模型能回答得很好，并且延遲可以控制在2-3秒。
例如游戲客服的文檔在幾萬字，也符合上面的要求。還有一些特定場景，請求比較頻繁，共同的上下文比較集中，例如AI翻譯、針對AI文檔的回答等，也適合長文本。
單純從開發角度來說，只用長文本會有優勢，開發比較簡單，基本上不需要復雜的機構或者使用其他的第三方工具，只需要把文本轉化成text，然后全部給大模型的message里即可，這個不在于使用效果有多大的差別，而是對于開發者的負擔比較小。
如果用戶側問經常問一些刁鉆的問題，比如模型的推理價格報表，或一些比較復雜的問題，比如用 a 模型相較于 b 模型能省多少錢？可能這個時候用長文本是一個比較合適的選擇。
要看具體的場景，需要開發人員去測一下。一般來說，RAG肯定是相對多一些準確度的損耗。因為最后還是要把過RAG的信息給到大模型（RAG本身的準確度損耗+大模型的準確度損耗 vs 只有大模型的準確度損耗）。
在很長一段時間內，這兩種技術都是需要去搭配使用的。產品經理在做技術選型的時候，需要更深入的了解這兩個技術，去設計場景。
在AI coding細分賽道，已經變得越來越專業，對模型的要求也越來越高。對于場景如何去獲取信息，要求也越來越高。
比如GitHub，推出了Github copilot workspace，這是更加專業的場景。
包括字節、騰訊和Google ，都推出瀏覽器VScode 的插件，甚至一些IDE能力。這樣他們可以更加全面的做代碼推理，不僅僅是代碼補全，還包括一跨文檔的能力，比如在一處進行修改，能夠幫助把相關聯的地方全部都做修改，但這也需要更加復雜的產品設計能力。
如果是前端代碼，可能很多都是跟業務沒什么關系的代碼，可能就不那么的關鍵。
如果是一個智能合約，其核心邏輯非常短，百行之內就能把核心的邏輯描述清楚。
產品類型也非常有關。像一些dify的代碼，大概在幾十行，就把核心的邏輯表述出來。
百萬代碼量可能是一個很小的代碼庫，千萬代碼量可能也是小代碼庫。一個項目稍微復雜點的就能做到百萬的量級的代碼量。
像 Google這樣大的體量，2015 年有 20 億行，一行一般幾十個token，所以代碼量在稍微大一點的軟件工程的場景下時巨大的。
如果能夠限定問題所在的代碼范圍，比如說某些文件夾，那么代碼量并不大，一個文件夾里面的幾個files，可能 5, 000 行，什么1萬行就到頭，然后幾十個token一行，總計大概在幾十萬token。
可以不用RAG，但是需要有辦法把代碼篩選出來。
RAG背后是向量，向量搜索是基于語義的 similarity 去搜，對代碼的搜索除了語義還能利用其他信息。因為代碼是有結構的，對于能夠解析的結構，就不一定需要全用Vector similarity 去search。
比如可以根據項目名稱，模塊名稱先去找到大概的范圍，當然這個范圍有多大的代碼量可能預先并不不知道，如果量特別大，可以結合長文本。
通用代碼結構解析的能夠做到的程度：比如Java 的項目，因為 Java 的語法是相對標準，所以能夠解析出來它的類（function）的結構，然后建立結構化樹，該樹用來做從項目名到模塊的路由。這部分是有通用性的，因為各家用的Java的項目結構大體都是一樣，甚至有一些框架帶有一定結構，然后這個框架是通用的。
不能通用的部分：比如，某個模塊是由某個團隊管理，該團隊要負責給該模塊寫說明，因為代碼里幾乎找不出來它跟業務邏輯之間的關系。這一段代碼，具體是給哪個模塊，給哪個業務里邊的哪個功能的，如果沒有歷史背景，只有維護這個東西的團隊知道，甚至維護的團隊時間久了也不知道了。
企業實際應用中會遇到這類 “三不管”代碼，是個比較現實的問題。這個現實問題就很難用通用的方法去解，可能有的甚至要通過組織架構的方式去解，這些就需要做很多定制化的東西。
一些開源的項目會相對容易，host 在 GitHub 上，各方面的文檔的read me，各種描述軟件，比如說各種 function 的使用文檔都是內嵌在 code 里邊，有了這些前置條件，這屬于比較容易觸達到這個問題的核心相對好用通用的辦法去解決。
這種選擇大概率是出于成本等的考量，不能承擔太高的推理成本的。因為搜索是商業服務，而不是慈善業務。
所以如果每一個免費用戶都花幾美金的成本去承擔query的成本，這肯定是付不起的。所以背后一定是做了大量的優化，Perplexity 宣稱做了一些小一點的模型，并單獨為這個場景做了模型優化，這樣它能夠把成本降下來。
大家會覺得RAG 就是成本很低，但量大情況也不一定。如果使用的體量非常大的話，向量數據庫本身的存儲成本，還有進行服務 的serving 成本也是很高，也需要做一些優化。
比如Zilliz最近在做的冷熱存儲的切換，將價值不高、訪問頻次不高的數據放到冷存儲里，以節省成本。如果用 RAG 都有成本的問題，那全都用大語言模型去付出高昂的推理成本，應該說在這些商業的產品里邊一般是不現實的。
分兩部分，第一部分是做語義檢索，語義檢索本質上是粗顆粒度的模糊的搜索，把這一篇網頁分成 50 個片段，每個片段 500 個字，然后整個片段就生成一個向量，然后向量代表了這個網頁抽象語義，或者是它的一個指紋或表征，這是一種抽取的方式，它并沒有邏輯的關系。
至于向量怎么生成出來，拿深度神經網絡模型訓出來的，然后對齊了一些業務場景對模型的需求，就是語義相似的東西，就給把這個向量給分布到相似的空間里邊的位置上，然后這是一部分的抽取。
另外一部分就是給提取出來的東西標簽、關鍵字，或者根據它的內容提出來一些描述性的標簽。這個一般也是通過模型來實現，有的是用大語言模型做的，有的是專有模型來做。
是用到向量檢索去檢索到一些內容，然后再搭配關鍵字的倒排和一些其他標簽。Web 搜索里叫token base retrieve，把那些 token 相關的東西都去除。然后對所有這些拿出來的東西放在一起進行 merge，這個merge 是根據業務和渠道的特點做重排序。
然后重排序里邊，像互聯網的話，業務是占主流的，即要達到什么商業目的，重排序要與根據商業目的對齊。
不好判斷。創業公司可能在商業層面上，比如說他根據場景做的一些定制，或者說從流量獲取就是純商業運營的角度上有自己的獨特玩法。
涉及數值計算以及Text2SQL的選擇
Text to SQL可以看到成熟度越來越高。但總體而言數值計算，并不太適合用大語言模型這種概率模型直接去做。數值計算比較適合使用邏輯模型或者規則工具去做，比如說SQL。大語言模型在里面起到的作用是把自然語言所表達的問題，拆解成有邏輯關聯的步驟，然后將這些步驟轉化sql。達到的效果是輸入自然語言，輸出是SQL 的查詢語句，然后SQL查詢語句進入數據庫運行，這是一種比較好的方式。
如果非要用大語言模型去解決這樣的問題，即仍然依賴于概率分布，不去借助類似計算器這樣的工具，則需要給大語言模型很多例子，至少告訴大語言模型怎么計算步驟的拆解。但是大語言模型還是擺脫不了next token predictor的情況 ，即知道自然語言的分布是怎樣的，回答的結果就是概率分布的結果。比如說之前 3.11 和3.8比大小的情況，大預言模型會認為3.11更大，是因為大語言模型可能理解的是兩個版本號，比如Python的3.11和3.8。大語言模型理解的是3.11版本比3.8版本更晚出現，肯定更強，所以更大，而不是不是按照人類日常使用的小數規則。
長文本的技術爬坡方向
推理質量不能有所下降，如何在保質保量的做長文本的推理，是一件非常困難的事。
解決了能力問題之后，還要解決貴且慢的問題。前面講到兩個瓶頸，一個是推理成本會特別高，一個是首token會特別慢。在一個階段解決好這兩個問題之后，待上下文窗口再提升到下一個里程碑，這兩個問題又會出現。
但還是要持續去研究expand context window, 因為有一個現象表明，當長文本能力上去之后，有很多附帶的能力會涌現出來。
RAG的技術爬坡方向
整個鏈路變得更長了，遠遠比半年之前變得更復雜，開始有更多的技術棧被加入進來。
大概 6- 12 個月之前，市場對于 RAG 的印象是：先embedding 模型抽象出一個向量，然后導入向量數據庫里邊，然后搜索出向量背后代表的短文本塊，放入大語言模型。
6個月之前，甚至三五個月之前，出現了一種說法，如果不用向量數據庫，把整個文章輸入大語言模型就解決問題了，所以在Twitter等自媒體上，開始有了長文本vsRAG 的提法，這個故事很抓眼球。但后來實際的情況沒這么簡單，這里邊是一整個鏈路的問題，這兩個東西不是簡單就能比較的。
開始大家都覺得只應該用向量。但慢慢的發現其實向量檢索只是很復雜技術棧中間的一塊而已。包括有人覺得向量數據庫是不是有能力做端到端服務，或者向量數據庫是不是能做端到端服務，直接提供搜索業務，但實際不然。
實際情況比向量檢索加大語言模型拼接更復雜。最近新涌現出來的技術棧提供了很多其他的解決方式，比如知識圖譜，包括長文本用于離線數據的挖掘，即給很長的文本進行壓縮，總結出來一些信息，然后這個信息更容易進行搜索。或者因為有長文本，所以對文本檔案的切分就不用那么精益求精了，稍微長一點也沒有關系。甚至于其他新的embedding 模型類型，根本就不在意切斷的具體方法，但這個主要還是在學術界領域在討論，實際應用的比較少。
從語義的識別，query serving角度來說，原來覺得query 就應該直接去匹配文本段，但實際上不是所以情景都適合這樣做。很多時候 query 不是一個簡單拿一個文本段就能回答了。很可能query 含有一個復合問題，需要分為好幾步才能夠解答，比如說是需要比較分析的問題，比如A和B之間的區別是什么？如果是人去做這類問題的回答，可能會先看 A 是什么，然后 B 是什么，這兩者都充分理解后，然后再去做一個比較，這就是一個多步問題。
大語言模型的進展除了長文本本身之外，包括推理和邏輯的能力也在提升，然后就出現了用大語言模型去解析query語義，將其拆成多步，甚至產生了是交互式的問題解答，即先解答一步，然后根據該步的返回的情況，再讓大語言模型去決后面一步要解決什么樣的問題。這樣復雜的 query 的解析和路由的方式已經開始出現了，而且在前期生產應用的效果看起來也不錯。
整個過程是需要online和offline的結合：傳統搜索，就有offline的部分， offline 就是像管理圖書館中的圖書一樣，怎么分門別類的把書放好，這樣進行檢索的的時候更容易。另外一部分是online 的部分， online 的時候就是用戶要過來查這個書了，那怎么能夠快速把這書找到，依賴于線下做的事情，然后這兩塊現在都有進化，都有新的技術棧的加入，整體來看實現效果包括應用情況也比 6 個月之前要好了很多。
長文本與RAG也在融合部署
比如說開始有離線做數據挖掘的情況出現了，比如說最簡單的數據挖掘就寫一個總結。除了給這一整本書的很長的內容做了場景切分之外，還去把這一本書在離線的時候都讀了，就是拿大語言模型長文本的能力去讀了一遍，然后寫了一個總結，這個總結本身也是作為召回的語料之一。
然后在serving的階段，原來大家會謹小慎微的往里邊塞東西，現在可能多塞幾個片段，甚至切分 chunking 都不用切的特別小，可以切很大的chunk。然后把幾個很大的 chunk 加在一起，非常長的東西扔進去，只要能承擔這個成本。
這里邊也會有一些問題，有trade off，比如說放了很長的東西，對大語言模的穩定性要求就很高，就是剛才提到大海撈針或者數星星的這種能力要逐步的增強。還有推理的能力，大模型需要注意到這些任務里面有自相矛盾的內容，它應該有判斷。
GraphRAG 帶來的啟發？GraphRAG的技術路線是否是目前的best practice？
GraphRAG是一個價值很高的項目。對于知識圖譜的提取，應用都做了開源的實現，填補了市場上的空白
GraphRAG在一些方面填補了知識圖譜的空白，但實際上它做的不是一個典型傳統的知識圖譜，GraphRAG做了兩件事情：
一是創造了community的概念，本質上是利用知識圖譜進行數據挖掘。通俗點說，把一個很長的一個文檔，或者說文檔庫里邊的內容先做了切分，這個有點像 RAG 里邊做 chunking ，切分后對于每一個單元去提取里邊的知識三元組，比如說一個實體和另外一個實體中間是什么關系。比如說奧巴馬是美國總統，這樣的關系提取出來。
二是還把知識圖譜跟向量檢索做了結合。一方面用知識圖譜做了數據挖掘，建立樹形的信息結構，這個叫community，相關的 entity 聚合成小的community，然后把多個小的 community聚合成大的community，相當于采用金字塔型的結構整理了信息，并做了總結。使得每一個三元組成為信息單元。對知識三元組本身也做了向量化。然后將所有這些東西放在向量數據庫里邊，根據語義去做召回。GraphRAG召回的方法的設計也比較全面，考慮到小的entity，也考慮到總結性的信息。最后把這一套東西做了開源的實現，這是價值比較大的點。
