기술 요약: 토큰 효율적인 자율 실험을 위한 상태 유지형(Stateful) ReAct 에이전트

문제 정의

"autoresearch" 패턴은 대규모 언어 모델(LLM)이 타겟 지표를 최적화하기 위해 코드를 반복적으로 수정하도록 함으로써 자율적인 실험을 가능하게 합니다. 그러나 이 방식은 효과적이긴 하지만, 기본 구현은 상태 비저장(stateless) 방식입니다. 즉, 매 반복마다 에이전트는 연구 지시 파일(예: program.md)에 축적된 결과와 코드 수정의 전체 이력을 다시 읽음으로써 실험 컨텍스트를 재구성해야 합니다.

이러한 설계는 구조적 비효율성을 초래합니다:

• 토큰 비용: 프롬프트 크기가 반복 횟수($n$)에 따라 선형적으로 증가($O(n)$)하여, 총 토큰 비용은 $O(n^2)$에 달하게 됩니다.
• 중복성: 에이전트는 이전 단계에서 이미 처리한 정보를 다시 전송하게 됩니다.
• 확장성: 실험이 축적됨에 따라 프롬프트가 컨텍스트 창 제한에 도달하며, 이는 정보의 요약이나 절단을 강요하여 실험의 중요한 뉘앙스를 손실할 위험을 초래합니다.

본 논문은 LLM이 상호작용 간에 일시적인 상태를 유지할 수 없기 때문에(Huang et al. [10]), 외부 상태 관리가 이러한 이차 함수적(quadratic) 비용 곡선을 깨뜨리기 위한 아키텍처적 필수 요소라고 주장합니다.

방법론

저자들은 LangGraph를 사용하여 autoresearch 패턴을 상태 유지형(stateful) ReAct 에이전트로 재정의합니다. 모놀리식(monolithic) 프롬프트에 전체 이력을 포함하는 대신, 에이전트는 도구 호출(tool calls)을 통해 ML 시스템과 상호작용하며, 실험 이력, 추론 흔적(reasoning traces), 수렴 지표는 **타입이 지정된 지속성 상태 그래프(typed persistent state graph)**에 유지됩니다.

아키텍처

에이전트는 세 가지 주요 노드를 가진 상태 그래프로 작동합니다:

1. REASON (추론): 현재 상태 컨텍스트와 함께 LLM(Claude Haiku 4.5)을 호출합니다. 모델은 추론 흔적과 도구 호출을 생성합니다.
2. TOOLS (도구): 도구 호출을 결정론적으로 실행하고(예: 실험 실행, 결과 쿼리) 관찰 값을 반환합니다.
3. CHECK (검사): LLM의 개입 없이 수렴 기준(타겟 지표 임계값, 반복 예산 또는 LLM의 결론)을 평가합니다.

조건부 엣지(conditional edges)가 흐름을 제어합니다. 만약 LLM이 도구 호출을 생성하면 제어권이 TOOLS로 넘어가고, 그렇지 않으면 CHECK로 진행됩니다. 수렴하지 않았다면 루프는 다시 REASON으로 돌아갑니다.

상태 관리

핵심 혁신은 반복 전반에 걸쳐 지속되는 AgentState(타입이 지정된 딕셔너리)입니다. 여기에는 다음이 포함됩니다:

• messages: 입력 비용을 제한하기 위한 마지막 20개의 메시지 슬라이딩 윈도우.
• experiment_history: 과거의 모든 결과 리스트.
• current_best: 현재까지 발견된 최적의 결과.
• train_py_content: 현재의 코드 상태.

결정적으로, 에이전트는 각 단계에서 LLM을 위한 압축된 요약을 생성하기 위해 헬퍼 클래스(ExperimentState 또는 CodeState)를 사용합니다. 이 요약에는 다음이 포함됩니다:

• 현재 반복 횟수 및 최적의 집계 지표.
• 최근 5개의 실험(또는 최근 결과).
• 전략 노트 및 실패한 접근 방식.

이를 통해 LLM은 총 실험 횟수에 관계없이 각 단계에서 $O(1)$의 입력 토큰만을 받게 됩니다. 전체 이력은 상태 내에 접근 가능하지만, 도구를 통해 명시적으로 쿼리되지 않는 한 프롬프트에서는 제외됩니다.

도구 구성

에이전트는 특정 도구를 통해 ML 시스템과 상호작용합니다:

• 하이퍼파라미터 튜닝: get_experiment_history 및 run_experiment.
• 코드 최적화: get_current_train_py, modify_train_py(평가 로직을 보존하기 위한 가드레일 포함), submit_training_job, query_results.

주요 기여

