[arXiv 2605.05191] LongSeeker: 장기 검색 에이전트를 위한 탄력적 컨텍스트 오케스트레이션

LongSeeker: Elastic Context Orchestration for Long-Horizon Search Agents

arXiv: https://arxiv.org/abs/2605.05191

Yijun Lu, Rui Ye, Yuwen Du, Jiajun Wang, Songhua Liu, Siheng Chen | Shanghai Jiao Tong University | arXiv:2605.05191 | 2026년 5월

---

1. 서론: 장기 검색 에이전트의 컨텍스트 병목

LongSeeker 논문은 장기 검색 에이전트의 병목을 단순한 모델 크기나 검색 엔진 품질보다 먼저 작업 컨텍스트의 성장 방식에서 찾는다. ReAct 계열 에이전트는 reasoning trace, tool call, observation을 시간순으로 이어 붙이며 다음 단계의 입력을 만든다. 이 구조는 짧은 과업에서는 해석하기 쉽고 구현도 단순하지만, 수십 회 이상의 검색과 읽기, 검증, 반박을 거치는 과업에서는 이전 관찰이 그대로 누적되어 비용과 오류 가능성을 동시에 키운다고 논문은 서술한다.

논문이 지적하는 핵심 현상은 append-only context가 정보 보존을 보장하는 듯 보이지만 실제로는 신호 대 잡음비를 낮춘다는 점이다. 오래된 검색 결과, 실패한 쿼리, 중복된 페이지 요약, 아직 검증되지 않은 추론이 모두 같은 무게로 남아 있으면 모델은 중요한 증거를 다시 찾기 위해 더 많은 토큰을 소비한다. 또한 긴 컨텍스트 안에서 잘못된 초기 가설이 반복 노출되면 hallucination risk와 reasoning drift가 커질 수 있다고 논문은 설명한다.

이 논문은 이러한 문제를 해결하기 위해 Context-ReAct라는 실행 패러다임을 제안한다. 표준 ReAct가 reasoning과 tool use만을 순차적으로 생성했다면, Context-ReAct는 reasoning, context meta-operation, tool use를 한 루프에서 공동 생성한다. 즉 에이전트가 검색 도구를 부르기 전에 자기 작업 메모리를 어떤 단위로 남기고, 압축하고, 되돌리고, 잘라내고, 삭제할지를 명시적으로 결정하도록 만든다.

LongSeeker는 이 패러다임을 Qwen3-30B-A3B 기반 모델에 학습시킨 장기 검색 에이전트다. 논문은 10k synthesized trajectories를 이용한 SFT만으로도 BrowseComp, BrowseComp-ZH, xbench-2505, GAIA-text에서 폐쇄형 대형 모델 및 공개 검색 에이전트와 비교 가능한 성능을 보고한다. 중요한 점은 논문이 성능 향상을 단지 더 긴 컨텍스트 창으로 설명하지 않고, 컨텍스트를 조작 가능한 action layer로 올린 설계로 설명한다는 데 있다.

비교 축	표준 ReAct식 장기 검색	Context-ReAct / LongSeeker	논문이 강조하는 의미
컨텍스트 성장	reasoning, tool call, observation을 계속 append	매 단계 작업 컨텍스트를 재구성	토큰 비용과 overflow risk를 완화
정보 선택 단위	최근 window 또는 전체 history	step range, snippet, branch 단위	중요도와 목적에 따라 보존 수준을 조절
오류 처리	실패한 branch도 계속 남음	Rollback 또는 Delete로 정리	잘못된 가설의 반복 노출을 줄임
충실도	모든 원문을 남기거나 일괄 요약	Snippet으로 exact evidence 보존 가능	요약 손실과 증거 누락 사이의 균형을 조절

문제 설정을 이렇게 정리하면 LongSeeker의 기여는 더 분명해진다. 논문은 검색 에이전트가 더 많은 웹 페이지를 읽는 것만으로는 장기 과업을 안정적으로 해결하기 어렵다고 본다. 대신 어떤 관찰을 원문 그대로 남길지, 어떤 추론을 요약해도 되는지, 어떤 탐색 가지를 폐기할지 결정하는 운영 체계가 필요하다고 주장한다.

2. 배경 및 관련 연구: 누적형 ReAct에서 능동적 작업 메모리로

2.1 ReAct 기반 검색 에이전트의 누적형 메모리

ReAct는 reasoning, action, observation의 반복 루프로 에이전트 행동을 구조화한다. 논문은 이 형식이 검색 에이전트의 기본 골격이 되었지만, 장기 과업에서는 monotonic history growth라는 구조적 약점을 갖는다고 설명한다. $t$번째 단계의 기록을 $H_t$라고 할 때 표준 ReAct는 대체로 $H_t = H_{t-1} \Vert (r_t, a_t, o_t)$처럼 동작한다. 여기서 $r_t$는 추론, $a_t$는 도구 호출, $o_t$는 관찰이다.

이 수식은 단순하지만 중요한 함의를 갖는다. 과거 정보가 일단 들어오면 기본적으로 지워지지 않기 때문에, 에이전트가 긴 탐색을 수행할수록 입력 토큰 수는 거의 선형적으로 증가한다. 논문은 이 상황에서 모델이 필요한 근거를 찾기 위해 더 많은 attention 자원을 쓰고, 중복된 관찰과 실패한 중간 결론 사이에서 불필요한 추론을 반복할 수 있다고 서술한다. 따라서 긴 context window 자체는 충분조건으로 보기 어렵다는 것이 논문의 출발점이다.

2.2 기존 컨텍스트 관리 접근의 한계

논문은 기존 대응을 크게 sliding window, threshold-triggered restart, periodic summarization, proactive curation으로 분류한다. Sliding window는 최근 기록을 남기고 오래된 기록을 버리므로 구현은 쉽지만, 오래된 핵심 증거가 사라질 수 있다. Restart 계열은 overflow를 막을 수 있지만 reasoning continuity를 끊는다. Periodic summarization은 전체 길이를 줄이지만 고정 주기와 고정 granularity 때문에 요약 손실이 누적될 수 있다고 논문은 설명한다.

Proactive curation은 에이전트가 어느 정도 능동적으로 기록을 정리하도록 만들지만, 논문은 기존 방식이 조작 위치와 조작 종류에서 충분히 세밀하지 않다고 본다. LongSeeker의 차별점은 컨텍스트 관리를 외부 memory module이나 사후 요약기에 머물지 않고 에이전트의 표준 action space 안에 포함한다는 데 있다. 이 관점에서는 검색 도구 호출과 마찬가지로 컨텍스트 조작도 모델이 학습하고 실행해야 할 명시적 행동이 된다.

접근	대표 아이디어	장점	논문이 보는 한계
Sliding window	최근 $k$ steps만 보존	단순하고 예측 가능한 비용	중요한 오래된 증거를 importance-agnostic하게 버림
Restart / discard-all	문턱값 초과 시 컨텍스트를 비움	overflow를 강하게 회피	이전 탐색의 논리적 연결이 끊어짐
Periodic summary	일정 주기로 history를 요약	토큰 절감 효과가 있음	고정 주기와 고정 granularity로 인해 정보 손실이 누적
Proactive curation	에이전트가 일부 기록을 선별	task-aware 선택 가능	조작 원자성이 제한적이고 branch 수준 backtracking이 약함
Context-ReAct	meta-operation을 ReAct 루프에 삽입	압축, 추출, 삭제, 되돌리기를 한 action layer에서 처리	학습 데이터 품질과 operation 선택 신뢰성이 중요해짐

관련 연구와 비교하면 LongSeeker는 검색 데이터 수집이나 평가 프레임워크 자체보다는 runtime memory policy에 초점을 둔다. 논문은 장기 검색 능력이 검색 쿼리 생성, 웹 브라우징, 정보 합성 문제에 그치지 않고, 그 모든 과정을 담는 작업 컨텍스트의 형태를 동적으로 제어하는 문제라고 재정의한다.

3. 방법론: Context-ReAct와 LongSeeker

3.1 Context-ReAct 루프의 형식화

논문은 Context-ReAct를 표준 ReAct의 일반화로 제시한다. 표준 단계가 $(r_t, a_t, o_t)$라면 Context-ReAct 단계는 $(r_t, m_t, a_t, o_t)$에 가깝다. 여기서 $m_t$는 하나 이상의 context meta-operation이다. 모델은 다음 도구를 호출하기 전에 현재 history에 대해 어떤 조작을 수행할지 함께 출력하고, 그 결과 만들어진 working context를 다음 reasoning의 입력으로 사용한다.

이때 핵심은 meta-operation이 사후 청소 작업을 넘어 reasoning과 공동 생성되는 행동이라는 점이다. 논문은 에이전트가 어떤 evidence가 여전히 중요하고, 어떤 observation은 요약 가능한지, 어떤 branch는 실패했는지를 스스로 판단하도록 만든다. 따라서 Context-ReAct는 memory compression 알고리즘 하나라기보다, 검색 에이전트의 thought-action-observation 루프에 memory action을 추가하는 agentic paradigm으로 해석할 수 있다.

Figure 2: Overview of the Context-ReAct paradigm

