AI · 2026-08-31

昨天那條算式的結論是四個 0.95 的子代理接上三道各掉 10% 的交接縫，端到端只剩 0.59，而且每一塊儀表板都是綠的。綠燈不是造假，是它們量的東西本來就不含縫——per-agent 指標的定義域是「單一節點的輸入到輸出」，交接發生在節點之間，任何以節點為單位的量測在數學上就照不到它。要看見縫，唯一的辦法是把量測對象換成整條軌跡：不是評估每個節點做得好不好，而是評估這一連串節點串起來的路徑本身。今天把這件事做完，從三層評估對象的區分開始，到具體怎麼算、怎麼採集資料、怎麼在交接點插探針，最後說清楚它什麼時候不值得做。

📖 學

三層評估對象：outcome、step、trajectory

評估 agent 有三個互不重疊的對象，混用會得到互相矛盾的結論。**最終答案（outcome）**問的是「使用者拿到的東西對不對」，輸入是一個問題、輸出是一個字串或一次副作用，中間發生什麼完全不看。**單步（step-level）**問的是「這一次工具呼叫／這一次模型生成合不合格」，粒度是單一 span。**整條軌跡（trajectory）**問的是「從問題到答案的這條路徑合不合理」，看的是選了哪些工具、順序對不對、有沒有多繞、資訊有沒有在傳遞中掉東西。

outcome-only 的失效模式有一個很傳神的名字：lucky pass。agent 用了完全錯誤的方法，卻碰巧產出正確答案，於是通過測試。這在有標準答案的封閉題目上特別容易發生——選項只有幾個，猜也有一定機率對；在工具型 agent 上則表現為「跳過了必要的檢查步驟但結果剛好沒事」。這種 agent 會通過你的 CI，然後在生產環境遇到第一個不走運的輸入時炸掉，而你的 eval 集裡沒有任何一條記錄能告訴你它一直在跳步驟。更根本的問題是 outcome-only 沒有定位能力：0.59 這個數字只說「壞了」，不說壞在哪一段，你只能靠猜和二分法去逐個節點拆。

step-level 的失效模式是局部最優。每一步都合格不蘊含整條路徑合格，因為 step-level 的評分函數裡沒有「全局目標」這個變數。舉一個很常見的情況：檢索代理每一步的 context recall 都是 0.93、faithfulness 都是 0.96（就是 08-27 用 RAGAS 量的那兩個指標），單看它無可挑剔——但它檢索的主題是上一棒交給它的，而上一棒漏掉了「此客戶已超過 30 天退貨期」這個約束。檢索代理在錯誤的前提下把每一步都做對了。你可以把它從 0.93 調到 0.97，端到端一分都不會漲。這就是為什麼四塊儀表板全綠而總分 0.59：每個節點的分數都是條件機率，而條件本身是壞的。

軌跡評估的定義域剛好補上這塊：順序、選擇、必要性、資訊流——這四樣東西全都只存在於節點之間。

五種軌跡比對法，與它們各自的失效模式

軌跡比對的基本形式是「一條參考軌跡（reference trajectory）對一條實際軌跡（predicted trajectory）」，差別在比對的嚴格程度。Google 的 Gen AI evaluation service 與 LangChain 的 agentevals 各自提供了一組，名字不同但語意重疊：

做法	判準	主要失效模式
exact match	工具呼叫與順序完全相同	幾乎永遠是 0。對非決定性系統毫無鑑別力，只能當「有沒有徹底改變行為」的煙霧警報
in-order match	參考的呼叫全數出現，且相對順序保持；允許額外呼叫	「允許額外呼叫」會被用來洗掉順序違規（下面舉例）
any-order / unordered match	參考的呼叫全數出現，順序不論	完全放棄前置條件的檢查。副作用型工具用它等於沒測
subset / superset	前者要求不多呼叫、後者要求至少呼叫	只看集合成員，對重複呼叫與參數錯誤同樣無感
precision / recall over tool calls	多重集合交集除以各自總數	對順序完全無感；用 set 而非 multiset 實作時連浪費都量不到
LLM-as-judge on trace	讓模型讀整條 trace 打分	位置偏誤、長度偏誤、self-preference（下一節詳談）

