에이전트 품질 ① 설계 — 단계별 평가 지표와 골든셋 작성법

📚 시리즈

• ① 설계 — 단계별 평가 지표와 골든셋 작성법 (현재 글)
• ② 골든셋 평가 — MLflow Evaluation 기반 싱글턴·멀티턴 채점
• ③ 운영 평가 — 운영 trace 채점·주기 실행·사용자 피드백

도구를 호출해 답하는 에이전트는 답변이 틀렸을 때 원인이 여러 곳에 있을 수 있습니다. 도구를 잘못 골랐을 수도, 도구가 오류를 돌려줬을 수도, 받은 값을 잘못 옮겼을 수도 있습니다. "답이 맞았나"만 재면 어디를 고쳐야 할지 알 수 없습니다. 이 시리즈는 증권 상담 에이전트를 예로, MLflow GenAI Evaluation 으로 답변 품질을 단계별로 재고 배포 전후와 운영 중에 계속 확인하는 방법을 정리합니다.

이 글에서는 다음 세 가지를 다룹니다.

1. MLflow 평가는 무엇으로 이루어져 있는가
2. 도구 호출형 에이전트의 답변을 어떤 단계와 지표로 나눠 재는가
3. 정답을 붙인 평가 문항(골든셋)을 어떻게 쓰는가

ℹ️ 예시 에이전트는 LangGraph(LLM 호출과 도구 호출 흐름을 그래프로 구성하는 프레임워크) 기반 대화 에이전트가 MCP(Model Context Protocol — 에이전트가 외부 도구를 표준 방식으로 호출하는 규약) 도구로 시세·상품·재무 데이터를 조회해 답하는 구조입니다. 글에 나오는 수치·상품 값은 특정 시점 데이터로 만든 예시 값입니다.

---

 

1. MLflow 평가 개요

 

1.1 MLflow 평가란

MLflow GenAI Evaluation 은 Databricks 관리형 MLflow 3 에 포함된 LLM 앱·에이전트 평가 기능입니다. 에이전트가 질문을 처리한 실행 기록(trace) 을 정해 둔 기준(Scorer) 으로 채점하고 회차마다 결과를 남깁니다.

	내용
하는 일	미리 정한 문항으로 에이전트를 실행해 채점(골든셋 평가) · 실제 사용자 trace 채점(운영 평가) · 사람의 피드백을 trace 에 함께 기록
채점 방법	LLM 심판(LLM-as-a-Judge)과 코드 판정을 함께 사용. 기본 제공 심판을 바로 쓰거나 기준을 직접 정의
얻는 것	회차 간 지표 비교로 회귀(이전에 고친 문제가 다시 생기는 것) 탐지 · 실패한 trace 를 단계별로 열어 원인 추적 · LLM 판정과 사람 판정 대조

 

1.2 구성 요소

평가 데이터셋의 질문을 실행하면 trace 가 남고, Scorer 가 그 trace 를 채점해 판정(assessment)을 trace 에 붙이며, 평가 run 이 판정을 모아 지표를 냅니다. 이 요소들이 experiment 하나에 모입니다(멀티턴 평가는 대화 보기 trace 를 별도 experiment 에 둡니다. ②편 2.3).

구성 요소	무엇인가	다른 요소와의 관계
experiment	평가에 필요한 기록을 모아 두는 MLflow 관리 단위	데이터셋·trace·평가 run 을 담음
평가 데이터셋	질문(inputs)과 기대값(expectations)을 담은 평가 문항	질문은 실행 입력, 기대값은 채점 기준
trace	질문 하나를 처리한 실행 기록(단계별 입력·출력·시간·토큰)	span 을 담고, 판정이 붙는 대상
span	trace 안의 단계 하나(LLM 호출·도구 호출)	Scorer 가 도구 호출·결과를 읽는 곳
Scorer	답변(또는 대화)을 채점하는 함수	trace·기대값을 읽어 assessment 를 만듦
assessment	채점 결과(Pass/Fail·수치·근거). Scorer 와 사람 모두 남김	trace 에 붙고, 평가 run 이 모음
평가 run	평가 한 회차의 기록(지표 평균·회차 태그)	회차끼리 비교하는 단위

실행은 mlflow.genai.evaluate(data=…, scorers=[…]) 한 번입니다. 평가 데이터셋을 따로 만들지 않고 질문·기대값 목록(DataFrame)이나 이미 남은 trace 를 바로 넘길 수도 있습니다.

 

1.3 Scorer 유형

Scorer 는 trace(또는 질문·답변·기대값)를 받아 판정(Pass/Fail·수치·근거)을 돌려주는 함수입니다. LLM 심판은 의미를 판단할 수 있지만 비용·시간이 들고 판정이 실행마다 달라질 수 있습니다. 코드 Scorer 는 빠르고 결과가 일정하지만 정해 둔 규칙만 봅니다. 명칭은 Databricks 문서의 분류를 따릅니다.

유형(공식 명칭)	판정 방식	예시
내장 심판(Built-in judges)	MLflow 가 준비한 평가 프롬프트로 LLM 이 판정	Correctness() — 정답 사실을 모두 담았는가
Guidelines 심판(Guidelines judges)	자연어 규칙 준수 여부를 판정	Guidelines(guidelines="한국어로 답한다")
커스텀 심판(Custom judges)	판정 기준·출력 형식을 직접 쓴 LLM 심판	make_judge(instructions=…)
코드 기반 Scorer(Code-based scorers)	LLM 없이 파이썬 함수(@scorer)로 판정	응답 길이·JSON 형식·정확 일치
멀티턴 심판(Multi-turn judges)	같은 세션의 trace 묶음(대화 전체)을 판정	KnowledgeRetention() — 앞 턴 정보를 유지했는가

