EVAL RUN · 評估報告 回到執行

#279 兩項目評估報告

auto-db283a46-r1-053959587 production-baseline 產製於 05月16日 14:50

I. VITAL SIGNS

各項目健康度概覽

項目二: 情境調用與完成 (10 cases)

各維度品質分 · 覆蓋率
走對流程 召回
scenario
100.0%
[100.0% – 100.0%] · n=10
F1 100.0% · 召回 100.0% · 精確 100.0%
10 / 10 適用
用對工具 召回
tool_usage
100.0%
[100.0% – 100.0%] · n=10
F1 100.0% · 召回 100.0% · 精確 100.0%
10 / 10 適用
答得到位 平均
answer_quality
33.0%
[23.3% – 43.0%] · n=10
10 / 10 適用
II. RUN ECONOMICS

本次 Run 的 LLM 成本概覽

Judge 總成本（USD） $0.0068 19 次 judge 呼叫
Judge 總 Token 數 56,860 輸入 53,352 · 輸出 3,508
LLM 成本來源追蹤狀態
來源 追蹤狀態 數值 備註
Eris Case Generator 已追蹤 $0.0231
170,040 tokens · 106 calls 		案例生成階段 LLM 呼叫（sampler / info_held / validator / kb_matcher / response_rules judge）— Round 8 起 CostTracker 自動寫入 EvalCaseGeneration 對應欄位
Eris LLM Judge 已追蹤 $0.0068
56,860 tokens 		EvalJudgement 表記錄真實 OpenAI usage（faithfulness / answer_quality / retrieval_relevance 三類 judge）
Neptune Bot Inference 受阻 — Neptune unified_llm.tool_calling_stream streaming 模式下 final chunk 未帶 usage（OpenAI stream_options.include_usage 未啟用），導致 metadata.usage 全 0。Eris 端無法從 chat response 重建。Fix 在 Neptune team 的 tracking ticket 內。
UserSimulator 尚未實作 — UserSimulator multi-turn LLM 呼叫目前 Eris 沒寫追蹤；這部分要新增 service + 在 simulator client 裡寫入 token 紀錄
Judge 次數 Input Output Cost
忠實度（faithfulness） 7 10,627 754 $0.0015
回答品質（answer_quality） 12 42,725 2,754 $0.0053
檢索相關性（retrieval_relevance） 0 0 0 $0.0000
III. ACTIONABLE FINDINGS

優先處理項目

依「最低分 sub-metric」排序的 worst-3 case，標示出此 run 中最該優先檢視的 scenario × 維度組合。每筆同時列出實際觸發低分的 sub-metric 名稱，方便定位是 KB 漏洞、工具排序問題、還是規則違反。

  1. 01
    知識與產品查詢 回答品質
    33.0% n=11 最低 sub_metric： critical_coverage
  2. 02
    知識與產品查詢 忠實度
    50.0% n=6 最低 sub_metric： rule_compliance
  3. 03
    知識與產品查詢 情境
    100.0% n=11 最低 sub_metric： scenario_precision
IV. DEEP DIVE

全段詳細數據

兩項目評估報告

  • EvalRun: #279（suite #127 auto-db283a46-r1-053959587）
  • Target: #1 production-baseline
  • Cases: 12（N=1, attempts=12/12）
  • Generated: 2026-05-16T14:50:29+08:00

本報告含兩個獨立評估項目。項目一 評估 bot 進入「知識與產品查詢」fallback 後的撈取 + 回答能力；項目二 評估 bot 跨全 enabled scenarios 的 routing → tool → answer 三段 funnel 健康度。

項目一: 知識庫精準度

評估範圍 (prerequisite: 進對 scenario)

  • 進對 scenario 的 attempts: 12 / 12 (100.0%)
  • 只對這些 attempts 算 retrieval + answer
  • 沒進對 scenario 的 attempts → 排除（routing 失敗不該污染 KB 訊號）

Per-scenario 評估

Scenario qualifying / total attempts retrieval_relevance answer_correctness
知識與產品查詢 11 / 11 ❌ 0.0% —
轉接真人客服 1 / 1 ❌ 0.0% —

待修方向（worst-3）

  1. 知識與產品查詢 × retrieval_relevance = 0.0% — bot 進對 scenario 但沒呼叫 search tool — 流程 / prompt 問題（不是 KB content gap）
  2. 轉接真人客服 × retrieval_relevance = 0.0% — bot 進對 scenario 但沒呼叫 search tool — 流程 / prompt 問題（不是 KB content gap）

項目二: 情境調用與完成

整體 funnel（全 scenarios 加總）

Stage Pass count % of total
Total attempts 12 100.0%
Step 1: scenario_routing 12 100.0%
Step 2: + tool_calling 12 100.0%
Step 3: + answer 1 8.3%

Per-scenario funnel

Scenario (n_attempts) Step 1 (routing) Step 2 (tool) Step 3 (answer) end-to-end
知識與產品查詢 (11) ✅ 11/11 (100.0%) ✅ 11/11 (100.0%) ❌ 0/11 (0.0%) ❌ 0/11 (0.0%)
轉接真人客服 (1) ✅ 1/1 (100.0%) ✅ 1/1 (100.0%) ✅ 1/1 (100.0%) ✅ 1/1 (100.0%)

Drop-off 最大的 5 個 scenario

  1. 知識與產品查詢 drop at step3 (-100.0pp)
  2. 轉接真人客服 drop at step1 (-0.0pp)

Audit

Reproduce combined report: bin/rails runner "puts Eval::EvaluationReport.call(run: EvalRun.find(279))" Or fetch each item separately:

  • bin/rails runner "puts Eval::KbAccuracyReport.call(run: EvalRun.find(279))"
  • bin/rails runner "puts Eval::ScenarioFunnelReport.call(run: EvalRun.find(279))"

Per-Scenario × Per-Dim — Run #279

Suite: test (bulk R1) · scenarios: 2 · dims: 5 · populated cells: 7/10

Scenario Scenario Tool Retrieval Faith AnsQ
知識與產品查詢 100.0% [100.0–100.0] (n=11) 100.0% [100.0–100.0] (n=11) — 50.0% [16.7–83.3] (n=6) 33.0% [23.3–41.5] (n=11)
轉接真人客服 100.0% (n=1) — — 100.0% (n=1) 100.0% (n=1)

Worst-3 cells (lowest primary score)

  1. 知識與產品查詢 × AnsQ · 33.0% (n=11) · lowest sub_metric: critical_coverage
  2. 知識與產品查詢 × Faith · 50.0% (n=6) · lowest sub_metric: rule_compliance
  3. 知識與產品查詢 × Scenario · 100.0% (n=11) · lowest sub_metric: scenario_precision