멀티턴 LLM 평가: 지표 5개, 프레임워크 3종, 워크플로우 1개

멀티턴 LLM 평가: 지표 5개, 프레임워크 3종, 워크플로우 1개

멀티턴 LLM 평가는 '8번째 턴 건망증 버그'를 잡아내는 유일한 방법입니다. 사용자가 3번째 턴에서 주문 번호를 알려줬는데, 봇이 그걸 다시 묻는 상황이죠. 개별 턴은 모두 통과했는데 대화 전체는 실패한 겁니다. DeepEval 4.0과 RAGAS 0.4가 정확히 이 문제를 위해 전용 대화형 평가 API를 내놓았습니다. Techsy의 자체 파이프라인에서 두 차례 평가 인시던트를 겪은 뒤, 저희가 정리한 지표 5개, 프레임워크 3종, 그리고 시작용 워크플로우 1개를 소개합니다.

핵심 요약

• 멀티턴 평가는 고립된 입력-출력 쌍이 아니라 대화 전체를 채점합니다.
• 단일 턴 벤치마크 선두 모델도 대화 턴을 거듭하면 측정 가능할 정도로 성능이 떨어집니다.
• 지표 4개로 시작하세요: 완전성, 지식 유지, 역할 준수, 턴 관련성.
• DeepEval, RAGAS, Langfuse는 멀티턴 평가를 서로 다르게 해결합니다. 아래 프레임워크 표에서 비교했습니다.

왜 단일 턴 점수는 당신을 속이는가?

단일 턴 평가는 한 번에 입력-출력 쌍 하나만 채점하므로, 턴을 거듭해야 드러나는 실패를 보지 못합니다: 망각, 모순, 표류. 모델이 벤치마크에서 높은 점수를 받아놓고도 실제 대화에서는 맥락을 놓칠 수 있습니다. Laban et al.은 LLMs Get Lost In Multi-Turn Conversation(인용 353회)에서 이를 문서화했습니다: 단일 턴 결과가 아무리 건강해 보여도 멀티턴 환경에서는 성능이 떨어진다는 것입니다.

핵심 문제는 비결정성입니다: n번째 응답은 그 앞의 n-1개 턴 전체에 의존하므로, 동일한 프롬프트도 히스토리에 따라 다르게 동작합니다. 고립된 쌍으로만 구성된 데이터셋은 이런 의존성을 결코 검증하지 못합니다. 약 250개 자료를 대상으로 한 PRISMA 체계적 리뷰인 arXiv 서베이 Evaluating LLM-based Agents for Multi-Turn Conversations는 이 분야를 '무엇을 평가할 것인가'(컨텍스트 관리, 계획, 일관성)와 '어떻게 평가할 것인가'(지표, LLM 저지, 사람 검토)로 나눕니다. 단일 턴 스위트에는 이 두 축이 모두 없습니다.

그렇다고 단일 턴 스택이 쓸모없어지는 건 아닙니다. BLEU, ROUGE, G-Eval 같은 단일 턴 지표를 쓰고 있다면, 그것들이 잘 재는 항목에는 그대로 두세요: 형식 준수, 유해성, 고정 프롬프트에 대한 사실 회수. 다만 사용자가 실제로 만나는 대화의 건강 검진으로 읽는 건 그만두세요.

이 연구들에 대한 저희의 한 줄 해석입니다:

단일 턴 평가는 답변을 재고, 멀티턴 평가는 대화를 잰다. 1번째 턴을 완벽하게 넘긴 모델도 5번째 턴이면 길을 잃을 수 있다.

멀티턴 LLM 평가란? 두 가지 평가 모드

멀티턴 LLM 평가는 고립된 프롬프트-응답 쌍 대신 대화 전체, 또는 그 안의 윈도우를 채점하는 방법입니다. 모델이 컨텍스트를 유지했는지, 역할을 지켰는지, 턴을 거쳐 사용자의 문제를 해결했는지를 묻습니다. 두 가지 모드가 이 일을 합니다: 대화 수준 스코어링과 슬라이딩 윈도우 턴 수준 스코어링. 대부분의 팀은 둘 다 돌립니다.

대화 수준 스코어링은 저지에게 전체 대화 기록을 넘기고 질문 하나를 던집니다: 이 대화는 성공했는가? 조기 종료와 미해결 루프를 잡아냅니다. 사용자가 끝내 환불을 받지 못했다는 사실은 스레드 전체를 봐야만 드러나기 때문입니다. 약점은 세분성입니다: 12턴 스레드에서 "실패"라는 결과는 어디서 깨졌는지를 말해주지 않습니다.

슬라이딩 윈도우 턴 수준 스코어링은 N개 턴짜리 윈도우를 대화 기록 위에서 움직이며 윈도우마다 판정 하나를 내립니다. 10턴 대화에 윈도우 3을 쓰면 판정 8개가 대화의 특정 영역에 묶여 나오므로, "실패"에 좌표가 붙습니다: 6~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?

