AI 輔助錯誤分析

資料來源#

摘要#

錯誤分析是所有其他評估活動的上游步驟：閱讀追蹤紀錄，找出究竟有哪些失敗模式，之後才開始衡量。Shreya Shankar（電腦科學教授；與 Hamel Husain 共同創辦 Maven AI Evals 課程）在 2026 年 7 月的一場演講中主張，這是 AI 無法代你完成的步驟，並提出一套仍能在其中運用 AI 的工作流程。

本 wiki 其他評估頁面，都以已存在的分類為基礎——評審器依照某人撰寫的準則評分，LLM-Judge Validation探討這些分數是否可靠，Production-Sourced Evaluation則追問案例從何而來。本頁是這份資料集中首篇探討準則從何而來的文章。

practitioner-opinion：一場含現場示範、沒有測量結果的研討會演講。文中有一項實證主張（下方的工具比較結果）仍屬初步且未發表，並已標明。

認識論論證#

這裡的關鍵主張不是自動化評估工具做得不好，而是這項工作無法完全規格化：

你的產品何謂好，存在你的心中，不在追蹤紀錄裡。

由此可得兩個推論，第二個更為犀利：

未外顯的事物無從發現。 代理程式讀取追蹤紀錄，只能找出在追蹤紀錄或提示詞中可辨識的失敗。專屬於品味的失敗——那些讓你的產品成為你自己的特質——依定義並不存在於其中。
競爭差異化論點。「如果某個工具能替你完整打造並修復產品，它也能為其他所有人、為你的每個競爭對手做到同樣的事，這樣一來，就沒有任何東西能讓你的產品脫穎而出。」因此，全面自動化錯誤分析不只是困難，對買方而言也是自我挫敗，不論哪家供應商先做到。

接下來的重新定位是：評估用 AI 工具應致力於協助開發者更快表達並應用心中已有的判斷，而非代為提供判斷。

生命週期，以及 AI 能力所在的位置#

課程提出的三步循環，需要反覆執行，而非只跑一次：

分析——閱讀追蹤紀錄，找出失敗模式。
衡量——估計每種模式的普遍程度，決定先修復什麼。
改進——修改提示詞、模型或微調版本。

**AI 的能力沿著這份清單單調上升，在步驟 1 最差。**衡量與爬山式最佳化（提示詞最佳化）很適合自動化；發現則不然。Shankar 認為步驟 1 最困難的理由，應與前述認識論論證分開看：錯誤沒有真值定義。監督式 ML 可以把失敗定義為預測 ≠ 標籤；但「這算不算 AI 垃圾內容？」有種「我一看就知道」的特質，無法如此定義。貫穿全篇的例子是一款 AI 寫作助理，並以一項引述自 Graphite 的統計數字作為動機：網路上超過一半的文章，如今聽起來明顯像是 AI 生成。

衡量之所以重要，是因為有一項柏拉圖觀察：資料中約 80% 的問題來自約 20% 的失敗模式，因此依普遍程度排序，才能讓待修清單變得可處理。

錯誤一——「這是我的追蹤紀錄，去評估吧」#

這種反模式的典型做法是打開程式碼代理程式，指向一個放有追蹤紀錄的 S3 bucket，然後叫它評估應用程式。它會產出看似合理的結果，但有三處問題：

漏掉所有專屬品味的失敗，如前述認識論論證所說。
**憑空捏造優先級。**示範截圖的醒目結論——「語氣極度重複，是最大的問題」——既含糊，也沒有和其他項目比較排名。代理程式沒有根據判定哪種模式最大，卻還是這麼說了。
無法重用。每次執行都會重新讀取資料，從頭推導失敗模式；執行與新的追蹤紀錄批次之間都沒有共享資訊。你真正想要的是保留生命週期中的中間產物——失敗模式及其定義——放在記憶體或程式碼裡，讓後續流程從這些成果開始。

第三點與LLM-as-Compiler Knowledge Base的「編譯一次並持續更新」前提相同，只是從評估角度切入：昂貴的產物是逐步累積的分類，每次執行都重新推導就是缺陷。

工作流程：由代理程式打造審查介面#

