LLM 5종이 팩트체크 67%에서 갈렸다, AI 검색의 검증 비용

Lenz Research는 2026년 5월 21일 frontier LLM 팩트체크 불일치 연구를 공개했습니다. 이 연구는 AI 검색 제품이 피하기 어려운 질문을 던집니다. 모델이 답을 그럴듯하게 쓰는지가 아니라, 같은 실제 claim을 두고 frontier 모델들이 같은 verdict를 내리는지입니다. 연구 결과는 거칠게 말하면 이렇습니다. 1,000개의 실제 사용자 팩트체크 청구 중 672개, 즉 67%에서 다섯 모델이 같은 결론에 도달하지 못했습니다.

연구 대상 모델은 GPT-5.4, Claude Opus 4.7, Gemini 3 Pro, Gemini 3 Pro + Search, Sonar Pro입니다. 각 모델은 같은 claim과 날짜 기준점을 받고 True, Mostly True, Misleading, False 중 하나만 골라야 했습니다. 설명을 붙이거나 유보하는 선택지는 없었습니다. Lenz는 이 설정을 통해 모델의 장문 설득력이나 citation 품질이 아니라 최종 라벨의 일관성을 분리해 보려 했습니다.

원문 표의 첫 줄은 전체 그림을 압축합니다. 다섯 모델이 모두 동의한 claim은 328개, 33%입니다. 한 모델만 다수결에서 벗어난 claim은 224개, 22%입니다. 두 모델이 벗어난 claim은 316개, 32%입니다. 엄격한 다수결이 생기지 않은 2-2-1 또는 2-1-1-1 split은 132개, 13%입니다. Lenz는 ordinal Krippendorff's alpha를 0.639로 보고했습니다. 모델들이 무작위로 답한 것은 아니지만, 하나의 교체 가능한 판정자로 다루기에는 일관성이 부족하다는 수치입니다.

더 불편한 숫자는 34%입니다. Lenz는 343개 claim에서 가장 멀리 갈라진 두 모델 사이에 2개 이상의 bucket gap이 있었다고 적었습니다. True와 False처럼 양끝으로 갈라지는 사례만을 말하는 것은 아니지만, 단순한 표현 차이나 confidence 보정으로 보기 어려운 라벨 차이가 1,000건 중 3분의 1 이상에 있었다는 뜻입니다. AI 검색 화면에서 "출처를 확인했습니다"라는 문장을 붙여도, 같은 claim에 대해 모델별 최종 verdict가 달라질 수 있습니다.

이 연구가 일반 벤치마크와 다른 부분은 데이터 출처입니다. Lenz는 자사 팩트체킹 플랫폼에 실제 사용자가 제출한 최근 claim 1,000개를 사용했습니다. 원문은 이 claim들이 2026년 2월 15일보다 오래되지 않았고, private claim, staff 또는 API submission, pending 또는 hidden 상태, near-duplicate를 제외했다고 설명합니다. 공개 벤치마크처럼 정답 라벨이 붙은 데이터셋을 모델이 학습했을 가능성을 줄이기 위한 설계입니다.

여기서 주의할 점은 Lenz가 모델 다수결을 ground truth로 쓰지 않았다는 사실입니다. 원문은 다수 verdict가 때로 틀릴 수 있고, 소수 모델이 맞을 수도 있다고 못 박습니다. 그래서 이 연구는 "GPT-5.4가 Claude보다 팩트체크를 잘한다" 같은 리더보드가 아닙니다. 측정 대상은 정확도보다 구조입니다. 같은 claim이 들어왔을 때 frontier panel이 얼마나 자주 같은 bucket에 도달하지 못하는지입니다.

CSV를 내려받아 모델별 라벨 분포를 보면, 불일치의 한 원인이 라벨 사용 습관이라는 점도 드러납니다. Gemini 3 Pro는 1,000개 중 True 539개, False 401개를 골랐고 Mostly True와 Misleading은 각각 30개에 그쳤습니다. Gemini 3 Pro + Search도 True 520개, False 351개로 양끝 라벨 비중이 높았습니다. 반대로 Claude Opus 4.7은 Mostly True 258개, Misleading 193개를 사용했고, Sonar Pro도 middle bucket을 더 넓게 썼습니다.

