01
AI 批量归因 bad case
让模型辅助判断问题出在 Query 理解、供给缺口、排序错误、Top1 不准还是答案不可信。
Case File 07搜索质量2016.12 - 2020.05字节跳动 · 搜索业务
搜索满足度评估与问答式搜索探索
在没有大模型叙事的时候，先回答一个朴素问题：用户搜完到底解决了吗？
我的判断
搜索质量不是结果多不多，而是用户有没有少走弯路。很多时候，第一条结果就决定了这次搜索是不是成立。
Search SatisfactionQuery IntentEvaluation StandardDirect AnswerSemantic SearchTop1 命中Result Quality
开场判断
这个项目要解决的，不是搜索结果看起来多丰富。
这个项目不是今天意义上的大模型搜索项目。当时没有现在的大模型叙事，也做过 BERT 等模型探索，但收益并不总是靠模型名解决。
真正要回答的问题很朴素：用户搜完以后，到底有没有少走弯路，问题有没有被解决。
所以我把搜索满足拆成 Query 意图、内容供给、排序结果、Top1 命中和问答式结果，让搜索质量从“有结果”变成“有满足”。
问答式结果 Top1 精准命中覆盖 10%+ 搜索需求，这个数字说明有一部分需求适合直接答案，但不代表所有搜索都应该问答化。
这个项目留下来的，不是一个 AI 概念，而是一套搜索满足度评估、bad case 归因和答案命中判断口径。
搜索质量与问答式搜索 · One Page
搜索不是给一堆结果，而是让用户少走弯路。
这个项目不要硬讲成今天的大模型项目。当时更真实的问题是： 用户搜完以后，到底有没有解决问题。我的重点不是证明某个模型很先进， 而是先定义什么叫搜索满足，再把它转成内容引入、结果评估、排序调优和问答式结果命中的策略动作。
01
不是 AI 项目
当时还没有大模型搜索叙事。更真实的问题是：用户搜完以后，到底有没有少走弯路。
02
模型不是万能解
当时有过语义模型探索，但收益有限。很多 bad case 最后还是回到意图、供给和评估标准。
03
Top1 决定体验
搜索不像推荐可以慢慢纠偏。很多时候，第一条结果就决定这次搜索是不是成立。
核心口径
搜索满足度四问：意图、供给、Top1、答案
用户在找什么？
Query 是找事实、教程、视频、事件，还是在问一个可以被直接回答的问题。
供给够好吗？
没有好内容，排序很难救；有好内容但标准不清，也很难稳定优化。
Top1 命中了吗？
不是结果列表看起来相关就够了，要看第一条是否真正解决用户问题。
要不要直接回答？
只有适合直接回答的需求，才应该追求问答式结果、答案可信和可验证。
主线 A
供给标准 × 结果评估 × 排序调优视频搜索质量
- 定义哪些视频内容适合进入搜索供给
- 建立相关性、可消费性、质量稳定性和时效口径
- 用横向对照和人工评估校准搜索体验
- 联动算法调优候选、排序和结果准确性
主线 B
可回答需求 × Top1 命中 × 答案可信问答式搜索探索
- 识别适合直接回答的搜索需求
- 把 Top1 精准命中作为核心体验目标，而不是只看列表整体相关性
- 评估答案是否准确、完整、可信、可验证
- 用覆盖范围判断问答式结果对搜索满足度的增量
策略链路
从 Query 到少走弯路的质量链路
1
Query 分型
→
2
供给补齐
→
3
评估标准
→
4
排序调优
→
5
Top1 命中
→
6
答案承接
结果与沉淀
行业第一
多端视频搜索体验
10%+
问答式结果覆盖用户搜索需求
达到目标水平
综合搜索结果准确性
我的重点：不是证明某个模型很先进，而是先定义什么叫满足， 再让模型、供给、排序和问答式结果一起服务这个目标。
AI 时代怎么做
如果今天重做，我会把它做成搜索满足度与答案质量评估工具。
今天可以接到 LLM 评估、RAG 和答案质量判断，但前提仍然是先定义什么叫“搜完被满足”。
02
人定义满足标准
哪些搜索需要直接答案，哪些需要视频结果，哪些需要多结果比较，这个边界不能只靠模型自动决定。
03
沉淀答案评估工具
把搜索满足度、Top1 命中、答案可信度和 RAG 证据链做成评估工作流，服务搜索策略迭代。
AI 在这里不是把搜索包装成问答，而是帮助更稳定地判断用户有没有真的被满足。