拿一個具體的退款流程來算。參考軌跡 R 有五個呼叫：

[
  {"tool": "search_policy",      "args": {"topic": "refund"}},
  {"tool": "get_order",          "args": {"order_id": "A-1029"}},
  {"tool": "check_eligibility",  "args": {"order_id": "A-1029", "policy_id": "P-7"}},
  {"tool": "issue_refund",       "args": {"order_id": "A-1029", "amount": 1280}},
  {"tool": "send_confirmation",  "args": {"order_id": "A-1029"}}
]

實際軌跡 P 有六個，開頭順序反了，中間多打了一次 get_order：

[
  {"tool": "get_order",          "args": {"order_id": "A-1029"}},
  {"tool": "search_policy",      "args": {"topic": "refund"}},
  {"tool": "get_order",          "args": {"order_id": "A-1029"}},
  {"tool": "check_eligibility",  "args": {"order_id": "A-1029", "policy_id": "P-7"}},
  {"tool": "issue_refund",       "args": {"order_id": "A-1029", "amount": 1280}},
  {"tool": "send_confirmation",  "args": {"order_id": "A-1029"}}
]

exact match = 0，順序不同且多一步。any-order match = 1，五個都在。in-order match 也是 1——這一項值得停下來看：R 的順序是 search_policy 在 get_order 之前，P 的第一個呼叫卻是 get_order，順序明明違反了，但因為 P 在第三步又打了一次 get_order，比對演算法找到 search_policy(P₂) → get_order(P₃) → check(P₄) → issue(P₅) → send(P₆) 這條合法的子序列，判定通過。**多餘的重複呼叫替順序違規補了位。**這是 in-order match 最需要警覺的地方：它獎勵「多打幾次總有一次順序對」的行為。

precision / recall 要用多重集合算才有意義。P 的多重集合是 {get_order:2, search_policy:1, check:1, issue:1, send:1} 共 6 個，R 是 5 個，逐鍵取 min 得到交集 5。於是 precision = 5/6 ≈ 0.833，recall = 5/5 = 1.0，F1 ≈ 0.909。precision 掉的那 0.167 精確地指向那次多餘呼叫，這正是我們想量到的浪費。如果實作時偷懶用一般集合（把 P 去重成 5 個 distinct 工具），precision 會變成 5/5 = 1.0，浪費就從指標上消失了。多數自己動手寫的比對函式都栽在這一行。

至於順序該不該計較，判準不是風格而是副作用與前置條件。get_order 與 search_policy 都是唯讀、可交換的取數動作，誰先誰後不影響任何結果，對它們計較順序只會讓 eval 變得脆弱又吵。issue_refund 必須在 check_eligibility 之後、send_confirmation 必須在 issue_refund 之後——這兩條不是偏好，違反了就是產品缺陷（先退款再檢查資格是真的會賠錢的 bug）。所以正確的做法不是在整條軌跡上套單一 mode，而是把軌跡切成可交換區塊，對區塊內用 unordered，對跨區塊的硬約束寫成成對的 precedence 斷言：

unordered_block: [search_policy, get_order]
precedence: check_eligibility BEFORE issue_refund
precedence: issue_refund      BEFORE send_confirmation
no_duplicate: get_order (max 1 per order_id)

這組斷言比 strict 或 unordered 任何一邊都準，而且是確定性的、可以直接進 CI，不需要 LLM 呼叫。

可觀測性是評估的前置條件

上面所有做法都預設一件事：你手上有一條結構化的、帶父子關係的軌跡物件。日誌檔給不了這個。你需要的是 span 樹——每個 agent 呼叫、每個模型呼叫、每個工具呼叫各自一個 span，共用同一個 trace_id，父子關係還原出誰呼叫了誰。沒有 span 樹之前，「一條軌跡」這個物件根本不存在，軌跡評估無從談起。

