我花了一天重做一个企业问答机器人，终于解决了机器人回答幻觉问题

Hi，大家好，我是七帅。

最近，我重新做了一次企业内部的人力制度问答 Agent。

一开始，我只是想解决一个很具体的问题：员工有制度问题时，不用翻几十份文件，直接问一句话，系统就能给出答案。

但真正做起来以后，我发现，这并不是简单地把文件上传到知识库，再接一个大模型。

中间我走了一些弯路，也重新思考了一个问题：

企业 AI 到底应该追求什么？是回答得越多越好，还是回答得更可靠？

这次调整之后，我的答案变得很明确：

企业知识库问答最重要的，不是让 AI 显得什么都懂，而是让它只在有依据的时候回答。

一开始，我想做的是一个通用 RAG 系统

最开始，我提出的是一个比较完整的 RAG 优化需求。

我希望解决两个问题。

第一个问题是，Agent 容易产生幻觉。

知识库里没有明确写过的内容，它可能会根据常识、经验或者模型记忆，自己补充一个听起来合理的答案。

比如员工询问某项福利、薪酬或待遇政策时，如果制度材料里没有明确规定，系统就不应该自己猜测。

但实际使用中，很多 AI 都会犯这个问题。

它们不一定是在故意胡说，而是模型习惯了“尽量给出一个完整答案”。当资料不足时，它会下意识地把缺失部分补齐。

第二个问题是，知识库里明明有答案，却经常检索不到。

员工问的是：

“这个假怎么休？”

制度文件里可能写的是：

“员工休假按照相关管理规定执行。”

员工说的是人话，制度写的是规范语言。两者表达方式不同，系统就可能匹配失败。

所以我最初考虑了很多优化方向：

• 把制度内容整理成 FAQ；
• 给知识片段增加标题和关键词；
• 优化切块方式；
• 增加关键词检索；
• 让用户问题先经过改写；
• 让回答带上引用；
• 没有依据时进行拒答。

从技术角度看，这些方向都合理。

但后来我发现，我一开始就把事情做复杂了。

第一次调整，我发现方向偏了

当时我把注意力放在“怎么优化 RAG”上，却没有先确认 Dify 里已经存在的 Agent 和知识库。

我后来直接指出：

“我这个 Dify 明明有一个知识库的啊，就这个。我要的是人力资源部的制度解答啊。”

这句话看起来只是纠正了一下方向，但实际上，它重新定义了整个项目。

我真正需要的，并不是一个什么问题都能回答的通用知识库机器人。

我需要的是：

一个专门回答企业人力资源制度问题的 Agent。

这两个目标看起来很接近，实际上差别很大。

前者关注的是“系统能不能回答更多问题”，后者关注的是“系统能不能在明确范围内回答正确”。

所以我重新确认了三个问题：

如果这几个问题没有先确认，后面的优化很可能都是在优化错误的对象。

我最担心的，是原来的知识库被改乱

在调整过程中，我又遇到了一个问题。

我担心之前的知识库被修改得太多，影响其他业务使用，所以我问：

“之前修改的那个知识库变化大不大？还能改回去吗？”

这个问题其实比“怎么提高召回率”更重要。

因为企业知识库不是一次性的测试文件。里面的内容可能已经被其他 Agent 使用，也可能是其他流程的资料来源。

如果为了满足一个新需求，直接覆盖原来的知识库，表面上看是完成了新功能，实际上可能会影响原来的业务。

所以我明确要求：

“把之前的知识库恢复成原样。再做人力资源部制度这个新的知识库，不碰其他任何内容。”

这一步确定了整个项目的边界：

• 原来的知识库恢复并保留；
• 新的人力制度资料单独建立知识库；
• 不修改其他知识库；
• 不影响其他 Agent；
• 只调整当前这个人力制度问答 Agent。

我后来越来越觉得，企业 AI 项目里，“不碰什么”有时候和“要做什么”同样重要。

我让助手重新建立独立的人力制度知识库

确认范围之后，我让助手根据企业内部的人力资源制度资料，建立一个新的独立知识库。

这个知识库主要覆盖：

• 员工福利；
• 薪酬管理；
• 考勤与休假；
• 招聘与录用；
• 员工异动；
• 培训管理；
• 福利待遇；
• 其他人力资源管理规定。

我没有让它继续混用原来的综合知识库。

原因很简单：

员工问人力制度问题时，我希望 Agent 只从人力制度资料中寻找答案，而不是从其他业务材料里“顺便找一个看起来相关的内容”。

知识库边界越清楚，回答就越容易控制。

员工说的是人话，制度写的是规范语言

新的知识库建立之后，我又重点调整了检索逻辑。

我明确要求：

不能直接拿用户原话去知识库匹配。

因为员工提问很少会使用制度文件里的正式表述。

例如，员工可能会问：

