相关性检索优化说明.md 34 KB
Edit Raw Blame History Permalink


相关性检索优化说明（当前实现）
1. 文档目标
本文描述当前代码中的文本检索策略，重点覆盖：


多语言检索路由（detector / translator / indexed 的关系）
统一文本召回表达式（无布尔 AST 分支）
解析层与检索表达式层的职责边界
重排融合打分与调试字段
典型场景下实际生成的 ES 查询结构


说明：向量召回（KNN）是另一维度，本篇仅简要提及，不展开。

2. 核心流程
查询链路（文本相关）：


QueryParser.parse()

负责产出解析事实：query_normalized、rewritten_query、detected_language、translations、query_vector、query_tokens。
Searcher.search()

负责读取租户 index_languages，并将其传给 QueryParser 作为 target_languages（控制翻译目标语种）；ESQueryBuilder 仅根据 detected_language 与各条译文构建子句字段，不再接收 index_languages。
ESQueryBuilder._build_advanced_text_query()

基于 rewritten_query + detected_language + translations + index_languages 构建 base_query 与 base_query_trans_*；并按语言动态拼接 title/brief/description/vendor/category_* 的 .{lang} 字段，叠加 shared 字段（tags、option*_values）。
build_query()

统一走文本策略，不再有布尔 AST 枝路。

3. 能力矩阵（Detector / Translator / Indexed）
三类能力的职责边界：


Detector：识别 query 源语言（detected_language）
Indexed：租户可检索语言集合（tenant_config.*.index_languages）
Translator：源语言到目标语言的可翻译能力及实时成功率

3.1 决策规则

若 detected_language in index_languages：

源语言字段做主召回；其他语言走翻译补召回（低权重）。
若 detected_language not in index_languages：

翻译到 index_languages 是主路径；源语言字段仅作弱召回。
若翻译部分失败或全部失败：

当前实现不会再额外生成“原文打到其他语种字段”的兜底子句；系统保留 base_query 并继续执行，可观测性由 translations / warning / 命名子句分数提供。

3.2 翻译与向量：并发提交与共享超时
QueryParser.parse() 内对翻译与向量采用线程池提交 + 一次 concurrent.futures.wait：


翻译：对调用方传入的 target_languages 中、除 detected_language 外的每个目标语种各提交一个 translator.translate 任务（多目标时并发执行）。
查询向量：若开启 enable_text_embedding，再提交一个 text_encoder.encode 任务。
上述任务进入同一 future 集合；例如租户索引为 [zh, en] 且检测语种不在索引内时，常为 2 路翻译 + 1 路向量，共 3 个任务并发，共用超时。


等待预算（毫秒）由 detected_language 是否属于调用方传入的 target_languages 决定（query_config）：


在索引内：translation_embedding_wait_budget_ms_source_in_index（默认较短，如 80ms）— 主召回已能打在源语种字段，翻译/向量稍慢可容忍。
不在索引内：translation_embedding_wait_budget_ms_source_not_in_index（默认较长，如 200ms）— 翻译对可检索文本更关键，给足时间。


超时未完成的任务会被丢弃并记 warning，解析继续（可能无部分译文或无数向量）。
4. 统一文本召回表达式
每个语言子句的基础形态：
{
  "multi_match": {
    "_name": "base_query|base_query_trans_xx",
    "query": "<text>",
    "fields": ["title.xx^3.0", "brief.xx^1.5", "...", "tags", "option1_values^0.5", "..."],
    "minimum_should_match": "75%",
    "tie_breaker": 0.9,
    "boost": "<按策略决定，可省略>"
  }
}


最终按 bool.should 组合，minimum_should_match: 1。
5. 关键配置项（文本策略）
query_config 下与解析等待相关的项：


translation_embedding_wait_budget_ms_source_in_index
translation_embedding_wait_budget_ms_source_not_in_index


位于 config/config.yaml -> query_config.text_query_strategy：


base_minimum_should_match
translation_minimum_should_match
translation_boost（所有 base_query_trans_* 共用）
tie_breaker_base_query


