我大部分時(shí)間都在構(gòu)建和改進(jìn) Retrieval-Augmented Generation (RAG) 應(yīng)用。

我相信 RAG 可能是最受歡迎的 AI 應(yīng)用之一。它無處不在，從聊天機(jī)器人到文檔摘要。

我也相信，由于各種原因，許多 RAG 應(yīng)用最終未能部署，其中很多并非技術(shù)原因。然而，我希望自己早知道一些技術(shù)方面的知識(shí)，以創(chuàng)建更有效的 RAG。

但這就是我們學(xué)習(xí)新事物的方式。沒有比構(gòu)建并失敗更好的工程學(xué)習(xí)方法了。

從我的失敗中，我學(xué)到了一些寶貴的經(jīng)驗(yàn)教訓(xùn)，這些經(jīng)驗(yàn)對首次構(gòu)建 RAG 的人很有幫助。你不必重復(fù)我犯過的錯(cuò)誤，這樣你就能更快前進(jìn)。

那么，讓我們談?wù)劦谝粋€(gè)錯(cuò)誤。

如果你對本文感興趣，請點(diǎn)贊、轉(zhuǎn)發(fā)、關(guān)注，感謝~~~

向量數(shù)據(jù)庫并非硬性規(guī)定

幾乎所有關(guān)于 RAG 的網(wǎng)絡(luò)教程都使用向量數(shù)據(jù)庫。如果你搜索過 RAG 相關(guān)內(nèi)容，你會(huì)明白我的意思。

基于向量的檢索無疑是 RAG 成功的重要因素。向量嵌入非常適合映射文本的語義含義。它們也適用于不同大小的文本。你的查詢可能是一句話，但你的文檔存儲(chǔ)包含整頁文章？——向量搜索可以處理。

然而，檢索并不僅限于基于向量的檢索。

RAG 可以從互聯(lián)網(wǎng)、關(guān)系數(shù)據(jù)庫、Neo4J 中的知識(shí)圖譜或三者的組合中檢索信息。

在許多情況下，我注意到混合方法能帶來更好的性能。

對于通用應(yīng)用，你可以使用向量數(shù)據(jù)庫，但當(dāng)向量數(shù)據(jù)庫中沒有所需信息時(shí)，你可以搜索互聯(lián)網(wǎng)。

對于客戶聊天機(jī)器人，你可能需要讓 RAG 訪問部分客戶數(shù)據(jù)庫，這可以是關(guān)系數(shù)據(jù)庫。

企業(yè)的知識(shí)管理系統(tǒng)可能會(huì)創(chuàng)建一個(gè)知識(shí)圖譜，并從中檢索信息，而不是使用向量數(shù)據(jù)庫。

這些都是 RAG 的定義。

然而，選擇數(shù)據(jù)源的過程并非直截了當(dāng)。你需要嘗試各種選項(xiàng)，了解每種方法的優(yōu)點(diǎn)。接受或拒絕一個(gè)想法的理由可能受技術(shù)和業(yè)務(wù)因素的影響。

例如，你可以為每個(gè)客戶簡介信息創(chuàng)建文本版本并進(jìn)行向量化以供檢索。這對于查詢來說可能很高效，因?yàn)槟阒惶幚硪粋€(gè)數(shù)據(jù)庫。但它的準(zhǔn)確性可能不如運(yùn)行 SQL 查詢。這是技術(shù)原因。

然而，讓 LLM 運(yùn)行 SQL 查詢可能導(dǎo)致 SQL 注入攻擊。這是技術(shù)和業(yè)務(wù)上的問題。

向量數(shù)據(jù)庫在語義檢索方面也很高效。但這并不意味著其他數(shù)據(jù)庫不能處理語義檢索；幾乎所有其他數(shù)據(jù)庫都可以進(jìn)行向量搜索。

因此，如果你決定在 RAG 中使用某種形式的向量嵌入，這里還有一個(gè)建議。

優(yōu)先選擇經(jīng)過微調(diào)的小模型

嵌入模型可以將任何內(nèi)容轉(zhuǎn)化為向量形式。大型模型的性能通常優(yōu)于小型模型。

但這并不意味著越大越好。

別管模型大小。所有模型都在公開數(shù)據(jù)集上訓(xùn)練。它們能區(qū)分“蘋果”水果和“蘋果”品牌。但如果你和朋友用“蘋果”作為暗號，嵌入模型無法知道。

然而，我們創(chuàng)建的幾乎所有應(yīng)用都專注于一個(gè)小的細(xì)分領(lǐng)域。

對于這些應(yīng)用，大型模型的收益是微不足道的。

這里有一個(gè)不同的做法。

