多輪 LLM 評估：5 項指標、3 個框架、1 套工作流程

多輪 LLM 評估：5 項指標、3 個框架、1 套工作流程

多輪 LLM 評估是唯一能抓到「第八輪失憶」問題的方法：使用者在第三輪給了訂單編號，機器人到第八輪又問了一次。每一輪單獨看都沒問題，整段對話卻失敗了。DeepEval 4.0 和 RAGAS 0.4 正是為此推出了專門的對話評估 API。在 Techsy 自己的管線經歷了兩次評估事故之後，我們整理出五項指標、三個框架，以及一套可以直接上手的工作流程。

重點摘要

• 多輪評估的對象是整段對話，而非孤立的輸入輸出配對。
• 在單輪基準測試中領先的模型，跨輪表現會明顯衰退。
• 從四項指標起步：完整性、知識保留、角色遵循、輪次相關性。
• DeepEval、RAGAS 和 Langfuse 解決多輪評估的方式各不相同；下方的框架比較表一目了然。

為什麼單輪分數會騙你？

單輪評估一次只評一組輸入輸出配對，因此看不見跨輪才出現的失敗：遺忘、矛盾、漂移。模型可以跑出漂亮的基準分數，卻在即時對話中完全跟不上脈絡。Laban 等人在 LLMs Get Lost In Multi-Turn Conversation 中記錄了這個現象，該論文已被引用 353 次：即使單輪結果看起來健康，多輪場景下的效能仍然會衰退。

核心問題在於非確定性：第 n 輪的回應取決於前 n-1 輪的所有內容，所以相同的提示詞會因為歷史不同而產生不同行為。一組由孤立配對組成的資料集永遠無法驗證這種相依性。arXiv 上的綜述論文 Evaluating LLM-based Agents for Multi-Turn Conversations 是一項 PRISMA 系統性回顧，涵蓋約 250 篇文獻，將這個領域分為「評估什麼」（上下文管理、規劃、連貫性）和「怎麼評估」（指標、LLM 評審、人工審查）。這兩個維度在單輪測試套件中完全缺席。

這並不表示你的單輪測試毫無用處。如果你正在使用 BLEU、ROUGE 和 G-Eval 等單輪指標，繼續保留它們擅長的部分：格式合規、毒性偵測、固定提示詞的事實召回。只是別再把它們當成使用者實際對話的健康指標。

我們對這些研究的一句話解讀：

單輪評估測的是回答，多輪評估測的是對話；第一輪滿分的模型，到第五輪可能就迷路了。

什麼是多輪 LLM 評估？兩種評估模式

多輪 LLM 評估是對整段對話或其中的窗口進行評分，而非評估孤立的提示-回應配對。它要回答的問題是：模型是否保持了上下文、是否維持了角色、是否跨輪解決了使用者的問題。兩種模式承擔這項工作：對話層級評分和滑動窗口逐輪評分，大多數團隊兩者都會跑。

對話層級評分把完整對話紀錄交給評審，只問一個問題：這段對話成功了嗎？它能抓到過早結束和未解決的迴圈，因為只有整段紀錄才能暴露使用者始終沒有拿到退款。它的弱點是粒度不足：一段 12 輪的對話只得到「失敗」，卻不知道問題出在哪裡。

滑動窗口逐輪評分用一個 N 輪的窗口在對話紀錄上滑動，每個窗口給一個判定。在 10 輪對話上使用窗口大小 3，會產生 8 個判定，每個都對應對話的特定區域，所以「失敗」帶有座標：問題出在第六到第八輪。本文頂部的示意圖在同一條對話上展示了兩種模式：一個括號標示對話層級判定，一個滑動框架標示逐窗口判定。

用對話層級評分作為門檻，用窗口評分在門檻觸發時定位失敗位置。DeepEval 的多輪評估指南將工作單元定義為場景而非輸入輸出配對（其 ConversationalGolden 型別）：你測試的是一個情境，而非一個問題。

示意範例（合成資料；展示機制，非真實執行結果）：在一段 8 輪退貨對話上使用窗口大小 3 的滑動窗口。

Turn 1  user:      I want to return an order that arrived damaged.
Turn 2  assistant: Sorry about that. Can you share the order number?
Turn 3  user:      It's #4471.
Turn 4  assistant: Got it. Damaged on arrival, or after use?
Turn 5  user:      On arrival. The screen was cracked.
Turn 6  assistant: Understood. Replacement or refund?
Turn 7  user:      Refund. How long does that take?
Turn 8  assistant: 3-5 business days. Can you share the order number again?

