1. 項(xiàng)目概述為什么RAG知識庫搭建是個(gè)精細(xì)活兒最近和幾個(gè)做AI應(yīng)用的朋友聊天發(fā)現(xiàn)大家一提到RAG檢索增強(qiáng)生成眼睛都放光覺得這是讓大模型“說真話”、解決幻覺問題的銀彈。但真上手去搭一個(gè)從爬數(shù)據(jù)開始到最終能穩(wěn)定、準(zhǔn)確地回答用戶問題中間踩的坑能寫滿一本錯(cuò)題集。這個(gè)項(xiàng)目標(biāo)題“從零搭建 RAG 知識庫爬蟲→分詞→向量化→檢索一步都不能錯(cuò)”可以說精準(zhǔn)地戳中了所有實(shí)踐者的痛點(diǎn)。它不是一個(gè)簡單的流程串聯(lián)而是一個(gè)環(huán)環(huán)相扣、每一步都充滿技術(shù)選型和細(xì)節(jié)打磨的系統(tǒng)工程。我自己在搭建企業(yè)內(nèi)部知識庫、行業(yè)資訊分析系統(tǒng)時(shí)反復(fù)驗(yàn)證過這個(gè)流程。RAG的核心價(jià)值在于為LLM提供一個(gè)精準(zhǔn)、可靠的外部知識“記憶體”。但這個(gè)記憶體的質(zhì)量直接決定了最終回答的靠譜程度。你可以把整個(gè)過程想象成給一位博聞強(qiáng)識但記憶模糊的學(xué)者LLM建造一個(gè)私人圖書館。爬蟲是采購員負(fù)責(zé)從各處搜集書籍?dāng)?shù)據(jù)分詞和向量化是圖書管理員負(fù)責(zé)給書籍編目、貼標(biāo)簽、做摘要把非結(jié)構(gòu)化的文本變成機(jī)器能理解的索引卡片檢索則是學(xué)者的助手當(dāng)學(xué)者被問到問題時(shí)助手能快速從海量索引卡片中找到最相關(guān)的那幾本遞給學(xué)者參考。這個(gè)鏈條里任何一環(huán)的粗糙處理都會導(dǎo)致“垃圾進(jìn)垃圾出”。爬蟲抓得不全或格式混亂后續(xù)處理就無從談起分詞分得不好語義被割裂向量化就成了“歪曲事實(shí)”向量模型選得不對或者索引建得不好檢索召回的就是一堆不相關(guān)的文檔最后即使召回了如果排序策略不行最關(guān)鍵的答案也可能被埋沒在噪音里。所以標(biāo)題強(qiáng)調(diào)“一步都不能錯(cuò)”絕非危言聳聽而是血淚教訓(xùn)的總結(jié)。接下來我就結(jié)合實(shí)戰(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組合。這沒錯(cuò)但對于RAG項(xiàng)目我們需要更全面地考慮靜態(tài)頁面對于新聞網(wǎng)站、博客、文檔站如許多開源項(xiàng)目的Docsrequests/httpx配合BeautifulSoup或parsel速度更快是經(jīng)典選擇。重點(diǎn)在于編寫健壯的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)千差萬別。一個(gè)實(shí)戰(zhàn)技巧是使用readability庫或trafilatura這類專門用于正文提取的工具它們通過算法識別網(wǎng)頁核心內(nèi)容區(qū)域成功率遠(yuǎn)高于手寫規(guī)則。動態(tài)渲染頁面越來越多的網(wǎng)站如單頁應(yīng)用SPA內(nèi)容由JavaScript動態(tài)加載。這時(shí)requests只能拿到空殼。解決方案是Selenium/Playwright模擬瀏覽器行為功能強(qiáng)大但重量級適合復(fù)雜交互如登錄、點(diǎn)擊。資源消耗大不適合大規(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)險(xiǎn)僅用于個(gè)人學(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ù)的換行符、空格、制表符壓縮為單個(gè)空格或標(biāo)準(zhǔn)段落分隔。質(zhì)量過濾長度過濾剔除過短如少于20字符的文本塊這可能是導(dǎo)航碎片或廣告。語言檢測如果你的知識庫只針對中文使用langdetect庫過濾掉非中文內(nèi)容。去重對高度相似或完全相同的文本進(jìn)行去重避免在向量庫中引入冗余?？梢允褂肧imHash或MinHash算法進(jìn)行近似去重。實(shí)操心得建立一個(gè)可配置的清洗管道Pipeline至關(guān)重要。我為每個(gè)數(shù)據(jù)源定義了一套清洗規(guī)則并保存清洗前的原始文本和清洗后的版本方便回溯和調(diào)試。清洗效果直接影響分詞和嵌入的質(zhì)量這里多花一天時(shí)間后面能省下一周的調(diào)試功夫。3. 第二步文本分詞與切片——如何讓機(jī)器“讀懂”段落清洗后的文本是連續(xù)的字符串我們需要將其切割成適合向量化和檢索的片段Chunks。這一步直接決定了檢索的粒度。3.1 分詞Word Segmentation與分句對于中文RAG分詞是基礎(chǔ)。但這里的“分詞”更多指的是為后續(xù)的語義切片做準(zhǔn)備而不是簡單的詞語切分。工具選擇Jieba最常用的中文分詞庫速度快自定義詞典功能強(qiáng)大。適合作為基礎(chǔ)分詞器。HanLP功能更全面除了基礎(chǔ)分詞還提供詞性標(biāo)注、命名實(shí)體識別NER、依存句法分析等。在Spring Boot等Java生態(tài)中集成良好如hanlp-spring-boot-starter。如果你的知識庫涉及大量實(shí)體人名、地名、機(jī)構(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將文本按句號、問號、感嘆號等分割成獨(dú)立的句子。這是更細(xì)粒度的切片基礎(chǔ)?？梢允褂煤唵蔚恼齽t也可以使用更智能的庫如pysbd適用于多種語言。3.2 知識切片Chunking策略核心中的核心這是RAG項(xiàng)目成敗的關(guān)鍵技術(shù)點(diǎn)之一。切片太大會引入無關(guān)噪聲降低檢索精度切片太小會丟失上下文導(dǎo)致語義不完整。固定長度重疊切片最常用、最穩(wěn)定的方法。使用字符數(shù)或token數(shù)作為窗口大小并設(shè)置一個(gè)重疊區(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個(gè)字符或tokens之間。需要權(quán)衡較小的size如256檢索更精準(zhǔn)但可能信息不全較大的size如1024信息完整但可能包含無關(guān)內(nèi)容。一個(gè)經(jīng)驗(yàn)是讓你的塊大小大致等于你期望LLM在生成答案時(shí)參考的上下文長度。chunk_overlap選擇通常為chunk_size的10%-20%。重疊是為了防止一個(gè)完整的句子或概念被生硬地切到兩個(gè)塊中導(dǎo)致檢索時(shí)只召回一半?；谡Z義的切片更高級的方法試圖在語義邊界如段落、章節(jié)處進(jìn)行切割?？梢允褂米匀粩帱c(diǎn)優(yōu)先在\n\n空行、標(biāo)題標(biāo)記#、##、p標(biāo)簽等處切割。語義分割模型使用預(yù)訓(xùn)練模型判斷哪里是自然的語義邊界。這更智能但計(jì)算成本高且模型本身可能引入誤差?；旌锨衅琀ybrid Chunking對于結(jié)構(gòu)清晰的文檔如PDF、Markdown采用分層切片。先按章節(jié)/標(biāo)題切大塊再在大塊內(nèi)按固定長度切小塊。為每個(gè)塊保留其層級信息如{“chapter”: “3”, “section”: “3.1”, “content”: “...”}檢索時(shí)可以利用層級進(jìn)行過濾或加權(quán)。注意事項(xiàng)不要破壞表格和代碼對于技術(shù)文檔表格和代碼塊應(yīng)被視為一個(gè)整體不應(yīng)被切開。需要在分割前進(jìn)行預(yù)處理將這些部分標(biāo)記并保護(hù)起來。保留元數(shù)據(jù)為每個(gè)切片chunk附加來源信息如URL、文件名、標(biāo)題、時(shí)間戳、作者等。這些元數(shù)據(jù)在后續(xù)檢索和結(jié)果展示中非常有用。測試你的切片隨機(jī)抽樣一些切片人工閱讀檢查其語義是否完整重疊是否合理。這是調(diào)試切片策略最直接有效的方法。4. 第三步向量化嵌入——將文本映射到語義空間向量化也叫嵌入Embedding是把文本切片轉(zhuǎn)換成高維空間中的向量一組數(shù)字。語義相似的文本其向量在空間中的距離如余弦相似度也相近。這是實(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項(xiàng)目的首選。Sentence-BERTSBERT有中文變體paraphrase-multilingual-MiniLM-L12-v2在多語言場景下表現(xiàn)穩(wěn)健。M3E系列專門為中文優(yōu)化的嵌入模型在部分中文評測集上表現(xiàn)不錯(cuò)。開源模型優(yōu)勢數(shù)據(jù)隱私安全、可離線運(yùn)行、定制化微調(diào)、無調(diào)用費(fèi)用。劣勢需要本地GPU或CPU資源推理速度取決于硬件模型管理需要自行負(fù)責(zé)。閉源API在線服務(wù)OpenAItext-embedding-3系列性能強(qiáng)大且穩(wěn)定使用簡單。百度文心、阿里通義、智譜ChatGLM等國內(nèi)廠商的嵌入API符合數(shù)據(jù)合規(guī)要求。API優(yōu)勢免運(yùn)維性能穩(wěn)定隨模型升級自動更新。劣勢有調(diào)用成本和數(shù)據(jù)出境風(fēng)險(xiǎn)對于國外API存在網(wǎng)絡(luò)延遲和速率限制。選型建議對于企業(yè)內(nèi)部或?qū)?shù)據(jù)安全要求高的項(xiàng)目優(yōu)先選擇BGE這類優(yōu)秀的開源模型在本地部署。對于快速原型驗(yàn)證或中小規(guī)模應(yīng)用可以考慮國內(nèi)大廠的嵌入API。一個(gè)折中方案是用開源模型處理核心敏感數(shù)據(jù)用API處理非敏感或公開數(shù)據(jù)。4.2 嵌入實(shí)踐與優(yōu)化批量處理與性能調(diào)用嵌入模型是耗時(shí)的。務(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 是一個(gè) numpy 數(shù)組 shape 為 (文本數(shù), 向量維度)normalize_embeddingsTrue將向量歸一化為單位向量。強(qiáng)烈建議開啟這樣后續(xù)計(jì)算余弦相似度就簡化為點(diǎn)積np.dot(a,b)計(jì)算更快且余弦相似度范圍在[-1,1]或[0,1]歸一化后。向量維度不同模型的輸出維度不同如BGE-large是1024維OpenAI text-embedding-3-small是1536維。這會影響向量數(shù)據(jù)庫的存儲和檢索效率但通常更高維度的模型表征能力更強(qiáng)。選擇時(shí)需權(quán)衡效果和成本。指令微調(diào)模型的使用像BGE這類為檢索優(yōu)化的模型通常經(jīng)過了指令微調(diào)。這意味著在編碼查詢query時(shí)需要添加指令前綴而在編碼被檢索的文檔passage時(shí)則不需要或使用不同的前綴以達(dá)到最佳效果。# 對于BGE模型 query 什么是機(jī)器學(xué)習(xí) passages [機(jī)器學(xué)習(xí)是人工智能的一個(gè)分支..., 深度學(xué)習(xí)是機(jī)器學(xué)習(xí)的一種...] # 編碼查詢時(shí)添加指令 query_embedding model.encode([f為這個(gè)句子生成表示以用于檢索相關(guān)文章{query}], normalize_embeddingsTrue) # 編碼文檔時(shí)不需要或使用其他指令具體看模型說明 passage_embeddings model.encode(passages, normalize_embeddingsTrue)務(wù)必查閱所用模型的官方文檔或Hugging Face頁面了解其推薦的編碼方式這是發(fā)揮模型性能的關(guān)鍵。5. 第四步檢索與排序——從海量向量中精準(zhǔn)定位有了高質(zhì)量的向量下一步就是建立索引并實(shí)現(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ù)庫特點(diǎn)適用場景Milvus功能全面性能強(qiáng)勁生態(tài)豐富支持標(biāo)量過濾、動態(tài)Schema。大規(guī)模、高并發(fā)生產(chǎn)環(huán)境需要復(fù)雜過濾和混合搜索。Chroma輕量級API簡單與LangChain集成極佳入門快。原型開發(fā)、小規(guī)模項(xiàng)目、快速驗(yàn)證想法。QdrantRust編寫性能好支持豐富的數(shù)據(jù)類型和過濾條件有云服務(wù)。對性能和過濾有較高要求的生產(chǎn)環(huán)境。PGVectorPostgreSQL的擴(kuò)展利用現(xiàn)有PG生態(tài)支持ACID。已在使用PostgreSQL希望簡化技術(shù)棧。Weaviate集成了向量、圖、關(guān)鍵詞搜索自帶模塊化設(shè)計(jì)。需要結(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是不錯(cuò)的選擇。插入數(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)積因?yàn)槲覀兊南蛄渴菤w一化的內(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 多路召回與混合檢索單一的向量檢索語義檢索有時(shí)會漏掉一些關(guān)鍵詞匹配但語義稍遠(yuǎn)的文檔。因此工業(yè)級RAG系統(tǒng)常采用“多路召回”策略。向量檢索語義召回如上所述利用余弦相似度查找語義最接近的片段。關(guān)鍵詞檢索稀疏召回使用BM25、TF-IDF等算法。它更注重關(guān)鍵詞的精確匹配能有效召回那些包含查詢關(guān)鍵詞但語義嵌入可能不近的文檔例如包含特定產(chǎn)品型號、錯(cuò)誤代碼、人名。BM25是TF-IDF的改進(jìn)版考慮了文檔長度歸一化效果更好?？梢允褂胷ank_bm25庫實(shí)現(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ò)連接超時(shí) 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個(gè)混合檢索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為這個(gè)句子生成表示以用于檢索相關(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)實(shí)際可用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)重通常需要在一個(gè)驗(yàn)證集上調(diào)試。5.3 重排序Reranking提升精度的最后一道關(guān)卡召回Recall階段我們可能找回了100個(gè)相關(guān)文檔但其中真正有用的可能只有前5個(gè)。重排序的目標(biāo)是利用一個(gè)更精細(xì)的模型通常是交叉編碼器Cross-Encoder對召回的Top N個(gè)結(jié)果進(jìn)行兩兩比較或與查詢進(jìn)行精細(xì)匹配重新打分排序?qū)⒆钕嚓P(guān)的結(jié)果推到最前面。為什么需要重排序用于召回的向量模型雙編碼器Bi-Encoder為了效率將查詢和文檔獨(dú)立編碼損失了一些交互信息。而交叉編碼器將查詢和文檔同時(shí)輸入模型進(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] # 計(jì)算相關(guān)性分?jǐn)?shù) scores reranker.compute_score(pairs) # 返回一個(gè)分?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個(gè)候選文檔后使用重排序模型對這50個(gè)文檔進(jìn)行精排選出最終的Top M例如M5個(gè)文檔送入LLM生成答案。6. 全鏈路集成與效果調(diào)優(yōu)將以上四個(gè)模塊串聯(lián)起來就形成了一個(gè)完整的RAG流水線。但搭建完成只是開始持續(xù)的調(diào)優(yōu)才是讓系統(tǒng)變得好用的關(guān)鍵。6.1 流水線搭建與框架選擇你可以完全從零手寫這個(gè)流水線但對于快速開發(fā)和維護(hù)使用框架是更明智的選擇。LangChain/LlamaIndex這兩個(gè)是當(dāng)前最流行的RAG應(yīng)用框架。LangChain更像一個(gè)“膠水”框架提供了豐富的組件Document Loaders, Text Splitters, Vector Stores, Retrievers, Chains靈活性極高你可以自由組合。學(xué)習(xí)曲線稍陡但能深度定制。LlamaIndex更專注于RAG和數(shù)據(jù)索引提供了更高級的檢索抽象如索引、查詢引擎開箱即用的體驗(yàn)更好對復(fù)雜查詢帶過濾、匯總支持更友好。選擇建議如果你需要高度定制化或者你的應(yīng)用邏輯非常復(fù)雜LangChain可能更適合。如果你希望快速構(gòu)建一個(gè)標(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)一個(gè)RAG系統(tǒng)的好壞不能憑感覺需要量化評估。評估指標(biāo)檢索階段命中率Hit Rate在Top K個(gè)檢索結(jié)果中至少包含一個(gè)正確答案文檔的比例。平均倒數(shù)排名MRR正確答案在檢索結(jié)果中排名的倒數(shù)的平均值。衡量系統(tǒng)把正確答案排在前面的能力。生成階段忠實(shí)度Faithfulness生成的答案是否嚴(yán)格基于檢索到的文檔有沒有“胡編亂造”幻覺?？梢杂肔LM本身或?qū)ｉT模型來評判。答案相關(guān)性Answer Relevance生成的答案是否直接回答了問題。人工評估最終的金標(biāo)準(zhǔn)。設(shè)計(jì)一批測試問題讓人來評判答案的準(zhǔn)確性、有用性和流暢性。迭代調(diào)優(yōu)的閉環(huán)收集bad cases記錄系統(tǒng)回答錯(cuò)誤或不好的問題。歸因分析是檢索沒找到相關(guān)文檔還是文檔找到了但排序不對還是LLM在生成時(shí)誤解了文檔針對性優(yōu)化檢索問題調(diào)整切片策略chunk_size/overlap、嘗試混合檢索、調(diào)整重排序模型、優(yōu)化查詢對用戶原始查詢進(jìn)行改寫或擴(kuò)展即Query Rewriting/Expansion。生成問題優(yōu)化提示詞Prompt明確要求LLM“嚴(yán)格根據(jù)給定上下文回答”并設(shè)計(jì)更好的上下文組織方式如將最相關(guān)的文檔放在最前面。一個(gè)關(guān)鍵的提示詞技巧在給LLM的Prompt中明確指令和上下文格式至關(guān)重要。你是一個(gè)專業(yè)的助手請嚴(yán)格根據(jù)以下提供的上下文信息來回答問題。如果上下文中的信息不足以回答問題請直接說“根據(jù)已知信息無法回答該問題”不要編造信息。 上下文 {context} 問題{question} 請根據(jù)上下文回答同時(shí)可以在{context}中按照相關(guān)性從高到低排列文檔并在每個(gè)文檔前加上[文檔1]、[文檔2]的標(biāo)識有助于LLM更好地利用信息。7. 常見問題與避坑指南在實(shí)際搭建過程中你會遇到各種各樣的問題。這里記錄一些高頻問題和解決思路。問題現(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指令不夠強(qiáng)硬LLM自由發(fā)揮。3. 上下文太長或格式混亂LLM無法有效處理。1. 先檢查檢索階段返回的文檔是否真的相關(guān)。2. 強(qiáng)化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時(shí)。1. 使用GPU推理并增大encode的batch_size。2. 確認(rèn)集合已load()適當(dāng)調(diào)小nprobe以平衡速度與精度。3. 考慮使用更小的LLM或啟用流式輸出改善體驗(yàn)。4. 考慮緩存頻繁查詢的嵌入或結(jié)果。對于簡單事實(shí)性問題效果好復(fù)雜推理問題差1. 檢索粒度太細(xì)單個(gè)切片無法提供完整推理鏈條。2. 未實(shí)現(xiàn)多跳檢索Multi-hop Retrieval。1. 嘗試增大chunk_size或采用基于章節(jié)的切片策略。2. 實(shí)現(xiàn)迭代檢索用LLM從第一輪答案中提煉出新的查詢進(jìn)行第二輪檢索如此循環(huán)。如何處理文檔更新全量重建向量庫成本高。1.增量更新為新文檔生成向量并插入為已刪除文檔標(biāo)記為無效軟刪除。定期如每周合并增量重建索引以優(yōu)化性能。2. 使用支持動態(tài)更新的向量數(shù)據(jù)庫如Milvus、Qdrant。最后一點(diǎn)個(gè)人體會RAG系統(tǒng)是一個(gè)典型的“木桶效應(yīng)”工程最終效果取決于最短的那塊板。不要只盯著最炫的LLM或最復(fù)雜的檢索算法往往花時(shí)間把最基礎(chǔ)的數(shù)據(jù)清洗和文本切片做好整個(gè)系統(tǒng)的效果就能提升一個(gè)檔次。從簡單的流程開始構(gòu)建一個(gè)可工作的最小版本MVP然后基于真實(shí)的用戶問題和bad cases有針對性地、一步一步地去迭代優(yōu)化每一個(gè)環(huán)節(jié)這才是搭建一個(gè)健壯RAG知識庫的正道。