RecursiveMAS의 Claude 네이티브 버전을 구축했습니다

RecursiveMAS (arXiv 2604.25917)는 내부 추론 상태 (internal reasoning state)를 공유하는 에이전트가 최종 출력물 (final outputs)만을 공유하는 에이전트보다 성능이 뛰어나다는 것을 보여주었습니다. 벤치마크 전반에 걸친 평균 정확도 향상은 8.3포인트였습니다. 그 메커니즘은 다음과 같습니다: 각 에이전트가 단순히 정답만을 전달하는 것이 아니라, 자체 추론 과정에서 생성된 잠재 임베딩 (latent embeddings)을 전달하며, 다음 에이전트는 이 두 가지 모두를 조건 (condition)으로 삼습니다. 이 논문은 훌륭한 결과물입니다.

문제는 접근성입니다. RecursiveMAS는 추론 (inference) 시점에 은닉 상태 (hidden states)가 노출되는 오픈 웨이트 (open-weight) 모델을 필요로 합니다. 이로 인해 Claude, GPT-4o, Gemini는 제외됩니다. 저는 Anthropic의 확장된 사고 (extended thinking) API를 사용하여 Claude 네이티브 버전을 구축했습니다. 핵심 아이디어는 그대로 유지됩니다: 잠재 벡터 (latent vectors)를 전달하는 대신, 전체 사고 텍스트 (thinking text)를 전달하는 것입니다. 논문에서는 이를 내부 상태 공유 (internal state sharing)라고 부르며, Claude 버전에서는 사고 블록 전달 (thinking-block relay)이라고 부릅니다.

아키텍처 문제

Claude의 확장된 사고 블록 (extended thinking blocks)에는 시작된 대화와 연결된 암호화된 서명 (encrypted signature)이 포함되어 있습니다. 서명된 사고 블록을 다른 에이전트의 메시지 배열 (messages array)로 전달할 수 없습니다. API가 이를 거부하기 때문입니다. 해결 방법은 사고 블록에서 텍스트를 추출하여 일반 사용자 메시지 (user message)로 주입하는 것입니다.