對話層級判定：失敗。六個窗口中五個通過，整段對話仍然在知識保留上崩潰，這正是單輪測試套件永遠不會浮現的失敗。

哪些多輪指標真正重要？這 5 項

先跑四項指標：對話完整性、知識保留、角色遵循、輪次相關性。再加第五項，一個自訂標準（DeepEval 中的 G-Eval，RAGAS 中的 AspectCritic），用來覆蓋你的產品絕對不能出錯的部分。前四項可以跨專案遷移；第五項才是你的失敗模式所在。

1. 對話完整性。 使用者的目標是否被解決，還是機器人過早宣告勝利？這是你偵測過早結束的工具。
2. 知識保留。 模型是否記得對話中先前陳述的事實？第八輪失憶問題就是知識保留失敗。
3. 角色遵循。 助理是否維持在其角色設定內，並拒絕超出範圍的請求？在有合規邊界時至關重要。
4. 輪次相關性。 每一輪回應是否在前文脈絡下切題？用來抓漂移和迴圈。
5. 自訂標準。 一條針對你領域的白話規則：「永遠不要報出與價目表不同的價格。」DeepEval 以 ConversationalGEval 實作；RAGAS 以 AspectCritic 實作。

DeepEval 指標指南為每項指標提供了可執行的類別定義，但概念本身與框架無關：即使你自行打造評審，這張表依然適用。

自訂標準讀起來就像一句話：

criterion "price_accuracy":
  question: Does the assistant quote prices matching the official
            list, and self-correct when the user flags a mismatch?
  scale: 0 (wrong, no correction) to 1 (correct throughout)
  verdict: pass if score >= 0.5

同一條規則用真實 DeepEval 程式碼寫出來：

from deepeval.metrics import ConversationalGEval
from deepeval.test_case import LLMTestCaseParams

price_accuracy = ConversationalGEval(
    name="Price Accuracy",
    criteria=(
        "Does the assistant quote prices that match the official "
        "price list, and correct itself immediately when the user "
        "points out a discrepancy?"
    ),
    evaluation_params=[
        LLMTestCaseParams.INPUT,
        LLMTestCaseParams.ACTUAL_OUTPUT,
    ],
    threshold=0.5,
)

DeepEval、RAGAS、Langfuse：哪個框架適合你？

三者都能評估多輪對話，但評估單元不同：DeepEval 離線模擬場景，RAGAS 對你已有的對話進行面向評分，Langfuse 評估真實生產環境的追蹤記錄。選擇依據是你的對話從哪裡來，而不是功能數量。

先給出與框架無關的邏輯，這樣下方的廠商程式碼才是可移植的：

for scenario in scenario_set:
    transcript = run_chatbot(scenario, max_turns=10)
    for window in sliding_windows(transcript, 3):
        scores.append(judge(window, criteria))
    scores.append(judge(transcript, completeness))
fail_if(mean(scores) < baseline - tolerance)

DeepEval：場景與開箱即用的模擬器

DeepEval 是唯一擁有一等公民對話模擬器的框架：描述一個場景和一個角色設定，它就會扮演使用者來跟你的機器人對話。它的多輪指南是「場景而非配對」模式的標準參考。Confident AI 販售託管儀表板；我們的 Confident AI 評測涵蓋了付費層增加了什麼。

from deepeval.dataset import ConversationalGolden
from deepeval.synthesizer import ConversationSimulator
from deepeval.metrics import (
    ConversationCompletenessMetric,
    KnowledgeRetentionMetric,
)
from deepeval import evaluate

scenario = ConversationalGolden(
    additional_context="Customer wants to return a damaged order",
    user_persona="Impatient customer, second contact this week",
)
simulator = ConversationSimulator(model="gpt-4o-mini", max_turns=10)
test_case = simulator.simulate(scenario, your_chatbot_fn)

evaluate(
    test_cases=[test_case],
    metrics=[
        ConversationCompletenessMetric(threshold=0.7),
        KnowledgeRetentionMetric(threshold=0.7),
    ],
)

RAGAS：以錯誤分析驅動，逐面評分

RAGAS 從你已有的對話出發，逐個面向進行評分。它的多輪操作指南與手動錯誤分析搭配使用：閱讀失敗的對話，為每種失敗模式寫一個 AspectCritic，然後評分。