OpenTelemetry 的 GenAI semantic conventions 就是為此而生的一套命名約定，但它的成熟度必須說清楚：**截至 2026 年年中，GenAI 的 span、屬性、指標仍標記為 Development（experimental），沒有任何一項是 Stable。**2026 年 6 月 12 日的 v1.42.0 把所有 gen_ai.* 從主 semantic-conventions repo 搬到獨立的 semantic-conventions-genai 倉庫，那是為了讓這塊快速變動的東西有自己的釋出節奏，不是升 stable。實務上 agent 與 framework 這層的 span 從 2026 年 Q1 以來相當穩定，可以用；但屬性名稱仍可能改，所以在你的採集層跟評估層之間留一層映射，不要讓 eval 程式直接綁死屬性字串。

span 的切法照 convention 走：create_agent {agent.name} 描述遠端 agent 資源的建立，invoke_agent {agent.name} 描述一次 agent 呼叫（span kind 為 CLIENT），底下掛 chat {model} 表示模型呼叫、execute_tool {tool.name} 表示工具呼叫。屬性方面 gen_ai.operation.name 與 gen_ai.provider.name 是 Required，gen_ai.agent.name / gen_ai.agent.id / gen_ai.request.model 視情況必填，gen_ai.conversation.id 讓你把跨請求的多輪對話串成一條。

什麼進 attribute、什麼進 event，判準很單純：**會被拿來 group by、算聚合、設告警門檻的，進 attribute；只有在事後重播軌跡時才需要讀的大體積內容，進 event。**前者是低基數、每 span 一份的欄位——gen_ai.usage.input_tokens、gen_ai.usage.output_tokens、error.type、模型名、工具名。後者是 gen_ai.system_instructions、gen_ai.input.messages、gen_ai.output.messages，這三個在 convention 裡的 requirement level 是 Opt-In，因為它們幾乎必然含使用者內容與 PII，預設不採。convention 對格式也有規定：錄在 event 上時 MUST 用結構化形式；錄在 span 上時 SHOULD 結構化，不支援結構化時才 MAY 退回 JSON 字串。把整份對話塞成一個超長 string attribute 是最常見的錯誤實作，它會讓後端的 attribute 索引爆掉，而且完全喪失查詢能力。

一個 convention 目前還沒有涵蓋的東西：agent 之間的 handoff。沒有標準的 handoff span 或 gen_ai.handoff.* 屬性族。你得自己開一個命名空間，例如 app.handoff.from / app.handoff.to / app.handoff.payload，不要污染 gen_ai.*，否則將來 convention 真的加了同名東西你會撞在一起。這個自訂 span 是下一節整套做法的載體。

LLM-as-judge 用在軌跡上的三種偏誤

MT-Bench 那篇論文（Zheng et al., 2023）系統性地命名了三種偏誤：position bias、verbosity bias、self-enhancement bias。它們在軌跡評估上不只是存在，而是被放大。

位置偏誤在軌跡上跟 Lost in the Middle 是同一個機制。一條 15 步的軌跡展開成 prompt 可能是好幾萬 token，judge 對開頭的請求與結尾的答案印象清楚，中間那幾步最容易被略過——而交接恰恰就發生在中間。你請 judge 評「資訊有沒有在傳遞中掉」，它最看不清楚的就是那一段。

長度偏誤在軌跡上會反轉成特別危險的方向。一般文本評分裡長度偏誤是「偏好囉唆的回答」，在軌跡上則是「偏好步驟多的路徑」——十二步、看起來很努力很謹慎的軌跡拿高分，三步的最短正確路徑被判為「不夠仔細」。用這種分數去迭代 prompt，你會系統性地把 agent 訓練成愛繞路，成本和延遲一起上升，而分數在漲。

self-preference 在多代理系統裡尤其糟，因為 judge 和 orchestrator 常常就是同一個 model id——你在用同一個模型評自己的推理風格，它當然覺得合理。

