企业知识库里常有两种问法。一种带着准确编号，比如设备型号、合同编号和故障码。另一种只说意思，比如“那台夏天容易过热的机器怎么处理”，我把 Azure AI Search 的混合检索与排序文档对了一遍，这两类问题适合让关键词检索和向量检索一起找。
混合检索会在一次请求里同时带上全文查询和向量查询，服务并行执行两路检索，随后把结果合成一份排序。向量检索擅长找概念接近的段落，即使用户没有复述原文。全文检索能抓住准确词面，产品代码、专业缩写、日期和人名经常靠这一边找得更稳。
两路分数不能直接相加
全文检索常用 BM25，向量检索会按余弦相似度等办法打分。两种分数的范围和含义不同，直接比较会把数字大小误当成相关性。Azure 的实现采用倒数排名融合，也就是 RRF。它主要看一份结果在各个列表里排第几，再把名次换算成分数相加。
一份文档若在关键词结果和向量结果里都靠前，融合以后通常也会靠前。只在一路出现的文档仍有机会入选。这个办法省掉了强行统一两种原始分数的麻烦。融合完成后，还可以让语义重排器处理候选结果，精细判断问题和段落是否匹配。
排查排名时也要分开看这些阶段。RRF 分数通常比单独的向量相似度小，数字变小不代表结果变差。先看各路候选和融合名次，再看语义重排后的顺序，才知道相关文档在哪一步被挤掉。
混合查询也保留了许多全文搜索能力。团队可以按部门、文档状态和权限字段过滤，继续使用分面、排序与评分配置。向量字段与普通文本字段要放在同一索引中，原始段落仍要保留，因为最后回答用户时需要读到文字，也需要给出出处。
上线前先做一组难题
调试时别只试“报销制度”这类宽问题。拿一组真实查询分成三类，准确编号、同义改写和一句话描述故障。逐条记录关键词结果、向量结果、融合结果，以及正确段落第一次出现的位置。这样才能看出哪一路贡献了答案。
候选数量也会改变结果。关键词侧召回多少条、向量查询里的邻居数量、两路权重和后续重排范围，都要在同一组问题上比较。调大数量通常会增加召回，也会带来更多无关段落和处理时间。
我的判断是，混合检索适合词面与语义都很重要的企业材料。它不会自动修好错误切块、过期文档和权限缺口。先把索引里的文档版本与访问范围管住，再用真实问题调排名，回答才有稳定的依据。