issue-2026-03-31-评估框架-done-0331.md 7.23 KB
Edit Raw Blame History


参考资料：


搜索接口：

export BASE_URL="${BASE_URL:-http://localhost:6002}"
export TENANT_ID="${TENANT_ID:-163}"   # 改成你的租户ID

curl -sS "$BASE_URL/search/" \
  -H "Content-Type: application/json" \
  -H "X-Tenant-ID: $TENANT_ID" \
  -d '{
    "query": "芭比娃娃",
    "size": 20,
    "from": 0,
    "language": "zh"
  }'


response：
{
  "results": [
    {
      "spu_id": "12345",
      "title": "芭比时尚娃娃",
      "image_url": "https://example.com/image.jpg",
      "specifications":[],
      "skus":[{"sku_id":" ...
...


重排服务：
curl -X POST "http://localhost:6007/rerank" \
-H "Content-Type: application/json" \
-d '{
"query": "玩具 芭比",
"docs": ["12PCS 6 Types of Dolls with Bottles", "纯棉T恤 短袖"],
"top_n":386,
"normalize": true
}'
基于指定字段查询：es_debug_search.py


主要任务：


评估工具的建立：
注意判断结果好坏，要用统一的评估工具，不要对每个query设定关键词匹配的规则来判断是否符合要求，这样不可扩展，这种方式且容易有误判还是复杂，并且不好扩展到其他搜索词。
因此要做一个搜索结果评估工具、多个结果对比的工具，供后面的标注集合构建工具调用。工具内部实现可以是调用大模型来判断，说清楚什么叫高相关、基本相关、不相关：


prompt:
你是一个电商搜索结果相关性评估助手。请根据用户查询（query）和每个商品的信息，输出该商品的相关性等级。

## 相关性等级标准
Exact 完全相关 — 完全匹配用户搜索需求。
Partial 部分相关 — 主意图满足（同品类或相近用途，基本上符合搜索意图），但次要属性（如颜色、风格、尺码等）跟用户需求有偏差或无法确认。
Irrelevant 不相关 — 品类或用途不符，主诉求未满足。

1. {title1} {option1_value1} {option2_value1} {option3_value1}
2. {title2} {option1_value2} {option2_value2}, {option3_value2}
...
50. {title50} {option1_value50} {option2_value50} {option3_value50}

## 输出格式
严格输出 {input_nums} 行，每行仅Exact / Partial / Irrelevant三者之一。按顺序对应上述 50 个商品。不要输出任何其他任何信息


测试集（结果标注）建立：
@queries/queries.txt


对其中每一个query：


召回：
1）参考搜索接口 召回结果。搜索结果的top500，纳入召回池，打分全部标记为1
2）调用重排模型，扫描全库（tenant_id=163），如果已经在召回池（打分已经是1了），则跳过，其余的全部过reranker模型接口调用。每80个doc做一次请求。注意重排模型打分一定要做缓存（本地文件缓存即可。query+title->rerank_score）。
3）对reranker打分超过0.5的结果数大于1000条的query，则打印一行日志，跳过这个query，表示相关结果太多、容易被满足
对如上召回的内容，进行全排序，然后逐批进行llm评判标注（50个一批），每一批都记录exact比例和不相关比例，打印日志。
直到连续三批不相关比例都大于92%。
最少要跑15批，最多跑40批
请你思考如何存储结果、并利于以后的对比、使用、展示。
评估工具页面：
请你设计一个搜索评估交互页面。端口6010。
页面主题：上方是搜索框，如果发起搜索，那么下方给出本次结果的总体指标以及top100结果（允许翻页）


总体指标：
| 指标 | 含义 |
|------|------|
| P@5, P@10, P@20, P@50 | 前 K 个结果中「仅 3 相关」的精确率 |
| P@5_2_3 ～ P@50_2_3 | 前 K 个结果中「2 和 3 都算相关」的精确率 |
| MAP_3 | 仅 3 相关时的 Average Precision（单 query） |
| MAP_2_3 | 2 和 3 都相关时的 Average Precision |

结果列表：
按行列下来，每行左侧给每个结果找到标注值（三个等级。对结果也可以颜色标记），展示图片,title.en+title.en+首个sku的option1/2/3_value（分三行展示，这三行和左侧的图片并列）

评测页面最左侧：
queries默认是queries/queries.txt，填入左侧列表框，点击其中任何一个发起搜索。


批量评估工具


给一个批量执行脚本，

这里要新增一个批量评估的页面。点击批量评估的按钮，对所有搜索词依次发起搜索，最后汇总总体的评估指标，生成报告，报告名称带上时间标记和一些关键信息。并且记录当时的主搜索程序的config.yaml。
你需要精心地设计如何切换两种模式，通过同一个端口承载这两种不同交互的内容。
批量评估关注的是所有搜索词总体的评估指标。
需要记录测试环境时间以及当时的配置文件，以及对应的结果。要保存历次的评估记录，并能查到每一次评估结果对应的配置文件有相关的指标

以上是我的总体设计，但有不周全的地方。你要站在更高的层次理解我的需求，你有足够的自由可以适当调整设计，基于你所了解的自动化搜索评估框架的最佳实践，做出更优秀的设计和更好的实现。


请仔细检验这个标注集的质量，如果质量不符合要求，那么你要优化工具，迭代直至标注集的结果质量足够高，可以以此为自动化工具来评估检索效果，对检索效果形成指导性意见。
在结果标注集的质量足够好，批量评估工具足够好用，并且经过你的试用，能判断出搜索质量好坏的情况下，开始真正的动手检索效果调优：基于这个50条query的结果标注集和批量评估工具，对融合公式进行调参。请你先精心地设计实验，设计几组参数，对几组参数分别修改config.yaml、重启（./restart.sh backend）、跑批量评估、收集结果。
注意评估的过程中，如果发现工具不好用，发现日志不全，发现可以通过修改工具或者日志来提高效率，都可以先做这些，根据完善。
注意你是代码的总负责人，你有任何权限来满足你进行检索效果调优的需要。你如果发现有其他可能带来更大提升的点，也可以进行实验，你甚至可以修改融合、重排漏斗的代码，来进行实验，以追求更好的结果指标。
但是注意，因为收到性能和耗时的约束，不要调大reranker模型的输入条数、不要打开精排，耗时方面无法承受两轮reranker模型的调用。


@scripts/evaluation/README.md @scripts/evaluation/eval_framework/framework.py 
@start_eval.sh.sh (29-35) 
请以如下流程为准，进行改造：
如果重建的话，对每个query：
每个搜索结果应该会扫描全库，


搜索结果的top500，纳入召回池，打分全部标记为1
调用重排模型，扫描全库（tenant_id=163），如果已经在召回池（打分已经是1了），则跳过，其余的全部过
对reranker打分超过0.5的大于1000条，则打印一行日志，跳过这个query，表示相关结果太多、容易被满足


对如上召回的内容，进行全排序，然后逐批进行llm评判标注（50个一批），每一批都记录exact比例和不相关比例，打印日志。
直到连续三批不相关比例都大于92%。
最少要跑15批，最多跑40批