北京
一个开发者问：“API 的认证怎么配置？”检索系统确实找到了一段文本，里面有配置参数。但认证的前置条件在上一块里，真正的示例代码在下一块里。系统检索到了技术上相关的文字，只是没检索到足够对的上下文。
这是我不认为分块大小应该从一个数字开始的理由之一。500 token 不是一种分块策略，它是一个约束条件。好的分块应该代表一个有意义的信息单元，在被检索出来的时候能够独立成立。
不同文档有不同的边界
先看源代码。如果把一个 Python 文件每 500 token 切一刀，很可能一个类的一半落在这一块，另一半落在下一块。这通常是个糟糕的检索边界。更好的做法是保留代码的自然结构：文件下面有类，类下面有方法，方法之外还有函数。
一个函数或一个类，往往比一个任意的 token 区间更能代表一个语义单元。同样的原则适用于文档。一份产品指南可能是这样的顺序：安装、配置、认证、使用、故障排查。如果有人问认证怎么配置，我希望分块保留相关的那一节，而不是因为撞上了某个任意的 token 上限被切开。
法律文档把这一点暴露得更明显。一个条款可能严重依赖它周围的定义、例外和条件。从中间切开一个条款，得到的块单独读起来通顺，但在法律意义上是不完整的。结构化的商业文档也有自己的自然单元：表格、政策、章节、流程和记录。不存在一个通用的分块大小能同时适配所有这些。
先问问题，再谈 token
我会先问：用户会问什么样的问题？假设用户在检索一个技术知识库，他们可能问：“我怎么重置我的 API key？”这大概率是一个流程导向的查询。另一个用户可能问：“哪些套餐支持 SSO？”这是一个产品政策类查询。还有人可能问：“为什么我遇到了 4017 错误？”这是错误诊断类查询。
这些问题需要的上下文可能非常不同。对其中一类有效的分块策略，在另一类上可能表现很差。目标不是造出数学上整齐划一的块，而是造出可检索的意义单元。
语义边界比数字更重要
看一份简单的文档，退款政策：客户可以在购买后 30 天内申请退款；企业客户必须联系他们的客户经理；年度合同续约之后不支持退款。
这三句话共享同一个主题，彼此互为条件。如果按固定 token 数切开，第二句和第三句可能被分到别的块里，检索到第一句的人就不知道企业客户走的是另一条路径。分块要守住的，是这种语义上的完整性，而不是数字上的整齐。
把这几类文档放在一起看，结论其实是一致的：
- 源代码的自然单元是函数和类，不是 token 区间
- 产品文档的自然单元是章节，比如安装、配置、认证
- 法律文档的自然单元是条款，连同它的定义和例外
- 商业文档的自然单元是表格、政策、流程和记录
这些单元的大小天然不一致。强行用同一个数字去切，等于用工程上的便利去换检索质量。
从问题倒推分块
流程类问题、政策类问题、诊断类问题，需要的上下文范围不一样。分块策略应该从这些真实问题出发去设计，而不是先定一个 token 数，再指望所有文档都适配它。
500 token 听起来合理：小到能检索，大到能装下一些上下文，处理起来还一致。但一致性是给流水线看的，不是给检索质量看的。当用户问出那个认证配置的问题时，决定成败的不是块有多整齐，而是块里有没有那个能独立成立的答案。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