说明：


phrase_query / keywords_query 已从当前实现中移除，文本相关性只由 base_query、base_query_trans_* 两类子句组成。

6. 典型场景与实际 DSL
以下示例来自当前 ESQueryBuilder 生成结果（已按当前代码验证）。
场景 A：源语种已在索引语言中，且翻译成功

detected_language=de
index_languages=[de,en]
rewritten_query="herren schuhe"
translations={en:"men shoes"}


策略结果：


base_query：德语字段，不写 multi_match.boost
base_query_trans_en：英语字段，boost=translation_boost（默认 0.4）

场景 B：源语种不在索引语言中，部分翻译缺失

detected_language=de
index_languages=[en,zh]
只翻译出 en，zh 失败


策略结果：


base_query（德语字段）：不写 multi_match.boost（默认 1.0）
base_query_trans_en（英文字段）：boost=translation_boost（如 0.4）
不会生成额外中文兜底子句

场景 C：源语种不在索引语言中，翻译全部失败

detected_language=de
index_languages=[en,zh]
translations={}


策略结果：


base_query（德语字段，无 boost 字段）
不会生成 base_query_trans_*


这意味着当前实现优先保证职责清晰与可解释性，而不是继续在 Builder 内部隐式制造“跨语种原文兜底”。
7. QueryParser 与 Searcher / ESBuilder 的职责分工

QueryParser 负责“解析事实”：


query_normalized
rewritten_query
detected_language
translations
query_vector
query_tokens

Searcher 负责“租户语境”：


index_languages
将其传给 parser 作为 target_languages

ESQueryBuilder 负责“表达式展开”：


动态字段组装
子句权重分配
base_query / base_query_trans_* 子句拼接
跳过“与 base_query 文本和语言完全相同”的重复翻译子句


这种分层让 parser 不再返回 ES 专用的“语言计划字段”，职责边界更清晰。
8. 融合打分（ES + Text + KNN + Model）
当前融合逻辑位于 search/rerank_client.py。
8.1 文本相关性大分
文本大分由两部分组成：


base_query
base_query_trans_*


聚合方式：


source_score = base_query
translation_score = max(base_query_trans_*)
加权：


weighted_source = source_score
weighted_translation = 0.8 * translation_score

合成：


primary = max(weighted_source, weighted_translation)
support = weighted_source + weighted_translation - primary
text_score = primary + 0.25 * support


如果以上子分都缺失，则回退到 ES _score 作为 text_score，避免纯文本召回被误打成 0。
8.2 向量相关性大分
向量不是两路分别进入最终公式，而是先融合成一个统一的 knn_score。

当前实现位于 search/rerank_client.py 的 _collect_knn_score_components()：


text_knn_score = matched_queries["knn_query"]
image_knn_score = matched_queries["image_knn_query"]
分别乘权重：


weighted_text_knn_score = knn_text_weight * text_knn_score
weighted_image_knn_score = knn_image_weight * image_knn_score

再做一层 dismax 融合：


primary_knn_score = max(weighted_text_knn_score, weighted_image_knn_score)
support_knn_score = 另一侧较弱信号
knn_score = primary_knn_score + knn_tie_breaker * support_knn_score


当前默认配置在 config.yaml 中是：


knn_text_weight = 1.0
knn_image_weight = 1.0
knn_tie_breaker = 0.1


也就是说：


现在确实是“文本 KNN + 图片 KNN 先融合成一项 knn_score”
但图片权重目前并没有略高于文本权重
当前两路权重是相等的，只是通过 dismax 机制保留“主路 + 辅助路”


如果业务上希望 image 语义更主导，可以把 knn_image_weight 调成略高于 knn_text_weight，例如 1.1 ~ 1.3 这一类小幅领先值，再观察 query 分布与 bad case。
8.3 各阶段融合公式
coarse_score = (
    (es_score + es_bias) ** es_exponent
    * (text_score + text_bias) ** text_exponent
    * (knn_score + knn_bias) ** knn_exponent
)

