一、先说结论：大模型系统优化，不只是“让模型回答更好”

很多人一提到大模型优化，第一反应是：

“Prompt 优化一下？”
“换个更强的模型？”
“加个 RAG？”
“微调一下？”

这些当然重要，但真正到了企业项目上线阶段，最关键的往往不是“能不能回答”，而是：

高并发来了能不能扛住？
模型接口慢了能不能保护系统？
下游服务挂了会不会拖垮全链路？
用户还能不能拿到一个可接受的兜底结果？

大模型项目的工程化优化，核心可以分成四层：

第一层：大模型效果优化
让回答更准、更稳定、更符合业务。

第二层：大模型性能优化
让响应更快、成本更低、吞吐更高。

第三层：并发治理与熔断限流
防止瞬时流量把模型服务、网关、数据库、向量库打爆。

第四层：容灾降级与兜底恢复
即使模型超时、第三方接口失败、RAG 不可用，也能给用户一个可接受的结果。

这篇文章就按真实项目落地思路，把大模型优化、并发熔断、容灾降级一次讲透。

---

二、大模型项目为什么比普通后端项目更容易出问题？

普通 Java 后端接口一般是：

用户请求 → Controller → Service → DB / Redis / MQ → 返回结果

但大模型项目一般是：

用户请求 → 鉴权 → 意图识别 → Prompt 组装 → RAG 检索 → 重排序 → 大模型推理 → 工具调用 → 结果后处理 → 日志追踪 → 返回结果

链路更长，依赖更多，变量更多。

尤其大模型调用有几个天然问题：

1. 大模型响应时间不稳定

普通接口可能几十毫秒、几百毫秒。

但大模型接口经常是：

• 简单问题：1～3 秒
• 复杂问题：5～15 秒
• 长文本生成：几十秒
• 模型繁忙时：直接超时

所以大模型系统必须做：

• 超时控制
• 异步处理
• 流式返回
• 限流排队
• 熔断降级

2. 大模型成本高

普通接口调用一次成本可以忽略不计。

但大模型调用可能涉及：

• Token 消耗
• 模型推理资源
• GPU 成本
• 第三方 API 费用
• 向量库检索成本
• 重排序模型成本

所以系统不能无脑调用大模型。

必须做：

• Prompt 压缩
• 缓存
• 意图分流
• 小模型优先
• FAQ 优先
• RAG 优先
• 大模型兜底

3. 大模型容易拖垮下游系统

比如用户突然批量提问，系统可能同时打爆：

• 大模型服务
• 向量数据库
• Redis
• MySQL
• ES
• 工具调用服务
• 日志 MQ
• 回调接口

因此大模型项目一定要有：

• 限流
• 熔断
• 隔离
• 降级
• 超时
• 重试
• 监控告警

这类设计在云架构里也属于经典可靠性模式，比如限流、重试、熔断、舱壁隔离等都是云服务设计中常见的可靠性模式。微软云架构中心也把 Rate Limiting、Retry、Circuit Breaker、Bulkhead 等列为云设计模式。

---

三、大模型优化第一步：先做“请求分流”，不是所有请求都丢给大模型

很多系统上线初期最大的问题是：

所有问题都直接请求大模型。

这会导致：

• 成本高
• 响应慢
• 并发低
• 结果不稳定
• 简单问题也占用模型资源

正确做法是：先分流，再决定走哪条链路。

1. 第一类：简单 FAQ 请求

比如：

“怎么修改密码？”
“报销流程是什么？”
“这个按钮在哪里？”
“发票怎么开？”

这类问题不需要大模型深度推理。

可以直接走：

用户问题 → FAQ 匹配 → 返回标准答案

优点是：

• 快
• 稳
• 成本低
• 可控
• 不容易胡说

2. 第二类：知识库问答请求

比如：

“根据公司制度，年假怎么计算？”
“这份合同里面付款周期是什么？”
“产品 A 和产品 B 的区别是什么？”

这类问题适合走 RAG：

用户问题 → 向量检索 → 关键词检索 → 重排序 → 拼接上下文 → 大模型回答

也就是说，大模型不是凭空回答，而是基于检索出来的资料回答。

3. 第三类：工具调用请求

比如：

“帮我查一下订单状态。”
“帮我生成一份周报。”
“帮我查询客户最近三个月的消费记录。”

