化評估實(shí)踐)
做 RAG 應(yīng)用快兩年了最讓我頭疼的從來不是模型選型也不是向量庫調(diào)優(yōu)而是根本說不清楚系統(tǒng)到底哪里出了問題。用戶說回答不對你問他怎么個(gè)不對法他說就是感覺不對。你翻日志、查 prompt、調(diào)參數(shù)忙活一整天最后還是靠猜。后來我把 LangSmith 用起來才算是把這條鏈路從黑盒變成了透明再從透明升級到自動(dòng)把關(guān)。這篇就聊聊我怎么從零開始接鏈路追蹤又怎么一步步把它變成一套 RAG 自動(dòng)化評估體系的。1. 鏈路追蹤到底在追什么先弄懂 LangSmith 的工作機(jī)理很多朋友一上來就急著看 UI、看 span 列表其實(shí)沒搞清楚 LangSmith 的底層邏輯后面排查問題就很容易被界面上的信息帶偏。1.1 一次 RAG 請求在 LangSmith 里是怎樣被拆解的LangSmith 的核心概念其實(shí)只有幾個(gè)Run、Span、Trace。一次用戶請求進(jìn)來LangSmith 會(huì)把它記為一條Trace里面嵌套若干個(gè)Run。以最常見的 RAG 流程為例一個(gè)Trace大致長這樣RetrieveRun查向量庫 └── QueryEmbeddingRun問題向量化 └── VectorStoreSearchRun相似度檢索 └── DocumentPostProcessRun重排/截?cái)?GenerateRun模型生成 └── PromptBuildRun拼 prompt └── LLMInvokeRun調(diào)用大模型每條Run都會(huì)記錄輸入、輸出、耗時(shí)、token 消耗以及自定義的元數(shù)據(jù)。真正好用的地方在于你可以給任意一個(gè)Run掛上你自己關(guān)心的指標(biāo)比如檢索結(jié)果里到底有幾個(gè)是真正相關(guān)的最終答案引用了哪幾個(gè)文檔片段。1.2 埋點(diǎn)方式選擇自動(dòng)埋點(diǎn)與手動(dòng)埋點(diǎn)的適用時(shí)機(jī)LangSmith 提供兩種接入方式很多人不知道該怎么選。我的建議很簡單如果用的是 LangChain 框架直接用自動(dòng)埋點(diǎn)如果你像我一樣是手寫 RAG 管線老老實(shí)實(shí)手動(dòng)埋點(diǎn)。自動(dòng)埋點(diǎn)的好處是零侵入wrap_openai()或設(shè)置環(huán)境變量后框架內(nèi)部會(huì)自動(dòng)生成 trace。但代價(jià)是你只能看到框架替你記錄的內(nèi)容想記錄檢索結(jié)果相關(guān)性評分這種自定義字段還得額外寫代碼。手動(dòng)埋點(diǎn)雖然多寫幾行但靈活度完全可控。我現(xiàn)在的做法是半自動(dòng)框架調(diào)用用自動(dòng)埋點(diǎn)自定義邏輯用run_tree手動(dòng)包一層兩邊互不干擾。from langsmith import Client, traceable traceable(run_typechain, nameRetrieveDocuments) def retrieve_documents(question: str, top_k: int 5): # 這里可以是任意檢索邏輯 docs, scores vector_store.search_with_score(question, top_ktop_k) return {docs: docs, scores: scores} traceable(run_typellm, nameGenerateAnswer) def generate_answer(question: str, context: list[str]): prompt build_prompt(question, context) return llm.invoke(prompt)加了traceable之后函數(shù)輸入輸出會(huì)自動(dòng)出現(xiàn)在 LangSmith 的 trace 詳情頁里。注意run_type不要亂填chain、llm、retriever、embedding這幾個(gè)類型對應(yīng)的 UI 渲染和信息聚合邏輯差很多。1.3 只記錄最有價(jià)值的信息很多人埋點(diǎn)走極端要么什么都不記要么把所有東西全都塞進(jìn)去。token 多的請求會(huì)讓 trace 頁面變得極其卡頓而且真正排查問題時(shí)反而找不到重點(diǎn)。我習(xí)慣在每個(gè) Run 里至少掛上這幾類信息- input_question用戶原始問題 - retrieval_scores各候選文檔的相似度得分 - context_truncation上下文截?cái)嗖呗耘c實(shí)際保留長度 - model_params實(shí)際生效的溫度、top_p 等參數(shù) - ground_truth_doc_ids這個(gè)請求關(guān)聯(lián)的標(biāo)準(zhǔn)答案文檔 ID評估階段用尤其是ground_truth_doc_ids這個(gè)字段很多團(tuán)隊(duì)會(huì)忽略。它能在你回看 trace 時(shí)快速判斷當(dāng)時(shí)這個(gè)答案到底有沒有按預(yù)期引用正確的文檔是后面構(gòu)建評估集的重要錨點(diǎn)。2. 從 trace 里定位 RAG 的高發(fā)事故現(xiàn)場接好埋點(diǎn)后LangSmith 的 traces 頁面會(huì)開始積累數(shù)據(jù)。但數(shù)據(jù)多不代表有價(jià)值你得學(xué)會(huì)在 trace 里快速定位那幾類典型問題。我總結(jié)了 RAG 應(yīng)用最高發(fā)的四類問題每個(gè)都有對應(yīng)的 trace 特征。2.1 檢索召回偏移問題在 Embedding 而不是關(guān)鍵詞表現(xiàn)用戶在 UI 上問蘋果公司的創(chuàng)始人是誰回答卻引用了蘋果作為一種水果的營養(yǎng)價(jià)值。這類問題看 trace 最容易發(fā)現(xiàn)。點(diǎn)開RetrieveRun你會(huì)發(fā)現(xiàn) QueryEmbeddingRun 生成向量沒問題VectorStoreSearchRun 的得分也不算低但返回的文檔片段在語義上明顯跑偏。問題不在鏈路而在 Embedding 模型本身對某些領(lǐng)域詞匯的區(qū)分度不夠。排查思路別急著換 Embedding 模型。先在 trace 里對比問題向量與正確答案向量的相似度和問題向量與錯(cuò)誤候選向量的相似度。很多時(shí)候你會(huì)發(fā)現(xiàn)兩者差距很小這屬于模型能力邊界問題。此時(shí)可以考慮對原始輸入做查詢改寫或者用 Hybrid Search 搭配 BM25把關(guān)鍵詞匹配這一路也拉進(jìn)來兜底。2.2 上下文爆炸還記得自己輸出了多少 token 嗎表現(xiàn)答案質(zhì)量沒變差但響應(yīng)延遲從 1.5 秒慢慢爬升到 5 秒以上賬單金額也在悄悄變多。查看 trace 里的 GenerateRun重點(diǎn)關(guān)注prompt_tokens和raw_input里的上下文長度。這個(gè)問題通常不是 Retrieval 階段查多了而是你塞進(jìn)去的補(bǔ)充資料太多了。比如我在某個(gè)項(xiàng)目里發(fā)現(xiàn)開發(fā)同學(xué)為了提升回答質(zhì)量在 prompt 里加了行業(yè)知識(shí)庫的 8 個(gè)固定條目每個(gè)條目都有上千字而 RAG 檢索答案只需 1-2 個(gè)條目就足夠。解決方向有兩個(gè)一是檢索階段嚴(yán)格控制top_k比如從 5 降到 3配合重排序模型只保留 top 2二是對檢索到的文檔做相關(guān)性截?cái)嗟陀陂撝档膱?jiān)決不放行寧缺毋濫。2.3 幻覺根因追蹤回答內(nèi)容到底引用了哪一句表現(xiàn)答案聽起來頭頭是道但每條論據(jù)在原始文檔里都找不到出處。LangSmith 的 trace 頁有個(gè)很實(shí)用的功能你可以在GenerateRun的 output 里直接看到最終答案的哪句話引用了哪個(gè)文檔塊。但如果你的 prompt 里沒有讓模型輸出引用標(biāo)記如 [1][2]這里只會(huì)在引用文檔列表區(qū)域顯示檢索片的得分看不出具體對應(yīng)關(guān)系。我的習(xí)慣是在 prompt 里強(qiáng)制模型按上下文引用的文檔序號(hào)標(biāo)注答案比如說回答時(shí)請基于提供的上下文并在句子末尾使用 [數(shù)字] 標(biāo)注依據(jù)的文檔序號(hào)。這樣 trace 里就能看到answer: 蘋果公司由喬布斯創(chuàng)立[1]再點(diǎn)開[1]所對文檔的實(shí)際內(nèi)容問題是否出在模型自己腦補(bǔ)了內(nèi)容還是上下文里其實(shí)有但模型漏看了一目了然。如果發(fā)現(xiàn)答案引用了文檔 [2]但 trace 里顯示的檢索得分很低那就說明檢索鏈路把不相關(guān)的內(nèi)容也放進(jìn)了上下文回到了 2.1 的范疇。2.4 延遲瓶頸定位耗時(shí)到底花在哪一步KPI 飆升的另一大來源是延遲。看 trace 的每個(gè)Run耗時(shí)分布如果 QueryEmbedding 和 VectorStoreSearch 加起來只占 200msLLM 調(diào)用占 3.5s瓶頸在生成環(huán)節(jié)。此時(shí)你該檢查是不是 prompt 塞得太長或者溫度、max_tokens是否合理而不是去優(yōu)化向量庫。如果 VectorStoreSearch 本身就占了 2s先檢查是不是沒走 ANN 索引而是全表掃描或者自定義過濾條件太多導(dǎo)致索引失效。這些在常規(guī)日志里很難定位但在 trace 里一眼就能看出來。3. 從看一眼到有標(biāo)準(zhǔn)用 LangSmith 沉淀真實(shí)的評估數(shù)據(jù)集鏈路追蹤解決的是出問題時(shí)快速定位但如果每次都要人肉看 trace團(tuán)隊(duì)規(guī)模一大還是扛不住。更關(guān)鍵的問題是你怎么知道這次改動(dòng)是變好了還是變壞了要回答這個(gè)問題就得把評估從人看變成自動(dòng)跑這是 LangSmith 最有價(jià)值的部分也是標(biāo)題里自動(dòng)化評估的真正含義。3.1 數(shù)據(jù)集從哪來直接復(fù)用線上真實(shí)請求LangSmith 里可以直接把某條 trace 創(chuàng)建為數(shù)據(jù)集樣本。這個(gè)功能實(shí)用程度遠(yuǎn)超想象。具體操作在 trace 詳情頁選一條有代表性的回答點(diǎn)擊添加到數(shù)據(jù)集LangSmith 會(huì)自動(dòng)把輸入問題抓下來。你可以順手在outputs里補(bǔ)上 ground truth 答案或相關(guān)文檔 ID。我個(gè)人的做法是每條樣本至少包含三項(xiàng)內(nèi)容——輸入問題、標(biāo)準(zhǔn)答案或標(biāo)準(zhǔn)引用文檔 ID、期望的拒絕行為可選。from langsmith import Client client Client() dataset client.create_dataset( dataset_nameRAG-Eval-Regression-Set, description面向核心業(yè)務(wù)場景的 RAG 回歸標(biāo)準(zhǔn)集 ) client.create_examples( dataset_iddataset.id, inputs[ {question: 我們產(chǎn)品的退款政策是什么}, {question: 對接 API 時(shí)出現(xiàn) 401 錯(cuò)誤怎么解決} ], outputs[ {answer: 退款政策見幫助中心條款 3.2 節(jié)支持 7 天無理由退款。, doc_ids: [faq-3.2]}, {answer: 401 錯(cuò)誤通常由 API 密鑰無效或過期導(dǎo)致詳見對接文檔第 4 節(jié)。, doc_ids: [api-doc-4]} ] )數(shù)據(jù)集不需要一開始就做到幾百上千條。我通常從真實(shí)用戶反饋中挑 30~50 條最典型的再讓運(yùn)營同學(xué)補(bǔ)充一部分邊角場景的毒問題比如意圖刁鉆、含敏感詞的基本就能撐起第一版回歸集。3.2 評估器的選擇誰來判斷這個(gè)答案好不好有了數(shù)據(jù)集接下來是定義評估邏輯。LangSmith 支持兩類評估器LLM-as-Judge和Heuristic就是規(guī)則判斷。很多初學(xué)者會(huì)陷入一個(gè)誤區(qū)只選一個(gè) LLM 評估器然后讓它判所有維度。結(jié)果就是評分忽高忽低沒法解釋。我建議做組合拳評估維度評估器類型說明答案正確性LLM-as-Judge用強(qiáng)模型對比標(biāo)準(zhǔn)答案判斷語義一致性忠實(shí)度/幻覺檢測LLM-as-Judge判斷答案內(nèi)容是否都能從給定上下文中找到依據(jù)答案引用率Heuristic檢查答案中的引用標(biāo)記是否都指向真實(shí)存在的文檔片段檢索相關(guān)性Heuristic計(jì)算檢索結(jié)果中相關(guān)文檔的覆蓋率比如 top-k 命中率回答拒絕率Heuristic對不該回答的問題是否正確觸發(fā)拒答流程自定義評估器其實(shí)就是一個(gè)函數(shù)輸入run和example輸出一個(gè)字典。LangSmith 會(huì)在評估時(shí)自動(dòng)把expected和prediction傳進(jìn)來。下面寫一個(gè)簡單的引用合規(guī)評估器from langsmith import evaluate def validate_citations(run, example): answer run.outputs.get(answer, ) doc_ids run.outputs.get(doc_ids, []) # 解析答案中的引用標(biāo)記 cited_ids extract_citation_ids(answer) invalid [cid for cid in cited_ids if cid not in doc_ids] score 1.0 if not invalid else 0.0 return {key: citation_validity, score: score, comment: f無效引用: {invalid}} evaluate( lambda input: app.invoke(input[question]), # 你的 RAG 入口函數(shù) dataRAG-Eval-Regression-Set, evaluators[validate_citations] )用evaluate跑完LangSmith 會(huì)生成一份評估報(bào)告按數(shù)據(jù)集逐條給出分?jǐn)?shù)并匯總成矩陣。這樣每次代碼改動(dòng)后你都可以快速跑一遍回歸不需要人肉看十幾條 trace。3.3 評估數(shù)據(jù)集要像測試用例一樣管理既然叫回歸集就得像代碼測試一樣做版本管理。LangSmith 的數(shù)據(jù)集支持指定dataset_id和對應(yīng)version。我建議每次修改評估集都新建一個(gè)版本不要在原數(shù)據(jù)集上直接改新功能發(fā)布前先往數(shù)據(jù)集里加入對應(yīng)的新用例至少讓模型見過這類場景線上出現(xiàn)嚴(yán)重 bad case 后第一時(shí)間把它沉淀進(jìn)數(shù)據(jù)集再調(diào)優(yōu)而不是修完就完事這樣做的好處是三個(gè)月后你再回頭看能清楚知道這個(gè)版本的評估集覆蓋了哪些場景遺留了哪些坑。4. 把評估從手工觸發(fā)變成發(fā)布必修課自動(dòng)化評估的落地細(xì)節(jié)數(shù)據(jù)集和評估器都就緒后核心問題是調(diào)度。LangSmith 的自動(dòng)化評估有兩種常見玩法我分別說下適用場景和容易踩的坑。4.1 離線回歸每次代碼合并前自動(dòng)跑一遍最理想的狀態(tài)是每次 PR 提出時(shí)CI 里自動(dòng)觸發(fā)一輪評估。LangSmith 提供了 Python SDK 和 REST API可以很方便地集成進(jìn)去。我的做法是在 CI 的某個(gè) Job 里拉取最新代碼啟動(dòng)一個(gè)測試環(huán)境然后運(yùn)行一條評估腳本pytest tests/evaluate_regression.py --dataset RAG-Eval-Regression-Set --threshold 0.85腳本內(nèi)部核心邏輯是調(diào)用 LangSmith 的evaluate()把線上測試 split 跑一遍結(jié)束后拿到評估報(bào)告。我可以設(shè)定一個(gè)閾值比如忠實(shí)度平均分低于 0.85 則構(gòu)建失敗。這樣就把感覺上好像沒問題變成了指標(biāo)上必須過關(guān)。注意評估時(shí)盡量用與線上一致的 Embedding 模型和 LLM 模型否則測出來的成績沒有參考價(jià)值。我見過有團(tuán)隊(duì)評估用大模型線上用小模型結(jié)果評估全綠上線后回歸效果一塌糊涂。更合理的做法是準(zhǔn)備一組評估專用模型配置和線上一致環(huán)境變量直接注入。4.2 在線監(jiān)控不是所有請求都能拿標(biāo)準(zhǔn)答案評估真實(shí)線上環(huán)境里大多數(shù)用戶請求沒有 ground truth 可對照。但這不代表不能做監(jiān)控。我常用的思路是反饋回路在生成答案的同時(shí)給每條請求生成一個(gè)隱式反饋事件比如在 UI 上加上點(diǎn)贊/點(diǎn)踩按鈕。LangSmith 支持通過client.create_feedback()把評分掛到對應(yīng) trace 上。之后可以在 LangSmith 里篩選出所有點(diǎn)踩的 trace集中分析。啟發(fā)式監(jiān)控對純規(guī)則可判斷的問題比如答案是否為空、答案是否包含我不知道、檢索是否返回 0 條結(jié)果用 LangSmith 的run元數(shù)據(jù)做聚合超過閾值自動(dòng)告警。client.create_feedback( run_idrun_id, keyuser_thumb, score0.0, comment用戶反饋答案不相關(guān) )這些反饋數(shù)據(jù)積累到一定量后可以回流到評估數(shù)據(jù)集里形成線上問題→回歸樣本的閉環(huán)。這也是為什么我在前面強(qiáng)調(diào)數(shù)據(jù)集要用真實(shí) trace 創(chuàng)建反哺鏈路才順。4.3 評估器自身的可信度小心Judge 被帶偏LLM-as-Judge 存在一個(gè)隱蔽但是致命的問題當(dāng)評估用的強(qiáng)模型本身也受 prompt 影響時(shí)評分會(huì)產(chǎn)生系統(tǒng)性偏差。比如你讓 GPT-4 當(dāng) Judge給一個(gè)答案簡潔但精準(zhǔn)的候選評分Judge 可能會(huì)因?yàn)榛卮鸩粔驘崆槎虻头?。這種偏差會(huì)通過回歸測試傳導(dǎo)到整個(gè)研發(fā)流程讓團(tuán)隊(duì)為了討好 Judge 而調(diào)整 prompt最后線上用戶的真實(shí)感受卻越來越差。針對這個(gè)坑我的經(jīng)驗(yàn)是Judge 的 prompt 要寫得像評分規(guī)則而不是喜好描述。明確說明只依據(jù)是否與標(biāo)準(zhǔn)答案語義一致來評分忽略風(fēng)格差異。定期人工抽檢評估報(bào)告。隨機(jī)抽 10 條評估結(jié)果人工判別 Judge 是否誤判。如果誤判率超過 20%說明 Judge prompt 需要重新設(shè)計(jì)。不一致時(shí)以 Heuristic 為準(zhǔn)。涉及可量化指標(biāo)如引用合規(guī)時(shí)不要用 Judge 覆蓋規(guī)則結(jié)果。評估器本身也要像被測系統(tǒng)一樣管理版本。我一般把每條評估器的 prompt 固定下來寫在代碼倉庫里配上system_prompt_version字段出問題能回滾。5. 進(jìn)階把評估指標(biāo)延伸到 RAG 的業(yè)務(wù)效果很多團(tuán)隊(duì)用 LangSmith 做到追蹤、評估就停在了回答正確性這一步。但對業(yè)務(wù)方來說答案正不正確只是中間指標(biāo)他們更關(guān)心用戶能不能一次解決問題回答有沒有促進(jìn)轉(zhuǎn)化。這部分沒法純靠 LLM-as-Judge 完成但可以在 LangSmith 的 trace 里加一層業(yè)務(wù)埋點(diǎn)。5.1 給關(guān)鍵業(yè)務(wù)動(dòng)作打上 trace 標(biāo)記我在不少項(xiàng)目里會(huì)在 RAG 應(yīng)用之外再上報(bào)一組業(yè)務(wù)事件。比如用戶是否在看完回答后點(diǎn)擊了詳情頁用戶是否在答案里找到了他想要的商品并加入購物車用戶是否重復(fù)提問同一類問題說明第一次沒解決這些事件不直接在鏈路追蹤里體現(xiàn)但它們可以關(guān)聯(lián)到同一個(gè)trace_id。LangSmith 允許你給 trace 附加元數(shù)據(jù)和反饋因此可以在業(yè)務(wù)后端把這些事件統(tǒng)一上報(bào)。client.create_feedback( run_idtrace_id, keytask_success, score1.0, comment用戶在回答后完成了下單動(dòng)作 )5.2 構(gòu)建指標(biāo)樹從鏈路指標(biāo)回歸業(yè)務(wù)目標(biāo)更完整的做法是建立一個(gè)三層指標(biāo)樹第一層 鏈路健康檢索延遲、生成延遲、token 消耗、錯(cuò)誤率 第二層 內(nèi)容質(zhì)量忠實(shí)度、引用合規(guī)率、上下文相關(guān)性、拒答準(zhǔn)確率 第三層 業(yè)務(wù)結(jié)果任務(wù)成功率、用戶滿意度、重復(fù)提問率LangSmith 的 trace 和 feedback 天然適合承載三層數(shù)據(jù)。你可以自定義一個(gè)數(shù)據(jù)面板Dashboard把這三層指標(biāo)按天聚合觀察趨勢變化。一旦業(yè)務(wù)結(jié)果指標(biāo)出現(xiàn)波動(dòng)順著 trace 往下鉆取通常能定位是在鏈路哪個(gè)環(huán)節(jié)出了偏差。5.3 壞樣本驅(qū)動(dòng)的持續(xù)優(yōu)化閉環(huán)從工具使用角度鏈路追蹤和評估最終需要形成一個(gè)運(yùn)轉(zhuǎn)閉環(huán)線上異常 → 沉淀到評估集 → 離線回歸暴露根因 → 修復(fù)/調(diào)優(yōu) → 再次回歸驗(yàn)證 → 發(fā)布上線 → 持續(xù)監(jiān)控LangSmith 只是讓這個(gè)閉環(huán)里的每一步都有了數(shù)據(jù)支撐。真正決定效果的是團(tuán)隊(duì)有沒有養(yǎng)成主動(dòng)沉淀壞樣本而不是只救火的習(xí)慣。我見過一些團(tuán)隊(duì)把 LangSmith 用得風(fēng)生水起核心差異就在于他們每周會(huì)固定留出時(shí)間把一周的新 bad case 轉(zhuǎn)化為新的評估樣本讓系統(tǒng)越用越聰明。6. 我的經(jīng)驗(yàn)補(bǔ)遺接入 LangSmith 前后容易忽略的細(xì)節(jié)最后分享幾個(gè)實(shí)操中容易踩的坑能省下不少折騰時(shí)間。6.1 環(huán)境變量與 API Key 隔離LangSmith 的客戶端通過環(huán)境變量控制上報(bào)目標(biāo)。如果你有多個(gè)環(huán)境dev、staging、prod一定要嚴(yán)格隔離 API Key 和 project 名。我遇到過因?yàn)闆]有區(qū)分環(huán)境開發(fā)時(shí)用的噪音數(shù)據(jù)污染了正式項(xiàng)目的評估集導(dǎo)致回歸測試越來越離譜。建議每個(gè)環(huán)境單獨(dú)申請一個(gè) API Key且在代碼里顯式聲明LANGSMITH_TRACINGtrue LANGSMITH_ENDPOINThttps://api.smith.langchain.com LANGSMITH_API_KEYyour_env_specific_key LANGSMITH_PROJECTrag-prod6.2 埋點(diǎn)別忘排除隱私字段RAG 應(yīng)用經(jīng)常輸入包含用戶隱私信息的內(nèi)容比如企業(yè)內(nèi)部資料、個(gè)人信息片段。在開啟自動(dòng)埋點(diǎn)前先想想是否需要脫敏。我這里用traceable的方式會(huì)在函數(shù)輸入輸出里自動(dòng)記錄實(shí)際內(nèi)容所以我在傳入前先做一層脫敏只保留問題與文檔 ID不保留完整文檔正文。這樣既不會(huì)讓敏感數(shù)據(jù)進(jìn)入 trace又能滿足排查需求。6.3 評估閾值不要太激進(jìn)評估指標(biāo)全綠并不代表線上一定沒問題這是所有自動(dòng)化評估體系的共同邊界。我建議把閾值設(shè)定在能攔住明顯回歸的程度就夠不要追求 100% 通過。因?yàn)槟Ｐ陀须S機(jī)性同一問題在不同溫度下可能會(huì)輸出不同答案設(shè)定過高的閾值只會(huì)讓團(tuán)隊(duì)把時(shí)間浪費(fèi)在重跑和調(diào)整 prompt 上。具體來說忠實(shí)度平均分和引用合規(guī)率可以設(shè) 0.85 作為底線但單條樣本低于 0.5 才會(huì)被標(biāo)記為明顯回歸。真正高優(yōu)先級的告警是出現(xiàn)在核心場景樣本上的大幅下滑而不是某個(gè)邊角樣本的單點(diǎn)波動(dòng)。6.4 別忘了人工抽檢工具的終極目標(biāo)是輔助決策而不是替代決策。我始終保留每周一次的人工抽檢機(jī)制從線上隨機(jī)抽 20 條 trace逐個(gè)看一遍 retrieval 得分和生成答案確認(rèn)評估器沒有漂移。LangSmith 的 UI 讓這個(gè)抽檢過程非常高效不需要額外寫統(tǒng)計(jì)分析工具。這套體系跑了一段時(shí)間后我最大的感受是鏈路追蹤解決的是看得見自動(dòng)化評估解決的是守得住兩者配合起來RAG 應(yīng)用才有了持續(xù)交付的基本保障。如果你正在做的項(xiàng)目也遇到類似問題建議別急著調(diào) prompt先把鏈路數(shù)據(jù)和評估閉環(huán)搭起來。有了數(shù)據(jù)你做的每個(gè)決策都會(huì)更有底氣。 基于LangSmith的RAG鏈路追蹤與自動(dòng)化評估實(shí)踐
做 RAG 應(yīng)用快兩年了最讓我頭疼的從來不是模型選型也不是向量庫調(diào)優(yōu)而是根本說不清楚系統(tǒng)到底哪里出了問題。用戶說回答不對你問他怎么個(gè)不對法他說就是感覺不對。你翻日志、查 prompt、調(diào)參數(shù)忙活一整天最后還是靠猜。后來我把 LangSmith 用起來才算是把這條鏈路從黑盒變成了透明再從透明升級到自動(dòng)把關(guān)。這篇就聊聊我怎么從零開始接鏈路追蹤又怎么一步步把它變成一套 RAG 自動(dòng)化評估體系的。1. 鏈路追蹤到底在追什么先弄懂 LangSmith 的工作機(jī)理很多朋友一上來就急著看 UI、看 span 列表其實(shí)沒搞清楚 LangSmith 的底層邏輯后面排查問題就很容易被界面上的信息帶偏。1.1 一次 RAG 請求在 LangSmith 里是怎樣被拆解的LangSmith 的核心概念其實(shí)只有幾個(gè)Run、Span、Trace。一次用戶請求進(jìn)來LangSmith 會(huì)把它記為一條Trace里面嵌套若干個(gè)Run。以最常見的 RAG 流程為例一個(gè)Trace大致長這樣RetrieveRun查向量庫 └── QueryEmbeddingRun問題向量化 └── VectorStoreSearchRun相似度檢索 └── DocumentPostProcessRun重排/截?cái)?GenerateRun模型生成 └── PromptBuildRun拼 prompt └── LLMInvokeRun調(diào)用大模型每條Run都會(huì)記錄輸入、輸出、耗時(shí)、token 消耗以及自定義的元數(shù)據(jù)。真正好用的地方在于你可以給任意一個(gè)Run掛上你自己關(guān)心的指標(biāo)比如檢索結(jié)果里到底有幾個(gè)是真正相關(guān)的最終答案引用了哪幾個(gè)文檔片段。1.2 埋點(diǎn)方式選擇自動(dòng)埋點(diǎn)與手動(dòng)埋點(diǎn)的適用時(shí)機(jī)LangSmith 提供兩種接入方式很多人不知道該怎么選。我的建議很簡單如果用的是 LangChain 框架直接用自動(dòng)埋點(diǎn)如果你像我一樣是手寫 RAG 管線老老實(shí)實(shí)手動(dòng)埋點(diǎn)。自動(dòng)埋點(diǎn)的好處是零侵入wrap_openai()或設(shè)置環(huán)境變量后框架內(nèi)部會(huì)自動(dòng)生成 trace。但代價(jià)是你只能看到框架替你記錄的內(nèi)容想記錄檢索結(jié)果相關(guān)性評分這種自定義字段還得額外寫代碼。手動(dòng)埋點(diǎn)雖然多寫幾行但靈活度完全可控。我現(xiàn)在的做法是半自動(dòng)框架調(diào)用用自動(dòng)埋點(diǎn)自定義邏輯用run_tree手動(dòng)包一層兩邊互不干擾。from langsmith import Client, traceable traceable(run_typechain, nameRetrieveDocuments) def retrieve_documents(question: str, top_k: int 5): # 這里可以是任意檢索邏輯 docs, scores vector_store.search_with_score(question, top_ktop_k) return {docs: docs, scores: scores} traceable(run_typellm, nameGenerateAnswer) def generate_answer(question: str, context: list[str]): prompt build_prompt(question, context) return llm.invoke(prompt)加了traceable之后函數(shù)輸入輸出會(huì)自動(dòng)出現(xiàn)在 LangSmith 的 trace 詳情頁里。注意run_type不要亂填chain、llm、retriever、embedding這幾個(gè)類型對應(yīng)的 UI 渲染和信息聚合邏輯差很多。1.3 只記錄最有價(jià)值的信息很多人埋點(diǎn)走極端要么什么都不記要么把所有東西全都塞進(jìn)去。token 多的請求會(huì)讓 trace 頁面變得極其卡頓而且真正排查問題時(shí)反而找不到重點(diǎn)。我習(xí)慣在每個(gè) Run 里至少掛上這幾類信息- input_question用戶原始問題 - retrieval_scores各候選文檔的相似度得分 - context_truncation上下文截?cái)嗖呗耘c實(shí)際保留長度 - model_params實(shí)際生效的溫度、top_p 等參數(shù) - ground_truth_doc_ids這個(gè)請求關(guān)聯(lián)的標(biāo)準(zhǔn)答案文檔 ID評估階段用尤其是ground_truth_doc_ids這個(gè)字段很多團(tuán)隊(duì)會(huì)忽略。它能在你回看 trace 時(shí)快速判斷當(dāng)時(shí)這個(gè)答案到底有沒有按預(yù)期引用正確的文檔是后面構(gòu)建評估集的重要錨點(diǎn)。2. 從 trace 里定位 RAG 的高發(fā)事故現(xiàn)場接好埋點(diǎn)后LangSmith 的 traces 頁面會(huì)開始積累數(shù)據(jù)。但數(shù)據(jù)多不代表有價(jià)值你得學(xué)會(huì)在 trace 里快速定位那幾類典型問題。我總結(jié)了 RAG 應(yīng)用最高發(fā)的四類問題每個(gè)都有對應(yīng)的 trace 特征。2.1 檢索召回偏移問題在 Embedding 而不是關(guān)鍵詞表現(xiàn)用戶在 UI 上問蘋果公司的創(chuàng)始人是誰回答卻引用了蘋果作為一種水果的營養(yǎng)價(jià)值。這類問題看 trace 最容易發(fā)現(xiàn)。點(diǎn)開RetrieveRun你會(huì)發(fā)現(xiàn) QueryEmbeddingRun 生成向量沒問題VectorStoreSearchRun 的得分也不算低但返回的文檔片段在語義上明顯跑偏。問題不在鏈路而在 Embedding 模型本身對某些領(lǐng)域詞匯的區(qū)分度不夠。排查思路別急著換 Embedding 模型。先在 trace 里對比問題向量與正確答案向量的相似度和問題向量與錯(cuò)誤候選向量的相似度。很多時(shí)候你會(huì)發(fā)現(xiàn)兩者差距很小這屬于模型能力邊界問題。此時(shí)可以考慮對原始輸入做查詢改寫或者用 Hybrid Search 搭配 BM25把關(guān)鍵詞匹配這一路也拉進(jìn)來兜底。2.2 上下文爆炸還記得自己輸出了多少 token 嗎表現(xiàn)答案質(zhì)量沒變差但響應(yīng)延遲從 1.5 秒慢慢爬升到 5 秒以上賬單金額也在悄悄變多。查看 trace 里的 GenerateRun重點(diǎn)關(guān)注prompt_tokens和raw_input里的上下文長度。這個(gè)問題通常不是 Retrieval 階段查多了而是你塞進(jìn)去的補(bǔ)充資料太多了。比如我在某個(gè)項(xiàng)目里發(fā)現(xiàn)開發(fā)同學(xué)為了提升回答質(zhì)量在 prompt 里加了行業(yè)知識(shí)庫的 8 個(gè)固定條目每個(gè)條目都有上千字而 RAG 檢索答案只需 1-2 個(gè)條目就足夠。解決方向有兩個(gè)一是檢索階段嚴(yán)格控制top_k比如從 5 降到 3配合重排序模型只保留 top 2二是對檢索到的文檔做相關(guān)性截?cái)嗟陀陂撝档膱?jiān)決不放行寧缺毋濫。2.3 幻覺根因追蹤回答內(nèi)容到底引用了哪一句表現(xiàn)答案聽起來頭頭是道但每條論據(jù)在原始文檔里都找不到出處。LangSmith 的 trace 頁有個(gè)很實(shí)用的功能你可以在GenerateRun的 output 里直接看到最終答案的哪句話引用了哪個(gè)文檔塊。但如果你的 prompt 里沒有讓模型輸出引用標(biāo)記如 [1][2]這里只會(huì)在引用文檔列表區(qū)域顯示檢索片的得分看不出具體對應(yīng)關(guān)系。我的習(xí)慣是在 prompt 里強(qiáng)制模型按上下文引用的文檔序號(hào)標(biāo)注答案比如說回答時(shí)請基于提供的上下文并在句子末尾使用 [數(shù)字] 標(biāo)注依據(jù)的文檔序號(hào)。這樣 trace 里就能看到answer: 蘋果公司由喬布斯創(chuàng)立[1]再點(diǎn)開[1]所對文檔的實(shí)際內(nèi)容問題是否出在模型自己腦補(bǔ)了內(nèi)容還是上下文里其實(shí)有但模型漏看了一目了然。如果發(fā)現(xiàn)答案引用了文檔 [2]但 trace 里顯示的檢索得分很低那就說明檢索鏈路把不相關(guān)的內(nèi)容也放進(jìn)了上下文回到了 2.1 的范疇。2.4 延遲瓶頸定位耗時(shí)到底花在哪一步KPI 飆升的另一大來源是延遲。看 trace 的每個(gè)Run耗時(shí)分布如果 QueryEmbedding 和 VectorStoreSearch 加起來只占 200msLLM 調(diào)用占 3.5s瓶頸在生成環(huán)節(jié)。此時(shí)你該檢查是不是 prompt 塞得太長或者溫度、max_tokens是否合理而不是去優(yōu)化向量庫。如果 VectorStoreSearch 本身就占了 2s先檢查是不是沒走 ANN 索引而是全表掃描或者自定義過濾條件太多導(dǎo)致索引失效。這些在常規(guī)日志里很難定位但在 trace 里一眼就能看出來。3. 從看一眼到有標(biāo)準(zhǔn)用 LangSmith 沉淀真實(shí)的評估數(shù)據(jù)集鏈路追蹤解決的是出問題時(shí)快速定位但如果每次都要人肉看 trace團(tuán)隊(duì)規(guī)模一大還是扛不住。更關(guān)鍵的問題是你怎么知道這次改動(dòng)是變好了還是變壞了要回答這個(gè)問題就得把評估從人看變成自動(dòng)跑這是 LangSmith 最有價(jià)值的部分也是標(biāo)題里自動(dòng)化評估的真正含義。3.1 數(shù)據(jù)集從哪來直接復(fù)用線上真實(shí)請求LangSmith 里可以直接把某條 trace 創(chuàng)建為數(shù)據(jù)集樣本。這個(gè)功能實(shí)用程度遠(yuǎn)超想象。具體操作在 trace 詳情頁選一條有代表性的回答點(diǎn)擊添加到數(shù)據(jù)集LangSmith 會(huì)自動(dòng)把輸入問題抓下來。你可以順手在outputs里補(bǔ)上 ground truth 答案或相關(guān)文檔 ID。我個(gè)人的做法是每條樣本至少包含三項(xiàng)內(nèi)容——輸入問題、標(biāo)準(zhǔn)答案或標(biāo)準(zhǔn)引用文檔 ID、期望的拒絕行為可選。from langsmith import Client client Client() dataset client.create_dataset( dataset_nameRAG-Eval-Regression-Set, description面向核心業(yè)務(wù)場景的 RAG 回歸標(biāo)準(zhǔn)集 ) client.create_examples( dataset_iddataset.id, inputs[ {question: 我們產(chǎn)品的退款政策是什么}, {question: 對接 API 時(shí)出現(xiàn) 401 錯(cuò)誤怎么解決} ], outputs[ {answer: 退款政策見幫助中心條款 3.2 節(jié)支持 7 天無理由退款。, doc_ids: [faq-3.2]}, {answer: 401 錯(cuò)誤通常由 API 密鑰無效或過期導(dǎo)致詳見對接文檔第 4 節(jié)。, doc_ids: [api-doc-4]} ] )數(shù)據(jù)集不需要一開始就做到幾百上千條。我通常從真實(shí)用戶反饋中挑 30~50 條最典型的再讓運(yùn)營同學(xué)補(bǔ)充一部分邊角場景的毒問題比如意圖刁鉆、含敏感詞的基本就能撐起第一版回歸集。3.2 評估器的選擇誰來判斷這個(gè)答案好不好有了數(shù)據(jù)集接下來是定義評估邏輯。LangSmith 支持兩類評估器LLM-as-Judge和Heuristic就是規(guī)則判斷。很多初學(xué)者會(huì)陷入一個(gè)誤區(qū)只選一個(gè) LLM 評估器然后讓它判所有維度。結(jié)果就是評分忽高忽低沒法解釋。我建議做組合拳評估維度評估器類型說明答案正確性LLM-as-Judge用強(qiáng)模型對比標(biāo)準(zhǔn)答案判斷語義一致性忠實(shí)度/幻覺檢測LLM-as-Judge判斷答案內(nèi)容是否都能從給定上下文中找到依據(jù)答案引用率Heuristic檢查答案中的引用標(biāo)記是否都指向真實(shí)存在的文檔片段檢索相關(guān)性Heuristic計(jì)算檢索結(jié)果中相關(guān)文檔的覆蓋率比如 top-k 命中率回答拒絕率Heuristic對不該回答的問題是否正確觸發(fā)拒答流程自定義評估器其實(shí)就是一個(gè)函數(shù)輸入run和example輸出一個(gè)字典。LangSmith 會(huì)在評估時(shí)自動(dòng)把expected和prediction傳進(jìn)來。下面寫一個(gè)簡單的引用合規(guī)評估器from langsmith import evaluate def validate_citations(run, example): answer run.outputs.get(answer, ) doc_ids run.outputs.get(doc_ids, []) # 解析答案中的引用標(biāo)記 cited_ids extract_citation_ids(answer) invalid [cid for cid in cited_ids if cid not in doc_ids] score 1.0 if not invalid else 0.0 return {key: citation_validity, score: score, comment: f無效引用: {invalid}} evaluate( lambda input: app.invoke(input[question]), # 你的 RAG 入口函數(shù) dataRAG-Eval-Regression-Set, evaluators[validate_citations] )用evaluate跑完LangSmith 會(huì)生成一份評估報(bào)告按數(shù)據(jù)集逐條給出分?jǐn)?shù)并匯總成矩陣。這樣每次代碼改動(dòng)后你都可以快速跑一遍回歸不需要人肉看十幾條 trace。3.3 評估數(shù)據(jù)集要像測試用例一樣管理既然叫回歸集就得像代碼測試一樣做版本管理。LangSmith 的數(shù)據(jù)集支持指定dataset_id和對應(yīng)version。我建議每次修改評估集都新建一個(gè)版本不要在原數(shù)據(jù)集上直接改新功能發(fā)布前先往數(shù)據(jù)集里加入對應(yīng)的新用例至少讓模型見過這類場景線上出現(xiàn)嚴(yán)重 bad case 后第一時(shí)間把它沉淀進(jìn)數(shù)據(jù)集再調(diào)優(yōu)而不是修完就完事這樣做的好處是三個(gè)月后你再回頭看能清楚知道這個(gè)版本的評估集覆蓋了哪些場景遺留了哪些坑。4. 把評估從手工觸發(fā)變成發(fā)布必修課自動(dòng)化評估的落地細(xì)節(jié)數(shù)據(jù)集和評估器都就緒后核心問題是調(diào)度。LangSmith 的自動(dòng)化評估有兩種常見玩法我分別說下適用場景和容易踩的坑。4.1 離線回歸每次代碼合并前自動(dòng)跑一遍最理想的狀態(tài)是每次 PR 提出時(shí)CI 里自動(dòng)觸發(fā)一輪評估。LangSmith 提供了 Python SDK 和 REST API可以很方便地集成進(jìn)去。我的做法是在 CI 的某個(gè) Job 里拉取最新代碼啟動(dòng)一個(gè)測試環(huán)境然后運(yùn)行一條評估腳本pytest tests/evaluate_regression.py --dataset RAG-Eval-Regression-Set --threshold 0.85腳本內(nèi)部核心邏輯是調(diào)用 LangSmith 的evaluate()把線上測試 split 跑一遍結(jié)束后拿到評估報(bào)告。我可以設(shè)定一個(gè)閾值比如忠實(shí)度平均分低于 0.85 則構(gòu)建失敗。這樣就把感覺上好像沒問題變成了指標(biāo)上必須過關(guān)。注意評估時(shí)盡量用與線上一致的 Embedding 模型和 LLM 模型否則測出來的成績沒有參考價(jià)值。我見過有團(tuán)隊(duì)評估用大模型線上用小模型結(jié)果評估全綠上線后回歸效果一塌糊涂。更合理的做法是準(zhǔn)備一組評估專用模型配置和線上一致環(huán)境變量直接注入。4.2 在線監(jiān)控不是所有請求都能拿標(biāo)準(zhǔn)答案評估真實(shí)線上環(huán)境里大多數(shù)用戶請求沒有 ground truth 可對照。但這不代表不能做監(jiān)控。我常用的思路是反饋回路在生成答案的同時(shí)給每條請求生成一個(gè)隱式反饋事件比如在 UI 上加上點(diǎn)贊/點(diǎn)踩按鈕。LangSmith 支持通過client.create_feedback()把評分掛到對應(yīng) trace 上。之后可以在 LangSmith 里篩選出所有點(diǎn)踩的 trace集中分析。啟發(fā)式監(jiān)控對純規(guī)則可判斷的問題比如答案是否為空、答案是否包含我不知道、檢索是否返回 0 條結(jié)果用 LangSmith 的run元數(shù)據(jù)做聚合超過閾值自動(dòng)告警。client.create_feedback( run_idrun_id, keyuser_thumb, score0.0, comment用戶反饋答案不相關(guān) )這些反饋數(shù)據(jù)積累到一定量后可以回流到評估數(shù)據(jù)集里形成線上問題→回歸樣本的閉環(huán)。這也是為什么我在前面強(qiáng)調(diào)數(shù)據(jù)集要用真實(shí) trace 創(chuàng)建反哺鏈路才順。4.3 評估器自身的可信度小心Judge 被帶偏LLM-as-Judge 存在一個(gè)隱蔽但是致命的問題當(dāng)評估用的強(qiáng)模型本身也受 prompt 影響時(shí)評分會(huì)產(chǎn)生系統(tǒng)性偏差。比如你讓 GPT-4 當(dāng) Judge給一個(gè)答案簡潔但精準(zhǔn)的候選評分Judge 可能會(huì)因?yàn)榛卮鸩粔驘崆槎虻头?。這種偏差會(huì)通過回歸測試傳導(dǎo)到整個(gè)研發(fā)流程讓團(tuán)隊(duì)為了討好 Judge 而調(diào)整 prompt最后線上用戶的真實(shí)感受卻越來越差。針對這個(gè)坑我的經(jīng)驗(yàn)是Judge 的 prompt 要寫得像評分規(guī)則而不是喜好描述。明確說明只依據(jù)是否與標(biāo)準(zhǔn)答案語義一致來評分忽略風(fēng)格差異。定期人工抽檢評估報(bào)告。隨機(jī)抽 10 條評估結(jié)果人工判別 Judge 是否誤判。如果誤判率超過 20%說明 Judge prompt 需要重新設(shè)計(jì)。不一致時(shí)以 Heuristic 為準(zhǔn)。涉及可量化指標(biāo)如引用合規(guī)時(shí)不要用 Judge 覆蓋規(guī)則結(jié)果。評估器本身也要像被測系統(tǒng)一樣管理版本。我一般把每條評估器的 prompt 固定下來寫在代碼倉庫里配上system_prompt_version字段出問題能回滾。5. 進(jìn)階把評估指標(biāo)延伸到 RAG 的業(yè)務(wù)效果很多團(tuán)隊(duì)用 LangSmith 做到追蹤、評估就停在了回答正確性這一步。但對業(yè)務(wù)方來說答案正不正確只是中間指標(biāo)他們更關(guān)心用戶能不能一次解決問題回答有沒有促進(jìn)轉(zhuǎn)化。這部分沒法純靠 LLM-as-Judge 完成但可以在 LangSmith 的 trace 里加一層業(yè)務(wù)埋點(diǎn)。5.1 給關(guān)鍵業(yè)務(wù)動(dòng)作打上 trace 標(biāo)記我在不少項(xiàng)目里會(huì)在 RAG 應(yīng)用之外再上報(bào)一組業(yè)務(wù)事件。比如用戶是否在看完回答后點(diǎn)擊了詳情頁用戶是否在答案里找到了他想要的商品并加入購物車用戶是否重復(fù)提問同一類問題說明第一次沒解決這些事件不直接在鏈路追蹤里體現(xiàn)但它們可以關(guān)聯(lián)到同一個(gè)trace_id。LangSmith 允許你給 trace 附加元數(shù)據(jù)和反饋因此可以在業(yè)務(wù)后端把這些事件統(tǒng)一上報(bào)。client.create_feedback( run_idtrace_id, keytask_success, score1.0, comment用戶在回答后完成了下單動(dòng)作 )5.2 構(gòu)建指標(biāo)樹從鏈路指標(biāo)回歸業(yè)務(wù)目標(biāo)更完整的做法是建立一個(gè)三層指標(biāo)樹第一層 鏈路健康檢索延遲、生成延遲、token 消耗、錯(cuò)誤率 第二層 內(nèi)容質(zhì)量忠實(shí)度、引用合規(guī)率、上下文相關(guān)性、拒答準(zhǔn)確率 第三層 業(yè)務(wù)結(jié)果任務(wù)成功率、用戶滿意度、重復(fù)提問率LangSmith 的 trace 和 feedback 天然適合承載三層數(shù)據(jù)。你可以自定義一個(gè)數(shù)據(jù)面板Dashboard把這三層指標(biāo)按天聚合觀察趨勢變化。一旦業(yè)務(wù)結(jié)果指標(biāo)出現(xiàn)波動(dòng)順著 trace 往下鉆取通常能定位是在鏈路哪個(gè)環(huán)節(jié)出了偏差。5.3 壞樣本驅(qū)動(dòng)的持續(xù)優(yōu)化閉環(huán)從工具使用角度鏈路追蹤和評估最終需要形成一個(gè)運(yùn)轉(zhuǎn)閉環(huán)線上異常 → 沉淀到評估集 → 離線回歸暴露根因 → 修復(fù)/調(diào)優(yōu) → 再次回歸驗(yàn)證 → 發(fā)布上線 → 持續(xù)監(jiān)控LangSmith 只是讓這個(gè)閉環(huán)里的每一步都有了數(shù)據(jù)支撐。真正決定效果的是團(tuán)隊(duì)有沒有養(yǎng)成主動(dòng)沉淀壞樣本而不是只救火的習(xí)慣。我見過一些團(tuán)隊(duì)把 LangSmith 用得風(fēng)生水起核心差異就在于他們每周會(huì)固定留出時(shí)間把一周的新 bad case 轉(zhuǎn)化為新的評估樣本讓系統(tǒng)越用越聰明。6. 我的經(jīng)驗(yàn)補(bǔ)遺接入 LangSmith 前后容易忽略的細(xì)節(jié)最后分享幾個(gè)實(shí)操中容易踩的坑能省下不少折騰時(shí)間。6.1 環(huán)境變量與 API Key 隔離LangSmith 的客戶端通過環(huán)境變量控制上報(bào)目標(biāo)。如果你有多個(gè)環(huán)境dev、staging、prod一定要嚴(yán)格隔離 API Key 和 project 名。我遇到過因?yàn)闆]有區(qū)分環(huán)境開發(fā)時(shí)用的噪音數(shù)據(jù)污染了正式項(xiàng)目的評估集導(dǎo)致回歸測試越來越離譜。建議每個(gè)環(huán)境單獨(dú)申請一個(gè) API Key且在代碼里顯式聲明LANGSMITH_TRACINGtrue LANGSMITH_ENDPOINThttps://api.smith.langchain.com LANGSMITH_API_KEYyour_env_specific_key LANGSMITH_PROJECTrag-prod6.2 埋點(diǎn)別忘排除隱私字段RAG 應(yīng)用經(jīng)常輸入包含用戶隱私信息的內(nèi)容比如企業(yè)內(nèi)部資料、個(gè)人信息片段。在開啟自動(dòng)埋點(diǎn)前先想想是否需要脫敏。我這里用traceable的方式會(huì)在函數(shù)輸入輸出里自動(dòng)記錄實(shí)際內(nèi)容所以我在傳入前先做一層脫敏只保留問題與文檔 ID不保留完整文檔正文。這樣既不會(huì)讓敏感數(shù)據(jù)進(jìn)入 trace又能滿足排查需求。6.3 評估閾值不要太激進(jìn)評估指標(biāo)全綠并不代表線上一定沒問題這是所有自動(dòng)化評估體系的共同邊界。我建議把閾值設(shè)定在能攔住明顯回歸的程度就夠不要追求 100% 通過。因?yàn)槟Ｐ陀须S機(jī)性同一問題在不同溫度下可能會(huì)輸出不同答案設(shè)定過高的閾值只會(huì)讓團(tuán)隊(duì)把時(shí)間浪費(fèi)在重跑和調(diào)整 prompt 上。具體來說忠實(shí)度平均分和引用合規(guī)率可以設(shè) 0.85 作為底線但單條樣本低于 0.5 才會(huì)被標(biāo)記為明顯回歸。真正高優(yōu)先級的告警是出現(xiàn)在核心場景樣本上的大幅下滑而不是某個(gè)邊角樣本的單點(diǎn)波動(dòng)。6.4 別忘了人工抽檢工具的終極目標(biāo)是輔助決策而不是替代決策。我始終保留每周一次的人工抽檢機(jī)制從線上隨機(jī)抽 20 條 trace逐個(gè)看一遍 retrieval 得分和生成答案確認(rèn)評估器沒有漂移。LangSmith 的 UI 讓這個(gè)抽檢過程非常高效不需要額外寫統(tǒng)計(jì)分析工具。這套體系跑了一段時(shí)間后我最大的感受是鏈路追蹤解決的是看得見自動(dòng)化評估解決的是守得住兩者配合起來RAG 應(yīng)用才有了持續(xù)交付的基本保障。如果你正在做的項(xiàng)目也遇到類似問題建議別急著調(diào) prompt先把鏈路數(shù)據(jù)和評估閉環(huán)搭起來。有了數(shù)據(jù)你做的每個(gè)決策都會(huì)更有底氣。