fine_stage_score = (
    (es_score + es_bias) ** es_exponent
    * (fine_score + fine_bias) ** fine_exponent
    * (text_score + text_bias) ** text_exponent
    * (knn_score + knn_bias) ** knn_exponent
    * style_boost
)

final_score = (
    (es_score + es_bias) ** es_exponent
    * (rerank_score + rerank_bias) ** rerank_exponent
    * (fine_score + fine_bias) ** fine_exponent   # 仅当 fine rank 打开且有分数时参与
    * (text_score + text_bias) ** text_exponent
    * (knn_score + knn_bias) ** knn_exponent
    * style_boost
)


当前默认配置下：


coarse: es_exponent=0.05, text_exponent=0.35, knn_exponent=0.2
fine/final: es_exponent=0.05, text_exponent=0.25, knn_exponent=0.2
final: 额外有 rerank_exponent=1.15


设计意图可以概括成：


es_score 不再只做 debug，而是作为全阶段都保留的弱先验
text_score 是稳定主干信号
knn_score 是统一的语义信号入口
fine_score / rerank_score 是越往后越贵、越强的模型因子
style_boost 只在命中已选 SKU 时乘上去

8.4 调试字段
开启 debug=true 后，debug_info.per_result 会暴露：


es_score
es_factor
rerank_score
retrieval_plan（query 级）
ltr_summary（query 级）
ltr_features（doc/stage 级稳定特征块）

8.5 面向调参与 LTR 的新日志视角
为了让 bad case 分析和后续 LTR 更直接，当前调试信息建议按下面三层来读：


Query 级：retrieval_plan
看这次请求到底走了哪套 KNN 计划：


text_knn.k / num_candidates
image_knn.k / num_candidates
是否命中长查询分支

Top-N 汇总：ltr_summary
看最终第一页/前 20 个结果中，信号分布是否异常：


translation_match_docs
text_knn_docs
image_knn_docs
text_fallback_to_es_docs
各类 score 的均值

Doc 级漏斗：per_result[*].ranking_funnel.*.ltr_features
用稳定特征字段来判断“为什么这个 doc 上去了/没上去”：


文本主召回还是翻译召回在主导
text KNN / image KNN 哪一路在抬分
rerank 是否足够强，能否纠正上游 lexical 噪声


推荐的诊断顺序：


先看 missing_relevant，确认是不是召回缺失。
若召回到了但没进最终页，先看 coarse_rank 是否提前裁掉。
若进了 rerank 窗口但排序差，再比较 rerank_score 与 text_score/knn_score 谁在压制谁。
对多语言 query，优先确认 source_score 是否为 0；如果是，说明当前结果主要吃翻译召回。
text_score
text_source_score
text_translation_score
text_primary_score
text_support_score
knn_score
fused_score
matched_queries


debug_info.query_analysis 还会暴露：


translations
detected_language
rewritten_query


这些字段用于检索效果评估与 bad case 归因。
9. 兼容与注意事项

当前文本主链路已移除布尔 AST 分支。

文档中的旧描述（如 operator: AND 固定开启）不再适用，当前实现未强制设置该参数。

HanLP 为必需依赖；当前 parser 不再提供轻量 fallback。

若后续扩展到更多语种，请确保：


mapping 中存在对应 .<lang> 字段
index_languages 配置在支持列表内
翻译 provider 对目标语种可用


10. 评估与复现
建议使用项目根目录虚拟环境：
cd /data/saas-search
source ./activate.sh
python -m pytest -q tests/test_rerank_client.py tests/test_es_query_builder.py tests/test_search_rerank_window.py tests/test_query_parser_mixed_language.py
./scripts/service_ctl.sh restart backend
sleep 3
./scripts/service_ctl.sh status backend
./scripts/evaluation/start_eval.sh batch


评估产物在 artifacts/search_evaluation/（如 search_eval.sqlite3、batch_reports/ 下的 JSON/Markdown）。流程与参数说明见 scripts/evaluation/README.md。
11. 建议测试清单
建议在 tests/ 增加文本策略用例：


