Hamel Husain 指「很難 eval」是產品警訊，Karpathy 與 Google PAIR 怎麼看可驗證性

你做了一個內部資料分析 agent。業務問：「Product A 上季的淨營收是多少？」它回答「4.21M 美元」。財務主管只追問一句：「這個數字怎麼來的？」你手邊的評測集沒有這題的標準答案，想確認它對不對，只能請分析師把整個查詢重跑一遍。（這是假設的情境，數字沿用下面 Hamel Husain 文章裡的設計草圖。）

在這種處境，團隊常說「我們的產品很難 eval」。專注 AI 評測的工程師 Hamel Husain 在 2026 年 6 月 29 日回應了這句話。

快速回答 「很難 eval」常是產品沒有替使用者設計驗證步驟的徵兆。Hamel Husain 在 2026-06-29 寫道，你自己難以驗證的產出，使用者通常也難以驗證。Andrej Karpathy 主張把人類驗證 AI 產出的迴圈縮短，Google 的 People + AI Guidebook 則把目標定為讓使用者校準信任，過度信任也算設計失敗。本篇引用的三份材料都沒有談評測集怎麼建；使用者得自己判斷輸出對錯的產品，最適用這個檢查。

三方各用什麼手法，讓產出可以被驗證？

Hamel 用出處、逐步展開與拆小單元，Karpathy 用應用專屬介面加快審核，Google PAIR 用資料來源、信心顯示與部分解釋校準信任。

三個說法的出處各不相同。Hamel Husain 在個人部落格 hamel.dev 發表〈"It's Hard to Eval" Is a Product Smell〉，文中自述過去三年的專業重心是 AI evals。Andrej Karpathy（前 Tesla AI 負責人、OpenAI 共同創辦人）在 2025 年 6 月 YC 的 AI Startup School（活動日為 6 月 16、17 日，影片上傳日為 2025-06-19）發表〈Software Is Changing (Again)〉。Google 的 People + AI Research（PAIR）團隊維護 People + AI Guidebook，下面引用的是「Explainability + Trust」一章，頁面沒有標日期，本篇於 2026-10-23 讀取。

爭點一：很難 eval 是評測做得不夠，還是產品該改？

Hamel Husain 2026 年的答案是改產品；他稱這類說法為 product smell（產品警訊，指設計可能出了問題的徵兆，中文是本站的譯法）。

評測這一邊。 同一位作者在更早的文章裡把力氣放在團隊自己的評測流程。2024-03-29 的〈Your AI Product Needs Evals〉寫道：「You must remove all friction from the process of looking at data.」2025-03-24 的〈A Field Guide to Rapidly Improving AI Products〉說，設計得好的資料檢視器能讓團隊迭代快上 10 倍，並以 Nurture Boss 為例：處理日期的成功率從 33% 升到 95%。這些做法降低的是評測人員看資料的成本。

產品這一邊。 2026-06-29 的文章把同一個「降低看資料的摩擦」往前推到使用者。他說最常聽到的反對意見是「我們的產品很難 eval」，並回應：「Artifacts that are hard for you to verify are often hard for users too.」注意原文用的是 often，他用三個自己提供過建議的產品當例子，沒有給統計。他還主張，為了容易驗證而做的設計，應該排在建立 evals 之前。

第一個例子是資料分析 agent。Hamel 認為常見錯誤是把答案當成唯一輸出。他的改法是聊天回覆先露出值得看的細節：這個答案改寫自哪一份已驗證的分析、作者是誰，用了哪個指標定義，哪些中間計算找不到可信來源。他舉 Hex 當這類產品中整合筆記本與聊天最好的例子。

這張草圖的重點在紅線標出的兩列：他列出的專家驗證步驟，最後一條寫道：某一步沒有可信的對照來源時，他會標出來，不會當成已確定的事呈現。使用者因此知道該把時間花在哪兩個數字上，不必重跑全部查詢。

另外兩個例子套用同一個模式。體育課教案產生器原本直接生成一份完整教案，Hamel 的草圖改成先檢索一份已驗證的教案，標出多少所學校在用（草圖寫 14 所、今年跑過 30 多次），再把調整的地方逐項列出理由，草圖中老師只需複核 2 處修改。工傷理賠的醫療報告原本只輸出 50 頁敘述，Hamel 的改法是先讀完所有紀錄，抽出事實並連回原頁，標出互相矛盾與缺漏之處，醫師確認過後才組出最後的報告。