그림 2에서 논문은 표준 ReAct가 history를 수동적으로 누적하는 구조인 반면, Context-ReAct는 reasoning과 tool call 사이에 meta-action layer를 삽입한다고 설명한다. 이 계층은 Skip, Compress, Rollback, Snippet, Delete를 통해 원문 보존부터 구조적 되돌리기까지 세밀한 조작을 허용하며, 컨텍스트 관리가 외부 규칙에 머물지 않고 에이전트 출력의 일부가 되도록 만든다.

3.2 다섯 가지 atomic meta-operation

Context-ReAct의 작업 단위는 Skip, Compress, Rollback, Snippet, Delete 다섯 가지다. 논문은 Compress가 표현력 측면에서 complete하다고 주장한다. 임의의 source history를 임의의 target string으로 바꾸는 작업은 전체 history를 하나의 구간으로 잡아 Compress하는 방식으로 표현할 수 있기 때문이다. 그러나 논문은 Compress만 쓰는 것이 실용적이지 않다고 보고, 나머지 operation들이 비용과 충실도 측면에서 유용한 inductive bias를 제공한다고 설명한다.

Operation	동작	주요 보장 또는 장점	적합한 상황
Skip	현재 컨텍스트를 그대로 유지	추가 생성 비용이 거의 없음	현재 작업 메모리가 이미 작고 관련성이 높을 때
Compress	연속된 step range를 요약으로 대체	expressively complete, 장기 history를 유연하게 재작성	중복 검색 결과나 이미 해결된 하위 쟁점을 축약할 때
Rollback	특정 step 이후의 branch를 버리고 되돌아감	tree search식 backtracking prior 제공	잘못된 가설이나 막다른 탐색을 abandon할 때
Snippet	중요한 원문 span을 정확히 추출	lossless evidence retention 가능	숫자, 이름, 날짜, 인용문처럼 변형되면 안 되는 근거를 남길 때
Delete	불필요하거나 오염된 기록을 제거	요약 생성 없이 noise를 제거	중복 observation, 실패한 query, 명백한 잡음을 버릴 때

이 operation 집합의 설계 의도는 중복을 제거하면서도 원문 충실도를 잃지 않는 것이다. 예를 들어 모든 것을 Compress로 처리하면 이론적으로 어떤 변환도 가능하지만, 중요한 숫자나 URL을 요약 문자열에 다시 생성하게 되므로 오류가 들어갈 수 있다. 반대로 Snippet은 필요한 span을 그대로 가져오기 때문에 evidence fidelity를 높인다. Delete와 Rollback은 모델이 잘못된 탐색 경로를 일반 요약으로 흐리게 남기지 않고 구조적으로 폐기하도록 돕는다.

Figure 3: Managed context and structured output at a single Context-ReAct step

그림 3에서 논문은 한 단계의 Context-ReAct 출력이 어떻게 managed context를 만드는지 예시한다. 초기 steps 1~4는 Compress로 핵심만 남고, step 5는 Skip으로 유지되며, step 6은 Delete로 제거된다. 이후 Rollback을 통해 비생산적인 탐색 가지를 정리한다. 이 예시는 다섯 operation이 단순한 요약 명령을 넘어 작업 메모리의 구조를 바꾸는 조작이라는 점을 보여 준다. 특히 meta-operation이 도구 호출과 분리된 사후 처리 단계로 남지 않고 같은 step의 출력 안에서 함께 결정된다는 점이 도식의 핵심이다.

3.3 LongSeeker 학습 데이터와 파이프라인

LongSeeker는 Context-ReAct 형식의 궤적을 생성하고 이를 기반으로 SFT를 수행한 모델이다. 논문은 Qwen3-30B-A3B를 기반으로 삼고, 약 10k synthesized trajectories를 사용했다고 보고한다. 여기서 중요한 점은 정답과 검색 결과 학습에 머물지 않고, reasoning, meta-operation, motivation, standard tool call이 함께 들어 있는 structured output을 학습한다는 것이다.

논문이 제시하는 파이프라인은 장기 검색 궤적을 만든 뒤, 그 궤적 안에서 어떤 step을 보존하고 어떤 step을 압축하거나 삭제할지를 Context-ReAct 형식으로 재표현하는 방식으로 이해할 수 있다. 즉 학습 목표는 좋은 답을 찾는 검색 행동과 좋은 작업 컨텍스트를 유지하는 운영 행동을 동시에 모방하는 것이다. 이 결합이 LongSeeker를 단순 검색 모델과 구분하는 핵심이다.

단계	입력 또는 산출물	역할	주의할 지점
Trajectory synthesis	장기 검색 과업에 대한 다단계 reasoning/tool trace	검색 행동과 중간 관찰을 확보	teacher 품질이 학습 상한을 결정할 수 있음
Context annotation	Skip, Compress, Rollback, Snippet, Delete label	작업 메모리 조작 방식을 명시	operation 선택의 근거가 불충분하면 편향 가능
Structured output formatting	reasoning, meta-tool calls, motivation, tool call	추론과 메모리 조작을 동일한 출력 체계로 정렬	형식 오류가 runtime 안정성에 직접 영향을 줄 수 있음
SFT on Qwen3-30B-A3B	10k synthesized trajectories	LongSeeker-30B 행동 정책 학습	SFT-only 설정에서 exploration correction은 제한적일 수 있음

이 표에서 보듯 LongSeeker의 학습은 tool-augmented QA 데이터만으로는 설명되지 않는다. 논문은 context operation 자체를 모델이 출력해야 할 토큰 시퀀스로 만들고, 그 operation이 왜 필요한지 motivation까지 포함시킨다. 이는 모델이 단순히 짧게 답하는 법에 그치지 않고, 긴 탐색 중 어느 정보를 어느 해상도로 들고 갈지 결정하는 컨텍스트 운영 정책을 학습한다는 의미다.

Figure 7: Complete structured output from LongSeeker

그림 7은 LongSeeker가 한 단계에서 reasoning, meta-tool call, motivation, standard tool call을 함께 출력하는 형식을 보여 준다. 논문은 이 구조화가 단순한 로그 장식을 넘어 runtime 제어면이라고 본다. 특히 motivation 필드는 왜 특정 구간을 압축하거나 삭제했는지 남겨, 후속 단계에서 operation의 의도를 추적할 수 있게 한다는 점에서 중요하다. 이 예시는 요약, 보존, 삭제, 되돌리기가 한 화면 안에서 어떻게 다른 history 구간에 적용되는지를 보여 주므로, operation 단위의 차이를 확인하기 좋다.

3.4 이론적 주장: 표현 완전성과 실용적 중복성

논문은 Compress가 임의의 history 변환을 표현할 수 있다는 점에서 expressively complete하다고 서술한다. 직관적으로, 현재 history 전체를 하나의 구간으로 잡고 target context를 요약 결과로 출력하면 어떤 target도 만들 수 있다. 따라서 operation set의 나머지 원소는 이론적 표현력을 높이기 위해서라기보다, 모델이 더 낮은 비용과 더 높은 충실도로 자주 필요한 변환을 수행하도록 돕는 역할을 한다.

이 주장은 Context-ReAct의 설계를 평가할 때 중요하다. 만약 목표가 순수 표현력뿐이라면 Compress 하나로 충분하다. 그러나 장기 검색에서는 중요한 원문 span을 exact하게 남겨야 하고, 실패한 branch를 명확히 버려야 하며, 현재 상태가 충분히 작으면 아무것도 하지 않는 선택도 필요하다. 논문은 이런 이유로 principled redundancy라는 관점에서 다섯 operation의 공존을 정당화한다.

Context-ReAct의 설계를 조금 더 자세히 보면, 논문은 다섯 operation을 같은 수준의 편의 명령으로 두지 않는다. Skip은 현재 history가 이미 충분히 작고 정보 밀도가 높을 때 아무 조작도 하지 않는 선택이다. 이 선택이 명시적으로 존재해야 모델은 매 단계마다 불필요한 요약을 생성하지 않는다. 요약 자체도 새 텍스트를 만드는 행위이기 때문에, 근거 숫자나 이름이 중요한 순간에는 오히려 손실을 만들 수 있다. Skip은 그런 상황에서 원문 맥락을 그대로 유지하는 보존 행동으로 작동한다.

Compress는 논문에서 가장 강한 이론적 지위를 갖는다. 논문은 Compress가 임의의 history를 임의의 target string으로 바꿀 수 있으므로 표현적으로 완전하다고 설명한다. 하지만 이 완전성은 실무적으로는 양날의 성격을 갖는다. 모델이 충분히 좋은 요약을 만들면 길고 지저분한 trajectory가 짧은 상태 표현으로 바뀌지만, 숫자, 인용, 시간, entity 관계처럼 원문 충실도가 필요한 정보는 요약 과정에서 변형될 수 있다. 그래서 논문은 Compress 하나로 모든 조작을 처리하지 않고 Snippet, Rollback, Delete 같은 더 구체적인 연산을 함께 둔다.

Snippet은 Compress의 손실 가능성을 보완하는 장치다. 검색 에이전트가 웹 페이지에서 날짜, 회사명, 논문 제목, 인용 문구, 벤치마크 점수처럼 그대로 남겨야 하는 evidence를 발견했을 때, 그 부분을 재생성하지 않고 필요한 문자열만 보존한다. 논문이 Snippet을 별도 operation으로 둔 이유는 장기 검색에서 정확한 증거 한 조각이 긴 요약 전체보다 더 중요해지는 순간이 많기 때문이다. 특히 BrowseComp류 과업은 정답 후보를 좁히는 과정에서 세부 사실 하나가 결정적 근거가 되는 경우가 많다.

