AI 팩트체크 판정을 어느 모델에 맡길까: 2026년 9월 검증 기록에서

결론부터: 정답률만 보고 고르지 않는다

판정에 쓸 모델은 정답을 미리 준비한 테스트 문제의 정답률만으로 고르지 않는 편이 안전합니다. Rootpublish의 검증에서는 합성 데이터에서 97% 이상의 정답률을 낸 모델 중 일부가, 실제 AI 글에서 발견된 자사 서비스 과장 4건을 한 건도 잡아내지 못했습니다. 기록에는 “합성 데이터에서의 성적이 실제 글에서의 성적을 보장하지 않았다”고 적혀 있습니다.

이번 검증은 6개 사이트, 사이트당 최대 12개 글이라는 작은 표본이며, 사람의 확인도 끝나지 않았습니다. 따라서 여기서 소개하는 결과는 ‘이 모델이 언제나 뛰어나다’는 근거가 아니라, 모델을 고를 때 무엇을 확인해야 하는지 생각하는 재료로 읽어 주세요.

검증에서 무엇을 확인했나

여기서 말하는 확인은 일반적인 사실의 진위를 조사하는 것이 아닙니다. 공개 중인 페이지를 단락으로 나누고, 회사명·서비스명이나 ‘당사’, ‘저희’ 등을 포함한 단락을 골라, 회사 소개·요금·서비스 페이지의 기재 내용과 어긋나지 않는지 대조하는 것입니다. 각 사이트에서 대상으로 삼은 것은 최신 글 12개까지이며, 불일치 판정은 Claude Opus로 하고 후보는 Claude가 읽고 확인했습니다. 사람이 확인한 것은 일부에 그칩니다.

모델 비교에서는 5개 모델에 같은 281문제를 판정하게 했습니다. 정답을 준비한 합성 데이터 102문제와, 공개 중인 페이지로 만든 179문제입니다. 어느 문제에 정답이 준비되어 있는지는 판정 모델에 알리지 않았습니다. 참여한 모델은 Claude Opus 5.5, Sonnet 5, Haiku 4.5, Fable 5.1과 Codex를 통한 GPT입니다. Gemini CLI는 인증 설정이 부족해 참여하지 않았습니다.

합성 데이터에서는 차이가 작았다

합성 데이터 102건에서의 정답률은 Claude Opus 5.5와 Fable 5.1이 100%, Sonnet 5가 99%, Codex를 통한 GPT가 97%, 판정 전용 모델 Jev가 97%, Haiku 4.5가 88%였습니다. Haiku 4.5를 제외하면 차이는 몇 퍼센트포인트에 그칩니다.

5개 모델의 다수결은 합성 데이터에서 정답률 99%, 불일치 지적의 정밀도와 재현율이 모두 100%였습니다. 정밀도는 ‘지적한 것 가운데 실제로 불일치였던 비율’, 재현율은 ‘실제로 있는 불일치 가운데 지적한 비율’입니다.

공개 페이지로 만든 179문제에는 정답이 준비되어 있지 않아, Jev의 답과 다수결의 일치율로 비교했습니다. 일치율은 86.6%였고, 다수결이 갈린 28문제 가운데 26문제는 ‘일치’와 ‘언급 없음’ 중 어느 쪽으로 볼지의 차이였습니다. 글의 기재가 회사 정보와 맞는지, 애초에 같은 내용을 말하고 있지 않은지의 경계에서 모델의 판단이 갈리기 쉽다는 것을 알 수 있습니다.

실제 글에서 차이가 드러났다

실제 AI 글에서 발견된 자사 서비스 과장 4건은 Jev와 Sonnet이 한 건도 잡아내지 못했고, Opus는 잡아냈습니다. 합성 데이터에서 비슷한 성적을 낸 모델들이 실제 글에서는 결과가 뚜렷하게 갈린 셈입니다.

