DeepResearchGym: A Free, Transparent, and Reproducible Evaluation Sandbox for Deep Research
> Source: arXiv:2505.19253 — May 2025. This post is a Chinese-forum digest of the paper; consult the PDF for exact numbers.
Overview
DeepResearchGym is an open evaluation sandbox for deep research systems (LLM agents that iteratively search, read, and synthesize information). The paper's central argument is that evaluation in this field currently depends heavily on commercial search APIs, which are:
- expensive and rate-limited;
- opaque — ranking algorithms are proprietary;
- non-reproducible — results change over time without notice, so comparing systems across dates or labs is unreliable.
- Problem: search-API-based evaluation is costly, opaque, and non-reproducible.
- Solution: a free sandbox built on public web/news corpora with a controlled ranking/retrieval interface.
- Evaluation axis: both end-task quality (report quality, citations) and retrieval-stage quality (how well agents find relevant sources).
- Cost/latency awareness: the framework lets researchers account for retrieval cost and latency alongside accuracy.
- Evaluation of Retrieval-Augmented Generation: A Survey (arXiv:2405.07437)
- ARES: Automated Evaluation Framework for RAG (arXiv:2311.09476)
- AgentBoard: Multi-turn LLM Agent Evaluation (arXiv:2401.13178)
- Agent-X: Multimodal Agentic Reasoning Evaluation (arXiv:2505.24876)
- QASA/QALD-style research-anchored QA datasets (arXiv:2105.03011)
DeepResearchGym replaces closed APIs with a transparent, reproducible harness built over large public corpora (e.g., subsets of ClueWeb22-B and MS MARCO), exposing ranking-based retrieval so that any deep research agent can be evaluated against a fixed, versioned search substrate.
Why This Matters for Evaluation
Deep research evaluation is shifting from static IR metrics (nDCG@10, Recall@k) toward process-oriented metrics: task success on open-ended research queries, citation accuracy, multi-hop reasoning chains, and answer verifiability. A shared, frozen search environment is a prerequisite for meaningful comparison—otherwise differences in scores may reflect API drift rather than model quality.
Key Points
Forum Commentary: Engineering Checklist
| Concern | Suggestion | |---|---| | Latency | cascade + early stopping, cache frequent queries, async reranking | | Quality | interleaved A/B testing, human audits, citation verification | | Safety | source allowlists, poisoning/bias detection, output filtering | | Cost | route to smaller models, distillation, hybrid sparse+dense retrieval |
Takeaways for the Field
1. Architecture: cascade retrieve-rerank-generate remains dominant, but agentic paradigms make *when and how often to retrieve* a learnable policy. 2. Evaluation: offline metrics increasingly diverge from user satisfaction; LLM-as-judge should be cross-validated with human assessment. 3. Production constraints: latency, cost, interpretability, and safety are hard requirements—not just benchmark scores.