최근 한 품질 보증(QA) 매니저가 필자에게 CSV AI 에이전트의 평가 보고서를 보여주었습니다. 거기에는 ’10점 만점에 8.2점’이라는 단 하나의 종합 점수만 적혀 있었습니다. 그녀는 이 점수가 다음 FDA 실사(inspection)를 통과하기에 충분한 수준인지 물었습니다. 필자는 그녀에게 7.2점과 8.2점의 차이가 무엇인지 되물었습니다. 그녀는 오랫동안 그 숫자를 말없이 응시했습니다.

그 질문에는 아무도 답할 수 없습니다 — QA 매니저도, 모델 벤더도, 그리고 승인 전 실사(PAI, Pre-Approval Inspection) 도중 이 질문을 던질 FDA 조사관도 마찬가지입니다. 규제 준수(regulatory compliance)에 대해 1~10점으로 매긴 점수는 올바른 평가가 아닙니다. 지표의 탈을 쓴 법적 책임이자 리스크(liability)에 불과합니다.

문제는 컴퓨터 시스템 밸리데이션(CSV) 환경에서 AI 에이전트를 평가하는 것 자체가 어렵다는 점이 아닙니다. 대부분의 팀이 엉뚱한 대상을 최적화하도록 평가 시스템을 구축하고 있다는 점이 문제입니다. 즉, 결정론적 규정 준수 점검 대신 주관적인 품질 점수를 매기고, 검증 가능한 결과 대신 모호한 느낌(vibes)을 따르며, 실제 환경의 상태 대신 트랜스크립트의 주장을 평가하는 우를 범하고 있습니다.

CSV를 위한 훌륭한 평가는 단조롭고 명확합니다(boring). 추적성 매트릭스(trace matrix)의 행은 연결되어 있거나, 연결되어 있지 않거나 둘 중 하나입니다. 규제 인용문은 통제된 참조 데이터베이스에 존재하거나, 존재하지 않거나 둘 중 하나입니다. 테스트 스텝은 측정 가능한 합격 기준을 갖추고 있거나, 아니면 모호하게 ’정확하게(correctly)’라는 단어를 남발하고 있거나 둘 중 하나입니다. 이러한 단조로움과 명확함이야말로 실사 준비(audit-ready)를 완벽하게 만듭니다.

핵심적인 역설 (The Core Paradox)

전통적인 CSV는 결정론적(deterministic) 시스템을 전제로 합니다. 동일한 입력이 들어가면 매번 완전히 동일한 출력이 나와야 합니다. 이러한 전제는 지금까지 작성된 모든 밸리데이션 프로토콜의 법적 기반이었습니다.

하지만 AI 에이전트는 이 모든 전제를 무너뜨립니다. 에이전트는 확률적으로 추론합니다. 매번 다른 순서로 도구 호출(tool calls)을 연쇄적으로 연결합니다. 실행할 때마다 달라지는 맥락을 검색해 가져옵니다. 완전히 동일한 프롬프트에서도 서로 다른 출력을 만들어냅니다.

따라서 AI 에이전트를 위한 밸리데이션 전략은 코드 실행을 검증하는 방식에서 **에이전트의 경계(boundary), 운영 범위(operational envelope), 그리고 최종 결과(outcomes)**를 검증하는 방식으로 전환되어야 합니다. 그리고 그 결과를 입증하는 평가 시스템 자체 또한 FDA 조사관에게 방어 가능해야 합니다.

이 지점에서 대부분의 팀이 실패합니다. 평가를 나중에 덧붙이는 사후 고려 사항 정도로 취급하며, 파이프라인 끝에 ’이 결과물을 1~10점으로 평가하라’는 식의 조잡한 LLM 판사(LLM judge)를 덧붙여 놓습니다. 규제 대상 환경에서 이는 평가가 아닙니다. 감사 추적(audit trail)이 없는 한낱 주관적 의견에 불과합니다.

검증의 비대칭성 (The Asymmetry of Verification)

모든 평가 결정을 이끌어야 하는 근본적인 통찰은 바로 이것입니다: 정확한 밸리데이션 프로토콜을 생성하기는 어렵지만, 그것을 검증하기는 매우 저렴하다는 점입니다.

