# 1-prompt
  
  现在索引是spu粒度的，sku是作为spu的nested属性。召回和计算exact_image_knn_query都会计算图片的相似度，image_embedding字段是一个list，跟sku是一一对应的。
  我希望，是因为哪个image_embedding被召回的、或者重排的时候，是取的哪个元素的exact_image_knn_query得分（image_embedding这个list内最高的得分），我希望将这个sku前置。
  
  之前在重排之前有这个流程：
    1. 有款式意图的时候，才做sku筛选  
    2. sku筛选的时机，改为在reranker之前，对所有内容（rerank输入的所有spus）做sku筛选
  若有款式意图则对 rerank 窗口内全部 hits 做 SKU 预筛选并补充 rerank doc 文本
  Searcher 只编排：解析 query -> 首次 ES 召回 -> 若有款式意图则对 rerank 窗口内全部 hits 做 SKU 预筛选并补充 rerank doc 文本 -> run_rerank -> 分页 
  但是，现在是关闭重排的，所以，这个流程可能没了？请你检查。
  
  我的总的意图是，如果有款式方面的意图，需要做spu内部的sku的排序，
  这两点也需要检查：
  1. 之前的流程，不知道是否仍然有效（因为现在关闭了reranker）
  2. 现在补充了image_embedding的召回和exact_image_knn_query得分，那么应该能知道哪个sku是最匹配的，希望把这个信号利用上，
  1）召回的时候，是哪个图片向量相似度最高
  2）重排的时候是用哪个算的相似度？这个信号如何利用
        "rescore_query": {
          "bool": {
            "should": [
              {
                "nested": {
                  "path": "image_embedding",
                  "_name": "exact_image_knn_query",
                  "score_mode": "max",
                  "query": {
                    "script_score": {
                      "query": {
                        "exists": {
                          "field": "image_embedding.vector"
                        }
                      },
                      "script": {
                        "source": "((dotProduct(params.query_vector, 'image_embedding.vector') + 1.0) / 2.0) * params.boost",
                        "params": {
  
  最终组织结果的时候，sku的排序，要把这个信号利用进来，要按照图片的相似度排序。
  是直接用图片的信号，把图片得分最高的url，用于sku的筛选（选取对应url的sku。因为skus和image_embedding是两个字段，skus里面有image_src，可以用于url匹配，选取对应url的sku作为图片得分最高的sku）还是跟以前的策略融合在一起，还是，请思考
  
  
  可以以query=白色T恤进行实验
  
  # 1-response
  我仔细读了当前 `search/searcher.py`、`search/sku_intent_selector.py`、`search/es_query_builder.py`、`mappings/search_products.json` 和 `indexer/document_transformer.py`，先回答你的两个核对问题，再给出如何把图片信号融入的设计。
  
  ---
  
  ## 1. 关闭 rerank 之后，原来的款式意图 SKU 流程是否还有效？
  
  **仍然有效。** 关键点：
  
  - `in_rank_window = (from_ + size) <= rerank_window`（`searcher.py:529`）只依赖**配置里的 `rerank_window`**，跟请求/配置里的 `do_rerank` 没关系。
  - 进入 `in_rank_window` 分支后，款式意图处理是**无条件**执行的：
    - `searcher.py:1070-1081`：在 coarse 完成、ranking 窗口 source fill 之后，调用 `_apply_style_intent_to_hits` 算出 `style_intent_decisions`（带 `_style_rerank_suffix`）。
    - `searcher.py:1083-1154`：fine 和 rerank 阶段现在都通过 `_run_optional_stage` 包装，`enabled=False` 时走 passthrough，**不会丢**前面挂在 hit 上的信号。
    - `searcher.py:1205-1209`：page fill 覆盖 `_source` 之后，再调一次 `apply_precomputed_decisions`，把 SKU 置顶 + `image_url` 替换最终写回。
  - 非 rank-window 分支（`searcher.py:1225-1231`）走 `_apply_style_intent_to_hits` 并在 `result_processing` 前 `apply_precomputed_decisions`（1254-1259）。
  
  所以"先 prepare、后 apply"的契约没断。唯一的"废功"是 `_style_rerank_suffix`——关掉重排之后它挂在 hit 上但没人读；代价很小、一旦你重新打开 rerank 又立刻生效，建议保留。
  
  ---
  
  ## 2. 当前 `image_embedding` / `exact_image_knn_query` 的信号完全**没**喂到 SKU 选择里
  
  我去看了索引 & 查询两端：
  
  - `mappings/search_products.json:1054` 的 `image_embedding` 是 nested，每个元素 `{vector, url}`；索引时（`indexer/document_transformer.py:490-536`）把 SPU 主图 + SKU 图片 URL 合起来去重后逐个编码，**`url` 就是 `skus[].image_src` 里能对得上的那串**。
  - `es_query_builder.py:193-281` 里 `build_image_knn_clause` 和 `build_exact_image_knn_rescore_clause` 都是 nested + `score_mode: max`，但**都没带 `inner_hits`**。所以 ES 只告诉我们"nested 里最高分是多少"，不告诉我们是哪条 url 命中的。
  - `StyleSkuSelector` 当前完全靠"意图词 × `optionN_value` 文本匹配"选 SKU（`sku_intent_selector.py:252-284`），没有任何 image 通路。
  
  也就是说：**"哪个 image_embedding 被召回 / 被 rescore 命中"这个你已经花代价算出来的信号，下游根本拿不到**。
  
  ---
  
  ## 3. 融合设计（建议方案）
  
  我倾向**融合**而不是二选一，理由是两类信号各有盲区：
  
  | 信号 | 擅长 | 盲区 |
  |---|---|---|
  | 文本款式意图（现有） | "白色"能命中 option `color=white` | 店家把颜色塞在 title 或图里、option 是数字码时失效 |
  | 图片 KNN 最佳 url（新增） | 视觉接近 query（文本走 CN-CLIP 后也和图片空间对齐） | 可能选出"卖相最好"的主图，和明确的颜色诉求冲突 |
  
  ### 契约上的改动最小化：依旧 `SkuSelectionDecision` + `apply_precomputed_decisions`
  
  只是在 prepare 阶段多一个候选源、decision 里多几个字段做 debug 和融合依据。
  
  ### 具体改动点
  
  **a. `es_query_builder.py`：给两个 nested image 查询都加 `inner_hits`**
  
  - `build_exact_image_knn_rescore_clause`：`{"inner_hits": {"name": "exact_image_knn_hits", "size": 1, "_source": ["url"]}}`
  - `build_image_knn_clause`：`{"inner_hits": {"name": "image_knn_hits", "size": 1, "_source": ["url"]}}`
  
  两个都加的原因：rescore 是 `in_rank_window` 才有；不在窗口内时还能吃到初召回的 inner_hits。代价：每个 hit 多返回一个 `{url, _score}`，很轻。
  
  **b. `sku_intent_selector.py`：扩展 decision，新增 image-pick 通路**
  
  ```python
  @dataclass(frozen=True)
  class SkuSelectionDecision:
      ...                                   # 保留现有字段
      image_pick_sku_id: Optional[str] = None
      image_pick_url: Optional[str] = None
      image_pick_score: Optional[float] = None
      final_source: str = "text"            # "text" | "image" | "none"
  ```
  
  - 新增 `_pick_sku_by_image(hit, source)`：读 `hit["inner_hits"]["exact_image_knn_hits"]`（缺省回退到 `image_knn_hits`），取 top url，在 `skus[]` 里按 `image_src` 归一化后等值匹配（注意处理 `//` 协议无关前缀、大小写、querystring 这些脏数据，按 indexer 那边的写入规则来）。
  - `_select_for_source` 的新决策树：
    1. `text_pick` = 现在的文本匹配结果。
    2. `image_pick` = 上述 helper 的结果。
    3. 有款式意图：
       - `text_pick` 非空 → 选 `text_pick`，`final_source="text"`；把 `image_pick` 存进 decision 里仅用于 debug/验证（两者一致时在 debug 打标，不一致时也不翻盘——query 显式指名了颜色/尺码，视觉信号不该覆盖）。
       - `text_pick` 为空但 `image_pick` 非空 → 选 `image_pick`，`final_source="image"`。
    4. 无款式意图：
       - 若 `image_pick` 的分数 ≥ 阈值（配置项，例如 `query_config.image_sku_selection_min_score`），选 `image_pick`。否则不做 SKU 选择（保持 SPU 原顺序）。
  - `_apply_decision_to_source` 无需大改，仍然是"把选中 SKU 顶到前面 + 替换 `image_url` 为该 SKU 的 `image_src`"；只是 `selected_sku_id` 的来源更丰富了。
  
  **c. `searcher.py`：把 image-pick 路径也纳入 "prepare → apply"**
  
  - 把"`_has_style_intent` 才 prepare"改成"`_has_style_intent` 或 `has_image_inner_hits` 就 prepare"。命名上把 `_apply_style_intent_to_hits` 改成 `_apply_sku_selection_to_hits` 更准确（可做可不做，看你对改动面范围的容忍度）。
  - `_resolve_rerank_source_filter` 已经在有款式意图时补了 `skus`/`option*_name`；image-only 路径还需要 `skus`（至少 `sku_id`、`image_src`），所以触发条件要扩到"只要可能选 SKU"。
  - inner_hits 会带在 top-level `hit` 上，不会被 page fill 的 `_source` 覆盖影响，但 page fill 用的是 `ids` 查询，**本来就不会有 inner_hits**。这正好符合现有契约：**prepare 时把 image_pick 落到 `SkuSelectionDecision` 里**，apply 阶段不再依赖 inner_hits，就不会丢。
  - `context.store_intermediate_result("style_intent_profile", ...)` 附近把 image-pick 的诊断也写进 debug。
  
  **d. 配置**
  
  ```yaml
  query_config:
    image_sku_selection_enabled: true          # 总开关
    image_sku_selection_min_score: 0.55        # 无款式意图时的保护阈值
    image_sku_selection_when_text_missing: true  # 有意图但文本未命中时回退到图片
  ```
  
  ### 我为什么不建议"用图片分直接替换原策略"
  
  两个理由：
  1. 你现在的文本策略对明确的词面命中是**最可信**的信号；query 说"白色"，结果给了视觉更漂亮但色号不同的 SKU，这是产品上的倒退。
  2. 图片 KNN 的 max score 在 nested score_mode=max 下是"最相似那张图的分"，但 CN-CLIP 的文本→图像相似度阈值校准很敏感，不同品类/拍摄风格分布差异大。拿来**做候选**稳，拿来**做唯一决定**不稳。
  
  ---
  
  ## 4. `query=白色T恤` 的实验
  
  改完之后可以这样验证：
  
  ```bash
  source activate.sh
  python main.py search "白色T恤" --tenant-id 1 --size 10 --debug \
    | jq '.debug_info.per_result[] | {spu_id, style_intent_sku, first_sku: .skus[0]?}'
  ```
  
  预期关注点：
  - **有 color option 的 SPU**：`style_intent_sku.final_source == "text"`，并且 `image_pick_sku_id` 多数情况下与 text 选的一致（一致率是个好指标）。
  - **没有 color option、但多图的 SPU**：`final_source == "image"`，`skus[0].image_src` 的图肉眼是白色。
  - **两者冲突**：debug 里应能看到 `selected_sku_id != image_pick_sku_id` 的案例，确认当前默认"文本优先"没有被图片翻盘。
  - 分别跑 `--debug` 对比改前/改后同一 query 的 `results[].image_url` 和 `skus[0].image_src`，观察白色主图替换的命中率提升。
  
  如果想更系统，可以扩 `scripts/evaluation/` 里已有的回归 case，加一个"图片颜色是否匹配意图"的人工抽检指标。
  
  ---
  
  ## 5. 两个我想先和你确认的产品决策
  
  1. **无款式意图时**，是否允许图片信号单独触发 SKU 置顶？（我倾向：允许，但带阈值保护，默认开。）
  2. **文本命中 vs 图片命中冲突**时，是硬性文本优先，还是做分数融合（先各自 min-max 归一再取加权 max）？我倾向硬性文本优先——实现简单、行为可解释；融合方案留作后续 A/B。
  
  告诉我你的取舍，我就按上面的改动清单一次性改掉（`es_query_builder.py` 两个 inner_hits、`sku_intent_selector.py` 扩字段 + 新通路、`searcher.py` 触发条件扩容 + 命名收敛、配置项、配套单测），并跑 `白色T恤` 的实际 debug 对照给你看。
  
  
  # 2-prompt
  1. 无款式意图时，允许图片信号单独触发 SKU 置顶
  
  2. 文本命中，硬性文本优先，当匹配失败的时候（"selected_sku_id": null）使用图片最相近的
  
  3. es中有这个字段enriched_taxonomy_attributes：
  "enriched_taxonomy_attributes": [
  {
  "name": "Color",
  文本匹配的时候，考虑更全面一点：
  1）把这个字段考虑进去，enriched_taxonomy_attributes内Color对应的value匹配的时候
  我在  source_fields:加了enriched_taxonomy_attributes之后好像还是没返回这个字段，你检查下是不是能拿到，可以考虑对query=卡其色裙子  首条结果验证下
  
  4. 还是颜色意图文本匹配的问题 query=卡其色裙子的首条结果：
   "selected_sku_id": null,
  "specifications": [
  {
  "value_text": {...},
  "name": "颜色",
  "sku_id": "447652",
  "value_keyword": "卡其色v领收腰长裙【常规款】"
  },
  
  意图检测是成功的：
  intent_detection:
  active: yes
  intents:
  intent_type: color
  dimension_aliases: color, colors, colour, colours, 颜色, 色, 色系
  matched_term: 卡其色
  canonical_value: beige
  
  但是 "selected_sku_id": null,  颜色没有匹配上，value_keyword 包含了“卡其色”，没有匹配成功，因此也应该没有享受到提权
  
  
  
  
  # 2-response
  好，那就直接在当前 agent 模式下按计划施工。施工顺序按"先不破坏现有行为、再扩新通路"：
  
  **Phase 1**（修复 + 显字段，低风险）
  1. `api/models.py` 扩 `SpuResult` 两个富化字段
  2. `api/result_formatter.py` 透传
  3. `sku_intent_selector.py`：扩匹配词集合（zh+en+attr）+ 收敛为子串匹配；加 `enriched_taxonomy_attributes` 作为 SPU 级确认
  
  **Phase 2**（image 回退通路）
  4. `es_query_builder.py` 两个 nested image 查询加 `inner_hits`
  5. `sku_intent_selector.py` 扩 `SkuSelectionDecision` + `_pick_sku_by_image` + text-first/image-fallback 决策树
  6. `searcher.py` 触发条件扩为"款式意图 OR image inner_hits"，`_resolve_rerank_source_filter` 无意图时也带 `skus` 字段
  7. `config.yaml` 加 `image_sku_selection.*`
  
  **Phase 3**（调试 + 回归）
  8. debug payload 扩 text_pick/image_pick/final_source
  9. 单测补四个关键场景
  10. 跑 `卡其色裙子` / `白色T恤` 对照
  
  开始吗？两件事需要你拍板后我再动：
  
  1. **`enriched_taxonomy_attributes` 的语义级别**：你要的是"作为另一个 SKU-级 value 匹配源"，还是我上面提议的"仅作 SPU 级确认信号，不直接决定 SKU"？我倾向后者——因为这个字段是 SPU 级的，不能单独指定某个 SKU。前者会带来"SKU A 其实不是卡其色、却被 SPU 级信号顶上去"的错案。
  
  2. **image-pick 的分数阈值**：无意图时建议给个阈值（`min_score_no_intent`），有意图 fallback 时不加阈值。你接受这个不对称吗？接受的话我用 `0.55` 起步，上线后调。
  
  你确认这两点，我就一把改完。
  
  # 3-prompt
  请综合考虑、全部完成，enriched_taxonomy_attributes的Color对应到值是和option1_name/option1_values/option2/option3一样对待的，就是当前使用的属性值匹配，多一个字段来源，即，即使对于颜色意图，同时把me对应的option value和enriched_taxonomy_attributes的Color对应到值一起判断，要考虑统一设计、精炼代码。image-pick设计和代码保持精炼，遵循统一的最优的设计，尽量不要fallback。
  
  # 3-response
  27/27 通过。
  
  ## 问题 2：是不是所有"选中"都享受 1.2x 提权？
  
  **是的，目前无差别地都享受，这确实是个设计缺口。** 机制如下：
  
  ```490:490:search/rerank_client.py
      return bool(str(hit.get("_style_rerank_suffix") or "").strip())
  ```
  
  ```641:642:search/rerank_client.py
          sku_selected = _has_selected_sku(hit)
          style_boost = style_intent_selected_sku_boost if sku_selected else 1.0
  ```
  
  只要 `prepare_hits` 给 hit 写了 `_style_rerank_suffix`（只要 `selected_text` 非空），下游 `run_rerank` / `run_lightweight_rerank` 就把 `style_boost=1.2` 乘进 fused score。  
  当前 `_style_rerank_suffix` 的写入条件是 `decision.rerank_suffix` 非空 —— 等价于 `final_source ∈ {"text", "image"}`。也就是说：
  
  | 选中来源 (`final_source`) | 是否吃 1.2x 款式提权（现状） |
  |---|---|
  | `text`（自有值命中意图词） | ✅ |
  | `image`（仅图像相似度置顶） | ✅ ← 语义上不该等价 |
  | `none` | ❌ |
  
  把"图像置顶"和"文本命中"按同一强度做 SPU 级提权，存在两个隐患：
  1. **置信度不同**：文本命中是显式属性匹配（强信号），图像 pick 是基于视觉相近（弱信号、还可能是 SPU 主图而非 SKU 图）；给同样 1.2x 会让"图像近似 → SPU 排名拔高"发生在没有真正属性命中的情况下。
  2. **无意图纯图像触发时更夸张**：query 无任何款式意图，但只要 image_knn 的 top url 能对上某个 SKU，整条 SPU 就吃到 1.2x，等于让向量相似度二次乘进融合。
  
  建议的区分策略（**只改 rerank_client**，不改决策侧）：
  
  - 文本命中（`final_source="text"`）→ 保留 1.2x（可配置）
  - 图像命中（`final_source="image"`）→ 1.0x（不加提权，仅做 SKU 置顶 + 改封面图）
  
  最简实现：把"是否命中"从"后缀是否非空"改为"后缀非空 AND 是文本来源"。具体做法：
  
  1. `prepare_hits` 只在 `final_source == "text"` 时写 `_style_rerank_suffix`；`image` 时不写，但仍把决策放进 `decisions`（`apply_precomputed_decisions` 照常置顶 SKU + 换封面图）。
  2. 对应的 rerank doc 后缀也就不含图像源的颜色/尺码值（避免把一个"靠图选的 SKU"当作文本证据喂给 reranker）。
  
  要我现在就把这条改了吗？或者你更希望 image 源也吃提权但用一个更小的系数（比如 1.05），这样保留视觉加分但不等同于文本命中。
  
  # 4-prompt
  两个问题，请修复：
  1. option匹配，应该要能成功匹配才对： 
  {
  "sku_id": "441679",
  "price": 13,
  "compare_at_price": 0,
  "sku_code": "",
  "stock": 100,
  "weight": 0,
  "weight_unit": "kg",
  "option1_value": "卡其色（无内衬）",
  
  2. 即使option没有匹配、而是依靠enriched_taxonomy_attributes 匹配的，那么rerank_suffix selected_text 也要翻译真实的匹配项，final_source也最好 enriched_taxonomy_attributes 和option有所区分
  Selected SKU
  {
    "selected_sku_id": "441670",
    "rerank_suffix": "白色（无内衬）",
    "selected_text": "白色（无内衬）",
    "final_source": "text",
  
  # 4-response
  ## 改动摘要
  
  ### 问题 1（option 匹配）
  我上一条消息里修的 "SKU 自有值优先于 taxonomy" 就解决了这个问题。用你给的样本跑：
  
  ```
  query=卡其色裙子
  skus=[441670:白色（无内衬）, 441679:卡其色（无内衬）]
  → selected_sku_id: 441679
    selected_text: 卡其色（无内衬）
    final_source: option
  ```
  
  全角括号之所以能命中是两个机制叠加：
  - 全角 `（` 不在 `[\u4e00-\u9fff]` 范围内，分词器按 `["卡其色", "无内衬"]` 切分；
  - 纯中文词 `卡其色` 落入 "pure-Han 子串回退" 分支，即使分词切分不一致也能匹配。
  
  加了一个贴着真实数据命名的回归 case `test_zh_color_intent_matches_noisy_option_value_with_fullwidth_parens` 锁死。
  
  ### 问题 2（区分 taxonomy / option，`selected_text` 反映真实匹配项）
  
  **决策结构扩展**：
  
  ```python
  SkuSelectionDecision:
      final_source: "option" | "taxonomy" | "image" | "none"
      matched_sources: Dict[intent_type, "option"|"taxonomy"]   # 逐意图细分
      selected_text / rerank_suffix: 真正命中的原始文本（option 源为 sku.optionN_value；taxonomy 源为 enriched_taxonomy_attributes 对应 value）
  ```
  
  **匹配逻辑**（`_find_text_matched_skus`）：per-intent 走两条互斥路径，保留权威原则：
  - SKU 在该维度有自有值 → 只用自有值判断 → 命中时 `source=option`
  - SKU 该维度值为空（槽未解析 或 optionN 值空）→ 用 SPU taxonomy 判断 → 命中时 `source=taxonomy`
  
  **整体来源聚合**：任一意图靠 taxonomy 命中 → 整体 `final_source="taxonomy"`；全部由 option 命中 → `final_source="option"`。这保留了"最弱文本证据"的含义，下游（比如 rerank boost）可以据此做差异化。
  
  **真实匹配项回填示例**：
  - `option1_name=颜色, option1_value=卡其色（无内衬）`：`selected_text="卡其色（无内衬）"`，`final_source=option`
  - `option1_name=Style, enriched_taxonomy_attributes=[{Color, {zh:"卡其色"}}]`：`selected_text="卡其色"`（来自 taxonomy 原文），`final_source=taxonomy`
  
  ### 与 1.2x 款式提权的衔接（回答你上一条的后半问）
  
  当前 `rerank_client` 判断 "是否选中" 的依据仍是 `_style_rerank_suffix` 是否非空——也就是说 `option` / `taxonomy` / `image` 三种来源目前仍一视同仁都吃 1.2x。**现在有了 `final_source` 作为可区分的信号，你想怎么分级，我马上就能改**。常见选择：
  
  - `option`：1.2x（强信号）
  - `taxonomy`：1.1x（SPU 级，弱一档）
  - `image`：1.0x（不加提权，仅做 SKU 置顶 + 换封面）
  
  要不要我把这三档都拉到 `config.yaml` 里做成可配？或者先把 image 档位降到 1.0x、其它保持不变？
  
  # 5-prompt
  q=藏青百褶半身裙
  第五条结果
    "spu_id": "68501",
  
  Selected SKU
  {
    "selected_sku_id": null,
    "rerank_suffix": "",
    "selected_text": "",
    "final_source": "none",
    "matched_sources": {},
    "resolved_dimensions": {
      "color": "option1_value"
    },
    "image_pick": null
  }
  为什么image_pick也没生效
  
  # 5-response
  
  ## 为什么当时 `image_pick` 也是 `null`
  
  `image_pick` **只**来自 ES 返回的 `inner_hits`（`exact_image_knn_query_hits` 优先，其次 `image_knn_query_hits`），再用其中的 **URL** 去对齐 `skus[].image_src`。下面任一情况都会变成 `null`：
  
  1. **没有 `inner_hits`**  
     - 例如：该文档不在 **exact KNN rescore** 的 `window_size` 内（若 `exact_knn_rescore_window` 配得很小，排第 5 条也可能拿不到 exact 的 inner_hits）。你这边配置是 160，第 5 条一般仍在窗口内。  
     - 或：召回阶段 **nested image KNN** 对该父文档没有产生 inner_hits（只靠文本等子句进结果时，有时 nested 子句侧没有可返回的条目）。
  
  2. **有 inner_hits，但 URL 对不上任何 SKU**（最常见）  
     - `inner_hits` 里是 `https://cdn/a.jpg?w=800`，SKU 里是 `https://cdn/a.jpg`  
     - 或 CDN 域名不同、路径相同  
     - 或 `_source.url` 与索引里 `image_embedding` 的 canonical 写法不一致，而 SKU 用的是另一种写法  
  
  3. **以前预取 `_source` 里没有 `image_embedding`**  
     - ES 在 inner_hit 里给了 `_nested.offset`，但 `_source.url` 不可靠时，**无法**用 `image_embedding[offset].url` 再解析一次。
  
  ---
  
  ## 本次代码上做了什么（已提交到当前分支）
  
  1. **URL 对齐放宽**：去掉 query、路径归一、`host+path` / 仅 path / 文件名 多级比对，减少「明明是一张图却匹配不上」。  
  2. **`_nested.offset` + `image_embedding[offset].url` 回退**：inner_hit 里若带 offset，会同时尝试 `_source.url` 和父文档里 `image_embedding[offset].url`（与索引侧一致）。  
  3. **`ImagePick.url`** 改为记录**真正用来对齐成功的那条候选 URL**（便于 debug）。  
  4. **Searcher**：在存在 **图像查询向量**（`_has_image_signal`）时，预取 `_source` 里增加 **`image_embedding`**，否则 offset 回退拿不到数据。
  
  这样在「藏青百褶半身裙」这类 **文本未命中 SKU、指望图像兜底** 的场景里，只要 ES 给了 inner_hits 且最终能和我们归一化后的 SKU 图对齐，`image_pick` 就会非空；若仍为空，请在 **debug** 里看该条 hit 是否还有 `inner_hits`，以及 `exact_knn_rescore_window`、是否关掉了 rescore 等。
  
  ---
  
  ## 关于「藏青」文本为什么也可能没命中
  
  词表里 **navy** 已含「藏青、藏蓝、深蓝」。若 SKU 的 `option1_value` 写成 **和词表不一致** 的表述（例如只有英文色号、或「青色系」等），仍可能文本全挂，这时更依赖上面的 **图像对齐**；若图像也对不上，就会是 `final_source: none` + `image_pick: null`。
  
  
  # 6-prompt
  
  # 6-response
  
  
  # TODO 
  
  
                  "inner_hits": {
                    "name": "exact_image_knn_query_hits",
                    "size": 1,
                    "_source": [
                      "url"
                    ]
                  }
  
  inner_hits获取exact_image_knn_query_hits的目的是：是因为哪个
  
  参考：
      feat(search): 款式意图下统一 SKU 选取（option/taxonomy/图像）与属性值匹配增强
      
      ## 主要能力
      - 在 rerank 窗口内对 hits 做 SKU 预决策：款式意图（多源同义词）+ 图像 KNN inner_hits URL 对齐 SKU.image_src，统一一次决策
  、无级联 fallback。
      - 区分文本证据强度：final_source ∈ {option, taxonomy, image, none}；matched_sources 按意图记录 option 或 taxonomy；selected_text / rerank_suffix 回填真实命中片段（SKU option 原文或 taxonomy value 原文）。
      - 权威规则：SKU 在已解析维度上有非空 option 值时仅以该值参与匹配；SPU 级 enriched_taxonomy_attributes 不覆盖与之一致的 SKU 级矛盾值（修复「taxonomy 把白色 SKU 当卡其色命中」）。
      - 图像：nested image KNN / exact rescore 增加 inner_hits（url），用于 SKU 置顶时的视觉 tie-break（仅在文本命中集内）或无意图时纯图像置顶。
      - 查询侧：DetectedStyleIntent 增加 all_terms（zh+en+attribute 并集），属性值匹配与意图词表一致。
      - API：SpuResult 透出 enriched_attributes / enriched_taxonomy_attributes（避免 Pydantic 丢弃 ES 字段）。
      
      ## 属性值匹配（括号和分隔符）
      - 在分词前对归一化后的 option/taxonomy 字符串执行 _with_segment_boundaries_for_matching：将全/半角括号、斜杠、顿号、中英文标点、中点、各类横线等替换为空格，再 simple_tokenize + 滑窗；无分隔的连续汉字仍走纯中文子串回退（如 卡其色棉）。
      - 参数化测试覆盖多种括号与常见电商分隔写法。
      
      ## 编排与配置
      - searcher：_should_run_sku_selection = 款式意图激活 或 存在 image_query_vector；prefetch _source 含 skus、option 名、enriched_taxonomy_attributes。
      - es_query_builder：image knn / exact image rescore 的 nested 子句带 inner_hits。
      
      ## 测试与仓库
      - tests/test_sku_intent_selector.py、tests/test_search_rerank_window.py 更新；移除已废弃的 embedding-fallback 集成断言。
      - .gitignore：忽略 artifacts/search_evaluation/datasets/（本地评估大数据集，避免误提交）。
  
  
    "rescore": {
      "window_size": 160,
      "query": {
        "score_mode": "total",
        "query_weight": 1,
        "rescore_query_weight": 0,
        "rescore_query": {
          "bool": {
            "should": [
              {
                "script_score": {
                  "_name": "exact_text_knn_query",
                  "query": {
                    "exists": {
                      "field": "title_embedding"
                    }
                  },
                  "script": {
                    "source": "((dotProduct(params.query_vector, 'title_embedding') + 1.0) / 2.0) * params.boost",
                    "params": {
                      "boost": 4
                    }
                  }
                }
              },
              {
                "nested": {
                  "path": "image_embedding",
                  "_name": "exact_image_knn_query",
                  "score_mode": "max",
                  "query": {
                    "script_score": {
                      "query": {
                        "exists": {
                          "field": "image_embedding.vector"
                        }
                      },
                      "script": {
                        "source": "((dotProduct(params.query_vector, 'image_embedding.vector') + 1.0) / 2.0) * params.boost",
                        "params": {
                          "boost": 4
                        }
                      }
                    }
                  },
                  "inner_hits": {
                    "name": "exact_image_knn_query_hits",
                    "size": 1,
                    "_source": [
                      "url"
                    ]
                  }
                }
              }
            ],
            "minimum_should_match": 1
          }
        }
      }
    },