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