下面把這三個例子對應的手法整理成圖。Hamel 在文中列了四個設計問題（要檢查什麼、拿什麼可信的東西對照、專家用什麼訊號、哪些小單元可以接受、修改或退回），並反覆使用三種手法：出處、逐步展開、拆成小單元。他的論點是這樣標註成本會下降，評測會有更好的訊號；他同時說「None of this is new」，也就是這些道理並不新。

工程上的意思。 本站的建議：每一份 agent 輸出，先寫下使用者要拿什麼對照，再決定要在介面上放出處、定義還是來源紀錄；找不到可信對照的項目，直接標在輸出上，同時列進評測要追的清單。

爭點二：驗證要多快，使用者又該有多少把握？

Karpathy 主張盡量加快人類審核，Google PAIR 主張讓使用者的信任落在恰當的位置，兩邊的目標並不相同。

加快審核這一邊。 Karpathy 在演講中說，人和 AI 的合作有一個迴圈：AI 通常負責生成，人負責驗證。他的說法是「It is in our interest to make this loop go as fast as possible.」，並且認為應用專屬的 GUI 能讓人審核這些會犯錯的系統，「you can see what's being added or subtracted」是他以 Cursor 的差異檢視為例的說法。他也說，自己有很大一部分心思花在怎麼把 AI 拴在人能掌控的範圍內（原話用 leash，牽繩）。投影片「Consider the full workflow of partial autonomy UIUX」在影片約 22 分。

校準信任這一邊。 Google PAIR 的章節不把「越信任越好」當目標。它寫道：「Users shouldn't implicitly trust your AI system in all circumstances, but rather calibrate their trust correctly.」章節舉了兩個方向的風險：人會過度信任系統做不到的事，也有大量「algorithm aversion」（對軟體系統的排斥）的研究。談到信心顯示，它警告：「A misleadingly high confidence, for example, may cause users to blindly accept a result.」並說更細緻的信心數字若看不出影響，可能令人困惑。對解釋的建議是「The best explanation is likely a partial one.」

兩份材料沒有直接交鋒。本站的歸納是：加快驗證只回答了「多快」，PAIR 多問了「驗證完使用者是不是信得剛好」。Hamel 的逐步展開（先給來源與假設，信任建立後收合）落在兩者之間。

更新的資料點。 Hamel 與 Antaripa Saha 在 2026-10-20 發表〈How To Use Decision Models for Evals〉，把決策模型（回傳 0 到 1 失敗機率的小型分類模型）拿來做自動評測。資料是一個租屋 agent 的 98 份有效對話紀錄，其中 61 份有已知失敗，標籤來自人工審查。他們發現，某個模型（Clef Flash）有一組紀錄的平均預測失敗機率約 8%，實際有 60% 含有失敗，並建議檢查機率是否符合實際結果。這份資料只有約 100 份、對話內容不公開，也沒有談使用者介面，只能說明一件事：連自動評分給的信心數字，也要拿人工標註的結果校準。

工程上的意思。 本站的建議：介面上若要顯示信心或分數，先用人工標註過的樣本確認它與實際失敗率相符；對不上時，寧可只顯示出處與假設。

爭點三：驗證的責任最後落在誰身上？

Hamel 把責任切成使用者能接受、修改或退回的小單位，Karpathy 要人留在迴圈裡，Google PAIR 要求風險越高，說明越完整。

縮小單位這一邊。 Hamel 在工傷理賠的例子裡讓醫師先確認事實，報告只用醫師已經確認過的內容組成；教案的例子讓老師只看 2 處修改。他說這樣自動評分也變容易，因為要測的面積縮小了。他也舉了程式碼：寫程式是最容易驗證的領域之一（有測試、型別與差異檢視），Cursor 與 Devin 仍會錄下介面改動的短影片，讓使用者確認功能真的能用。

留在迴圈裡這一邊。 Karpathy 的立場是人必須持續驗證，他花了很多心思在如何讓 AI 受人掌控。PAIR 的章節則有一個小節叫「Account for situational stakes」（考慮情境的風險高低），並寫道高風險情境下，「Don't say 'what' without saying 'why'」。

