FAQ 数量增加却越来越难搜，往往不是问题不够多，而是同义问法重复建条、不同任务又被塞进同一个答案。治理时应按用户要完成的事和答案适用条件决定拆分或合并，避免只根据标题相似程度操作。
先把问题与答案依据放在一起看
“培训费用怎么报”和“参加外部课程能报多少钱”都含有培训与报销，但前者可能需要流程和票据，后者需要限额。若直接合并成一篇很长的通用 FAQ，检索命中后仍可能没有回答用户最关心的部分。
相反，“年休假能留到明年吗”和“年假可以跨年使用吗”若适用条件与依据一致，可以作为同一条目的不同问法。保留这些别名有助于检索，不必为每种句式复制一份答案，造成后续修订遗漏。
用三项比较决定动作
| 比较项 | 判断用途 |
|---|---|
| 用户任务 | 查资格、查金额和查流程是否不同 |
| 适用条件 | 是否面向不同人群、事项或期间 |
| 来源依据 | 答案是否来自同一条款及同一版本 |
三项都相同而仅表达不同，通常适合合并；任务不同或条件差异会改变结论，则应独立表达。对于共享一部分背景的条目，可以关联统一说明，而不是把全部内容反复复制。
拆分时保留必要条件
将一个大 FAQ 拆成短条目，不等于把每句话独立成题。比如“需要提交课程安排”必须带上适用对象，否则用户无法知道它是所有培训还是某类培训的要求。每个条目都应能够在脱离原页面时被正确理解。
如果答案依赖多个条件，可以用清楚的小节或条件表呈现，不必机械拆成大量碎片。拆分粒度由问题与证据决定，不能以字数整齐作为目标。后续 RAG 切分还需要保留这些条件关系。
合并后检查旧问法是否还能找到
整理前收集真实查询和失败样本，整理后用同样问题检查是否命中正确条目。特别留意旧标题、常用简称和历史入口。合并不应让用户原来能找到的答案突然消失，也不应让一个宽泛条目吞掉所有细分问题。
可以记录条目之间的替代与关联关系，保留内容维护依据。若两份答案存在冲突，先解决事实问题再合并，不能用更顺畅的文字把分歧隐藏。对尚未确定的条件，应明确待核状态。
最终衡量应看问题是否更容易找到正确依据、重复维护是否减少，以及关键条件是否保留。FAQ 数量下降只是整理动作的结果，不能单独证明知识质量提高。持续保留真实失败问法，才能知道下一轮该补内容还是调整入口。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。