업무에서 AI가 사실을 틀리게 답하면 보통 두 가지 처방이 먼저 나온다. 검색을 붙이거나, 더 큰 모델로 바꾸는 방식이다. 둘 다 유효한 선택일 수 있다. 다만 오류가 왜 발생했는지 구분하지 않으면 비용과 지연만 늘고 답변 품질은 기대만큼 오르지 않을 수 있다.
Google Research가 8월 12일 소개한 연구는 이 문제를 조금 더 잘게 나눈다. 모델이 그 사실을 아예 학습하지 못한 것인지, 내부에 인코딩했지만 질문을 받았을 때 꺼내지 못한 것인지 분리해 보자는 제안이다. 연구진은 전자를 빈 진열대, 후자를 잃어버린 열쇠에 비유한다.
이 구분은 벤치마크의 해석을 바꾸는 데 그치지 않는다. 사내 문서 질의, 고객 응대 초안, 코드 리뷰처럼 사실성이 필요한 흐름에서 무엇을 로그로 남기고 어느 단계에 검색·재질문·사람 검토를 둘지 판단하는 출발점이 될 수 있다.
정답률 하나로는 오류의 원인을 알기 어렵다
기존의 사실성 평가는 질문에 맞았는지 틀렸는지를 주로 센다. 그런데 같은 오답이라도 원인은 다를 수 있다. 최신 정책처럼 학습 시점 뒤에 생긴 정보는 모델 내부 지식에 없을 가능성이 높다. 반면 제품명과 기능은 알고 있어도, 표현을 바꾸거나 관계의 방향을 뒤집으면 답을 못 내는 경우가 있다.
이 연구가 말하는 인코딩은 모델이 사실을 파라미터 안에 표현하고 있는 상태다. 회상은 그 사실을 다양한 표현의 질문에 맞게 꺼내는 능력이다. 인코딩 여부와 회상 가능성을 구분하면, 오답을 단순히 모델의 무지로 처리하지 않게 된다.
예를 들어 어떤 시스템이 “A의 본사는 B에 있다”는 정보를 문맥 속에서는 맞게 이어 쓰지만 “B에 본사를 둔 회사는 어디인가”라는 역방향 질문에는 실패할 수 있다. 이때 정답을 선택지로 주면 맞힐 수 있다면, 지식이 완전히 없는 것보다 생성 단계의 접근성이 약한 경우로 볼 여지가 생긴다. 물론 실제 업무 데이터에서 같은 현상이 얼마나 재현되는지는 별도 검증이 필요하다.
WikiProfile이 본 것은 질문이 아니라 사실의 상태다
연구진은 Wikipedia에서 뽑은 2,150개 사실에 각각 10개 질문을 붙인 WikiProfile을 만들었다. 문맥에서 사실을 완성하게 하는 과제, 정방향·역방향의 다양한 질문, 객관식 인식 과제를 함께 사용해 한 사실의 상태를 살폈다. 총 13개 LLM에서 약 400만 개 응답을 평가했다.
그 결과는 흥미롭다. 연구 범위 안에서 GPT-5와 Gemini-3 계열은 시험한 사실의 95~98%를 인코딩한 것으로 보고됐다. 그런데 직접 회상에서는 여전히 26~34%의 사실을 놓쳤고, 추론 과정을 활성화한 뒤에도 11~12%는 회상하지 못했다. 논문의 수치는 WikiProfile과 연구진의 평가 설정에 한정된다. 모든 업무 사실성이나 모든 언어에서 그대로 성립한다고 읽으면 안 된다.
특히 드문 사실과 역방향 질문에서 회상 실패가 두드러졌다. 반대로 선택지를 제시하는 인식 과제에서는 역방향 질문이 반드시 더 어렵지는 않았다. 시스템이 정답을 생성하지 못했다고 해서 그 지식이 파라미터에 없다고 바로 결론 내릴 수 없다는 뜻이다.
생각 모드는 만능 보강책이 아니다
추론 시간에 계산을 더 쓰는 이른바 thinking은 인코딩됐지만 바로 회상하지 못한 사실 일부를 회복했다. Google Research는 thinking에 최적화된 모델에서 이런 사실의 약 40~65%가 회복됐다고 설명한다. ICML 게시 페이지의 요약도 최대 65%라는 결과를 제시한다.
하지만 여기서 “어려운 질문이면 항상 길게 생각하게 하자”로 넘어가면 곤란하다. thinking은 지연 시간과 연산 비용을 늘리고, 인코딩되지 않은 사실에는 효과가 훨씬 작았다. 최신 정보, 사내 전용 데이터, 정확한 수치처럼 근거가 필요한 질문은 여전히 검증 가능한 외부 출처가 더 중요하다.
따라서 실무의 선택지는 단순한 이분법이 아니다. 빠른 응답이 중요한 낮은 위험 작업에는 기본 응답을 쓰고, 표현 변화에 취약한지 확인된 유형에는 재질문이나 추론 예산을 추가할 수 있다. 근거 제시가 필수인 고위험 답변은 검색이나 승인된 지식베이스를 거쳐 출처와 함께 답하게 해야 한다. 이 세 경로의 효과를 같은 정확도 지표로만 비교하지 않는 것이 중요하다.
업무용 AI 평가에 추가할 세 가지 질문
새 모델이나 프롬프트를 평가할 때 테스트셋을 조금만 바꿔도 더 실용적인 신호를 얻을 수 있다.
- 표현을 바꿔도 같은 답을 내는가. 자주 묻는 질문마다 자연스러운 표현, 짧은 표현, 관계를 뒤집은 표현을 함께 만든다. 한 문장에만 맞는 답변은 업무에서 쉽게 흔들린다.
- 근거를 주면 회복되는가. 승인된 문서 조각이나 선택지를 주었을 때 정답률이 크게 오르는지 확인한다. 이 결과는 검색 연동이나 인용 강제가 적절한지 판단하는 단서가 된다. 다만 선택지 정답률은 자유 생성의 정확도를 대신하지 않는다.
- 추론 예산의 이득이 비용을 넘는가. 기본 모드와 thinking 모드를 같은 질문 묶음에서 비교한다. 정확도 변화뿐 아니라 응답 시간, 토큰 사용량, 근거 없는 자신감 있는 답변의 빈도도 같이 기록하는 편이 낫다.
여기서 중요한 것은 오류 원인을 완벽하게 판정하려는 것이 아니다. 인코딩과 회상은 연구에서 정의한 행동 기반 분류이며, 상용 API를 쓰는 팀이 내부 상태를 직접 들여다보는 방법은 아니다. 대신 어떤 개입이 실제로 답을 회복하는지 관찰하고, 그 결과에 맞춰 시스템을 설계하자는 제안으로 받아들일 수 있다.
검색은 대체재가 아니라 검증 경로다
이번 연구는 모델 크기나 데이터 확장이 쓸모없다고 주장하지 않는다. 연구진의 결론도 사실성 개선이 지식의 양뿐 아니라 이미 인코딩된 지식을 활용하는 방법에 달려 있을 수 있다는 쪽에 가깝다.
한국어 업무 환경에서는 한 가지 조건을 더 확인해야 한다. WikiProfile은 영어 Wikipedia 기반 사실로 구성됐다. 한국어 표현, 조직 내부 약어, 최신 규정, 표 형태의 수치에서 같은 비율이 나올지는 알 수 없다. 그래서 외부 발표의 수치를 그대로 도입 기준으로 삼기보다, 실제로 쓰는 20~50개 질문을 골라 역방향·표현 변형·근거 제공 조건을 나란히 시험하는 편이 안전하다.
AI가 틀린 답을 냈을 때 필요한 첫 질문은 “모델이 이걸 몰랐나?”만은 아니다. “알고 있어도 이 질문 형태에서 못 꺼낸 건가?”, “근거를 붙이면 회복되는가?”, “그 회복에 드는 시간과 비용이 감당할 만한가?”까지 확인해야 한다. 이 세 가지를 기록하기 시작하면 모델 교체와 검색 연동, 사람 검토의 역할도 조금 더 구체적으로 나눌 수 있다.