跳转至

AI 工程架构

概述

本页描述基础模型（foundation model）应用的生产环境架构，内容综合自 Chip Huyen 的 AI Engineering（O'Reilly，2025，第 10 章）。该架构遵循渐进式思路：从尽可能简单的系统起步，再随着生产环境需求的出现逐步增加组件，而不是一开始就过度设计。

尽管 AI 应用形态各异，它们却共享一组通用组件。本文这套五步架构已在多个生产部署中得到验证。

最简架构

最小可行架构接收一条查询，将其直接发送给模型 API，再把响应返回给用户。没有上下文增强，没有护栏（guardrails），没有优化。

[User Query] → [Model API] → [Response]

Model API 这个方框既涵盖第三方 API（OpenAI、Anthropic、Google），也涵盖自托管模型（需要一台推理服务器，详见「推理优化」部分）。

从这里起步能让早期开发保持快速。只有当用户反馈或生产指标提供了证据时，才增加复杂度。

第 1 步：增强上下文

第一次扩展是加入动态构建上下文的机制——把模型权重中没有的相关信息提供给它。

上下文可以通过以下方式构建：

  • 文本检索（检索增强生成，RAG）：搜索向量数据库或关键词索引，检索出相关的文档片段
  • 图像/多模态检索：检索相关的图像、表格或结构化数据
  • 表格数据检索：执行 SQL 查询以检索结构化记录
  • 基于 API 的增强：通过网页搜索、天气、新闻或内部 API 调用获取实时数据

构建上下文类似于传统机器学习（ML）中的特征工程：它为模型提供产出准确结果所需的数据。

关键考量：不同模型 API 提供方在上下文构建支持上各有差异——上传上限、片段大小、检索算法、工具执行方式（串行 vs. 并行）。当通用 API 不足以满足需求时，专门的 RAG 方案或许能支持不限量的文档上传，仅受向量数据库容量的限制。

第 2 步：加入护栏

护栏（guardrails）保护系统及其用户免受风险。它同时作用于输入和输出。

输入护栏

两类主要风险： 1. 向外部 API 泄露私密信息：员工或应用可能无意中把敏感数据（个人身份信息 PII、商业机密、内部政策）放进发往第三方 API 的提示词中。 2. 提示词注入与越狱：攻击者构造输入来覆盖系统指令，或套取系统本不应透露的信息。

缓解措施： - PII/敏感数据检测：自动化工具扫描提示词中的 PII（身份证号、银行账号、人脸）、知识产权关键词或涉密措辞。一旦检出，可以拦截、脱敏，或将该提示词改路由到本地模型。 - 注入检测：基于模式和基于模型的分类器检测注入企图。

输出护栏

三类主要输出风险： 1. 空响应或格式错误的响应：模型失败或返回了无效结构 2. 幻觉（hallucination）：把事实上错误的内容当作事实呈现 3. 不安全内容：有毒、有害或违反政策的输出

输出护栏可以包括： - 基于模型的打分器：用小模型评估输出质量（相关性、忠实度、毒性），并触发补救措施（重新生成、上报人工、返回兜底结果） - 格式校验器：确保结构化输出（JSON、XML）符合预期的模式（schema） - 内容分类器：标记不安全、跑题或存在法律风险的内容

权衡：输出护栏会让每条响应多出额外的模型调用，增加延迟和成本。

第 3 步：加入模型路由器与网关

随着应用规模扩大，管理多个模型和多个入口点需要额外的基础设施。

路由器

路由器使用意图分类器或下一步动作预测器，把每条查询路由到最优方案：

  • 模型路由：把简单查询路由到便宜/快速的模型，把复杂查询路由到前沿模型
  • 动作路由：对智能体（agent）而言，预测下一步动作（代码解释器、网页搜索、上报人工）
  • 记忆路由：决定从哪一层记忆（上下文内、语义缓存、向量库、数据库）拉取数据

路由器通常是小而快的模型（微调后的 BERT、Llama-7B，甚至基于规则的分类器），增加的延迟极小，却能带来可观的成本节省。

路由顺序：路由往往发生在检索之前（判断查询是否在范围内、是否需要检索）。检索之后的路由也会被采用（当检索置信度较低时路由到人工）。

网关

模型网关为多个模型提供统一接口，把各提供方专有的 API 抽象掉：

  • 统一接口：无论底层是哪个模型（OpenAI、Google、Anthropic、自托管），都用同一种 API 调用
  • 访问控制：集中管理 API 密钥以及按团队/用户划分的访问权限
  • 成本监控：按用户、项目或模型跟踪并限制 API 消耗
  • 兜底策略：当主模型被限流或不可用时自动故障转移
  • 版本固定：固定特定的模型版本，防止提供方更新导致意外的行为变化

