10.4 결정론적 평가를 지원하는 데이터셋 메타데이터 스키마 설계

결정론적 오라클을 구축하기 위해서는 테스트 데이터셋 자체가 프로그래밍 가능한 객체(Programmable Object)로 취급되어야 한다. 단순히 ’질문’과 ‘정답’ 텍스트를 나열한 CSV 엑셀 파일은 오라클 파이프라인에 통합될 수 없다. 테스트 엔진이 각 데이터 포인트를 어떻게 평가해야 할지, 어떤 문맥을 주입해야 할지, 실패 시 어떤 도메인 모델에 결함이 있는지 역추적하기 위해서는 반드시 기계가 읽을 수 있는(Machine-Readable) 풍부한 메타데이터(Metadata) 스키마가 데이터셋과 결합되어야 한다.

본 절에서는 CI/CD 파이프라인에서 자동화된 회귀 테스트를 완벽하게 제어하고, 오탐(False Positive)과 미탐(False Negative)을 최소화하기 위해 반드시 포함되어야 할 골든 데이터셋의 메타데이터 구조를 설계한다.

1. 테스트 케이스 고유 식별 및 추적성(Traceability) 필드

모든 골든 데이터 레코드는 독립적인 생명주기를 가지며, 요구사항 추적 매트릭스(Requirements Traceability Matrix, RTM)와 직접 연결되어야 한다. 특정 테스트 케이스가 실패했을 때 즉각적인 디버깅이 가능하도록 다음과 같은 필수 식별자를 기록하라.

• test_case_id: UUID 형식의 고유 식별자. 동일한 의도의 질문이 표현만 바뀐 채 추가될 경우, 파생 관계를 추적할 수 있도록 parent_id를 함께 관리하는 것이 유리하다.
• category / domain: 테스트가 타깃으로 삼는 비즈니스 도메인(예: refund_policy, technical_support) 또는 기능 단위. 특정 모듈 변경 시 이 필드를 기반으로 관련 데이터만 추출하여 부분 회귀 테스트(Partial Regression Test)를 수행한다.
• version / updated_at: 골든 데이터의 최종 수정일과 버전. 비즈니스 룰이 변경되었을 때, 구 버전의 데이터셋이 실수로 테스트에 사용되어 오라클 오류를 유발하는 것을 방지한다.
• origin: 해당 데이터 포인트가 어떻게 생성되었는지 출처를 명시하라. (예: production_log, manual_creation_by_sme, synthetic_generation_by_llm). 합성 데이터의 비중을 조절하거나 특정 출처의 신뢰도가 떨어졌을 때 필터링하는 파라미터로 사용된다.

2. 오라클 유형(Oracle Type) 및 평가 전략 바인딩

가장 중요한 메타데이터는 **‘이 데이터를 어떤 알고리즘으로 채점할 것인가’**를 테스트 러너(Test Runner)에게 지시하는 필드다. 모든 응답을 LLM-as-a-Judge로 평가하는 것은 비용과 예측 가능성 면에서 매우 비효율적이다.

• evaluation_strategy: 해당 데이터 포인트에 적용할 오라클의 유형을 명시하라.
• exact_match: 출력 문자열이 정답과 100% 동일해야 통과. (예: 제품 식별 코드, 수학 계산 결과)
• regex: 출력이 정해진 정규 표현식 패턴을 만족해야 통과. (예: 이메일 주소 포맷, 날짜 형식)
• json_schema_validation: 출력이 지정된 JSON 구조를 완벽히 준수하는지 파싱하여 검사.
• llm_judge: 의미론적 유사도나 논리성 평가가 필요하여 보조 LLM 심판관을 호출해야 하는 경우.
• evaluation_kwargs: evaluation_strategy가 실행될 때 필요한 동적 파라미터. 예를 들어 전략이 regex라면 여기에 실제 정규식 패턴 문자열을 키-값(Key-Value) 형태로 저장하며, llm_judge라면 심판관에게 주입할 평가 루브릭(Rubric) ID나 허용 오차 수준(예: score_threshold: 0.8)을 정의한다.

3. 참조 지식(Grounding Context) 스냅샷 고정

RAG(Retrieval-Augmented Generation) 시스템을 테스트할 때, 외부 지식 베이스의 내용이 변경되면 AI의 올바른 응답조차도 기존 골든 데이터셋의 정답과 달라져 테스트가 실패하게 된다. 이러한 외부 의존성에 의한 오라클 붕괴를 막기 위해서는 테스트 시점에서 주입되어야 할 참조 지식 자체를 데이터셋에 박제(Snapshot)해야 한다.

• injected_context: 이 질문에 대답하기 위해 AI에 반드시 주입(Injection)되어야 하는 백그라운드 텍스트나 문서 덩어리(Chunk). 테스트 러너는 실제 Vector DB 검색 단계를 우회(Bypass)하고 이 필드의 값을 강제로 프롬프트에 삽입하여 순수한 ’생성(Generation) 능력’만을 격리하여 평가한다.
• retrieval_targets: 반대로 ’검색(Retrieval) 능력’을 평가하는 테스트의 경우, Vector DB가 반드시 반환해야 하는 정답 문서의 고유 ID(Document ID) 목록을 기재하라. 이 ID 목록이 검색 결과의 상위 K개(Top-K) 내에 포함되었는지를 검사하는 형태의 오라클을 구동할 수 있다.

이처럼 철저하게 설계된 JSONL 또는 Parquet 포맷의 구조화된 데이터셋은 단순한 테스트 문서가 아니라, AI 시스템의 품질을 결정론적으로 보장하는 **실행 가능한 사양서(Executable Specification)**로 작동하게 된다.