R2R for RAG

R2R (RAG to Riches) is an open-source agentic retrieval system from SciPhi-AI built around a RESTful API — multimodal ingestion, hybrid search, knowledge graphs, and a Deep Research agent in one server. As of July 2026, PyPI lists r2r at 3.6.6 (released 17 August 2025, MIT license, Python 3.10–3.12), and the live GitHub capture shows about 7,900 stars. This page states what R2R gives a RAG build and where its production breadth becomes operational cost.

What is R2R, and what part of a RAG system does it own?

R2R owns the retrieval service layer — ingest, index, search, graph extraction, and cited generation exposed over HTTP — not the application UI wrapped around it (SciPhi-AI GitHub README, 2026; AI/TLDR tool summary, 2026). 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 your app 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. The broader author-layer context for these tools sits at RAG frameworks.

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 (GitHub README, 2026). The live README lists ingestion for .txt, .pdf, .json, .png, and .mp3; hybrid search that fuses semantic and keyword retrieval with reciprocal rank fusion; automatic knowledge-graph entity and relationship extraction; and a Deep Research API that runs multi-step reasoning over your knowledge base and the web.

Unstructured’s September 2024 integration post adds another 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 for retrieval quality because a RAG server is only as good as the text its parser extracts.

For the agent pattern itself — when multi-step retrieval beats one-shot RAG — see agentic RAG. For how GraphRAG changes retrieval mechanics, see graph RAG; this profile only names that R2R exposes graph build commands, not the fusion math behind them.

How does R2R deploy in light mode, full mode, and managed cloud?

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 (GitHub README, 2026; PyPI project page, 2026). That mode is meant for experimentation without standing up the full dependency stack.

Full mode uses Docker Compose with Postgres and pgvector via compose.full.yaml — the path Bright Coding’s July 2025 walkthrough and Unstructured’s September 2024 post both describe for production-shaped deployments. Unstructured’s post also documents r2r serve –docker and optional config that points parsing and chunking at the Unstructured API. The official docs link a managed SciPhi Cloud option; this page does not quote Cloud pricing because public list prices were not verified in the July 2026 teardown.

The honest limit is operational: once you leave light mode, you are running Postgres, workers, configuration, and upgrades — not a single-file demo. Full command-by-command setup belongs on 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 trade-off is clearer side by side than in a feature bullet list.

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 reciprocal rank fusion combines scores — named on the GitHub README — is a retrieval mechanism question at hybrid search, not repeated here.

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 (AI/TLDR when-to-use list, 2026; practitioner fit notes in live comparison pages, 2026).

Against LangChain, R2R is the better fit when retrieval infrastructure — not general LLM-app orchestration — is the product. Against LlamaIndex, R2R is the better fit 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 — not when you only need top-k search over one embedding index.

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. The scored verdict across LangChain, LlamaIndex, Haystack, and building it yourself belongs on choosing a RAG framework. Deeper sibling profiles live at LangChain for RAG and LlamaIndex for RAG.

What are the most common R2R questions?

These answers cover the recurring R2R questions from the July 2026 query harvest and ranking pages: what the system is, whether it is open source, which retrieval modes it supports, how to run it locally, and when to pick something simpler.