Shankar 提出的替代方案，是一項可重複使用的技能（以開放原始碼釋出，目前仍在變動中），保留人類的工作流程，只在特定環節加入 AI。共五個步驟：

理解資料——載入一份樣本，辨識追蹤紀錄中重複出現的欄位、結構與內容。
設計視覺編碼——為追蹤紀錄內會變化的維度分配視覺通道（最簡單的例子：依訊息角色上色）。這是標準的設計實務，應用於讓人快速讀懂追蹤紀錄。
打造審查應用程式，包含三種檢視畫面——逐筆追蹤紀錄檢視器、顯示所有待標註追蹤紀錄的地圖檢視，以及呈現目前找到之失敗模式樹狀圖的進度檢視。
分群並抽樣——挑選具代表性的追蹤紀錄，讓人類不必逐一審查。刻意不指定做法：技能只要求找出能解釋追蹤紀錄差異的特徵，再進行分群，方法則交給代理程式決定。早期版本曾硬編碼 embeddings 加上 K-means；Shankar 把它移除，因為 embeddings 不一定是合適的表示法，有時分析對象根本不是追蹤紀錄（在此例中是最終文章）。
人在迴路中的審查，代理程式全程監控、建立分類，並推動廣度（涵蓋所有模式）與深度（找出每種模式的多個實例）。

現場示範中：33 篇 AI 生成的部落格文章 → 抽樣審查 21 篇 → 介面在 4 分 42 秒內建好。過程中坦率提到兩項但書：代理程式生成的 UI 仍顯粗糙（「UI 還有很長一段路要走」），抽樣也是猜測——「不能假設分群或樣本選擇完美無缺。」

錯誤二——每筆追蹤紀錄只審查一次#

多數人只標註一次追蹤紀錄就繼續往下。Shankar 說，根據她自己的研究與實務經驗，重新閱讀已分析過的追蹤紀錄，會浮現新的失敗模式，因為失敗模式來自腦中對多筆追蹤紀錄的組合印象，而不是任何一筆單獨的紀錄。

示範的例子具體而令人信服。她審查自己的文章到第三篇時，注意到 matters 一詞反覆出現——包括她已完成標註的兩篇文章。這種模式初讀任何單筆追蹤紀錄時都看不出來，之後卻變得顯而易見。

結構上的修正，是在資料上跑外層迴圈，在單筆資料點的假設上跑內層迴圈，再加上演講中最值得借鏡的自動化做法：

請代理程式把你提供的每個新標註，也套用到先前已標註的追蹤紀錄，以及尚未標註的紀錄。

因此，當人類在一筆追蹤紀錄上標記「我不喜歡不完整句」時，代理程式會回頭搜尋已審查的追蹤紀錄，找出其他不完整句並提出建議，由人類逐一接受或拒絕。代理程式的建議會出現在進度檢視中的專屬分頁。她坦白說明兩項限制：代理程式不會找得完整無遺——它會找出遭標記的失敗模式實例，但不會找出全部；它在這裡扮演的是加速人類自身審查，而非取而代之。

界線：應用，而非創作#

最重要的設計決策是一項刻意不做的事。Shankar 刻意不請代理程式提出新的失敗模式或擴充分類：

在技能之前的版本裡，我曾請代理程式建議新的失敗模式類型，但我總是發現，有些我認同，有些我不認同，而我不喜歡只是試著驗證代理程式品味的過程。自己說出我的想法，再讓代理程式擴大套用，對我來說容易得多。

人類負責分類；代理程式負責大規模應用。這正是CMU 灰色文獻團隊跨越界線而失敗後找到的分工——LLM 負責機械式、以引文為依據的開放編碼，人類保留詮釋性的主軸編碼，而自動化後半段產生了 15,029 條淺薄且重複的陳述。兩個彼此獨立的研究都抵達同一條界線：一個是質性研究中經測量確認的失敗，另一個是從業者親身感受到的成本；Shankar 說明了界線成立的原因：驗證別人的品味，比表達自己的品味更費力。

錯誤三——所有應用都設相同的準確度門檻#

團隊對推出的每項 AI 功能投入同等程度的評估。門檻應依情境設定：內部 Slack 討論串摘要工具不需要非常準確，面向客戶的工具則需要。