from ragas.dataset_schema import MultiTurnSample
from ragas.metrics import AspectCritic
from ragas.llms import llm_factory

user_input = [
    {"role": "user", "content": "Can I return a damaged order?"},
    {"role": "assistant", "content": "Yes, within 30 days."},
    {"role": "user", "content": "It arrived broken. Do I pay shipping?"},
    {"role": "assistant", "content": "No, we cover it."},
]
sample = MultiTurnSample(user_input=user_input)

critic = AspectCritic(
    name="policy_consistency",
    definition="Does the assistant stay consistent with the stated return policy across all turns? Answer yes or no.",
    llm=llm_factory("gpt-4o-mini"),
)
score = await critic.multi_turn_ascore(sample)  # binary 0 or 1

Langfuse：對真實追蹤記錄進行 N+1 評估

Langfuse 走的是相反的路線：追蹤器優先。它的 N+1 cookbook評估每一輪的追蹤記錄加上整段對話，對象是生產環境流量而非模擬。如果你還在選擇可觀測性層，我們的 Langfuse vs LangSmith 比較涵蓋了那個決策。

我們的結論，不模稜兩可：新的聊天機器人專案，從 DeepEval 開始。模擬器讓你在沒有生產流量之前就能攔截回歸，而那正是你最需要測試的時候。等真實對話串存在後再加入 Langfuse；當你的團隊偏好閱讀失敗對話並把發現編碼成規則時，再使用 RAGAS。

如何從錯誤分析走向自動化？

按順序來。閱讀 20 到 30 段真實對話，手動標註失敗模式，為顯而易見的問題寫二元通過/失敗檢查，把這些自動化，然後才為需要主觀判斷的殘留部分加入 LLM 評審指標。Hamel Husain 主張的正是這個順序：先做手動錯誤分析和二元決策，因為一個你能解釋的檢查勝過一個你無法解釋的分數。

先二元再評審：救了我們的排序

這不是我們跑的聊天機器人基準測試；而是我們對自身內容管線中相同模式的解讀，該管線在每次提示詞和工具變更時都會跑評估門檻的回歸檢查。兩次事故為我們驗證了這個排序。

2026 年 6 月 13 日，一個重新發佈的 bug 產生了新的本地化 slug，導致 54 份重複的線上文件被推送出去。我們在 2026 年 7 月 5 日發現並下架了它們（備份在 techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json）。修復方法不是更聰明的模型；而是一個確定性的發佈前檢查：在任何建立操作之前，先透過標準文章加語言來解析現有文件。一個二元門檻。

第二次事故：翻譯 LLM 偶爾輸出 ASCII 而非 Unicode，把「karşılaştırma」變成「karsilastirma」。不需要評審；一個 grep 門檻就能抓到：

grep -cP '[çşğüöıİŞÇĞÜÖ]' file.md   # must be > 0

兩者都被成本不到一分錢、而且能精確印出失敗原因的檢查抓住了。把這個對應到多輪評估：「機器人是否重新詢問了使用者已經給過的欄位？」是對對話紀錄的字串比對，不是評審呼叫。先跑便宜的確定性門檻；它們能在昂貴的評審啟動之前就抓住那些難看的失敗。

LLM 評審真正適合的時機

評審的 token 成本花在那些你無法化簡為規則的標準上：「語氣是否適當表達了歉意？」「處理方式是否符合情境？」如果你能寫出一個斷言，就寫斷言。一份充滿主觀判斷的評分表才是評審的領地。

我們反覆回歸的那條線：

先從你能向隊友解釋的二元通過/失敗檢查開始，然後只為無法化簡為規則的部分加入 LLM 評審。

如何大規模模擬對話？評審成本是多少？

從場景模擬，而非從匯出的日誌。場景測試的是「可能發生什麼」；日誌只顯示你目前的系統已經允許了什麼。DeepEval 的指南提醒，歷史對話是由產生它們的系統塑造的，所以針對它們做基準測試會把現狀固化進去。

場景，而非對話紀錄

把每個場景寫成目標加角色設定：「不耐煩的客戶要退一件損壞的訂單」、「在預訂中途改變主意的使用者」。設定最大輪數上限（10 輪是合理的）和停止條件：目標達成、使用者放棄、或到達上限。DeepEval 建議至少準備 20 個多樣化場景，涵蓋主要使用情境、邊緣情境和容易失敗的情境；低於這個數量，你的測試套件只是在測量軼事。

