CritICL: 작은 모델의 실패를 큰 모델의 문맥 힌트로 쓰는 방법 | DAKER 커뮤니티

작은 모델의 오답은 보통 버려집니다. 하지만 2026년 8월 27일 arXiv에 공개된 CritICL은 그 오답을 큰 모델의 추론 힌트로 다시 씁니다. 추론 시간 스케일링은 대개 같은 문제를 여러 번 생성하거나 외부 검증을 붙이는 방식으로 성능을 끌어올립니다. 다만 그만큼 호출 수와 토큰 비용도 함께 늘어나는 경우가 많습니다.

CritICL이 흥미로운 이유는 다른 곳에 있습니다. 같은 모델 가족 안에서 작은 모델의 실패 유형이 큰 모델에도 구조적으로 이어진다는 관찰을 바탕으로, 약한 모델의 실패를 비평 문맥 예제로 바꿔 넣는 방식이기 때문입니다. 초록이 말하는 범위 안에서 보면, 이 방법은 표준 문맥 학습보다 앞섰고 시험 시간 스케일링과 겨루거나 더 나았으며, 생성 횟수와 토큰 비용은 더 낮았습니다.

논문은 2026년 8월 27일 arXiv에 올라왔습니다. 초록은 arXiv:2608.27455에서 볼 수 있습니다. 저자는 Yufan Wu, Yinghui He, Zhengyi Hu, Lang Wei, Ruichen Li, Qifan Yang, Ting Zhu입니다. 코드는 github.com/umwyf/CRITICL에 공개되어 있습니다. 이 글은 초록이 밝힌 범위만 다루며, 초록에 없는 정확도 퍼센트는 적지 않습니다.

실패를 버리지 않고 문맥 힌트로 남기는 발상

추론 시간 스케일링은 큰 언어모델의 성능을 높이는 익숙한 방법입니다. 같은 질문에 대해 여러 답을 생성해 고르거나, 외부 검증 모델을 붙여 답을 다시 판정하는 식입니다. 이런 방식은 성능 향상 가능성이 있지만, 호출 수와 토큰 사용량이 함께 늘어나는 부담이 있습니다.

CritICL은 여기서 다른 신호를 씁니다. 같은 모델 가족 안에서는 규모가 달라도 실패 유형이 구조적으로 닮아 있다는 관찰입니다. 다시 말해, 작은 모델이 틀리는 방식이 큰 모델에도 남아 있을 수 있다는 뜻입니다. 이때 작은 모델의 실패는 단순한 오답이 아니라, 큰 모델이 피해야 할 함정을 미리 알려 주는 문맥 힌트가 됩니다.

작은 모델의 실패를 버릴 출력이 아니라 큰 모델이 피해야 할 비평 예제로 본다는 점이 CritICL의 핵심입니다.

표준 문맥 학습이 주로 맞은 풀이를 예제로 보여 준다면, CritICL은 틀린 풀이와 그에 대한 비평을 함께 보여 줍니다. 맞은 예제만 넣는 방식과 달리, 무엇을 피해야 하는지가 문맥 안에 직접 들어간다는 점이 다릅니다.

CritICL-dynamic과 CritICL-static의 차이

CritICL에는 두 변형이 있습니다. CritICL-dynamic은 입력마다 실패 유형을 예측하고, 그에 맞는 비평을 찾아 최종 생성에 반영합니다. 반면 CritICL-static은 전역적인 실패 윤곽을 바탕으로, 입력과 무관하게 모델 가족이 자주 보이는 실패 비평을 넣습니다.

두 방식은 이름만 다른 것이 아니라 동작 방식도 다릅니다. 동적 방식은 문제마다 다른 위험을 겨냥할 수 있지만, 실패 유형 예측과 비평 검색이 추가되므로 호출이 한 번 더 필요합니다. 정적 방식은 전역 윤곽이 준비되어 있다면 최종 생성만으로 적용할 수 있어 더 단순합니다.

동적은 입력별 위험을 겨냥하고, 정적은 가족이 반복하는 실패를 안정적으로 보여 줍니다.

따라서 시간이 빠듯한 환경에서는 정적 방식부터 붙이는 편이 구현이 짧을 수 있습니다. 반대로 문제 유형이 뚜렷하게 갈리는 과제라면 동적 방식이 더 잘 맞을 수 있습니다. 어느 쪽이든 공통 전제는 같습니다. 비평 예제는 미리 작은 모델의 오답에서 모아 두어야 합니다. 이는 시험 직전에 작은 모델을 새로 학습하라는 뜻이 아니라, 이미 나온 오답을 유형별로 정리해 두는 작업에 가깝습니다.

