把企业手册变成会答话的机器人：知识问答怎么落地（AI 落地三形态·二）

AI 落地三形态 · 二/六 | 基于 Dify 1.17.0 社区版 + Hermes Agent v0.21.0 实测（2026-09，DeepSeek）

📖 摘要：企业里最值钱的知识锁在手册里——几百页设备文档、故障记录，平时没人翻、出事翻不到。本文讲一种生产环境验证过的落地形态：AI 执行体做入口与调度，Dify 承载知识库与问答应用，把「翻手册」变成「聊天里问一句」，答案带手册出处、置信度与示意图。为什么知识要放 Dify 不放 AI 执行体自己带（18 条用例双跑实测）、链路每个环节的设计取舍、三个生产里排过的坑——检索配置丢失、LLM 空输出、改写丢关键词。企业知识问答、Dify RAG、故障支持类 AI 项目参考。

本文是《AI 落地三形态》系列第二篇（二/六），讲形态二·知识问答——独立成文可直接阅读；想看三形态完整框架可先读系列零篇，或按序号顺序阅读。

先回答标题里的问题：把手册变成会答话的机器人，不是「把文档丢给 AI」，是把知识放进专门的知识库设施（Dify），让 AI 执行体做入口调度——答案带出处、格式稳定、图能回传。 我们为「知识放哪」做过 18 条固定用例的双路实测：知识随执行体自己带 vs 知识放 Dify 应用——结论是知识库设施在输出契约稳定、图回传可靠、回答聚焦三个维度明显胜出。这篇把链路每个环节的设计取舍、三个生产环境排过的坑讲清楚。

---

一、场景：值班的人，不翻手册了

一个真实的场景：企业网络设备出了状况，值班工程师以前的做法——凌晨被电话叫起来，翻几百页的手册找排查流程，找到流程图还得对着型号找差异，一通折腾一小时。现在不用了：在聊天工具里问一句「这个告警怎么处理」，机器人十几秒内回来一段带格式的回答——结论是什么、置信度多高、依据在哪一页、建议怎么修、有没有风险提示，手册里的诊断流程图直接带在答案里。

「聊天里问一句，答案带出处」——这个体验的生产运行形态，就是本文要讲的形态二（知识问答）。它不是把手册丢进聊天窗口，背后是一条完整的链路。

二、为什么知识放 Dify，不放 AI 执行体自己带

这是形态二最先要回答的问题：AI 执行体本身有记忆、有文件系统，为什么知识不随它带，要单独放一套知识库设施？

因为我们做过实测定论。同一批知识问答用例（18 条固定问题），两条路各跑一遍对比：A 路是执行体直连检索库自己组织答案；B 路是执行体调 Dify 应用（应用承载检索与组织）。

先说对比怎么做的（方法值得抄）：固定 18 条用例——覆盖手册问答的典型形态（这是什么、为什么、怎么办、带不带图、跨章节综合问题）——两条路逐条跑同样的输入；检索参数锁死（候选数、阈值、是否 rerank 都固定），不调参追答案；每条结果落盘、逐条归因。跑完不是看「答对几条」——是看「同样的问题，两条路的答案形态差在哪」。

结论是 B 路明显胜出，三个决定性维度：

1. 输出契约稳定。 应用里把回答格式锁死成五段式——结论、置信度、依据、修复建议、风险提示。读者收到的答案永远长一个样：可预期、可验收、可对接流程。A 路让执行体自由组织时，格式会漂移——同一批问题，今天带出处明天不带，今天有条理明天是一段话。格式的专业性本身就是答案质量的一部分——最开始我们以为 A 路更灵活是优点，跑完 18 条才明白：知识问答场景里，稳定性比灵活性值钱。

2. 图回传可靠。 技术手册图文并茂——诊断流程图、组网图是答案价值的一半。B 路有图清单机制：检索命中段落含图，就通过清单把物理图文件带回，稳定出现在回答里。A 路靠执行体临场发挥，图时有时无，换会话后可能彻底丢。

3. 回答聚焦。 知识管理是重资产——文档清洗、分段策略、混合检索参数、rerank、命中测试、版本更新。这套设施在 Dify 里是成熟产品；放在执行体侧等于自造轮子还要自己维护。知识问答的交付质量，七成在知识库建设——这件事应该交给专门的设施，而不是让执行体兼职。

