GrepSeek: Training Search Agents for Direct Corpus Interaction

Sign up for free to create and run prompts on this paper using GPT-5.

A simple guide to “GrepSeek: Training Search Agents for Direct Corpus Interaction”

What is this paper about?

This paper introduces GrepSeek, a new kind of AI “search agent” that answers questions by searching through raw text directly, instead of using a traditional search index. Think of it like a careful detective who reads the original pages with a magnifying glass, rather than relying on a pre-made summary or card catalog. GrepSeek uses simple, fast command-line tools (like “find this exact word” and “filter these lines”) to locate exact pieces of evidence in huge text collections.

What are the main goals?

The researchers set out to:

• Teach a smaller AI model to use command-line search tools to find, filter, and combine evidence directly from large text files.
• Make this training stable and reliable, so the agent learns good search habits instead of messy, slow ones.
• Build a fast execution engine so these searches run quickly, even on millions of documents.
• Compare this direct approach to standard methods that use search indexes or embeddings, and see where each works best.

How does GrepSeek work? (Methods in everyday terms)

GrepSeek treats the text collection as a place it can “act in.” It issues simple, executable commands (like “search for this exact phrase,” then “filter for lines that also contain this other word,” then “show just the first few matches”) to step-by-step gather the facts it needs.

To train the agent without it picking up bad habits, the authors use a two-stage process:

1. Create strong examples to learn from (cold start)

• A Tutor (a larger helper AI that already knows the answer) builds a solution backward. Imagine a teacher who knows the final answer and traces the path back through the text to find all the supporting clues. To keep this fair, the Tutor is not allowed to cheat by searching the exact final answer text.
• A Planner (another AI, acting like a student who does not know the answer) then turns that backward path into a realistic forward plan: a step-by-step sequence the agent could follow in real life. The Tutor checks that each step is logically correct and only uses information already seen so far.
• The result is a set of clean, verified “search-and-think” examples that teach the agent how to look up evidence properly.

2. Fine-tune and improve with practice

• First, the agent is trained directly on those good examples (so it learns basic, safe command use).
• Then it improves with a form of reinforcement learning called Group Relative Policy Optimization (GRPO). In simple terms: the agent tries several solution attempts for the same question, compares their quality (Did it answer correctly? Did it follow the rules?), and learns from the best attempts in that group.

Speeding it up at scale

• Searching huge text files line by line can be slow. The authors split the big text into shards (slices), run the same search command on many shards in parallel, and then combine the results. This is like dividing a giant book among friends and merging the matching pages at the end.
• Importantly, they guarantee that the final combined result is exactly the same as if you had run the command on the whole text in one go. This “semantics-preserving” design means it’s faster without changing the answers.

A tiny example

• Suppose the question is about a band’s singer and what award the singer’s father received. GrepSeek might: 1) Search for the band’s name and filter for lines mentioning “singer,” to get the singer’s name. 2) Search for the singer’s father by name and filter for “highest,” to find the specific “highest Hirsch index rating.”
• These small, precise steps are like stacking filters to narrow down to the exact fact.

What did they find, and why does it matter?

Main results across seven question-answering benchmarks:

• GrepSeek achieved the best overall performance (token-level F1) and was strongest on 4 out of 7 datasets, especially on multi-hop questions (where you must connect facts across multiple pieces of text).
• It shines when exact wording matters: rare names, precise phrases, or symbolic patterns (like a chemical formula). Exact matching avoids confusion that sometimes happens with “semantic” search, which can mix up similar names or concepts.
• Limitations: When the question uses very different wording than the text (surface-form variation), or the wording is broad and fuzzy, GrepSeek can struggle because it relies on exact matches. In those cases, dense embedding search often helps.

Efficiency and practicality:

• GrepSeek’s end-to-end time per question is a bit slower mainly because the model reasons in several steps. But the actual search time (the tool’s work) is fast thanks to parallelization.
• Big advantage: no huge memory-hungry index and no long, expensive precomputation. It uses about the size of the raw text in memory (around 14 GB in their setup), while some embedding-based systems need many times more memory and hours of GPU time to build indexes.
• Their parallel engine sped up command execution by up to 7.6x while keeping exact correctness.

