为什么需要制度检索问答Agent？

公司制度是保障企业规范运营、防范风险和提升管理效能的基石。然而，在日常管理中，传统制度文档普遍面临三大挑战：

• 检索繁琐：员工往往需在多平台、多文件中人工查找相关制度条款，效率低下且信息筛选成本高；
• 理解不一致：复杂或跨部门的制度条文易产生解读歧义，导致执行偏差与协同摩擦；
• 更新延迟：制度修订后难以快速触达全员，旧版本沿用可能引发合规风险。
  
  

该Agent不仅是一个检索工具，更是将静态制度转化为动态知识服务的智能中枢，显著提升组织合规效率与员工协同体验，它具备以下好处：

• 减少行政部门30%以上重复咨询工作量，释放人力处理更高价值事务；

• 缩短50%以上新员工适应周期，减少集中培训频次；

• 制度更新实时同步全员，确保合规性0延迟；

• 便捷的查询方式推动员工主动了解制度，减少“因不知情而违规”现象

  
  

它能为公司和员工个人带来这么多好处，是不是已经心动了呢？

下面，我们将在这篇文章中为大家分享我们搭建工作流的真实心路历程以及后续优化的方向。让我们一起来搭建工作流吧！

下面是我们搭建的公司制度检索工作流的演示视频：

具体实现流程

在这部分，我们将详细讲解公司制度检索问答工作流的搭建步骤。

它主要分为三部分：用户问题处理、知识库检索以及生成回复。

一、用户问题处理

优质的用户问题对于检索问答类的工作流简直是“如虎添翼”。那么这个“优质的用户问题”该是如何定义的呢？

以我们目前的AI应用开发经验来说，语义完整、表述清晰的问题就是有利于检索的“优质问题”。我们无法要求每个用户问题都表达清晰，所以我们就需要借助一些方法来“校正”。下面让我们来看一下我们在工作流中是如何生成“优质问题”的吧！

首先，拿到用户问题之后我们首先使用LLM来进行判断，目标就是筛选出需要改写的用户问题。我们在prompt中说明了需要改写的情况：追问、表述不清晰。

二、知识库检索

经过上一部分的处理，我们进入检索问答类工作流中最为关键的一步：知识库检索。这部分主要分为制度文档处理和知识库检索进行讲解。

制度文档处理

公司中的制度文档的格式一般是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，如果你的显存充裕，可以拉满。

三、生成回复

待改进点：

通过上面的三个步骤我们完整搭建了公司制度检索问答的工作流。公司制度检索问答在不断迭代中我们也面临两个待优化的内容：

• 合理改写用户问题

在“用户问题处理”这一部分，我们有两种需要改写的情况，如何合理地改写用户问题是一件值得推敲的事情。结合上下文改写还好，因为有改写的依据。然而无上下文直接改写给大模型制造了“巧妇难为无米之炊”的困境，改写出来的问题常常是“xx是什么？”这类泛泛的问题。

为了优化这点，我们计划给LLM一个“问题库”，从公司制度文件中提取出一些具有代表性的问题，依据“问题库”给LLM的改写任务一个支点。

• 降低显存压力

对于显存有限的玩家来说，兼具效率和准确率是一件让人头疼的事情。而检索问答类任务的用户问题往往具有语义相似性的特点，因此我们提出增加用户问答“cache”来提升响应速度，降低显存压力。这一点优化内容在检索问答类任务中具有普适性。为了避免“cache”污染，我们只将用户点赞的问答内容存储到“cache”中，用户提出新问题时通过user_id和app_id的限制进行语义检索，后续使用CPU部署的小语言模型或者直接输出，降低显存压力。

系统不是终点，而是管理升级的杠杆：当员工能3秒查到差旅标准时，节省的不仅是时间，更是将企业规则真正转化为生产力。