GAMP 카테고리 4 LIMS(실험실 정보관리시스템)에 대한 위험 평가를 생성하려면 시스템, 규제 프레임워크, 사용 목적(intended use), 데이터 흐름, 환자 안전에 미치는 영향 등을 깊이 이해해야 합니다. 반면, 해당 위험 평가가 시스템을 카테고리 4로 정확하게 분류했는지 확인하는 작업은 output.category == expected.category라는 단 한 줄의 비교 연산에 불과합니다.

이 비대칭성은 평가 엔지니어의 가장 강력한 무기입니다. 평가 작업을 사전에 저장된 기대 출력(expected output)과의 결정론적 점검으로 환원할 수 있을 때마다 세 가지 이점을 동시에 얻습니다: 점검이 즉각적으로 이루어지고, 실행 간에 일관성이 유지되며, 감사(audit) 대응이 극도로 단순해집니다.

규칙은 단순합니다: 평가하려는 대상이 시스템 내에서 직접 확인 가능하거나 사전에 저장해 둔 기대 출력과 비교할 수 있다면, 코드를 사용하십시오. LLM 판사는 결과가 순수한 언어 형태로만 존재하고 사전에 정의된 기대 출력이 없을 때만 제한적으로 사용해야 합니다.

점검하려는 항목 결정론적 방식 (권장) LLM 판사 (가급적 지양)
GAMP 카테고리 기대값: Category 4. 코드: output.category == expected.category 판사가 20페이지 분량의 기능 명세서(FS)를 읽고 Category 4가 타당한지 추측
추적성 (Traceability) 기대값: 모든 URS에 1개 이상의 테스트 매핑. 코드: 매트릭스를 파싱하여 고아(orphan) 요구사항 확인 판사가 매트릭스를 읽고 “완전해 보임”이라고 답변
21 CFR Part 11 인용 내부 SOP에 명시된 기대 인용구 목록. 코드: 허용 목록(allow-list)에 해당 인용구가 존재하는가? 판사가 인용구가 그럴듯하게 들리는지 확인
실제 조치 vs. 주장 (Action vs. Claim) 에이전트의 말: “VP(밸리데이션 계획서) 생성 완료.” 코드: Veeva API를 호출해 실제 파일이 생성되었는지 확인 판사가 트랜스크립트의 “VP를 생성했습니다”라는 주장을 읽고 합격 처리

전지전능한 단일 평가자(God Evaluator) 탈피하기

전반적인 품질을 평가하는 단 하나의 거대한 판사를 만들지 마십시오. “규정 준수, 완전성, 어조를 기준으로 이 밸리데이션 패키지를 1~10점으로 평가하라”는 지시는 전지전능한 평가자(God Evaluator)를 만듭니다. 이는 해석 불가능한 점수를 낳고, 무엇을 수정해야 하는지 숨기며, 규제 실사에서 결코 방어할 수 없습니다.

평가를 좁고 이진적(binary)이며 범주형(categorical)인 점검들로 세분화하십시오. 각 평가자는 정확히 하나의 질문에 대해 단 하나의 명확한 결론을 내려야 합니다.

다음은 CSV 에이전트를 위한 기초 평가기 세트입니다 — 모든 출력은 점수 척도가 아닌 이진(binary) 또는 범주형(categorical)입니다:

1. GAMP 카테고리 정확성 — 코드 평가자. 입력: 시스템 설명. 출력: 기대 카테고리와 비교한 합격/불합격(pass/fail). 이는 주관적 판단이 아니라 룩업(lookup) 검증입니다.

2. 추적성 무결성 — 코드 평가자. 입력: 에이전트가 생성한 추적성 매트릭스 JSON. 출력: 고아 요구사항이나 고아 테스트가 존재하면 불합격. 이는 그래프 순회(graph traversal) 점검입니다.

3. 규정 환각 방지(No Hallucinated Regulation) — 코드 + 판사 하이브리드. 입력: 에이전트 출력 + 내부 SOP 규정 허용 목록. 코드로 정확한 일치 여부를 먼저 확인합니다. 허용 목록과 정확히 일치하지 않는 패러프레이징(의역)에 대해서만 판사가 개입합니다.

