建立一個最小可行評估

本影片中的示範錄製於 2026 年 8 月。它運行於 Claude Haiku 4.5、Claude Sonnet 5 和 Claude Opus 5。在較新的模型上，結果會有所不同。每堂課程的示範都是獨立的評估運行，因此其分數和成本不會與其他課程中的相符。

評估是一種模型參加的測驗。 它有三個部分：真實的輸入、您對每個輸入預期的答案，以及評判每個模型所回傳內容的方法。每個模型會對每個輸入執行您的提示。一個輸入連同其預期答案構成一個案例，而對每個案例進行評分就能得到一個分數。

Meridian 的提取提示從每份月度專案報告中提取三個欄位：專案 ID 和排程狀態，這兩者是簡短的值，以及最大風險，這是一個句子。

建立評估就像出一場考試，您是老師，而模型是學生。

LLM 評審是一個第二模型，用來檢查答案並判定其是否正確。任何評判答案的東西都稱為評分者，無論它是程式碼、模型，還是人。您將分六個步驟建立 Meridian 的評估：

1. 為每個欄位選擇評分者
2. 設計案例集
3. 寫下預期答案
4. 為最大風險設定 LLM 評審
5. 運行模型並評判其答案
6. 在信任評審之前先對樣本進行人工評分

為每個欄位選擇評分者

評判答案有三種方式。規則是選擇既可靠又能擴展的最快方法。

1. 基於程式碼的評分。 您的程式碼檢查答案是否與預期答案完全相符，或是否包含某個關鍵詞組。這是最快且最可靠的方式，並且可以擴展到任意數量的案例。
2. LLM 評審。 評審適合那些兩個不同句子都可能正確的答案。它同樣快速、靈活且可擴展。
3. 人工評分。 一個人閱讀每個答案，這能提供最佳的品質，但速度慢且成本高，因此排在最後。對於專業的、高風險的工作，以及取決於判斷的答案，人依然是合適的評分者。

對每個可以精確檢查的欄位使用程式碼，只把剩下的交給評審。 以下是這在 Meridian 其中一個案例（報告 r032）三個欄位上的實際運作方式。

不過，當報告沒有指出任何風險時，預期的 top_risk 答案為 null，也就是 JSON 的空值。程式碼可以用精確比對來檢查這一點。

設計案例集

四條規則形塑了整個案例集。它們建立在文件中的評估設計原則之上。

1. 讓案例具有任務針對性。 用您自己的真實報告來建構它們，因為範例資料只能顯示模型在範例上的表現。
2. 自動化評分。 您會反覆運行這個案例集，因此日常評分必須能在沒有人的情況下運作。
3. 重視數量勝過精緻度。 在相同的工作量下，許多自動評分的案例比少數精心人工評分的案例告訴您更多資訊。
4. 對邊緣案例進行分層。 邊緣案例是指生產環境中仍會出現的不尋常輸入，例如掃描版報告。讓每種邊緣案例在案例集中所佔的比例，大致符合它在生產環境中所佔的比例，所以如果掃描版報告佔到達報告的 5%，就讓它們在案例集中大約佔 5%。

最重要的是，案例的組成應該要看起來像生產環境傳送給您的內容。 團隊常常認為數量意味著數百個案例，但一組 20 到 50 個簡單案例就是很好的開始。

Meridian 最終確定了 50 個案例。其中 30 個是典型報告，10 個涵蓋多個專案，另外 10 個是缺失風險的案例，意指沒有風險章節的報告。這兩種不尋常的情況在 Meridian 中經常出現，因此它希望能涵蓋它們。

寫下預期答案

已由人寫下預期答案的案例稱為已標記集。在任何模型運行之前，親自從報告中寫下每個預期答案。 程式碼評分者會將模型的答案與這些答案進行比較。