為你的領(lǐng)域數(shù)據(jù)創(chuàng)建一個(gè)數(shù)據(jù)集，并對小型嵌入模型進(jìn)行微調(diào)。

小型模型足以捕捉語言細(xì)微差別，但可能無法理解在不同語境中有特殊含義的詞。

但仔細(xì)想想，你的模型為什么需要理解木星的衛(wèi)星？

小型模型更高效。它們速度快，成本低。

為了彌補(bǔ)模型在領(lǐng)域知識(shí)方面的不足，你可以對其進(jìn)行微調(diào)。

這兩個(gè)建議可以優(yōu)化索引部分以實(shí)現(xiàn)高效檢索。然而，檢索過程也可以進(jìn)一步優(yōu)化。

檢索過程可以更高級

最直接的檢索過程是直接查詢。

如果你使用向量數(shù)據(jù)庫，可以對用戶輸入進(jìn)行語義搜索。否則，你可以使用 LLM 生成 SQL 或 Cipher 查詢。

必要時(shí)你還可以調(diào)用 HTTP 端點(diǎn)。

但直接查詢方法很少能產(chǎn)生可靠的上下文。

你可以以更高級的方式查詢數(shù)據(jù)源。例如，你可以嘗試查詢路由技術(shù)來決定從哪個(gè)數(shù)據(jù)源獲取數(shù)據(jù)。具有良好推理能力的 LLM 可以用于此目的。你還可以在小型模型上進(jìn)行指令微調(diào)，以節(jié)省成本并降低延遲。

另一種技術(shù)是鏈?zhǔn)秸埱?。對于初始查詢，我們可以從?shù)據(jù)源獲取信息。然后，根據(jù)獲取的文檔，我們可以獲取后續(xù)文檔。

分塊是 RAG 中最具挑戰(zhàn)性且至關(guān)重要的部分

當(dāng)上下文包含無關(guān)信息時(shí)，LLM 容易出現(xiàn)幻覺。

防止 RAG 幻覺的最佳方法是分塊。

現(xiàn)代 LLM 可能支持更長的上下文長度。例如，Gemini 2.5 Pro 支持高達(dá) 200 萬個(gè) token，足以容納兩到三本大學(xué)級別的物理教科書。

但對于基礎(chǔ)力學(xué)問題，你很少需要量子物理的上下文信息。

如果你將教科書分解成較小的部分，可能每個(gè)部分只討論一個(gè)主題，你就能只獲取回答問題所需的相關(guān)信息。

這里的挑戰(zhàn)在于分塊技術(shù)有很多種。每種技術(shù)都有其優(yōu)缺點(diǎn)。適合你領(lǐng)域的技術(shù)可能不適用于其他領(lǐng)域。

遞歸字符分塊可能是最簡單的，也是我的默認(rèn)選擇。然而，它假設(shè)文本中每個(gè)主題的討論長度相等，這很少是事實(shí)。盡管如此，這是最好的起點(diǎn)。

你甚至可以嘗試主題聚類和代理分塊。

嘗試重新排序

最后但同樣重要的是，重新排序。

事實(shí)證明，相關(guān)分塊的位置是高質(zhì)量 LLM 響應(yīng)的關(guān)鍵因素。

然而，常規(guī)向量搜索甚至數(shù)據(jù)庫查詢的排序方式并不智能。LLM 可以做到。

因此，我們使用專門的大型語言模型 (LLM) 作為重新排序器，重新排列獲取的上下文并進(jìn)一步過濾，找出最相關(guān)的分塊。

這種二級重新排序在某些應(yīng)用中有幫助，但在其他應(yīng)用中未必。但你可以使用一些技術(shù)來改進(jìn)重新排序的結(jié)果。

其中之一是獲取大量初始結(jié)果。寬松定義初始標(biāo)準(zhǔn)會(huì)拉取一些無關(guān)上下文，但會(huì)增加獲取正確內(nèi)容的概率。

重新排序器現(xiàn)在可以處理這個(gè)大型集合并過濾出更相關(guān)的部分。

最終思考

構(gòu)建 RAG 已成為任何 LLM 應(yīng)用的必備。即使是 200 萬 token 的上下文窗口也無法挑戰(zhàn)它。

我們開發(fā)的原型通常未能部署。部分原因歸于業(yè)務(wù)決策，但也有可以解決的技術(shù)原因。

本文是我在構(gòu)建 RAG 方面的經(jīng)驗(yàn)總結(jié)。

雖然這不是一個(gè)全面的列表，但考慮這五個(gè)方面將確保你開發(fā)出更持久的 RAG。

本文轉(zhuǎn)載自???AI大模型觀察站???，作者：AI大模型觀察站