源语种在索引语言，翻译命中缓存

源语种不在索引语言，翻译部分失败（验证仅保留 base_query + 成功翻译子句）

源语种不在索引语言，翻译全部失败（验证无 base_query_trans_* 时仍可正常执行）

非 zh/en 语种字段动态拼接（如 de/fr/es）

搜索pipeline
整体图
这个 pipeline 现在可以理解成一条“先广召回，再逐层收窄、逐层加贵信号”的漏斗：


Query 解析
ES 召回
粗排：ES 原始总分 + 文本大分 + 统一 KNN 大分
款式 SKU 选择 + title suffix
精排：轻量 reranker + ES/text/KNN 融合
最终 rerank：重 reranker + fine score + ES/text/KNN 融合
分页、补全字段、格式化返回


主控代码在 searcher.py，打分与 rerank 细节在 rerank_client.py，配置定义在 schema.py 和 config.yaml。

先看入口怎么决定走哪条路
在 searcher.py:348 开始，search() 先读租户语言、开关、窗口大小。
关键判断在 searcher.py:364 到 searcher.py:372：


rerank_window 现在是 80，见 config.yaml:256
coarse_rank.input_window 是 700，output_window 是 240，见 config.yaml:231
fine_rank.input_window 是 240，output_window 是 80，见 config.yaml:245


所以如果请求满足 from_ + size <= rerank_window，就进入完整漏斗：


ES 实际取前 700
粗排后留 240
精排后留 80
最终 rerank 也只处理这 80
最后再做分页切片


如果请求页超出 80，就不走后面的多阶段漏斗，直接按 ES 原逻辑返回。

这点非常重要，因为它决定了“贵模型只服务头部结果”。

Step 1：Query 解析阶段
在 searcher.py:432 到 searcher.py:469：
query_parser.parse() 做几件事：


规范化 query
检测语言
可能做 rewrite
生成文本向量
如果有图搜，还会带图片向量
生成翻译结果
识别 style intent


这一步的结果存在 parsed_query 里，后面 ES 查询、style SKU 选择、fine/final rerank 全都依赖它。

Step 2：ES Query 构建
ES DSL 在 searcher.py:471 开始，通过 es_query_builder.py:181 的 build_query() 生成。

这里的核心结构是：


文本召回 clause
文本向量 KNN clause
图片向量 KNN clause
它们一起放进 bool.should
过滤条件放进 filter
facet 的多选条件走 post_filter


KNN 部分在 es_query_builder.py:250 之后：


文本向量 clause 名字固定叫 knn_query
图片向量 clause 名字固定叫 image_knn_query


而文本召回那边，后续 fusion 代码约定会去读：


原始 query 的 named query：base_query
翻译 query 的 named query：base_query_trans_*


也就是说，后面的粗排/精排/最终 rerank，并不是重新理解 ES score，而是从 matched_queries 里把这些命名子信号拆出来自己重算。

Step 3：ES 召回
在 searcher.py:579 到 searcher.py:627。

这里有个很关键的工程优化：
如果在 rerank window 内，第一次 ES 拉取时会把 _source 关掉，只取排序必需信号，见 searcher.py:517 到 searcher.py:523。

原因是：


粗排先只需要 _score 和 matched_queries
不需要一上来把 700 条完整商品详情都拉回来
等粗排收窄后，再补 fine/final rerank 需要的字段


这是现在这条 pipeline 很核心的性能设计点。

Step 4：粗排
粗排入口在 searcher.py:638，真正的打分在 rerank_client.py:348 的 coarse_resort_hits()。

粗排现在看三类信号：


es_score
text_score
knn_score


它们先都从统一 helper _build_hit_signal_bundle() 里拿，见 rerank_client.py:246。

文本分怎么来，见 rerank_client.py:200：


source_score = matched_queries["base_query"]
translation_score = max(base_query_trans_*)
weighted_translation = 0.8 * translation_score
primary_text = max(source, weighted_translation)
support_text = 另一路
text_score = primary_text + 0.25 * support_text


