GrepSeek: Training Search Agents for Direct Corpus Interaction Review

0. Introduction

Paper link

Code link

Model link

GrepSeek은 search agent 논문이지만, 단순히 RAG agent의 retrieval policy를 조금 더 잘 학습시키는 논문으로 읽으면 핵심을 놓치기 쉽다. 이 논문의 문제의식은 retrieval model을 더 잘 고르는 데 있지 않다. 오히려 질문은 더 원초적이다. 꼭 pre-computed index와 top-k document retrieval을 통해서만 corpus에 접근해야 하는가?

GrepSeek은 이 질문에 Direct Corpus Interaction, DCI라는 방향으로 답한다. Agent가 dense retriever나 BM25 retriever에 query를 던지는 대신, raw text corpus를 하나의 search environment로 보고 rg, grep, head, awk, sed, sort, uniq 같은 shell command를 실행해 evidence를 찾는다. 즉 retrieval을 black-box ranking call이 아니라, agent가 직접 작성하고 실행하는 search program으로 바꾼다.

흥미로운 점은 이 논문이 DCI를 prompt engineering으로 끝내지 않는다는 것이다. 최근 DCI 계열 접근은 Claude 같은 strong proprietary model이 inference time에 shell command를 잘 짜도록 prompting하는 방식으로도 가능하다. 하지만 GrepSeek은 compact open-weight model인 Qwen3.5-9B를 실제로 학습시켜 corpus interaction skill을 policy 안에 넣으려 한다. 그래서 이 논문은 retrieval paper이면서 동시에 tool-use RL paper이고, agent serving system paper이기도 하다.

한 줄 요약: GrepSeek은 pre-computed retrieval index 대신 raw corpus에 직접 shell command를 실행하는 DCI search agent를 만들고, answer-aware Tutor와 answer-blind Planner로 만든 cold-start trajectory에 SFT를 수행한 뒤 GRPO로 search behavior를 개선하는 논문이다.

이 논문을 지금 볼 가치가 있는 이유는 다음과 같다.

• Agentic search에서 retrieval interface 자체를 다시 묻는다.
• Dense embedding retriever가 약한 exact entity, rare string, multi-hop bridge entity 탐색을 shell command interface로 다룬다.
• Naive RL이 쉽게 망가지는 corpus interaction task를 cold-start SFT + GRPO로 안정화하는 recipe를 제시한다.
• Sharded-parallel execution engine, persistent daemon, released model, released data까지 있어 실제 system 관점에서 읽을 부분이 많다.
• Internal corpus, document AI, code search, log search, enterprise RAG에 적용할 수 있는 설계 아이디어가 있다.

이 논문의 핵심 메시지는 간단하다. Search agent의 병목은 reasoning model만이 아니라 corpus와 agent 사이의 interface일 수 있다. Top-k retriever는 편하고 빠르지만, agent가 원하는 search operation을 항상 충분한 해상도로 표현해주지는 못한다. GrepSeek은 그 interface를 shell command로 넓힌다.

1. Problem Setting

1-1. Problem definition

이 논문이 겨냥하는 문제는 knowledge-intensive QA에서 search agent가 evidence를 찾는 방식이다.

일반적인 RAG agent는 대략 다음처럼 동작한다.

1. Agent가 natural language query나 keyword query를 만든다.
2. Retriever가 pre-computed index에서 top-k document를 반환한다.
3. Agent가 반환된 document를 읽고 다음 query를 만들거나 final answer를 생성한다.

이 구조는 매우 실용적이지만, retrieval interface가 너무 고정되어 있다. Retriever는 보통 document 또는 chunk 단위로 score를 매긴다. 그래서 agent는 corpus 안에서 정확히 어떤 string을 찾고 싶은지, 어떤 조건을 순차적으로 걸고 싶은지, 어떤 entity alias를 배제하고 싶은지, 어떤 line을 먼저 truncate하고 싶은지를 직접 제어하기 어렵다.

GrepSeek은 이 문제를 DCI로 바꾼다. Corpus를 하나의 environment로 보고, agent가 executable shell command를 action으로 내보내도록 한다. 예를 들어 agent는 아래와 같은 식으로 search를 수행할 수 있다.

rg -F "entity A" corpus | rg -F "entity B" | head -n 20

