07 Apr, 2026
1 commit
-
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
13 commits
-
Made-with: Cursor