4. GxP 영향 평가 — 범주형. 출력: correct / missed_critical / over_classified. 사전에 정의된 기대 출력이 필요합니다. 환자 안전 리스크를 누락하는 것은 치명적인 실패(critical failure)이며, 문서 관리 시스템을 고위험으로 과대 분류하는 것은 불필요한 자원 낭비입니다.

5. 위험 평가 완전성 — LLM 판사. 이진 평가: GAMP 5 2nd Edition에 따라 심각도(Severity)와 발생 확률(Probability)을 모두 평가했는가? “얼마나 잘 작성되었는가”가 아니라 필수 구성 요소를 포함하고 있는지를 확인합니다.

6. 실제 조치 vs. 말(주장) — 코드 평가자. 에이전트가 “OQ 실행 완료”라고 말한다면, 실제 QMS에 테스트 증적 행(evidence row)이 기록되었는지 확인합니다. 트랜스크립트의 주장이 아니라 실제 환경에서의 결과를 채점하십시오. 이는 전체 평가 시스템에서 가장 중요한 평가자입니다.

7. ALCOA+ 근거성(Grounding) — LLM 판사. 이진 평가: 모든 데이터 무결성 주장이 지어낸 것이 아니라 제공된 SOP/맥락에 근거하고 있는가? ALCOA+ 요구사항을 환각(hallucination)하는 에이전트는 이를 누락하는 에이전트만큼이나 위험합니다.

8. 시기상조 규정 준수 확약 방지 — LLM 판사. 이진 평가: IQ/OQ 증적이 실제로 존재하기도 전에 에이전트가 “시스템 밸리데이션 완료 / 실사 준비 완료 / 규정 준수 완료”라고 섣부르게 단언하는가? 이는 CSV 에이전트에서 가장 흔하게 발생하는 위양성(false positive)입니다. 증거가 갖춰지기 전에 성공을 선언하고 싶은 유혹은 가장 흔하면서도 가장 위험한 패턴입니다.

5계층 아키텍처 (The Five-Layer Architecture)

평가자를 계층형으로 조직화하면 모든 점검을 동등하게 취급하는 흔한 실수를 방지할 수 있습니다. JSON 스키마 실패와 규정 환각은 심각도가 전혀 다르며, 동일한 평면 목록에 있어서는 안 됩니다.

         비즈니스 임팩트 (BUSINESS IMPACT)
  ┌─────────────────────────────┐                                     
  │  계층 5: 인간 QA 검토       │  승인 / 수정 / 반려 (Approve / Revise / Reject)
  └─────────────┬───────────────┘                                     
                │                                                     
  ┌─────────────▼───────────────┐                                     
  │  계층 4: 규제 준수          │  GAMP 5, Part 11, ALCOA+            
  └─────────────┬───────────────┘                                     
                │                                                     
  ┌─────────────▼───────────────┐                                     
  │  계층 3: 태스크 성공        │  산출물 점검 (RTM, URS, 스크립트)
  └─────────────┬───────────────┘                                     
                │                                                     
  ┌─────────────▼───────────────┐                                     
  │  계층 2: 추론               │  정성적 점검을 위한 LLM 판사
  └─────────────┬───────────────┘                                     
                │                                                     
  ┌─────────────▼───────────────┐                                     
  │  계층 1: 기본 출력          │  100% 결정론적 (JSON, 스키마)
  └─────────────────────────────┘

계층 1은 순수한 코드입니다. 출력이 필수 필드를 갖춘 유효한 JSON으로 파싱되지 않는다면 다른 어떤 것도 의미가 없습니다 — 에이전트는 규제 준수 여부를 따지기도 전에 이미 실패한 것입니다. 계층 5는 자격을 갖춘 사람의 검토를 요구합니다. 이 계층들은 선택적 대안이 아니라 순차적인 스택입니다. 계층 1에서의 실패는 그 위의 모든 상위 계층 실행을 즉시 차단합니다.

규제 실사를 견뎌내는 LLM 판사 프롬프트 작성법

