1. 項(xiàng)目概述為什么RAG是當(dāng)前AI應(yīng)用落地的關(guān)鍵拼圖最近和不少做AI應(yīng)用的朋友聊天發(fā)現(xiàn)一個(gè)挺有意思的現(xiàn)象大家不再只盯著大模型的參數(shù)規(guī)?；蛘甙駟闻琶擞懻摰慕裹c(diǎn)越來(lái)越集中在“怎么讓模型別胡說(shuō)八道”、“怎么把公司內(nèi)部的知識(shí)用起來(lái)”這些實(shí)際問(wèn)題上。這背后一個(gè)繞不開的技術(shù)就是RAG也就是檢索增強(qiáng)生成。你可能在各種地方聽過(guò)這個(gè)詞感覺(jué)它很火但又有點(diǎn)霧里看水。簡(jiǎn)單來(lái)說(shuō)RAG就是給大語(yǔ)言模型LLM配了一個(gè)“超級(jí)外掛大腦”——一個(gè)可以實(shí)時(shí)查詢、檢索外部知識(shí)庫(kù)的系統(tǒng)。當(dāng)模型需要回答問(wèn)題時(shí)它不再僅僅依賴自己訓(xùn)練時(shí)“記住”的那些可能已經(jīng)過(guò)時(shí)或者不全面的知識(shí)而是先去這個(gè)外掛大腦里搜一搜最新的、相關(guān)的資料然后結(jié)合這些資料來(lái)生成答案。這解決了大模型應(yīng)用中最頭疼的幾個(gè)問(wèn)題幻覺(jué)一本正經(jīng)地胡說(shuō)八道、知識(shí)更新滯后模型訓(xùn)練完世界又變了以及數(shù)據(jù)隱私和安全不可能把公司機(jī)密數(shù)據(jù)拿去訓(xùn)練一個(gè)公開模型。想象一下你想讓AI幫你分析一份剛簽的合同或者回答一個(gè)關(guān)于公司內(nèi)部產(chǎn)品架構(gòu)的細(xì)節(jié)問(wèn)題RAG就能讓模型精準(zhǔn)地引用你上傳的合同文本或技術(shù)文檔來(lái)回答而不是憑空編造。這也是為什么從OpenAI的GPTs到國(guó)內(nèi)各大平臺(tái)的AI助手再到各種企業(yè)級(jí)AI應(yīng)用RAG幾乎成了標(biāo)配能力。我之所以想寫這個(gè)“完全指南”是因?yàn)榘l(fā)現(xiàn)網(wǎng)上很多資料要么過(guò)于學(xué)術(shù)化講一堆數(shù)學(xué)公式要么就是某個(gè)框架比如LangChain的簡(jiǎn)單教程缺了全局視角和工程落地的細(xì)節(jié)。這次我會(huì)結(jié)合最新的實(shí)踐特別是像DeepSeek這類高性能、高性價(jià)比模型興起后的新玩法從頭到尾拆解如何構(gòu)建一個(gè)健壯、可用的RAG系統(tǒng)。無(wú)論你是想快速上手做個(gè)demo還是正在為公司規(guī)劃一個(gè)正式的AI知識(shí)庫(kù)項(xiàng)目相信這些從一線踩坑總結(jié)出來(lái)的經(jīng)驗(yàn)都能幫到你。2. RAG的核心架構(gòu)與工作流程拆解要理解RAG不能只把它看作一個(gè)黑盒。一個(gè)完整的RAG系統(tǒng)其實(shí)是一條精心設(shè)計(jì)的流水線每個(gè)環(huán)節(jié)的優(yōu)劣都直接影響最終答案的質(zhì)量。我們可以把它拆解成四個(gè)核心階段文檔處理、檢索、增強(qiáng)和生成。2.1 從原始文檔到向量知識(shí)庫(kù)的構(gòu)建這是所有RAG系統(tǒng)的地基但也是最容易被輕視的環(huán)節(jié)。很多人以為就是簡(jiǎn)單地把PDF或TXT文件切一切扔進(jìn)向量數(shù)據(jù)庫(kù)就完事了。實(shí)際上這里的門道很深。文檔加載與解析第一步是讓機(jī)器能“讀懂”各種格式的文件。除了常見(jiàn)的.txt,.pdf,.docx還有網(wǎng)頁(yè)、Markdown、甚至數(shù)據(jù)庫(kù)表。你需要一個(gè)強(qiáng)大的解析器Parser。例如解析PDF時(shí)PyPDF2或pdfplumber可以提取文本但對(duì)于復(fù)雜的版式如多欄、表格、圖表unstructured或docling這類庫(kù)效果更好它們能保留一定的語(yǔ)義結(jié)構(gòu)。一個(gè)常見(jiàn)的坑是直接從PDF復(fù)制文本會(huì)丟失換行和空格導(dǎo)致句子破碎所以必須用專門的庫(kù)。文本分塊Chunking這是決定檢索精度的關(guān)鍵一步。分塊不是簡(jiǎn)單按字?jǐn)?shù)切割。想象一下如果你把一本小說(shuō)的每一頁(yè)都切成256個(gè)字符的片段那么檢索“主角在第三章做了什么”時(shí)系統(tǒng)可能只返回包含“主角”和“第三章”幾個(gè)字但不連貫的碎片丟失了完整的上下文。固定大小分塊最簡(jiǎn)單比如每塊500字符重疊100字符。適合格式規(guī)整的文檔。工具如LangChain的RecursiveCharacterTextSplitter?；谡Z(yǔ)義的分塊更高級(jí)利用句子邊界、標(biāo)點(diǎn)、甚至小模型來(lái)識(shí)別自然段落。例如semantic-text-splitter庫(kù)會(huì)嘗試在完整的句子或段落末尾進(jìn)行切割保證塊的語(yǔ)義完整性。分層分塊對(duì)于長(zhǎng)文檔如手冊(cè)、論文可以采用多級(jí)分塊。先按章節(jié)分大塊大塊內(nèi)再按段落分小塊。檢索時(shí)可以先定位到大章節(jié)再精確定位到具體段落兼顧召回率和精度。實(shí)操心得分塊大小沒(méi)有銀彈。對(duì)于事實(shí)性問(wèn)答小塊200-400字精度高對(duì)于需要推理總結(jié)的任務(wù)大塊800-1000字能提供更豐富的上下文。我通常的做法是準(zhǔn)備兩種分塊策略在測(cè)試集上對(duì)比效果。重疊Overlap設(shè)置很重要通常10%-20%的重疊能有效防止關(guān)鍵信息被切碎。向量化Embedding這是將文本轉(zhuǎn)化為機(jī)器能理解的“數(shù)學(xué)指紋”的過(guò)程。選擇一個(gè)好的嵌入模型Embedding Model至關(guān)重要。它決定了語(yǔ)義相似的文本在向量空間里是否真的“靠近”。模型選擇OpenAI的text-embedding-3系列效果很好但需付費(fèi)。開源方面BGEBAAI、text2vec、M3E都是中文社區(qū)表現(xiàn)優(yōu)異的模型。BGE系列對(duì)中文語(yǔ)義理解尤其出色且提供了不同尺寸的版本平衡效果與速度。維度維度越高通常表征能力越強(qiáng)但計(jì)算和存儲(chǔ)開銷也越大。BGE的bge-large-zh是1024維而text-embedding-3-small是1536維。對(duì)于千萬(wàn)級(jí)以下的文檔庫(kù)1024維通常足夠。本地部署 vs. API調(diào)用如果數(shù)據(jù)敏感或要求低延遲建議本地部署嵌入模型。使用SentenceTransformers庫(kù)可以輕松加載Hugging Face上的模型。計(jì)算一下用CPU編碼百萬(wàn)級(jí)文本可能很慢但用一張消費(fèi)級(jí)GPU如RTX 4090就能獲得極快的速度。向量數(shù)據(jù)庫(kù)入庫(kù)生成向量后需要存入專門的數(shù)據(jù)庫(kù)以便快速檢索。這不是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)擅長(zhǎng)的。主流選擇有Pinecone / Weaviate (云服務(wù))開箱即用管理方便適合快速原型和中小規(guī)模項(xiàng)目。Chroma (本地/輕量)簡(jiǎn)單易用純Python適合學(xué)習(xí)和中小型項(xiàng)目但生產(chǎn)環(huán)境穩(wěn)定性待考。Qdrant / Milvus (自托管/高性能)為大規(guī)模向量搜索設(shè)計(jì)支持分布式部署性能強(qiáng)勁是生產(chǎn)環(huán)境的常見(jiàn)選擇。Qdrant的Rust底層效率很高M(jìn)ilvus生態(tài)更龐大。PGVector (基于PostgreSQL)如果你的技術(shù)棧里已經(jīng)有PostgreSQL這是一個(gè)非常自然的選擇。它把向量作為一種數(shù)據(jù)類型可以直接用SQL進(jìn)行查詢和與其他業(yè)務(wù)數(shù)據(jù)關(guān)聯(lián)管理起來(lái)非常統(tǒng)一。我個(gè)人的傾向是對(duì)于嚴(yán)肅的生產(chǎn)系統(tǒng)如果數(shù)據(jù)規(guī)模大、要求高性能選Qdrant或Milvus如果想和現(xiàn)有業(yè)務(wù)數(shù)據(jù)庫(kù)深度集成用PGVector。初期驗(yàn)證用Chroma最快。2.2 檢索Retrieval不僅僅是相似度匹配當(dāng)用戶提問(wèn)時(shí)系統(tǒng)需要從海量文檔塊中找出最相關(guān)的幾個(gè)。最簡(jiǎn)單的就是計(jì)算問(wèn)題向量和所有文檔塊向量的余弦相似度取Top-K。但這遠(yuǎn)遠(yuǎn)不夠?；A(chǔ)語(yǔ)義檢索即上述的向量相似度搜索。這是核心但存在“詞匯鴻溝”問(wèn)題問(wèn)題表述和文檔表述不同但語(yǔ)義相同可能檢索不到?；旌蠙z索Hybrid Search結(jié)合語(yǔ)義檢索和關(guān)鍵詞檢索如BM25。BM25擅長(zhǎng)精確匹配關(guān)鍵詞能抓住“命名實(shí)體”、“特定術(shù)語(yǔ)”彌補(bǔ)純向量檢索有時(shí)過(guò)于“模糊”的缺點(diǎn)。例如問(wèn)題“DeepSeek-V4 Flash模型有什么特點(diǎn)”BM25能確保檢索到包含“DeepSeek-V4 Flash”這個(gè)精確詞組的文檔塊。Qdrant、Elasticsearch都支持混合檢索。重排序Reranking初步檢索可能返回10-20個(gè)相關(guān)塊但其中可能有幾個(gè)只是“沾邊”。用一個(gè)更精細(xì)但更耗時(shí)的“交叉編碼器”模型對(duì)這批候選文檔進(jìn)行重新打分和排序能顯著提升Top結(jié)果的相關(guān)性。BGE-Reranker、Cohere Rerank都是常用的重排序模型。這是一個(gè)“召回后再精排”的策略用少量計(jì)算成本換取答案質(zhì)量的顯著提升。查詢轉(zhuǎn)換Query Transformation用戶的原始問(wèn)題可能很模糊。我們可以對(duì)查詢進(jìn)行優(yōu)化查詢擴(kuò)展利用LLM生成問(wèn)題的多個(gè)同義或相關(guān)問(wèn)法用這些擴(kuò)展查詢一起去檢索提高召回率。例如“怎么部署RAG”可以擴(kuò)展為“RAG系統(tǒng)部署步驟”、“搭建檢索增強(qiáng)生成環(huán)境的方法”。查詢壓縮/改寫對(duì)于冗長(zhǎng)的問(wèn)題提取核心意圖。例如“我昨天看了篇博客講的是用LangChain和Chroma做RAG但步驟里好像沒(méi)提怎么處理PDF表格你能告訴我具體怎么做嗎”可以壓縮為“如何處理PDF表格中的文本用于RAG”。逐步分解Step-back讓LLM先根據(jù)問(wèn)題推導(dǎo)出更本質(zhì)、更通用的“元問(wèn)題”進(jìn)行檢索獲取背景知識(shí)再結(jié)合原問(wèn)題生成答案。這適合需要多步推理的復(fù)雜問(wèn)題。2.3 增強(qiáng)Augmentation與生成Generation檢索到相關(guān)文檔塊后并不是直接扔給LLM就完事了。如何“呈現(xiàn)”這些上下文極大影響最終答案的質(zhì)量。上下文構(gòu)造與提示工程把檢索到的文檔塊按照相關(guān)性排序拼接成一個(gè)長(zhǎng)的“上下文”然后和用戶問(wèn)題一起構(gòu)成給LLM的最終提示詞Prompt。這里的關(guān)鍵是格式和指令。一個(gè)經(jīng)典的Prompt模板如下你是一個(gè)專業(yè)的助手請(qǐng)嚴(yán)格根據(jù)以下提供的上下文信息來(lái)回答問(wèn)題。如果上下文中的信息不足以回答問(wèn)題請(qǐng)直接說(shuō)“根據(jù)提供的信息我無(wú)法回答這個(gè)問(wèn)題”不要編造信息。 上下文信息 {context_document_1} {context_document_2} ... {context_document_k} 問(wèn)題{user_question} 請(qǐng)根據(jù)上述上下文回答指令清晰明確要求模型“基于上下文”并設(shè)置“不知道”的邊界這是抑制幻覺(jué)的第一道防線。上下文標(biāo)記清晰地區(qū)分上下文和問(wèn)題避免模型混淆。相關(guān)性排序把最相關(guān)的文檔放在上下文靠前的位置因?yàn)橛行┠Ｐ蛯?duì)上下文長(zhǎng)度有限制可能會(huì)忽略后面的內(nèi)容。生成模型LLM的選擇與調(diào)用這是RAG的“大腦”。選擇很多GPT-4 / Claude-3效果頂尖但API成本高數(shù)據(jù)需出境。DeepSeek系列近期炙手可熱。特別是DeepSeek-V3和最新的V4系列在性能上逼近第一梯隊(duì)但價(jià)格極具競(jìng)爭(zhēng)力甚至免費(fèi)額度很高API響應(yīng)也快成為很多開發(fā)者的新寵。它的長(zhǎng)上下文能力128K/1M對(duì)于需要注入大量上下文的RAG場(chǎng)景非常友好。國(guó)內(nèi)大廠模型通義千問(wèn)、文心一言、智譜GLM等API易得符合數(shù)據(jù)合規(guī)要求。本地模型Llama 3、Qwen 2.5、Yi等開源模型用Ollama、vLLM、LMDeploy等工具本地部署數(shù)據(jù)完全私有但需要GPU資源和技術(shù)棧。注意事項(xiàng)模型的選擇不僅是效果和成本的權(quán)衡更要考慮上下文窗口長(zhǎng)度。如果你檢索并拼接了10個(gè)每個(gè)1000字的文檔塊那么上下文就長(zhǎng)達(dá)1萬(wàn)字。許多模型的上下文窗口是4K、8K或16K你需要確保“問(wèn)題上下文回答”的總長(zhǎng)度不超過(guò)限制。DeepSeek的128K甚至1M上下文在這里就是巨大優(yōu)勢(shì)。3. 構(gòu)建生產(chǎn)級(jí)RAG系統(tǒng)的關(guān)鍵技術(shù)與工程實(shí)踐了解了流程我們來(lái)看看如何把它從玩具變成真正可靠的生產(chǎn)系統(tǒng)。這里涉及到架構(gòu)設(shè)計(jì)、性能優(yōu)化和效果評(píng)估。3.1 高級(jí)檢索模式讓搜索更智能基礎(chǔ)的向量檢索在很多場(chǎng)景下已經(jīng)不夠用了我們需要更精細(xì)的控制。元數(shù)據(jù)過(guò)濾向量數(shù)據(jù)庫(kù)中的每個(gè)文檔塊除了向量和文本還可以存儲(chǔ)元數(shù)據(jù)比如來(lái)源文件、作者、創(chuàng)建日期、章節(jié)標(biāo)題等。檢索時(shí)可以結(jié)合語(yǔ)義相似度和元數(shù)據(jù)過(guò)濾。例如“僅從2024年的產(chǎn)品手冊(cè)中查找相關(guān)信息”。這能極大提升檢索的精準(zhǔn)度。在Chroma、Qdrant中這通常通過(guò)where過(guò)濾器實(shí)現(xiàn)。多向量檢索一個(gè)文檔塊可能包含多種信息。我們可以為同一個(gè)文本塊生成多個(gè)向量表示一個(gè)基于整體內(nèi)容一個(gè)基于摘要一個(gè)基于提取的關(guān)鍵詞。檢索時(shí)綜合這些不同視角的向量進(jìn)行搜索能獲得更全面的結(jié)果。圖檢索Graph RAG這是更前沿的方向。傳統(tǒng)的RAG把文檔視為獨(dú)立的“碎片”丟失了碎片之間的關(guān)聯(lián)比如“A概念在B章節(jié)被定義在C章節(jié)被應(yīng)用”。圖檢索先構(gòu)建一個(gè)知識(shí)圖譜提取文檔中的實(shí)體人、地點(diǎn)、概念和關(guān)系檢索時(shí)不僅找相似的文本塊還沿著圖譜尋找相關(guān)聯(lián)的實(shí)體和子圖將更結(jié)構(gòu)化的知識(shí)送入LLM。這對(duì)于回答涉及多步驟推理、因果關(guān)系的問(wèn)題特別有效。LlamaIndex對(duì)Graph RAG有較好的支持。智能路由Query Routing系統(tǒng)可以根據(jù)問(wèn)題的類型決定走不同的檢索路徑。例如通過(guò)一個(gè)分類器判斷如果是事實(shí)性問(wèn)答 - 走標(biāo)準(zhǔn)向量檢索。如果是需要數(shù)值計(jì)算或精確匹配 - 走傳統(tǒng)數(shù)據(jù)庫(kù)查詢或關(guān)鍵詞檢索。如果是需要多文檔匯總 - 走更復(fù)雜的、檢索多個(gè)子問(wèn)題并合成的路徑。 這需要在前端設(shè)計(jì)一個(gè)“路由智能體”。3.2 RAG的評(píng)估體系如何知道你的系統(tǒng)好不好“感覺(jué)回答得還行”是遠(yuǎn)遠(yuǎn)不夠的。我們需要可量化的指標(biāo)。RAG的評(píng)估通常分為“檢索質(zhì)量”和“生成質(zhì)量”兩部分。檢索質(zhì)量評(píng)估命中率Hit Rate在Top-K個(gè)檢索結(jié)果中至少包含一個(gè)能回答問(wèn)題的真實(shí)相關(guān)文檔的概率。這是最基礎(chǔ)的指標(biāo)。平均排序倒數(shù)MRR計(jì)算第一個(gè)相關(guān)文檔出現(xiàn)位置的倒數(shù)然后對(duì)所有問(wèn)題取平均。它衡量系統(tǒng)把相關(guān)文檔排在前面的能力。歸一化折損累計(jì)增益NDCG不僅考慮相關(guān)文檔是否被檢索到還考慮它們被排在第幾位以及相關(guān)程度可以人工標(biāo)注相關(guān)性分?jǐn)?shù)。這是更精細(xì)的指標(biāo)。生成質(zhì)量評(píng)估忠實(shí)度Faithfulness生成的答案是否嚴(yán)格基于提供的上下文有沒(méi)有捏造上下文里沒(méi)有的信息這是對(duì)抗“幻覺(jué)”的核心指標(biāo)。可以用一個(gè)小的LLM如GPT-3.5來(lái)判斷答案中的每一條陳述是否都能從上下文中找到依據(jù)。答案相關(guān)性Answer Relevance生成的答案是否直接回答了原始問(wèn)題有沒(méi)有答非所問(wèn)或包含冗余信息上下文利用率Context Utilization模型是否有效地利用了提供的上下文還是基本忽略了上下文只憑自己的知識(shí)回答這些評(píng)估可以人工進(jìn)行但成本高。現(xiàn)在有一些自動(dòng)化框架如RAGAS、TruLens、ARES它們利用LLM本身作為裁判來(lái)對(duì)答案進(jìn)行上述維度的評(píng)分雖然不完全準(zhǔn)確但對(duì)于快速迭代和對(duì)比不同方案非常有用。構(gòu)建測(cè)試集這是評(píng)估的基石。你需要從真實(shí)業(yè)務(wù)場(chǎng)景中收集一批“問(wèn)題-標(biāo)準(zhǔn)答案”對(duì)并且知道每個(gè)標(biāo)準(zhǔn)答案對(duì)應(yīng)支撐它的“文檔片段”Ground Truth。用這個(gè)測(cè)試集去跑你的RAG流水線計(jì)算各項(xiàng)指標(biāo)。3.3 性能優(yōu)化與成本控制當(dāng)文檔庫(kù)達(dá)到百萬(wàn)、千萬(wàn)級(jí)時(shí)性能和成本就成為必須考慮的問(wèn)題。向量索引優(yōu)化暴力計(jì)算問(wèn)題向量和所有文檔向量的相似度暴力搜索是不可行的。向量數(shù)據(jù)庫(kù)使用近似最近鄰搜索算法來(lái)加速如HNSW分層可導(dǎo)航小世界、IVF倒排文件。這些算法通過(guò)建立索引用少量精度換取巨大速度提升。在初始化向量數(shù)據(jù)庫(kù)時(shí)需要根據(jù)數(shù)據(jù)規(guī)模和查詢延遲要求來(lái)調(diào)整索引參數(shù)如HNSW的ef_construction和M參數(shù)。分層檢索與緩存分層檢索先用一個(gè)快速的、粗略的檢索器如基于較小嵌入模型的檢索召回大量候選比如100個(gè)再用一個(gè)精確但慢的檢索器如大嵌入模型重排序從這100個(gè)里精選出Top-5。緩存對(duì)于高頻、熱點(diǎn)問(wèn)題可以將“問(wèn)題-檢索結(jié)果”甚至“問(wèn)題-最終答案”緩存起來(lái)下次直接返回極大降低檢索和生成開銷?？梢杂肦edis等內(nèi)存數(shù)據(jù)庫(kù)實(shí)現(xiàn)。嵌入模型蒸餾與量化BGE-large模型效果好但體積大、推理慢?？梢钥紤]使用其蒸餾版如BGE-small或?qū)δＰ瓦M(jìn)行量化將FP32精度轉(zhuǎn)換為INT8/INT4在幾乎不損失效果的情況下大幅提升編碼速度和減少內(nèi)存占用。LLM調(diào)用優(yōu)化流式輸出對(duì)于長(zhǎng)答案使用流式接口Streaming可以提升用戶體驗(yàn)實(shí)現(xiàn)“打字機(jī)”效果。合理設(shè)置參數(shù)不要盲目使用低temperature可能導(dǎo)致回答呆板或高max_tokens造成浪費(fèi)。對(duì)于事實(shí)性回答temperature0.1左右比較合適。并發(fā)與批處理如果需要處理大量問(wèn)題可以利用異步調(diào)用或批處理API來(lái)提高吞吐。4. 基于主流框架的RAG實(shí)戰(zhàn)以LangChain和LlamaIndex為例理論說(shuō)再多不如動(dòng)手搭一個(gè)。這里我用兩個(gè)最流行的框架——LangChain和LlamaIndex分別展示一個(gè)最簡(jiǎn)單的RAG流水線如何構(gòu)建。我會(huì)以處理一份技術(shù)PDF文檔并問(wèn)答為例。4.1 使用LangChain構(gòu)建RAG流水線LangChain是一個(gè)將LLM與各種工具、數(shù)據(jù)源連接起來(lái)的框架其設(shè)計(jì)哲學(xué)是“鏈”Chain非常適合快速組裝原型。環(huán)境準(zhǔn)備pip install langchain langchain-community langchain-chroma pypdf openai tiktoken假設(shè)我們使用OpenAI的嵌入和生成模型實(shí)際中可替換為DeepSeek等。步驟一文檔加載與分割from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加載PDF loader PyPDFLoader(path/to/your/technical_manual.pdf) documents loader.load() # 2. 分割文本 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每個(gè)塊的大小 chunk_overlap50, # 塊之間的重疊 length_functionlen, separators[\n\n, \n, 。, , , , , , ] # 中文優(yōu)先按句分割 ) chunks text_splitter.split_documents(documents) print(f將文檔切分為 {len(chunks)} 個(gè)塊。)步驟二向量化與存儲(chǔ)from langchain_openai import OpenAIEmbeddings from langchain_chroma import Chroma # 使用OpenAI的嵌入模型可替換為本地模型如HuggingFaceEmbeddings embeddings OpenAIEmbeddings(modeltext-embedding-3-small, openai_api_keyyour_key) # 創(chuàng)建向量數(shù)據(jù)庫(kù)并存儲(chǔ) vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db # 指定持久化目錄 ) # 之后加載可以直接用 Chroma(persist_directory./chroma_db, embedding_functionembeddings)步驟三構(gòu)建檢索鏈from langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate # 1. 定義提示詞模板 prompt_template 你是一個(gè)技術(shù)文檔助手。請(qǐng)僅根據(jù)以下上下文來(lái)回答問(wèn)題。如果上下文沒(méi)有提供足夠信息請(qǐng)說(shuō)“根據(jù)已知信息無(wú)法回答”不要編造。 上下文 {context} 問(wèn)題{question} 請(qǐng)根據(jù)上下文給出準(zhǔn)確、簡(jiǎn)潔的答案 PROMPT PromptTemplate( templateprompt_template, input_variables[context, question] ) # 2. 初始化LLM這里替換為DeepSeek # 假設(shè)有LangChain集成的DeepSeek接口或使用通用的ChatOpenAI兼容接口 # 例如如果DeepSeek API兼容OpenAI格式 llm ChatOpenAI( modeldeepseek-chat, # 或具體模型名 openai_api_basehttps://api.deepseek.com/v1, openai_api_keyyour_deepseek_key, temperature0.1 ) # 3. 創(chuàng)建檢索問(wèn)答鏈 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 最簡(jiǎn)單的方式將所有上下文塞進(jìn)prompt retrievervectorstore.as_retriever(search_kwargs{k: 4}), # 檢索4個(gè)最相關(guān)塊 chain_type_kwargs{prompt: PROMPT}, return_source_documentsTrue # 返回源文檔便于調(diào)試 ) # 4. 進(jìn)行問(wèn)答 result qa_chain.invoke({query: 本文檔中提到的核心架構(gòu)是什么}) print(答案, result[result]) print(\n來(lái)源) for doc in result[source_documents]: print(f- {doc.metadata.get(source, N/A)} (頁(yè)碼: {doc.metadata.get(page, N/A)}))踩坑記錄LangChain的RecursiveCharacterTextSplitter默認(rèn)按字符數(shù)分割對(duì)中文可能在不該斷句的地方切斷。務(wù)必調(diào)整separators參數(shù)優(yōu)先按中文句號(hào)、換行等分割。另外Chroma的持久化有時(shí)在頻繁寫入后加載會(huì)出問(wèn)題生產(chǎn)環(huán)境建議用更穩(wěn)定的Qdrant或PGVector。4.2 使用LlamaIndex構(gòu)建RAG流水線LlamaIndex原名GPT Index更專注于數(shù)據(jù)索引和檢索提供了更精細(xì)的索引結(jié)構(gòu)和查詢接口對(duì)復(fù)雜查詢支持更好。環(huán)境準(zhǔn)備pip install llama-index llama-index-embeddings-openai llama-index-vector-stores-chroma pypdf步驟一文檔加載與索引創(chuàng)建from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, StorageContext from llama_index.vector_stores.chroma import ChromaVectorStore from llama_index.embeddings.openai import OpenAIEmbedding import chromadb # 1. 加載文檔 documents SimpleDirectoryReader(input_dir./data).load_data() # 假設(shè)PDF在./data目錄 # 2. 初始化嵌入模型和向量存儲(chǔ) embed_model OpenAIEmbedding(modeltext-embedding-3-small) chroma_client chromadb.PersistentClient(path./chroma_db_llama) chroma_collection chroma_client.get_or_create_collection(tech_docs) vector_store ChromaVectorStore(chroma_collectionchroma_collection) storage_context StorageContext.from_defaults(vector_storevector_store) # 3. 創(chuàng)建索引 index VectorStoreIndex.from_documents( documents, embed_modelembed_model, storage_contextstorage_context, show_progressTrue )步驟二配置查詢引擎并提問(wèn)LlamaIndex的強(qiáng)大之處在于其靈活的查詢引擎。from llama_index.core import Settings from llama_index.llms.openai import OpenAI # 配置全局LLM和Embedding這里L(fēng)LM換成DeepSeek兼容接口示例 # 注意需要確保有兼容OpenAI的DeepSeek LLM類或使用llama_index.llms.openai_like.OpenAILike from llama_index.llms.openai_like import OpenAILike llm OpenAILike( modeldeepseek-chat, api_basehttps://api.deepseek.com/v1, api_keyyour_key, is_chat_modelTrue, temperature0.1 ) Settings.llm llm Settings.embed_model embed_model # 創(chuàng)建基礎(chǔ)查詢引擎 query_engine index.as_query_engine( similarity_top_k5, # 檢索5個(gè)塊 response_modecompact # 生成模式“compact”會(huì)盡量壓縮上下文“refine”會(huì)迭代精煉 ) # 進(jìn)行查詢 response query_engine.query(請(qǐng)總結(jié)一下文檔中提到的安全注意事項(xiàng)。) print(response.response) print(\n 來(lái)源節(jié)點(diǎn) ) for node in response.source_nodes: print(f文本片段: {node.text[:200]}...) print(f相似度得分: {node.score:.4f}) print(---)步驟三實(shí)現(xiàn)高級(jí)查詢——帶重排序和元數(shù)據(jù)過(guò)濾from llama_index.core.postprocessor import SentenceTransformerRerank from llama_index.core.vector_stores import MetadataFilter, FilterCondition # 1. 創(chuàng)建重排序器 rerank SentenceTransformerRerank(modelBAAI/bge-reranker-large, top_n3) # 從top-10中重排選出top-3 # 2. 創(chuàng)建帶過(guò)濾的檢索器 from llama_index.core import VectorStoreIndex index VectorStoreIndex.from_vector_store(vector_store) # 從已有存儲(chǔ)加載 # 假設(shè)我們的文檔塊有 metadata{category: safety} from llama_index.core.vector_stores import MetadataFilters, ExactMatchFilter filters MetadataFilters( filters[ ExactMatchFilter(keycategory, valuesafety) # 只檢索category為safety的文檔 ] ) # 3. 組裝高級(jí)查詢引擎 query_engine index.as_query_engine( similarity_top_k10, node_postprocessors[rerank], # 應(yīng)用重排序 filtersfilters, # 應(yīng)用元數(shù)據(jù)過(guò)濾 verboseTrue # 打印詳細(xì)過(guò)程 ) response query_engine.query(安全注意事項(xiàng)里關(guān)于密碼管理的具體規(guī)定是什么)LlamaIndex將檢索、后處理、生成等模塊解耦得很清晰方便你像搭積木一樣組合高級(jí)功能比如上面就組合了元數(shù)據(jù)過(guò)濾和重排序。5. RAG系統(tǒng)常見(jiàn)問(wèn)題排查與效果調(diào)優(yōu)指南即使搭建好了流水線你可能會(huì)發(fā)現(xiàn)答案質(zhì)量不盡如人意。別急RAG的調(diào)優(yōu)是一個(gè)系統(tǒng)工程。我們可以按照“檢索-增強(qiáng)-生成”的鏈路來(lái)逐一排查。5.1 檢索階段的問(wèn)題與優(yōu)化問(wèn)題1檢索不到相關(guān)文檔低召回率可能原因1分塊策略不當(dāng)。塊太大包含無(wú)關(guān)信息稀釋了核心語(yǔ)義塊太小關(guān)鍵信息被切碎。排查檢查檢索到的Top-K個(gè)塊看它們是否真的與問(wèn)題相關(guān)?？梢匀斯?biāo)注一批問(wèn)題-相關(guān)文檔對(duì)作為測(cè)試集。優(yōu)化嘗試不同的分塊大小和重疊。對(duì)于結(jié)構(gòu)化工件API文檔、手冊(cè)嘗試按標(biāo)題/章節(jié)分塊。使用語(yǔ)義分塊工具。可能原因2嵌入模型不匹配。使用的嵌入模型對(duì)特定領(lǐng)域如醫(yī)療、法律或語(yǔ)言如專業(yè)中文術(shù)語(yǔ)理解不佳。排查用一些同義詞或相關(guān)術(shù)語(yǔ)測(cè)試看模型是否能將它們映射到相近的向量。例如“深度學(xué)習(xí)”和“深度神經(jīng)網(wǎng)絡(luò)”在向量空間是否接近。優(yōu)化換用領(lǐng)域適配的嵌入模型。在中文場(chǎng)景BGE-large-zh或M3E通常比通用英文模型好。對(duì)于極專業(yè)領(lǐng)域可以考慮用領(lǐng)域數(shù)據(jù)對(duì)開源嵌入模型進(jìn)行微調(diào)?？赡茉?查詢表述與文檔表述差異大。優(yōu)化實(shí)施查詢擴(kuò)展。用LLM生成3-5個(gè)問(wèn)題的不同問(wèn)法一起用于檢索?；蛘呤褂肏yDE技術(shù)讓LLM先根據(jù)問(wèn)題生成一個(gè)假設(shè)性答案然后用這個(gè)假設(shè)答案的向量去檢索有時(shí)能更好地匹配文檔語(yǔ)言風(fēng)格。問(wèn)題2檢索到的文檔不精準(zhǔn)低準(zhǔn)確率可能原因1缺少元數(shù)據(jù)過(guò)濾。檢索到了相關(guān)但來(lái)源不對(duì)的文檔例如從舊版本手冊(cè)中檢索到了信息。優(yōu)化在存入向量數(shù)據(jù)庫(kù)時(shí)盡可能豐富元數(shù)據(jù)文件來(lái)源、更新時(shí)間、章節(jié)、類型等。檢索時(shí)結(jié)合元數(shù)據(jù)過(guò)濾?？赡茉?單純向量檢索的局限性。優(yōu)化引入混合檢索。結(jié)合BM25等關(guān)鍵詞檢索方法。在Qdrant中可以設(shè)置sparse_vector并配置混合搜索權(quán)重?？赡茉?返回的Top-K中混入了不相關(guān)文檔。優(yōu)化引入重排序。用交叉編碼器模型對(duì)初步檢索結(jié)果進(jìn)行精排。雖然增加了一點(diǎn)延遲但對(duì)最終答案質(zhì)量提升顯著。可以將similarity_top_k設(shè)大一點(diǎn)如20然后用重排序模型選出最相關(guān)的3-5個(gè)。5.2 生成階段的問(wèn)題與優(yōu)化問(wèn)題3答案出現(xiàn)幻覺(jué)編造了上下文沒(méi)有的信息可能原因1Prompt指令不夠強(qiáng)硬。模型忽略了“僅根據(jù)上下文”的指令。優(yōu)化強(qiáng)化Prompt。使用更嚴(yán)厲的措辭例如“你必須且只能使用以下上下文中的信息。上下文未提及的內(nèi)容一律回答‘我不知道’?！?可以在Prompt中提供遵循指令和違反指令的示例少樣本學(xué)習(xí)?？赡茉?上下文信息過(guò)多或噪聲大。LLM的注意力被不相關(guān)的信息干擾。優(yōu)化優(yōu)化檢索確保Top-K的文檔高度相關(guān)。在構(gòu)造上下文時(shí)可以只取每個(gè)檢索文檔塊中最相關(guān)的幾個(gè)句子而不是整個(gè)塊?；蛘呤褂肕ap-Reduce等鏈?zhǔn)椒椒ㄏ茸孡LM分別總結(jié)每個(gè)文檔塊再基于總結(jié)生成最終答案?？赡茉?LLM本身幻覺(jué)傾向強(qiáng)。優(yōu)化換用已知幻覺(jué)較少的模型。目前Claude系列和GPT-4在遵循指令和減少幻覺(jué)方面表現(xiàn)較好。DeepSeek在指令遵循上也做了大量?jī)?yōu)化。也可以嘗試降低temperature參數(shù)如0.1讓輸出更確定性。問(wèn)題4答案未能有效利用上下文像在自說(shuō)自話可能原因模型沒(méi)有“注意到”上下文中的關(guān)鍵信息。優(yōu)化在Prompt中顯式要求“引用”。例如“請(qǐng)根據(jù)上下文回答并在答案中引用上下文的具體描述例如‘根據(jù)第一段…’”?；蛘呤褂靡锰崾炯夹g(shù)在拼接上下文時(shí)在每個(gè)文檔塊前加上明顯的引用標(biāo)識(shí)如[1],[2]并要求模型在答案中標(biāo)注引用來(lái)源。問(wèn)題5答案冗長(zhǎng)或格式不符合要求可能原因Prompt中對(duì)答案格式和長(zhǎng)度沒(méi)有明確約束。優(yōu)化在Prompt中指定格式。例如“請(qǐng)用不超過(guò)三句話的要點(diǎn)形式總結(jié)。”“請(qǐng)以表格形式列出…”“請(qǐng)先給出是或否的判斷再解釋原因。”5.3 系統(tǒng)性評(píng)估與迭代調(diào)優(yōu)不是盲目的需要建立一個(gè)評(píng)估-迭代的循環(huán)。構(gòu)建黃金測(cè)試集收集50-100個(gè)真實(shí)用戶可能問(wèn)的問(wèn)題并人工標(biāo)注標(biāo)準(zhǔn)答案和對(duì)應(yīng)的支撐文檔Ground Truth。建立自動(dòng)化評(píng)估流水線使用RAGAS或類似框架針對(duì)忠實(shí)度、答案相關(guān)性等指標(biāo)對(duì)每個(gè)RAG系統(tǒng)版本進(jìn)行批量測(cè)試和打分。A/B測(cè)試如果你有線上系統(tǒng)可以將不同優(yōu)化方案如新的分塊策略、新的嵌入模型部署為不同版本將一小部分流量導(dǎo)過(guò)去對(duì)比關(guān)鍵業(yè)務(wù)指標(biāo)如用戶滿意度、問(wèn)題解決率。監(jiān)控與反饋在生產(chǎn)環(huán)境記錄用戶的每次提問(wèn)、檢索到的文檔、生成的答案。設(shè)計(jì)用戶反饋機(jī)制如“答案是否有用”按鈕。這些數(shù)據(jù)是持續(xù)優(yōu)化最寶貴的資源。RAG系統(tǒng)的構(gòu)建是一個(gè)持續(xù)迭代的過(guò)程沒(méi)有一勞永逸的“最佳配置”。核心在于建立一套從數(shù)據(jù)準(zhǔn)備、檢索優(yōu)化、提示工程到效果評(píng)估的完整方法論并能根據(jù)實(shí)際反饋和數(shù)據(jù)不斷調(diào)整每個(gè)環(huán)節(jié)的參數(shù)與策略。從簡(jiǎn)單的文檔問(wèn)答出發(fā)逐步擴(kuò)展到支持多輪對(duì)話、復(fù)雜推理、多模態(tài)檢索的智能知識(shí)系統(tǒng)這才是RAG技術(shù)真正的魅力所在。