面经策

你在 AI 超级智能体项目中集成了哪些大模型，遇到了什么挑战？ ​

  • 标签：后端、编程导航

🏛 业务架构师 ​

我集成过国内外多家模型：OpenAI GPT 系列、DeepSeek、通义千问、智谱 GLM，Embedding 侧也做过对比选型。挑战我按业务影响的真实排序讲：

  • 模型能力差异：同一个 prompt 在不同模型上表现差异巨大——指令遵循、中文能力、结构化输出稳定性各有强弱。对策：关键场景建评测集，换模型先跑评测，而不是靠感觉；
  • 限流与配额：高峰期 429 限流是常态，尤其新模型发布的热点期。对策：多供应商路由 + 请求排队 + 降级链——AI 业务的容量规划要按"供应商配额"这个新变量做；
  • 成本波动：token 单价差异大、长上下文成本陡增。对策：调用层埋点计量（按功能/用户核算毛利）、模型分级路由（简单任务用便宜模型，复杂推理才上旗舰）——模型选择本身成了成本工程；
  • 输出稳定性：同一输入偶发不同输出，格式漂移导致下游解析失败。对策：结构化输出 + 重试校验 + 兜底提示；
  • 数据合规：用户数据出境审查，某些场景必须国产模型或私有化。

我踩过最典型的坑：早期只接一家模型，某天它大面积超时，整个产品瘫痪——AI 应用把供应商可用性当成了自己的可用性。之后就建立了"主备双模型 + 健康探测自动切换"的路由层，用架构冗余对冲供应商风险，这在传统分布式系统里叫异地多活，在 AI 应用里就是多模型热备。

🏗 系统架构师 ​

我集成了 OpenAI GPT 系列、DeepSeek、通义千问（OpenAI 兼容接口）以及本地 Ollama（测试用），遇到的挑战按真实痛点讲：

1. 供应商差异与切换：各家的参数（上下文长度、函数调用格式、JSON 输出稳定性）、限流额度、计费方式都不同。解法：Spring AI 的 ChatModel 抽象统一接入 + 配置化路由（dev 用 Ollama/DeepSeek 省钱，prod 按任务分级路由），供应商故障自动降级切换（比如超时切备用模型）——模型层的高可用设计。

2. 延迟与流式：LLM 首 token 延迟 1~5 秒，全量生成几十秒。必须 SSE 流式 + 首 token 超时独立配置；长任务（Agent 多轮）改为异步任务 + 进度推送。

3. 限流与配额：厂商 RPM/TPM 限流，多实例共享配额要自己做全局限流（Redis 令牌桶）与排队，避免 429 雪崩；重试要指数退避 + 尊重 Retry-After。

4. 稳定性差异：同一提示词不同模型输出质量波动大——关键流程（结构化输出）要加校验 + 失败重试 + 兜底模型；Prompt 要针对每家模型微调。

5. 成本：上下文越长越贵，对话记忆要摘要压缩；缓存高频问答命中直接返回。

架构心法：把 LLM 当不稳定的外部依赖设计——超时、重试、降级、限流、成本监控五件套一样不能少，这与接入任何第三方服务的治理思路完全一致。

💻 全栈开发专家 ​

接的模型：云端——OpenAI GPT 系列、DeepSeek（主力，便宜）、通义千问（国内合规场景备选）；本地——Ollama 跑 qwen/deepseek 蒸馏版用于开发自测。Spring AI 统一抽象 + OpenAI 兼容端点切换。

遇到的挑战与解决（面试的核心素材）：

  1. 流式超时误杀：LLM 首 token 慢，网关默认 3s 超时把流掐断。解决：读超时 60s、网关关闭响应缓冲（proxy_buffering off）、SSE 单独的超时策略（按 chunk 间隔判活而不是总时长）。

  2. 各家 API 协议细节不一致：名义上"OpenAI 兼容"，实际 tool calling 的 schema、错误码、流式 chunk 格式有差异。解决：统一走 Spring AI 抽象层 + 自研薄适配层，模型差异封装在一个 ModelGateway 里，业务无感。

  3. 长上下文成本失控：多轮对话 + RAG 上下文一长 token 爆炸。解决：记忆窗口截断 + 历史摘要压缩，RAG 检索只带 top5 片段并做相关性过滤，实测 token 降 60%。

  4. 可用性：单一厂商抖动/限流。解决：多模型 failover（主 DeepSeek，异常自动切通义），配合熔断，可用性从 99% 提到 99.9%。

  5. 国内访问 OpenAI 网络问题：代理或干脆用国产模型直连，架构上预留 endpoint 可配。