还有个成本维度要正面回答：多维护一套 Dify，值不值？Dify 社区版开源、自部署不花授权费，额外成本是部署一台服务（执行体本来也要跑机器，多一个容器的事）；而执行体自带知识的「零成本」是假零成本——知识多了之后（检索找不着、答案漂移、没出处），返工成本会吃掉省下的部署费。判断：知识少到执行体记忆扛得住，形态一更省；知识到了要管理要出处的规模，Dify 的部署成本是固定的小头，检索与契约能力是长期的大头。

三、链路解剖：五个环节，各管一段

形态二端到端的链路：聊天工具 → 执行体（入口与调度）→ Dify 应用（知识库 + 问答）→ 成品答案 → 回聊天工具。五个环节，每个都有设计取舍：

环节 1：执行体做入口与调度。 执行体不抢戏——它做三件事：接收提问、判断问题类型（要不要改写、路由到哪个库）、把 Dify 应用的成品答案带回聊天工具。为什么不让用户直接开 Dify 的页面？因为入口要长在用户已经在的地方（聊天工具），而且执行体能承接多平台入口的差异。

环节 2：改写闸门。 用户的提问口语化（「那个 502 是咋回事」），直接拿去检索命中率低——先改写成检索友好的关键词组合。但改写是概率环节，可能丢词：实测排过一个坑——改写把「接口返回超时」里的「超时」丢了，检索直接跑偏。解法是确定性闸门：改写结果与原问题做关键词覆盖比对，丢得太多就放弃改写、用原问题直查。AI 链路里的概率性环节，都要有确定性闸门兜底——这是这套链路反复验证的教训。

环节 3：多库检索与 rerank。 手册按分册建多个库（配置指导、故障处理、告警参考各有独立库），按问题类型路由到对应库，混合检索取候选，再经 rerank 重排。参数按库独立配置：故障处理库的问题大多是「现象→原因」形态，要求准——混合检索 + rerank + 较大候选数（先多捞再重排，相关的别漏）；配置举例类的问题要求「整段完整配置」，分段粒度比候选数更关键——同一个库换了分段策略，命中质量明显提升。还有分数阈值：低于阈值的段落直接不返回，宁缺毋滥——避免 LLM 拿不相关的段落硬答（答案「看起来合理但依据是错的」）。检索参数按库调优的更多实例与 18 条双跑全过程，在门户完整记录《把企业手册变成会答话的机器人：知识问答形态》里有完整展开。

环节 4：LLM 按契约组织答案。 检索到的片段交给 LLM，按五段式契约组织：结论/置信度/依据/修复建议/风险提示，只依据片段内容、带来源标注、覆盖不到如实说。这个环节的坑是偶发空输出：模型偶尔把答案全写进思考过程、正文返回空——节点状态显示成功，实际输出是空的。解法同样是确定性兜底：正文过短就走固定文案（「手册中未找到相关说明，建议查阅官方分册」），绝不把空回答给用户。

环节 5：图清单回传。 手册里的流程图在清洗入库时被独立检测出来保存，建立图清单索引（图 ID → 所属章节 → 关联段落 → 物理路径）。回答时命中段落含图引用，就通过索引反查物理文件，随答案带回聊天工具——这就是回答里【图】那一行的来源。图的可靠性是整个链路最容易被忽视、也最影响体验的一环（图从手册到答案的四道关，本系列（四）清洗方法论里单独讲透）。

四、三个生产里排过的坑

这套链路在生产环境跑，坑排过一轮。挑三个最有代表性的，都指向同一教训：AI 链路里的概率性环节，都要有确定性闸门兜底。

坑一：「突然没图了」是假故障，真问题是检索配置丢了

某次线上反馈：机器人回答里【图】那一行消失了——之前一直好好的，突然所有带图的答案都不带图了。第一反应查图回传机制（图清单、物理路径反查），翻遍代码没找到问题。最后排查到知识库本身：库级的检索配置在迁移中悄悄丢了——回退成了默认参数（纯语义检索、候选数变小、无 rerank），检索命中的段落恰好都不含图，图清单永远是空的。

