怎么证明 agentic search 比普通 search 好？
先弄清楚：每个概念是什么
- Baseline
- 同一个 retrieval 系统放在普通 search 界面后面，只返回结果列表，不生成答案，也不多步搜索。
- Ablation
- 一次只改一样东西。只加“生成答案”，只加“多步”，分别看各自带来多少增量。
- Slice
- 按 query 类型分组看结果。平均数会把差异盖住，因为 agent 的优势集中在某几类 query 上。
- Guardrail metric
- 不能变差的指标，比如 latency、cost、错误回答率。它破了，主指标涨了也不能上线。
- A/B test
- 线上把用户随机分成两组，分别用新版和旧版，比较行为指标。
30 秒回答
I'd hold the retrieval system fixed and compare the two interfaces, so the difference is the agent, not the index. Offline, I'd run both on the same queries, sliced by type: simple lookup, multi-hop, aggregate, and unanswerable. I expect the agent to win on multi-hop and aggregate, tie on simple lookups, and risk losing on unanswerable ones by making things up. I'd report task success together with latency and cost. Online, I'd run an A/B test on reformulation rate, with guardrails on latency and wrong answers. If it only wins on some slices, I'd route only those to the agent.
按 slice 看
| Slice | 预期 | 重点看 |
|---|---|---|
| Simple lookup | 持平 | latency 和 cost 不能明显变差 |
| Multi-hop | agent 赢 | task success、per-hop recall |
| Aggregate、temporal | agent 赢 | 答案正确率 |
| Unanswerable | 风险最大 | 错误回答率、abstention rate |
公平比较：同一个 index、同一批 query、配对检验（见 offline eval）。一个返回结果列表，一个返回答案，原生指标不同，所以统一成 task success。普通 search 的 gold 文档在前 k 条里就算成功，agent 要答案正确并且有依据。再加一个用户成本指标，比如拿到答案前的操作步数。
必答点
- 固定 retrieval，只换界面，差异才能归因到 agent
- 按 slice 看，不只看平均
- 质量和 latency、cost 一起报
- unanswerable 是 agent 最容易输的地方
- 只在赢的 slice 上用 agent：router 分流
追问
agent 在哪里没有价值？质量更好但慢很多、贵很多，怎么办？
一次检索就能答的问题，多步只增加 latency 和出错机会。所以不做全量替换，用 router 只把多跳和聚合类送给 agent。router 自己也要评，看分错的代价。
online 看什么指标？
主指标：reformulation rate、放弃率、是否还要点开原始结果。guardrail：p95 latency、用户举报的错误回答。
A/B 刚上线时新版指标很好，过两周回落，为什么？
这是 novelty effect，用户对新界面好奇，多用了几次。实验要跑到指标稳定再看。
来源PracHub：Design an Agentic Search Experience（题面要求说明 agent 在哪里有价值、哪里用确定性 search 就够）· Apple JD 200670397