이 command는 단순한 top-k retrieval이 아니다. Exact matching, cascaded filtering, truncation, counting, sorting 같은 operation을 agent가 직접 조합한다. 특히 multi-hop QA에서는 중간 entity를 찾고, 그 entity를 다음 search의 anchor로 쓰는 과정이 필요하다. 이런 과정을 retriever query 하나로 표현하기는 어렵다.

1-2. Why previous approaches are insufficient

기존 search agent 접근은 크게 두 방향으로 볼 수 있다.

첫째, retriever를 그대로 두고 agent의 query planning을 개선하는 방식이다. Search-R1, Search-O1, IRCoT 계열 접근은 agent가 언제 search하고 어떤 query를 던질지를 더 잘 학습하게 만든다. 하지만 corpus access interface는 여전히 retriever가 반환하는 top-k list다.

둘째, strong proprietary model을 이용해 raw corpus를 직접 탐색하게 하는 방식이다. 이 방식은 DCI의 장점을 보여주지만, inference time prompting에 크게 의존한다. Strong closed model이 매 query마다 긴 search trajectory를 생성해야 하므로 cost, latency, reproducibility 문제가 생긴다.

GrepSeek이 보는 병목은 여기에 있다.

• Index-based retriever는 exact lexical constraints, rare entity, symbolic pattern, bridge entity chaining에 약할 수 있다.
• Prompt-only DCI는 strong proprietary model 의존도가 크고, compact model로 바로 이전하기 어렵다.
• Naive RL로 shell command를 바로 학습시키면 overly broad command, excessive context retrieval, unstable trajectory 문제가 생긴다.
• Shell-based search는 빠르게 만들 수 있지만, large corpus에서 sequential execution만 쓰면 interactive agent에 부담이 크다.

정리하면 GrepSeek은 retrieval algorithm 하나를 바꾸는 논문이 아니다. Search agent가 corpus와 상호작용하는 action space, training data generation, RL objective, execution engine을 한 번에 다루는 논문이다.

2. Core Idea

2-1. Main contribution

GrepSeek의 핵심 기여는 세 가지로 볼 수 있다.

1. Direct Corpus Interaction agent
   • Agent가 retriever API 대신 shell command를 action으로 생성한다.
   • Corpus는 line-oriented text collection으로 노출되고, command output이 observation으로 돌아온다.
   • Action space는 rg, grep, find, sed, awk, head, tail, cat, ls, wc, sort, cut, uniq, tr 등을 포함한다.
2. Cold-start SFT + GRPO training pipeline
   • Naive RL은 corpus-wide command search에서 불안정하므로, 먼저 synthetic trajectory로 stable search behavior를 만든다.
   • Answer-aware Tutor가 gold answer를 알고 backward evidence chain을 만든다.
   • Answer-blind Planner가 forward causal trajectory를 작성한다.
   • 이후 Qwen3.5-9B policy를 SFT하고, GRPO로 task-oriented search behavior를 개선한다.
3. Semantics-preserving sharded-parallel execution engine
   • Shell command를 corpus shard에 병렬로 실행하되, sequential execution과 byte-exact equivalence를 유지한다.
   • Compatible pipeline은 parallel execution으로 빠르게 돌리고, unsafe pipeline은 sequential fallback으로 처리한다.
   • Persistent daemon과 memory-mapped search primitive를 이용해 tool latency를 줄인다.

2-2. Design intuition

이 논문의 설계 직관은 꽤 현실적이다.

Retrieval은 단순히 relevant document를 고르는 문제가 아니다. Agentic search에서는 evidence를 찾는 과정 자체가 reasoning의 일부가 된다. Multi-hop question에서는 첫 번째 evidence가 다음 search term을 결정하고, 그 결과가 다시 다음 bridge entity를 만든다. 이런 setting에서는 retrieval result의 ranking score만큼이나, agent가 search space를 어떻게 조작할 수 있는지가 중요하다.

DCI는 이 조작 가능성을 높인다. Agent가 exact string search를 하고, 결과를 다시 filter하고, 너무 긴 output은 head로 자르고, 필요하면 wc -l로 count할 수 있다. 이건 vector DB query보다 투박해 보이지만, entity ambiguity나 rare phrase가 핵심인 문제에서는 오히려 더 강한 inductive bias가 된다.

