豆包知识库如何开启问答对自动去重功能？

功能定位：为什么需要“问答对自动去重”

在豆包企业知识库里，同一问题常被不同同事用异构表述重复录入，导致搜索时前 3 条结果高度相似，既浪费 128K 超长上下文窗口的推理额度，也让机器人“看似啰嗦”。自动去重（下称“本功能”）通过语义指纹 + 字面哈希双阈值模型，把相似度 ≥0.94 的问答对合并为 canonical 版本，并在前台保留“历史版本”折叠入口，兼顾唯一性与可追溯性。

与「手动合并」相比，本功能在 10 万条量级下可节省约 30% 存储空间；经验性观察显示，搜索 latency 在移动端亚秒级内完成，桌面端因调用本地缓存甚至更快。需注意：去重仅作用于“问答”类型节点，对“文章”“文件”暂不生效。

入口对比：三条最短路径与平台差异

Android / iOS

1. 打开豆包 App → 底部「团队」页签 → 右上角「管理后台」
2. 在「知识库」卡片点「设置」→「数据治理」→ 开启「问答对自动去重」

桌面端（Windows/macOS）

1. 左侧栏「知识库」→ hover 目标库 →「⋯」→「库设置」
2. 「高级」→「去重策略」→ 勾选「自动合并相似问答」

若找不到「数据治理」入口，请确认：1) 你是该库管理员；2) 客户端已升级至「截至当前的最新版本」；3) 企业认证已生效。缺失任一条件，界面将自动隐藏该选项，避免误触。

决策树：什么时候该开、什么时候观望

• 问答对总量 > 5 000 条且月新增 > 300 条：建议开启，收益明显。
• 总量 < 1 000 条：手动合并更直观，可暂不开。
• 存在大量“多跳”关联问答（如 FAQ 带条件分支）：先评估 canonical 合并后是否丢失条件节点；若会丢失，先用「例外标签」功能打标再开。
• 合规要求保留完整审计链（金融、医疗）：可开启「只标记不合并」模式，满足双重留存。

操作步骤：从开启到首次合并的全过程

1. 预检：生成重复度报告

在「数据治理」面板点击「分析重复度」，系统会在后台跑批（耗时视数据量数十秒至数分钟）。报告返回后，你可见「高相似问答分布图」与「预估可释放空间」。若可释放空间 < 5%，工作假设认为收益有限，可终止后续流程。

2. 开开关：选择合并强度

豆包提供两档强度：

• 「严格」：语义 + 字面双通道同时满足阈值才合并；适合术语固定的技术库。
• 「宽松」：仅语义通道达标即合并；适合口语化客服库。

强度可随时下调，但已合并的记录不会自动拆回；需要拆回时，请用「历史版本」→「还原」单条处理。

3. 运行与观测

点击「立即执行合并」后，界面实时显示进度条与成功 / 跳过计数。完成后，系统会在「操作日志」生成一条可追溯记录，包含管理员昵称、时间、合并数、跳过原因（如命中例外标签）。

例外规则：让“必须保留”的问答免于合并

有时业务需要保留看似重复、实则答案不同的问答（例如不同地区运费）。豆包允许用「例外标签」豁免：

1. 在问答编辑页底部「高级」→ 勾选「禁止自动合并」
2. 或在批量 Excel 导入时，在列 header 写 keep_unique=1

被标记的问答会被去重流程跳过，并在报告中单独计数，方便审计。

回退与故障排查

现象：合并后发现答案被覆盖

处置：进入该问答 →「历史版本」→ 选择被覆盖版本 →「还原」。还原后系统会自动给另一条问答打「潜在重复」灰标，供下次跑批时二次判断。

现象：日志提示“索引锁超时”

原因：库内正在执行「全文重建」或「多模态记忆增强」索引，与去重任务抢占锁。验证：在「系统状态」页看是否有 Running 状态的重建任务。处置：等待重建完成或手动暂停重建，再重新执行去重。

与机器人/第三方的协同边界

豆包提供「企业机器人」事件回调：当问答被合并时，会向你的 webhook 发送 canonical_id + 被合并 id 列表。若你在飞书/钉钉侧做了问答镜像，可监听此事件把旧 id 映射到新 id，保持链接可用。权限最小化原则：webhook 仅需开启 kb.merge 事件，勿勾选全部写权限，防止误删。

适用 / 不适用场景清单

场景特征	建议	理由
客服 FAQ，月增 > 500 条	开启宽松模式	口语化表述重复率高，合并收益大
法规条文库，答案随地区差异	先打例外标签再开严格模式	避免把“北京版”与“上海版”合并
技术 changelog，每条都唯一	不开启	版本号不同即视为不同答案

最佳实践 5 条（检查表）

1. 先跑「重复度报告」→ 看可释放空间是否 > 5% 再动手。
2. 给地区差异、价格差异问答预置「例外标签」，避免事后还原。
3. 合并后 48 小时内监控「搜索无结果率」与「负向反馈 / thumbsDown」是否异常上升；若上升 > 1 个百分点，立即审查合并记录。
4. 每季度跑一次「压缩存储」任务，把已合并的旧版本做冷归档，减少活跃索引体积。
5. 给管理员组设置「仅查看」权限的子账号，用于定期审计合并日志，避免既当运动员又当裁判。

版本差异与迁移建议

在 8.3 及更早版本，去重功能以「实验室插件」形式存在，需手动开启「开发者模式」才能看见；8.4 起正式并入「数据治理」。若你从 8.3 升级，旧插件会自动卸载，已合并数据无损，但 webhook 地址需重新填写，因为事件名从 lab.qa_dedup 改为 kb.merge。

验证与观测方法

1) 在「搜索分析」里把「搜索结果 TOP10 相似度」作为核心指标，合并后该值应下降 10–30%。
2) 用「/stat delta=7」命令查看近 7 天「重复问答点击数」是否减少，若减少即表明用户更快找到唯一答案。
3) 监听 webhook 事件，统计 canonical 被调用次数，评估合并后答案的实际使用率。

FAQ（必须使用 FAQPage Schema）

总结与下一步行动

豆包知识库的问答对自动去重功能，用语义 + 字面双通道在后台静默消重，能显著节省存储与推理开销，但前提是你先跑重复度报告、打好例外标签，并在合并后 48 小时观测搜索指标。若数据量不足 1 000 条或存在多跳条件问答，建议先用人工合并验证逻辑，再决定是否自动化。

下一步：1) 在测试库执行上述完整流程，记录耗时与可释放空间；2) 把「搜索无结果率」「负向反馈率」加入周报表；3) 若效果正向，再在正式库开启，并给管理员开通只读审计子账号。这样，你就能在数据治理与用户体验之间取得可量化的平衡。