这类请求需要调用业务系统接口。

链路是：

用户问题 → 意图识别 → 参数抽取 → 工具调用 → 大模型总结 → 返回结果

4. 第四类：复杂推理请求

比如：

“帮我分析这份销售数据，给出问题和改进方案。”
“根据这几份文档，生成一份项目复盘。”
“帮我设计一个营销活动方案。”

这类问题才真正需要大模型充分发挥能力。

---

四、大模型优化第二步：Prompt 优化，别让模型“又慢又贵又不稳定”

Prompt 是大模型系统里最容易被忽视、但收益很高的优化点。

1. Prompt 要有固定结构

不要每次随便拼一句话给模型。

建议使用固定模板：

你是一个专业的业务助手。

你的任务：
根据用户问题和参考资料，生成准确、清晰、可执行的回答。

回答要求：
1. 只能基于参考资料回答。
2. 如果资料不足，要明确说明“当前资料不足”。
3. 不要编造不存在的信息。
4. 输出结构要清晰。

用户问题：
{question}

参考资料：
{context}

这样做的好处是：

• 模型角色稳定
• 输出格式稳定
• 降低幻觉
• 方便后续解析
• 方便评测

2. Prompt 要控制长度

很多系统为了“保险”，把一大堆上下文全塞给模型。

结果是：

• Token 变多
• 成本变高
• 响应变慢
• 模型抓不到重点
• 重要信息被淹没

正确做法是：

• 只放 Top K 相关片段
• 先重排序再拼接
• 去掉重复内容
• 去掉无关字段
• 对长文档先摘要
• 对历史对话做压缩

3. Prompt 要区分系统指令和业务内容

比如：

系统指令负责告诉模型“怎么回答”。

业务内容负责告诉模型“根据什么回答”。

不要把所有东西混在一起。

更推荐分层：

System：你是一个严谨的企业知识库问答助手。
Developer：回答必须基于资料，不允许编造。
User：用户真实问题。
Context：检索出来的资料。

4. Prompt 要做版本管理

Prompt 不是随便改的。

企业项目里应该把 Prompt 当作配置管理：

• Prompt 编号
• Prompt 版本
• 生效时间
• 适用场景
• 修改人
• 回滚记录
• 效果评测结果

否则上线后很容易出现：

“昨天还好好的，今天回答怎么变差了？”

---

五、大模型优化第三步：RAG 优化，别让模型拿着错误资料回答

RAG 的核心不是“接个向量库”这么简单。

真正要优化的是：

检索准不准、召回全不全、排序对不对、上下文干不干净。

1. 文档切分要合理

切太小：

• 信息不完整
• 模型看不懂上下文

切太大：

• 噪音太多
• Token 浪费
• 召回不精准

一般可以按：

• 标题
• 段落
• 章节
• 表格
• 业务语义

进行切分。

比如制度文档可以按“章节 + 条款”切分。

产品说明可以按“功能模块”切分。

合同可以按“付款、交付、验收、违约责任”切分。

2. 检索不要只靠向量

很多人做 RAG，只用向量检索。

但向量检索有个问题：

它擅长语义相似，不一定擅长精确匹配。

比如：

• 产品编号
• 合同编号
• 人名
• 公司名
• 日期
• 金额
• 专有名词

这些更适合关键词检索。

所以推荐使用混合检索：

向量检索 + 关键词检索 + 规则过滤 + 重排序

3. 要加重排序

第一阶段检索出来的结果，不一定最适合直接给大模型。

可以加一个 rerank 模型或者规则排序：

• 问题和片段相关度
• 文档更新时间
• 文档权威等级
• 命中的关键词数量
• 用户权限
• 业务优先级

最终只把最相关的内容给大模型。

4. 要做权限过滤

企业知识库不能所有人看所有内容。

RAG 检索必须加权限：

• 用户部门
• 用户角色
• 数据范围
• 文档密级
• 项目权限
• 租户隔离

正确链路应该是：

用户问题
→ 获取用户权限
→ 检索候选文档
→ 权限过滤
→ 重排序
→ 拼接 Prompt
→ 大模型回答

而不是先让模型看完所有内容再让它“不要泄露”。

---

六、大模型性能优化：让系统更快、更省、更稳

1. 使用流式返回