다만 shell command action space는 자유도가 너무 높다. 아무런 initialization 없이 RL을 걸면 agent는 지나치게 넓은 command를 만들거나, 너무 많은 context를 읽어오거나, format을 망가뜨릴 수 있다. 그래서 GrepSeek은 RL 이전에 good trajectory prior를 만든다. 이 점에서 GrepSeek은 “shell command를 쓸 수 있다”보다 “shell command를 안정적으로 학습 가능한 behavior로 만든다”가 더 중요한 논문이다.

3. Architecture / Method

3-1. Overview

Item	Description
Goal	Search agent가 raw text corpus에서 evidence를 직접 찾고 조합하도록 학습
Corpus interface	Pre-computed index가 아니라 shell command 기반 DCI
Base policy	Qwen3.5-9B
Teacher side	Qwen3.5-27B Tutor and Planner
Training recipe	Cold-start trajectory generation -> SFT -> GRPO
Reward	Token-level F1 with format gate
Execution engine	Sharded-parallel shell execution with sequential-equivalent output
Main use case	Open-domain QA, multi-hop evidence aggregation, exact lexical search

3-2. Module breakdown

1) DCI search agent

GrepSeek agent는 ReAct-style loop 안에서 동작한다.

각 turn에서 model은 reasoning trace와 action을 생성한다. Tool action은 shell command이고, environment는 command를 corpus 위에서 실행한 뒤 output을 observation으로 돌려준다. Model이 충분한 evidence를 모았다고 판단하면 final answer를 낸다.

논문에서 중요한 점은 corpus가 하나의 logical file처럼 보인다는 것이다. 실제 내부 구현은 여러 shard와 file로 나뉘어 있을 수 있지만, agent 입장에서는 unified corpus interface를 본다. 이 단순한 abstraction 덕분에 model은 filesystem layout보다 search command composition에 집중할 수 있다.

실제로 agent가 주로 쓰는 primitive는 매우 단순하다.

• rg 또는 grep으로 exact search를 한다.
• rg -F로 regex가 아니라 fixed-string matching을 자주 쓴다.
• head -n K로 observation size를 제한한다.
• 여러 rg를 pipe로 연결해 cascaded filtering을 수행한다.

이 구조는 vector retrieval보다 덜 semantic하지만, 훨씬 더 controllable하고 interpretable하다.

2) Answer-aware Tutor

Cold-start data generation의 첫 단계는 backward phase다.

Tutor는 gold answer를 알고 있다. 이 때문에 그냥 answer를 query로 검색하면 data leakage가 생긴다. GrepSeek은 이를 막기 위해 target entity와 alias를 command에서 금지하는 answer-leak rule을 둔다. Tutor는 target answer를 직접 쓰지 않고도 evidence를 찾는 command를 만들어야 한다.

Backward phase의 장점은 verification이다. Gold answer가 있으므로, Tutor는 어떤 document가 target answer를 실제로 support하는지 확인할 수 있다. Multi-hop question에서는 final answer에서 이전 bridge entity로 거슬러 올라가며 evidence chain을 만든다. 이렇게 하면 random search trajectory보다 훨씬 안정적인 support path를 만들 수 있다.

3) Answer-blind Planner

Backward evidence chain은 verification에는 좋지만, 그대로 학습시키면 inference-time behavior와 맞지 않는다. 실제 agent는 gold answer를 모른다. 그래서 GrepSeek은 verified chain을 forward order로 뒤집고, answer-blind Planner가 현재까지 관측한 history만 보고 reasoning과 command를 생성하게 한다.

여기서 Tutor는 Planner의 reasoning을 constrained하게 align한다. 핵심은 future evidence를 몰래 쓰지 않으면서, verified command가 자연스럽게 나오도록 reasoning trace를 정리하는 것이다. 마지막에는 judge가 trajectory의 causal consistency와 logical consistency를 검사한다.

이 설계는 꽤 중요하다. 많은 synthetic trajectory generation은 정답을 알고 만든 search path가 inference-time agent에게 불가능한 hint를 포함할 수 있다. GrepSeek은 answer-aware verification과 answer-blind forward assembly를 분리해 이 문제를 줄인다.

4) SFT initialization

GrepSeek은 10,000개의 cold-start trajectory를 만든다. Training source는 NQ와 HotpotQA의 balanced mixture다. Tutor와 Planner는 Qwen3.5-27B를 사용하고, policy model은 Qwen3.5-9B다.

