1. 項目概述從“茴香豆”到RAG智能助理的實踐之路最近在整理學(xué)習(xí)筆記正好翻到之前研究RAG技術(shù)時的一個實踐項目標(biāo)題就叫“茴香豆”。這名字聽起來有點趣味其實它指向的是一個非常具體的技術(shù)實現(xiàn)如何從零開始搭建一個屬于自己的檢索增強(qiáng)生成智能助理。RAG也就是檢索增強(qiáng)生成現(xiàn)在可以說是大模型應(yīng)用落地的標(biāo)配技術(shù)了。它核心要解決的就是大模型“一本正經(jīng)胡說八道”和知識更新不及時的痛點。簡單來說RAG通過外掛一個專屬的知識庫讓大模型在回答問題時先從這個知識庫里找到最相關(guān)的信息片段作為參考再組織語言回答這樣既能保證答案的準(zhǔn)確性又能讓模型掌握你私有的、最新的知識。這個“茴香豆”項目就是一個典型的RAG系統(tǒng)搭建實戰(zhàn)。它不只是一個Demo而是涵蓋了從文檔處理、向量檢索到與大模型集成的完整鏈路。對于想入門AI應(yīng)用開發(fā)特別是希望將大模型能力與自身業(yè)務(wù)數(shù)據(jù)結(jié)合的朋友來說走通這樣一個項目意義遠(yuǎn)大于單純調(diào)用API。你會深刻理解數(shù)據(jù)如何變成模型能“理解”的格式查詢?nèi)绾尉珳?zhǔn)命中知識以及整個流程中那些影響效果的關(guān)鍵“旋鈕”都在哪里。接下來我就結(jié)合自己的實操筆記把這個過程的思路、步驟和踩過的坑系統(tǒng)地梳理一遍。2. RAG系統(tǒng)核心架構(gòu)與“茴香豆”設(shè)計思路拆解2.1 為什么是RAG核心價值與問題域界定在動手之前我們必須先想清楚為什么要用RAG。直接使用大模型對話比如問它“我司2024年最新的產(chǎn)品政策是什么”它大概率是無法回答的因為這些信息不在它的訓(xùn)練數(shù)據(jù)里。即使是一些公開知識模型也可能因為訓(xùn)練數(shù)據(jù)截止日期或“幻覺”問題給出錯誤答案。RAG的價值就在于它為大模型裝上了一雙“眼睛”和一個“外部記憶體”。這雙眼睛檢索器負(fù)責(zé)在你提供的文檔庫中快速掃描找到與問題最相關(guān)的段落這個記憶體向量數(shù)據(jù)庫則高效存儲和索引這些文檔內(nèi)容。“茴香豆”項目的設(shè)計目標(biāo)很明確構(gòu)建一個輕量級、可復(fù)現(xiàn)、效果可控的RAG智能助理原型。它不追求一步到位的企業(yè)級復(fù)雜功能而是聚焦于打通核心鏈路讓你能清晰地看到數(shù)據(jù)是如何流動的。整個系統(tǒng)可以抽象為三個核心模塊文檔處理與索引模塊、檢索與排序模塊、提示工程與生成模塊。第一個模塊解決“知識怎么存”的問題第二個模塊解決“知識怎么找”的問題第三個模塊解決“找到了怎么用”的問題。這個清晰的劃分是后續(xù)一切工作的基礎(chǔ)。2.2 “茴香豆”技術(shù)棧選型背后的考量技術(shù)選型往往決定了項目的上手難度和天花板。在這個項目中我們的選型遵循“輕量、主流、可控”的原則。1. 文檔加載與切分LangChain 自定義切分器LangChain幾乎是當(dāng)前大模型應(yīng)用開發(fā)的事實標(biāo)準(zhǔn)框架其DocumentLoader支持PDF、Word、TXT、HTML等多種格式能省去大量解析文件的臟活累活。但LangChain自帶的RecursiveCharacterTextSplitter遞歸字符切分器有時不夠靈活。在“茴香豆”里我采用了基于語義的切分策略作為補(bǔ)充。例如對于技術(shù)文檔我會優(yōu)先按章節(jié)標(biāo)題Markdown的##或###進(jìn)行切分以保持上下文的完整性對于普通段落再輔以固定長度重疊overlap的字符切分。這樣能更好地平衡檢索精度和上下文信息量。2. 向量化模型與向量數(shù)據(jù)庫Sentence Transformers Chroma文本轉(zhuǎn)化為向量嵌入是檢索的基石。我選擇了all-MiniLM-L6-v2這個模型它來自Sentence Transformers庫。選它的理由很實在模型大小僅80MB左右在CPU上也能跑出不錯的速度并且在MTEB等通用語義相似度評測榜上表現(xiàn)均衡。對于入門和大多數(shù)中文場景它完全夠用。如果追求更高精度可以升級為text2vec系列或bge系列的模型。 向量數(shù)據(jù)庫方面ChromaDB以其極簡的API和內(nèi)存/持久化兩種模式脫穎而出。它無需單獨(dú)部署服務(wù)幾行代碼就能集成特別適合原型開發(fā)和中小規(guī)模知識庫萬級文檔以內(nèi)。它的核心接口就是add_documents、query直觀易懂讓我們能把精力集中在效果優(yōu)化上而不是數(shù)據(jù)庫配置上。3. 大模型接口OpenAI API 或 本地開源模型為了快速驗證流程初期直接使用OpenAI的GPT-3.5/4 API是最佳選擇穩(wěn)定且效果有保障。但在“茴香豆”的后期我嘗試接入了本地部署的開源模型如ChatGLM3、Qwen等通過FastChat或vLLM提供兼容OpenAI的API接口。這一步的意義在于實現(xiàn)數(shù)據(jù)閉環(huán)和成本可控畢竟長期調(diào)用商用API是一筆不小的開銷且敏感數(shù)據(jù)不出本地更安全。4. 前端交互Gradio 或 Streamlit一個可視化的界面能極大提升演示和調(diào)試體驗。Gradio和Streamlit都能快速構(gòu)建Web界面。Gradio更輕量專注于機(jī)器學(xué)習(xí)Demo幾行代碼就能創(chuàng)建一個帶聊天框的界面Streamlit則更像一個數(shù)據(jù)應(yīng)用框架布局能力更強(qiáng)。在“茴香豆”項目中我選擇了Gradio因為它與LangChain的集成更無縫ChatInterface組件開箱即用。3. 從文檔到向量知識庫構(gòu)建的魔鬼細(xì)節(jié)3.1 文檔預(yù)處理清洗、格式化與結(jié)構(gòu)化很多人以為RAG就是簡單地把文檔扔進(jìn)去切分但預(yù)處理的質(zhì)量直接決定了檢索的上限。垃圾進(jìn)垃圾出在這里同樣適用。首先格式統(tǒng)一與噪音去除。從不同渠道獲得的文檔掃描PDF、網(wǎng)頁爬蟲、Word文件含有大量噪音頁眉頁腳、頁碼、無關(guān)的廣告鏈接、特殊字符等。我的做法是先用pdfplumber或pypdf2提取PDF文本用python-docx處理Word用BeautifulSoup清理HTML。一個常見的坑是掃描版PDF需要用OCR工具如Tesseract先轉(zhuǎn)文字但這一步會引入大量識別錯誤需謹(jǐn)慎評估。其次文檔結(jié)構(gòu)化解析。這是提升效果的關(guān)鍵。對于技術(shù)手冊、產(chǎn)品文檔這類有明確層級結(jié)構(gòu)的文本我會先用正則表達(dá)式或基于規(guī)則的解析器識別出章節(jié)標(biāo)題如“1.1 概述”、“第二章 安裝”并以此作為元數(shù)據(jù)metadata記錄下來。這樣在后續(xù)切分時可以盡量保證一個切片包含一個完整的小節(jié)避免將一個問題和一個答案切到兩個不同的片段中。注意元數(shù)據(jù)metadata是RAG中的“黃金信息”。除了章節(jié)標(biāo)題還可以包括文檔來源、更新時間、作者等信息。在檢索時不僅可以按向量相似度排序還可以按元數(shù)據(jù)過濾比如“只檢索2024年更新的產(chǎn)品文檔”這能大幅提升答案的時效性和準(zhǔn)確性。3.2 文本切分策略長度、重疊與語義邊界切分是門藝術(shù)。切得太碎檢索到的片段缺乏足夠上下文模型看不懂切得太長片段會包含無關(guān)信息稀釋核心內(nèi)容同時增加模型處理負(fù)擔(dān)和成本。1. 固定長度重疊切分這是最基礎(chǔ)的方法。在“茴香豆”中我設(shè)置chunk_size500字符數(shù)chunk_overlap100。500字符大約是一個自然段到兩個自然段的長度能容納一個相對完整的觀點。100字符的重疊是為了防止一個完整的句子或關(guān)鍵信息恰好被切在邊界上導(dǎo)致上下文斷裂。這個重疊區(qū)域就像一個“緩沖區(qū)”確保了信息的連續(xù)性。2. 語義切分僅按字符長度切分會破壞語義完整性。我引入了semantic-text-splitter庫的啟發(fā)嘗試基于句子邊界如中文句號、問號、感嘆號進(jìn)行切分并盡量保證每個切片的句子是語義上相對獨(dú)立的。更高級的做法是使用小型模型計算句子間的語義變化在語義發(fā)生較大轉(zhuǎn)折處進(jìn)行切分但這會顯著增加處理時間在原型階段性價比不高。3. 混合切分策略我的實戰(zhàn)經(jīng)驗是先按結(jié)構(gòu)切再按長度微調(diào)。例如對于一份API文檔首先識別出每個獨(dú)立的“接口說明”板塊通常由接口名稱、URL、方法等標(biāo)題標(biāo)識將每個板塊作為一個大單元。然后在這個大單元內(nèi)部如果內(nèi)容很長再使用固定長度重疊的方式進(jìn)行二次切分。最后為每個切片記錄其所屬的“接口名稱”作為元數(shù)據(jù)。這樣當(dāng)用戶問“用戶登錄接口的返回值是什么”時檢索系統(tǒng)不僅能找到語義相似的片段還能通過元數(shù)據(jù)快速定位到“用戶登錄接口”這個章節(jié)下的所有相關(guān)內(nèi)容精度更高。3.3 向量化嵌入與索引構(gòu)建文本切分后就來到了核心的向量化步驟。這里使用的是之前選定的all-MiniLM-L6-v2模型。from sentence_transformers import SentenceTransformer # 加載嵌入模型 embed_model SentenceTransformer(‘sentence-transformers/all-MiniLM-L6-v2‘) # 假設(shè) docs 是切分好的文本片段列表 doc_texts [doc.page_content for doc in docs] # 生成向量嵌入 doc_embeddings embed_model.encode(doc_texts, normalize_embeddingsTrue)關(guān)鍵參數(shù)normalize_embeddingsTrue非常重要。它將向量歸一化為單位長度這樣后續(xù)計算余弦相似度就簡化為向量點積計算效率最高這也是大多數(shù)向量數(shù)據(jù)庫的默認(rèn)做法。接下來是將向量存入ChromaDB。這里有一個細(xì)節(jié)連同向量一起存儲的還有原始的文本片段chunk和它的元數(shù)據(jù)metadata。ChromaDB會為每個文檔分配一個唯一ID。import chromadb from chromadb.config import Settings # 創(chuàng)建或連接到持久化的ChromaDB client chromadb.PersistentClient(path“./my_chroma_db“) collection client.get_or_create_collection(name“my_knowledge_base“) # 準(zhǔn)備批量添加的數(shù)據(jù) ids [f“doc_{i}“ for i in range(len(docs))] metadatas [doc.metadata for doc in docs] # 之前準(zhǔn)備好的元數(shù)據(jù) documents [doc.page_content for doc in docs] # 原始文本 # 添加文檔和其嵌入向量 collection.add( idsids, embeddingsdoc_embeddings.tolist(), # 注意轉(zhuǎn)換為list metadatasmetadatas, documentsdocuments )實操心得在構(gòu)建索引時建議對輸入文本進(jìn)行一次簡單的清洗比如去除首尾空白符、合并多個換行符。有時候PDF解析會帶來奇怪的換行導(dǎo)致“用戶\n登錄”和“用戶登錄”在向量化后產(chǎn)生不必要的差異。另外對于大規(guī)模知識庫分批batch進(jìn)行encode和add操作并加入進(jìn)度提示能更好地管理內(nèi)存和掌控進(jìn)程。4. 檢索、重排與生成智能問答鏈路的實現(xiàn)4.1 檢索器相似度計算與多路召回當(dāng)用戶提出一個問題Query時第一步是將其轉(zhuǎn)化為向量然后在向量數(shù)據(jù)庫中進(jìn)行相似度搜索相似度計算通常使用余弦相似度。# 將用戶問題轉(zhuǎn)化為向量 query_embedding embed_model.encode([user_question], normalize_embeddingsTrue)[0] # 在集合中進(jìn)行相似度搜索 results collection.query( query_embeddings[query_embedding.tolist()], n_results5 # 返回最相似的5個片段 )這里的n_results是一個關(guān)鍵超參數(shù)。返回太少可能遺漏關(guān)鍵信息返回太多會引入噪音并增加后續(xù)處理和模型成本。通常我會設(shè)置一個較大的初始值如10然后根據(jù)效果調(diào)整。單純的向量相似度檢索Dense Retrieval有時會漏掉一些關(guān)鍵詞匹配但語義表述不同的重要文檔。因此在“茴香豆”中我引入了混合檢索的思路稠密檢索如上所述基于向量相似度擅長理解語義。稀疏檢索如BM25算法基于關(guān)鍵詞匹配擅長處理專有名詞、術(shù)語。 可以將兩者的檢索結(jié)果取并集或按分?jǐn)?shù)融合實現(xiàn)“多路召回”提高召回率。4.2 重排序從“找到”到“找對”檢索系統(tǒng)返回了Top K個相關(guān)片段但它們的順序完全基于向量相似度分?jǐn)?shù)這個分?jǐn)?shù)不一定與“對生成最終答案最有幫助”的程度完全一致。這時就需要重排序。重排序器Reranker是一個更精細(xì)、通常也更耗資源的模型它會對檢索到的候選片段和問題進(jìn)行一次更深入的交互式打分。一個流行的選擇是bge-reranker系列模型。from FlagEmbedding import FlagReranker reranker FlagReranker(‘BAAI/bge-reranker-large‘, use_fp16True) # 使用半精度節(jié)省內(nèi)存 pairs [[user_question, doc] for doc in retrieved_docs] scores reranker.compute_score(pairs, normalizeTrue) # 計算每個問題文檔對的得分 # 根據(jù)重排序得分對文檔重新排序 reranked_docs [doc for _, doc in sorted(zip(scores, retrieved_docs), reverseTrue)]重排序后排名靠前的片段質(zhì)量通常會有顯著提升。在實踐中對于精度要求高的場景重排序幾乎是必選項。但它會帶來額外的延遲因此一種折中方案是先用向量檢索召回較多的候選如20個再用重排序器精選出最相關(guān)的3-5個送入大模型。4.3 提示工程與答案生成組裝上下文與提問這是RAG鏈路的最后一環(huán)也是直接面向用戶的環(huán)節(jié)。我們需要將檢索到的最相關(guān)文檔片段作為上下文Context和用戶問題Question一起構(gòu)造一個提示詞Prompt發(fā)送給大模型。一個經(jīng)典且有效的Prompt模板如下你是一個專業(yè)的智能助理請嚴(yán)格根據(jù)以下提供的上下文信息來回答問題。如果上下文中的信息不足以回答問題請直接說“根據(jù)已知信息無法回答該問題”不要編造信息。 上下文信息 {context} 用戶問題{question} 請根據(jù)上下文信息回答在代碼中我們這樣實現(xiàn)def build_prompt(context_docs, question): # 將多個文檔片段合并為上下文 context “\n\n“.join([doc.page_content for doc in context_docs]) prompt_template “““你是一個專業(yè)的智能助理請嚴(yán)格根據(jù)以下提供的上下文信息來回答問題。如果上下文中的信息不足以回答問題請直接說“根據(jù)已知信息無法回答該問題”不要編造信息。 上下文信息 {context} 用戶問題{question} 請根據(jù)上下文信息回答”“” return prompt_template.format(contextcontext, questionquestion) # 使用重排序后的前3個文檔 top_k_docs reranked_docs[:3] final_prompt build_prompt(top_k_docs, user_question) # 調(diào)用大模型 response openai_chat_completion(final_prompt) # 或調(diào)用本地模型這里有幾個至關(guān)重要的細(xì)節(jié)上下文長度合并的上下文總長度不能超過大模型的上下文窗口限制如GPT-3.5的4K或16K。需要在構(gòu)建Prompt時計算token數(shù)必要時截斷最不重要的片段。指令遵循Prompt中必須明確強(qiáng)調(diào)“嚴(yán)格根據(jù)上下文”這是抑制模型幻覺的關(guān)鍵。引用標(biāo)注在答案中可以要求模型注明答案來源于哪個文檔片段通過元數(shù)據(jù)中的ID或標(biāo)題增加可信度。例如在Prompt中加入“請在答案末尾用【來源文檔標(biāo)題】的格式注明出處”。5. 效果評估與迭代優(yōu)化讓“茴香豆”更聰明搭建完基礎(chǔ)流程只是第一步要讓RAG智能助理真正可用必須進(jìn)行效果評估和持續(xù)優(yōu)化。5.1 構(gòu)建測試集與評估指標(biāo)不能憑感覺說“好像還行”。需要建立一個小的測試集QA對例如從知識庫中抽取20-50個問題并準(zhǔn)備好標(biāo)準(zhǔn)答案或關(guān)鍵信息點。評估指標(biāo)可以包括檢索精度Top K檢索結(jié)果中是否包含了能回答問題的正確片段可以計算Hit RateK。答案準(zhǔn)確性模型的回答與標(biāo)準(zhǔn)答案在事實層面上是否一致這需要人工或借助更強(qiáng)大的模型如GPT-4進(jìn)行評判。答案相關(guān)性答案是否緊扣問題沒有答非所問幻覺率答案中是否出現(xiàn)了上下文未提供的、編造的信息5.2 常見問題排查與優(yōu)化技巧在實際運(yùn)行“茴香豆”的過程中我遇到了不少典型問題以下是排查思路和優(yōu)化方法問題1檢索不到相關(guān)文檔。檢查用戶問題的向量表示是否合理可以嘗試將問題用更完整、更書面化的語言重新表述后檢索。優(yōu)化查詢擴(kuò)展對原始問題進(jìn)行同義詞擴(kuò)展、或者讓大模型生成幾個相關(guān)的問題用這組問題去檢索然后合并結(jié)果。優(yōu)化切分回顧文檔切分策略。是不是切得太碎導(dǎo)致關(guān)鍵信息被割裂嘗試增大chunk_size或采用語義切分。調(diào)整嵌入模型對于專業(yè)領(lǐng)域如醫(yī)學(xué)、法律通用嵌入模型可能表現(xiàn)不佳。嘗試使用在該領(lǐng)域數(shù)據(jù)上微調(diào)過的嵌入模型或者像bge-large-zh這樣在中文上表現(xiàn)更優(yōu)的模型。問題2檢索到了相關(guān)文檔但答案還是不對或包含幻覺。檢查查看最終送入模型的上下文。是不是包含了無關(guān)或矛盾的片段Prompt指令是否足夠強(qiáng)硬優(yōu)化引入重排序這是解決此問題最有效的手段之一確保送給模型的是最精華、最相關(guān)的片段。優(yōu)化Prompt在Prompt中增加更嚴(yán)格的約束例如“你必須且只能使用以下上下文中的信息。上下文中的信息是真實可信的請忽略你已有的任何可能與之沖突的知識?！鄙舷挛膲嚎s/摘要如果檢索到的片段很長且包含冗余可以先用一個較小的模型或大模型本身對每個片段進(jìn)行摘要再將摘要作為上下文送入減少噪音。問題3回答“根據(jù)已知信息無法回答”但明明知識庫里有。檢查這是典型的“語義鴻溝”問題。用戶的問題表述和知識庫中的文檔表述差異太大。優(yōu)化對知識庫進(jìn)行數(shù)據(jù)增強(qiáng)在構(gòu)建索引時除了原始文本還可以為每個片段人工或自動生成幾個可能的問題Question Generation將“問題-片段”對一起存入向量數(shù)據(jù)庫。檢索時不僅用用戶問題去匹配片段內(nèi)容也去匹配這些生成的問題。使用HyDE技術(shù)讓大模型根據(jù)用戶問題“幻想”一個假設(shè)性答案Hypothetical Document Embedding然后用這個假設(shè)答案的向量去檢索。因為假設(shè)答案的表述風(fēng)格可能更接近知識庫文檔從而能更好地檢索到相關(guān)內(nèi)容。5.3 高級進(jìn)階Agentic RAG 與 查詢路由當(dāng)基礎(chǔ)RAG跑通后可以探索更高級的模式讓“茴香豆”變得更智能。Agentic RAG將RAG系統(tǒng)作為一個工具嵌入到一個智能體Agent的循環(huán)中。例如當(dāng)用戶提出一個復(fù)雜、多步驟的問題時Agent可以自主規(guī)劃先檢索A文檔了解概念再根據(jù)結(jié)果檢索B文檔獲取具體數(shù)據(jù)最后綜合生成答案。這需要引入如LangChain的Agent框架并定義好RAG工具的調(diào)用方式。查詢路由不是所有用戶查詢都需要走RAG流程。系統(tǒng)可以設(shè)計一個路由層先判斷問題類型如果是簡單的問候或通用知識如“你好”、“太陽為什么東升西落”直接讓大模型基于自身知識回答。如果是需要最新信息或私有信息的問題如“我司Q3財報要點”、“項目X的架構(gòu)圖在哪里”則觸發(fā)RAG流程。如果是需要計算或執(zhí)行某個操作如“計算一下我的報銷總額”、“創(chuàng)建一個會議邀請”則路由到相應(yīng)的工具或函數(shù)。 這可以通過訓(xùn)練一個簡單的文本分類器或者使用大模型本身進(jìn)行意圖識別來實現(xiàn)。6. 項目部署與工程化思考6.1 從腳本到服務(wù)API封裝與前端集成開發(fā)階段的代碼可能是零散的腳本。為了實用需要將其封裝成服務(wù)。一個簡單的架構(gòu)是使用FastAPI構(gòu)建RESTful APIfrom fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI(title“茴香豆RAG智能助理API“) class QueryRequest(BaseModel): question: str top_k: int 5 class QueryResponse(BaseModel): answer: str sources: list[str] # 引用來源 app.post(“/ask“, response_modelQueryResponse) async def ask_question(request: QueryRequest): # 這里集成前面實現(xiàn)的所有步驟檢索、重排、生成 # ... answer, source_docs rag_chain.invoke(request.question) return QueryResponse(answeranswer, sources[doc.metadata.get(‘title‘, ‘N/A‘) for doc in source_docs])這樣前端如Gradio、微信小程序、企業(yè)內(nèi)部系統(tǒng)就可以通過調(diào)用這個API來獲取智能問答服務(wù)。Gradio的集成非常簡單幾乎就是一個函數(shù)調(diào)用。6.2 知識庫的更新與維護(hù)知識不是靜態(tài)的。當(dāng)有新文檔加入或舊文檔更新時需要支持知識庫的增量更新。全量重建最簡單但最耗時刪除舊集合重新處理所有文檔并構(gòu)建索引。適用于知識庫較小或更新不頻繁的場景。增量更新更優(yōu)雅的方式。為每個文檔切片計算一個哈希值如MD5當(dāng)文檔更新時只需處理哈希值發(fā)生變化的文檔并更新向量數(shù)據(jù)庫中對應(yīng)的條目。這需要更精細(xì)的數(shù)據(jù)管理邏輯。刪除處理同樣需要支持從知識庫中刪除特定文檔。在ChromaDB中可以根據(jù)文檔的ID或元數(shù)據(jù)進(jìn)行刪除操作。6.3 性能、成本與監(jiān)控性能主要瓶頸在嵌入模型推理和向量檢索。對于大規(guī)模知識庫需要考慮將向量數(shù)據(jù)庫如Chroma部署為獨(dú)立服務(wù)并使用GPU加速嵌入模型。檢索時使用近似最近鄰搜索ANN算法如HNSW來平衡精度和速度。成本如果使用商用大模型API成本主要來自Token消耗。優(yōu)化策略包括優(yōu)化Prompt減少冗余、壓縮上下文、對簡單問題使用更便宜的模型如GPT-3.5 Turbo、設(shè)置使用頻率限制等。監(jiān)控記錄每一次問答的日志包括用戶問題、檢索到的文檔、生成的答案、耗時、Token使用量。這有助于分析效果瓶頸、發(fā)現(xiàn)常見錯誤問題Bad Cases并為后續(xù)的優(yōu)化提供數(shù)據(jù)支持。走完“茴香豆”這個完整的項目你對RAG的理解就不再停留在概念上了。你會清楚地知道一個簡單的問答背后是數(shù)據(jù)預(yù)處理、向量化、檢索、重排、提示工程等一系列環(huán)節(jié)的精密協(xié)作每一個環(huán)節(jié)都有優(yōu)化的空間。這套方法論和實操經(jīng)驗是構(gòu)建任何更復(fù)雜AI應(yīng)用如智能客服、企業(yè)知識中樞、AI編程助手的堅實基礎(chǔ)。最重要的是你擁有了一個完全受自己掌控的智能助理原型可以根據(jù)需要不斷喂養(yǎng)它新的知識讓它持續(xù)成長真正成為你工作或?qū)W習(xí)中的得力幫手。