AI 에이전트 정확도는 어떻게 검증하나: 확신도 0.9인데 틀리는 모델, 정답지와 검수 기준 설계
업체가 제시한 정확도나 모델이 내는 확신도는 그대로 믿으면 안 됩니다. 판단 전용 모델을 23건으로 실측한 공개 사례를 출발점으로, 우리 회사 데이터로 정답지를 만들고, 고위험 유형의 재현율과 확신도 구간별 정답률을 확인하고, 운영 중 다시 재는 방법을 표와 순서로 정리했습니다.
AI 에이전트의 정확도는 업체가 보여 준 숫자나 모델이 스스로 내는 확신도(confidence)로 판단하면 안 됩니다. 우리 회사의 과거 처리 사례로 만든 정답지로 다시 재야 합니다. 핵심은 세 가지입니다. 틀렸을 때 피해가 큰 유형의 재현율을 따로 보고, 확신도 구간별 실제 정답률을 확인해 문턱 아래는 사람에게 넘기고, 운영 중에도 같은 정답지로 정기적으로 다시 재는 것입니다.
이 기준이 왜 필요한지 보여 주는 실측이 최근 공개됐습니다. 2026년 9월 29일 한 개발자 블로그는 판단 전용 오픈소스 모델 Laya로 '제목이 같은 두 노트가 같은 개념인가'를 23건 판정했습니다. 정답률은 78%(18건)였습니다. 그런데 내용이 전혀 다른 노트를 같다고 잘못 판정한 답에 확신도 0.802와 0.896이 붙었고, 맞힌 답 일부는 확신도가 0.01 수준이었습니다. 표본이 23건이라 이 모델 전체를 평가할 수는 없습니다. 그래도 '확신도가 높으면 맞다'는 가정이 우리 데이터로 확인하기 전에는 성립하지 않는다는 점은 분명합니다. 작성자는 README에 적힌 GPU 기준 지연 시간과 자신의 CPU 환경 실측(호출당 평균 1.3초)이 30배 넘게 달랐다고도 적었습니다. 숫자는 측정 조건과 함께 읽어야 합니다.
작성자가 내린 결론은 한 문장입니다. '진짜 문제는 정확도가 아니라 확신이었다.' 그래서 작성자는 이 모델로 바꾸지 않고, 이미 검증된 기존 방식을 유지하기로 했습니다.
정확도는 무엇으로 재고, 기준은 어떻게 정하나
| 검증 항목 | 무엇을 재나 | 기준 정하는 법 | 업체에 요구할 것 |
|---|---|---|---|
| 정답지(평가 세트) | 과거 처리 사례에 담당자가 정답을 붙인 표본 | 최근 업무에서 유형별로 고르게 뽑고, 애매한 사례도 일부러 넣는다 | 정답지를 누가 만들고 어디에 보관하는지, 계약 종료 시 반환 여부 |
| 전체 정확도 | 정답지 전체에서 맞힌 비율 | 도입 전 사람이 처리할 때의 오류율을 기준선으로 함께 잰다 | 측정에 쓴 데이터, 채점자, 틀린 사례 목록 |
| 고위험 유형 재현율 | 놓치면 안 되는 유형(부정 이슈, 환불 요청, 계약 조건 등)을 놓치지 않은 비율 | 전체 정확도와 따로 합격선을 둔다 | 유형별 결과표, 놓친 사례 원문 |
| 확신도 보정 | 확신도 구간별(예: 0.9 이상, 0.7~0.9) 실제 정답률 | 구간별 정답률이 확신도와 맞지 않으면 문턱을 다시 정한다 | 구간별 정답률 표, 문턱 아래 건의 처리 경로 |
| 사람 검토 비율 | 문턱 아래라 사람에게 넘어간 건의 비율과 처리 시간 | 자동 처리율과 검토 부담을 함께 본다 | 검토 화면, 검토 결과가 다음 기준에 반영되는 방식 |
| 운영 중 재측정 | 같은 정답지로 다시 잰 결과의 변화 | 모델·프롬프트·데이터가 바뀔 때마다, 그리고 정기적으로 | 재측정 주기와 비용, 결과 보고 형식 |
계약 전부터 운영까지 어떤 순서로 검증하나
- 1. 판단을 보기로 정의한다: 에이전트가 내릴 판단을 '보기 중 하나 고르기'로 적습니다(예: 긴급·일반·스팸). 판단이 문장으로만 정의돼 있으면 채점도 할 수 없습니다.
- 2. 정답지를 만든다: 최근 처리 기록에서 유형별로 표본을 뽑아 담당자가 정답을 붙입니다. 수십 건으로 시작해 PoC 중에 늘려도 됩니다.
- 3. 기준선을 잰다: 사람이 같은 일을 할 때의 오류와 처리 시간을 먼저 잽니다. 비교 대상이 없으면 '좋아졌다'고 말할 수 없습니다.
- 4. 업체 시스템을 채점한다: 같은 정답지로 돌린 결과를 유형별 표와 틀린 사례 원문으로 받습니다.
- 5. 문턱을 정한다: 확신도 구간별 정답률을 보고 자동 처리할 구간과 사람에게 넘길 구간을 나눕니다.
- 6. 운영 중 다시 잰다: 모델이나 프롬프트를 바꾸면 같은 정답지로 다시 재고, 떨어진 유형이 있으면 배포하지 않습니다.
업무 유형별로 무엇이 달라지나
분류·판정(문의 분류, 이슈 긴급도)
보기별 재현율과 자주 헷갈리는 보기 쌍을 봅니다. 놓치면 안 되는 보기에는 전체 정확도와 별도의 합격선을 둡니다.
문서 검색·답변(RAG)
답의 정확도와 함께 근거 문서가 맞는지, 근거가 없을 때 답을 유보하는지를 채점합니다. 보면 안 되는 문서가 인용되지 않았는지도 권한별 시험 계정으로 확인합니다.
생성·번역(답변 초안, 자막)
정답이 하나가 아니므로 체크리스트(용어집 준수, 금지 표현, 사실 오류)로 채점하고 사람 수정률을 함께 봅니다.
검증 비용과 기간은 무엇이 좌우하나
검증 비용의 대부분은 모델이 아니라 정답지를 만드는 사람의 시간입니다. 판단 유형이 많을수록, 애매한 사례가 많을수록, 정답을 붙일 수 있는 담당자가 적을수록 기간이 늘어납니다. 앞의 실측에서도 작성자는 모델을 자기 데이터로 다시 학습시키는 방안을 검토했지만, 공식 문서의 데모 데이터만 해도 1,200건 규모였던 반면 손에 있는 실측 데이터는 23건뿐이었습니다. 그래서 병목은 GPU가 아니라 데이터라고 결론 내렸습니다. 모델 교체가 잦은 업무라면 재측정 비용도 운영비에 미리 넣어야 합니다.
노벤티스가 하는 일
노벤티스는 구축·PoC 단계에서 실제 업무 데이터로 에이전트를 만들고 결과를 사람이 검토하며, 검증된 범위만 운영으로 넘깁니다. 운영·고도화 단계에서는 처리량·오류·검토 시간을 같은 기준으로 다시 재서 범위를 넓힙니다. 고객사 프로젝트에서 멀티 LLM 라우팅과 프롬프트 평가 체계를 만들어 왔습니다. 우유자조금 미디어 모니터링 시스템을 구축·운영하며 정리한 기준(부정·긴급 이슈를 놓치지 않는지 먼저 본다)도 같은 원리입니다. 첫 프로젝트는 대개 접점 하나를 대상으로 4~8주 안에 PoC까지 진행하며, 범위와 비용은 진단 미팅 후 서면 견적으로 드립니다.
이 방식이 특히 필요한 조직(best for): 틀린 결과가 외부로 나가는 업무(고객 회신, 공식 보고)를 자동화하려는 조직, 업체가 제시한 정확도만으로 계약을 판단해야 하는 구매 담당자, 모델을 자주 바꾸는 운영 팀입니다.
자주 묻는 질문
- AI 에이전트 정확도는 어떻게 검증하나요?
- 과거 처리 사례에 담당자가 정답을 붙인 정답지로 다시 잽니다. 전체 정확도와 별도로 놓치면 안 되는 유형의 재현율과 확신도 구간별 실제 정답률을 확인하고, 문턱 아래 건은 사람 검토로 보냅니다.
- 모델이 주는 확신도(confidence)를 믿고 자동 처리해도 되나요?
- 우리 데이터로 확신도 구간별 정답률을 확인하기 전에는 안 됩니다. 공개된 실측에서도 틀린 답에 0.8~0.9의 확신도가 붙은 사례가 있었습니다. 구간별 정답률을 보고 자동 처리 문턱을 정하세요.
- 정답지는 몇 건이 필요하고 누가 만드나요?
- 유형별로 고르게 뽑은 수십 건으로 시작해 PoC 중에 늘릴 수 있습니다. 정답은 그 업무를 실제로 처리하는 담당자가 붙여야 하고, 업체는 채점 결과를 유형별 표와 틀린 사례 원문으로 제공해야 합니다.