Meridian 將其已標記集保存在一個檔案 golden.json 中，每個案例對應一筆記錄。一筆記錄包含案例的 id、其 category，以及每個欄位的預期答案。category 是 typical、multi_project 或 missing_risk。

為最大風險設定 LLM 評審

top_risk 欄位保存一個句子。程式碼無法判斷兩個不同的句子是否指出相同的風險，因此這個欄位交給評審處理。這就是論文題，就像教學助理一樣，評審需要一份評分指南。

這份指南就是評分準則，一套書面規則，說明什麼算正確、什麼算不正確。它應該詳細且清楚。

評審的提示包含報告、答案和評分準則。每一項都放在自己的 XML 標籤中，這樣評審比較不會把它們混在一起。您的預期答案不會出現在提示中，因為評審要根據報告本身來做判斷。這樣一來，答案就不會僅僅因為用與您不同的措辭表達風險而失分。不過仍要保留您的預期答案，因為這是您人工評分時判斷正確答案的依據。

評審對一個答案做出的判定稱為其裁決。只有當裁決以您的程式碼可以計算的形式回傳時，它才有用。 結構化輸出能為您提供這一點。您隨請求一起傳送一個 JSON schema，而回應必須與其相符。JSON schema 描述了 JSON 可以保存哪些欄位，以及每個欄位可以放什麼內容。

Meridian 的 schema 有兩個欄位，explanation 和 verdict。裁決必須是 correct、incorrect 或 unknown。解釋是對評審為何如此判定的簡短說明，因此當您想知道某個答案出了什麼問題時，您讀的就是這個。

最重要的值是 unknown。它給了評審一條退路，一個表示自己無法判斷的選項。沒有它，每當評審不確定時，它就必須在其餘兩者之間猜測。

運行模型並評判其答案

在任何東西能被評分之前，您需要先有答案。用每個您正在測試的模型，對每個案例運行您的提示，並將每個答案儲存到檔案中。Meridian 用 Claude Haiku 4.5、Claude Sonnet 5 和 Claude Opus 5 在全部 50 個案例上運行了其提取提示。

先在程式碼也能評分的案例上測試評審一次，看看兩種評分者是否一致。 Meridian 第一次評審運行只取了 10 個缺失風險的案例，三個模型共產生 30 個答案。它們的預期答案是 null，所以程式碼也能評分。將每個裁決與其對應的答案保存在一起，以便日後人工檢查評審。

評審第一次運行，在程式碼也能評分的 10 個缺失風險案例上進行。

對於沒有風險章節的報告，Meridian 現在對每個模型都有了一個數字，而以前只有各種意見。

Haiku 4.5 的五個不正確答案都是同一種錯誤，案例 r045 就是一個例子。

評審的解釋指出了答案所犯錯誤的種類。該錯誤源自提取提示，因為它從未說明當報告沒有指出風險時該怎麼做。

在信任評審之前先對樣本進行人工評分

評審在全部 30 個答案上都與程式碼一致，但這些答案原本程式碼也能檢查。評審真正的工作是評判自由文字，在這方面程式碼幫不上忙。在把這項工作交給它之前，測試它是否可靠。 有兩種做法有幫助。

1. 親自評分一個樣本。 親手評分幾個已保存的答案，並將您的評分與評審的裁決進行比較，因為評審的判定應該與人類專家緊密一致。在您和評審意見不一致的地方，讓評分準則更清楚，然後再次運行。
2. 使用一個沒有寫出那些答案的評審。 通常最好用與產生輸出的模型不同的模型來評分。

重點整理

1. 在精確檢查可行的地方用程式碼評分，在兩個不同句子都可能正確的地方用評審評分，在取決於判斷的地方用人評分。
2. 在任何模型運行之前先寫下預期答案，並建立一個看起來像生產環境的案例集。
3. 給評審一份評分準則、一個裁決必須符合的 schema，以及說出 unknown 的選項。
4. 在信任評審之前，先人工評分其工作的一個樣本。