EADST

从“能搜到”到“能生产提效、能评审、能自我进化”

Search 从来不是一个向量接口，而是一个长期演进的生产系统。

---

引言：为什么大多数 Search System 一到生产就失效？

在很多系统中，Search System 的设计往往止步于三件事：

• 结构化过滤
• 向量召回
• 加权排序

在 demo 或小规模使用时，它们看起来已经“够用”。 但一旦 Search 被真正接入生产流程——作为参考库、作为提效工具、甚至作为评审官的一部分——问题会迅速暴露：

• 用户或调用方的表达天然不稳定，意图经常被误解
• 单一语义向量召回，无法区分“动作像”“风格像”“结构合理”
• 排序结果高度同质化，同源内容刷屏
• 检索结果不可解释、不可复现、不可追责
• 系统无法从“哪些结果真的帮到了下游”中学习

真正的问题不是“召回不准”，而是 Search 没被当成一个“可治理系统”来设计。

---

Search 的角色转变：从工具函数到生产基础设施

当 Search 开始承担以下职责时，设计范式必须升级：

• 为生成模型提供高质量参考样例
• 为生产流程提供稳定、可控的素材来源
• 为 benchmark / 评审系统提供可解释、可复现的证据
• 为系统长期演进提供反馈与学习信号

这意味着： Search System不再只是“返回一个 list”，而是一个从查询理解 → 多路召回 → 策略排序 → 可解释输出 → 反馈学习的完整闭环。

---

核心原则：一个成熟 Search System的 7 个“必须”

1. 先理解，再检索（Query Understanding）

大量检索失败并不是算法问题，而是输入表达不稳定。

一个成熟的 Search API，必须承担“翻译官”的角色：

• 识别用户真正想找的是：

• 动作相似？

• 风格相似？
• 场景/构图相似？
• 还是已经验证过的高分通路样例？
• 把自然语言拆解为结构化、可控的检索条件
• 在调用方没说清楚时，替他做合理默认

关键不是“猜对”，而是让这次“猜测”是可见、可回溯的。

---

2. 多路召回，而不是“一个向量打天下”

在真实系统中，“语义相似”往往并不是最重要的相似性。

以视频/动作类内容为例，至少需要并行考虑：

• 文本-视频语义相似
• 标签与元数据的硬约束
• 动作与运动模式的相似性
• 同一舞蹈 / 同一音乐 / 同一结构的关联召回
• 已被验证有效的高分参考样例

多路召回的价值不在于“更多”，而在于“来源可解释”。

---

3. Query-by-example：用内容本身发起搜索

在生产环境中，最常见的需求并不是：

“我用一句话描述我想要的东西”

而是：

“我已经有一个视频 / 一帧 / 一个生成结果，帮我找类似的”

因此，搜索系统需要支持：

• 用视频搜视频
• 用图片/关键帧搜视频
• 与文本条件组合使用

这是 Search 真正进入生产流程的关键一步。

---

4. 去重与多样性：让结果“可用”，而不只是“相关”

排序再强，如果结果是：

• 同一舞蹈的不同搬运版本
• 同一场景、同一机位的密集重复
• 同一创作者、同一服装刷屏

对生成和创作来说都是噪声。

成熟的 Search 系统必须主动管理多样性：

• 识别近重复内容并分组
• 控制每一类来源的曝光上限
• 按不同“检索意图”分桶返回结果

---

5. 可解释性：Search 结果必须“能被相信”

当 Search 结果会被用于：

• 人工选择参考
• 模型评审与打分
• benchmark 对比

系统必须回答一个问题：

“为什么是它？”

因此，解释性不应是调试功能，而应是 API 的一等公民。

---

6. 可观测与可回放：一次检索必须能复现

如果一次检索结果无法在未来被重放，那么：

• 线上问题无法定位
• benchmark 结果无法对齐
• 排序策略无法评估

Search 必须像训练数据一样，被版本化、记录、可回放。

---

7. 反馈闭环：Search 也要“从结果中学习”

Search 的终极问题不是“这次排得好不好”，而是：

“哪些结果，真的帮助下游成功了？”

当下游（生成模型、用户、评审系统）能回传结果使用情况时， Search 才真正拥有了自我优化的能力。

---

从 API 到 Agent：Search 的下一步

当系统足够复杂，仅靠规则已经无法覆盖所有情况时，引入 Agent 是自然演进：

• Query Agent：将自然语言转为结构化检索计划，并显式说明假设
• Retrieval Orchestrator Agent：动态分配多路召回预算，处理降级与异常
• Judge / Eval Agent：为结果生成解释，并参与 benchmark 闭环
• Feedback Agent：把下游成功归因到检索与排序策略，驱动系统迭代

Search 不再是“被动响应请求”，而是一个能理解、能判断、能学习的系统组件。

---

结语：Search 是生产系统，而不是 Demo

当 Search 开始影响模型质量、生产效率和评审结论时， 它的设计目标就不该是“跑得通”，而是：

可解释、可复现、可治理、可进化。

这正是一套真正成熟收缩系统的分水岭。