미해결 정보 요구를 기준으로 다중 에이전트 탐색을 조율하는 ANTMAN

ANTMAN: Adaptive Need Tracking for Multi-Agent Navigation in Large Information Spaces

HF Daily2609.33326

Jerry Wang, Haibo Jin, Xiaopeng Yuan2026-09-27조회 3

무엇인가

이 논문은 정보 탐색 에이전트가 감당할 수 없을 만큼 큰 정보 공간을 다룰 때 생기는 비용 구조 문제를 지적한다. 기존의 다중 에이전트 시스템 상당수는 입력을 고정 크기로 잘라 각 조각을 별도 워커에 배정한다. LongAgent처럼 청크를 나눠 멤버 에이전트에 할당하는 방식이 대표적인데, 이 설계는 개별 워커의 컨텍스트 부담은 줄이지만 에이전트 수가 정보 공간의 분할 개수에 비례해 늘어난다. 질의가 실제로 요구하는 정보량은 그대로인데 검색 가능한 컨텍스트만 커져도 조율 규모가 기계적으로 팽창한다는 것이 저자들이 보는 핵심 불일치다.

어떻게 동작하나

ANTMAN은 이 문제를 풀기 위해 런타임 조율의 단위를 입력 분할이 아니라 진화하는 미해결 정보 요구로 바꾼다. 구조는 세 층이다. 첫째, 정적 기질 맵은 정보 공간을 결정론적으로 M개의 영역으로 나누고 각 영역에 경량 메타데이터인 WorkerCard를 붙인다. 이는 어떤 워커가 존재하는지를 정의할 뿐, 매 질의마다 모두 참여해야 한다는 뜻이 아니다. 둘째, 수정 가능한 Need Graph G_t=(N_t, Δ_t)가 실행 상태를 들고 있다. 각 니즈 노드 n은 해결 상태, 누적 증거, 이전 시도 이력, 현재 진행 상태의 네 값을 갖는다. 셋째, 이 그래프가 워커 선택과 라우팅을 통제한다.

무엇과 다른가

실행 루프는 Select, Route, Exec의 세 단계다. 현재 그래프에서 미해결 니즈 하나를 고르고, 그래프와 WorkerCard를 근거로 어느 영역으로 보낼지 정한 뒤, 해당 영역 워커에게 실행을 맡긴다. 워커는 전체 과제를 재구성하지 않고 배정된 범위 안에서만 국소적으로 탐색해 증거·진행·잔여 불확실성을 담은 구조화 보고를 돌려준다. 이 보고는 그래프 갱신 연산 U를 통해 다시 반영되며, 갱신은 니즈를 해결하거나, 미해결로 남기거나, 실패한 니즈를 다른 형태로 재구성하거나, 새 증거가 드러낸 추가 의존성을 삽입할 수 있다. 진행이 막히면 니즈 재구성, 다른 영역으로의 재라우팅, 대체 해결 경로 호출 같은 국소 복구를 수행한다. 저자들은 이 설계가 공간 크기와 활성 조율을 분리한다는 것을 |A(q)| ≤ min{M, ρH(q)} 형태의 상한으로 제시한다. 실제로 실현된 정보 수요가 유한하면, 정보 공간이 커져 M이 늘어도 활성 조율은 따라 늘지 않는다는 것이다.

어떻게 쓰나

실험은 세 갈래다. 먼저 HotpotQA, 2WikiMultiHopQA, MuSiQue에서 벤치마크당 30문항, 9개 방법으로 총 810개 예측을 GPT-4.1 기반으로 평가했고, ANTMAN은 집계 성능이 가장 좋았으며 S2G-RAG 같은 전용 검색 시스템과도 경쟁력이 있었다. 오케스트레이터만 GPT-4.1을 쓰고 나머지를 Qwen3-8B로 바꾼 ANTMAN-H도 HotpotQA에서 전체 ANTMAN과 동일한 성능을 냈다. 두 번째는 LongAgent의 다중 니들 설정을 따른 통제 실험으로, 32K·64K·128K·512K 컨텍스트에서 증거 위치를 Early·Middle·Late로 바꿔가며 10개 질문을 평가했다. 검색 공간이 16배 커질 때 ANTMAN의 활성 조율은 1.23배만 증가한 반면 LongAgent와 CoA는 15배 이상 늘었다. 반대로 공간을 512K로 고정하고 필요한 증거를 1개에서 16개로 늘리면 활성 워커는 5.0개에서 8.0개로, 질의당 모델 호출은 35.5회에서 86.2회로 증가했고 모든 정답을 맞혔다. 조율이 공간이 아니라 수요를 따른다는 것을 양방향으로 확인한 셈이다.

전제와 한계

세 번째는 실제 구조 탐색 환경이다. 8개 대형 파이썬 저장소의 108문항으로 구성된 RepoProbe-Python, 다중 파일 코드베이스 탐색이 필요한 SWE-QA-Pro의 동결된 80문항 부분집합, 그리고 텍스트 전용 GAIA-Text-103에서 평가했다. ANTMAN은 벤치마크 특화가 아닌 가장 강한 베이스라인 대비 RepoProbe에서 15.3%, SWE-QA-Pro에서 18.4%, GAIA에서 27.9% 앞섰다. ANTMAN-H는 각각 전체 ANTMAN 성능의 89.2%, 93.5%, 98.3%를 유지했다. 절제 실험에서는 명시적 Need Graph를 그래프 없는 적응적 재계획으로 대체하면 512K에서 23.82%, GAIA에서 16.67% 성능이 떨어졌다. 위치 민감도도 줄어, Early·Middle·Late 배치에서 ANTMAN의 중간 위치 격차는 +0.015였고 전체 컨텍스트 직접 추론은 -0.181이었다.

개발자 관점에서 이 논문이 주는 실무적 시사점은 명확하다. 긴 컨텍스트를 청크로 잘라 워커를 늘리는 구조를 쓰고 있다면, 컨텍스트가 커질 때 모델 호출과 비용이 분할 수에 비례해 늘어나는지 먼저 확인해야 한다. ANTMAN은 그 대신 남은 질문 목록을 명시적 상태로 유지하고, 그 상태가 워커 활성화와 라우팅을 결정하게 한다. 또한 조율 정책을 기질별 검색 인터페이스와 분리했기 때문에, 문서 컬렉션이든 코드 저장소든 웹 도구 환경이든 같은 메커니즘을 재설계 없이 옮길 수 있다는 점이 실무 적용에서 중요하다. 워커를 8B급 소형 모델로 내려도 성능 대부분이 유지된다는 결과는 비용 설계에도 직접 참고할 만하다.

저자들이 밝힌 전제와 한계도 분명하다. GAIA에서 ANTMAN-H와 전체 ANTMAN의 격차는 대부분 Level 3에서 발생했고, 즉 어려운 과제일수록 전체 ANTMAN이 유리하다. 또한 GAIA는 단일 영역 워커를 쓰기 때문에 적응적 재라우팅 절제가 아무 효과가 없었고, 복구 메커니즘은 통제 스케일링 실험에서, 재라우팅은 저장소 탐색에서 각각 중요하게 작용하는 등 런타임 기제의 기여가 환경마다 다르다. 향후 과제로는 더 다양한 정보 기질로의 확장, 정보 니즈의 전이 가능한 표현 개발, 탐색 진행에 따른 니즈 수정·라우팅 정책의 정교화를 제시한다.