Skip to content

如何評估多智慧體系統

評估多智慧體 LLM 系統的實用指南：把失敗歸因到負有責任的智慧體和交接、審查互動圖，以及為每個智慧體和整個團隊打分。

一個多智慧體系統是若干個 LLM 智慧體（規劃者、編碼者、審查者等）協作完成同一項任務。評估它不只是為最終答案打分，因為真正重要的失敗發生在智慧體之間：交接處丟掉的某個約束、錯誤的智慧體接管了任務、一個從不驗證自身工作的團隊。有用的判斷單元是哪個智慧體、哪一步、哪次交接。 Potato 是一款用於對多智慧體執行進行人工評估的開源工具，為團隊結構提供了一組專門構建的標註介面。

這裡的多智慧體系統指的是一個由 LLM 驅動的工作流，其中各自有角色的智慧體交換訊息並交接控制權。關於這些系統為何失敗的研究（MAST 分類體系，Why Do Multi-Agent LLM Systems Fail?）發現，相當大一部分失敗是智慧體間的：規範問題、智慧體之間的失配，以及缺失驗證。一段扁平的對話記錄恰恰會把這些隱藏起來。

為什麼單智慧體評估還不夠？

當你評估一個智慧體時，你判斷的是單一序列的思考、工具呼叫和觀察。一個團隊會增加只存在於智慧體之間的失敗模式：

  • 交接丟失：智慧體 A 知道一個約束，而智慧體 B 從未收到它。
  • 錯誤歸因：執行失敗了，但負有責任的智慧體處在錯誤浮現位置的上游。
  • 協調失敗：每個智慧體單獨看都很稱職，團隊卻迴圈、停滯，或從不驗證。
  • 資源爭用：兩個智慧體同時觸及同一個工具或檔案並死鎖。

只為最終輸出打分只能告訴你團隊失敗了，而不是失敗發生在哪裡。歸因才是讓資料對除錯或訓練有用的關鍵。

我如何歸因一次多智慧體失敗？

失敗歸因文獻（Zhang 等人，Which Agent Causes Task Failures and When?，ICML 2025）將標籤構建為一個三元組：負有責任的智慧體、決定性步驟和一個原因。在 Potato 中，failure_attribution schema 由軌跡本身填充智慧體和步驟選擇器，因此標註者從實際發生過的智慧體和步驟中進行選擇：

yaml
annotation_schemes:
  - annotation_type: radio
    name: outcome
    description: "Did the system succeed?"
    labels: [success, failure]
  - annotation_type: failure_attribution
    name: attribution
    description: "If it failed: which agent, which step, and why?"
    steps_key: steps
    agent_key: agent

將結果 schema 與歸因搭配，意味著這個三元組只在實際失敗的執行上收集。

我如何審查團隊結構，而不只是對話記錄？

兩個介面讓結構可見。互動圖把智慧體渲染為節點、把交接渲染為邊，標註者標記關鍵路徑並標出有問題的邊。交接審查把每一次控制權轉移都變成一張卡片，用以標記失配並評定品質：

yaml
annotation_schemes:
  - annotation_type: handoff_review
    name: handoffs
    description: "For each handoff: flag any misalignment and rate the quality."
    steps_key: steps
    agent_key: agent
    flags: [info_loss, dropped_constraint, garbling, goal_drift]
    quality_scale: 5

在打分方面，agent_scorecard 在角色忠實度、貢獻度和協調性上為每個智慧體評分，並在團隊自身的維度上為團隊打分，這樣一個處在協調糟糕的團隊中的強勢個體智慧體就會在數字中顯現出來。

我該使用哪種方法？

  • 除錯一條流水線：從互動圖和失敗歸因入手，定位執行在哪裡崩潰。
  • 對比編排模式：加入評分卡，在相同任務上為順序型 vs. 層級型 vs. 群聊型設計打分。
  • 構建訓練或獎勵資料：在步驟粒度上用 MAST 模式標記失敗（通過 trajectory_eval），使標籤附著到行動智慧體和步驟上。
  • 併發缺陷：用工具爭用時間線捕捉對話記錄無法顯示的死鎖和競態。

像對待任何主觀標籤那樣衡量歸因上的一致性；參見標註者間一致性。

延伸閱讀