발견된 불일치는 단순한 숫자 오류보다 자사 서비스의 범위나 조건을 과장한 기재가 많았습니다. 무료 진단에서 제공하는 범위를 실제보다 넓게 쓰거나, 서비스를 다른 이름으로 쓰거나, 요금 페이지에는 ‘최소 계약 기간 없음’인데 최소 계약 기간을 ‘3개월’로 쓰거나, 자사 고객 사례의 요금이 요금 페이지의 가장 저렴한 요금제보다 낮은 경우입니다. 합성 데이터처럼 한 문장에 하나의 주장이 분명히 쓰인 문제와는 성격이 다릅니다.

6개 사이트 감사에서는 3개 사이트에서 회사 정보와의 불일치가 발견되었습니다. AI로 글을 대량 생산하는 기업 블로그에서는 12개 글에서 4건(그중 1건은 판단이 갈리는 사례), AI 관련 칼럼을 내는 기업 한 곳에서는 12개 글에서 2건이었습니다. 직접 쓴 개인 블로그와, 글 끝의 자사 안내를 정형화된 문구로 만든 기업 두 곳에서는 뚜렷한 불일치가 발견되지 않았습니다.

Rootpublish 자사 사이트에서도 322개 단락에서 2건이 발견되었습니다. WordPress 버전 소개 페이지의 헤드라인인 일본어 「自動運営」(자동 운영)과 영어 “On autopilot”이 공개 전에 사람의 승인이 필요하다는 제품 사양과 어긋난다고 판정되어, 헤드라인을 일본어 「一次情報で育てる」(1차 정보로 키운다)와 영어 “Grown from what you know”로 바꿔 공개했습니다. 공개 후 같은 페이지의 129개 단락을 다시 감사한 결과, 불일치는 0건이었습니다.

판정 전용 모델 Jev의 강점과 약점

Jev는 선택지마다 확률을 돌려주는 판정 전용 모델입니다. 한 문장에 하나의 주장이 있는 합성 데이터에서는 숫자 불일치, 단위를 바꾼 표현, 과거 요금에 대한 언급, 이중 부정을 포함한 63쌍을 모두 올바르게 판정했습니다. 짧고 분명한 주장끼리 비교하는 작업에는 강하다고 할 수 있습니다.

한편 회사 정보의 조합을 모두 대조하자, ‘승인’처럼 단어가 겹치는 회사 정보끼리 잘못된 지적이 나왔습니다. 정밀도는 한 쌍씩 묻는 방식에서 0.91, 한꺼번에 묻는 방식에서 0.82였습니다. 실제 AI 글 12개에서는 후보로 든 22쌍이 모두 잘못된 지적이었고, 자사 서비스 과장 4건은 후보에 들어가지 않았습니다. 이번 검증에서는 겹치는 단어에 반응하기 쉽고, 문맥 속에서 범위나 조건을 넓혀 쓴 기재는 잡아내기 어려운 경향이 있었습니다.

지시문의 한 문장으로 답이 바뀌었다

모델의 성능뿐 아니라 판정 지시문을 쓰는 방식도 결과를 좌우했습니다. Sonnet 5는 실제 AI 글에서 고른 114개 단락을 판정하고 불일치를 한 건도 제시하지 않았습니다. 서비스를 다른 이름으로 쓴 단락을 검토하기는 했지만, 지시문에 있던 “같은 단어라도 가리키는 대상이 다르면 관계를 판단하지 않는다”는 한 문장을 이유로 불일치에서 제외했습니다. 같은 지시문으로 Opus는 불일치라고 판정했습니다.

이 예에서 알 수 있는 것은, 어떤 모델이 놓쳤을 때 그 원인이 모델에 있는지 지시문에 있는지를 나누어 확인해야 한다는 점입니다. 잘못된 판정을 줄이려고 넣은 한 문장이 찾고 싶은 불일치까지 제외해 버리는 경우가 있습니다.

저렴한 모델로 걸러 내는 설계가 놓친 이유

비용을 줄이는 방법으로, 판정 전용 모델 Jev로 확률 0.3 이상인 후보만 고르고 이를 다수결로 확인하는 2단계 설계도 검증했습니다. 합성 데이터에서는 정밀도와 재현율이 모두 100%였고, 공개 페이지에서는 확인이 필요한 조합이 875쌍 중 9쌍(약 1%)으로 줄었습니다.

