R2R for RAG
A production-oriented RAG framework with ingestion and orchestration — batteries included, opinions included.
R2R is an open-source agentic retrieval system from SciPhi-AI built around a RESTful API for multimodal ingestion, hybrid search, knowledge graphs, cited RAG, and a Deep Research agent. As of the 18 September 2026 GitHub API capture, SciPhi-AI/R2R shows about 7,998 stars under an MIT license and is not archived. PyPI lists the r2r package at 3.6.6. R2R owns the retrieval service layer rather than the chat UI wrapped around it. How it compares to other frameworks sits under RAG frameworks.
What is R2R, and what part of a RAG system does it own?
R2R owns ingest, index, search, graph extraction, and cited generation exposed over HTTP. The SciPhi Python README (captured 18 September 2026) describes an advanced AI retrieval system with production-oriented features and a Deep Research API for multi-step reasoning over a knowledge base and the web. You talk to it through a REST API and Python or JavaScript SDK clients, so document management and retrieval logic live in one service instead of scattered across application code.
That split matters because R2R standardizes how documents become searchable context and how answers cite chunks. It does not remove the need for good parsing, chunking, embedding choices, or backend store configuration. Those stages still set what retrieval can find. Owen Colegrove’s introduction post and AI/TLDR’s tool summary both place R2R as a retrieval backend you deploy, not as a notebook toy.
Ragas documents an integration path for evaluating R2R pipelines, which is a useful signal that SciPhi expected R2R to sit in production evaluation loops. Metric depth for that evaluation belongs under Ragas and the wider evaluation hub, not inside this profile.
What does R2R give you for ingestion, search, and agentic retrieval?
R2R ships multimodal ingestion, hybrid retrieval, graph extraction, cited RAG, access control, and an agentic research loop in one server. The README usage examples show client.retrieval.search, client.retrieval.rag, and client.retrieval.agent with extended thinking configuration for Deep Research. Hybrid search is described as fusing semantic and keyword retrieval. Graph features extract entities and relationships for GraphRAG-style retrieval.
Unstructured’s September 2024 integration post adds a concrete ingestion path: R2R can use the Unstructured open-source library by default for local builds, or the Unstructured Serverless API for production, covering 64+ file types including complex PDFs with tables and embedded graphics. That pairing matters because a RAG server is only as good as the text its parser extracts. Firecrawl’s 2026 open-source RAG frameworks survey includes R2R in the production-oriented cohort for the same reason: batteries included, opinions included.
| Capability | What you get | What it still does not solve |
|---|---|---|
| Multimodal ingestion | One API path for text, PDF, JSON, images, and audio | Extraction quality still depends on the parsing provider and document messiness |
| Hybrid search | Semantic plus keyword retrieval fused in one query | You still tune limits, filters, and when hybrid beats pure vector |
| Knowledge graphs | Automatic entity and relationship extraction | Graph build jobs add orchestration beyond a simple vector index |
| Cited RAG | Answers grounded in retrieved chunks with citation metadata | Citations do not fix wrong chunks |
| Deep Research agent | Multi-step reasoning over your knowledge base and the web | Agent loops add latency versus single-turn retrieve-then-generate |
| User and collection management | Authentication and collection scoping for multi-tenant apps | Identity, permissions, and audit policy remain yours |
For the agent pattern itself, see agentic RAG. For how GraphRAG changes retrieval mechanics, see graph RAG. Hybrid score fusion depth is at hybrid search.
How does R2R deploy in light mode and full mode?
R2R’s quickest path is light mode: install the Python package, set an OpenAI API key, and run python -m r2r.serve to bring up the API on http://localhost:7272 (SciPhi README, 2026). The Python client initializes with R2RClient(base_url=”http://localhost:7272″). JavaScript users install r2r-js. That mode is meant for experimentation without standing up the full dependency stack.
Full mode uses Docker Compose with Postgres via compose.full.yaml, with R2R_CONFIG_NAME=full in the README’s commented path. Unstructured’s post documents production-shaped deployments that point parsing and chunking at the Unstructured API. The honest limit is operational: once you leave light mode, you are running Postgres, workers, configuration, and upgrades.
Public SciPhi Cloud list prices are not published in the SciPhi and Unstructured materials cited here. Full command-by-command setup belongs under building a RAG pipeline. Broader deployment trade-offs sit at RAG deployment.
What are R2R’s capabilities and limits, side by side?
R2R is strongest when you want a batteries-included retrieval server with graphs and agents, and weakest when you need the lightest possible FAQ bot with no service to operate.
The matrix that follows keeps each capability beside the operational cost that arrives with it, using the SciPhi README and Unstructured integration notes rather than vendor slogans.
Feature breadth is attractive in a demo and expensive in on-call. Every additional subsystem, from graph jobs to Deep Research loops, is another surface to monitor, rate-limit, and explain when latency spikes.
| Capability | What you get | The limit that rides along |
|---|---|---|
| REST server + SDKs | One service owns ingest, search, RAG, and graph operations | You run, monitor, secure, and upgrade that service in production |
| Unstructured-backed parsing | 64+ file types and complex PDF paths (Unstructured, 2024) | Serverless parsing has its own cost model |
| Hybrid + GraphRAG | Semantic, keyword, and relationship-aware retrieval in one stack | More moving parts than vector-only RAG |
| Deep Research agent | Multi-step cited answers for research-style questions | Overkill for simple single-turn Q&A |
| Open source (MIT) | About 7,998 GitHub stars; PyPI r2r==3.6.6 | Last GitHub push in the API capture is 7 November 2025; verify release cadence before committing |
The two limits practitioners hit first are self-hosting load and feature breadth. The first is the price of owning the retrieval server. The second is why teams building a thin FAQ wrapper often prefer a smaller framework or a direct vector-database SDK instead.
How do the R2R SDKs express search, RAG, and agents?
The Python README shows three call shapes that map to increasing complexity. client.retrieval.search returns retrieval results for a query string. client.retrieval.rag runs cited generation over retrieved context. client.retrieval.agent runs the Deep Research path with a message object and a generation config that can enable extended thinking and large token budgets.
Those three calls are the product contract. Search is retrieval only. RAG is retrieve-then-generate with citations. Agent is multi-step research that may consult the knowledge base and the web. Picking agent for a single-turn FAQ wastes latency and money.
JavaScript users initialize r2r-js against the same base URL. Keeping clients thin and the server fat is the architectural bet: application UIs should not reimplement hybrid fusion or graph extraction.
When is R2R the wrong default?
R2R is the wrong default when your corpus is small, your queries are single-hop, and your team already operates Weaviate or another store with a short retrieve-then-generate path. Adding a retrieval server then duplicates ops without buying graph or Deep Research value.
It is also the wrong default when the failure mode is chunking or stale documents. A richer server will still retrieve the wrong passage if the index is wrong. Fix the index first. Server features cannot compensate for missing documents.
Choose R2R when citations, multimodal ingest, graphs, and agentic research are requirements you do not want to assemble from scratch. Otherwise start thinner and graduate when measured needs demand it.
What do R2R’s GitHub stars and push date imply?
About 7,998 stars on 18 September 2026 show adoption interest across the open-source retrieval community. The API push timestamp of 7 November 2025 shows the repository was not archived, yet it was also not freshly active on the capture day itself.
Stars without recent commits are a softer signal than an archive banner, and a harder signal than a weekly release train. PyPI r2r==3.6.6 remains the install pin to cite until you verify a newer wheel.
Before production, confirm whether newer releases exist and whether your Docker Compose files match the README you cloned. Popularity metrics never replace latency budgets, evaluation gates, or on-call ownership for a retrieval server that owns hybrid search and agents.
When should you choose R2R over LangChain, LlamaIndex, or a bare retrieval API?
Choose R2R when you want a dedicated retrieval server with hybrid search, knowledge graphs, and agentic research already wired, especially for multimodal corpora and citation-heavy internal knowledge bases. Against LangChain, R2R fits when retrieval infrastructure is the product rather than general LLM-app orchestration. Against LlamaIndex, R2R fits when you want an opinionated server with auth and graph features rather than a Python data-layer toolkit you compose yourself.
Against a bare vector-database API plus your own retrieve-then-generate code, R2R earns its overhead when cited RAG, graphs, and Deep Research are requirements from day one. Do not default to R2R when the app is a thin single-turn FAQ, when your team cannot operate a self-hosted retrieval service, or when the real bottleneck is chunking and index quality rather than missing server features.
When naming vector databases beside R2R’s retrieval service, Weaviate, Pinecone, Qdrant, and Milvus remain store choices for stacks that keep retrieval logic in application code. The scored framework verdict belongs on choosing a RAG framework. Sibling profiles live at LangChain for RAG and LlamaIndex for RAG.
How does Unstructured change R2R ingestion quality?
Unstructured’s September 2024 post argues that production RAG fails when parsers drop tables and layout. Pairing R2R with Unstructured’s open-source library locally, or with Unstructured Serverless in production, is their answer for 64+ file types. R2R remains the retrieval server. Unstructured remains the parsing specialist.
That split is healthy. It also means your bill and your failure modes span two systems. When answers miss table cells, debug the parser before you tune Deep Research prompts. When citations look right but entities are wrong, debug the graph build and the chunker next.
Parsing and table extraction depth on this site live under ingestion and table-failure nodes. R2R’s job is to call a parser and index what comes back.
R2R packages production-shaped retrieval into a REST service: multimodal ingest, hybrid search, graphs, cited RAG, and a Deep Research agent, with light mode on python -m r2r.serve and full mode on Docker Compose. As of 18 September 2026 it remains unarchived at about 7,998 stars with PyPI 3.6.6, and the operational cost of that breadth is still yours to run. Choose it when the server is the product; choose a thinner stack when retrieve-then-generate on Weaviate or another store is enough.