08 Apr, 2026
2 commits
-
Previously, both `b` and `k1` were set to `0.0`. The original intention was to avoid two common issues in e-commerce search relevance: 1. Over-penalizing longer product titles In product search, a shorter title should not automatically rank higher just because BM25 favors shorter fields. For example, for a query like “遥控车”, a product whose title is simply “遥控车” is not necessarily a better candidate than a product with a slightly longer but more descriptive title. In practice, extremely short titles may even indicate lower-quality catalog data. 2. Over-rewarding repeated occurrences of the same term For longer queries such as “遥控喷雾翻滚多功能车玩具车”, the default BM25 behavior may give too much weight to a term that appears multiple times (for example “遥控”), even when other important query terms such as “喷雾” or “翻滚” are missing. This can cause products with repeated partial matches to outrank products that actually cover more of the user intent. Setting both parameters to zero was an intentional way to suppress length normalization and term-frequency amplification. However, after introducing a `combined_fields` query, this configuration becomes too aggressive. Since `combined_fields` scores multiple fields as a unified relevance signal, completely disabling both effects may also remove useful ranking information, especially when we still want documents matching more query terms across fields to be distinguishable from weaker matches. This update therefore relaxes the previous setting and reintroduces a controlled amount of BM25 normalization/scoring behavior. The goal is to keep the original intent — avoiding short-title bias and excessive repeated-term gain — while allowing the combined query to better preserve meaningful relevance differences across candidates. Expected effect: - reduce the bias toward unnaturally short product titles - limit score inflation caused by repeated occurrences of the same term - improve ranking stability for `combined_fields` queries - better reward candidates that cover more of the overall query intent, instead of those that only repeat a subset of terms
07 Apr, 2026
4 commits
-
- consolidate suggestion rebuild flow into build_suggestions.sh via --rebuild and remove the redundant rebuild_suggestions.sh wrapper - make suggestion versioned index names use microseconds and handle index-create retries/timeouts without false already_exists failures - treat create requests as successful when the index was created server-side, then explicitly wait for shard readiness and surface allocation diagnostics - clean up freshly created suggestion indices on rebuild failure to avoid leaving red orphan indices behind - make rebuild smoke tests target the local backend by default, with SUGGESTIONS_SMOKE_BASE_URL as the explicit override - add unit coverage for microsecond versioned index names and cleanup on unallocatable index failures
-
2. issues文档
04 Apr, 2026
2 commits
-
Exact Match High Relevant Low Relevant Irrelevant to Fully Relevant Mostly Relevant Weakly Relevant Irrelevant
03 Apr, 2026
2 commits
02 Apr, 2026
4 commits
-
目前在54训练数据里面，拆分44条train + 10 test，训练集显著提升但是test上不及基线 作为基础设施保留，以后可以考虑扩大数据集进行使用
01 Apr, 2026
18 commits
-
Irrelevant
-
都会合并成数组，和 qanchors / enriched_tags 的处理方式保持一致，更符合你现在这套 ES mapping 的灌入方式。ES 的 text 字段本身支持数组，所以像 value.zh: ["舒适", "无鞋带设计"] 这种写法是可以正常入库的；nested 只是外层对象数组，不影响内部语言字段存数组。
-
现在的行为（按你的路径） 用途 路径（相对仓库根 PROJECT_ROOT） 评估主日志（CLI + framework 的 INFO） logs/eval.log LLM 全量 prompt / 原始响应 logs/verbose/eval_verbose.log 实现要点： constants.py：EVAL_LOG_DIR、EVAL_VERBOSE_LOG_DIR、EVAL_LOG_FILE、EVAL_VERBOSE_LOG_FILE。 logging_setup.py：setup_eval_logging() 给名为 search_eval 的 logger 挂 文件 + stderr，只初始化一次；build_annotation_set.py / serve_eval_web.py 走的 eval_framework.cli.main() 开头会先调用。 cli.py：原来的 print 改为 search_eval.cli 的 logging.info；启动时写一条 CLI start command=... log_file=... 到 logs/eval.log。 framework.py：rebuild 相关 print 改为 search_eval.framework 的 logging.info。 clients.py：verbose 改为写入 logs/verbose/eval_verbose.log；首次需要时调用 setup_eval_logging()，并用 search_eval.info 提示 verbose 文件路径（不再用 print）。
-
scripts/evaluation/eval_framework/constants.py：500 → 200 Rebuild 里 rank <= recall_n 的 rerank_score: 1.0 仍按该 K 生效。 2. LLM 批次上下限 最少批次：DEFAULT_REBUILD_MIN_LLM_BATCHES 20 → 10 最多批次：仍为 40（未改） 3. 提前结束条件（_annotate_rebuild_batches） 在已跑满 min_batches 之后，对每个批次： 本批无 Exact（exact_n == 0），且满足其一即视为 bad batch： irrelevant_ratio >= 0.94 或 (irrelevant + Low Relevant) / n >= 0.96（弱相关用 RELEVANCE_LOW） 连续 2 个 bad batch 则 early stop（原先是连续 3 次、irrelevant > 0.92）。 批次日志里增加了 low_ratio、irrelevant_plus_low_ratio；rebuild 元数据里增加了 rebuild_irrel_low_combined_stop_ratio。 4. CLI --search-recall-top-k 说明改为默认 200 --rebuild-min-batches 说明改为默认 10 --rebuild-irrelevant-stop-ratio / --rebuild-irrelevant-stop-streak 说明与新逻辑一致 新增 --rebuild-irrel-low-combined-stop-ratio（默认 0.96）
-
`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`。 - 写缓存时也统一写成归一化后的内部结构，并且空内容不再写入缓存。
31 Mar, 2026
8 commits