對應的緩解手段各有代價。位置偏誤的標準解是交換順序跑兩次取一致，但那只適用於 pairwise 比較；single-grading 的軌跡評分用不上。對軌跡更有效的是分段評分：把軌跡切成固定窗口（例如每 4 步一段，重疊 1 步），每段獨立評分再彙總，讓每個步驟都當過一次「開頭」。長度偏誤的解法是把效率從 judge 手上拿走——步數、重複呼叫、token 成本這些東西 precision 和確定性斷言算得又快又準，judge 只負責它獨有能力的部分（這一步的推理有沒有跟上一步矛盾、工具參數的語意對不對）。self-preference 則沒有巧解，換一家 vendor 的模型當 judge。

無論如何都要校準。收 100 到 300 條人工標註，重跑 judge，算 Cohen’s kappa：κ = (p_o − p_e) / (1 − p_e)，其中 p_o 是原始一致率、p_e 是隨機一致的期望值。舉個實際會遇到的數字：100 條二元判定，judge 與人一致 82 條，p_o = 0.82；judge 判 pass 70 條、人判 pass 75 條，於是 p_e = 0.70×0.75 + 0.30×0.25 = 0.60；κ = (0.82 − 0.60) / (1 − 0.60) = 0.55。**82% 的一致率聽起來很體面，κ 只有 0.55，屬於中等。**這個落差來自類別分布偏斜——大部分軌跡本來就會過，一個永遠回答 pass 的 judge 也能拿到 75% 一致率。實務門檻：κ < 0.4 的 judge 不要拿來當 CI gate，只能當趨勢參考；要當 gate 至少要 0.6 以上，而且每次換 judge 模型或改 rubric 都要重測。

一個可以直接改的 rubric 骨架：

你會看到一條 agent 執行軌跡的片段（步驟 {start}–{end}，共 {total} 步）。
只評這個片段，不要推測片段之外發生了什麼。
 
對以下四項各給 0 / 1 / 2，並各引用一個具體步驟編號作為證據：
 
1. 步驟必要性 —— 這些步驟是否都對達成任務有貢獻？
   0 = 有明顯無用或重複的呼叫；1 = 有可疑但可辯護的步驟；2 = 全部必要
2. 參數正確性 —— 工具參數是否與此前步驟取得的事實一致？
   0 = 出現憑空捏造或與前文矛盾的參數；1 = 有未經驗證的參數；2 = 全部可溯源
3. 前置條件 —— 有副作用的動作是否都在其必要檢查之後？
   0 = 違反；1 = 順序可疑；2 = 滿足。若片段內沒有副作用動作，填 N/A
4. 資訊延續 —— 本片段是否使用了前一片段傳入的關鍵事實？
   0 = 明顯忽略；1 = 部分使用；2 = 完整使用。片段為軌跡開頭時填 N/A
 
明確規則：
- 步驟數量本身不是品質。較短的正確路徑優於較長的正確路徑。
- 不要獎勵「看起來很謹慎」。只有實際改變了後續決策的檢查才算數。
- 你無法從片段中判斷的項目，填 N/A，不要猜。
 
輸出 JSON：{"scores": {...}, "evidence": {...}, "na": [...]}

三條明確規則裡，第一條直接對抗長度偏誤，第三條逼 judge 承認不確定而不是硬猜——後者對降低變異性的效果通常比前兩條加起來還大。

多代理特有的度量：把交接的資訊保真度變成可測的東西

回到 0.59。要修那三道縫，得先讓縫變成一個有數字的東西。做法是在交接點插一組「必須被傳下去的事實」探針，量 handoff recall。

第一步，對每條交接邊 A→B 定義一份 required_facts schema。這份 schema 不是從 A 的輸出反推，而是從 B 的需求反推：B 要正確完成它的工作，最少需要哪幾個事實？以退款流程為例，交接邊「意圖解析代理 → 政策代理」的必要事實可能是訂單編號、購買日期、退款原因分類、以及那句關鍵約束「已超過 30 天退貨期」。

第二步，建帶標記事實的評估集。在上游輸入裡植入可驗證的唯一值——隨機生成的訂單號 A-1029、精確金額 1280、政策 ID P-7。用唯一值而不是「台北」「三天前」這種下游可能自行猜出來的東西，否則你量到的是模型的先驗知識，不是傳遞保真度。同時探針要跟真實 payload 同形，不要用 __PROBE_FACT_1__ 這種明顯的 magic string，那樣你量的是「agent 會不會複製奇怪字串」。每條邊放 3 到 7 個探針，再多探針本身就變成 payload 裡的雜訊。

