为什么是 Dify + Qwen3
企业内部问答系统看上去门槛不高，真做起来常被三件事卡住：文档格式乱、回答容易一本正经地胡说、权限不知道该收到多细。
Dify 在 2026 年仍是国内最常用的开源 LLMOps 平台之一，工作流、知识库、Agent 编排和 API 化能力都是开箱即用，对照官方《使用知识库搭建智能客服机器人》一文就能完成基础客服场景的搭建。Qwen3 则补齐了模型侧——通义千问 Qwen3 系列在 2025 年下半年发布后，已经成为国内知识库问答场景的常驻选项，从轻量版本到 Qwen3-32B 都有可商用的部署方案。CSDN 在 2026 年 3 月的一篇实战文章里，就把 Qwen3-32B 跑在星图 GPU 平台上、与 Dify 拼成企业级问答系统作为完整案例展示。
这套组合的优势是省事：Dify 负责数据切片、检索增强生成（RAG）流程和权限，Qwen3 负责语言理解与生成。它不是性能最强的组合，但部署路径最短，调试点最可控。
下文按企业实战顺序拆解：先把原始文档洗成结构化语料，再接 Dify 知识库，最后用工作流串起检索、生成和兜底回复。
第一步：文档清洗与分段
真实企业的语料大多是这样：PDF 里嵌着扫描件、Confluence 里是随处可见的表格，还有从邮件里复制出来带样式标签的 HTML。直接丢给 Dify，效果不会好。
清洗阶段的目标只有一个：让每个分段都能独立被理解。常见的做法是：
- 把扫描件先 OCR，常用 PaddleOCR 或云服务商的文档识别接口；如果你的语料里有大量历史合同、发票、调度日志，这一步不能省——参考《北京亦庄 Robotaxi 夏日体验》一文提到的车队文档处理思路也一样，原始数据不规整，后面的模型很努力也救不回来。
- HTML 和 Markdown 文档要保留标题层级，Dify 的分段器会根据标题重新切片，丢掉层级相当于把上下文揉碎。
- 表格单独处理，要么转成 Markdown 表格保留行/列结构，要么转成"列名：值"的句子。Qwen3 对 Markdown 表格的解析明显比裸文本更稳。
- 文件名和作者元数据保留一份进元数据库，后面做权限控制会用到。
Dify 内置的分段策略有"通用分段"和"父子分段"两种。多数企业问答场景建议先用"父子分段"：父块负责定位召回，子块负责喂给模型，能明显降低 Qwen3 拿到错误片段后编造答案的概率。
第二步：在 Dify 里接 Qwen3
Dify 的模型供应商列表里，阿里通义千问是内置项，配置相对简单：
- 在 Dify 后台"设置 - 模型供应商"里找到通义千问，填入百炼平台或阿里云灵积的 API Key。如果走自部署，Qwen3-32B 在 H20、H200 这类卡上推理速度较稳；如果走 API，注意 Qwen3 系列不同尺寸的上下文窗口差异较大，长文档问答建议选 32B 以上的版本。
- 在"工作室"里新建一个"知识库"应用，把清洗好的文档批量上传。Dify 1.x 版本对 PDF、Word、Markdown、网页的支持已经比较完整。
- 索引方式选"高质量"，Embedding 模型可以先用 BGE-M3 或通义自带的 text-embedding-v3，等跑通流程再换。
- 召回测试先用一组不参与训练的内部问题验证一遍，看 Top-K 召回的片段有没有把关键段落漏掉，漏的多就要回头重切。
第三步：工作流的四个关键节点
知识库接好后，真正的差别出在工作流编排。Dify 的工作流节点很直观，关键在于顺序设计：
- 问题分类：用 Qwen3 先把用户提问分成"事实查询/流程咨询/跨文档归纳/闲聊"。不同类别走不同分支，能拦掉一大半离题问题。
- 知识库检索：根据分类动态调整 Top-K 和相似度阈值。事实查询保留 Top-K=3、阈值 0.5 以上；跨文档归纳可以放大到 Top-K=8、阈值放宽到 0.3，宁可多召回再让模型筛。
- 提示词模板：这是最容易踩坑的地方。模板里必须包含三类信息——角色定义、检索片段、回答约束。回答约束建议明确写出"如果检索片段没有覆盖答案，请直接回答不知道，不要补全"，这是抑制幻觉最直接的办法。
- 兜底回复：当相似度低于设定阈值、或者连续两次检索都空时，进入兜底分支，转人工或给出标准应答。这一点对企业场景特别关键，参考《欧盟 AI 法案生效后，出海 SaaS 先做这份合规自查》一文，自动拒答比强行回答更符合合规要求。
如果想走更深的链路，可以参考《LangGraph 多 Agent 客服，难点在派单和接管》一文的思路，把咨询、技术支持、投诉等不同业务线拆成子 Agent，再由一个路由节点统一调度。Dify 工作流里也能做类似的事，只是节点名字换成"问题分类器 + 多分支 + 聚合"。
第四步：权限设置与审计
企业内部问答最容易出的事故不是模型答错，而是把不在用户权限内的文档检索出来，再被模型原样念出来。
Dify 的知识库支持在数据集级别配置访问 API Key，但更细的字段级权限需要你自己写一层代理。建议两步走：
- 用户层：先用 SSO 或企业微信/钉钉的 OAuth 登录，把用户 ID、部门、角色带进请求头。
- 文档层：每份文档入库时打上"可见部门 + 可见角色"的标签，检索阶段先按标签过滤再做向量召回。这样权限泄漏的风险就锁在检索阶段，模型根本看不到不该看的段落。
审计上，把每一次问答的"问题 + 召回片段 + 模型回答 + 用户反馈"落到日志表里，保留至少 90 天。出问题时能定位是哪一批文档、哪一版提示词出的故障。AI Agent 在中小企业部署时也常见类似的预算失控、记录缺失问题，可以对照《中小企业部署 AI Agent，先把账单和 ROI 算明白》一文调整自己的预算与审计 SOP。
第五步：上线前后的常见坑
照着上面四步走完，多数团队能跑通。但上线前还有几个真实场景容易踩到：
- 文档更新滞后：内部制度文档每周都在改，知识库还是旧版。解法是接 Dify 的 API 做定时同步，或者把文档源换成 Notion/语雀这类自带版本控制的平台。
- 端侧协作机器人卡顿：把同一个问答系统接进飞书/钉钉机器人后，问题长度经常被截断。检查机器人 webhook 的消息体长度上限，必要时在 Dify 侧先做摘要。端侧运行 Qwen3 系列目前仍不现实，可以参考《六款手机端侧大模型实测：能跑不等于好用》了解 70 亿参数模型在端侧的实际表现，但要把它当手机端体验，不是企业级问答的主战场。
- 算力成本：Qwen3-32B 自部署的单卡显存占用高，Baseten、B200 价格上行后，云推理单价压力上升（详见《Baseten 调价后，昇腾 910D 和 B200 的账怎么比》），国产卡如昇腾 910C、910D 在企业私有化场景下成为更稳的选择，运维避坑可以参考《昇腾 910C 扩到千卡，先把六本运维账算清》一文。
- 长尾问题比例高：开放给全员后，前 20% 的问题往往覆盖 80% 的提问。把这些高频问题抽出来做成 FAQ 走"直接命中"通道，只把长尾留给 RAG 链路，能显著降低单次问答成本。
按这五步走完，团队通常能在两天内拿到一个能上线试用的内部问答机器人雏形，剩下的就是根据真实问题持续调整提示词和分段策略。Qwen3（来自阿里通义实验室）和 Dify（开源 LLMOps 平台）的组合在国内属于成熟方案，关键不在工具本身，而在文档清洗、权限边界与兜底设计这三件容易偷懒的事。
参考链接：Dify 官方文档「使用知识库搭建智能客服机器人」、CSDN《企业 AI 应用实战：用 Dify 和 Qwen3-32B 搭建知识库问答系统》、Anspire 最佳实践《十分钟基于 Qwen3 和 Dify 构建一个深度联网搜索机器人》