위험 평가 추론, 일탈(deviation) 근거 작성, 규제 해석 등 LLM 판사가 반드시 필요한 경우, 프롬프트 자체도 통제 문서(controlled document)가 됩니다. 따라서 버전 관리, 변경 관리, 그리고 캘리브레이션(calibration, 보정) 증적이 필수적입니다.

모든 판사 프롬프트는 신입 밸리데이션 엔지니어를 온보딩하기 위한 교육 자료처럼 구조화하십시오. 예외 없이 5가지 파트로 구성합니다:

파트 1: 맥락(Context). 에이전트가 무엇을 수행하는지, 어떤 규제 프레임워크가 적용되는지, 어떤 SOP가 이를 관할하는지 명시합니다. 일반적인 지시사항이 아니라 해당 태스크와 도메인에 특화되어야 합니다.

파트 2: 명확한 기준 + 무시할 요소(Precise Criterion + What to Ignore). “위험 평가가 우수한가?“가 아니라 “위험 평가가 구체적인 위험(hazard)을 언급하고 발생 확률 및 심각도 추정치를 인용하고 있는가?“와 같이 작성합니다. 서식, 길이, 치명적이지 않은 표현상의 차이 등 무시해야 할 요소를 명시적으로 밝힙니다.

파트 3: 라벨링된 예시(Labeled Examples). 합격과 불합격을 고루 섞어 수작업으로 라벨링한 실제 사례 2~4개를 각각의 짧은 이유와 함께 제공합니다. 가상의 시나리오가 아니라 실제 오류 분석에서 도출된 사례여야 합니다.

파트 4: 추론 먼저, 판정은 마지막에(Reasoning First, Verdict Last). 모델이 이진 합격/불합격을 출력하기 전에 단계별 추론을 먼저 출력하도록 강제합니다. 이는 실패로 판정된 이유에 대한 감사 추적(audit trail)을 생성합니다. 실사관은 이 추론을 읽고 판사의 논리가 타당한지 평가할 수 있습니다.

파트 5: 명시적 탈출구(Explicit Way Out). 입력 데이터에 판단을 내릴 충분한 맥락이 부족한 경우 판사는 반드시 UNKNOWN을 출력해야 합니다. 모델이 임의로 추측하게 해서는 안 됩니다. 규제 환경에서 추측은 결코 용납되지 않습니다.

예시: 규정 환각 방지 판사

맥락(Context): 귀하는 FDA 21 CFR Part 11 및 EU Annex 11에 따라 GxP 시스템을 위한 컴퓨터 시스템 밸리데이션 문서를 작성하는 AI 에이전트를 평가합니다. 에이전트는 반드시 제공된 맥락 문서에 명시된 요구사항만을 인용해야 합니다.

기준(Criterion): 응답이 맥락(CONTEXT)에 존재하지 않는 규제 인용구나 요구사항을 날조(지어냄)하고 있습니까? 맥락에 존재하지 않는 특정 조항(예: “21 CFR 11.300”)을 언급하거나, 규정에 명시되지 않은 내용을 규정의 요구사항이라고 주장하는 경우 날조된 것으로 간주합니다. 서식 차이는 무시하십시오.

예시(Examples):
[PASS] 응답: “SOP-042에 따라 감사 추적이 필수적입니다.” — 맥락 내 SOP-042에 감사 추적이 실제로 요구됨.
[FAIL] 응답: “21 CFR 11.70에 따라 블록체인 적용이 의무화됩니다.” — 21 CFR 11.70은 존재하지 않거나 맥락에 없음.

지시사항(Instructions): 먼저 단계별로 추론 과정을 설명하십시오. 그런 다음 판정 결과를 JSON 형식으로 출력하십시오: {“verdict”: “PASS” | “FAIL” | “UNKNOWN”}. 맥락이 누락된 경우 UNKNOWN을 사용하십시오.

판사 캘리브레이션 (Calibrating the Judge)

인간 SME(도메인 전문가)의 승인을 거쳐 실제 케이스 20~30개를 라벨링하십시오. 판사를 절반에 대해 실행해 보고 각 클래스별로 개별 점검하십시오. 90% 정확도의 함정을 경계해야 합니다. 실패율이 10%인 환경에서 항상 PASS만 출력하는 판사는 90%의 정확도를 갖지만 완전히 무용지물입니다. 실제 실패를 결코 잡아내지 못하기 때문입니다.

