01 Apr, 2026
2 commits
-
都会合并成数组，和 qanchors / enriched_tags 的处理方式保持一致，更符合你现在这套 ES mapping 的灌入方式。ES 的 text 字段本身支持数组，所以像 value.zh: ["舒适", "无鞋带设计"] 这种写法是可以正常入库的；nested 只是外层对象数组，不影响内部语言字段存数组。
-
`indexer/product_enrich.py`，不是再补一层判断。 根因有两个：缓存 key 按内容复用，但缓存值里还带着旧商品的 `id/title_input`；同时内部分析结果在历史上混用了 `tags` 和 `enriched_tags`。这样一旦命中旧缓存，`build_index_content_fields()` 会因为 `id` 对不上把结果丢掉，最后对外就变成全空。 现在的处理是： - 内部分析结果统一用 `tags` 作为 LLM/缓存层字段。 - 对外只在 `build_index_content_fields()` 封装时映射成 `enriched_tags`，`enriched_attributes` 里也统一产出 `name="enriched_tags"`。 - 读取缓存时会先做归一化：把旧缓存里的 `enriched_tags` 兼容成内部 `tags`，并把命中的缓存结果重绑到当前请求商品的 `id/title_input`。 - 写缓存时也统一写成归一化后的内部结构，并且空内容不再写入缓存。
18 Mar, 2026
3 commits
-
核心改动在 rerank_client.py (line 99)：fuse_scores_and_resort 现在按 rerank * knn * text 的平滑乘法公式计算，优先从 hit["matched_queries"] 里取 base_query 和 knn_query，并把 _text_score / _knn_score 一并写回调试字段。为了让 KNN 也有名字，我给 top-level knn 加了 name: "knn_query"，见 es_query_builder.py (line 273)。搜索执行时会在 rerank 窗口内打开 include_named_queries_score，并在显式排序时加上 track_scores，见 searcher.py (line 400) 和 es_client.py (line 224)。
-
2. 优化缓存，缓存粒度为商品级，每次只对batch中未cache的重新计算；key使用每个商品输入的hash