为什么要协同调
切分长度要与 embedding 模型的输入上限匹配：超长会被静默截断，尾部信息实际没参与向量化；过短则语义不足、噪声占比偏高。同时要确认模型是否要求指令前缀（例如 E5 系列的查询侧与文档侧前缀不同）。三项参数彼此牵制，调其中一项就要回头核对另外两项，否则召回会莫名下滑。
基本信息
| 第一项 | 模型输入上限（按 token 计），以模型卡标注为准 |
|---|---|
| 第二项 | 实际切分长度分布，重点看 90 与 99 分位 |
| 第三项 | 指令前缀要求，查询侧与文档侧是否不同 |
| 核对方式 | 统计长度分位数与上限比对，前缀写成常量避免漏加 |
典型使用场景
- 换 embedding 模型：上限从 512 变到 8192 后，原切分长度需要重新评估
- 召回率下滑排查：先确认有没有块超限被静默截断
- 多语言语料：中英混排下同样字数的 token 数差异大，需实测分布
- 前缀核查：E5 类模型未加前缀时效果明显打折，属于高频低级错误
- 新语料接入：不同来源的文档长度分布不同，需要重新跑一遍分位统计
三项参数核对
三项参数核对
# 1) 模型输入上限（tokens）：如 512，需查模型卡确认
# 2) 实测切分长度分布：重点看 90 与 99 分位是否接近上限
# 3) 指令前缀：查询侧是否需要 "query: " 之类前缀，文档侧是否不同
import numpy as np
lens = [len(t) for t in chunk_token_lens] # 按 tokenizer 统计
print(np.percentile(lens, [50, 90, 99])) # 超上限的块会被截断
三项核对表
| 检查项 | 正常表现 | 异常后果 |
|---|---|---|
| 块长度 99 分位 | 低于模型输入上限 | 超限部分被截断，尾部内容检索不到 |
| 块长度中位数 | 语义完整、可独立理解 | 过短导致语义碎片化 |
| 前缀一致性 | 查询与文档按模型要求分别添加 | 相似度整体失真，召回明显下降 |
| 归一化设置 | 入库与查询两侧一致 | 分数分布改变，原有阈值失效 |
E5 系列等模型对前缀敏感：查询与文档必须按模型文档的指示加前缀，加错或只加一侧，效果下降通常比换模型带来的差异更大。
长度核对要以 token 为准：用字符数估算在中英混排语料上误差很大，建议直接调用模型的 tokenizer 统计，脚本随切分代码一起维护。