SearchOS-V1: Towards Robust Open-Domain Information-Seeking Agent Collaboration
https://arxiv.org/abs/2607.15257
Yuyao Zhang, Junjie Gao, Zhengxian Wu, Jiaming Fan, Jin Zhang, Shihan Ma, Yao Yao, Weiran Qi, Chuyan Jin, Guiyu Ma, Xingzhong Xu, Kai Yang, Ji-Rong Wen, Zhicheng Dou | Gaoling School of Artificial Intelligence, Renmin University of China; Ant Group | arXiv:2607.15257 | 2026년 7월
1. 서론: 검색 기록을 넘어 검색 상태를 운영하는 시스템
도구 통합 대형 언어모델은 웹 검색을 호출하고, 페이지를 읽고, 얻은 단서를 바탕으로 다음 질의를 만드는 정보 탐색 에이전트로 발전했다. 짧은 사실 확인에서는 이 반복만으로도 충분할 수 있지만, 수십 개의 엔티티와 속성을 여러 출처에서 수집해야 하는 장기·개방형 정보 탐색에서는 문제가 달라진다. 에이전트는 단지 관련 페이지를 찾는 것을 넘어 무엇을 이미 확인했는지, 어느 필드가 비어 있는지, 어떤 값이 어느 출처에서 왔는지, 어느 검색 경로가 실패했는지를 실행 내내 유지해야 한다.
기존 에이전트는 이런 정보를 대체로 대화 기록 안에 둔다. 검색 질의, 도구 출력, 페이지 요약, 중간 추론이 시간순으로 쌓이고 모델은 긴 history를 다시 읽어 현재 상태를 추정한다. 그러나 실행이 길어지면 중요한 근거가 오래된 관찰 사이에 묻히고, 이미 채운 항목을 다른 에이전트가 다시 찾거나, 서로 충돌하는 값을 알아차리지 못하거나, 아직 조사하지 않은 엔티티를 누락하기 쉽다. 실패한 질의와 접근 불가능한 사이트도 명시적인 상태로 남지 않으면 조금 다른 표현으로 반복된다.
다중 에이전트를 붙인다고 이 문제가 자동으로 해결되지는 않는다. 여러 worker가 같은 대상을 중복 조사할 수 있고, 서로 다른 필드 정의를 전제로 결과를 제출할 수 있으며, 동기식 batch에서는 가장 느린 작업이 끝날 때까지 이미 비어 있는 실행 slot이 놀 수 있다. 즉 병목은 검색 모델의 개별 능력만큼 계획, 진행률, 증거, 실패를 어느 계층이 소유하는가에 있다.
SearchOS-V1은 이 문제에 대해 “검색 상태는 대화 기록에서 매번 추론하는 대신 시스템이 유지해야 한다”는 원칙을 제시한다. 자연어 요청을 인용 근거가 붙은 관계형 schema 완성 문제로 바꾸고, 현재 작업과 증거, coverage, 실패를 Search-Oriented Context Management(SOCM)에 외부화한다. Orchestrator는 이 공유 상태를 읽어 미해결 gap을 작업으로 만들고, explore·search agent는 범위가 제한된 조사만 수행하며, optional writer는 완성된 상태를 인용 보고서로 합성한다.
1.1 SearchOS가 겨냥하는 네 가지 실행 실패
| 실패 축 | 대화 기록 중심 에이전트에서 생기는 현상 | SearchOS의 대응 | 운영상 의미 |
|---|---|---|---|
| 진행률 망각 | 이미 채운 값과 아직 비어 있는 필드를 긴 history에서 다시 추정 | Coverage Map과 Frontier Task로 cell 수준 상태를 명시 | 누락과 중복 수집을 측정·제어 가능 |
| 근거 매몰 | 값, URL, 인용 span의 연결이 요약 속에서 흐려짐 | Evidence Graph와 citation matrix로 원자적 provenance를 보존 | 각 값의 독립 검증과 충돌 감사 가능 |
| 실패 반복 | 무정보 질의, 접근 실패, 막다른 branch를 여러 agent가 재시도 | Failure Memory가 실패 signature와 교정 지침을 공유 | 검색 budget을 같은 실패에 다시 쓰는 일을 줄임 |
| 병렬 자원 낭비 | 동기식 batch가 straggler를 기다리고 중복 task가 slot을 점유 | pipeline-parallel continuous dispatch와 dispatch-time 재검증 | slot이 비는 즉시 다음 미해결 gap에 재할당 |
이 표의 핵심은 SearchOS가 더 많은 agent를 투입하는 방식보다 먼저 공유할 artifact의 구조를 정한다는 점이다. Worker끼리 자유로운 자연어 대화를 늘리는 대신, 모든 agent가 같은 schema와 상태 version을 기준으로 움직이게 한다. 따라서 협업의 단위도 “이 주제를 조사해 달라”는 느슨한 요청에서 특정 table·entity·attribute cell을 채우는 작업으로 바뀐다.
1.2 논문의 네 가지 기여
첫 번째 기여는 개방형 정보 탐색을 grounded citation을 포함한 관계형 schema completion으로 정식화한 것이다. 엔티티를 발견하고 속성 값을 채우는 일에 더해, 각 값에 URL과 근거 span을 연결하는 일까지 하나의 출력 계약으로 묶는다. 단일 flat table을 넘어 primary key와 foreign key로 이어진 여러 table을 허용하므로, 일대다 관계나 서로 다른 엔티티 유형도 중복을 줄인 구조로 표현할 수 있다.
두 번째는 stateful, pipeline-parallel collaboration이다. SOCM이 미해결 작업, 원자적 증거, coverage, 실패를 공유하고, orchestrator가 최신 상태에서 우선순위를 다시 계산한다. Worker가 하나 끝날 때마다 상태를 반영하고 빈 slot을 즉시 채우므로, 고정 batch의 가장 느린 작업을 기다리는 시간을 줄인다.
세 번째는 Search Tool Middleware Harness다. 장기 실행에서 반드시 지켜야 할 evidence anchoring, context projection, budget enforcement, stall detection을 agent의 자발적인 tool 사용이나 prompt 준수에 맡기지 않는다. Model call과 tool call의 경계에서 middleware가 개입해 관찰을 구조화하고 전역 불변조건을 유지한다.
네 번째는 계층형 search skill이다. 전체 조정 방법, 출처에 독립적인 검색 전략, 특정 사이트에 접근하고 추출하는 절차를 분리한다. SearchOS-V1은 280개의 사전 구축 skill을 포함하며, task와 source에 맞는 일부만 각 agent에 노출한다. 논문이 강조하는 범위는 대규모 skill 합성 자체보다, 이런 skill을 검색 실행 상태와 결합해 재사용하는 시스템 기반에 있다.
논문 서론은 이 설계가 WideSearch와 GISA의 평가 대상 single-agent·multi-agent baseline 가운데 보고된 F1 지표를 모두 앞섰다고 요약한다. 대표적으로 WideSearch item-level F1 80.3, GISA set F1 76.5를 기록하며, GISA set F1에서는 가장 강한 baseline보다 13.4 point 높다. 다만 이 수치는 뒤의 실험 설정과 평가 protocol을 함께 읽어야 하며, 1~3절에서 더 중요한 주장은 점수 자체보다 검색 진행률을 관찰 가능한 system state로 바꾼 설계다.
2. 문제 정식화: 인용 근거가 붙은 관계형 schema 완성
2.1 자연어 요청을 관계형 검색 목표로 변환하기
SearchOS는 자연어 요청 $q$를 받으면 먼저 관계형 검색 schema를 구성한다. 논문의 표기는 $\mathcal{S}=(\{T_m\}_{m=1}^{M},\mathcal{R})$이고, 각 table은 $T_m=(\mathcal{A}_m,\mathcal{P}_m)$이다. $\mathcal{A}_m$은 table $m$의 attribute 집합, $\mathcal{P}_m$은 entity를 식별하는 primary-key attribute 집합이며, $\mathcal{R}$은 table 사이의 foreign-key relation을 담는다. 전체 task는 $\mathcal{T}=(q,\mathcal{S})$로 정의된다.
예를 들어 사용자가 여러 연구기관과 그 기관이 발표한 모델, 각 모델의 공개일과 평가 점수를 조사해 달라고 요청했다고 하자. 모든 정보를 한 table에 넣으면 기관 정보가 모델 행마다 반복되고, 한 모델에 여러 benchmark 결과가 있을 때 행 구조가 불안정해진다. 관계형 표현에서는 기관 table, 모델 table, 평가 결과 table을 나누고 institution ID와 model ID를 foreign key로 연결할 수 있다. 검색 중 발견한 관계를 명시적으로 표현하면서 동일 사실의 중복·불일치 가능성을 줄이는 방식이다.
이 formulation의 중요한 변화는 검색 성공 기준을 문장 수준의 “그럴듯한 답”에서 schema cell의 채움 여부로 내리는 것이다. 요청에서 요구한 entity와 attribute가 무엇인지 구조가 드러나므로 orchestrator는 “조사를 계속할까”보다 “어느 row의 어느 cell이 아직 비었는가”를 기준으로 다음 task를 만들 수 있다. 검색 범위가 넓어져도 진행률을 동일한 좌표계에서 계산할 수 있다.
2.2 값 행렬과 citation matrix
각 table $m$에 대해 시스템은 entity 집합 $\mathcal{E}_m=\{e_{m,i}\}_{i=1}^{N_m}$을 발견하고, 값 행렬 $\mathbf{Y}_m\in\mathcal{V}^{N_m\times |\mathcal{A}_m|}$을 채운다. 일반적인 table completion이라면 여기서 끝날 수 있지만, SearchOS는 같은 shape의 citation matrix $\mathbf{C}_m$을 함께 유지한다. $\mathbf{Y}_m[i,a]$에 값이 들어가면 $\mathbf{C}_m[i,a]$에는 그 값을 뒷받침하는 source URL과 observation 안에서 anchor된 excerpt가 연결되어야 한다.
최종 구조 출력은 $\mathcal{O}=\{(\mathcal{E}_m,\mathbf{Y}_m,\mathbf{C}_m)\}_{m=1}^{M}$으로 표현된다. 이 정의는 citation을 최종 writer가 문장 끝에 덧붙이는 장식으로 보지 않는다. 값과 근거가 같은 index를 공유하기 때문에 각 cell은 독립적으로 검증할 수 있고, 같은 값에 여러 source가 있거나 서로 다른 값이 충돌하는 상황도 합성 이전에 다룰 수 있다.
| 구성 요소 | 표기 | 시스템이 찾아야 하는 것 | 검증 질문 |
|---|---|---|---|
| 관계형 schema | $\mathcal{S}$ | table, attribute, primary key, foreign-key relation | 요청의 entity 유형과 관계를 빠짐없이 표현하는가 |
| Entity 집합 | $\mathcal{E}_m$ | 각 table에 들어갈 row와 식별 key | 동일 entity가 alias 때문에 중복되지 않았는가 |
| 값 행렬 | $\mathbf{Y}_m$ | entity별 attribute value | 요구된 cell이 정확하고 일관되게 채워졌는가 |
| Citation matrix | $\mathbf{C}_m$ | 각 값의 URL과 anchored supporting span | 인용된 span이 해당 값을 실제로 지지하는가 |
2.3 이 정식화가 검색 orchestration에 주는 이점
첫째, entity discovery와 attribute completion을 한 목표 안에 결합한다. 닫힌 table이라면 row 목록이 미리 주어질 수 있지만, 개방형 요청에서는 검색하면서 새로운 entity가 발견된다. 새 row가 생기면 채워야 할 cell도 늘어난다. SearchOS의 coverage는 현재까지 materialize된 row를 기준으로 계산되므로, open-set 전체를 완전히 열거했다고 과장하지 않으면서도 현재 작업의 진척은 측정할 수 있다.
둘째, 관계형 구조는 task decomposition의 기준이 된다. 특정 entity의 여러 속성을 한 worker에게 묶거나, 동일 attribute를 여러 entity에 걸쳐 수집하거나, 먼저 parent table의 key를 발견한 뒤 child table 조사를 여는 식으로 dependency를 만들 수 있다. Orchestrator가 임의의 자연어 subtask를 계속 생성하는 대신 schema relation과 빈 cell을 사용해 작업 범위를 좁힌다.
셋째, citation matrix는 합성 단계의 오류를 줄이는 장치다. Writer는 긴 raw browser history를 읽고 근거를 다시 찾는 대신, schema-bound value와 source span을 받아 보고서를 구성한다. 값이 채워져도 anchor가 없으면 grounded completion으로 인정하지 않는 구조이므로, “페이지를 방문했다”와 “주장을 지지하는 근거를 확보했다”를 구분한다.
다만 이 문제 정의가 open-domain search의 모든 불확실성을 없애는 것은 아니다. Open-set table에서는 새로운 entity가 발견될 때 denominator가 커질 수 있고, 서로 다른 source가 같은 cell에 다른 값을 제시할 수 있다. 따라서 schema completion 위에는 conflict 표시, provenance 우선순위, unreachable 상태, stop criterion이 추가로 필요하다. SearchOS의 SOCM과 middleware가 바로 이 실행상의 간극을 메운다.
3. 방법론: SOCM, pipeline orchestration, middleware, 계층형 skill
3.1 최신 검색 상태를 중심으로 도는 closed loop
SearchOS는 schema를 한 번 만든 뒤 agent를 일괄 실행하는 선형 pipeline을 넘어 stateful closed loop로 구현된다. Orchestrator가 최신 coverage에서 미해결 gap을 골라 task를 dispatch하고, worker의 관찰은 middleware를 거쳐 evidence와 coverage에 commit되며, 완료 보고와 실패 signal은 frontier와 failure memory를 갱신한다. 상태가 바뀌면 ready task와 우선순위를 다시 계산하고, 충분히 완성되면 optional writer가 citation-grounded report를 만든다.
Figure 1: SearchOS의 전체 구조. Agent의 판단, middleware의 실행 통제, SOCM의 공유 상태, 계층형 skill이 하나의 검색 loop를 이룬다.
Figure 1에서 중요한 경계는 worker가 raw conversation을 서로 넘기는 대신 SOCM을 통해 협업한다는 점이다. Orchestrator는 전역 gap과 task 상태를 보고, search agent는 자신에게 배정된 cell과 관련 evidence만 보며, writer는 합성에 필요한 compact state를 읽는다. 같은 전체 상태를 모든 role의 prompt에 복제하지 않고, 최신 state에서 role별 projection을 다시 생성한다. 이 분리는 병렬 worker 수가 늘어날수록 상태 충돌과 stale context를 줄이는 핵심 경계로 작동한다.
3.2 SOCM: 대화 밖에 존재하는 공유 검색 상태
시각 $t$의 SOCM은 $\mathcal{M}_t=(\mathcal{F}_t,\mathcal{G}_t,\mathcal{C}_t,\mathcal{W}_t)$로 정의된다. 각각 Frontier Task, Evidence Graph, Coverage Map, Failure Memory다. 이 상태는 agent conversation 밖에 지속되며, locked read-modify-write 방식으로 갱신된다. Role $r$과 assignment $z_t$를 받은 agent의 입력은 전체 $\mathcal{M}_t$ 대신 $x_t^{(r)}=\phi_r(\mathcal{M}_t;z_t)$다.
| SOCM 구성 | 저장 단위 | 주요 역할 | 방지하려는 실패 |
|---|---|---|---|
| Frontier Task | 상태, 우선순위, dependency, target cell, 담당 agent, attempt | 검색 gap을 실행 가능한 작업으로 변환 | 중복 dispatch, dependency 위반, 완료 cell 재검색 |
| Evidence Graph | value, URL, supporting span, schema binding, confidence, provenance | 원자적 발견과 support·conflict·refine 관계 보존 | page summary 수준 provenance, 충돌 덮어쓰기 |
| Coverage Map | cell status, supporting set, primary evidence, conflict flag | missing·filled·uncertain·unreachable을 materialize | 진행률 착시, 빈 table 조기 완료, 누락 |
| Failure Memory | failure type, task-scoped signature, correction, recurrence, time | 실패와 “다시 시도하지 말 것” 지침 공유 | 반복 질의, 차단 source 재접근, 막다른 branch 재탐색 |
Frontier Task의 task는 $f_j=(\kappa_j,s_j,p_j,B_j,Z_j,a_j,n_j)$로 표현된다. Type, status, priority, dependency, target cell, assigned agent, attempt count를 한 record에 둔다. 모든 dependency가 terminal 상태가 된 pending task만 ready set에 들어가며, dispatch 직전 target cell을 다시 검사해 이미 채워진 task는 닫는다. 동시에 활성화된 task끼리 target cell이 겹치면 deduplication guard가 중복 작업을 막는다.
Evidence Graph는 page 단위 요약 대신 atomic finding을 저장한다. Node $g_i=(v_i,u_i,x_i,\mathbf{b}_i,\gamma_i,\tau_i,s_i)$는 value, source URL, supporting span, schema binding $(m_i,e_i,a_i)$, confidence, provenance tier, status를 가진다. Node 사이는 Support, Conflict, Refine relation으로 연결된다. Binding·normalized value·source가 같은 node는 deduplicate하지만, 서로 다른 source의 corroboration은 남긴다. Rejected나 superseded evidence도 audit를 위해 보존하되 coverage에는 포함하지 않는다.
Coverage Map은 schema cell $c=(m,e,a)$마다 status와 supporting evidence set $H_c$를 둔다. 여러 finding이 한 cell을 지지하면 provenance tier $\tau$, schema alignment $\alpha$, authority-adjusted confidence $\gamma$를 lexicographic order로 비교해 primary evidence $g_c^*$를 고른다. 서로 다른 값이 경쟁할 때는 조용히 overwrite하지 않고 conflict flag를 세운다.
Coverage는 materialized cell 가운데 Filled의 비율로 계산하지만, 아직 entity를 하나도 발견하지 못한 declared table의 attribute 수도 denominator에 더한다. 이 장치가 없으면 비어 있는 table이 $0/0$ 또는 조사할 cell이 없다는 이유로 완료처럼 보일 수 있다. 반대로 open-set table에서는 새 row가 발견될 때 cell 집합이 확장되므로 이 값은 알려진 row에 대한 진행률이지 세계에 존재하는 모든 entity의 완전 열거율은 아니다.
Failure Memory는 무정보·반복 query, inaccessible source, failed skill, dropped branch, rejected claim을 기록한다. 같은 task-scoped signature가 다시 나타나면 recurrence count를 올리고, 반복될수록 “재시도하지 말라”는 guidance를 강화한다. 다른 agent는 자신의 assignment와 관련된 failure만 projection으로 받으므로, 전체 실패 log를 읽지 않고도 선행 worker가 소진한 경로를 피할 수 있다.
네 memory는 별도 파일처럼 독립적으로 느슨하게 갱신되지 않는다. Evidence observation은 Evidence Graph와 Coverage Map을 함께 바꾸고, agent report와 middleware sensor는 Frontier Task와 Failure Memory를 갱신한다. Locked interface를 통해 한 transition으로 commit하기 때문에 agent가 서로 다른 version의 evidence, coverage, task status를 동시에 보는 위험을 줄인다.
3.3 Pipeline-parallel multi-agent orchestration
SearchOS는 전역 계획과 국소 검색을 분리한 orchestrator-worker 구조를 사용한다. Orchestrator는 schema를 만들고 gap의 우선순위를 정하며 stop 여부를 판단한다. Explore agent는 후보 entity와 source를 찾고, search agent는 할당된 cell의 grounded evidence를 수집한다. Writer는 SOCM에 축적된 값을 인용 보고서로 합성한다. Role 간 직접 대화보다 공유 상태와 제한된 toolset이 coordination의 중심이다.
동기식 batch라면 같은 round의 모든 worker가 끝날 때까지 다음 작업을 보내지 못한다. SearchOS는 시각 $t$의 빈 slot 수를 $b_t$, Frontier의 ready set을 $\mathcal{R}_t$라 두고, 우선순위 $p$에 따라 $\min(b_t,|\mathcal{R}_t|)$개의 task를 dispatch한다. 하나가 완료될 때마다 SOCM을 갱신하고 ready set을 다시 계산한 뒤 방금 비어 난 slot에 새 task를 넣는다.
이 정책을 pipeline-parallel이라고 부르는 이유는 explore, search, synthesis에 가까운 서로 다른 역할의 작업이 dependency가 허용하는 범위에서 겹쳐 실행되기 때문이다. 모든 entity discovery가 끝날 때까지 search를 막는 대신, 먼저 발견된 row의 attribute search를 진행하면서 다른 explore agent가 다음 row를 찾을 수 있다. 중요한 것은 무조건적인 병렬화보다, 최신 coverage와 dependency가 허용하는 ready work를 계속 공급하는 데 있다.
| Role | 주요 책임 | 주요 tool 범위 | 받는 context |
|---|---|---|---|
| Orchestrator | schema·entity·task 관리, 우선순위, 종료 판단 | Schema/Entity CRUD, task queue, coordination | 전역 gap과 frontier 상태 |
| Explore | 후보 entity와 유망 source 발견 | Browser search/open/find | 탐색 범위와 discovery gap |
| Search | 할당된 cell의 anchored evidence 수집 | Browser와 strategy/access skill | target cell, 관련 evidence·failure |
| Writer | 완성 상태를 fine-grained citation report로 합성 | Outline, SOCM read, 필요한 skill | compact evidence·coverage summary |
Browser interface도 의도적으로 작다. search는 result page를 반환하고, open은 선택한 source를 렌더링·이동하며, find는 keyword-matched span을 찾는다. 각 navigation transition이 observation을 만들지만, observation을 evidence로 인정하고 SOCM에 쓰는 권한은 middleware에 있다. Agent가 페이지를 열었다는 사실만으로 coverage가 올라가지 않는다.
3.4 Search Tool Middleware Harness
장기 실행의 safeguard를 prompt에만 적어 두면 context가 커지거나 model·role이 바뀔 때 준수 여부가 흔들릴 수 있다. SearchOS는 model call과 tool call의 경계에 Search Tool Middleware Harness를 두고 Context, Evidence Extraction, Sensor의 세 구성 요소가 순서대로 개입하게 한다. 개념적으로 실행은 context 준비, tool observation의 evidence commit, 진행·budget signal에 따른 next action 결정으로 이어진다.
| Middleware | 개입 시점 | 핵심 동작 | 시스템이 얻는 보장 |
|---|---|---|---|
| Context | Model inference 전 | Role별 SOCM projection, 관련 skill, 최근 history를 조합하고 오래된 기록을 trim | 최신 target·gap·failure는 남기면서 prompt 팽창을 제어 |
| Evidence Extraction | Tool observation 후 | Entity·attribute·value·source·span 후보를 추출하고 bind/anchor 검사 후 commit | Evidence Graph와 Coverage Map의 atomic provenance update |
| Sensor | State transition 후 | Coverage·evidence 변화, iteration·search·time budget을 측정 | Stall 교정, backfill, drain-only, branch stop을 prompt 밖에서 적용 |
Context Middleware는 현재 role의 state view $v_t^{(r)}=\phi_r(\mathcal{M}_t)$를 만들고, query·schema·state에 맞는 top-k skill 집합 $\mathcal{K}_t$를 검색한다. 최종 model context는 최근 history, role view, rendered skill을 결합한 형태다. Token pressure가 커지면 오래된 상호작용은 줄일 수 있지만 active constraint, target cell, grounded evidence, gap, failure guidance는 유지한다. Conversation을 단순 요약하는 것과 달리 durable state를 다시 주입할 수 있다는 점이 중요하다.
Evidence Extraction Middleware는 observation $o_t$에서 schema-bound candidate를 추출한다. 후보에는 entity, attribute, value, source, supporting span이 포함된다. $\operatorname{Bind}(z,\mathcal{S})=1$이고 동시에 $\operatorname{Anchor}(z,o_t)=1$인 후보만 accepted evidence에 들어간다. 이후 Evidence Graph와 Coverage Map을 하나의 transition으로 갱신한다. 따라서 page 방문이나 agent의 자유형 summary를 제외하고, 원문 observation에 anchor된 schema value만 grounded progress로 계산된다.
Sensor Middleware는 연속 step 사이의 coverage 증가 $\Delta_t^{\mathrm{cov}}$와 evidence node 증가 $\Delta_t^{\mathrm{ev}}$를 본다. Window $w$ 동안 두 합이 모두 0이면 trajectory를 stalled로 판단한다. Budget pressure $\rho_t$는 iteration 사용률, search 사용률, wall-clock time 사용률의 최댓값으로 정의된다. Harness는 stall, budget, 현재 gap을 함께 보고 계속 실행할지, 교정 signal을 넣을지, backfill을 요청할지, 새 검색을 막고 drain할지, branch를 종료할지를 선택한다.
이 middleware 설계의 핵심은 agent의 자율성을 없애기보다 국소 검색 판단과 전역 실행 invariant를 분리하는 데 있다. Search agent는 어떤 query와 source를 시도할지 판단하지만, budget 차감, evidence anchoring, coverage 반영, 반복 정체 감지는 system layer가 담당한다. 서로 다른 post-trained model을 worker로 쓰더라도 최소한의 실행 규칙을 같은 방식으로 적용할 수 있다.
3.5 계층형 Search Skill
SearchOS는 검색 지식을 orchestrator, strategy, access의 세 층으로 나눈다. Orchestrator skill은 task decomposition, schema·row alignment, synthesis validation 같은 전역 playbook이다. 시작 시 공유 지침으로 주입되어 table 구조와 row set이 요청과 어긋나지 않게 한다.
Strategy skill은 특정 사이트에 묶이지 않은 검색 방법을 담는다. Query reformulation, entity enumeration과 disambiguation, structured extraction, multi-hop·temporal reasoning, aggregation, stall recovery가 여기에 해당한다. 동일한 접근을 여러 domain과 source에 재사용하기 위한 층이다.
Access skill은 database, 정부 portal, encyclopedia, 기업 site, media catalog처럼 source별 접근·추출 절차를 담는다. 일부는 instruction과 typed executor를 포함해 반복적인 navigation과 parsing을 한 번의 구조화된 tool call로 줄인다. Query-driven router가 전체 access catalog를 먼저 prune하고, 각 task에 필요한 strategy와 access skill만 선택한다.
이 분리는 “어떻게 찾을 것인가”와 “어디에 어떻게 접근할 것인가”를 구분한다. 특정 사이트가 막히면 access skill과 Failure Memory를 갱신할 수 있고, entity enumeration 같은 일반 전략은 그대로 재사용할 수 있다. 반대로 좋은 사이트별 extractor가 있어도 task decomposition이 잘못되면 coverage가 완성되지 않으므로 orchestrator skill이 별도 층으로 남는다.
3.6 방법론을 하나의 제어 loop로 읽기
SearchOS의 구성 요소를 따로 보면 schema는 데이터 모델, SOCM은 memory, pipeline scheduling은 병렬 실행, middleware는 safeguard, skill은 재사용 지식처럼 보인다. 그러나 논문의 실제 기여는 이들을 하나의 loop로 결합한 데 있다. Schema가 search gap의 좌표를 만들고, SOCM이 그 좌표의 현재 상태를 보존하며, orchestrator가 gap을 task로 바꾸고, middleware가 tool observation을 grounded evidence로 commit하며, sensor가 다음 dispatch 여부를 결정한다.
이 구조에서 자연어 conversation은 여전히 agent의 reasoning 인터페이스지만 더 이상 유일한 memory가 아니다. Evidence와 failure는 durable artifact로 남고, coverage는 숫자로 관찰되며, task는 dependency와 target cell을 가진다. 그래서 context를 trim하거나 worker를 교체해도 전역 검색 상태 전체를 잃지 않는다. SearchOS가 말하는 “OS”는 범용 운영체제를 구현했다는 뜻이라기보다, 장기 검색의 state와 scheduling, middleware control을 agent prompt 바깥의 system concern으로 끌어올렸다는 비유에 가깝다.
동시에 이 설계는 새로운 검증 지점도 만든다. Schema가 잘못 설계되면 coverage가 높아도 사용자의 실제 요구를 놓칠 수 있고, Evidence Extraction이 잘못 bind하면 근거 있는 오답이 구조화될 수 있으며, Failure Memory가 지나치게 강하면 유효한 재시도를 막을 수 있다. 따라서 SearchOS의 장점은 오류를 없애는 데만 있지 않다. 암묵적인 search drift를 schema, evidence node, coverage cell, failure record, sensor event처럼 감사 가능한 중간 artifact로 바꾸는 데 있다.
4. 실험 설정: 벤치마크와 재현 조건이 보여 주는 평가 범위
SearchOS의 실험은 장기·개방형 정보 탐색을 얼마나 넓고 완전하게 구조화할 수 있는지를 보기 위해 WideSearch와 GISA를 사용한다. 두 benchmark 모두 단순한 한 문장 사실 확인보다 여러 출처에서 정보를 모으는 과업을 다루지만, 질문 구성과 정답 형식은 다르다. 따라서 뒤에서 제시되는 점수는 하나의 homogeneous task에 대한 성능이라기보다, 넓은 atomic fact 수집과 여러 structured answer format을 함께 포괄하는 평가로 읽어야 한다.
4.1 WideSearch와 GISA가 측정하는 정보 탐색 범위
WideSearch는 대규모 “wide” information collection을 목표로 한다. 실제 사용자 query에서 가져와 사람이 선별한 질문은 모두 200개이며, 영어 100개와 중국어 100개로 정확히 나뉜다. Domain은 15개를 넘고, 각 질문은 객관적으로 검증 가능한 atomic fact를 대량으로 모아 완전한 table로 정리하도록 요구한다. 언어와 domain의 폭에 더해 누락 없이 많은 cell을 채우는 능력이 평가 대상에 들어간다.
GISA는 실제 검색 scenario를 반영해 사람이 작성한 373개 query로 general information-seeking assistant를 평가한다. 정답은 item, set, list, table의 네 structured format을 따르므로 deterministic scoring이 가능하다. 과업은 깊은 multi-hop reasoning과 폭넓은 cross-source aggregation을 결합한다. WideSearch가 많은 사실을 완성된 table로 수집하는 데 초점을 둔다면, GISA는 여러 형식에서 추론 깊이와 출처 집계를 함께 시험한다.
| Benchmark | 질문 구성 | 언어·범위 | 요구 출력 형식 | 과업 성격 |
|---|---|---|---|---|
| WideSearch | 수작업 선별 질문 200개 | 영어 100개, 중국어 100개, 15개 초과 domain | 검증 가능한 atomic fact의 완전한 table | 대규모 wide information collection |
| GISA | 사람이 작성한 query 373개 | 실제 검색 scenario 반영 | item, set, list, table의 4개 형식 | 깊은 multi-hop reasoning과 넓은 cross-source aggregation |
이 구성은 SearchOS의 relational schema completion과 잘 맞는 평가 범위를 만든다. WideSearch에서는 여러 atomic fact를 하나의 완전한 표로 조직해야 하므로 발견하지 못한 entity나 비어 있는 cell이 직접 손실이 된다. GISA에서는 동일한 정보 탐색 능력이 table에만 한정되지 않고 set과 list, 단일 item에도 적용되는지 확인한다. 다만 두 benchmark가 공통으로 structured answer와 deterministic comparison을 중심에 둔다는 사실은 점수의 해석 범위를 함께 규정한다.
4.2 구조화된 출력과 실행 상태를 연결해 보는 인터페이스
평가의 최종 대상은 gold answer와 비교되는 structured output이지만, SearchOS의 실행 단위는 그 결과를 채우는 과정에도 구조를 부여한다. Orchestrator는 unresolved schema gap을 dispatch하고, explore·search agent의 관찰은 SOCM과 middleware를 거쳐 grounded evidence로 반영된다. 이 때문에 benchmark의 table, set, list, item은 단순한 렌더링 형식에 그치지 않고, 어떤 entity와 attribute가 채워졌는지 추적하는 시스템 상태와 연결된다.
Figure 2: 장기 정보 탐색 작업을 위한 SearchOS 인터페이스.
Figure 2은 장기 정보 탐색을 단일 답변 생성을 넘어 orchestrator가 unresolved schema gap을 dispatch하고, 병렬 sub-agent가 scoped search를 수행하며, 그 관찰을 SOCM의 evidence와 coverage로 commit하는 실행으로 보게 한다. 실험에서 화면은 별도의 성능 지표가 아니며 structured fact collection이 만들어지는 과정을 설명하는 보조 자료다. Benchmark의 table·set·list·item 형식과 SearchOS가 유지하는 cell 상태의 대응을 이해하게 하지만, interface 자체가 정량 결과를 뜻하지는 않는다.
방법론의 browser interface는 search, open, find라는 세 operation으로 shared navigation stack을 구성한다. 각 전환은 observation을 만들지만, 페이지를 열었다는 사실만으로 정답 cell이 채워지는 것은 아니다. Middleware가 evidence extraction과 provenance를 결정하고, schema binding과 supporting span anchoring을 모두 통과한 값만 상태에 commit한다. 따라서 실험의 structured score는 browsing activity의 양보다 근거가 연결된 최종 answer를 대상으로 한다.
4.3 평가 지표와 비교 baseline
평가는 완성된 table을 gold standard와 대조하되 두 granularity를 구분한다. Item-level Precision, Recall, F1은 answer cell을 각각 독립적인 단위로 취급한다. 반면 Row-level Precision, Recall, F1은 한 행의 모든 cell이 맞을 때만 그 row를 정답으로 인정한다. 하나의 잘못된 값이나 누락만 있어도 전체 행이 credit을 잃으므로, Row-level score는 개별 사실 회수와 함께 entity record 전체의 일관된 완성을 더 엄격하게 본다.
Exact Match(EM)는 전체 table이 gold answer와 정확히 일치한 case의 비율이다. 논문은 GISA에서 question type별로 Table, Set, List, Item을 나누어 보고한다. 메인 결과 표에서는 Table에 Item F1과 Row F1을 함께 두고, Set과 List에는 F1, Item에는 EM을 제시한다. 따라서 서로 다른 형식의 숫자를 비교할 때는 같은 이름의 score인지 먼저 확인해야 하며, Row F1이나 EM을 Item F1과 동일한 완화 기준으로 읽어서는 안 된다.
| 평가 항목 | 보고 지표·수 | 정답 인정 단위 | 적용 범위 |
|---|---|---|---|
| Item-level | Precision, Recall, F1의 3개 지표 | 각 answer cell을 독립 평가 | 조립된 table과 gold standard 비교 |
| Row-level | Precision, Recall, F1의 3개 지표 | 모든 cell이 맞은 row만 인정 | 완전한 행의 정확성과 coverage |
| Exact Match | EM 1개 지표 | 전체 table의 정확한 일치 | 전체 case 단위 |
| GISA 형식별 보고 | Table, Set, List, Item의 4개 유형 | 형식에 맞춘 F1 또는 EM | Table은 Item·Row F1, Set·List는 F1, Item은 EM |
비교군은 single-agent와 multi-agent의 두 범주로 나뉜다. Single-agent baseline은 ReAct와 Plan-and-Solve 두 개이며, multi-agent system은 A-MapReduce, Web2BigTable, Table-as-Search 세 개다. 즉 SearchOS는 총 5개 baseline과 비교된다. 논문은 이 분류를 통해 단일 agent의 reasoning·planning 방식에 더해 table 중심 또는 분산형 정보 수집 system과도 같은 benchmark 결과를 대조한다.
| 비교 범주 | 방법 수 | Baseline |
|---|---|---|
| Single-agent | 2 | ReAct, Plan-and-Solve |
| Multi-agent system | 3 | A-MapReduce, Web2BigTable, Table-as-Search |
| 전체 baseline | 5 | Single-agent 2개와 multi-agent 3개 |
이 metric 구성은 precision만으로는 보이지 않는 누락을 Recall과 F1로 드러내고, cell 수준의 부분 성공과 row 전체의 완성을 분리한다. 이는 Coverage Map이 missing cell을 추적하고 coverage-aware dispatch가 unresolved gap을 다시 작업으로 만드는 SearchOS의 설계 목표와 대응한다. 동시에 baseline의 수와 범주는 비교 폭을 알려 주지만, 각 범주 이름만으로 계산 budget이나 backbone이 동일하다고 추가 가정해서는 안 된다. 이 절에서 명시적으로 고정된 재현 조건은 다음 실험 설정 표의 SearchOS 구성이다.
4.4 모델 분업, Max@3, 실행 budget
SearchOS는 모든 역할과 처리 단계를 하나의 model에 맡기지 않는다. Agent role의 backbone은 GLM-5이고, tool observation에서 schema-bound candidate를 뽑는 Evidence Extraction에는 Qwen3.5-35B-A3B를 사용한다. 각 case는 세 번 실행하며 그중 가장 좋은 run을 보고하는 Max@3 protocol을 적용한다. 보고값은 $\times 100$으로 scale된다.
별도 언급이 없는 한 session마다 orchestrator iteration은 최대 50회, parallel sub-agent는 최대 8개다. 검색 상한은 sub-agent마다 20회이며, wall-clock budget은 1800초다. 이 숫자들은 단순한 구현 세부에 그치지 않고 결과가 생성된 search depth, concurrency, tool-use, 시간의 경계를 이룬다. 특히 8개 agent는 session 전체 검색 횟수를 뜻하지 않고 병렬 sub-agent 상한이고, 20회는 각 sub-agent에 적용되는 search 한도다.
| 설정 항목 | 정확한 값 | 적용 대상·의미 |
|---|---|---|
| Agent role backbone | GLM-5 | Agent 역할의 추론과 실행 |
| Evidence Extraction model | Qwen3.5-35B-A3B | Observation에서 evidence candidate 추출 |
| 반복 보고 protocol | Case마다 3회, Max@3 | 세 run 중 최고 결과 보고, score는 $\times 100$ |
| Orchestrator iterations | 50회 | Session별 상한 |
| Parallel sub-agents | 8개 | 동시에 운용하는 하위 agent 상한 |
| Searches | Sub-agent당 20회 | 각 하위 agent의 검색 상한 |
| Wall-clock budget | 1800초 | Session의 경과 시간 상한 |
Max@3는 세 번 실행한 결과의 평균 대신 가장 좋은 한 실행을 case별 대표값으로 택한다. 따라서 표의 수치는 이 protocol 아래에서 얻은 최고 run 기준으로 해석해야 한다. 또한 “별도 언급이 없는 한”이라는 조건이 붙으므로, 후속 ablation이 다른 설정을 명시하면 해당 실험의 수치를 우선해야 한다. 재현 시에는 model 이름만 맞추는 것으로 충분하지 않고, 50회 iteration, 8-way parallelism, agent별 검색 20회, 1800초 제한과 report aggregation을 함께 맞춰야 논문의 기본 setting과 대응한다.
Figure 3: Search agent loop에서 이루어지는 middleware intervention.
Figure 3은 search agent loop의 model·tool 경계에서 Context, Evidence Extraction, Sensor Middleware가 차례로 개입하는 구조를 요약한다. 실험에서 Evidence Extraction에 Qwen3.5-35B-A3B를 따로 배치한 설정은 observation을 grounded evidence로 바꾸는 경로와 연결된다. Agent role을 맡은 GLM-5의 검색 판단과 schema binding·span anchoring, budget·stall 감시를 수행하는 system 경로가 분리되므로, 결과는 backbone과 함께 이 middleware 실행 조건을 포함한 구성의 성능으로 읽어야 한다.
Method의 실행 순서로 쓰면 model inference 전 Context Middleware가 role-specific state를 준비하고, tool 실행 뒤 Evidence Extraction Middleware가 observation $o_t$를 schema와 Coverage Map에 맞춰 검사한다. Accepted evidence는 Evidence Graph와 Coverage Map에 함께 반영되고, 그 다음 Sensor Middleware가 coverage·evidence 변화와 iteration, search, time counter를 평가한다. 그러므로 50·20·1800이라는 budget은 prompt에 적힌 권고가 아닌 middleware가 실행 중 감시하는 resource boundary다.
종합하면 이 절의 평가 범위는 분명하다. Dataset 측면에서는 200개의 WideSearch 질문과 373개의 GISA query, 출력 측면에서는 완전한 table과 item·set·list·table 형식, metric 측면에서는 cell·row·whole-table granularity를 포괄한다. 실행 측면에서는 두 model의 역할 분담과 Max@3, 명시된 iteration·agent·search·time cap 아래의 SearchOS를 측정한다. 뒤의 성능 수치는 이 benchmark, scoring rule, baseline 구성, resource condition을 함께 고정한 결과로 읽는 것이 정확하다.
5. 주요 실험 결과: 정밀도를 지키면서 완전성을 끌어올린 검색
SearchOS의 실험은 단순히 정답 셀을 얼마나 많이 맞혔는가와 함께, 여러 속성이 한 행 안에서 함께 맞는지와 답 전체가 정확히 일치하는지를 구분해 본다. 핵심 질문은 Coverage Map과 completeness-aware dispatch가 누락을 줄이면서도 precision을 떨어뜨리지 않는지, 그리고 continuous scheduling·middleware·hierarchical skill이 긴 검색을 더 효율적으로 유지하는지다. 결과를 읽을 때는 각 지표의 판정 단위와 Max@3 보고 방식을 함께 봐야 한다.
5.1 평가 대상, 지표, 실행 설정
WideSearch는 대규모의 “넓은” 정보 수집을 겨냥한다. 실제 사용자 질의에서 가져온 수작업 질문 200개로 구성되며 영어 100개와 중국어 100개가 포함된다. 분야는 15개를 넘고, 각 문제는 객관적으로 검증 가능한 많은 원자적 사실을 모아 완전한 표로 정리하도록 요구한다. GISA는 실제 검색 상황을 반영해 사람이 만든 373개 질의로 일반 정보 탐색 assistant를 평가한다. 답 형식은 item, set, list, table의 네 가지이며, 결정론적으로 채점할 수 있도록 구조화되어 있다. 이 과제들은 깊은 multi-hop reasoning과 여러 출처를 가로지르는 폭넓은 aggregation을 함께 요구한다.
비교군은 single-agent와 multi-agent 두 범주다. Single-agent 방법에는 ReAct와 Plan-and-Solve가, multi-agent system에는 Table-as-Search, A-MapReduce, Web2BigTable이 들어간다. 따라서 메인 표는 SearchOS가 단일 trajectory 중심의 방법에 더해 표 수집이나 작업 분산을 이미 사용하는 시스템과 비교될 때도 이점을 유지하는지를 보여 준다.
평가는 gold table과 생성된 table을 두 granularity에서 비교한다. Item-level Precision·Recall·F1은 answer cell을 각각 독립적으로 채점한다. 반면 Row-level Precision·Recall·F1은 한 행의 모든 cell이 정확할 때만 그 행을 맞은 것으로 인정하므로 더 엄격하다. Exact Match(EM)는 전체 table이 gold answer와 완전히 같은 case의 비율이다. GISA는 여기에 Table·Set·List·Item 질문 유형별 결과를 나누어 보고한다.
Agent role의 backbone은 GLM-5이고 Evidence Extraction에는 Qwen3.5-35B-A3B를 사용했다. 각 case를 세 번 실행해 그중 가장 좋은 결과를 보고하는 Max@3이며, 점수는 $\times100$으로 표시한다. 별도 언급이 없으면 한 session은 orchestrator iteration 50회, 병렬 sub-agent 8개, sub-agent당 search 20회, wall-clock 1,800초로 제한된다. 이 조건은 뒤의 성능 수치가 세 번 실행의 평균 대신 최고값이라는 점을 분명히 한다.
5.2 WideSearch와 GISA: recall 중심의 개선이 full-row 일관성으로 이어지는가
WideSearch에서는 여섯 개 지표 모두 SearchOS가 가장 높다. Item precision은 83.9로 차선인 Plan-and-Solve의 83.8보다 0.1점 높지만, item recall은 79.7로 차선인 A-MapReduce의 74.2보다 5.5점 높다. 그 결과 item F1은 80.3으로 가장 강한 baseline F1 76.0보다 4.3점 향상된다. 즉 가장 큰 차이는 precision을 희생해 더 많이 출력한 데서보다, 최고 precision을 유지한 채 빠뜨린 cell을 줄인 데서 나타난다.
| WideSearch 지표 | ReAct | Plan-and-Solve | Table-as-Search | A-MapReduce | Web2BigTable | SearchOS | $\Delta$ |
|---|---|---|---|---|---|---|---|
| Item Precision | 82.9 | 83.8 | 82.4 | 83.1 | 78.3 | 83.9 | +0.1 |
| Item Recall | 70.2 | 72.9 | 73.5 | 74.2 | 73.4 | 79.7 | +5.5 |
| Item F1 | 72.9 | 75.2 | 75.4 | 76.0 | 73.8 | 80.3 | +4.3 |
| Row Precision | 58.0 | 58.7 | 57.1 | 56.9 | 57.5 | 59.0 | +0.3 |
| Row Recall | 48.8 | 50.2 | 51.6 | 49.8 | 54.0 | 55.8 | +1.8 |
| Row F1 | 50.9 | 52.2 | 52.7 | 51.4 | 54.5 | 56.5 | +2.0 |
한 cell만 틀려도 행 전체가 오답이 되는 row-level 평가에서도 같은 방향이 유지된다. SearchOS의 Row Precision·Recall·F1은 각각 59.0·55.8·56.5다. Row F1은 다음으로 높은 Web2BigTable의 54.5보다 2.0점 높으며, Row Precision도 차선 58.7보다 0.3점 높다. 따라서 item recall의 이득은 고립된 cell을 더 많이 찾는 데 머물지 않고, 한 entity의 여러 필드를 함께 맞히는 더 엄격한 수준으로 이어진다.
GISA에서도 SearchOS는 모든 질문 유형에서 선두다. 가장 큰 차이는 정답 집합을 빠짐없이 열거해야 하는 Set F1에서 나타난다. SearchOS의 76.5는 가장 강한 baseline인 Plan-and-Solve의 63.1보다 13.4점 높다. Table에서는 Item F1 76.9와 Row F1 59.7을 기록하고, List F1은 68.1이다. Item EM은 50.0으로 Web2BigTable의 50.0과 공동 최고다.
| GISA 유형·지표 | ReAct | Plan-and-Solve | Table-as-Search | A-MapReduce | Web2BigTable | SearchOS | $\Delta$ |
|---|---|---|---|---|---|---|---|
| Table Item F1 | 74.8 | 71.2 | 73.4 | 72.5 | 68.1 | 76.9 | +2.1 |
| Table Row F1 | 58.1 | 50.7 | 54.1 | 52.1 | 45.3 | 59.7 | +1.6 |
| Set F1 | 61.6 | 63.1 | 60.9 | 62.5 | 56.7 | 76.5 | +13.4 |
| List F1 | 67.1 | 53.8 | 54.2 | 57.4 | 65.5 | 68.1 | +1.0 |
| Item EM | 0.0 | 16.7 | 16.7 | 33.3 | 50.0 | 50.0 | 0.0 |
두 benchmark를 함께 보면 SearchOS는 보고된 여섯 headline F1에서 모두 가장 높은 값을 기록한다. 특히 WideSearch의 item recall과 GISA의 Set F1처럼 coverage와 completeness에 민감한 항목에서 개선 폭이 크고, WideSearch item precision도 동시에 최고다. 논문은 이 패턴을 open-domain information seeking을 relational schema completion으로 구성하고 Evidence Graph와 shared SOCM state를 통해 미해결 부분을 계속 확인하는 설계와 연결한다.
5.3 Continuous scheduling: batch barrier를 없앤 효율과 품질
Scheduling ablation은 같은 query, model configuration, concurrency limit $K=8$을 유지하고 scheduling policy만 바꿨다. WideSearch 10개 case에서 세 차례 paired round를 수행했으며, batch는 한 group의 모든 task가 끝날 때까지 기다리고 continuous policy는 task 하나가 끝나 slot이 풀리는 즉시 다음 task를 넣는다. 세 round 모두 continuous scheduling이 end-to-end time과 token 사용을 줄이면서 Item F1을 높였다.
| Scheduling policy | Time (s) $\downarrow$ | Slot utilization $\uparrow$ | Tasks/min $\uparrow$ | LLM calls $\downarrow$ | Item F1 $\uparrow$ |
|---|---|---|---|---|---|
| Batch (Control) | 629.13 | 34.6% | 2.99 | 341.4 | 79.66 |
| Continuous (SearchOS) | 476.34 | 41.7% | 3.37 | 296.6 | 86.75 |
정책별 30개 trajectory 평균에서 continuous scheduling은 시간을 629.13초에서 476.34초로 줄여 평균 end-to-end time을 24.3% 단축했다. Slot utilization은 34.6%에서 41.7%로, 처리량은 분당 2.99 task에서 3.37 task로 올라갔다. 동시에 LLM call은 341.4회에서 296.6회로 줄었고 Item F1은 79.66에서 86.75로 높아졌다. Batch 경계에서 생기는 idle capacity를 줄이는 것이 retrieval quality의 희생으로 이어지지 않았다는 결과다.
5.4 Middleware 개입과 hierarchical skill의 실행 효과
Aggregate score만으로는 long-horizon search가 정체했을 때 middleware가 실제로 무엇을 하는지 알기 어렵다. 논문은 Search Tool Middleware Harness의 governance가 낮은 진전을 감지한 뒤 검색을 다시 생산적으로 만드는지 확인하기 위해 WideSearch의 대표 trajectory 세 개를 제시한다.
Figure 4: WideSearch의 middleware-governance trajectory. 점선은 Loop Sensor가 정체를 감지하고 전략 전환을 일으킨 시점이다.
이 그림은 WideSearch의 대표적인 세 trajectory를 조기·중기·후기 개입 사례로 나누어 보여 준다. 각 열의 위쪽 곡선은 table coverage, 아래쪽 곡선은 누적 발견 entity 수이며, 세로 점선은 Loop Sensor가 진전이 낮은 검색 loop를 감지해 전략 전환을 촉발한 시점이다. 개입 시점은 서로 달랐지만 세 사례 모두 앞선 정체 구간을 넘어 검색 진행을 회복했다. 다만 coverage와 entity discovery에 미친 정도는 사례마다 달랐으므로, 이는 정체한 검색을 생산적인 작업으로 돌리는 mechanism-level evidence다.
세 사례의 개입 시점은 서로 다르지만 조기·중기·후기 intervention 모두 직전의 stagnation period 이후 진행을 복구한다. 개입이 coverage와 새 entity 발견에 미치는 정도는 case마다 다르다. 따라서 이 분석은 전체 benchmark의 평균 효과를 다시 계산한 표라기보다, Loop Sensor가 멈춘 검색을 감지하고 strategy switch를 통해 productive work로 redirect할 수 있음을 trajectory 수준에서 보여 준다.
Hierarchical skill ablation은 skill을 켠 설정과 모든 skill layer를 끈 설정을 비교하며, 각 설정에서 세 번 실행한 Max@3를 보고한다. Skills를 사용하면 Item F1은 78.3에서 80.3으로 2.0점, Row F1은 53.1에서 56.5로 3.4점 오른다. Row-level 상승 폭이 더 크다는 것은 reusable decomposition, search, source-access knowledge가 개별 cell과 함께 coherent entity record를 조립하는 데 기여한다는 논문의 해석과 맞닿아 있다.
| 설정 | Item-level | Row-level | ||||
|---|---|---|---|---|---|---|
| Precision | Recall | F1 | Precision | Recall | F1 | |
| Without Skills | 82.2 | 78.5 | 78.3 | 56.0 | 52.4 | 53.1 |
| With Skills | 83.9 | 79.7 | 80.3 | 59.0 | 55.8 | 56.5 |
| $\Delta$ | +1.7 | +1.2 | +2.0 | +3.0 | +3.4 | +3.4 |
Figure 5: 같은 WideSearch 100개 질문에서 skills 사용 여부에 따른 효율. Error bar는 95% confidence interval이다.
이 그림은 동일한 WideSearch 100개 질문에서 계층형 skill을 켠 경우와 끈 경우의 효율을 비교하며, error bar는 95% confidence interval을 나타낸다. Skill을 사용하면 session time은 36.6%, search call은 39.1%, page call은 42.7% 감소했다. 따라서 품질 개선은 browsing을 더 늘린 결과가 아닌 exploratory trial and error를 줄인 결과로 나타났다. 다만 실험에서는 모든 skill layer를 함께 껐으므로, 수치는 개별 layer가 아닌 계층형 skill 전체의 joint contribution을 측정한다.
품질과 효율을 함께 보면 skill을 쓴 SearchOS는 더 높은 Item·Row F1을 얻으면서도 session time과 두 종류의 browsing call을 모두 줄였다. 논문은 이를 더 많은 탐색을 추가한 효과로 보기보다 재사용 가능한 decomposition, 일반 search strategy, source-access knowledge가 시행착오를 줄인 결과로 설명한다. 단, layer별 제거 실험이 아닌 전 계층을 한꺼번에 비활성화한 비교이므로 이 수치가 나타내는 것은 skill system의 결합 효과다.
6. 추가 분석 및 Ablation Study: 성능 향상을 구성 요소별로 해부하기
메인 benchmark의 최종 점수만으로는 SearchOS의 어느 설계가 정확도와 실행 효율에 기여했는지 구분하기 어렵다. 논문은 이 간극을 좁히기 위해 검색 중 schema 계획, pipeline-parallel scheduling, middleware가 통제하는 실행 trajectory, 계층형 skill을 차례로 분석한다. 네 실험은 모두 같은 종류의 증거를 제공하지 않는다. Schema와 scheduling, skill 분석에는 비교 수치가 있지만, middleware 분석은 대표 trajectory에서 정체와 개입 전후의 진행을 관찰한 정성적 사례 연구다.
이 절에서는 결과를 단순히 “각 부품을 켜면 좋아진다”로 요약하지 않고 평가 단위와 비교 조건을 함께 읽는다. Item-level F1은 각 answer cell을 독립적으로 채점하고, Row-level F1은 한 행의 모든 cell이 맞아야 그 행을 맞은 것으로 인정한다. 따라서 Row F1의 변화는 고립된 값을 더 많이 찾았는지보다 완결된 entity record를 얼마나 일관되게 조립했는지에 더 엄격한 신호를 준다. 시간·호출 수 감소도 품질 변화와 분리하지 않고 함께 확인해야 한다.
6.1 고정 Schema와 검색 시점 Schema 계획
첫 분석은 모든 요청에 미리 정한 table 구조가 적합한지를 묻는다. 저자들은 여러 table로 분해할 수 있는 40개 질문을 고르고, 각 질문에 대해 GPT-5.5로 의미적으로 대응하는 fixed single-table schema와 fixed multi-table schema를 만들었다. 두 고정 조건에는 같은 필수 attribute가 들어가므로, 비교의 초점은 요구 정보의 차이보다 그 정보를 한 table에 모을지 관계에 따라 나눌지에 있다. 이 둘을 SearchOS의 explore agent가 검색 과정에서 수행하는 autonomous schema planning과 비교했다.
| 설정 | Item-level | Row-level | ||||
|---|---|---|---|---|---|---|
| Precision | Recall | F1 | Precision | Recall | F1 | |
| Fixed Single-Table | 54.7 | 46.7 | 47.9 | 33.5 | 28.2 | 29.2 |
| Fixed Multi-Table | 66.9 | 55.7 | 58.3 | 37.4 | 32.6 | 34.2 |
| Oracle Single/Multi | 70.3 | 60.7 | 62.4 | 44.8 | 39.7 | 41.2 |
| SearchOS | 76.3 | 68.3 | 70.6 | 52.7 | 47.3 | 48.9 |
고정 조건끼리 보면 multi-table의 평균 Item F1 58.3은 single-table의 47.9보다 높다. 그러나 case별 승패는 multi-table 21승, 17패, 2무다. 평균 우위만으로 모든 문제를 multi-table로 고정할 수 없는 이유다. Oracle은 각 case의 결과를 본 뒤 Item F1이 더 높은 고정 schema를 고르는 상한 비교인데도 Item F1 62.4, Row F1 41.2에 그친다. SearchOS는 각각 70.6과 48.9로 oracle보다 8.2점, 7.7점 높다.
논문은 속성이 한 entity에 집중되고 relation이 단순한 task는 single table에 잘 맞을 수 있고, 일대다 relation, 여러 entity type, 공유 attribute, cross-entity organization이 있는 task는 multiple table의 이점을 얻기 쉽다고 설명한다. 실제 40개 case에서 SearchOS는 35개에 single-table, 5개에 multi-table을 선택했다. 중요한 결론은 multi-table을 더 자주 선택했다는 사실보다, 검색하면서 드러나는 entity type, field 분포, 반복 pattern, relation에 맞춰 single, multi 또는 hybrid 구조를 선택하고 새 evidence가 정보 topology를 바꾸면 schema를 수정할 수 있었다는 점이다.
6.2 Batch Barrier를 제거한 Continuous Scheduling
Scheduling ablation은 synchronized batch와 continuous dispatch만 바꾸고 다른 조건을 맞춘다. 10개 WideSearch case에 같은 query, model configuration, concurrency limit $K=8$을 적용해 세 번의 paired round를 수행했다. Batch는 한 group의 모든 task가 끝날 때까지 다음 group을 기다리지만, continuous policy는 task 하나가 끝나 slot이 풀릴 때마다 SOCM을 갱신하고 ready task로 즉시 채운다. 아래 값은 각 round에서 10개 case의 median이며, 시간과 token의 음수 변화는 continuous scheduling이 batch보다 적게 사용했다는 뜻이다.
| Paired Round | Time $\Delta$ | Tokens $\Delta$ | Item F1 $\Delta$ |
|---|---|---|---|
| 1 | $-32.6\%$ | $-27.7\%$ | $+2.35$ point |
| 2 | $-32.3\%$ | $-31.2\%$ | $+15.00$ point |
| 3 | $-28.6\%$ | $-10.8\%$ | $+1.85$ point |
세 round 모두에서 time과 token은 줄고 Item F1은 높아졌다. 전체 30개 trajectory를 policy별로 평균 내면 batch는 629.13초, slot utilization 34.6%, 분당 task 2.99개, LLM call 341.4회, Item F1 79.66이었다. Continuous는 476.34초, 41.7%, 3.37개, 296.6회, 86.75를 기록했다. 평균 end-to-end time 감소율은 24.3%다. 이 비교가 보여 주는 것은 단순히 agent 수를 늘린 결과가 아니다. 동시성 상한은 같고, batch의 straggler를 기다리며 생기는 idle capacity를 완료 event마다 재할당한 scheduling policy의 차이다.
품질이 낮아지는 대신 빨라진 trade-off도 이 표에서는 나타나지 않는다. 세 paired round 모두 Item F1 변화가 양수이고, 30 trajectory 평균에서도 continuous policy의 Item F1이 더 높다. 논문은 이를 batch barrier를 제거해 pipeline utilization과 task throughput을 높이면서 LLM call을 줄인 결과로 해석한다. 다만 round별 F1 증가는 $+1.85$에서 $+15.00$ point까지 다르므로, 대표적인 한 round를 넘어 세 반복에서 방향이 일관되었다는 사실이 더 직접적인 근거다.
6.3 Middleware Intervention: 정량 Ablation이 아닌 Trajectory 증거
Search Tool Middleware Harness의 분석은 앞의 두 비교와 증거 성격이 다르다. 논문은 WideSearch의 대표 trajectory 세 개를 골라 Loop Sensor가 이른 시점, 중간, 늦은 시점에 개입한 실행을 보여 준다. 각 case의 상단에는 table coverage, 하단에는 누적 발견 entity 수가 놓이고, 점선은 sensor가 low-progress loop를 감지해 strategy switch를 촉발한 시점을 표시한다. 세 case 모두 개입 전 정체 구간을 지난 뒤 coverage나 entity discovery가 다시 진행되지만, 두 지표가 회복되는 정도는 case마다 다르다.
이 동작은 method에서 정의한 sensor signal과 연결된다. 연속 상태 사이의 grounded coverage 증가를 $\Delta_t^{\mathrm{cov}}$, Evidence Graph node 증가를 $\Delta_t^{\mathrm{ev}}$라 두고, window $w$에서 두 증가량의 합이 모두 0이면 $s_t=1$인 stall로 판단한다. Harness는 이 신호와 iteration, search, time 사용률의 최댓값인 budget pressure $\rho_t$를 현재 gap과 함께 읽어 continue, correction 주입, backfill 요청, drain-only 전환, branch stop 가운데 다음 동작을 고른다.
그러나 source가 제시하는 middleware intervention 결과는 정량적인 controlled ablation이 아닌 정성적인 representative trajectory 분석이다. 세 사례는 점선 이후 검색이 다시 생산적인 방향으로 움직였다는 mechanism-level evidence를 제공하지만, middleware를 끈 대조군의 전체 평균이나 개입 하나당 F1·시간 효과를 보고하지 않는다. 따라서 이 결과로 Loop Sensor의 집계 effect size를 추정하거나 모든 stall에서 같은 개선 폭이 난다고 확대해서는 안 된다. 논문이 직접 뒷받침하는 결론은 조기·중기·후기 정체를 감지한 뒤 strategy switch가 정체 이전을 넘어선 추가 진행과 연결된 세 실행 사례가 관찰되었다는 범위다.
부록의 complete trajectory도 이 통제 방식의 작동 예를 보탠다. Spotify case에서는 두 agent에 걸쳐 bare_search_without_progress reminder가 네 번 기록되었고, 최종적으로 알려진 20개 row의 gap이 0이 되었다. Publisher page가 막힌 journal case에서는 Wiley와 JSTOR의 access check 또는 HTTP 402 이후 Crossref, OpenAlex, academic-paper skill로 전환하고, 남은 source와 agent budget이 소진되자 unsupported metadata를 만들지 않은 채 unresolved cell을 보존했다. 이 역시 개별 process evidence이며, 정량 ablation을 대체하는 수치로 읽어서는 안 된다.
6.4 계층형 Skill의 품질 및 효율 기여
Skill ablation은 hierarchical skill 전체를 켠 조건과 끈 조건을 비교하며, 각 설정을 세 번 실행한 Max@3를 보고한다. 품질 표에서 skill을 사용하지 않으면 Item F1은 78.3, Row F1은 53.1이고, 사용하면 각각 80.3과 56.5다. Item F1의 $+2.0$ point보다 Row F1의 $+3.4$ point 증가가 더 크다. 논문은 reusable decomposition, search, source-access knowledge가 고립된 cell을 찾는 데 그치지 않고 완결된 entity record를 조립하는 데 도움을 준 결과로 해석한다.
| 설정 | Item-level | Row-level | ||||
|---|---|---|---|---|---|---|
| Precision | Recall | F1 | Precision | Recall | F1 | |
| Without Skills | 82.2 | 78.5 | 78.3 | 56.0 | 52.4 | 53.1 |
| With Skills | 83.9 | 79.7 | 80.3 | 59.0 | 55.8 | 56.5 |
| $\Delta$ | $+1.7$ | $+1.2$ | $+2.0$ | $+3.0$ | $+3.4$ | $+3.4$ |
같은 100개 WideSearch 질문에서 측정한 효율은 품질 향상이 더 많은 browsing을 투입한 결과가 아님을 보여 준다. Skill을 켜면 평균 session time은 21.75분에서 13.78분으로, search call은 154.1회에서 93.8회로, page call은 240.6회에서 137.8회로 감소한다. 원 논문의 효율 그래프는 각 평균에 95% confidence interval error bar를 함께 표시한다.
| 효율 지표 | Without Skills | With Skills | 감소율 |
|---|---|---|---|
| Session time | 21.75분 | 13.78분 | $-36.6\%$ |
| Search calls | 154.1 | 93.8 | $-39.1\%$ |
| Page calls | 240.6 | 137.8 | $-42.7\%$ |
세 지표가 모두 줄면서 Item·Row F1은 함께 높아졌으므로, 논문은 skill이 추가 browsing으로 정답을 얻기보다 exploratory trial-and-error를 줄였다고 설명한다. 다만 이 ablation에서는 orchestrator, strategy, access skill layer를 한꺼번에 비활성화했다. 따라서 $+2.0$ Item F1, $+3.4$ Row F1이나 세 비용 감소율은 계층형 skill의 joint contribution이며, 특정 layer 하나의 독립 효과로 배분할 수 없다.
6.5 280개 Skill Library가 보여 주는 재사용 지식의 범위
SearchOS-V1의 280개 pre-built skill은 세 층으로 조직된다. Orchestrator skill은 task decomposition, schema·row alignment, synthesis validation을 위한 global playbook이고, strategy skill은 source와 무관한 query reformulation, entity enumeration·disambiguation, structured extraction, multi-hop·temporal reasoning, aggregation, stall recovery를 담는다. Access skill은 특정 database, government portal, encyclopedia, company site, media catalog의 retrieval·extraction 절차를 담당하며, 일부는 instruction과 typed executor를 결합한다.
Figure 6: 사전 구축 skill library의 weighted keyword frequency.
Figure 6는 280개 사전 구축 skill에서 자주 나타난 keyword를 가중 빈도로 요약한다. 이 시각화는 개별 benchmark 점수나 keyword의 인과 효과를 측정한 그래프가 아니다. Query reformulation, entity enumeration과 disambiguation, structured extraction, multi-hop·temporal reasoning, aggregation, stall recovery처럼 논문이 strategy skill의 기능으로 명시한 반복 검색 행위를 library가 재사용 가능한 지식 단위로 외부화한다는 구성을 읽기 위한 그림이다.
실행 시 모든 skill을 모든 agent에게 한꺼번에 주입하지 않는다. 시작 단계에는 orchestrator skill을 shared playbook으로 넣고, task마다 strategy와 access skill을 검색한다. Strategy는 model이 따를 guidance로 렌더링하고, executable access skill은 typed tool로 노출한다. Query-driven router는 selection 전에 access catalog를 먼저 prune하므로, library 규모와 개별 agent context의 action space를 분리한다.
Figure 7: Domain별 access skill 수와 평균 function 수.
Figure 7는 access skill을 domain별 개수와 평균 function 수로 나누어 보여 준다. 논문이 열거한 범위는 database, government portal, encyclopedia, company site, media catalog이며, 일부 skill은 instruction과 typed executor를 함께 제공한다. 따라서 이 그림은 어느 domain이 더 우수하다는 성능 순위가 아닌, source별 navigation·retrieval·parsing 절차를 typed tool로 노출하는 library의 구성 범위를 읽기 위한 자료다.
부록의 Senate.gov 사례는 executable access skill의 packaging을 구체화한다. skill.md는 source별 사용 지침을, manifest.yaml은 agent에게 공개할 typed parameter schema를, executor.py는 dispatch, retrieval, parsing, normalization을 구현한다. 이런 구성은 반복적인 browser loop를 구조화된 function call로 압축하지만, 최종 observation을 schema-bound evidence로 받아들일지는 여전히 Evidence Extraction Middleware의 binding과 anchoring 검사를 거친다.
전체 ablation을 함께 보면 성능 향상의 경로가 구분된다. Search-time schema planning은 검색 중 드러나는 정보 관계에 맞춰 completion target을 조직하고, continuous scheduling은 그 target의 ready work를 빈 slot에 공급한다. Middleware trajectory는 정체 감지 뒤 strategy switch가 진행 회복과 연결되는 대표 사례를 제공하며, skill ablation은 재사용 지식이 품질을 높이면서 검색 시간과 호출을 줄였음을 수치로 보여 준다. 다만 middleware는 정성 trajectory이고 skill layer는 함께 제거되었으므로, 네 결과를 동일한 강도의 독립 인과 추정으로 취급해서는 안 된다.
7. 한계점 및 향후 연구 방향: 구조화된 상태가 해결하지 못한 마지막 빈칸
7.1 알려진 셀의 완성과 전체 범위의 완성은 다르다
SearchOS에서 가장 중요한 한계는 Coverage Map의 100%가 곧 과업의 100% 완성을 뜻하지 않는다는 점이다. 스키마에 이미 등록된 엔티티와 속성만 놓고 보면 빈 셀을 정확히 셀 수 있지만, open-set 검색에서는 아직 발견하지 못한 행이 분모에 들어가지 않는다. 논문 부록도 이 문제를 숨기지 않는다. Spotify 사례의 마지막 상태는 알려진 20개 행의 모든 셀이 채워졌다고 보고하면서도, 이것만으로 요청된 행 집합이 완전하다는 보장은 없다고 명시한다. 그래서 시스템은 곧바로 종료하지 않고 공식 글로벌·미국 Top 10 목록과 행 집합을 다시 대조한다.
Michael Phelps 메달 사례는 이 취약점을 더 선명하게 보여 준다. 초기 두 에이전트가 작업을 마친 뒤 알려진 셀 기준 coverage는 100%였지만 표에는 16개 행만 있었고, 에이전트 보고서가 암시한 적격 종목 수는 약 31개였다. 오케스트레이터가 별도의 scope audit과 backfill을 수행하면서 표는 33개, 다시 35개 행으로 늘어났다. 최종 Item F1은 80.1이었지만 Row F1은 28.2에 머물렀다. 즉 셀 채우기 상태를 외부화하는 것과 검색 우주 자체가 충분히 발견되었는지 증명하는 것은 서로 다른 문제다.
따라서 향후에는 cell coverage와 별도로 row-set completeness를 일급 상태로 관리할 필요가 있다. 공식 목록의 기대 cardinality, 독립 출처별 후보 집합, 새 엔티티 발견률, 아직 확인하지 않은 기간·지역·카테고리, 상충하는 범위 정의를 별도의 scope ledger에 기록하면 좋다. 종료 조건도 “모든 알려진 셀이 채워짐” 하나를 넘어, “행 집합 감사 통과 + 신규 엔티티 발견 포화 + 주요 범위 축 검증”을 함께 요구하는 방식으로 강화할 수 있다.
7.2 Max@3는 시스템의 최고 가능성을 보여 주지만 단일 실행 신뢰도는 가린다
메인 실험은 각 문제를 세 번 실행한 뒤 가장 좋은 결과를 취하는 Max@3로 보고된다. 이 방식은 비결정적인 멀티에이전트 시스템이 도달할 수 있는 상한을 보여 주는 데는 유용하지만, 사용자가 한 번 실행했을 때 기대할 수 있는 평균 품질과 실패 확률을 직접 알려 주지는 않는다. 특히 SearchOS처럼 스키마 선택, 탐색 순서, 하위 에이전트 분배, 출처 접근 성공 여부가 연쇄적으로 결과를 바꾸는 시스템에서는 best-of-three와 single-run 사이의 차이가 운영 판단에 중요하다.
실험 설정도 해석 범위를 제한한다. 에이전트 역할에는 GLM-5, Evidence Extraction에는 Qwen3.5-35B-A3B를 사용했고, 세션마다 오케스트레이터 50회, 병렬 하위 에이전트 8개, 에이전트당 검색 20회, 1,800초의 상한을 둔다. 이 결과만으로 더 작은 모델, 다른 도구 호출 형식, 더 엄격한 시간 예산에서도 SOCM과 middleware의 이점이 같은 크기로 유지된다고 단정하기는 어렵다. 후속 평가에서는 평균과 표준편차, 최악 실행, 성공 확률, single-run과 Max@3의 격차를 함께 보고하고, 여러 backbone과 예산 구간에서 동일한 구조를 교차 검증하는 편이 바람직하다.
7.3 여러 부품이 함께 움직여 개별 기여를 완전히 분리하기 어렵다
논문은 스키마 계획, continuous scheduling, middleware intervention, hierarchical skills를 각각 분석한다. 결과도 일관되게 긍정적이다. Search-time schema planning은 더 나은 고정 스키마를 사후 선택하는 oracle보다 Item F1에서 8.2점, Row F1에서 7.7점 높았고, continuous dispatch는 평균 시간을 24.3% 줄였다. Skills는 Item F1을 2.0점, Row F1을 3.4점 높이면서 session time을 36.6% 줄였다.
다만 핵심인 SOCM 내부의 네 상태, 즉 Frontier Task, Evidence Graph, Coverage Map, Failure Memory를 하나씩 제거한 결과는 제시되지 않는다. Evidence Extraction과 Context Middleware, Sensor Middleware도 완전한 요인 설계로 분리되어 있지 않다. 세 개의 middleware 개입 trajectory는 정체 이후 coverage와 entity discovery가 다시 움직이는 모습을 보여 주지만, 논문 스스로 밝히듯 대표 사례에 기반한 mechanism-level evidence이지 전체 데이터에 대한 집계 인과 효과는 아니다. 따라서 “어떤 부품이 정확도를 올렸고 어떤 부품이 비용만 줄였는가”를 더 세밀하게 답하려면 구성 요소별 ablation과 상호작용 분석이 추가로 필요하다.
특히 Failure Memory의 효과는 별도 검증 가치가 크다. 차단된 Wiley·JSTOR 페이지 사례에서는 에이전트가 Crossref, OpenAlex와 학술 논문용 skill로 전환하고, 예산이 소진되면 확인되지 않은 셀을 억지로 채우지 않는다. 이 좋은 결과가 실패 기록 자체, Loop Sensor, access skill, 또는 오케스트레이터 판단 중 어디에서 주로 나오는지 분리하면 SearchOS의 재사용 가능한 설계 원리가 더 분명해질 것이다.
7.4 구조화된 표를 넘어선 일반화와 비용 정규화가 필요하다
WideSearch와 GISA는 폭넓은 open-domain 정보 탐색을 다루지만, 평가는 주로 item, set, list, table처럼 정답을 구조화해 비교할 수 있는 과업에 집중한다. 이는 relational schema completion이라는 논문의 문제 설정과 잘 맞는 동시에, 장문 조사 보고서의 논증 품질, 상충 출처에 대한 설명, 멀티모달 근거, 사용자의 주관적 기준처럼 표의 셀 하나로 환원하기 어려운 요소는 상대적으로 덜 시험한다. 저자들도 결론에서 더 넓은 도메인과 multimodal setting, 에이전트·출처·과업 간 적응을 후속 방향으로 제시한다.
또한 SearchOS는 최대 8개 하위 에이전트를 병렬로 사용한다. Continuous scheduling과 skills가 시간·호출 수를 줄인다는 내부 비교는 강점이지만, 메인 baseline 대비 총 토큰, 검색 비용, 페이지 비용, wall-clock time을 동일한 품질 수준에서 정규화한 표가 더해지면 실무적 판단이 쉬워진다. 향후에는 고정 예산에서의 F1, 고정 품질에서의 비용, tail latency, 출처 접근 실패율을 함께 보고하는 cost-normalized evaluation이 필요하다.
| 남은 한계 | 현재 논문에서 보이는 신호 | 가능한 후속 검증 |
|---|---|---|
| Open-set 완전성 | 알려진 셀 coverage 100% 뒤에도 행 집합 감사가 필요 | scope ledger, 기대 행 수, 독립 목록 대조, discovery saturation |
| 실행 분산 | 세 번 중 최고값인 Max@3 중심 보고 | single-run 평균·분산·최악값·성공 확률 공개 |
| 개별 부품의 인과 효과 | SOCM 네 메모리와 middleware가 결합되어 작동 | 요인별 제거 실험과 구성 요소 간 상호작용 분석 |
| 일반화와 운영 비용 | 두 benchmark, 특정 backbone, 구조화 출력 중심 | 다중 backbone·멀티모달·장문 보고서·비용 정규화 평가 |
8. 내 해석: 검색 상태를 운영하는 주체를 시스템으로 옮긴 선택
나는 SearchOS의 가장 큰 약점을 Coverage Map이 알려진 행의 셀 완성도는 잘 나타내지만, 아직 발견하지 못한 행의 규모까지는 교정하지 못한다는 데서 본다. 논문 부록의 Phelps 사례처럼 16개 행이 모두 채워져 coverage 100%가 되어도 사용자가 기대한 범위가 더 넓다면 결과는 불완전할 수 있다. 실험도 WideSearch와 GISA에서 Max@3 최고 성능을 보고하므로, 단일 실행에서 이 scope 오류가 얼마나 자주 발생하는지까지는 분리해 보여 주지 않는다. 이전에 검토한 LongSeeker가 누적 history를 Context-ReAct로 편집해 모델 입력의 정보 밀도를 높였다면, SearchOS는 그 입력을 재생성할 durable state를 제공한다. 두 시스템을 연결할 때도 잘못된 row set이 고밀도로 유지되면 오류가 더 오래 살아남을 수 있어, known-cell coverage와 open-set completeness를 별도 지표로 다뤄야 한다.
내가 다음 단계로 붙인다면 이중 원장형 scope memory를 먼저 실험할 것 같다. 첫 원장은 현재 Coverage Map처럼 발견된 행의 cell 상태와 근거를 관리하고, 둘째 원장은 요청 범위의 정의, 권위 있는 목록별 예상 행 수의 하한·상한, 출처 사이의 중복과 누락, 마지막 신규 엔티티 발견 시점, 아직 탐색하지 않은 범위 축을 기록한다. 종료 조건은 두 원장이 동시에 통과할 때만 만족시키고, 불일치가 남으면 본 검색과 독립된 verification agent가 행 집합만 다시 감사하도록 한다. 평가는 최종 Item·Row F1에 scope calibration error, single-run success rate, 추가 감사 비용을 함께 붙여야 한다. 이렇게 하면 SearchOS의 강점인 atomic evidence와 failure reuse를 유지하면서, 모델이 자연어로 판단하던 ‘충분히 찾았는가’를 관측 가능한 시스템 상태로 끌어낼 수 있다.
9. 결론: 장기 검색의 병목을 모델보다 상태와 실행 제어에서 다시 보기
SearchOS-V1은 open-domain information seeking을 근거 인용이 붙은 relational schema completion으로 다시 정의하고, 그 과정을 시스템이 유지하는 공유 상태 위에서 실행한다. SOCM은 unresolved gap, atomic evidence, cell coverage, failed attempt를 대화 history 밖으로 꺼낸다. 오케스트레이터와 explore·search·writer agent는 agent-to-agent 대화를 길게 이어 가는 대신 역할별 projection을 통해 같은 최신 상태를 본다. Middleware는 context 구성, evidence grounding, stall·budget 감시를 prompt 바깥에서 수행하고, hierarchical skills는 반복되는 decomposition·검색 전략·출처 접근 절차를 재사용한다.
메인 결과는 이 설계가 정확도 면에서 실제 이득을 준다는 점을 보여 준다. WideSearch에서 SearchOS는 Item F1 80.3으로 가장 강한 baseline의 76.0보다 4.3점 높고, Row F1도 56.5로 다음 방법보다 2.0점 높다. GISA에서는 모든 질문 유형에서 선두를 기록하며, 특히 Set F1은 76.5로 기존 최고 63.1보다 13.4점 높다. 개선이 precision보다 recall과 completeness에 민감한 지표에서 크게 나타난다는 사실은 Coverage Map과 gap-driven dispatch라는 설계 목표와 잘 맞는다.
분석 실험도 시스템의 각 설계가 단순한 장식이 아님을 뒷받침한다. Search-time schema planning은 고정 single-table과 multi-table 가운데 더 좋은 쪽을 사후 선택한 oracle보다도 높았고, continuous scheduling은 평균 시간을 629.13초에서 476.34초로 줄이면서 Item F1을 79.66에서 86.75로 높였다. Skills는 탐색 trial-and-error를 줄여 session time 36.6%, search call 39.1%, page call 42.7%를 절감했다. 대표 trajectory에서는 Loop Sensor 개입 뒤 정체된 coverage와 entity discovery가 다시 진행되는 모습도 확인된다.
동시에 이 논문의 가장 중요한 교훈은 coverage 숫자를 맹신하지 않는 데 있다. 알려진 행의 모든 셀이 채워져도 전체 행 집합이 빠졌을 수 있고, 접근 불가능한 출처 때문에 일부 셀이 끝까지 unresolved로 남을 수 있다. SearchOS의 좋은 선택은 이 불확실성을 숨기지 않고 audit, backfill, conflict, unreachable state로 남기는 것이다. 다만 그 상태를 얼마나 정확히 감지하고 언제 종료할지는 아직 더 강한 scope modeling과 실행 신뢰도 평가가 필요하다.
결국 SearchOS가 던지는 메시지는 명확하다. 긴 검색을 안정화하려면 더 큰 context window나 더 많은 에이전트만으로는 부족하다. 검색 목표를 구조화하고, 근거를 원자 단위로 보존하고, 빈칸과 실패를 공유하며, 실행을 시스템 수준에서 감시하는 인프라가 필요하다. SearchOS는 이 인프라를 하나의 닫힌 제어 루프로 묶어, multi-agent search를 대화의 연쇄에서 inspectable state machine으로 옮긴 중요한 사례다.
10. 요약 정리: SearchOS-V1에서 붙잡을 핵심 포인트
- SearchOS-V1은 open-domain 정보 탐색을 근거 인용이 붙은 relational schema completion 문제로 정식화한다.
- SOCM은 Frontier Task, Evidence Graph, Coverage Map, Failure Memory를 agent conversation 밖의 durable shared state로 유지한다.
- 역할별 agent는 최신 공유 상태에서 자신의 목표에 필요한 projection만 받고, continuous dispatch는 완료된 slot을 즉시 다시 채운다.
- Search Tool Middleware Harness는 context 구성, evidence extraction·grounding, loop·budget 감시를 prompt 바깥에서 집행한다.
- 280개의 hierarchical skill은 orchestrator, strategy, access 층으로 나뉘며, 품질을 높이는 동시에 session time과 검색·페이지 호출을 줄인다.
- WideSearch에서 Item F1은 80.3, Row F1은 56.5로 가장 강한 baseline보다 각각 4.3점, 2.0점 높다.
- GISA에서는 모든 질문 유형에서 선두를 기록했고, 특히 Set F1은 76.5로 기존 최고보다 13.4점 높다.
- Search-time schema planning, continuous scheduling, middleware trajectory, skill ablation은 구조 선택·실행 효율·정체 복구·검색 품질을 서로 다른 관점에서 뒷받침한다.
- 남은 핵심 과제는 known-cell coverage와 open-set completeness의 간극, Max@3가 가리는 single-run 신뢰도, 결합된 component의 인과 효과를 분리해 평가하는 것이다.