工程实践pgvector Elasticsearch RRF 混合检索在合同条款比对中的落地面向开发者 / 架构师 | 技术深度 | 适配掘金 / CSDN / 博客园合同条款比对有个怪现象纯向量检索pgvector能找语义相近的条款却常漏掉字面几乎一样、只换了数字的表述“账期 30 天” vs “账期 90 天”纯关键词BM25/Elasticsearch能精确抓账期二字却不懂付款周期和账期是一回事。制造业合同比对既要认字也要懂意。本文讲清 draft-legal 的 Portfolio Agent 采用的双通道召回 RRF 融合怎么写、怎么调参、Benchmark 长什么样。一、为什么不用 cross-encoder 重排有人会问为什么不直接向量召回 Top-100 再接 cross-encoder 重排可以但重排是串行且贵的——每份查询多花数百毫秒和一次大模型调用。RRF 是无监督、零额外推理的融合先把两路便宜结果并起来只把 Top-10 送大模型。制造业合同库动辄几十万条省下的推理费是真金白银。二、三层检索架构查询这类付款条款我们吃过几次亏 │ ┌────────┼────────┐ ▼ ▼ ┌──────────┐ ┌──────────────┐ │ pgvector │ │ Elasticsearch│ │ 稠密向量 │ │ BM25 稀疏 │ │ (语义相似)│ │ (字面命中) │ └────┬─────┘ └──────┬───────┘ │ rank_dense │ rank_sparse └───────┬────────┘ ▼ ┌──────────────┐ │ RRF 融合排序 │ │ scoreΣ1/(kr)│ └──────┬───────┘ ▼ Top-K 条款 引用溯源两路互补性强稠密侧抓意思像稀疏侧抓词一样。验收合格后支付和到货即付语义相反纯关键词混为一谈货到付款和款到发货纯向量可能判成近似。只有两路相互校验既懂意又不漏字。三、核心实现RRF 融合排序defrrf_fuse(dense_ranks:dict,sparse_ranks:dict,k:int60)-list:fused{}fordoc_id,rankindense_ranks.items():fused[doc_id]fused.get(doc_id,0.0)1.0/(krank)fordoc_id,rankinsparse_ranks.items():fused[doc_id]fused.get(doc_id,0.0)1.0/(krank)returnsorted(fused,keyfused.get,reverseTrue)查询时两路并行召回各 Top-50RRF 融合后取 Top-10 送大模型比对。-- 稠密侧pgvectorSELECTid,content,1-(embedding:q_vec)ASsimFROMclausesORDERBYembedding:q_vecLIMIT50;// 稀疏侧Elasticsearch{query:{match:{content:账期 付款 违约}},size:50}稀疏侧分词器要用对否则术语被切坏。给 clause 字段配 ik_max_word 制造业自定义词典{settings:{analysis:{analyzer:{contract_ik:{type:ik_max_word,filter:[contract_stop]}}}},mappings:{properties:{content:{type:text,analyzer:contract_ik}}}}k60 是经验值太小头部排名过度主导太大会抹平两路贡献。制造业语料上 k60 比 k10 命中率高约 7 个点。分块按条款而非固定字数保证一个 chunk 是一条完整义务向量才准。四、性能数据命中率与延迟2000 份真实采购合同建库500 条人工标注应召回条款评测方案Recall10平均延迟纯 pgvector0.8138ms纯 Elasticsearch0.7612msRRF 融合0.9352ms融合把漏召的字面相同但语义漂移类条款补回Recall 12 点延迟仍可控比单路多一次合并 ~14ms。按条款类型拆条款类型纯向量纯 ESRRF付款/账期0.780.880.95违约/责任0.830.740.94质保/验收0.800.790.92账期类纯 ES 最高数字和字面最关键违约类纯向量最高表述花样多。RRF 把两头短板都补齐。成本侧仅多一次内存合并无额外模型调用。并发 50 查询延迟稳定在 60ms 内ES 和 pgvector 走连接池两路并行使系统更稳。注意RRF 是召回增强而非精度增强Top-10 仍可能有噪声最终由大模型 引用溯源兜底。别指望融合替代审核。五、踩坑记录7 条embedding 维度不一致换模型后旧向量没重建召回腰斩。建库锁模型版本迁移全量重算。BM25 分词不友好“质保金”连带责被切坏加 ik 自定义词库才正常。RRF 掩盖单路失效某次 ES 索引损坏 RRF 仍吐结果。现两路各自打健康分任一低于阈值告警。引用溯源造假大模型把融合结果编成不存在条款。强制每条回贴 chunk_id无 id 不展示。向量未归一化用 cosine 外距离时量纲乱掉结果漂移。统一归一化 cosine固定距离算子。测试集泄漏同批合同既建库又评测Recall 虚高到 0.97。改时间切分旧建库、新评测得真实 0.93。评测口径比模型更易骗自己。冷启动无历史新系统库空组合智能空转。先导入近三年历史合同建底库再开 Portfolio 检索——组合洞察依赖量。六、开源实现参考混合检索已在 draft-legalPortfolio Agentpgvector ES RRF与 01amine/CLMQdrant MongoDB有不同实现。wraft 的 Elixir 体系提供文档检索范式aakd 的 MCP 端点已把合同检索暴露成标准协议draft-legal 的 BYOK 模式让你自带向量模型密钥无供应商锁定。小团队嫌双基础设施重可用 Qdrant 同时存稠密 稀疏向量平替但我们推荐 pgvector ES——稀疏侧 BM25 调参空间更大运维多半已会 ES。开放性问题如果你的合同库里字面一样、数字不同的坑条款最多你会优先调稠密侧还是稀疏侧调参的杠杆k 值 / 分块粒度 / 分词词典你先动哪一个动手试试想本地验证 RRF 融合的召回提升拉取合同管理系统开源 Demo或到官网免费试用用你们合同库跑一轮比对。也欢迎加入技术社群交流召回调优经验。