大模型生成长文本时，如果等全部生成完再返回，用户体验会很差。

建议用流式返回：

模型边生成 → 前端边展示

用户看到文字不断出来，会觉得系统很快。

即使总耗时一样，体验也完全不同。

2. 使用缓存

大模型系统缓存非常重要。

可以分几类：

1）问题级缓存

用户问同样的问题，直接返回上次结果。

适合：

• FAQ
• 固定政策
• 标准流程
• 常见问答

2）检索缓存

相同问题或相似问题，可以复用检索结果。

比如：

“年假怎么计算？”
“公司年假规则是什么？”

检索结果可能差不多。

3）Prompt 结果缓存

完整 Prompt 一样时，可以直接复用模型结果。

4）Embedding 缓存

文档向量化成本也不低。

文档没变时，不要重复生成向量。

5）前缀缓存

很多大模型请求都有固定前缀，比如系统提示词、工具说明、知识库说明。推理框架可以复用这些相同前缀的计算结果，从而提升吞吐和降低延迟。vLLM 等推理框架就支持面向大模型服务的高吞吐、内存优化、前缀缓存等能力。

3. 控制输出长度

很多系统没有限制输出长度，用户问一句话，模型输出几千字。

这会导致：

• 慢
• 贵
• 占资源
• 并发下降

可以设置：

• 最大输出 Token
• 不同场景不同长度
• 简单问题简短回答
• 报告类任务允许长输出
• 超长任务异步生成

4. 小模型优先，大模型兜底

不是所有场景都需要最强模型。

可以分层：

简单分类 → 小模型
意图识别 → 小模型
参数抽取 → 小模型
常规问答 → 中模型
复杂推理 → 大模型
高价值任务 → 最强模型

这样可以明显降低成本。

5. 批处理与队列削峰

如果是离线任务，比如：

• 批量生成报告
• 批量总结文档
• 批量生成标签
• 批量清洗数据

不要同步调用大模型。

可以走 MQ：

任务提交 → MQ → 消费者批量处理 → 结果入库 → 前端查询结果

好处是：

• 削峰填谷
• 失败可重试
• 任务可追踪
• 不影响在线接口

---

七、并发控制：大模型项目不能让请求无限进来

大模型系统最怕瞬时并发。

比如平时 100 QPS，突然活动推广来了 3000 QPS。

如果没有保护，结果就是：

• 模型服务打满
• 请求大量超时
• 线程池耗尽
• 网关连接堆积
• 数据库被拖垮
• 日志 MQ 堆积
• 整个系统雪崩

所以必须做并发控制。

1. 网关层限流

第一道防线在网关。

可以按：

• IP
• 用户 ID
• 租户 ID
• App ID
• 接口路径
• 模型类型
• Token 消耗
• 请求来源

进行限流。

比如：

普通用户：每分钟 20 次
企业用户：每分钟 200 次
内部系统：每分钟 1000 次
高成本模型：每分钟 10 次

2. 应用层限流

网关挡的是入口流量。

应用层要控制具体资源。

比如：

RAG 检索最大并发：100
模型调用最大并发：50
工具调用最大并发：80
文档解析最大并发：20

不同模块单独限流，防止互相影响。

3. 模型层限流

模型服务通常要控制：

• RPM：每分钟请求数
• TPM：每分钟 Token 数
• 并发请求数
• 最大上下文长度
• 最大输出长度

OpenAI 官方文档也建议在遇到限速错误时使用随机指数退避重试，避免请求失败后立刻密集重试，从而进一步放大流量压力。

4. 队列排队

如果请求不能立即处理，可以进入队列。

常见做法：

用户请求
→ 判断当前模型并发是否满
→ 未满：立即处理
→ 已满：进入等待队列
→ 超过等待时间：返回降级提示

适合：

• 文档总结
• 报告生成
• 视频脚本生成
• 数据分析
• 批量任务

5. 拒绝策略

系统必须敢于拒绝。

不要所有请求都硬扛。

常见拒绝策略：

当前系统繁忙，请稍后再试。
当前生成任务较多，已为你加入队列。
当前问题较复杂，建议缩短输入内容后重试。

比起系统直接崩溃，友好拒绝是更专业的做法。

---

八、熔断机制：当模型服务快挂了，要及时“断开”

熔断可以理解成家里的空气开关。