第 4 步：用缓存降低延迟

缓存避免重复计算，对重复或相似的查询能大幅降低延迟和成本。

精确缓存

以精确查询或嵌入哈希为键来缓存结果：

  • 响应缓存：如果同一查询（或同一份产品摘要请求）此前已回答过，直接返回缓存结果
  • 嵌入缓存：如果某查询此前已嵌入并做过向量搜索，返回缓存的检索结果
  • 工具结果缓存：缓存确定性的工具输出（API 响应、SQL 结果），并设置合适的 TTL

实现：Redis（用于快速的内存查找）、PostgreSQL 或分层存储（用于较大的缓存）。淘汰策略：LRU、LFU 或 FIFO。训练一个分类器来预测哪些查询值得缓存（避免缓存与用户相关或时效性强的查询）。

安全风险：不当的缓存会造成数据泄露。与特定用户相关的响应绝不能被缓存后返回给另一个用户。

语义缓存

利用嵌入相似度，为语义相似（而不仅是完全相同）的查询返回缓存结果： - 把进入的查询做嵌入，在过往查询嵌入的缓存中搜索 - 当余弦相似度超过阈值时，返回缓存的响应

这对 FAQ 智能体、分类流水线，以及任何查询模式可预测的高并发场景尤其有效。

第 5 步：加入智能体模式

简单的串行查询-响应流程可以升级为智能体（agentic）模式，以应对复杂任务：

  • 循环：当任务尚未完成时，把生成的输出再喂回模型（例如一个搜索智能体判断出它第一次检索的结果不够充分）
  • 并行执行：并发派发多次检索或工具调用
  • 条件分支：根据中间的模型输出走不同的执行路径
  • 写操作（write actions）：模型输出触发现实世界中的变更（撰写邮件、下单、更新数据库、发起转账）

关于写操作的重要警示：写操作大幅拓展了系统能够完成的事情，但也带来了不可逆的后果。写操作能力应当仅在必要时才授予，并为高影响操作设置明确的人在回路（HITL）检查点、用严格的幂等性保证防止重复的副作用、以及对所有写事件做审计日志记录。

监控与可观测性

可观测性应当在应用设计之初就纳入，而不是事后再补。系统越复杂，这一点越关键。

关键区分： - 监控（Monitoring）：跟踪系统的外部输出，以便在出问题时及时发现 - 可观测性（Observability）：为系统埋点，使其内部状态能够从外部输出推断出来——从而无需部署新代码即可做根因诊断

三个源自 DevOps、用于评判可观测性质量的指标：

指标 定义 目标
MTTD（平均检测时间，Mean Time to Detection） 多久能检测到一次故障 最小化
MTTR（平均响应时间，Mean Time to Response） 检测到之后多久能解决 最小化
CFR（变更失败率，Change Failure Rate） 导致需要回滚的故障的部署占比 跟踪并降低

专门针对基础模型应用需要埋点的内容： - 响应质量指标：采样的 AI 充当评审分数，涵盖相关性、忠实度、毒性 - 用户反馈信号：点赞/点踩、明确评分、追问（隐含的不满意信号） - 延迟分解：检索、模型推理、护栏、缓存各环节的耗时 - 每请求成本：token 数量、所用模型档位、缓存命中率 - 失败模式：护栏拒绝、空响应、工具调用错误、路由误分类

评测与监控流水线必须保持同步：一个在离线评测中表现良好的模型，在生产环境中也应表现良好。监控中发现的问题应反馈回评测流水线。

AI 流水线编排

对于复杂的多步流水线，由一个编排层把所有组件串联起来：

  • 串行链接：检索 → 生成 → 打分 → 输出
  • 并行扇出：同时派发多次检索或工具调用，再合并结果
  • 重试逻辑：以指数退避重新调用失败的步骤
  • 状态管理：为长时运行的智能体工作流跟踪部分执行状态（持久化执行）

主流编排框架：LangChain/LangGraph、AWS Strands、Google ADK、Temporal（用于持久化执行），以及面向简单流水线的自定义编排。

架构演进小结

步骤 新增组件 解决的问题
基础 Model API 基本的查询-响应
第 1 步 上下文构建（RAG、工具） 模型缺乏对私密/近期数据的了解
第 2 步 输入/输出护栏 安全风险、质量控制
第 3 步 路由器 + 网关 多模型管理、成本控制
第 4 步 精确缓存 + 语义缓存 规模化下的延迟与成本
第 5 步 智能体模式 + 写操作 复杂的多步任务
+ 监控与可观测性 生产环境可靠性
+ 编排层 串联所有组件

参见

参考资料