SFT의 목적은 final answer accuracy를 바로 극대화하는 것만이 아니다. 더 중요한 목적은 policy가 valid tool protocol, concise command, causally grounded search behavior를 먼저 배우게 하는 것이다. 논문은 SFT 없이 바로 RL을 걸면 broad retrieval, huge context, memory instability 같은 문제가 발생한다고 설명한다.

SFT stage에서 학습되는 것은 low-level search syntax에 가깝다.

• 어떻게 rg와 head를 조합할지
• 언제 output을 줄일지
• 어떻게 command format을 지킬지
• 어떤 식으로 evidence observation을 다음 action에 반영할지

이 initialization이 있어야 이후 GRPO가 higher-level search strategy를 다듬을 수 있다.

5) GRPO optimization

SFT 이후에는 GRPO로 policy를 optimize한다. Reward는 token-level F1 기반 correctness reward와 format gate로 구성된다. Format gate는 trajectory가 think, tool_call, tool_response, answer 구조를 제대로 지켰는지 확인하고, format이 깨지면 learning signal을 차단한다.

이 reward design은 단순하지만 실용적이다. Search agent RL에서 format violation은 치명적이다. Tool call이 조금만 깨져도 environment interaction이 망가지고, answer reward와 search behavior 사이의 credit assignment도 흐려진다. GrepSeek은 correctness reward를 주되, structural validity를 gate로 강하게 묶는다.

GRPO는 같은 query에 대해 여러 trajectory를 sample하고, group 내부 relative advantage를 계산한다. 이렇게 하면 explicit critic 없이도 같은 question에 대해 더 좋은 search behavior를 강화할 수 있다.

6) Sharded-parallel execution engine

DCI가 실용적이려면 shell search가 충분히 빨라야 한다. 단일 large corpus file 위에서 sequential command를 반복 실행하면 interactive agent latency가 커진다.

GrepSeek은 corpus를 line-aligned shard로 나누고, command pipeline이 shard-independent인지 보수적으로 판정한다. 안전하게 parallelizable한 command는 shard별로 실행한 뒤 output을 merge한다. 안전하지 않거나 global state에 의존하는 pipeline은 sequential execution으로 fallback한다.

Pipeline 처리 방식은 대략 다음과 같이 볼 수 있다.

Case	Execution idea
Stateless filtering	Shard별 실행 후 shard order로 concat
head -n K ending	Shard별 local head 후 global head
wc -l ending	Shard별 count를 sum
sort plus head	Shard별 top output을 deterministic merge
Unsafe pipeline	Original corpus에서 sequential fallback

이 engine의 핵심은 speed보다 correctness다. Search output이 sequential shell command와 다르면 agent가 다른 observation을 보게 되고, training과 inference의 semantics가 바뀐다. GrepSeek은 byte-exact equivalence를 유지하는 범위에서만 parallelism을 적용한다.

4. Training / Data / Recipe

4-1. Data

실험은 2018 Wikipedia dump를 corpus로 사용한다. 논문과 repository 설명 기준 corpus는 21M passages이고, raw corpus size는 약 14GB다.

Training과 evaluation split은 다음처럼 읽을 수 있다.

Dataset	Role	Note
NQ	SFT and RL train, evaluation	Single-hop retrieval dynamics
HotpotQA	SFT and RL train, evaluation	Multi-hop reasoning dynamics
TriviaQA	OOD evaluation	Single-hop QA
PopQA	OOD evaluation	Long-tail entity QA
2WikiMultihopQA	OOD evaluation	Multi-hop compositional QA
MuSiQue	OOD evaluation	Multi-hop QA with shortcut filtering
Bamboogle	OOD evaluation	Search-hard multi-hop QA

Cold-start SFT dataset은 NQ 5,000개와 HotpotQA 5,000개로 총 10,000개 trajectory다. RL training은 NQ와 HotpotQA full training split을 사용하고, 나머지 dataset은 generalization 평가로 둔다.

이 split은 논문 해석에서 중요하다. GrepSeek이 모든 benchmark를 직접 학습한 것은 아니다. NQ와 HotpotQA에서 search behavior를 학습한 뒤, 다른 single-hop and multi-hop QA benchmark로 일반화되는지를 본다.

4-2. Training strategy

Training pipeline은 다음 세 단계다.

1. Cold-start trajectory generation
   • Answer-aware Tutor가 backward evidence chain을 만든다.
   • Answer-blind Planner가 forward causal trajectory를 만든다.
   • Judge가 answer overlap, causal consistency, format validity를 확인한다.
