7.7.5 불확실성(Uncertainty)이 높은 평가 결과의 인간 검토(Human-in-the-loop) 전환 트리거
정규표현식 구조 검사와 JSON 파싱을 모두 완전하게 통과했음에도 불구하고, 최상위 계층의 ’의미론적 평가 오라클(LLM-as-a-Judge)’마저도 확신을 가지지 못하는 회색 지대(Gray Area)가 필연적으로 존재한다. 하이브리드 오라클 파이프라인의 완성도는, 이 오라클이 자신의 ’무지(Ignorance)’를 얼마나 정확하게 파악하고 시스템 밖의 인간 전문가에게 제어권을 신속히 넘기는지(Handoff)에 달려 있다.
1. 불확실성(Uncertainty)의 정량화 방식
LLM 판사(Judge)가 특정 답변의 통과/실패를 결정할 때, 그 결정이 얼마나 확고한지 정량적인 수치로 측정하는 메커니즘을 내장해야 한다.
- Logprobs(로그 확률) 기반 측정: 가장 직접적인 방법은 언어 모델 API가 반환하는 개별 토큰의 확률값(
logprobs)을 활용하는 것이다. 모델이Pass라는 토큰을 생성할 때 확률이 99\%라면 확고한 결정으로 볼 수 있으나, 확률이 55\%라면 내부적인 경쟁 토큰(Fail)과 심하게 경합했음을 의미한다. - 다중 패널 간의 불일치(Consensus Failure): 여러 개의 평가 모델(예: GPT-4, Claude 3, 로컬 LLM)을 동시에 판사로 세우는 ‘Panel of Judges’ 아키텍처에서, 판정 결과가
[Pass, Pass, Fail]이나[Pass, Fail, Fail]형태로 극명하게 갈린다면 해당 데이터는 알고리즘적 판단의 신뢰 구간을 벗어난 것으로 간주해야 한다.
2. HITL(Human-in-the-loop) 트리거 조건 설계
불확실성이 감지되면, 시스템은 그 즉시 배포나 테스트 프로세스를 강제 중단하지 않고 해당 케이스만 격리(Quarantine)하여 인간 검토 대기열(Queue)로 밀어 넣어야 한다. 이를 발동시키는 공학적 트리거 조건은 다음과 같이 설계된다.
- 임계값 미달 (Threshold Breach): 평가 스코어가 1~10점 척도에서 극단값(1점, 10점)이 아닌 모호한 중간값(5점, 6점)에 집중적으로 수렴할 때.
- 사고의 사슬(CoT) 내 모순 감지: LLM-as-a-Judge가 작성한 평가 사유(Reasoning)에는 긍정적인 평가가 가득하지만, 최종 도출된 결론 필드가
score: 2로 기재된 경우. 이는 환각에 의한 논리적 모순이므로 즉시 트리거의 대상이 된다. - 가드레일 우회 의심: PII(개인식별정보) 필터나 욕설 검사기는 통과했으나, 문맥적으로 교묘한 프롬프트 인젝션(Prompt Injection)이나 우회 공격이 의심되는 미묘한 발화.
3. 피드백 루프에 의한 오라클의 진화
인간 전문가가 개입하는 HITL 단계는 단순히 “하나의 에러를 수정하는” 일회성 땜질 작업이 아니다. 이 과정은 하이브리드 오라클 그 자체를 고도화하는 가장 강력한 데이터 수집 파이프라인이다.
- 엔지니어는 대기열에 격리된 데이터를 바탕으로, 무엇이 LLM 판사를 헷갈리게 만들었는지 기존의 평가 기준(Rubric)을 역추적하여 수선한다.
- 인간이 수정한 최종 판정 결과(인간의 판결문)는 그 즉시 골든 데이터셋(Golden Dataset)의 회귀 테스트 시드(Seed) 데이터로 편입된다.
완벽한 소프트웨어 오라클이란 모든 상황을 자동화하는 것이 아니라, 자신이 판단할 수 없는 ’불확실성’의 영토를 명확히 획정하고, 인간의 판단을 끊임없이 시스템 내부의 결정론적 룰(Rule)로 치환해 나가는 자가 발전적 성장을 이룩하는 시스템이다.