LLM 답변을 “정확도 점수”로만 보게 되면, 나중에 서비스에서 더 큰 문제를 만나요. 점수는 높아 보여도, 실제 사용자 상황에선 근거가 없거나 조건을 바꿨을 때 무너지는 답이 섞이기 쉽거든요.
그래서 정확도보다 먼저 확인할 건 “어떤 실패가 실제로 발생하느냐”예요. 아래 4가지 테스트는 그 실패를 빨리 드러내는 방식으로 설계합니다.
정확도 점수보다 먼저 확인할 4가지 검증 테스트
- 근거 확인: 답이 ‘왜 그렇게 말하는지’가 재현 가능한지 본다.
- 자극(반사실) 테스트: 질문/조건을 살짝 바꿨을 때 버티는지 확인한다.
- 수치·사실 검증: 날짜/단위/계산 같은 “딱 잘라 틀리면” 바로 잡는다.
- 일관성 정렬: 같은 정보가 출력 전반에서 모순 없이 이어지는지 본다.
테스트 1) “근거가 답을 지탱하는지”를 먼저 보세요
점수표에선 정답처럼 보여도, 실제론 근거가 빈약한 경우가 많아요. 특히 RAG(검색 기반 생성)나 문서 기반 답변일수록 “답은 그럴듯한데 근거가 안 맞는” 일이 반복됩니다.
이 테스트의 목표는 근거-답 연결이 끊기는 순간을 잡는 거예요.
설계 방법(간단 버전)
- 대표 질문 10~30개를 뽑아 “기대 주장(무엇이 맞아야 하는지)”을 목록으로 만든다.
- LLM 답변을 수집한 뒤, 주장 단위로 분리한다.
- 각 주장에 대해 “근거로 제시된 문장/출처가 실제로 그 주장과 일치하는지”만 판단한다.
성공 기준 예시
- 근거가 있어야 할 질문에서, 근거 없이 결론만 찍는 답변 비율이 낮아야 해요.
- 근거를 인용하더라도 “문장 방향이 뒤집힌” 경우(예: 반대로 말한 인용)는 즉시 감점합니다.
이런 류의 문제는 RAG에서 특히 자주 나오는데, RAG에서 인용이 안 맞을 때 원인, 벡터DB보다 먼저 확인할 5가지 흐름도 같이 보면 빨리 정리돼요.
테스트 2) 질문을 “살짝” 바꿔서 반사실로 무너지는지 보세요
환각은 가끔 “정확한 것처럼 보이는 순간”에 숨어요. 그래서 그냥 같은 질문만 반복하면 놓치기 쉽습니다.
이 테스트는 질문을 조금만 바꿔도 답이 흔들리는지 확인해요. 흔들리면 그 답은 조건 일반화가 약한 상태일 가능성이 큽니다.
자극 세트(추천)
| 자극 유형 | 질문 변경 예시 | 기대하는 판정 |
|---|---|---|
| 시간/버전 치환 | “2023년 기준이면?” ↔ “현재 기준이면?” | 달라져야 할 부분이 그대로면 위험 |
| 조건 반전 | “예외가 있나요?” ↔ “예외는 없나요?” | 예외 존재 여부가 모호하게 뭉개지면 위험 |
| 단위/스케일 변경 | “kg” ↔ “g”, “월” ↔ “주” | 단위 변환이 따라오지 않으면 위험 |
| 대상 범위 축소 | “모든 사용자” ↔ “초보자만” | 권장안이 동일하면 과잉 일반화 |
체크 포인트
- 질문 조건이 바뀌면 결론도 바뀌어야 하는데 그대로면 감점
- 특정 표현(“~인 것으로 보입니다”)만 늘고 근거는 유지되면 위험 신호
- 유사 질문군에서 같은 실수 패턴이 반복되면 개선 우선순위가 보입니다
만약 “LLM이 답을 자꾸 그럴듯하게 틀리는” 패턴을 줄이는 체크리스트가 필요하면, LLM이 답을 자꾸 ‘그럴듯하게’ 틀릴 때, 환각 줄이는 체크리스트 6가지와 원인별 해결 순서도 같이 참고해보세요.
테스트 3) 수치·사실은 “계산/단위/출처”로 잘라서 검증하세요
환각 중 상당수는 수치나 사실관계에서 터집니다. 그래서 정확도 점수보다 먼저, “틀리면 바로 티 나는 구간”을 별도 테스트로 떼어내는 게 좋아요.
이 테스트는 문장 흐름 평가가 아니라, 검증 가능한 항목만 골라 확인합니다.
검증 항목 5가지
- 날짜/기간: 특정 연도·기간이 들어가면 실제 출처가 맞는지 확인
- 단위: g/kg, %, km/mi, 통화 등 변환을 요구하는지 점검
- 계산: “합계/비율/증가분”이 나오면 계산 과정을 요구
- 제한 조건: “~인 경우에만” 같은 조건이 생략되지 않는지 확인
- 출처 범위: 출처가 전체 주장에 커버되는지(부분만 커버하는지) 확인
예를 들어 “대략” 표현을 허용하는 질문과, “정확한 수치”를 요구하는 질문을 섞으면 평가가 흔들립니다. 문서/데이터 기반 답변이라면 특히 범위를 분리해두세요.
테스트 4) 같은 내용을 다른 문장으로 말해도 모순이 없는지 ‘정렬’로 확인하세요
일관성 테스트는 “답이 말이 되냐”가 아니라, 서로 맞물리는 정보가 안 맞는지를 봅니다.
LLM은 한 번 확신을 잡으면, 다음 문장에서 근거 없이 분위기로 밀어붙이기도 해요. 그래서 출력 안에서 모순을 찾아내는 방식이 효과적입니다.
정렬 테스트(추천 체크 순서)
- 답변에서 핵심 정보 3~5개를 뽑는다(예: 결론, 조건, 수치, 주의사항).
- 그 정보가 문장/불릿에서 반복될 때 값·조건이 동일한지 확인한다.
- 근거가 있다면 “근거 문장”과 값이 일치하는지 교차 확인한다.
- 주의사항(예: “다만 ~에서는 제외”)이 결론을 제한하는데, 결론부에서 그 제한이 무시되진 않는지 확인한다.
참고로 이런 검증 프레임은 자연어 처리에서 출력 품질을 다룰 때도 자주 쓰는 관점이에요. 배경이 더 필요하면 자연어 처리도 한 번 훑어보면 좋아요.
자주 묻는 질문
정확도 점수는 아예 안 써도 되나요?
아니요. 다만 먼저 써야 하는 건 “실패 유형을 줄이는 테스트”예요. 점수는 전체 경향을 보여주지만, 실제 장애로 이어지는 근거/조건/수치/모순 같은 문제를 초기에 잡아주진 못할 때가 많아요.
자극 테스트에서 ‘얼마나’ 바꿔야 하나요?
크게 바꿀수록 다른 질문이 돼버려요. 보통은 시간/단위/조건처럼 의미는 유지하면서 제약만 바꾸는 방식이 가장 실용적입니다.
근거 확인 테스트는 사람 검수가 꼭 필요하나요?
초기엔 사람이 제일 정확합니다. 대신 주장 단위로 쪼개고, 근거의 일치/불일치 기준을 문서화하면 자동화 범위를 점점 넓힐 수 있어요.
이 4가지만 하면 환각이 완전히 사라지나요?
완전히 사라지진 않습니다. 대신 “어떤 상황에서, 어떤 방식으로 틀리는지”가 빨리 드러나서 수정 우선순위를 명확히 해줍니다.
마무리: 테스트는 ‘점수’가 아니라 ‘실패를 줄이는 구조’로 설계하세요
LLM 답변 검증을 잘하려면, 먼저 근거를 확인하고 자극에서 무너지는지 보세요. 그리고 수치·사실은 잘라서 검증하고, 출력 전체는 모순 없이 정렬되는지 확인하면 됩니다.
한 번에 완벽한 테스트를 만들 필요는 없어요. 대표 질문 몇 개로 시작해서, 위 4가지 실패 유형 중 어디에서 문제가 반복되는지만 먼저 잡아보세요.