2. SFT
   • Qwen3.5-9B policy를 10,000개 trajectory로 1 epoch fine-tuning한다.
   • Max sequence length는 16,384 tokens로 설정된다.
   • Purpose는 stable DCI behavior initialization이다.
3. GRPO
   • SFT checkpoint에서 시작한다.
   • Token-level F1과 format gate를 이용해 trajectory reward를 만든다.
   • 200 global steps 동안 policy를 optimize한다.
   • Inference에서는 최대 6 assistant turns와 16,384 token context를 사용한다.

이 pipeline의 진짜 포인트는 SFT와 RL의 역할 분리다. SFT는 syntax와 causal search protocol을 만들고, RL은 어떤 command를 언제 쓸지와 얼마나 evidence를 가져올지를 조정한다. SFT 없이 RL만 걸면 action space가 너무 넓고, RL 없이 SFT만 쓰면 task-specific exploration과 correction이 부족하다.

4-3. Engineering notes

실무 관점에서 GrepSeek은 method보다 engineering detail이 더 유용할 수 있다.

첫째, DCI는 retrieval index를 만들지 않는다. Dense retriever를 쓰면 corpus embedding을 만들고 index를 유지해야 한다. GrepSeek은 raw corpus를 그대로 두고 shell command로 접근하므로 setup cost가 작다. Repository 설명 기준 raw corpus memory footprint는 약 14GB이고, dense retrieval baseline은 E5 index가 70GB, Qwen3-4B embedding index가 221GB로 제시된다.

둘째, command execution semantics를 지키는 것이 중요하다. 단순히 shard별 grep을 병렬로 돌리는 것은 쉽지만, pipe, head, sort, uniq가 섞이면 output order와 truncation semantics가 달라질 수 있다. GrepSeek은 pipeline을 conservative하게 classify해서 안전한 경우에만 parallel execution을 적용한다.

셋째, command output control이 policy behavior의 일부다. GrepSeek은 모든 invocation에서 head를 사용해 output verbosity를 제한하는 경향을 보인다. 이는 단순한 latency trick이 아니라 context length explosion을 막는 agent behavior다.

넷째, shell interface는 보안 boundary가 필요하다. 논문은 QA benchmark setting을 다루지만, 실제 internal corpus에 적용하려면 command whitelist, sandboxing, resource limit, path isolation이 필수다. DCI는 agent에게 corpus operation 권한을 주는 방식이므로, system integration 단계에서 policy와 execution engine을 분리해 엄격히 관리해야 한다.

5. Evaluation

5-1. Main results

평가는 7개 open-domain QA benchmark에서 token-level F1을 중심으로 수행된다. 비교군은 Direct, RAG, IRCoT, Search-O1, Rejection Sampling, Search-R1 계열이고, retrieval baseline에는 BM25, E5-110M, Qwen3-4B embedding 등이 포함된다.

주요 결과를 micro-average F1 기준으로 보면 다음과 같다.

Method	Retriever	Micro-avg F1
Direct	none	0.3340
RAG	BM25	0.4129
RAG	E5-110M	0.4599
RAG	Qwen3-4B	0.4905
Search-O1	Qwen3-4B	0.5021
Rejection Sampling	Qwen3-4B	0.5133
Search-R1	Qwen3-4B	0.5441
GrepSeek	DCI	0.5691

GrepSeek은 전체 micro-average에서 가장 높은 F1을 보인다. Benchmark별로는 NQ, HotpotQA, 2Wiki, MuSiQue에서 best result를 보고하고, 그중 여러 dataset에서 statistically significant improvement를 표시한다.

하지만 이 결과를 “DCI가 dense retrieval을 항상 이긴다”로 읽으면 안 된다. TriviaQA와 Bamboogle에서는 차이가 작거나 baseline이 비슷하고, PopQA에서는 GrepSeek이 best baseline보다 유의하게 낮게 나온다. 이 점이 오히려 논문을 더 신뢰할 만하게 만든다. DCI는 exact lexical control이 강한 query에 유리하지만, surface-form variation이나 semantic paraphrase가 큰 query에서는 약할 수 있다.

Ablation도 중요하다.

Variant	Micro-avg F1
GrepSeek	0.5691
w/o GRPO	0.4249
w/o SFT	0.3314