對抗性角色設定

加入試圖打破機器人的角色設定：一個升級投訴的憤怒使用者、一個自相矛盾的困惑使用者、一個在第四輪偷偷植入指令的注入攻擊使用者。多輪注入本身就是一門學問；我們的 LLM 護欄指南涵蓋了與這些測試搭配的防禦層，Langfuse 的模擬 cookbook展示了使用者模擬器迴圈。

評估 100 段對話的成本

以下每個數字都是根據公開的 token 數量和定價估算的，不是我們實際測量的結果。重點是算術本身：換成你自己的數字。

不到一美元就能完整評估 100 段對話。換用更貴的評審模型會讓成本增加 10 到 50 倍，而我們降低 LLM API 成本指南中的策略同樣適用：快取標準文字、批次處理窗口、用便宜模型跑二元門檻。

6 步多輪評估工作流程

這個迴圈這樣跑：從真實失敗中定義場景，挑選四項核心指標加一項自訂指標，模擬至少 20 個場景，為目前版本建立基準線，在 CI 中攔截回歸，並把生產環境的失敗回饋到場景集中。

1. 從失敗中定義場景。 閱讀 20 到 30 段對話紀錄（或者，在產品上線前，從客服工單中撰寫）。每個場景都要有目標、角色設定和最大輪數上限。負責人：你和 Hamel 的錯誤分析優先方法。
2. 挑選四項指標，一項自訂。 完整性、知識保留、角色遵循、輪次相關性，再加一個 ConversationalGEval 或 AspectCritic 來覆蓋你領域中代價最高的錯誤。
3. 模擬。 跑至少 20 個場景，包含對抗性場景集。負責人：DeepEval 的 ConversationSimulator，或 Langfuse 的模擬 cookbook。
4. 為目前版本建立基準線。 記錄每項指標在 3 次執行中的平均值，因為模型是非確定性的，單次執行只是雜訊。負責人：你的評估腳本，結果提交到儲存庫。
5. 在 CI 中攔截回歸。 為每項指標設定門檻，當回歸超過容許範圍時讓建置失敗：

# ci/multi-turn-eval-gate.sh
set -euo pipefail
python eval/run_multi_turn.py --scenarios eval/scenarios.yaml --out results.json
SCORE=$(jq -r '.aggregate.completeness' results.json)
BASELINE=0.82
TOLERANCE=0.03
if (( $(echo "$SCORE < $BASELINE - $TOLERANCE" | bc -l) )); then
  echo "FAIL: completeness $SCORE below baseline $BASELINE"
  exit 1
fi

1. 監控生產環境的對話串。 按對話串分組即時追蹤記錄，非同步評估，並把每一段失敗的對話串轉化為新場景。負責人：Langfuse 或你的追蹤器；我們關於在生產環境評估 AI 代理和 AI 可觀測性的指南涵蓋了監控這一半。

這套測試永遠不會完成：第 6 步回饋到第 1 步，場景集會隨著你抓到的每一次生產失敗而成長。

如何跨語言評估語氣？

一個在英文資料上調校過的角色遵循指標，會讓母語人士覺得粗魯的土耳其文或日文對話紀錄通過，因為禮貌語域是語言特定的。你的英文評分表裡沒有對應的詞。修復方法：針對每個語域期望寫一個面向標準，每種語言各寫一份，而非一個全域語氣指標。

每個語域一個標準

這是我們對 RAGAS AspectCritic 模式的解讀，延伸自經營一條 23 種語言管線的經驗，而非已發表的測試結果：

English:  "Is the assistant's tone friendly but professional?"
Turkish:  "Does the assistant use formal 'siz' address consistently,
           and avoid casual verb forms with an upset customer?"
Japanese: "Does the assistant keep keigo (polite form) throughout,
           including the apology at the resolution turn?"

每個標準都是同一份對話紀錄上的一個獨立二元評審。我們沒有發表過跨語言語氣分數，也不會信任一篇印出分數卻不附評分表的文章。從管線工作中得到的觀察：失敗集中在道歉和升級輪次，語域在這些地方最先崩潰。

關於作者

Mert Batur 是 Techsy.io 的聯合創辦人，團隊為 B2B 客戶打造 AI 代理、自動化系統和語音/SDR 管線。他撰寫的主題是 Techsy 團隊在生產環境中實際使用的 LLM 工具鏈。資歷：Techsy.io 聯合創辦人。在 LinkedIn 上聯繫。

常見問題

什麼是多輪對話 LLM？

一種第 n 輪回應取決於所有先前輪次、而非僅取決於最新提示詞的語言模型。它以整段對話為條件，因此行為會隨對話歷史而改變。這種上下文相依性正是單輪測試無法驗證、而多輪評估存在就是为了評分的部分。

LLM 評估是什麼意思？

自動且可重複地根據定義好的標準來衡量輸出品質，而不是憑感覺。單輪評估根據 BLEU 或 LLM 評審等指標對孤立的提示-回應配對評分。多輪評估將此擴展到整段對話，跨輪評分上下文保留和目標完成度，而非逐提示詞評分。

如何對多輪 LLM 效能做基準測試？

建立至少 20 個帶有目標和角色設定的場景，對模型進行模擬，並用對話層級指標加上滑動窗口檢查來評分。在多次執行中記錄基準線以吸收非確定性，然後在 CI 中將每個新版本與基準線比較。生產環境的追蹤記錄會在之後擴展基準。

評估 LLM 的最佳方式是什麼？

按順序來：先做手動錯誤分析，然後為所有能化簡為規則的部分建立二元通過/失敗門檻，最後才用 LLM-as-a-judge 處理語氣和處理品質等主觀標準。二元檢查更便宜、可除錯、不會漂移；評審屬於那些真正需要判斷的標準，在便宜的門檻通過之後才上場。

我應該從哪些多輪評估指標開始？

對話完整性、輪次相關性和知識保留；它們能抓到任何聊天產品中最常見的失敗（未解決的目標、漂移、遺忘）。如果你的機器人有合規邊界，加入角色遵循，然後再加一個自訂 G-Eval 或 AspectCritic 標準來覆蓋你的業務承受不起的錯誤。

LLM-as-a-judge 每段對話的成本是多少？

在 10 輪上使用窗口大小 5 的滑動窗口加一次對話層級呼叫，每段對話需要 7 次評審呼叫。以 GPT-4o-mini 每次呼叫約 2,000 輸入 token 計算，我們展示的算術估算得出每 100 段對話約 $0.29。高階評審模型會讓這個數字增加 10 到 50 倍。

多輪評估選 DeepEval 還是 RAGAS？

如果你想要帶有內建對話模擬器的離線回歸測試，特別是在還沒有生產流量的時候，選 DeepEval。如果你的工作流程從閱讀真實失敗對話開始，並把每種失敗模式編碼成 AspectCritic，選 RAGAS。一種常見的分工：CI 中用 DeepEval，生產日誌上用 RAGAS 風格的評審。

多輪評估套件需要多少個場景？

至少 20 個，涵蓋主要使用情境、邊緣情境和容易失敗的情境；這個門檻來自 DeepEval 的公開指南，也與我們的經驗一致。低於 20 個時，通過率會隨著恰好被納入的場景而擺動。每抓到一次生產失敗就擴展場景集。

可以在 CI/CD 中跑多輪評估嗎？

可以。在儲存庫中維護一組固定的場景集，在每次提示詞或模型變更時執行，當某項指標相對於基準線的回歸超過容許範圍時讓建置失敗。因為模型是非確定性的，比較 3 次執行的平均值並使用容許範圍（我們用 0.03），而非精確門檻。

如何在生產環境中評估多輪對話？

按對話串分組追蹤記錄，非同步為每段對話串評分，讓評估永遠不阻塞回應，並將失敗的對話串路由到審查佇列。每一個確認的失敗都會成為離線套件中的新場景，閉合監控與回歸測試之間的迴圈。

精簡版

• 單輪分數看不見對話失敗；研究顯示模型在基準健康的情況下仍然跨輪衰退。
• 用對話層級評分作為門檻，用滑動窗口評分來定位斷裂點。
• 四項核心指標加一項自訂標準涵蓋大多數聊天產品；永遠先二元檢查再評審。
• DeepEval 用於模擬回歸測試，RAGAS 用於錯誤分析驅動的評審，Langfuse 用於生產環境追蹤。
• 評審成本很低（mini 模型每 100 段對話不到一美元）；成本很少是阻礙。

關於更廣泛的工具版圖，我們在最佳 LLM 評估工具評比中排名了整個領域。如果你更想和團隊一起建構評估管線，可以預約免費諮詢，與 Techsy 團隊聊聊。