본문으로 건너뛰기

CRITIC: LLM 자기 수정에 외부 도구 피드백이 필요한 이유

· 약 5분
Mike Thrift
Mike Thrift
Marketing Manager

CRITIC(Gou et al., ICLR 2024)을 읽으면서 금융 에이전트가 실수를 저지른 뒤에 어떤 일이 벌어지는지 생각해보았습니다. Reflexion은 에이전트가 에피소드를 거치며 실패로부터 배울 수 있다는 점을 알려주었습니다. CRITIC은 더 예리한 질문을 던집니다. LLM이 단 한 번의 생성 과정 내에서 스스로 오류를 포착하고 수정할 수 있는가? 만약 그렇다면, 이를 위해 실제로 무엇이 필요한가?

논문 요약

2026-04-26-critic-llm-self-correct-tool-interactive-critiquing

CRITIC은 언어 모델이 초기 출력을 생성한 후, 외부 도구를 사용해 '검증 후 수정' 루프를 반복하는 프레임워크를 제안합니다. 사실 관계 확인을 위한 검색 API, 코드 및 산술 연산을 위한 Python 인터프리터, 콘텐츠 중재를 위한 유해성 분류기 등이 도구로 사용됩니다. 이 루프는 고정된 횟수만큼 반복되며(논문에서는 약 3회의 수정에서 효과적인 결과를 보고함), 이를 통해 자유 형식 질의응답(TriviaQA, AmbigNQ, HotpotQA), 수학 프로그램 합성, 유해성 감소 측면에서 평가된 정제된 출력을 생성합니다.

핵심 주장은 LLM이 스스로 자가 수정을 할 수 있다는 것이 아닙니다. 오히려 정반대에 가깝습니다. CRITIC의 가치는 비판의 근거를 모델이 조작할 수 없는 외부 신호에 둠으로써 발생합니다. 검색 API가 없으면 QA 성능 향상은 거의 제로에 가깝거나 오히려 나빠집니다. 이 프레임워크가 작동하는 이유는 모델이 신뢰할 수 있는 자기 감사자가 되었기 때문이 아니라, 도구가 모델이 정말로 몰랐던 정보를 알려주기 때문입니다.

핵심 아이디어

  • ChatGPT에 적용했을 때, CRITIC은 세 가지 오픈 도메인 QA 작업에서 평균 7.7 F1 점수 향상을, 세 가지 수학적 추론 벤치마크에서 7.0% 포인트의 절대적인 이득을 얻었습니다.
  • 유해성 감소는 가장 눈에 띄는 단일 결과로, 평가 데이터셋에서 유해성 발생 확률을 79.2% 줄였습니다.
  • 검색 API를 제거하면 QA 성능이 정체되거나 저하됩니다. 사실 관계 확인 작업에서 모델 고유의 자가 비판 능력은 거의 쓸모가 없습니다.
  • 루프는 빠르게 수렴합니다. 세 번의 수정 라운드에서 대부분의 이득을 얻으며, 그 이상의 반복은 수확 체감의 법칙을 따릅니다.
  • 프레임워크는 모델에 구애받지 않으며 미세 조정(fine-tuning)이 필요하지 않습니다. Text-Davinci-003 및 ChatGPT를 포함한 블랙박스 API에서 작동합니다.
  • CRITIC은 대부분의 작업에서 자기 일관성(self-consistency, 여러 샘플 중 다수결 채택)보다 뛰어난 성능을 보였습니다. 자기 일관성은 단계별 도구 비용이 들지 않는다는 점을 고려하면 이는 유의미한 결과입니다.

유효한 점과 그렇지 않은 점

핵심적인 실증 결과는 견고합니다. 외부 도구의 피드백은 출력을 유의미하게 개선하며, 검색 API를 제거한 절제 실험(ablation)은 나이브한 자가 수정을 옹호하는 이들에게 치명적인 반증이 됩니다. 논문은 또한 그 메커니즘에 대해 솔직합니다. 이득은 어떤 창발적인 메타 인지 능력이 아니라 도구에서 나옵니다.

제가 다소 부족하다고 느낀 부분은 실패 사례의 분류(taxonomy)입니다. 모델이 잘못된 비판을 생성하여 정답에서 더 멀어지게 되는 경우는 언제일까요? 논문은 평균적인 성능을 보고하지만, 실제 배포 시에는 작업과 질문 유형에 따른 편차(variance)가 매우 중요합니다. 금융 맥락에서 가장 나쁜 결과는 '개선 없음'이 아니라, 그럴싸해 보이지만 새로운 오류를 도입하는 수정입니다.