当电流过大时，空气开关会自动断电，防止烧坏电路。

系统里的熔断也是一样。

当某个服务持续失败或响应过慢时，系统不再继续请求它，而是直接走降级逻辑。

AWS 对熔断模式的说明中也提到，当服务调用失败或超时后，可以经过有限次数的指数退避重试；如果仍失败，则打开熔断器，让后续请求在熔断期间快速失败，避免持续冲击故障服务。

1. 熔断适合哪些地方？

大模型项目里可以对这些环节做熔断：

• 大模型接口
• 向量数据库
• Rerank 服务
• Embedding 服务
• 工具调用接口
• 第三方 API
• 文档解析服务
• 图片识别服务
• 语音识别服务
• 日志上报服务

2. 熔断的三个状态

1）关闭状态

服务正常，请求照常进入。

2）打开状态

服务异常，请求不再打过去，直接失败或降级。

3）半开状态

过一段时间后，放少量请求试探。

如果成功，恢复正常。

如果失败，继续熔断。

3. 熔断触发条件

可以按这些指标触发：

连续失败次数 > 10 次
错误率 > 50%
平均响应时间 > 5 秒
P99 响应时间 > 10 秒
超时率 > 30%
HTTP 5xx 数量过高
429 限流错误过高

4. 熔断后的处理方式

熔断不是简单报错。

要配合降级：

大模型熔断 → 返回缓存答案
RAG 熔断 → 走 FAQ
工具接口熔断 → 返回“当前数据暂不可查”
Rerank 熔断 → 使用粗排结果
Embedding 熔断 → 使用关键词检索
高级模型熔断 → 切换普通模型

---

九、超时控制：大模型系统一定要有“时间边界”

没有超时控制的系统非常危险。

假设一个模型请求卡住 60 秒。

如果并发 1000 个请求同时卡住，就会占满：

• Tomcat 线程
• Netty 连接
• 线程池
• 内存
• 数据库连接
• HTTP 连接池

最后整个服务不可用。

1. 每一层都要设置超时

建议：

网关超时：30 秒
应用接口超时：25 秒
RAG 检索超时：2 秒
Rerank 超时：1 秒
模型首 Token 超时：5 秒
模型总生成超时：20 秒
工具调用超时：3 秒
数据库查询超时：1 秒
Redis 查询超时：200 毫秒

2. 超时要分场景

不同场景不能用同一个超时。

比如：

在线问答：5～15 秒
复杂报告：异步任务
批量文档处理：后台任务
实时客服：3～5 秒
内部分析：可等待更久

3. 首 Token 超时很重要

流式输出场景下，用户最关心的是：

“什么时候开始出字？”

所以要重点监控：

首 Token 时间
总生成时间
平均生成速度
输出 Token 数

---

十、重试机制：不是所有失败都应该重试

重试是把双刃剑。

适当重试可以提升成功率。

但无脑重试会把系统压垮。

1. 哪些错误可以重试？

适合重试：

• 网络抖动
• 临时超时
• 连接重置
• 429 限流
• 503 服务暂不可用
• 短暂资源不足

不适合重试：

• 参数错误
• 鉴权失败
• 权限不足
• Prompt 超长
• 用户输入非法
• 业务规则不允许

2. 重试要加退避

不要失败后立刻重试。

推荐：

第一次失败：等待 200ms
第二次失败：等待 500ms
第三次失败：等待 1s
仍失败：进入降级

更好的方式是加随机抖动，避免所有请求同一时间再次冲击服务。

3. 重试次数要有限

一般在线接口最多重试 1～2 次。

批处理任务可以重试 3～5 次。

超过次数后进入：

• 失败队列
• 死信队列
• 人工处理
• 后台补偿

---

十一、隔离机制：不要让一个模块拖垮整个系统

隔离也叫舱壁模式。

就像轮船被分成多个舱室，一个舱进水，不会整艘船立刻沉。

Azure 的 Bulkhead Pattern 文档也强调，可以将服务或消费者隔离成不同舱壁，并与重试、熔断、限流等模式组合使用，提升故障处理能力。

1. 线程池隔离

不同任务用不同线程池。

比如：

FAQ 线程池
RAG 检索线程池
模型调用线程池
工具调用线程池
日志写入线程池
文档解析线程池

不要所有任务共用一个线程池。

