簡介面向AI工程師、后端開發(fā)及技術(shù)決策者的《RAG實(shí)踐手冊(cè)——構(gòu)建知識(shí)庫和問答系統(tǒng)的實(shí)戰(zhàn)指南》PDF電子書核心目標(biāo)是幫助讀者掌握檢索增強(qiáng)生成RAG的工程化落地方法。手冊(cè)以Cloudflare Vectorize作為主要技術(shù)棧系統(tǒng)講解RAG原理、參考架構(gòu)、流水線總覽、技術(shù)選型、環(huán)境準(zhǔn)備等內(nèi)容并基于實(shí)際項(xiàng)目拆解API申請(qǐng)、向量索引創(chuàng)建、元數(shù)據(jù)索引配置、項(xiàng)目初始化等關(guān)鍵操作步驟。對(duì)希望快速搭建企業(yè)級(jí)知識(shí)庫問答系統(tǒng)或升級(jí)現(xiàn)有檢索方案的開發(fā)者具有較強(qiáng)的對(duì)照參考價(jià)值。資源以單個(gè)PDF文件提供整體約4.11MB內(nèi)容組織清晰章節(jié)由基本原理延伸至架構(gòu)設(shè)計(jì)與部署準(zhǔn)備層級(jí)分明。已有466人學(xué)習(xí)下載讀者可跟隨手冊(cè)逐步完成從向量庫構(gòu)建到問答系統(tǒng)部署的完整實(shí)戰(zhàn)既能鞏固RAG理論體系也能直接遷移到自己的項(xiàng)目中應(yīng)用。1. RAG實(shí)踐手冊(cè)先搞懂你要解決的是“幻覺”還是“找不到”做知識(shí)庫問答系統(tǒng)最尷尬的場面不是模型答錯(cuò)而是它用一本正經(jīng)的語氣編出一個(gè)不存在的版本號(hào)或者把兩個(gè)客戶的政策條款串在一起。單純把文檔丟給大模型微調(diào)成本高、更新慢、還容易把原有能力帶偏RAG檢索增強(qiáng)生成的解法是讓模型先查再答——把知識(shí)庫當(dāng)成外掛記憶每次提問先檢索相關(guān)片段再讓模型基于這些片段生成答案。這套思路聽起來不復(fù)雜但真正落地過的人都知道瓶頸不在“連起來”而在檢索質(zhì)量和工程細(xì)節(jié)。這本實(shí)踐筆記面向的是準(zhǔn)備把RAG放進(jìn)生產(chǎn)環(huán)境的開發(fā)者你已經(jīng)知道RAG是什么現(xiàn)在想知道框架怎么選、參數(shù)怎么調(diào)、為什么別人跑通了你卻翻車。我從選型、流水線、調(diào)參到避坑把做知識(shí)庫問答系統(tǒng)最常踩的坑和可復(fù)現(xiàn)的做法一次講完。2. 選型先行RAG框架、向量庫和知識(shí)庫形態(tài)怎么搭配才不會(huì)返工RAG項(xiàng)目第一次返工九成發(fā)生在選型階段。很多團(tuán)隊(duì)上來就選一個(gè)全家桶框架結(jié)果內(nèi)部黑匣子太多出了問題不知道查哪一層另一些團(tuán)隊(duì)什么都自己寫光文檔解析就耗掉兩個(gè)星期。這里沒有銀彈但有一個(gè)務(wù)實(shí)的決策順序先定知識(shí)庫形態(tài)再選框架最后選向量庫。2.1 從Dify到開源組件按團(tuán)隊(duì)水平選RAG框架知識(shí)庫問答系統(tǒng)的框架選擇本質(zhì)是在“開箱即用”和“可控可改”之間做權(quán)衡。如果你所在的團(tuán)隊(duì)以業(yè)務(wù)人員為主后端開發(fā)資源有限D(zhuǎn)ify這類帶可視化流水線的開源平臺(tái)是首選。Dify把文檔上傳、分塊、embedding、檢索、對(duì)話編排串成了一條可視化的知識(shí)庫流水線你可以在界面上直接調(diào)試檢索參數(shù)不用寫一行代碼就能看到top_k、相似度閾值對(duì)答案的影響。它的缺點(diǎn)是流水線是半開放的想插入自定義的rerank邏輯或元數(shù)據(jù)過濾需要改源碼或依賴插件調(diào)試起來比較繞。如果你的團(tuán)隊(duì)有算法工程師或者你本身就想把RAG吃透我更推薦用組件式方案LangChain/LlamaIndex做編排向量庫自選Rerank模型單獨(dú)掛。這樣做的好處是每一層都透明出了問題能準(zhǔn)確判斷是分塊的問題、embedding的問題還是生成的問題。我一般會(huì)用LlamaIndex而不是LangChain來做知識(shí)庫類項(xiàng)目因?yàn)長lamaIndex對(duì)文檔解析、索引結(jié)構(gòu)和檢索評(píng)估的支持更原生跑通最小驗(yàn)證的時(shí)間更短。還有一條容易被忽略的選型標(biāo)準(zhǔn)看你的知識(shí)庫是不是要頻繁更新。Dify這類平臺(tái)在文檔變更后要觸發(fā)生成流水線重建索引如果你每天有幾百篇文檔增量進(jìn)來要考慮它是否支持增量索引和斷點(diǎn)續(xù)建組件式方案雖然要自己寫更新邏輯但至少你完全掌控索引的生命周期。另外如果團(tuán)隊(duì)里有人擅長前端也可以考慮開源的MaxKB、RAGFlow這類項(xiàng)目它們的文檔問答體驗(yàn)做得更貼近產(chǎn)品但定制深度不如自己搭。提示無論是全家桶還是組件方案第一個(gè)星期不要碰代碼先拿10篇真實(shí)文檔跑通端到端流程確認(rèn)“解析—索引—檢索—生成”每個(gè)環(huán)節(jié)的輸出你都能看到?？床灰娭虚g結(jié)果的框架后期排障會(huì)非常痛苦。2.2 向量庫選型Milvus、pgvector、Elasticsearch怎么選向量庫是整個(gè)RAG系統(tǒng)的存儲(chǔ)核心選型時(shí)先回答三個(gè)問題數(shù)據(jù)量級(jí)多大、是否需要混合檢索、團(tuán)隊(duì)誰會(huì)運(yùn)維。答案會(huì)直接決定你該用專用向量庫還是復(fù)用現(xiàn)有數(shù)據(jù)庫。如果知識(shí)庫在百萬級(jí)向量以內(nèi)團(tuán)隊(duì)已經(jīng)有PostgreSQLpgvector是最務(wù)實(shí)的起點(diǎn)。它不需要引入新組件SQL就能做相似度搜索還能把向量字段和業(yè)務(wù)字段比如文檔來源、部門、時(shí)間放在同一個(gè)SQL里過濾這在做權(quán)限隔離時(shí)特別方便。我個(gè)人在項(xiàng)目早期階段幾乎無腦選pgvector因?yàn)樗恼{(diào)試成本極低出了問題可以直接查數(shù)據(jù)表。要注意的是pgvector的索引參數(shù)——數(shù)據(jù)量超過十萬條后一定要建IVFFlat或HNSW索引否則每次檢索都是全表掃描延遲會(huì)隨數(shù)據(jù)量線性惡化。如果數(shù)據(jù)量從百萬級(jí)向量起步或者檢索并發(fā)很高M(jìn)ilvus是更專業(yè)的選項(xiàng)。它支持多種索引類型、分區(qū)和標(biāo)量過濾還有獨(dú)立的運(yùn)維控制面。但代價(jià)是引入了額外的分布式組件你需要有人懂它的部署和調(diào)優(yōu)否則很容易出現(xiàn)“檢索變慢但不知道為什么”的窘境。Elasticsearch則適合已經(jīng)有ES運(yùn)維經(jīng)驗(yàn)、且文檔本身有強(qiáng)烈關(guān)鍵詞檢索訴求的團(tuán)隊(duì)——ES的全文檢索能力是向量庫的補(bǔ)充它天然適合做關(guān)鍵詞匹配和詞頻加權(quán)但在向量檢索的性能和精度上不如專用向量庫。這里給一個(gè)具體的決策參考知識(shí)庫文檔量小于5萬篇、團(tuán)隊(duì)沒專人運(yùn)維中間件pgvector文檔量大但團(tuán)隊(duì)能投入運(yùn)維Milvus檢索場景要求關(guān)鍵詞精確命中優(yōu)先比如法律條文、合同編號(hào)ES如果你的場景是“先關(guān)鍵詞過濾、再向量召回、最后重排”可以直接在pgvector或Milvus上用Filter Vector Search組合不一定要引入獨(dú)立ES。2.3 RAG知識(shí)庫和結(jié)構(gòu)化知識(shí)庫的邊界什么時(shí)候該上Ontology很多團(tuán)隊(duì)在選型階段糾結(jié)的一個(gè)問題是到底用RAG知識(shí)庫還是先做結(jié)構(gòu)化知識(shí)庫這個(gè)問題問得越晚返工成本越高。我的判斷依據(jù)很簡單如果問答的答案是“查出來”的用結(jié)構(gòu)化知識(shí)庫如果答案是“總結(jié)出來”的用RAG。典型適合RAG的知識(shí)庫是產(chǎn)品手冊(cè)、政策文件、論文、內(nèi)部制度——內(nèi)容以自然語言為主答案需要跨段落歸納。典型適合結(jié)構(gòu)化知識(shí)庫的是員工信息、庫存數(shù)量、價(jià)格表、故障代碼——每條數(shù)據(jù)有明確字段答案完全由匹配決定。比如“給張三調(diào)薪10%后的工資是多少”這種計(jì)算和查表操作RAG天然不擅長模型會(huì)把數(shù)字算錯(cuò)更該交給SQL。兩者并不是二選一。生產(chǎn)環(huán)境里我見過最多的架構(gòu)是“RAG 結(jié)構(gòu)化檢索”的混合文檔類走向量檢索實(shí)體關(guān)系類走圖數(shù)據(jù)庫或SQL最后把兩路結(jié)果拼進(jìn)提示詞。有一批團(tuán)隊(duì)在往這個(gè)方向深入把實(shí)體、關(guān)系抽出來建Ontology本體模型讓RAG的檢索從“按文本相似度找段落”升級(jí)為“按實(shí)體關(guān)系找答案”。這套做法在農(nóng)業(yè)知識(shí)庫、醫(yī)療知識(shí)庫這種專業(yè)領(lǐng)域很有效因?yàn)樾g(shù)語之間的關(guān)聯(lián)比語義相似更重要。但Ontology的構(gòu)建成本很高需要領(lǐng)域?qū)＜覅⑴c團(tuán)隊(duì)人少時(shí)不要輕易啟動(dòng)。還有身邊朋友常問的“RAG知識(shí)庫能存圖片嗎”——答案分兩層如果圖片里有文字信息OCR之后是可以作為文本進(jìn)向量庫的如果圖片本身的信息在視覺上比如產(chǎn)品款式、故障照片那要上多模態(tài)embedding模型檢索時(shí)用圖片或文本去匹配圖片。這塊在后面的落地流程里會(huì)展開。3. 落地流程從PDF到可問答知識(shí)庫的最小可運(yùn)行流水線選型定了就可以動(dòng)手搭流水線。這一章我會(huì)給出一條完整的最小可運(yùn)行鏈路PDF解析成干凈文本按語義分塊生成向量索引最后加上大模型完成問答。代碼以組件式方案演示用到的核心庫是LlamaIndex向量庫用pgvectorembedding用bge-m3中文效果好且成本可控。先跑通這條鏈路再談優(yōu)化。3.1 文檔解析與清洗PDF轉(zhuǎn)Markdown的預(yù)處理RAG效果的天花板不在模型在文檔解析。很多PDF從排版軟件導(dǎo)出后是“假文本”——看起來是文字實(shí)際是曲線和圖形塊直接用PyMuPDF提取會(huì)得到一堆亂序碎片。我處理PDF的順序是先判斷是文本型還是掃描型文本型用PyMuPDF提取掃描型或復(fù)雜排版先做OCR。import fitz # PyMuPDF import re def extract_pdf_text(pdf_path): 提取PDF文本適合文本型PDF doc fitz.open(pdf_path) pages_text [] for page in doc: # 按塊提取保留結(jié)構(gòu)信息 blocks page.get_text(blocks, sortTrue) page_text \n.join([b[4].strip() for b in blocks if b[4].strip()]) pages_text.append(page_text) doc.close() # 簡單清洗去掉連續(xù)的空白行和孤立的頁碼 full_text \n.join(pages_text) full_text re.sub(r\n\s*\n, \n\n, full_text) full_text re.sub(r\n\d{1,3}\n, \n, full_text) # 去掉單獨(dú)成行的頁碼 return full_text這段代碼的邏輯是用PyMuPDF按塊而不是按行提取文本因?yàn)镻DF里的文本塊通常保留了段落的完整性sortTrue保證塊按閱讀順序排列。清洗步驟解決兩個(gè)高頻問題——PDF轉(zhuǎn)文本后的多余空行以及獨(dú)立成頁的頁碼混入正文。參數(shù)方面blocks的塊大小取決于PDF原始排版表格密集的文檔可能要改用get_text(words)再按坐標(biāo)重組但一般場景按塊提取足夠。掃描型PDF要先過OCR工具PaddleOCR或Tesseract把圖像轉(zhuǎn)成帶坐標(biāo)的文本再做版面分析。這一步?jīng)]有統(tǒng)一代碼因?yàn)樗蕾嘜CR模型的輸出格式。推薦的做法是先把OCR結(jié)果存成Markdown保住標(biāo)題層級(jí)和表格結(jié)構(gòu)后續(xù)分塊的質(zhì)量會(huì)明顯好過純文本。3.2 分塊策略固定窗口與語義分塊的取舍分塊的大小直接決定了檢索的命中精度。塊太大語義包含得多但噪聲也多embedding向量被稀釋檢索不夠精準(zhǔn)塊太小語義碎片化模型生成時(shí)缺少上下文答案會(huì)斷章取義。固定窗口分塊的實(shí)現(xiàn)簡單但容易把表格和段落攔腰截?cái)嗾Z義分塊的效果更好但計(jì)算量更大。我的經(jīng)驗(yàn)是先用固定窗口跑基線再針對(duì)檢索失敗樣本局部換成分隔符感知的分塊器。from llama_index.core.node_parser import SemanticSplitterNodeParser from llama_index.core import Document from llama_index.embeddings.huggingface import HuggingFaceEmbedding # 語義分塊基于embedding相似度識(shí)別話題邊界 embed_model HuggingFaceEmbedding(model_nameBAAI/bge-m3) splitter SemanticSplitterNodeParser( buffer_size1024, # 候選文本緩沖區(qū)大小 breakpoint_percentile_threshold95, # 相似度突變的百分位閾值 embed_modelembed_model ) docs [Document(textfull_text, metadata{source: product_manual.pdf})] nodes splitter.get_nodes_from_documents(docs) print(f分塊數(shù): {len(nodes)}, 平均塊長度: {sum(len(n.text) for n in nodes) / len(nodes):.0f} 字符)語義分塊的核心原理是計(jì)算相鄰句子之間的embedding相似度在相似度發(fā)生明顯下跌的位置認(rèn)為進(jìn)入了新話題這里就是切分點(diǎn)。buffer_size1024表示每次評(píng)估的文本窗口大小影響切分粒度和計(jì)算開銷breakpoint_percentile_threshold95是切分的靈敏度值越大越不容易切分塊越長值越小切得越碎。如果發(fā)現(xiàn)檢索結(jié)果經(jīng)常把上下文截?cái)嗫梢哉{(diào)低這個(gè)閾值如果塊之間話題混雜嚴(yán)重就調(diào)高。不建議生產(chǎn)環(huán)境一上來就上語義分塊——它的計(jì)算開銷不小而且很多人會(huì)把分塊和chunk_size混為一談。先跑固定窗口chunk_size512, overlap64作為基線讓評(píng)估數(shù)據(jù)告訴你哪里檢索不準(zhǔn)再對(duì)短板類型的文檔啟用語義分塊這是性價(jià)比最高的路徑。對(duì)于表格密集的文檔記得在分塊后保留node.metadata里的頁碼和表格標(biāo)題后面做引用溯源要用。注意分塊器評(píng)估的是“切出來的塊是否語義自洽”不是“塊與塊是否連續(xù)”。一個(gè)塊里包含了兩個(gè)不同主題但文本連續(xù)語義分塊器能識(shí)別固定窗口識(shí)別不了這是RAG檢索精度差異的主要來源之一。3.3 索引與檢索用Python腳本跑通embedding 向量檢索分塊完成后的下一步是把每個(gè)塊embedding成向量并寫入向量庫。這里我用pgvector存儲(chǔ)配合HNSW索引。embedding模型選擇對(duì)中文場景很關(guān)鍵bge-m3的優(yōu)勢在于它同時(shí)支持稠密檢索和稀疏檢索還能做多向量組合在中文長尾詞和同義改寫上的效果明顯優(yōu)于通用多語言模型。from llama_index.core import StorageContext, VectorStoreIndex from llama_index.vector_stores.postgres import PGVectorStore import psycopg2 # 連接pgvector表結(jié)構(gòu)會(huì)自動(dòng)創(chuàng)建 conn psycopg2.connect( dbnamerag_db, userpostgres, passwordyour_password, hostlocalhost ) vector_store PGVectorStore.from_params( connconn, table_namedoc_nodes, embed_dim1024, # bge-m3的向量維度 hnsw_kwargs{hnsw_m: 16, ef_construction: 64} # HNSW索引參數(shù) ) # 寫入索引 storage_context StorageContext.from_defaults(vector_storevector_store) index VectorStoreIndex(nodesnodes, embed_modelembed_model, storage_contextstorage_context) # 檢索測試 retriever index.as_retriever(similarity_top_k4) results retriever.retrieve(產(chǎn)品保修期是多久) for r in results: print(f得分: {r.score:.3f} | 來源: {r.node.metadata.get(source)} | 文本: {r.node.text[:50]})這段代碼完成了索引構(gòu)建和一次基礎(chǔ)檢索。參數(shù)說明embed_dim1024必須和embedding模型的輸出維度一致bge-m3是1024維如果你換用OpenAI的text-embedding-3-small要改成1536改錯(cuò)會(huì)在寫入時(shí)報(bào)維度錯(cuò)誤。hnsw_m控制HNSW圖每個(gè)節(jié)點(diǎn)的最大連接數(shù)默認(rèn)16數(shù)據(jù)量小時(shí)不需要?jiǎng)觘f_construction是索引構(gòu)建時(shí)的搜索寬度值越大索引質(zhì)量越高但構(gòu)建越慢一般64~128之間。similarity_top_k4是召回?cái)?shù)量它決定了大模型能看到多少候選片段。這個(gè)參數(shù)單獨(dú)調(diào)沒有意義要和后面的重排、提示詞模板一起聯(lián)動(dòng)。檢索測試時(shí)別只看分?jǐn)?shù)要看返回的文本是否真的覆蓋了問題的關(guān)鍵信息這比分?jǐn)?shù)高不高更重要?；A(chǔ)跑通后把檢索結(jié)果丟給LLM生成答案整個(gè)鏈路就算通了。3.4 生成對(duì)接大模型完成問答閉環(huán)最后一步是把檢索到的節(jié)點(diǎn)打包進(jìn)提示詞讓大模型基于檢索內(nèi)容回答。這里的關(guān)鍵是提示詞的邊界控制讓模型”僅依據(jù)上下文回答“、”如果上下文不足就明確說不知道“這是RAG抑制幻覺的第一道防線。如果你用的是支持function calling的模型還能把來源引用也做成結(jié)構(gòu)化輸出前端直接渲染。from llama_index.llms.openai import OpenAI from llama_index.core.query_engine import RetrieverQueryEngine llm OpenAI(modelgpt-4o-mini, temperature0.1) query_engine RetrieverQueryEngine.from_args( retrieverretriever, llmllm, system_prompt( 你是企業(yè)知識(shí)庫助手。請(qǐng)嚴(yán)格基于提供的上下文回答用戶問題。 如果上下文中沒有足夠信息直接回復(fù)知識(shí)庫中未找到相關(guān)內(nèi)容。 回答末尾用[來源: 文檔名-頁碼]標(biāo)注引用。 ) ) response query_engine.query(產(chǎn)品保修期是多久) print(str(response)) print(引用來源:, [n.node.metadata.get(source) for n in response.source_nodes])temperature0.1在知識(shí)庫問答場景是必要的——溫度過高會(huì)讓模型在檢索信息不足時(shí)自由發(fā)揮編造答案的概率顯著上升。對(duì)于RAG場景我更推薦用閉源API先跑通基線因?yàn)樗∪チ吮镜啬Ｐ筒渴鸬淖兞康认到y(tǒng)穩(wěn)定了再根據(jù)成本和合規(guī)需要替換成開源模型。RetrieverQueryEngine生成的答案附帶了source_nodes這是你的引用溯源入口一定要存到日志里后面做答案質(zhì)檢時(shí)它就是判斷“模型是否忠實(shí)于檢索內(nèi)容”的依據(jù)。4. 檢索質(zhì)量優(yōu)化三個(gè)必調(diào)參數(shù)與重排粗排到精排流水線跑通后你很快會(huì)發(fā)現(xiàn)效果達(dá)不到預(yù)期有時(shí)候檢索出來的片段相關(guān)但太寬泛有時(shí)候關(guān)鍵詞明明相同卻搜不到對(duì)應(yīng)內(nèi)容。這一章講檢索側(cè)的三個(gè)核心參數(shù)和一套重排組合它們把RAG的準(zhǔn)頭從“偶爾能用”拉到“生產(chǎn)可用”。4.1 top_k、score_threshold、chunk_size三個(gè)參數(shù)怎么聯(lián)動(dòng)很多新手單獨(dú)調(diào)top_k結(jié)果發(fā)現(xiàn)答案質(zhì)量沒有變化因?yàn)檫@三個(gè)參數(shù)是一個(gè)系統(tǒng)。它們的聯(lián)動(dòng)關(guān)系是chunk_size決定檢索單元的粒度top_k決定喂給模型的候選池大小score_threshold決定候選池的純度。調(diào)參順序應(yīng)當(dāng)是固定語義理解最差的那個(gè)環(huán)節(jié)先動(dòng)其他兩個(gè)。# 三個(gè)參數(shù)的聯(lián)動(dòng)調(diào)參示例 retriever index.as_retriever( similarity_top_k8, # 候選個(gè)數(shù)先擴(kuò)大池子 score_threshold0.35 # 相似度閾值過濾垃圾片段 ) # 對(duì)每個(gè)query先單獨(dú)檢索引擎debug tune_queries [保修期, 退換貨政策, 發(fā)票怎么開] for q in tune_queries: nodes retriever.retrieve(q) print(f\nQuery: {q}) for n in nodes: if n.score 0.35: # 低于閾值的直接丟棄 print(f score{n.score:.3f} | {n.text[:40]})參數(shù)含義與調(diào)節(jié)方向similarity_top_k越大召回的候選片段越多大模型的上下文越充足但無關(guān)節(jié)點(diǎn)的干擾也越大。score_threshold是相似度的下限閾值調(diào)高會(huì)丟掉低相似度但可能信息正確的片段——中文語義檢索里很多答案的措辭與問題完全不同直接用相似度閾值做硬過濾反而誤傷。chunk_size則是根本性的粒度參數(shù)檢索粒度越小答案越精確但容易缺失推理所需的上下文。實(shí)際操作中我建議把chunk_size控制在512~1024字符之間針對(duì)中文top_k控制在4~8然后只用score_threshold做日志記錄而不要做硬過濾因?yàn)橄嗨贫确謹(jǐn)?shù)在不同embedding模型之間的分布差異很大設(shè)定固定閾值非常容易踩坑。記憶要訣是把score_threshold當(dāng)作日志字段而不是過濾條件。RAG項(xiàng)目的效果突破通常發(fā)生在引入重排之后而不是把時(shí)間花在調(diào)這三個(gè)數(shù)字上。4.2 混合檢索與Rerank關(guān)鍵詞搜不到和語義漂移的解藥向量檢索天然不擅長精確詞匹配比如合同編號(hào)“HT-2024-008”embedding會(huì)被語義干擾而關(guān)鍵詞檢索可以精確命中。反過來關(guān)鍵詞檢索處理不了同義改寫比如“質(zhì)?！焙汀氨Ｐ奁凇??；旌蠙z索同時(shí)跑向量檢索和關(guān)鍵詞檢索然后合并結(jié)果能讓兩類檢索互相兜底在大多數(shù)RAG知識(shí)庫場景里是必備的。LlamaIndex里可以直接掛一個(gè)QueryFusionRetriever也可以用Elasticsearch的BM25 向量雙路召回再在合并后做Rerank。from llama_index.retrievers.bm25 import BM25Retriever from llama_index.retrievers import QueryFusionRetriever, FUSION_MODE_RECIPROCAL_RANK bm25_retriever BM25Retriever.from_defaults(nodesnodes, similarity_top_k4) fusion_retriever QueryFusionRetriever( [retriever, bm25_retriever], similarity_top_k6, num_queries1, # 是否對(duì)query做改寫擴(kuò)展1表示不擴(kuò)展 modeFUSION_MODE_RECIPROCAL_RANK, # 用RRF融合兩邊排序 use_asyncFalse ) # 融合檢索再交給一個(gè)中文Rerank模型精排 from llama_index.postprocessor.cohere_rerank import CohereRerank reranker CohereRerank(top_k4, modelrerank-multilingual-v2.0)混合檢索的排序融合用FUSION_MODE_RECIPROCAL_RANKRRF它的思路是把兩個(gè)列表里每個(gè)候選的排名換算成一個(gè)分?jǐn)?shù)1/(k rank)k默認(rèn)60。RRF的好處是不依賴兩套檢索分?jǐn)?shù)可比較——BM25打分的分布和余弦相似度完全不同不能直接相加。num_queries1表示不對(duì)用戶query做同義改寫擴(kuò)展如果改成更大的數(shù)字系統(tǒng)會(huì)用LLM把用戶問題改寫成多個(gè)變體再分別檢索召回率更高但延遲成倍增加本地先不要開。Rerank重排是檢索質(zhì)量質(zhì)的提升原理是做一個(gè)更重的模型對(duì)候選片段和原始query逐對(duì)做相關(guān)性打分打出一個(gè)比embedding相似度更準(zhǔn)的分?jǐn)?shù)。用bge-reranker-base或cohere的rerank模型都能把前面粗排的top_k候選重新排序只保留最相關(guān)的top_n。記住重排模型的輸入格式是 (query, passage) 對(duì)不是單獨(dú)給passage打分——它在比較“這個(gè)片段對(duì)這個(gè)問題有多相關(guān)”而不是“這個(gè)片段在語義上長什么樣”。如果不用Rerank你也許能感覺到答案時(shí)好時(shí)壞用了Rerank通常能穩(wěn)定提升5~10個(gè)百分點(diǎn)的召回準(zhǔn)確率。4.3 圖片與表格進(jìn)知識(shí)庫多模態(tài)RAG的一個(gè)可行做法“RAG知識(shí)庫能存儲(chǔ)圖片嗎”這個(gè)問題在實(shí)踐中經(jīng)常被問到。明確說圖片直接存進(jìn)向量庫沒有任何問題但檢索能不能命中取決于embedding模型的模態(tài)能力。如果你用的是文本embedding模型圖片被轉(zhuǎn)成一個(gè)向量后拿文本去檢索它語義空間是不對(duì)齊的結(jié)果當(dāng)然搜不到。兩個(gè)可行的路徑一是對(duì)文檔里的圖片先OCR或調(diào)用多模態(tài)模型比如GPT-4o、Qwen-VL生成文字描述再把描述文本入庫二是換用多模態(tài)embedding模型直接做圖文互檢。from llama_index.multi_modal_llms.openai import OpenAIMultiModal from llama_index.core.schema import ImageDocument, MetadataMode # 方案1圖片轉(zhuǎn)文本描述后入庫工程上最穩(wěn)妥 mm_llm OpenAIMultiModal(modelgpt-4o-mini, max_tokens300) image_doc ImageDocument(path./assets/fault_diagram.png, metadata{source: 維修手冊(cè).pdf}) description mm_llm.complete( 請(qǐng)?jiān)敿?xì)描述這張圖片中的故障現(xiàn)象和標(biāo)注文字輸出純文本描述, image_documents[image_doc] ) # 用描述文本構(gòu)建節(jié)點(diǎn)走普通文本索引 img_node TextNode(textstr(description), metadata{type: image, orig_path: ./assets/fault_diagram.png})生產(chǎn)中我推薦方案1用多模態(tài)模型把圖片“翻譯”成文本再走常規(guī)向量檢索。它的缺點(diǎn)是描述不能完全覆蓋圖片的視覺細(xì)節(jié)優(yōu)點(diǎn)是不引入新的檢索鏈路工程成本低。如果業(yè)務(wù)真的強(qiáng)依賴圖片原樣檢索比如以圖搜圖的案例再去接專門的圖像檢索模型。表格的情況類似最簡單有效的方式是讓多模態(tài)模型把復(fù)雜表格轉(zhuǎn)成Markdown再入庫Markdown的分塊檢索比純文本表格保留更多結(jié)構(gòu)信息。5. RAG常見坑與排查從“答非所問”到“排隊(duì)中”的五條血淚經(jīng)驗(yàn)RAG系統(tǒng)的排障最怕“全鏈路看著都正常輸出就是一塌糊涂”。這一章把高頻踩坑按“現(xiàn)象→原因→解決”拆開你遇到類似情況時(shí)可以直接對(duì)照定位。五條經(jīng)驗(yàn)覆蓋了從檢索、更新到容錯(cuò)的大部分問題面遇到其他玄學(xué)問題先記住一個(gè)原則把中間過程全部打印出來黑匣子是敵人。5.1 現(xiàn)象檢索結(jié)果相關(guān)但答案還是錯(cuò)——上下文窗口沒塞滿系統(tǒng)日志顯示檢索命中率的分?jǐn)?shù)很高top_k返回的片段確實(shí)提到了問題關(guān)鍵詞但生成的答案張冠李戴。大部分情況是碎片化上下文造成的分塊太碎答案的完整推理鏈被切成了兩三個(gè)獨(dú)立片段而提示詞里塞了top_k4個(gè)片段模型只知道每個(gè)片段各自說什么不知道它們之間的先后關(guān)系和因果關(guān)系。原因集中在chunk_size過小或overlap不足導(dǎo)致一個(gè)完整的論證段落被攔腰切開。解決方法是先看檢索返回的原始片段用肉眼判斷它是否完整覆蓋了生成答案所需的前提信息。如果片段之間相互獨(dú)立查一下分塊器是否按標(biāo)題或段落邊界切分30%的情況下把chunk_size從512調(diào)整到1024overlap保持在64~128再配合rerank把真正相關(guān)的片段排進(jìn)前幾位就能解決。另外檢查提示詞模板確認(rèn)你把所有檢索片段都放進(jìn)了上下文窗口有些框架默認(rèn)只取前兩段這是個(gè)很容易被你忽略的坑。5.2 現(xiàn)象Dify知識(shí)庫排隊(duì)中——embedding并發(fā)和文檔拆分沖突用Dify上線的團(tuán)隊(duì)經(jīng)常遇到知識(shí)庫處理任務(wù)排隊(duì)文檔傳多了界面一直轉(zhuǎn)圈。這是Dify知識(shí)庫的流水線設(shè)計(jì)導(dǎo)致的生產(chǎn)環(huán)境里索引文檔會(huì)分批觸發(fā)embedding調(diào)用如果embedding API有并發(fā)限制或者文檔拆分階段有循環(huán)依賴任務(wù)就堆積起來了。我不止一次看到有人把幾百個(gè)PDF一次性拖進(jìn)Dify然后整個(gè)隊(duì)列卡死。解決方法是拆分上傳批次一批控制在50個(gè)文檔以內(nèi)并且分批之間留出處理間隔。更重要的一點(diǎn)是檢查embedding模型來源——如果你用的是在線API看它是否有每分鐘的token限額Dify知識(shí)庫流水線卡死的常見原因是embedding API被限流后重試機(jī)制不夠健壯。我一般會(huì)先上傳一個(gè)復(fù)雜文檔驗(yàn)證耗時(shí)再按耗時(shí)估算合理批次大小而不是盲目批量導(dǎo)入。如果你恰好看到“排隊(duì)中”和“知庫”同時(shí)出現(xiàn)先懷疑是不是embedding響應(yīng)變慢了不是Dify框架本身的問題。5.3 現(xiàn)象知識(shí)庫更新后問答不生效——緩存與索引版本新文檔上傳成功后問答系統(tǒng)仍然用舊內(nèi)容回答。原因通常是多層緩存疊加文件解析階段有緩存、embedding結(jié)果有緩存、向量庫里有舊索引未清理、上層還套了對(duì)話緩存。尤其在Dify這類平臺(tái)上文檔更新會(huì)生成一個(gè)新的索引版本但已有的會(huì)話或查詢可能還在用舊版本。解決方法是先定位緩存層檢查文件是否重新解析、embedding是否重新計(jì)算、向量表中是否堆積了重復(fù)節(jié)點(diǎn)。組件式方案中我習(xí)慣在元數(shù)據(jù)里寫入version字段加載索引時(shí)過濾version 最新值Dify平臺(tái)則在更新文檔后手動(dòng)觸發(fā)一次索引重建并在測試時(shí)開一個(gè)無緩存的新會(huì)話驗(yàn)證。還有一個(gè)容易被忽略的坑向量庫中舊版本文檔的向量并沒有被刪除新檢索把新舊內(nèi)容同時(shí)召回而舊內(nèi)容優(yōu)先級(jí)更高。務(wù)必在寫入新索引時(shí)清理對(duì)應(yīng)source的舊向量。5.4 現(xiàn)象圖片檢索不到——知識(shí)庫能存圖片嗎的真相這個(gè)問題反復(fù)出現(xiàn)——用戶把圖片文檔傳進(jìn)知識(shí)庫檢索時(shí)用文本搜不到?，F(xiàn)象層面前面提過這里講排查路徑。首先是確認(rèn)你的文檔解析階段是否真的處理了圖片很多PDF解析器默認(rèn)丟棄圖片只保留文字層圖片根本沒有入庫。其次是確認(rèn)圖片是否有文字描述如果圖片入庫的是二進(jìn)制向量而你是用文本向量去檢索兩套向量不在同一個(gè)語義空間里搜不到是正常的。解決方法是先做圖片的OCR或多模態(tài)描述把“圖”變成“文”后再入庫這是工程上最省事且效果穩(wěn)定的一條路。如果業(yè)務(wù)強(qiáng)烈依賴圖片檢索比如要按圖像特征搜故障照片需要引入獨(dú)立的圖像向量庫并單獨(dú)走以圖搜圖的檢索邏輯不要混在文本RAG鏈路里。排查時(shí)先在索引里查該圖片對(duì)應(yīng)的節(jié)點(diǎn)是否存在、文本描述是否合理再?zèng)Q定是修解析還是修檢索。5.5 現(xiàn)象答案“看起來對(duì)”但引用對(duì)不上——元數(shù)據(jù)跟蹤問答系統(tǒng)給出了正確回答但點(diǎn)擊來源跳轉(zhuǎn)后文檔里根本沒有那段話。這個(gè)現(xiàn)象背后是兩個(gè)問題疊加分塊時(shí)做了文本截?cái)嗄Ｐ蛯?shí)際看到的內(nèi)容和源文檔不完全一致或者在提示詞里把來源寫死為“知識(shí)庫”模型自己編了一個(gè)引用格式。RAG系統(tǒng)的答案溯源能力取決于從頭到尾是否保留metadata。解決方法是全鏈路傳遞元數(shù)據(jù)解析階段保留頁碼和文檔名分塊階段保留原始段落偏移檢索階段把metadata掛在每個(gè)節(jié)點(diǎn)上生成階段的提示詞里明確要求“根據(jù)上下文中的source字段輸出引用”。如果模型引用格式錯(cuò)了是提示詞問題如果引用內(nèi)容找不到是分塊污染或索引殘留問題。排查時(shí)直接打印response.source_nodes看看能不能從源頭回溯到對(duì)應(yīng)段落這是判斷RAG系統(tǒng)是否可信的最直接手段。引用溯源功能上線后才能把問答系統(tǒng)放給業(yè)務(wù)用戶用——否則用戶看到有來源標(biāo)識(shí)就覺得結(jié)論可靠這是比幻覺答案更致命的安全隱患。提示RAG排障不要依賴“感覺”每次發(fā)現(xiàn)問題都保留一個(gè)可復(fù)現(xiàn)的最小查詢和當(dāng)時(shí)各環(huán)節(jié)的輸出日志。很多玄學(xué)問題在換了一個(gè)embedding模型或升級(jí)了框架后自己消失但你沒有日志就永遠(yuǎn)不知道為什么消失的。6. 進(jìn)階驗(yàn)證用RAGAS和回歸測試守護(hù)你的知識(shí)庫別讓“玄學(xué)”變“黑匣子”RAG系統(tǒng)跑通后最大的風(fēng)險(xiǎn)是效果退化——你換了一個(gè)embedding模型或者調(diào)整了分塊參數(shù)當(dāng)時(shí)覺得沒問題兩周后用戶反饋答案質(zhì)量下降了。沒有評(píng)估體系的話這種退化只能靠玄學(xué)感知。我通常會(huì)在知識(shí)庫穩(wěn)定運(yùn)行后立刻引入離線評(píng)估用RAGAS這套框架量化三個(gè)指標(biāo)忠實(shí)度答案是否忠實(shí)于檢索內(nèi)容、相關(guān)性答案是否回答了用戶問題、上下文精確率檢索結(jié)果中真正有用的比例。from ragas import evaluate from ragas.metrics import faithfulness, answer_relevancy, context_precision from datasets import Dataset # 準(zhǔn)備評(píng)估樣本20~50條真實(shí)用戶查詢 標(biāo)準(zhǔn)答案 檢索上下文 eval_dataset Dataset.from_dict({ question: [產(chǎn)品保修期是多久], answer: [自購買之日起12個(gè)月], contexts: [[保修政策整機(jī)保修12個(gè)月核心部件保修36個(gè)月]], ground_truth: [自購買之日起12個(gè)月], }) results evaluate(eval_dataset, metrics[faithfulness, answer_relevancy, context_precision]) print(忠實(shí)度:, results[faithfulness]) print(答案相關(guān)性:, results[answer_relevancy]) print(上下文精確率:, results[context_precision])這段評(píng)估代碼要求你準(zhǔn)備好 20~50 條帶標(biāo)準(zhǔn)答案的測試集這是整個(gè)RAG工程里最需要花時(shí)間沉淀的部分。指標(biāo)解讀上忠實(shí)度低說明大模型自由發(fā)揮嚴(yán)重先查提示詞和溫度相關(guān)性低說明檢索沒問題但答案偏題查LLM對(duì)上下文的利用方式上下文精確率低說明把不相關(guān)的片段召回進(jìn)了候選池優(yōu)先調(diào)Rerank和top_k。這套評(píng)估要固化成回歸測試每次改動(dòng)embedding模型、分塊參數(shù)或提示詞模板都跑一遍同一份測試集指標(biāo)不降才允許上線。最后再補(bǔ)一個(gè)排查習(xí)慣保留線上真實(shí)查詢的日志定期把那些“用戶改寫了問題才問到答案”的case抽取出來加進(jìn)測試集。讓評(píng)估集跟著真實(shí)業(yè)務(wù)長比任何調(diào)參技巧都重要。我自己踩過最大的坑就是上線前沒有沉淀測試集上線后一遇到提示詞調(diào)整就沒法判斷效果好壞只能回滾?，F(xiàn)在每做一個(gè)RAG項(xiàng)目第一周就把評(píng)估集建好——它決定了你的系統(tǒng)是持續(xù)迭代的黑匣子還是一個(gè)看得見、摸得著、能隨時(shí)改進(jìn)的工程系統(tǒng)。希望這份手冊(cè)能幫你少走幾步彎路。本文還有配套的精品資源點(diǎn)擊獲取