长文档检索总答非所问，问题出在切块

做企业知识库的人多半遇到过这种抱怨：答案明明就在这篇文档里，检索就是找不到。Manticore Search 团队把原因量化了出来：多数向量检索的实现是“一篇文档一个向量”，而嵌入模型有窗口上限——他们用的模型窗口是 512 token，大约两千个字符。

被截断的那部分，永远检索不到

超出窗口的内容既不参与计算，也不可能被匹配到，等于对检索系统隐形了。他们的做法是把切块下沉到数据库内部：建表时把向量列声明成 float_vector_array，指定切块模型与来源字段，写入时自动按策略切分。

查询侧有个重要约定：查询本身永远不切块。问题足够短，整体嵌入即可，只有入库的文档需要拆分。

三种切块策略，怎么选

truncate 只取开头。文档短的时候够用、最省资源，遇到长文就伤——文档页、知识库文章、合同、会议记录、邮件串、维基页面、说明文件、故障复盘，都会栽在它手里。

mean 把全文压成一个向量，适合主题单一的短材料，比如一件商品的完整描述、一份菜谱、一则招聘启事；文档一长、话题一多，平均值就把细节抹平了。

recursive 按段落层级递归切分。他们称这是写作文档的通用默认选择——Markdown、网页文档、维基、博客、结构化报告这类由人按段落写成的材料，在实测中深处内容得分最高。

实测数字说明了什么

测试集是 Manticore 自己的英文手册：189 页、约 29.8 万词，最短的是两段小记，最长的变更日志近三万九千词。作者特意圈出“深处内容”——标题出现在页面首约一千二百字符之后的那些查询，共 419 条。结果显示，召回率从 55.1% 提升到 83.3%，MRR 从 0.44 升到 0.70。

代价也写得很清楚：约 2.5 倍内存、约 4 倍入库时间。做容量规划时，这组数字比准确率更需要提前算——切块越细，向量越多，内存和写入都会跟着涨。

落地到企业知识库的建议

先按结构切，再按长度兜底。优先尊重标题、小节、段落这些天然边界，别用固定字数硬切；句子被拦腰截断的向量，对检索几乎没有价值。

把“深处内容”单独拿出来测。很多团队的评测集恰好都问文档开头写了什么，指标好看，一线却天天找不到答案。

用业务能感知的指标验收。不是向量相似度，而是“提问之后能不能命中正确段落”。检索质量差了，后面换再大的模型也补不回来。