把一篇五千字的技术手册塞进向量数据库，终端悄无声息地返回成功，但背后的嵌入模型其实只读了前 380 词。受制于轻量模型通常仅有 512 tokens 的上下文窗口，剩下的三千多词被静默丢弃，文档后半段的核心操作在检索中彻底蒸发。长期以来，开发者不得不依赖外部流水线把文章切成碎块，再通过子表或缓存把碎片拼回整篇。开源搜索引擎 Manticore Search 在 29.9.0 版本中给出了内核级解法，直接在建表语句里用纯 DDL 声明切块策略，试图把繁琐的 RAG 胶水层彻底抹平。
一行 SQL 终结切块胶水层
过去搭建长文本检索系统，工程链路通常格外臃肿。开发者要么用 LangChain 的 ParentDocumentRetriever 配合独立文档库切分存储，要么依赖 Qdrant 和 Milvus 的分组检索功能在外部去重，或者配置 OpenSearch 繁复的 text_chunking 写入管道。如果选用功能更完备的 Elasticsearch，则需要通过 semantic_text 机制在底层生成隐藏嵌套文档，并处理复杂的字符偏移量。
Manticore Search 29.9.0 换了一种极简思路。它允许开发者在定义 float_vector_array 字段时，直接附加 chunk_strategy 参数。数据写入时，数据库引擎内部自动切词、并发推断嵌入向量，并由底层 HNSW 索引接管全部向量碎片。
在支持的五种策略中，truncate 与 mean 输出单个向量，存入普通的 float_vector 字段；而 fixed、recursive 与 sentence 策略则输出多向量，必须配合多向量数组字段使用。用户可以微调 max_tokens 块大小、overlap_tokens 重叠长度，并用 max_chunks 设置单文档切块保底上限。
这个改动的绝妙之处在于查询请求永不切块。由于用户搜索词天然简短，只有存入的底库文档被拆分，检索时 Top-K 统计的依然是文档数量而不是切块数量，系统自动以最接近的单块距离作为整个文档的相似度得分。同期发布的版本还引入了 mmap 列式访问，全方位优化存储引擎的 I/O 效率。
召回率跃升与硬性算力损耗
把数据切开确实能捞回被截断的信息。根据官方基于 189 页、约 29.8 万词的英文技术手册基准测试，在 32 线程环境下采用 Xenova/all-MiniLM-L6-v2 模型验证，recursive 策略展现出立竿见影的效果。针对埋藏在文档 1200 字符之后的深层内容，Hit@5 从 55.1% 提升至 83.3%，平均倒数排名 MRR 也从 0.44 跃升到 0.70。
但工程世界不存在免费午餐，性能数字大幅改善的背面是清晰的资源代价。
索引所占用的内存直接从 4.2 MB 膨胀到 11.7 MB，整体开销接近 2.8 倍。更严峻的瓶颈落在写入吞吐上，单次导入耗时从 21 秒拉长到 86 秒，写入延迟暴涨 4.1 倍。这种延迟并不是切词算法本身拖慢的，核心瓶颈在于嵌入模型的推断次数成倍放大。
- 风险.若在海量数据且频繁高并发写入的生产集群中开启多向量切块，CPU 与推断算力会被急剧挤压，建表前必须精确核算写入承载力。
此外，当前版本还有一个显性约束，模型支持的多向量字段必须在执行建表时显式定义，系统暂不支持后续使用 ALTER TABLE 动态追加切块列并重建索引。这意味着既有业务库想要享受该特性，必须经历全量数据迁移。
最佳单块机制背后的语义断裂
即便算力充裕，把切块逻辑全盘推给数据库也并非高枕无忧。许多人容易产生错觉，以为把整篇文档切碎建库，检索系统就真正读懂了长篇大论。
实则不然。Manticore 当前的核心逻辑本质是单块最优打分机制，也就是用匹配度最高的一块代表整篇文档。这种贪心策略在单一事实查询中非常奏效，但在复杂推理下极度脆弱。
一篇文档若在两处各答对一半，其综合得分往往会败给仅有一处沾边的平庸结果。
当用户的问题需要跨章节整合两处信息时，系统无法进行跨切块的证据累加。更棘手的问题出在上下文断裂上。Manticore 切块后并没有内置语境增强能力，后方的段落完全脱离了标题、层级和前文主旨。如果一段技术细节通篇只写着代词它与该服务，一旦被切成孤立碎片，模型推断出的向量就会严重偏离本意。
测试数据甚至揭示了一个反直觉的细节，在前 1200 字符以内的浅层内容检索中，未切块的截断策略其首位命中率 Hit@1 达到 65.9%，反而明显优于 recursive 策略的 58.0%。
这是因为短文档未被切割时，整篇语义更加收敛集中；而切成细碎片段后，过短的切片缺乏上下文支撑，反而更容易被干扰项误导。加之系统目前采用的是先切分再分别计算嵌入的常规路线，并没有引入长文本全局编码后再分块池化的 Late Chunking 技术，跨块的长程关联在切刀落下的那一刻便已不可逆地丢失了。
工具收编外围，架构各安其位
数据库历史上每一次演进，几乎都在重复吸收外围组件的宿命。正如当年关系型数据库收编文件索引与事务中间件一样，Manticore 将分块向量化做进内核，也是检索引擎对抗架构复杂度的必由之路。
天下大事，合久必分，分久必合。在软件工程里，胶水层存在的意义往往是修补基础设施的能力空白。
面对长文档检索，选型逻辑正变得十分明朗。如果团队只是维护内部知识库、运维手册或客服应答系统，不需要极其严苛的高亮引用，那么尽早扔掉笨重的外部流水线，改用 Manticore 的单表声明，是消除维护负担的高效路径。
但如果业务是严肃的司法分析或医疗问答，系统必须拿到精确命中的文本字符偏移量，或者依赖跨段落深度推理，那么支持高亮返回的 Elasticsearch、或者保留应用层语境注入的定制流水线，依然是短时间内无法逾越的护城河。