否则文档解析慢了，可能把问答接口也拖死。

2. 连接池隔离

不同下游服务使用不同连接池。

比如：

模型服务连接池
向量库连接池
MySQL 连接池
Redis 连接池
第三方接口连接池

防止某个下游连接耗尽影响全局。

3. 租户隔离

企业项目里，经常有多个租户。

大客户不能被小客户拖垮。

可以按租户隔离：

租户级限流
租户级队列
租户级配额
租户级熔断
租户级资源池

4. 模型隔离

不同模型也要隔离。

比如：

普通模型池
高级模型池
Embedding 模型池
Rerank 模型池
图片模型池
语音模型池

不要让图片生成任务占满资源，导致文本问答不可用。

---

十二、容灾降级：系统出问题时，用户还能拿到什么？

容灾降级的核心思想是：

不是所有能力都必须同时可用，但核心链路必须尽量可用。

比如一个智能客服系统，最坏情况下可以不做复杂推理，但至少要返回：

“当前系统繁忙，已为你转人工 / 给你标准答复 / 请稍后重试。”

1. 大模型降级

如果高级模型不可用，可以降级到普通模型。

GPT-4 级别模型不可用
→ 切换到中等模型
→ 再不行切换小模型
→ 再不行返回缓存答案

项目中可以设计模型路由：

高级模型：复杂分析、长文生成
中模型：常规问答
小模型：分类、抽取、改写
规则引擎：兜底判断

2. RAG 降级

如果向量库不可用：

向量检索失败
→ 使用关键词检索
→ 使用 FAQ
→ 使用缓存答案
→ 返回资料暂不可用提示

如果 Rerank 服务不可用：

Rerank 失败
→ 使用原始召回结果
→ 降低 Top K
→ 直接按关键词得分排序

3. 工具调用降级

如果订单接口不可用：

很抱歉，当前订单系统暂时不可用，请稍后再试。

如果库存接口不可用：

当前库存信息暂不可查，建议以业务系统页面为准。

如果客户画像接口不可用：

当前无法获取客户最新画像，仅基于已有信息进行分析。

关键是：不要让模型胡编一个结果。

4. 日志系统降级

日志系统也可能出问题。

如果日志 MQ 堆积或日志平台异常，不能影响主链路。

正确做法：

业务请求正常返回
日志异步写入 MQ
MQ 异常时本地缓冲
缓冲满了采样丢弃低优先级日志
核心错误日志单独保留

不能因为日志写失败，导致用户请求失败。

5. 监控告警降级

监控系统也可能挂。

但核心业务不能依赖监控系统同步返回。

监控、日志、埋点、链路追踪都应该尽量异步化。

---

十三、真实大模型系统推荐架构

可以设计成下面这样：

用户请求
  ↓
API 网关
  ↓
鉴权 / 租户识别 / 用户权限
  ↓
限流 / 黑白名单 / 防刷
  ↓
意图识别
  ↓
任务路由
  ├── FAQ
  ├── RAG
  ├── Agent 工具调用
  ├── 文档生成
  └── 闲聊兜底
  ↓
上下文构建
  ↓
模型路由
  ├── 小模型
  ├── 中模型
  ├── 大模型
  └── 第三方模型
  ↓
熔断 / 超时 / 重试 / 降级
  ↓
流式返回
  ↓
日志埋点 / 链路追踪 / 指标上报
  ↓
Grafana / 告警平台 / 日志平台

这个架构里，每一层都要有保护机制。

---

十四、并发熔断在项目中怎么落地？

假设你做的是一个企业 AI 助手。

用户可能同时问：

• 制度问题
• 报销问题
• 合同问题
• 数据分析
• 生成周报
• 调用业务接口

你可以这样设计。

1. 接口层限流

按用户和租户限流：

单用户：每分钟最多 20 次
单租户：每分钟最多 1000 次
高成本接口：每分钟最多 50 次

2. 模型调用层限流

模型调用单独限流：

大模型最大并发：50
小模型最大并发：200
Embedding 最大并发：100
Rerank 最大并发：80

3. 超时控制

意图识别：1 秒
向量检索：2 秒
Rerank：1 秒
工具调用：3 秒
模型调用：15 秒
整体请求：25 秒

4. 熔断规则