이 결과는 SFT와 GRPO가 둘 다 필요하다는 점을 보여준다. 특히 w/o SFT가 크게 무너지는 것은 DCI action space에서 structured initialization이 매우 중요하다는 뜻이다.

5-2. What really matters in the experiments

1) GrepSeek의 강점은 multi-hop lexical control에 있다

GrepSeek이 특히 좋은 setting은 multi-hop evidence aggregation이다. Agent가 first-hop evidence에서 bridge entity를 찾고, 그 entity를 다음 command의 search anchor로 삼을 수 있기 때문이다. Dense retriever는 semantic similarity로 후보를 넓게 가져오지만, entity collision이나 rare phrase에서 헷갈릴 수 있다. GrepSeek은 exact string constraint를 걸어 ambiguity를 강하게 줄일 수 있다.

2) F1 micro-average만 보면 놓치는 trade-off가 있다

GrepSeek은 micro-average 기준으로 좋지만, PopQA에서는 약하다. PopQA는 long-tail entity와 surface-form variation이 중요하다. Accent mark, alias, spelling variation, paraphrase가 핵심이면 exact string matching이 오히려 brittleness가 된다.

즉 DCI는 semantic retrieval의 대체재라기보다 보완재에 가깝다. Exact anchor가 있는 search problem에서는 강하고, fuzzy semantic matching이 필요한 problem에서는 dense retriever가 낫다.

3) RL은 command 수를 늘리는 것이 아니라 command를 더 조합하게 만든다

논문의 behavior analysis에 따르면 GrepSeek은 training이 진행되면서 search command 수를 줄이고, 대신 pipe를 이용한 multi-stage command를 더 잘 구성한다. Table 3에서는 RL step이 진행될수록 commands per trajectory가 대략 3.06에서 2.56 수준으로 내려가고, head -n으로 가져오는 line 수와 reasoning token은 증가하는 흐름이 보인다.

이 해석은 흥미롭다. RL이 agent를 더 많이 검색하게 만든 것이 아니라, 한 번의 search command에서 더 많은 조건을 조합하도록 만든다. 이는 DCI의 장점과 잘 맞는다. 좋은 DCI agent는 command를 많이 던지는 agent가 아니라, 적은 command로 search space를 잘 좁히는 agent다.

4) Execution cost와 generation cost를 분리해서 봐야 한다

GrepSeek은 dense retriever보다 end-to-end latency가 높을 수 있다. 주된 이유는 shell command execution이 아니라, agent가 긴 reasoning trajectory와 tool interaction을 생성하기 때문이다. 논문은 optimized engine이 tool execution cost를 낮춘다고 설명하지만, LLM decoding overhead는 여전히 남는다.

그래서 GrepSeek을 serving system으로 볼 때는 두 가지 cost를 분리해야 한다.

• Retrieval substrate cost: index memory, offline indexing, command execution latency
• Agent reasoning cost: token generation, multi-turn trajectory, context management

DCI는 첫 번째 cost를 줄이지만, 두 번째 cost가 커질 수 있다. Production에서는 prompt compaction, trajectory compression, early stopping, hybrid retriever boundary가 필요할 가능성이 크다.

6. Limitations

1. Surface-form variation에 취약하다.
   • DCI는 exact lexical operation에 강하지만, alias, typo, diacritics, paraphrase가 많으면 dense retriever보다 약할 수 있다.
   • PopQA 결과가 이 limitation을 잘 보여준다.
2. Semantic ranking이 없다.
   • rg는 matching line을 찾을 수 있지만, learned semantic relevance score를 제공하지 않는다.
   • Keyword가 overloaded되면 relevant document가 retrieval stream 뒤쪽에 묻힐 수 있다.
3. End-to-end latency는 여전히 크다.
   • Tool execution은 sharded-parallel engine으로 줄일 수 있지만, long reasoning trace와 multi-turn decoding cost는 남는다.
   • High-throughput QA serving에서는 token budget 관리가 중요하다.
4. Text corpus 중심이다.
   • 논문은 line-oriented Wikipedia text corpus에서 실험한다.
   • PDF, table, HTML, image-heavy document, multimodal corpus에는 별도 parsing layer가 필요하다.
5. Shell interface는 안전한 sandbox가 필요하다.
   • Real deployment에서는 arbitrary shell command를 그대로 열면 안 된다.
   • Command whitelist, timeout, memory limit, path sandbox, output truncation이 필수다.