• “我能不能休这个假？”
• “这个福利我能申请吗？”
• “要准备什么材料？”
• “这个政策什么时候开始？”
• “夫妻两个人都能申请吗？”

这些说法不一样，但背后可能对应同一个制度主题。

所以，我让 Agent 在正式检索之前，增加一个“问题理解和检索改写”环节。

这个环节不负责回答问题，只负责理解用户真正想问什么：

• 是在问条件，还是在问流程；
• 是在问时间，还是在问金额；
• 是在问自己能不能申请，还是在问所有人是否适用；
• 用户使用的是不是口语、省略表达或同义词。

但我也给它设置了边界：

可以理解用户表达，但不能擅自补充用户没有提供的事实。

比如用户只问“工资什么时候调整”，系统可以理解为“薪酬调整时间或相关政策”，但不能自己补充“明年”“所有员工”或者“具体涨幅”。

我要求 Agent 只有在有证据时才能回答

这是整个调整中最核心的一步。

我要求 Agent 遵循一个简单原则：

只有制度资料中存在能够直接支持结论的明确条款，才能回答。

这意味着以下内容不能靠推测补充：

• 具体数字；
• 日期；
• 金额；
• 比例；
• 年限；
• 适用条件；
• 例外情况；
• 办理流程。

如果员工问：

“明年是不是所有人都会涨薪？具体涨多少？”

而制度资料中没有明确写出这些内容，那么系统就不能根据常识回答“可能会涨”“一般每年都会调整”或者“预计涨几个百分点”。

我要求它统一回复：

现有制度材料中未找到关于该问题的明确条款，无法据此作答，请联系人力资源部门确认。

我宁可让 Agent 承认“资料里没有明确答案”，也不希望它给出一个听起来合理、实际上没有依据的结论。

回答不能只给结论，还要告诉我依据是什么

对于知识库里有明确答案的问题，我要求正式回答尽量包含：

这样，员工看到的就不只是一个答案，而是一条可以被核对的信息。

这也能帮助人力资源部门判断：这个答案是不是来自正确的制度，系统有没有把不同规定混在一起。

我还要求移除旧知识库的绑定

在调整前，当前 Agent 还使用着原来的综合知识库。

为了避免不同业务资料相互干扰，我要求把原知识库从当前 Agent 的绑定关系中移除，只保留新建立的人力制度知识库。

这里需要特别说明：

我没有删除原来的知识库，也没有修改原知识库本身。

我只是要求当前这个 Agent 不再调用它。

这也是我一直强调“不碰其他任何内容”的原因。

新需求就用新的知识库解决，旧资料继续保留，两个范围分开管理。

我不接受只说“改好了”，一定要测试

我还特别要求，不能只检查工作流页面上的节点有没有连接，也不能只看系统有没有自动保存。

修改之后，必须重新发布，并进行真实问答测试。

我让助手至少测试两类问题。

一类是知识库里有明确答案的问题

例如员工询问某项休假、福利或办理条件。

系统需要能够找到对应制度内容，回答适用条件和办理要求，并提供资料来源。

另一类是知识库里没有明确答案的问题

例如员工询问未来是否一定调整待遇、某项政策是否适用于所有人，以及具体调整幅度是多少。

如果制度资料中没有明确内容，系统就必须拒绝猜测。

我认为，这两类测试缺一不可。

只测试“能不能答出来”，无法证明 Agent 可靠。

还要测试：

当它没有答案时，会不会老老实实地说没有答案？

最终的工作逻辑

经过这次调整，Agent 的工作逻辑变得很清楚：

员工提出问题
 ↓
理解员工真正想问什么
 ↓
从人力制度知识库中检索
 ↓
判断有没有直接制度依据
 ↓
有依据：回答并提供来源
无依据：明确拒答，不自行补充

它不再是一个什么问题都尝试回答的万能机器人。

它更像一个有明确工作范围的制度助手。

只回答制度资料中能够找到依据的问题。

这次经历让我明白了什么

这次调整让我意识到，企业 AI 最重要的不是让它看起来很聪明，而是让它的边界足够清楚。

我以前容易把重点放在模型、检索和 Prompt 上，但真正影响使用效果的，往往是几个更基础的问题：

• 这个 Agent 到底服务谁；
• 它应该使用哪些资料；
• 哪些内容不属于它的回答范围；
• 没有答案时应该怎么处理；
• 修改之后有没有做真实验证。

如果这些问题没有解决，技术越复杂，系统可能越难控制。

现在回头看，我认为一个可靠的企业制度问答 Agent，至少要做到四点：

第一，知识来源清楚。

第二，回答范围明确。

第三，答案必须有依据。

第四，不知道时能够拒答。

这次项目最后让我确定了一件事：

企业 AI 不是知道得越多越好，而是要在自己的边界内，给出可靠、清楚、可核对的答案。

这才是我重新调整这个人力制度问答 Agent 的真正目的。