大模型技术栈重构：从向量数据库到AI编排实践

1. 大模型时代的技术栈重构：从确定性到概率性的基础设施革命

过去二十年里，我们见证了技术栈的数次重大演进。从早期的单体架构到微服务，再到容器化和Kubernetes编排，每一次变革都围绕着两个核心命题：如何管理日益增长的复杂度，以及如何实现系统的高效规模化。如今，大模型技术的崛起正在引发新一轮基础设施革命，这场变革的本质是从确定性计算向概率性计算的范式转移。

作为经历过多次技术栈迁移的老兵，我深刻体会到这次转型的特殊性。传统架构中，我们处理的是确定性结果——数据库查询要么返回准确结果，要么报错；函数调用要么返回预期值，要么抛出异常。而在大模型时代，我们面对的是概率性输出——同一个问题可能得到不同但都合理的回答，模型可能"自信满满"地给出完全错误的答案（即所谓的"幻觉"现象）。

这种转变对基础设施提出了全新要求。我们不能再简单地把大模型当作又一个API端点来调用，而需要构建一整套适应概率性计算的技术栈。这就像从建造砖房转向建造生物组织，虽然都是"建造"，但材料特性和施工工艺已截然不同。

2. 记忆的外化：向量数据库作为新基石

2.1 传统数据存储的局限性

在传统架构中，我们的数据存储方案已经形成了成熟的分工体系：

• 关系型数据库（如MySQL）负责结构化数据的精准存储与查询
• Redis等缓存系统处理热点数据加速
• 对象存储（如S3）承载非结构化文件

这套体系在确定性查询场景下表现出色，但当我们需要处理"帮我找出去年关于差旅报销的政策文件中与机票预订相关的条款"这类语义查询时，就显得力不从心。传统方案要么要求精确的关键词匹配，要么需要开发复杂的业务逻辑层。

2.2 向量数据库的核心价值

向量数据库通过将数据转化为高维向量（通常由大模型生成的embedding），实现了基于语义相似度的检索。这相当于为机器提供了"理解"数据含义的能力。以典型的RAG（检索增强生成）流程为例：

1. 文档预处理：将PDF、Word等文档按语义段落切分
2. 向量化：使用embedding模型（如OpenAI的text-embedding-ada-002）将文本转换为向量
3. 存储索引：将向量及其元数据存入向量数据库（如Pinecone、Weaviate）
4. 查询时：将用户问题同样向量化，通过余弦相似度查找最相关的文档片段

关键决策点：选择向量数据库时，除了常规的性能指标，要特别关注其对动态数据（频繁更新）的支持能力，以及是否提供混合搜索（同时支持向量检索和传统关键词过滤）。

2.3 实施挑战与经验

在实际部署中，我们踩过几个典型的坑：

• 分块策略：简单的固定长度分块会导致语义断裂。我们最终采用递归分块法，优先按自然段落划分，再对长段落进行二次分割
• 元数据设计：除了向量本身，必须精心设计元数据结构。我们为每个分块添加了来源文档、创建时间、业务部门等字段，这对后续的检索过滤至关重要
• 更新机制：当源文档修改时，如何高效更新向量数据库是个挑战。我们建立了文档指纹机制，只对变更部分重新生成embedding

3. AI编排层：新时代的开发范式

3.1 从线性逻辑到认知逻辑

传统业务代码遵循明确的输入-处理-输出流程，而AI应用引入了认知决策层。以客服系统为例，现代AI应用的逻辑流程可能包含：

1. 意图识别：判断用户问题是查询、投诉还是操作请求
2. 上下文检索：从向量数据库获取相关知识片段
3. Prompt工程：动态构建适合当前问题的提示词
4. 模型调用：根据问题复杂度选择不同规模的模型
5. 后处理：可能包括敏感信息过滤、格式标准化等

这种复杂流程如果硬编码实现，很快就会变得难以维护。这就是AI编排框架（如LangChain、LlamaIndex）的价值所在。

3.2 编排框架选型要点

在选择编排框架时，我们建立了以下评估矩阵：

基于半年实践，我们的体会是：

• 快速原型开发阶段适合用LangChain，其丰富的组件库能加速实验
• 生产环境建议基于LlamaIndex或自建轻量框架，避免LangChain的抽象泄漏问题
• 企业级应用可评估Semantic Kernel，特别是已有微软技术栈的团队

3.3 编排层最佳实践