Rollback과 Delete는 둘 다 정보를 줄이는 operation이지만 적용 범위가 다르다. Rollback은 탐색 가지 자체가 생산적이지 않다고 판단될 때 이후 trajectory를 되돌리는 구조적 조작이고, Delete는 특정 step이나 observation이 noise라고 판단될 때 그 단위만 제거하는 국소 조작이다. 장기 검색 에이전트에서는 잘못된 쿼리 하나가 여러 후속 검색을 낳을 수 있으므로 branch 단위 정리가 필요하다. 반대로 특정 검색 결과 하나만 중복이거나 무관할 때는 전체 가지를 되돌릴 필요 없이 해당 step만 지우는 편이 정보 손실을 줄인다.

논문이 제안한 출력 형식도 중요하다. LongSeeker는 답변과 검색 호출만 내는 구조를 넘어, reasoning, meta-tool call, motivation, standard tool call을 함께 생성한다. motivation 필드는 왜 특정 구간을 압축했는지, 왜 어떤 observation을 삭제했는지, 왜 특정 evidence를 snippet으로 남겼는지를 설명한다. 이 구조는 후속 분석에서 operation decision을 재검토할 수 있게 만들며, 장기 실행 에이전트에서 흔히 문제가 되는 "왜 이 정보를 버렸는가"라는 질문에 최소한의 trace를 제공한다.

operation	권장 사용 상황	주요 위험	검증할 흔적
Skip	현재 context가 충분히 compact하고 핵심 evidence가 원문 형태로 남아 있을 때	불필요한 보존이 반복되면 context가 다시 팽창	Skip 이후 token growth와 후속 답변의 evidence 사용 여부
Compress	이미 결론이 난 여러 step을 짧은 상태 설명으로 묶을 때	숫자, entity, 조건이 요약 중 변형될 수 있음	요약 전후 핵심 사실의 일치와 provenance 유지
Rollback	탐색 branch가 잘못된 가설에서 출발했거나 후속 검색이 무의미해졌을 때	branch 안에 숨은 유효 evidence까지 잃을 수 있음	되돌린 구간의 최종 답 기여 가능성
Snippet	정확한 문구, 날짜, 고유명사, 점수를 보존해야 할 때	문맥 없는 짧은 발췌가 잘못 해석될 수 있음	발췌 주변 문맥과 source URL 연결
Delete	중복 검색, 실패한 호출, 명백히 무관한 observation을 제거할 때	초기에는 무관해 보인 정보가 나중에 필요해질 수 있음	삭제 이유와 대체 evidence 존재 여부

이 표에서 보듯 Context-ReAct는 컨텍스트를 줄이는 기술만을 의미하지 않는다. 오히려 논문이 목표로 하는 것은 해상도 선택이다. 어떤 정보는 원문 그대로 남고, 어떤 정보는 요약되며, 어떤 정보는 branch와 함께 접히고, 어떤 정보는 noise로 제거된다. 이 해상도 선택이 잘 맞으면 모델은 긴 검색 동안 같은 사실을 반복해서 읽지 않아도 되고, 잘못된 중간 결론이 다음 reasoning을 오염시키는 빈도도 줄어든다.

학습 측면에서 LongSeeker는 OpenSeeker에서 가져온 복합 multi-hop 질문을 바탕으로 teacher model이 Context-ReAct trajectory를 생성하는 절차를 사용한다. 논문은 영어와 중국어 질문을 포함하고, 각 step마다 meta-operation과 motivation을 함께 기록한다. 이 데이터 구성은 정답 supervision만으로는 배울 수 없는 중간 context policy를 모델에 제공한다. 다만 teacher가 생성한 operation decision이 항상 최적이라고 보기는 어렵기 때문에, 후속 연구에서는 operation quality를 별도 평가하는 과정이 필요하다.

SFT-only라는 선택도 해석할 지점이 있다. 강화학습을 쓰지 않았다는 점은 training pipeline을 단순하게 만들고 재현 가능성을 높일 수 있다. 반면 장기 검색에서 좋은 context operation은 최종 성공, 중간 evidence 보존, 비용 절감, 잘못된 branch 제거가 함께 맞아야 하므로 단일 demonstration을 그대로 모방하는 것만으로는 한계가 생길 수 있다. 논문이 좋은 출발점을 제시하지만, operation-level reward나 provenance-aware evaluator가 붙을 여지가 남는다.

4. 실험 설정: 검색 벤치마크와 10k Context-ReAct 궤적

4.1 벤치마크 구성

논문은 LongSeeker를 네 가지 장기 검색 벤치마크에서 평가한다. BrowseComp와 BrowseComp-ZH는 복잡한 웹 검색과 증거 결합이 필요한 과업을 다루며, xbench-2505는 검색 기반 문제 해결의 최신 구성으로 제시된다. GAIA-text는 도구 사용과 다단계 reasoning이 필요한 GAIA 계열 과업에서 텍스트 중심 조건을 반영한다. 논문은 이 조합을 통해 영어, 중국어, 일반 검색, 장기 추론을 함께 확인한다고 보고한다.

Benchmark	주요 성격	검색 에이전트에 요구되는 능력	LongSeeker 평가상 의미
BrowseComp	영어권 복합 웹 탐색	멀티홉 검색, 교차 검증, 증거 합성	장기 검색의 대표 난도 확인
BrowseComp-ZH	중국어권 복합 웹 탐색	다국어 검색, 지역 웹 정보 처리	중국어 검색 환경에서의 일반화 확인
xbench-2505	검색 기반 최신 평가 세트	웹 관찰을 장기 reasoning에 통합	최신 에이전트 비교에서의 위치 확인
GAIA-text	GAIA 계열 텍스트 중심 과업	도구 사용, 정보 추적, 최종 답 검증	검색 외 reasoning robustness 확인

평가 구성을 볼 때 LongSeeker의 주장은 특정 데이터셋 하나의 점수 상승에 국한되지 않는다. 논문은 여러 벤치마크에서 비슷한 방향의 결과를 보이며, 컨텍스트 조작이 영어 웹 검색과 더불어 중국어 검색과 텍스트 중심 장기 과업에서도 도움이 될 수 있음을 보고한다. 다만 benchmark sampling과 실행 환경의 세부 차이는 비교 해석에서 주의해야 할 요소다.

4.2 비교 대상과 해석 범위

비교 대상은 GPT-5, Gemini-3.0-Pro, Claude-Opus-4.5, Seed-2.0-Pro, DeepSeek-V3.2, GLM-4.7 같은 foundation model with tools와 MiroThinker, RedSearcher, IterResearch, AgentFold, Tongyi-DeepResearch, OpenSeeker 같은 search agent를 포함한다. 논문은 일부 수치에 별표를 붙여 ReAct-based agents without context management 조건을 표시하고, unavailable 또는 unknown 결과는 대시로 표기한다.

이 비교는 LongSeeker가 30B급 공개 기반 모델에서 학습된 시스템이라는 점 때문에 흥미롭다. 폐쇄형 모델은 내부 도구, 검색 엔진, 추론 정책, 컨텍스트 처리 방식이 공개되지 않는 경우가 많다. 따라서 논문이 보고한 점수는 LongSeeker의 가능성을 보여 주지만, 모든 baseline이 동일한 runtime 조건에서 평가되었는지에 대해서는 조심스럽게 읽어야 한다. 논문도 수치 표기에서 unknown 결과와 별표 조건을 구분한다.

5. 주요 실험 결과: 30B 검색 에이전트의 성능 위치

5.1 메인 결과 표

논문은 LongSeeker가 BrowseComp 61.5, BrowseComp-ZH 62.5, xbench-2505 78.0, GAIA-text 77.7을 기록했다고 보고한다. 이 점수는 모든 벤치마크에서 최고라는 뜻은 아니지만, 30B급 모델이 context operation 학습만으로 강한 폐쇄형 모델 및 공개 검색 에이전트와 경쟁 가능한 위치에 오른다는 근거로 제시된다. 특히 xbench-2505에서는 DeepSeek-V3.2와 같은 78.0을 기록한다.

Model	Category	Training / Note	BrowseComp	BrowseComp-ZH	xbench-2505	GAIA-text
GPT-5	Foundation model with tools	closed / tool use	54.9	63.0	77.8	76.4
Gemini-3.0-Pro	Foundation model with tools	closed / tool use	59.2	66.8	-	74.8
Claude-Opus-4.5	Foundation model with tools	closed / tool use	67.8	62.4*	-	71.5
Seed-2.0-Pro	Foundation model with tools	closed / tool use	77.3	82.4	-	78.6
DeepSeek-V3.2	Foundation model with tools	671B / tool use	67.6	65.0*	78.0	75.1
GLM-4.7	Foundation model with tools	358B / tool use	67.5	66.6*	72.0	-
MiroThinker-1.7-mini	Search agent	CPT + SFT + RL	67.9	72.3	-	80.3
MiroThinker-1.5-mini	Search agent	CPT + SFT + RL	56.1	66.8	73.1	72.0
RedSearcher	Search agent	CPT + SFT + RL	57.4	58.2	-	80.1
IterResearch	Search agent	agent training	37.3	45.2	71.0	72.8
AgentFold	Search agent	agent training	36.2	47.3	-	67.0
Tongyi-DeepResearch	Search agent	agent training	43.4*	46.7*	75.0	70.9
OpenSeeker	Search agent	open search agent	29.5*	48.4*	74.0	-
LongSeeker	Search agent	Qwen3-30B-A3B + 10k SFT trajectories	61.5	62.5	78.0	77.7