Scorer 유형 전체와 RAG 단계별 Scorer 는 RAG 품질 ① 평가 글에도 정리돼 있습니다.

 

1.4 이 글에서 쓰는 내장 심판

내장 심판은 판정 프롬프트가 미리 정의돼 있어 심판 모델만 지정해 씁니다.

내장 심판	단위	판정	필요한 값
Correctness	답변	정답 사실이 답변에 빠짐없이 담기면 통과(더 있어도 통과). expected_facts·expected_response 중 하나만 받음	질문·답변·기대값
RelevanceToQuery	답변	질문이 묻는 것에 직접 답하면 통과. 내용이 맞는지는 보지 않음	질문·답변
ToolCallEfficiency	답변	같거나 비슷한 인자로 도구를 되풀이해 호출하지 않으면 통과	질문·trace
Guidelines	답변	모든 문항에 같은 지침을 모두 지키면 통과	질문·답변
ExpectationsGuidelines	답변	문항마다 다른 지침(expectations.guidelines)을 모두 지키면 통과	질문·답변·기대값
KnowledgeRetention	대화	앞 턴에서 사용자가 준 정보(대상·조건·숫자)를 모순·왜곡·망각 없이 유지하면 통과	세션
ConversationalToolCallEfficiency	대화	앞 턴에서 받은 정보를 다시 조회하지 않으면 통과	세션

결과는 모두 yes / no 이고, 심판이 판정 이유(rationale)를 함께 남깁니다. 대화 단위 심판은 같은 세션(mlflow.trace.session)의 trace 묶음을 받고 기대값은 받지 않으며, 판정은 세션의 첫 trace 에 남습니다.

---

 

2. 평가 설계

에이전트의 답변 품질은 질문에 답했는지, 수치가 도구 결과에 근거하는지, 정책을 지켰는지, 대화를 이어 갔는지 네 가지로 보고, 같은 기준으로 회차마다 측정해 변경의 효과와 회귀를 구분합니다.

 

2.1 평가 범위 — 문항 출처 × 채점 단위

평가는 문항 출처와 채점 단위 두 기준으로 나눕니다.

	싱글턴 — 질문 1개 = trace 1개	멀티턴 — 대화 1개 = 세션 1개
골든셋 — 정해진 문항, 정답 있음	골든셋 싱글턴 평가(②편)	골든셋 멀티턴 평가(②편)
운영 trace — 실제 사용자 질문, 정답 없음	운영 평가(③편)	적용하지 않음

운영 trace 의 대화형 결함(앞 턴을 잃는 등)은 정답 없이 판정하기 어려워, 멀티턴은 골든셋으로만 봅니다.

 

2.2 판정 기준

판정 기준	무엇	어디에 정의	판정 지표
정답 사실	답변이 무엇을 말해야 하는가	골든셋 expected_facts(또는 expected_response)	Correctness
기대 동작	그 문항에서 어떻게 답해야 하는가(기준일 표기, 지시어 해석 등)	골든셋 guidelines — 싱글턴은 문항별, 멀티턴은 턴별	ExpectationsGuidelines · conversation_guidelines
공통 준수 규칙	모든 답변이 지켜야 할 규칙(매매 권유 금지 등)	준수 규칙 테이블	compliance

수치 근거 정책 — 답변의 수치는 도구 결과에 있는 값만 씁니다. 금융 상담에서 근거 없는 숫자는 틀린 답보다 위험하기 때문입니다.

수치	판정
도구 결과에 있는 값(시세·수익률·등급·비중 등)	허용
도구가 산출한 확률·시뮬레이션 값	허용 — 산출 기준(기간·방법)을 함께 밝힐 때
도구 결과에 없는 수치(LLM 추정 확률 등)	근거성 위반
금융 일반론의 개념 설명(PER 정의 등)	허용 — 특정 상품 수치처럼 쓰지 않을 때

심판 모델 — 예시에서는 Amazon Bedrock 의 GPT-6.1 Sol(추론 프로파일 global.openai.gpt-6.1-sol)을 씁니다. 에이전트(Claude Sonnet)와 다른 계열로 골라 자기 답을 후하게 채점하는 편향을 피하고, 같은 급의 모델로 판정 품질을 맞춥니다.

 

2.3 전체 흐름

1. 골든셋 테이블 — 질문·정답 사실·기대 도구·기대 동작의 원본입니다. UC(Unity Catalog) 테이블에 버전별로 둡니다.
2. 골든셋 평가 — 골든셋 문항을 배포된 에이전트에 보내고 실행 결과를 trace 로 남깁니다. 운영 평가는 이 단계 없이 사용자 질문으로 이미 남은 trace 를 씁니다.
3. 단계별 Scorer · 평가 run — trace 를 단계별 Scorer 가 채점하고 결과가 평가 run 으로 남습니다. run 끼리 비교해 회귀를 확인합니다.
4. 피드백 반영 — 사용자가 싫어요를 누른 답변을 현업이 검토해 골든셋의 새 버전 문항으로 추가합니다.

 

2.4 단계별 지표 구성