第三步，在自訂的 handoff span 上抓 B 實際收到的 payload：

{
  "name": "handoff intent_agent -> policy_agent",
  "trace_id": "4bf92f...",
  "attributes": {
    "app.handoff.from": "intent_agent",
    "app.handoff.to": "policy_agent",
    "app.handoff.required_facts": ["order_id","purchase_date","reason_code","past_30d_constraint"],
    "app.handoff.facts_present": ["order_id","purchase_date","reason_code"],
    "app.handoff.facts_distorted": [],
    "app.handoff.recall": 0.75
  }
}

第四步，定義兩個分開的數字，不要合成一個：

• handoff_recall(A→B) = B 收到的必要事實數 / 必要事實總數 —— 量的是遺漏
• handoff_fidelity(A→B) = 收到且值未被改寫的事實數 / 收到的事實數 —— 量的是變形

分開報是有理由的。變形比遺漏危險得多：漏掉「需主管核准」時下游可能還會問一句，把「需主管核准」改寫成「已核准」時下游會非常有信心地做錯事——這就是 08-29 講的 poisoning，錯誤敘述進了上下文後會自我強化，補一句更正沒有用。把兩者混在一個分數裡，你會看不出正在發生的是哪一種。

第五步，把它跟端到端分數對照。連乘估計是 Π(per-agent score) × Π(handoff_recall)。四個 0.95 的代理是 0.95⁴ ≈ 0.815；假設三條邊實測 handoff_recall 為 0.90 / 0.92 / 0.88，乘積 ≈ 0.729，估計端到端 ≈ 0.594——跟昨天算出的 0.59 對得上。這個對照的價值不在於數字漂亮，而在於：如果實測端到端明顯低於這個估計值，差額就是連「軌跡」都照不到的損失（通常是 orchestrator 的決策錯誤或工具本身的失敗率），你知道還要往哪裡挖。而如果對得上，你就拿到了昨天缺的那塊儀表板——不是 per-agent score，是 per-edge recall，修的時候直接知道修哪一條邊。

實務上第一次量完往往會發現問題集中在一兩條邊上，而且原因很無聊：上游用自然語言摘要交棒，把結構化欄位寫成散文，下游再抽一次就掉了。這種修法也很無聊——加一個 structured payload 欄位，讓事實走 schema 而不是走句子。無聊但有效，而且你現在有數字證明它有效。

誠實的邊界

軌跡評估貴。一條 15 步的軌跡展開成 judge 的輸入是幾萬 token，100 條 eval set 跑一輪就是可觀的成本，而且 agent 本身還得真的跑一次（用真實工具有副作用，用 mock 則測不到真實失敗）。這個成本結構決定了它不能像單元測試那樣每次 commit 都跑。

參考軌跡難建，而且有個隱蔽的陷阱：**你以為的黃金路徑，往往只是你當初實作的那條路徑。**當 agent 找到一條更短更好的解法時，嚴格的軌跡比對會把它判為失敗。這不是理論擔憂，是升級模型後最常遇到的假警報。緩解方式是參考軌跡只寫硬約束（precedence、必要工具、禁止工具），不寫完整序列。

非決定性讓 CI 很痛。同一個輸入跑兩次軌跡不同，二元 assert 必然 flaky，而 flaky test 的下場是被停用。可行的切法是把確定性的東西和統計性的東西分開放：precedence 斷言、禁用工具、參數 schema 這類硬約束違反了就是 bug，放 CI 直接擋；judge 分數與 handoff recall 跑 N 次取分布，放 nightly，在趨勢圖上看，用分布下界（例如 p10）而不是單次結果當警戒線。