Training insights:

• Both parts of training matter: the initial supervised examples and the later reinforcement learning. Removing either hurt performance a lot.
• As the agent learns, it issues fewer, smarter commands and keeps results short and readable, often using exact-string searches and small filters.

Why is this important? What could it change?

• GrepSeek shows that direct, tool-based searching can be a practical and powerful alternative to standard index-based search, especially for multi-step reasoning and tasks needing exact matches.
• It can complement existing methods: use GrepSeek for precise, “needle-in-a-haystack” lookups, and use dense retrieval when wording differs a lot or when broader meaning matters.
• Because it avoids heavy indexing and huge memory overhead, it may be easier to deploy in real-world systems that need to search large text collections quickly and accurately.
• The authors released code, data, and models, which can help others build on this approach and combine it with future advances.

In short: GrepSeek trains an AI to search text like an expert detective—carefully, precisely, and step by step—showing strong results on tough questions and offering a practical path that works well alongside today’s popular search methods.

Knowledge gaps, limitations, and open questions

Below is a concise list of what remains missing, uncertain, or unexplored in the paper, phrased to guide future research.

• Lexical rigidity vs. semantic variation
  • No mechanism for fuzzy/approximate matching, stemming, or synonym handling; the agent largely depends on exact-string filters (e.g., rg -F), making it brittle to paraphrases, typos, diacritics, and morphological variants.
  • Absence of any relevance scoring or ranking in shell-based retrieval; when keywords are overloaded, authoritative evidence may be buried among earlier matches with no learned ranking to disambiguate.
  • No integration with lexical normalization (e.g., case-folding beyond what’s used, diacritic stripping, transliteration), which would mitigate surface-form brittleness.
• Generalization scope and corpus diversity
  • Evaluation is limited to an English Wikipedia corpus (~14 GB, 21M passages); generalization to other domains (biomedical, legal, news), document types (PDFs, HTML), and noisy or heterogeneous corpora remains untested.
  • No experiments on multilingual corpora or cross-lingual queries; handling of non-ASCII scripts, mixed-language documents, and locale-specific tokenization is unknown.
  • Sensitivity to corpus structure and chunking is not examined (each “line = document”); how retrieval quality changes under different segmentation schemes is unclear.
• Hybrid retrieval and system design
  • No exploration of hybrid DCI + index-based retrieval to combine lexical precision with semantic robustness (e.g., fallback to dense retrievers for paraphrastic queries).
  • Unclear how to dynamically decide between shell-based operations and retriever calls, or how to route sub-queries to the most effective tool.
• Training pipeline and supervision quality
  • Synthetic cold-start data depend on a Tutor/Planner (same LLM family); potential biases, error propagation, and “self-endorsement” risks are not quantified (e.g., how often the Judge misses leakage or flawed chains).
  • Only end-task F1 rewards are used in RL (via GRPO); there are no step-level or tool-quality rewards (e.g., penalizing excessive I/O, large outputs, or invalid commands), making credit assignment opaque.
  • Ablations do not cover alternative RL objectives (e.g., stepwise rewards, cost-aware penalties, reward models for faithfulness) or other algorithms (PPO/ILQL/DPO), leaving the optimal training recipe unknown.
  • Robustness across random seeds, multiple runs, and longer RL schedules is not reported; stability beyond 200 GRPO steps and sensitivity to hyperparameters remain open.
• Evidence faithfulness and causal grounding at inference
  • Evaluation focuses on F1/EM; there is no explicit measurement of whether final answers are supported by retrieved evidence (e.g., citation precision/recall, attribution accuracy).
  • No automated or human assessments of reasoning trace validity at inference (distinct from synthetic training-time checks), leaving real-world faithfulness unverified.
