★ FEATURED ARTICLE 向量检索常被概括成一句话把查询和文档分别编码成一个向量然后计算余弦相似度。这个方案快、索引成熟也很适合作为 RAG 的第一版。但“一段文本压缩成一个点”并非没有代价。一个技术段落可能同时包含产品名称、版本条件、错误码、操作动作和例外条款单个固定维度向量需要把这些信号混在一起查询只关心其中一个细节时重要词可能被段落的主话题稀释。ColBERT 选择了另一条路线查询和文档仍然可以独立编码文档却不再只保留一个向量而是保留 token 粒度的多组向量真正检索时让每个查询 token 在文档 token 中寻找最相似的匹配再把这些最大相似度相加。这种架构被称为 Late Interaction即晚交互。它比 Cross-Encoder 更容易预计算和索引又比单向量保留更多细粒度匹配信号。多向量并不意味着任何语料都会变好也不意味着可以把所有 token 原样塞进普通向量库。索引体积、候选生成、压缩、查询延迟和训练域都会决定最终价值。本文先用一个不依赖大型模型的最小实现验证 MaxSim再接入官方 ColBERT 工作流最后给出能与现有 RAG 共存的落地方案。1. 单向量在哪些问题上容易吃亏考虑三个知识块文档 A系统在 4.8.2 版本修复导出任务重复提交问题错误码为 E1047。文档 B系统在 4.8.2 版本增加批量导入功能失败时返回 E2047。文档 C旧版导出任务超时后可重试但不得重复提交。用户问“4.8.2 导出重复提交对应什么错误码”。查询同时包含版本、动作、故障和目标字段。单向量会把整句压缩为一个整体语义A、B 共享版本A、C 共享导出与重复若语料中还有大量相似发布说明微小但关键的E1047容易被平均。关键词检索能抓住精确字符串却不理解“重复提交”和“幂等失败”的语义关系。ColBERT 为查询中的“4.8.2”“导出”“重复提交”“错误码”等 token 保留各自表示。评分时“4.8.2”可以匹配文档中的版本“导出”匹配动作“重复提交”匹配故障“错误码”匹配 E1047 周围的表示。每个查询 token 都有自己的最佳证据不需要先把全部需求揉成一个方向。这种优势在实体密集、条件组合、长尾术语、代码符号和多约束查询中更明显。对于“公司休假制度是什么”这类宽泛问题单向量已经能捕捉主题多向量的额外成本未必值得。设计时应先按查询类型分桶评测而不是只看一个汇总平均数。查询文本查询编码器查询 token 向量 q1...qm文档块文档编码器文档 token 向量 d1...dnMaxSim: 每个 qi 找最相似 dj求和得到文档分数Top-K 候选可选重排/生成2. MaxSim晚交互的核心计算设查询编码后得到 (m) 个向量 (q_1, …, q_m)文档得到 (n) 个向量 (d_1, …, d_n)并且向量已经 L2 归一化。ColBERT 的经典评分可以写为[S(Q,D)\sum_{i1}{m}\max_{j1}{n} q_i^T d_j]矩阵视角更直观先计算一个 (m \times n) 的相似度矩阵对每一行取最大值表示该查询 token 在文档中能找到的最佳匹配最后对行最大值求和。交互发生在编码之后所以文档 token 向量可以提前计算这也是它与 Cross-Encoder 的关键区别。Cross-Encoder 把查询和文档拼接后共同编码通常质量强但每个查询都要对候选文档重新前向计算难以直接搜索大规模全集。MaxSim 不是简单关键词对齐。token 表示经过上下文化同一个词在不同句子中可以有不同向量模型训练也会学习哪些 token 应被强调。ColBERT 的实现还会使用特殊查询标记、文档标记、掩码和投影层不能拿任意 BERT 的最后一层直接替代就声称等价。先用一个纯 NumPy 示例把计算过程固定下来。它不负责生成语义向量只验证形状、归一化和评分适合写成单元测试保护检索服务的核心逻辑。from__future__importannotationsimportnumpyasnpdefnormalize_rows(matrix:np.ndarray)-np.ndarray:ifmatrix.ndim!2:raiseValueError(expected a 2-D matrix)normsnp.linalg.norm(matrix,axis1,keepdimsTrue)ifnp.any(norms0):raiseValueError(zero vector cannot be normalized)returnmatrix/normsdefmaxsim_score(query:np.ndarray,document:np.ndarray)-float:ifquery.shape[1]!document.shape[1]:raiseValueError(query and document dimensions differ)qnormalize_rows(query.astype(np.float32))dnormalize_rows(document.astype(np.float32))similaritiesq d.Treturnfloat(similarities.max(axis1).sum())if__name____main__:query_vectorsnp.array([[1.0,0.0],[0.0,1.0]],dtypenp.float32)exact_documentnp.array([[1.0,0.0],[0.0,1.0]],dtypenp.float32)partial_documentnp.array([[1.0,0.0],[1.0,0.0]],dtypenp.float32)assertmaxsim_score(query_vectors,exact_document)2.0assertmaxsim_score(query_vectors,partial_document)1.0这个例子也展示了一个特性文档对第一个查询方向匹配得再多第二个查询方向没有证据时分数仍然缺一块。多向量评分关注查询各部分是否都能在文档中找到支持而不是让一个高度相似的主题信号盖过其他约束。3. ColBERT、Late Chunking 和重排器不是一回事它们都带有“late”或“更细粒度匹配”很容易被混为一谈。Late Chunking 是先用较大上下文生成 token 表示再按文本块池化最终每个块通常还是一个向量。ColBERT 保留块内多个 token 向量并在查询时执行 MaxSim。两者改变的是不同阶段可以分别使用也存在组合研究但不应在架构图中画成同一个组件。Cross-Encoder 重排器则把查询和候选块一起输入模型输出相关性分数。它能建模更充分的查询—文档交互但通常只用于几十或几百个候选。ColBERT 可以直接承担第一阶段检索也可以重排 BM25 或单向量召回的候选。选择哪种模式取决于语料规模、延迟预算和索引能力。还有一类普通向量数据库提供“一个业务记录包含多个向量”的功能但不同产品的评分聚合方式未必是 MaxSim有的只支持多字段加权有的不能为每个查询 token 生成动态数量的向量。接入前必须确认索引和查询算子而不是看到“multi-vector”字段就默认兼容 ColBERT。4. 官方工作流准备语料、建索引、查询官方stanford-futuredata/ColBERT仓库给出的基本流程是准备 collection、加载 checkpoint、构建索引并搜索。collection 通常是 TSV每行包含整数 passage id 和文本。索引不是一个通用的list[float]列而是多向量、聚类质心、压缩残差和文档映射等结构的组合。环境安装应以官方仓库当前说明为准。GPU 通常用于训练和高效建索引小规模查询或教学可以使用 CPU但不要据此估计生产吞吐。模型 checkpoint 和代码版本要固定否则重建索引后分数分布可能变化。python-mvenv .venv .venv\Scripts\activate pipinstallcolbert-ai[torch,faiss-cpu]下面示例沿用官方 Python API 的典型对象。第一次运行会下载模型并构建索引真实项目应把下载和建库放到受控离线任务不要在 Web 请求中触发。from__future__importannotationsfrompathlibimportPathfromcolbertimportIndexer,Searcherfromcolbert.dataimportQueriesfromcolbert.infraimportColBERTConfig,Run,RunConfig ROOTPath(.colbert)COLLECTIONPath(data/collection.tsv)CHECKPOINTcolbert-ir/colbertv2.0INDEX_NAMEmanual-v1defbuild_index()-None:ifnotCOLLECTION.is_file():raiseFileNotFoundError(COLLECTION)configColBERTConfig(nbits2,doc_maxlen300)withRun().context(RunConfig(nranks1,experimentrag-demo,rootstr(ROOT))):Indexer(checkpointCHECKPOINT,configconfig).index(nameINDEX_NAME,collectionstr(COLLECTION),overwritereuse,)defsearch(text:str,k:int5)-list[tuple[int,int,float]]:ifnottext.strip():raiseValueError(query must not be empty)withRun().context(RunConfig(experimentrag-demo,rootstr(ROOT))):searcherSearcher(indexINDEX_NAME,collectionstr(COLLECTION))passage_ids,ranks,scoressearcher.search(text,kk)returnlist(zip(passage_ids,ranks,scores,strictTrue))if__name____main__:build_index()forpid,rank,scoreinsearch(4.8.2 导出重复提交对应什么错误码):print(rank,pid,score)API 会随项目版本演进复制示例前应核对官方 README 和所安装包的版本。生产代码还需要显式保存 checkpoint 修订、配置、collection 哈希和索引清单。overwritereuse适合本地重复实验不代表可以在生产中复用来源不明的旧索引。5. 文档长度与 token 保留策略ColBERT 的doc_maxlen不是普通业务块的字符数而是模型最终保留的文档 token 上限。块太短会失去上下文并增加记录数量块太长末尾可能被截断多向量索引也变大。合理选择仍应从文档结构和查询证据范围出发而不是盲目沿用论文参数。对发布说明、API 手册和错误码文档可以按标题和列表项切成较短 passage因为每个条目本来就独立。对规章制度可以按条款切分并携带标题路径。不要为了“多向量能表达更多内容”把十页文档当成一个 passageMaxSim 允许每个查询 token 在任何位置寻找匹配过长文档更容易偶然拼出多个局部匹配造成虚高分而且返回给生成模型的证据难以阅读。查询端也有最大长度和 token 增强策略。ColBERT 经典设计会对短查询做特定填充从而提供更多可学习的查询表示这些细节由官方 tokenizer 和模型实现负责。自行删除标点、停用词或[MASK]等特殊位置可能改变已训练模型的行为。中文场景尤其要通过真实查询验证分词与模型训练域英文 MS MARCO checkpoint 并不自动等于中文生产模型。索引前建议统计 passage token 长度的 P50、P95、P99 和截断比例。若大量文本触顶先检查切分是否合理如果只是极少数附录超长可以单独处理。不能只扩大doc_maxlen因为索引空间和查询计算会随保留 token 数增长。6. 索引为什么会大以及 ColBERTv2 如何缓解单向量检索每个块保存一个向量朴素 ColBERT 每个块保存多个 token 向量空间很容易增加一个数量级。ColBERTv2 使用残差压缩把 token 向量近似表示为一个聚类质心加上量化残差索引保存质心编号和少量残差信息。论文报告的压缩收益来自特定数据和配置不应直接当作你项目的容量承诺。PLAID 进一步优化晚交互搜索通过质心交互和剪枝减少需要完整评分的候选。理解这些结构很重要因为它说明 ColBERT 不是“把 token 数组存进 JSON然后对全库跑 NumPy”。全量矩阵比较的复杂度和 I/O 会迅速失控真正的大规模检索需要专用候选生成、压缩和内核。容量评估至少包含原始 collection、模型文件、索引文件、构建临时空间和备份空间。建索引时峰值磁盘可能高于最终索引发布新版本还需要新旧索引并存。只用“最终目录大小乘文档数”估算容易在切换时把磁盘占满。还应记录每百万 passage 的构建时间、索引大小和查询 P95 延迟使用与你生产相近的平均 token 长度。压缩位数越低空间通常越小但可能影响召回更强的剪枝能降低延迟也可能漏掉候选。每次调参都要回到固定评测集不能只观察平均响应时间。索引参数是质量—成本合同的一部分应与模型版本一起管理。7. 与 BM25、单向量和 Cross-Encoder 组合没有必要一次替换现有检索栈。风险最小的落地方式是把 ColBERT 作为并行召回器BM25 负责编号、专有词和精确字符串单向量负责宽泛语义ColBERT 负责多约束细粒度匹配。三路各取候选后用 Reciprocal Rank Fusion 合并再做权限过滤和可选重排。RRF 不要求不同检索器的原始分数可比因为 BM25、余弦相似度和 MaxSim 的尺度完全不同。它按名次融合易于建立稳定基线。下面实现去重后的最小版本并保留每条候选的来源便于线上解释。from__future__importannotationsfromcollectionsimportdefaultdictfromdataclassesimportdataclassdataclass(frozenTrue)classFusedHit:passage_id:strscore:floatsources:tuple[str,...]defreciprocal_rank_fusion(rankings:dict[str,list[str]],limit:int20,rank_constant:int60,)-list[FusedHit]:ifrank_constant0:raiseValueError(rank_constant must be positive)scores:dict[str,float]defaultdict(float)sources:dict[str,set[str]]defaultdict(set)forsource,passage_idsinrankings.items():forrank,passage_idinenumerate(dict.fromkeys(passage_ids),start1):scores[passage_id]1.0/(rank_constantrank)sources[passage_id].add(source)orderedsorted(scores,keylambdaitem:(-scores[item],item))[:limit]return[FusedHit(item,scores[item],tuple(sorted(sources[item])))foriteminordered]if__name____main__:hitsreciprocal_rank_fusion({bm25:[p2,p1],colbert:[p1,p3]},limit3,)asserthits[0].passage_idp1asserthits[0].sources(bm25,colbert)另一种节省成本的方式是先用 BM25 或单向量召回几百个 passage再对这些候选计算精确 MaxSim。它不是完整 ColBERT 全库检索因为第一阶段漏掉的内容无法恢复但能低风险验证晚交互是否改善排序。若候选召回率已经足够高这种两阶段方案可能比部署专用多向量索引更合算。Cross-Encoder 可放在融合后的最后一级但层数越多并不必然越好。每一级都增加延迟和调试难度也可能把前一层正确结果重新排低。上线时保留每一级排名、分数与淘汰原因出现错误才能定位是召回缺失、融合错误还是重排误判。8. 评测不要只比较最终回答检索器评测需要 query、相关 passage 标注和稳定语料版本。至少报告 RecallK、MRRK、nDCGK并按查询类型拆分精确实体、多条件组合、语义改写、长尾术语、无答案问题。若只看 LLM 最终回答模型可能凭参数知识答对掩盖检索失败也可能因生成错误让正确检索背锅。对 ColBERT 还要增加效率指标索引大小、构建耗时、峰值显存、查询吞吐、P50/P95/P99 延迟、每次查询候选量。多向量质量提高两个百分点却让磁盘和延迟超出业务预算不能算可上线方案。反过来某一类高价值故障查询提升明显即使全局平均变化小也可能值得只在该路由启用。标注时需要允许多个相关 passage。一条答案的版本、动作和错误码可能分布在相邻块只有一个“黄金块”会把合理召回判错。还要把近似但有冲突的 passage 标为 hard negative例如相同版本的导入错误和旧版本的导出错误它们比随机无关文本更能测试细粒度匹配。离线通过后使用影子流量同一查询同时跑旧检索与 ColBERT记录差异但仍使用旧结果回答。人工抽检“新进 Top-K”和“被挤出 Top-K”的内容特别关注专有名词、短查询和超长 passage。观察充分后再按租户或查询类型小流量启用保留快速关闭开关。9. 典型失败与排查顺序第一种是语言或领域不匹配。官方 checkpoint 在特定数据上训练中文内部术语、医疗缩写或代码仓库未必表现良好。先用小规模真实标注集比较不要因模型在公开英文榜单优秀就跳过验证。若需要训练应准备查询—正例—难负例并严格隔离验证集避免同一文档的近重复块泄漏到两边。第二种是 passage id 不稳定。collection 重排后若用行号作为外部主键旧引用、反馈和评测标签都会指向错误文本。应维护不可变业务 chunk_id 与 ColBERT 内部整数 pid 的映射并把 collection 哈希写进索引清单。构建前校验 pid 唯一构建后抽样回读文本。第三种是索引与 checkpoint 不匹配。查询端换了模型索引仍由旧模型生成维度可能相同但空间已经不同。服务启动时应读取索引清单并核对 checkpoint、代码版本和参数不匹配就拒绝加载而不是等用户发现结果异常。第四种是短查询噪声。“报错”“怎么处理”这类查询 token 很少MaxSim 可能偏向大量泛化文档。可以结合会话上下文重写查询或路由到关键词与单向量融合但重写必须保留原始实体和编号。不要让 LLM 擅自补出用户没说的版本号。第五种是长文档偶然匹配。passage 越长查询每个 token 找到高相似位置的机会越多即便这些位置互不构成同一事实。应限制 passage 范围、保留结构边界并在最终候选上用 Cross-Encoder 或规则验证约束是否共同出现。多向量不是“不用切块”的理由。第六种是过滤顺序错误。若先取全库 Top-K 再做权限过滤用户可见结果可能不足并且检索服务可能把不可见文本交给后续重排或日志。更好的方式是在候选生成阶段做租户或权限分区无法原生过滤时扩大候选只是权宜之计仍要确保不可见正文不离开受控边界。10. 生产架构与可回滚发布把 collection、索引和映射视为一个不可分割的发布单元。构建任务在新版本目录完成生成 manifest内容包括源语料哈希、pid 数量、checkpoint、nbits、doc_maxlen、代码提交、评测结果和创建时间。所有校验通过后检索服务通过只读别名切换版本旧版本保留到观察期结束。在线服务不负责临时建索引。它加载只读索引限制查询长度和并发对空查询、超长查询和非法租户快速失败。超时后可以回退到已有 BM25 或单向量检索但响应元数据要记录降级监控分别统计不能把回退结果当作 ColBERT 成功。模型推理、索引搜索和正文读取可以拆开扩容但最初版本不必过度微服务化。只要单进程能满足容量一个服务加载一个不可变索引最容易维护。等索引超出单机内存或吞吐实测不足再引入分片和副本。过早分布式化会让版本一致性、路由和调试成本先到来而业务收益尚未验证。日志记录 query_id、索引版本、耗时、返回 pid 和分数即可原始查询与正文应按数据分级决定是否留存。用户反馈要绑定当时的索引版本和候选列表否则索引升级后无法复盘。对安全敏感查询进行脱敏或哈希不要为了检索分析建立另一个无权限控制的影子知识库。11. 用 token 匹配解释结果但不要过度承诺MaxSim 天然产生查询 token 到文档 token 的最佳匹配位置这为调试提供了比单个余弦分数更丰富的信息。可以把相似度矩阵中每一行的最大位置记录下来在内部诊断页展示“查询中的版本号匹配了哪里、动作词匹配了哪里”。当错误文档排名靠前时工程师能看见究竟是实体错配、常用词贡献过高还是长文档拼出了分散匹配。解释页面必须使用与实际搜索相同的 tokenizer、checkpoint、归一化和掩码若为了展示重新用另一个模型分词位置会错。子词 token 需要合并成可读文本特殊 token 和填充位置不显示。中文分词可能把一个术语拆成多片前端应按原文字符偏移高亮而不是直接把模型 token 拼给业务用户。这种高亮是“分数如何形成”的诊断不是“模型理解了什么”的因果证明。某个 token 获得最高相似度不代表它在语言学上就是正确对齐也不代表文档事实可信。解释功能适合内部排查和标注辅助面向终端用户仍应展示完整引用、来源和版本避免把彩色热力图包装成确定性证据。还应观察匹配集中度。如果一个长 passage 的查询 token 最佳位置分散在互不相关的多段可能是偶然拼接若关键 token 集中在一个句子附近证据通常更完整。可以把跨度作为重排特征或告警信号但不要未经评测就设硬阈值因为列表、表格和跨句定义本来就可能分散。12. 分数校准与查询长度问题MaxSim 对每个查询 token 的最大相似度求和原始分数会受到查询 token 数量影响。不同长度查询之间的分数通常不能直接用同一阈值判断“有答案”。在一个请求内部排序没有问题但若要做全局拒答、监控或跨查询比较就需要基于验证集校准。最直接的方法是按查询长度分桶分别统计正例和最难负例的 Top-1 分数分布再选择满足业务风险的阈值。也可以训练轻量校准器输入 Top-1 分数、Top-1 与 Top-2 差值、查询长度、候选来源和 BM25 是否命中等特征输出可解释的置信区间。校准器必须在时间或文档维度独立的验证集上训练不能把同一文档的近重复问题随机拆到训练与验证两边。短查询尤其容易缺少约束。用户只输入一个错误码时精确关键词通常非常强应让 BM25 参与融合用户输入长自然语言时ColBERT 的多局部匹配更有发挥空间。查询路由可以从最简单的规则开始例如识别明确编号并提高关键词通道权重只有真实评测证明需要时再引入学习路由。拒答不能只看一个绝对 MaxSim 分数。更可靠的判断还包括是否存在权威来源、多个候选是否冲突、关键实体是否在正文出现、引用能否覆盖答案。检索分数描述相关性不等同于事实正确性和回答安全性。13. 更新、删除与多租户隔离多向量索引的更新成本常被低估。一个 passage 对应多组压缩向量和内部映射增删不一定像普通数据库更新一行那样简单。若官方引擎对在线增量支持有限最可靠方案是周期性构建新索引再用别名原子切换。更新频繁的内容可以先进入一个较小的增量索引查询时与主索引融合达到阈值后再压实重建。删除请求要先从权限层立即屏蔽 pid再安排物理索引清理。只等待下一次全量构建可能在数小时内继续暴露内容。业务 chunk_id 到内部 pid 的映射必须可反查且映射版本与索引绑定否则删除一篇文档时无法确定它对应哪些压缩向量。多租户系统优先采用物理或逻辑分区使候选生成阶段就不会搜索其他租户。若把所有租户放进同一索引后再过滤Top-K 可能全部来自不可见租户扩大 K 只是性能与正确性的权宜折中更严重的是不可见内容可能已经进入解释或重排组件。索引分区粒度需要结合租户规模不能让数万个微型索引拖垮运维也不能把所有数据混成一个无边界全集。备份不只复制索引目录还要同时保存 collection、pid 映射、manifest 和 checkpoint 标识。恢复演练必须验证相同查询能找到相同 passage而不是目录能解压就算成功。若模型文件依赖远程下载应在合规的制品仓库留存固定修订避免灾难恢复时上游模型已经变化或下线。14. 中文和垂直领域如何训练与验证一个检索模型是否支持中文不能只看 tokenizer 能否输出 token。关键是预训练与检索训练是否覆盖中文语义、专业术语和你的查询风格。先评测公开或现有 checkpoint若精确实体正确但同义改写较差可能需要领域训练。若错误主要来自文档切分、权限或标签训练模型不是第一优先级。训练数据通常包含查询、正例 passage 和负例 passage。随机负例太容易模型学不到版本、产品和动作之间的细微差异。应从现有 BM25、单向量或旧 ColBERT 的高排名错误结果中挖 hard negative例如同一产品不同版本、相邻错误码、相同动作不同模块。负例要经过规则或人工检查避免把实际相关段落当负例制造相互矛盾监督。数据划分优先按文档、产品或时间隔离。把同一手册的相邻块分别放入训练和验证会让指标虚高发布说明场景可以用较早版本训练、较新版本验证更接近上线后遇到新内容的情况。每次训练保存数据快照、随机种子、基础 checkpoint、超参数和评测结果不能只留下一个无法复现的权重目录。训练后的验收不仅比较平均 nDCG还应查看已知关键查询是否退化、索引大小是否变化、查询延迟是否可接受。新模型必须构建新索引不能拿它查询旧向量。影子流量观察后再切换并保留原 checkpoint 与索引作为完整回滚对。15. 什么时候不该用 ColBERT如果语料只有几千条、查询简单且现有 BM25 已满足目标就没有必要引入多向量索引。如果数据频繁逐条更新而当前工具链只能整库重建需要先评估新鲜度能否接受。如果硬件和运维团队无法稳定管理模型、索引和版本单向量加 Cross-Encoder 重排往往是更成熟的路径。若主要问题是源文档脏、权限错误、切块跨表格或答案没有引用替换检索模型不会解决根因。先修正文档解析和评测集再谈更复杂的评分。多向量最值得投入的场景是现有召回对主题判断正确却经常把版本、实体、动作和限制条件混淆并且这类错误在业务上足够昂贵。决策前可以做一个廉价验证沿用现有第一阶段召回只对固定候选离线计算 ColBERT 分数比较它能否把相关块从候选内部排到前面。如果候选集中根本没有正确块说明首阶段召回才是瓶颈如果晚交互稳定改善排序再评估专用全库索引是否值得。这样把“模型是否有用”和“系统是否值得重建”拆成两个可回答的问题。正式上线的退出条件也要提前写清质量提升低于门槛、P95 延迟超过预算、索引构建无法在更新窗口完成或运维恢复演练失败都应保持旧检索为主。技术选型不是单向门完整的新旧索引和流量开关能让团队基于证据继续迭代而不是被一次迁移绑住。ColBERT 的核心启发并不是“向量越多越好”而是相关性由多个局部证据共同构成。单向量强调全局语义关键词强调精确匹配晚交互保留查询各部分与文档局部之间的对应关系。通过可归因的离线评测、清晰的成本核算和可回滚发布它可以成为 RAG 检索栈中的一层而不是一场无法撤回的重写。参考资料Khattab 与 Zaharia《ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT》https://arxiv.org/abs/2004.12832Santhanam 等《ColBERTv2: Effective and Efficient Retrieval via Lightweight Late Interaction》https://arxiv.org/abs/2112.01488Santhanam 等《PLAID: An Efficient Engine for Late Interaction Retrieval》https://arxiv.org/abs/2205.09707Stanford Future Data SystemsColBERT 官方代码库https://github.com/stanford-futuredata/ColBERTColBERT 官方 LoTTE 评测集说明https://github.com/stanford-futuredata/ColBERT/blob/main/LoTTE.mdBEIR《A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models》https://arxiv.org/abs/2104.08663Cormack 等《Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods》https://dl.acm.org/doi/10.1145/1571941.1572114
阅读完成 · 觉得有帮助？