그러나 실제 AI 글에서는 이 설계로도 놓친 것이 남았습니다. 1단계의 Jev가 자사 서비스 과장을 후보에 넣지 않았기 때문에, 2단계 모델이 아무리 정확해도 판정할 기회가 없었던 것입니다. 2단계 설계에서는 1단계에서 떨어진 불일치를 나중에 되찾을 수 없습니다.

그래서 Rootpublish는 자사에 관해 서술한 단락을 단어 조건으로 고르고, 이를 Opus로 판정하는 방식으로 바꾸었습니다. 후보를 좁히는 역할을 모델의 판단이 아니라 단어 조건에 맡긴 형태입니다.

비용 기준

Jev로 12개 글, 1,212개 단락을 모두 대조한 비용은 공개 단가 기준으로 약 0.25달러였습니다. 다만 이 방법으로는 실제 불일치를 잡아내지 못했습니다.

자사에 관해 서술한 단락(전체의 약 10%)만 골라 Opus로 판정하는 방식은 글 1개당 약 0.05달러로 추산합니다. 이는 추산치이며, 추론에 쓰인 토큰 수는 측정하지 않았습니다. 실제 비용은 사용하는 모델의 요금 체계와 선택되는 단락 수에 따라 달라집니다.

이번 검증의 한계

이번 감사는 6개 사이트, 사이트당 최대 12개 글이라는 작은 표본입니다. 많은 판정은 Opus의 판정과 Claude의 확인에 그치며, 사람의 확인은 끝나지 않았습니다. 실제 글에서의 비교 결과도 사람이 확정한 정답과의 비교가 아니라는 점에 주의하세요.

단락을 고르는 단어 조건에도 약점이 있습니다. 글과 회사 정보에서 제품을 부르는 이름이 다르면 자사에 관해 서술한 단락을 놓칠 수 있습니다. 또한 불일치가 발견되더라도 기준이 되는 회사 정보 쪽이 오래되었다면, 고쳐야 할 것은 글이 아니라 기준 페이지입니다.

자사 글로 판정 모델을 고르는 절차

여기부터는 위 검증 기록을 바탕으로 한 편집상의 제안입니다. 이 절차 자체를 검증한 것은 아닙니다.

1. 대조의 기반을 갖춘다. 회사 소개·요금·서비스 등 대조에 쓸 기준 페이지를 정하고, 먼저 내용이 최신인지 확인합니다. 기준 페이지가 오래된 상태라면 올바른 글을 틀렸다고 판정할 수 있습니다.
2. 판정할 단락을 고르는 조건을 정한다. 회사명·서비스명이나 ‘당사’, ‘저희’ 등을 포함한 단락을 대상으로 하고, 글에서 자주 쓰이는 다른 이름도 조건에 더합니다.
3. 이미 알고 있는 불일치로 시험한다. 공개 벤치마크나 합성 데이터의 성적이 아니라, 자사 글에서 실제로 발견된 범위나 조건의 과장을 몇 건 준비해 후보 모델이 그것을 잡아내는지 확인합니다.
4. 지시문의 문장을 점검한다. 놓친 것이 나오면 모델의 추론을 읽고, 제외한 이유가 지시문의 한 문장에 있지 않은지 확인합니다.
5. 후보를 좁히는 단계를 둔다면 누락을 확인한다. 저렴한 모델로 좁힐 때는 3번에서 준비한 불일치가 1단계 후보에 남는지 반드시 확인합니다.
6. 비용은 대상 단락 수로 추산한다. 모든 단락을 대조할지, 자사에 관해 서술한 단락만 대조할지에 따라 비용도 놓치기 쉬운 경향도 달라집니다.
7. 지적은 사람이 확인할 후보로 다룬다. 판정 모델의 출력으로 글을 바로 고쳐 쓰지 말고, 사람이 본문과 출처를 보고 판단합니다. Rootpublish도 생성 결과를 승인 대기 상태로 저장하고, 공개 권한을 가진 사람이 본문과 출처를 확인해 공개를 결정하도록 설계되어 있습니다.

이러한 확인은 기재의 정확성을 지키기 위한 것이며, 검색 순위나 AI 인용의 개선을 약속하는 것이 아닙니다.