这就是一个 text dismax 思路：
原 query 是主路，翻译 query 是辅助路，但不是简单相加。

向量分怎么来，见 rerank_client.py:156：


text_knn_score
image_knn_score
分别乘自己的 weight
取强的一路做主路
弱的一路按 knn_tie_breaker 做辅助
产出一个统一的 knn_score


然后粗排融合公式在 rerank_client.py:346：


coarse_score = es_factor * text_factor * knn_factor
es_factor = (es_score + es_bias)^es_exponent
text_factor = (text_score + text_bias)^text_exponent
knn_factor = (knn_score + knn_bias)^knn_exponent


配置定义在 schema.py:124 和 config.yaml:231。

算完后：


写入 hit["_coarse_score"]
按 _coarse_score 排序
留前 240，见 searcher.py:645


Step 5：粗排后补字段 + SKU 选择
粗排完以后，searcher 会按 doc template 反推 fine/final rerank 需要哪些 _source 字段，然后只补这些字段，见 searcher.py:669。

之后才做 style SKU 选择，见 searcher.py:696。

为什么放这里？
因为现在 fine rank 也是 reranker，它也要吃 title suffix。
而 suffix 是 SKU 选择之后写到 hit 上的 _style_rerank_suffix。
真正把 suffix 拼进 doc 文本的地方在 rerank_client.py:65 到 rerank_client.py:74。

所以顺序必须是：


先粗排
再选 SKU
再用带 suffix 的 title 去跑 fine/final rerank


Step 6：精排
入口在 searcher.py:711，实现是 rerank_client.py:603 的 run_lightweight_rerank()。

它会做三件事：


用 build_docs_from_hits() 把每条商品变成 reranker 输入文本
用 service_profile="fine" 调轻量服务
不再只按 fine_score 排，而是按融合后的 _fine_fused_score 排


精排融合公式现在是：


fine_stage_score = es_factor * fine_factor * text_factor * knn_factor * style_boost


具体公共计算在 rerank_client.py:286 的 _compute_multiplicative_fusion()：


es_factor = (es_score + es_bias)^es_exponent
fine_factor = (fine_score + fine_bias)^fine_exponent
text_factor = (text_score + text_bias)^text_exponent
knn_factor = (knn_score + knn_bias)^knn_exponent
如果命中了 selected SKU，再乘 style boost


写回 hit 的字段见 rerank_client.py:655：


_fine_score
_fine_fused_score
_text_score
_knn_score


排序逻辑在 rerank_client.py:683：
按 _fine_fused_score 降序排，然后留前 80，见 searcher.py:727。

这就是你这次特别关心的点：现在 fine rank 已经不是“模型裸分排序”，而是“模型分 + ES 文本/KNN 信号融合后排序”。

Step 7：最终 rerank
入口在 searcher.py:767，实现是 rerank_client.py:538 的 run_rerank()。

它和 fine rank 很像，但多了一个更重的模型分 rerank_score。
最终公式是：


final_score = es_factor * rerank_factor * fine_factor * text_factor * knn_factor * style_boost


也就是：


ES 原始总分也会继续保留到最终阶段
fine rank 产生的 fine_score 不会丢
到最终 rerank 时，它会继续作为一个乘法项参与最终融合


这个逻辑在 rerank_client.py:468 到 rerank_client.py:476。

算完后写入：


_rerank_score
_fused_score


然后按 _fused_score 排序，见 rerank_client.py:531。

这里你可以把它理解成：


fine rank 负责“轻量快速筛一遍，把 240 缩成 80”
最终 rerank 负责“用更贵模型做最终拍板”
但最终拍板时，不会忽略 fine rank 结果，而是把 fine score 当成一个先验信号保留进去


Step 8：分页与字段补全
多阶段排序只在头部窗口内完成。
真正返回给用户前，在 searcher.py:828 之后还会做两件事：


先按 from_:from_+size 对最终 80 条切片
再按用户原始 _source 需求补回页面真正要显示的字段，见 searcher.py:859


所以这条链路是“三次不同目的的数据访问”：


