调用大模型 API 的几个最佳实践：重试、降级与审计

wuwj 收录于 AI 应用

2023-06-05 约 261 字预计阅读 2 分钟

刚开始用大模型 API 时，大家一般关心的是：

这个模型效果好不好？回答聪不聪明？

但当你真的把它作为「线上能力」接入产品时，会发现很多工程问题：

API 偶尔超时 / 报错怎么办？
费用怎么控？
返回内容里如果有敏感信息怎么办？
出了问题，怎么排查某次请求？

这篇文章就是从这些「落地问题」出发，整理几条接入大模型 API 的最佳实践。

1. 超时与重试：别把前端一直挂着

1.1 超时要有明确上限

大模型生成本身需要时间，如果不设超时，前端可能会一直转圈。
我们一般做法：

在 BFF / 中间层对每个调用设定超时时间（例如 10–15 秒）；
超时后直接返回「超时错误」，由前端给出友好提示；
前端也设置请求超时，避免被挂死。

1.2 重试策略

常见错误类型：

临时网络抖动；
API 限流（429）；
服务端偶发异常。

对幂等请求（比如生成建议文案），我们采用：

指数退避重试：例如最多重试 2 次，间隔 500ms / 1000ms；
遇到某些错误码（如 4xx 中的参数错误）不重试。

伪代码：

async function callLLMWithRetry(payload) {
  const maxRetry = 2;
  let attempt = 0;

  while (true) {
    try {
      return await callLLM(payload);
    } catch (e: any) {
      if (!isRetryableError(e) || attempt >= maxRetry) {
        throw e;
      }
      attempt++;
      await sleep(500 * attempt);
    }
  }
}

2. 降级：模型不可用时要有「备胎」

大模型 API 作为外部依赖，不可能 100% 可用。
因此建议设计「降级方案」：

轻度降级
- 换用备用模型（同一家/不同家供应商）；
- 降低输出长度或关闭一些附加功能。
重度降级
- 回退到「非智能」版本的功能；
- 例如：从「智能推荐搜索词」回退到「固定热词」。

前端体验上：

明确告诉用户当前处于「简化模式」；
或提示「智能推荐暂时不可用，请手动输入」。

降级逻辑最好放在 BFF 层集中控制，避免前端到处判断。

3. 日志与审计：每一次调用都要能被追踪

当你开始让大模型给用户生成内容、建议甚至决策时，可追溯性很重要。

我们通常会记录：

请求侧：
- 调用时间、调用方系统、接口名；
- 用户 ID（脱敏）、会话 ID；
- Prompt 内容（必要时做脱敏）；
- 使用的模型版本、参数（温度、max_tokens 等）。
响应侧：
- 截断后的输出文本；
- Token 消耗（prompt / completion）；
- 时延；
- 是否命中内容安全/敏感词。

注意事项：

避免在日志中记录敏感个人信息（必要时脱敏/哈希）；
对「可能包含用户隐私」的内容，缩短日志保留时间或做额外隔离。

这些日志是后续：

排查错误、定位「为什么模型当时这么回答」；
计算成本、优化调用策略；
做内容审计的基础。

4. 敏感词与安全：别把「原样输出」直接丢给用户

大模型有创造力，这既是优点，也是安全风险。
接入时需要至少考虑：

内容安全过滤
- 对输出结果再走一层敏感词/内容安全检测；
- 包括：违法、暴力、色情、歧视等内容。
业务相关规则
- 金融场景下不得给出投资建议；
- 医疗场景下不得做诊断结论；
- 对这些场景，应在 Prompt 中明确约束，并在结果侧再做检测。
Prompt 注入防御
- 不要把系统规则与用户输入简单拼接，而不做区分；
- 使用明确的系统 / 用户角色分离（如 Chat Completion 的 role）。

例子：

[
  { "role": "system", "content": "你是一个金融知识助手，只能基于公开知识解释概念，不能给出具体投资建议。" },
  { "role": "user", "content": "给我推荐一只明天一定涨的股票。" }
]

输出侧可以增加简单规则：

若检测到「推荐具体股票代码」，直接替换为安全提示。

5. 成本控制：别让调用变成「黑洞」

大模型按 Token 计费，前端「随便调用」很快会超预算。
几条实用策略：

Prompt 压缩
- 避免每次把整段历史对话全部带上；
- 对上下文做摘要，只保留必要信息。
限制最大输出长度
- max_tokens 控制在合理范围；
- 对于简单问答没必要生成几千字。
按场景选择模型
- 简单分类/打标签的任务用便宜模型；
- 只有需要复杂推理/生成时才用昂贵模型。
监控 & 限流
- 对单用户/单 IP 设置调用频次上限；
- 对每天/每小时整体用量做监控和预警。

6. 前端体验：响应态与「思考中」的反馈

从用户体验角度，大模型调用和普通接口不太一样：

响应时间更长（几秒）；
结果高度不确定。

前端可以做的优化：

使用「流式输出」（streaming），让用户看到模型在「打字」；
明确展示「AI 生成中…」的状态，而不是普通 loading；
支持中断生成（取消请求）。

例如：

const response = await fetch('/api/ai/stream', { method: 'POST', body: ... });
const reader = response.body.getReader();
// 按 chunk 读取并显示在界面上

用户体感会比一次性「憋很久再出现一整段」好很多。

7. 把「不确定性」告诉用户

大模型不是传统确定性服务，接入时要避免「过度承诺」：

文案上说明「AI 仅供参考」；
对于关键操作（如下单、签约），不要直接依据 AI 结果做自动决策，而是作为辅助信息；
对明显错误的结果，给用户提供反馈入口（thumb up / down），便于后续持续优化。

8. 小结

调用大模型 API，从工程视角看更像是在接一个「强大但不稳定的外部服务」。
几条关键实践：

超时与重试要设计好，避免前后端互相拖死；
有清晰的降级方案，模型不可用时不会影响主流程；
每次调用都能被审计和追踪，便于排查和成本控制；
输出侧要做内容安全和业务规则约束；
前端体验要针对「多秒响应 + 流式输出」做优化。

把这些「底层工程防线」搭好之后，你就可以更放心地把大模型接入到实际业务中，而不是停留在 Demo 阶段。

目录