• Execution engine coverage and correctness guarantees
  • Semantics-preserving sharded execution relies on heuristic classification of pipelines; there is no formal verification or comprehensive test suite quantifying equivalence failures and edge cases.
  • Limited support for globally stateful commands (sort/uniq cases partially addressed); broader classes of commands fall back to sequential execution—how often and how costly this is under varied workloads is not analyzed.
  • Deterministic concatenation/merge strategies may bias which shard’s matches survive under truncation; the impact of shard order on retrieval outcomes and fairness is unexplored.
• Scalability and systems constraints
  • Results target an in-memory corpus (14 GB) on a single machine; performance under disk-backed corpora, networked storage, or substantially larger collections (100s of GB to TBs) is unreported.
  • Throughput and multi-user concurrency are not evaluated; queueing, contention, and scheduling policies for many simultaneous queries remain open.
  • Sensitivity of performance to number and size of shards beyond 32, memory bandwidth ceilings, and OS-level constraints is only partially explored.
• Latency and efficiency trade-offs
  • End-to-end latency is dominated by LLM decoding; no investigation of distillation, smaller backbones, or caching to reduce token generation without sacrificing accuracy.
  • Tool-use cost is reported, but energy usage and cost-per-query (LLM + tools) under realistic traffic distributions are not analyzed.
• Safety and security of direct shell execution
  • The paper assumes a whitelisted toolset but does not formally specify sandboxing, command injection defenses, or resource limits (e.g., to prevent runaway processes or excessive I/O).
  • No discussion of adversarial corpora (e.g., content crafted to mislead pattern matching) or prompt injection via retrieved text, and how the agent resists tool-use manipulation.
• Robustness to data dynamics and noise
  • Behavior under streaming or frequently updated corpora (index-free updates are a selling point) is not studied; strategies for cache invalidation and incremental sharding are absent.
  • Resilience to near-duplicates, noisy OCR, or adversarial noise is unknown; no experiments quantify degradation under corpus corruption.
• Retrieval strategy design
  • The agent routinely truncates with head -n; the risk of missing later evidence vs. latency savings is not quantified, nor is adaptive selection of n optimized/fine-tuned.
  • The policy often avoids regex in favor of fixed-string matching; the potential gains of safe regex or structured patterns (with guards against overgeneralization) are not explored.
• Baseline fairness and breadth
  • Dense/sparse baselines retrieve only top-3 documents and omit strong reranking pipelines; sensitivity to larger k, rerankers, or stronger retrievers (e.g., Contriever, GTR, ColBERT, SPLADE, hybrid BM25+dense) is not reported.
  • No direct head-to-head comparison with concurrent DCI agents using large models due to proprietary access; a normalized budget comparison (speed/accuracy/cost) remains open.
• Task and modality coverage
  • Experiments focus on QA; applicability to other knowledge-intensive tasks (fact verification, long-form synthesis, multi-document summarization) is untested.
  • Non-text modalities (tables, code beyond natural language, images) and semi-structured data (JSON, XML) are not addressed; how to extend DCI tools to these forms is unclear.
• Domain shift and portability
  • The agent is trained on NQ/HotpotQA and evaluated mostly on Wikipedia-based QA; transfer to unseen corpora with different styles and metadata is unvalidated.
  • No study on corpus- or task-adaptive finetuning, or on mechanisms to quickly specialize the agent to new domains without rebuilding indices.
• Interpretability vs. performance tension
  • While shell pipelines are interpretable, there is no systematic framework to trade off interpretability against retrieval effectiveness (e.g., permitting limited approximate match with transparent justification).
• Data and artifact clarity
  • Details of the underlying passage segmentation, line lengths, and preprocessing in the Wikipedia dump are sparse; how these choices impact retrieval is an open variable.
  • The extent and format of released trajectories, their license, and reproducibility across platforms (OS/shell differences) are not exhaustively documented.

These gaps suggest concrete directions: integrating semantic matching into DCI, robustifying to surface-form and multilingual variation, formally validating the execution engine, broadening evaluation to diverse corpora and tasks, adding faithfulness metrics and safety guarantees, and optimizing training with richer reward shaping and hybrid tool routing.

Immediate Applications