設定門檻的方法是預先與助理一起推演最壞情況——把一批追蹤紀錄、應用程式說明或程式碼庫交給 Claude Code 或 Codex，詢問使用者可能遇到的最糟情況是什麼。以寫作助理為例：竄改引文，或洩露私人資訊（例如記者蒐集的來源素材出現在已發布文章中）。接著從這些情境反推要建構哪些評估與防護措施。這與Risk-Tiered Auto-Approval依後果決定投資層級的模式相同，只是套用在評估工作，而非代理程式可在無人看管下合併哪些差異。

請留意，這是在生命週期中最依賴品味的環節使用 AI——但它並未違反認識論論證，因為代理程式被要求列出供人類判斷的可能情境，而不是決定哪些情境重要。

初步發現：通用代理程式勝過專用評估工具#

Shankar 預告了一項尚未發表、由 Hamel Husain 和 Antariksha Dasgupta 主導的初步基準測試，使用真實資料評估現有的自動化評估工具，並報告兩項結果：

**通用程式碼代理程式——Claude Code、Codex——通常比專用的評估探索平台更能全面找出失敗模式。**她說這個結果令人意外。
沒有任何工具能以良好的精確度找出你所有的失敗模式。

Husain 對第一項結果的解釋較為平實：專用工具「說到底就是某個人的提示詞。或許再加上一點 harness」——而你可以把自己的領域專業知識放進自家代理程式的提示詞中，再根據資料客製化，縮小差距。有提供自動評估產品的具名廠商包括 LangChain、Braintrust 和 Arize；這場演講明確表示不會逐一評估其中任何一家。

兩項結果都應視為初步且來自評估課程作者自身的研究；這些作者的教學材料正是這類工具的替代方案。揭露的利益衝突確實存在，研究也尚未公開。值得一併提及Compute-Controlled Benchmarking提出的持續性警告：兩組測試都沒有報告預算或投入程度，因此「更全面」還不能算是受控比較。

這篇文章不是什麼#

這不是反對自動化衡量的論點——Shankar 明確把 AI 放在衡量與改進步驟中。這也不是說評估供應商的工具什麼都找不到；它們能找到「一些錯誤」。主張的範圍明確而有限：自動化管線到了發現何謂失敗這一步，就無法再帶來效益；原因在於認識論，而非更好的模型能彌補的工具缺口。

延伸閱讀#