1. 아키텍처적 재정의: Stateless autoresearch 패턴을 LangGraph를 사용하는 stateful ReAct 에이전트로 변환하여, 에이전트의 작업 기억(working memory)과 프롬프트 컨텍스트를 분리했습니다.
2. 토큰 효율성: 상태 유지형 에이전트가 stateless 방식 대비 토큰 비용을 $O(n^2)$에서 $O(n)$으로 구조적으로 감소시킴을 입증했습니다(각 반복당 $O(1)$ 비용).
3. 구현 청사진: 실무자들이 상태 유지형 에이전트를 구현할 수 있도록 상세하고 재현 가능한 아키텍처(상태 스키마, 그래프 로직, 도구 정의 포함)를 제공합니다.

실험 결과

저자들은 3개의 무작위 시드를 사용하여 두 가지 벤치마크 태스크에 대해 stateful 에이전트를 stateless 베이스라인과 비교 평가했습니다.

태스크 1: 하이퍼파라미터 튜닝 (작은 관측치)

• 설정: UCI Covertype 데이터셋에 대해 XGBoost를 최적화하는 15회의 반복. 관측치는 작았습니다 (~200 토큰: JSON 설정 + 지표).
• 결과:
  • 토큰 감소: stateful 에이전트는 90% 적은 토큰을 소비했습니다 (24,465 vs. 2,492). 이는 9.8배 감소한 수치입니다.
  • 성능: 두 에이전트 모두 유사한 F1 점수(0.779 vs. 0.764)를 달성했으며, 차이는 아키텍처의 우위보다는 시드 변동성에 기인했습니다.
  • 비용 곡선: stateless 입력 비용은 반복당 약 700에서 1,900 토큰으로 선형적으로 증가했으나, stateful 비용은 약 100 토큰으로 일정하게 유지되었습니다.

태스크 2: 코드 성능 최적화 (큰 관측치)

• 설정: 파이썬 데이터 처리 함수를 최적화하는 40회의 반복. 관측치는 컸습니다 (~1,500–3,000 토큰: 전체 소스 코드 + 벤치마크).
• 결과:
  • 토큰 감소: stateful 에이전트는 52% 적은 토큰을 소비했습니다 (1,275K vs. 627K). 이는 2.0배 감소한 수치입니다.
  • 성능: 두 에이전트 모두 유사한 속도 향상(~베이스라인 대비 1.9배)을 달성했습니다.
  • 비용 곡선: stateful 에이전트는 매 단계에서 "현재 최적의 코드"를 전송하기 위해 고정 비용(~1,500 토큰)이 발생했지만, 총 비용은 정체(plateau)되었습니다. 반면, stateless 비용은 40회 반복 시점에 80,000 토큰 이상의 이력이 누적되면서 계속해서 선형적으로 상승했습니다.

비교 분석

토큰 감소 비율은 상태 요약 대비 관측치의 크기에 반비례합니다.

• 작은 관측치: 고정 크기의 요약이 누적된 이력보다 훨씬 작기 때문에 높은 감소 비율(9.8배)을 보입니다.
• 큰 관측치: stateful 에이전트도 여전히 현재 코드 아티팩트를 전송해야 하므로 비율이 제한됩니다(2.0배). 그러나 본 논문은 반복 횟수가 증가함에 따라(예: 100회 또는 200회) $O(n^2)$와 $O(n)$의 격차가 벌어져 감소 비율이 크게 확대될 것임을 언급했습니다(4배에서 7배로 예상).

의의 및 주장

본 논문은 주요 기여가 최적화 품질의 개선이 아니라 구조적 효율성에 있다고 주장합니다. stateful 에이전트는 stateless 베이스라인과 유사한 최적화 품질을 달면서도 토큰 소비량을 획기적으로 줄였습니다.

• 확장성: 반복당 $O(1)$ 비용은 프롬프트 절단이나 의사 결정 능력의 손실 없이 임의의 길이의 실험 시퀀스를 가능하게 합니다.
• 경제적 영향: 짧은 실행에서는 절감 효과가 미미할 수 있으나, 매일 수백 개의 실험을 수행하는 대규모 연구와 같이 stateless 실행의 이차 함수적 비용이 주요 병목 현상이 되는 경우 그 영향은 매우 큽니다.
• 향후 전망: 저자들은 실험 범위가 길어짐에 따라 stateless 실행의 이차 함수적 토큰 비용이 주요 제약 사항이 될 것이며, 따라서 stateful 아키텍처가 지속 가능한 자율 실험을 위해 필수적이라고 제안합니다.

저자들은 관찰된 지표의 차이가 노이즈 범위 내에 있음을 명시하며, 이를 stateful 방식의 품질 우위로 해석해서는 안 된다고 밝히며 신중한 태도를 유지했습니다. 본 연구의 초점은 철저히 아키텍처 전환에 따른 효율성 이득에 맞춰져 있습니다.