대화 수준 판정: 실패. 6개 윈도우 중 5개가 통과했는데도, 스레드는 지식 유지에서 깨졌습니다. 바로 단일 턴 스위트가 결코 드러내지 못하는 그 실패입니다.

어떤 멀티턴 지표가 중요한가? 진짜 중요한 5가지

먼저 지표 4개를 돌리세요: 대화 완전성, 지식 유지, 역할 준수, 턴 관련성. 그리고 다섯 번째로 커스텀 기준(DeepEval의 G-Eval, RAGAS의 AspectCritic)을 더해, 당신의 제품이 절대 틀리면 안 되는 부분을 맡기세요. 처음 4개는 프로젝트 사이에 이식할 수 있고, 다섯 번째에 바로 당신의 실패 모드가 삽니다.

1. 대화 완전성. 사용자의 목표가 해결되었는가, 아니면 봇이 일찍 승리를 선언했는가? 조기 종료 탐지기입니다.
2. 지식 유지. 모델이 스레드 앞에서 언급된 사실을 기억하는가? 8번째 턴 건망증 버그가 바로 지식 유지 실패입니다.
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 vs RAGAS vs 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은 1급 대화 시뮬레이터를 가진 유일한 프레임워크입니다: 시나리오와 페르소나를 기술하면, 그것이 사용자가 되어 당신의 봇과 대화합니다. 그 멀티턴 가이드는 '쌍이 아닌 시나리오' 패턴의 정준 참고 자료입니다. 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는 이미 가지고 있는 대화에서 출발해 측면별로 채점합니다. 그 멀티턴 how-to는 수동 오류 분석과 짝을 이룹니다: 실패한 대화를 읽고, 실패 모드마다 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-06-13, 재배포 버그가 새로운 지역화 slug를 만들어 내며 라이브 문서 54개의 중복을 출고했습니다. 2026-07-05에 발견해 비공개 처리했죠 (백업: techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). 수정은 더 똑똑한 모델이 아니었습니다. 결정적인 사전 배포 체크였죠: 어떤 생성이든 그전에 canonical 게시물과 언어로 기존 문서를 먼저 해석하는 것. 이진 게이트였습니다.

두 번째 인시던트: 번역 LLM이 가끔 Unicode 대신 ASCII를 출력해 "karşılaştırma"가 "karsilastirma"가 됩니다. 저지는 필요 없습니다. grep 게이트가 잡아냅니다:

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

둘 다 1센트의 일부 비용에, 왜 실패했는지를 정확히 출력하는 체크에 잡혔습니다. 이를 멀티턴 평가에 대응시켜 보면: "봇이 사용자가 이미 준 필드를 다시 물었는가?"는 대화 기록에 대한 문자열 매칭이지, 저지 호출이 아닙니다. 저렴한 결정적 게이트를 먼저 돌리세요. 비싼 저지가 실행되기도 전에 추한 실패를 잡아냅니다.

LLM 저지가 실제로 맞는 도구일 때

저지는 규칙으로 환원할 수 없는 기준에 그 토큰 비용을 씁니다: "어조가 적절히 사과조였는가?", "해결책이 상황에 맞았는가?" 단언문을 쓸 수 있다면, 단언문을 쓰세요. 판단으로 가득한 루브릭이 저지의 영역입니다.

우리가 계속 돌아오는 기준선:

팀원에게 설명할 수 있는 이진 통과/실패 체크로 시작하고, 규칙으로 환원할 수 없는 것에만 LLM 저지를 더하라.

대화는 어떻게 대규모로 시뮬레이션하고, 저지 비용은 얼마인가?

시나리오에서 시뮬레이션하세요. 내보낸 로그에서가 아니라. 시나리오는 일어날 수 있는 것을 테스트합니다. 로그는 현재 시스템이 이미 허용한 것만 보여줍니다. DeepEval의 가이드는 과거 대화가 그것을 만든 시스템에 의해 형성되었으므로, 그것들을 상대로 벤치마크하면 현상 유지가 굳어진다고 경고합니다.

대화 기록이 아니라 시나리오

각 시나리오는 목표와 페르소나로 쓰세요: "파손된 주문을 반품하는 조급한 고객", "예약 도중 마음을 바꾸는 사용자". 최대 턴 제한(10이 적당)과 정지 조건을 설정하세요: 목표 달성, 사용자 이탈, 또는 상한. DeepEval은 주요 유스케이스, 엣지 케이스, 실패가 잦은 상황을 아우르는 다양한 시나리오를 최소 20개 권합니다. 그 이하면, 당신의 스위트는 일화를 재는 셈입니다.

적대적 페르소나

봇을 부수려 드는 페르소나도 포함하세요: 에스컬레이션하는 화난 사용자, 자기모순에 빠진 혼란한 사용자, 4번째 턴에 지시를 끼워 넣는 인젝션 사용자. 멀티턴 인젝션은 그 자체로 하나의 영역입니다. 저희 LLM 가드레일 가이드가 이 테스트와 짝을 이루는 방어 레이어를 다루고, Langfuse의 시뮬레이션 cookbook이 사용자 시뮬레이터 루프를 보여줍니다.