Agent Quality Flywheel——從供應商角度看同一個生命週期，也是這份資料集中最鮮明的對照。Google 的第 4 階段（「Analyze Failures」）讀取評分規準的判定來解釋案例為何失敗——它依賴第 1 至 3 階段假定已存在的分類。Shankar 的錯誤分析在那之前；飛輪以白話描述的介面（「我擔心旅遊禮賓助理能否遵守對話中途提出的變更」），正是她所說必須由人類提供的外顯判斷
Evals as Product Spec——探討規格內容從何而來：Cat Wu 所說「十個優秀的評估勝過一百個平庸的評估」，前提是你知道哪十個才對；本頁描述的正是產出這些評估的探索程序
LLM-Assisted Grey-Literature Theory Building——質性研究中獨立發現的相同自動化界線：機械式編碼可以委派，詮釋性分類建構則不行
LLM-as-a-Judge——下游使用者：評審器需要準則，而錯誤分析正是撰寫準則的步驟。Shankar 的柏拉圖觀察能告訴你哪些準則值得成為穩定指標
Production-Sourced Evaluation——探討相同追蹤紀錄的相關問題：該頁詢問如何把正式環境流量抽樣為評估集，本頁則詢問取得樣本後該如何閱讀。分群與抽樣步驟是兩者的交會處；Shankar 提醒樣本選擇只是猜測，這一點同樣適用於兩者
Failures That Look Like Success——最需要透過閱讀來發現的失敗類別：輸出中沒有任何訊號，因此事先撰寫的指標都無法捕捉
LLM-as-Compiler Knowledge Base——保存生命週期的中間產物，而非每次執行時重新推導，是本 wiki 自身的運作前提，從評估角度切入
Context Advantage, Not Taste——值得持續討論的直接分歧。Andrew Ng 將人類剩餘的貢獻重新詮釋為可以彌補的資訊不對稱；Shankar 的差異化論點則認為，這道差距在結構上無法彌補，因為替你彌補的工具也會替競爭對手彌補。Ng 的觀點將人類角色視為工程落差；Shankar 則視為護城河
Research Taste as the Human Bottleneck——同一瓶頸出現在產品規模，而非研究規模，並以特別具體的方式說明表達品味實際上要付出什麼代價
Risk-Tiered Auto-Approval——錯誤三是把相同的後果分級邏輯用於決定應用程式值得投入多少評估資源
Verification as the New Bottleneck——錯誤分析是驗證中沒有變得更便宜的部分；演講結尾那句話正好說明原因：「評估總會包含某種人為因素」
Compute-Controlled Benchmarking——初步的代理程式對平台比較缺少的控制項
Transluce——這份資料集中專用平台類別的具名案例：Docent 會依據書面評分規準，從記錄中標記代理程式行為，因此它位於本頁指出不可委派的分類撰寫步驟之下游。Husain 所說的「某個人的提示詞，或許再加上一點 harness」公平地描述了它的架構；它是否包含在初步基準測試的平台之中，則未有說明
Pilot-to-Production Gap——**把相同的後果優先推理用在自動化界線，而非評估投資上。**Anthropic × Accenture 的就緒度測試指出，錯誤「率」不是正確的衡量數字：「某系統在有限流量下達到 95% 準確率，聽起來已經可以投入正式環境。但剩下的 5% 很重要」——審查者幾秒內就能發現的格式錯誤，或許適合完全自動化；錯誤的財務計算或漏掉合規旗標，則會讓每增加一單位流量都帶來風險，因此真正要問的是，在完整正式環境流量下，每一類錯誤會造成什麼代價。兩者都反對對所有功能設定統一門檻，也都預先透過推演最壞結果來訂定門檻；不同之處在於結論帶來什麼：前者帶來評估與防護措施，此處則是監督階梯上的分級。vendor-claim，屬規範性主張，沒有實際部署案例

開放問題#

Shankar 的技能會把每項新的人類標註套用到已標註的追蹤紀錄，但明確不提出新的失敗模式。分類的撰寫權界線能長久維持嗎？還是只是因為審查成本太高？也就是說，如果代理程式建議介面夠好用（拒絕成本低、建議有排序），驗證代理程式的品味是否會比表達自己的品味更省力？
據稱，代理程式把遭標記的失敗模式重新套用到已審查追蹤紀錄時，無法做到完整無遺。實際召回率是多少？漏掉的實例會不會使普遍程度估計產生偏差，進而影響衡量步驟排序待修項目的結果？
考量到這項研究出自一門與這些工具競爭的課程作者之手，通用代理程式勝過專用工具的結果，能否通過預算匹配的比較與第三方複現？#oq/wait——Husain 與 Dasgupta 的基準測試研究發表後即可驗證

資料來源#

How to Automate AI Evals (Correctly)——Shreya Shankar 與 Hamel Husain，How to Automate AI Evals (Correctly)，YouTube，2026-07-03，27:19，practitioner-opinion（約 6.0k 字）。這是 12 部 AI 產品工程迷你課程的第 1 部，課程推廣作者的 Maven AI Evals 課程——工具比較部分揭露利益衝突，而比較本身也屬初步、尚未發表。逐字稿取自上傳的人工撰寫字幕軌；匯入時修正其中轉錄錯誤的領域用語（evals、Hamel、skill、improve、Graphite），修正紀錄見 wiki/sources.md。投影片與現場示範畫面均未收錄——審查介面、三種檢視畫面，以及 Claude Code 螢幕截圖都只以口頭描述，因此本頁所有 UI 細節都是演講者說出的內容，而非畫面所示。技能的程式碼儲存庫網址出現在投影片上，演講中從未口述
Deploying AI from pilot to production: A practical blueprint for CIOs and technical leaders——Deploying AI from pilot to production，Anthropic × Accenture，2026-09-11，38 頁，vendor-claim。本文僅在考量 07 中引用其錯誤模式分布就緒度測試。完整分析與證據限制見Pilot-to-Production Gap