dfb45131
 tangwang
issues文档整理
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
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](/data/saas-search/docs/issues/issue-2026-04-16-bayes寻参-TODO.md:24)。这次我没有做补丁式方案，而是把它统一成“多 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](/data/saas-search/config/config.yaml:48)、[config/schema.py](/data/saas-search/config/schema.py:410)、[config/loader.py](/data/saas-search/config/loader.py:304) 和新加的 [datasets.py](/data/saas-search/scripts/evaluation/eval_framework/datasets.py:1)。现在 `search_evaluation.datasets` 里正式注册了 `core_queries` 和 `clothing_top771`，CLI / store / framework / Web API / 前端都改成以 `dataset_id` 为主轴了，关键实现分别在 [cli.py](/data/saas-search/scripts/evaluation/eval_framework/cli.py:1)、[store.py](/data/saas-search/scripts/evaluation/eval_framework/store.py:1)、[framework.py](/data/saas-search/scripts/evaluation/eval_framework/framework.py:1)、[web_app.py](/data/saas-search/scripts/evaluation/eval_framework/web_app.py:1)、[index.html](/data/saas-search/scripts/evaluation/eval_framework/static/index.html:1)、[eval_web.js](/data/saas-search/scripts/evaluation/eval_framework/static/eval_web.js:1)。调参入口也已经带上 `--dataset-id`，在 [tune_fusion.py](/data/saas-search/scripts/evaluation/tune_fusion.py:1) 和几个启动脚本里都打通了；文档同步写到了 [scripts/evaluation/README.md](/data/saas-search/scripts/evaluation/README.md:1) 和 [issue-2026-04-16-bayes寻参-TODO.md](/data/saas-search/docs/issues/issue-2026-04-16-bayes寻参-TODO.md:35)。
验证这边我跑过一轮编译检查，另外新增了 [tests/test_search_evaluation_datasets.py](/data/saas-search/tests/test_search_evaluation_datasets.py:1)，`./.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](/data/saas-search/logs/eval.log:1) 跟主进度，看 [logs/verbose/eval_verbose.log](/data/saas-search/logs/verbose/eval_verbose.log:1) 跟完整 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](/data/saas-search/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](/data/saas-search/scripts/evaluation/start_eval.sh) 新增 `batch-rebuild-resume` 入口，统一用 dataset 模式，`REPO_EVAL_QUERIES` 仅作可选覆盖。
- 在 [scripts/start_eval_web.sh](/data/saas-search/scripts/start_eval_web.sh) 做同样的 dataset/queries 统一化。
- 在 [scripts/evaluation/README.md](/data/saas-search/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`）
如果你要自己盯进度，直接看：
```bash
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
```
|