이 차이는 모델 하나가 더 조심스럽다는 평가로 바로 이어지지 않습니다. Lenz의 prompt는 라벨 하나만 출력하게 했고, retrieval-enabled 모델이 어떤 자료를 찾았는지는 통제하지 않았습니다. 다만 제품 개발자에게는 충분히 실무적인 신호입니다. 같은 근거 검색이 붙어도 모델이 Misleading을 넓게 쓰는지, False로 강하게 자르는지, Mostly True로 완충하는지에 따라 사용자에게 보이는 위험도와 후속 행동이 바뀝니다.

AI 검색 제품은 이미 이 문제를 겪고 있습니다. 검색 결과 위에 요약 답변을 올리는 화면, 고객 문의를 자동 판정하는 support agent, 사내 위키와 로그를 엮어 장애 원인을 요약하는 RAG 도구는 모두 claim을 판정합니다. "이 정책이 현재 적용됩니까", "이 라이브러리 버전이 취약합니까", "이 계약 조항이 특정 고객군에 유효합니까" 같은 질문은 단순 텍스트 생성이 아니라 판정 작업입니다. Lenz 연구는 판정 작업에서 모델 간 agreement를 별도 지표로 추적해야 한다는 쪽에 힘을 실어줍니다.

특히 팩트체크와 compliance 도메인에서는 citation이 충분조건이 아닙니다. 모델이 같은 URL을 가져와도 claim을 어떤 시간 기준으로 읽는지, "mostly true"와 "misleading"의 경계를 어디에 두는지, 불완전한 출처를 어떻게 벌점 처리하는지에 따라 verdict가 달라집니다. Lenz가 claim마다 "as of YYYY-MM-DD" anchor를 넣은 이유도 이 때문입니다. 날짜가 빠지면 정치, finance, legal, tech claim에서는 같은 문장도 사실 여부가 바뀔 수 있습니다.

연구의 appendix는 이 문제가 추상적인 통계가 아니라는 점을 보여줍니다. 예시 claim 중에는 World Bank의 Nigeria portfolio 규모, 특정 scientific claim, India 또는 Kenya 관련 정치 claim, tech 조직 책임 범위 같은 항목이 있습니다. 일부 사례에서는 GPT-5.4가 True, Gemini 3 Pro가 False, Sonar Pro가 Misleading을 고르는 식으로 max bucket distance 3이 나옵니다. 사용자에게는 하나의 질문이지만, 시스템 안에서는 서로 다른 판정 체계가 부딪친 셈입니다.

다만 이 결과를 "LLM 팩트체크는 쓸 수 없다"로 단정하면 연구가 말한 범위를 벗어납니다. Lenz는 human-labeled ground truth를 이번 snapshot에 넣지 않았습니다. 원문 FAQ는 follow-up study에서 사람 라벨을 붙여 frontier panel과 Lenz verdict를 비교하겠다고 설명합니다. 현재 v1.0은 모델이 틀린 비율을 확정하지 않습니다. 한 claim에서 다섯 모델이 갈렸다면 적어도 하나의 verdict는 4개 bucket rubric 아래에서 label-inconsistent라는 하한만 말할 수 있습니다.

이 제한은 오히려 개발팀에 더 현실적인 과제를 남깁니다. 운영 중인 AI 검색 또는 검증 제품은 언제나 정답 라벨 없이 답해야 합니다. 정답을 미리 아는 상황이면 제품이 필요 없습니다. 따라서 시스템은 "모델이 확신합니다"보다 "모델들이 얼마나 같은 판정에 도달했는가", "출처가 같은 결론을 지지하는가", "시간 기준이 claim과 맞는가", "middle bucket이 왜 선택됐는가"를 저장하고 표시해야 합니다.