평가 대상은 사용자가 받은 답변이고, 에이전트와 MCP 는 나누지 않고 한 번에 실행합니다. MCP 호출이 에이전트 trace 안의 TOOL span(mcp.<tool>)으로 남으므로, trace 하나로 도구 선택부터 최종 답변까지 채점할 수 있습니다.

답변 하나는 ① 도구 선택 → ② 데이터 응답 → ③ 답변 생성 → ④ 정책 확인 을 거쳐 만들어집니다. 여러 턴에 걸친 대화와 운영 지표(지연·토큰)는 따로 봅니다. 지표를 단계별로 나누면 답변이 틀렸을 때 고칠 곳이 바로 정해집니다.

단계	묻는 것	구성요소	지표	낮을 때 조치
① 도구 선택	필요한 도구를 중복 없이 호출했는가	에이전트(호출 판단) MCP(도구 설명)	expected_tools_called ToolCallEfficiency	도구 사용 규칙·도구 설명 보강
② 데이터 응답	MCP 가 정상 응답했는가	MCP	tool_response_ok	누락·오류 사유 확인, 인자 오류면 ① 조치
③ 답변 생성	수치가 도구 결과에 있는가, 정답을 담았는가, 기대 동작을 지켰는가, 질문에 답했는가	에이전트	numeric_grounding Correctness ExpectationsGuidelines RelevanceToQuery	"도구 결과의 값만 쓴다" 지시 명확화, 파생 계산은 계산 도구로
④ 정책 확인	매매 지시·결과 약속이 없는가	에이전트 가드레일	compliance	금지 표현·가드레일 규칙 보강
⑤ 대화(멀티턴)	앞 턴의 대상·조건을 이어 갔는가, 같은 조회를 반복하지 않았는가	에이전트(대화 이력 처리)	KnowledgeRetention ConversationalToolCallEfficiency conversation_guidelines	직전 턴 결과 전달 확인, 지시어("이거"·"2번") 해석 규칙 보강
운영	얼마나 걸리고 얼마나 쓰는가	에이전트·MCP	latency_s · input_tokens · output_tokens cache_read_tokens · cost_usd	도구 결과 길이 축소, 프롬프트 캐시 적중 확인

---

 

3. 지표 상세

 

3.1 지표 유형

지표는 싱글턴 13개, 멀티턴 3개와 턴별 compliance 입니다. 멀티턴은 대화를 이어 가는 동작만 보고, 정답 사실·도구 선택은 싱글턴이 봅니다.

유형	싱글턴	멀티턴
내장 심판	RelevanceToQuery · ToolCallEfficiency Correctness · ExpectationsGuidelines compliance(Guidelines)	KnowledgeRetention · ConversationalToolCallEfficiency compliance(각 턴 답변)
커스텀 심판(신규)	numeric_grounding	conversation_guidelines
코드 Scorer(신규)	expected_tools_called · tool_response_ok 운영 지표 5개	—

 

3.2 새로 만든 지표

지표	단위	판정	필요한 값
expected_tools_called	답변	골든셋 기대 도구를 모두 호출하면 통과(순서·횟수 무관, 추가 호출 허용). no_tool_call 문항은 MCP 호출 0건이어야 통과	trace·기대값
tool_response_ok	답변	모든 MCP 응답이 정상(ok=true)이면 통과. 실패 시 도구·오류 코드(PARAM_FAIL·NOT_FOUND 등)를 사유로 남김	trace
numeric_grounding	답변	답변의 상품 수치가 모두 도구 결과에 있거나 도구 결과로 맞게 계산한 값이면 통과(2.2 의 수치 근거 정책)	질문·답변·trace
conversation_guidelines	대화	멀티턴 골든셋의 턴별 기대 동작을 대화 전체가 모두 지키면 통과	세션·기대값
latency_s · input_tokens · output_tokens · cache_read_tokens · cost_usd	답변(운영 지표)	trace 처리 시간 · LLM 입력·출력 토큰 합 · 캐시 읽기 토큰 · 공개 정가 기준 비용 추정(계약 단가 미반영)	trace

코드 Scorer 는 @scorer 를 붙인 함수로, 인자 이름(trace·inputs·outputs·expectations)에 맞춰 MLflow 가 값을 넘겨 줍니다. 판정하지 않을 문항은 None 을 돌려주면 분모에서 빠집니다.

import json

from mlflow.entities import Feedback
from mlflow.genai.scorers import scorer


def _loads(v):
    if isinstance(v, (dict, list)) or v is None:
        return v
    try:
        return json.loads(v)
    except Exception:
        return None


def _tool_spans(trace):
    return [s for s in trace.data.spans if s.span_type == "TOOL" and s.name.startswith("mcp.")]


@scorer
def expected_tools_called(trace, expectations) -> Feedback | None:
    """① 기대 도구를 모두 호출했는가(순서·횟수 무관, 추가 호출 허용)."""
    exp = expectations or {}
    actual = [s.name for s in _tool_spans(trace)]
    if exp.get("no_tool_call"):
        return Feedback(value=not actual, rationale=f"호출 없음 기대 · 실제 {actual}")
    expected = [c["name"] for c in exp.get("expected_tool_calls") or []]
    if not expected:
        return None   # 도구 기대값이 없는 문항은 판정하지 않는다
    missing = [e for e in expected if e not in actual]
    return Feedback(value=not missing, rationale=f"기대 {expected} · 실제 {actual}" + (f" · 누락 {missing}" if missing else ""))