模型接口 1 分钟内失败率超过 50% → 熔断 30 秒
向量库 P99 超过 3 秒 → 熔断 20 秒
工具接口连续失败 10 次 → 熔断 60 秒
Rerank 服务超时率超过 30% → 降级为普通排序

5. 降级策略

大模型不可用 → 切换备用模型
备用模型不可用 → 返回缓存答案
RAG 不可用 → 返回 FAQ
工具不可用 → 返回业务系统暂不可查
日志不可用 → 异步缓冲或采样丢弃

---

十五、项目容灾要做哪些关键预案？

1. 模型服务容灾

至少准备：

• 主模型
• 备用模型
• 小模型兜底
• 缓存兜底
• 规则兜底

例如：

主模型超时
→ 自动切换备用模型
→ 备用模型失败
→ 返回历史相似问题答案
→ 仍无结果
→ 返回友好提示

2. 向量库容灾

向量库不可用时：

• 切关键词检索
• 切 ES 检索
• 切 FAQ
• 切缓存
• 提示知识库暂不可用

3. MQ 容灾

如果日志或任务通过 MQ：

要考虑：

• MQ 堆积
• 消费失败
• 消费重复
• 死信队列
• 消费幂等
• 消费限速

比如日志链路：

业务埋点 → MQ → 日志消费服务 → 日志平台 → 查询分析

如果 MQ 堆积，不能影响主业务。

可以：

• 非核心日志采样
• 错误日志优先
• 消费者扩容
• 死信队列兜底
• 定时补偿消费

4. 数据库容灾

数据库要考虑：

• 慢查询
• 连接池耗尽
• 主从延迟
• 数据库不可用
• 大查询拖垮系统

措施：

• 查询超时
• 连接池隔离
• 读写分离
• 缓存热点数据
• 慢 SQL 监控
• 非核心数据异步写

5. 第三方接口容灾

第三方服务最不可控。

必须有：

• 超时
• 重试
• 熔断
• 降级
• 备用接口
• 本地缓存

---

十六、监控指标怎么设计？

大模型系统必须可观测。

否则线上出问题，你只会看到一句：

“AI 不好用了。”

但到底哪里不好用？

是模型慢？
向量库慢？
Rerank 慢？
Prompt 太长？
Token 太多？
工具接口挂了？
用户输入异常？
限流太严格？

没有监控就不知道。

1. 业务指标

总请求量
成功请求量
失败请求量
用户活跃数
租户请求量
问题类型分布
命中 FAQ 比例
命中 RAG 比例
工具调用比例
人工转接比例

2. 性能指标

平均响应时间
P95 响应时间
P99 响应时间
首 Token 时间
模型生成耗时
检索耗时
Rerank 耗时
工具调用耗时

3. 模型指标

输入 Token 数
输出 Token 数
总 Token 数
单次调用成本
模型调用成功率
模型调用失败率
模型超时率
模型限流次数

4. 稳定性指标

熔断次数
限流次数
降级次数
重试次数
超时次数
队列积压数
MQ 消费延迟
死信队列数量

5. 效果指标

用户点赞率
用户点踩率
回答采纳率
人工纠错率
幻觉率
无答案率
知识命中率
答案准确率

---

十七、日志和全链路追踪怎么结合？

大模型系统一定要把每次请求完整记录下来。

建议每次请求生成一个 TraceId。

链路如下：

用户请求 TraceId
→ 网关日志
→ 意图识别日志
→ RAG 检索日志
→ Prompt 构造日志
→ 模型调用日志
→ 工具调用日志
→ 返回结果日志
→ 用户反馈日志

每个节点记录：

TraceId
用户 ID
租户 ID
问题内容
命中的意图
检索文档 ID
Prompt 版本
模型名称
输入 Token
输出 Token
耗时
错误码
降级状态
最终答案

这样线上问题可以快速定位：

• 是哪个用户的问题？
• 走了哪个模型？
• 检索到了哪些文档？
• Prompt 是什么版本？
• 哪个节点超时？
• 有没有触发熔断？
• 有没有走降级？
• 最终回答是什么？

---

十八、一个完整的大模型降级案例

假设用户问：

“帮我总结一下公司最新的报销制度，并告诉我差旅报销有什么限制。”

正常链路：