Below are concrete ways the paper’s contributions—direct corpus interaction (DCI) via shell pipelines, the Tutor/Planner cold-start data generation, GRPO-trained compact agents, and a semantics-preserving sharded-parallel execution engine—can be deployed today.

• Enterprise and eDiscovery search (Industry: Legal/Compliance)
  • What: Explainable, “surgical” search across large document collections (policies, contracts, emails, tickets) using exact string matching and cascading filters with reproducible, auditable logs (<tool_call>/<tool_response> records).
  • Workflow/Product: An on-prem “Index-free Search Agent” that accepts questions, executes rg/grep pipelines across internal corpora, and returns the answer with the precise lines (head -n) and command trace.
  • Why DCI: No embedding/index build, low memory (≈ raw corpus size), exact entity precision, high interpretability for audits.
  • Assumptions/Dependencies: Text-accessible corpora; Unix-like shell tools (rg/grep); sandboxing for shell execution; lexical overlap between queries and target text.
• Incident response and log triage (Industry: Software/SRE/SecOps)
  • What: Rapid triage of logs and configs via exact match and compositional filtering (e.g., rg -F “error id” | rg “service X” | head -n 20) with shard-parallel execution for speed.
  • Workflow/Product: “DCI Log Investigator” integrated into observability platforms to answer multi-step questions (time ranges, component joins, exact IDs).
  • Why DCI: Minimal setup; interpretable pipelines; shard-parallel execution reduces latency to sub-second per command at scale.
  • Assumptions/Dependencies: Logs accessible as text; careful pipeline safety (no global-state ops requiring sequential mode).
• Regulatory and policy checks across document sets (Industry & Public Sector)
  • What: Verifiable compliance checks (e.g., “show all occurrences and supporting passages where policy X references standard Y and exception Z”).
  • Workflow/Product: “Explainable Policy Auditor” generating exact passages plus command traces for audit trails.
  • Why DCI: Byte-exact, deterministic outputs; no opaque relevance ranking; strong for entity-specific clauses.
  • Assumptions/Dependencies: Policies/procedures available as plain text; exact references exist; governance for shell execution.
• Data governance and PII keyword sweeps (Industry: Finance/Healthcare/Enterprise IT)
  • What: Precise scans for regulated strings (IDs, SSNs, account numbers) with cascading filters and limited context windows.
  • Workflow/Product: “Compliance Scanner Agent” for scheduled scans and on-demand investigations.
  • Why DCI: No embeddings to manage; auditable; robust to long-tail identifiers and rare formats (e.g., chemical formulas, account patterns).
  • Assumptions/Dependencies: High lexical signal; normalization/alias dictionaries if formats vary; access controls and redaction.
• Scientific curation and literature triage (Academia/Pharma R&D)
  • What: Exact extraction of rare entities (gene variants, chemical notations) and cross-document bridging to assemble evidence.
  • Workflow/Product: “DCI Literature Screener” that chains searches to connect entities (compound → author → metric).
  • Why DCI: Superior for rare symbols and exact names; interpretable trails for systematic reviews.
  • Assumptions/Dependencies: Corpora as plain text (e.g., preprints, patents); less effective for heavy paraphrase; alias maps benefit recall.
• Public records and FOIA processing (Public Sector/Journalism)
  • What: Targeted retrieval from public filings to answer multi-hop queries and link entities through exact string steps.
  • Workflow/Product: “FOIA DCI Agent” that returns result snippets with command history for legal defensibility.
  • Why DCI: Transparent, repeatable searches that withstand scrutiny; no indexing overhead.
  • Assumptions/Dependencies: Text-structured filings; reproducibility requirements; training on task-specific QA pairs increases precision.
• Internal knowledge base Q&A without indexing (Industry: General/SMBs)
  • What: Lightweight Q&A over wikis/runbooks/FAQs without vector stores; deploy rapidly, maintain on-prem.
  • Workflow/Product: “Indexless RAG Agent” replacing retrievers with shell pipelines on the content directory.
  • Why DCI: Near-zero setup; low memory; explainability; good for precise procedural questions.
  • Assumptions/Dependencies: Sufficient lexical overlap; consistent naming conventions; Unix environment.
