「产品矩阵平台」平台级 AI 支撑架构

第九章 平台级 AI 支撑架构

AI 能力进入产品矩阵后，很容易从“一个接口调用”变成“不可控的成本和风险来源”。平台级 AI 架构要解决的不只是调用模型，还包括模板版本、知识检索、异步任务、租户配额、内容安全、成本计量和人工复核。

一个成熟 AI 支撑层应像支付中心一样被治理：谁调用、调用了什么、花了多少钱、生成了什么、是否可追溯，都要清楚。

9.1 AI 微服务封装

AI 服务建议独立为平台服务，业务模块通过统一接口调用。

graph TD
    A[Business Service] --> B[AI Gateway]
    B --> C[Prompt Service]
    B --> D[Model Router]
    B --> E[Safety Guard]
    B --> F[Usage Meter]
    D --> G[OpenAI / Claude / Local Model]
    B --> H[Task Queue]

统一封装的好处：

9.2 Prompt 模板系统

Prompt 不应该散落在业务代码里。它应像配置和代码一样有版本。

模板字段：

一次 Prompt 变更要能灰度。比如只对某个租户启用新版客服回复模板，观察满意度和人工接管率后再扩大。

9.3 模型适配层

模型适配层要屏蔽不同供应商 API 差异。

统一接口可以表达为：

type ModelClient interface {
    Chat(ctx context.Context, req ChatRequest) (*ChatResponse, error)
    Embed(ctx context.Context, req EmbedRequest) (*EmbedResponse, error)
}

模型选择策略：

不要让业务代码直接写供应商名称。应通过任务类型、租户配置和成本策略来路由。

9.4 向量检索服务

向量检索适合解决“语义相关”的问题，但不是万能数据库。

典型链路：

文档上传 -> 切分 chunk -> 生成 embedding -> 写入向量库
用户问题 -> 生成 query embedding -> 检索 TopK -> 重排序 -> 拼接上下文 -> 调用模型

切分策略很重要：

向量库可以选择 PgVector、Milvus、Qdrant 等。早期如果数据量不大，PgVector 更容易运维。

9.5 RAG 与数据增强

RAG 的关键不是“检索 + 生成”，而是让模型知道哪些内容可信、哪些内容只是参考。

上下文建议包含：

1. 文档片段；
2. 来源链接；
3. 更新时间；
4. 租户和权限信息；
5. 置信度。

回答输出应保留引用信息，尤其是知识库问答、内部政策、财务说明等高风险场景。

9.6 AIGC 输出管理

平台要防止三类问题：

高风险任务应进入人工复核，例如医疗建议、金融建议、法律文本、公开发布内容。

9.7 与产品矩阵融合

AI 不应只是一个“生成按钮”。它可以嵌入不同业务域：

每个融合点都要记录输入、输出、模型、模板版本和人工修改结果。这些数据会反过来优化 Prompt 和产品体验。

9.8 AI 成本与计费

AI 成本必须可见，否则很容易被几个租户打穿预算。

记录维度：

套餐可以按“次数 + token + 高级模型额度”组合计费。

9.9 AI 支撑架构清单