▲

재귀적 언어 모델 (Recursive Language Models)

 (arxiv.org)
2P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 대규모 언어 모델(LLM) 이 매우 긴 입력 프롬프트를 처리할 수 있도록 하는 새로운 추론 전략 RLM(Recursive Language Model) 이 제안됨
  • RLM은 긴 프롬프트를 외부 환경의 일부로 간주하고, 모델이 이를 프로그래밍적으로 탐색·분해·재귀 호출할 수 있게 함
  • 이 방식은 기존 컨텍스트 윈도 한계를 초월하여 최대 수천만 토큰 규모의 입력을 처리하며, 기존 LLM 대비 품질이 크게 향상됨
  • 실험 결과, GPT-5 및 Qwen3-Coder 기반 RLM은 다양한 장문 과제에서 두 자릿수 성능 향상을 보이며, 비용은 비슷하거나 더 낮음
  • 긴 문맥 처리 한계를 극복하고 LLM의 추론 능력을 대폭 확장할 수 있는 일반적 접근법으로 평가됨

RLM 개요

  • Recursive Language Model(RLM) 은 LLM이 긴 입력을 직접 신경망에 넣지 않고, 이를 외부 환경의 변수로 취급해 상호작용하도록 설계
    • 입력 프롬프트 P를 Python REPL 환경의 변수로 로드하고, LLM이 코드로 이를 탐색·분해·재귀 호출하도록 함
    • LLM은 REPL 환경의 상태(예: 문자열 길이)를 인식하고, 코드 실행의 부작용을 관찰하며 점진적으로 문제를 해결
  • 이 구조는 기존의 문맥 압축(compaction) 이나 요약 기반 접근법이 세부 정보를 잃는 문제를 해결함
  • RLM은 입력과 출력 길이를 모두 확장할 수 있는 일반적 추론 패러다임으로 제시됨

기존 접근법의 한계

  • 기존 LLM은 컨텍스트 윈도우 한계로 인해 긴 입력에서 성능이 급격히 저하되는 context rot 현상을 보임
  • 문맥 압축(compaction) 기법은 일정 길이를 넘으면 요약을 반복하지만, 세밀한 정보 접근이 필요한 작업에는 부적합
  • RLM은 프롬프트를 외부 객체로 다루어 입력 크기를 모델 한계 이상으로 확장할 수 있음

실험 설정

  • 평가 모델: GPT-5(OpenAI, 2025) 와 Qwen3-Coder-480B-A35B(Team, 2025)
  • 비교 대상:
    • 기본 LLM 직접 호출
    • 요약 에이전트(Summary agent)
    • CodeAct + BM25 검색 기반 에이전트
    • RLM(REPL 환경 포함) 및 RLM(REPL, 재귀 호출 없음)
  • GPT-5 실험에서는 GPT-5-mini를 재귀 호출용으로, GPT-5를 루트 모델로 사용해 성능과 비용의 균형 확보

평가 과제

  • S-NIAH: 단일 ‘needle-in-a-haystack’ 문제, 입력 길이에 관계없이 일정한 처리 비용
  • BrowseComp-Plus: 여러 문서를 넘나드는 multi-hop 질의응답 과제, 1000개 문서 중 정답 포함
  • OOLONG: 입력의 거의 모든 항목을 의미적으로 변환·통합해야 하는 장문 추론 과제, 처리 비용이 입력 길이에 선형 비례
  • OOLONG-Pairs: OOLONG 변형으로, 쌍 단위 정보 결합이 필요하며 처리 비용이 입력 길이에 제곱 비례
  • LongBench-v2 CodeQA: 코드 저장소 이해를 요구하는 다중 선택형 과제, 최신 모델에도 어려운 문제

주요 결과

  • RLM은 GPT-5 대비 긴 문맥에서도 성능 저하가 거의 없음
    • GPT-5는 입력 길이와 과제 복잡도 증가에 따라 급격히 성능 하락
    • RLM은 272K 토큰 한계를 초과하는 입력(최대 10M+ 토큰) 도 효과적으로 처리
  • 모든 장문 과제에서 RLM이 다른 방법 대비 두 자릿수 성능 향상을 보임
  • 비용 효율성도 유지되어, 동일 쿼리당 비용이 기존 접근법과 유사하거나 더 낮음

장문 과제의 복잡도 분석

  • LLM의 실질적 컨텍스트 윈도우는 물리적 한계보다 과제 복잡도에 따라 더 짧아질 수 있음
    • 단순한 NIAH 문제는 1M+ 토큰에서도 해결 가능
    • 복잡한 OOLONG류 과제는 훨씬 짧은 길이에서도 성능 저하 발생
  • 따라서 과제의 정보 밀도와 입력 길이의 상관관계를 함께 고려해야 함