什麼時候不該做這件事，有四種情況值得直說。單代理、少於三個工具、單步就能完成的任務——outcome eval 已經足夠，軌跡評估只是純成本。還沒有穩定的 trace——先做可觀測性，沒有 span 樹談軌跡評估是空的，這個順序不能顛倒。沒有人標預算——別上 LLM-as-judge，未校準的 judge 分數比沒有指標更糟，因為它給你錯誤的安全感，而你會拿它去做決策。產品還在每週改架構——參考軌跡的維護成本會超過它的價值，這時候先只做 handoff 探針，因為探針綁的是「哪些事實必須傳到」而不是「走哪條路」，改架構時比較不會失效。

🧠 記

• 三層對象不能互相替代：outcome 說「壞了」、step 說「這個節點還好」、trajectory 說「壞在哪一段」。四塊綠燈配 0.59，缺的是第三層。
• lucky pass：用錯方法但答對，outcome-only 抓不到。step-level 則會把你優化到局部最優——每個節點的分數都是條件機率，條件壞了調節點沒用。
• 那條退款軌跡的實算：exact = 0、any-order = 1、in-order 也 = 1（多打一次 get_order 替順序違規補了位）、precision = 5/6 ≈ 0.833、recall = 1.0、F1 ≈ 0.909。precision 要用多重集合，用 set 會變成 1.0，浪費就消失了。
• 順序該不該計較的判準是副作用與前置條件，不是風格。可交換區塊用 unordered，硬約束寫成 precedence 斷言，確定性、可進 CI、不用 LLM。
• OTel GenAI conventions 2026 年年中仍全數為 Development / experimental；v1.42.0（2026-06）搬到獨立 repo 是釋出節奏切分，不是升 stable。留一層屬性映射，別綁死字串。
• attribute vs event 的判準：要 group by / 設門檻的進 attribute，只在重播時讀的大內容進 event。gen_ai.input.messages 等三個內容屬性是 Opt-In，預設不採。handoff 目前沒有標準 span，自開 app.handoff.*，別污染 gen_ai.*。
• judge 的三偏誤在軌跡上都被放大：位置偏誤讓中間（交接處）被略過、長度偏誤把 agent 訓練成愛繞路、self-preference 在 judge 與 orchestrator 同一個 model id 時最嚴重。分段評分 + 把效率交給確定性指標 + 換 vendor。
• 82% 一致率 → κ = 0.55。偏斜資料上原始一致率嚴重高估。κ < 0.4 不能當 gate，要當 gate 至少 0.6。
• handoff 要拆成兩個數字：recall 量遺漏、fidelity 量變形。變形更危險——「需主管核准」變「已核准」，下游會非常有信心地做錯。
• 0.95⁴ × (0.90×0.92×0.88) ≈ 0.594。實測端到端若明顯低於這個估計，差額就是連軌跡都照不到的損失。

✍️ 實踐

挑一條你系統裡真實跑過、而且你知道它結果不太對的請求，20 到 30 分鐘做完下面四步。不要挑成功的案例，成功案例學不到東西。

1. 手工還原 span 樹（8 分鐘）。翻日誌或 trace，把這次執行畫成一棵樹：哪個 agent 呼叫了哪個、每個 agent 底下有幾次模型呼叫和工具呼叫。如果你畫不出來，這就是今天最重要的發現——先去補可觀測性，後面三步都做不了。畫出來之後數一下總共幾個工具呼叫，其中有幾個是重複的。

2. 寫一條 required_facts（7 分鐘）。挑這棵樹裡最可疑的那一條交接邊，站在下游那一棒的立場問：它要做對它的事，最少需要哪幾個事實？寫成 3 到 7 條的清單。這份清單要從下游需求反推，不是抄上游輸出。

3. 人工算一次 handoff recall 和 fidelity（8 分鐘）。找出下游實際收到的 payload，逐條對第 2 步的清單打勾。分成三堆：有傳到且值正確、有傳到但值被改寫、根本沒傳。recall = (前兩堆) / 總數，fidelity = 第一堆 / (前兩堆)。兩個數字分開寫下來。

4. 寫兩條 precedence 斷言（5 分鐘）。從第 1 步的軌跡裡找出至少一個有副作用的動作，以及它必須在哪個檢查之後。寫成 X BEFORE Y 的形式。這兩條是你今天唯一能立刻進 CI 的東西——它們確定性、不用 LLM、違反了就是真 bug。