# 에이전트 1에서 사고 텍스트 추출
thinking_text = next(
    (b.thinking for b in response.content if b.type == "thinking"), ""
...

서명은 전달되지 않지만, 추론 (reasoning)은 전달됩니다.

relay-structured: 제가 처음으로 구축한 것

첫 번째 아키텍처는 Planner > Critic > Solver 루프로, 각 에이전트가 가공되지 않은 사고 텍스트 대신 압축된 정신 모델 (mental model) JSON을 방출하는 방식이었습니다. 1024 토큰 예산 내에서의 가공되지 않은 사고는 종종 압축되고 파편화됩니다. 저의 가설은 150 토큰의 구조화된 신호 (structured signal)가 1024 토큰의 압축된 산문 (compressed prose)보다 토큰당 더 많은 정보를 담고 있다는 것이었습니다.

각 에이전트가 방출하는 스키마 (schema):

{
  "interpretation": "에이전트가 문제를 해석한 방식",
  "key_steps": ["단계 1", "단계 2"],
...

confidence (신뢰도)와 potential_errors (잠재적 오류)는 핵심적인 하중을 견디는 필드(load-bearing fields)입니다. 이 필드들은 하위 에이전트(downstream agents)가 전체 추론 과정(reasoning trace)을 파싱할 필요 없이, 어디에 더 세밀한 검토(scrutiny)를 적용해야 하는지 알려줍니다. "confidence: 0.4, potential_errors: x에 대한 제약 조건을 잘못 읽었을 수 있음"을 볼 수 있는 비평가(critic)는, 800개의 토큰으로 된 산문을 읽고 동일한 내용을 추론해야 하는 비평가와는 시작점부터 다릅니다.

결과 (n=50, 예비 결과)

조건	정확도 (Accuracy)	평균 토큰 (Avg tokens)
단일 에이전트 (single-agent)	70.0%	1,212
릴레이 구조 (relay-structured)	72.0%	18,821

+2포인트. 15배의 토큰 비용. 릴레이 구조(relay-structured)는 50개 중 단 한 문제에서 승리했습니다. 방향은 맞습니다. 하지만 비용 비율은 이대로 배포할 수 있는 수준이 아닙니다. 모든 요청에 대해 Planner > Critic > Solver 전체 체인을 실행하는 것은 n=50 기준에서 2포인트의 이득만으로는 정당화되지 않습니다.

왜 'read-before'를 구축하지 않았는가

명백한 다음 단계는 에이전트 2가 자신의 답변을 생성하기 전에 에이전트 1의 JSON을 읽게 하는 것입니다. 저는 이를 건너뛰었습니다. 문제는 앵커링(anchoring, 정박 효과)입니다. 에이전트 2는 자신의 견해를 형성하기 전에 에이전트 1의 답변을 보게 되며, 이는 도전을 하기보다는 확인하려는 경향을 보일 것입니다. 이는 수학적으로 역할 전문화(role specialization)가 제거되고 앵커링이 추가된 릴레이 구조(relay-structured)와 동일합니다. 예상되는 결과는 더 나빠지는 것이지 더 좋아지는 것이 아닙니다. 구축할 가치가 없었습니다.

'read-after' + 불일치 에스컬레이션 (disagreement escalation)

설계: 두 에이전트가 독립적으로 추론합니다. 추론 과정 중에는 공유된 컨텍스트(shared context)가 없습니다. 두 에이전트가 모두 완료한 후, API 호출 없이 코드 상에서 답변을 비교합니다. 만약 두 답변이 일치하면, 더 높은 신뢰도(confidence)를 가진 답변을 반환합니다. 만약 불일치한다면, 두 답변과 두 정신 모델(mental model) JSON을 모두 확인하여 더 강력한 추론 체인(reasoning chain)을 선택하는 리졸버(resolver)를 실행합니다.

독립적인 추론(Independent reasoning)을 우선시한다는 것은 앵커링(anchoring)이 없음을 의미합니다. 비교 단계는 순수하게 코드로 이루어지므로, 에이전트들이 의견이 일치할 때는 토큰 비용이 발생하지 않습니다. 리졸버(resolver)는 진정한 불일치가 발생할 때만 실행되며, 어려운 MATH 문제에 대해 5,000토큰 예산을 사용할 경우 이는 약 40%의 빈도로 나타납니다. 두 에이전트가 동의하는 쉬운 질문의 경우 비용은 단일 에이전트(single-agent)의 2배입니다. 리졸버가 필요한 더 어려운 질문의 경우 비용은 약 3.5배입니다. 두 경우의 가중 평균을 내면 단일 에이전트 대비 약 2.9배이며, 이는 relay-structured 방식의 15배와 대조적입니다.

구현의 핵심:

def run_self_relay(question, n_rounds=2, model=DEFAULT_MODEL, budget_tokens=DEFAULT_BUDGET):
    # 두 에이전트가 독립적으로 추론하며, 공유 컨텍스트(shared context)가 없음
    mm1, answer1, tokens1 = agent_call_structured("solver", question, [], [], model, budget_tokens)
...

결과

200개의 예시, MATH 레벨 4-5, claude-sonnet-4-6, 예산=5,000토큰, 예비 결과:

조건	정확도 (Accuracy)	평균 토큰 (Avg tokens)
single-agent	63.0%	1,234
self-relay	65.5%	3,290

self-relay는 단일 에이전트 대비 2.7배의 토큰 비용으로 2.5포인트의 정확도를 얻었습니다. 이는 2포인트를 위해 15배의 비용을 사용하는 relay-structured의 프로필과는 다릅니다. read-after 아키텍처는 약 6분의 1 수준의 토큰 오버헤드로 유사한 정확도 이득을 얻습니다. 이 벤치마크에서의 불일치율(disagreement rate)은 약 40%였으며, 이는 예상 범위와 일치합니다.

토큰 비용은 단일 에이전트의 2.7배입니다. relay-structured는 15배였습니다. 동일한 5,000토큰 예산에서 self-relay는 리졸버가 필요할 때만 실행되기 때문에 훨씬 적은 비용으로 유사한 정확도 이점을 얻습니다.

통계가 말해주는 것

+2.5pp(퍼센트 포인트)의 차이는 통계 검정(stat test)을 통과하지 못합니다. Wilson 95% 신뢰 구간(confidence intervals)이 겹칩니다: 단일 에이전트(single-agent)는 [56.1%, 69.4%], self-relay는 [58.7%, 71.7%]입니다. 두 점 추정치(point estimates) 모두 다른 조건이 동일하다는 가설과 완전히 일치합니다.

McNemar 검정은 self-relay가 승리하는 경우와 단일 에이전트가 승리하는 경우가 동일하게 분포하는지 묻습니다. 약 40%의 불일치(disagreement)와 관찰된 순이익(net gain)을 고려할 때, 현실적인 불일치 분할(discordant split)은 200개의 예시 중 self-relay 승리 약 22건 대 단일 에이전트 승리 18건으로 나타납니다. chi2=0.23, p는 약 0.89입니다.

80%의 검정력(power)으로 실제 2.5pp 효과를 감지하려면 약 5,767개의 예시가 필요합니다. 현재의 n(표본 크기)은 29배나 너무 작습니다. GSM8K의 테스트 세트는 대략 1,319개의 예시를 가지고 있습니다. 전체 MATH 데이터셋은 대략 5,000개를 보유하고 있습니다. 표준 벤치마크들은 이토록 작은 개선을 확인하기에는 충분히 크지 않습니다.

측정 메커니즘이 제대로 작동하는지 확인하기 위해 n=5 비용 프로브(cost probe)에서 보정(calibration) 스크립트를 실행했습니다. 불일치율(Disagreement rate)은 40%로 이전 실험과 일치했습니다. 다섯 가지 예시 모두 에이전트의 최대 신뢰도(max agent confidence)가 0.8 이상이었으므로, 신뢰도 게이팅(confidence-gating)을 적용했다면 모두 단일 에이전트로 라우팅되었을 것입니다. 리졸버(Resolver)는 2개의 불일치 사례 중 1개를 해결했으며, 이는 동일한 문제에 대한 단일 에이전트의 성공률과 같습니다. 이는 새로운 발견이 아니라, 단지 스크립트가 실행된다는 증거일 뿐입니다.

비용의 아주 일부만 사용하여 어려운 벤치마크에 대한 방향성을 제시하는 것은 유용합니다. 다만 아직 결과라고 할 수는 없습니다. 6,000개의 예시로 실행한다면 결과가 될 것입니다. 사전 등록(pre-registering)하고 재현(replicating)하는 것도 마찬가지입니다. 지금 통계 검정을 보고하는 것은 아키텍처에 대한 비관론이 아닙니다. 그것은 패턴과 우연의 차이를 구별하는 방법입니다.

이것이 프로덕션에 적용되는 방식

Self-relay는 오답의 비용이 두 번째 호출(second call)의 비용을 초과하는 모든 곳에 적합합니다. 법률 문서 검토, 코드 보안 감사, 의료 트리아지(medical triage), 금융 분석 등이 이에 해당합니다. 이러한 작업에서 두 개의 독립적인 추론 체인(reasoning chains)을 실행하고, 두 체인이 불일치할 때만 중재(arbitration) 비용을 지불하는 것은 직관적인 신뢰성 패턴(reliability pattern)입니다.

실제 배포 방식은 항상 켜져 있는 중계(always-on relay)가 아니라 신뢰도 게이팅(confidence-gating) 방식입니다. 먼저 단일 에이전트(single-agent)를 실행한 다음, 멘탈 모델 (mental model) JSON에서 confidence 필드를 확인합니다. 만약 신뢰도가 임계값(threshold)보다 높으면 답변을 반환합니다. 그렇지 않으면 셀프 중계(self-relay)로 에스컬레이션(escalate)합니다.

def answer_with_confidence_gate(question, threshold=0.75, model="claude-sonnet-4-6", budget=5000):
    # 1차 통과: 멘탈 모델을 가진 단일 에이전트
    mm, answer, tokens = agent_call_structured("solver", question, [], [], model, budget)
...

질문의 약 2530%가 임계값 미만으로 떨어지는 실제 워크로드(workload)에서, 이 방식은 평균 토큰 오버헤드(token overhead)를 단일 에이전트 대비 2.7배에서 약 1.31.5배로 낮춰줍니다. 중계(relay)는 실제로 필요한 요청에 대해서만 실행됩니다.

다음에 시도해 볼 것

n=500 임계값은 트리거되지 않았으므로(65.5%가 72.0% 미만), 이 결과들은 n=200 상태로 유지됩니다. 다음으로 유용한 테스트는 신뢰도 임계값(confidence threshold)을 보정(calibrating)하는 것입니다. 어느 수준에서 셀프 중계로 에스컬레이션했을 때 정답을 회복하는지, 그리고 잘못된 에스컬레이션 비율(false-escalation rate)은 어느 정도인지 확인해야 합니다. 또한 법률 검토나 코드 분석과 같은 도메인 특화 벤치마크(domain-specific benchmark)를 통해, 불일치 패턴(disagreement pattern)과 해결사 정확도(resolver accuracy)가 경시대회 수학 이외의 영역에서도 유지되는지 스트레스 테스트(stress-test)를 진행할 것입니다.

리포지토리(repo)는 github.com/bhj37193/relay에 있습니다. 평가 하네스(eval harness)는 relay/eval_structured.py에 있으며, 모든 결과는 eval_structured_results.json에 포함되어 있습니다.