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