25 Mar, 2026
9 commits
-
这两个配置、四种情况： backend: qwen3_vllm | qwen3_vllm_score instruction_format: compact | standard 调用 python scripts/benchmark_reranker_random_titles.py 100,200,400,600,800,1000 --repeat 5 产出性能测试报告 平均延迟（ms，客户端 POST /rerank 墙钟，--seed 99） backend instruction_format n=100 n=200 n=400 n=600 n=800 n=1000 qwen3_vllm compact 213.5 418.0 861.4 1263.4 1744.3 2162.2 qwen3_vllm standard 254.9 475.4 909.7 1353.2 1912.5 2406.7 qwen3_vllm_score compact 239.2 480.2 966.2 1433.5 1937.2 2428.4 qwen3_vllm_score standard 299.6 591.8 1178.9 1773.7 2341.6 2931.7 归纳： 在本机 T4、当前 vLLM 与上述 YAML（max_model_len=160、infer_batch_size=100 等）下，两种后端都是 compact 快于 standard；整体最快为 qwen3_vllm + compact（n=1000 ≈ 2.16 s），最慢为 qwen3_vllm_score + standard（≈ 2.93 s）。其他 GPU / vLLM 版本下排序可能变化。
-
@config/dictionaries/style_intent_color.csv @config/dictionaries/style_intent_size.csv @query/style_intent.py @search/sku_intent_selector.py 1. 两个csv词典，分为三列， - 英文关键词 - 中文关键词 - 标准属性名称词 三列都可以允许逗号分割。补充的第三列使用在商品属性中，使用的是标准的英文名称 2. 判断意图的时候，中文词用中文翻译名去匹配，如果不存在中文翻译名，则用原始 query，英文词同理 3. SKU 选择的时候，用每一个 SKU 的属性名去匹配。 匹配规则要大幅度简化，并做性能优化： 1）文本匹配规则只需要看规范化后的属性值是否包含了词典配置的第三列"标准属性名称词"，如果包含了，则认为匹配成功。 找到第一个匹配成功的即可。如果都没有成功，后面也不再需要用向量匹配。 暂时废弃向量匹配、双向匹配等复杂逻辑。
24 Mar, 2026
7 commits
-
加了一个过滤/降权词典，query中有独立分词匹配到指定的触发词，将过滤带某些分词的商品（比如fitted/修身，过滤宽松、loose、relaxed、baggy,slouchy等商品） 2. reranker的query使用翻译后的
-
上面一版实现，性能上完全无法接受。因此进行了一轮策略简化 style_sku_prepare_hits阶段耗时太长。请根据需求，思考优化的方法，给出性能优化的方案。 1. _select_by_embedding，有缓存吗，option_value的值是有限的，之前已经算过的，就不用再算了。不仅仅是embedding相似的结果，整个option_value的匹配结果，是有包含、还是没包含，相似度多少，都不用重新计算。比如之前已经有一个sku的某个属性值叫做“卡其色”，已经算出来是否文本匹配了，那么不需要再去做文本匹配。如果已经算出来向量的相似度，那么不需要再去取向量以及计算相似度。 2. 匹配可以适当的优化： 匹配流程简化： 1）找到第一个文本匹配的，如果有直接匹配成功。不需要考虑匹配多个的情况。 2）如果全部都没有匹配，那么进行embedding筛选。 匹配规则： option_name的匹配，直接看规范化后的option_name是不是意图维度的泛化词之一（比如颜色、color、colour），如果没有匹配的，现在应该是把所有维度都算上，这样匹配成本和比较成本太高了，去掉这些逻辑，这种情况不需要加后缀、不需要选择sku。 ption_value的匹配。意图检测的时候，有匹配的query中的命中的词，这个词被包含在属性值中，那么就算匹配。属性值被包含在query（包括翻译文本）中，也算匹配。提高匹配的覆盖率。 3. 这一阶段得到sku选择的结果即可（选中的sku的id，也可以为空值表示没找到匹配成功的，这种情况不需要拼接title后缀给重排输入），但是不用着急做image_url的替换和sku的置顶。等最后填充的时候判断有选中sku的时候直接做替换和置顶即可。 请你思考如何进行设计，提高性能的时候不带来复杂度的提升，可以适当的重构以降低修改后的代码行数。 @search/sku_intent_selector.py @query/style_intent.py
-
The backend now exposes a structured debug_info that is much closer to the real ranking pipeline: query_analysis now includes index_languages, query_tokens, query-vector summary, translation/enrichment plan, and translation debug. query_build now explains the ES recall plan: base-language clause, translated clauses, filters vs post-filters, KNN settings, function-score config, and related inputs. es_request distinguishes the logical DSL from the actual body sent to ES, including rerank prefetch _source. es_response now includes the initial ES ranking window stats used for score interpretation. rerank now includes execution state, templates, rendered rerank query text, window/top_n, service/meta, and the fusion formula. pagination now shows rerank-window fetch vs requested page plus page-fill details. For each result in debug_info.per_result, ranking debug is now much richer: initial rank and final rank raw ES score es_score_normalized = raw score / initial ES window max es_score_norm = min-max normalization over the initial ES window explicit normalization notes explaining that fusion does not directly consume an ES-normalized score rerank input details: doc template, title suffix, template field values, doc preview/length fusion breakdown: rerank_factor, text_factor, knn_factor, constants, raw inputs, final fused score text subcomponents: source/translation/weighted/primary/support/fallback evidence via matched_queries richer style-intent SKU debug, including selected SKU summary and intent texts
-
2， 漏了一些重要的stage，比如「款式意图 SKU 预筛选（StyleSkuSelector.prepare_hits）」，补上这个stage
23 Mar, 2026
8 commits
-
combined_fields+best_field+phrase_boost
-
子句都变成了一个带有以下结构的命名布尔查询： must：combined_fields should：加权后的 best_fields 和 phrase 子句 主要改动位于 search/es_query_builder.py，但此次调整沿用了现有语言路由设计，并未引入一次性分支。额外的 should 子句权重现在通过 config/schema.py、config/loader.py、search/searcher.py 以及 config/config.yaml 进行配置驱动，从而保持结构的集中管理。
22 Mar, 2026
4 commits
21 Mar, 2026
3 commits
20 Mar, 2026
9 commits
-
问题描述 ---------- 使用 facebook/nllb-200-distilled-600M（CTranslate2 后端）时，若 API 传入 ISO 639-1 或 FLORES 短标签（如 ca、da、nl、sv、no、tr 等），会触发 「Unsupported NLLB source/target language」。模型与 tokenizer 实际支持这些语言； 根因是 resolve_nllb_language_code 仅依赖 translation/languages.py 里十余条 NLLB_LANGUAGE_CODES 映射，大量合法短码未注册，校验误报为不支持。 修改内容 ---------- 1. 新增 translation/nllb_flores_short_map.py - NLLB_FLORES_SHORT_TO_CODE：与 HF 模型卡 language 列表对齐的短标签 -> NLLB 强制 BOS/src_lang 形式（<ISO639-3>_<ISO15924>，如 cat_Latn）。 - NLLB_TOKENIZER_LANGUAGE_CODES：从 tokenizer.json 提取的 202 个语言 token 全集，供直接传入 deu_Latn 等形式时做规范化解析。 - 额外约定：ISO 639-1「no」映射 nob_Latn（书面挪威语 Bokmål）；nb/nn 分别 对应 nob_Latn / nno_Latn；「ar」显式指向 arb_Arab（与 NLLB 一致）。 2. 调整 translation/languages.py - build_nllb_language_catalog：合并顺序为 FLORES 全表 -> NLLB_LANGUAGE_CODES （保留少量显式覆盖，如 zh->zho_Hans）-> 调用方 overrides。 - resolve_nllb_language_code：在目录与别名之后，增加基于 NLLB_TOKENIZER_LANGUAGE_CODES 的大小写不敏感匹配（如 eng_latn -> eng_Latn）， 覆盖「已传完整 NLLB 码」的场景。 3. tests/test_translation_local_backends.py - 新增 test_nllb_resolves_flores_short_tags_and_iso_no，覆盖用户关心的短码及 deu_Latn 直通解析。 方案说明 ---------- NLLB 接口语义以 Hugging Face NllbTokenizer 为准：语言标识为 FLORES-200 风格 三字母语种码 + 下划线 + 四字母脚本子标签（ISO 15924）。业务侧常用 ISO 639-1 （de、sv）或模型卡短列表（ca、nl），需在服务内统一映射到 tokenizer 特殊 token。 本实现以模型卡 language 字段 + tokenizer 词表为单一事实来源生成静态表， 避免运行时依赖额外库；同时保留原有 NLLB_LANGUAGE_CODES 作为薄覆盖层以兼容 既有配置与测试。 Refs: https://huggingface.co/facebook/nllb-200-distilled-600M Made-with: Cursor -
ResultFormatter.format_search_results() runs. What changed: For each final paginated SPU hit, the searcher now scans skus[].option1_value against the query text set built from the original query, normalized query, rewritten query, and translations. If no option1_value matches textually, it falls back to embedding similarity and picks the SKU with the highest inner product against the query embedding. The matched SKU is promoted to the front of the SPU’s skus list. The SPU-level image_url is replaced with that matched SKU’s image_src. I left api/result_formatter.py unchanged because it already preserves the SKU order and reads image_url from _source; updating the page hits in searcher makes the formatter return the desired result automatically. Verification: ReadLints on the edited files: no errors Passed targeted tests: pytest tests/test_search_rerank_window.py -k "translated_query or no_direct_option_match"
-
## 背景 多语言索引下，用户查询常中英混写；需在解析阶段显式标记脚本类型，并在 BM25 子句中同时覆盖对应语言字段。 ## 方案 ### 1. Query 分析（query_parser.ParsedQuery） - 新增 `contains_chinese`：query 文本含 CJK（沿用 _contains_cjk）。 - 新增 `contains_english`：分词结果中存在「纯英文、len>=3」token（fullmatch 字母及可选连字符）。 - 写入 to_dict、请求 context 中间结果，便于调试与 API 透出。 ### 2. ES 文本召回（es_query_builder._build_advanced_text_query） - 对每个 search_lang 子句：若含英文且子句语言非 en（且租户 index_languages 含 en），合并 en 列字段；若含中文且子句语言非 zh（且含 zh），合并 zh 列字段。 - 合并进来的字段 boost 乘以 `mixed_script_merged_field_boost_scale`（默认 0.8，可在 ESQueryBuilder 构造参数调整）。 - fallback_original_query_* 分支同样应用上述逻辑。 ### 3. 实现整理 - 引入 `MatchFieldSpec = (field_path, boost)`：`_build_match_field_specs` 为唯一权重来源；`_merge_supplemental_lang_field_specs` / `_expand_match_field_specs_for_mixed_script` 在 tuple 上合并与缩放；最后 `_format_match_field_specs` 再格式化为 ES `path^boost`，避免先拼字符串再解析。 ## 测试 - tests/test_query_parser_mixed_language.py：脚本标记与 token 规则。 - tests/test_es_query_builder.py：合并字段、0.8 缩放、index_languages 限制。 Made-with: Cursor