1. 為什么說RAG是現(xiàn)階段大模型開發(fā)的真正重頭戲這兩年大模型開發(fā)領(lǐng)域有個很有意思的現(xiàn)象大量新手把重心全押在Prompt上。聊天界面里做各種技巧實驗研究角色設(shè)定、思維鏈、各種花式模板確實能出一些效果。但真到了要做一個能落地、能上生產(chǎn)環(huán)境的系統(tǒng)時你會發(fā)現(xiàn)光靠Prompt撐不住。這時候RAG的價值就非常突出了。RAG全稱是檢索增強生成簡單說是把外部知識庫檢索能力接入到大模型生成流程中讓大模型在回答用戶問題時先從一個能控制的私有知識庫里找到相關(guān)的參考內(nèi)容再基于這些內(nèi)容組織輸出。它解決的核心痛點非常直接大模型不懂你手上的數(shù)據(jù)。無論你用的是通用大模型還是行業(yè)大模型模型內(nèi)部的參數(shù)知識始終是有限的并且訓(xùn)練數(shù)據(jù)有截止時間。想要問它公司內(nèi)部的規(guī)章制度、某款產(chǎn)品的最新參數(shù)、某個項目的過往復(fù)盤它往往是編的編得還很自信。這就是大模型最典型的幻覺問題。RAG做的事情就是讓模型帶著小抄答題。你提前把文檔切好、向量化、存起來。用戶問問題時系統(tǒng)先把問題變成同樣的向量在庫里做相似度檢索找出最相關(guān)的若干個片段把它和原始問題一起拼進提示詞交給大模型生成回答。大模型不需要記得這些內(nèi)容只需要在有限上下文里讀到這些片段然后組織語言。這等于把知識來源從模型內(nèi)部轉(zhuǎn)移到了你可以管理的索引里。相比Prompt工程RAG有四個不可替代的優(yōu)勢。第一是知識實時性你只要重新跑一遍文檔入庫流程模型就知道最新信息而不用重新訓(xùn)練。第二是數(shù)據(jù)私有化企業(yè)敏感數(shù)據(jù)根本不需要進模型訓(xùn)練集只在自己系統(tǒng)內(nèi)部的向量庫里流動。第三是可追溯性回答里引用了具體知識片段你可以給用戶展示引用來源這是企業(yè)級應(yīng)用非常硬性的需求。第四是幻覺抑制模型有了給定素材它的任務(wù)從從記憶里挖答案變成了從素材里總結(jié)答案發(fā)散空間大幅縮小。當(dāng)然這不意味著Prompt可以完全丟開。實際上RAG系統(tǒng)的最后一步——生成階段的提示詞設(shè)計——本身就是Prompt工程的分支。專業(yè)開發(fā)者的做法是用RAG解決知識來源問題用Prompt解決表達方式和推理約束問題。兩者是配合關(guān)系不是替代關(guān)系。但從學(xué)習(xí)優(yōu)先級來說如果一個完全沒做過大模型應(yīng)用的人問我先學(xué)什么我的建議很明確先搞懂RAG主鏈路因為這是一條能跑通的完整技術(shù)棧而Prompt只是這條鏈路上的一小段。標(biāo)題說別再只學(xué)Prompt重點不在于否定Prompt而在于提醒后來者大模型應(yīng)用開發(fā)的核心難點已經(jīng)從怎么問問題轉(zhuǎn)移到了怎么把系統(tǒng)架構(gòu)和外部知識管理起來。這篇文章后面的內(nèi)容會從RAG的全流程設(shè)計開始逐步拆到文檔切分、向量化、檢索、生成等每個環(huán)節(jié)最后給出可直接運行的代碼實現(xiàn)以及我實際踩坑后總結(jié)的問題排查經(jīng)驗?zāi)康氖亲屚耆珱]接觸過的讀者也能把一個基礎(chǔ)RAG系統(tǒng)跑起來。2. 一次搞懂RAG的核心鏈路與每個環(huán)節(jié)的設(shè)計邏輯RAG聽起來高大上拆開就是一條三段的流水線索引Indexing、檢索Retrieval、生成Generation。這三段各自都有能寫幾千字的細節(jié)新手最容易犯的錯誤就是只盯著其中一段猛鉆比如拼命調(diào)提示詞或者拼命換向量模型卻忽略了整條鏈路的配合。下面我把每一段的關(guān)鍵設(shè)計邏輯拆開講清楚。2.1 離線索引一切效果的地基索引階段做的是把原始文檔變成可供檢索的結(jié)構(gòu)化數(shù)據(jù)全流程是文檔加載、文本清洗、分段切塊、向量化、寫入向量庫。文檔加載這一步看似簡單但坑不少。PDF可能是掃描件需要跑OCRWord里可能嵌了圖片和表格表格轉(zhuǎn)成純文本后語義結(jié)構(gòu)會產(chǎn)生一定損壞網(wǎng)頁內(nèi)容有導(dǎo)航、頁腳等噪聲需要正文抽取。這些預(yù)處理粗糙后面整個系統(tǒng)都會受影響。有一個很樸素的檢驗方式你可以隨機抽一批處理后的純文本片段用肉眼掃一遍。如果加載清洗后文本里有大量亂碼、錯位、無意義的重復(fù)內(nèi)容那不用繼續(xù)了先把這一步做好比什么都重要。文本切塊是整條鏈路里最能直接影響檢索效果的操作而且沒有標(biāo)準(zhǔn)答案。切太碎一個語義單元被拆散檢索到的是殘缺的觀點切太大一個塊里混入太多主題向量表示被稀釋檢索精確度下降而且占用的上下文窗口token也更多。我常用的策略是先按結(jié)構(gòu)切再按大小補。什么意思如果你處理的是產(chǎn)品手冊它天然有章節(jié)標(biāo)題你可以先用標(biāo)題切出一個大塊如果大塊超過預(yù)設(shè)的token上限再往細分。沒有明確結(jié)構(gòu)的就按固定大小切一般起步用chunk_size500、overlap50這樣的參數(shù)這個組合對大多數(shù)技術(shù)文檔效果都還不錯。overlap的作用非常關(guān)鍵它讓相鄰塊之間有一定重復(fù)內(nèi)容避免一句話在邊界處被截斷導(dǎo)致語義斷開。向量化是把文本變成數(shù)字序列。選擇文本嵌入模型時需要綜合考慮生成質(zhì)量、維度大小、中文支持能力。通用場景下市面上主流的開源嵌入模型對中文的支持都做得不錯維度通常在768到1024之間。這里有一個常見的誤區(qū)維度越大不代表效果越好高維度帶來了更高的存儲和計算成本而實際檢索效果提升可能非常有限。我通常先拿自己的領(lǐng)域數(shù)據(jù)用幾種候選模型分別向量化一批文檔然后人工設(shè)計二三十個標(biāo)準(zhǔn)問題跑一遍完整鏈路看哪些問題檢索到的結(jié)果真正相關(guān)。模型對比評測沒有比這更靠譜的方法。向量庫選型上數(shù)據(jù)量小比如幾千條可以用輕量級庫在本地跑部署簡單文件即庫適合學(xué)習(xí)和原型驗證。數(shù)據(jù)量上了百萬級別需要分布式部署和高并發(fā)支持就要用專用向量數(shù)據(jù)庫服務(wù)。選型的核心指標(biāo)就幾個規(guī)模上限、并發(fā)能力、召回質(zhì)量、運維成本。不要盲目追求分布式一個小項目配一套復(fù)雜集群光是運維成本就讓項目變重。2.2 在線檢索與生成決定用戶體驗的雙引擎用戶發(fā)起一個查詢后系統(tǒng)的工作首先是查數(shù)據(jù)庫找到最相關(guān)的文檔片段。這里的關(guān)鍵是找出一個平衡點如果你只取1個片段模型可利用信息太少回答容易單薄且可能遺漏關(guān)鍵信息如果你取10個片段上下文塞滿了內(nèi)容生成時模型會被無關(guān)信息干擾而且token成本顯著上升。可以這樣判斷先看你的主文檔切塊大小大約在500字左右時取4到6個塊是一個合理的初始區(qū)間再觀察生成質(zhì)量如果回答明顯遺漏了重要信息往上加如果回答出現(xiàn)了前后矛盾或偏離重點往下減。檢索到的原始片段理論上不能直接塞給模型因為它們可能內(nèi)容重復(fù)、順序混亂包含一些不連貫的碎片。這里可以做兩件事一是相關(guān)性排序重新排列片段優(yōu)先級讓最相關(guān)內(nèi)容排在前面二是信息壓縮把多個片段中的冗余信息整理去重保留核心內(nèi)容。經(jīng)過整理后的上下文能顯著提升回答質(zhì)量并控制token消耗。同時在把內(nèi)容交給模型之前我會給每個片段標(biāo)記來源這樣在系統(tǒng)輸出時可以同時返回參考了哪幾個文檔的哪一段用戶能自己核對對提升信任感非常有幫助。最后一步的生成我不建議搞復(fù)雜。提示詞保持簡潔穩(wěn)定核心就三部分角色與任務(wù)的描述限定模型只依據(jù)給定片段來作答給定的參考內(nèi)容無法作答時明確說不知道而不是編造。然后把用戶問題拼接在最前面。還要注意一個交互設(shè)計細節(jié)給用戶展示正在檢索知識庫……這類中間過程反饋而不是讓用戶對著一個轉(zhuǎn)圈等待的按鈕發(fā)呆。系統(tǒng)的工程體驗也是體驗的一部分。2.3 增強優(yōu)化從能用到好用到這里一個最小可用的RAG系統(tǒng)已經(jīng)能跑起來了但真實場景里你需要做得更細。檢索排序的后處理是非常關(guān)鍵的一環(huán)。你可以對初步檢索到的候選片段再做一次重排序Rerank讓它與用戶問題的語義匹配度精準(zhǔn)對齊。這是投入少、收益大的一個環(huán)節(jié)。除了語義向量檢索我強烈建議加入關(guān)鍵詞檢索分支兩者各取所長的融合檢索策略。向量檢索擅長找語義相近但表述不同的內(nèi)容關(guān)鍵詞檢索精準(zhǔn)匹配術(shù)語、編號、型號這類信息。比如用戶問RAG-102 型號的保修期限如果只靠向量檢索很容易匹配到語義相似的RAG系列產(chǎn)品的保修而關(guān)鍵詞檢索能直接鎖定RAG-102出現(xiàn)過的片段。把兩種結(jié)果按某種策略合并后統(tǒng)一重排是我在多個項目里驗證過的穩(wěn)健組合。高并發(fā)場景下你需要給向量查詢加緩存層。相同和相似問題的查詢結(jié)果直接命中緩存避免重復(fù)走完整條鏈路。多輪對話場景下你可以把歷史對話信息做摘要或選擇近期關(guān)鍵幾輪一起參與檢索問題改寫或指代消解都是這一步的常見操作。這幾項優(yōu)化做完整個系統(tǒng)的體驗會有質(zhì)的區(qū)別。3. 手把手搭建一個最小可用的RAG系統(tǒng)現(xiàn)在進入最實用的部分從零搭一個能跑通的RAG系統(tǒng)。我選了一條適合小白的路線Python 3.10以上版本用開源框架來組裝檢索鏈路向量庫先用輕量級方案跑通最后配合商業(yè)大模型API做生成。整體代碼量不大但每一步都仔細解釋為什么這么寫。3.1 技術(shù)選型為什么選這套方案技術(shù)選型上我堅持三個原則能用成熟的不用自己造的、易于替換的優(yōu)先、上手成本不能高。文檔處理與切分部分用開源框架的文檔加載器和文本分割器就夠了。它自帶大量常見的文檔加載器兼容PDF、Word、Markdown等格式切分器支持按結(jié)構(gòu)、按大小遞歸切分overlap參數(shù)直接內(nèi)置省去自己寫文本邊界處理的時間。向量庫方面前面說了先用輕量級方案它有最小可用的相似度檢索能力數(shù)據(jù)存在本地文件里重啟不丟足夠支撐學(xué)習(xí)階段和中小規(guī)模項目。等架構(gòu)穩(wěn)定了再平滑替換成專用向量數(shù)據(jù)庫代碼改動非常有限。嵌入模型用開源模型本地跑百度或者各種嵌入排行榜上找中文支持好的都行。注意在代碼里最好把嵌入模型名放到配置文件里換模型時不用改邏輯代碼。生成端接商業(yè)大模型API但這個步驟我放在最后前面檢索鏈路完全可以用本地邏輯驗證避免一開始就把API費用燒在不成熟的環(huán)節(jié)上。3.2 離線索引的代碼實現(xiàn)第一步加載文檔并切塊。下面這個例子以Markdown文檔為例展示從文件讀入到切塊的完整過程from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter loader TextLoader(product_manual.md, encodingutf-8) documents loader.load() text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , , , ], ) chunks text_splitter.split_documents(documents) print(f共切分為 {len(chunks)} 個片段)這段代碼里有幾個地方特別說一下。RecursiveCharacterTextSplitter切分的邏輯是先嘗試用第一個分隔符切如果切出來的塊還是太大就換下一個更細的分隔符繼續(xù)切。我設(shè)置的separators順序很關(guān)鍵中文場景要把句末標(biāo)點和逗號放在空格、空字符串前面否則它會優(yōu)先按英文空格切中文文本被攔腰切斷的概率大增。chunk_size和chunk_overlap的單位是字符數(shù)而不僅是token數(shù)500字符的中文大約對應(yīng)200到300個token配合主流模型的上下文窗口綽綽有余。如果你處理的是代碼文件分隔符應(yīng)該換成代碼結(jié)構(gòu)相關(guān)關(guān)鍵詞這就屬于需要根據(jù)文檔類型調(diào)整的部分。第二步向量化并寫入向量庫。用下面的代碼把切好的塊轉(zhuǎn)成向量并入庫from langchain_huggingface import HuggingFaceEmbeddings from langchain_community.vectorstores import FAISS embedding_model HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vector_store FAISS.from_documents(chunks, embedding_model) vector_store.save_local(faiss_index)HuggingFaceEmbeddings會把指定模型下載到本地并用它編碼文本。這里我用了bge-small-zh-v1.5原因是它體量小單條文本編碼速度快中文效果在同體積模型里表現(xiàn)出色非常適合CPU環(huán)境。理解它的原理會對你以后選模型有幫助嵌入模型本質(zhì)是通過深度神經(jīng)網(wǎng)絡(luò)把文本映射到一個向量空間在這個空間里語義接近的文本向量距離也接近。檢索時做的就是距離計算。FAISS庫本身是Meta開源的相似度檢索工具底層對向量距離計算做了大量指令集優(yōu)化本機幾萬條數(shù)據(jù)量下查詢延遲可以做到幾十毫秒級別不需要額外起服務(wù)。入庫前有一個值得注意的優(yōu)化如果你預(yù)計知識庫會反復(fù)更新不要每次都重建整個索引而是分批增量寫入。FAISS支持add_documents方法但頻繁修改后索引會產(chǎn)生碎片所以我的習(xí)慣是小項目全量重建幾十秒的成本完全可以接受大項目定期全量重建增量寫入只用于少量新文檔。3.3 在線檢索與生成的代碼實現(xiàn)檢索端代碼核心思路問題向量化然后與庫對比相似度取TopK結(jié)果。FAISS庫加載后可以直接查詢vector_store FAISS.load_local( faiss_index, embedding_model, allow_dangerous_deserializationTrue, ) query 這款設(shè)備支持快充嗎 retrieved_docs vector_store.similarity_search_with_score(query, k5) for i, (doc, score) in enumerate(retrieved_docs): print(f[{i}] 相關(guān)度 {score:.4f} :: {doc.page_content[:50]}...)注意分數(shù)越低代表向量距離越近即語義越相關(guān)這與直覺相反我最初排查時也在這里困惑過一陣。代碼里allow_dangerous_deserializationTrue是FAISS本地加載的一個安全性參數(shù)你只應(yīng)該加載自己信任的索引文件千萬不要加載來路不明的文件。取回片段后在發(fā)給生成模型前做整理構(gòu)造提示詞。下面是我在項目里總結(jié)出的一套比較穩(wěn)的提示詞結(jié)構(gòu)from openai import OpenAI client OpenAI(base_urlhttps://api.example.com/v1, api_key你的密鑰) context \n\n.join( f[來源片段{i1}]\n{doc.page_content} for i, (doc, _) in enumerate(retrieved_docs) ) prompt f你是一個知識問答助手。請嚴格依據(jù)下面給出的資料片段回答用戶問題。 如果資料中沒有足夠的信息請直接回答“我無法從現(xiàn)有資料中找到答案”不要編造。 回答時請采用簡潔的段落結(jié)構(gòu)并在句末用[來源片段i]標(biāo)注引用。 資料片段 {context} 用戶問題{query} response client.chat.completions.create( model你的模型名稱, messages[ {role: system, content: 你是嚴謹?shù)募夹g(shù)問答助手。}, {role: user, content: prompt}, ], temperature0.2, ) print(response.choices[0].message.content)temperature0.2是為了讓模型在回答時盡量克制、貼近資料內(nèi)容減少自由發(fā)揮。如果你希望回答有創(chuàng)造性那是另一類場景RAG場景下答案準(zhǔn)確性永遠優(yōu)先。如果你自己搭建的是本地模型這套API的調(diào)用方式在兼容接口的本地推理服務(wù)下同樣適用只是把base_url換成對應(yīng)的本地端口。到這里一個最小可用的RAG系統(tǒng)已經(jīng)完整跑通。整個流程你已經(jīng)能感知到不是輸入問題直接給答案而是經(jīng)過了一次數(shù)據(jù)讀取、切塊、編碼、檢索、拼接、生成六個環(huán)節(jié)每個環(huán)節(jié)你都可以插手優(yōu)化這就是RAG系統(tǒng)工程的本質(zhì)。4. 把系統(tǒng)做扎實升級檢索策略與工程優(yōu)化能跑通只是一個起點真實使用環(huán)境里的考驗接踵而至。下面這些是我在實際項目中反復(fù)權(quán)衡后沉淀出來的升級路徑按性價比從高到低排列。4.1 混合檢索與重排序排名靠前不等于答案正確只用向量相似度檢索的RAG系統(tǒng)早期表現(xiàn)往往過得去但用戶問題角度一變就露餡。最常見的是兩類問題。第一術(shù)語和編號精確匹配場景下向量檢索不一定把包含精確關(guān)鍵詞的文本排在前面因為向量編碼更關(guān)注整體語義而不是某個詞的字面命中。第二檢索結(jié)果Top5里真正能回答問題的可能只有一個排在第四第五大模型生成時被前面幾個不相關(guān)內(nèi)容帶偏給出一個看似流暢但明顯從錯誤前提推理的答案?；旌蠙z索策略就是在向量檢索之外加一路關(guān)鍵詞檢索。傳統(tǒng)方案上你可以用開源全文檢索引擎構(gòu)建倒排索引按BM25算法打分排名。兩路結(jié)果做加權(quán)合并這個加權(quán)系數(shù)可以通過小批量標(biāo)注數(shù)據(jù)來調(diào)節(jié)沒有標(biāo)注數(shù)據(jù)時可以先用經(jīng)驗值語義優(yōu)先場景向量權(quán)重0.7、關(guān)鍵詞權(quán)重0.3精確查找場景反過來。合并后的候選集再交給重排序模型打分。重排序模型和嵌入模型不同。嵌入模型需要把全部文本編碼成向量然后比較向量距離重排序模型則是把查詢和文檔片段成對輸入直接讓一個深度模型判斷這段內(nèi)容和這個問題的相關(guān)程度精度明顯更高。常見做法是先用輕量級檢索從全庫里快速篩出前50個候選片段再用重排序模型精排取前5。這樣既控制了時間開銷又拿到了高精度排序。我在項目中加入重排序后評測指標(biāo)上的提升非常明顯尤其在文檔庫規(guī)模上去以后屬于投入產(chǎn)出比極高的優(yōu)化。4.2 多輪對話下的查詢改寫與知識緩存用戶真實使用系統(tǒng)時很少一上來就把完整需求說清楚。比如第一輪問我們公司有什么遠程辦公制度第二輪問那申請流程呢這個那指的是遠程辦公的申請流程。如果直接拿申請流程去檢索系統(tǒng)很可能檢索到別的東西。這里的解法叫查詢改寫借助大模型把多輪對話的上下文合成為一個獨立的完整查詢再去做檢索。合成之后變成我們公司遠程辦公制度的申請流程是什么效果天差地別。def rewrite_query(history, current_query): history_text \n.join( f用戶{turn[user]}\n助手{turn[assistant]} for turn in history ) prompt f根據(jù)對話歷史把用戶最新問題改寫成一個可獨立檢索的完整問題。 只輸出改寫后的問題不要解釋原因。 對話歷史 {history_text} 最新問題{current_query}這段邏輯可以放到生成階段之前每次處理請求時先判斷是否需要改寫。判斷依據(jù)很簡單問題里出現(xiàn)代詞、省略、指代等表述就選擇改寫。 緩存是另一個容易被忽略的工程優(yōu)化點。把已經(jīng)回答過的問題和對應(yīng)的檢索結(jié)果、生成結(jié)果存起來。下一次遇到相同問題直接返回緩存結(jié)果。更進一步可以做語義緩存把新問題的向量和緩存里問題的向量做相似度比對距離足夠近就直接復(fù)用。實際業(yè)務(wù)中熱門問題重復(fù)率極高緩存能省掉90%的重復(fù)計算對成本控制和響應(yīng)速度都是關(guān)鍵指標(biāo)。 ### 4.3 保證知識新鮮度數(shù)據(jù)更新的工程化方案 RAG系統(tǒng)最大的賣點之一就是知識可更新。但這個更新如果沒有工程化管理會變成新的麻煩。我在項目里遇到過這種情況第二天文檔內(nèi)容改了但向量庫里還留著昨天的舊片段用戶問新問題時舊內(nèi)容和新增內(nèi)容同時被檢索到生成結(jié)果就開始精分。 一套簡單可靠的做法是給每個文檔片段記錄元數(shù)據(jù)包括文檔ID、更新時間、版本號。每次更新流程分三步先把該文檔ID下所有舊向量從庫里刪除然后重新加載、切分、向量化新版本最后寫入向量庫。如果你用的開源向量庫本身沒有原生元數(shù)據(jù)過濾能力你就需要自己維護一份文檔ID到向量索引編號的映射關(guān)系。更簡單粗暴但也很實用的方式是全量重建索引對于大多數(shù)中小規(guī)模項目幾分鐘的重新索引完全可以接受。 還有一個實際項目里經(jīng)常踩的坑當(dāng)你同時更新多個關(guān)聯(lián)文檔時千萬不要拆分多次寫入應(yīng)該在所有文檔處理完成后再一次性寫入向量庫否則會出現(xiàn)短暫的新舊知識并存的中間狀態(tài)。 ## 5. 常見問題排查實錄與避坑技巧 做RAG系統(tǒng)90%的時間都花在排查問題上。我把最常遇到的問題和排查思路整理成速查表這些經(jīng)驗是我在一個又一個項目中驗證過的高頻問題能幫你少走很多彎路。 | 現(xiàn)象 | 常見原因 | 排查方向與解決建議 | | --- | --- | --- | | 回答里出現(xiàn)明顯錯誤信息 | 檢索到不相關(guān)內(nèi)容或切塊把關(guān)鍵信息截斷了 | 打印出實際檢索到的片段人工判斷相關(guān)性調(diào)整切塊大小與overlap | | 回答總是無法在資料中找到答案 | 檢索閾值過高或切塊過碎導(dǎo)致語義不完整 | 降低相似度閾值檢查切塊后的純文本是否語義完整 | | 新文檔更新后回答還是舊內(nèi)容 | 向量庫里舊向量未清除或緩存未失效 | 核查更新邏輯確認元數(shù)據(jù)過濾是否生效清緩存重試 | | 檢索結(jié)果Top1相關(guān)度很高但生成質(zhì)量差 | 上下文里缺少支撐性細節(jié)Top1只覆蓋了部分信息 | 增加TopK數(shù)量加入重排序環(huán)節(jié) | | 不同文檔對同一問題給出沖突答案 | 文檔本身存在矛盾或檢索時帶入太多無關(guān)片段 | 在文檔入庫前建立矛盾檢測機制限制參考片段數(shù)量 | | 響應(yīng)速度越來越慢 | 向量庫索引碎片化嚴重或未加緩存 | 定期重建索引確保緩存命中率 | | 中文問題檢索效果明顯差于英文 | 切分符沒有適配中文標(biāo)點 | 修改切分器的分隔符順序把中文句末標(biāo)點前置 | | API調(diào)用費用過高 | 每輪請求都塞了大量參考片段重復(fù)問題沒有命中緩存 | 控制檢索片段數(shù)量引入語義緩存 | 排查問題有一個不變的原則先弄清是檢索環(huán)節(jié)的問題還是生成環(huán)節(jié)的問題。做法是手動打印檢索結(jié)果不看生成結(jié)果直接檢查TopK片段是否真的相關(guān)。如果檢索結(jié)果沒問題問題多半出在生成的提示詞上如果檢索結(jié)果本身就不相關(guān)那你再怎么調(diào)提示詞都沒有意義。 實際開發(fā)中還有一類問題很容易被新手忽略文檔重復(fù)與文本碎片。如果你的知識庫里存在同一知識點的多種不同表述檢索時會同時命中多個相似片段白白擠占上下文空間。解決辦法是在入庫前做一輪相似文檔或段落級別的去重用嵌入模型向量化后互相算距離距離過近的保留一份即可。 另外在小白起步階段不要一上來就試圖做一個覆蓋所有場景的完美系統(tǒng)。我個人的建議是先跑通那個最小的閉環(huán)解決你和你的數(shù)據(jù)之間的對不上話問題然后在真實使用中發(fā)現(xiàn)最難受的痛點一次只優(yōu)化一個環(huán)節(jié)。RAG的每個模塊都可以深入研究很久但它們是串聯(lián)關(guān)系單一環(huán)節(jié)的極端優(yōu)化往往抵不過整條鏈路的均衡提升。 最后分享一個我常用來給系統(tǒng)做體檢的辦法準(zhǔn)備20到30個覆蓋不同維度的標(biāo)準(zhǔn)問題寫進一個腳本里批量跑完人工逐條給檢索質(zhì)量和生成質(zhì)量打分。每次改動完任何一個環(huán)節(jié)重跑一遍這組問題對比前后的分數(shù)差異。這樣你就不會憑感覺做優(yōu)化每個決策都有數(shù)據(jù)支撐。這個方法看著笨但確實是最穩(wěn)定、最有效的迭代方式我在多個RAG項目里都靠它穩(wěn)住質(zhì)量底線。