추론은 강해졌는데 사실은 자주 틀려요, 소형 AI 모델의 새로운 절충

요즘 소형 LLM은 수학과 코딩 문제를 꽤 잘 풀어요. 그런데 인물의 생년이나 특정 라이브러리 버전처럼 세부 사실을 물으면 자신 있게 틀리는 경우가 많아요. 모델을 작게 만드는 과정에서 무엇을 기억하고 무엇을 외부 자료에 맡길지 다시 따져볼 시점이에요. 1
핵심 요약
| 구분 | 핵심 | 왜 볼 만한가요 |
| 성능 변화 | 적은 활성 매개변수로 높은 추론 점수를 내는 모델이 늘고 있어요 | 모델 크기와 문제 해결 능력의 관계가 달라지고 있어요 |
| 약점 | 도구 없이 세부 사실을 회상할 때 오답과 환각이 많아요 | 벤치마크 점수만으로 실제 답변 품질을 판단하기 어려워요 |
| 설계 방향 | 최신 세부 정보는 검색, 문서, 도구 호출로 가져오는 방안이 거론돼요 | 오래된 API나 가격 정보를 가중치에 계속 담는 비용을 줄일 수 있어요 |
| 남은 문제 | 검색 결과도 틀릴 수 있고, 모델이 확인이 필요한 순간을 놓칠 수 있어요 | 외부 출처가 있다고 정확성이 저절로 생기지는 않아요 |
1. 모델이 모든 사실을 외울 필요가 있을까요
원문은 최근 소형 모델과 전문가 혼합(MoE) 모델에서 한 가지 절충이 뚜렷해졌다고 봐요. GLM-5.2, Qwen3.5, DeepSeek V4-Flash처럼 토큰마다 일부 매개변수만 활성화하는 모델이 수학과 코딩 평가에서 높은 점수를 내고 있어요. 반면 도구 사용을 막고 사실을 직접 묻는 평가에서는 성적이 크게 떨어져요. 원문이 인용한 자료에서는 Qwen3.5 4B와 9B의 지식 평가 환각률이 80~82%로 나타났어요. 2
저자는 이 차이를 단순한 성능 저하로 보지 않아요. 모델 용량을 수많은 세부 사실보다 문제 분해, 중간 결과 확인, 검산 같은 반복 가능한 절차에 더 많이 쓰는 선택일 수 있다고 봐요. 사실 지식은 저장 공간을 많이 차지하고 빠르게 낡아요. 라이브러리 API, 제품 가격, 인물의 소속은 학습이 끝난 뒤에도 계속 바뀌어요.
그렇다고 기본 지식까지 모두 밖으로 빼자는 얘기는 아니에요. 모델은 PostgreSQL이 무엇이고 MVCC가 대략 어떻게 작동하는지 알아야 적절한 자료를 찾을 수 있어요. 특정 기능이 어느 버전에 들어갔는지처럼 자주 바뀌는 정보는 설치된 패키지 문서나 공식 문서에서 그때 확인하는 편이 더 정확할 수 있어요.
이 접근은 코딩 도구에서 특히 현실적이에요. 코딩 AI가 학습 당시의 API를 떠올리는 대신 현재 프로젝트의 의존성과 문서를 읽으면 실제 설치 버전에 맞춰 코드를 만들 수 있어요. 잘못된 답의 근거가 외부 문서에 남으면 어느 자료에서 오류가 시작됐는지도 추적하기 쉬워져요.
다만 원문의 후반부는 아직 검증되지 않은 가설을 포함해요. 세부 지식을 충분히 외부로 옮기면 20~40B급 양자화 모델로 프런티어 수준의 추론을 로컬 GPU에서 돌릴 수 있다는 전망이에요. 전문가 계층의 상당 부분이 사실 저장에 쓰인다는 전제부터 확인이 더 필요해요. 높은 수학 점수가 폭넓은 현실 문제의 추론 능력을 그대로 뜻하는지도 따로 검증해야 해요.
출처가 생겨도 환각은 남아요
검색과 문서 조회는 오답을 자동으로 없애지 못해요. 모델이 자료를 잘못 읽거나 서로 다른 정보를 엉뚱하게 합칠 수 있어요. 검색 결과 자체가 틀렸을 가능성도 있어요. 무엇을 모르는지 판단하고 확인을 요청하는 능력이 함께 좋아져야 이 구조가 제대로 작동해요.
평가 지표의 시점도 확인해야 해요. 원문이 주요 근거로 든 SimpleQA는 최신 모델의 사실 회상 능력을 모두 대표하기 어렵다는 비판을 받고 있어요. 따라서 “요즘 모델이 의도적으로 멍청해졌다”라는 제목은 확정된 결론보다 설계 방향을 설명하는 주장으로 읽는 편이 안전해요.
왜 중요한가요
AI 제품을 만드는 팀은 모델 점수보다 정보가 어디에서 오는지 먼저 설계할 필요가 있어요. 자주 바뀌는 가격, 정책, API, 사내 규정은 모델의 기억에 맡기기 어려워요. 공식 문서와 내부 자료를 실행 시점에 읽고, 답변에 사용한 출처를 남기면 수정과 재검증이 쉬워져요. 2
모델 선택 기준도 달라질 수 있어요. 모든 사실을 많이 기억하는 큰 모델보다 필요한 자료를 정확히 찾고, 근거를 비교하고, 모르면 확인하는 작은 모델이 특정 업무에서는 더 유용할 수 있어요. 다만 검색 비용과 응답 지연, 잘못된 출처를 고르는 위험까지 함께 측정해야 해요.
개발 현장에서는 간단한 확인부터 시작할 수 있어요. 코딩 AI가 답할 때 현재 저장소의 문서와 잠금 파일을 먼저 읽게 하고, 사용한 API 버전을 답변에 남기도록 설정해요. 이후 잘못된 답이 나오면 모델 전체를 탓하기 전에 참조한 문서, 검색 결과, 추론 과정 중 어느 지점에서 문제가 생겼는지 나눠 확인할 수 있어요.
참고 자료
- 모델은 의도적으로 더 멍청해지고 있다 — GeekNews
- Models Are Getting Dumber on Purpose — Walter van der Giessen
'IT & AI' 카테고리의 다른 글
| Codex에서 GPT-5.6 Sol 100만 토큰 컨텍스트를 켜는 방법 (0) | 2026.08.18 |
|---|---|
| Docbank, 사람과 AI 에이전트가 함께 쓰는 로컬 문서 금고 (0) | 2026.08.18 |
| 공식 가격보다 90% 싼 AI API, 크레딧 재판매 시장의 구조와 위험 (0) | 2026.08.17 |
| 좋은 아이디어가 평가받기 전에 사라지는 이유 (1) | 2026.08.17 |
| AI가 편해진 만큼 기준도 높아졌어요: Stripe Staff Engineer의 2026년 (1) | 2026.08.17 |