1. debug信息展示方面 在这次重构过程中，你基本上了解了从query析到 ES 搜索，再到重排的全流程。 在这些环节中，有哪些重要的信息对搜索结果产生较大影响，先回顾，适当的完善、优化日志。 debug_info也给前端更充分的调试信息，包括，丰富每条结果的ranking debug。目前只有这些 Ranking Debug spu_id ES score ES normalized ES norm (rerank input): Rerank score Fused score title.en title.zh

还不够，需要详细思考，设计一个更加完整的展示的体系 比如： position（重排前的，重排后最终的） ES打分，从ES检索原始打分、相关的因子（minmax归一化的因子。到底用了哪些因子，你自己关注下，用到的要体现出来，让人知道从原始打分怎么得到的ES norm (rerank input)）。另外ES normalized，ES norm，要梳理清楚，如果代码不清晰则改代码，展示不清晰则要梳理展示。 Rerank这一块，除了rerank_score，输入的信息比如输入的doc模板，被选中的sku及其用于辅助reranker相关性的、加到title后面的后缀 融合公式这一块，除了fused_score，还要包含rerank_factor, text_factor, knn_factor等因子，以及text_score, knn_score, text_source_score, text_translation_score, … 等变量，要清晰的展示。 证据 matched_queries

耗时记录方面：

1. Stage Timings: 为每个阶段耗时补充起止时间戳。 2， 我看到total_search大幅度大于上面各个Stage 的总和，可能漏了一些重要的stage，比如「款式意图 SKU 预筛选（StyleSkuSelector.prepare_hits）」，补上这个stage

但是也要注意，不要影响不带debug_info的请求的性能。

1. 日志方面也需要完善 从 query 到 ES 再到重排，对结果影响大的信息，语种检测 + index_languages，Query 向量，ES查询的构建过程中所使用的关键的变量、关键的中间结果，rerank相关信息（intput/window，query/doc 模板，融合公式的详细信息和关键的因子、输入原始值以及中间变量、到最终的融合公式的因子，Page fill，sku_filter_dimension等

2. 测试用例方面 子串匹配（Direct 阶段）是否可能产生误判 — 与尺码/短词强相关 _is_direct_match 使用 normalized_value in query_text（见 sku_intent_selector.py）。 词表里 l、m、s、xl，会在常见英文 query 里产生字符级子串命中，例如"l" 是否会匹配 "large …" 里的 l，注意要用分词匹配，检查分词匹配逻辑是否容易产生badcase。