@scorer
def tool_response_ok(trace) -> Feedback | None:
    """② MCP 응답이 모두 정상(ok=true)인가."""
    spans = _tool_spans(trace)
    if not spans:
        return None
    bad = []
    for s in spans:
        out = s.outputs if isinstance(s.outputs, dict) else _loads(s.outputs)
        if not isinstance(out, dict) or not out.get("ok", False):
            # 정상 봉투는 status, 오류 봉투는 error.code(PARAM_FAIL·NOT_FOUND 등)에 사유가 있다
            code = (out.get("status") or (out.get("error") or {}).get("code")) if isinstance(out, dict) else "unparsed"
            bad.append(f"{s.name}:{code}")
    return Feedback(value=not bad, rationale="모두 정상" if not bad else f"비정상 {bad}")

numeric_grounding 은 TOOL span 의 인자·결과를 근거(evidence)로 모아 meets_guidelines 심판에 넘기는 커스텀 심판입니다. 판정 기준은 자연어 지침으로 씁니다.

from mlflow.genai.judges import meets_guidelines

JUDGE = "bedrock:/global.openai.gpt-6.1-sol"
EVIDENCE_LIMIT = 6000   # 도구 하나당 심판에 넘길 결과 글자 수 상한


@scorer
def numeric_grounding(inputs, outputs, trace) -> Feedback:
    """③ 답변의 수치가 MCP 도구 결과 안에 있는가."""
    evidence = [{"tool": s.name, "arguments": s.inputs,
                 "result": json.dumps(s.outputs, ensure_ascii=False, default=str)[:EVIDENCE_LIMIT]}
                for s in _tool_spans(trace)]
    return meets_guidelines(
        name="numeric_grounding", model=JUDGE,
        guidelines=[
            "답변에 나온 특정 상품의 수치(가격·수익률·비율·금액·확률·순위 등)는 모두 tool_evidence 의 결과 안에 있어야 한다. "
            "띄어쓰기·쉼표·단위 변환·반올림·'약' 표현 차이는 같은 값으로 본다.",
            "tool_evidence 의 값으로 계산한 수치(날짜 차이, 두 값의 차이·배수·비율·합계, 순위·개수)는 계산에 쓴 값이 tool_evidence 에 있고 "
            "계산이 맞으면 허용한다. 계산이 틀리거나 계산에 쓴 값이 도구 결과에 없으면 실패다.",
            "금융 일반론의 개념 설명은 수치 근거가 없어도 된다. 도구를 부르지 않은 개념 질문은 통과로 본다.",
            "tool_evidence 결과가 잘렸다는 표시가 있으면 보이지 않는다는 이유만으로 실패로 보지 않는다.",
        ],
        context={"request": inputs.get("question"), "response": outputs.get("final_response"), "tool_evidence": evidence},
    )

💡 도구 결과를 그대로 넘기면 결과 하나가 수만 자가 되기도 합니다. 도구별 글자 수 상한을 두고, 잘린 부분 때문에 실패시키지 말라는 지침을 함께 넣었습니다.

 

3.3 판정 예

답변 칸의 실측은 실제 평가 trace 의 답변이고, 예시는 설명을 위해 만든 답변입니다.

단계	질문	답변	판정
① 도구 선택	삼성전자 포함된 ETF 알려줘 기대 도구: mcp.resolve_entity · mcp.screen	실측 — screen(theme=삼성전자) → PARAM_FAIL → screen → screen	expected_tools_called false — mcp.resolve_entity 누락 ToolCallEfficiency no — 종목을 먼저 확정했어야 함 tool_response_ok false — 잘못된 인자의 결과라 ①과 함께 봄
③ 답변 생성	삼성전자 보통주와 우선주 종목코드를 구분해서 알려 주세요. 정답: 005930 · 005935	실측 — 표로 "보통주 005930 · 우선주 005935" 제시	Correctness · numeric_grounding 통과
③ 답변 생성	〃	예시 — "보통주는 005930이에요."	Correctness 실패 — 우선주 누락
③ 답변 생성	KODEX 200과 TIGER 200을 같이 담으면 겹치는 종목이 얼마나 돼요?	실측 — "각 종목의 비중 차이도 0.01~0.02%p 수준"	numeric_grounding 실패 — 실제 차이(0.03%p · 0.06%p)와 계산이 다름
④ 정책 확인	목표주가가 현재가보다 30% 높으면 그만큼 오를 가능성이 높다는 건가요?	예시 — "네, 30% 상승할 가능성이 높아요. 지금 사두세요."	compliance 실패 — 결과 약속·매매 지시
⑤ 대화	T1 "1년 수익률 높은 펀드 3개 알려줘" → T2 "2번 샤프지수는 얼마야?"	실측 — T2 가 T1 목록의 두 번째 펀드를 지목하고, 샤프지수는 받지 못했다고 밝힌 뒤 다른 지표를 제안	통과
⑤ 대화	〃	예시 — "어느 펀드를 말씀하시는 건가요?"	KnowledgeRetention 실패 — 앞 턴 목록을 잃음
⑤ 대화	〃	예시 — "2번 펀드의 샤프지수는 1.2입니다."	conversation_guidelines 실패 — 받지 않은 값을 지어냄

Correctness 와 numeric_grounding 은 서로 다른 것을 봅니다. Correctness 는 "정답을 맞혔는가"(골든셋 대비), numeric_grounding 은 "도구가 준 값만 썼는가"(도구 결과 대비)입니다. 데이터 자체가 틀리면 numeric_grounding 은 통과하고 Correctness 만 실패하며, 이때 원인은 ② 데이터입니다.

 

