在智能客服系统里我们经常遇到一个头疼的问题用户问了一个问题系统可能会用不同的方式去理解生成好几个查询然后从知识库或FAQ里拉出一堆候选答案。怎么把这些结果“揉”成一个最靠谱的回复给用户呢传统方法比如简单按相关性分数取Top-K或者粗暴地加权平均常常要么反应慢要么给出来的答案啰嗦重复用户体验大打折扣。最近在项目里我们尝试用重排序Re-ranking技术来优化这个“多查询结果融合”的环节效果挺明显的。响应速度上来了答案也更精准了。今天就来聊聊我们的实战心得从问题分析到代码落地再到性能调优和踩过的坑希望能给有类似需求的同学一些参考。1. 背景与痛点为什么传统融合方法不好用先说说我们遇到的具体问题。我们的客服机器人接收到用户query后会通过意图识别和查询改写生成3-5个语义相近但侧重点略有不同的查询语句。每个查询都会去检索知识库各自返回一个候选答案列表。传统做法A取并集再按原始分排序。把所有候选答案丢到一个大池子里按它们来自各自查询的原始相关性分数比如ES的_score排序。问题来了不同查询的分数尺度可能不一致一个查询的80分和另一个查询的75分哪个更相关没法直接比。而且会导致热门但可能不精准的答案总排前面。传统做法B加权平均分数。给不同查询赋予固定权重比如主查询权重高改写查询权重低计算每个候选答案的加权平均分。这稍微好点但依然没考虑答案之间的语义关系容易选出“四平八稳”但非最优的答案并且计算延迟随着候选集增大而线性增加。核心痛点总结延迟问题融合逻辑如果复杂比如要做很多文本比对在候选答案多的时候几十上百条实时计算压力大拖慢整体响应。冗余问题返回的Top结果里经常有好几条表达不同但意思几乎一样的答案浪费了展示位也干扰用户选择。精度问题缺乏一个全局视角的评判。一个答案可能对某个改写查询得分不高但对用户原始问题的语义匹配度却是最高的传统方法发现不了这点。2. 技术选型哪种重排序算法更适合我们重排序顾名思义就是用一个更牛的模型对初步检索出来的粗排结果列表进行重新打分和排序。我们的目标是把多个查询得到的结果混合列表重新排个更合理的序。主流重排序技术对比Learning to Rank (LTR)是什么传统机器学习方法把排序问题转化为分类或回归问题。需要人工构造特征如词频、BM25分数、文本长度、查询与答案的编辑距离等。优点模型相对轻量推理速度快可解释性较强。对于有明显特征规律的问题效果不错。缺点特征工程依赖经验难以捕捉深层次的语义信息。在我们的场景里不同查询结果之间的语义相似度这种复杂特征不好构造。适用场景对延迟要求极度苛刻且业务逻辑的特征相对明确、稳定的场景。基于BERT等预训练模型的Cross-Encoder是什么将“用户查询”和“候选答案”拼接在一起输入BERT等模型直接输出一个相关度分数。优点效果通常最好能深度理解语义关联。我们最终选的就是这个方向。缺点计算成本高。每个查询答案对都需要完整走一遍模型前向传播如果候选答案多延迟爆炸。适用场景候选答案数量不多例如10-20条且对精度要求极高的场景。基于双塔模型Bi-Encoder的向量检索精排是什么查询和答案分别通过编码器得到向量通过向量相似度如余弦进行粗排。可以先用这个快速筛选出Top-K再用Cross-Encoder对Top-K进行精排。优点平衡了精度和速度。粗排阶段极快近似最近邻搜索精排阶段只对少量候选做深度计算。缺点需要维护两个模型或一个模型两种用法架构稍复杂。精度略低于纯Cross-Encoder。适用场景这非常适合我们的多查询融合场景我们可以将多个查询和所有候选答案都编码成向量在向量空间进行快速匹配和初筛极大减少需要精排的数量。我们的选择考虑到生产环境高并发和低延迟的要求我们采用了“双塔模型粗排 Cross-Encoder精排”的两阶段流水线。粗排负责快速从混合的大候选池中筛选出最有希望的20-30个答案精排则在这小范围里用强大的语义模型决出最终排名。这个策略完美解决了延迟和精度的矛盾。3. 核心实现从特征到融合的代码流水线下面用Python代码片段展示核心流程。我们假设已经有了一个初步的混合候选答案列表candidate_pool每个元素包含答案文本和来源查询的原始分以及用户原始问题original_query。第一步双塔模型粗排快速筛选这里我们使用sentence-transformers库它提供了现成的预训练双塔模型。from sentence_transformers import SentenceTransformer, util import numpy as np # 加载预训练的双塔模型例如 all-MiniLM-L6-v2 平衡了速度和效果 bi_encoder SentenceTransformer(all-MiniLM-L6-v2) def coarse_ranking(original_query, candidate_pool, top_k30): 粗排使用双塔模型快速筛选Top-K候选 # 准备文本将原始查询和所有候选答案文本提取出来 # 注意这里我们只用了原始查询进行向量化。更复杂的策略可以考虑融合多个改写查询。 answer_texts [candidate[text] for candidate in candidate_pool] # 编码 query_embedding bi_encoder.encode(original_query, convert_to_tensorTrue) answer_embeddings bi_encoder.encode(answer_texts, convert_to_tensorTrue) # 计算余弦相似度 cos_scores util.cos_sim(query_embedding, answer_embeddings)[0] # 获取Top-K索引 top_results np.argsort(-cos_scores.cpu().numpy())[:top_k] # 返回粗排后的候选列表 coarse_ranked_candidates [candidate_pool[i] for i in top_results] # 附加上粗排相似度分数供后续参考 for idx, cand in enumerate(coarse_ranked_candidates): cand[coarse_score] cos_scores[top_results[idx]].item() return coarse_ranked_candidates第二步Cross-Encoder精排精准打分对粗排后的少量候选使用更强大的模型进行精细打分。from sentence_transformers import CrossEncoder # 加载Cross-Encoder模型例如 cross-encoder/ms-marco-MiniLM-L-6-v2在问答对排序上表现良好 cross_encoder CrossEncoder(cross-encoder/ms-marco-MiniLM-L-6-v2) def fine_ranking(original_query, coarse_ranked_candidates): 精排使用Cross-Encoder对粗排结果进行精确打分和排序 # 准备模型输入将查询和答案文本组合成句子对 sentence_pairs [[original_query, candidate[text]] for candidate in coarse_ranked_candidates] # 模型预测相关度分数 scores cross_encoder.predict(sentence_pairs) # 将分数附加到候选答案上 for candidate, score in zip(coarse_ranked_candidates, scores): candidate[fine_score] score # 按精排分数降序排序 fine_ranked_candidates sorted(coarse_ranked_candidates, keylambda x: x[fine_score], reverseTrue) return fine_ranked_candidates第三步结果融合与后处理精排之后我们得到了一个有序列表。但还需要解决冗余问题。from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity def deduplicate_and_fuse(fine_ranked_candidates, similarity_threshold0.8): 去重与融合去除语义高度相似的冗余答案 if not fine_ranked_candidates: return [] texts [cand[text] for cand in fine_ranked_candidates] # 使用TF-IDF向量化并计算余弦相似度矩阵简单高效适合短文本去重 vectorizer TfidfVectorizer().fit_transform(texts) cosine_sim_matrix cosine_similarity(vectorizer, vectorizer) final_results [] used_indices set() # 贪心选择按精排分数从高到低遍历如果与已选结果不高度相似则加入最终列表 for i in range(len(fine_ranked_candidates)): if i in used_indices: continue current_candidate fine_ranked_candidates[i] is_redundant False for j in final_results: # final_results里存的是索引或对象这里假设存了对象 # 计算当前候选与已选任一结果的相似度 if cosine_sim_matrix[i, j[index]] similarity_threshold: is_redundant True break if not is_redundant: # 记录原始索引用于相似度矩阵查询实际代码中可能需要调整 current_candidate[index] i final_results.append(current_candidate) used_indices.add(i) # 达到所需数量可提前终止 if len(final_results) 5: # 假设最终返回5条 break return final_results主流程串联def multi_query_fusion_pipeline(original_query, candidate_pool): 多查询结果融合主流程 # 1. 粗排快速从大池子筛选 coarse_candidates coarse_ranking(original_query, candidate_pool, top_k30) # 2. 精排对粗排结果深度语义打分 ranked_candidates fine_ranking(original_query, coarse_candidates) # 3. 去重融合得到最终简洁、有序的结果列表 final_answer_list deduplicate_and_fuse(ranked_candidates) return final_answer_list4. 性能优化让重排序快到飞起直接部署上面的流程并发一高肯定扛不住。我们做了下面这些优化并发与异步处理粗排编码并行化对多个候选答案的编码bi_encoder.encode可以利用模型的批处理能力一次性传入一个batch的文本而不是循环单条处理。sentence-transformers的encode本身支持批处理。精排预测批处理同样cross_encoder.predict也支持批量句子对输入。将粗排产生的所有sentence_pairs一次性传入。异步化整个流水线在Web服务框架如FastAPI中将融合流水线封装成异步函数避免阻塞事件循环。对于模型推理部分如果使用ONNX Runtime或TensorRT可以结合其异步接口。向量缓存策略答案向量缓存知识库中的答案文本相对稳定。可以预先用双塔模型将所有标准答案编码成向量存入向量数据库如Milvus、Qdrant或高性能缓存如Redis。粗排时只需实时编码用户查询然后进行向量相似度搜索速度极快。查询向量缓存对于高频或热门的用户查询其编码结果也可以缓存一段时间进一步减少重复计算。模型量化与加速ONNX转换与量化将训练好的PyTorch模型导出为ONNX格式并使用ONNX Runtime进行推理。进一步可以对模型进行动态或静态量化INT8在精度损失很小的情况下显著提升推理速度并降低内存占用。使用更轻量模型在效果可接受的范围内选择参数量更小的预训练模型如all-MiniLM-L6-v2相比all-mpnet-base-v2快很多。分级降级策略设置超时阈值。如果精排模型响应超时系统自动降级直接使用粗排分数甚至原始查询分数作为最终排序依据保证服务可用性。5. 避坑指南生产环境里的那些“坑”冷启动问题问题新业务上线或知识库大幅更新时没有足够的查询答案配对数据来训练或微调精排模型。解决先使用预训练模型如我们示例中直接加载的作为起点。同时积极收集线上用户反馈数据如点击、采纳、人工纠正构建高质量的训练集。初期可以采用“主动学习”策略对模型不确定的样本进行人工标注高效积累数据。数据偏差问题问题训练精排模型的数据如果有可能和线上真实分布不一致。例如训练数据多是简短FAQ而线上用户问题很长很口语化导致模型效果下降。解决定期用线上最新日志数据更新训练集。在特征工程或模型输入中可以加入一些统计特征如查询长度、答案长度、是否包含关键词等帮助模型适应不同分布。延迟波动问题问题候选答案数量波动大有时多有时少导致融合阶段耗时不稳定。解决在粗排阶段设置一个动态的Top-K。根据系统当前负载和响应时间要求动态调整粗排筛选出的数量如负载高时Top-K从30降到20。确保精排阶段的输入规模相对稳定。去重阈值选择问题similarity_threshold设得太高去不掉冗余设得太低可能把两个表述不同但有互补信息的正确答案误删一个。解决这个阈值需要结合业务实际通过人工评估来确定。可以做一个评估界面抽样查看不同阈值下的去重效果选择一个平衡点。也可以考虑更复杂的聚类方法而不是简单的贪心去重。6. 结语通过引入“双塔粗排 Cross-Encoder精排”的重排序流水线我们算是比较优雅地解决了智能客服里多查询结果融合的难题。速度上来了答案也更准、更简洁了。这套策略的核心思想——“快速召回精准排序”——其实在很多NLP任务里都通用。比如在搜索引擎里可以用它来融合来自不同召回渠道文本、视频、图片标签的结果在推荐系统里可以用来对多路召回的商品、视频进行统一排序甚至是在代码检索、法律条文检索这些垂直领域思路都是相通的先用简单快速的方法扩大候选池再用复杂精准的模型做最终决策。技术总是在迭代现在大语言模型LLM这么火是不是可以直接用LLM来做重排序和结果生成呢当然可以但成本和时间又是新的挑战。或许未来我们现在的两阶段流水线会变成“向量检索 LLM重排/生成”的新模式。不管工具怎么变理解业务痛点、平衡效果与效率这个内核是不会变的。希望我们这次的实践分享能给你带来一些启发。