캘리브레이션 산출물 자체도 밸리데이션 증적이 됩니다:

  • 판사 프롬프트 = 통제 문서, 버전 관리, 변경 관리 적용
  • 라벨링된 케이스 = 변경 기록에 참조되는 밸리데이션 증적
  • 클래스별 일치율 = 밸리데이션 보고서로 저장
  • 판사 프롬프트 변경 = 무단 재배포가 아닌 공식 재밸리데이션(re-validation) 사안

평가 데이터셋 구축 (Building the Eval Dataset)

평가 데이터셋은 에이전트를 위한 OQ/PQ 테스트 스위트입니다. GAMP 5에 따라 데이터셋은 버전 관리되어야 하고, 추적 가능해야 하며, 정상 경로(happy path)뿐만 아니라 위험 공간 전체를 포괄하도록 설계되어야 합니다.

단 하나의 릴리스 질문으로 시작하라

“CSV 에이전트 테스트”와 같은 막연한 목표가 아니라, “COTS 시스템용 밸리데이션 계획서 초안을 작성하는 v2 버전을 배포할 수 있는가?“와 같이 구체적이어야 합니다. 하나의 목표는 곧 하나의 데이터셋을 의미합니다. 서로 다른 입력이나 릴리스 의사결정이 필요하다면 데이터셋을 분리하십시오.

최소 단위의 완전한 첫 번째 버전

15~30개의 데이터 행으로 충분합니다. 이는 유의미한 실험을 실행하고 최악의 리그레션(성능 퇴행)을 포착하기에 충분한 규모입니다. 여기서부터 계획적으로 확장해 나가십시오.

일상적(Routine) 모호함 / 고위험(Ambiguous / High-Risk)
인프라 (Cat 1) OS 패칭 AWS 클라우드 VM 적격성평가
COTS 설정 가능 (Cat 4) 설정이 적용된 LIMS 커스텀 워크플로우가 포함된 Veeva Vault
커스텀 (Cat 5) 실험실 분석기기 인터페이스 배치 릴리스용 GxP AI 모델
데이터 무결성 이슈 누락된 감사 추적 매크로가 포함되고 접근 제어가 없는 Excel

프로덕션의 발생 빈도를 그대로 반영하지 마십시오. 고위험 시나리오와 이미 알려진 실패 사례를 의도적으로 과대표집(over-represent)해야 합니다. 평가 데이터셋은 현실에 대한 통계적 표본이 아니라, 실사관이 지적하기 전에 문제를 먼저 찾아내기 위해 설계된 스트레스 테스트입니다.

아이템 스키마 (The Item Schema)

데이터셋의 각 항목은 단순한 자유 텍스트 프롬프트가 아니라 구조화되고 평가 가능한 객체여야 합니다:

{
  "input": {
    "task": "generate_iq_protocol",
    "system_description": "SaaS LIMS, configured workflow, stability data",
    "gamp_category": 4,
    "context_docs": ["SOP-042", "GAMP5 Cat definitions"]
  },
  "expectedOutput": {
    "required_docs": ["VP", "RA", "URS", "IQ", "OQ"],
    "must_not_claim": "System validated",
    "traceability": {"URS-042": ["OQ-05", "OQ-06"]}
  },
  "metadata": {
    "source": "audit_finding_2024_07",
    "scenario_type": "COTS_configurable",
    "difficulty": "ambiguous",
    "role": "known_regression"
  }
}

input에는 에이전트가 프로덕션에서 실제로 보는 정보만 담아야 합니다. expectedOutput에는 평가자가 필요로 하는 핵심 요소, 즉 문구가 아닌 동작(behavior) 기준만을 포함하십시오.

계획적이고 의도적인 확장

각기 고유한 목적을 지닌 3가지 확장 패턴을 활용하십시오:

프로덕션 미러링(Production-mirroring): 익명화되고 QA의 승인을 받은 실제 트레이스를 매주 추가합니다. 데이터셋이 현실의 실제 사용 패턴과 지속적으로 일치하도록 유지합니다.