教训：遇到「应用突然无图/检索质量变差」，先查库级检索配置是否还在，别先怀疑应用逻辑和图提取链路。检索配置是数据层的状态，迁移、重启、误操作都可能动它，失效时的症状（无图/答不准）容易被误判成应用 bug。更进一步：配置核对要进上线检查清单——每次发布/迁移后，按清单核对库级检索配置、路由参数、图库关联是否在位，而不是等用户反馈「没图了」再倒查。配置类故障的预防成本远低于排查成本。

坑二：LLM 偶发空输出——状态成功，内容是空的

模型偶尔把答案全写进思考过程、正文返回空。节点状态显示成功——输出却是空的。如果流程只判断「成功」不看内容，空输出就会一路传到用户面前。

修法是确定性兜底：LLM 输出过短就走固定兜底文案（「手册中未找到相关说明，建议查阅官方分册」），同时在契约里强制要求结构化（JSON 或固定分段），解析失败同样走兜底。生产环境里，「状态成功但内容是空的」比「状态失败」更危险——失败能被看见，空内容会被当成正常回答送出去。

坑三：查询改写丢关键词——改写救了召回，丢了召回

用户口语化提问先改写再检索，是提召回的常规操作。但改写是概率环节：实测排过「改写后丢了关键约束词」——问题里最重要的限定词被改写没了，检索命中一堆不相关的段落，答案自然跑偏。

修法：改写结果和原问题做关键信息覆盖比对——限定词、专有名词、数字这类必须保留；覆盖不足就放弃改写结果，用原问题直查。改写的价值是提召回，但不能以丢关键信息为代价——这一条写进了我们的链路设计原则。

五、适用边界与上线后的事

形态二适合：手册/规范/故障记录类知识要多人高频查询的；答案必须带出处（员工要依据才采信）的；文档图文并茂（图是答案一半）的。不适合：知识很小（几十页、单人偶尔翻——形态一更省）；要真操作系统的（那是形态三的活，形态二只答不碰）；对答案实时性要求极高的（知识库更新有周期）。

上线之后还有持续运维：文档更新了要重新清洗入库、检索质量要定期命中测试、新分册要加库加路由。命中测试是检索质量的「体检」：维护一组固定问题集（几十条，覆盖各分册、各问答形态），每次知识库变动后跑一遍——看同样的问题，命中率有没有下降、答案引用的段落对不对。这套问题集就像回归测试——不跑，就不知道一次文档更新是不是把检索带偏了。实测里「更新后检索变差」是常态风险：新文档的分段风格和旧库不一致、覆盖了旧内容但索引没跟上，都可能让命中质量悄悄下滑。上线三个月后的质量，取决于运维机制而不取决于当初的搭建水平。

成本量级参考：模型 key 由使用方自备；知识库建设按文档量与清洗难度计——清洗是其中最大头（工时占比过半），完整方法见本系列（四）。

常见问题

直接丢给通用大模型不就行了吗？为什么要建知识库？

通用大模型对「公开知识」很强，但对「你们公司手册里写的私有配置」一无所知——你不告诉它，它只能编。知识库解决的问题是「只依据手册内容回答 + 带出处」：检索命中哪段就据哪段答，答不了如实说，不乱编。判断标准：答案能不能接受「没依据就明说」？能接受才谈得上知识库，否则模型再大也会自信地编。

员工问的问题五花八门，怎么保证检索都命中？

三层兜底：改写闸门（口语化问题先改写，丢关键信息就放弃改写直查）、多库路由（按问题类型路由到对应库，参数按库调优）、命中测试（固定问题集定期回归——更新后检索变差能第一时间发现）。三层都过还答不好的问题，进标注迭代——生产环境里检索质量是养出来的，不是一次配出来的。

手册会更新，知识库怎么跟着变？

流程是：新文档进库前重新清洗 + 分段 + 入库，旧文档按版本归档或替换，然后跑命中测试验证更新没把检索质量带偏。这套运维机制决定问答质量能维持多久——交付时会包含知识更新的标准流程文档。

💬 你见过「知识库答得自信但依据是错的」吗？当时怎么排查出来的？评论区聊聊。

相关文章：RAG知识库，如何进行持续更新运维（手册更新后知识库怎么跟着变——本文 FAQ 的完整展开）｜RAG 知识库建库前，数据到底该怎么清洗？一条可复用的清洗管线实测（入库前的清洗环节怎么自动化落地）
📚 更多实战记录见我的博客：鱼日先生

本文基于 Dify 1.17.0 社区版 + Hermes Agent v0.21.0 实测。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。