논문은 이 표를 통해 LongSeeker가 GPT-5보다 BrowseComp에서 높고, xbench-2505에서는 GPT-5보다 소폭 높으며 DeepSeek-V3.2와 동률이라고 보고한다. 반면 Seed-2.0-Pro와 MiroThinker-1.7-mini는 일부 지표에서 LongSeeker보다 높은 값을 보인다. 따라서 결과의 핵심은 절대 1위 주장보다, context orchestration만을 명시적으로 학습한 30B agent가 상위권에 접근했다는 점으로 읽는 것이 타당하다.

Figure 1: LongSeeker-30B delivers strong results on challenging long-horizon benchmarks

그림 1에서 논문은 LongSeeker-30B가 장기 검색 벤치마크 전반에서 강한 결과를 낸다고 시각화한다. 이 그림의 메시지는 모델 파라미터 규모만으로 성능을 설명하기 어렵다는 것이다. LongSeeker는 Seed-2.0-Pro 같은 최상위 폐쇄형 시스템을 넘지는 못하지만, GPT-5와 Gemini-3.0-Pro 수준의 여러 지표에 근접하며 Context-ReAct 설계의 실효성을 강조한다. 이 곡선은 긴 context window를 모두 채우는 전략보다 활성 작업 집합을 작게 유지하는 전략이 장기 검색에서 어떤 자원 이점을 줄 수 있는지 보여 준다.

5.2 수치가 말하는 강점과 절제된 해석

LongSeeker의 가장 설득력 있는 수치는 BrowseComp 61.5와 xbench-2505 78.0이다. 전자는 장기 웹 탐색의 비용과 오류 누적 문제를 직접 반영하는 지표로 볼 수 있고, 후자는 최신 검색 평가에서 대형 모델과 동률에 도달했다는 점에서 의미가 있다. 논문은 이러한 결과가 Context-ReAct의 adaptive context management가 실제 성능으로 이어질 수 있음을 보여 준다고 해석한다.

다만 BrowseComp-ZH에서는 LongSeeker가 62.5로 GPT-5의 63.0보다 약간 낮고 Gemini-3.0-Pro의 66.8, Seed-2.0-Pro의 82.4보다 낮다. GAIA-text에서도 MiroThinker-1.7-mini와 RedSearcher가 더 높은 점수를 보인다. 따라서 논문 결과는 Context-ReAct가 모든 벤치마크를 지배했다기보다, SFT-only 30B 모델이 컨텍스트 운영 정책을 학습함으로써 비용 대비 강한 장기 검색 성능을 달성했다는 주장으로 해석하는 편이 정확하다.

메인 결과를 읽을 때는 비교군이 서로 다른 성격을 가진다는 점을 먼저 분리해야 한다. GPT-5, Gemini-3.0-Pro, Claude-Opus-4.5, Seed-2.0-Pro, DeepSeek-V3.2, GLM-4.7은 foundation model with tools 범주에 놓이고, MiroThinker, RedSearcher, IterResearch, AgentFold, Tongyi-DeepResearch, OpenSeeker, LongSeeker는 search agent 범주에 놓인다. 같은 표에 있지만 학습 데이터, inference stack, 도구 환경, 내부 prompt, 최대 step budget이 모두 동일하다고 보기는 어렵다. 따라서 논문이 제시한 숫자는 절대적 순위보다 Context-ReAct 기반 30B agent가 어느 위치까지 올라오는지를 보여 주는 지표로 해석하는 편이 안전하다.

LongSeeker의 BrowseComp 61.5는 GPT-5 54.9와 Gemini-3.0-Pro 59.2보다 높고, Tongyi-DeepResearch 43.4, AgentFold 36.2, OpenSeeker 29.5보다 크게 높다. BrowseComp-ZH 62.5는 DeepSeek-V3.2의 65.0, Gemini-3.0-Pro의 66.8, MiroThinker-1.7-mini의 72.3, Seed-2.0-Pro의 82.4에는 미치지 못하지만, Tongyi-DeepResearch 46.7과 AgentFold 47.3보다 높다. 이 분포는 LongSeeker가 모든 조건에서 최고라는 주장보다, 작은 규모의 공개 검색 에이전트가 강한 context policy만으로 상위권에 접근할 수 있다는 쪽에 더 가깝다.

xbench-2505와 GAIA-text 결과는 별도 의미를 갖는다. BrowseComp류가 hard information retrieval과 multi-step navigation을 직접 겨냥한다면, xbench와 GAIA-text는 planning, synthesis, tool use, 일반 agent capability가 섞인 평가다. LongSeeker가 xbench-2505에서 78.0, GAIA-text에서 77.7을 기록했다는 점은 Context-ReAct의 효과가 특정 검색 문항 세트에만 묶이지 않을 수 있음을 보여 준다. 논문은 이를 long-horizon search에서 배운 context orchestration이 더 넓은 agent task에도 전이될 가능성으로 해석한다.

다만 수치가 높은 벤치마크와 낮은 벤치마크를 나누어 보는 것도 필요하다. LongSeeker는 BrowseComp에서 MiroThinker-1.5-mini, Tongyi-DeepResearch, AgentFold, OpenSeeker를 명확히 앞선다. 반면 BrowseComp-ZH에서는 MiroThinker-1.7-mini, Seed-2.0-Pro, Gemini-3.0-Pro보다 낮다. 이 차이는 언어별 검색 환경, teacher trajectory의 분포, 중국어 웹 자료 접근성, question sampling의 난이도 차이가 함께 작용했을 수 있다. 논문은 200 questions sampling을 사용했다고 밝히므로, 전체 benchmark에 대한 완전한 ranking으로 확대할 때는 신중해야 한다.

결과 축	논문이 보고한 관찰	해석할 때의 주의점
BrowseComp	LongSeeker 61.5로 여러 공개 search agent와 일부 tool-augmented foundation model을 상회	폐쇄형 agent의 내부 도구·prompt·sampling 조건은 완전히 통제되지 않음
BrowseComp-ZH	62.5로 Tongyi-DeepResearch와 AgentFold보다 높지만 최상위 모델보다 낮음	중국어 검색 corpus와 teacher distribution의 영향을 분리하기 어려움
xbench-2505	78.0으로 DeepSeek-V3.2와 같은 점수, MiroThinker-1.5-mini와 Tongyi-DeepResearch보다 높음	context policy 효과와 base model/tool stack 효과를 추가 ablation으로 나눌 필요
GAIA-text	77.7로 DeepSeek-V3.2와 Claude-Opus-4.5보다 높고 MiroThinker-1.7-mini보다 낮음	text-only subset 특성이 multimodal/tool-heavy GAIA와 다를 수 있음

이 결과 표에서 특히 실용적인 부분은 LongSeeker가 256k context window를 거의 다 쓰지 않고도 경쟁력 있는 점수를 낸다는 분석과 연결된다. 많은 장기 에이전트 시스템은 실패할수록 더 많은 history를 입력에 밀어 넣어 다음 step의 부담을 키운다. LongSeeker는 평균 context token이 약 15k 수준에서 안정화되는 패턴을 보이므로, 같은 최대 300 tool calls 조건에서도 매 step의 입력 비용과 잡음 노출을 줄일 수 있다. 논문이 말하는 효율성은 단순 latency 수치보다 장기 실행의 입력 표면을 작게 유지하는 능력에 더 가깝다.

6. 추가 분석 및 Ablation Study: 컨텍스트 성장과 operation 사용 패턴

6.1 컨텍스트 성장 곡선

논문은 LongSeeker의 평균 컨텍스트 토큰 수가 장기 탐색 중에도 안정적으로 유지된다고 보고한다. Figure 4(a)에 따르면 LongSeeker의 context token count는 약 15k 토큰 부근에서 plateau를 형성하며, 256k context capacity에 충분한 headroom을 남긴다. 반면 ReAct 기반 DeepSeek-V3.2는 step이 늘수록 컨텍스트가 거의 선형적으로 증가하는 양상을 보인다고 논문은 설명한다.

Figure 4(a): average context token count remains stable around 15k tokens

그림 4(a)는 Context-ReAct가 단순히 최종 답률을 높이는 장치를 넘어 runtime resource profile을 바꾸는 장치임을 보여 준다. 논문은 LongSeeker의 working context가 약 15k 토큰 주변에서 안정화되어 256k capacity를 거의 다 쓰지 않는다고 보고한다. 이는 overflow 방지와 함께, 매 단계 모델이 읽어야 하는 noisy history를 줄이는 효과로 해석된다. 분포를 함께 보면 모델이 모든 정보를 과감히 지우기보다 대부분의 상황에서 보존과 압축을 중심으로 움직인다는 점도 확인할 수 있다.

