1. 項目概述為什么我們需要RAG工具如果你最近在折騰大語言模型大概率已經(jīng)聽過RAG這個詞了。簡單來說RAG就是讓LLM在回答問題時能“翻看”你提供的特定資料庫而不是只依賴它訓練時學到的那些可能已經(jīng)過時或不精確的通用知識。這就像給一個博聞強識但記憶固定的學者配了一個隨時可查的、最新的個人圖書館。想法很美好但真干起來你會發(fā)現(xiàn)從一堆雜亂無章的文檔PDF、Word、網(wǎng)頁到讓模型吐出精準答案中間隔著一條名為“工程化”的鴻溝。文檔怎么切分向量用什么模型編碼存到哪里怎么搜得又快又準搜出來的結(jié)果太多太雜怎么辦每一個環(huán)節(jié)都有坑。這就是為什么“RAG工具”變得如此重要。它們不是某個單一軟件而是一系列框架、庫和平臺旨在把上述復雜流程標準化、自動化讓你能聚焦在業(yè)務邏輯上而不是重復造輪子。今天我們不談空洞的理論直接上手七種我深度使用或調(diào)研過的RAG工具/方案從輕量級庫到企業(yè)級平臺剖析它們各自的核心設計、適用場景以及那些只有踩過坑才知道的“實操要點”。無論你是想快速驗證一個點子還是為產(chǎn)品構(gòu)建穩(wěn)定的知識庫服務這里總有一款適合你。2. 七種RAG工具深度解析與選型指南面對琳瑯滿目的工具直接說“某某最好”是武斷的。我的選擇邏輯始終是根據(jù)你的團隊規(guī)模、技術(shù)棧、數(shù)據(jù)復雜度以及對性能、成本的權(quán)衡來決策。下面我將這七種工具分為三大類輕量級開發(fā)庫、一體化框架和云原生/企業(yè)級平臺并為你逐一拆解。2.1 輕量級開發(fā)庫靈活與控制的代價這類工具通常以Python庫的形式存在提供核心的RAG組件如文本加載、切分、向量化、檢索但需要你自行組裝流水線和搭建服務。它們適合有較強開發(fā)能力追求極致定制和控制的團隊。1. LangChain LangChain4j生態(tài)之王但需警惕“黑盒”核心定位這可能是目前知名度最高的LLM應用開發(fā)框架RAG只是其眾多功能模塊之一。它提供了極其豐富的“鏈”Chain和“智能體”Agent抽象以及海量的第三方集成各種文檔加載器、向量數(shù)據(jù)庫、LLM提供商。優(yōu)勢生態(tài)豐富幾乎你能想到的組件LangChain都有對應的集成快速原型驗證無敵。抽象層次高用很少的代碼就能串起一個完整的RAG流程對于演示和快速實驗非常友好。多語言支持LangChain4j是其Java版本讓Spring Boot等技術(shù)棧的團隊也能享受同款便利。痛點與實操心得注意LangChain的抽象在帶來便利的同時也隱藏了細節(jié)。如果不深入其源碼你很難確切知道一次檢索調(diào)用背后發(fā)生了什么參數(shù)如何傳遞錯誤如何拋出。這在調(diào)試復雜問題時會非常痛苦。性能開銷高級抽象鏈會帶來額外的函數(shù)調(diào)用開銷在追求低延遲Low Latency的生產(chǎn)場景中需要謹慎評估。版本迭代快API變動相對頻繁幾個月前的代碼可能就需要調(diào)整。我的建議用它來做原型設計和探索但在構(gòu)建對穩(wěn)定性和性能有要求的生產(chǎn)服務時考慮基于其核心思想進行“淺度使用”或自己實現(xiàn)關鍵環(huán)節(jié)。例如只用它的文檔加載和切分模塊而用自己的向量檢索和重排邏輯。2. LlamaIndex專為RAG而生的“數(shù)據(jù)框架”核心定位如果說LangChain是“應用框架”那么LlamaIndex就更專注于“數(shù)據(jù)層”。它將自己定義為LLM的數(shù)據(jù)連接框架核心優(yōu)勢在于對異構(gòu)數(shù)據(jù)文本、PDF、SQL、API等的索引結(jié)構(gòu)Index設計。優(yōu)勢索引結(jié)構(gòu)強大提供了向量索引、關鍵詞索引、組合索引等多種索引類型甚至支持圖索引能更好地捕獲文檔間的復雜關系。查詢引擎靈活除了簡單的檢索還支持基于索引的復雜查詢?nèi)缱硬樵?、多步推理等對于復雜問答效果更好。對長文檔處理友好其“節(jié)點”Node和“檢索器”Retriever的設計讓長文檔的切片和上下文管理更精細。痛點與實操心得學習曲線其核心概念索引、節(jié)點、檢索器、查詢引擎需要一定時間理解不如LangChain上手直觀。生態(tài)相對專注雖然也集成很多組件但不像LangChain那樣“萬物皆可鏈”更聚焦于數(shù)據(jù)檢索增強本身。我的建議當你面臨的數(shù)據(jù)源非常復雜混合了結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)或者查詢邏輯需要超越簡單的語義搜索時LlamaIndex是比LangChain更專業(yè)的選擇。它能讓你的RAG系統(tǒng)在“智商”上更勝一籌。2.2 一體化框架開箱即用的生產(chǎn)力這類工具旨在提供一個更完整的、可部署的解決方案通常包含了前端界面、后端服務和基礎的管理功能幫你省去大量搭建界面的工作。3. Spring AI 向量數(shù)據(jù)庫如MilvusJava生態(tài)的堅實組合核心定位Spring AI是Spring官方推出的AI應用開發(fā)框架旨在為Java/Kotlin開發(fā)者提供類似LangChain的編程模型。結(jié)合Milvus、PgVectorPostgreSQL擴展等向量數(shù)據(jù)庫可以構(gòu)建出高性能、易維護的RAG服務。優(yōu)勢Spring生態(tài)無縫集成如果你團隊的主力是Spring Boot那么Spring AI幾乎是無痛接入。依賴注入、配置管理、監(jiān)控告警都能沿用現(xiàn)有體系。類型安全與工程化Java的強類型特性加上Spring的工程化最佳實踐使得構(gòu)建大型、穩(wěn)定的生產(chǎn)級服務更有信心。性能與可控性自己掌控整個服務棧從HTTP服務器、業(yè)務邏輯到向量檢索可以進行深度優(yōu)化。實操要點組件選型Spring AI負責與LLMOpenAI、Azure、本地模型交互和提示詞管理。向量數(shù)據(jù)庫的選擇至關重要Milvus專為向量搜索設計性能最強但運維復雜PgVector作為PostgreSQL擴展運維簡單與現(xiàn)有業(yè)務數(shù)據(jù)庫兼容性好但性能有上限。根據(jù)數(shù)據(jù)量百萬級以下PgVector可能夠用以上考慮Milvus和團隊運維能力選擇。示例流程使用Apache Tika或PDFBox解析文檔。用遞歸字符分割或語義分割算法進行文本切片。調(diào)用Spring AI的EmbeddingClient接口可接OpenAI、本地SentenceTransformer模型生成向量。將向量和元數(shù)據(jù)存入Milvus或PgVector。用戶提問時先將問題向量化在向量數(shù)據(jù)庫中進行相似性檢索。將檢索到的文本片段作為上下文通過Spring AI的ChatClient構(gòu)造提示詞發(fā)給LLM生成答案。我的建議這是中型以上Java團隊構(gòu)建私有化、高性能RAG服務的首選路徑。它平衡了開發(fā)效率、系統(tǒng)性能和運維可控性。4. 基于Coze/Dify等低代碼平臺的快速搭建核心定位這類平臺提供了可視化的編排界面通過拖拽組件知識庫、LLM、提示詞、條件判斷就能構(gòu)建AI應用內(nèi)置了RAG所需的大部分能力。優(yōu)勢極致快速無需編寫代碼幾分鐘就能創(chuàng)建一個可用的知識庫問答機器人。降低門檻產(chǎn)品、運營等非技術(shù)角色也能直接參與構(gòu)建和調(diào)試AI應用。集成度高通常直接集成多種大模型、語音、多模態(tài)等能力。痛點與局限黑盒化與定制難平臺隱藏了所有技術(shù)細節(jié)當你有特殊需求如自定義切片規(guī)則、特定的重排算法時會感到束手無策。數(shù)據(jù)安全與隱私知識庫數(shù)據(jù)存儲在平臺方對于敏感數(shù)據(jù)需要評估風險。私有化部署版本通常價格不菲。性能與規(guī)模瓶頸面對海量文檔十萬級以上或高并發(fā)查詢云平臺的性能可能遇到瓶頸且優(yōu)化手段有限。我的建議適用于快速原型驗證、內(nèi)部不敏感數(shù)據(jù)的知識庫、或者作為市場/運營部門的輕量級工具。對于核心業(yè)務系統(tǒng)或?qū)?shù)據(jù)、性能有嚴格要求的場景慎用。2.3 云原生/企業(yè)級平臺面向規(guī)模與治理這類方案關注的是大規(guī)模、可觀測、可治理的企業(yè)級部署通常以云服務或高級開源項目的形式出現(xiàn)。5. 專為RAG優(yōu)化的向量數(shù)據(jù)庫Milvus, Weaviate, Qdrant核心定位它們本身不是“RAG工具”但卻是高性能RAG系統(tǒng)的基石。當你的數(shù)據(jù)量達到百萬、千萬級時傳統(tǒng)的方案如直接用PgVector就會成為瓶頸。橫向?qū)Ρ扰c選型特性MilvusWeaviateQdrant核心優(yōu)勢專為向量搜索設計性能極致功能豐富多向量、標量過濾、時間旅行。內(nèi)置向量圖數(shù)據(jù)庫支持數(shù)據(jù)對象與向量一體化存儲自帶簡單GraphQL API。Rust編寫輕量高效API簡潔云服務友好動態(tài)量化壓縮省內(nèi)存。部署復雜度較高分布式架構(gòu)組件多。中等。低單二進制文件可容器化。生態(tài)與語言主流語言SDK齊全社區(qū)活躍。側(cè)重Python/Go內(nèi)置模塊化設計。主流語言SDK齊全。適用場景超大規(guī)模向量檢索對延遲和召回率有極致要求。需要結(jié)合向量與對象屬性進行復雜查詢的場景。需要快速部署、云原生、對資源敏感的中大規(guī)模場景。實操心得索引選擇是關鍵HNSW圖索引適合高召回、高查詢速度的場景但內(nèi)存占用大IVF類索引如IVF_FLAT內(nèi)存占用小但需要訓練適合大規(guī)模數(shù)據(jù)。生產(chǎn)環(huán)境通常需要根據(jù)數(shù)據(jù)分布進行測試調(diào)優(yōu)。過濾查詢一定要用好標量過濾Metadata Filtering比如按文檔來源、時間過濾能極大提升檢索準確性和速度。我的建議數(shù)據(jù)量在千萬以下Qdrant是平衡易用與性能的甜蜜點千萬以上且團隊有運維能力考慮Milvus如果需要頻繁做基于對象屬性的關聯(lián)查詢看看Weaviate。6. Agentic RAG讓RAG擁有“思考”能力核心定位這是RAG的高級形態(tài)也是當前的研究熱點。傳統(tǒng)的RAG是“一次檢索一次生成”。Agentic RAG則引入了智能體Agent的概念讓系統(tǒng)能進行多步推理、判斷、甚至調(diào)用工具。核心模式自適應檢索Self-RAG讓LLM自己判斷是否需要檢索、檢索什么關鍵詞、以及如何評估檢索結(jié)果的相關性。這能避免無關查詢也去搜庫提升效率。多智能體協(xié)作可以設計不同的智能體分工合作例如一個“規(guī)劃智能體”分解復雜問題一個“檢索智能體”負責找資料一個“驗證智能體”檢查答案一致性。工具調(diào)用集成RAG智能體不僅可以查知識庫還能調(diào)用計算器、搜索引擎、業(yè)務API等解決純文本知識庫無法覆蓋的問題。實現(xiàn)方式目前沒有完全開箱即用的產(chǎn)品多在LangChain/LlamaIndex的Agent框架上結(jié)合ReAct、Plan-and-Execute等模式進行構(gòu)建。OpenAI的Assistant API也提供了函數(shù)調(diào)用和檢索的初步結(jié)合。我的建議Agentic RAG是解決復雜、多跳問答的利器但復雜度劇增調(diào)試困難。建議在基礎RAG流程完全跑通并穩(wěn)定后再針對特定場景如復雜數(shù)據(jù)分析、多步驟決策支持進行探索。7. 多模態(tài)RAG超越文本的認知核心定位讓RAG系統(tǒng)能夠理解和處理圖像、表格、音頻、視頻等多模態(tài)數(shù)據(jù)。用戶不僅可以問“某份報告里說了什么”還可以問“這張圖表反映了什么趨勢”或“視頻里演示了哪個步驟”技術(shù)棧核心多模態(tài)嵌入模型如CLIP能將圖像和文本映射到同一向量空間實現(xiàn)跨模態(tài)檢索。多模態(tài)大模型MLLM如GPT-4V能理解圖像內(nèi)容并基于此進行對話。專用解析器用于從PDF中提取表格和圖表從視頻中提取關鍵幀和字幕。典型流程將文檔中的圖片、表格單獨提取。使用多模態(tài)嵌入模型為這些非文本內(nèi)容生成向量并與文本切片一起存入向量數(shù)據(jù)庫需支持多模態(tài)向量。用戶提問時系統(tǒng)同時進行文本檢索和跨模態(tài)檢索將相關的文本和圖像片段一起作為上下文提供給MLLM生成答案。挑戰(zhàn)與現(xiàn)狀技術(shù)復雜度高流程更長模型更重MLLM通常很昂貴。評估困難如何評估圖像檢索的相關性和最終答案的質(zhì)量缺乏標準。我的建議多模態(tài)RAG是前沿方向在醫(yī)療分析影像報告、教育圖文并茂教材、電商商品搜索等領域有巨大潛力。但目前更適合作為前瞻性技術(shù)儲備或針對特定高價值場景的POC大規(guī)模應用成本和技術(shù)成熟度仍需觀望。3. RAG核心環(huán)節(jié)的通用實戰(zhàn)要點無論你選擇哪種工具一套RAG系統(tǒng)都繞不開以下幾個核心環(huán)節(jié)。工具可以幫你簡化但理解其中的門道才能避免踩坑。3.1 文檔接入、清洗與切片質(zhì)量決定上限這是最臟最累但最重要的一步。垃圾進垃圾出。文檔解析PDF是噩夢格式復雜掃描件、雙層PDF、圖表多的PDF。PyPDF、pdfplumber對付簡單文本還行Unstructured庫更強大但重。對于復雜PDF商業(yè)OCR引擎Azure Form Recognizer, AWS Textract或開源方案PaddleOCR幾乎是必須的。實操心得一定要做解析后的質(zhì)量抽樣檢查。特別是表格和代碼塊經(jīng)常被解析得亂七八糟。可以寫一個簡單的腳本隨機抽取解析后的文本片段與原文對比。文本清洗去除無意義的頁眉頁腳、版權(quán)聲明、亂碼。規(guī)范化空格、換行符。對于中文可能需要處理全半角字符。文本切片Chunking固定長度重疊切片最簡單用LangChain的RecursiveCharacterTextSplitter即可。關鍵參數(shù)是chunk_size和chunk_overlap。chunk_size通常設置在256-1024之間token數(shù)overlap建議在chunk_size的10%-20%以保證上下文連貫。語義切片更高級利用句子嵌入模型在語義邊界處切分。LangChain的SemanticChunker或sentence-transformers庫可以實現(xiàn)。這對長文檔、邏輯性強的文本如論文、手冊效果更好但計算開銷大。混合切片先按固定長度粗切再對每個粗切片進行語義判斷是否需要合并或再切分。注意沒有一種切片方式適合所有文檔類型。最好的方法是用小批量數(shù)據(jù)測試不同切片策略對最終問答效果的影響。一個簡單的評估方法是用一些典型問題去檢索看返回的切片是否完整包含了答案所需的信息。3.2 向量化與索引構(gòu)建檢索效率的引擎嵌入模型選擇通用vs領域通用模型如text-embedding-ada-002,BGE,Sentence Transformers在大多數(shù)場景下表現(xiàn)良好。如果你的領域非常專業(yè)如生物醫(yī)學、法律使用在該領域語料上微調(diào)過的嵌入模型效果會有顯著提升。尺寸與速度模型維度越高如1024通常表征能力越強但存儲和計算成本也越高。需要權(quán)衡。BGE的BAAI/bge-small-zh是一個在中文上表現(xiàn)不錯且輕量的選擇。實操建議在本地部署一個中等規(guī)模的Sentence Transformer模型如all-MiniLM-L6-v2作為基線與OpenAI的嵌入API進行效果和成本的對比測試。對于生產(chǎn)環(huán)境如果數(shù)據(jù)敏感或查詢量大本地部署是更可控的選擇。索引構(gòu)建策略全量重建 vs 增量更新知識庫文檔頻繁更新嗎如果每天都有新文檔你需要設計增量索引更新流程而不是每次都全量重建。一些向量數(shù)據(jù)庫如Qdrant支持upsert操作。分布式索引當單機內(nèi)存/磁盤無法容納全部向量時必須使用支持分布式的向量數(shù)據(jù)庫如Milvus集群。元數(shù)據(jù)設計除了向量一定要存儲豐富的元數(shù)據(jù)如document_id,chunk_id,source,author,timestamp等。這是后續(xù)進行高效過濾和溯源的基礎。3.3 召回與重排序策略精準命中的關鍵這是提升答案質(zhì)量最有效的環(huán)節(jié)之一。簡單向量搜索召回的結(jié)果可能包含相關但不精確的片段。混合檢索問題純向量搜索可能因為語義相似但主題不相關而“誤傷”例如問“蘋果手機”可能搜出關于“吃蘋果”的文檔。純關鍵詞搜索如BM25又無法理解語義。方案同時進行向量檢索和關鍵詞檢索然后合并結(jié)果。這就是混合檢索。LangChain的EnsembleRetriever可以輕松實現(xiàn)。權(quán)重調(diào)優(yōu)給向量檢索和關鍵詞檢索的結(jié)果賦予不同的權(quán)重如0.7和0.3這個比例需要根據(jù)你的數(shù)據(jù)特點進行調(diào)優(yōu)。重排序目的混合檢索返回了N個候選片段例如30個需要從中選出最相關的K個例如5個送給LLM。重排序模型就是干這個的。模型選擇可以使用專門的交叉編碼器模型如BGE-reranker,Cohere rerank它們比用于檢索的雙編碼器模型更精細但計算更慢。通常流程是先用快速的向量/關鍵詞檢索召回100個再用重排序模型精排前10個。實操技巧重排序模型雖然慢但因為它只對少量候選100進行操作且可以批量處理總體延遲增加在可接受范圍內(nèi)對精度提升卻非常明顯強烈建議在生產(chǎn)系統(tǒng)中加入此環(huán)節(jié)。檢索結(jié)果沖突與消解現(xiàn)象當知識庫中存在多個來源、或更新前后版本對同一事實描述不一致時檢索結(jié)果可能互相沖突。應對策略元數(shù)據(jù)過濾與優(yōu)先級為文檔來源設置可信度權(quán)重如官方手冊 技術(shù)博客 用戶討論。檢索時按權(quán)重排序或過濾。時間戳過濾對于時效性強的知識優(yōu)先返回最新版本的文檔。LLM仲裁在提示詞中明確告訴LLM“以下是檢索到的多個可能矛盾的資料請根據(jù)其來源可靠性和時效性綜合判斷并給出最可能的答案?！边@需要LLM具備較強的推理能力。4. 生產(chǎn)環(huán)境部署與性能調(diào)優(yōu)實錄讓一個RAG原型跑起來不難難的是讓它穩(wěn)定、快速、可靠地服務成千上萬的請求。4.1 架構(gòu)設計考量服務拆分建議將嵌入生成服務、向量檢索服務和LLM推理服務拆分開。這有助于獨立擴縮容。例如檢索請求量大就擴向量數(shù)據(jù)庫生成任務重就擴LLM服務。緩存策略嵌入緩存常見問題的嵌入向量可以緩存起來避免重復計算。結(jié)果緩存對于完全相同的查詢可以直接緩存最終的LLM回答注意設置合理的TTL。異步處理文檔解析、向量化等耗時操作應該放入任務隊列如Celery, RabbitMQ異步執(zhí)行避免阻塞主請求線程。4.2 性能與延遲優(yōu)化低延遲Low Latency服務這是chimera等論文關注的核心。多智能體服務中延遲是關鍵。嵌入模型輕量化在效果可接受的前提下選擇更小的嵌入模型。向量索引優(yōu)化在向量數(shù)據(jù)庫中為索引選擇更快的參數(shù)如HNSW的ef_construction和ef_search參數(shù)需要權(quán)衡構(gòu)建速度和查詢速度。LLM調(diào)用優(yōu)化使用流式響應Streaming讓用戶盡快看到首個token。考慮使用LLM的異步API。對于簡單問題可以嘗試更小、更快的模型如GPT-3.5-TurbovsGPT-4。批量處理對于文檔入庫的向量化操作一定要采用批量推理而不是一條條處理可以極大提升吞吐量。4.3 監(jiān)控與評估可觀測性必須監(jiān)控關鍵指標應用層請求量、響應時間P50, P95, P99、錯誤率。組件層向量數(shù)據(jù)庫查詢耗時、LLM API調(diào)用耗時與token消耗。業(yè)務層檢索召回率、答案準確率需要人工或LLM-as-a-judge定期評估。評估體系離線評估構(gòu)建一個包含問題標準答案相關文檔的測試集。評估檢索模塊的召回率RecallK以及最終問答的準確率、忠實度答案是否嚴格來自上下文、信息量。在線評估收集用戶反饋如點贊/點踩或設計AB測試對比不同策略如加不加重排序的效果。5. 常見問題排查與避坑指南這里記錄了我自己和同行們踩過的一些典型坑。問題1LLM回答“根據(jù)提供的信息無法回答此問題”但明明知識庫里有相關內(nèi)容。排查檢索環(huán)節(jié)檢查檢索到的片段是否真的包含答案?？赡苁乔衅缓侠戆汛鸢盖兴榱?。也可能是嵌入模型不合適導致問題與文檔的向量不匹配。提示詞環(huán)節(jié)檢查你的提示詞Prompt是否明確指令LLM必須基于上下文回答。經(jīng)典的提示詞模板是“請嚴格根據(jù)以下上下文來回答問題。如果上下文不包含答案請說‘根據(jù)已知信息無法回答’。上下文{context}。問題{question}”。上下文長度檢索到的上下文總長度是否超過了LLM的上下文窗口限制導致后面的片段被截斷。解決優(yōu)化切片策略調(diào)整檢索的top_k參數(shù)強化提示詞指令使用LLM的更長上下文版本。問題2回答的內(nèi)容與知識庫無關像是LLM在“胡編亂造”。原因這是“幻覺”問題。當檢索到的上下文相關性不強或者LLM的指令遵循能力不夠時容易發(fā)生。解決提升檢索質(zhì)量混合檢索重排序。在提示詞中增加限制“你的回答必須完全基于提供的上下文不要引入外部知識?！笨紤]使用“引用”功能讓LLM在生成答案時標注出處如[1]這也能變相約束它。問題3系統(tǒng)響應速度很慢用戶體驗差。瓶頸定位使用鏈路追蹤如OpenTelemetry或詳細日志記錄每個環(huán)節(jié)的耗時文本預處理、向量化、向量檢索、重排序、LLM生成。常見瓶頸點向量數(shù)據(jù)庫查詢慢檢查索引是否構(gòu)建合理ef_search參數(shù)是否設置過高查詢時是否使用了低效的過濾條件LLM API調(diào)用慢網(wǎng)絡延遲模型本身慢考慮更換區(qū)域或使用更快的模型。嵌入生成慢是否在實時請求中同步調(diào)用嵌入模型考慮預計算或使用更快的本地小模型。問題4知識庫更新后回答還是舊內(nèi)容。原因向量數(shù)據(jù)庫索引沒有更新或者緩存沒有失效。解決建立規(guī)范的文檔更新流程。更新源文檔后觸發(fā)對應的向量索引更新增量或全量。同時清除或更新相關的查詢緩存。問題5如何處理非常長或結(jié)構(gòu)復雜的文檔如整本書、帶大量圖表的手冊策略分層索引建立多級索引。第一級是章節(jié)摘要第二級是段落細節(jié)。用戶先檢索到相關章節(jié)再在該章節(jié)內(nèi)進行精細檢索。圖索引如果文檔內(nèi)部有很強的邏輯關系如API文檔可以使用LlamaIndex的圖索引來捕獲這種關系實現(xiàn)更智能的多跳查詢。摘要嵌入為每個長文檔或章節(jié)生成一個摘要將摘要向量化用于首輪粗篩。選擇RAG工具本質(zhì)上是選擇一套適合自己當前和未來一段時間內(nèi)技術(shù)棧、團隊能力和業(yè)務需求的“腳手架”。沒有銀彈從簡單方案開始逐步迭代持續(xù)監(jiān)控和評估才是通往穩(wěn)定高效RAG系統(tǒng)的不二法門。我最深的體會是RAG項目30%是算法和模型70%是數(shù)據(jù)工程和系統(tǒng)設計。把數(shù)據(jù)管道做扎實把系統(tǒng)架構(gòu)設計得清晰可擴展遠比追求某個最新潮的模型或框架來得重要。