복잡한 토폴로지 제어가 필요할까? 매 라운드 새 상대를 무작위로 뽑는 Multi-Agent Debate

Who Should Read

여러 LLM 에이전트에게 토론시켜 정답률을 높이려는데 토큰 비용이 부담되는 에이전트 개발자

Core Mechanics

• 매 라운드 새 상대 2명 뽑기
  • 에이전트 8명이 각자 매 라운드마다 자기 외 에이전트 중 서로 다른 2명을 무작위로 골라 답을 읽는다.
  • 이전에 만났던 상대도 다시 뽑힐 수 있고, 상대 선택에 상태 추정이나 학습은 필요 없다.
  • 논문은 이 방식을 Random-NoDup이라 부른다.
• 복잡한 라우팅은 일관된 이득이 없었다
  • 불확실성 기반 라우팅, 단계별 전환, 학습형 엣지 조정(AgentPrune 스타일)을 같은 조건에서 비교했다.
  • 전체 라운드 기준 Random-NoDup의 macro 정확도가 이들보다 높았다.
  • 특정 과제에서는 앞선 방식이 있었지만 과제를 넘어 이어지지 않았다.
• 토론은 짧게 끊어도 된다
  • 3라운드(소통 업데이트 2번)에서 끊으면 정확도는 비슷하고 토큰이 크게 줄었다.
  • 2~5라운드에서 macro 정확도가 거의 최고점이었고 그 뒤에는 토큰만 늘었다.
  • 3라운드가 최적이라는 주장은 아니고 이른 기준점일 뿐이라고 논문이 밝힌다.
• 적응형 중단은 이득이 적었다
  • 다수 답이 안정되면 멈추는 방식과 불확실성 기준 중단은 일부 과제에서만 정확도가 올랐다.
  • 대신 토큰이 더 들었고, 라우팅 제어를 더해도 전체 득실은 나아지지 않았다.

Evidence

• GPT-4o-mini, 5개 벤치마크 macro 기준 비용
  • 3라운드 Random-NoDup은 macro 정확도 77.33%, 토큰 12.36k/질문이다.
  • Ring(Sparse MAD)은 76.27%, 57.25k/질문이다.
• GPT-4o-mini, 전체 라운드 macro 정확도 비교
  • Random-NoDup 76.87%로 Ring 76.27%, 불확실성 라우팅 76.53%, AgentPrune 스타일 76.27%보다 높다.
  • 토큰은 57.38k/질문으로 Ring 57.25k와 비슷하다.
• GPT-4o-mini, 적응형 중단과의 비교
  • 불확실성 게이트 중단은 77.20%에 18.60k/질문, 다수 안정성 중단은 76.13%에 13.82k/질문이다.
  • 3라운드 고정(77.33%, 12.36k)이 정확도와 토큰 모두 앞선다.
• 교차 모델 GPQA-Diamond 정확도 변화
  • GPT-4o-mini에서 전체 라운드 Random-NoDup 42.00%에 비해 3라운드는 48.67%이다.
  • GPT-5.6 Luna에서는 GSM8K 98.67%에서 99.33%로 올랐다.

How to Apply

• 지금 쓰는 토론 라운드를 3으로 줄여 비교하기
  • 라운드를 많이 돌리는 MAD 파이프라인에서 평가셋으로 3라운드와 기존 라운드 수를 같은 조건에서 돌려라.
  • 정확도와 질문당 총 토큰(입력+출력)을 함께 기록하라.
• 에이전트별 참조 상대를 매 라운드 랜덤 재추첨하기
  • 고정 이웃 구조를 쓰고 있다면 라운드마다 자신을 뺀 에이전트 중 서로 다른 k명(논문은 2명)을 균등 추출하도록 바꿔라.
  • 이전 상대도 다시 뽑히게 두어라.
• 복잡한 라우터 도입 전 단순 기준선과 먼저 비교하기
  • 학습형 토폴로지나 적응형 라우팅을 검토 중이면 먼저 랜덤 라우팅과 짧은 토론을 같은 프롬프트·온도로 돌려라.
  • 이득이 보이지 않으면 라우터 개발을 미뤄라.
• 도메인 과제로 3라운드 컷 검증하기
  • 수학 문제처럼 긴 토론이 도움이 될 수 있는 과제는 자체 평가셋으로 라운드별 정확도 곡선을 그려라.
  • 비용 절감은 모델에 따라 일관됐지만 정확도 유지는 모델·과제에 따라 달랐다.

Try It

# 논문 방법의 간이 버전: Python으로 돌려보는 Random-NoDup 3라운드 토론 (call_llm은 직접 구현)

import random

N, K, ROUNDS = 8, 2, 3

def call_llm(prompt):
    raise NotImplementedError  # 사용하는 LLM API 호출로 교체

def debate(question):
    answers = [call_llm(f"Question: {question}\nAnswer concisely.") for _ in range(N)]
    for _ in range(ROUNDS - 1):
        new = []
        for i in range(N):
            peers = random.sample([j for j in range(N) if j != i], K)
            msgs = "\n".join(f"Peer {p}: {answers[p]}" for p in peers)
            new.append(call_llm(f"Question: {question}\nYour previous answer: {answers[i]}\n{msgs}\nGive your updated final answer."))
        answers = new
    return max(set(answers), key=answers.count)

# 이어서 해 볼 것: ROUNDS를 3과 14로 바꿔 같은 질문 세트의 정확도와 토큰 사용량을 비교해 보라.

Terminology

관련 논문

• 같은 시뮬레이션, 다른 근거: 도구 출력을 파일로 넘기면 LLM 에이전트 정확도가 어디서 깎이나

  긴 툴 출력을 파일로 넘기자 GPT-5.1은 정확도 11.3%p 하락, 정식 출력 지정하니 회복

• 가짜 뉴스가 진짜 폭락을: LLM 트레이딩 에이전트 대상 정보 주입 공격

  가짜 헤드라인 한 줄로 LLM 트레이딩 에이전트 62%를 조종했다(프롬프트 주입은 14%)

• Harness Engineering 101: LLM은 뇌, harness는 몸

  에이전트는 JSON 배열을 관리하는 루프이고, 16개 챕터로 직접 만들어 본다

• Harness²: 에이전트 harness를 스스로 고쳐 쓰는 재귀 최적화 프레임워크

  모델은 고정하고 harness를 재귀로 고쳤더니 벤치마크 점수가 최대 11.8%p 올랐다

• 해고된 Savannah 경찰관, ICE 요원 남편에게 Flock 계정 공유

  경찰관이 Flock 계정을 남편(ICE 요원)에게 공유했고, 감사에서 983건 검색이 드러나 해고됐다

• tmux와 Claude Code: 세션, send-keys, 그리고 한계선

  tmux로 Claude Code 여러 개를 돌리면 편하지만 에이전트 4개쯤에서 한계가 온다

• Hybrid Reasoning Agents: 잠재 공간에서 생각하고 텍스트로 행동하는 LLM 에이전트

  잠재 공간 추론과 텍스트 도구 호출을 섞었더니 성능 10.4%↑, 토큰 최대 54.7%↓