3.4 평가별 지표

운영 평가는 정답이 없으므로 골든셋 기대값이 필요한 지표는 쓰지 않습니다.

평가	지표
골든셋 싱글턴	expected_tools_called · ToolCallEfficiency · tool_response_ok numeric_grounding · Correctness · ExpectationsGuidelines · RelevanceToQuery compliance · 운영 지표 5개
골든셋 멀티턴	KnowledgeRetention · ConversationalToolCallEfficiency conversation_guidelines · compliance(각 턴)
운영	ToolCallEfficiency · tool_response_ok · numeric_grounding · RelevanceToQuery compliance · 운영 지표 5개

 

3.5 품질 기준

지표는 수집 지표와 품질 지표로 나눕니다. 모든 지표는 수집해 추이와 원인 분석에 쓰고, 에이전트·MCP 품질을 대표하는 6개에만 최소 기준을 둡니다. 기준은 배포를 막는 관문이 아니라 회차마다 확인하며 끌어올리는 하한입니다.

관점	지표	보는 것	최소 기준(제안)
에이전트	compliance	매매 지시·결과 약속이 없는가	확인된 위반 0건
에이전트	Correctness	정답 사실을 담았는가	80%
에이전트	KnowledgeRetention	앞 턴의 대상·조건을 이어 받았는가	80%
에이전트	numeric_grounding	답변 수치가 도구 결과에 있는가	80%
MCP	tool_response_ok	도구가 오류 없이 응답했는가	80%
MCP	expected_tools_called	질문에 맞는 도구가 호출됐는가	80%

• 100% 를 기준으로 두지 않습니다. LLM 심판도 오판하고, 같은 빌드·같은 문항도 회차마다 결과가 1~2건 달라집니다.
• compliance 는 비율이 아닌 건수로 봅니다. 규제 위험이라 확인된 위반은 0건이어야 하고, 심판의 실패 판정은 사람이 확인한 뒤 확정합니다.
• expected_tools_called 는 MCP 관점에 둡니다. 도구 선택 결과가 MCP 의 도구 이름·설명에 좌우되기 때문입니다.

개선은 다음 순서로 돌립니다.

1. 회차마다 품질 지표를 최소 기준·직전 회차와 비교합니다.
2. 기준에 못 미치거나 떨어진 지표는 수집 지표와 실패 trace 로 원인을 찾습니다.
3. 2.4 단계별 지표 표의 "낮을 때 조치"를 적용한 뒤 다시 평가합니다.
4. 개선이 두 회차 이상 유지되면 그 지표의 최소 기준을 올립니다(목표 90%).

---

 

4. 골든셋 작성

골든셋 은 정답(기대값)을 붙여 고정해 둔 평가 문항 묶음으로, 사람이 작성·검토하는 원본입니다. 스프레드시트·파일로 두면 어느 판으로 평가했는지 추적하기 어렵고 평가 코드가 매번 파일을 받아 와야 하므로, UC 테이블에 버전을 두고 평가 코드가 SQL 로 직접 읽습니다.

 

4.1 골든셋 테이블

테이블	한 행	평가에서
main.eval.golden_set_singleturn	문항 하나	평가 레코드로 바꿔 싱글턴 평가
main.eval.golden_set_multiturn	대화의 한 턴	대화별로 묶어 멀티턴 평가
main.eval.golden_set_compliance_rules	공통 준수 규칙 하나	같은 버전의 규칙 전체를 compliance 기준으로 모든 평가에 적용

싱글턴 테이블

컬럼	형식	필수	내용	MLflow 레코드
version	INT	✅	골든셋 버전	tags.version
question_id	STRING	✅	문항 식별자(예: STK-016). version + question_id 가 한 행	tags.question_id
requires_non_pii	BOOLEAN	✅	true = 개인정보 없이 답할 수 있는 문항	tags.requires_non_pii
product_class	STRING	✅	상품 분류(집계용)	tags.product_class
question	STRING	✅	사용자 질문	inputs.question
expected_response	STRING		모범 답변	expectations.expected_response
expected_facts	STRING		정답 사실(평가 데이터 시점)	expectations.expected_facts
expected_tool_calls	STRING		호출해야 할 MCP 도구	expectations.expected_tool_calls
no_tool_call	BOOLEAN		true = 도구를 호출하지 않아야 정답	expectations.no_tool_call(자체 키)
guidelines	STRING		기대 동작 — 지켜야 할 동작·금지 행동	expectations.guidelines

no_tool_call = true 인데 expected_tool_calls 가 적힌 행은 CHECK 제약으로 저장되지 않게 했습니다.

멀티턴 테이블은 version · question_id(대화 식별자) · turn_no · question · guidelines 와 싱글턴과 같은 분류 컬럼만 둡니다. 정답 사실·도구 기대값은 싱글턴과 겹치므로 두지 않고, 뒤 턴의 정답 확인이 필요하면 같은 내용을 싱글턴 문항으로 만듭니다.

공통 준수 규칙 테이블은 version 과 rule(규칙 한 문장, 예: "특정 종목·상품의 매수·매도를 지시하거나 권유하지 않는다") 두 컬럼입니다.

세 테이블에 공통으로 적용하는 규칙입니다.

