AI는 언제 답하지 말아야 할까: 정답률·답변율·중대 오류를 함께 재는 법

AI가 질문 열 개 중 여덟 개를 맞혔다고 해도, 남은 두 개를 자신 있게 잘못 답했다면 고객 지원에 바로 투입하기 어렵습니다. 반대로 불확실한 두 질문을 담당자에게 넘겼다면 같은 모델도 전혀 다른 서비스가 됩니다. 업무용 AI를 평가할 때는 정답률과 함께 ‘얼마나 답했는가’, ‘답한 것 중 얼마나 틀렸는가’, ‘넘긴 질문이 정말 어려웠는가’를 나눠 봐야 합니다. 이 글은 새 모델 출시 소식이 아니라, 2026년 9월 30일 확인한 공식 평가·위험관리 자료를 바탕으로 답변 보류를 평가에 넣는 방법을 정리합니다.

정답률의 빈틈

모든 질문에 대답하도록 강제한 평가에서는 정확도가 비교하기 쉽습니다. 하지만 실제 상담에서는 잘못 안내한 환불 기한 한 건이 문장 표현이 어색한 열 건보다 큰 손해를 만들 수 있습니다. 따라서 먼저 오류의 비용을 정의해야 합니다. 주소 오타 수정, 결제 취소, 의료 판단을 같은 ‘틀림’으로 묶으면 평균 점수는 높아도 위험한 부분이 가려집니다.

Anthropic의 평가 문서는 성공 기준을 구체적이고 측정 가능하며 달성 가능하고 실제 목적에 맞게 정의하고, 정확도뿐 아니라 개인정보·지연·가격 등 여러 축을 함께 평가하라고 설명합니다. NIST AI RMF는 AI의 설계·개발·사용·평가에서 신뢰성과 위험을 함께 다루는 자발적 프레임워크입니다. 아래 지표와 환불 사례는 그 방향을 작은 서비스에 적용한 필자의 설계 예시이며, 두 기관이 정한 공통 인증 기준은 아닙니다.

보류도 결과다

출력을 ‘답변’, ‘확인 요청’, ‘담당자 이관’으로 구분합니다. 필요한 자료가 빠졌다면 구매일을 묻고, 문서끼리 충돌한다면 보류하며, 권한이 필요한 조치라면 사람에게 넘깁니다. 보류는 모델이 “자신감이 낮다”고 말하는 것과 다릅니다. 정해진 업무 조건을 만족하지 못했다는 시스템의 판단이어야 합니다.

예를 들어 환불 기한 안내에서는 정책 문서의 적용 국가와 시행일, 주문의 결제일을 모두 확인해야 합니다. 주문일이 없으면 답변을 만들지 않고 추가 정보를 요청합니다. 문서에 예외가 존재하지만 질문이 그 예외에 해당하는지 알 수 없다면 담당자에게 넘깁니다. 참고문서에 링크가 있다는 이유만으로 답변을 승인하지 않습니다. 그 문서가 실제 주장과 적용 범위를 뒷받침하는지를 확인해야 합니다.

세 지표를 나눈다

첫째는 답변율입니다. 전체 평가 사례 중 바로 답한 사례의 비율입니다. 둘째는 답변 정확도입니다. 보류를 제외하고 실제로 답한 사례 중 맞힌 비율입니다. 셋째는 위험한 오답률입니다. 전체 사례 또는 실제 답변 수 중 중대 오류가 차지하는 비율을 재되, 분모를 보고서에 반드시 적습니다. 답변율을 줄이면 답변 정확도가 좋아질 수 있으므로 어느 하나만 목표로 삼으면 안 됩니다.

예를 들어 가상의 100문항에서 60개에 답하고 그중 57개가 맞았다면 답변율은 60%, 답변 정확도는 95%입니다. 나머지 40개가 모두 불필요한 보류였다면 운영비와 대기 시간이 크게 늘어납니다. ‘모두 보류’ 전략이 안전 점수에서 승리하지 못하도록 쉬운 문제의 불필요한 보류율과 담당자 처리량도 같이 봅니다. 이 숫자는 계산 설명용이며 실제 모델의 성능 수치가 아닙니다.

평가 묶음 만들기

먼저 업무 담당자가 질문과 정답, 답변 가능 여부, 중대 오류 조건을 작성합니다. 정상 질문만 모으지 말고 날짜가 빠진 질문, 서로 다른 국가의 정책이 섞인 질문, 오래된 문서, 문서에 없는 예외를 포함합니다. 민감정보는 제거한 가상 주문번호로 바꾸고, 각 사례에 어떤 문서 버전이 근거인지 기록합니다.

프롬프트를 수정할 때 보는 개발용 사례와 최종 판단에 쓰는 보류된 평가 세트를 분리합니다. 같은 문장을 조금 바꾼 사례를 양쪽에 나누면 사실상 정답을 미리 본 효과가 생길 수 있습니다. 가능한 경우 정책 유형·문서 묶음 단위로 나눕니다. 작은 세트는 초기 오류를 찾는 데 유용하지만 배포 성능의 통계적 보증으로 취급하지 않습니다.

작은 계산 예시

다음은 모델을 호출하지 않고, 사람이 작성한 가상 판정 여섯 건에서 지표를 계산하는 교육용 Python 예제입니다. AI 추론 성능을 시험한 것이 아니라 평가 계산 로직만 로컬 실행으로 확인했습니다. Python 3가 있는 macOS·Linux에서는 아래 블록을 실행할 수 있고, Windows에서는 코드를 eval_demo.py에 저장한 뒤 py eval_demo.py로 실행하면 됩니다. 패키지 설치·API 키·네트워크 연결은 필요하지 않습니다.

