你让模型答一个问题，它给了答案却附不上一句「这话出自哪」，上线后用户不信、审核也过不了。这篇不评谁家模型强，只帮你把「带来源引用的联网问答接口」这件事拆成可执行动作：先分清引用是模型生成的还是检索层给的，再按场景筛接口，最后补上超时、降级和日志。价格和限速这类会变的数字，都指到站内对应页面自己核。
你让模型答一个问题，它给了答案却附不上一句「这话出自哪」，上线后用户不信、审核也过不了。所以这篇不评谁家模型强，只帮你把「带来源引用的联网问答接口」拆成可执行动作：先分清引用是模型生成的还是检索层给的，再按场景筛接口，最后补上超时、降级和日志。
需要先说清楚一件事：会变的数字——单价、限速、额度、返回条数上限——一律不在这里写死，你到 /official-api 和 /price-watch 核对当时的数字就行。这篇文章只给判断标准和动作顺序，落地时按你自己的场景替换参数。
先分清「引用」是从哪来的
同样是「返回来源引用」，接口背后的实现差别很大，直接决定你前端能不能展示、审核能不能过。拿到一个接口文档别急着写代码，先判断它属于下面哪一类。
- 检索层给引用
- 接口在返回正文之外还带回 URL、标题、抓取时间，可信度最高，前端也好做展示
- 模型层编引用
- 模型自己写出一段看起来像出处的话，接之前一定要用固定几条问题试出它到底带不带真实链接
- 混合型
- 接口既给候选文档又给总结，要看引用编号是否真的能对上返回的文档列表
- 拿同一个问题问三次，看三次返回的链接是否稳定、是否同一条能打开
- 把答案里提到的关键事实逐条去链接里找，看内容对不对得上，而不是只看有没有链接
- 检查引用编号和文档数组的下标是否一一对应，错位是最常见的坑
- 换个冷门问题再测一遍，热门问题谁都能蒙对，冷门问题才看得出检索层有没有真干活
按你的场景筛接口，别按名气筛
选接口最容易犯的错是看谁家名气大。正确的顺序是先写清楚你的任务属于哪一类，再拿类别去对照接口能力，最后才看价格。下面这张表可以先帮你把需求定位清楚。
| 任务类型 | 优先看什么能力 | 可以妥协的地方 |
|---|---|---|
| 时效敏感（新闻、行情、政策） | 抓取频率、是否支持指定时间范围 | 答案的文风、长度 |
| 领域可信（医疗、法律、金融） | 能否限定站点或白名单来源 | 响应速度可以稍慢 |
| 开发者自用查资料 | 接口是否简单、文档是否清楚 | 引用格式是否美观 |
| 创意类（写作、头脑风暴） | 基本不需要引用能力 | 不必为引用多花钱 |
- 时效敏感型：抓取频率和是否支持指定时间范围是硬指标，价格再低、库不新也没用
- 领域可信型：能不能限定站点或白名单来源，比答案花哨重要得多
- 开发者自用型：只是给内部工具查资料，很多官方接口之外的中转站也提供同款能力，先到 /sites 看目录再逐个测
- 不适用情况：纯创意写作、头脑风暴这类本来就没有标准答案的任务，不必为引用能力多花钱
还有一类容易被忽略的边界：如果你的用户只是偶尔问一句「今天有什么新闻」，而你的产品本身不是资讯类，那用带引用的联网接口可能属于过度设计，先跑通普通问答再回来加也可以。
接入时的接口契约与降级顺序
定好接口之后，真正决定线上稳不稳的是契约和降级。契约是你要在请求侧确认的能力，降级是失败之后按什么顺序退。这两件事写清楚，后面出问题才好定位。
- 确认请求侧三件事能不能传时间范围、能不能传站点白名单、回答里的引用编号是否和文档数组一一对应。文档里没写的，拿测试请求实打实验一次。
- 超时按段设检索段通常比生成段慢，连接超时和整体超时要分开配，别用一个值兜住全部，否则检索慢一点就把整个请求掐死。
- 写显式降级链带引用接口失败先退到普通问答，再退到不带联网的模型，最后返回缓存答案并标记「非实时」，顺序写进配置而不是散落在代码里。
- 把引用当必查字段每次调用都检查是否真的返回了引用，没引用就记一笔，不要静默当成功，否则问题会拖到用户投诉才暴露。
日志与评测：让引用质量可复盘
引用质量不会自己变好，得靠日志和小规模回归把它变成可看的数字。日志字段先定下来，评测集合不用大，二三十条固定问题足够暴露接口切换带来的波动。
- 每次调用至少记：用了哪个接口、是否命中缓存、返回引用条数、引用链接可打开率、耗时、是否为降级结果
- 用一个二三十条固定问题的小集合做回归，换接口或换版本后重跑，只看「引用条数」和「链接可核对比例」两个指标
- 引用打不开、指向首页、内容对不上答案，这三类要单独归类统计，它们对应的往往不是模型问题而是检索质量问题
- 数字类结论（单价、限速、额度）别写进代码注释里，改到 /official-api 和 /price-watch 现查现用
如果你的产品有多个入口都在调联网问答，建议把上面这套日志字段统一到一份公共封装里，别让每个入口各记各的，否则对比接口时口径都对不上。
下一步把你现在候选的接口列出来，到 /sites 看中转站目录，再用固定问题集跑一轮，重点看引用条数和链接可核对比例这两个指标。→常见问题
接口返回了引用链接，就说明它真的联网查过吗？
不一定。有的接口是检索后再生成，链接是检索层给的；有的只是模型按记忆写出一段像出处的话。验证办法很简单：拿一条最近几天才出现的问题去问，看它能不能给出能打开、内容也对得上的链接。给不出就别把「联网」当成能力承诺写进产品说明。
自己用 RAG 加一个普通问答接口，和直接用带引用的联网接口，怎么选？
看你的资料在哪。答案只依赖你私有文档，就走自己的 RAG，引用由你自己的检索结果给，可控性最高；答案依赖公开实时信息，直接用带引用的联网接口省事，但要接受来源不可控。两者也能叠：先联网取料，再拿你库里的资料做二次校验。RAG 侧的落地思路可以对照 rag-retrieval 那篇。
接多个带引用接口会不会更稳？
并发和成本都会上去，收益主要体现在「单一来源挂掉时有备胎」。务实做法是主接口加一个备接口，按显式顺序降级，而不是并行全问一遍。数量一多，日志里要能一眼看出这次答案是哪家给的，不然出了问题根本没法复盘。
