關(guān)于長(zhǎng)文本和 RAG 到底如何選擇，一直有爭(zhēng)論，從基模公司到應(yīng)用開(kāi)發(fā)者。
今天這篇文章，是來(lái)自基模公司月之暗面和中間層 Zilliz 的技術(shù)對(duì)話，值得一看。本期討論會(huì)參與者： 陳將老師：Zilliz 生態(tài)和 AI 平臺(tái)負(fù)責(zé)人 唐飛虎老師：月之暗面研發(fā)工程師，開(kāi)發(fā)者關(guān)系負(fù)責(zé)人 主持人：周默：共識(shí)粉碎機(jī)，前美元對(duì)沖基金投資人，曾在騰訊與微軟從事戰(zhàn)略與投資業(yè)務(wù) 01 長(zhǎng)文本與RAG通用對(duì)比準(zhǔn)確率：通常情況下長(zhǎng)文本優(yōu)于RAG
長(zhǎng)文本在準(zhǔn)確性上表現(xiàn)好的原因，以及長(zhǎng)度與準(zhǔn)確性選擇 長(zhǎng)文本處理之后，會(huì)做對(duì)齊和專門的Benchmark測(cè)試調(diào)整。比如說(shuō)之前的大海撈針以及騰訊的數(shù)星星的Benchmark，這些是更難一些要求，不僅要找到相關(guān)的位置，還得把具體的數(shù)字給出來(lái)。 現(xiàn)在也出現(xiàn)了一些新的關(guān)于長(zhǎng)文本模型的bench mark，比如legal bench，它就是專門測(cè)長(zhǎng)文本模型的retrieval 和reasoning 的能力。然后如果大家對(duì)這個(gè)方面的推理有興趣的話，可以去搜，最近有一些論文是比較相關(guān)的。 從實(shí)際應(yīng)用出發(fā)，其實(shí)幾十 k token的輸入量量并不算很多，現(xiàn)在一般的大語(yǔ)言模型都能滿足。用額外的輔助，就有點(diǎn)像為了10本書，去搞一個(gè)圖書館，可能不太需要。但是如果對(duì)這 10 本書有什么特殊的需求，沒(méi)準(zhǔn)也需要搞一個(gè)圖書館，需要搞一個(gè)機(jī)器人去幫你拿書。比如說(shuō)是10本某個(gè)偉人的手記。就是這個(gè)取決于具體的情況。 在現(xiàn)實(shí)情況中，只有十本書的情況畢竟不多。在數(shù)據(jù)量較大的場(chǎng)景，RAG還是非常適合。 而且基準(zhǔn)是在變化，趨勢(shì)來(lái)看大語(yǔ)言模型的文本的 context window會(huì)變得越來(lái)越長(zhǎng)的。如果它普遍的都變得特別長(zhǎng)，如果推理的成本，做了很多優(yōu)化，能夠顯著的降低，那可能就是這么小的文本可能真的不需要去再費(fèi)功夫給它搞一個(gè)數(shù)據(jù)庫(kù)去做這個(gè) efficient retrieval，靠模型本身就能高效地把這些信息全部掃一遍了。 - 對(duì)于效果，前面講的大海撈針都是在幾百萬(wàn)的 token 這個(gè)量級(jí)下去講的，如果幾十k，可能就不算大海撈針，在這個(gè)量級(jí)上把注意力集中到用戶所問(wèn)的那些問(wèn)題上，不是一個(gè)特別難的事情，從觀測(cè)用戶使用的情況來(lái)看單純用大模型效果已經(jīng)很好了。
長(zhǎng)度與性能關(guān)系：RAG線性，長(zhǎng)文本受限因素更多 展開(kāi)看上下文長(zhǎng)度對(duì)長(zhǎng)文本成本、延遲的影響 目前主流的長(zhǎng)文本推理，是根據(jù) token 數(shù)去計(jì)算最后的價(jià)格，所以價(jià)格看起來(lái)是線性的關(guān)系。 但是背后的長(zhǎng)文本模型，實(shí)際推理成本受很多因素影響。需要有一個(gè)推理集群，然后做優(yōu)化。 Context window越大除了成本會(huì)增長(zhǎng)之外，首 token 延遲會(huì)顯著的增加。比如128K的模型，如果全用滿，需要大概幾十秒鐘的時(shí)間才能返回首token。 部分廠商提供了更加長(zhǎng)上下文的模型。比如月之暗面之前有一個(gè) 200 萬(wàn)字的模型，包括像Claude也有一個(gè)更長(zhǎng)的模型。這些模型，一次推理，可能延遲需要等幾分鐘。 - 在很多目前的場(chǎng)景下，這樣的延遲導(dǎo)致模型不能投入實(shí)際使用。所以說(shuō)主要是推理成本和首token的延遲這兩個(gè)問(wèn)題，以及再把長(zhǎng)上下文在進(jìn)一步擴(kuò)大的時(shí)候，還會(huì)遇到很多技術(shù)上的困難，在很多場(chǎng)景下，動(dòng)輒可能需要數(shù)據(jù)是比如說(shuō)幾GB，甚至有更大場(chǎng)景，用長(zhǎng)上下文就不是特別好的選擇。
上下文長(zhǎng)度在長(zhǎng)文本與RAG的邊界 有一些數(shù)值的參考坐標(biāo)，如果講分chunk，大概就是500， 1000， 1500，甚至兩三千token，大概這個(gè)量級(jí)。所以如果是500個(gè)token，不需要搜索，搜索里邊的最小單元都比這個(gè)大。 幾十 k 處在中間狀態(tài)，大語(yǔ)言模型 context window，可能是幾十 k 這個(gè)量級(jí)16K、 64K 或者更多的。embedding 模型如果要做搜索的話，需要能夠把這一段片段塞到embedding 模型的窗口里邊。之前的embedding 模型跟大語(yǔ)言模型的架構(gòu)有一些不同，然后現(xiàn)在有一些embedding模型直接用大語(yǔ)言模型的架構(gòu)去實(shí)現(xiàn)。量級(jí)大概也就是典型的像 16K context window 的，然后長(zhǎng)一點(diǎn)兒的，比如有64K，但沒(méi)有太長(zhǎng)的。 - 文本如果比較多，就適合用知識(shí)庫(kù)的方式管理。海量的文本做分段落，每個(gè)段落用embedding提取向量，存到向量數(shù)據(jù)庫(kù)里。
長(zhǎng)文本如何優(yōu)化First Token延遲問(wèn)題 RAG的成本原理 輸入階段：輸入內(nèi)容的大小、類型會(huì)有很大差別。在RAG環(huán)節(jié)也會(huì)分離線和在線。離線是預(yù)先所有內(nèi)容用Embedding模型等處理一邊，切分然后生成向量入庫(kù)，甚至在中間還可以做數(shù)據(jù)挖掘提取各種標(biāo)簽用于搜索中做過(guò)濾。在這其中，也可以將總結(jié)同步生成出來(lái)，是否要生成總結(jié)以及是否伴隨細(xì)節(jié)，都會(huì)對(duì)成本直接影響。 入庫(kù)成本的天花板：用小的Embedding模型把所有內(nèi)容刷一遍，然后再用大模型把內(nèi)容提取標(biāo)簽或總結(jié)，所產(chǎn)生的成本基本是一次性入庫(kù)成本的天花板。 輸出階段（Serving）：每次的 serving 的服務(wù)成本，取決于retrieve 出來(lái)多少。這和業(yè)務(wù)邏輯設(shè)計(jì)的有關(guān)，可以是TOP3或者TOP5。然后取這里邊的乘積，比如說(shuō)五個(gè)片段，每一個(gè)片段的平均長(zhǎng)度是 1, 000 個(gè)tokens，那每一個(gè)平均的 context 長(zhǎng)度就已經(jīng)是 5, 000 個(gè)tokens。再加上用戶的query，一般情況下長(zhǎng)度還是遠(yuǎn)小于長(zhǎng)文本方案的長(zhǎng)度，按極限來(lái)說(shuō)長(zhǎng)文本是每次付出兩個(gè) milliontoken 的推理成本，那 RAG 的方案可能就是 5, 000 個(gè)token，每次的推理成本大概是這么一個(gè)感覺(jué)，但還要考慮到 RAG 有一次性的入庫(kù)成本，包括除了入庫(kù)之外，存儲(chǔ)還有成本，但是存儲(chǔ)成本相對(duì)低。 其他成本：需要維護(hù)data pipelines，即需要長(zhǎng)期的維護(hù)數(shù)據(jù)。做數(shù)據(jù)更新，即增刪改查，還有很多工程成本。 - 總體分配：推理成本不一定是最大的部分，如果是使用量非常大的服務(wù)，推理可能是成本大頭。但如果使用量很小，比如說(shuō)企業(yè)知識(shí)庫(kù)文檔量極多，但大多數(shù)文檔的使用頻率非常低。那一次性入庫(kù)和存儲(chǔ)成本變成主要部分。
長(zhǎng)文本的降本方向 - 降本方面有一篇paper就是關(guān)于那個(gè)長(zhǎng)文的推理的一個(gè)總結(jié)，來(lái)自于付瑤的博客的最新的一篇，從四個(gè)角度去分析了目前有可能去降低成本的這個(gè)方向。包括https://character.AI他們最近也發(fā)了一篇博客，就介紹了他們?cè)谶@方面的一些努力。
具體的選擇比較需要看場(chǎng)景 單純從學(xué)術(shù)上，長(zhǎng)文本跟RAG有非常大的差別，沒(méi)有太多互相之間比較的點(diǎn)。很多指標(biāo)雖然是同樣的指標(biāo)但是要求千差萬(wàn)別。在AI場(chǎng)景里面，需要根據(jù)不同的場(chǎng)景分析特點(diǎn)。 需要從業(yè)務(wù)實(shí)際的情況去考慮，支持的業(yè)務(wù)的性質(zhì)是什么？所需要工具有什么主要特點(diǎn)？比如關(guān)注延遲，關(guān)注整個(gè)系統(tǒng)的運(yùn)維成本、機(jī)器成本？還是關(guān)注用戶體驗(yàn)？比如問(wèn)答愿意花 10 美金，只要這個(gè)問(wèn)答能答對(duì)就有價(jià)值。 長(zhǎng)文本是大語(yǔ)言模型能力增長(zhǎng)非常好的體現(xiàn)，但是大語(yǔ)言模型肯定不只有這一個(gè)能力，那么即便是短文本里邊，比如 reasoning 能力，數(shù)理邏輯的感知，在實(shí)際業(yè)務(wù)中非常重要；然后 RAG雖然說(shuō)是叫 retrieval augmented generation，其實(shí)大家主要的關(guān)注點(diǎn)是在retrieval上，功能類似于搜索。 - 現(xiàn)在在新的AI體系下，包括新的技術(shù)軟件的基建，包括像向量數(shù)據(jù)庫(kù)大語(yǔ)言模型，也是數(shù)據(jù)處理或者說(shuō)數(shù)據(jù)挖掘的工具之一。以上重新組裝成了一套搜索的系統(tǒng)，包括數(shù)據(jù)流轉(zhuǎn)和處理系統(tǒng)，然后這套系統(tǒng)再去支撐業(yè)務(wù)，在應(yīng)用中是否合適？在不同的業(yè)務(wù)下應(yīng)該有什么樣的變化？應(yīng)該選用什么樣的變種？應(yīng)該根據(jù)實(shí)際去判定。
02 部署落地與權(quán)限安全差別RAG部署有許多系統(tǒng)化優(yōu)化點(diǎn)
RAG分化程度非常高，因?yàn)镽AG是許多東西的組成，類似大數(shù)據(jù)生態(tài)，里邊有非常多的環(huán)節(jié)，從數(shù)據(jù)抓取、數(shù)據(jù)清洗、數(shù)據(jù)挖掘，然后預(yù)處理，再經(jīng)過(guò)模型分析，比如說(shuō)embedding模型生成向量，然后再做數(shù)據(jù)的持久化，serving stack，就是怎么能夠非常 efficiently 把東西檢索出來(lái)。 然后到檢索層面上整個(gè)serving鏈路，從某個(gè) query 的語(yǔ)義識(shí)別到解析，可能要路由到不同的業(yè)務(wù)邏輯上。有的是用向量檢索，有的直接通過(guò)規(guī)則，有的通過(guò)大語(yǔ)言模型進(jìn)行回答。然后最后再加一些guardrails，比如說(shuō)要檢查一下這個(gè)是否符合價(jià)值觀，或者不安全的內(nèi)容，然后再去作為回答的后處理。 各個(gè)環(huán)節(jié)基本上把數(shù)據(jù)基礎(chǔ)軟件的環(huán)節(jié)都涉及到了，還涉及到模型的hosting，machine learning infra stack 里邊的東西，包括部署到生產(chǎn)環(huán)境之中，要有 continuous evaluation，要有監(jiān)控 observability ，涉及到的方面會(huì)非常多。 - 所以在實(shí)際部署的時(shí)候，客戶有的是自研一部分，然后用一部分開(kāi)源的組件，有的用第三方的服務(wù)商所提供的組件，也有全部交給集成商去做、交給云廠去做的，還有用self service 方式，就是用一個(gè)定制化程度不高，但是前前后后全都給做了公開(kāi)服務(wù)的套件，這里邊的情況比較復(fù)雜。采用什么方法取決于客戶業(yè)務(wù)是什么樣的訴求，尤其是對(duì)定制化，對(duì)功能有沒(méi)有客戶自己特殊的要求等等，造成解決方式的多樣性和可選方案的多樣性。
長(zhǎng)文本（大模型）的部署相對(duì)簡(jiǎn)單 大模型的部署要么用開(kāi)放的API服務(wù)，比如說(shuō)月之暗面提供的公有云上的服務(wù)，要么客戶自己私有化部署的開(kāi)源方案，或者大模型廠商提供的私有部署方案主要是這兩種情況。 就從部署技術(shù)而言，能解決這個(gè)問(wèn)題的人大部分都是大的云廠和大模型公司本身，或者有一些開(kāi)源項(xiàng)目，如vLLM 能做一些inference的優(yōu)化。這一塊的分化程度是比較低的。 - 長(zhǎng)文本做得比較好的一些模型廠商，一般提供的都是閉源模型。可能因?yàn)閷?duì)于長(zhǎng)文本模型來(lái)說(shuō)，部署和推理中間牽扯到比較復(fù)雜，現(xiàn)在還沒(méi)有一個(gè)特別好的開(kāi)源長(zhǎng)文本模型，支持用戶的本地化部署。
?RAG可以做到很高精度的權(quán)限劃分? 權(quán)限可以分為大權(quán)限和小權(quán)限。大權(quán)限，比如數(shù)據(jù)根本不能上網(wǎng)，需要放在本地一體化的硬件數(shù)據(jù)中；或者說(shuō)數(shù)據(jù)可以聯(lián)網(wǎng)，但是只能在存儲(chǔ)在客戶私有的IDC 里，但I(xiàn)DC不能連接公有云或者不能使用公有云廠提供的第一方服務(wù)。小權(quán)限，不限制云服務(wù)使用方式，但是需要保證不同部門不能訪問(wèn)他部門內(nèi)限制數(shù)據(jù)。 從大權(quán)限到小權(quán)限中間是連續(xù)的光譜，采用RAG的方案，只要保證基礎(chǔ)軟件，包括machine learningstack 的組裝都符合對(duì)應(yīng)的權(quán)限的需求即可。 保證權(quán)限的統(tǒng)一性。比如有不能聯(lián)網(wǎng)的要求，所有stack的行為就必須得在盒子里邊發(fā)生，或者說(shuō)是我都在公有云上，但是不同用戶能訪問(wèn)什么要被 stack 里的每一個(gè)步驟里邊都要遵守。 - 有的客戶數(shù)據(jù)的某些處理可以是上網(wǎng)的，某些處理是必須在私有環(huán)境中進(jìn)行，那么這種情況會(huì)稍微復(fù)雜一點(diǎn)，需要根據(jù)場(chǎng)景定制化一個(gè)方案。但一般來(lái)說(shuō)這種方案都是可以實(shí)施的，因?yàn)樵诿恳粋€(gè)成熟的組件里邊，比如向量數(shù)據(jù)庫(kù)，像Zilliz其實(shí)支持了各種部署方式，從私有的到公有的，有的用開(kāi)源，有的用商業(yè)化服務(wù)，只要保證每一個(gè)組件都能夠滿足整條業(yè)務(wù)鏈路對(duì)于前線的要求就可以了。
?長(zhǎng)文本在權(quán)限上更取決于數(shù)據(jù)架構(gòu)設(shè)計(jì)? - 在權(quán)限處理上，類似問(wèn)題在沒(méi)有大模型的時(shí)候也會(huì)遇到，跟具體用什么樣的模型關(guān)聯(lián)不是特別大，因?yàn)槟Ｐ图夹g(shù)并不涉及這方面的細(xì)節(jié)，主要還是數(shù)據(jù)架構(gòu)設(shè)計(jì)和權(quán)限管理。這個(gè)取決于各家的標(biāo)準(zhǔn)。
企業(yè)落地RAG時(shí)克服冷啟動(dòng)、降低落地難度的方法 落地里邊是有很多挑戰(zhàn)的，尤其對(duì)于傳統(tǒng)企業(yè)，沒(méi)有成熟的AI技術(shù)棧，又有非常復(fù)雜的業(yè)務(wù)訴求，很難通過(guò)通用的方案去解決。這個(gè)現(xiàn)狀造成落地具有很大挑戰(zhàn)，但這也是商業(yè)上的機(jī)會(huì)。 Zilliz選擇的方式：一方面先做好基礎(chǔ)設(shè)施，同時(shí)跟生態(tài)，比如開(kāi)源的做邏輯串聯(lián)，或者做某一個(gè)方面，比如像知識(shí)圖譜，或者 evaluation 這些項(xiàng)目做集成、做合作，然后給大家提供更多的工具選擇；另外一方面也跟商業(yè)項(xiàng)目形成伙伴，這里邊有很多落地的咨詢服務(wù)、定制化服務(wù)，甚至本地部署解決數(shù)據(jù)的管理和安全問(wèn)題。這些需要一些有服務(wù)能力的商業(yè)項(xiàng)目去做實(shí)施，Zilliz也選擇合作。 - 需要整個(gè)生態(tài)，包括大模型廠商，應(yīng)用廠商、咨詢能力的公司一起構(gòu)建開(kāi)發(fā)者或者說(shuō)服務(wù)矩陣，通過(guò)多層的能力去解決客戶的實(shí)際問(wèn)題。
月之暗面在長(zhǎng)文本使用中的配套方案 目前，月之暗面和谷歌的Gemini，現(xiàn)在都有上線長(zhǎng)上下文緩存的服務(wù)給開(kāi)發(fā)者。月之暗面之前在founder park 的 AGI Playground 上面做了發(fā)布，現(xiàn)在也可以直接使用。 以客服群里的文檔機(jī)器人舉例，其實(shí)只有 32K 的長(zhǎng)度，但每小時(shí)有 20 次提問(wèn)，這其實(shí)是很容易達(dá)到的。只要群里面隨便跟同這個(gè)文檔機(jī)器人聊天幾句，就能達(dá)收支平衡，就是推理的開(kāi)銷就超過(guò)存儲(chǔ)的開(kāi)銷。如果是一些爆款應(yīng)用，比如說(shuō)之前很火的M.Riddle、哄哄模擬器、拜年模擬器等，可能在短時(shí)間內(nèi)，比如說(shuō)幾個(gè)小時(shí)內(nèi)有一個(gè)瞬時(shí)的爆發(fā)性流量，用這種方法也是非常的合適的。 - 這個(gè)是目前對(duì)開(kāi)發(fā)者來(lái)說(shuō)最容易接觸到的推理優(yōu)化方案。之前月之暗面也發(fā)了一篇叫mooncake的論文，具體闡述了 KV cache的推理集群是如何優(yōu)化的，并且這個(gè)優(yōu)化方案已經(jīng)在Kimi智能助手上線了相當(dāng)長(zhǎng)的時(shí)間。上了這個(gè)方案之后，讓 Kimi 智能助手每天能夠處理的推理量增加了80%。
03 場(chǎng)景：客服與Sales Agent客服與Sales Agent選擇取決于知識(shí)庫(kù)復(fù)雜度 場(chǎng)景所需要的文檔量級(jí)會(huì)直接影響選擇，例如幾千字或者幾萬(wàn)字規(guī)模適合長(zhǎng)文本模型+上下文緩存的方式，不僅能優(yōu)化價(jià)格，還可以優(yōu)化First Token的延遲。 例如營(yíng)銷群里的段問(wèn)題，多數(shù)已經(jīng)不需要人工介入，大模型能回答得很好，并且延遲可以控制在2-3秒。 例如游戲客服的文檔在幾萬(wàn)字，也符合上面的要求。還有一些特定場(chǎng)景，請(qǐng)求比較頻繁，共同的上下文比較集中，例如AI翻譯、針對(duì)AI文檔的回答等，也適合長(zhǎng)文本。 - 但到了更加復(fù)雜的場(chǎng)景，例如大型呼叫中心或者作業(yè)輔導(dǎo)，就需要長(zhǎng)文本+RAG；如果長(zhǎng)度特別長(zhǎng)，那可能就需要主要依靠RAG。
長(zhǎng)文本在相對(duì)簡(jiǎn)單知識(shí)庫(kù)時(shí)候的優(yōu)勢(shì) 單純從開(kāi)發(fā)角度來(lái)說(shuō)，只用長(zhǎng)文本會(huì)有優(yōu)勢(shì)，開(kāi)發(fā)比較簡(jiǎn)單，基本上不需要復(fù)雜的機(jī)構(gòu)或者使用其他的第三方工具，只需要把文本轉(zhuǎn)化成text，然后全部給大模型的message里即可，這個(gè)不在于使用效果有多大的差別，而是對(duì)于開(kāi)發(fā)者的負(fù)擔(dān)比較小。 如果用戶側(cè)問(wèn)經(jīng)常問(wèn)一些刁鉆的問(wèn)題，比如模型的推理價(jià)格報(bào)表，或一些比較復(fù)雜的問(wèn)題，比如用 a 模型相較于 b 模型能省多少錢？可能這個(gè)時(shí)候用長(zhǎng)文本是一個(gè)比較合適的選擇。 - 還是要看具體場(chǎng)景。可能有些場(chǎng)景，比如說(shuō)簡(jiǎn)單的客服，RAG和長(zhǎng)上下文它的效果都可以，都可以滿足日常的需求。
對(duì)準(zhǔn)確率要求高的場(chǎng)景如何選擇 04 場(chǎng)景：AI CodingAI Coding如何選擇 在很長(zhǎng)一段時(shí)間內(nèi)，這兩種技術(shù)都是需要去搭配使用的。產(chǎn)品經(jīng)理在做技術(shù)選型的時(shí)候，需要更深入的了解這兩個(gè)技術(shù)，去設(shè)計(jì)場(chǎng)景。 在AI coding細(xì)分賽道，已經(jīng)變得越來(lái)越專業(yè)，對(duì)模型的要求也越來(lái)越高。對(duì)于場(chǎng)景如何去獲取信息，要求也越來(lái)越高。 比如GitHub，推出了Github copilot workspace，這是更加專業(yè)的場(chǎng)景。 包括字節(jié)、騰訊和Google ，都推出瀏覽器VScode 的插件，甚至一些IDE能力。這樣他們可以更加全面的做代碼推理，不僅僅是代碼補(bǔ)全，還包括一跨文檔的能力，比如在一處進(jìn)行修改，能夠幫助把相關(guān)聯(lián)的地方全部都做修改，但這也需要更加復(fù)雜的產(chǎn)品設(shè)計(jì)能力。 - 現(xiàn)在什么代碼放到Context Window，什么放到RAG里沒(méi)有Best Practise。這類工作，具體先要?jiǎng)澐殖龊诵倪壿?，比如?MVC(model-view-controller)的話，是model 層面的邏輯，然后把view層面的邏輯給弱化，除非具體問(wèn)到的時(shí)候再把它們加進(jìn)來(lái)。需要要看具體的項(xiàng)目去做具體調(diào)整。
業(yè)務(wù)場(chǎng)景看代碼庫(kù)大小 如果是前端代碼，可能很多都是跟業(yè)務(wù)沒(méi)什么關(guān)系的代碼，可能就不那么的關(guān)鍵。 如果是一個(gè)智能合約，其核心邏輯非常短，百行之內(nèi)就能把核心的邏輯描述清楚。 產(chǎn)品類型也非常有關(guān)。像一些dify的代碼，大概在幾十行，就把核心的邏輯表述出來(lái)。 - 但比如游戲代碼，大概一大半的代碼是引擎。真正涉及到核心邏輯的代碼會(huì)很分散，這種的實(shí)現(xiàn)就會(huì)更困難。
1m Context Windown對(duì)于大部分科技公司還不夠用 百萬(wàn)代碼量可能是一個(gè)很小的代碼庫(kù)，千萬(wàn)代碼量可能也是小代碼庫(kù)。一個(gè)項(xiàng)目稍微復(fù)雜點(diǎn)的就能做到百萬(wàn)的量級(jí)的代碼量。 像 Google這樣大的體量，2015 年有 20 億行，一行一般幾十個(gè)token，所以代碼量在稍微大一點(diǎn)的軟件工程的場(chǎng)景下時(shí)巨大的。 如果能夠限定問(wèn)題所在的代碼范圍，比如說(shuō)某些文件夾，那么代碼量并不大，一個(gè)文件夾里面的幾個(gè)files，可能 5, 000 行，什么1萬(wàn)行就到頭，然后幾十個(gè)token一行，總計(jì)大概在幾十萬(wàn)token。 - 稍微上體量的中等公司，根據(jù)業(yè)務(wù)的情況，也有可能達(dá)到千萬(wàn)甚至更多的代碼行數(shù)，這樣token 數(shù)也要上億了。
對(duì)于代碼庫(kù)大的企業(yè)可以不用RAG嗎？ 可以不用RAG，但是需要有辦法把代碼篩選出來(lái)。 RAG背后是向量，向量搜索是基于語(yǔ)義的 similarity 去搜，對(duì)代碼的搜索除了語(yǔ)義還能利用其他信息。因?yàn)榇a是有結(jié)構(gòu)的，對(duì)于能夠解析的結(jié)構(gòu)，就不一定需要全用Vector similarity 去search。 比如可以根據(jù)項(xiàng)目名稱，模塊名稱先去找到大概的范圍，當(dāng)然這個(gè)范圍有多大的代碼量可能預(yù)先并不不知道，如果量特別大，可以結(jié)合長(zhǎng)文本。 - 如果量大且對(duì)成本的考量比較敏感，可以再用向量搜索的方式去做一些切塊，然后把里邊的部分代碼通過(guò)語(yǔ)義的 similarity 去搜出來(lái)，甚至可以結(jié)合標(biāo)簽，根據(jù)標(biāo)簽的similarity，或者根據(jù)大語(yǔ)言模型線下給這一部分代碼做的總結(jié)去搜索。這里邊有很多工程化方法。
客戶如何針對(duì)代碼進(jìn)行結(jié)構(gòu)解析和工程優(yōu)化 通用代碼結(jié)構(gòu)解析的能夠做到的程度：比如Java 的項(xiàng)目，因?yàn)?Java 的語(yǔ)法是相對(duì)標(biāo)準(zhǔn)，所以能夠解析出來(lái)它的類（function）的結(jié)構(gòu)，然后建立結(jié)構(gòu)化樹，該樹用來(lái)做從項(xiàng)目名到模塊的路由。這部分是有通用性的，因?yàn)楦骷矣玫腏ava的項(xiàng)目結(jié)構(gòu)大體都是一樣，甚至有一些框架帶有一定結(jié)構(gòu)，然后這個(gè)框架是通用的。 不能通用的部分：比如，某個(gè)模塊是由某個(gè)團(tuán)隊(duì)管理，該團(tuán)隊(duì)要負(fù)責(zé)給該模塊寫說(shuō)明，因?yàn)榇a里幾乎找不出來(lái)它跟業(yè)務(wù)邏輯之間的關(guān)系。這一段代碼，具體是給哪個(gè)模塊，給哪個(gè)業(yè)務(wù)里邊的哪個(gè)功能的，如果沒(méi)有歷史背景，只有維護(hù)這個(gè)東西的團(tuán)隊(duì)知道，甚至維護(hù)的團(tuán)隊(duì)時(shí)間久了也不知道了。 企業(yè)實(shí)際應(yīng)用中會(huì)遇到這類 “三不管”代碼，是個(gè)比較現(xiàn)實(shí)的問(wèn)題。這個(gè)現(xiàn)實(shí)問(wèn)題就很難用通用的方法去解，可能有的甚至要通過(guò)組織架構(gòu)的方式去解，這些就需要做很多定制化的東西。 一些開(kāi)源的項(xiàng)目會(huì)相對(duì)容易，host 在 GitHub 上，各方面的文檔的read me，各種描述軟件，比如說(shuō)各種 function 的使用文檔都是內(nèi)嵌在 code 里邊，有了這些前置條件，這屬于比較容易觸達(dá)到這個(gè)問(wèn)題的核心相對(duì)好用通用的辦法去解決。 - 但如果是個(gè)對(duì)知識(shí)產(chǎn)權(quán)有很強(qiáng)的訴求的公司，組織架構(gòu)非常復(fù)雜，代碼的管理也比較的粗糙，然后文檔什么的建設(shè)都不健全，如果是這樣的場(chǎng)景，解決起來(lái)就非常困難。
05 場(chǎng)景：搜索搜索場(chǎng)景的選擇 這種選擇大概率是出于成本等的考量，不能承擔(dān)太高的推理成本的。因?yàn)樗阉魇巧虡I(yè)服務(wù)，而不是慈善業(yè)務(wù)。 所以如果每一個(gè)免費(fèi)用戶都花幾美金的成本去承擔(dān)query的成本，這肯定是付不起的。所以背后一定是做了大量的優(yōu)化，Perplexity 宣稱做了一些小一點(diǎn)的模型，并單獨(dú)為這個(gè)場(chǎng)景做了模型優(yōu)化，這樣它能夠把成本降下來(lái)。 大家會(huì)覺(jué)得RAG 就是成本很低，但量大情況也不一定。如果使用的體量非常大的話，向量數(shù)據(jù)庫(kù)本身的存儲(chǔ)成本，還有進(jìn)行服務(wù) 的serving 成本也是很高，也需要做一些優(yōu)化。 比如Zilliz最近在做的冷熱存儲(chǔ)的切換，將價(jià)值不高、訪問(wèn)頻次不高的數(shù)據(jù)放到冷存儲(chǔ)里，以節(jié)省成本。如果用 RAG 都有成本的問(wèn)題，那全都用大語(yǔ)言模型去付出高昂的推理成本，應(yīng)該說(shuō)在這些商業(yè)的產(chǎn)品里邊一般是不現(xiàn)實(shí)的。 - 甚至剛才所說(shuō)的coding場(chǎng)景成本下降都不一定很明顯。舉之前有客戶疑問(wèn)：Github Copilot 做的不錯(cuò)，是否拿長(zhǎng)文本做的，'我把整個(gè)項(xiàng)目給丟進(jìn)去了，然后我去問(wèn)的時(shí)候，他這個(gè)回答的效果就很好，就是說(shuō)他好像方方面面都照顧到了，那不就是長(zhǎng)文本嗎'。如果一個(gè)建庫(kù)就需要超過(guò) 10 分鐘，背后大概率是離線做了索引。當(dāng)搜的時(shí)候，每一個(gè) query的延遲，非常短，瞬間搜出來(lái)了，采用的技術(shù)一定不是長(zhǎng)文本， 是結(jié)合了RAG的。Github Copilot的建庫(kù)時(shí)間較長(zhǎng)，單次搜索延遲很短，應(yīng)該是采用了RAG的方案。
AI搜索的語(yǔ)義提取顆粒度 分兩部分，第一部分是做語(yǔ)義檢索，語(yǔ)義檢索本質(zhì)上是粗顆粒度的模糊的搜索，把這一篇網(wǎng)頁(yè)分成 50 個(gè)片段，每個(gè)片段 500 個(gè)字，然后整個(gè)片段就生成一個(gè)向量，然后向量代表了這個(gè)網(wǎng)頁(yè)抽象語(yǔ)義，或者是它的一個(gè)指紋或表征，這是一種抽取的方式，它并沒(méi)有邏輯的關(guān)系。 至于向量怎么生成出來(lái)，拿深度神經(jīng)網(wǎng)絡(luò)模型訓(xùn)出來(lái)的，然后對(duì)齊了一些業(yè)務(wù)場(chǎng)景對(duì)模型的需求，就是語(yǔ)義相似的東西，就給把這個(gè)向量給分布到相似的空間里邊的位置上，然后這是一部分的抽取。 另外一部分就是給提取出來(lái)的東西標(biāo)簽、關(guān)鍵字，或者根據(jù)它的內(nèi)容提出來(lái)一些描述性的標(biāo)簽。這個(gè)一般也是通過(guò)模型來(lái)實(shí)現(xiàn)，有的是用大語(yǔ)言模型做的，有的是專有模型來(lái)做。 - 這兩種情況在互聯(lián)網(wǎng)公司，因?yàn)榧夹g(shù)能力會(huì)比較強(qiáng)，一般都是存在的。
類似百度和Google已經(jīng)采用AI搜索，還是會(huì)偏傳統(tǒng)更多采用倒排？ 是用到向量檢索去檢索到一些內(nèi)容，然后再搭配關(guān)鍵字的倒排和一些其他標(biāo)簽。Web 搜索里叫token base retrieve，把那些 token 相關(guān)的東西都去除。然后對(duì)所有這些拿出來(lái)的東西放在一起進(jìn)行 merge，這個(gè)merge 是根據(jù)業(yè)務(wù)和渠道的特點(diǎn)做重排序。 然后重排序里邊，像互聯(lián)網(wǎng)的話，業(yè)務(wù)是占主流的，即要達(dá)到什么商業(yè)目的，重排序要與根據(jù)商業(yè)目的對(duì)齊。 - 對(duì)企業(yè)知識(shí)庫(kù)談不上商業(yè)考量的場(chǎng)景，更多是根據(jù)問(wèn)答質(zhì)量去考量。
現(xiàn)在有一些做AI搜索公司，宣稱壁壘是靠去做緩存到的網(wǎng)頁(yè)的語(yǔ)義索引來(lái)積累語(yǔ)義索引庫(kù)。按照合格邏輯，對(duì)于百度和谷歌的工作來(lái)講，它其實(shí)已經(jīng)建立了全網(wǎng)網(wǎng)頁(yè)細(xì)粒度的索引庫(kù)的話，那么對(duì)于 AI 搜索的創(chuàng)業(yè)公司，大廠還是有領(lǐng)先優(yōu)勢(shì)的嗎？ 06 其他場(chǎng)景涉及數(shù)值計(jì)算以及Text2SQL的選擇
Text to SQL可以看到成熟度越來(lái)越高。但總體而言數(shù)值計(jì)算，并不太適合用大語(yǔ)言模型這種概率模型直接去做。數(shù)值計(jì)算比較適合使用邏輯模型或者規(guī)則工具去做，比如說(shuō)SQL。大語(yǔ)言模型在里面起到的作用是把自然語(yǔ)言所表達(dá)的問(wèn)題，拆解成有邏輯關(guān)聯(lián)的步驟，然后將這些步驟轉(zhuǎn)化sql。達(dá)到的效果是輸入自然語(yǔ)言，輸出是SQL 的查詢語(yǔ)句，然后SQL查詢語(yǔ)句進(jìn)入數(shù)據(jù)庫(kù)運(yùn)行，這是一種比較好的方式。 如果非要用大語(yǔ)言模型去解決這樣的問(wèn)題，即仍然依賴于概率分布，不去借助類似計(jì)算器這樣的工具，則需要給大語(yǔ)言模型很多例子，至少告訴大語(yǔ)言模型怎么計(jì)算步驟的拆解。但是大語(yǔ)言模型還是擺脫不了next token predictor的情況 ，即知道自然語(yǔ)言的分布是怎樣的，回答的結(jié)果就是概率分布的結(jié)果。比如說(shuō)之前 3.11 和3.8比大小的情況，大預(yù)言模型會(huì)認(rèn)為3.11更大，是因?yàn)榇笳Z(yǔ)言模型可能理解的是兩個(gè)版本號(hào)，比如Python的3.11和3.8。大語(yǔ)言模型理解的是3.11版本比3.8版本更晚出現(xiàn)，肯定更強(qiáng)，所以更大，而不是不是按照人類日常使用的小數(shù)規(guī)則。 - 這樣的例子非常多，有一些非常識(shí)性的問(wèn)題，人類可能不可能犯的錯(cuò)誤。但是大型語(yǔ)言模型可能是語(yǔ)料被污染，或者是人類語(yǔ)言自然就有的歧義，可能就會(huì)弄錯(cuò)。對(duì)于非常嚴(yán)肅的計(jì)算場(chǎng)景，則一般需要額外的verify手段保證大語(yǔ)言模型做的是正確。
07 技術(shù)爬坡長(zhǎng)文本的技術(shù)爬坡方向
推理質(zhì)量不能有所下降，如何在保質(zhì)保量的做長(zhǎng)文本的推理，是一件非常困難的事。 解決了能力問(wèn)題之后，還要解決貴且慢的問(wèn)題。前面講到兩個(gè)瓶頸，一個(gè)是推理成本會(huì)特別高，一個(gè)是首token會(huì)特別慢。在一個(gè)階段解決好這兩個(gè)問(wèn)題之后，待上下文窗口再提升到下一個(gè)里程碑，這兩個(gè)問(wèn)題又會(huì)出現(xiàn)。 但還是要持續(xù)去研究expand context window, 因?yàn)橛幸粋€(gè)現(xiàn)象表明，當(dāng)長(zhǎng)文本能力上去之后，有很多附帶的能力會(huì)涌現(xiàn)出來(lái)。 - 具體到以后長(zhǎng)度能到多長(zhǎng)，現(xiàn)在行業(yè)沒(méi)有共識(shí)。具體的技術(shù)，從實(shí)驗(yàn)室環(huán)境到真正的生產(chǎn)環(huán)境，會(huì)有很大的gap。10 Million 的模型， 100 Million的模型可能已經(jīng)有了，但是可能推不到生產(chǎn)。主要是延遲特別高，或者精度特別的差。
RAG的技術(shù)爬坡方向 整個(gè)鏈路變得更長(zhǎng)了，遠(yuǎn)遠(yuǎn)比半年之前變得更復(fù)雜，開(kāi)始有更多的技術(shù)棧被加入進(jìn)來(lái)。 大概 6- 12 個(gè)月之前，市場(chǎng)對(duì)于 RAG 的印象是：先embedding 模型抽象出一個(gè)向量，然后導(dǎo)入向量數(shù)據(jù)庫(kù)里邊，然后搜索出向量背后代表的短文本塊，放入大語(yǔ)言模型。 6個(gè)月之前，甚至三五個(gè)月之前，出現(xiàn)了一種說(shuō)法，如果不用向量數(shù)據(jù)庫(kù)，把整個(gè)文章輸入大語(yǔ)言模型就解決問(wèn)題了，所以在Twitter等自媒體上，開(kāi)始有了長(zhǎng)文本vsRAG 的提法，這個(gè)故事很抓眼球。但后來(lái)實(shí)際的情況沒(méi)這么簡(jiǎn)單，這里邊是一整個(gè)鏈路的問(wèn)題，這兩個(gè)東西不是簡(jiǎn)單就能比較的。 開(kāi)始大家都覺(jué)得只應(yīng)該用向量。但慢慢的發(fā)現(xiàn)其實(shí)向量檢索只是很復(fù)雜技術(shù)棧中間的一塊而已。包括有人覺(jué)得向量數(shù)據(jù)庫(kù)是不是有能力做端到端服務(wù)，或者向量數(shù)據(jù)庫(kù)是不是能做端到端服務(wù)，直接提供搜索業(yè)務(wù)，但實(shí)際不然。 實(shí)際情況比向量檢索加大語(yǔ)言模型拼接更復(fù)雜。最近新涌現(xiàn)出來(lái)的技術(shù)棧提供了很多其他的解決方式，比如知識(shí)圖譜，包括長(zhǎng)文本用于離線數(shù)據(jù)的挖掘，即給很長(zhǎng)的文本進(jìn)行壓縮，總結(jié)出來(lái)一些信息，然后這個(gè)信息更容易進(jìn)行搜索?；蛘咭?yàn)橛虚L(zhǎng)文本，所以對(duì)文本檔案的切分就不用那么精益求精了，稍微長(zhǎng)一點(diǎn)也沒(méi)有關(guān)系。甚至于其他新的embedding 模型類型，根本就不在意切斷的具體方法，但這個(gè)主要還是在學(xué)術(shù)界領(lǐng)域在討論，實(shí)際應(yīng)用的比較少。 從語(yǔ)義的識(shí)別，query serving角度來(lái)說(shuō)，原來(lái)覺(jué)得query 就應(yīng)該直接去匹配文本段，但實(shí)際上不是所以情景都適合這樣做。很多時(shí)候 query 不是一個(gè)簡(jiǎn)單拿一個(gè)文本段就能回答了。很可能query 含有一個(gè)復(fù)合問(wèn)題，需要分為好幾步才能夠解答，比如說(shuō)是需要比較分析的問(wèn)題，比如A和B之間的區(qū)別是什么？如果是人去做這類問(wèn)題的回答，可能會(huì)先看 A 是什么，然后 B 是什么，這兩者都充分理解后，然后再去做一個(gè)比較，這就是一個(gè)多步問(wèn)題。 大語(yǔ)言模型的進(jìn)展除了長(zhǎng)文本本身之外，包括推理和邏輯的能力也在提升，然后就出現(xiàn)了用大語(yǔ)言模型去解析query語(yǔ)義，將其拆成多步，甚至產(chǎn)生了是交互式的問(wèn)題解答，即先解答一步，然后根據(jù)該步的返回的情況，再讓大語(yǔ)言模型去決后面一步要解決什么樣的問(wèn)題。這樣復(fù)雜的 query 的解析和路由的方式已經(jīng)開(kāi)始出現(xiàn)了，而且在前期生產(chǎn)應(yīng)用的效果看起來(lái)也不錯(cuò)。 整個(gè)過(guò)程是需要online和offline的結(jié)合：傳統(tǒng)搜索，就有offline的部分， offline 就是像管理圖書館中的圖書一樣，怎么分門別類的把書放好，這樣進(jìn)行檢索的的時(shí)候更容易。另外一部分是online 的部分， online 的時(shí)候就是用戶要過(guò)來(lái)查這個(gè)書了，那怎么能夠快速把這書找到，依賴于線下做的事情，然后這兩塊現(xiàn)在都有進(jìn)化，都有新的技術(shù)棧的加入，整體來(lái)看實(shí)現(xiàn)效果包括應(yīng)用情況也比 6 個(gè)月之前要好了很多。 - 可以看到整個(gè)市場(chǎng)中，越來(lái)越多的人開(kāi)始探索更細(xì)節(jié)的問(wèn)題，比如語(yǔ)義識(shí)別應(yīng)該怎么做？用什么模型比較好？該用大的模型還是小的模型，還是幾個(gè)模型堆在一起做gate，像基層鏈路關(guān)系。然后單純的問(wèn) RAG是什么的問(wèn)題越來(lái)越少，說(shuō)明已經(jīng)慢慢的開(kāi)始解決落地的問(wèn)題，而不只是概念驗(yàn)證的問(wèn)題。
長(zhǎng)文本與RAG也在融合部署 比如說(shuō)開(kāi)始有離線做數(shù)據(jù)挖掘的情況出現(xiàn)了，比如說(shuō)最簡(jiǎn)單的數(shù)據(jù)挖掘就寫一個(gè)總結(jié)。除了給這一整本書的很長(zhǎng)的內(nèi)容做了場(chǎng)景切分之外，還去把這一本書在離線的時(shí)候都讀了，就是拿大語(yǔ)言模型長(zhǎng)文本的能力去讀了一遍，然后寫了一個(gè)總結(jié)，這個(gè)總結(jié)本身也是作為召回的語(yǔ)料之一。 然后在serving的階段，原來(lái)大家會(huì)謹(jǐn)小慎微的往里邊塞東西，現(xiàn)在可能多塞幾個(gè)片段，甚至切分 chunking 都不用切的特別小，可以切很大的chunk。然后把幾個(gè)很大的 chunk 加在一起，非常長(zhǎng)的東西扔進(jìn)去，只要能承擔(dān)這個(gè)成本。 這里邊也會(huì)有一些問(wèn)題，有trade off，比如說(shuō)放了很長(zhǎng)的東西，對(duì)大語(yǔ)言模的穩(wěn)定性要求就很高，就是剛才提到大海撈針或者數(shù)星星的這種能力要逐步的增強(qiáng)。還有推理的能力，大模型需要注意到這些任務(wù)里面有自相矛盾的內(nèi)容，它應(yīng)該有判斷。 - 整個(gè)進(jìn)步是螺旋上升的，就是一邊在系統(tǒng)層，比如說(shuō)搜索數(shù)據(jù)處理在提升。另外一方面，大語(yǔ)言模型作為框架里邊非常重要的工具，本身也要提升。整個(gè)系統(tǒng)會(huì)采用大語(yǔ)言模型工具提升的能力來(lái)，甚至有新的用法，就比如說(shuō)剛才提到的做總結(jié)，做數(shù)據(jù)挖掘這類事情。
08 GraphRAGGraphRAG 帶來(lái)的啟發(fā)？GraphRAG的技術(shù)路線是否是目前的best practice？ GraphRAG在一些方面填補(bǔ)了知識(shí)圖譜的空白，但實(shí)際上它做的不是一個(gè)典型傳統(tǒng)的知識(shí)圖譜，GraphRAG做了兩件事情： 一是創(chuàng)造了community的概念，本質(zhì)上是利用知識(shí)圖譜進(jìn)行數(shù)據(jù)挖掘。通俗點(diǎn)說(shuō)，把一個(gè)很長(zhǎng)的一個(gè)文檔，或者說(shuō)文檔庫(kù)里邊的內(nèi)容先做了切分，這個(gè)有點(diǎn)像 RAG 里邊做 chunking ，切分后對(duì)于每一個(gè)單元去提取里邊的知識(shí)三元組，比如說(shuō)一個(gè)實(shí)體和另外一個(gè)實(shí)體中間是什么關(guān)系。比如說(shuō)奧巴馬是美國(guó)總統(tǒng)，這樣的關(guān)系提取出來(lái)。 二是還把知識(shí)圖譜跟向量檢索做了結(jié)合。一方面用知識(shí)圖譜做了數(shù)據(jù)挖掘，建立樹形的信息結(jié)構(gòu)，這個(gè)叫community，相關(guān)的 entity 聚合成小的community，然后把多個(gè)小的 community聚合成大的community，相當(dāng)于采用金字塔型的結(jié)構(gòu)整理了信息，并做了總結(jié)。使得每一個(gè)三元組成為信息單元。對(duì)知識(shí)三元組本身也做了向量化。然后將所有這些東西放在向量數(shù)據(jù)庫(kù)里邊，根據(jù)語(yǔ)義去做召回。GraphRAG召回的方法的設(shè)計(jì)也比較全面，考慮到小的entity，也考慮到總結(jié)性的信息。最后把這一套東西做了開(kāi)源的實(shí)現(xiàn)，這是價(jià)值比較大的點(diǎn)。
|