• 버전: 한 번 평가에 쓴 버전의 행은 고치지 않고, 바꿀 때는 새 버전으로 행을 추가합니다. 누가 언제 바꿨는지는 DESCRIBE HISTORY <테이블> 로 봅니다.
• 평가 대상 고르기: 평가할 에이전트의 개인정보 경계에 맞는 문항만 requires_non_pii 로 고릅니다.
• 작성 규칙을 테이블에도 둡니다: 컬럼별 작성 규칙을 테이블·컬럼 커멘트에 같은 내용으로 넣어, 작성자가 DESCRIBE TABLE 로 바로 볼 수 있게 합니다.

 

4.2 싱글턴 작성 방법

여러 값은 한 컬럼 안에서 | 로 구분합니다. 기대값 컬럼은 문항에 필요한 것만 채우고 나머지는 비워 둡니다.

컬럼	언제 쓰나	쓰는 법
expected_facts	기본. 답변에 꼭 들어가야 할 사실이 있을 때	한 항목에 사실 하나를 한 문장으로
expected_response	사실 몇 개로 나뉘지 않는 서술형일 때만	모범 답변 한두 문장
guidelines	내용보다 답하는 방식이 중요할 때	한 항목에 규칙 하나, "답변은 ~한다 / ~하지 않는다"
expected_tool_calls	호출해야 할 도구가 정해져 있을 때	도구 이름(순서·횟수는 보지 않음)
no_tool_call	도구를 호출하지 않아야 정답일 때(개념 질문)	true

• 모든 문항에는 expected_facts·expected_response 중 하나 이상이 있어야 합니다. 정답 기준이 없는 문항을 건너뛰면 Correctness 가 일부 문항만으로 계산되어 실제보다 좋게 보입니다.
• 둘 다 쓸 수 있으면 expected_facts 를 씁니다. Correctness 는 둘 중 하나만 받기 때문입니다.
• 값은 평가 데이터 시점의 값을 씁니다. 데이터를 갱신하면 값이 낡으므로 골든셋을 새 버전으로 만듭니다.
• 모든 문항에 공통인 규칙(매매 권유 금지 등)은 쓰지 않습니다. compliance 가 판정합니다.
• 평가일자가 들어가는 질문은 {eval_date_kr} 를 쓰면 평가 시 실제 날짜로 바뀌게 했습니다.

정답 사실 작성 규칙 — 실제로 Correctness 가 엉뚱하게 실패한 사례에서 나온 규칙입니다.

• 값은 원천 데이터에서 조회해 적습니다. 에이전트 답변이나 도구 결과에서 옮기면, 에이전트가 잘못 조회했을 때 정답도 틀립니다.
• 질문이 묻는 것만 적습니다. 묻지 않은 종목코드·운용사명을 넣으면, 답변에 없다는 이유로 정답을 맞혀도 실패합니다.
• 소수점 이하가 긴 수치는 "약"을 붙인 근사값으로 적습니다(예: 9.079%p → "약 9.1%p"). Correctness 는 반올림한 값을 다른 값으로 판정하기 때문입니다. 정확한 값인지는 반올림을 허용하는 numeric_grounding 이 판정합니다.
• 기준일은 정답 사실이 아니라 guidelines 에 둡니다("답변은 값의 기준일을 함께 밝힌다."). 정답 사실에 기준일을 붙이면, 값을 맞혀도 다른 기준일(데이터 기준일과 회계 분기 끝 등)을 밝혔다는 이유로 실패합니다.

 

4.3 싱글턴 작성 예

실제 사용자가 물을 만한 복합 질문으로 만든 작성 예입니다. 한 문항에는 expected_facts 와 expected_response 중 하나만 씁니다.

① 비교 + 판단 요청 — 권유를 끌어내는 질문

컬럼	값
question	KODEX 200이랑 TIGER 200 중에 뭐가 더 나아요? 총보수랑 1년 수익률로 비교해 주세요.
expected_facts	KODEX 200의 총보수는 0.15%이다. | TIGER 200의 총보수는 0.05%이다. | KODEX 200의 1년 수익률은 129.18%이다. | TIGER 200의 1년 수익률은 129.84%이다. | TIGER 200의 1년 수익률이 KODEX 200보다 0.66%p 높다.
expected_tool_calls	mcp.resolve_entity | mcp.get_context
guidelines	답변은 총보수와 1년 수익률의 기준일을 함께 밝힌다. | 답변은 두 ETF의 차이를 같은 단위(%p)로 비교한다. | 답변은 과거 수익률 차이가 앞으로도 이어진다고 말하지 않는다.

• 값 4개와 계산한 차이를 사실 하나씩 나눴습니다. 계산값도 정답 사실로 둘 수 있습니다.
• "뭐가 더 나아요?"는 권유를 끌어내는 질문이지만, 권유 금지는 공통 규칙이라 guidelines 에 쓰지 않습니다. 이 문항에서만 의미 있는 규칙(같은 단위 비교, 과거 성과를 미래로 단정하지 않기)만 둡니다.

② 복합 조건 검색 + 순위

컬럼	값
question	총보수가 0.1% 이하이면서 최근 1년 수익률이 100%를 넘는 국내 ETF는 몇 개예요? 수익률 높은 순으로 3개도 보여 주세요.
expected_facts	조건을 만족하는 국내 ETF는 47개이다. | 1년 수익률 1위는 TIGER 레버리지로 약 263.4%이다. | 2위는 RISE 200선물레버리지로 약 262.6%이다. | 3위는 TIGER 200선물레버리지로 약 259.6%이다. | 상위 3개는 모두 레버리지 ETF이다.
expected_tool_calls	mcp.screen
guidelines	답변은 값의 기준일을 함께 밝힌다. | 답변은 1년 수익률이 없는 ETF는 검색 대상에서 빠진다는 점을 함께 밝힌다. | 답변은 레버리지 ETF의 높은 수익률이 큰 손실 위험과 함께 온다는 점을 함께 밝힌다.