이 분석은 장기 검색 에이전트 운영에서 특히 중요하다. 컨텍스트 창이 매우 큰 모델이라도 모든 중간 기록을 계속 넣으면 inference cost와 latency가 증가한다. 논문은 LongSeeker가 context capacity를 더 크게 요구하는 방식이 아니라, 주어진 capacity 안에서 working set size를 안정화하는 방식으로 장기 탐색을 수행한다고 주장한다.

6.2 Meta-operation 분포

Figure 4(b)는 LongSeeker가 다섯 operation을 모두 사용하지만, Skip과 Compress가 지배적인 비율을 차지한다고 보고한다. 이는 대부분의 단계에서 현재 컨텍스트를 그대로 두거나 일부 구간을 요약하는 선택이 충분하다는 뜻으로 해석할 수 있다. Rollback과 Delete는 더 보수적으로 사용되며, 논문은 이를 충실도 보존과 과도한 pruning 회피의 결과로 설명한다.

Figure 4(b): Meta-operation distribution of LongSeeker

그림 4(b)에서 논문은 LongSeeker가 모든 meta-operation을 실제로 사용한다고 보고한다. Skip과 Compress가 많다는 점은 작업 컨텍스트 관리가 매번 공격적인 삭제로 이루어지기보다, 필요한 경우에만 해상도를 낮추는 방식임을 시사한다. Rollback과 Delete가 낮은 비율인 것은 중요 증거를 잘못 버리는 위험을 줄이기 위한 보수적 pruning으로 해석된다. 동일 base와 step budget 조건에서 비교했다는 점 때문에, 이 그림은 모델 규모보다 context operation 설계가 성능에 주는 차이를 분리해 보려는 실험으로 읽힌다.

분포가 중요한 이유는 operation set이 장식적인 vocabulary가 아닌지 확인할 수 있기 때문이다. 특정 operation 하나만 압도적으로 쓰인다면 Context-ReAct의 원자 조작 설계가 실제 정책으로 학습되지 않았을 가능성이 있다. 논문은 다섯 operation이 모두 관찰된다는 점을 통해 LongSeeker가 상황별로 다른 메모리 조작을 수행한다고 주장한다.

6.3 Context management strategy ablation

논문은 같은 DeepSeek-V3.2 base와 동일한 step budget 조건에서 Context-ReAct, Summary, Discard-all을 비교하는 ablation을 제시한다. Figure 5에 따르면 Context-ReAct가 가장 높은 성능을 보이며, 단순 요약이나 전체 폐기보다 더 나은 결과를 낸다고 보고한다. 이는 세밀한 operation layer가 고정 전략보다 task-aware context retention에 유리하다는 주장을 뒷받침한다.

Strategy	컨텍스트 처리 방식	예상 장점	논문이 보고한 경향
Summary	일정 범위 또는 일정 시점의 history를 요약	토큰 수 절감, 구현 단순성	고정 granularity 탓에 중요한 원문 근거가 흐려질 수 있음
Discard-all	문턱값 도달 시 컨텍스트를 크게 비움	overflow를 강하게 방지	reasoning continuity와 evidence chain을 잃을 위험이 큼
Context-ReAct	Skip, Compress, Rollback, Snippet, Delete를 상황별 적용	task-aware, fine-grained, evidence-preserving	동일 step budget에서 가장 높은 성능을 보인다고 보고

Figure 5: Context-ReAct vs Summary and Discard-all under the same base and budget

그림 5에서 논문은 Context-ReAct가 Summary와 Discard-all보다 높은 성능을 보인다고 보고한다. 이 결과는 단순히 길이를 줄이는 것과 올바르게 줄이는 것이 다르다는 점을 강조한다. Summary는 전체를 부드럽게 축약하지만 중요한 span을 잃을 수 있고, Discard-all은 과감하지만 연결성을 끊는다. Context-ReAct는 두 극단 사이에서 조작 단위를 세분화한다. 긴 case study는 정량표에서 보이지 않는 operation 조합을 확인하게 해 주며, 특히 어떤 정보가 요약되고 어떤 정보가 exact snippet으로 남는지를 보여 준다.

Ablation의 해석은 LongSeeker 논문의 가장 강한 논리적 연결고리 중 하나다. 메인 결과만으로는 개선이 모델, 데이터, 도구, 실행 환경 중 어디에서 왔는지 분리하기 어렵다. 반면 동일 base와 step budget 아래에서 management strategy만 바꾼 비교는 context orchestration 자체의 효과를 더 직접적으로 보여 준다.

6.4 Case study: 관리된 컨텍스트와 구조화 출력

논문은 Figure 6에서 Compress, Rollback, Delete, Snippet이 결합된 완전한 case study를 제시한다. 이 사례의 목적은 operation이 독립적으로 하나씩 쓰이는 데 머물지 않고, 긴 검색 trajectory의 서로 다른 부분에 동시에 적용될 수 있음을 보여 주는 것이다. 어떤 구간은 요약되고, 어떤 branch는 되돌려지며, 어떤 세부 증거는 snippet으로 남는다.

Figure 6: Complete case study of managed context using Compress, Rollback, Delete, Snippet

그림 6은 Context-ReAct가 실제 장기 검색 trajectory에서 어떻게 여러 operation을 조합하는지 보여 준다. 논문은 Compress로 해결된 하위 탐색을 축약하고, Rollback으로 비생산적인 branch를 접으며, Delete로 잡음을 제거하고, Snippet으로 핵심 evidence를 보존하는 흐름을 제시한다. 이 사례는 context management가 단일 요약기를 넘어 작업 메모리 편집 정책이라는 점을 강화한다.

Case study는 정량 결과를 보완한다. 성능 표만 보면 LongSeeker가 왜 더 안정적으로 탐색하는지 알기 어렵지만, managed context 예시는 어떤 정보가 어떤 이유로 남는지 관찰하게 해 준다. 논문은 이 구조가 장기 검색에서 불필요한 검색 반복을 줄이고, 중요한 근거를 다시 사용할 수 있게 만든다고 설명한다.

그림 4(a)의 plateau는 LongSeeker 논문에서 가장 중요한 진단 결과 중 하나다. 장기 검색에서 step 수가 늘어도 평균 context token이 계속 선형 증가하지 않고 약 15k 부근에서 안정화된다면, 모델은 매 step마다 전체 과거를 다시 읽는 대신 현재 과업에 필요한 working set만 유지하는 쪽으로 행동하고 있다고 볼 수 있다. 논문은 이를 256k context capacity의 작은 일부만 사용하는 상태로 설명한다. 이 관찰은 긴 window를 갖춘 모델도 실제 운영에서는 window 전체를 채우기보다 중요한 정보를 재배치하는 능력이 필요하다는 점을 보여 준다.

그림 4(b)의 operation distribution은 또 다른 단서를 준다. Skip과 Compress가 상대적으로 자주 쓰이고 Rollback과 Delete는 낮은 비율로 등장한다면, LongSeeker는 공격적으로 정보를 지우는 정책을 배웠다기보다 신중한 보존과 압축을 기본값으로 삼는다고 해석할 수 있다. 장기 검색에서는 초기에 무관해 보인 정보가 나중에 결정적 단서로 바뀔 수 있기 때문에, 무조건 많이 삭제하는 정책은 위험하다. 논문이 보고한 분포는 모델이 필요한 경우에만 branch 제거와 step 삭제를 수행하는 보수적 편집 정책을 학습했을 가능성을 시사한다.

Figure 5의 ablation은 Summary와 Discard-all이 왜 부족한지 설명한다. Summary는 overflow가 발생하거나 특정 시점이 되었을 때 긴 history를 하나의 요약으로 압축하는 방식이다. 이 방식은 토큰을 줄이지만 어떤 구간을 요약해야 하는지, 어떤 evidence는 원문으로 남겨야 하는지, 어떤 실패 branch는 구조적으로 접어야 하는지까지는 세밀하게 다루지 못한다. Discard-all은 더 과감하게 context를 초기화하지만, 이전 탐색에서 얻은 유효한 증거까지 사라질 수 있다. Context-ReAct는 두 극단 사이에서 조작 단위와 보존 해상도를 분리한다.

Case study가 필요한 이유도 여기에 있다. 장기 검색 과업에서 좋은 answer accuracy만 보면 에이전트가 어떤 과정을 거쳐 성공했는지 알기 어렵다. Figure 6과 Figure 7은 Compress, Rollback, Delete, Snippet이 한 trajectory 안에서 함께 쓰이는 예를 보여 준다. 어떤 구간은 요약되고, 어떤 실패 branch는 되돌려지며, 어떤 노이즈는 삭제되고, 어떤 핵심 근거는 발췌된다. 이 조합은 단일 memory compression algorithm보다 작업 메모리 편집 언어에 가깝다.

그렇지만 이 분석에는 후속 검증이 붙어야 한다. Compress가 만든 요약이 원문 evidence를 얼마나 충실히 보존했는지, Delete된 observation 안에 최종 답에 필요한 단서가 없었는지, Rollback이 실제 실패 branch만 접었는지, Snippet이 주변 문맥을 충분히 담았는지는 별도의 audit 없이는 확인하기 어렵다. 논문은 motivation 필드와 case study를 제공하지만, operation-level precision과 recall을 정량화하지는 않는다. 이 지점이 Context-ReAct를 실제 production search agent에 적용할 때 가장 먼저 확인해야 할 품질 gate다.

