phoenix-zhou/industrial-general-rag: a FAQ plus RAG dual-engine stack for industrial Q&A
The project integrates the RAG and FAQ dual mechanisms, introduces intent recognition, dynamic adaptive retrieval, and the RAGAS automated evaluation system, achieving a transformation from empirical optimization to data-driven optimization.
At a glance
- What is it?
- The repository routes high-frequency questions to a MySQL FAQ cache and long-tail questions to a Milvus hybrid retrieval pipeline, with RAGAS evaluation scripts in the same tree. The architecture is the interesting part; the documentation is thinner than the diagram suggests.
- Who is it for?
- Adopt it if you already run Milvus, Redis and MySQL, you are working in Chinese industrial text, and you want a working reference for intent routing plus hybrid retrieval rather than a packaged product. Do not adopt it if you need a licence you can read before shipping, if you expect a hosted API, or if your corpus is English-only and you have no way to obtain the BGE and BERT checkpoints.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 59 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap industrial-general-rag is aimed at
A general-purpose chat model answers an industrial question about a specific valve tolerance with something plausible and unverifiable. Two failure modes follow from that. The first is hallucination: the model produces a number that was never in any manual. The second is knowledge latency: the manual was revised last month and the model has never seen the revision. The repository frames both explicitly in its project introduction, and the design follows from them rather than from a general desire to build a chatbot.
The intended user is someone standing up an internal question-answering service over a corpus of industrial documents, where answers must be traceable to a source and where a subset of questions repeats constantly. That second condition matters more than it looks. The entire FAQ branch exists because a small set of questions arrives over and over, and paying a full retrieval and generation pass for each one is wasteful. The README claims under 100ms for those high-frequency questions and second-level responses for the complex ones.
How the router splits FAQ from RAG
The mermaid diagram in the README is the clearest artifact in the repository. A user query enters an intent recognition router. The router dispatches in two directions. High-frequency or simple queries go to the FAQ module, which is MySQL plus Redis plus BM25 matching. Complex or long-tail queries go to the RAG module, which is Milvus.
The FAQ branch has a threshold: if similarity exceeds 0.85, the system returns the stored answer directly. That is the mechanism that produces the sub-100ms figure, and it is also the mechanism that produces the project's sharpest trade-off. A cached answer is fast and stable, but it is frozen. If the underlying procedure changes and nobody updates the FAQ row, the system serves a confidently wrong answer at high speed, and it does so for exactly the questions that get asked most. The RAG branch is slower but reads from the current index.
The RAG branch runs a fixed sequence: hybrid retrieval over dense and sparse vectors, re-ranking with BGE-Reranker-Large, context augmentation, then generation with Qwen2.5-7B. The README also lists HyDE and sub-query decomposition as adaptive strategies, aimed at multi-hop questions where one retrieval pass is not enough. The offline layer is separate: documents are split, vectorized, and written into Milvus. Nothing in the README describes how the two layers stay in sync, which is the operational question that matters most once the system is live.
Installing it and running a first ingestion
The quick start assumes Docker and Docker Compose are already present. The first block is the clone, and it is worth reading closely before running it: the README still contains a placeholder owner in the URL, so you will need the real repository path.
git clone https://github.com/your-username/Industrial-Intelligent-QA.git
cd Industrial-Intelligent-RAGThe directory names in those two lines do not match each other, which is the kind of detail that tells you the quick start was written against a local working copy. Adjust both to whatever you actually clone.
Startup is a shell script or a direct Compose call. The script brings up Milvus, Redis, MySQL and the backend together.
chmod +x start_compose.sh
./start_compose.shIf you prefer to see the orchestration yourself, the README gives the direct form:
docker-compose up -d --buildOnce the containers are healthy, the knowledge base is empty. Documents go into the rag_qa/data directory, and the ingestion script walks them:
python rag_qa/core/ingest_data.pyAfter ingestion, the service exposes two endpoints. API documentation is at http://localhost:8000/docs and a health check at http://localhost:8000/health. The health endpoint is the one to poll while the embedding and rerank models load, because that is the slow part of a cold start.
There is a step the quick start does not cover. Five model checkpoints are required: bert_query_classifier, bert-base-chinese, bge-m3, bge-reranker-large, and nlp_bert_document-segmentation_chinese-base. The README points to a Baidu Pan link with extraction code h588, or to the models' official repositories. Without bert_query_classifier the router has nothing to classify with, and the README does not state what the system does in that case.
Where the documentation stops short
The repository has no licence file that the README names, and the licence is listed as unknown. For anything you intend to deploy inside a company, that is a blocker rather than a footnote. You cannot reason about redistribution or modification rights for code whose terms are not stated, and the model checkpoints carry their own separate terms that the README does not discuss at all.
The accuracy claim is the second thing to treat carefully. The README states that hybrid retrieval plus re-ranking boosts accuracy above 90 percent. No evaluation dataset, no baseline, and no per-metric breakdown appear in the README, even though the project ships RAGAS evaluation scripts under rag_qa/rag_assessment. That is an odd gap: the tooling to substantiate the number is in the tree, but the number itself is presented without it. Run the evaluation on your own corpus before repeating the figure internally.
The third gap is the FAQ threshold. A similarity cutoff of 0.85 is a single global constant in the described flow. Industrial vocabularies are full of near-identical part numbers and revision codes, which is precisely the setting where a high similarity score can pair two different answers. The README does not describe any per-category threshold or any guard against that class of collision.
Finally, the stack is Chinese-first. The query classifier is bert-base-chinese, the document segmentation model is nlp_bert_document-segmentation_chinese-base, and the linked tutorial is on CSDN. Nothing says the pipeline cannot handle other languages, but the tuned components are chosen for Chinese text and the README does not document behaviour outside it.
How it compares to a managed RAG service
The obvious alternative is a hosted retrieval service that handles chunking, embedding, indexing and generation behind an API. The difference is not quality, it is where the moving parts live. A managed service gives you one endpoint and no Milvus, Redis or MySQL to operate. industrial-general-rag gives you the opposite: four containers, five model checkpoints, and an ingestion script you run yourself.
What you buy with that burden is control over the retrieval strategy. The dual-branch design, the 0.85 FAQ cutoff, the choice to re-rank with BGE-Reranker-Large, and the option to add HyDE or sub-query decomposition are all decisions you can change in code. In a managed service those are configuration options at best, and often not exposed. If your corpus is a fixed set of industrial manuals and your questions cluster the way the FAQ branch assumes, the local design has a real cost advantage at query time.
What you give up is operational simplicity and, right now, licensing clarity. A managed service also comes with an evaluation story. Here the RAGAS scripts are present but the README does not walk through running them, so you are reading source to find the entry point.
Maintenance and upgrade cost
The last push to the default branch was on 2026-07-22, which is recent enough that the project has not gone quiet, but there are no tagged releases in the repository, so there is no version to pin against and no changelog to read before upgrading. You would be tracking main.
The upgrade surface is wide. Python 3.10 or later, LangChain, Transformers, Milvus, Redis, MySQL, RAGAS, Pandas and Matplotlib all move independently, and the docker-compose.yml pins whatever versions were current when it was written. Model checkpoints are a separate axis: swapping bge-m3 or bge-reranker-large changes retrieval behaviour and invalidates any cached vectors, which means a re-ingestion pass over the whole corpus.
On licence, the repository does not state one. Code with no declared licence is not automatically free to use, modify or redistribute, and the model checkpoints have their own terms from their publishers. That is a question for whoever handles licensing at your organization, and it is worth resolving before the first commit rather than after.
Editorial conclusion
Adopt it if you already run Milvus, Redis and MySQL, you are working in Chinese industrial text, and you want a working reference for intent routing plus hybrid retrieval rather than a packaged product. Do not adopt it if you need a licence you can read before shipping, if you expect a hosted API, or if your corpus is English-only and you have no way to obtain the BGE and BERT checkpoints. Verify three things first: the licence file, whether the router actually falls back when the BERT classifier is missing, and whether ingest_data.py can be pointed at your own document directory without editing source. The README's own quick start still clones from a placeholder URL, so treat the repository as a starting point to fork, not a dependency to install.
Frequently asked questions
What are the four levels of RAG?
The repository does not describe a four-level taxonomy. It documents one pipeline with two retrieval branches: a MySQL FAQ path with BM25 and Redis caching, and a Milvus RAG path using dense plus sparse hybrid retrieval with BGE-Reranker-Large re-ranking.
Is ChatGPT a RAG LLM?
The README does not discuss ChatGPT. industrial-general-rag uses Qwen2.5-7B for generation and keeps retrieval outside the model, in Milvus and MySQL, so the language model and the knowledge source are separate components.
Is RAG still relevant?
The repository treats retrieval as the mechanism that addresses knowledge latency and hallucination in a specialized domain, and pairs it with an FAQ cache so repeated questions skip retrieval entirely. It does not argue for or against RAG as a general technique.
Can you explain RAG in a simple way?
In this project, documents are split and vectorized into Milvus offline, then at query time the system retrieves relevant chunks, re-ranks them, and passes them to Qwen2.5-7B as context for the answer. The FAQ branch sits in front of that and answers known questions from MySQL and Redis without invoking the model.
Community notes