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

把检索做成可评测的:召回、排序与答案三段分开测

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

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

答案错时先问片段够不够,别把生成的问题算在检索头上。

「检索效果不好」要拆成三段来测

把检索链路当成一个整体去评,只会得到一句"不好用"。拆成三段,问题立刻具体:

1. 召回:该找到的文档,进没进候选集?

2. 排序:进来的文档,排到前面了吗?

3. 答案:拿到这些片段,回答对不对、有没有引用?

三段的责任人、指标和修法都不同。混在一起测,往往会把"排序问题"误当成"模型问题",白换模型。

第一段:召回

· 构造 30~50 个问题,人工标注每题的"应命中片段"(哪一段是真正能回答它的);

· 指标:召回率@K(K 取 10~50,看候选集够不够);

· 召回低通常是切分/解析问题(见"文档解析与切分"那篇),不是向量模型问题;

· 排查顺序:先看该片段是否存在 → 是否存在但没进候选(切分/索引)→ 是否进了但排太后(排序)。

第二段:排序

· 指标:MRR 或 命中位次(第一条正确片段平均排在第几);

· 对比改动时只改一个因子(加时效、加权威、去重、多样性重排);

· 常见现象:召回不错但第一条永远是"最像但不是最有用"的那段 → 这是排序信号不足,而不是召回问题。

第三段:答案

· 指标:正确率 + 引用率(答案里给出的片段是否真的支撑结论)+ 编造率;

· 关键:答案错时先问"给它的片段够不够"——片段不足导致的错,不该记在生成头上;

· 要求模型给出引用来源,并做引用一致性检查(引用内容与结论是否相关)。

三段分开测之后能得到什么

· 定位清楚(是切分、排序还是生成);

· 改动可归因(每段有自己的指标与前后的对照);

· 预算花得准(哪一段最需要投入一目了然)。

一个最小落地流程

1. 30 个问题 + 每题标注应命中片段(半天能做完);

2. 跑基线:召回@20、MRR、答案正确率/引用率/编造率;

3. 挑最差的一段,只改一个因子,复跑同一批问题;

4. 记录改动与三段指标变化(包括没变好的地方);

5. 把这三段指标接进流水线,改动即回归。

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

相关文章

顺序阅读

← 上一篇:上线前的红队检查:AI 功能该测哪些「坏输入」
下一篇:提示词里的示例怎么给:少而准 vs 多而全 →

第 31 / 171 篇

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

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