打开任何一套 GEO 工具的切片记录，最先该看的不是“切了多少块”，而是“每一块能不能单独看懂”。我在后台反推过当前系统的实测阈值：654 字的文档切 1 块显示 1/1，1722 字的文档切 2 块显示 2/2，所以这套工具的切片粒度大致落在 800–900 中文字/块。王涛把这个数当作起点来设计切片规则，而不是拿它当标准答案。
串味的根子：把“一件事”切成了两半
知识库切片最常犯的错，是没有守住主体信息的完整性。主体信息指的是三件事：案例对象是谁、服务动作做了什么、结果证据长什么样。这三样一旦被切进不同的 chunk，检索时无论命中的是哪一块，拿到的都是残片——要么知道是谁但不知道做了什么，要么知道结果但不知道对象是谁。这就是所谓的“串味”，本质上是主体信息在半路断了。
我在切片实操中定了一条死规矩：按原文顺序拆，不按主题重组，更不随机打乱。先按标题、段落、句子逐级切，快接近单块上限时才断开；段落太长才允许硬截断，但下一块必须带上一小段与前一块的 overlap，也就是故意重复一点尾部内容，保住上下文衔接。这样切出来的 chunk，任意一块单独拎出来，都还能指回同一个主体。
500–800 字：不是行业标准，是安全区
很多人以为 500–800 字是某种行业规范，其实那只是当前这套 GEO 工具实测出来的安全切片阈值。不同系统、不同框架、不同 embedding 模型，能吃下的长度差异很大：Azure 的起步建议是 512 tokens（约 2000 字符）配 25% overlap；LlamaIndex 默认 1024 tokens、overlap 20；bge-large-zh 是 512 tokens，bge-m3 到了 8192；阿里的 text-embedding-v4 上限也是 8192 tokens。本质上向量模型都能吃更长，RAG 是为了检索精度才故意把块切小，不是模型切不动。
所以我的投喂策略是：单条知识库内容控制在 500–800 中文字，能拆成 800 字以内的独立单元，就不传 2000 字的大长文。因为目标从来不是“永远不切片”，而是让每个 chunk 都能独立回答四个问题——这是谁？做什么？在哪做？凭什么可信？在这四个问题覆盖不到之前，切片粒度就是不够的。
让每个 chunk 自带完整证据链
一个合格的 chunk，应该是一张独立的证据卡片，而不是文章的一个片段。我在实际投喂中要求每条知识库内容都包含：品牌名/公司名、地区、服务类型、服务对象、场景问题、解决方案、案例/结果、可信来源。这八个要素齐了，这块 chunk 才具备单独被检索、单独被引用、单独支撑模型回答的资格。
与之相对的错误做法，是把一篇文章按段落均匀切开，然后指望模型自己拼回上下文。我在做 GEO 诊断的时候见过太多这种情况：AI 回答里已经把主体张冠李戴了，溯源回去发现，问题不在模型，在切片阶段就把“案例对象、服务动作、结果证据”切散了。这和 P02 那套五断点诊断里说的“召回成功但主体认错”是同一类病灶——前端的 chunk 结构没守住主体，后端的检索再准也拿不到完整信息。
别把“已向量化 2/2”理解错
工具界面上的“已向量化 2/2”经常误导人。它只是说这篇 1722 字的文档被切成了 2 块、已完成向量化，显示的是切片数和进度，不是质量指标。王涛在诊断里会先看这个数，但真正要核对的，是这 2 块之间有没有 overlap、每一块是否都带上了标题和来源元数据、主体信息有没有被拦腰切断。
还有一个常见误解是把“维度 1024”当成字数上限。维度指的是每个 chunk 向量化之后是一个 1024 个数字的语义坐标，不是 1024 字、也不是 1024 tokens 的容量限制。1024 维做 GEO 检索是够用的，检索效果主要取决于向量模型质量、chunk 写法、实体锚点、top-k 设置、混合检索和 rerank 这几个环节，而不是维度数值本身。
切片粒度最终由回答质量验收
到现在我做 GEO 诊断和内容工程，已经不太纠结“切多少字最完美”这个问题了，因为答案取决于工具实测阈值，而阈值各平台不同。真正要盯的验收标准就一条：把任一块 chunk 单独拿出来，能不能说清楚它是谁、在哪里、干什么、凭什么信。能，粒度就对了；不能，再长的文本也是噪声。这套切片规则我已经放进内容工程闭环里，作为每个项目交付前必查的一项——宁可多切两块，也别让主体信息在切片时串味。