第一次 ES：只要排序信号
第二次按 id 回填：只要 fine/final rerank 需要字段
第三次按页面 ids 回填：只要最终页面显示字段


这也是为什么它性能上比“一次全量拉 700 条完整文档”更合理。

Step 9：结果格式化与 debug funnel
最后在 searcher.py:906 进入结果处理。
这里会把每个商品的阶段信息组装成 ranking_funnel，见 searcher.py:1068：


es_recall
coarse_rank
fine_rank
rerank
final_page


其中：


coarse stage 保留 es/text/translation/knn 的拆分信号
fine/rerank stage 现在都保留 fusion_inputs、fusion_factors、fusion_summary
fusion_summary 来自真实计算过程本身，见 rerank_client.py:265
当 fine_rank 关闭时，rerank.rank_change 会继承 coarse_rank 作为上游阶段，不会错误地全部显示为 0


这点很重要，因为现在“实际排序逻辑”和“debug 展示逻辑”是同源的，不是两套各写一份。

一句话总结这条 pipeline
这条 pipeline 的本质是：


ES 负责便宜的大范围召回
粗排负责只靠 ES 内置信号先做一次结构化筛选
style SKU 选择负责把商品文本改造成更适合 reranker 理解的输入
fine rank 负责用轻模型把候选进一步压缩
final rerank 负责用重模型做最终判定
每一层都尽量复用前一层信号，而不是推翻重来


如果你愿意，我下一步可以继续按“一个具体 query 的真实流转样例”来讲，比如假设用户搜 black dress，我把它从 parsed_query、ES named queries、coarse/fine/final 的每个分数怎么出来，完整手推一遍。
12. 值得优先探索的相关性实验方向
下面这些方向按我对当前 rank 体系的判断，优先级大致是“先做低风险高收益，再做结构性升级”。
12.1 Query 分桶，而不是所有 query 共用一套融合参数
当前问题：


所有 query 基本共用同一套 exponent / bias
但“强词法 query”、“泛类目 query”、“风格词 query”、“图搜触发 query”、“中英混输 query”的最优信号配比通常不同


建议实验：


先做轻量 query 分桶：


精准实体词
泛类目词
风格/属性词
中英混输
带强图片语义的 query

每个桶单独调：


text_translation_weight
knn_text_weight / knn_image_weight
es_exponent / text_exponent / knn_exponent


为什么值得先做：


不改主架构
容易上线灰度
往往比“全局调一个 exponent”稳定得多

12.2 把 image KNN 设成略高于 text KNN，但只在合适 query 上生效
当前问题：


现在 knn_text_weight = 1.0，knn_image_weight = 1.0
对鞋、服饰款式、图案、轮廓类 query，image embedding 往往比 text embedding 更接近用户真实意图
但不是所有 query 都适合直接全局抬高 image 权重


建议实验：


离线先试：


knn_image_weight = 1.1 / 1.2 / 1.3
knn_text_weight = 1.0

再进一步试 query gating：


若 query 命中款式词、形状词、鞋包词、图案词，则抬高 image weight
若 query 是明确品类词或强属性词，则维持中性


为什么我不建议一上来全局大幅抬高：


会把一些“文本很明确，但图像泛相似”的结果抬上来
容易让高视觉相似、低语义准确的商品误冲前排

12.3 不只融合“分数”，还要融合“排名证据”
当前问题：


现在所有阶段都高度依赖 score 级别的乘法融合
不同信号源的 score 标度未必天然可比
reranker 分数、ES score、named query score、KNN score 的数值空间差异很大


建议实验：


增加 rank-based 特征：


es_rank
text_rank
knn_rank
rerank_rank

试两类简单方法：


RRF（Reciprocal Rank Fusion）
score-rank 混合：先做 rank 融合，再乘少量 score 因子


为什么值得做：


对异常 score 分布更稳
对模型偶发极端分更鲁棒
很适合拿来做基线对照

12.4 将 base_query 和 translation_query 从“单点 max”升级为“更完整的 lexical 证据”
当前问题：