6. Benchmark coverage가 아직 제한적이다.
   • 평가가 open-domain QA 중심이고, BrowseComp 같은 broader deep-search setting은 future work로 남겨둔다.
   • Enterprise search, codebase search, legal discovery, scientific corpus search에서 같은 behavior가 유지되는지는 추가 검증이 필요하다.
7. Hybrid retrieval design은 아직 본격적으로 다루지 않는다.
   • GrepSeek은 DCI가 index-based retrieval과 경쟁 가능하다는 것을 보여준다.
   • 하지만 실제 system에서는 retriever가 interaction space를 좁히고, DCI가 그 안을 정밀 탐색하는 hybrid design이 더 적합할 수 있다.

7. My Take

7-1. Why this matters for my work

이 논문은 RAG를 “retriever + generator”로만 보던 시야를 넓혀준다. 특히 internal document search나 product log search처럼 exact identifier, version string, field name, error message, table key가 중요한 환경에서는 dense retriever만으로는 부족할 때가 많다. 그런 환경에서 GrepSeek식 DCI는 꽤 직접적인 reuse point가 있다.

예를 들어 enterprise setting에서는 다음 문제가 자주 생긴다.

• 문서 안의 exact product code를 찾아야 한다.
• OCR output에서 특정 invoice number와 company name을 동시에 만족하는 line을 찾아야 한다.
• Log corpus에서 error code와 timestamp window를 같이 filter해야 한다.
• Codebase에서 function name, call path, config key를 순차적으로 좁혀야 한다.

이런 문제는 dense similarity보다 command-like filtering이 더 자연스럽다. GrepSeek은 이 intuition을 학습 가능한 agent policy로 만든다는 점에서 의미가 있다.

7-2. Reuse potential

재사용해볼 만한 포인트는 다음과 같다.

1. Retriever를 tool 하나로만 보지 말고 interaction interface로 설계한다.
   • Query string을 던지는 retriever만 둘 것이 아니라, search, filter, count, truncate, sort 같은 operation primitive를 agent action space로 열 수 있다.
2. Answer-aware generation과 answer-blind trajectory를 분리한다.
   • Synthetic agent trajectory를 만들 때 gold answer를 활용하되, final training trajectory는 inference-time causality를 지켜야 한다.
   • 이 설계는 search agent뿐 아니라 tool-use data generation 전반에 적용 가능하다.
3. Format gate를 reward에 넣는다.
   • Tool agent RL에서는 answer correctness보다 먼저 interaction protocol이 깨지지 않아야 한다.
   • Format validity를 binary gate로 넣는 방식은 단순하지만 practical하다.
4. Execution engine도 method의 일부로 본다.
   • DCI는 model만 좋다고 되는 것이 아니라, corpus execution latency와 output equivalence가 같이 해결되어야 한다.
   • Agent paper에서 system layer를 함께 공개했다는 점이 좋다.
5. Hybrid RAG 설계를 후속으로 생각한다.
   • Dense retriever가 broad candidate space를 만들고, DCI agent가 그 안에서 exact search를 수행하는 방식이 현실적이다.
   • 특히 huge corpus에서 pure DCI는 broad command cost가 커질 수 있으므로, bounded interaction space가 필요할 수 있다.

7-3. Follow-up papers

• Search-R1: Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning
• Beyond Semantic Similarity: Rethinking Retrieval for Agentic Search via Direct Corpus Interaction
• Towards Retrieving Interaction Spaces for Agentic Search
• IRCoT: Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions
• ReAct: Synergizing Reasoning and Acting in Language Models

8. Summary

• GrepSeek은 search agent가 retriever index 대신 raw corpus에 직접 shell command를 실행하는 DCI approach를 제안한다.
• 핵심은 DCI 자체보다, cold-start SFT + GRPO로 compact model이 stable shell search behavior를 학습하도록 만든 pipeline이다.
• Answer-aware Tutor와 answer-blind Planner를 분리해 verified evidence chain과 inference-time causal trajectory 사이의 leakage 문제를 줄인다.
• 7개 open-domain QA benchmark에서 GrepSeek은 micro-average F1 0.5691로 가장 높은 전체 성능을 보고하지만, PopQA처럼 surface-form variation이 큰 setting에서는 약점을 보인다.
• 실무적으로는 dense retriever의 대체재라기보다, exact lexical control이 중요한 internal search system에서 hybrid RAG component로 재사용할 가치가 크다.