결론

  • RLM은 LLM의 추론 능력을 재귀적으로 확장하여, 기존 모델이 처리할 수 없는 초장문 입력을 다룰 수 있게 함
  • 프롬프트를 환경 객체로 다루는 설계가 핵심 혁신으로, 장문 처리의 구조적 한계를 해결
  • 다양한 모델과 과제에서 성능·비용·확장성의 균형을 달성한 일반적 추론 프레임워크로 제시됨
▲
GN⁺ 2일전  [-]
Hacker News 의견들

  • 이건 그냥 subagent 개념처럼 보임
    즉, 다른 LLM을 불러 파일을 읽고 필요한 정보를 추출하게 해서 메인 컨텍스트를 복잡하게 만들지 않으려는 방식임
    아이디어는 괜찮지만 완전히 새로운 건 아님

    • 나는 인간처럼 의인화된 subagent보다는 컨텍스트 관리 수단으로 보고 있음
      현재 Scope 프로젝트에서 관찰 가능한 subagent들이 작업을 재귀적으로 분해하도록 실험 중임
      다만 이 계획 단계 평가를 어떻게 개선할지 모르겠음
      마크다운 파일로 휴리스틱을 기록하지만 구조가 느슨해서 측정이 어려움
      관련 문헌이나 프로젝트를 아는 사람이 있다면 알려주면 좋겠음
    • 논문에서는 이렇게 말함
      RLM은 에이전트도 요약도 아님
      여러 LM 호출을 하나의 시스템에서 사용하는 건 새로운 개념이 아니며, 이는 대부분의 agentic scaffold가 하는 일임
      가장 유사한 예로 ROMA agent가 문제를 분해해 여러 sub-agent로 해결하는 방식을 들 수 있음
      또 Cursor나 Claude Code 같은 코드 어시스턴트도 컨텍스트가 길어질수록 요약하거나 가지치기함
      이런 접근은 보통 작업 단위로 분해하지만, RLM은 컨텍스트 단위 분해를 강조하며 그 선택은 LM이 스스로 결정해야 한다고 봄
    • 제목만 보면 전체 연산이 differentiable하고 하나의 모델로 학습된 것처럼 들리지만, 실제로는 단순히 모델을 반복 호출하는 수준으로 보임
    • subagent가 또 다른 subagent를 무한히 호출할 수 없다면 그건 재귀적이라 할 수 없음
    • 동일한 컨텍스트(파일 시스템이나 REPL 변수)에 접근하고 조작하는 sub-agent 개념을 말하는 것 같음

  • 핵심 통찰은 긴 프롬프트를 신경망(Transformer)에 직접 넣지 말고, LLM이 상징적으로 상호작용할 수 있는 환경의 일부로 다뤄야 한다는 것임
    그런데 이게 근본적으로 RAG와 어떻게 다른지 궁금함
    그림 4를 보면, 차이는 사람이 아닌 LLM이 직접 retrieval 메커니즘을 구현한다는 점 같음

    • 내가 보기엔 두 가지 차이가 있음
      1️⃣ RAG는 workflow에 가깝고, 이건 좀 더 agentic함
      2️⃣ 재귀적 구조를 가짐
      workflow에서는 사람이 단계별로 흐름을 짜지만, agentic 접근에서는 에이전트가 스스로 무엇을 검색하고 몇 번 호출할지, 언제 답변할지를 결정함
      예를 들어 Claude Code나 Codex가 코드베이스를 탐색하며 파일을 읽고 ripgrep을 돌리는 식임
      이런 재귀적 시도는 예전에도 있었지만 (예: babyagi, 2023년경) 당시 모델 성능이 부족해서 많은 glue code가 필요했음
      이제는 모델이 충분히 강력해져서 이런 구조가 실제로 작동함

  • “T̶u̶r̶t̶l̶e̶s̶ LLMs all the way down”이라는 농담처럼, 끝없이 LLM이 LLM을 호출하는 구조를 암시함

    • “attention is all you need”를 반복적으로 적용하는 셈이며, 결국 우리가 추구해야 할 건 정밀도(precision) 임

  • 더 읽기 쉬운 버전의 글이 있음: alexzhang13 블로그 글

  • 2026년에 바라는 점은 Anthropic이나 OpenAI가 CLI 플러그인 제작자에게 “compaction이 어떻게 실행되는지”를 공개하는 것임
    이 기술은 Claude Code에 내장된 기능을 대체할 수도 있지만, 현재는 적절한 hook이나 기능이 노출되어 있지 않음

    • Codex가 오픈소스라면 직접 읽어볼 수 있지 않나?
      나는 Gemini 소스를 봤는데, 컨텍스트 윈도우가 가득 차면 전체를 요약하는 단순한 프롬프트 구조였음

  • 이 논문과 유사해 보임: arXiv:2510.14826

답변달기