RAGFlow 1.0 release candidates: agentic retrieval, knowledge compilation and a 16 GB Docker floor

Four thinking modes decide how many retrieval rounds a question gets

The headline feature of the 1.0 line is Agentic Retrieval, introduced on 2026-08-19. Instead of one vector lookup per question, the model analyzes the question and, when needed, breaks it into parts, retrieves knowledge for each, and verifies the evidence before answering. It can run several rounds of retrieval and reasoning to gather more complete context. You control that depth with four thinking modes: Low, Medium, High and Ultra. The intent is to match the mode to the complexity of the question. The consequence for operators is that the mode is a cost decision as much as a quality one: every extra round is another retrieval pass and another model call against whatever LLM you configured, so setting Ultra as a blanket default spends model calls on simple lookups that a single pass would answer.

Knowledge Compilation produces artifacts you have to regenerate

Also added on 2026-08-19, Knowledge Compilation turns content at the document and dataset levels into structured knowledge artifacts. Compilation templates produce Wikis, Graphs, Trees, PageIndex, Mind Maps, Timelines and Skills, each aimed at a different way of organizing and reusing the same material. You configure which compilation model runs and which processing rules apply, and you can view, update and regenerate the artifacts afterwards. That last point is the catch. A compiled wiki or graph is a derived copy of your documents at the moment of compilation. When the source dataset changes, through new uploads, the sitemap ingestion added on 2026-09-10, or the BigQuery incremental sync added on 2026-07-02, the artifacts do not stay correct on their own unless someone regenerates them.

Elasticsearch needs vm.max_map_count at 262144, and the change does not survive a reboot

RAGFlow can run on Elasticsearch or on Infinity as its document engine. With Elasticsearch, the Docker host must have vm.max_map_count set to at least 262144; with Infinity this step is usually unnecessary. Check the current value first:

sysctl vm.max_map_count

If it is lower, raise it:

sudo sysctl -w vm.max_map_count=262144

That setting is lost on the next reboot. To make it permanent, add or update this line in /etc/sysctl.conf:

vm.max_map_count=262144

Skipping the persistent step produces a stack that works on day one and then breaks after the host restarts, which is easy to miss when the first deployment is tested once and left running.

The 16 GB starting configuration is a floor, not a sizing guide

The recommended starting point for Docker is 4 CPU cores, 16 GB of RAM and 50 GB of free disk, on Docker 24.0.0 or later with Docker Compose v2.26.1 or later. The project is explicit that actual needs depend on the document engine, data volume, parsing tasks and concurrency, and that local models and other optional components may need more. Part of that weight is visible in the Dockerfile: it copies deepdoc layout, detection, recognition and table-structure models (layout.onnx, det.onnx, rec.onnx, tsr.onnx) from the infiniflow/ragflow_deps image, and it symlinks three byte-identical layout model variants to layout.onnx to save about 219 MB. A team planning to run embedding or chat models on the same host should budget on top of the 16 GB, not inside it.

Source builds need Go 1.27 and Python pinned below 3.14

Local deployment comes in two forms. Docker is meant for quick evaluation, integration testing and production, and it does not need a Go compiler. Launching from source is meant for developing and debugging RAGFlow itself. It requires the Go version in go.mod, which declares go 1.27, and frontend work additionally needs Node.js and npm. The Python side is narrower still: pyproject.toml sets requires-python to >=3.13,<3.14, so neither 3.12 nor 3.14 will satisfy it. The same file pins pyasn1>=0.6.4 as a uv constraint to close CVE-2026-30922 and three further HIGH advisories pulled in through google-auth and rsa. Contributors who build from source carry that whole toolchain, which is why Docker is the route for anyone who only wants to run the service. To start either way, clone the repository:

git clone https://github.com/infiniflow/ragflow.git

The next step is checking out a release tag rather than running whatever is on main.

The 1.0 line is still a release candidate

RAGFlow 1.0.0-rc1 shipped on 2026-09-29, and the most recent tag is v1.0.0-rc3 from 2026-10-30, which also matches the version in pyproject.toml. The newest tag outside the candidate series is v0.27.3 from 2026-10-23. There is also a nightly tag dated 2025-12-01. The repository itself is busy: the last push to main was on 2026-11-02. For anyone deploying, the practical question is which of these to pin. Agentic Retrieval and Knowledge Compilation arrived in the run up to 1.0, so taking them means running a candidate build, while staying on the 0.27 line means a tag that is not part of the 1.0 candidate series.

Chunk visualization lets you correct parsing before it reaches answers

RAGFlow's pitch is quality in, quality out. It extracts knowledge from unstructured files with complicated formats: Word, PowerPoint, Excel, TXT, images, PDFs, scanned copies, structured data and web pages. Chunking is template-based, with several templates to choose from, and the chunking result is visualized so a person can step in and adjust it. Answers come with quick views of the key references and traceable citations. Retrieval combines multiple recall paths with fused re-ranking, and both the LLM and the embedding model are configurable. The tradeoff is that the citation quality depends on the chunking being right. A scanned contract split badly by the wrong template will still produce citations, but they will point at the wrong fragments, so the visual chunk review is a step to budget time for rather than an optional extra.

Editorial conclusion

RAGFlow fits teams that need cited answers over messy document collections (scanned PDFs, Office files, spreadsheets, web pages) and can give a Docker host at least 4 cores, 16 GB of RAM and 50 GB of disk. It does not fit a laptop side project or anyone who needs a stable 1.0 today, since the 1.0 line is at v1.0.0-rc3 and v0.27.3 is the latest non-candidate tag. Before deploying, decide between Elasticsearch and Infinity, set vm.max_map_count persistently if you choose Elasticsearch, and pin the release tag you check out.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes