人人都会AI编程

16.2 生成性能优化

更新时间：2026-07-12

在整个 RAG 链路中，生成环节往往是最耗时的部分——一次 LLM 调用动辄数百毫秒到数秒。当用户期望即时回答，或系统需要支撑高并发请求时，生成性能直接影响体验和成本。这部分内容聚焦于不牺牲答案质量前提下的实用优化手段。

16.2.1 流式输出：让用户“先看到先安心”

生成性能优化的第一原则不是缩短总时长，而是降低用户的感知等待时间。流式输出（streaming）是实现这一目标最直接的方法。模型每生成若干个 token 立刻返回给前端，用户可以看到回答逐字、逐句出现，而不是面对一个凝固的等待界面。

  • 配置方式：绝大多数 LLM API 都提供 stream=True 选项，只需在调用时开启，前端同步改为接收分片事件即可。
  • 实际效果：某内部系统在上线前后对比发现，虽然回答总耗时（TTFT + 生成时间）基本不变，但用户自发反馈“快了很多”。这是因为第一个 token 出现的时间（TTFT，Time To First Token）大幅提前，从 3-4 秒缩短到 1 秒以内。

注意事项：流式输出下，溯源引用的格式化（如 【来源：xxx】）可能被拆散在多个片段中。需要前端做缓冲和拼接，或在提示词中把引用标记放在靠前位置，使其尽早输出，方便前端识别处理。

16.2.2 提示词精简：少即是快

送给 LLM 的提示词越长，编码和推理的计算量越大。检索环节召回的内容往往有冗余，直接把多个长片段塞进提示词，不仅拉高延迟，还可能让模型分心。

可以采取以下策略控制上下文长度：

  1. 设置检索片段数量上限：根据经验，top‑3 到 top‑5 个高质量片段通常足够回答大多数问题，不必贪多。
  2. 对召回片段二次精简：在拼接前，只保留每个片段中与问题最相关的句子。可以用简单的关键词匹配，或调用轻量级模型做句级相关性判断。
  3. 压缩历史对话：在多轮对话场景中，历史消息会持续占用 token 配额。可以做摘要压缩，或者只保留最近 N 轮问答，避免上下文无限膨胀。
  4. 去掉非必要装饰：提示词里过多的礼节性语句、重复的格式说明，只会增加 token 数。保持指令干练、明确。

一个实例：某客服系统原提示词包含近 500 字的详细角色设定和回答规范，优化后缩减到 120 字，仅保留关键格式要求与禁止行为，每次生成耗时平均下降约 30%，且回答质量没有明显退化。

16.2.3 选择合适模型：并非越大越好

许多场景下，中等规模甚至小参数的模型就足以完成基于检索内容回答的任务。盲目使用最昂贵的超大模型只会平添延迟和成本。

  • 分级路由：根据问题复杂度做分流。简单的事实查询（如“xx 产品的价格”）使用小模型（7B-13B 级别，或轻量级商业模型）；复杂推理或多步总结才调用大模型。可以在入口处用分类器或规则进行分流。
  • 领域微调的小模型：如果业务领域窄，用合格数据微调一个小模型，配合 RAG 检索，效果可能不输通用大模型，且生成速度大幅提升。
  • 私有化部署优化：如果使用开源模型，可借助 vLLM、TensorRT-LLM 等推理加速框架，实现连续批处理、量化、KV 缓存等优化，吞吐和延迟都比默认部署有数量级提升。

真实取舍：某医疗问答系统从 GPT-4 降级到 GPT-4o-mini 后，回答延时缩短了 60%，而由于答案严格基于检索资料，专家评审的准确率仅微降 1.2 个百分点，性价比极高。

16.2.4 语义缓存：避免重复计算

在实际业务中，大量用户的提问高度相似。比如“怎么重置密码”“年假有几天”这类问题，每天会被问上百次。为每次调用 LLM 产生完全相同或近似答案，是巨大的算力浪费。

可以引入语义缓存层：

  1. 将用户问题向量化后，在专门的缓存向量库中搜索相似历史问题。
  2. 如果相似度超过阈值（如 0.95），直接返回对应的已生成答案，无需再次调用 LLM。
  3. 缓存库会随知识库更新而做失效处理，保证答案的时效性。

实施建议：阈值可以设置得稍保守（0.98 以上），先在小范围验证，避免因为过度宽泛匹配导致错误缓存。该方案在高频 FAQ 场景可减少 40%-70% 的 LLM 调用，既省钱又加速。

16.2.5 生成参数调优

调整 LLM 的推理参数也能带来可观的性能回报，而不需要改变模型或架构。

  • 降低 max_tokens：根据实际答案长度设置合理的截断上限。如果绝大多数回复在 200 字以内，就不要给模型 1000 token 的额度，减少生成长尾。
  • 适当提高 temperature：在严格事实性任务上，通常使用较低的温度（0-0.3）以保证确定性；但要注意，过低温度有时会导致模型反复输出同一短语，反而增加生成长度。通过实验找到平衡点。
  • 使用 stop 序列：当答案到达某个自然结束点（如特定标点组合），主动停止生成，避免模型“多嘴”拖长回复。

16.2.6 异步与并行处理

如果一次用户提问需要生成多段回答（如拆解成多个子问题并行回答），或需要同时产生带引文和不带引文的两个版本，可以利用 LLM 可并发调用的特性。

  • 将多个独立生成任务用异步请求同时发出，总耗时约等于最慢那个调用的时间，而非各个调用之和。
  • 在前端可先展示一个无需引用的简洁答案（更快生成完成），同时后台拼接待引用回答作为补充信息，渐进式展示。

小结：生成性能优化是一个组合策略，没有单一银弹。实践中通常从流式输出和提示词精简开始立竿见影，再逐步加入模型分级、缓存、参数调优等长效手段。核心思路始终是：用最小的计算开销，换取最及时的准确回答，让 RAG 系统在响应速度上真正达到生产级可用标准。