SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

双编码器和交叉编码器

一个把问题和文档分别编码后比距离,速度快但精度有限。一个把问题和文档捆在一起编码,精度高但计算量大。选哪个决定了你的 RAG 系统是快而粗还是慢而准。

寓言

隔墙对诗和面对面品诗

城南有个诗社,每个月办一次评诗会。最初的办法很简单:投稿的人把诗写在纸上,评审的人也在纸上写出自己偏好的风格关键词。工作人员把两叠纸分别放进两个信封,送到评诗房,根据关键词的相似度排序,挑出前二十首。这个过程很快,一个下午能处理几百首。

但问题来了。有一首诗写了「明月松间照」,关键词匹配到了「月」「松」,被排到了前十。评委拿过来一看,发现这是一首打油诗,只是碰巧用了那几个词。还有一首诗通篇精妙,但作者用的词比较冷僻,关键词没对上,直接被筛掉了。

社长觉得不对。下次评诗会,他换了一种做法:把每一首诗和每一位评委的口味说明书放在一起,逐字逐句对照着读,看整首诗的意境、结构、用典是否匹配。准确率大幅提升,好的诗再也不会漏掉,差的诗再也不会混进来。但代价也很明显——原来一个下午评几百首,现在一个下午只能评几十首。

社长开了一次复盘会,把两种方法分别起了名字。第一种叫「隔墙对诗」,诗和评语分别处理,只在最后比一下距离。第二种叫「面对面品诗」,诗和评语绑在一起细细审读。

后来诗社摸索出一套组合用法:初筛用隔墙对诗,从几百首里快速拉出一个五十首的候选池。精选用面对面品诗,在这五十首里精细排一次序,挑出前十。

这套流程跑了一年以后,评诗会的口碑上了一个台阶。入选的诗质量稳定了,评审的时间也没有失控。诗社里流传着一句话:隔墙定候选,面对面定名次。

后来有人问社长,为什么不直接用面对面品诗处理全部来稿。社长说:你要是有无限的时间和算力当然可以,但我们没有。好方法要把有限的资源花在最有价值的那一段上。

后来师傅让快眼徒弟先挑十张,再让细眼徒弟一张张对照。快慢分工后,画像铺终于既接得住人,也挑得准。

双编码器 (Bi-Encoder)

将查询和文档分别独立编码为向量,再通过向量相似度(如余弦距离)进行匹配。编码可以预先计算和缓存,检索速度极快,但损失了查询与文档之间的细粒度交互信息。

交叉编码器 (Cross-Encoder)

将查询和文档拼接后一同输入模型,让模型在注意力机制中同时考虑双方的交互关系。精度远高于双编码器,但每对查询-文档都需要完整推理一次,无法预计算,计算成本高。

故事对应

  • 隔墙对诗:Bi-Encoder,分别编码,快速计算相似度。
  • 面对面品诗:Cross-Encoder,拼接输入,细粒度交互评分。
  • 关键词碰巧匹配的打油诗:Bi-Encoder 的语义漂移,向量相似但实际不相关。
  • 冷僻词的好诗被筛掉:Bi-Encoder 对罕见表达的召回不足。
  • 初筛 + 精选的组合流程:Bi-Encoder 粗排 → Cross-Encoder 精排,经典的 RAG 两阶段检索策略。

落到项目里

不要在 RAG 系统里二选一。标准做法是:Bi-Encoder 做第一阶段检索,从海量文档中召回 Top-K(通常 50-200);Cross-Encoder 对 Top-K 做重排序,输出 Top-N 送给大模型。这个流水线的性价比远高于单独使用任何一种。唯一需要调的是 K 值——K 太小会漏掉 Cross-Encoder 能救回来的好文档,K 太大会让 Cross-Encoder 的成本失控。