The news calls it version 3.0, the tags call it 0.3.0, and most dependency pins have their reason written next to them

The news section says version 3.0 and the tags say 0.3.0

The page carries two numbering systems and does not reconcile them. The news section announces version 3.0 with a slogan about refusing black-box development and making each line of reasoning visible, dated in January 2026, while the three most recent releases are all 0.3.0 point releases, the newest from September 2026 and the previous two from April and March. The manifest declares a third number again, matching the middle release rather than the newest, so the source tree is one patch behind the newest tag. The source install pins its environment manager to an exact version, and so does the container:

## Direct installation
pip install uv==0.12.0

Underneath that sits a habit worth noting: earlier major announcements each preserved their code on a branch of its own, so version 1 and version 2 are both still readable, and there is a third branch carrying a paper digest that is updated daily. That is generous archival practice, and it means the page you are reading describes a line whose name does not appear in its own release tags.

The architecture is independent servers plus control flow in configuration

The design claim is that the core components of a retrieval pipeline, with the retriever and the generator named as examples, are standardised as independent servers speaking the Model Context Protocol, and that the orchestration on top comes from a client that speaks the same protocol. The consequence is that a pipeline's control structure, including conditional branches and loops, is written as configuration rather than as code, and the page puts a number on the saving: dozens of lines. Four groups are credited with the project, two university laboratories, one open organisation and one smaller team, and the stated audience is research exploration and industrial prototyping. The extension model follows from the same choice, since new capability is registered as a function-level tool on a server rather than added to a base class, which is what makes a component swappable at the configuration level.

The interface is a pipeline editor with two-way sync, and it ends in a chat app

The visual environment is described as moving past a chat interface into something closer to an integrated development environment for pipelines, combining construction, debugging and demonstration. Two capabilities carry most of the weight. The first is a builder whose canvas and its code representation stay synchronised in both directions, so a change made by editing code appears on the canvas and a change made on the canvas appears in the code, which is what removes the usual drift between a diagram and the thing it describes. The second is an assistant that covers the whole lifecycle, from designing the pipeline's structure to tuning parameters and writing prompts. The payoff described at the end of the paragraph is a single click: once a flow is built, it becomes an interactive dialogue system. Knowledge base management is folded into the same interface for document question answering, so the ingestion side is part of the tool rather than a separate product.

Two of the four headline claims are about reproducibility

The highlights are laid out as a four-cell table, and the first cell is the one the rest of the project depends on: low-code orchestration, with sequential, looping and conditional structures supported natively and a complex iterative pipeline expressed in configuration in dozens of lines. The second is modularity, with functions decoupled into independent servers and new features registered as function-level tools. The third and fourth are the interesting pair. One is a built-in standardised evaluation workflow with ready-to-use research benchmarks, unified metric management and baseline integration, described as improving experiment reproducibility and comparison efficiency. The other is one-click delivery, converting pipeline logic into a conversational web interface with one command. So one cell of the marketing table is about being able to compare two runs honestly, which is the claim a research framework should lead with and almost never does.

Every dependency ceiling in the manifest has its reason written beside it

The dependency list is where this project is most instructive, because the constraints are commented rather than merely applied. Four examples. fastmcp is held below 3.4.5 because that version requires Starlette 1 or newer through its client extra, while MinerU and Gradio need Starlette below 1. NumPy is held at >=2,<2.4 because faiss-gpu-cu12 1.14 requires NumPy 2, and the comment notes the <2.4 ceiling also satisfies vLLM and Numba. The inference engine is pinned to an exact release because newer accelerator wheels either pull a newer toolkit or collide with the document parser. And a grammar library is capped because the next version has no wheel for one combination of Python version and platform. Around those sit three vector stores, two search backends, and two Chinese-language text libraries for word segmentation and pinyin conversion, which tells you something about who the first users were.

Six optional groups, and one exists specifically to avoid the heavy one

The extras are where the project's priorities show. The retriever group is the largest and mixes embedding libraries, two search engines, two vector stores, the inference stack and a small web service. The generation group is the heavy one, with the inference engine, the transformer library and the tensor library. Then there is evaluation, with a rouge implementation and a retrieval metric library; a corpus group holding a document parser; and a group for a pure API client, with a comment explaining that it is kept separate from the heavy generation group precisely so that people running on a CPU or through a proxy do not have to install the inference stack. That is a small design decision with a large effect on who can try the project. The remaining group simply pulls the others together, and the platform-specific split between two builds of the same vector search library is handled by markers rather than by documentation.

The container starts from a GPU image and installs every extra

The image is built in two stages and the second one is the interesting part. A slim Node image builds the interface, then the result is copied into a runtime that starts from a vendor base image for a specific accelerator toolkit release. The environment manager is copied in from its own published image at a pinned version, matching the version the installation instructions ask you to install. The system packages include the interpreter and its headers, a document converter, a build toolchain and certificates, and the interpreter is symlinked under two names so that scripts asking for either find the right one. Then the dependency sync runs with the frozen flag, development dependencies excluded and every optional group included, which means the image ships the inference stack even if you only want the interface. It listens on one port and its default command starts the interface bound to all interfaces, and the tree holds two more base images for the CPU and GPU variants.

Editorial conclusion

UltraRAG fits a team doing research on retrieval pipelines who wants to swap a component without rewriting the pipeline, because each piece is a separately registered server and the control flow sits in configuration rather than in your code. Three things to know before you start. The version numbers on the page and in the release tags are two different schemes, so pin by tag rather than by what the news section calls it. The supported interpreter window is narrow, two versions, with an upper bound below the current release. And the container starts from a GPU base image and installs every optional dependency group, so it is a research environment rather than a small deployment image, and the two extra base files in the tree are the ones to look at if you want a CPU variant.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. OpenBMB/UltraRAG on GitHub
3. Project website
4. README
5. Releases