검증 질문	왜 필요한가	가능한 측정 방식
요약 충실도	Compress가 사실·숫자·조건을 바꾸면 후속 reasoning 전체가 틀어짐	요약 전후 entity, date, numeric fact, citation overlap 비교
삭제 안전성	Delete가 실제 evidence를 제거하면 답은 맞아도 재현성이 낮아짐	삭제 step을 복원했을 때 최종 답과 근거 경로 변화 측정
되돌리기 타당성	Rollback이 너무 빠르면 탐색 폭이 줄고, 너무 늦으면 비용이 커짐	branch별 answer contribution과 tool-call budget 절감량 분석
발췌 맥락	Snippet이 짧으면 정확한 문구는 남아도 의미 조건이 빠질 수 있음	snippet 주변 원문 window와 최종 인용 문장의 entailment 검사

이런 검증 표는 논문 결과를 낮게 보려는 목적보다, Context-ReAct가 실제로 유용해지는 조건을 분명히 하려는 목적에 가깝다. 장기 검색 에이전트가 사람 대신 웹을 읽고 보고서를 작성하려면, 최종 답의 정확도와 함께 어떤 evidence를 남겼고 어떤 부분을 버렸는지 설명할 수 있어야 한다. LongSeeker는 그 설명 가능성을 motivation과 meta-operation 형태로 시작했지만, production 단계에서는 source-level provenance와 삭제·요약 로그의 재검산이 붙어야 한다.

7. 한계점 및 향후 연구 방향: SFT-only 정책의 검증 과제

7.1 SFT-only 정책의 신뢰성과 데이터 의존성

논문은 LongSeeker를 Qwen3-30B-A3B에서 10k synthesized trajectories로 SFT했다고 보고한다. 이 설정은 효율적인 장점이 있지만, operation 선택의 품질이 teacher trajectory와 annotation pipeline의 품질에 크게 의존한다. 모델이 잘못된 teacher의 삭제 기준을 모방하면 중요한 evidence를 제거할 수 있고, 과도한 Compress를 배워 세부 근거를 잃을 수도 있다. 따라서 operation correctness는 답률과 별도로 평가되어야 한다.

또한 SFT는 관찰된 행동을 모방하는 데 강하지만, 긴 horizon에서 나중에 드러나는 오류를 반영해 이전 operation 선택을 수정하는 데에는 한계가 있다. 예를 들어 초기에는 불필요해 보였던 snippet이 후반 검증에서 결정적 증거가 될 수 있다. 논문은 operation의 효율성과 충실도 보장을 논하지만, 실제 agent run에서 특정 Delete나 Compress가 최종 실패에 어떤 인과적 영향을 주었는지 측정하는 것은 추가 연구가 필요하다.

7.2 비교 환경과 benchmark coverage

LongSeeker의 비교 표에는 폐쇄형 모델과 공개 검색 에이전트가 함께 들어 있다. 이 비교는 독자가 성능 위치를 빠르게 파악하는 데 유용하지만, proprietary/closed agents의 내부 검색 도구, context policy, sampling 조건, tool budget이 완전히 공개되지 않는 경우가 많다. 따라서 논문이 보고한 상대 순위는 중요한 참고치이지만, 동일한 infrastructure에서 모든 시스템을 재실행한 결과로 해석하기에는 제한이 있다.

벤치마크 측면에서도 장기 검색 과업은 질문 유형, 웹 환경, 언어, 시간성, 정답 검증 방식에 따라 난도가 크게 달라진다. 논문은 BrowseComp, BrowseComp-ZH, xbench-2505, GAIA-text를 통해 폭을 확보하지만, context operation이 어떤 유형의 질문에서 가장 잘 작동하는지 더 세밀한 분석이 가능하다. 예컨대 숫자 기반 fact verification, entity disambiguation, temporal tracking, multi-document contradiction resolution은 서로 다른 retention policy를 요구할 수 있다.

7.3 향후 연구 방향

향후 연구는 operation-level supervision을 더 정밀하게 만들 수 있다. 답이 맞았는지를 넘어 어떤 Compress가 원문 evidence를 충분히 보존했는지, 어떤 Rollback이 실제로 실패 branch를 제거했는지, 어떤 Delete가 noise와 useful clue를 구분했는지 평가해야 한다. 논문이 제시한 action layer는 이러한 세분화된 reward나 audit을 붙이기에 적합한 구조를 제공한다.

또 다른 방향은 검색 인프라와의 결합이다. Context-ReAct가 working context를 줄이더라도, 원문 evidence가 외부 workspace나 retrieval cache에 추적 가능하게 남아 있어야 재검증이 가능하다. 따라서 LongSeeker류 시스템은 browser log, citation store, snippet provenance, operation history를 함께 관리하는 방식으로 확장될 수 있다. 이렇게 하면 컨텍스트 효율과 검증 가능성 사이의 균형을 더 체계적으로 다룰 수 있다.

8. 내 해석: 약점 1 + 후속 제안 1

8.1 약점: SFT-only 10k trajectory와 비교 해석의 불확실성

내가 가장 크게 보는 약점은 LongSeeker가 SFT-only로 학습된 10k teacher-generated trajectory에 상당히 의존한다는 점이다. 논문은 Context-ReAct의 operation set을 설득력 있게 정의하지만, 실제로 어떤 상황에서 Delete가 안전하고 어떤 상황에서 Snippet이 필수인지에 대한 ground-truth는 답 정답률만으로 충분히 관찰되지 않는다. 특히 benchmark가 일부 sampled setting으로 운영되거나 200개 안팎의 평가 단위에 의존한다면, operation policy의 안정성을 일반화해 말하기 어렵다.

또한 GPT-5, Gemini-3.0-Pro, Claude-Opus-4.5, Seed-2.0-Pro 같은 proprietary/closed agents와의 비교는 유용하지만 조심해야 한다고 본다. 이 시스템들은 내부 context management, browsing stack, search ranking, tool retry policy가 공개되지 않을 가능성이 높다. 따라서 LongSeeker의 점수가 높거나 비슷한 구간은 분명 흥미롭지만, 그것이 오직 Context-ReAct만의 효과라고 단정하기보다 공개된 30B agent에서 재현 가능한 context action layer의 효과로 읽는 것이 더 안전하다.

기존 wiki 맥락과 연결하면, long-horizon-agent-training(post 253)은 horizon bottleneck을 주로 훈련 trajectory와 장기 보상 문제로 봤고, agent-web-search-infrastructure(post 225)는 검색 도구와 브라우징 스택의 안정성을 다뤘다. deep-research-sandbox-evaluation(post 180/225)과 workspace-agent-benchmark(draft for 2605.03596)는 평가·샌드박스·작업공간 문제를 강조했다. 나는 LongSeeker가 이 흐름을 search agent runtime의 working context 관리 문제로 옮겼다는 점에서 의미가 크다고 본다.

8.2 후속 제안: provenance audit와 operation-level reward

내 후속 제안은 Context-ReAct operation마다 provenance / ground-truth evidence retention audit를 붙이는 것이다. Compress가 만든 summary에는 어떤 원문 observation과 snippet이 근거인지 링크해야 하고, Delete나 Rollback은 제거된 정보 중 최종 답에 필요한 evidence가 있었는지 사후 점검해야 한다. 이렇게 하면 단순히 답이 맞았는지를 넘어, 답을 맞히는 동안 어떤 context surgery가 안전했는지 추적할 수 있다.

제안 요소	구체적 구현	검증 질문	기대 효과
Compress provenance	summary sentence마다 source observation id 연결	요약이 원문 evidence를 왜곡하지 않았는가	abstractive compression hallucination 감소
Snippet retention audit	최종 답 근거 span이 working context 또는 external store에 남았는지 확인	결정적 숫자·이름·날짜가 exact하게 보존되었는가	faithfulness와 citation 품질 개선
Delete / Rollback safety	제거된 branch를 사후 replay하여 missed evidence 여부 측정	버린 정보가 실제로 불필요했는가	과도한 pruning으로 인한 실패 감소
Human review checkpoint	고위험 Delete와 large-range Compress에만 사람 검수 queue 부여	어느 operation이 사람 검수를 가장 많이 필요로 하는가	운영 비용을 제한하면서 안전성 강화
Operation-level RL	정답률, token cost, evidence retention score를 함께 reward화	어떤 operation sequence가 장기 성공률을 높이는가	SFT imitation을 넘어 context policy를 직접 최적화

나는 이 제안이 AutoResearchBench나 DR3-Eval 계열의 평가·검색 문제와 LongSeeker의 내부 context orchestration을 연결하는 다리라고 본다. 평가 벤치마크는 최종 답과 근거를 요구하지만, agent 내부에서는 어떤 근거가 언제 사라졌는지 알기 어렵다. operation-level audit와 reward를 붙이면 LongSeeker식 action layer가 단순한 토큰 절감 장치를 넘어, 검증 가능한 장기 검색 운영체계로 확장될 수 있다.

이전에 정리한 long-horizon-agent-training 관점에서는 horizon length가 길어질수록 sparse reward와 exploration 문제가 커진다는 점이 핵심이었다. LongSeeker는 같은 장기 지평 문제를 학습 알고리즘의 관점보다 runtime context 운영의 관점에서 다시 자른다. 장기 과업이 어려운 이유가 좋은 action을 찾기 어려운 데 더해, 이미 찾은 정보와 실패한 정보가 같은 입력 표면에 뒤섞여 다음 action 선택을 방해하기 때문이라는 설명을 덧붙인다.