Hacker News 반응도 이 지점에 집중됐습니다. 해당 글은 2026년 5월 28일 올라와 Algolia API 기준 다음 날 489 points와 341 comments를 기록했습니다. 토론은 단일 모델 팩트체킹의 위험, 검색 결합 모델도 같은 결론을 보장하지 못한다는 점, 팩트체크 라벨 자체가 사람에게도 어려운 작업이라는 반론으로 갈렸습니다. 이 반응은 원문 제한과 맞물립니다. Lenz는 AVeriTeC 같은 human-annotated fact-check corpus에서도 annotator agreement가 완벽하지 않다고 적었습니다.

개발자가 당장 바꿀 수 있는 설계는 세 가지입니다. 첫째, fact-checking pipeline에서 최종 verdict와 함께 dissent metadata를 저장해야 합니다. 단일 모델을 쓰더라도 temperature, prompt version, retrieval trace, timestamp를 남기지 않으면 재현 가능한 검증이 어렵습니다. 둘째, 다중 모델을 쓴다면 majority label만 노출하지 말고 vote distribution과 bucket distance를 함께 계산해야 합니다. no-majority split 13%는 자동 발행이나 자동 차단 같은 hard action에 별도 정책이 필요하다는 숫자입니다.

셋째, 사용자 화면에서 "검증됨"이라는 단일 배지를 줄여야 합니다. claim이 legal, health, finance, politics에 걸쳐 있으면 false positive와 false negative 비용이 다릅니다. Lenz CSV의 domain 분포는 General 179개, Health 171개, Politics 168개, Science 151개, History 131개, Tech 77개, Finance 75개, Legal 48개입니다. 같은 disagreement rate라도 health claim의 UI와 tech claim의 UI는 달라야 합니다.

AI 검색 제품이 이 데이터를 무시하기 어려운 이유는 비용 구조에도 있습니다. 한 번 더 모델을 호출하면 consensus가 생길 것 같지만, Lenz 결과는 "다섯 모델을 불렀는데도 67%가 갈렸다"는 반대 사례입니다. 다중 모델 호출은 latency와 비용을 늘리고, 제품은 갈라진 verdict를 처리할 정책을 가져야 합니다. 이 정책이 없으면 비용은 증가하지만 사용자에게 보이는 결과는 여전히 한 문장 답변입니다.

RAG 팀에는 평가 항목도 바뀝니다. 지금까지 많은 내부 평가는 answer correctness, citation recall, groundedness score에 머물렀습니다. Claim verification workflow에는 disagreement rate, max bucket distance, no-majority rate, domain별 abstain 또는 escalation 비율이 들어가야 합니다. Lenz v1.0은 abstain bucket을 일부러 빼고 4개 라벨을 강제했습니다. 실제 제품에서는 모델이 유보해야 하는 claim을 어떻게 분리할지도 별도 설계가 됩니다.

이 연구를 읽는 가장 보수적인 태도는 "모델이 틀렸다"보다 "판정 인터페이스가 덜 성숙하다"입니다. Lenz의 follow-up이 human labels를 붙이면 accuracy 이야기를 더 할 수 있습니다. 지금 공개된 snapshot만으로도 단일 LLM 답변을 팩트체크처럼 포장하는 제품 문구는 조심해야 합니다. 사용자 claim 1,000건 중 672건에서 frontier panel이 같은 라벨을 내지 못했다면, 제품은 그 불일치를 숨기지 않는 방향으로 설계돼야 합니다.

마지막으로 이 결과는 AI 개발 도구에도 연결됩니다. 코딩 에이전트가 의존성 취약점, 라이선스 조건, 릴리스 노트 변경, 클라우드 장애 원인을 판정할 때도 같은 문제가 생깁니다. "검색해서 확인했다"는 로그는 충분하지 않습니다. claim의 날짜, 출처 선택, verdict rubric, dissent 처리, 사람이 검토해야 할 threshold가 함께 있어야 합니다. Lenz v1.0의 67%는 AI 검색의 실패 선언이 아니라, 검증 제품이 실제로 구현해야 할 비용 항목입니다.