ai-saas / saas-search

issue-2026-04-16-bayes寻参-数据集扩增-clothing_top771.md 6.58 KB

Prompt - 1

参考当前的评估框架 @scripts/evaluation/README.md @scripts/evaluation/eval_framework/framework.py @start_eval.sh.sh 当前，是基于54个评测样本（queries.txt），建立了自动化评估的系统，便于发现策略在这个评估集上的效果。

我需要扩大评估样本，使用all_keywords.txt.top1w.shuf.top1k.clothing_filtered（771条）为query集合，走标注流程，从而新建一个标注集。 那么以后eval-web服务，现在的Batch Evaluation按钮，应该支持多个评估集合，左侧的History，也有对应多个评估集合的评估结果，请你考虑如何支持、如何设计。请进行统一的设计，不要补丁式的支持。

Response - 1

设计已经整理并写回到 issue-2026-04-16-bayes寻参-TODO.md。这次我没有做补丁式方案，而是把它统一成“多 dataset registry 模式”：dataset_id 成为一等主键，eval-web 的 Queries / Batch Evaluation / History / 调参脚本都围绕当前 dataset 工作，历史产物按 dataset 隔离，并且每次 batch/build 都固化一份 dataset snapshot，避免以后 query 文件变更导致历史失真。

这份设计里最关键的取舍是：评估集和标签缓存分层。relevance_labels / rerank_scores 继续按 (tenant_id, query, spu_id) 共享复用，不按 dataset 重复标注；真正带 dataset_id 的是 build_runs、batch_runs、artifact 目录、Web API 和前端上下文。文档里也补了配置结构、API 设计、UI 交互、迁移方案，以及调参链路如何接入 --dataset-id。另外我顺手核对了当前文件规模：queries.txt 现在仓库里是 53 条非空 query，all_keywords.txt.top1w.shuf.top1k.clothing_filtered 是 771 条。

如果你要我继续落地实现，我建议下一步先做 3 件事：dataset registry + artifact path helper、batch_runs/build_runs 存储升级、/api/datasets 与 History 按 dataset 过滤。此次没有跑测试，因为目前是文档设计更新，没有改功能代码。

prompt - 2

请推进、完成这些事项、并且把llm标注跑起来

response - 2

多评估集这套已经落地到代码里了，核心改动在 config/config.yaml、config/schema.py、config/loader.py 和新加的 datasets.py。现在 search_evaluation.datasets 里正式注册了 core_queries 和 clothing_top771，CLI / store / framework / Web API / 前端都改成以 dataset_id 为主轴了，关键实现分别在 cli.py、store.py、framework.py、web_app.py、index.html、eval_web.js。调参入口也已经带上 --dataset-id，在 tune_fusion.py 和几个启动脚本里都打通了；文档同步写到了 scripts/evaluation/README.md 和 issue-2026-04-16-bayes寻参-TODO.md。

验证这边我跑过一轮编译检查，另外新增了 tests/test_search_evaluation_datasets.py，./.venv/bin/pytest -q tests/test_search_evaluation_datasets.py 结果是 2 passed。eval-web 代码已经按新模型重启过一次并健康通过，但在当前机器资源占用下它后来没有稳定驻留，我没把这个问题硬掩过去；如果你要立刻看 UI，我建议等这轮大标注稳定后再单独 ./scripts/service_ctl.sh restart eval-web 复位。

LLM 标注已经跑起来了，目标 dataset 是 clothing_top771。我先手动拉起了 reranker 并确认 http://127.0.0.1:6007/health 返回 {"status":"ok"...}，然后启动了 rebuild build。当前进度已经进入第 1 个 query 白色oversized T-shirt 的 LLM 批量标注阶段，最新日志大约推进到 llm_batch=24/40。你现在可以直接看 logs/eval.log 跟主进度，看 logs/verbose/eval_verbose.log 跟完整 LLM I/O。唯一要注意的是：这轮 build 依赖我手动拉起的 reranker，因为当前 search.rerank.enabled=false，service_ctl 会跳过它。

prompt - 3

“LLM 标注已经跑起来了，目标 dataset 是 clothing_top771。” 好像进程在第 48 条 build上停了 "query 雪纺衬衫 —— 正好是 query 文件里 第 47 行。

response - 3

当前不是卡死，已经越过你说的第 48 条。clothing_top771 的 query_builds 现在是 54，正在跑第 55/771（barbie backpack），第 47/48（雪纺衬衫 / convertible zip-off hiking pants）都已被识别为已完成并跳过续跑。

我把这次流程做成了可持续的“统一续跑”能力，避免再靠临时脚本：

  • 在 scripts/evaluation/eval_framework/cli.py 新增 build --resume-missing --continue-on-error --max-retries-per-query --retry-backoff-sec，并修正默认参数逻辑（有 dataset_id 时不再强塞 legacy queries_file）。
  • 在 scripts/evaluation/start_eval.sh 新增 batch-rebuild-resume 入口，统一用 dataset 模式，REPO_EVAL_QUERIES 仅作可选覆盖。
  • 在 scripts/start_eval_web.sh 做同样的 dataset/queries 统一化。
  • 在 scripts/evaluation/README.md 补了中断续跑说明和新命令。
  • 已验证 eval-web 多数据集接口正常（/api/datasets、/api/history?dataset_id=... 均返回 core_queries 与 clothing_top771 分域结果）。

当前在线进程：

  • LLM 标注：PID 2062901（build ... --dataset-id clothing_top771 --resume-missing ...）
  • reranker：PID 2065235（6007，/health 返回 ok）

如果你要自己盯进度，直接看：

tail -f logs/eval.log
ls -1 artifacts/search_evaluation/datasets/clothing_top771/query_builds | wc -l
curl -sS http://127.0.0.1:6007/health