agent-web-search-infrastructure와 deep-research-sandbox-evaluation 페이지와 연결해 보면, 이 논문은 검색 API나 평가 코퍼스의 바깥쪽보다 에이전트 내부 working memory의 안쪽을 다룬다. DR3-Eval과 AutoResearchBench 계열이 검색 과업을 어떻게 재현 가능하게 평가할지 묻는다면, LongSeeker는 그 평가장에서 agent가 자기 관찰을 어떻게 정리해야 할지 묻는다. 그래서 이 논문은 benchmark 논문이라기보다 검색 에이전트 runtime policy 논문에 가깝다.

workspace-agent-benchmark와의 연결도 있다. Workspace-Bench는 파일 의존성이 많은 업무공간에서 agent가 필요한 파일을 찾고 산출물을 만들어야 하는 문제를 다룬다. 이런 환경에서는 검색 결과와 더불어 파일 경로, 중간 산출물, 실패한 편집 시도, 검증 로그가 모두 context에 들어올 수 있다. LongSeeker의 operation set은 웹 검색 과업에서 출발했지만, Compress로 오래된 조사 로그를 요약하고, Snippet으로 결정적 파일 경로나 수치를 보존하며, Rollback으로 잘못된 분석 branch를 접는 식으로 workspace agent에도 응용될 수 있다.

내가 이 논문에서 가장 조심해서 보는 부분은 operation decision의 ground truth다. 최종 답이 맞았다고 해서 중간 context surgery가 모두 안전했다고 볼 수는 없다. 운 좋게 필요한 evidence가 남았을 수도 있고, 필요 없는 정보를 지웠다고 생각했지만 실제로는 다른 질문에서는 중요한 단서였을 수도 있다. 따라서 LongSeeker식 접근을 서비스형 deep research agent에 붙인다면, answer-level accuracy와 별도로 operation log를 샘플링해 사람이 검사하는 workflow를 먼저 둘 것 같다.

내가 확장한다면 첫 번째로 붙일 것은 evidence retention audit다. 각 Compress 전후에 보존해야 할 entity, 날짜, 숫자, URL, quote를 자동 추출하고, 최종 답에서 실제 사용된 evidence가 어떤 operation을 거쳐 살아남았는지 추적한다. 이렇게 하면 Context-ReAct가 단순히 토큰을 줄였는지, 또는 답에 필요한 증거를 안전하게 남기면서 토큰을 줄였는지를 구분할 수 있다. 특히 Snippet의 역할은 이런 audit에서 더 명확해진다.

두 번째 확장 방향은 operation-level reward다. 현재 논문은 10k teacher-generated trajectories를 SFT하는 방식이므로 teacher의 context editing 습관을 모방한다. 다음 단계에서는 final answer correctness, context token budget, evidence retention, deleted-branch harmlessness를 함께 보상으로 두고, operation 선택 자체를 RL 또는 preference learning 대상으로 만들 수 있다. 이때 reward가 너무 토큰 절감에 치우치면 위험하므로, 원문 evidence 보존과 citation consistency를 함께 넣어야 한다.

9. 결론: 큰 창보다 관리 가능한 작업 메모리

LongSeeker 논문은 장기 검색 에이전트의 핵심 병목을 컨텍스트 창 크기의 부족보다 컨텍스트 운영 정책의 부재로 재정의한다. 표준 ReAct가 모든 reasoning trace와 observation을 append-only 방식으로 누적하는 반면, Context-ReAct는 Skip, Compress, Rollback, Snippet, Delete를 통해 working context를 상황별로 재구성한다. 이 발상은 memory를 수동 저장소를 넘어 agent가 조작하는 action space로 바꾼다.

실험적으로 논문은 LongSeeker가 10k synthesized trajectories 기반 SFT만으로 BrowseComp 61.5, BrowseComp-ZH 62.5, xbench-2505 78.0, GAIA-text 77.7을 달성했다고 보고한다. 또한 context growth curve, operation distribution, ablation study를 통해 이 성능이 단순 요약이나 전체 폐기보다 정교한 context orchestration과 연결된다는 근거를 제시한다. 특히 약 15k token plateau는 runtime resource 측면에서 중요한 결과다.

이 논문의 실용적 메시지는 명확하다. 장기 검색 에이전트를 강하게 만들려면 더 긴 context window와 더 많은 검색 call만으로는 부족하다. 에이전트가 스스로 무엇을 남기고, 무엇을 줄이며, 무엇을 되돌릴지 결정해야 한다. LongSeeker는 이 결정을 학습 가능한 structured output으로 만든 첫 번째 강한 사례 중 하나이며, 향후 provenance audit, human review checkpoint, operation-level RL과 결합될 때 더 신뢰할 수 있는 long-horizon search agent로 발전할 여지가 크다.

9.1 운영 관점에서 보는 컨텍스트 오케스트레이션

LongSeeker의 설계는 실제 운영 환경에서 장기 검색 에이전트를 배포할 때 어떤 로그를 남겨야 하는지에 대한 힌트도 제공한다. 단순한 conversation history만 저장하면 모델이 어떤 정보를 왜 버렸는지 알 수 없다. 반대로 Context-ReAct식 로그는 검색 쿼리, 관찰, 요약, 삭제, 되돌리기, 원문 snippet을 모두 구분해 남긴다. 논문이 직접 운영 시스템을 완성했다고 주장하는 것은 아니지만, 이 구조는 디버깅 가능한 agent trace를 만드는 데 유리한 출발점이다.

예를 들어 장기 검색 실패를 분석할 때 기존 ReAct 로그에서는 어느 시점부터 오류가 누적되었는지 찾기 어렵다. 모든 observation이 같은 형식으로 이어져 있기 때문이다. Context-ReAct 로그에서는 특정 Compress가 근거를 과도하게 축약했는지, 특정 Delete가 결정적 clue를 제거했는지, 특정 Rollback이 실제로는 유망한 branch를 버렸는지 더 직접적으로 조사할 수 있다. 이는 모델 평가를 final answer accuracy에서 operation-level failure analysis로 확장할 수 있게 한다.

또한 LongSeeker가 보여 주는 plateau 현상은 비용 관리 측면에서 실용적이다. 긴 컨텍스트 창을 가진 모델을 사용하더라도 매 step마다 100k 이상의 history를 넣는 방식은 latency와 비용을 크게 키운다. Context-ReAct는 필요한 evidence를 잃지 않는 범위에서 working set을 약 15k 토큰 수준으로 유지하려는 방향을 제시한다. 논문은 이 점을 통해 장기 검색의 병목이 최대 context length만이 아니라 활성 작업 메모리의 품질이라고 설명한다.

이 관점은 multi-agent search나 deep research product에도 확장될 수 있다. 여러 에이전트가 병렬로 검색한 뒤 결과를 합치는 시스템에서는 각 에이전트의 raw trace를 전부 중앙 컨텍스트에 넣기 어렵다. Context-ReAct식 operation log는 각 branch의 요약, 핵심 snippet, 폐기 이유, 보존 이유를 표준화할 수 있으므로, 상위 coordinator가 불필요한 세부 trace를 모두 읽지 않고도 근거 구조를 파악하도록 돕는다. 논문이 제시한 원자 operation은 이런 계층형 검색에도 비교적 자연스럽게 맞는다.

운영 체크포인트	Context-ReAct에서 관찰할 로그	실패 시 의심할 원인	보강 방향
Evidence drift	Compress summary와 원문 snippet의 대응	요약 과정에서 숫자나 조건이 변형됨	source-linked summary와 citation validation 추가
Premature pruning	Delete와 Rollback의 대상 step	후반에 필요한 clue를 너무 일찍 제거함	high-risk pruning에는 delayed deletion 또는 quarantine store 적용
Context bloat	Skip 비율과 token growth curve	모델이 압축 가능한 history를 계속 보존함	Compress trigger와 cost-aware reward를 추가
Branch confusion	Rollback motivation과 이후 query	버린 가설과 새 가설이 섞여 reasoning drift 발생	rollback note에 abandoned assumption과 retained insight를 분리 기록

이 표와 같은 운영 체크리스트는 LongSeeker의 연구적 아이디어를 실제 서비스 품질 관리로 옮길 때 필요하다. 논문은 atomic operation의 정의와 성능 결과를 중심으로 설명하지만, 배포 단계에서는 각 operation이 downstream answer에 미친 영향을 추적해야 한다. 특히 법률, 의료, 금융처럼 evidence chain이 중요한 도메인에서는 token cost 절감보다 무엇을 왜 버렸는지 설명 가능해야 하는 요구가 더 클 수 있다.

9.2 연구적 가치와 일반화 가능성

LongSeeker의 연구적 가치는 context management를 heuristic preprocessing에서 학습 가능한 행동 공간으로 이동시킨 데 있다. 기존에는 memory를 줄이는 방법이 외부 규칙으로 구현되는 경우가 많았다. 예를 들어 일정 길이가 넘으면 오래된 메시지를 버리거나, 일정 주기로 전체를 요약하는 식이다. Context-ReAct는 이 결정을 모델 출력 안으로 가져와, 과업 상태와 현재 reasoning에 따라 다른 조작을 선택하게 만든다.