文本大分现在只抓：


base_query
max(base_query_trans_*)

这很干净，但可能过于压缩文本证据
phrase 命中、best_fields 命中、多语言字段命中、字段质量差异，没有更细粒度地进入后续 rank


建议实验：


把 lexical 证据拆得更细：


exact / phrase
best_fields
title 命中
category 命中
brand/vendor 命中

后续不一定都入主公式，但可以先做 debug / feature log


这样做的收益：


更容易解释“为什么这条词法上明明更准却没排上来”
为后续 learning-to-rank 或规则门控准备特征

12.5 增加“类目先验”和“商品类型约束”
当前问题：


现在体系更偏“文本/向量相似度驱动”
对“牛仔裤 vs 连裤袜”这种 bad case，问题常常不只是分数融合，而是商品类型约束太弱


建议实验：


query 侧先做轻量商品类型识别：


裙子
裤子
上衣
鞋

doc 侧取：


category_path
taxonomy leaf
类目 embedding / one-hot

然后试：


作为 hard filter 候选约束
作为 coarse/final 的 boost 因子
作为 rerank 输入字段增强


这是我认为对明显 bad case 最有价值的一类结构性修复。
12.6 把“负证据”纳入体系，而不只是累加正证据
当前问题：


当前乘法体系主要是在积累正向因子
但很多错误结果不是“正向不够强”，而是“存在明显负证据”
例如 query 是“半身裙”，doc 却强命中“上衣”“打底衫”“连裤袜”


建议实验：


抽取轻量负词特征：


商品类型冲突词
性别/人群冲突词
长度/版型冲突词

方式可以先很简单：


penalty factor
blacklist term penalty
query-doc type mismatch penalty


这是当前体系里非常缺的一块。
12.7 把 KNN 从“单一总分”升级为“多语义子通道”
当前问题：


现在 KNN 最终会被压成一个 knn_score
这对工程简单很好，但损失了“这条向量信号到底为什么相似”的信息


建议实验：


分通道记录和使用：


text semantic similarity
image appearance similarity
category-aware similarity
style-aware similarity

即使最终仍合成一个总分，也建议先保留分通道特征


这样未来才能回答：


这条结果是“外观像”
还是“描述语义像”
还是“类目像但款式不对”

12.8 从纯手工公式，逐步过渡到轻量 LTR
当前问题：


目前公式已经比较清晰，但本质还是手工 feature engineering + 手工 exponent
一旦信号变多，靠手调很难长期维护


建议实验：


先不引入复杂在线模型
先做离线 LTR baseline：


LambdaMART / XGBoost ranker
输入现成特征：
es_score
text_score
text_source_score
translation_score
text_knn_score
image_knn_score
coarse_rank
rerank_score
category match
style intent match


为什么这一步值得准备：


你们现在的 debug 字段已经很接近 feature log 了
其实已经具备往 LTR 过渡的土壤

12.9 先把评估体系补齐，再谈大改
当前问题：


很多相关性讨论容易停留在个例
但融合改动经常存在 query 分布层面的 tradeoff


建议实验配套：


建立 query slice 指标：


鞋靴
裙装
裤装
中英混输
图像语义强 query
属性词强 query

每次实验至少看：


overall
top 1
top 3
slice breakdown
bad case 回归集


12.10 我对当前体系的几个核心判断

当前体系最大的优点不是公式本身，而是已经把信号拆成了可解释的层级，这非常适合继续做实验。
当前体系最大的短板不是“knn exponent 还不够准”，而是缺少 query 分桶、类目先验和负证据。
只调融合公式还能继续拿到一部分收益，但中期最值得投入的是：


query-aware 参数
类型/类目约束
score + rank 混合融合
为 LTR 做特征沉淀


reranker方面：
BAAI/bge-reranker-v2-m3的一个严重badcase：
q=黑色中长半身裙

Rerank score: 0.0785
title.zh: 2026款韩版高腰显瘦雪尼尔包臀裙灯芯绒开叉中长款咖啡色半身裙女
title.en: 2026 Korean-style High-waisted Slimming Corduroy Skirt with Slit, Mid-Length Coffee-colored Skirt for Women