• Personal knowledge management (Daily Life/Prosumer)
  • What: Answer questions over emails, notes, and documents locally with exact matches and snippet previews.
  • Workflow/Product: Desktop “GrepSeek-Style” assistant with persistent daemon and shard-parallel search over user files.
  • Why DCI: On-device privacy; instant setup; deterministic retrieval.
  • Assumptions/Dependencies: Users store text documents/maildir/markdown; OS sandboxing; customization for encodings/diacritics.
• Curriculum for explainable IR and agentic reasoning (Academia/Education)
  • What: Use GrepSeek-like traces to teach retrieval strategies, causal reasoning, and tool use in IR courses.
  • Workflow/Product: Teaching kits: datasets, Tutor/Planner prompts, GRPO training scripts; students inspect causally valid trajectories.
  • Why DCI: Interpretability and reproducibility; low infra burden.
  • Assumptions/Dependencies: Availability of open corpora; compute for 9B agent fine-tuning (single A100 suffices as per paper).
• Benchmarks and evaluation of tool-using agents (Academia/AI Research)
  • What: Reproducible pipelines for training/evaluating agents that reason and act over corpora with verifiable evidence.
  • Workflow/Product: Open-source “DCI Agent Eval Harness” with semantics-preserving parallel execution and logs.
  • Why DCI: Byte-exact equivalence guarantees faithful comparisons across systems.
  • Assumptions/Dependencies: Standardized corpora; agreed tool sets; reproducible environments.

Long-Term Applications

These opportunities depend on additional research, integration, scaling, or validation beyond what the paper demonstrates.

• Hybrid retrieval agents (lexical DCI + dense embeddings) (Software/Search/Enterprise)
  • What: Combine DCI’s exact filtering with semantic retrievers to handle paraphrase/diacritics and improve recall.
  • Product/Workflow: Router that tries DCI first, then falls back to dense retrieval if lexical anchors fail, with unified provenance logs.
  • Dependencies: Fusion strategies; semantic normalization; latency orchestration; careful evaluation to avoid “conflation” errors.
• Domain-adapted aliasing and normalization (Healthcare/Finance/Legal)
  • What: Augment DCI with synonym/alias dictionaries, lemmatization, and diacritic-insensitive search to mitigate surface-form variation.
  • Product/Workflow: Preprocessing layer that expands queries while preserving exact-match guarantees where applicable.
  • Dependencies: Curated terminologies (e.g., UMLS, legal thesauri); robust normalization pipelines; explainable expansion policies.
• Web- and enterprise-scale DCI (Large-scale Infrastructure)
  • What: Distributed, cluster-level semantics-preserving shard-parallel engines operating over hundreds of GBs/TBs.
  • Product/Workflow: “DCI Search Fabric” with data locality, memory-mapped shards, and deterministic k-way merges across nodes.
  • Dependencies: Filesystem and network throughput; global-state operation detection and fallback; observability for correctness.
• Safety-critical decision support (Healthcare/Regulatory)
  • What: Explainable assistants for clinicians or compliance officers that provide exact evidence trails and multi-hop reasoning.
  • Product/Workflow: “Regulatory-grade QA” systems with human-in-the-loop verification, auditable trajectories, and policy constraints.
  • Dependencies: Extensive validation, bias/error analysis, privacy and PHI protections, certification; robust alias handling.
• Structured and semi-structured data integration (Data Engineering/Analytics)
  • What: Extend DCI to operate over JSON/CSV/tables with shell-friendly parsers (e.g., jq/awk pipelines) and cross-file joins.
  • Product/Workflow: “Corpus+Table Agent” that composes text filters with simple relational operations for end-to-end evidence assembly.
  • Dependencies: Semantics-preserving parallelization for non-line-based tools; accurate schema inference; determinism guarantees.
• Multi-modal corpus interaction (R&D)
  • What: Bridge exact text matches with references to images/figures/tables (e.g., link captions to text evidence) for richer QA.
  • Product/Workflow: Pipelines that index only minimal multi-modal metadata while keeping text DCI-based; strict provenance.
  • Dependencies: Reliable text-to-media linkage; minimal indexing without sacrificing determinism; evaluation suites.