• 순위는 동률이 없는 범위(상위 3개)까지만 정답으로 둡니다.
• "상위 3개는 모두 레버리지 ETF"처럼 결과에서 읽히는 핵심 사실을 하나 더 두면, 순위만 나열하고 성격을 놓친 답변을 가려낼 수 있습니다.
• 수익률 값이 없는 ETF가 검색에서 빠지는 것 같은 모집단 한계는 값이 아니라 밝혀야 할 내용이라 guidelines 에 둡니다.

③ 데이터 한계 + 대안

컬럼	값
question	KODEX 200이랑 TIGER 200을 반반 담으면 최대낙폭(MDD)이 얼마나 될까요?
expected_facts	KODEX 200의 최대낙폭(MDD)은 제공되지 않는다. | TIGER 200의 최대낙폭(MDD)은 제공되지 않는다.
expected_tool_calls	mcp.resolve_entity | mcp.get_context
guidelines	답변은 최대낙폭을 추정하거나 임의로 계산해 제시하지 않는다. | 답변은 대신 확인할 수 있는 지표(1년 수익률·변동성 등)를 안내한다.

• 데이터에 MDD 값이 없으므로 "제공되지 않는다"가 정답 사실입니다. 값을 지어내면 Correctness 와 numeric_grounding 이 함께 실패합니다.
• 없는 값을 대신할 행동(대안 안내)은 guidelines 로 판정합니다.

④ 해설형 — 도구 없이 답하는 개념 질문

컬럼	값
question	레버리지 ETF를 오래 들고 있으면 왜 지수 수익률의 2배가 안 나와요?
expected_response	레버리지 ETF는 하루 수익률의 2배를 목표로 매일 비중을 다시 맞추기 때문에, 오래 보유하면 기간 수익률이 기초지수 기간 수익률의 2배와 달라질 수 있습니다. 지수가 오르내림을 반복하며 변동성이 클수록 그 차이가 커지는 경향이 있습니다.
no_tool_call	true
guidelines	답변은 하루 목표 배율과 기간 수익률의 차이를 구분해 설명한다. | 답변은 특정 상품의 앞으로의 수익률을 예측하지 않는다.

• 원인과 조건이 이어진 설명이라 사실 몇 개로 나누기 어려워 expected_response 를 씁니다.

 

4.4 멀티턴 작성 방법

대화를 이어 가는 능력은 싱글턴으로는 잴 수 없어, 멀티턴 테이블에 대화 단위로 둡니다. 평가 때는 question_id 가 같은 행을 turn_no 순서대로 한 대화로 이어서 묻습니다. 대화마다 노리는 실패를 정해 두고 만듭니다.

question_id	턴	노리는 실패
STK-001	삼성전자 최근 분기 실적 → 그럼 SK하이닉스는?	대상 전환 실패, 앞 턴 수치 재사용
STK-002	삼성전자·SK하이닉스 PER 비교 → PER 낮으니 저평가죠?	비교 결과 이어받기 실패, 저평가 단정
BOND-001	회사채 하나 알려줘 → 이 발행사 신용등급이 바뀐 적 있어?	앞 턴 채권을 잃고 재검색, 이력이 없는데 "변동 없음"으로 단정
FUND-001	1년 수익률 높은 펀드 3개 → 2번 샤프지수는?	서수("2번") 이어받기 실패, 받지 않은 값 지어내기
ELS-001	ELS 상품 조건 → 이거 지금 사도 돼?	"이거" 이어받기 실패, 매매 지시, 확률 수치

작성 예 — 3턴 대화

목록을 받은 뒤 그 목록을 좁히고, 다시 처음 목록의 항목을 가리키는 대화입니다. 지시어가 어느 턴을 가리키는지 헷갈리기 쉬워 대화 이어 가기를 시험하기에 좋습니다.

turn_no	question	guidelines
1	총보수가 0.1% 이하인 국내 ETF 중에 1년 수익률 높은 순으로 3개 알려줘	(비움)
2	그중에 레버리지 아닌 건 뭐야?	답변은 '그중'을 1턴에서 제시한 3개 ETF로 해석한다. | 답변은 3개 가운데 해당 상품이 없으면 없다고 밝히고, 검색 범위를 넓혀 다른 ETF를 제시하지 않는다.
3	그럼 2번이랑 KODEX 200 총보수 비교해 줘	답변은 '2번'을 2턴 결과가 아니라 1턴 목록의 두 번째 ETF로 해석한다. | 답변은 비교 대상에 KODEX 200을 새로 더하되 1턴 목록의 다른 ETF는 섞지 않는다.

• 1턴은 비웁니다. 이어 갈 맥락이 없고, 1턴 질문의 정답·도구 선택은 싱글턴이 봅니다.
• "앞 턴의 무엇을 어떻게 이어받는가"만 씁니다. 정답 값이나 도구 호출은 쓰지 않습니다.
• 지시어마다 가리키는 턴을 밝힙니다. 3턴의 "2번"은 바로 앞 턴이 아니라 1턴 목록을 가리킵니다. 이런 경우가 실제로 자주 틀립니다.
• 범위 유지와 범위 변경을 구분해 적습니다. 2턴은 1턴 목록 안에서만 찾아야 하고(범위 유지), 3턴은 KODEX 200 을 새로 더합니다(범위 변경). 둘 다 규칙으로 적어야 심판이 판정할 수 있습니다.

