知识库治理产品决策记录
一、决策结论（一句话）
知识库的管理是"运维工作"而非"产品功能"；维护者是甲方侧具备文档数据处理能力的人员，直接用 Dify 完成知识库全生命周期维护。Dify 原生能力 + 方法论交付，即为产品的知识库形态。
二、核心概念界定
2.1 知识库维护者（关键角色定义）
知识库的维护者定义为：甲方侧具备一定文档数据处理能力的人员。
- 不绑定具体职位——可能是甲方的 IT 运维、文档管理员、或具备数据处理能力的运营人员；
- 具备能力：操作文档解析工具（如 MinerU）、处理 Markdown 清洗（错行/标题层级/无效图片链接）、理解元数据标签含义、执行召回验证。
对这类人，Dify 是可用且合理的运维界面。
2.2 两层用户划分
| 用户层 | 角色 | 与知识库的关系 |
|---|---|---|
| 终端用户 | 甲方业务人员 / 员工 / 访客 | 仅通过 AI 对话消费知识，不接触知识库本身 |
| 知识维护者 | 甲方具备文档处理能力的人员 | 负责上传 / 清洗 / 打标 / 召回验证 / 更新下架，直接使用 Dify |
三、决策依据
知识库内容生产是低频、专业、数据工程性质的工作 文档清洗（如PDF→MD）、标题层级修正、无效图片链接清理等环节无法完全自动化，必须由具备数据处理能力的人参与。这不是高频业务运营场景，不具备"为纯业务方打造自助后台"的需求基础。
维护者具备技术能力，Dify 即运维界面 Dify 的文档列表、元数据配置、分段设置、召回测试等功能，对文档处理能力的人是可用的运维工具。自建后台只是把 Dify 已有能力再包一层，无增量价值。
Dify 中 QA 与文档统一为文档向量形态，不存在独立的"QA 资产"可管理 Dify 以"文档→向量"为统一知识单元（Q&A 分段模式详见附录 A），表格上传亦按行切块走向量，不支持列索引精确匹配。因此 Dify 内没有独立的"QA 对表"可供单独维护，"为 QA 单独建后台"缺乏管理对象。若未来确需列索引级精确匹配，那是自研 QA 引擎的产品能力问题，不属于"知识库管理后台"范畴。
权限体系不一致可通过"运维账号"规避 Dify 账号与业务中台权限体系不一致，但知识库维护者收敛为单一角色（甲方维护者），为其分配 Dify 运维账号即可规避，无需深度对接权限体系，不构成建设后台的理由。
四、表格类（QA 对）知识库能力对比
| 能力 | Dify | Coze（扣子） |
|---|---|---|
| 上传 Excel/CSV | ✅ | ✅ |
| 表格分片 | 按行切块，向量检索 | 按行分片 |
| 指定某一列做检索索引 | ❌ 不支持 | ✅ 核心能力 |
| QA 匹配方式 | Q&A 分段模式（LLM 提炼问答对，详见附录 A） | 列索引 + NL2SQL |
说明：本对比聚焦"QA 对 / 表格"这一类知识单元。当前能力边界下，Dify 对表格数据不提供"指定列索引"的精确匹配能力，QA 内容以文档向量形态统一处理；分段层面的两个增强选项（摘要自动生成 vs Q&A 分段）差异详见附录 B。
五、产品边界与交付物
5.1 产品化范围（纳入产品）
- AI 对话对知识库的检索与回答能力
- 检索效果验证（Dify 自带召回测试）
- 元数据标签体系的规范定义（业务域 / 访问角色 / source_url / 文档标题等）
5.2 交付/服务范围（非产品功能）
- 文档导入与元数据打标：项目初始阶段我方技术人员可协助完成初始化（属交付服务）；正式运营后由甲方维护者自行维护。
- 数据清洗（PDF→MD 及 Markdown 精修）：不在初始化默认范围内。由甲方维护者通过我方提供的工具与方法自行完成，或另行按商务约定采购服务。
- 知识库日常维护（上传 / 更新 / 下架 / 召回验证）：由甲方维护者执行。
5.3 我方交付物清单
- 架构模板：知识库目录结构、文档命名规范、元数据打标模板
- 梳理方法论：文档优先级、清洗标准（含工具选用）、导入流程
- 运维培训：面向甲方维护者的 Dify + 文档解析工具操作培训
六、未来触发条件（满足任一即重新评估）
- 甲方明确要求纯业务人员自助维护 FAQ / 制度类内容；
- 甲方要求"知识库管理界面"且拒绝使用 Dify；
- 文档 / QA 量级显著上升，Dify 维护成本明显不可接受。
届时评估的应是"内容运营后台"（业务化表单，底层写回 Dify），而非"知识库管理后台"。
七、常见疑问回应
Q1：科技馆项目做了 QA 对管理后台，现在为什么不做？ 科技馆当时的做法较简单，两个前提与现在不同：一是当时不适合将 Coze 暴露给用户，故在中台自建后台做能力封装；二是场景简单，未考虑元数据标签体系、未考虑权限体系。当前 Dify 对具备文档处理能力的甲方维护者可直接使用，无需封装；且 Dify 下 QA 与文档统一为向量形态，无独立后台的必要。
Q2：不建后台，甲方怎么维护知识库？ 知识库维护本身不是纯业务人员的职责——它需要文档数据处理能力。具备该能力的甲方维护者使用 Dify 即可完成全流程，我方提供架构模板、梳理方法论与运维培训。
Q3：Dify 和业务中台的权限不是一套，怎么解决？ 为甲方维护者分配 Dify 运维账号，收敛为单一维护角色即可规避；业务人员不接触知识库，不产生权限穿透问题。
附录 A：Dify Q&A 分段模式说明
定义：Dify 对文档完成 chunking 后，由 LLM 对每个分段二次提炼出问答对，检索采用 Q-to-Q（问题匹配问题）方式——用户提问时先匹配最相似的问题，命中后再返回该问答对对应的原始 chunk 作为答案。原始分段完整保留，问答对仅作为附加匹配层，不会替换原文。Q&A 分段与其他分段增强选项（摘要自动生成）的能力对比见附录 B。
关键澄清：该模式产出的 QA 是 LLM 从文档自动生成的衍生品，非业务方直接提供的原始问答对。它是 Dify 的平台加工能力，而非独立的知识资产形态。
Q 与 A 的分工（Q&A 对为何 Q 与 A 成对生成）：
- Q 负责"命中"（检索入口）：Q-to-Q 用用户问题去匹配预生成的问题，Q 决定了能否被检索到。
- A 负责"命中后直接给答案"（回答质量）：问答对整体存储（
content=问题、answer=提炼答案），命中后 A 随上下文注入 LLM，作为 LLM 可直接引用的精炼参考答案，避免其现场从长 chunk 中自行寻找，降低回答不确定性与 Token 消耗。 - chunk 负责"兜底上下文"：原始分段完整保留，作为补充事实来源。
官方表述与实现的差异提示：官方文档描述为"命中问答对后返回对应的原始 chunk"，而实际实现（GitHub issue #7402 等）为命中后返回包含 Q 与 A 的问答对（A 随命中返回）。阅读官方文档时易误以为"A 不参与返回、生成多余"，理解"Q 负责命中、A 负责答案质量、chunk 兜底"三者分工后即可避免该误区。
与业务方直接提供的 QA 对（如科技馆场景）的区别：
| 维度 | Dify Q&A 分段模式 | 业务方直接提供的 QA 对 |
|---|---|---|
| 来源 | LLM 从文档自动提炼 | 业务方人工编写（知识资产本体） |
| 形态 | 依附于源文档分段的衍生数据 | 独立可编辑的问答记录 |
| 管理对象 | 无独立资产，随文档管理 | 需要独立的增删改查界面 |
| 成本 | 启用需额外消耗 Token | 无加工成本，维护即人力成本 |
结论：Dify 下"QA 分段"与"业务方 QA 对"是两个不同概念，不可混同。本决策中的"QA 不区分对待"指前者（平台加工环节，无独立资产）；后者若真实出现（业务方纯自助维护问答），属于"内容运营后台"的评估范围，见正文第六章触发条件。
附录 B：Dify 分段增强能力调研（摘要自动生成 vs Q&A 分段）
背景：Dify 分段设置页提供两个易混淆的增强选项——"摘要自动生成"与"使用 Q&A 分段"。二者作用层面完全不同，且互不排斥（通用模式下可同时开启）：
- 摘要自动生成 = 附加索引层：为每个分段额外生成一段摘要，摘要同样向量化参与检索（原文向量 + 摘要向量双索引召回）。不改变分段结构、不替换原文，兼容通用/父子两种分段模式，可随时开关、手动编辑、批量重新生成。仅自托管可用。
- Q&A 分段 = 附加匹配层：在通用分段基础上，由 LLM 为每个分段提炼问答对作为匹配入口（Q-to-Q）。原始 chunk 完整保留，命中问答对后返回原始分段。注意：Q&A 复选框仅在通用分段面板出现，父子分段 UI 直接移除该选项（硬互斥）。
| 维度 | 摘要自动生成 | Q&A 分段 |
|---|---|---|
| 产出物 | 每个分段 1 段文字摘要（附加索引） | 每个分段多条问答对（附加匹配入口） |
| 检索方式 | 问题匹配原文 + 摘要向量 | 问题匹配预生成的问题（Q-to-Q），命中后返回原始 chunk |
| 适合文档 | 通用、长文本、技术文档 | FAQ、问答类、客服材料 |
| 资源消耗 | 中等（每分段生成 1 条摘要） | 偏高（每分段生成多条问题） |
| 底层索引 | 摘要索引（Summary Index，独立插件） | 问答对索引 |
| 与分段模式关系 | 兼容通用/父子模式 | 仅通用分段面板提供（父子 UI 移除，硬互斥） |
| 原始 chunk | 保留（摘要为附加层） | 保留（问答对为附加层） |
| 主要限制 | 仅自托管可用；仅高质量索引 | 仅高质量索引、仅支持中英日 |
| 变更灵活性 | 可随时开关 / 手动编辑 / 批量重新生成 | 分段结构保存后不可更改 |
对项目的影响：设备手册、制度、技术文档等长文本多主题内容，建议"父子模式 + 摘要自动生成"（性价比高、不锁定结构，摘要兼容父子模式）；FAQ 类问法固定的短条目才考虑在通用模式下叠加 Q&A 分段（需接受仅中英日 + 仅高质量索引的约束）。二者均为 Dify 平台在原文之上的附加加工层、原始文档始终保留，不改变"QA 与文档统一为文档向量形态、无独立 QA 资产"的决策结论。
参考来源（Dify 官方文档 / GitHub / 官方博客）：
- 分段与预处理设置：https://docs.dify.ai/zh/use-dify/knowledge/create-knowledge/chunking-and-cleaning-text （摘要自动生成仅自托管可用，可独立开启，父子模式亦支持）
- 索引方式与检索设置：https://docs.dify.ai/zh/use-dify/knowledge/create-knowledge/setting-indexing-methods （Q&A 模式定义，enterprise-docs 3.7.x 版原文：命中问答对后返回对应原始 chunk）
- GitHub Discussion #31890（摘要索引为独立插件，可与 Q&A 索引同时挂载于通用分段模式）
- Dify 官方博客《1.12.0 Summary Index》：https://dify.ai/blog/dify-1.12.0-summary-index-from-fragmented-retrieval-to-full-context （chunk 附加 summary 字段、原文+摘要双向量召回、不改变分段逻辑；自动生成仅社区版可用）
注：链接 3 本次未能直接访问核验，其结论来源于项目内人工摘录，使用前建议复核。