一段文档压成一个向量，搜索很方便。细节怎么办？查询里多了一个限定条件，结果的主题仍然相近，实际用途已经变了。ColBERT 采用了一种更细的匹配办法。我对照了原始论文、作者仓库和第二版研究，它把这件事称为后期交互。
这个名称里的“后期”指计算顺序。查询和文档先各自通过编码器，等各自有了表示，才计算两者之间的匹配。2020 年的 ColBERT 论文让 BERT 参与编码，同时保留后面的细粒度交互。文档表示可以提前算好，用户每次输入问题时，无须让所有查询与文档组合重新走一遍完整编码过程。
一段资料可以有多个向量
作者仓库把段落表示画成 Token 级向量矩阵，查询同样对应一个矩阵。也就是说，一段话保留多个位置的向量，查询中的局部信息可以分别参与比较。这里的 Token 由模型分词决定，不一定刚好对应一个中文词，理解时不要把它当作人工切出来的关键词清单。
ColBERT 使用 MaxSim 计算匹配。可以把基本过程理解为，查询的每个 Token 到文档的 Token 向量里寻找最相近的位置，再汇总这些匹配分数。它保留了比单个文档向量更细的比较机会，但高分仍然表达模型估计的相关性。否定条件、数字关系是否被正确理解，依然需要用题目检查。
原始论文同时讨论了候选重排和从大型语料直接检索。后期交互描述一种匹配结构，重排描述系统中重新排列候选的步骤，两者并不等同。团队评估方案时要问清它放在哪一段流程，否则可能把一种结构的效果，错当成所有重排方法都有的效果。
多存的向量会产生实际开销
每个段落保留多个向量，索引就要处理更多数据，ColBERTv2 的研究因此直接把空间占用列为问题，使用残差压缩，并结合去噪监督改进检索。论文报告的空间缩减有明确实验条件，不能据此推算自己公司的知识库一定能省多少机器。
这也是我看检索演示时会多问的一步。演示只给响应速度，通常不足以决定是否迁移。原文量多大、切成多少段、索引占多少空间，这些条件会影响结果。文档持续更新的团队，还应实际测一次新增和删除后的可检索状态，确认维护工作在现有资源内做得完。
采用更细的匹配前，先检查当前失败属于哪一类。资料没进库，改匹配结构帮不上忙。相关段落已经进入候选却总排在后面，后期交互才有值得比较的地方。建议保留一组带明确限定条件的真实查询，人工标出应该出现的段落，用同一批题评估变化。
试验记录里可以同时保留查询耗时和索引大小，最后让使用者看结果是否更容易找到。若收益只出现在少量问题上，就继续判断这些问题在业务里有多常见。服务器上多放一套索引，之后每次内容更新也要有人维护，这笔工作应当在选型时算进去。