缘起2025.11.30我决定做一个企业级知识库项目原因可能是有了一些工作上或者学习生活中的积累决定差不多了。帮助别人做了glyph这个项目拿到了国二差不多就是工作空隙时间20天左右我是10月初开始接触vibe coding的那时候 codex claude code 还流口水整个项目的设计哲学还得参考我之前写的项目。到11.30底的时候其实claude code codex已经可用了然后我开始着手去做知识库。我的设计哲学就是让rag 每一部分做到可监控。 我希望这个知识库可以回答或者如果没法召回能够如何调整怎么切块怎么实体抽取怎么治理元数据怎么召回。 把它做成一个标准流程同时可管理。把rag的每一步都做到极致那么得到的就是一个极致的rag了。整个项目在市级的智能助手上验证过下面我会贴出一点测试报告。 我不会去试图解答什么但是这个项目会给做企业级rag的佬们一点启发。知识库管理MimirQ 将知识库拆成几个能够单独检查的阶段文档解析支持 DeepDoc、MinerU、Docling、MarkItDown、OCR 与 VLM 等不同路径可以按文档类型选择。数据治理支持规则 DSL、脚本和插件清洗并提供解析结果、文档质量和处理状态检查。切块与索引支持递归、标题、父子块、语义切块、RAPTOR、Late Chunking 等策略以及 Milvus、FAISS、Chroma。检索与重排支持 BM25、向量检索、混合召回、RRF、ColBERT、Cross-Encoder 等组合。证据与评测提供检索 Trace、重排过程、逐句引用、版本追踪、RAGAS 和 Golden 题集回归。企业治理包含文档 ACL、RBAC、Security Trimming、脱敏、审计和安全护栏。仓库目前覆盖 30 个解析后端、86 种切块策略和 13 类重排器。数量不是最终目的重点是每一个环节都能检查输入输出并能通过固定题集持续回归。主流解析支持入库到证据评测知识图谱作为检索的一环知识图谱主流的解法一个是kg-rag 第二个是graphrag 前者不够灵活后者的话资源消耗太大了所以企业里面很少用graphrag因为他的检索成本很难接受退而求其次可能Lightrag已经是最高能够接受的grphrag方案这里我们借鉴了sag的思路把chunk 抽取事件然后作为元数据去管理显著降低召回该分支的时延。直接接入 Dify关于dify, 我想这个知识库应该类似ragflow那样支持外链到dify中去。我们没有在 MimirQ 里重复实现 Dify 工作流画布这部分是dify的很强的优点也最优特色部分了 dify一切都很好只是知识库有点弱项。让它作为可治理的外部知识层接入现有应用。 目前支持 Dify External Knowledge API 和 Workflow HTTP 节点。 支持直接接入dify也可以通过接口接入。对比实验后续MimirQ 还远谈不上完美。但是能给佬们一些启示其实在4月份的时候我已经做不下去了那时候我已经积累相当多的内容了真正好的rag系统肯定是基于业务来谈的诸如dify、mimirq、ragflow 、fastgpt等等之类的大家做着做着都变成通用了如果让我做一个rag我可能不会选择这些因为消耗的精力可能比我直接做来的更多。知识库 整个流程是 文档解析mineru or deepdoc-文档治理(脚本规则 dsl)-切块 递归、父子块 等等- 入库向量库-》召回混合召回等等 bm25向量检索ragflow的优势在于deepdoc graphrag 图谱 其他优势很小 ragflow 是可以代替dify的知识库作为外链知识库但是实际我们使用下来很多工程问题。 ragflow其实不是大部分企业的优选当然业务简单用平台更容易如果是一个稳定的业务流程可能是这样的。 客户数据拿来第一步先 拿一批数据做评估 比如pdf里有多少图片 有多少文字 等等报价 这一步用mineru 现在效果最好解析完了后。知道收多少钱后。开始正式做业务 第一步 按照不同业务选择不同解析模型 复杂排版不可编辑用mineru,公式很多的数学书用docling,都是txt文字的用markitdown, 没算力可以上deepdoc(这些有人抽出来)之后人工清洗整理解析后的文章然后做切块 根据业务来切 不要死的重叠快切一般800主流比如根据文章切 标题啥的这类ragflow有设计可以参考切完后 入库一般选Milvus 主流。 然后 整个rag就做好了 整个流程搭建 任意框架 哪怕直接pythonpydantic都能实现这个在业务上是完全可控的 如果你要做聊天助手那么复杂的用langgraph 涉及到图路由的web search kg rag等 a2a 如果简单的直接用pydantic-ai 这样设计。