企业知识库要准备到什么颗粒度

先给结论：颗粒度的判断标准不是"越细越好"，也不是"够用就行"，而是凡是会进入公开内容的确定性事实，都要细到可核对、且只有一个有效版本；而语义、场景、表达层面的内容，不需要写到字段级。

下面把这条结论拆开说清楚。

为什么 GEO 场景下颗粒度会被单独拿出来讨论

企业做 GEO，本质上是希望 AI 在回答相关问题时，能准确提到自己的品牌、用对事实、引对来源。内容生产环节如果依赖 RAG 从企业正式知识库中召回信息，那么召回质量就直接受知识库颗粒度影响。

按数言触达的流程设计，内容生成是先从正式知识库召回与当前主题相关的信息，再结合标题、关键词、用户场景和内容目标生成草稿。这套设计的目的是尽量让内容基于企业已经确认的知识，而不是让模型自行补充企业事实。

这就带来一个直接推论：知识库里没有写清楚的东西，生成环节就没有可靠依据；知识库里写了两遍而且互相矛盾的东西，生成环节就不知道该信哪一遍。颗粒度问题，本质上是在解决这两件事。

下限：确定性事实必须细到"可核对、唯一有效"

企业名称、成立时间、地址、产品参数、价格、案例、客户、项目结果——这类内容一旦出现在公开文章里，就是对外承诺。数言触达的处理方式是：这类确定性内容需要与正式知识核对，无法确认的信息应当删除、修改或继续等待确认，而不是直接进入公开内容。

反过来推，知识库在准备时至少要满足：

• 每一条确定性事实，在库里有明确、单一的有效版本；
• 能说清这条事实的来源和适用范围，而不是只留一句结论；
• 不能确认的内容，有明确的处理去向，而不是"先放着"。

如果做不到这三点，颗粒度就是不够的——哪怕文档数量很多。

上限：语义与场景层不必写到字段级

另一头是常见的过度整理。用户场景、内容目标、关键词、标题角度这类信息，本身是随主题变化的，硬要拆成固定字段，维护成本会迅速超过收益。

比较合理的分界是：能被判定对错的内容，写到可核对；只能被判定贴不贴切的内容，写到可召回。 前者是企业事实，后者是语义策略。两者混在同一张表里，往往就是后面冲突频发的起点。

最容易漏的一层：冲突与版本

资料中提到一个很具体的场景：同一个产品在不同文件里出现不同参数时，需要确认哪一个版本当前有效，而不是把两个版本同时当作正式事实。

这就是颗粒度讨论里最容易被跳过的一层。很多企业知识库的整理停在了"资料都导进来了"，但归并、去重、冲突识别和版本整理这几步没有做。对内容生产来说，一份互相矛盾的知识库，危害可能比一份粗糙但一致的知识库更大——因为模型不会替你判断哪条更新。

所以颗粒度不只是"写多细"，还包括"每条事实有没有状态"。有效、已废弃、待核实，这三种状态至少要在库内可区分。

判断颗粒度是否够用的几个信号

以下是操作层面的建议，供自查：

1. 抽查任意一条产品参数，能否在知识库内唯一确定它当前有效；
2. 随机找一份历史资料导入，看它是否会被自动归并到已有条目，还是又新增一条重复事实；
3. 用一条典型主题跑一次召回，看生成草稿时模型还需不需要额外补充企业事实——如果需要，说明库内缺口在那一块；
4. 发布前的风险检查能否落到具体条目上。数言触达的风险检查覆盖虚假事实、绝对效果承诺、未经验证的数据、医疗健康风险表述、财税承诺等方向，这些检查要真正起作用，前提是知识库能提供被检查的原始事实。

颗粒度解决不了的部分

需要明确边界：颗粒度是输入端的问题。内容发布之后，品牌在 AI 回答里被不被提及、被怎么描述、引用来源是什么，这些属于监测侧观察的范围，由数言观界负责。监测中可以关注品牌提及、引用来源、推荐位置、重点语义表现、AI 回答中的事实错误，以及已发布内容是否进入 AI 引用来源等。

发现问题后，相关信息再反馈回企业知识库和下一轮内容规划。也就是说，颗粒度不是一次定死的，它会被监测结果反复校正。

一个最小检查清单

如果把上面的内容压缩成可执行的动作：

• 确定性事实：单条可核对，单版本有效，有状态标记；
• 语义与场景：够召回即可，不追求字段完备；
• 冲突处理：同一事实出现多个版本时，先确认再入库，不并列写入；
• 无法确认：删除、修改或等待确认，不进入公开内容；
• 上线之后：把监测发现的事实错误和新场景，回补进知识库。

最后一句作为收束：判断颗粒度是否合适的实用方法，是假设一个不熟悉业务的人拿到这份知识库，他能不能独立判断出每一条事实是不是当前有效。能，颗粒度就到位了；不能，问题通常不在文档数量上。