1. 項(xiàng)目緣起為什么是《紅樓夢(mèng)》與RAG最近在折騰大模型應(yīng)用發(fā)現(xiàn)一個(gè)挺有意思的現(xiàn)象很多朋友一上來(lái)就想搞個(gè)“萬(wàn)能知識(shí)庫(kù)”恨不得把公司所有文檔、個(gè)人所有筆記都喂進(jìn)去。結(jié)果往往是要么向量化過程卡死要么召回結(jié)果驢唇不對(duì)馬嘴最后項(xiàng)目不了了之。我自己的經(jīng)驗(yàn)是從一個(gè)小而具體的領(lǐng)域切入把全鏈路跑通、吃透遠(yuǎn)比一開始就鋪個(gè)大攤子要實(shí)在得多。所以這次我選了《紅樓夢(mèng)》作為實(shí)驗(yàn)對(duì)象。原因很簡(jiǎn)單第一文本體量適中全文約73萬(wàn)字既不會(huì)像單篇文檔那樣過于簡(jiǎn)單也不會(huì)像海量文檔庫(kù)那樣復(fù)雜到讓人迷失第二內(nèi)容結(jié)構(gòu)清晰有明確的人物、情節(jié)、詩(shī)詞非常適合測(cè)試問答系統(tǒng)的準(zhǔn)確性第三文化內(nèi)涵豐富很多問題需要結(jié)合上下文理解比如“林黛玉為什么葬花”、“‘冷月葬花魂’這句詩(shī)好在哪里”這能很好地檢驗(yàn)RAG系統(tǒng)是否真的“理解”了文本而不是簡(jiǎn)單的關(guān)鍵詞匹配。這個(gè)項(xiàng)目的核心目標(biāo)就是手把手帶你從零開始搭建一個(gè)能針對(duì)《紅樓夢(mèng)》進(jìn)行高質(zhì)量問答的RAG應(yīng)用。我們會(huì)用到LangChain這個(gè)當(dāng)今最流行的AI應(yīng)用框架來(lái)組織流程用輕量高效的ChromaDB作為向量數(shù)據(jù)庫(kù)存儲(chǔ)知識(shí)最后調(diào)用通義千問的qwen-plus模型來(lái)生成最終答案。整個(gè)過程我會(huì)把每一步的原理、踩過的坑、以及那些官方文檔里不會(huì)寫的調(diào)試技巧都掰開揉碎了講清楚。無(wú)論你是剛接觸LangChain的新手還是想找一個(gè)具體項(xiàng)目來(lái)深化理解的開發(fā)者相信都能有所收獲。2. 核心組件選型為什么是LangChain Chroma qwen-plus在動(dòng)手之前我們得先搞清楚手里的“兵器”。市面上框架、模型、數(shù)據(jù)庫(kù)那么多為什么偏偏是這套組合這背后是經(jīng)過一番權(quán)衡和實(shí)際測(cè)試的。2.1 LangChain不只是“膠水”更是“腳手架”很多人把LangChain理解為連接大模型和外部工具的“膠水”這個(gè)說(shuō)法對(duì)但不全面。在我實(shí)際使用中它更像一個(gè)高度模塊化、提供了最佳實(shí)踐范式的“腳手架”。對(duì)于RAG應(yīng)用它至少解決了三個(gè)關(guān)鍵問題文檔加載與處理的標(biāo)準(zhǔn)化一本《紅樓夢(mèng)》的txt文件你怎么讀LangChain提供了TextLoader、UnstructuredFileLoader等一大堆文檔加載器能處理PDF、Word、HTML等多種格式。更重要的是它內(nèi)置了文本分割RecursiveCharacterTextSplitter的邏輯這是RAG的基石。你自己寫分割邏輯很容易切碎一個(gè)完整的句子或詩(shī)詞而LangChain提供的分割器已經(jīng)考慮到了中英文的標(biāo)點(diǎn)、換行等特性開箱即用省心不少。流程編排的抽象化RAG的核心流程“檢索 - 增強(qiáng) - 生成”是一個(gè)固定范式。LangChain將其抽象為RetrievalQA鏈。你只需要配置好檢索器Retriever和大模型LLM它就能自動(dòng)幫你完成“將用戶問題轉(zhuǎn)化為向量 - 去向量庫(kù)檢索 - 將檢索到的上下文和問題組合成Prompt - 發(fā)給LLM生成答案”這一整套流程。這避免了我們?cè)跇I(yè)務(wù)邏輯里寫大量膠水代碼讓開發(fā)更聚焦于核心優(yōu)化點(diǎn)。生態(tài)與擴(kuò)展性LangChain有極其豐富的集成生態(tài)。今天我們用Chroma明天想換Milvus或Pinecone可能只需要改一行代碼。想給檢索結(jié)果加個(gè)重排序Re-ranking模塊也有現(xiàn)成的接口可以接入。這種設(shè)計(jì)保證了項(xiàng)目的可迭代性。注意LangChain的版本迭代很快API有時(shí)會(huì)有變動(dòng)。建議在項(xiàng)目開始時(shí)就用pip freeze requirements.txt鎖定核心庫(kù)的版本避免后續(xù)跑不通。本項(xiàng)目基于langchain0.1.0和langchain-community0.0.10進(jìn)行。2.2 Chroma輕量且開發(fā)者友好的向量數(shù)據(jù)庫(kù)向量數(shù)據(jù)庫(kù)是RAG的“記憶體”。選擇ChromaDB主要是看中它的兩個(gè)特點(diǎn)極致簡(jiǎn)單內(nèi)置嵌入Chroma最大的優(yōu)勢(shì)是“開箱即用”。它內(nèi)置了多種開源的句子嵌入模型比如all-MiniLM-L6-v2你甚至不需要單獨(dú)去申請(qǐng)Embedding API的密鑰就能快速把文本轉(zhuǎn)化為向量。這對(duì)于原型驗(yàn)證和中小型項(xiàng)目來(lái)說(shuō)極大地降低了門檻。它可以直接在內(nèi)存中運(yùn)行也支持持久化到磁盤部署方式非常靈活。與LangChain深度集成Chroma是LangChain官方推薦和深度支持的向量數(shù)據(jù)庫(kù)之一集成度非常高。從創(chuàng)建集合Collection、添加文檔到構(gòu)建檢索器都有非常簡(jiǎn)潔的API。當(dāng)然Chroma不適合海量數(shù)據(jù)比如上億條的生產(chǎn)環(huán)境它的集群能力和性能優(yōu)化相比專業(yè)的商業(yè)向量數(shù)據(jù)庫(kù)有差距。但對(duì)于我們這個(gè)百萬(wàn)字級(jí)別的《紅樓夢(mèng)》項(xiàng)目以及絕大多數(shù)個(gè)人或中小團(tuán)隊(duì)的知識(shí)庫(kù)場(chǎng)景它都是綽綽有余且最佳的選擇。2.3 qwen-plus選擇閉源大模型的現(xiàn)實(shí)考量模型層我們選擇了通義千問的qwen-plus。這里可能有人會(huì)問為什么不用開源的Llama 3或者Qwen2.5原因在于項(xiàng)目階段的務(wù)實(shí)選擇。穩(wěn)定性與易用性在項(xiàng)目搭建和調(diào)試階段我們最需要的是模型輸出的穩(wěn)定性和API調(diào)用的便捷性。閉源模型如qwen-plus、GPT-4提供了穩(wěn)定可靠的云端服務(wù)我們無(wú)需關(guān)心模型部署、顯卡資源、推理優(yōu)化等問題可以把全部精力放在應(yīng)用邏輯本身。強(qiáng)大的指令遵循與長(zhǎng)上下文能力qwen-plus擁有128K的上下文長(zhǎng)度這對(duì)于RAG應(yīng)用非常重要。當(dāng)我們的檢索器返回多段相關(guān)文本時(shí)需要模型有能力在長(zhǎng)長(zhǎng)的Prompt中準(zhǔn)確找到并利用這些信息。它的指令遵循能力也經(jīng)過優(yōu)化能更好地理解我們?cè)O(shè)計(jì)的Prompt模板輸出我們想要的格式。成本可控對(duì)于《紅樓夢(mèng)》這個(gè)規(guī)模的問答調(diào)用次數(shù)有限使用qwen-plus的API成本極低甚至可能在新用戶贈(zèng)額范圍內(nèi)。這比自己去部署一個(gè)同等能力的開源模型要經(jīng)濟(jì)、省事得多。一個(gè)重要的心法在項(xiàng)目初期用錢換時(shí)間和穩(wěn)定性是劃算的。先用成熟的閉源API快速跑通流程、驗(yàn)證想法等到流程穩(wěn)定、需求明確后如果成本成為問題再考慮用開源模型進(jìn)行替換和優(yōu)化這才是更高效的路徑。LangChain的模型接口是抽象的未來(lái)切換模型供應(yīng)商核心代碼幾乎不用動(dòng)。3. 環(huán)境搭建與數(shù)據(jù)準(zhǔn)備從文本到向量的第一步理論說(shuō)再多不如動(dòng)手做。我們首先需要一個(gè)干凈的環(huán)境并把《紅樓夢(mèng)》的原始文本處理成向量數(shù)據(jù)庫(kù)能“消化”的格式。3.1 創(chuàng)建虛擬環(huán)境與安裝依賴強(qiáng)烈建議使用虛擬環(huán)境來(lái)管理依賴避免包沖突。# 創(chuàng)建并激活虛擬環(huán)境 (以conda為例venv同理) conda create -n rag-honglou python3.10 conda activate rag-honglou # 安裝核心依賴 pip install langchain0.1.0 langchain-community0.0.10 # ChromaDB及其依賴 pip install chromadb # 用于調(diào)用通義千問API pip install dashscope # 用于文檔加載處理txt pip install unstructured # 可選但推薦用于更準(zhǔn)確的文本分割 pip install tiktoken這里解釋一下tiktoken它是OpenAI開源的BPE分詞器非常高效。LangChain的RecursiveCharacterTextSplitter可以用它來(lái)精確地按token數(shù)量分割文本這對(duì)于控制上下文長(zhǎng)度、優(yōu)化成本至關(guān)重要。即使我們不用OpenAI的模型這個(gè)分詞器本身也是一個(gè)優(yōu)秀的工具。3.2 獲取并清洗《紅樓夢(mèng)》文本你可以在古登堡計(jì)劃等網(wǎng)站找到《紅樓夢(mèng)》的純文本版本。下載后通常需要做一些簡(jiǎn)單的清洗去除無(wú)關(guān)信息刪除文件開頭和結(jié)尾的版權(quán)聲明、項(xiàng)目介紹等非正文內(nèi)容。處理章節(jié)標(biāo)題確保章節(jié)標(biāo)題格式統(tǒng)一例如“第一回 甄士隱夢(mèng)幻識(shí)通靈 賈雨村風(fēng)塵懷閨秀”。這有助于后續(xù)分割時(shí)章節(jié)信息能作為一個(gè)整體被保留。統(tǒng)一換行符將文本中的換行符統(tǒng)一為\n。假設(shè)我們清洗后的文件保存為hongloumeng.txt。一個(gè)干凈的文本是后續(xù)高質(zhì)量向量化的前提。3.3 文檔加載與智能分割RAG成敗的關(guān)鍵這是整個(gè)流程中技術(shù)含量最高、最容易被忽視也最容易出問題的環(huán)節(jié)。很多RAG效果差問題八成出在這里。from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加載文檔 loader TextLoader(‘./hongloumeng.txt‘, encoding‘utf-8‘) documents loader.load() print(f“原始文檔加載完畢共 {len(documents)} 個(gè)文檔對(duì)象。”) # 通常為1 # 2. 配置文本分割器 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每個(gè)文本塊的最大字符數(shù)或token數(shù) chunk_overlap50, # 相鄰塊之間的重疊字符數(shù) length_functionlen, # 計(jì)算長(zhǎng)度的方法這里用字符數(shù)。如果用tiktoken可以換成 tiktoken_len separators[“\n\n“, “\n“, “?！? ““, ““, “ “, ““] # 分割優(yōu)先級(jí)列表 ) # 3. 執(zhí)行分割 split_docs text_splitter.split_documents(documents) print(f“分割后得到 {len(split_docs)} 個(gè)文本塊。”)參數(shù)選擇的藝術(shù)與實(shí)戰(zhàn)經(jīng)驗(yàn)chunk_size500為什么是500對(duì)于中文古典文學(xué)《紅樓夢(mèng)》單句信息密度高。如果設(shè)置太大如1000一個(gè)塊里可能包含多個(gè)不相關(guān)的情節(jié)導(dǎo)致檢索精度下降設(shè)置太小如200可能會(huì)把一句完整的詩(shī)詞或?qū)Π浊袛鄟G失關(guān)鍵信息。500是一個(gè)經(jīng)過測(cè)試的折中點(diǎn)能較好地容納一個(gè)相對(duì)完整的情節(jié)片段或人物描寫。chunk_overlap50重疊是必須的這是為了避免一個(gè)關(guān)鍵信息比如一個(gè)人名出現(xiàn)在兩個(gè)塊的邊界被硬生生切開。50個(gè)字符的重疊能確保上下文的連貫性。例如一段描寫結(jié)束在“黛玉聽了不覺”下一段開頭是“紅了臉”有了重疊就能保證“黛玉聽了不覺紅了臉”這個(gè)完整語(yǔ)義能被檢索到。separators列表這個(gè)列表定義了分割的“刀”下在哪里。LangChain的分割器會(huì)按列表順序嘗試分割。這里我們把雙換行\(zhòng)n\n通常表示段落分隔放在最前面其次是單換行、句號(hào)等。這意味著它會(huì)優(yōu)先保證段落的完整性其次才是句子。這個(gè)順序?qū)χ形奈谋拘Ч芎谩Ｒ粋€(gè)我踩過的坑最初我用默認(rèn)的英文分隔符如\n\n,\n,“, “. “,“,“,“結(jié)果發(fā)現(xiàn)很多中文句號(hào)被忽略導(dǎo)致塊過大。**務(wù)必根據(jù)你的文本語(yǔ)言特性調(diào)整separators**。對(duì)于中文加入“?！薄ⅰ啊?、“”是必要的。執(zhí)行完這一步你會(huì)得到上千個(gè)文本塊split_docs。每個(gè)塊都是一個(gè)Document對(duì)象包含page_content文本內(nèi)容和metadata元數(shù)據(jù)如來(lái)源屬性。接下來(lái)我們就要把這些塊變成向量。4. 構(gòu)建向量知識(shí)庫(kù)讓ChromaDB記住《紅樓夢(mèng)》有了文本塊下一步就是將它們“嵌入”Embedding到高維向量空間并存入ChromaDB。4.1 初始化嵌入模型與向量數(shù)據(jù)庫(kù)Chroma的一大便利是內(nèi)置了嵌入模型。我們使用它默認(rèn)的all-MiniLM-L6-v2模型這是一個(gè)在多語(yǔ)言語(yǔ)料上訓(xùn)練過的輕量級(jí)模型對(duì)中文有不錯(cuò)的效果。from langchain.vectorstores import Chroma from langchain.embeddings import HuggingFaceEmbeddings import os # 定義持久化路徑 PERSIST_DIRECTORY ‘./chroma_honglou_db‘ # 1. 初始化嵌入模型 # 使用HuggingFace上的開源模型 embeddings HuggingFaceEmbeddings( model_name“sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2“, model_kwargs{‘device‘: ‘cpu‘}, # 使用CPU如需GPU可改為 ‘cuda‘ encode_kwargs{‘normalize_embeddings‘: True} # 歸一化向量有利于相似度計(jì)算 ) # 2. 創(chuàng)建并持久化向量數(shù)據(jù)庫(kù) vectordb Chroma.from_documents( documentssplit_docs, # 我們分割好的文本塊列表 embeddingembeddings, # 使用的嵌入模型 persist_directoryPERSIST_DIRECTORY # 指定持久化目錄 ) vectordb.persist() # 顯式持久化到磁盤 print(f“向量數(shù)據(jù)庫(kù)已創(chuàng)建并保存至 {PERSIST_DIRECTORY}”)關(guān)鍵點(diǎn)解析HuggingFaceEmbeddings這里我換成了paraphrase-multilingual-MiniLM-L12-v2它比Chroma默認(rèn)的模型對(duì)中文的支持更好一些。model_kwargs指定模型運(yùn)行的設(shè)備encode_kwargs中的normalize_embeddings設(shè)置為True非常重要它會(huì)對(duì)生成的向量進(jìn)行歸一化處理使得后續(xù)的余弦相似度計(jì)算更加準(zhǔn)確和高效。Chroma.from_documents這個(gè)方法一次性完成了三件事將每個(gè)文檔塊通過embeddings模型轉(zhuǎn)換為向量在Chroma中創(chuàng)建一個(gè)集合Collection將所有向量和對(duì)應(yīng)的原始文本、元數(shù)據(jù)存儲(chǔ)進(jìn)去。持久化調(diào)用persist()后所有數(shù)據(jù)會(huì)保存到本地目錄。下次啟動(dòng)應(yīng)用時(shí)可以直接加載這個(gè)目錄無(wú)需重新生成向量節(jié)省大量時(shí)間。這個(gè)過程可能會(huì)花費(fèi)幾分鐘取決于你的文本塊數(shù)量和模型速度。完成后你的目錄下會(huì)生成一個(gè)chroma_honglou_db文件夾里面就是《紅樓夢(mèng)》的向量化知識(shí)庫(kù)了。4.2 驗(yàn)證向量庫(kù)進(jìn)行第一次檢索測(cè)試在接入大模型之前我們先驗(yàn)證一下向量庫(kù)的檢索能力是否正常。# 重新加載持久化的向量數(shù)據(jù)庫(kù) vectordb Chroma( persist_directoryPERSIST_DIRECTORY, embedding_functionembeddings ) # 定義一個(gè)簡(jiǎn)單的檢索測(cè)試函數(shù) def test_retrieval(query, k3): print(f“\n問題‘{query}‘”) docs vectordb.similarity_search(query, kk) print(f“檢索到 {len(docs)} 個(gè)相關(guān)片段”) for i, doc in enumerate(docs): print(f“\n--- 片段 {i1} (相似度僅供參考) ---”) print(doc.page_content[:200] “...“) # 打印前200字符 print(f“來(lái)源: {doc.metadata}”) # 測(cè)試幾個(gè)問題 test_retrieval(“林黛玉第一次進(jìn)賈府是怎樣的場(chǎng)景“) test_retrieval(“‘好了歌‘的內(nèi)容是什么“) test_retrieval(“賈寶玉的玉上刻了什么字“)運(yùn)行這段代碼你會(huì)看到控制臺(tái)輸出與問題最相關(guān)的幾個(gè)文本片段。這是檢驗(yàn)?zāi)阒拔谋痉指詈颓度肽Ｐ褪欠裼行У狞S金時(shí)刻。如何判斷檢索質(zhì)量相關(guān)性返回的片段是否直接回答了問題例如問“黛玉進(jìn)府”返回的片段是否確實(shí)描述了第三回“接外孫賈母惜孤女”的場(chǎng)景完整性關(guān)鍵信息是否在一個(gè)完整的片段內(nèi)比如“好了歌”的全文是否被完整地檢索出來(lái)而不是被切成了兩半排序性最相關(guān)的片段是否排在第一位如果測(cè)試結(jié)果不理想大概率要回溯調(diào)整文本分割器的參數(shù)chunk_size,chunk_overlap,separators。這是RAG調(diào)優(yōu)中最重要的一環(huán)。5. 接入大模型與構(gòu)建問答鏈讓qwen-plus“開口說(shuō)話”知識(shí)庫(kù)準(zhǔn)備好了現(xiàn)在需要請(qǐng)出“大腦”——大語(yǔ)言模型qwen-plus并用LangChain的鏈Chain把檢索和生成兩個(gè)環(huán)節(jié)無(wú)縫銜接起來(lái)。5.1 配置通義千問qwen-plus模型首先你需要前往阿里云百煉平臺(tái)或靈積平臺(tái)創(chuàng)建一個(gè)API-KEY。from langchain.llms import Tongyi import os # 設(shè)置你的通義千問API-KEY os.environ[“DASHSCOPE_API_KEY“] “your-api-key-here“ # 替換成你的真實(shí)Key # 初始化qwen-plus模型 llm Tongyi( model_name“qwen-plus“, # 指定模型 temperature0.1, # 溫度參數(shù)控制隨機(jī)性。越低輸出越確定。 top_p0.8, # 核采樣參數(shù)與temperature配合使用。 streamingFalse, # 是否流式輸出調(diào)試時(shí)可設(shè)為False )參數(shù)解讀temperature在問答任務(wù)中我們通常希望答案確定、準(zhǔn)確。因此設(shè)置為一個(gè)較低的值0.1-0.3。如果設(shè)得太高如0.9模型可能會(huì)開始“編造”一些《紅樓夢(mèng)》里不存在的情節(jié)。top_p與temperature一起作用控制采樣范圍。0.8是一個(gè)常用值能在保證一定多樣性的同時(shí)避免跑偏。5.2 設(shè)計(jì)Prompt模板告訴模型如何“答題”直接給模型“問題”和“上下文”它可能不知道該如何組織答案。我們需要一個(gè)清晰的指令Prompt Template來(lái)引導(dǎo)它。from langchain.prompts import PromptTemplate # 定義一個(gè)針對(duì)我們問答任務(wù)的Prompt模板 prompt_template “““請(qǐng)根據(jù)以下提供的《紅樓夢(mèng)》相關(guān)上下文片段回答用戶的問題。 如果你在提供的上下文中找不到明確答案請(qǐng)直接說(shuō)“根據(jù)已知信息無(wú)法回答該問題”不要編造答案。 上下文 {context} 問題{question} 請(qǐng)給出準(zhǔn)確、簡(jiǎn)潔的答案””” PROMPT PromptTemplate( templateprompt_template, input_variables[“context“, “question“] )這個(gè)模板有幾個(gè)設(shè)計(jì)要點(diǎn)明確指令開頭就告訴模型任務(wù)是什么。設(shè)定邊界強(qiáng)調(diào)“根據(jù)上下文”并明確要求對(duì)于未知信息說(shuō)“無(wú)法回答”。這是控制模型幻覺Hallucination的關(guān)鍵一步。沒有這個(gè)約束模型很可能會(huì)用它的內(nèi)部知識(shí)可能不準(zhǔn)確或與本書不符來(lái)編造答案。結(jié)構(gòu)化輸入用{context}和{question}作為占位符LangChain會(huì)在運(yùn)行時(shí)自動(dòng)填充。要求簡(jiǎn)潔要求“準(zhǔn)確、簡(jiǎn)潔”避免模型生成冗長(zhǎng)的無(wú)關(guān)內(nèi)容。5.3 組裝RetrievalQA鏈完成最后拼圖現(xiàn)在把向量數(shù)據(jù)庫(kù)檢索器、Prompt模板和大模型組裝成一條自動(dòng)化流水線。from langchain.chains import RetrievalQA # 從向量數(shù)據(jù)庫(kù)創(chuàng)建檢索器 retriever vectordb.as_retriever( search_type“similarity“, # 使用相似度搜索 search_kwargs{“k“: 4} # 每次檢索返回4個(gè)最相關(guān)的片段 ) # 創(chuàng)建RetrievalQA鏈 qa_chain RetrievalQA.from_chain_type( llmllm, chain_type“stuff“, # 最常用的類型將所有檢索到的上下文“塞”進(jìn)Prompt retrieverretriever, chain_type_kwargs{“prompt“: PROMPT}, # 使用我們自定義的Prompt return_source_documentsTrue # 非常重要返回檢索到的源文檔便于調(diào)試 )關(guān)鍵參數(shù)解釋chain_type“stuff“這是最簡(jiǎn)單直接的方式將所有檢索到的文檔片段合并成一個(gè)長(zhǎng)字符串放入Prompt的{context}中。它的優(yōu)點(diǎn)是簡(jiǎn)單缺點(diǎn)是有上下文長(zhǎng)度限制取決于模型。對(duì)于qwen-plus的128K上下文和我們的4個(gè)片段完全夠用。其他還有map_reduce、refine等復(fù)雜類型適用于文檔極多或需要摘要的場(chǎng)景但復(fù)雜度高本例不需要。return_source_documentsTrue務(wù)必設(shè)置為True。這能讓鏈在返回答案的同時(shí)也返回它參考了哪些原文片段。這是后期調(diào)試和優(yōu)化的生命線。當(dāng)你發(fā)現(xiàn)答案不對(duì)時(shí)可以立刻查看模型到底“看”到了什么材料從而判斷是檢索出了問題還是模型理解出了問題。6. 實(shí)戰(zhàn)問答與深度調(diào)試從“能用”到“好用”激動(dòng)人心的時(shí)刻到了讓我們問幾個(gè)問題看看這個(gè)親手搭建的系統(tǒng)表現(xiàn)如何。# 定義一個(gè)漂亮的問答函數(shù) def ask_question(question): print(f“\n 用戶問題{question}”) print(“-“ * 50) result qa_chain({“query“: question}) print(f“ AI答案{result[‘result‘]}”) print(“\n 參考來(lái)源”) for i, doc in enumerate(result[‘source_documents‘]): print(f“ 片段{i1}: {doc.page_content[:150]}...“) # 打印片段前150字 # 開始提問 ask_question(“賈寶玉和林黛玉是什么關(guān)系“) ask_question(“‘金陵十二釵‘正冊(cè)里都有誰(shuí)“) ask_question(“薛寶釵吃的‘冷香丸‘是怎么制作的“) ask_question(“賈府最后為什么被抄家了“)運(yùn)行后你應(yīng)該能看到模型生成的答案以及它背后參考的原文。現(xiàn)在才是真正工作的開始——調(diào)試與優(yōu)化。你可能會(huì)遇到以下幾種典型情況6.1 情況一答案不準(zhǔn)確或未命中問題問“冷香丸配方”答案卻只說(shuō)了“薛寶釵從胎里帶來(lái)一股熱毒”沒提具體的藥材和制作工藝。排查立刻看source_documents。如果檢索到的片段里根本沒有配方細(xì)節(jié)那就是檢索環(huán)節(jié)的問題。解決方案調(diào)整檢索數(shù)量將search_kwargs{“k“: 4}中的k調(diào)大比如到6或8增加命中概率。優(yōu)化檢索方式search_type可以嘗試從“similarity“相似度改為“mmr“最大邊際相關(guān)性。后者會(huì)在考慮相關(guān)性的同時(shí)盡量讓返回的片段多樣性更高避免內(nèi)容冗余。retriever vectordb.as_retriever( search_type“mmr“, search_kwargs{“k“: 6, “fetch_k“: 20, “l(fā)ambda_mult“: 0.5} )回溯檢查分割如果調(diào)整檢索后依然找不到很可能配方描述被你的chunk_size切碎了。你需要回到第3步檢查相關(guān)章節(jié)的原文調(diào)整分割策略。對(duì)于“冷香丸”這種配方描述可能需要更小的chunk_size或不同的separators來(lái)保證其完整性。6.2 情況二答案包含幻覺或無(wú)關(guān)信息問題回答“賈府被抄家的原因”時(shí)模型開始自由發(fā)揮扯上一些歷史背景或自己推斷的原因。排查查看source_documents如果提供的片段里沒有明確原因但模型卻給出了答案這就是模型幻覺。解決方案強(qiáng)化Prompt指令在Prompt模板中把“不要編造答案”的警告寫得更嚴(yán)厲、更具體。例如“你必須嚴(yán)格依據(jù)上下文作答。上下文未提及的信息一律視為未知絕對(duì)不允許自行推斷或添加任何外部知識(shí)?！苯档湍Ｐ汀皠?chuàng)造力”將temperature參數(shù)進(jìn)一步調(diào)低比如到0.01讓模型輸出更加保守和確定。后處理過濾在代碼層面對(duì)答案進(jìn)行校驗(yàn)如果答案中出現(xiàn)“可能”、“我覺得”、“歷史上”等詞匯或者與源文檔相關(guān)性極低可以觸發(fā)一個(gè)重答或提示“信息不足”。6.3 情況三答案冗長(zhǎng)或格式不佳問題答案把檢索到的幾個(gè)片段內(nèi)容幾乎原樣復(fù)述了一遍沒有提煉。解決方案優(yōu)化Prompt在Prompt中明確要求“用簡(jiǎn)潔的語(yǔ)言概括”、“直接回答核心問題”、“分點(diǎn)列出”。嘗試不同的chain_type雖然stuff簡(jiǎn)單但refine鏈類型可以讓模型迭代式地精煉答案。不過這會(huì)增加調(diào)用次數(shù)和復(fù)雜度對(duì)于簡(jiǎn)單問答不一定必要。模型層面控制除了temperature還可以調(diào)整max_tokens來(lái)限制答案的最大長(zhǎng)度。一個(gè)重要的調(diào)試習(xí)慣始終打開return_source_documentsTrue。任何一次錯(cuò)誤的回答都不要直接去修改模型參數(shù)或Prompt而是先看源文檔。90%的問題出在檢索向量化環(huán)節(jié)而不是生成環(huán)節(jié)。7. 進(jìn)階優(yōu)化與擴(kuò)展思路當(dāng)基礎(chǔ)問答跑通后我們可以考慮讓這個(gè)系統(tǒng)變得更強(qiáng)大、更智能。這里分享幾個(gè)有明確提升效果的進(jìn)階方向。7.1 為文檔塊添加元數(shù)據(jù)Metadata我們之前分割的文檔塊丟失了重要的章節(jié)信息。添加上下文元數(shù)據(jù)能極大提升檢索質(zhì)量和答案的可解釋性。# 假設(shè)我們?cè)诜指顣r(shí)能夠知道每個(gè)塊屬于第幾回可以通過解析原文標(biāo)題實(shí)現(xiàn) # 這里演示如何后補(bǔ)元數(shù)據(jù)實(shí)際應(yīng)在分割時(shí)處理 for i, doc in enumerate(split_docs): # 這里需要根據(jù)你的文本解析邏輯來(lái)填充此處為示例 doc.metadata {“source“: “hongloumeng.txt“, “chapter“: “第五回“} # 然后使用帶元數(shù)據(jù)的docs創(chuàng)建向量庫(kù) vectordb Chroma.from_documents( documentssplit_docs_with_metadata, # 帶元數(shù)據(jù)的文檔 embeddingembeddings, persist_directoryPERSIST_DIRECTORY )在檢索時(shí)元數(shù)據(jù)可以作為過濾器Filter使用。例如用戶可以問“在‘寶玉挨打’那一回里賈政說(shuō)了什么”。我們可以先檢索“寶玉挨打”相關(guān)的回目元數(shù)據(jù)再在該范圍內(nèi)進(jìn)行相似度搜索結(jié)果會(huì)精準(zhǔn)得多。7.2 實(shí)現(xiàn)多路召回與重排序Rerank這是工業(yè)級(jí)RAG系統(tǒng)的常見優(yōu)化手段。核心思想是先用簡(jiǎn)單的檢索方法如關(guān)鍵詞BM25快速召回一批候選文檔再用更精細(xì)的模型交叉編碼器對(duì)它們進(jìn)行重排序最后把最相關(guān)的幾篇交給大模型。# 偽代碼思路 from rank_bm25 import BM25Okapi from sentence_transformers import CrossEncoder # 1. 關(guān)鍵詞召回 (BM25) bm25_index BM25Okapi([doc.page_content for doc in split_docs]) keyword_candidates bm25_index.get_top_n(question, split_docs, n20) # 2. 向量召回 vector_candidates vectordb.similarity_search(question, k20) # 3. 合并去重 all_candidates merge_and_deduplicate(keyword_candidates, vector_candidates) # 4. 使用交叉編碼器重排序 model CrossEncoder(‘cross-encoder/ms-marco-MiniLM-L-6-v2‘) pairs [[question, doc.page_content] for doc in all_candidates] scores model.predict(pairs) # 根據(jù)scores對(duì)all_candidates排序 # 5. 取Top-K作為最終上下文 final_context top_k_reranked_candidates這種方法結(jié)合了關(guān)鍵詞匹配的“字面”相關(guān)性和向量匹配的“語(yǔ)義”相關(guān)性能顯著提升召回文檔的質(zhì)量。LangChain社區(qū)也有相關(guān)的ContextualCompressionRetriever等組件可以探索。7.3 構(gòu)建Web應(yīng)用界面一個(gè)命令行工具畢竟不方便。我們可以用Gradio或Streamlit快速構(gòu)建一個(gè)Web界面。# 使用Gradio的示例 import gradio as gr def answer_question(history, message): # history是對(duì)話歷史這里我們實(shí)現(xiàn)單輪問答 result qa_chain({“query“: message}) answer result[‘result‘] # 可以附上參考來(lái)源 sources “\n”.join([f“- {doc.page_content[:100]}...“ for doc in result[‘source_documents‘]]) full_response f“{answer}\n\n**參考來(lái)源**\n{sources}” return full_response # 創(chuàng)建界面 demo gr.ChatInterface( fnanswer_question, title“《紅樓夢(mèng)》智能問答助手“, description“基于RAG技術(shù)構(gòu)建知識(shí)來(lái)源于《紅樓夢(mèng)》全文。請(qǐng)?zhí)釂柊伞? ) if __name__ “__main__“: demo.launch(shareTrue) # shareTrue會(huì)生成一個(gè)臨時(shí)公網(wǎng)鏈接運(yùn)行這段代碼一個(gè)擁有聊天界面的Web應(yīng)用就啟動(dòng)了。你可以把它分享給朋友讓他們也來(lái)體驗(yàn)一下。從一行代碼沒有到擁有一個(gè)能回答《紅樓夢(mèng)》問題的智能應(yīng)用這個(gè)過程本身就是一個(gè)完整的“從0到1”的項(xiàng)目實(shí)踐。它涉及了數(shù)據(jù)處理、算法應(yīng)用、系統(tǒng)集成和交互設(shè)計(jì)。更重要的是你親手摸清了RAG每一個(gè)環(huán)節(jié)的“脾氣”知道了問題可能出在哪里以及如何去優(yōu)化。這套方法論和工具鏈完全可以平移到你自己的專業(yè)文檔、公司知識(shí)庫(kù)、甚至是個(gè)人筆記的管理上。