选型指南 架构设计 含可复制代码

把检索质量接到业务指标:从答案质量到业务结果

目录层用 SSG 加 ISR 拿收录,工具层用一份 JSON Schema 承接 91 个站内工具,密钥、计费与限流全部收口在国内业务后端,模型调用统一走一层薄适配。这篇把我们真实的目录结构、Schema 字段定义、路由闸门、预扣结算伪代码和合规清单完整摊开。

陈
陈默架构组
2026-09-28 · 14 分钟阅读 · 8,432 次浏览

说不出「召回提升 X 点对应业务变化 Y」,就无法证明投入价值。

检索做得好,业务就一定会好吗

不一定 ✔。检索质量是中间指标 ✔,业务结果是最终指标 ✔,两者之间隔着一层:

用户是否采纳、是否因此少打了一个电话、是否更快解决问题 ✔。

把中间指标接到业务指标 ✔,才能回答"这套投入值不值" ✔。

一、先画一条链(四层)

```

① 检索层:召回率、命中位次、片段质量 ✔

② 答案层:正确率、引用一致率、该拒答却作答率 ✔

③ 使用层:采纳率、修改率、追问率、转人工率 ✔

④ 业务层:处理时长、一次解决率、成本/单、满意度 ✔

```

每层都要有指标 ✗→✔:只测第 ① 层,无法判断投入价值 ✔;

只测第 ④ 层,出了问题无法归因 ✔。

二、四层之间的"假设"要写下来

例如 ✔:

```

假设:召回率提升 10 个点 → 答案正确率提升 5 个点

→ 采纳率提升 3 个点 → 平均处理时长下降 8%

```

写下来才能验证 ✔(见对照实验那篇 ✔);不写下来,就只能在汇报时"感觉有提升" ✗。

三、怎么验证(别只看相关性)

· 逐层看变化(召回涨了但答案没涨 → 说明瓶颈不在检索 ✔);

· 做小规模对照(A/B 或前后对比,含区间 ✔);

· 看"采纳率"这类使用层指标(它比满意度更客观 ✔);

· 业务层要有基线(改之前先量一遍 ✔ —— 否则无法比较 ✔)。

四、两个常见误判

· 过度优化中间指标 ✗(召回从 85% 提到 92%,但用户感知没变 ✔)→ 该停下来 ✔;

· 只看业务指标 ✗(业务波动受很多因素影响,无法归因到检索 ✔)。

平衡点:中间指标做日常优化向导 ✔,业务指标做季度价值判断 ✔。

五、一个务实起点

```

① 先把"采纳率"量出来(用户是否用了 AI 给的结果 ✔)—— 最容易也最有说服力

② 再把"处理时长"或"一次解决率"量出来(业务基线 ✔)

③ 然后才有资格说"检索优化带来的价值" ✔

```

一条判据

> 你能否说出"召回率提升 X 个点,对应业务指标变化 Y" ✔?

> 说不出,说明指标链还没打通 ✗(投入价值无法证明 ✔)。

本文由云枢 AI导航整理,内容以官方来源为准。

相关文章

顺序阅读

← 上一篇:把模型输出接进报表:结构化数据的流转
下一篇:AI 项目的团队分工:谁负责提示词、谁负责评测 →

第 133 / 171 篇

术语速查 · 本页出现的 12 个词展开看中文名与一句话解释,点术语看完整条目
  • token词元:模型处理文本的最小单位,中文约 1–2 个汉字;计费与上下文长度都按它算。
  • 转写 / 字幕Transcription:把音视频人声逐句变成带时间戳的文字稿,便于做字幕与章节切分。
  • SSE服务器发送事件:服务器通过长连接持续推送增量文本,是对白逐字出现的常见实现。
  • API应用编程接口:程序之间约定的调用方式;站内工具由服务端调用,浏览器里不出现密钥。
  • CDN内容分发网络:把静态资源缓存到离用户更近的节点,缩短加载时间。
  • 缓存Cache:把结果暂存复用,复用得越多平均耗时越低;需要约定过期与刷新策略。
  • 限流Rate Limit:限制单位时间内的请求次数,防止单用户或异常流量打满服务端。
  • SSG静态站点生成:构建阶段就生成 HTML,访问时直接返回,不必每次请求都渲染。
  • ISR增量静态再生:先返回静态页,再在后台按需重新生成,兼顾速度与更新时效。
  • 灰度发布Canary Release:先让一小部分用户用新版本,确认无误再放量,出问题的爆炸半径最小。
  • 提示词Prompt:交给模型的指令文本;写清角色、任务、输入与输出格式比反复试更省。
  • 积分Credits:站内计费单位:按工具单价预扣,调用失败自动退还;单价以定价页为准。

完整解释与站内出现处见 AI 术语表(40 条)。