兩邊的差別在單位大小。Hamel 的設計把工作切到人看得完；PAIR 要求高風險時，每個結果旁都要有理由。Hamel 的文章用設計草圖說明，沒有給使用者驗證時間或抓出錯誤比例的數字（以 2026-10-23 讀到的版本為準），所以「拆小單元確實讓使用者抓到更多錯」目前只是設計主張。

工程上的意思。 本站的建議：把使用者對每個單元按下的接受、修改、退回記成一筆紀錄，附上當時介面顯示的出處。這份紀錄同時是 Hamel 所說的標註資料，也能拿來檢查 PAIR 要求的信任校準有沒有成真。

回到那個 4.21M

財務主管問「這個數字怎麼來的」，這個 agent 如果照 Hamel 的草圖改，畫面本身就能回答：它改寫自哪份已驗證的分析、用了哪個指標定義、哪兩個中間數字還沒有可信的對照。

我不會先去找更強的評分模型。我會先把 Hamel 的四個問題逐題寫在需求文件裡，答不出來的那一題，通常就是介面少放了東西。放上去之後，再用 PAIR 的標準檢查：使用者看完是信得剛好，還是看到「已驗證」三個字就不再往下看。這一步我沒有現成的研究可以引用，需要在自己的產品裡用使用者操作紀錄驗證。

常見問題

「很難 eval」就代表產品設計有問題嗎？

不一定。Hamel Husain 的原話是產出難以驗證時，使用者「often」也難以驗證，並以他提供過建議的三個產品為例，沒有給統計。先檢查使用者要拿什麼對照這個產出；找不到對照物，才輪到改產品。

讓驗證更容易，會不會讓使用者過度信任？

有可能。Google PAIR 的章節指出，人會過度信任系統做不到的事，信心顯示過高也會讓人不加檢查就接受；它的目標是校準信任。所以介面除了降低驗證成本，也要放出無法驗證的項目。

哪些產品最該先做這個檢查？

使用者得自己判斷輸出對錯、重新驗證又很貴的產品。Hamel 的例子是 50 頁的醫療意見，醫師若得從頭核對，成本接近重做。寫程式有測試與型別可用，Cursor 與 Devin 仍錄下介面改動的短影片。

自動評分（LLM judge、決策模型）怎麼配合這件事？

先用人工標註過的樣本校準。Hamel 與 Antaripa Saha 的資料有 98 份有效紀錄，其中 61 份有已知失敗；某個模型的一組紀錄平均預測失敗機率約 8%，實際有 60% 含有失敗。分數可以拿來篩選，但顯示給使用者之前要先量過。

延伸閱讀

• AI Demo 很成功，為什麼一上線就出事？五條失敗路徑一次看懂（2026）
• Loop Engineering 是什麼？怎麼讓 AI 自己把事情做完再叫你？（2026 實戰教學）

參考資料

• Hamel Husain, "It's Hard to Eval" Is a Product Smell, 2026-06-29。查證日 2026-10-23。 https://hamel.dev/blog/posts/eval-smell/
• Hamel Husain, Your AI Product Needs Evals, 2024-03-29。 https://hamel.dev/blog/posts/evals/
• Hamel Husain, A Field Guide to Rapidly Improving AI Products, 2025-03-24。 https://hamel.dev/blog/posts/field-guide/
• Hamel Husain, Antaripa Saha, How To Use Decision Models for Evals, 2026-10-20。 https://hamel.dev/blog/posts/decision-model-evals/
• Andrej Karpathy, Software Is Changing (Again), YC AI Startup School，2025 年 6 月（活動日 6 月 16–17 日，影片上傳 2025-06-19）。引言依兩份第三方逐字稿（singjupost.com、prepublish.ai）互相核對，投影片取自影片。 https://www.youtube.com/watch?v=LCEmiRjPEtQ
• Google People + AI Research (PAIR), People + AI Guidebook：Explainability + Trust（頁面無日期，查證日 2026-10-23；CC BY-NC-SA 4.0）。 https://pair.withgoogle.com/chapter/explainability-trust/
• Y Combinator, Join us at AI Startup School — June 16-17（活動日期）。 https://www.ycombinator.com/blog/ai-startupschool