이 접근은 검색 에이전트 밖에서도 적용 가능성이 있다. 코드 수정 에이전트는 긴 파일 diff와 test log를 다루고, 데이터 분석 에이전트는 여러 실험 결과와 notebook 상태를 추적하며, 연구 보조 에이전트는 수많은 논문과 인용 근거를 비교한다. 이 모든 환경에서 append-only trace는 금방 비대해진다. 따라서 Skip, Compress, Rollback, Snippet, Delete 같은 operation은 웹 검색뿐 아니라 workspace agent의 장기 작업 메모리에도 적용할 수 있는 일반적 인터페이스로 볼 수 있다.

다만 일반화를 위해서는 operation semantics가 도메인별로 구체화되어야 한다. 웹 검색의 Snippet은 문서 span을 의미하지만, 코드 에이전트의 Snippet은 함수 정의나 failing stack trace일 수 있다. Rollback도 검색 branch를 되돌리는 동작에서 코드 patch series를 되돌리는 동작으로 바뀔 수 있다. 논문이 제안한 다섯 operation은 충분히 추상적이지만, 실제 도메인에서는 evidence unit, state unit, rollback boundary를 명확히 정의해야 한다.

또한 Context-ReAct는 장기 에이전트 학습에서 credit assignment를 더 세밀하게 만들 수 있다. 최종 답이 틀렸을 때 검색 쿼리 생성이 문제였는지, 도구 관찰이 부족했는지, Compress가 핵심 조건을 잃었는지, Delete가 너무 공격적이었는지 분리해 볼 수 있기 때문이다. 논문이 보고한 ablation은 이 방향의 첫 증거이고, 이후 연구는 operation sequence 자체에 대한 평가와 보상을 설계함으로써 더 강한 agent training loop를 만들 수 있다.

결국 LongSeeker가 던지는 질문은 단순하다. 에이전트가 오래 생각하고 오래 검색해야 한다면, 모든 생각을 그대로 다음 입력에 넣는 것이 정말 최선인가. 논문은 그렇지 않다고 답한다. 장기 탐색에서 필요한 것은 큰 노트북 하나보다, 현재 과업에 맞춰 요약본, 원문 증거, 폐기 기록, 되돌린 branch를 구분해 정리하는 탄력적 작업대다. 이 작업대를 학습 가능한 출력 형식으로 만든 것이 Context-ReAct의 가장 중요한 메시지다.

9.3 읽을 때의 핵심 포인트

LongSeeker를 읽을 때 가장 먼저 분리해야 할 것은 최종 답률과 컨텍스트 정책의 품질이다. 답률은 여러 요인의 합성 결과다. base model의 언어 능력, 검색 엔진 품질, browsing interface, query rewriting, stopping criterion, answer verifier가 모두 영향을 준다. 반면 Context-ReAct의 고유한 가치는 어느 step을 어떤 해상도로 유지했는지에 있다. 따라서 이 논문은 성능표와 함께 operation distribution, context growth curve, case study를 함께 읽어야 설계 의도가 보인다.

두 번째 포인트는 Compress의 표현 완전성 주장을 과대해석하지 않는 것이다. 논문은 Compress 하나로 임의의 context rewriting을 표현할 수 있다고 말하지만, 이것은 수학적 표현 가능성에 관한 주장이다. 실제 장기 검색에서는 요약 문자열을 생성하는 순간 hallucination과 omission이 발생할 수 있다. 그래서 Snippet, Delete, Rollback, Skip이 별도의 이름을 갖는 것이 중요하다. 이 operation들은 모델에게 어떤 종류의 변환을 수행하는지를 더 명확히 지시한다.

세 번째 포인트는 Rollback과 Delete의 낮은 빈도를 실패라기보다 보수적 설계의 신호로 볼 수 있다는 점이다. 장기 검색에서 중요한 증거를 잘못 버리면 복구 비용이 크다. 따라서 논문이 보고한 낮은 Rollback/Delete 비율은 에이전트가 무리하게 pruning하지 않고, 주로 Skip과 Compress로 context size를 안정화한다는 해석을 가능하게 한다. 이 균형은 token cost와 evidence retention 사이의 trade-off를 다루는 방식이다.

네 번째 포인트는 LongSeeker가 단순한 long-context 모델을 넘어 elastic context 모델이라는 점이다. 긴 context window가 있다고 해서 작업 메모리가 좋은 것은 아니다. 필요한 근거가 긴 입력 속에 묻히면 모델은 오히려 더 불안정하게 추론할 수 있다. LongSeeker는 capacity를 끝까지 채우는 대신, 현재 과업에 필요한 정보만 다른 해상도로 남기는 방향을 취한다. 이 점이 Figure 4(a)의 plateau와 메인 성능 결과를 연결한다.

마지막 포인트는 이 논문이 장기 에이전트 설계에서 메모리 조작의 문법을 제공한다는 것이다. 기존 시스템도 내부적으로 요약하거나 버릴 수 있지만, 그 행동이 모델 출력의 명시적 구조로 드러나지 않으면 학습, 평가, 감사가 어렵다. Context-ReAct는 다섯 operation을 공통 문법으로 제시하여, 향후 다른 모델이나 도메인에서도 context policy를 비교하고 개선할 수 있는 발판을 마련한다.

특히 실무 독자는 LongSeeker의 score를 볼 때 context budget accounting을 함께 상상해야 한다. 같은 정답률이라도 매 step 입력 길이가 계속 늘어나는 에이전트와 일정한 working context를 유지하는 에이전트의 운영 비용은 다르다. 논문이 보여 준 약 15k plateau는 모델 호출 비용, 응답 지연, 실패 재시도 비용을 모두 줄일 수 있는 방향을 암시한다. 이런 측면에서 Context-ReAct는 성능 향상 기법이면서 동시에 장기 검색 시스템의 비용 제어 기법이다.

또한 이 논문은 agent trace를 사람이 읽을 수 있는 형태로 만드는 문제와도 연결된다. 긴 ReAct 로그는 사람이 검토하기 어렵고, 요약만 남기면 근거가 사라진다. Context-ReAct는 summary와 snippet, rollback note, deletion motivation을 나누어 남길 수 있으므로, 사후 검수자가 어떤 결정이 안전했는지 판단하기 쉽다. 향후 평가가 final answer에서 process audit로 이동할수록 이런 구조적 trace의 가치는 더 커질 것이다.

따라서 LongSeeker의 가장 큰 시사점은 에이전트가 긴 과업을 수행할 때 기억을 많이 갖는 것과 기억을 잘 다루는 것이 다르다는 사실이다. 논문은 후자를 모델의 명시적 행동으로 끌어올렸고, 그 결과를 수치와 분석 그림으로 제시한다. 이후 연구가 이 action layer를 더 엄밀하게 검증한다면 장기 검색 에이전트의 표준 구성 요소가 될 가능성이 있다.

이런 이유로 LongSeeker는 장기 검색 에이전트 논의에서 검색 능력, 추론 능력, 작업 메모리 운영 능력을 분리해 보게 만드는 기준점으로 남는다.

결과적으로 이 논문은 장기 검색의 성패를 얼마나 찾았는가보다 무엇을 작업 기억에 남겼는가라는 질문으로 다시 정렬한다.

그래서 이 작업은 모델 규모 경쟁보다 장기 실행 상태 관리 경쟁에 더 가깝다.

이 차이가 핵심이다.

10. 요약 정리: LongSeeker를 읽을 때 남길 핵심 항목

• 문제의식: 논문은 ReAct식 append-only context가 장기 검색에서 비용 증가, 오류 누적, context overflow를 유발한다고 서술한다.
• 핵심 제안: Context-ReAct는 reasoning, context meta-operation, tool use를 한 루프에서 공동 생성하여 working context를 동적으로 재구성한다.
• Operation set: Skip, Compress, Rollback, Snippet, Delete 다섯 atomic operation이 정보 보존, 요약, 되돌리기, 원문 추출, 잡음 제거를 담당한다.
• 이론적 주장: 논문은 Compress가 expressively complete하다고 설명하며, 나머지 operation은 효율성과 충실도 측면의 실용적 보장을 제공한다고 본다.
• 모델 구성: LongSeeker는 Qwen3-30B-A3B를 기반으로 10k synthesized Context-ReAct trajectories에서 SFT한 30B급 장기 검색 에이전트다.
• 주요 수치: LongSeeker는 BrowseComp 61.5, BrowseComp-ZH 62.5, xbench-2505 78.0, GAIA-text 77.7을 보고한다.
• 추가 분석: 평균 컨텍스트 토큰 수는 약 15k에서 plateau를 형성하며, 모든 meta-operation이 사용되고 Skip과 Compress가 가장 자주 등장한다고 논문은 보고한다.
• Ablation: 동일 base와 step budget 아래에서 Context-ReAct가 Summary와 Discard-all보다 높은 성능을 보이며, 세밀한 context orchestration의 효과를 뒷받침한다.
• 주의점: SFT-only 10k teacher-generated trajectory, sampled benchmark, closed agents와의 비교 조건은 결과 해석에서 제한으로 남는다.
• 후속 방향: provenance audit, ground-truth evidence retention check, 사람 검수 지점, operation-level RL을 결합하면 context operation의 안전성과 재현성을 더 강화할 수 있다.