불량 트레이스 확장(Bad-trace expansion): 심각한 프로덕션 실패가 발생할 때마다 해당 케이스를 데이터셋의 새로운 행으로 추가합니다. 이는 해당 결함이 다시는 재발하지 않도록 보장하는 영구적인 리그레션 테스트가 됩니다. 규제 환경에서 이는 선택 사항이 아니라 지속적 밸리데이션(continuous validation)의 필수 요건입니다.

목적별 분할(Purpose-specific splits): 데이터셋이 리그레션, 적대적 공격, 레드팀 테스트를 동시에 수행하려 할 때는 데이터셋을 분리하십시오. 엔드투엔드 계획 생성, 단계별 위험 평가, 적대적/규제 함정의 3가지 데이터셋으로 분리하는 것이 바람직합니다. 이를 혼합하면 합격률 수치가 본래의 의미를 잃게 됩니다.

오프라인 vs. 온라인 — 목적이 다른 두 개의 축

오프라인 (배포 전 OQ): 프롬프트, 모델, 도구 설정 변경을 릴리스하기 전에 전체 데이터셋을 통해 에이전트를 실행합니다. v2를 v1과 철저히 비교합니다. 단 하나의 리그레션이라도 발견되면 빌드를 즉시 중단합니다. 이것이 바로 CI 게이트입니다.

온라인 (배포 후 PQ): 결정론적 점검과 LLM 판사를 통해 프로덕션 트레이스를 지속적으로 평가합니다. 추세를 모니터링하십시오 — 이번 주에 환각된 인용구 비율이 증가하고 있습니까? 추적성 완전성이 저하되고 있습니까? 정확도가 사전에 정의된 품질 임계치 아래로 떨어지면 공식적인 재밸리데이션 절차를 트리거합니다.

CSV 에이전트의 경우, 큐레이션된 데이터셋을 기준으로 릴리스를 게이팅하는 오프라인 실험이 1차적인 핵심 밸리데이션 활동입니다. 온라인 평가는 인간 검토자의 오버라이드(수정/반려) 대비 판사 판정의 추세를 관찰하는 2차적인 보조 수단입니다. 이 불일치율(disagreement rate) 자체가 매우 유용한 지표입니다: 증적 검토자의 “충분함” 판정이 실제 인간 QA 검토자가 승인한 내용과 30% 이상 불일치한다면, 판사를 즉시 재캘리브레이션해야 합니다.

평가자 자체가 GxP 기록이다 (The Evaluator Is a GxP Record)

대부분의 팀이 간과하는 핵심 사항이 바로 이것입니다. 판사의 판정이 인간 검토 게이트로 전달되는 순간, 판정 결과와 추론 트레이스는 다른 모든 품질 기록과 동일한 ALCOA+ 요건을 충족해야 합니다:

  • Attributable (귀속성): 특정 모델 및 프롬프트 버전으로 명확히 추적 가능해야 함
  • Timestamped (일시성): 평가가 수행된 정확한 시점이 타임스탬프로 기록되어야 함
  • Immutable (불변성): 한 번 기록되면 위변조가 불가능해야 함
  • Legible (가독성): 감사를 위해 명확히 읽을 수 있고 재현 가능해야 함

평가 결과 자체도 불변의 감사 추적을 제공하는 21 CFR Part 11 준수 시스템에 저장되어야 합니다. LLM 판사가 일탈 근거에 대해 “합격”을 부여했는데 추후 이것이 FDA Form 483 지적사항(observation)으로 이어졌다면, 판사가 무엇을 보았고, 어떤 추론을 도출했으며, 어떤 프롬프트 버전이 활성화되어 있었는지 사후에 완벽히 재구성할 수 있어야 합니다.

이는 과도한 엔지니어링이 아닙니다. 규제 환경에서 품질 의사결정에 영향을 미치는 컴퓨터화 시스템이라면 당연히 갖추어야 할 최소한의 기준입니다.

폐루프 시스템 (The Closed-Loop System)

규제 실사관에게 평가 프레임워크를 폐루프(closed-loop) 구조로 제시하십시오:

골든 스탠다드 데이터셋 → AI 에이전트 → 평가자 (코드 + LLM)
    → 불일치 보고서 → 인간 검토 → 데이터셋 업데이트

