AI這兩年已經(jīng)從“能聊天”進(jìn)化到“能扛事”了。我說(shuō)的“扛事”是指像軍事化競(jìng)標(biāo)這類把可靠性、合規(guī)性和對(duì)抗性拉到極致的交付場(chǎng)景——評(píng)分標(biāo)準(zhǔn)極其嚴(yán)苛驗(yàn)收周期卡得死出了問(wèn)題不是返工而是出局。最近我連續(xù)參與了幾個(gè)高對(duì)抗性AI項(xiàng)目的測(cè)試評(píng)審一個(gè)特別強(qiáng)烈的感受是軟件測(cè)試工程師的處境正在被AI系統(tǒng)性地重構(gòu)。有人覺(jué)得AI把測(cè)試崗位變成了難題有人卻看到了新一輪的能力溢價(jià)。這篇文章不聊宏觀趨勢(shì)只講正在發(fā)生的真實(shí)情況AI軍事化競(jìng)標(biāo)背后的測(cè)試風(fēng)暴到底刮在哪里軟件測(cè)試工程師在哪些環(huán)節(jié)栽跟頭又能在哪些環(huán)節(jié)實(shí)現(xiàn)彎道超車。1. AI軍事化競(jìng)標(biāo)測(cè)試為什么成了風(fēng)暴中心先解釋一下我在這里用“軍事化競(jìng)標(biāo)”指什么。它不是說(shuō)某個(gè)特定領(lǐng)域的項(xiàng)目而是形容一種把標(biāo)準(zhǔn)拉到極限的競(jìng)標(biāo)場(chǎng)景客戶對(duì)系統(tǒng)的成功率、誤報(bào)率、響應(yīng)時(shí)間、抗干擾能力都有硬性指標(biāo)任何一項(xiàng)不達(dá)標(biāo)就直接淘汰。在這種場(chǎng)景下AI系統(tǒng)不再是“做一個(gè)能用的東西”而是“做一個(gè)經(jīng)得起全維度審查的東西”。1.1 從“功能驗(yàn)證”到“系統(tǒng)對(duì)抗”的測(cè)試角色變遷傳統(tǒng)軟件測(cè)試的日常是打開(kāi)頁(yè)面、調(diào)用接口、輸入數(shù)據(jù)、比對(duì)預(yù)期結(jié)果。這套玩法建立在“需求是確定的、邏輯是可窮舉的、bug是可復(fù)現(xiàn)的”這三個(gè)前提之上。但AI系統(tǒng)完全打破這三個(gè)前提——模型輸出概率化、行為空間巨大、很多缺陷在特定數(shù)據(jù)分布下才暴露。軍事化競(jìng)標(biāo)場(chǎng)景把這種矛盾放大了?？蛻粢竽阕C明的不只是“這個(gè)AI能干活”還包括“這個(gè)AI在極端輸入下不會(huì)崩”“它在數(shù)據(jù)漂移后依然穩(wěn)定”“它不會(huì)給出帶有歧視性的結(jié)果”“它能被審計(jì)和追溯”。這些要求全部落到了測(cè)試工程師頭上。我見(jiàn)過(guò)一個(gè)很典型的案例某AI圖像識(shí)別方案的招標(biāo)評(píng)測(cè)里12項(xiàng)評(píng)分指標(biāo)中有3項(xiàng)都是對(duì)抗樣本相關(guān)。有些團(tuán)隊(duì)模型本身訓(xùn)練得不錯(cuò)但根本沒(méi)有對(duì)抗樣本測(cè)試管線連評(píng)測(cè)環(huán)境都沒(méi)有直接失去資格。這就說(shuō)明一個(gè)問(wèn)題測(cè)試已經(jīng)從開(kāi)發(fā)的最后一道工序變成了進(jìn)入戰(zhàn)場(chǎng)的第一道門(mén)檻。1.2 競(jìng)標(biāo)場(chǎng)景下測(cè)試的“8倍放大效應(yīng)”有句老話叫“臺(tái)上一分鐘臺(tái)下十年功”用在AI競(jìng)標(biāo)里非常貼切。常規(guī)開(kāi)發(fā)項(xiàng)目中測(cè)試投入通常只占開(kāi)發(fā)成本的10%左右但在高對(duì)抗競(jìng)標(biāo)中測(cè)試結(jié)論可能決定100%的成敗。原因有三。第一評(píng)標(biāo)方無(wú)法在短時(shí)間內(nèi)部署并驗(yàn)證全部真實(shí)業(yè)務(wù)場(chǎng)景只能依賴你提交的測(cè)試證據(jù)鏈。第二AI系統(tǒng)具有不可完全預(yù)知性評(píng)標(biāo)方會(huì)重點(diǎn)審查你的測(cè)試覆蓋是否足夠、風(fēng)險(xiǎn)是否合理暴露。第三一旦中標(biāo)后驗(yàn)收階段出現(xiàn)問(wèn)題追責(zé)時(shí)會(huì)回溯到投標(biāo)時(shí)的測(cè)試報(bào)告報(bào)告就成了“呈堂證供”。所以你現(xiàn)在去看那些競(jìng)標(biāo)成功團(tuán)隊(duì)的測(cè)試文檔普遍具備三個(gè)特征可復(fù)現(xiàn)給出具體命令、代碼版本和數(shù)據(jù)版本、可追溯每個(gè)結(jié)論都能找到原始記錄、可審計(jì)明確標(biāo)注測(cè)試范圍、未覆蓋項(xiàng)和殘余風(fēng)險(xiǎn)。這三個(gè)特征恰恰是傳統(tǒng)測(cè)試工程師最熟悉的“用例管理”能力。測(cè)試這項(xiàng)手藝沒(méi)有過(guò)時(shí)只是從后臺(tái)走向了前臺(tái)。2. 傳統(tǒng)軟件測(cè)試方法論在AI系統(tǒng)前的四個(gè)失靈點(diǎn)如果你想用老一套方法測(cè)AI系統(tǒng)一定會(huì)踩壁。下面這四個(gè)失靈點(diǎn)是我在實(shí)際項(xiàng)目中反復(fù)遇到的也是很多測(cè)試團(tuán)隊(duì)轉(zhuǎn)型時(shí)最困惑的地方。2.1 預(yù)期結(jié)果不確定沒(méi)有Oracle的斷言困境傳統(tǒng)測(cè)試用例的核心是斷言輸入A應(yīng)該輸出B否則就是bug。到了AI這里“應(yīng)該輸出B”這件事變得很難定義。一個(gè)語(yǔ)言模型面對(duì)“給用戶推薦一款適合冬季跑步的耳機(jī)”這種問(wèn)題答案可以有一萬(wàn)種沒(méi)有唯一正確值。業(yè)界把這個(gè)問(wèn)題叫“測(cè)試Oracle缺失”——Oracle在這里指用來(lái)判斷被測(cè)對(duì)象結(jié)果是否正確的一個(gè)參照物。這不是說(shuō)斷言沒(méi)法做了而是要換一種方式。我目前的實(shí)操做法是雙通道驗(yàn)證第一通道是可驗(yàn)證的硬約束比如“回答必須合法JSON”“必須包含產(chǎn)品鏈接”“不允許出現(xiàn)政治敏感詞”“耗時(shí)必須小于3秒”第二通道是語(yǔ)義級(jí)軟約束用規(guī)則打分加上人工抽檢比如“回答是否切題”“是否有事實(shí)性錯(cuò)誤”。把“唯一正確”換成“滿足約束且語(yǔ)義合理”測(cè)試就能繼續(xù)往下走。2.2 數(shù)據(jù)漂移讓測(cè)試環(huán)境失去代表性第二個(gè)失靈點(diǎn)更隱蔽你的測(cè)試集在實(shí)驗(yàn)室里跑得很漂亮但上了生產(chǎn)環(huán)境就拉胯。問(wèn)題通常不在模型而在數(shù)據(jù)。生產(chǎn)環(huán)境的數(shù)據(jù)分布和訓(xùn)練/測(cè)試時(shí)的分布出現(xiàn)了偏差業(yè)界叫“數(shù)據(jù)漂移”。舉個(gè)我踩過(guò)的例子。某個(gè)文本分類模型測(cè)試集里“訂單咨詢”類目占比30%上線后真實(shí)用戶狂發(fā)“售后投訴”模型把大量投訴誤判成咨詢自動(dòng)化回復(fù)答非所問(wèn)。團(tuán)隊(duì)以為模型壞了查了半天發(fā)現(xiàn)是數(shù)據(jù)分布變了。對(duì)應(yīng)的測(cè)試動(dòng)作不是等上線后補(bǔ)救而是提前建立漂移監(jiān)控。我常用的指標(biāo)是PSI群體穩(wěn)定性指數(shù)和KS檢驗(yàn)工具上直接用Evidently AI這類開(kāi)源庫(kù)。做法是先用上線前一個(gè)月的業(yè)務(wù)數(shù)據(jù)凍結(jié)基線分布然后在測(cè)試環(huán)境的每個(gè)版本回歸里自動(dòng)對(duì)比當(dāng)前樣本分布和基線分布的差異一旦PSI超過(guò)閾值就中止測(cè)試先定位數(shù)據(jù)問(wèn)題。2.3 不可解釋性切斷了bug定位的鏈條傳統(tǒng)定位bug靠的是堆棧、日志和代碼路徑報(bào)錯(cuò)信息指到哪個(gè)函數(shù)哪個(gè)函數(shù)就是嫌疑犯。AI模型是個(gè)黑盒你拿到一個(gè)失敗樣本很難說(shuō)清楚到底是訓(xùn)練數(shù)據(jù)的問(wèn)題、模型權(quán)重的問(wèn)題、特征工程的問(wèn)題還是提示詞的問(wèn)題。我自己的排查思路是“三層快照”輸入快照用戶到底傳了什么、中間特征快照模型前處理之后的數(shù)據(jù)長(zhǎng)什么樣、輸出快照模型返回的原始內(nèi)容。只要把三層數(shù)據(jù)同時(shí)記錄下來(lái)排查范圍就能從“全模型”縮小到“某一層”。這里有個(gè)生活化的類比以前排查故障是檢查汽車哪根油管漏油打開(kāi)引擎蓋一目了然現(xiàn)在AI系統(tǒng)像一輛整體封裝的黑匣子車你只能從現(xiàn)象反推路面、天氣、油品和駕駛習(xí)慣。建立三層快照日志就是在黑匣子里裝上傳感器。2.4 測(cè)試集本身可能成為被攻擊的靶子這件事很多人沒(méi)想到AI系統(tǒng)的測(cè)試集本身就是攻擊面。競(jìng)標(biāo)場(chǎng)景下尤其危險(xiǎn)。三個(gè)真實(shí)風(fēng)險(xiǎn)一是測(cè)試集樣本可能與訓(xùn)練數(shù)據(jù)重疊導(dǎo)致成績(jī)虛高這叫“數(shù)據(jù)污染”二是模型可能過(guò)擬合公開(kāi)benchmark換一組私有樣本就露餡三是在LLM應(yīng)用里測(cè)試用例中的提示詞可能被模型以某種方式反向利用輸出帶偏見(jiàn)的答案。我處理這類問(wèn)題的做法是“測(cè)試集三隔離”隔離存儲(chǔ)測(cè)試集單獨(dú)放在權(quán)限受限的對(duì)象存儲(chǔ)里、隔離版本每次評(píng)測(cè)鎖定數(shù)據(jù)版本號(hào)、隔離生成不用公開(kāi)數(shù)據(jù)集做最終驗(yàn)收至少準(zhǔn)備30%的動(dòng)態(tài)生成樣本比如用規(guī)則工具對(duì)原始樣本加噪聲、換措辭、改實(shí)體。記住一句話在競(jìng)標(biāo)里你的測(cè)試集不是工具而是你最重要的資產(chǎn)。資產(chǎn)要上鎖。3. 機(jī)遇AI攪動(dòng)出的新崗位與能力溢價(jià)講完風(fēng)暴講機(jī)遇。很多人擔(dān)心AI測(cè)試難恰恰是因?yàn)殡y的背后是門(mén)檻門(mén)檻背后是溢價(jià)。一個(gè)能搞定上面四個(gè)失靈點(diǎn)的測(cè)試工程師現(xiàn)在的市場(chǎng)價(jià)值一點(diǎn)都不低。3.1 測(cè)試工程師的三條升級(jí)路徑我觀察下來(lái)身邊的測(cè)試同行正在分化成三條路徑你可以看看自己適合哪一條。路徑一是AI測(cè)試開(kāi)發(fā)工程師。這條路的核心是搭評(píng)測(cè)平臺(tái)、寫(xiě)測(cè)試工具、做自動(dòng)化流水線。傳統(tǒng)自動(dòng)化測(cè)試熟手轉(zhuǎn)這條路最順因?yàn)樗季S還是“工程化解決問(wèn)題”只不過(guò)被測(cè)對(duì)象從頁(yè)面和接口變成了模型和Agent。路徑二是模型質(zhì)量保障QA專家。這條路更像“數(shù)據(jù)算法”方向的測(cè)試核心工作是設(shè)計(jì)評(píng)測(cè)集、定義指標(biāo)、跟蹤模型版本、分析bad case、監(jiān)控?cái)?shù)據(jù)漂移。需要你對(duì)機(jī)器學(xué)習(xí)基礎(chǔ)有一定了解但不要求你手寫(xiě)模型。路徑三是測(cè)試算法工程師。這是門(mén)檻最高的方向要能寫(xiě)對(duì)抗樣本生成、能設(shè)計(jì)公平性評(píng)估實(shí)驗(yàn)、能理解模型內(nèi)部表示。這類人的稀缺度極高基本是行業(yè)搶手貨。三條路徑?jīng)]有優(yōu)劣只看你的興趣點(diǎn)在哪。但無(wú)論選哪條有三件事現(xiàn)在就可以開(kāi)始熟悉Python的數(shù)據(jù)處理庫(kù)pandas、numpy學(xué)會(huì)調(diào)用大模型API做評(píng)測(cè)采樣嘗試用開(kāi)源評(píng)測(cè)框架跑一個(gè)LLM評(píng)測(cè)任務(wù)。3.2 你會(huì)用到的工具矩陣與現(xiàn)實(shí)選型工具不在于多在于組合。我列一個(gè)我自己在AI測(cè)試?yán)飳?shí)際用到、覺(jué)得靠譜的工具矩陣。測(cè)試目標(biāo)推薦工具上手成本核心能力接口與E2E測(cè)試Pytest / Robot Framework低用例編寫(xiě)、斷言、報(bào)告數(shù)據(jù)質(zhì)量檢查Great Expectations中數(shù)據(jù)分布斷言、質(zhì)量報(bào)告數(shù)據(jù)漂移監(jiān)控Evidently AI中PSI/KS檢驗(yàn)、漂移可視化LLM輸出評(píng)測(cè)promptfoo / OpenAI Evals中批量評(píng)測(cè)、多模型對(duì)比AI應(yīng)用鏈路追蹤LangSmith / Langfuse中trace、輸入輸出快照模型版本管理MLflow中實(shí)驗(yàn)跟蹤、模型注冊(cè)性能監(jiān)控Prometheus Grafana中高延遲、GPU、錯(cuò)誤率指標(biāo)我的選型邏輯是一條線先用Great Expectations管數(shù)據(jù)再用promptfoo類工具管模型輸出最后用LangSmith這類工具管應(yīng)用鏈路。別一上來(lái)就搭一個(gè)大而全的測(cè)試平臺(tái)先用開(kāi)源工具串起來(lái)跑通比什么都強(qiáng)。我自己犯過(guò)“過(guò)度設(shè)計(jì)”的毛病花了三周做平臺(tái)最后發(fā)現(xiàn)需求都變了。3.3 簡(jiǎn)歷與面試AI測(cè)試崗位到底看重什么最近幫不少朋友看過(guò)簡(jiǎn)歷也模擬過(guò)AI測(cè)試崗位的面試。現(xiàn)在面試官基本不會(huì)再只問(wèn)“你怎么設(shè)計(jì)登錄功能的測(cè)試用例”而是直接拋場(chǎng)景題。必問(wèn)的三個(gè)方向第一你怎么驗(yàn)證一個(gè)RAG檢索增強(qiáng)生成系統(tǒng)回答是否可靠第二你怎么測(cè)試一個(gè)AI Agent的工具調(diào)用流程第三你如何建立數(shù)據(jù)漂移監(jiān)控并設(shè)定報(bào)警閾值。這三題考察的不是你會(huì)不會(huì)用某個(gè)工具而是你有沒(méi)有形成AI質(zhì)量保障的系統(tǒng)性思維。簡(jiǎn)歷上的寫(xiě)法我也建議換換說(shuō)法。把“熟練使用Postman/Pytest做接口自動(dòng)化”這種描述升級(jí)為“設(shè)計(jì)并落地了LLM應(yīng)用評(píng)測(cè)集體系覆蓋答案正確性、格式合規(guī)性和響應(yīng)延遲三類指標(biāo)”。如果你現(xiàn)在還沒(méi)有相關(guān)項(xiàng)目經(jīng)驗(yàn)最直接的辦法是拿一個(gè)開(kāi)源AI項(xiàng)目搭建一套評(píng)測(cè)基線并寫(xiě)一份測(cè)試報(bào)告這比寫(xiě)十遍“熟練掌握軟件測(cè)試工具”都有說(shuō)服力。4. 實(shí)操核心從0到1搭建AI測(cè)試與質(zhì)量保障方案理論說(shuō)得再多不如直接上手。下面這條路是我自己在項(xiàng)目里驗(yàn)證過(guò)的從0到1搭建一套AI系統(tǒng)測(cè)試方案按順序做不用跳步。4.1 先做測(cè)試策略分析別急著寫(xiě)腳本很多測(cè)試工程師拿到AI項(xiàng)目第一反應(yīng)是“我要用什么框架”這順序反了。第一步應(yīng)該是測(cè)試策略分析確定四件事驗(yàn)收標(biāo)準(zhǔn)需求里哪些話是可驗(yàn)證的、風(fēng)險(xiǎn)清單模型不可解釋、數(shù)據(jù)分布不穩(wěn)、提示詞注入、性能瓶頸、測(cè)試分層數(shù)據(jù)層-模型層-應(yīng)用層-系統(tǒng)層、資源與時(shí)間預(yù)算。我見(jiàn)過(guò)一個(gè)“測(cè)試策略文檔比測(cè)試結(jié)果還重要”的情況某個(gè)競(jìng)標(biāo)項(xiàng)目測(cè)試結(jié)論本身不錯(cuò)但因?yàn)椴呗晕臋n里沒(méi)有寫(xiě)“已識(shí)別風(fēng)險(xiǎn)”和“殘余風(fēng)險(xiǎn)”被評(píng)標(biāo)方質(zhì)疑“你們是不是沒(méi)意識(shí)到這些問(wèn)題”最后丟了分。所以策略文檔里一定要有一個(gè)風(fēng)險(xiǎn)登記表把每個(gè)風(fēng)險(xiǎn)的等級(jí)、概率、影響和應(yīng)對(duì)措施寫(xiě)清楚這反而能增加信任度。4.2 數(shù)據(jù)質(zhì)量測(cè)試第一道防線AI系統(tǒng)的質(zhì)量上限在數(shù)據(jù)。數(shù)據(jù)質(zhì)量測(cè)試通常分四性完整性字段是否有缺失、一致性同業(yè)務(wù)含義是否沖突、時(shí)效性數(shù)據(jù)是否過(guò)期、無(wú)偏性類別分布是否失衡。實(shí)操層面我建議用Great Expectations做自動(dòng)化數(shù)據(jù)斷言下面是一個(gè)最小可運(yùn)行的示例。import great_expectations as gx context gx.get_context() validator context.sources.pandas_default.read_csv( train_samples.csv ).expect_column_values_to_not_be_null(label) # 檢查標(biāo)簽分布是否失衡 validator.expect_column_distinct_values_to_be_in_set( label, [投訴, 咨詢, 建議] ) # 生成數(shù)據(jù)質(zhì)量報(bào)告 results validator.validate() print(results.to_json())除了自動(dòng)斷言數(shù)據(jù)質(zhì)量測(cè)試?yán)镒钊菀妆缓雎缘氖菢?biāo)簽質(zhì)量抽檢。取訓(xùn)練集里200條樣本由人工重新標(biāo)注一遍計(jì)算原始標(biāo)簽與復(fù)核標(biāo)簽的一致率。我們當(dāng)時(shí)做了一個(gè)文本分類項(xiàng)目模型F1一直卡在0.87上不去找了一個(gè)下午才發(fā)現(xiàn)訓(xùn)練集標(biāo)簽一致率只有0.79大量錯(cuò)誤標(biāo)注直接污染了模型。先把標(biāo)簽一致率提到0.95以上F1才爬到0.92。4.3 模型行為測(cè)試功能、魯棒性、公平性三輪驅(qū)動(dòng)數(shù)據(jù)過(guò)關(guān)之后進(jìn)入模型行為測(cè)試。我習(xí)慣把它拆成三輪。第一輪是功能測(cè)試按任務(wù)類型選指標(biāo)。分類任務(wù)看準(zhǔn)確率、精確率、召回率、F1生成任務(wù)看BLEU、ROUGE或語(yǔ)義相似度排序任務(wù)看NDCG、MRR。這里要特別注意生成類任務(wù)只看文本重疊度指標(biāo)容易失真我建議增加一個(gè)“語(yǔ)義一致性”維度計(jì)算生成結(jié)果與參考答案的向量余弦相似度。第二輪是魯棒性測(cè)試就是拿“壞數(shù)據(jù)”去轟模型。做法包括但不限于對(duì)文本樣本做錯(cuò)別字?jǐn)_動(dòng)、對(duì)圖片樣本做亮度/遮擋/高斯噪聲擾動(dòng)、對(duì)語(yǔ)音樣本做背景噪音疊加。下面是用簡(jiǎn)單規(guī)則做文本擾動(dòng)的示例。import random def text_noise(text: str, perturb_ratio: float 0.1) - str: chars list(text) for i in range(len(chars)): if random.random() perturb_ratio: # 模擬常見(jiàn)輸入錯(cuò)誤替換同音字、插入錯(cuò)誤拼音或刪除字符 chars[i] 啊 # 用占位符模擬噪聲 return .join(chars) samples [ 請(qǐng)幫我查一下明天的訂單狀態(tài), 我要預(yù)約后天的維修服務(wù), ] for raw in samples: for seed in [42, 1024, 2048]: random.seed(seed) corrupted text_noise(raw, perturb_ratio0.2) # 記錄模型在擾動(dòng)樣本上的輸出用于計(jì)算魯棒性得分 print(corrupted)第三輪是公平性測(cè)試核心是分組檢查模型表現(xiàn)是否存在系統(tǒng)性偏差。比如按性別、年齡段、地域等維度切分樣本對(duì)比各組的準(zhǔn)確率、通過(guò)率或拒識(shí)率。我常用一個(gè)簡(jiǎn)單指標(biāo)某分組的準(zhǔn)確率除以全體準(zhǔn)確率比值低于0.9就視為風(fēng)險(xiǎn)點(diǎn)需要重點(diǎn)分析。這不是“政治正確”而是“系統(tǒng)可靠性”的一部分——一個(gè)對(duì)某類用戶系統(tǒng)性失效的模型本身就是缺陷。評(píng)測(cè)報(bào)告我建議包含五個(gè)部分測(cè)試環(huán)境說(shuō)明、數(shù)據(jù)集版本與來(lái)源、分維度結(jié)果表、bad case樣例列表、結(jié)論與殘余風(fēng)險(xiǎn)。這既方便內(nèi)部復(fù)盤(pán)也方便競(jìng)標(biāo)時(shí)直接作為證據(jù)提交。4.4 系統(tǒng)級(jí)聯(lián)調(diào)測(cè)試AI Agent與多模型協(xié)作的E2E驗(yàn)證單模型測(cè)完還遠(yuǎn)沒(méi)結(jié)束。現(xiàn)在的AI項(xiàng)目大量采用多個(gè)模型協(xié)作一個(gè)主模型做意圖識(shí)別一個(gè)對(duì)話模型生成回復(fù)還套一個(gè)工具調(diào)用模型去查詢訂單接口這就是典型的AI Agent場(chǎng)景。系統(tǒng)級(jí)聯(lián)調(diào)測(cè)試要重點(diǎn)盯四件事?tīng)顟B(tài)管理對(duì)話上下文是否串了、工具調(diào)用正確性模型是否傳錯(cuò)參數(shù)、記憶一致性多輪會(huì)話后是否還記得初始信息、失敗挽回外部API超時(shí)后模型能不能兜底。這里特別想強(qiáng)調(diào)一點(diǎn)AI Agent的端到端測(cè)試不能只斷言最終結(jié)果一定要驗(yàn)證中間的每一步。比如用戶問(wèn)“幫我查一下昨天買的耳機(jī)訂單到哪了”Agent需要先調(diào)用意圖識(shí)別再抽出實(shí)體“昨天”“耳機(jī)”再調(diào)用物流查詢工具。如果你只檢查最終回答很可能工具調(diào)用鏈已經(jīng)錯(cuò)亂但大模型靠著“腦補(bǔ)”給出了一個(gè)貌似合理的回答這是最坑的假陰性。下面是一個(gè)用pytest驗(yàn)證Agent工具調(diào)用過(guò)程的示例思路。import pytest from agent import run_conversation pytest.fixture def mock_order_api(mocker): mock mocker.patch(agent.order_query) mock.return_value {status: 運(yùn)輸中, eta: 明日到達(dá)} return mock def test_tool_call_chain_is_correct(mock_order_api): result run_conversation(幫我查一下昨天買的耳機(jī)訂單到哪了) # 校驗(yàn)中間調(diào)用鏈Agent必須真的調(diào)用了訂單接口而不是憑記憶硬答 mock_order_api.assert_called_once() assert 昨日 in mock_order_api.call_args.kwargs.get(time_hint, ) # 校驗(yàn)最終回答包含關(guān)鍵信息 assert 運(yùn)輸中 in result你可以看到關(guān)鍵動(dòng)作是把斷言從“只看回答”擴(kuò)展到“校驗(yàn)工具調(diào)用參數(shù)”和“調(diào)用次數(shù)”。因?yàn)樵趯?shí)際系統(tǒng)里模型可能跳過(guò)程序、直接編造物流狀態(tài)看起來(lái)回答很流暢實(shí)際上完全跑偏。5. 實(shí)戰(zhàn)中的翻車現(xiàn)場(chǎng)與排查技巧這部分是掏家底的。AI測(cè)試和傳統(tǒng)測(cè)試最大的不同是錯(cuò)誤的模式變得非?！疤摗蹦愕脤W(xué)會(huì)跟概率性故障共處。下面是我自己踩過(guò)、也幫別人排查過(guò)的典型問(wèn)題。5.1 典型問(wèn)題快照AI測(cè)試?yán)镒畛２鹊?個(gè)坑#典型坑現(xiàn)象根因解法1對(duì)LLM輸出做完全匹配斷言測(cè)試天天紅但業(yè)務(wù)方說(shuō)功能正常生成式輸出天然有多樣性改用語(yǔ)義相似度或約束校驗(yàn)加人工抽檢2只測(cè)功能不測(cè)數(shù)據(jù)漂移上線兩周轉(zhuǎn)差投訴率上升生產(chǎn)數(shù)據(jù)分布偏移加Evidently漂移監(jiān)控設(shè)PSI閾值0.23評(píng)測(cè)集太小或混入訓(xùn)練數(shù)據(jù)測(cè)試結(jié)果虛高私有評(píng)測(cè)打回原形數(shù)據(jù)泄露或過(guò)擬合公開(kāi)集做測(cè)試集三隔離準(zhǔn)備動(dòng)態(tài)樣本4只看最終結(jié)果不看中間Agent軌跡偶發(fā)性錯(cuò)誤定位困難中間工具調(diào)用錯(cuò)亂被大模型掩蓋打詳細(xì)trace鏈路ID斷言每一步調(diào)用5忽略偶發(fā)概率性失敗復(fù)現(xiàn)不出來(lái)就標(biāo)記為“環(huán)境問(wèn)題”解碼參數(shù)隨機(jī)性導(dǎo)致輸出抖動(dòng)固定seed和temperature重復(fù)N次取分布統(tǒng)計(jì)這五個(gè)坑的共同特點(diǎn)是沒(méi)有從“確定性的軟件測(cè)試”切換到“概率性的系統(tǒng)驗(yàn)證”思維。AI系統(tǒng)測(cè)試更接近“統(tǒng)計(jì)過(guò)程控制”需要你接受一定比例的隨機(jī)失敗然后用重復(fù)實(shí)驗(yàn)去定位“是模型本身有問(wèn)題還是這次采樣運(yùn)氣不好”。5.2 排查方法論從一個(gè)“偶現(xiàn)bug”講起舉個(gè)真實(shí)的排查案例。一個(gè)基于LLM的客服系統(tǒng)偶發(fā)出現(xiàn)“回答格式變成純文本、丟了結(jié)構(gòu)化字段”導(dǎo)致下游解析失敗。因?yàn)榘l(fā)生頻率只有3%一開(kāi)始被當(dāng)成“網(wǎng)絡(luò)抖動(dòng)”或“環(huán)境問(wèn)題”但客戶不買單。我的排查步驟是這樣。第一步給所有請(qǐng)求打上全局traceID記錄輸入原文、帶temperature和seed參數(shù)的解碼配置、模型原始輸出字符串。第二步把偶發(fā)樣本和正常樣本做差異對(duì)比發(fā)現(xiàn)偶發(fā)樣本的輸入有個(gè)共同特征用戶消息都很長(zhǎng)超過(guò)800字。第三步單獨(dú)構(gòu)造了100條長(zhǎng)文本樣本去壓測(cè)發(fā)現(xiàn)輸出格式錯(cuò)誤的概率飆到25%基本鎖定是長(zhǎng)上下文導(dǎo)致的解碼不穩(wěn)定。第四步給模型添加了結(jié)構(gòu)化輸出約束把輸出格式從“自由文本”改成強(qiáng)制JSON Schema并對(duì)長(zhǎng)輸入做了截?cái)嗖呗?。回歸測(cè)試后格式錯(cuò)誤率從25%降到了0.8%。這類問(wèn)題在傳統(tǒng)測(cè)試?yán)锖茈y遇到因?yàn)閭鹘y(tǒng)系統(tǒng)對(duì)800字輸入和100字輸入的邏輯是一致的而AI模型對(duì)輸入長(zhǎng)度、措辭風(fēng)格極度敏感。解決的核心在于“把一次性的偶現(xiàn)變成可控的分布統(tǒng)計(jì)”。每次遇到偶現(xiàn)bug不要急著改代碼先按“收集快照、構(gòu)造復(fù)現(xiàn)集、加大采樣量、驗(yàn)證修復(fù)、固化回歸”五步走。5.3 獨(dú)家避坑技巧清單最后幾條經(jīng)驗(yàn)是我拿時(shí)間換來(lái)的教訓(xùn)。第一不要迷信大模型的“萬(wàn)能修復(fù)”。有人覺(jué)得把一個(gè)bad case喂給模型調(diào)一輪提示詞就能解決結(jié)果解決了A類樣本弄壞了B類樣本。正確做法是每一次提示詞改動(dòng)都跑一遍完整回歸集記錄“修復(fù)了一個(gè)bad case影響了幾個(gè)good case”。第二務(wù)必備份和保存每一個(gè)失敗樣本建立Bad Case庫(kù)。我見(jiàn)過(guò)團(tuán)隊(duì)把失敗樣本隨手刪掉后來(lái)要分析模型版本回退原因一點(diǎn)證據(jù)都沒(méi)有。Bad Case庫(kù)要包含輸入、模型輸出、期望輸出、人工標(biāo)注、歸屬模塊、發(fā)現(xiàn)日期、關(guān)聯(lián)版本這就是AI測(cè)試的“根因分析資產(chǎn)”。第三評(píng)測(cè)集一定要“加鹽”。所謂加鹽就是動(dòng)態(tài)生成擾動(dòng)樣本防止模型和測(cè)試團(tuán)隊(duì)一起“背答案”。我每次發(fā)布評(píng)測(cè)集時(shí)都會(huì)隨機(jī)替換一部分樣本的表達(dá)方式比如把“我要退款”改成“我買的東西能退一下嗎”。這樣才能測(cè)出模型的真實(shí)泛化能力。第四競(jìng)標(biāo)測(cè)試報(bào)告里要大大方方寫(xiě)“未覆蓋范圍”。很多團(tuán)隊(duì)怕暴露短板把所有風(fēng)險(xiǎn)藏起來(lái)結(jié)果評(píng)標(biāo)方提問(wèn)時(shí)一問(wèn)一個(gè)準(zhǔn)。主動(dòng)寫(xiě)出“本評(píng)測(cè)未覆蓋極端并發(fā)場(chǎng)景、未覆蓋音頻對(duì)抗樣本”同時(shí)給出應(yīng)對(duì)計(jì)劃反而顯得你專業(yè)可信。測(cè)試的核心不是證明系統(tǒng)沒(méi)有問(wèn)題而是精確描述問(wèn)題在哪里、影響有多大、剩下多少風(fēng)險(xiǎn)。6. 寫(xiě)在最后測(cè)試工程師會(huì)在AI時(shí)代被淘汰嗎經(jīng)常有同行問(wèn)我AI都能自己寫(xiě)測(cè)試了測(cè)試工程師還有前途嗎我的回答是AI能寫(xiě)的是測(cè)試代碼替代不了的是測(cè)試判斷。什么叫測(cè)試判斷就是你面對(duì)一個(gè)概率輸出的模型能判斷“這個(gè)失敗是關(guān)鍵缺陷還是邊緣噪聲”面對(duì)一份評(píng)測(cè)報(bào)告能判斷“這個(gè)準(zhǔn)確率在業(yè)務(wù)上是及格還是不及格”面對(duì)一個(gè)跨越數(shù)據(jù)、模型、應(yīng)用三層的復(fù)雜故障能判斷“該從哪里切進(jìn)去查”。這些判斷力目前還沒(méi)有哪個(gè)AI能自動(dòng)生成。我自己在實(shí)際項(xiàng)目里最大的體會(huì)是AI時(shí)代的測(cè)試門(mén)檻壘高了但是天花板也被頂開(kāi)了。以前高喊“測(cè)試快被自動(dòng)化干掉”的時(shí)代做的是重復(fù)執(zhí)行現(xiàn)在AI系統(tǒng)把執(zhí)行成本打下來(lái)之后真正值錢的是測(cè)試設(shè)計(jì)、測(cè)試分析、質(zhì)量度量體系搭建。這些東西恰恰是最難被AI替代的部分。如果你決定往這個(gè)方向走我給你一條最低成本的啟動(dòng)路徑先選一個(gè)開(kāi)源LLM項(xiàng)目把它的測(cè)試現(xiàn)狀摸清楚用Pytest寫(xiě)20個(gè)API級(jí)測(cè)試再用promptfoo搭一個(gè)20條的評(píng)測(cè)集跑出一份質(zhì)量報(bào)告掛到簡(jiǎn)歷上。這個(gè)過(guò)程不需要等項(xiàng)目分配任務(wù)不需要公司批準(zhǔn)只需要一臺(tái)能聯(lián)網(wǎng)的電腦加一個(gè)周末。再分享一個(gè)小技巧AI測(cè)試不要一開(kāi)始就追求“全自動(dòng)”而是先追求“可觀測(cè)”。哪怕你只做到“每個(gè)模型請(qǐng)求都有trace、每個(gè)失敗樣本都落庫(kù)、每個(gè)版本都有基線對(duì)比”就已經(jīng)比80%的團(tuán)隊(duì)更扎實(shí)了。風(fēng)暴不會(huì)停但站在風(fēng)暴中心的人手里的傘是可以越做越結(jié)實(shí)的。