Rerank score: 0.9643
title.en: Black Half-high Collar Base Shirt Women's Autumn and Winter fleece-lined Contrast Color Pure Desire Design Sense Horn Sleeve Ruffled Inner Top
title.zh: 黑色高领半高领女士秋冬内搭加绒拼色纯欲设计荷叶边袖内衬上衣

qwen3-0.6b的严重badcase：
q=牛仔裤

Rerank score: 0.0002
title.en: Wrangler Womens Cowboy Cut Slim Fit Jean Bleach
title.zh: Wrangler 女士牛仔裤 牛仔剪裁 紧身版型 漂白色

Rerank score: 0.0168
title.en: Fleece Lined Tights Sheer Women - Fake Translucent Warm Pantyhose Leggings Sheer Thick Tights for Winter
title.zh: 加绒透肤女士连裤袜 - 仿透视保暖长筒袜 冬季厚款透肤连裤袜

Rerank score: 0.1366
title.en: Dockers Men's Classic Fit Workday Khaki Smart 360 FLEX Pants (Standard and Big & Tall)
title.zh: Dockers 男士经典版型工作日卡其色智能360度弹力裤（标准码与加大码）

Rerank score: 0.0981
title.en: Lazy One Pajama Shorts for Men, Men's Pajama Bottoms, Sleepwear
title.zh: 懒人男士睡裤，男式家居裤，睡眠服饰

q=修身牛仔裤

这些好结果得分很低：

rerank_score:0.0564
    "en": "Judy Blue Women's High Waist Button Fly Skinny Jeans 82319",
    "zh": "Judy Blue 女士高腰纽扣开叉修身牛仔裤 82319"

rerank_score:0.0790
    "en": "2025 New Fashion European and American Women's Jeans High-Waisted Slim Straight Denim Pants Popular Floor-Length Pants",
    "zh": "2025新款欧美风女式高腰显瘦直筒牛仔裤 时尚及地长裤"

rerank_score:0.0822
    "en": "roswear Women's Trendy Stretchy Flare Jeans Mid Rise Bootcut Curvy Denim Pants",
    "zh": "Roswear 女士时尚弹力喇叭牛仔裤 中腰高腰修身直筒牛仔裤"

rerank_score:0.0956
    "en": "POSHGLAM Women's Maternity Jeans Over Belly 29'' Skinny Denim Jeggings Comfy Stretch Clearance Pregnancy Pants",
    "zh": "POSHGLAM 女士孕产期高腰显瘦牛仔紧身裤 29英寸 紧身弹力孕妇裤 休闲舒适 清仓特价"

（带有 Slim Stretch Jeans，但是打分只有0.0135，极低）
rerank_score:0.0135
    "en": "European and American Export Temu American Retro Sexy Bell-Bottomed Pants Slim Slim Stretch Jeans Women's Pants",
    "zh": "欧美出口 蒂姆美国复古性感喇叭裤 修身弹力女裤"

这几个结果比较差，但是得分很高：

rerank_score:0.4692
    "en": "American Vintage Low Waist Non-Elastic Washed Straight-Leg Jeans Women's Autumn New Street Wide Leg Denim Women's Pants",
    "zh": "美式复古低腰无弹洗水直筒阔腿牛仔裤 女士秋季新款阔腿牛仔裤"

rerank_score:0.4784
    "en": "Europe and the United States cross-border foreign trade 2025 spring and summer new Amazon independent station washed waist adjustable Denim pants",
    "zh": "欧美跨境外贸2025春夏新款亚马逊独立站洗水腰 adjustable 牛仔裤"

rerank_score:0.5849
    "zh": "新款女士修身仿旧牛仔短裤 – 休闲性感磨边水洗牛仔短裤，时尚舒",
    "en": "New Women's Slim-fit Vintage Washed Denim Shorts – Casual Sexy Frayed Hem, Fashionable & Comfortable"