做完後回答一個問題：**你的問題出在 recall（東西沒傳）還是 fidelity（東西傳歪了）？**如果是後者，先去看上游是不是用自然語言摘要在交棒。

🔗 延伸學習

• GenAI agent spans（OpenTelemetry semantic-conventions-genai）　create_agent / invoke_agent span 的完整屬性表與 requirement level，每一項都標了 Development 徽章，可直接對照確認成熟度。
• Inside the LLM Call: GenAI Observability with OpenTelemetry（2026-05）　官方部落格對這套 convention 的導覽，含內容擷取為何是 Opt-In 的取捨說明。
• How to evaluate your agent with trajectory evaluations（LangSmith）　agentevals 的 strict / unordered / subset / superset 四種 mode 與 tool_args_match_mode，附可執行的 Python 與 TypeScript 範例。
• Evaluate an agent（Vertex AI Agent Engine）　trajectory_exact_match / in_order_match / any_order_match / precision / recall 的官方定義，本文的計算方式即依此。
• Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena（Zheng et al., 2023）　position / verbosity / self-enhancement 三種偏誤的原始命名與量測，以及 GPT-4 judge 與人類一致率超過 80% 這個常被引用的數字。

💬 問 AI

我要替我的多代理系統設計一套端到端軌跡評估，重點是量出「per-agent 指標照不到」的交接損失。
請用我的實際結構算，不要給通用建議。
 
我的系統現況：
- 代理數量與各自職責：____
- 交接拓撲（誰交給誰，是鏈狀／星狀／有無回頭邊）：____
- 每個代理目前的 per-agent 分數與量法：____
- 實測的端到端分數（若沒有，直說沒有）：____
- 目前的 trace 狀況：有沒有 span 樹／有沒有共用 trace_id／用什麼後端：____
- 一條典型軌跡的步數與工具呼叫數：____
- 工具清單，並標出哪些有副作用（會寫入、會送出、會付錢）：____
- 有沒有人工標註的預算，大概能標幾條：____
- CI 現在跑什麼 eval、跑多久一次：____
 
請依序做六件事：
 
1. 用 0.95^n × Π(handoff_recall) 的形式寫出我的端到端估計式，先用 0.9 當各邊的
   佔位值算一次。若我有實測端到端分數，指出估計值與實測的差額，並說明那個差額
   可能來自哪裡（orchestrator 決策、工具失敗率、還是量測本身的問題）。
 
2. 幫我把軌跡切成「可交換區塊」與「precedence 硬約束」。用我的工具清單判斷，
   哪些呼叫順序無關、哪些違反了就是產品缺陷。硬約束寫成 X BEFORE Y 的斷言清單，
   標明每一條違反時的實際後果。
 
3. 挑出最可疑的那條交接邊，替它寫一份 required_facts schema。要從下游需求反推，
   說明每個欄位為什麼是必要的、以及下游能不能自己猜出來（能猜出來的不算探針）。
   同時給我 handoff_recall 與 handoff_fidelity 的計算定義。
 
4. 依我的 trace 現況，列出我還缺哪些 span 與屬性才能做上面這些事。區分
   「OTel GenAI convention 有標準名稱的」與「我得自訂命名空間的」，並提醒哪些
   屬性是 Opt-In、不該預設開啟。
 
5. 判斷我該不該上 LLM-as-judge：用我的人標預算對照 Cohen's kappa 的校準需求。
   如果該上，給我 rubric 骨架並指出我的軌跡長度會不會觸發位置偏誤、需不需要分段評分。
   如果不該上，直接說並給替代方案。
 
6. 把上面的東西分成「進 CI 的確定性斷言」與「進 nightly 的統計性指標」兩堆，
   說明各自的觸發條件與警戒線怎麼設，以及非決定性會讓哪些項目 flaky。
 
最後排優先順序，每項標「預估效益／實作成本／怎麼驗證」。
並且明確告訴我：以我的規模，有沒有哪一項其實不值得做。