d172c259
 tangwang
eval框架
|
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
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
|
参考资料：
1. 搜索接口：
```bash
export BASE_URL="${BASE_URL:-http://localhost:6002}"
export TENANT_ID="${TENANT_ID:-163}" # 改成你的租户ID
```
```bash
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":" ...
...
2. 重排服务：
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
}'
3. 基于指定字段查询：es_debug_search.py
主要任务：
1. 评估工具的建立：
注意判断结果好坏，要用统一的评估工具，不要对每个query设定关键词匹配的规则来判断是否符合要求，这样不可扩展，这种方式且容易有误判还是复杂，并且不好扩展到其他搜索词。
因此要做一个搜索结果评估工具、多个结果对比的工具，供后面的标注集合构建工具调用。工具内部实现可以是调用大模型来判断，说清楚什么叫高相关、基本相关、不相关：
prompt:
```bash
你是一个电商搜索结果相关性评估助手。请根据用户查询（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 个商品。不要输出任何其他任何信息
```
2. 测试集（结果标注）建立：
@queries/queries.txt
对其中每一个query：
1. 召回：
1）参考搜索接口 召回结果。搜索结果的top500，纳入召回池，打分全部标记为1
2）调用重排模型，扫描全库（tenant_id=163），如果已经在召回池（打分已经是1了），则跳过，其余的全部过reranker模型接口调用。每80个doc做一次请求。注意重排模型打分一定要做缓存（本地文件缓存即可。query+title->rerank_score）。
3）对reranker打分超过0.5的结果数大于1000条的query，则打印一行日志，跳过这个query，表示相关结果太多、容易被满足
2. 对如上召回的内容，进行全排序，然后逐批进行llm评判标注（50个一批），每一批都记录exact比例和不相关比例，打印日志。
直到连续三批不相关比例都大于92%。
最少要跑15批，最多跑40批
3. 请你思考如何存储结果、并利于以后的对比、使用、展示。
3. 评估工具页面：
请你设计一个搜索评估交互页面。端口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，填入左侧列表框，点击其中任何一个发起搜索。
4. 批量评估工具
给一个批量执行脚本，
这里要新增一个批量评估的页面。点击批量评估的按钮，对所有搜索词依次发起搜索，最后汇总总体的评估指标，生成报告，报告名称带上时间标记和一些关键信息。并且记录当时的主搜索程序的config.yaml。
你需要精心地设计如何切换两种模式，通过同一个端口承载这两种不同交互的内容。
批量评估关注的是所有搜索词总体的评估指标。
需要记录测试环境时间以及当时的配置文件，以及对应的结果。要保存历次的评估记录，并能查到每一次评估结果对应的配置文件有相关的指标
以上是我的总体设计，但有不周全的地方。你要站在更高的层次理解我的需求，你有足够的自由可以适当调整设计，基于你所了解的自动化搜索评估框架的最佳实践，做出更优秀的设计和更好的实现。
1. 请仔细检验这个标注集的质量，如果质量不符合要求，那么你要优化工具，迭代直至标注集的结果质量足够高，可以以此为自动化工具来评估检索效果，对检索效果形成指导性意见。
2. 在结果标注集的质量足够好，批量评估工具足够好用，并且经过你的试用，能判断出搜索质量好坏的情况下，开始真正的动手检索效果调优：基于这个50条query的结果标注集和批量评估工具，对融合公式进行调参。请你先精心地设计实验，设计几组参数，对几组参数分别修改config.yaml、重启（./restart.sh backend）、跑批量评估、收集结果。
注意评估的过程中，如果发现工具不好用，发现日志不全，发现可以通过修改工具或者日志来提高效率，都可以先做这些，根据完善。
注意你是代码的总负责人，你有任何权限来满足你进行检索效果调优的需要。你如果发现有其他可能带来更大提升的点，也可以进行实验，你甚至可以修改融合、重排漏斗的代码，来进行实验，以追求更好的结果指标。
但是注意，因为收到性能和耗时的约束，不要调大reranker模型的输入条数、不要打开精排，耗时方面无法承受两轮reranker模型的调用。
@scripts/evaluation/README.md @scripts/evaluation/eval_framework/framework.py
@quick_start_eval.sh (29-35)
请以如下流程为准，进行改造：
如果重建的话，对每个query：
每个搜索结果应该会扫描全库，
1. 搜索结果的top500，纳入召回池，打分全部标记为1
2. 调用重排模型，扫描全库（tenant_id=163），如果已经在召回池（打分已经是1了），则跳过，其余的全部过
3. 对reranker打分超过0.5的大于1000条，则打印一行日志，跳过这个query，表示相关结果太多、容易被满足
对如上召回的内容，进行全排序，然后逐批进行llm评判标注（50个一批），每一批都记录exact比例和不相关比例，打印日志。
直到连续三批不相关比例都大于92%。
最少要跑15批，最多跑40批
|