MimirQ: a Chinese-first RAG pipeline where every step stays inspectable

The failure MimirQ is built around: an answer that is wrong and unattributable

The README states the problem plainly: the hard part of an enterprise knowledge base is not vectorising documents, it is making errors locatable, policies replaceable and quality regressable. MimirQ grew out of a real government knowledge base delivery, where a wrong answer forced the team to work out whether the fault sat in parsing, governance, chunking, recall, reranking, or generation drifting away from its citations. A single upload-and-ask button hides all of that, which is fine for a prototype and painful for a contract that has to be estimated, accepted and governed over years. The intended audience is therefore not someone building a first chatbot. It is a delivery or platform team that has to answer a customer asking why a specific question returned a specific wrong passage, and has to show the evidence.

Eight stages, each with an input and an output you can look at

The pipeline the README documents runs data assessment, scenario-specific parsing, cleaning and governance, business-oriented chunking, vector and full-text indexing, hybrid recall, reranking with citation, and Golden regression. The design intent is that each stage can be inspected and swapped independently, per document and per scenario, rather than committing the whole corpus to one parser, one index and one model. Parsing is the clearest example of the replaceability claim: MimirQ ships 30 parsing backends, and the README recommends sampling and assessing the data before choosing one. Complex layouts and scans can be compared across MinerU and DeepDoc; formula-, table- and layout-heavy material can be evaluated with Docling; digital-native Office files or plain text can start from a lighter path such as MarkItDown. Governance then runs through scripts, a rule DSL or plugins before chunking, and chunking follows headings, sections, business records or parent-child relationships instead of one fixed length and overlap window. Retrieval combines BM25, vector search and reranking on top of a vector store such as Milvus. The repository also lists 86 chunking strategies and 13 reranker categories; the README is explicit that these numbers describe implementation breadth, not quality.

Getting it running: make init, then one of two startup paths

The README gives two routes. The Docker route needs Docker 20.10+ and Docker Compose 2.0+, GNU Make, and Python 3.9+ for config generation, on at least 4 CPU cores, 16 GB RAM and 50 GB disk. You clone with git clone --depth 1 --single-branch https://github.com/skygazer42/MimirQ.git, enter the directory and run make init. That command only creates missing .env and web/.env.local files and does not overwrite existing configuration. You then edit .env: LLM_API_KEY is required for the default model calls, with LLM_API_BASE and LLM_MODEL for a custom endpoint, EMBEDDING_API_BASE, EMBEDDING_API_KEY and EMBEDDING_MODEL for a separate embedding service, ENABLE_RERANKER plus RERANKER_API_BASE, RERANKER_API_KEY and RERANKER_MODEL to turn on reranking, and INITIAL_ADMIN_EMAIL, INITIAL_ADMIN_USERNAME and INITIAL_ADMIN_PASSWORD to auto-create the first administrator. Then make up-web and make api-ping, with the UI on http://localhost:3000. If no admin is preconfigured, the first account is registered in the page. The second route, source development, needs Python 3.11+, Node.js 20+ and pnpm 10.26, and starts with make setup-host: FastAPI runs from a .venv and Next.js from pnpm, with Docker holding only PostgreSQL, Redis and Milvus. Optional parsers are separate containers behind their own targets, including make up-docling, make up-docling-gpu, make up-marker, make up-etl4llm, make up-paddlevl, make up-mineru, make up-mineru-vlm, make up-olmocr, make up-magicpdf and make up-qianfanocr. Teardown is staged: make down stops, make docker-reset clears persistent data, and make docker-purge also removes the project's service images, the last two being irreversible.

Optional parsers are heavy containers with real hardware floors