평가된 대화 100개의 비용

아래 수치는 모두 공개된 토큰 수와 가격으로부터의 추정치이며, 우리가 실측한 값이 아닙니다. 요점은 산술 자체입니다: 당신 숫자로 바꿔 넣으세요.

완전히 저지된 대화 100개에 1달러 미만. 더 비싼 저지는 이 숫자를 10~50배 움직이고, 저희 LLM API 비용 절감 가이드의 전술이 적용됩니다: 기준 텍스트 캐싱, 윈도우 배치 처리, 이진 게이트에는 저렴한 모델 사용.

6단계 멀티턴 평가 워크플로우

이 루프는 이렇게 돕니다: 실제 실패에서 시나리오를 정의하고, 핵심 지표 4개에 커스텀 1개를 고르고, 시나리오를 최소 20개 시뮬레이션하고, 현재 버전의 기준선을 잡고, CI에서 리그레이션을 게이트하고, 프로덕션 실패를 시나리오 세트에 다시 넣습니다.

1. 실패에서 시나리오를 정의한다. 대화 기록 20~30개를 읽습니다 (또는 출시 전이라면 고객지원 티켓에서 작성). 각 시나리오는 목표, 페르소나, 최대 턴 상한을 갖습니다. 담당: 당신과 Hamel의 오류 분석 우선 방식.
2. 지표 4개와 커스텀 1개를 고른다. 완전성, 지식 유지, 역할 준수, 턴 관련성, 그리고 당신 도메인의 비싼 실수를 맡을 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개를 기준으로, 우리가 보인 산술 추정은 대화 100개당 약 $0.29입니다. 프리미엄 저지 모델은 이를 10~50배 올립니다.

멀티턴 평가, DeepEval vs RAGAS: 무엇을 골라야 하는가?

내장 대화 시뮬레이터와 함께 오프라인 리그레이션 테스트를 원한다면 DeepEval입니다. 특히 프로덕션 트래픽이 생기기 전에요. 실제 실패한 대화를 읽는 것에서 워크플로우가 시작되어 각 실패 모드를 AspectCritic으로 규칙화한다면 RAGAS입니다. 흔한 분업 하나: CI에는 DeepEval, 프로덕션 로그에는 RAGAS 스타일 저지.

멀티턴 평가 스위트에 시나리오는 몇 개가 필요한가?

최소 20개. 주요 유스케이스, 엣지 케이스, 실패가 잦은 상황을 커버해야 합니다. 이 임계값은 DeepEval의 공개 가이드에서 왔고 우리 경험과도 맞습니다. 20개 미만에서는, 통과율이 우연히 포함된 시나리오에 따라 흔들립니다. 프로덕션 실패를 잡을 때마다 세트를 키우세요.

멀티턴 평가를 CI/CD에서 돌릴 수 있는가?

네. 고정된 시나리오 세트를 저장소에 두고, 프롬프트나 모델 변경마다 돌리고, 기준선 대비 허용 범위를 넘어 리그레이션하는 지표에서 빌드를 실패시키세요. 모델은 비결정적이므로, 정확한 임계값이 아니라 허용 범위(우리는 0.03 사용)를 둔 3회 실행 평균을 비교하세요.

프로덕션의 멀티턴 대화는 어떻게 평가하는가?

트레이스를 대화 스레드별로 그룹화하고, 각 스레드를 비동기로 채점해 평가가 응답을 절대 막지 않게 하고, 실패한 스레드는 검토 큐로 라우팅하세요. 확인된 모든 실패는 오프라인 스위트의 새 시나리오가 되어, 모니터링과 리그레이션 테스트 사이의 루프를 닫습니다.

짧은 버전

• 단일 턴 점수는 대화 실패를 보지 못합니다. 연구는 벤치마크가 건강해도 턴을 거듭하며 성능이 떨어지는 모델을 보여줍니다.
• 대화 수준 스코어링을 게이트로, 슬라이딩 윈도우 스코어링을 깨진 지점 특정에 쓰세요.
• 핵심 지표 4개에 커스텀 기준 1개면 대부분의 챗 제품을 커버합니다. 저지보다 이진 체크가 항상 먼저.
• DeepEval은 시뮬레이션 리그레이션 테스트, RAGAS는 오류 분석 주도 저지, Langfuse는 프로덕션 트레이스.
• 저지 비용은 작습니다 (mini 모델로 대화 100개당 1달러 미만). 비용이 방해가 되는 경우는 거의 없습니다.

더 넓은 툴 지형도는 저희 최고 LLM 평가 도구 라운드업에서 전체 분야를 랭킹했습니다. 그리고 평가 파이프라인을 누군가와 함께 만들고 싶다면, Techsy 팀과 무료 상담을 받아보세요.