|
为什么需要制度检索问答Agent？ 公司制度是保障企业规范运营、防范风险和提升管理效能的基石。然而，在日常管理中，传统制度文档普遍面临三大挑战： - 检索繁琐：员工往往需在多平台、多文件中人工查找相关制度条款，效率低下且信息筛选成本高；
- 理解不一致：复杂或跨部门的制度条文易产生解读歧义，导致执行偏差与协同摩擦；
- 更新延迟：制度修订后难以快速触达全员，旧版本沿用可能引发合规风险。
制度检索问答Agent通过融合自然语言处理与实时知识检索技术，为企业提供以下核心价值：
✅即时精准响应：支持自然语言提问（如“员工报销期限是几天？”“远程办公申请流程？”），秒级返回最新制度依据；
✅降低合规风险：结构化解析制度要点、适用场景及关联条款，确保执行标准统一；
✅动态同步更新：无缝集成企业知识中台，保障Agent应答内容与现行制度版本完全一致。该Agent不仅是一个检索工具，更是将静态制度转化为动态知识服务的智能中枢，显著提升组织合规效率与员工协同体验，它具备以下好处：
它能为公司和员工个人带来这么多好处，是不是已经心动了呢？ 下面，我们将在这篇文章中为大家分享我们搭建工作流的真实心路历程以及后续优化的方向。让我们一起来搭建工作流吧！
下面是我们搭建的公司制度检索工作流的演示视频：
具体实现流程在这部分，我们将详细讲解公司制度检索问答工作流的搭建步骤。 它主要分为三部分：用户问题处理、知识库检索以及生成回复。 一、用户问题处理优质的用户问题对于检索问答类的工作流简直是“如虎添翼”。那么这个“优质的用户问题”该是如何定义的呢？ 以我们目前的AI应用开发经验来说，语义完整、表述清晰的问题就是有利于检索的“优质问题”。我们无法要求每个用户问题都表达清晰，所以我们就需要借助一些方法来“校正”。下面让我们来看一下我们在工作流中是如何生成“优质问题”的吧！ 首先，拿到用户问题之后我们首先使用LLM来进行判断，目标就是筛选出需要改写的用户问题。我们在prompt中说明了需要改写的情况：追问、表述不清晰。 若是需要改写，我们则将用户问题输入【query rewrite】节点中实现改写。因为我们并没有将表述不清的情况拆分开，所以我们在该LLM节点中还需要详细做分类处理。为了帮助LLM更好的区分两种情况，我们在prompt中使用了few-shot的方法，给出了示例。经过这个LLM节点之后我们将用户的问题进行了修正。经过改写的用户问题和无需改写的用户问题输入【问题变量聚合】节点，经过if-else的判断，我们获取最终在知识库中检索的用户问题。二、知识库检索经过上一部分的处理，我们进入检索问答类工作流中最为关键的一步：知识库检索。这部分主要分为制度文档处理和知识库检索进行讲解。 制度文档处理公司中的制度文档的格式一般是pdf类型，并且其中大部分是扫描pdf。文件内容以文字居多，大概率包含表格和图片。因此为了保证文档的内容完整和结构清晰，我们使用OCR工具来处理文档。 在做处理文档这部分工作时，我们测试了目前市面上常见的OCR工具，例如Docling、Mineru、gptpdf、MonkeyOCR等。最终，我们选择了使用MonkeyOCR作为我们的文档处理工具，其可以将复杂表格转化为图片保存、识别的准确率较高以及完善的官方讲解文档满足我们的需求。MonkeyOCR官方github：https://github.com/Yuliang-Liu/MonkeyOCR.git 在处理文件时还需要考虑的一件事情是：文档分块。这关系到后续检索的召回率和准确率，所以我们需要确保分块能够保证语义的完整性但又不会因为chunk过大在检索时给显存造成过大的压力。在我们嵌入知识库的过程中，一般按照章节分块，如果某个章节过长（例如超过了2048个token），我们则按照二级标题拆分，在每个块保留一级标题，同时使用overlap的参数保证语义的连贯性。 对于纯文字的文件，我们最终输出为markdown格式就算完成了处理。对于包含表格或图片的文档，我们最终输出为docx格式，这样在嵌入dify的知识库时可以保留图片，便于后续的图文混排输出。 文档处理是一个“千文千面”的工程，上述内容只是我们在处理文档时总结的经验，自己手中的文档还是需要拆解嵌入之后通过测试召回率和准确率才能知道何种方法更适合。 在处理文档的过程中我们还需要关注Embedding模型的选型。候选模型肯定是从大家都在使用的模型入手，例如bge系列、qwen3系列以及m3e系列。具体哪个更适用你的任务，还是需要测试。我们公司的制度知识库中使用了qwen3-Embedding-8B和qwen3-reranker-8B模型，因为qwen3系列的向量模型对于语义检索的效果更好一些，可能是因为qwen3系列向量模型训练时关注了嵌入在不同维度的语义（具体参考qwen3向量模型的技术报告）。 知识库检索在【正文检索】这个节点，我们将用户问题作为查询变量进行检索，召回设置中我们可以看到语义检索的权重高达0.9，这和检索阈值一样是我们在测试过程中找到的最优召回率的数值。top_k设置为5，这是因为显存的限制，过高的top_k会导致OOM，如果你的显存充裕，可以拉满。 三、生成回复这部分我们将实现生成回复。经过知识库检索之后，我们需要对检索内容进行判断。首先需要确认是否检索到内容，如果没有检索到内容，我们还是选择了使用一个LLM节点来处理，模型使用小一些的即可，例如我们使用了qwen3-4B模型。如果检索到了内容，我们需要处理检索到的内容输入LLM节点中。为了保证图文混排输出不被干扰，我们在代码节点中使用正则匹配判断其中是否包含图片URL。后续针对单纯文字输出和图文混排进行了区分处理。待改进点：通过上面的三个步骤我们完整搭建了公司制度检索问答的工作流。公司制度检索问答在不断迭代中我们也面临两个待优化的内容： 在“用户问题处理”这一部分，我们有两种需要改写的情况，如何合理地改写用户问题是一件值得推敲的事情。结合上下文改写还好，因为有改写的依据。然而无上下文直接改写给大模型制造了“巧妇难为无米之炊”的困境，改写出来的问题常常是“xx是什么？”这类泛泛的问题。 为了优化这点，我们计划给LLM一个“问题库”，从公司制度文件中提取出一些具有代表性的问题，依据“问题库”给LLM的改写任务一个支点。 对于显存有限的玩家来说，兼具效率和准确率是一件让人头疼的事情。而检索问答类任务的用户问题往往具有语义相似性的特点，因此我们提出增加用户问答“cache”来提升响应速度，降低显存压力。这一点优化内容在检索问答类任务中具有普适性。为了避免“cache”污染，我们只将用户点赞的问答内容存储到“cache”中，用户提出新问题时通过user_id和app_id的限制进行语义检索，后续使用CPU部署的小语言模型或者直接输出，降低显存压力。 系统不是终点，而是管理升级的杠杆：当员工能3秒查到差旅标准时，节省的不仅是时间，更是将企业规则真正转化为生产力。 | 