• Broader tool-use training with Tutor/Planner/GRPO (AI Tool Agents)
  • What: Apply the cold-start backward-to-forward trajectory generation to other tool ecosystems (e.g., SQL, APIs, code search).
  • Product/Workflow: “Causally-Grounded Tool Agent Trainer” that generates verified trajectories and refines with GRPO.
  • Dependencies: Task-specific verifiers; answer-leakage controls; scalable tutoring LLMs; guardrails for causal consistency.
• Policy auditing over evolving corpora (Gov/NGO/Enterprise)
  • What: Continual “no-precompute” compliance audits as policies and regulations change; no need to rebuild vector indexes.
  • Product/Workflow: Scheduled DCI scans with diff-aware reports and immutable evidence logs.
  • Dependencies: Change-detection; governance for frequent runs; strong aliasing for evolving terminology.
• Consumer-grade “private QA” across personal silos (Daily Life)
  • What: Unified, on-device QA over notes, chats, files with explainable snippets and safe sandboxes.
  • Product/Workflow: OS-integrated agent with resource-aware shard-parallel search and UI for command/evidence review.
  • Dependencies: Battery/CPU constraints; privacy UX; file format handling; normalization for informal language.
• Research-grade evaluations of explainability and causality (Academia)
  • What: Use DCI’s explicit command chains to study causal grounding, error propagation, and human trust in agent outputs.
  • Product/Workflow: Benchmarks pairing outputs with execution traces and answer verifications.
  • Dependencies: Community standards for trace schemas; metrics linking evidence quality and answer correctness.

Cross-cutting assumptions and constraints

• Corpus accessibility and format: Best performance when corpora are line-oriented plain text; performance degrades with heavy surface-form variation or noisy OCR unless normalized.
• Execution environment: Requires Unix-like shell tools (rg/grep/awk/sed etc.) and a secure sandbox; semantics-preserving parallelization only for safe pipelines (global-state commands fall back to sequential).
• Compute: Compact LLMs (≈9B) are sufficient but still require GPU for interactive latency; the paper’s 8.6 s/query used one A100 GPU and 32 CPU cores.
• Data generation resources: Tutor/Planner cold-start data used a larger model (≈27B); organizations need access to such models or alternatives.
• Governance and safety: For regulated domains, human oversight, logging, and validation are necessary; ensure PII handling and reproducibility.
• Complementarity: DCI excels with exact anchors and multi-hop bridging; for paraphrases/diacritics, hybridization with dense retrieval or alias dictionaries is advised.