반복 횟수를 3회로 제한한 선택도 원칙적인 중단 기준이라기보다는 실용적인 편의를 위한 것으로 보입니다. 수렴할 정답이 있는 TriviaQA 같은 작업에서는 3회 라운드가 적절할 수 있습니다. 하지만 '정확한' 답변을 위해 여러 문서에 걸친 추론과 도메인 지식이 필요한 장부 정산(ledger reconciliation)과 같은 분야에서는 세 번의 도구 호출로 충분한지, 혹은 범용 검색 API가 적절한 검증 신호를 제공할 수 있을지조차 불분명합니다.

동반 논문인 ICLR 2024의 "Large Language Models Cannot Self-Correct Reasoning Yet" (Huang et al., arXiv:2310.01798)은 다른 방향에서 CRITIC의 발견을 확인해 줍니다. 외부 피드백이 없다면 자가 수정은 추론 정확도를 안정적으로 저하시킨다는 것입니다. 이 두 논문은 일관된 그림을 보여줍니다. 사람들이 '자가 수정'이라 부르던 능력은 대부분 외부 피드백 기반의 정제 과정이며, 이 차이는 매우 중요합니다.

금융 AI에 중요한 이유

CRITIC 루프는 Beancount 에이전트의 기록 안전성(write-back safety) 문제에 자연스럽게 대입됩니다. 현재 LLM 에이전트가 거래 분류나 비용 분할과 같은 분개(journal entry)를 제안할 때, 이를 디스크에 기록하기 전 스스로 출력을 검증할 원칙적인 방법이 없습니다. CRITIC의 아키텍처는 구체적인 패턴을 제시합니다. 후보 항목을 생성한 다음, 도구(잔액 확인 함수, 규칙 엔진, 중복 탐지기 등)를 통해 검증을 실행하고, 실제 기록이 이루어지기 전에 도구의 출력을 사용하여 수정을 유도하는 것입니다.

유해성 결과는 유용한 비유가 됩니다. 정책 위반이 79.2% 감소한 것은 모델이 규칙을 내면화했기 때문이 아니라, 위반 사항을 보고하는 분류기가 있었기 때문입니다. Beancount 장부의 경우, 이는 이중 기입된 거래나 카테고리 위반을 찾아내어 에이전트의 수정 단계에 해당 신호를 제공하는 규칙 검사기와 같습니다. 에이전트는 규칙이 어긋났음을 독립적으로 알 필요가 없습니다. 도구의 신호가 필요할 뿐입니다.

금융 분야에서의 결정적인 한계는 검색 API 의존성입니다. 금융 에이전트에게는 도메인 특화된 검증 도구가 필요합니다. 계좌 잔액 무결성 확인, 계정 과목(chart-of-accounts) 검증기, 세무 규칙 조회 등이 그 예입니다. 일반적인 웹 검색으로는 잘못 분류된 비용을 잡아내기 어렵습니다. 회계 분야에서 CRITIC 스타일의 수정을 위한 적절한 도구 계층을 구축하는 것이 실제 엔지니어링의 핵심이며, 이 논문은 도메인 특화 도구 설계에 대해서는 다루지 않습니다.

더 읽어보기

  • "Large Language Models Cannot Self-Correct Reasoning Yet" (Huang et al., 2023, arXiv:2310.01798) — 내재적 자가 수정이 실패한다는 직접적인 실증적 주장입니다. CRITIC과 함께 읽으면 동일한 메커니즘을 서로 다른 관점에서 이해할 수 있습니다.
  • "Tree of Thoughts: Deliberate Problem Solving with Large Language Models" (Yao et al., NeurIPS 2023, arXiv:2305.10601) — 단일 경로의 비판 및 수정 아이디어를 중간 단계에 대한 검색 트리로 확장합니다. 에이전트가 탐색과 역추적(backtrack)이 필요한 다단계 정산 작업에 유용합니다.
  • "ToolBench: Facilitating Large Language Models in Mastering 16000+ Real-world APIs" (Qin et al., 2023, arXiv:2307.16789) — 에이전트가 도구 호출을 선택하고 연결하는 방법을 연구합니다. 이는 CRITIC이 당연하게 전제하고 있는 상위 단계의 문제입니다.