1. 項目概述為什么RAG知識庫搭建是個精細(xì)活兒最近和幾個做AI應(yīng)用的朋友聊天發(fā)現(xiàn)大家一提到RAG檢索增強生成眼睛都放光覺得這是讓大模型“說真話”、解決幻覺問題的銀彈。但真上手去搭一個從爬數(shù)據(jù)開始到最終能穩(wěn)定、準(zhǔn)確地回答用戶問題中間踩的坑能寫滿一本錯題集。這個項目標(biāo)題“從零搭建 RAG 知識庫爬蟲→分詞→向量化→檢索一步都不能錯”可以說精準(zhǔn)地戳中了所有實踐者的痛點。它不是一個簡單的流程串聯(lián)而是一個環(huán)環(huán)相扣、每一步都充滿技術(shù)選型和細(xì)節(jié)打磨的系統(tǒng)工程。我自己在搭建企業(yè)內(nèi)部知識庫、行業(yè)資訊分析系統(tǒng)時反復(fù)驗證過這個流程。RAG的核心價值在于為LLM提供一個精準(zhǔn)、可靠的外部知識“記憶體”。但這個記憶體的質(zhì)量直接決定了最終回答的靠譜程度。你可以把整個過程想象成給一位博聞強識但記憶模糊的學(xué)者LLM建造一個私人圖書館。爬蟲是采購員負(fù)責(zé)從各處搜集書籍?dāng)?shù)據(jù)分詞和向量化是圖書管理員負(fù)責(zé)給書籍編目、貼標(biāo)簽、做摘要把非結(jié)構(gòu)化的文本變成機器能理解的索引卡片檢索則是學(xué)者的助手當(dāng)學(xué)者被問到問題時助手能快速從海量索引卡片中找到最相關(guān)的那幾本遞給學(xué)者參考。這個鏈條里任何一環(huán)的粗糙處理都會導(dǎo)致“垃圾進(jìn)垃圾出”。爬蟲抓得不全或格式混亂后續(xù)處理就無從談起分詞分得不好語義被割裂向量化就成了“歪曲事實”向量模型選得不對或者索引建得不好檢索召回的就是一堆不相關(guān)的文檔最后即使召回了如果排序策略不行最關(guān)鍵的答案也可能被埋沒在噪音里。所以標(biāo)題強調(diào)“一步都不能錯”絕非危言聳聽而是血淚教訓(xùn)的總結(jié)。接下來我就結(jié)合實戰(zhàn)把這四步拆開揉碎了講清楚尤其是那些容易踩坑、文檔里不會寫的細(xì)節(jié)。2. 第一步爬蟲——數(shù)據(jù)源的“清潔度”決定天花板很多人覺得爬蟲就是requests加BeautifulSoup把HTML拖下來就完事了。但在RAG的語境下爬蟲的目標(biāo)不是“抓到數(shù)據(jù)”而是“抓到干凈、結(jié)構(gòu)化的高質(zhì)量文本數(shù)據(jù)”。你的下游所有工序都在為這一步的成果買單。2.1 爬蟲策略與工具選型不只是Python提到爬蟲第一反應(yīng)是Python的Scrapy或requestsparsel組合。這沒錯但對于RAG項目我們需要更全面地考慮靜態(tài)頁面對于新聞網(wǎng)站、博客、文檔站如許多開源項目的Docsrequests/httpx配合BeautifulSoup或parsel速度更快是經(jīng)典選擇。重點在于編寫健壯的CSS選擇器或XPath并處理好編碼問題。import httpx from parsel import Selector async def fetch_page(url): async with httpx.AsyncClient(timeout10.0, follow_redirectsTrue) as client: try: resp await client.get(url, headers{User-Agent: Mozilla/5.0 ...}) resp.raise_for_status() return resp.text except Exception as e: print(fFailed to fetch {url}: {e}) return None def parse_content(html): selector Selector(texthtml) # 核心精準(zhǔn)定位正文剔除導(dǎo)航、廣告、評論、頁腳 main_content selector.css(article .post-content ::text).getall() # 示例選擇器 # 更通用的策略通過標(biāo)簽密度、聚類算法識別正文區(qū)域 text .join([txt.strip() for txt in main_content if txt.strip()]) return text注意不要依賴單一的標(biāo)簽選擇器。不同網(wǎng)站結(jié)構(gòu)千差萬別。一個實戰(zhàn)技巧是使用readability庫或trafilatura這類專門用于正文提取的工具它們通過算法識別網(wǎng)頁核心內(nèi)容區(qū)域成功率遠(yuǎn)高于手寫規(guī)則。動態(tài)渲染頁面越來越多的網(wǎng)站如單頁應(yīng)用SPA內(nèi)容由JavaScript動態(tài)加載。這時requests只能拿到空殼。解決方案是Selenium/Playwright模擬瀏覽器行為功能強大但重量級適合復(fù)雜交互如登錄、點擊。資源消耗大不適合大規(guī)模爬取。Pyppeteer/Puppeteer (Node.js)無頭Chrome控制庫比Selenium更輕量高效。逆向工程API最高效的方法。打開瀏覽器開發(fā)者工具F12切換到Network網(wǎng)絡(luò)標(biāo)簽刷新頁面觀察XHR/Fetch請求。直接找到數(shù)據(jù)接口用requests模擬調(diào)用。這需要一些耐心但一旦成功速度和穩(wěn)定性極佳。特定平臺爬蟲如微信公眾號、小紅書、抖音等。這些平臺反爬嚴(yán)格通常需要模擬登錄獲取Cookie或Token。調(diào)用官方或非官方API有些平臺有未公開的移動端API通過抓包分析獲得。使用現(xiàn)成的SDK或工具例如wechatpy微信、inscrapperInstagram等但要注意合規(guī)性和穩(wěn)定性。重要提示爬取此類數(shù)據(jù)務(wù)必嚴(yán)格遵守robots.txt協(xié)議和平臺用戶協(xié)議評估法律風(fēng)險僅用于個人學(xué)習(xí)研究且控制請求頻率避免對目標(biāo)服務(wù)器造成壓力。2.2 數(shù)據(jù)清洗與標(biāo)準(zhǔn)化容易被忽視的“臟活”爬下來的原始文本通常包含大量噪音直接丟給分詞模型會嚴(yán)重影響后續(xù)效果。去除無關(guān)元素HTML/JS/CSS標(biāo)簽用BeautifulSoup.get_text()或正則表達(dá)式徹底清除。廣告、推薦閱讀、版權(quán)聲明通過常見的文本模式如“猜你喜歡”、“相關(guān)閱讀”、“Copyright”進(jìn)行過濾。導(dǎo)航欄、頁眉頁腳在解析階段就應(yīng)剔除。特殊字符和亂碼使用unicodedata.normalize()進(jìn)行Unicode規(guī)范化并用正則過濾非目標(biāo)語言的字符集。文本規(guī)范化統(tǒng)一編碼確保全部文本為UTF-8。全角轉(zhuǎn)半角中文環(huán)境下將全角字母、數(shù)字、符號轉(zhuǎn)換為半角保證一致性。日期、數(shù)字格式標(biāo)準(zhǔn)化將“2023年12月1日”、“2023-12-01”、“12/1/2023”統(tǒng)一為一種格式便于后續(xù)可能的信息抽取。去除多余空白將連續(xù)的換行符、空格、制表符壓縮為單個空格或標(biāo)準(zhǔn)段落分隔。質(zhì)量過濾長度過濾剔除過短如少于20字符的文本塊這可能是導(dǎo)航碎片或廣告。語言檢測如果你的知識庫只針對中文使用langdetect庫過濾掉非中文內(nèi)容。去重對高度相似或完全相同的文本進(jìn)行去重避免在向量庫中引入冗余。可以使用SimHash或MinHash算法進(jìn)行近似去重。實操心得建立一個可配置的清洗管道Pipeline至關(guān)重要。我為每個數(shù)據(jù)源定義了一套清洗規(guī)則并保存清洗前的原始文本和清洗后的版本方便回溯和調(diào)試。清洗效果直接影響分詞和嵌入的質(zhì)量這里多花一天時間后面能省下一周的調(diào)試功夫。3. 第二步文本分詞與切片——如何讓機器“讀懂”段落清洗后的文本是連續(xù)的字符串我們需要將其切割成適合向量化和檢索的片段Chunks。這一步直接決定了檢索的粒度。3.1 分詞Word Segmentation與分句對于中文RAG分詞是基礎(chǔ)。但這里的“分詞”更多指的是為后續(xù)的語義切片做準(zhǔn)備而不是簡單的詞語切分。工具選擇Jieba最常用的中文分詞庫速度快自定義詞典功能強大。適合作為基礎(chǔ)分詞器。HanLP功能更全面除了基礎(chǔ)分詞還提供詞性標(biāo)注、命名實體識別NER、依存句法分析等。在Spring Boot等Java生態(tài)中集成良好如hanlp-spring-boot-starter。如果你的知識庫涉及大量實體人名、地名、機構(gòu)名、專業(yè)術(shù)語HanLP的NER能幫你更好地識別和保留關(guān)鍵信息。PKUSeg、LTP北大和哈工大的工具在學(xué)術(shù)文本上分詞準(zhǔn)確率較高。大模型分詞使用ChatGLM、Qwen等模型的tokenizer進(jìn)行分詞可以保證與后續(xù)使用的LLM在詞匯表上對齊但速度較慢適合對齊要求高的場景。# 使用Jieba進(jìn)行基礎(chǔ)分詞和關(guān)鍵詞提取 import jieba import jieba.analyse text 這是一段關(guān)于人工智能技術(shù)的示例文本。 # 精確模式分詞 words jieba.lcut(text, cut_allFalse) # 提取TF-IDF關(guān)鍵詞 keywords jieba.analyse.extract_tags(text, topK5, withWeightFalse) # 使用TextRank算法提取關(guān)鍵詞 keywords_tr jieba.analyse.textrank(text, topK5, withWeightFalse)分句Sentence Splitting將文本按句號、問號、感嘆號等分割成獨立的句子。這是更細(xì)粒度的切片基礎(chǔ)。可以使用簡單的正則也可以使用更智能的庫如pysbd適用于多種語言。3.2 知識切片Chunking策略核心中的核心這是RAG項目成敗的關(guān)鍵技術(shù)點之一。切片太大會引入無關(guān)噪聲降低檢索精度切片太小會丟失上下文導(dǎo)致語義不完整。固定長度重疊切片最常用、最穩(wěn)定的方法。使用字符數(shù)或token數(shù)作為窗口大小并設(shè)置一個重疊區(qū)域overlap以保持上下文連貫。from langchain.text_splitter import RecursiveCharacterTextSplitter # LangChain提供的遞歸字符文本分割器效果很好 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 目標(biāo)塊大小字符數(shù) chunk_overlap50, # 塊之間的重疊字符數(shù) length_functionlen, separators[\n\n, \n, 。, , , , ] # 按此優(yōu)先級嘗試分割 ) chunks text_splitter.split_text(long_text)chunk_size選擇一般建議在256-1024個字符或tokens之間。需要權(quán)衡較小的size如256檢索更精準(zhǔn)但可能信息不全較大的size如1024信息完整但可能包含無關(guān)內(nèi)容。一個經(jīng)驗是讓你的塊大小大致等于你期望LLM在生成答案時參考的上下文長度。chunk_overlap選擇通常為chunk_size的10%-20%。重疊是為了防止一個完整的句子或概念被生硬地切到兩個塊中導(dǎo)致檢索時只召回一半?；谡Z義的切片更高級的方法試圖在語義邊界如段落、章節(jié)處進(jìn)行切割?？梢允褂米匀粩帱c優(yōu)先在\n\n空行、標(biāo)題標(biāo)記#、##、p標(biāo)簽等處切割。語義分割模型使用預(yù)訓(xùn)練模型判斷哪里是自然的語義邊界。這更智能但計算成本高且模型本身可能引入誤差?；旌锨衅琀ybrid Chunking對于結(jié)構(gòu)清晰的文檔如PDF、Markdown采用分層切片。先按章節(jié)/標(biāo)題切大塊再在大塊內(nèi)按固定長度切小塊。為每個塊保留其層級信息如{“chapter”: “3”, “section”: “3.1”, “content”: “...”}檢索時可以利用層級進(jìn)行過濾或加權(quán)。注意事項不要破壞表格和代碼對于技術(shù)文檔表格和代碼塊應(yīng)被視為一個整體不應(yīng)被切開。需要在分割前進(jìn)行預(yù)處理將這些部分標(biāo)記并保護(hù)起來。保留元數(shù)據(jù)為每個切片chunk附加來源信息如URL、文件名、標(biāo)題、時間戳、作者等。這些元數(shù)據(jù)在后續(xù)檢索和結(jié)果展示中非常有用。測試你的切片隨機抽樣一些切片人工閱讀檢查其語義是否完整重疊是否合理。這是調(diào)試切片策略最直接有效的方法。4. 第三步向量化嵌入——將文本映射到語義空間向量化也叫嵌入Embedding是把文本切片轉(zhuǎn)換成高維空間中的向量一組數(shù)字。語義相似的文本其向量在空間中的距離如余弦相似度也相近。這是實現(xiàn)語義檢索的數(shù)學(xué)基礎(chǔ)。4.1 嵌入模型選型開源與閉源的權(quán)衡開源模型本地部署B(yǎng)GEBAAI General Embedding系列智源研究院出品如BGE-large-zh、BGE-small-zh在中文語義相似度任務(wù)上表現(xiàn)SOTA最先進(jìn)且針對檢索任務(wù)進(jìn)行了優(yōu)化。這是目前中文RAG項目的首選。Sentence-BERTSBERT有中文變體paraphrase-multilingual-MiniLM-L12-v2在多語言場景下表現(xiàn)穩(wěn)健。M3E系列專門為中文優(yōu)化的嵌入模型在部分中文評測集上表現(xiàn)不錯。開源模型優(yōu)勢數(shù)據(jù)隱私安全、可離線運行、定制化微調(diào)、無調(diào)用費用。劣勢需要本地GPU或CPU資源推理速度取決于硬件模型管理需要自行負(fù)責(zé)。閉源API在線服務(wù)OpenAItext-embedding-3系列性能強大且穩(wěn)定使用簡單。百度文心、阿里通義、智譜ChatGLM等國內(nèi)廠商的嵌入API符合數(shù)據(jù)合規(guī)要求。API優(yōu)勢免運維性能穩(wěn)定隨模型升級自動更新。劣勢有調(diào)用成本和數(shù)據(jù)出境風(fēng)險對于國外API存在網(wǎng)絡(luò)延遲和速率限制。選型建議對于企業(yè)內(nèi)部或?qū)?shù)據(jù)安全要求高的項目優(yōu)先選擇BGE這類優(yōu)秀的開源模型在本地部署。對于快速原型驗證或中小規(guī)模應(yīng)用可以考慮國內(nèi)大廠的嵌入API。一個折中方案是用開源模型處理核心敏感數(shù)據(jù)用API處理非敏感或公開數(shù)據(jù)。4.2 嵌入實踐與優(yōu)化批量處理與性能調(diào)用嵌入模型是耗時的。務(wù)必使用批量推理batch inference來提升效率。from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(BAAI/bge-large-zh-v1.5) # 準(zhǔn)備文本列表 texts [段落1, 段落2, ...] # 批量編碼指定batch_size embeddings model.encode(texts, batch_size32, normalize_embeddingsTrue, show_progress_barTrue) # embeddings 是一個 numpy 數(shù)組 shape 為 (文本數(shù), 向量維度)normalize_embeddingsTrue將向量歸一化為單位向量。強烈建議開啟這樣后續(xù)計算余弦相似度就簡化為點積np.dot(a,b)計算更快且余弦相似度范圍在[-1,1]或[0,1]歸一化后。向量維度不同模型的輸出維度不同如BGE-large是1024維OpenAI text-embedding-3-small是1536維。這會影響向量數(shù)據(jù)庫的存儲和檢索效率但通常更高維度的模型表征能力更強。選擇時需權(quán)衡效果和成本。指令微調(diào)模型的使用像BGE這類為檢索優(yōu)化的模型通常經(jīng)過了指令微調(diào)。這意味著在編碼查詢query時需要添加指令前綴而在編碼被檢索的文檔passage時則不需要或使用不同的前綴以達(dá)到最佳效果。# 對于BGE模型 query 什么是機器學(xué)習(xí) passages [機器學(xué)習(xí)是人工智能的一個分支..., 深度學(xué)習(xí)是機器學(xué)習(xí)的一種...] # 編碼查詢時添加指令 query_embedding model.encode([f為這個句子生成表示以用于檢索相關(guān)文章{query}], normalize_embeddingsTrue) # 編碼文檔時不需要或使用其他指令具體看模型說明 passage_embeddings model.encode(passages, normalize_embeddingsTrue)務(wù)必查閱所用模型的官方文檔或Hugging Face頁面了解其推薦的編碼方式這是發(fā)揮模型性能的關(guān)鍵。5. 第四步檢索與排序——從海量向量中精準(zhǔn)定位有了高質(zhì)量的向量下一步就是建立索引并實現(xiàn)快速準(zhǔn)確的檢索。檢索系統(tǒng)通常分為“召回”Recall和“排序”Rerank兩步。5.1 向量數(shù)據(jù)庫選型與索引構(gòu)建向量數(shù)據(jù)庫負(fù)責(zé)高效存儲向量并提供近似最近鄰ANN搜索。選型考慮因素性能、易用性、社區(qū)生態(tài)、云服務(wù)支持。數(shù)據(jù)庫特點適用場景Milvus功能全面性能強勁生態(tài)豐富支持標(biāo)量過濾、動態(tài)Schema。大規(guī)模、高并發(fā)生產(chǎn)環(huán)境需要復(fù)雜過濾和混合搜索。Chroma輕量級API簡單與LangChain集成極佳入門快。原型開發(fā)、小規(guī)模項目、快速驗證想法。QdrantRust編寫性能好支持豐富的數(shù)據(jù)類型和過濾條件有云服務(wù)。對性能和過濾有較高要求的生產(chǎn)環(huán)境。PGVectorPostgreSQL的擴展利用現(xiàn)有PG生態(tài)支持ACID。已在使用PostgreSQL希望簡化技術(shù)棧。Weaviate集成了向量、圖、關(guān)鍵詞搜索自帶模塊化設(shè)計。需要結(jié)合多種搜索方式或圖關(guān)系的復(fù)雜應(yīng)用。以Milvus為例的索引構(gòu)建流程連接與集合Collection創(chuàng)建定義集合的Schema包括向量字段和元數(shù)據(jù)字段如id、text、source等。選擇索引類型常用的有IVF_FLAT平衡精度與速度、HNSW高召回率高速度內(nèi)存占用大、SCANN磁盤索引內(nèi)存占用小。對于中等規(guī)模數(shù)據(jù)百萬級IVF_FLAT是不錯的選擇。插入數(shù)據(jù)將文本切片、其對應(yīng)的向量和元數(shù)據(jù)批量插入集合。加載集合在搜索前需要將集合加載到內(nèi)存。from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType # 1. 連接 connections.connect(hostlocalhost, port19530) # 2. 定義Schema fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue, auto_idTrue), FieldSchema(nametext, dtypeDataType.VARCHAR, max_length65535), FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim1024), # 維度與模型匹配 FieldSchema(namesource, dtypeDataType.VARCHAR, max_length255), ] schema CollectionSchema(fields, description知識庫文檔集合) # 3. 創(chuàng)建集合 collection_name rag_knowledge_base collection Collection(namecollection_name, schemaschema) # 4. 創(chuàng)建索引 index_params { index_type: IVF_FLAT, metric_type: IP, # 內(nèi)積因為我們的向量是歸一化的內(nèi)積余弦相似度 params: {nlist: 1024} # 聚類中心數(shù)值越大搜索越準(zhǔn)越慢通常取 sqrt(數(shù)據(jù)量) } collection.create_index(field_nameembedding, index_paramsindex_params) # 5. 插入數(shù)據(jù)假設(shè)chunks是文本列表embeddings是向量列表metas是元數(shù)據(jù)列表 data [ chunks, # 文本 embeddings.tolist(), # 向量轉(zhuǎn)為list [meta[source] for meta in metas] # 元數(shù)據(jù)例如來源 ] collection.insert(data) collection.load() # 加載到內(nèi)存5.2 多路召回與混合檢索單一的向量檢索語義檢索有時會漏掉一些關(guān)鍵詞匹配但語義稍遠(yuǎn)的文檔。因此工業(yè)級RAG系統(tǒng)常采用“多路召回”策略。向量檢索語義召回如上所述利用余弦相似度查找語義最接近的片段。關(guān)鍵詞檢索稀疏召回使用BM25、TF-IDF等算法。它更注重關(guān)鍵詞的精確匹配能有效召回那些包含查詢關(guān)鍵詞但語義嵌入可能不近的文檔例如包含特定產(chǎn)品型號、錯誤代碼、人名。BM25是TF-IDF的改進(jìn)版考慮了文檔長度歸一化效果更好?？梢允褂胷ank_bm25庫實現(xiàn)。from rank_bm25 import BM25Okapi import jieba # 準(zhǔn)備語料庫分好詞的文檔列表 tokenized_corpus [list(jieba.cut(doc)) for doc in chunks] bm25 BM25Okapi(tokenized_corpus) # 對查詢進(jìn)行分詞和檢索 query 如何解決網(wǎng)絡(luò)連接超時 tokenized_query list(jieba.cut(query)) doc_scores bm25.get_scores(tokenized_query) top_keyword_indices np.argsort(doc_scores)[::-1][:10] # 取BM25分?jǐn)?shù)最高的10個混合檢索Hybrid Search將向量檢索和關(guān)鍵詞檢索的結(jié)果融合。最簡單的方法是加權(quán)求和Reciprocal Rank Fusion, RRF 是更魯棒的方法。def hybrid_search(query, vector_collection, bm25_index, tokenized_corpus, top_k10, alpha0.5): # 1. 向量檢索 query_embedding model.encode([f為這個句子生成表示以用于檢索相關(guān)文章{query}]) vector_results vector_collection.search(query_embedding, anns_fieldembedding, param{nprobe: 10}, limittop_k) vector_ids [hit.id for hit in vector_results[0]] vector_scores [hit.score for hit in vector_results[0]] # 2. 關(guān)鍵詞檢索 tokenized_query list(jieba.cut(query)) bm25_scores bm25_index.get_scores(tokenized_query) top_bm25_indices np.argsort(bm25_scores)[::-1][:top_k] # 3. 融合簡單加權(quán)實際可用RRF fused_scores {} # 為向量檢索結(jié)果賦分 for vid, vscore in zip(vector_ids, vector_scores): fused_scores[vid] alpha * vscore # 為BM25檢索結(jié)果賦分需歸一化到與向量分?jǐn)?shù)相近的范圍 max_bm25 max(bm25_scores) if max(bm25_scores) 0 else 1 for idx in top_bm25_indices: normalized_score bm25_scores[idx] / max_bm25 fused_scores[idx] fused_scores.get(idx, 0) (1 - alpha) * normalized_score # 4. 按融合分?jǐn)?shù)排序 sorted_items sorted(fused_scores.items(), keylambda x: x[1], reverseTrue) final_ids [item[0] for item in sorted_items[:top_k]] return final_idsalpha參數(shù)控制語義檢索和關(guān)鍵詞檢索的權(quán)重通常需要在一個驗證集上調(diào)試。5.3 重排序Reranking提升精度的最后一道關(guān)卡召回Recall階段我們可能找回了100個相關(guān)文檔但其中真正有用的可能只有前5個。重排序的目標(biāo)是利用一個更精細(xì)的模型通常是交叉編碼器Cross-Encoder對召回的Top N個結(jié)果進(jìn)行兩兩比較或與查詢進(jìn)行精細(xì)匹配重新打分排序?qū)⒆钕嚓P(guān)的結(jié)果推到最前面。為什么需要重排序用于召回的向量模型雙編碼器Bi-Encoder為了效率將查詢和文檔獨立編碼損失了一些交互信息。而交叉編碼器將查詢和文檔同時輸入模型進(jìn)行深度的注意力交互判斷相關(guān)性更準(zhǔn)確但速度慢只適合對少量候選進(jìn)行精排。重排序模型BGE-Reranker智源推出的中文重排序模型與BGE嵌入模型是絕配。Sentence-BERT Cross-Encoder也有多語言版本。from FlagEmbedding import FlagReranker reranker FlagReranker(BAAI/bge-reranker-large, use_fp16True) # 使用FP16加速 query 如何配置Python虛擬環(huán)境 retrieved_docs [文檔A的文本..., 文檔B的文本..., ...] # 從召回階段獲得 # 準(zhǔn)備 (query, document) 對 pairs [(query, doc) for doc in retrieved_docs] # 計算相關(guān)性分?jǐn)?shù) scores reranker.compute_score(pairs) # 返回一個分?jǐn)?shù)列表 # 根據(jù)分?jǐn)?shù)對retrieved_docs重新排序 reranked_indices np.argsort(scores)[::-1] final_docs [retrieved_docs[i] for i in reranked_indices]重排序的位置在混合召回得到Top K例如K50個候選文檔后使用重排序模型對這50個文檔進(jìn)行精排選出最終的Top M例如M5個文檔送入LLM生成答案。6. 全鏈路集成與效果調(diào)優(yōu)將以上四個模塊串聯(lián)起來就形成了一個完整的RAG流水線。但搭建完成只是開始持續(xù)的調(diào)優(yōu)才是讓系統(tǒng)變得好用的關(guān)鍵。6.1 流水線搭建與框架選擇你可以完全從零手寫這個流水線但對于快速開發(fā)和維護(hù)使用框架是更明智的選擇。LangChain/LlamaIndex這兩個是當(dāng)前最流行的RAG應(yīng)用框架。LangChain更像一個“膠水”框架提供了豐富的組件Document Loaders, Text Splitters, Vector Stores, Retrievers, Chains靈活性極高你可以自由組合。學(xué)習(xí)曲線稍陡但能深度定制。LlamaIndex更專注于RAG和數(shù)據(jù)索引提供了更高級的檢索抽象如索引、查詢引擎開箱即用的體驗更好對復(fù)雜查詢帶過濾、匯總支持更友好。選擇建議如果你需要高度定制化或者你的應(yīng)用邏輯非常復(fù)雜LangChain可能更適合。如果你希望快速構(gòu)建一個標(biāo)準(zhǔn)且高效的RAG系統(tǒng)LlamaIndex可能更省心。核心流程代碼示意以LangChain為例from langchain_community.document_loaders import WebBaseLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_huggingface import HuggingFaceEmbeddings from langchain_community.vectorstores import Milvus from langchain.chains import RetrievalQA from langchain_community.llms import ChatGLM # 示例可用其他LLM # 1. 加載文檔 loader WebBaseLoader(https://example.com/doc) documents loader.load() # 2. 分割文本 text_splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) docs text_splitter.split_documents(documents) # 3. 嵌入并存入向量庫 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-large-zh-v1.5) vector_store Milvus.from_documents( docs, embeddings, connection_args{host: localhost, port: 19530}, collection_namemy_rag_collection ) retriever vector_store.as_retriever(search_kwargs{k: 5}) # 創(chuàng)建檢索器 # 4. 構(gòu)建QA鏈 llm ChatGLM(endpoint_urlhttp://localhost:8000, max_tokens2048) qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 還有其他如map_reduce, refine等 retrieverretriever, return_source_documentsTrue ) # 5. 提問 result qa_chain.invoke({query: 什么是RAG}) print(result[result]) print(來源, [doc.metadata.get(source) for doc in result[source_documents]])6.2 效果評估與迭代調(diào)優(yōu)一個RAG系統(tǒng)的好壞不能憑感覺需要量化評估。評估指標(biāo)檢索階段命中率Hit Rate在Top K個檢索結(jié)果中至少包含一個正確答案文檔的比例。平均倒數(shù)排名MRR正確答案在檢索結(jié)果中排名的倒數(shù)的平均值。衡量系統(tǒng)把正確答案排在前面的能力。生成階段忠實度Faithfulness生成的答案是否嚴(yán)格基于檢索到的文檔有沒有“胡編亂造”幻覺?？梢杂肔LM本身或?qū)ｉT模型來評判。答案相關(guān)性Answer Relevance生成的答案是否直接回答了問題。人工評估最終的金標(biāo)準(zhǔn)。設(shè)計一批測試問題讓人來評判答案的準(zhǔn)確性、有用性和流暢性。迭代調(diào)優(yōu)的閉環(huán)收集bad cases記錄系統(tǒng)回答錯誤或不好的問題。歸因分析是檢索沒找到相關(guān)文檔還是文檔找到了但排序不對還是LLM在生成時誤解了文檔針對性優(yōu)化檢索問題調(diào)整切片策略chunk_size/overlap、嘗試混合檢索、調(diào)整重排序模型、優(yōu)化查詢對用戶原始查詢進(jìn)行改寫或擴展即Query Rewriting/Expansion。生成問題優(yōu)化提示詞Prompt明確要求LLM“嚴(yán)格根據(jù)給定上下文回答”并設(shè)計更好的上下文組織方式如將最相關(guān)的文檔放在最前面。一個關(guān)鍵的提示詞技巧在給LLM的Prompt中明確指令和上下文格式至關(guān)重要。你是一個專業(yè)的助手請嚴(yán)格根據(jù)以下提供的上下文信息來回答問題。如果上下文中的信息不足以回答問題請直接說“根據(jù)已知信息無法回答該問題”不要編造信息。 上下文 {context} 問題{question} 請根據(jù)上下文回答同時可以在{context}中按照相關(guān)性從高到低排列文檔并在每個文檔前加上[文檔1]、[文檔2]的標(biāo)識有助于LLM更好地利用信息。7. 常見問題與避坑指南在實際搭建過程中你會遇到各種各樣的問題。這里記錄一些高頻問題和解決思路。問題現(xiàn)象可能原因排查與解決思路檢索結(jié)果完全不相關(guān)1. 嵌入模型不適合領(lǐng)域。2. 文本切片不合理破壞了語義。3. 查詢未用指令格式化針對BGE等模型。4. 向量索引類型或參數(shù)設(shè)置不當(dāng)。1. 用領(lǐng)域內(nèi)句子對測試嵌入模型相似度。2. 人工檢查切片調(diào)整chunk_size和overlap。3. 確認(rèn)查詢編碼格式符合模型要求。4. 檢查索引的metric_type應(yīng)為IP或L2調(diào)整nprobe等搜索參數(shù)。LLM回答出現(xiàn)幻覺不依據(jù)上下文1. 檢索到的上下文本身不相關(guān)或質(zhì)量差。2. Prompt指令不夠強硬LLM自由發(fā)揮。3. 上下文太長或格式混亂LLM無法有效處理。1. 先檢查檢索階段返回的文檔是否真的相關(guān)。2. 強化Prompt使用“嚴(yán)格根據(jù)”、“必須引用”等措辭并讓LLM指出引用來源。3. 嘗試map_reduce或refine等鏈?zhǔn)椒绞教幚黹L上下文或?qū)z索到的文檔進(jìn)行摘要后再輸入。系統(tǒng)響應(yīng)速度慢1. 嵌入模型推理慢未用GPU或批處理。2. 向量索引未加載到內(nèi)存或ANN參數(shù)nprobe太大。3. LLM生成速度慢。4. 網(wǎng)絡(luò)延遲使用遠(yuǎn)程API時。1. 使用GPU推理并增大encode的batch_size。2. 確認(rèn)集合已load()適當(dāng)調(diào)小nprobe以平衡速度與精度。3. 考慮使用更小的LLM或啟用流式輸出改善體驗。4. 考慮緩存頻繁查詢的嵌入或結(jié)果。對于簡單事實性問題效果好復(fù)雜推理問題差1. 檢索粒度太細(xì)單個切片無法提供完整推理鏈條。2. 未實現(xiàn)多跳檢索Multi-hop Retrieval。1. 嘗試增大chunk_size或采用基于章節(jié)的切片策略。2. 實現(xiàn)迭代檢索用LLM從第一輪答案中提煉出新的查詢進(jìn)行第二輪檢索如此循環(huán)。如何處理文檔更新全量重建向量庫成本高。1.增量更新為新文檔生成向量并插入為已刪除文檔標(biāo)記為無效軟刪除。定期如每周合并增量重建索引以優(yōu)化性能。2. 使用支持動態(tài)更新的向量數(shù)據(jù)庫如Milvus、Qdrant。最后一點個人體會RAG系統(tǒng)是一個典型的“木桶效應(yīng)”工程最終效果取決于最短的那塊板。不要只盯著最炫的LLM或最復(fù)雜的檢索算法往往花時間把最基礎(chǔ)的數(shù)據(jù)清洗和文本切片做好整個系統(tǒng)的效果就能提升一個檔次。從簡單的流程開始構(gòu)建一個可工作的最小版本MVP然后基于真實的用戶問題和bad cases有針對性地、一步一步地去迭代優(yōu)化每一個環(huán)節(jié)這才是搭建一個健壯RAG知識庫的正道。