Manticore Search 长文档向量检索新解
Better Vector Search for Long Documents: Chunking Inside Manticore Search
当你在 Manticore Search 中处理长文档时，可能会遇到一个隐蔽的陷阱：模型输入窗口有限，导致文档后半部分的内容被直接丢弃，却无人知晓。以往你需要手动拆分文档并处理结果合并，而现在 Manticore 在表定义中直接引入了 chunk_strategy 参数。通过设置 sentence 等策略，系统自动将文档切分、嵌入并检索所有片段，同时保持文档作为单一搜索结果返回。实测显示，对于隐藏在模型窗口之外的内容，召回率从 55.1% 提升至 83.3%，让长文档检索不再“丢三落四”。
文档中该点之后的内容永远无法被检索到，而且没有任何地方会告诉你这件事。
HN 评论区
11- entrope
文章很大一部分篇幅都在讨论由 512 token 输入限制引发的问题。例如，输入窗口这么小，就需要切分出更多的块，尤其是还要考虑重叠部分。我知道有些嵌入模型确实只有这么小的上下文窗口，但 8K 和 32K 的窗口已经得到了广泛支持，并且能显著减少与分块相关的问题。
对于英语这类语言，文本内部通常存在大量冗余，因此 512 token 可能无法提供清晰的上下文指示。许多文档都有相似的介绍部分（比如 "#include <foo.h>\n"），这使得短上下文和截断操作尤为有害。
另外，文中提到“该点之后的文档内容永远无法被检索到，而且没有任何地方告知你这一点”。这种行为对用户极不友好，即使他们不想承认自动嵌入功能支持得不好。
最后，后面那段关于截断是“你本来就已经有的”的描述，读起来更像是 Claude 在对开发者说话，而不是厂商在对用户说话。不过话说回来，也许这对于一个主要搜索页面标题、聊天日志和 Xeets 的数据库来说，是个不错的默认设置？
- hn45e7pbij
更大的上下文窗口确实有帮助，但并不能消除分块的必要性。将 8K token 嵌入到一个向量中会把所有信息都抹平，导致检索质量下降，即使没有任何内容被截断。
- Chance-Device
挺有意思的，我相信对于那些正在自建 RAG 系统的人来说，这会很有用。