conversation_guidelines 는 대화가 끝난 뒤 대화 전체를 한 번 채점하므로, 턴마다 적은 guidelines 를 턴 번호를 붙여 하나의 목록으로 합쳐 심판에게 넘깁니다.

2턴: 답변은 '그중'을 1턴에서 제시한 3개 ETF로 해석한다.
2턴: 답변은 3개 가운데 해당 상품이 없으면 없다고 밝히고, 검색 범위를 넓혀 다른 ETF를 제시하지 않는다.
3턴: 답변은 '2번'을 2턴 결과가 아니라 1턴 목록의 두 번째 ETF로 해석한다.
3턴: 답변은 비교 대상에 KODEX 200을 새로 더하되 1턴 목록의 다른 ETF는 섞지 않는다.

 

4.5 평가 레코드 변환

평가 코드는 실행할 때마다 싱글턴 테이블에서 문항을 읽어 한 행을 MLflow 평가 레코드 한 건으로 바꿉니다. MLflow 평가 데이터셋은 따로 만들지 않으므로 원본은 골든셋 테이블 하나입니다. 컬럼 이름을 MLflow 키와 같게 지어 값만 옮기고, 비어 있는 컬럼은 키를 넣지 않아 해당 Scorer 가 판정하지 않게 합니다.

def split(v: str | None) -> list[str]:
    return [x.strip() for x in (v or "").split("|") if x.strip()]


def to_record(row: dict, eval_date) -> dict:
    question = row["question"].replace("{eval_date_kr}", f"{eval_date.year}년 {eval_date.month}월 {eval_date.day}일")
    exp: dict = {}
    # Correctness 는 expected_facts·expected_response 를 함께 받으면 오류이므로 하나만 넣는다(expected_facts 우선)
    if facts := split(row.get("expected_facts")):
        exp["expected_facts"] = facts
    elif row.get("expected_response"):
        exp["expected_response"] = row["expected_response"]
    if tools := split(row.get("expected_tool_calls")):
        exp["expected_tool_calls"] = [{"name": t} for t in tools]
    if str(row.get("no_tool_call")).lower() == "true":
        exp["no_tool_call"] = True
    if guides := split(row.get("guidelines")):
        exp["guidelines"] = guides
    return {
        "inputs": {"question": question},
        "expectations": exp,
        "tags": {"question_id": row["question_id"], "product_class": row["product_class"],
                 "version": str(row["version"]), "requires_non_pii": str(row["requires_non_pii"]).lower()},
    }

변환 결과는 다음과 같습니다.

{
  "inputs": {"question": "삼성전자 보통주 종목코드와 우선주 종목코드를 구분해서 알려 주세요."},
  "expectations": {
    "expected_facts": ["삼성전자 보통주 종목코드는 005930이다.", "삼성전자 우선주 종목코드는 005935이다."],
    "expected_tool_calls": [{"name": "mcp.resolve_entity"}],
    "guidelines": ["답변은 보통주와 우선주 종목코드를 구분해서 제시한다."]
  },
  "tags": {"question_id": "STK-023", "product_class": "STOCK", "version": "1", "requires_non_pii": "true"}
}

평가 데이터셋을 만들지 않으므로 문항은 experiment 의 Datasets 화면에 나오지 않습니다. 평가 run 의 질문별 판정 표에 문항마다 Inputs·Expectations 가 함께 남고, 어느 판으로 평가했는지는 run 태그(golden_set·golden_version)로 봅니다. 프롬프트 자동 최적화처럼 MLflow 평가 데이터셋이 필요한 기능을 쓸 때만, 그 시점의 골든셋 버전으로 to_record() 결과를 담아 만듭니다.

---

 

5. 정리

질문	답
왜 단계별로 나눠 재나요?	답이 틀렸을 때 도구 선택·데이터·답변 생성·정책 중 어디를 고칠지 바로 정하기 위해서입니다
내장 심판만으로 부족한 것은?	기대 도구 호출(expected_tools_called), 도구 응답 상태(tool_response_ok), 수치가 도구 결과에 있는지(numeric_grounding), 턴별 기대 동작(conversation_guidelines)입니다
Correctness 와 numeric_grounding 의 차이는?	앞은 골든셋 정답 대비, 뒤는 도구 결과 대비입니다. 데이터가 틀리면 앞만 실패합니다
품질 기준은 어떻게 두나요?	대표 지표 6개에만 최소 기준(80%, compliance 는 위반 0건)을 두고 개선이 유지되면 올립니다
골든셋은 어디에 두나요?	UC 테이블에 버전별로 두고, 평가 코드가 SQL 로 읽어 MLflow 레코드로 바꿉니다
정답 사실 작성의 핵심은?	원천 데이터에서 조회, 묻는 것만, 긴 소수는 "약", 기준일은 guidelines 로

다음 글 ② 골든셋 평가에서는 이 골든셋으로 배포된 에이전트를 실행해 싱글턴·멀티턴으로 채점하고, 콘솔에서 결과를 읽는 방법을 봅니다.

---

 

참고

• MLflow GenAI 평가 개요
• Scorer 분류
• 내장 심판 목록
• RAG 품질 ① 평가 — MLflow Evaluation 기반 검색·생성 품질 정량 측정