The parser table is where the deployment cost becomes concrete. The built-in DeepDoc needs no extra container. Docling Serve runs as an independent heavy image that does not enter the MimirQ main image; its CPU and GPU profiles share port 5001 and cannot run at the same time, and the README puts the GPU image at roughly 11.13 GB. PaddleOCR-VL, MinerU, MinerU VLM, olmOCR and MagicPDF all require an NVIDIA GPU, with PaddleOCR-VL suggested at 10 GiB of headroom and olmOCR at the 48 GiB class. Qianfan-OCR avoids local GPU by calling an upstream URL and API key. The README also notes a verification boundary: the repository verified PDF, DOCX, Markdown tables and the ParserFactory fallback-free path on an RTX 3070 Ti with 8 GiB. That is a single documented configuration, not a general performance claim, and it says nothing about throughput on a production corpus. The practical reading is that parser choice is a hardware decision as much as an accuracy decision, and the CPU and GPU Docling profiles cannot be mixed on one host.

Where MimirQ is the wrong tool

The README's own comparison table is unusually direct about this. If the business is simple, the flow is stable and low-code is the priority, application platforms such as Dify and FastGPT are usually faster. If you want DeepDoc and GraphRAG in one integrated product, RAGFlow is described as the mature choice. MimirQ positions itself for the case where the knowledge pipeline must be replaced per business, audited, and regressed. There are further constraints visible in the material. The project is Chinese-first, which shapes documentation, governance defaults and the plugin samples. It is a multi-service deployment, not a single binary: PostgreSQL, Redis and Milvus are part of the stack in both startup routes. The 30 parsers and 86 chunking strategies are breadth, and breadth is a maintenance surface, not an argument for adoption. The 800-question evidence is fixed and lives in the repository; it is not a measurement of your corpus, and the README does not claim otherwise. High-risk material still needs human verification, which the README states outright.

Dify as the front end, MimirQ as the knowledge layer

The interesting alternative here is not a like-for-like competitor but a split. Dify gives you a low-code application builder with a stable flow, and MimirQ's own table recommends it for that job. The difference in approach is where control sits. Dify treats the knowledge base as a component behind the application; MimirQ treats the pipeline itself as the product, exposing parsing, governance, chunking, recall, reranking and citation as stages you can inspect and replace, and adding a Golden question set with quality gates and traces to hold release quality across versions. The README explicitly allows combining them: use MimirQ as Dify's external knowledge layer. That is the honest framing. If you do not need stage-level diagnosis or regression gates, the extra services and parser containers buy you nothing over Dify. If you do, Dify alone will not give you the trace.

Licence, versioning and what upgrading actually costs

MimirQ is Apache-2.0, which permits commercial use and modification under that licence's terms; this is a factual note about the licence identifier, not legal advice, and anyone embedding it in a product should read the licence text and their own obligations. The release history in the material is dense rather than sparse: v1.0.0 on 2026-07-28, v0.8.0 and v0.7.17 on the same day, and the README badge points at v1.0.1 with release notes under docs/releases. That cadence is the upgrade cost. The v0.7.17 title mentions identity and general-knowledge boundary hardening, and v0.8.0 mentions general knowledge capability and concurrency safety, which suggests the boundary and concurrency semantics are still moving. Teams pinning a version should read docs/releases/README.md and the per-version notes before jumping, and should re-run their own Golden set after any upgrade, because that is the mechanism the project provides for exactly this. There is no separate migration tooling described in the material, so a version bump is a re-verification exercise, not a drop-in.

Editorial conclusion

Adopt MimirQ if retrieval errors have to be traced to a specific stage (parsing, governance, chunking, recall, reranking or citation drift) and you can staff a Docker Compose stack with Milvus, PostgreSQL and Redis plus at least one LLM API key. Do not adopt it if you want a low-code application platform with a stable, simple flow; the README itself points those teams to Dify or FastGPT, and points anyone who wants DeepDoc plus GraphRAG in one bundle to RAGFlow. Before committing, run make init, check that .env and web/.env.local were created without overwriting existing files, confirm which parser backend your document mix actually needs, and reproduce the Golden set on your own corpus rather than trusting the repository's fixed 800-question evidence.

Official sources

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