說到RAG應(yīng)用最近我聽到最多的吐槽就是“問答系統(tǒng)又在一本正經(jīng)地胡說八道了”。上個(gè)月我維護(hù)的一個(gè)內(nèi)部知識(shí)問答demo就翻了一次車用戶問某軟件產(chǎn)品當(dāng)前的版本號(hào)系統(tǒng)從三個(gè)月前的知識(shí)快照里檢索到舊版本然后非常自信地推薦用戶去下載一個(gè)早已不存在的版本。這種場(chǎng)面我已經(jīng)見怪不怪了——RAG應(yīng)用做得越多越能體會(huì)“不是模型不行是知識(shí)沒有保鮮”。后來我花了差不多一周時(shí)間把方案改成了Bright Data MCP 實(shí)時(shí)抓取的組合重新跑了一輪實(shí)測(cè)效果差別非常明顯。這篇文章就把整個(gè)過程寫出來包括RAG為什么會(huì)“張口就錯(cuò)”、MCP在鏈路里到底扮演什么角色、配置和代碼怎么接、實(shí)測(cè)數(shù)據(jù)如何以及我踩過的幾個(gè)坑。如果你也在做RAG應(yīng)用或者被用戶吐槽過答案過時(shí)這篇文章應(yīng)該能幫你少走一些彎路。1. 先別急著罵模型RAG“張口就錯(cuò)”到底錯(cuò)在哪個(gè)環(huán)節(jié)很多人遇到RAG答錯(cuò)第一反應(yīng)是“這個(gè)模型太笨了”。但根據(jù)我的觀察大部分錯(cuò)誤壓根不是生成能力的問題而是知識(shí)供給的問題。模型拿到一份過期的資料你讓它怎么答都答不對(duì)。1.1 一個(gè)典型翻車現(xiàn)場(chǎng)先還原一下我那個(gè)demo的翻車過程。用戶的問題很簡(jiǎn)單“某開源框架的最新穩(wěn)定版是多少”知識(shí)庫(kù)里存的快照顯示最新版是V2.4但現(xiàn)實(shí)里官方已經(jīng)發(fā)布了V3.0而且V2.4還帶著一個(gè)已知的安全漏洞。RAG系統(tǒng)把V2.4檢索出來當(dāng)作正確答案返回語氣還特別篤定甚至還貼了一段“官方推薦在生產(chǎn)環(huán)境使用”的說明。這種錯(cuò)誤比模型自由發(fā)揮的幻覺更危險(xiǎn)因?yàn)樗鼇碓疵鞔_、有依據(jù)感用戶很難分辨。我見過好幾個(gè)同行的項(xiàng)目卡在類似問題上不是檢索不到而是檢索到的內(nèi)容是“按時(shí)過期的”。你問它“XX產(chǎn)品現(xiàn)在的價(jià)格”它回答上個(gè)月的促銷價(jià)你問它“XX政策是否仍然有效”它引用一年前的公告。從技術(shù)上來說這套系統(tǒng)每一步都做對(duì)了——向量檢索返回了最相關(guān)的片段大模型忠實(shí)引用了上下文——但用戶看到的就是錯(cuò)誤答案。1.2 知識(shí)快照的保質(zhì)期問題RAG的核心思想很清楚不指望大模型記住所有知識(shí)把答案需要的資料準(zhǔn)備好讓模型照著資料說。問題在于大多數(shù)RAG知識(shí)庫(kù)是一份“靜態(tài)快照”在某個(gè)時(shí)間點(diǎn)導(dǎo)入或更新之后就再也不會(huì)動(dòng)了?？煺蘸同F(xiàn)實(shí)之間天然存在一個(gè)時(shí)間差。你今天建庫(kù)今天之后發(fā)生的所有變化都在盲區(qū)里。這個(gè)時(shí)間差不會(huì)影響“產(chǎn)品使用手冊(cè)”“公司制度文件”這類相對(duì)穩(wěn)定的知識(shí)但一旦問題涉及“最新、當(dāng)前、實(shí)時(shí)、價(jià)格、版本、新聞、活動(dòng)”這些維度快照就沒有招架之力了。我把這個(gè)過程類比成冰箱里的冷凍食品。知識(shí)庫(kù)就是那個(gè)冰箱存入時(shí)是新鮮的問題在于你不知道它凍了多久。你拿凍了三個(gè)月的肉炒菜肉本身爛不爛不好說反正和“新鮮”肯定沾不上邊。更麻煩的是大模型不知道這塊肉凍了多久它只會(huì)當(dāng)成好肉下鍋。1.3 召回鏈路的三處脆弱點(diǎn)拋開新鮮度RAG“張口就錯(cuò)”還有三個(gè)更底層的脆弱點(diǎn)我在調(diào)試時(shí)挨個(gè)排查過。第一是索引覆蓋率不夠。知識(shí)庫(kù)只包含建庫(kù)時(shí)導(dǎo)入的那批文檔用戶問了一個(gè)庫(kù)外問題系統(tǒng)只能靠模型硬編。庫(kù)越大、更新越頻繁覆蓋率就越難保證。第二是切分和索引策略不合理。文檔切得太粗一個(gè)chunk塞進(jìn)多個(gè)知識(shí)點(diǎn)召回結(jié)果模棱兩可切得太細(xì)完整上下文又被切斷模型看到一半信息就開始生成。第三是重排環(huán)節(jié)缺失。很多小項(xiàng)目壓根不做重排向量檢索的top-k直接進(jìn)prompt兩段不相關(guān)的文本被一起塞給模型模型只能強(qiáng)行找關(guān)系。這三種問題不一定同時(shí)出現(xiàn)但任何一種都可能造成錯(cuò)誤答案。而實(shí)時(shí)抓取方案至少能從“覆蓋率”和“新鮮度”兩個(gè)方向上做補(bǔ)充——庫(kù)外問題可以現(xiàn)搜過期問題可以現(xiàn)抓。這也正是我選擇引入Bright Data MCP的原因。2. 為什么選Bright Data MCP它在RAG鏈路里補(bǔ)上的是“新鮮度”這一環(huán)決定讓RAG具備實(shí)時(shí)信息能力之后我面臨一個(gè)選型問題怎么把“網(wǎng)頁實(shí)時(shí)內(nèi)容”接到RAG流程里。自己寫爬蟲是個(gè)選項(xiàng)但后來我選了Bright Data MCP。下面說說這個(gè)判斷的依據(jù)。2.1 MCP是什么AI應(yīng)用連接外部世界的“標(biāo)準(zhǔn)插座”MCP的全稱是Model Context Protocol一套開放協(xié)議。你可以把它理解成AI應(yīng)用與外部工具之間的標(biāo)準(zhǔn)USB接口設(shè)備廠商不用針對(duì)每個(gè)筆記本型號(hào)定制一根線只要支持USB協(xié)議插上就能通電。在MCP出現(xiàn)之前讓AI程序調(diào)用外部工具通常是一對(duì)一寫集成代碼——調(diào)這個(gè)搜索服務(wù)寫一套調(diào)那個(gè)數(shù)據(jù)庫(kù)寫一套。MCP定義了一套統(tǒng)一規(guī)范按理說一個(gè)支持MCP的客戶端就能接入任何兼容MCP的服務(wù)器。對(duì)于RAG工程來說這意味著“實(shí)時(shí)搜網(wǎng)頁”這個(gè)能力可以被打包成一個(gè)標(biāo)準(zhǔn)工具通過配置和幾行代碼接進(jìn)來而不是自己從零造輪子。2.2 Bright Data MCP的兩個(gè)核心工具與返回效果Bright Data的MCP服務(wù)器在我寫這篇文章時(shí)暴露了兩個(gè)核心工具web_search和web_scrape。web_search做的事就是給定一個(gè)查詢?cè)~返回一組搜索結(jié)果每條包含標(biāo)題、URL、站點(diǎn)名和一段摘要。它的價(jià)值在于讓RAG能“發(fā)現(xiàn)”知識(shí)庫(kù)之外的內(nèi)容。web_scrape則更進(jìn)一步輸入一個(gè)URL返回該頁面的正文內(nèi)容并且是以Markdown格式呈現(xiàn)——這意味著它已經(jīng)幫你做了一輪內(nèi)容提取不是把一堆HTML標(biāo)簽直接丟給你。對(duì)RAG流程來說這種預(yù)處理非常關(guān)鍵因?yàn)榇竽Ｐ蜕舷挛拇翱谠俅笠步?jīng)不起幾百KB的原始HTML轟炸。我實(shí)際測(cè)試下來它對(duì)大部分常規(guī)新聞頁、博客、文檔站的處理效果都不錯(cuò)正文提取比較干凈能直接切一段塞進(jìn)prompt。這一點(diǎn)對(duì)RAG場(chǎng)景特別友好。2.3 為什么不是“自己寫爬蟲”肯定有人會(huì)說網(wǎng)頁抓取嘛自己寫個(gè)腳本不就完了。我試過而且不止一次但它是一個(gè)看著簡(jiǎn)單、跑起來全是坑的方案?，F(xiàn)代網(wǎng)頁大量使用JavaScript動(dòng)態(tài)渲染你用普通HTTP庫(kù)抓到的HTML常常是空的得先用瀏覽器內(nèi)核去解渲染。頁面結(jié)構(gòu)五花八門正文、導(dǎo)航、評(píng)論區(qū)、廣告混在一起清洗規(guī)則今天能用明天站點(diǎn)改版就失效。還有訪問頻控、驗(yàn)證碼、UA識(shí)別、指紋檢測(cè)這些關(guān)卡每一條都?jí)蛘垓v一陣。維護(hù)成本會(huì)隨著目標(biāo)站點(diǎn)數(shù)量的增加而迅速膨脹。相比之下用現(xiàn)成的抓取基礎(chǔ)設(shè)施代碼里只需要調(diào)用一個(gè)工具就能拿到清洗后的網(wǎng)頁文本。對(duì)中小項(xiàng)目和獨(dú)立開發(fā)者來說性價(jià)比高得多。該權(quán)衡的點(diǎn)也很清楚這是付費(fèi)服務(wù)有免費(fèi)額度但超過之后按量計(jì)費(fèi)。我的做法是只在“實(shí)時(shí)性敏感”的請(qǐng)求上觸發(fā)抓取后面第4章細(xì)說。3. 組合方案落地全過程從MCP配置到抓取結(jié)果混排方案思路不復(fù)雜用戶提問之后先做一次判定判斷這個(gè)問題是否需要實(shí)時(shí)信息如果需要就通過Bright Data MCP搜索并抓取目標(biāo)網(wǎng)頁把抓回來的內(nèi)容清洗、截?cái)嗪蠛拖蛄繖z索結(jié)果一起喂給大模型。下面是我實(shí)際操作的完整鏈路。3.1 環(huán)境準(zhǔn)備注冊(cè)Token與MCP配置首先要有一個(gè)Bright Data賬號(hào)并申請(qǐng)API Token這一步跟著官方控制臺(tái)走就行。拿到Token之后在支持MCP的桌面AI客戶端里配置服務(wù)端。以某個(gè)支持MCP的客戶端為例配置文件大致長(zhǎng)這樣{ mcpServers: { brightdata-mcp: { command: npx, args: [-y, brightdata/mcp], env: { BRIGHT_DATA_API_TOKEN: 你的token } } } }如果你的RAG應(yīng)用是自己寫的Python服務(wù)也可以不依賴桌面客戶端直接用MCP的Python SDK建立會(huì)話通過流式傳輸協(xié)議連到MCP服務(wù)器。這樣配置會(huì)更靈活也更貼近生產(chǎn)環(huán)境。# 示意MCP客戶端核心結(jié)構(gòu) from mcp import MCPClient # 以官方SDK為準(zhǔn) async def main(): async with MCPClient(brightdata-mcp) as client: tools await client.list_tools() print(tools) # 能看到 web_search, web_scrape 等3.2 核心調(diào)用邏輯先判定再搜索最后抓取設(shè)置好環(huán)境之后重要的事情不是寫代碼而是定規(guī)則哪些問題需要走實(shí)時(shí)抓取哪些問題不必。我寫了一個(gè)“是否觸發(fā)實(shí)時(shí)信息”的判定函數(shù)判斷條件有兩個(gè)。def should_fetch(user_question: str, local_score: float) - bool: fresh_keywords [最新, 目前, 現(xiàn)在, 當(dāng)前, 價(jià)格, 版本, 新聞, 發(fā)布了, 更新了] has_fresh_word any(k in user_question for k in fresh_keywords) has_low_score local_score 0.65 # 本地向量檢索的最高相似度 return has_fresh_word or has_low_score第一個(gè)條件解決“新鮮度敏感”問題第二個(gè)條件解決“知識(shí)庫(kù)覆蓋不足”問題。兩者都不滿足說明本地知識(shí)已經(jīng)夠用直接走傳統(tǒng)RAG鏈路不增加任何額外耗時(shí)。需要觸發(fā)時(shí)流程如下async def get_realtime_context(session, user_question, top_n3): # 1. 搜索 search_result await session.call_tool( web_search, {query: user_question, count: 5} ) urls extract_urls_from_search(search_result) # 2. 抓取前top_n個(gè)網(wǎng)頁 segments [] for url in urls[:top_n]: scraped await session.call_tool( web_scrape, {url: url} ) text markdown_to_text(scraped) # 清洗處理 text text[:2000] # 截?cái)嗫刂崎L(zhǎng)度 segments.append({ url: url, fetched_at: now(), content: text }) return segments為什么只取top_n前三個(gè)網(wǎng)頁一是因?yàn)樗阉鹘Y(jié)果越靠后噪音越大二是因?yàn)槊總€(gè)網(wǎng)頁抓回來都要占上下文空間。我實(shí)測(cè)下來3個(gè)頁面已經(jīng)能覆蓋大部分問題的答案來源太多反而稀釋有效信息。截?cái)嗟?000字符也是為了控制大模型的token消耗——反正關(guān)鍵信息一般出現(xiàn)在正文前部尤其是新聞?lì)惡蛥?shù)類頁面。3.3 與向量檢索結(jié)果混排讓模型知道“誰新誰舊”拿回實(shí)時(shí)片段之后不能簡(jiǎn)單把它們和向量檢索結(jié)果混在一起丟給模型。如果模型分不清哪些是舊的、哪些是新的它很可能把快照中的舊知識(shí)當(dāng)成最新內(nèi)容來回答——那就白抓了。我采用“分組標(biāo)注”的方式拼裝prompt。先放歷史知識(shí)庫(kù)片段明確標(biāo)注“歷史參考資料快照時(shí)間2024年X月X日”再放實(shí)時(shí)抓取片段標(biāo)注“實(shí)時(shí)參考資料抓取時(shí)間今天”并在系統(tǒng)指令里給出優(yōu)先級(jí)規(guī)則請(qǐng)優(yōu)先參考實(shí)時(shí)參考資料。當(dāng)歷史資料與實(shí)時(shí)資料沖突時(shí)以實(shí)時(shí)資料為準(zhǔn)。如果實(shí)時(shí)資料也無法覆蓋答案請(qǐng)明確回復(fù)“未能檢索到最新信息”不要自行推測(cè)。為什么要保留歷史片段而不徹底替換因?yàn)橹R(shí)庫(kù)里有大量穩(wěn)定的靜態(tài)知識(shí)比如產(chǎn)品使用方法、歷史背景、內(nèi)部規(guī)范這些實(shí)時(shí)抓取反而不一定能提供。把兩組資料分開標(biāo)注模型就能“該穩(wěn)的穩(wěn)該新的新”。我在測(cè)試中還發(fā)現(xiàn)給每個(gè)實(shí)時(shí)片段加上來源URL對(duì)用戶側(cè)的可信度提升也很有幫助后續(xù)展示引用來源時(shí)也方便。4. 實(shí)測(cè)數(shù)據(jù)說話三種翻車場(chǎng)景下方案把準(zhǔn)確率拉回多少配置和代碼都跑通之后我最關(guān)心的問題只有一個(gè)這套組合方案到底能不能真正解決“張口就錯(cuò)”為了驗(yàn)證我在自己的測(cè)試項(xiàng)目上設(shè)計(jì)了三個(gè)場(chǎng)景每個(gè)場(chǎng)景5個(gè)問題對(duì)照組用純RAG實(shí)驗(yàn)組用RAG實(shí)時(shí)抓取逐條人工判斷回答是否準(zhǔn)確。4.1 場(chǎng)景一突發(fā)資訊類問題這類問題我在1.1里遇到過典型代表是“某開源框架最新版本是多少”“某產(chǎn)品最近發(fā)布的功能是什么”“今天有什么重大更新”。知識(shí)庫(kù)快照根本不可能包含實(shí)時(shí)信息純RAG只能靠訓(xùn)練數(shù)據(jù)里的舊記憶回答錯(cuò)的概率極高。測(cè)試結(jié)果很有意思純RAG組5題答對(duì)2題準(zhǔn)確率40%實(shí)驗(yàn)組答對(duì)4題準(zhǔn)確率80%。剩下那1題失敗原因也很典型——搜索結(jié)果首頁摘要指向了一個(gè)第三方轉(zhuǎn)載頁面而那個(gè)頁面的內(nèi)容本身是舊的抓取后把過時(shí)信息當(dāng)成答案。后來我在規(guī)則里加了一條“優(yōu)先抓取官方域名頁面”這類錯(cuò)誤才明顯減少。4.2 場(chǎng)景二官網(wǎng)改版后的產(chǎn)品參數(shù)第二個(gè)場(chǎng)景針對(duì)的是“產(chǎn)品頁面更新但知識(shí)庫(kù)沒同步”的經(jīng)典問題。我故意找了一個(gè)官網(wǎng)產(chǎn)品頁把參數(shù)改得和知識(shí)庫(kù)快照不一致再問“該產(chǎn)品的功耗和重量是多少”。純RAG組慘不忍睹5題只答對(duì)1題因?yàn)橹R(shí)庫(kù)里的參數(shù)已經(jīng)過期大模型還會(huì)把過期參數(shù)描述得煞有介事。實(shí)驗(yàn)組直接抓取官方產(chǎn)品頁參數(shù)完全準(zhǔn)確5題全對(duì)。這個(gè)場(chǎng)景也是整套方案里效果最好的官網(wǎng)頁面結(jié)構(gòu)固定、正文信息密度高、基本沒有雜質(zhì)抓回來稍微清洗一下就是標(biāo)準(zhǔn)答案。4.3 場(chǎng)景三冷門長(zhǎng)尾問題第三種情況更隱蔽用戶問了一個(gè)知識(shí)庫(kù)完全沒有覆蓋的問題向量檢索的最高相似度分?jǐn)?shù)也低于閾值。純RAG組此刻只能靠大模型內(nèi)部知識(shí)硬答幻覺風(fēng)險(xiǎn)極高測(cè)試中準(zhǔn)確率只有40%。實(shí)驗(yàn)組因?yàn)橛|發(fā)了“低分判定”自動(dòng)改為搜索抓取準(zhǔn)確率提升到80%。不過這個(gè)場(chǎng)景也是失敗案例最多的失敗原因大多是搜索返回的網(wǎng)頁內(nèi)容本身自相矛盾。比如某個(gè)技術(shù)問題的解決辦法兩個(gè)網(wǎng)頁說法相反模型只能挑一個(gè)信。這說明實(shí)時(shí)抓取也不是萬能的它兜住了覆蓋率問題但沒有徹底解決“信息源可信度排序”的問題。4.4 耗時(shí)與成本觀察好效果不是沒代價(jià)的實(shí)時(shí)抓取是有成本的包括時(shí)間和費(fèi)用。我在測(cè)試環(huán)境里記錄了平均指標(biāo)指標(biāo)純RAGRAG 實(shí)時(shí)抓取平均響應(yīng)耗時(shí)2.1秒7.4秒平均上下文大小2.1k tokens4.6k tokens單次調(diào)用費(fèi)用無增量增量明顯搜索抓取準(zhǔn)確率三個(gè)場(chǎng)景平均40%86.7%7.4秒的響應(yīng)時(shí)間對(duì)交互式問答來說偏慢所以我把“新鮮度敏感觸發(fā)”機(jī)制作為默認(rèn)配置跑了一周結(jié)果只有約30%的請(qǐng)求真正觸發(fā)了實(shí)時(shí)搜索其余70%的請(qǐng)求依然在2秒左右返回。費(fèi)用也因此可控不會(huì)出現(xiàn)每天燒掉幾十上百次抓取的情況。我的建議是把實(shí)時(shí)抓取定位成“按需付費(fèi)”的能力而不是所有請(qǐng)求的必經(jīng)之路。這既保住了用戶體驗(yàn)也不會(huì)讓運(yùn)維賬單失控。5. 我踩過的五個(gè)坑和對(duì)應(yīng)的處理方式接這套方案的時(shí)候我按照工具文檔一把梭結(jié)果連續(xù)踩了好幾個(gè)坑每次都得重新調(diào)代碼、調(diào)prompt。這里按嚴(yán)重程度列一下都是實(shí)測(cè)過的處理方式。5.1 坑一SPA頁面抓回來的內(nèi)容缺胳膊少腿第一次用web_scrape抓單頁應(yīng)用時(shí)就翻車了。那是一個(gè)典型的Vue單頁應(yīng)用所有內(nèi)容都是JS異步渲染出來的。我給它傳了個(gè)URL返回值里正文區(qū)域一片空白只有幾個(gè)按鈕文案。問題在于部分頁面需要等待渲染完成才能抓到完整內(nèi)容。后來我在調(diào)用時(shí)增加了渲染等待參數(shù)讓抓取器在頁面上多等幾秒問題才解決。當(dāng)時(shí)的關(guān)鍵參數(shù)大概是scraped await session.call_tool( web_scrape, {url: url, wait_for: 5000} # 等待渲染窗口 )這個(gè)參數(shù)不是萬能的但對(duì)JS渲染重的頁面很有效。如果你也遇到返回內(nèi)容明顯偏少先排查目標(biāo)頁面是不是動(dòng)態(tài)渲染再考慮加等待時(shí)間。5.2 坑二正文沒洗干凈上下文窗口先爆炸第二個(gè)坑是抓回來的文章里混著大量導(dǎo)航菜單、相關(guān)推薦、Cookie彈窗、廣告區(qū)塊。我一開始只做了簡(jiǎn)單的HTML標(biāo)簽剝離就拼進(jìn)上下文結(jié)果一次請(qǐng)求消耗了快6000個(gè)token其中一半以上是“登錄查看全文”“點(diǎn)擊訂閱”“相關(guān)閱讀”這種廢話。上下文被稀釋回答質(zhì)量自然下降。處理方式分兩步。第一步是行級(jí)過濾把包含“登錄”“訂閱”“閱讀全文”“推薦閱讀”“點(diǎn)擊下載”等關(guān)鍵詞的行直接刪掉。第二步是長(zhǎng)度約束只保留正文前N個(gè)段落通常2000字符以內(nèi)。經(jīng)過這兩步抓回來的文本干凈了很多上下文體積也減了大半。5.3 坑三抓取超時(shí)整個(gè)回答都被拖死網(wǎng)頁抓取天生不穩(wěn)定。有一次目標(biāo)網(wǎng)站響應(yīng)特別慢web_scrape在最關(guān)鍵的用戶請(qǐng)求中卡了30秒最終也沒成功整個(gè)RAG鏈路因?yàn)榈却瑫r(shí)。用戶很惱火我也很惱火。解決這個(gè)問題的核心思路是“不能讓單次抓取拖垮整條鏈路”。我寫了一個(gè)保護(hù)層設(shè)置15秒超時(shí)、最多重試2次如果某一個(gè)URL抓取失敗就用搜索結(jié)果的摘要作為兜底。摘要內(nèi)容短信息量有限但總比讓用戶空等強(qiáng)。另外抓取失敗記錄會(huì)進(jìn)入日志后續(xù)優(yōu)化目標(biāo)站點(diǎn)時(shí)也有依據(jù)。5.4 坑四不做緩存一句話的成本翻十倍剛開始跑測(cè)試時(shí)我把同一個(gè)問題連續(xù)問了三次每次系統(tǒng)都重新搜索一遍、重新抓取一遍費(fèi)用就燒掉了三次。后來我發(fā)現(xiàn)這個(gè)問題在并發(fā)場(chǎng)景里更嚴(yán)重——幾十個(gè)用戶問同一個(gè)熱門問題時(shí)系統(tǒng)會(huì)對(duì)同一個(gè)URL重復(fù)抓取幾十遍。我給系統(tǒng)加了一層簡(jiǎn)單的本地緩存以URL為key把抓取結(jié)果和抓取時(shí)間存進(jìn)本地文件TTL設(shè)為1小時(shí)。緩存命中就直接用不用調(diào)用遠(yuǎn)端接口。加上這個(gè)機(jī)制之后在相同測(cè)試問題量下MCP調(diào)用次數(shù)減少了約40個(gè)百分點(diǎn)費(fèi)用顯著下降。對(duì)個(gè)人開發(fā)者來說這一步就能保證項(xiàng)目不會(huì)因?yàn)闇y(cè)試量稍大而預(yù)算崩盤。5.5 坑五忘記標(biāo)記時(shí)間新舊信息在prompt里打架最后一個(gè)坑最隱蔽。有一次抓取結(jié)果明明是對(duì)的但模型給出的答案依然是舊版本號(hào)。我檢查了很久才發(fā)現(xiàn)問題出在prompt里沒有時(shí)間標(biāo)注——?dú)v史片段的“舊”和實(shí)時(shí)片段的“新”對(duì)模型來說沒有區(qū)別模型在兩份資料里各取一部分混合出了一個(gè)不存在的答案。從那以后我在每個(gè)實(shí)時(shí)片段旁邊都加上顯式的抓取時(shí)間并且在系統(tǒng)指令里強(qiáng)調(diào)“請(qǐng)根據(jù)資料中出現(xiàn)的時(shí)間信息判斷新舊關(guān)系”。這個(gè)改動(dòng)看起來簡(jiǎn)單但對(duì)回答準(zhǔn)確率的提升非常直接。它本質(zhì)上是在幫模型建立“時(shí)間坐標(biāo)系”沒有這個(gè)坐標(biāo)系再多實(shí)時(shí)資料也白搭。如果你也計(jì)劃把實(shí)時(shí)抓取接進(jìn)RAG系統(tǒng)我的建議是把它設(shè)計(jì)成一個(gè)“按需觸發(fā)能力”而不是讓所有請(qǐng)求都走實(shí)時(shí)鏈路。舊問題秒回新問題現(xiàn)抓現(xiàn)答這套組合才能真正跑得長(zhǎng)久。緩存和時(shí)間戳看著不起眼但它們?cè)趯?shí)戰(zhàn)里往往決定了方案是能用還是好用。