企业RAG三件套：MinerU+Dify+灿海星图，一个下午跑通

上周一个做财税的朋友来问我："金哥，我们公司有3000份历史合同，能不能让AI自动查合同条款？"

我说能，但是你得把三件东西串起来。他问哪三件。我说：文档解析、RAG框架、模型API。

他以为是在买软件——装一个就完了。不是的。企业AI知识库现在是"组装"的，不是"购买"的。但这三件套配齐之后，确实一个下午能跑通。

MinerU负责把文档变成LLM能读的格式，Dify负责搭检索和问答工作流，灿海星图负责提供推理API。

第一步：MinerU解析文档

pip install magic-pdf
magic-pdf -p "./公司文档/" -o "./rag_data/" --batch --workers 4

PDF、Word、PPT全部转成Markdown。表格、图片、标题层级全部保留。3000份文档，4个进程，约45分钟。

第二步：Dify搭建RAG工作流

Dify里创建知识库→上传MinerU输出的Markdown→选择向量模型（推荐BGE-large-zh）→创建应用→选"对话型"。

第三步：接入灿海星图API

Dify的模型提供商里，选"OpenAI兼容"，填灿海星图的API地址和Key。选DeepSeek-V4-Flash或GLM-5.2作为推理模型。企业AI知识库问答系统搭建完成。

踩坑实录

坑1：向量检索top_k太大。 top_k设超过10准确率反而下降。建议保持5-8。

坑2：切块大小不对导致答非所问。 512字符对中文合同效果好，但技术手册这类短段落文档需要256-384。切太大了上下文噪音多，切太小了语义不完整。

坑3：问题里包含多个子问题时，RAG只检索到部分信息。 比如"对比2023年和2024年的违约金条款变化"，检索可能只找到2023年的。解法：Dify里开多轮检索，或用query分解把问题拆成子问题分别检索。

效果验证

上传一份10页的合同PDF，提问"违约金条款在第几页、金额是多少"。检查：答案是否引用原文、页码是否正确、金额是否精确。

延伸思考

BGE-large-zh和通用多语言embedding到底差在哪？ 文档说BGE-large-zh对中文合同的理解优于text-embedding-3，但具体测试数据在哪？MTEB中文榜单BGE-large-zh确实是榜首，但那是对新闻、百科类文本的评测。合同文本有大量法律术语和固定句式，BGE在这类垂直文本上的表现有没有独立评测？

增量更新是怎么做到不丢上下文关联的？ Dify的知识库支持增量re-embedding——只对新文件做向量化。但如果新文件和旧文件有语义关联（比如一份新合同引用了旧合同的条款），检索时会不会因为它们的向量是不同批次生成的，导致关联性下降？这个问题在真实企业场景里很常见但文档没提。

常见疑问

Q1：为什么推荐BGE-large-zh作为向量模型？

BGE-large-zh在中文语义检索的MTEB基准上排名靠前，对合同、政策这类正式文档的段落级语义理解优于通用多语言模型。另外它是开源模型，可本地部署，避免了把企业文档发给第三方embedding API的合规风险。

Q2：3000份文档跑这套流程，硬件和成本大概多少？

MinerU解析3000份PDF，4核CPU约45分钟，几乎零成本。向量化用BGE-large-zh本地部署需要8G以上显存GPU，处理embedding约10-20分钟。推理走灿海星图API按token计费，一次问答约0.01-0.05元。一台32G内存+RTX 3060能跑通全流程。

Q3：文档更新了需要重新跑全流程吗？

不需要。MinerU支持增量处理。Dify知识库也支持增量re-embedding。频繁变动的文档库建议设置定时任务每晚跑增量更新。

下一步

• MinerU GitHub：https://github.com/opendatalab/MinerU
• Dify官网：https://dify.ai
• 灿海星图API：看我置顶的《Claude Code接入灿海星图完整指南》

本文数据来源于互联网公开信息（GitHub opendatalab/MinerU, Dify官网），仅供行业趋势参考。