SearchOS-V1 - Towards Robust Open-Domain Information-Seeking Agent Collaboration
Y. Zhang, J. Gao, Z. Wu, J. Fan, J. Zhang, S. Ma, Y. Yao, W. Qi, C. Jin, G. Ma, X. Xu, K. Yang, J.-R. Wen, and Z. Dou, "SearchOS-V1: Towards Robust Open-Domain Information-Seeking Agent Collaboration," arXiv:2607.15257, 2026.
저자
이 논문은 인민대학교(Renmin University of China) 가오링 인공지능대학(Gaoling School of AI)과 앤트 그룹(Ant Group) 간의 협력으로 탄생했습니다.
제1저자(equal contribution)는 가오링 AI 대학 박사과정생 장위야오(Yuyao Zhang, 앤트 그룹 인턴)와 앤트 그룹의 가오쥔제(Junjie Gao)입니다. 교신저자는 더우즈청(Zhicheng Dou)과 원지룽(Ji-Rong Wen) 교수입니다.
더우즈청 교수는 인터넷 규모 검색과 정보 검색을 20년 넘게 연구해온 RUC-NLPIR 연구실을 이끌고 있습니다. 원지룽 교수는 14년간 마이크로소프트 리서치 아시아(MSRA)에서 웹 검색·데이터 마이닝 그룹을 이끈 뒤 인민대학교에 합류해 현재 AI 대학장을 맡고 있습니다. 두 사람 모두 검색 시스템을 운영 인프라 수준에서 설계해온 배경이 이 논문의 핵심 설계 철학으로 이어졌습니다.
배경
ReAct, Plan-and-Solve 같은 도구 통합 에이전트는 웹 검색을 핵심 능력으로 탑재했습니다. 단순 질의에서는 잘 작동하지만, 수집해야 할 사실이 수백 개에 달하는 "넓은 검색(wide search)" 과제에서 이 에이전트들은 공통된 패턴으로 무너집니다.
대화 히스토리가 길어질수록 에이전트는 이미 수집한 증거를 잊습니다. 막힌 경로에서 빠져나오지 못하고 같은 쿼리를 반복 전송하다가 예산을 소진합니다. 에이전트를 여러 개 띄워도 해결되지 않습니다. 이번엔 에이전트끼리 같은 정보를 중복 수집하거나 처리 슬롯이 가장 느린 에이전트를 기다리며 유휴 상태에 빠집니다.
이 실패들의 공통 원인은 하나입니다. 계획, 진행 상황, 증거, 실패 이력이 모두 대화 히스토리라는 휘발성 공간 안에 있다는 점입니다. 시스템이 상태를 관리해주지 않으니 에이전트가 스스로 추론할 수밖에 없고, 컨텍스트 창이 차면 그 추론도 실패합니다.
SearchOS는 이 문제를 정면으로 공략합니다. 검색 상태는 에이전트 대화에서 매번 추론되는 것이 아니라, 시스템이 관리하는 영속적 구조로 외부화되어야 합니다.
어떻게 만들었나
SearchOS의 구조는 네 레이어로 구성됩니다.
검색 목표를 관계형 스키마로 정의
자연어 질문 \(q\)가 들어오면 시스템은 이를 관계형 탐색 스키마로 변환합니다:
\[\mathcal{S} = \left(\{T_m\}_{m=1}^M, \mathcal{R}\right), \quad T_m = (\mathcal{A}_m, \mathcal{P}_m)\]
각 테이블 \(T_m\)은 속성 집합 \(\mathcal{A}_m\)과 기본키 \(\mathcal{P}_m\)을 정의하고, \(\mathcal{R}\)은 테이블 간 외래키 관계를 담습니다. "북경 여행지와 주변 5성급 호텔 5박 일정"을 묻는다면, 여행지·호텔·일정 세 테이블이 연결된 스키마 하나가 만들어집니다.
모든 값에는 출처 URL과 본문 인용 발췌를 포함한 인용 행렬 \(C_m\)이 붙습니다. 검색 결과가 단순히 대화에 쌓이는 게 아니라 어느 행·어느 열에 해당하는 증거인지 명확히 기록됩니다.
SOCM: 검색 상태의 외부화
Search-Oriented Context Management(SOCM)는 모든 에이전트가 공유하는 네 가지 상태 구조를 유지합니다:
\[\mathcal{M}_t = \left(\mathcal{F}_t,\, \mathcal{G}_t,\, \mathcal{C}_t,\, \mathcal{W}_t\right)\]
- Frontier Task \(\mathcal{F}_t\): 의존성 DAG로 표현된 작업 큐. 선행 작업이 모두 완료되어야 실행 가능 상태(\(\text{PENDING}\))로 전환됩니다.
- Evidence Graph \(\mathcal{G}_t\): 원자 단위의 발견을 보관하는 그래프. 각 노드는 값, 출처 URL, 본문 스팬, 스키마 바인딩, 신뢰도, 출처 계층을 함께 기록합니다. 노드 간 관계는 \(\{\)SUPPORT, CONFLICT, REFINE\(\}\) 중 하나로 레이블됩니다.
- Coverage Map \(\mathcal{C}_t\): 각 스키마 셀의 상태(미수집·수집완료·불확실·불가)를 추적합니다. 커버리지는 다음과 같이 계산됩니다:
\[\text{Cov}(\mathcal{C}_t) = \frac{\displaystyle\sum_{c \in \Omega_t} \mathbf{1}[s(c) = \text{FILLED}]}{|\Omega_t| + \displaystyle\sum_{m:\, |\mathcal{E}_m(t)|=0} |\mathcal{A}_m|}\]
- Failure Memory \(\mathcal{W}_t\): 반복된 무익한 쿼리, 접근 불가 사이트, 효과 없는 전략을 기록합니다. 같은 실패를 여러 에이전트가 반복하는 것을 막습니다.
에이전트 각자는 전체 상태가 아닌 역할별 투영 \(\phi_r(\mathcal{M}_t;\, z_t)\)만 받습니다. 오케스트레이터는 전체 커버리지 공백을, 탐색 에이전트는 담당 셀 정보를, 작성 에이전트는 요약만 받습니다.
파이프라인-병렬 오케스트레이션
배치 방식은 한 라운드의 모든 작업이 끝날 때까지 다음 라운드를 기다립니다. 가장 느린 에이전트가 전체 처리량을 제한합니다. SearchOS는 GPU 학습의 파이프라인 병렬 처리(GPipe, PipeDream)에서 착안한 연속 디스패치를 씁니다:
\[\mathcal{D}_t = \text{Top}_{\min(b_t,\, |\mathcal{R}_t|)}(\mathcal{R}_t;\, p)\]
실행 슬롯이 하나 해제되면 즉시 준비된 작업 큐 \(\mathcal{R}_t\)에서 우선순위 \(p\) 순으로 다음 작업을 채웁니다. 에이전트끼리 기다리는 유휴 시간이 사라집니다.
검색 도구 미들웨어 하네스
에이전트에게 프롬프트로 "맥락이 길어지면 규칙을 지켜라"고 강제하는 방법은 신뢰하기 어렵습니다. SearchOS는 에이전트 루프를 가로채는 시스템 레이어를 씁니다:
\[\tilde{h}_t^{(r)} = H_\text{ctx}(h_t, \mathcal{M}_t), \quad \mathcal{M}_{t+1} = H_\text{evidence}(o_t, \mathcal{M}_t), \quad a_{t+1} = H_\text{sensor}(\mathcal{M}_t, \mathcal{M}_{t+1}, \xi_t)\]
- Context Middleware: 매 LLM 호출 전, SOCM 상태와 관련 스킬을 컨텍스트에 주입합니다. 예산 압박 시 오래된 히스토리를 쳐내되 상태와 활성 제약은 유지합니다.
- Evidence Extraction Middleware: 도구 실행 후, 관찰 결과에서 스키마에 바인딩되고 본문에 앵커된 증거만 수락합니다(\(\text{Bind}(z, \mathcal{S}) = 1 \wedge \text{Anchor}(z, o_t) = 1\)). Evidence Graph와 Coverage Map을 원자적으로 갱신합니다.
- Sensor Middleware: 커버리지 증가량 \(\Delta_t^\text{cov}\)와 증거 증가량 \(\Delta_t^\text{ev}\) 모두 윈도우 \(w\) 안에서 정체되면 스톨 신호를 내고, 전략 전환이나 분기 중단을 강제합니다.
계층적 검색 스킬 (280개)
스킬 라이브러리는 세 층으로 구성됩니다. 오케스트레이터 스킬은 전체 작업 분해와 스키마 정렬 방법을 담습니다. 전략 스킬은 쿼리 재정식화, 멀티홉 추론, 스톨 회복처럼 소스 독립적인 방법론을 제공합니다. 접근 스킬은 특정 사이트(정부 포털, 백과사전, 기업 사이트 등)에 맞춤화된 추출 로직으로, typed executor와 결합되어 에이전트가 URL 파싱을 직접 하지 않아도 됩니다.
SearchOS-V1은 commercial(138), government(36), organization(33) 등 총 280개 스킬을 보유합니다.
결과
WideSearch(200개 질문, 영중 각 100개)와 GISA(373개 질문, 4가지 구조적 답변 형식) 두 벤치마크에서 단일·다중 에이전트 기준선 전체를 앞질렀습니다.
WideSearch 및 GISA 주요 결과:
지표 |
ReAct |
Plan-and-Solve |
A-MapReduce |
Web2BigTable |
SearchOS |
개선 |
|---|---|---|---|---|---|---|
WideSearch Item F1 |
72.9 |
75.2 |
76.0 |
73.8 |
80.3 |
+4.3 |
WideSearch Row F1 |
50.9 |
52.2 |
51.4 |
54.5 |
56.5 |
+2.0 |
GISA Set F1 |
61.6 |
63.1 |
62.5 |
56.7 |
76.5 |
+13.4 |
GISA List F1 |
67.1 |
53.8 |
57.4 |
65.5 |
68.1 |
+1.0 |
GISA의 Set 질문에서 +13.4점 개선이 가장 두드러집니다. 집합을 빠짐없이 열거해야 하는 문제에서 Evidence Graph와 커버리지 추적이 직접 효과를 냈습니다. WideSearch에서는 Recall 쪽 개선이 집중되었는데, 커버리지 인식 디스패치로 빠진 셀을 줄이는 설계 의도와 일치합니다.
파이프라인-병렬 스케줄링 효과 (WideSearch 30개 궤적 평균):
스케줄링 방식 |
처리 시간 (s) |
슬롯 활용률 |
처리량 (task/min) |
LLM 호출 |
Item F1 |
|---|---|---|---|---|---|
배치 (대기) |
629.1 |
34.6% |
2.99 |
341.4 |
79.66 |
연속 디스패치 |
476.3 |
41.7% |
3.37 |
296.6 |
86.75 |
연속 디스패치는 처리 시간을 24.3%, LLM 호출을 13.2% 줄이면서 F1을 7점 이상 올렸습니다. 품질 향상이 추가 연산이 아닌 유휴 시간 제거에서 비롯된다는 것을 보여줍니다.
스킬 적용 효과 (WideSearch 100개 질문):
설정 |
Item F1 |
Row F1 |
평균 세션 시간 |
검색 호출 |
페이지 호출 |
|---|---|---|---|---|---|
스킬 없음 |
78.3 |
53.1 |
21.75분 |
154.1 |
240.6 |
스킬 적용 |
80.3 |
56.5 |
13.78분 |
93.8 |
137.8 |
개선 |
+2.0 |
+3.4 |
-36.6% |
-39.1% |
-42.7% |
스킬이 시행착오를 줄이면서 동시에 품질을 높였습니다. 알려진 방법을 재사용하면 탐색 비용이 사라집니다.
회고
저자들이 직접 밝힌 현재 한계입니다.
첫째, 스킬 합성 미공개. SearchOS-V1은 미리 구축된 280개 스킬에 의존합니다. 대규모 검색 궤적과 사용자 의도에서 스킬을 자동으로 합성하는 방법은 "Stay tuned!" 한 줄로만 예고하고 후속 논문에 미뤘습니다.
둘째, 백본 모델 단일 구성. 실험에서 GLM-5(오케스트레이터·에이전트)와 Qwen3.5-35B-A3B(증거 추출)를 사용했습니다. 다양한 모델과 도메인 간 적응성은 검증되지 않았습니다.
셋째, 평가 방식의 낙관성. Max@3(동일 입력에 3번 실행 후 최고값 보고) 방식을 사용했습니다. 실전 배포에서의 단회 실행 성능과 차이가 있을 수 있습니다.
더불어, SOCM의 잠금(locked read-modify-write) 메커니즘이 고부하 상황에서 병목이 될 가능성은 논문에서 다루지 않았습니다.
정리
- 검색 상태(진행 현황, 증거, 실패 이력)를 대화가 아닌 시스템 레이어(SOCM)로 분리해 장기 검색의 반복 루프 문제를 구조적으로 해결했습니다.
- 파이프라인-병렬 연속 디스패치로 배치 대비 처리 시간 24.3% 단축, F1 7점 향상.
- WideSearch Item F1 80.3, GISA Set F1 76.5로 모든 기준선 상회. 특히 집합 열거 과제에서 +13.4점.