생성을 늘리기 전에 실패 문맥을 넣는 이유

초록에 따르면 CritICL은 표준 문맥 학습보다 앞섰고, 시험 시간 스케일링과 겨루거나 더 나았습니다. 동시에 생성 횟수와 토큰 비용은 더 낮았습니다. 이 글에서는 초록에 없는 수치를 덧붙이지 않고, 비교의 방향만 유지합니다.

이 비교가 시사하는 바는 분명합니다. 성능을 높이기 위해 곧바로 생성 횟수를 늘리기보다, 먼저 작은 모델의 실패 유형을 문맥으로 넣는 편이 더 효율적일 수 있다는 점입니다. 맞은 예제만 넣는 것보다 실패 비평을 넣는 것이 더 나았고, 여러 번 생성해 합치는 방식과 비교해도 호출 부담이 적었습니다.

답을 여러 번 뽑기 전에, 작은 모델이 이미 보여 준 실패를 먼저 읽는 것이 CritICL의 제안입니다.

외부 검증 모델을 붙이는 접근과도 결이 다릅니다. 검증 방식은 강한 모델을 한 번 더 부르거나 별도의 판정 모델을 두는 경우가 많습니다. CritICL은 새로운 판정기를 추가하기보다, 이미 존재하는 작은 모델의 실패 기록을 다시 활용합니다. 그렇다고 외부 검증이 필요 없다고 단정하는 것은 아닙니다. 순서의 문제에 가깝습니다. 검증 전에 실패 문맥을 먼저 넣어 보는 접근입니다.

같은 가족 안의 실패라는 전제가 중요합니다

이 방법이 기대는 전제는 분명합니다. 초록이 말하는 옮김은 같은 가족 안에서 규모를 건너 이동하는 구조화된 실패 유형입니다. 따라서 다른 가족 모델의 오답을 그대로 큰 모델에 넣는 실험은, 적어도 이 초록이 직접 주장하는 범위 안에 있지 않습니다.

실무적으로 옮기면 규칙은 단순합니다. 비평 은행을 만들 작은 모델과 최종 답을 낼 큰 모델을 같은 가족에서 고르는 것이 좋습니다. 가족이 다르면 실패 유형이 맞지 않을 수 있기 때문입니다.

CritICL이 기대는 옮김의 전제는 같은 가족 안의 구조화된 실패 유형입니다.

이 전제를 지키려면 오답 로그를 남기는 방식도 중요합니다. 작은 모델의 오답을 단순히 쌓아 두는 것만으로는 부족합니다. 문제, 틀린 답, 실패 유형, 한 줄 비평을 함께 남겨야 정적 윤곽도 만들 수 있고 동적 검색도 가능합니다. 오답만 있고 유형이 없으면 검색할 열쇠가 없고, 유형만 있고 비평 문장이 없으면 큰 모델이 읽을 힌트가 사라집니다.

이 글이 말하지 않는 것들

이 글은 정확도 퍼센트를 소개하는 글이 아닙니다. 초록은 표준 문맥 학습보다 앞섰고 시험 시간 스케일링과 겨루거나 더 나았다고만 적고 있습니다. 없는 점수를 덧붙이지 않습니다.

또한 반복 생성을 부정하는 글도 아닙니다. CritICL은 반복 생성과 외부 검증의 비용을 짚으면서, 실패 문맥을 먼저 넣는 대안을 제시합니다. 반복이 필요한 상황까지 없애자는 뜻은 아닙니다.

다른 가족 모델의 실패를 그대로 옮기라는 주장도 아닙니다. 초록이 말하는 범위는 같은 가족 안의 구조화된 실패 유형입니다. 작은 모델을 큰 모델로 사후학습하라는 논문도 아닙니다. 이 방법은 추론 시간에 문맥 예제로 넣는 틀이지, 가중치를 갱신하는 방식으로 소개되지 않습니다.

참고 자료

arXiv:2608.27455 — CritICL (2026-08-27)
https://github.com/umwyf/CRITICL

작은 모델의 오답을 비평 예제로 바꾸는 방식이, 여러분이 다루는 과제에도 통할지 어떻게 가늠해 보고 싶으신가요?