用 Dify + 开源模型 3 天搭一个企业文档 Agent

引言

客户是一家做工程项目管理的中小企业，内部积累了 6 年的项目档案（约 1.2 万份 PDF/Word）。老板希望员工可以用自然语言提问直接拿到答案，而不是翻目录找文件。这个需求最终用 Dify + 开源模型在 3 天内搭出了一个能用的内部问答 Agent。本文是实操记录，不是教程——只记录我做了什么、花了多少时间、踩了哪些坑。

时间分配

3 天的工作量是这样切的：

时段	工作内容
第 1 天上午	部署 Dify（Docker Compose），建工作流骨架
第 1 天下午	文档导入（PDF/Word 解析 + 分块），搭知识库
第 2 天上午	接入开源 LLM（Qwen2.5-7B-Instruct，本机推理）
第 2 天下午	调检索策略、Top-K、rerank，写 API 调用层
第 3 天上午	对接客户 IM（飞书机器人）
第 3 天下午	压力测试 + 调提示词 + 验收

关键决策点

为什么用开源模型而不是 API： 客户的项目文档涉及未公开报价单和分包合同，明确要求“数据不出域”。开源模型本机推理虽然慢（首字 2-3 秒），但满足这个硬约束。云 API 哪怕签 DPA 也需要走外网。

为什么用 Dify 而不是自己写 LangChain： 独立运营没有时间维护一套 RAG 框架。Dify 把文档解析、向量化、检索、提示词编排、API 暴露都做完了，工作量从 2 周压缩到 3 天。代价是定制空间小——遇到 Dify 不支持的检索策略就只能绕路。

为什么不上 rerank 模型： 第 2 天试了 bge-reranker-base，提升幅度有限（从 72% → 78%），但首字延迟从 2 秒涨到 4 秒。客户场景是内部工具，78% 已经够用，rerank 上线就关掉了。

踩坑清单

• PDF 解析丢失表格： 客户档案里有大量项目报价表，pypdf 解析后表格结构丢了。第 2 天换成 PyMuPDF，加了表格识别重排。
• Embedding 模型选错： 第一版用了 text2vec-base-chinese，中文文档召回率惨不忍睹。换 bge-large-zh-v1.5 后召回率从 41% 升到 73%。
• 飞书机器人 webhook 鉴权： 飞书 v2 API 需要 tenant_access_token，每 2 小时过期。dify 的 webhook 节点没有内置刷新逻辑，自己写了个小函数轮换。

结语

3 天交付是极限速度，不是有意为之。后续该补的：监控埋点、badcase 收集、季度模型评估。第 4 天客户的 12 个员工上线使用，第 7 天累计对话 800+ 条，目前还在稳定跑。

如果你的团队也在做类似的内部知识问答搭建，欢迎预约一次 AI 可行性诊断 — 1 个工作日内回方案与报价。