用户问题
→ 意图识别：制度问答
→ RAG 检索：报销制度文档
→ Rerank：筛选最相关条款
→ Prompt 组装
→ 大模型生成答案
→ 返回结果

如果向量库超时：

向量检索失败
→ 切 ES 关键词检索
→ 找到报销制度相关文档
→ 大模型回答

如果 Rerank 超时：

Rerank 失败
→ 使用原始检索 Top 5
→ 大模型回答

如果大模型超时：

大模型超时
→ 切备用模型
→ 备用模型仍失败
→ 返回缓存中的报销制度摘要

如果所有能力都不可用：

返回：
当前制度问答服务繁忙，暂时无法生成完整总结。
你可以稍后重试，或前往制度中心查看《报销管理制度》。

这就是工程上的可靠性设计。

---

十九、常见错误做法

1. 所有请求直接调用大模型

结果：

• 成本高
• 响应慢
• 并发差
• 容易雪崩

2. 没有超时

结果：

• 请求堆积
• 线程池耗尽
• 系统卡死

3. 无脑重试

结果：

• 本来只是小故障
• 重试流量把系统彻底打爆

4. 没有降级

结果：

• 一个小模块挂了
• 整个 AI 助手不可用

5. 日志同步写

结果：

• 日志系统慢
• 主业务也慢

6. 没有指标

结果：

• 线上问题无法定位
• 只能靠用户反馈猜

---

二十、Java 项目中可以怎么实现？

1. 限流组件

可以用：

• Sentinel
• Resilience4j
• Guava RateLimiter
• Redis + Lua
• 网关限流
• Nginx 限流

2. 熔断组件

可以用：

• Sentinel
• Resilience4j
• Spring Cloud CircuitBreaker

3. MQ 削峰

可以用：

• RocketMQ
• Kafka
• RabbitMQ
• Pulsar

4. 监控体系

可以用：

• Prometheus
• Grafana
• SkyWalking
• OpenTelemetry
• ELK
• Loki
• 自建日志平台
• 公司内部指标告警系统

5. 链路追踪

可以记录：

TraceId
SpanId
ParentSpanId
ServiceName
MethodName
StartTime
EndTime
Status
ErrorMessage

最终形成树状调用链。

---

二十一、简历中怎么写才高级？

可以这样写：

负责大模型智能问答系统的稳定性建设，针对模型调用耗时高、并发波动大、第三方服务不稳定等问题，设计并落地限流、熔断、超时、重试、降级和隔离机制。

再具体一点：

1. 设计模型调用限流与熔断机制，按租户、用户、模型类型进行并发控制，避免高峰期请求打满模型服务。
2. 针对大模型响应慢、Token 消耗高的问题，优化 Prompt 模板、上下文裁剪、结果缓存和流式返回，提升用户响应体验。
3. 建立 RAG 降级链路，在向量检索或 Rerank 服务异常时，自动切换关键词检索、FAQ 或缓存答案，保障核心问答能力可用。
4. 引入超时控制与指数退避重试机制，针对模型接口、向量库、工具调用等下游依赖设置独立超时和失败恢复策略。
5. 接入日志平台、链路追踪和 Grafana 指标看板，监控模型调用耗时、Token 消耗、熔断次数、降级次数、接口成功率等核心指标。

更项目化一点：

在智能客服 / 企业知识库问答项目中，负责大模型服务稳定性治理。通过网关限流、模型并发控制、熔断降级、MQ 异步削峰、缓存兜底、链路追踪等方案，解决高并发场景下模型调用超时、RAG 检索不稳定、下游工具接口异常导致的系统雪崩问题，提升系统可用性和用户体验。

---

二十二、总结

大模型项目真正上线后，拼的不只是模型能力，而是工程能力。

一个成熟的大模型系统，必须同时具备：

效果优化能力
性能优化能力
并发治理能力
熔断保护能力
容灾降级能力
监控告警能力
链路追踪能力
问题复盘能力

简单说：

Prompt 优化解决“答得好不好”。
RAG 优化解决“有没有依据”。
缓存和流式返回解决“快不快”。
限流和熔断解决“扛不扛得住”。
容灾和降级解决“出问题还能不能用”。
日志和监控解决“问题能不能定位”。

真正的大模型工程化，不是写一个 Demo，而是让系统在真实用户、真实并发、真实故障、真实成本压力下，依然稳定运行。