坐下 3 / 5

PAY-4097 被向量检索排到第 37。

客服搜错误码。向量库返回「支付冲突处理原则」和「409 HTTP 状态码」。真正写着补偿步骤和适用版本的手册在第 37 位。换更大的 embedding 之前，先看 analyzer 有没有把 PAY-4097 切开，以及有没有一个 keyword 字段专门放这个码。

倒排先回答「哪些段落含这个词」

索引时把字段变成 token，记下出现在哪一截、出现几次。查询走同一套（或兼容的）analyzer。若分词把 PAY-4097 拆成 pay 和 4097，精确性下降；若停用词表删掉「不」，政策含义会翻面。索引和查询用了不同同义词表，线上行为很难复现。

BM25 给稀有词高 IDF，所以错误码这种几乎只出现两次的串很强。词频会饱和：出现四次不是四分，出现二十次也不会无限涨。长手册会被长度项压一压，避免整本含查询词就压过短答案段。手算时，k1=1.2、b=0.75、文档长度等于平均长度，词出现一次的 tf 因子是 1；出现四次大约 1.69。

字段分开

正文用语言分词。错误码、工单号、人名、SKU 进 keyword。同一截 chunk 可以投影到三个字段：body、title、identifiers。查询计划可以是精确字段高权重，正文兜底。tenant 和有效期是过滤条件，不能靠把未授权文档「排后面一点」。中英混排时保留原始串和规范化串；同义词只收录业务确认过的，把「退款」和「撤销」强行等同，在支付语境里会改动作。

什么时候上稠密，什么时候融合

用户说「和上次那个差不多的退款，客户很急」——几乎没有可倒排的标识。稠密检索按意思找。制度题既有「试用期」「年假」这些词，又有「入职折算」这种换说法，两边都召回，再用融合。

融合放在你有一小份 qrels 之后。二十到五十条真实问题，标出该回哪几截，就够拿来比较 BM25、稠密、两者融合。没有这份表，RRF 的 k 只是又一个旋钮。人名「张三丰」在二百页纪要里出现一次，稠密检索常把它稀释成「相关人员」；放进 keyword 字段，BM25 一次就能置顶。这一页坐完，不表示你的向量模型已经合格。embedding 好不好，要用你自己的问题集去量。