• Agentic search: A paradigm where an LLM acts as an autonomous search agent that plans, retrieves, and reasons iteratively. Example: "retrieval-augmented agentic search"
• Answer-blind Planner: A planning LLM that drafts forward reasoning and actions without access to the gold answer or future evidence. Example: "answer-blind Planner"
• Answer-aware Tutor: A supervisory LLM that knows the gold answer and constructs or verifies evidence chains and aligns steps. Example: "answer-aware Tutor"
• Answer-leak rule: A constraint preventing commands from querying the target answer or its aliases during backward construction to avoid leakage. Example: "answer-leak rule"
• BM25: A classic sparse lexical retrieval function used as a baseline retriever. Example: "BM25 (Robertson et al., 1994)"
• Bridge entities: Intermediate entities connecting pieces of evidence across documents for multi-hop reasoning. Example: "bridge entities across documents."
• Bridge extraction: The step of identifying the antecedent/connecting entity from retrieved evidence for the next hop. Example: "bridge extraction step"
• Byte-exact equivalence: Guarantee that optimized execution returns exactly the same bytes as sequential execution. Example: "byte-exact equivalence"
• Cascaded filtering: Chaining multiple filters (often via pipes) to progressively narrow results. Example: "cascaded filtering"
• Cold-start dataset: An initial training set constructed to bootstrap stable tool-use behaviors before RL. Example: "cold-start dataset"
• Compositional question answering: Answering that requires assembling evidence from multiple steps or sources. Example: "compositional question answering."
• Corpus shards: Partitions of the corpus used to enable parallel execution of search pipelines. Example: "corpus shards"
• Dense embedding: Vector representations of text enabling semantic similarity search. Example: "dense embedding (110M parameters)"
• Dense retrievers: Retrieval models that use dense embeddings to find semantically similar texts. Example: "dense retrievers"
• Direct Corpus Interaction (DCI): An approach where the agent searches the raw corpus directly with shell commands instead of using a pre-built index. Example: "Direct Corpus Interaction (DCI)"
• Exact Match (EM): A strict accuracy metric that counts a prediction as correct only if it exactly matches a gold answer. Example: "Exact Match"
• FAISS: A library for efficient similarity search and vector indexing. Example: "FAISS18 (Douze et al., 2025)"
• Fixed-string matching: Exact substring matching that avoids regex semantics, typically via flags like -F. Example: "fixed-string matching"
• Group Relative Policy Optimization (GRPO): An RL algorithm that normalizes rewards within sampled groups to stabilize optimization. Example: "Group Relative Policy Optimization (GRPO)"
• HNSW index: A graph-based approximate nearest neighbor structure for fast vector search. Example: "HNSW index (Malkov & Yashunin, 2020) (M = 32, efConstruction = 128, efSearch = 128)"
• K-way merge: A deterministic procedure to merge multiple sorted lists, often used after shard-local sorts. Example: "k-way merge procedure (Cormen et al., 2001)"
• Memory-mapped (search primitives): Using memory-mapped I/O to access the corpus efficiently during search operations. Example: "memory-mapped search primitives"
• Micro-average: An averaging scheme aggregating counts across datasets or classes before computing the metric. Example: "micro-average score (0.5691)"
• Multi-hop reasoning: Reasoning that requires chaining multiple evidence pieces or steps to answer a question. Example: "multi-hop reasoning benchmarks"
• Nucleus sampling: A decoding method that samples from the smallest set of tokens whose cumulative probability exceeds a threshold. Example: "nucleus sampling (Holtzman et al., 2020)"
• Persistent Search Daemon: A long-lived service keeping the corpus in memory and reusing workers to reduce per-command latency. Example: "Persistent Search Daemon"
• ReAct framework: A prompting/control framework interleaving reasoning traces with actions/tool calls. Example: "ReAct framework (Yao et al., 2023)"
• Reinforcement learning (RL): Optimization based on reward signals from interactions, used here to improve search behaviors. Example: "reinforcement learning (RL)"
• Rejection Sampling: A baseline training approach that filters generated trajectories based on quality criteria before learning. Example: "Rejection Sampling"
• Ripgrep (rg): A fast search tool used to scan large text corpora with exact or regex matching. Example: "ripgrep"
• Semantics-preserving sharded-parallel execution engine: A parallel execution system that accelerates shell pipelines over shards while guaranteeing identical outputs. Example: "semantics-preserving sharded-parallel execution engine"
• Semantic conflation: A failure mode where semantically similar but distinct entities or concepts are mixed up. Example: "semantic conflation"
• Sharded-Parallel Corpus Search: Executing compatible shell pipelines across multiple shards and reducing results deterministically. Example: "Sharded-Parallel Corpus Search:"
• Sparse lexical baseline: A retrieval baseline relying on term-frequency and inverted indices rather than dense embeddings. Example: "sparse lexical baseline"
• Stateless transformations: Line-wise operations in pipelines that do not depend on cross-line or global state and can be parallelized safely. Example: "stateless transformations"
• Supervised fine-tuning (SFT): Training the model on labeled trajectories to instill structured tool-use before RL. Example: "SFT on Synthetic Trajectories"
• Token-level F1: An evaluation metric measuring overlap between predicted and gold tokens, capturing partial correctness. Example: "token-level F1"
• Vector database: A storage/retrieval system for embedding vectors supporting approximate nearest neighbor search. Example: "vector database"

Sign up for free to add this paper to one or more collections.