构建生成式AI平台

步骤1：增强上下文

初始平台扩展通常涉及添加上下文构造机制，使系统能够为每个查询补充必要信息。研究表明，在上下文中提供相关信息有助于模型生成更详细的响应，同时减少幻觉（Lewis等，2020）。

RAG（检索增强生成）

最著名的上下文构造模式是RAG，包含两个组件：生成器（如语言模型）和从外部源检索相关信息的检索器。

检索算法主要采用两种方法：

1. 基于术语的检索
   可以是简单的关键词搜索，如BM25（利用TF-IDF）和Elasticsearch（利用倒排索引）。

2. 基于嵌入的检索（向量搜索）
   使用BERT等嵌入模型将数据块转换为向量，通过近似最近邻（ANN）算法如FAISS、ScaNN进行搜索。

生产检索系统通常结合多种方法，称为混合搜索。常见模式包括：

• 顺序模式：先用廉价检索器获取候选，再用精确机制重排序
• 集成模式：同时使用多个检索器，合并不同排名生成最终结果

表格数据RAG

外部数据源也可以是结构化的（如SQL表）。处理流程：

1. 文本到SQL：根据用户查询和表结构确定所需SQL
2. SQL执行
3. 生成：基于SQL结果和原始查询生成响应

代理式RAG

重要数据源是互联网。网络搜索工具（如Google API）让模型能获取丰富的最新信息。这种工作流称为代理式，架构如下：

步骤2：设置防护栏

防护栏帮助降低AI风险，保护用户和开发者。讨论两种类型：输入防护栏和输出防护栏。

输入防护栏

主要防范两类风险：

1. 向外部API泄露私人信息

   • 使用敏感数据检测工具自动识别（如个人身份信息、公司机密）
   • 处理方式：阻止整个查询或移除敏感信息

2. 模型越狱（执行恶意提示）

   • 定义应用范围外的话题
   • 使用AI分类输入是否涉及受限主题
   • 对罕见恶意提示使用异常检测算法

输出防护栏

主要功能：

1. 评估每次生成的质量

   • 检测空响应、格式错误、有毒内容、事实错误等
   • 使用专用工具验证JSON格式、Python代码等

2. 制定不同故障模式的处理策略

   • 重试逻辑：对空响应或格式错误尝试多次
   • 并行调用：减少延迟但增加API调用
   • 人工接管：对特定关键词或用户愤怒情绪转移给人工

防护栏权衡

• 可靠性 vs 延迟：多数团队认为增加的风险成本高于延迟
• 自托管 vs 第三方API：自托管需自行实现所有防护栏

步骤3：添加模型路由器和网关

随着应用复杂度增加，两种工具帮助管理多模型：

路由器

使用意图分类器预测用户意图，将查询路由到适当解决方案。例如客服聊天机器人：

• 密码重置 → 密码重置页面
• 账单错误 → 人工客服
• 技术问题 → 微调过的故障排除模型

网关

模型网关是中间层，让组织以统一安全方式对接不同模型。基本功能：

• 统一访问接口：简化代码维护
• 访问控制和成本管理
• 实现回退策略应对API限流或故障
• 负载均衡、日志记录和分析

示例网关实现（简化版）：

1
2
3
4
5
6
7
8
9

@app.route('/model', methods=['POST'])
def model_gateway():
    data = request.get_json()
    model_type = data.get("model_type")
    if model_type == "openai":
        result = openai_model(...)
    elif model_type == "gemini":
        result = gemini_model(...)
    return jsonify(result)

现有网关服务包括Portkey、MLflow AI Gateway等。

步骤4：用缓存降低延迟

缓存技术可显著降低应用延迟和成本。常见推理缓存技术：

提示缓存

存储重复使用的文本段（如系统提示）。对长系统提示应用可节省大量处理：

• 1000token系统提示 × 100万API调用 = 节省10亿token/天
• Google Gemini API提供"上下文缓存"功能，缓存输入token享受75%折扣

精确缓存

存储已处理项供重复使用。例如：

• 用户请求产品摘要 → 检查缓存 → 命中则返回，否则生成并缓存
• 可用于嵌入检索避免冗余向量搜索

实现方式：内存存储（快速）或PostgreSQL/Redis（大容量），需淘汰策略（LRU等）

语义缓存

允许重用语义相似查询（非完全相同）。工作流程：

1. 为查询生成嵌入
2. 向量搜索找到最接近的缓存嵌入
3. 相似度超过阈值则返回缓存结果

挑战：

• 依赖高质量嵌入和可信相似度指标
• 设置合适阈值需要大量试验
• 可能返回错误缓存响应
• 向量搜索本身耗时且计算密集

步骤5：添加复杂逻辑和写操作

复杂逻辑

模型输出可条件传递到其他模型或反馈为下一步输入。例如： 查询"规划巴黎周末行程" → 模型首先生成活动列表 → 每个活动反馈给模型生成详细子计划 → 迭代直至生成完整行程。

写操作

读操作允许模型从数据源读取上下文，写操作能改变数据源和现实世界。例如： 模型输出"发送邮件给X，内容Y" → 系统调用send_email(recipient=X, message=Y)。

写操作极大增强系统能力，但也带来严重安全风险：

• 需防范提示注入攻击（对AI的社会工程）
• 任何组织使用AI都需认真考虑安全性

可观测性

应从一开始集成到平台中，包含三大支柱：

指标

1. 系统指标：吞吐量、内存使用、硬件利用率等
2. 模型指标：准确性、毒性、幻觉率等
3. 长度相关指标：查询/上下文/响应长度，帮助理解模型行为
4. 延迟指标：首次令牌时间(TTFT)、令牌间隔(TBT)、令牌每秒(TPS)等
5. 成本指标：查询量、输入输出token量、每秒请求数（应对API限流）

日志

基本原则：记录一切。包括：

• 系统配置
• 查询、输出和中间输出
• 组件启动、结束、崩溃等
• 添加标签和ID帮助定位日志来源

跟踪

记录请求在系统各组件中的完整执行路径，显示：

• 从查询到响应的全过程
• 系统采取的操作、检索的文档、最终提示
• 每个步骤的时间（和成本）
• 失败时精确定位错误步骤

AI流水线编排

随着组件增多，编排器帮助指定如何组合不同组件创建端到端应用流。高级工作：

1. 组件定义：告诉编排器系统使用的模型、数据库、动作等
2. 链接（流水线）：指定从接收查询到完成任务的操作序列

示例流水线：

1. 处理原始查询
2. 检索相关数据
3. 组合查询和检索数据创建提示
4. 模型生成响应
5. 评估响应
6. 合格则返回用户，否则转人工

现有编排工具包括LangChain、LlamaIndex、Flowise等。选择时考虑：

• 集成和扩展性
• 复杂流水线支持
• 易用性、性能和可扩展性

结论

本文从基础架构开始，逐步添加组件应对日益复杂的应用需求。每个新增组件都带来独特优势和挑战，需要仔细考量和实施。

虽然组件分离对保持系统模块化和可维护性很重要，但这种分离是流动的。许多组件之间存在功能重叠，例如模型网关可与防护栏共享功能，缓存可在不同组件中实现。

更深入探讨将在即将出版的《AI工程》书中展开，包括模型服务、推理优化等未在本篇详述的主题。