python3 - <<'PY'
rows = [
    {"action": "answer", "correct": True, "severe": False, "answerable": True},
    {"action": "answer", "correct": True, "severe": False, "answerable": True},
    {"action": "answer", "correct": False, "severe": True, "answerable": False},
    {"action": "hold", "correct": False, "severe": False, "answerable": False},
    {"action": "hold", "correct": False, "severe": False, "answerable": True},
    {"action": "answer", "correct": True, "severe": False, "answerable": True},
]
answered = [r for r in rows if r["action"] == "answer"]
answerable = [r for r in rows if r["answerable"]]
coverage = len(answered) / len(rows)
accuracy = sum(r["correct"] for r in answered) / len(answered) if answered else None
severe_rate = sum(r["severe"] for r in answered) / len(rows)
unneeded_hold = sum(r["action"] == "hold" for r in answerable) / len(answerable)
print(f"coverage={coverage:.3f}")
print(f"answered_accuracy={accuracy}")
print(f"severe_per_all={severe_rate:.3f}")
print(f"unneeded_hold_per_answerable={unneeded_hold:.3f}")
PY

예상 결과는 coverage=0.667, answered_accuracy=0.75, severe_per_all=0.167, unneeded_hold_per_answerable=0.250입니다. 세 번째 사례는 답하면 안 되는 질문에 중대한 오답을 낸 것으로 설정했습니다. 다섯 번째는 답할 수 있는데 보류했습니다. 독자가 바꿀 부분은 rows의 사례와 판정이며, 판정 근거는 별도 평가 기록에 남겨야 합니다. accuracy가 None인 경우는 답변이 없다는 뜻이지 정확도가 100%라는 뜻이 아닙니다.

판정표를 고정한다

자유서술 답변을 정확한 문자열 하나로만 비교하면 표현이 다른 정답을 놓칩니다. 반대로 다른 AI에게 “좋은 답변인가?”라고만 물으면 길고 그럴듯한 오답이 통과할 수 있습니다. 환불 기한, 적용 조건, 문서 근거, 금지된 약속을 항목별로 평가하고 두 사람이 일부 표본을 독립적으로 채점해 기준의 모호함을 찾습니다.

자동 채점은 분류값·날짜처럼 명확한 필드에 먼저 적용하고, 근거가 실제 주장을 뒷받침하는지는 사람 검수를 병행합니다. 모델 채점을 쓴다면 채점 프롬프트와 모델 버전도 함께 고정하고 사람 판정과의 불일치를 기록합니다. 후보 모델의 자기보고 확신도 0.9를 곧바로 정답 확률 90%로 읽어서는 안 됩니다. 별도 보정과 검증 없이 보류 임계값을 그 숫자 하나로 정하지 않습니다.

비용과 데이터

실서비스 평가에는 개인정보 처리 권한과 보존 기한을 먼저 정합니다. 고객 원문을 외부 모델에 보내는 경우 제공자의 보관·학습 이용 조건, 지역, 계약을 확인해야 합니다. 이 글의 계산 코드는 로컬 메모리에서만 실행되지만 실제 모델 평가로 연결하면 API 비용과 데이터 전송이 새로 발생합니다. 채점 모델을 추가하면 입력·출력 토큰과 반복 실행 비용도 증가합니다.

보류 후 사람의 처리 시간까지 측정해야 ‘안전하지만 쓸 수 없는’ 시스템을 피할 수 있습니다. 고객에게는 왜 추가 확인이 필요한지 설명하되 내부 문서나 다른 고객의 정보를 노출하지 않습니다. 답변율을 높이려고 접근 권한을 넓히는 방식은 평가 개선이 아니라 새로운 위험을 만드는 변화입니다.

오류와 되돌리기

평가 점수가 갑자기 오르면 모델이 아니라 정답 파일이 바뀌었는지부터 확인합니다. 중복 사례, 보류를 정답으로 세는 집계 오류, 틀린 분모, 개발 세트와 평가 세트 혼합이 흔한 원인입니다. 코드의 여섯 사례는 계산을 이해하기 위한 최소 예시이므로 서비스 승인 기준으로 재사용하면 안 됩니다.

배포는 작은 비율로 시작하고 기존 모델·프롬프트·정책 버전을 보존합니다. 중대한 오답이 확인되면 해당 범주의 자동 답변을 중단하고 사람 처리로 전환합니다. 복귀 시에는 코드만 되돌리는 것이 아니라 문서 인덱스와 보류 규칙도 같은 검증된 조합으로 맞춥니다. 위 계산 예제는 설치 파일이나 서버 설정을 만들지 않으므로 종료하면 끝이며, 저장한 예제 파일만 삭제하면 됩니다.

평가의 목적은 모든 질문에 답하는 AI를 뽑는 것이 아닙니다. 어떤 질문에 답하고 어떤 질문을 넘기는지 설명할 수 있는 서비스를 만드는 것입니다. 정답률 옆에 답변율과 중대 오류를 적기 시작하면 모델 선택과 운영 정책이 비로소 같은 표에서 논의됩니다.

출처

• Anthropic: 성공 기준과 평가 설계
• NIST: AI Risk Management Framework