이 구조는 규제 당국에 조직이 AI를 맹목적으로 신뢰하지 않고 있음을 증명합니다. 시간이 지남에 따라 신뢰성을 능동적이고 과학적이며 정량적으로 입증하고 있음을 보여줍니다. 데이터셋은 실제 실패 사례를 통해 성장합니다. 판사는 실제 불일치를 통해 지속적으로 재캘리브레이션됩니다. 시스템은 반복을 거듭할수록 더욱 안정화되며 — 그 모든 반복 과정은 철저히 문서화됩니다.

반드시 피해야 할 함정들 (What to AVOID)

1~10점 품질 척도 사용. 실사관은 6점과 7점의 차이를 구분할 수 없습니다. 7점이라는 점수는 밸리데이션할 수도 없습니다. 모든 척도를 이진(binary) 또는 범주형(categorical) 출력으로 대체하십시오.

단일 “전지전능한 평가자(God Evaluator)”. 규정 준수, 완전성, 어조를 한꺼번에 채점하는 단 하나의 판사는 무엇을 고쳐야 하는지 전혀 알려주지 못합니다. 좁고 실행 가능한 개별 점검으로 분할하십시오.

트랜스크립트 주장 평가. 에이전트가 “일탈 #402 조치 완료”라고 말할 때, 트랜스크립트의 문장만 읽고 합격 처리하지 마십시오. 실제 QMS 데이터베이스를 조회하십시오. 환경 내의 실제 결과를 채점해야 합니다.

캘리브레이션되지 않은 판사. 라벨링된 캘리브레이션 케이스가 없는 판사 프롬프트는 품질 의사결정을 내리고 있는 검증되지 않은 컴퓨터화 시스템에 불과합니다. 실사에서 결코 방어할 수 없습니다.

리그레션과 적대적 테스트를 한 데이터셋에 혼합. 절반의 데이터가 실패하도록 설계된 함정 케이스라면, 합격률은 아무런 의미도 갖지 못합니다. 목적에 따라 데이터셋을 분리하십시오.

고위험 결과물에 대한 인간 검토 생략. 평가는 인간의 판단을 돕는 도구이지, 인간을 대체하는 수단이 아닙니다. 고위험 에이전트 산출물이 규제 문서로 공식 확정되기 전에는 반드시 자격을 갖춘 인원의 최종 승인을 거쳐야 합니다.

결론 (The Bottom Line)

CSV를 위한 AI 에이전트 평가는 가장 높은 품질 점수를 찾아내는 일이 아닙니다. 모든 실패를 측정할 수 있고, 모든 지표를 조치 가능하게 만들며, 모든 평가를 감사 가능하게 만드는 시스템을 구축하는 일입니다.

최근 20개의 트레이스에 대한 오류 분석부터 시작하십시오. 단 하나의 실패 모드를 선택하십시오. 허용 목록을 갖춘 코드 평가자로 해결할 수 있습니까? 그렇다면 코드로 구축하고 마무리하십시오. 그렇지 않다면 20개의 케이스를 라벨링하고, 맥락과 명확한 기준을 담은 15줄짜리 판사 프롬프트를 작성하여 캘리브레이션하십시오.

3가지 시나리오 유형과 2가지 난이도를 포괄하는 20행짜리 데이터셋을 구축하십시오. 이를 실행하십시오. 에이전트 프롬프트뿐만 아니라 스키마와 판사 자체도 함께 개선하십시오.

훌륭한 평가는 본질적으로 단조롭고 명확합니다. 요구사항은 추적되었거나, 추적되지 않았거나 둘 중 하나입니다. 인용구는 존재하거나, 존재하지 않거나 둘 중 하나입니다. 테스트 스텝은 측정 가능한 기준을 가지고 있거나, 아니면 모호하게 ’정확하게’라는 단어를 사용하고 있거나 둘 중 하나입니다.

그 단조로움과 명확함이야말로 여러분을 실사 준비(audit-ready) 상태로 이끄는 진정한 힘입니다.

연구 노트: [[Evaluating AI Agents in CSV Life Sciences]]

관련 글