1. 保持业务逻辑与AI逻辑分离：将Prompt模板、模型配置等外部化，避免硬编码
2. 实现可复用的认知组件：如将"文档检索-精炼-回答"流程封装为标准化模块
3. 建立测试框架：对每个认知环节设计单元测试，特别是评估模型输出的质量
4. 版本控制一切：不仅代码，Prompt模板、模型配置、甚至embedding模型版本都应纳入版本管理

4. 模型网关：智能流量调度中枢

4.1 传统API网关的不足

传统网关主要关注：

• 请求速率限制
• 负载均衡
• 基础认证授权

但在大模型场景下，我们需要更精细的流量管理：

1. 智能路由：将简单查询路由到成本更低的轻量模型（如GPT-3.5），复杂问题才使用GPT-4
2. 上下文缓存：实现会话级别的缓存，避免重复发送历史消息
3. 计费隔离：按部门/项目细分Token消耗
4. 降级策略：当主模型不可用时自动切换备用模型

4.2 网关实现模式

我们评估了三种实现方案：

1. 自研网关：

   • 优点：完全定制化
   • 缺点：开发成本高，特别是需要处理流式响应等复杂场景
   • 适合：有强大基础架构团队的大型企业

2. 开源方案（如OpenAI的Triton）：

   • 优点：社区支持
   • 缺点：功能有限，扩展困难
   • 适合：小规模应用

3. 商业方案（如Azure API Management的LLM扩展）：

   • 优点：开箱即用
   • 缺点：成本高，供应商锁定
   • 适合：需要快速上线的中型企业

最终我们选择了分层方案：基于Envoy构建基础网关，增加LLM特定插件，在保证灵活性的同时控制开发成本。

4.3 成本控制实战技巧

1. Token预算机制：为每个业务部门设置每日Token限额，超过阈值自动降级
2. 响应长度限制：在网关层强制限制max_tokens参数，避免意外长响应
3. 请求预处理：在调用模型前过滤明显不当请求
4. 分级监控：对高成本模型调用实施实时告警

5. LLMOps：模型生命周期的守护者

5.1 监控维度的扩展

传统运维监控主要关注：

• 资源利用率（CPU/GPU/内存）
• 请求延迟
• 错误率

LLMOps需要新增的关键指标：

1. 质量指标：

   • 幻觉率（模型编造信息的比例）
   • 拒答率（模型拒绝回答合理问题的比例）
   • 毒性分数（输出中包含不当内容的概率）

2. 成本指标：

   • 每请求平均Token消耗
   • 模型调用混合比例（不同模型的调用分布）

3. 业务指标：

   • 终端用户满意度（通过埋点收集）
   • 任务完成率（多轮对话场景）

5.2 评估体系构建

我们建立了三级评估体系：

1. 自动化测试：

   • 使用RAGAS等框架定期运行标准问题集
   • 关键业务场景的端到端测试

2. 人工审核：

   • 随机抽样审核
   • 高风险领域（如医疗建议）的100%审核

3. 用户反馈：

   • 嵌入式评分系统
   • 客服渠道收集的投诉与建议

5.3 漂移检测与应对

模型行为可能随时间变化（称为"漂移"），我们实施的检测策略包括：

1. 输入分布监控：检测用户问题模式的变化
2. 输出稳定性检查：对相同问题定期测试，比较回答一致性
3. embedding质量监控：定期检查向量检索的相关性

当检测到显著漂移时，我们的应对流程：

1. 隔离受影响业务流
2. 回滚到上一稳定版本
3. 分析根本原因（模型更新？数据变化？）
4. 针对性调整后逐步重新上线

6. 技术管理者的行动清单

基于两年的大模型基础设施实践，我总结出技术管理者应优先关注的领域：

1. 团队能力建设：

   • 培养"全栈AI工程师"——既懂传统软件开发，又理解AI特性
   • 设立专门的Prompt工程师和数据工程岗位
   • 建立与学术界的合作通道，跟踪最新进展

2. 技术路线规划：

   • 评估现有架构的AI就绪度
   • 制定分阶段的现代化路线图
   • 保持基础设施的适度前瞻性

3. 成本治理框架：

   • 建立模型调用预算制度
   • 实施细粒度的成本分配与展示
   • 定期优化模型使用策略

4. 风险管理体系：

   • 数据隐私保护机制
   • 内容安全过滤管道
   • 业务连续性计划（特别是模型供应商不可用时）

大模型基础设施的构建不是一次性项目，而是持续演进的过程。我们团队目前每月都会进行架构审视，确保基础设施能够支持不断变化的业务需求。记住，在AI时代，技术栈的质量不仅影响开发效率，更直接决定了业务创新的上限。