把一份五十頁的年度財報丟給大模型讓它準(zhǔn)確說出“去年第四季度毛利率是多少比第三季度變化了多少”你會得到什么如果直接問通用大模型它大概率會給你一個看似合理、其實是編出來的數(shù)字。這正是我想通過 Financial RAG Demo 解決的核心問題用一條完整的RAG服務(wù)鏈路把金融文檔變成可問答、可溯源、可驗證的“本地知識庫”。這篇內(nèi)容會完整拆解這個Demo從文檔解析、切片、向量檢索到生成回答的整個設(shè)計與實操過程適合正在做知識庫問答、金融NLP場景或者剛接觸RAG應(yīng)用開發(fā)的同學(xué)參考。金融場景對RAG的要求和通用文檔問答不太一樣數(shù)據(jù)密度高、術(shù)語密集、表格多、對數(shù)字準(zhǔn)確性要求極高。整個Demo做完我最大的感受是RAG服務(wù)的難點不在“接入大模型”而在前面的數(shù)據(jù)準(zhǔn)備和檢索質(zhì)量。鏈路中任何一個環(huán)節(jié)偷懶最后都會在回答質(zhì)量上暴露出來。下面直接進入正題按我實際開發(fā)的順序把所有關(guān)鍵技術(shù)決策和踩坑經(jīng)驗逐一講清楚。1. 為什么做Financial RAG Demo金融場景對RAG服務(wù)的特殊要求1.1 金融文檔問答難在哪里金融領(lǐng)域的文檔管理是個典型的海量數(shù)據(jù)場景。上市公司的年報、季報、臨時公告、研報、監(jiān)管政策文件動輒幾十上百頁PDF格式居多內(nèi)部還塞滿了財務(wù)報表、管理層討論、腳注注釋。過去這些文檔的利用方式基本就是“存起來、搜出來、人肉看”想要跨文檔得到一個綜合性的答案效率非常低。我把這個項目定位在“金融文檔問答”而不是泛泛的“聊天機器人”就是因為金融問答有幾個很難繞開的痛點。第一個痛點是術(shù)語密集。像“毛利率”“凈資產(chǎn)收益率”“經(jīng)營活動產(chǎn)生的現(xiàn)金流量凈額”這種表述一個概念有多種叫法縮寫和全稱混用。通用問答系統(tǒng)很難理解這些術(shù)語之間的關(guān)聯(lián)檢索時容易出現(xiàn)“關(guān)鍵詞命中了但拿到的段落根本不是用戶想問的那個指標(biāo)”。第二個痛點是數(shù)字敏感。金融問答最怕胡說一個人問“去年研發(fā)投入多少錢”如果系統(tǒng)回答里數(shù)字跟真實財報對不上這個系統(tǒng)基本就失去信任了。數(shù)字對錯的根源往往不在大模型而在檢索階段有沒有把正確的表格和上下文段落召回來。RAG服務(wù)如果不針對表格做專門處理檢索到的內(nèi)容經(jīng)常是殘缺的。第三個痛點是來源必須可溯?！案鶕?jù)哪份報告、哪一頁得出這個結(jié)論”在金融場景幾乎是剛需?；鸾?jīng)理、風(fēng)控人員、研究員拿到一個AI回答第一反應(yīng)就是去看原始依據(jù)。沒有引用來源的答案在金融場景等于無效答案。第四個痛點是時效性。財報是定期發(fā)布的公告是實時增加的模型固有的知識永遠滯后。RAG天然適合這種“知識庫持續(xù)變化、需要即時更新”的場景換數(shù)據(jù)源就能換知識不需要重新訓(xùn)練。1.2 為什么是RAG而不是微調(diào)大模型在做這個Demo之前一個繞不開的問題是為什么不用微調(diào)的方式把財報內(nèi)容直接喂給大模型訓(xùn)練我當(dāng)時把兩種方案放在一起對比過結(jié)論非常明確。對比維度RAG方案全量微調(diào)方案知識更新成本換索引、加文檔即可分鐘級生效需要重新訓(xùn)練小時到天級成本高輸出可信度回答基于檢索到的原文片段可溯源知識固化在參數(shù)里無法定位證據(jù)幻覺控制能力可在提示詞層強約束“只能依據(jù)上下文”模型容易把訓(xùn)練知識與上下文混雜實施成本無需訓(xùn)練GPU開發(fā)成本集中在檢索鏈路需要訓(xùn)練環(huán)境和高質(zhì)量標(biāo)注數(shù)據(jù)適合場景動態(tài)知識庫、專有文檔、持續(xù)更新的資料固定領(lǐng)域語料的指令遵循能力提升微調(diào)解決的是“讓模型更懂這個領(lǐng)域的說話方式”而不是“讓模型記住這份文檔里寫了什么”。你把一份三千行的財報PDF塞進微調(diào)數(shù)據(jù)集訓(xùn)練完之后你問它其中某個具體數(shù)字它依然可能編造。因為大模型的學(xué)習(xí)本質(zhì)是壓縮和泛化不是精確存儲。RAG的思路完全不同我不要求模型記住文檔內(nèi)容我只要求它學(xué)會“基于給定的材料回答問題”。知識存儲在檢索系統(tǒng)里模型負(fù)責(zé)組織和表達。這一層解耦是金融場景格外看重的因為文檔是流動的、權(quán)限是分級的、答案是必須能翻到原始頁面的。1.3 Demo項目的目標(biāo)與邊界一個Demo不能什么都做否則會變成“什么都很糙的半成品”。我在動手之前先劃定了邊界明確這個Financial RAG Demo要證明三件事一是能對結(jié)構(gòu)化程度低的金融PDF完成高質(zhì)量解析與切片二是能準(zhǔn)確檢索到包含關(guān)鍵數(shù)字和對比信息的片段三是能基于檢索內(nèi)容生成帶來源引用的可讀回答。演示數(shù)據(jù)源我選的是公開的模擬財報PDF、模擬公司公告和模擬行業(yè)研報一共準(zhǔn)備了十幾份。為什么不直接用真實財務(wù)數(shù)據(jù)一是合規(guī)風(fēng)險二是不想在Demo階段花大量時間處理數(shù)據(jù)授權(quán)問題。模擬數(shù)據(jù)已經(jīng)足夠把鏈路跑通、把問題暴露出來。這個項目的定位是“最小可用的金融問答參考實現(xiàn)”不是生產(chǎn)級系統(tǒng)。在這個定位下我要的是快速驗證方案、沉淀可復(fù)用的工程代碼而不是一開始就去追求過高的準(zhǔn)確率。2. RAG鏈路逐個拆從金融PDF到可信答案2.1 文檔解析金融PDF結(jié)構(gòu)化處理不能只做文本抽取RAG服務(wù)的上游是文檔解析。很多人一開始覺得解析很簡單不就是把PDF里的文字提取出來嘛。金融PDF分分鐘教你做人。我遇到的第一個坑是表格。財報的利潤表、資產(chǎn)負(fù)債表、現(xiàn)金流量表全是表格。如果用最簡單的文本抽取工具直接提取表格會變成一行行沒有任何結(jié)構(gòu)邏輯的文字堆疊數(shù)字和項目名稱的對應(yīng)關(guān)系全部丟失。比如“營業(yè)收入 1023456789”和“營業(yè)成本 987654321”在一張表里提取成純文本后你根本不知道哪個數(shù)字對應(yīng)哪個指標(biāo)。要解決這個問題必須使用能識別表格結(jié)構(gòu)邊界、能按單元格關(guān)系輸出的解析流程。我實際用的方案是兩層處理先用布局分析方式識別頁面中的文本塊和表格區(qū)域再對表格區(qū)域單獨走表格結(jié)構(gòu)識別邏輯嘗試還原出行列關(guān)系。解析完成后每條內(nèi)容都帶上坐標(biāo)信息、所在頁碼和所屬章節(jié)標(biāo)題這一步為后面的切片和引用打基礎(chǔ)。頁眉頁腳也是必須去掉的不然每頁重復(fù)的“某某公司2023年年度報告”字樣會被切進多個切片檢索時嚴(yán)重干擾相關(guān)性排序。這里有一個容易被忽視的點解析結(jié)果不要直接扔給切片器而是要轉(zhuǎn)成統(tǒng)一的中間結(jié)構(gòu)。我給每個文檔塊設(shè)計了一個簡單的元數(shù)據(jù)模型包括doc_id、page、section、content、type文本/表格/圖表標(biāo)題字段。后面所有環(huán)節(jié)都依賴這套元數(shù)據(jù)作用類似給每塊內(nèi)容貼上了身份證檢索到之后能回答“這段出自哪里”。2.2 切片策略保留語義、保住上下文、還要留得住表格切片是RAG里看似簡單、實際影響非常大的環(huán)節(jié)。切片太粗檢索粒度大相關(guān)性漂移嚴(yán)重一個大片段里只含一小段有效信息浪費向量空間切片太細(xì)語義不完整一個財務(wù)指標(biāo)的定義被切斷或者表格的表頭和數(shù)據(jù)被拆到兩個切片里檢索到了也沒法用。我測試過三種切片方式結(jié)果差異非常明顯切片方式優(yōu)點缺點適合場景固定長度切片如每512字一刀實現(xiàn)簡單索引穩(wěn)定切斷段落語義表格極易拆散純文本資料按章節(jié)/標(biāo)題切片語義完整邊界自然章節(jié)長度差異大長章節(jié)片段過大結(jié)構(gòu)化良好的文檔自定義語義切片標(biāo)題段落表格保護兼顧語義與檢索精度需要額外開發(fā)規(guī)則金融財報、公告我最終用的是第三種核心邏輯很簡單先把文檔按標(biāo)題層級切成大的區(qū)塊再對超過長度閾值的區(qū)塊按段落邊界二次切分同時加了一個保護規(guī)則——表格區(qū)域凡是檢測到表頭和首行數(shù)據(jù)的就整個作為一個獨立切片不允許切散。切片之間加少量重疊窗口避免把一個概念的結(jié)尾和下一個概念的開頭隔開。重疊窗口大小我設(shè)了64個字符左右。這個數(shù)值不是拍腦袋定的是通過檢索召回率對比得出來的。太小起不到銜接作用太大會讓相鄰切片高度相似檢索結(jié)果里出現(xiàn)四五條高度重復(fù)的內(nèi)容白白占用上下文窗口。2.3 Embedding與檢索混合檢索加排序為什么是標(biāo)配這個Demo的檢索模塊沒有只依賴向量相似度而是用了“稀疏檢索稠密檢索”的混合方案。原因很現(xiàn)實向量檢索擅長處理語義相近但字面不同的表達比如“公司賺了多少錢”和“凈利潤”的語義關(guān)聯(lián)但在金融場景關(guān)鍵詞精確匹配依然非常重要尤其是年份、股票代碼、專有指標(biāo)名這種字符特征強烈的查詢稀疏檢索的精確命中率往往高于向量召回。我使用的Embedding特征不是自己訓(xùn)練的而是選擇了在通用語料上預(yù)訓(xùn)練好的模型來生成向量。選擇模型時主要看兩方面一是對中文長文檔的支持二是金融術(shù)語的理解能力。實測下來通用Embedding模型對“ROE”“經(jīng)營性現(xiàn)金流”這類術(shù)語的字面匹配還行但有時會抓不住“股東回報能力”這種同義表達。當(dāng)時時間有限沒有自訓(xùn)練模型但我在檢索層做了補償加入BM25稀疏召回再用重排序模型把兩路結(jié)果合并打分這樣即使向量語義召回沒抓住精確關(guān)鍵詞BM25也能補位反之亦然?；旌蠙z索的合并我用的是RRF算法對兩路候選按排名融合而不是簡單加權(quán)平均分?jǐn)?shù)。因為不同檢索算法產(chǎn)出的分?jǐn)?shù)區(qū)間差異很大直接加權(quán)容易被某一方帶偏。排序階段再通過一個輕量級的重排序模型對召回的Top 20段重新打分取Top 5作為上下文。這一步的效果立竿見影Top 5命中率明顯提升冗余內(nèi)容也被濾掉不少。2.4 生成增強提示詞約束、來源引用與拒答機制檢索做得再好生成環(huán)節(jié)設(shè)計不到位回答質(zhì)量同樣拉跨。我在提示詞層面做了三個重要設(shè)計。第一個是上下文約束。原原本本在系統(tǒng)提示詞里寫清楚“只根據(jù)下面提供的資料回答問題。如果資料未提及直接回答‘未在現(xiàn)有資料中找到相關(guān)信息’嚴(yán)禁編造?！边@是對抗幻覺的第一道防線雖然不能完全消除幻覺但能大幅降低模型自由發(fā)揮的概率。第二個是來源標(biāo)注。我要求模型在回答的每個關(guān)鍵結(jié)論后用中括號標(biāo)注資料編號例如“[資料1][資料3]”。這些編號對應(yīng)檢索結(jié)果的元數(shù)據(jù)最終在展示層映射回“報告名稱頁碼”。用戶看到數(shù)字想核實只要照著頁碼翻原文就行。這是金融場景必須有的能力。第三個是拒答機制。對于檢索相關(guān)度不夠高的提問我設(shè)置了一個門檻邏輯如果重排序后的最高分?jǐn)?shù)低于設(shè)定閾值或者上下文與問題的關(guān)鍵詞重疊度太低服務(wù)端就直接返回“當(dāng)前資料庫中沒有覆蓋到您的問題”。寧可說不知道也不硬答。這個思路在可靠性要求高的場景非常值得推廣。3. 實操記錄我如何搭起這個RAG服務(wù)3.1 技術(shù)選型與環(huán)境準(zhǔn)備技術(shù)選型只有一個原則能用最簡方案搞定的就不引入重型組件。整套RAG服務(wù)驗證下來我的核心組成是一個PDF解析模塊負(fù)責(zé)布局分析和文本抽取、一個向量化模塊負(fù)責(zé)將切片轉(zhuǎn)為向量、一個向量數(shù)據(jù)庫負(fù)責(zé)存儲和召回、一個搜索引擎做BM25稀疏檢索、一個重排序模型負(fù)責(zé)精排以及一個大模型服務(wù)負(fù)責(zé)生成最終答案。為什么向量數(shù)據(jù)庫我選了本地部署而不是云服務(wù)因為這個Demo涉及金融資料處理數(shù)據(jù)不出本地是更穩(wěn)妥的姿態(tài)。實際選型時看重的點也不復(fù)雜是否支持過濾條件、是否有穩(wěn)定易用的客戶端、查詢延遲能不能控制在幾百毫秒以內(nèi)。開源方案完全夠用。大模型這一層我同時測試了本地部署的開源輕量模型和商業(yè)API兩種方案。Demo階段為了效果展示更穩(wěn)定最終選擇了API方式因為顯卡資源有限。但代碼層面我把模型服務(wù)封裝成了可替換的接口后期如果要在純內(nèi)網(wǎng)環(huán)境部署只需要把接口實現(xiàn)換成本地模型其他邏輯完全不用動。這一點對金融項目尤其重要因為生產(chǎn)環(huán)境很可能不允許調(diào)用外部服務(wù)。3.2 離線索引構(gòu)建的完整流程索引構(gòu)建是RAG服務(wù)的離線環(huán)節(jié)我剛才梳理了一下完整流程大概是這樣的讀取PDF文件逐頁做布局分析識別正文、表格區(qū)域和頁眉頁腳對表格區(qū)域走表格結(jié)構(gòu)還原邏輯整理成帶有行列信息的Markdown格式文本將每頁內(nèi)容按“章節(jié)切片區(qū)塊切分表格保護”的規(guī)則切分同時記錄元數(shù)據(jù)對每個切片做清洗去掉空白字符修正編碼問題調(diào)用Embedding接口生成向量將切片文本、元數(shù)據(jù)、向量全部寫入向量數(shù)據(jù)庫同時將文本寫入稀疏檢索引擎構(gòu)建完成后做一個抽樣自檢把幾個典型問題對應(yīng)的切片撈出來確認(rèn)內(nèi)容是否完整。清洗這一步在代碼里必須做好否則后面檢索會出現(xiàn)各種奇怪問題金融文本里常見的全角半角混用、制表符殘留、編號列表的縮進符號都需要在這一步抹平。索引構(gòu)建完成后我建議加個自動統(tǒng)計腳本輸出切片總數(shù)、平均長度、表格切片數(shù)量等指標(biāo)。這一步能幫你迅速發(fā)現(xiàn)解析環(huán)節(jié)有沒有出問題。我第一次跑完發(fā)現(xiàn)表格切片數(shù)量異常少回去排查才發(fā)現(xiàn)表格識別邏輯對某些樣式的表格失效了這個腳本直接幫我定位了問題非常實用。3.3 在線問答服務(wù)的關(guān)鍵代碼實現(xiàn)在線問答服務(wù)我拆成了三個模塊Query理解、檢索召回、生成回答。以下是我核心鏈路簡化后的實現(xiàn)邏輯# 檢索模塊混合召回 RRF融合 重排序 def retrieve_documents(query: str, top_k: int 20, final_k: int 5): # 1. 稀疏召回BM25 sparse_results sparse_searcher.search(query, top_k) # 2. 稠密召回向量 query_vector embedding_service.embed(query) dense_results vector_db.search(query_vector, top_k) # 3. RRF融合兩路結(jié)果 fused rrf_fusion(sparse_results, dense_results) # 4. 用重排序模型做精排取Top K reranked rerank_service.rerank(query, fused) return reranked[:final_k]# RRF融合按排名倒數(shù)累加分?jǐn)?shù) def rrf_fusion(sparse_results, dense_results, k: int 60): score_dict {} for rank, doc in enumerate(sparse_results): doc_id doc[id] score_dict[doc_id] score_dict.get(doc_id, 0) 1 / (k rank) for rank, doc in enumerate(dense_results): doc_id doc[id] score_dict[doc_id] score_dict.get(doc_id, 0) 1 / (k rank) return sorted(score_dict.items(), keylambda x: x[1], reverseTrue)生成模塊的提示詞我構(gòu)建成了一段結(jié)構(gòu)化的文本把檢索到的片段按編號排列并要求大模型嚴(yán)格按照編號引用請回答用戶問題。只允許參考下面列出的資料嚴(yán)禁使用資料以外的知識作答。 資料 [1] 來源模擬公司2023年度報告 第12頁 內(nèi)容報告期內(nèi)公司實現(xiàn)營業(yè)收入142.8億元同比增長18.5%... [2] 來源模擬公司2023年三季度報告 第5頁 ... 要求 - 回答每一點關(guān)鍵信息后標(biāo)注來源編號例如[1] - 若資料中沒有相關(guān)信息直接回復(fù)“現(xiàn)有資料中未找到相關(guān)信息” - 語言簡潔使用金融行業(yè)常用表述。有個接口細(xì)節(jié)必須注意問答接口的響應(yīng)時間幾乎全花在大模型生成上檢索階段一般耗時不大。用戶側(cè)體驗上建議加流式輸出一邊生成一邊推送而不是等全部生成完再一次性返回。金融場景里用戶看到的是逐段出現(xiàn)的答案加引用標(biāo)注體驗會好很多。3.4 演示界面與效果評估Demo要給別人看一個丑陋的命令行界面肯定不行。我花了一下午用輕量級Web框架搭了個極簡的聊天界面左側(cè)是文檔目錄和索引狀態(tài)右側(cè)是對話窗口回答內(nèi)容下面的“查看來源”按鈕可以直接定位到原始PDF的頁碼。界面本身只做展示重點是把檢索鏈路的所有中間信息暴露出來。展示中間信息是我特別堅持的一點。每次問答界面右側(cè)會顯示命中的Top 5片段、各片段的重排序分?jǐn)?shù)、用了哪些資料。別小看這個設(shè)計它能極大增強使用者的信任感也讓這個Demo更適合用于內(nèi)部技術(shù)評審。別人看到的不只是一個“漂亮的回答”而是一條可解釋的處理路徑。效果評估我建了一個小規(guī)模的人工評測集三十個問題覆蓋三類事實查詢型“去年營收是多少”、對比分析型“四季度毛利率環(huán)比變化”、跨文檔綜合型“兩份報告中關(guān)于研發(fā)投入的描述有什么差異”。我按四個維度打分檢索命中率、回答準(zhǔn)確率、來源引用準(zhǔn)確率、拒答合理率。初版全量跑完回答準(zhǔn)確率大概在七成左右后來經(jīng)過切片策略和重排序調(diào)優(yōu)后有明顯提升。這里說一句構(gòu)建評測集不需要很多條但要保證問題的典型性和多樣性比盲目堆數(shù)量有用得多。4. 踩坑實錄金融RAG的常見問題與排查4.1 表格數(shù)據(jù)解析后“散架”了我踩過無數(shù)次的坑表格數(shù)據(jù)解析成Markdown后行錯位、列錯位。原因很隱蔽PDF里某些單元格的文字過長會自動換行如果解析器沒有正確處理“單元格內(nèi)換行”就會把下一列的內(nèi)容頂?shù)较乱恍姓麄€表的結(jié)構(gòu)直接崩掉。排查方式是把解析后的表格與原文并排對比逐列檢查。修復(fù)方式有兩種一是選用對單元格邊界更敏感的解析配置二是在解析后增加一條校驗邏輯對項目名與數(shù)字的對應(yīng)關(guān)系做簡單規(guī)則檢查發(fā)現(xiàn)明顯異常就觸發(fā)重新解析。這個教訓(xùn)讓我明白一件事金融PDF解析永遠需要人工抽檢不能只看一兩個頁面的效果就默認(rèn)全部沒問題。4.2 財報數(shù)字檢索錯位指標(biāo)和數(shù)值對不上有一次測試問“經(jīng)營活動現(xiàn)金流凈額”系統(tǒng)返回的是“投資活動現(xiàn)金流”那個表的片段。乍一看兩個表結(jié)構(gòu)非常像但指標(biāo)名差了幾個字?jǐn)?shù)字完全不是用戶想要的。原因在于Embedding模型對“經(jīng)營活動”和“投資活動”這兩個高度相似短語的區(qū)分能力不足向量距離太近導(dǎo)致錯誤召回。解決辦法是引入字段級元數(shù)據(jù)的硬約束檢索時如果問題中識別到“經(jīng)營”“投資”“籌資”這類關(guān)鍵詞就在向量檢索的過濾條件中限定對應(yīng)的表頭區(qū)域不讓其他表的數(shù)據(jù)參與候選?；旌蠙z索加規(guī)則化是金融RAG必須有的組合純粹靠語義理解來處理財務(wù)術(shù)語的精確對應(yīng)目前還不可靠。4.3 金融縮寫與專業(yè)術(shù)語讓向量檢索失效“ROE”這個詞通用Embedding模型大概率能關(guān)聯(lián)到“凈資產(chǎn)收益率”但“EBITDA”這種更專業(yè)的縮寫向量召回效果就明顯差了。測試問“公司EBITDA情況”召回到的片段經(jīng)常是正文里順帶提到這個縮寫的那句話而不是真正披露指標(biāo)的表格頁。我之前一直強調(diào)混合檢索和重排序就是在這里發(fā)揮作用的。BM25對“EBITDA”這種精確詞命中很好重排序模型也能根據(jù)上下文重新識別真正包含指標(biāo)的表格段落。此外我還手動維護了一小份金融術(shù)語同義詞詞典查詢進來先做一遍術(shù)語擴展把“ROE”映射成“凈資產(chǎn)收益率”這樣一來向量檢索的命中率有明顯提高。4.4 答案仍然幻覺提示詞約束并不萬能就算提示詞寫了“嚴(yán)禁編造”模型在上下文中找不到明確答案時依然可能把相鄰年份的數(shù)據(jù)張冠李戴或者把上下文沒有的因果關(guān)系編出來。我見過最典型的情況是上下文中只有2022年和2023年的營收數(shù)據(jù)問“2021年營收”的時候模型硬是從兩句數(shù)據(jù)的表述里推測了一個數(shù)字還說得很篤定。應(yīng)對幻覺靠兩道防線。第一道是檢索質(zhì)量只要正確的切片被召回到Top位置幻覺概率就大降第二道是“拒答門檻”我在生成前置邏輯里加了相關(guān)性閘門如果檢索結(jié)果綜合分?jǐn)?shù)過低就不再調(diào)用生成接口而是直接返回提示讓用戶換種問法。前面提到過寧可答不上來也不要給一個貌似嚴(yán)謹(jǐn)?shù)腻e誤答案這在金融領(lǐng)域是一條底線。4.5 檢索性能與索引更新問題文本量放大之后檢索延遲會明顯上升。我曾在索引里塞了幾千份文檔發(fā)現(xiàn)一次查詢到了秒級趕緊查了原因——向量索引的索引參數(shù)沒有調(diào)優(yōu)導(dǎo)致暴力檢索。解決方式是把索引類型切換成更高效的近鄰檢索并調(diào)整構(gòu)建參數(shù)延遲立刻降到了百毫秒以內(nèi)。建議在壓測階段就關(guān)注這個參數(shù)不要等線上慢了再來排查。索引更新是另一個容易被忽略的環(huán)節(jié)。業(yè)務(wù)上新增了一份財報需要讓新知識立刻被檢索到。我采用的是全量重建與增量寫入結(jié)合的方式常規(guī)更新走增量接口文檔結(jié)構(gòu)大改或數(shù)據(jù)清洗規(guī)則變化時觸發(fā)重建。增量更新時務(wù)必維護好文檔ID與切片ID的映射表否則舊切片無法定位更新后容易出現(xiàn)新老數(shù)據(jù)混答的問題。最后再分享一個小技巧整套Financial RAG Demo跑下來如果要我說最值得關(guān)注的優(yōu)化點不是換更大的模型而是把數(shù)據(jù)準(zhǔn)備和檢索調(diào)優(yōu)做扎實。數(shù)據(jù)準(zhǔn)備階段的每個決策都會在最終的回答質(zhì)量上加分或減分。我建議每個做類似項目的人在第一次跑通端到端之后不要急著加強大模型能力而是建立一個“檢索失敗案例臺賬”把問答中檢索不到正確片段的案例一條條記錄下來分析是切片問題、解析問題還是Embedding問題。我自己就是這樣連續(xù)記錄和修復(fù)了三周數(shù)據(jù)準(zhǔn)確率才真正穩(wěn)定下來。這個臺賬方法免費、實用、任何場景都能用強烈推薦。