m208. AI 基础设施与中间件选型

本章覆盖 AI 产品的四层基础设施：向量数据库、编排框架、可观测性工具、模型服务层。这些是”水管”——用户感知不到，但一旦选错，后期迁移代价极高。

2.5.1 向量数据库

向量数据库是 RAG 系统的核心存储层，用于存储 Embedding 向量并支持近似最近邻（ANN）检索。

检索算法概念（了解即可）

HNSW：多层图结构，上层粗定位、下层精搜索。速度极快，内存占用高。大多数向量库的默认算法
IVF：将向量空间划分为聚类，先定位聚类再精搜。内存较低，需训练聚类中心
PQ/SQ（量化压缩）：对向量做有损压缩省内存，代价是精度损失（与模型量化原理相通，见 c07）

主流方案对比

方案	类型	核心优势	核心劣势	适用场景
Pinecone	全托管	零运维、自动扩缩	贵、数据在对方云上	快速验证、小团队
Milvus / Zilliz	开源/云托管	功能丰富、大规模支持好	自建运维复杂	大规模生产
Qdrant	开源（Rust）	性能好、Payload 过滤强	生态不如 Milvus	需要复杂元数据过滤
Weaviate	开源	内置向量化、GraphQL	大规模性能待验证	全栈方案
PGVector	PostgreSQL 扩展	复用 PG 基础设施	大规模性能差	< 100 万向量、已有 PG
Chroma	开源轻量	安装即用、Python 原生	不适合大规模	本地开发、原型

选型决策维度

数据量级	推荐方案
< 100 万向量	PGVector（如已有 PG）或 Chroma（开发原型）
100 万 ~ 1 亿	Qdrant 或 Milvus
> 1 亿	Milvus 或 Pinecone 企业版

其他关键维度：

无运维能力 → Pinecone / Zilliz Cloud（全托管）
数据安全不能出境 → 自建 Milvus 或国内云向量服务（阿里云、腾讯云）

2.5.2 编排框架与 Agent 平台

编排框架对比

框架	定位	优势	劣势	适合阶段
LangChain	最流行的 LLM 编排框架	组件丰富、社区大	过度封装、调试难、API 频繁变动	原型验证
LlamaIndex	数据索引和检索专精	RAG 功能深入	Agent 能力弱	RAG 核心产品
LangGraph	LangChain 团队的图编排	支持循环、条件分支、状态管理	学习曲线陡	Agent 工作流
CrewAI	多 Agent 协作框架	多 Agent 角色定义直观	灵活性受限	多 Agent 场景
Dify / Coze	低代码 LLM 应用平台	可视化编排、非工程人员可用	深度定制难	内部工具、快速 demo

为什么大厂会自研框架？

过度封装的性能开销和不可控性（LangChain 在某些场景引入 2–3 倍延迟）
复杂业务逻辑超出框架预设（灰度发布、熔断、复杂路由）
生产环境需要精细监控，LangChain 的 tracing 不够完整
对每毫秒延迟和每分钱成本极度敏感（见 m209）

PM 选型建议

原型阶段：LangChain 或 Dify（周级别快速验证）。

生产阶段：评估替换。不要在 LangChain 的重度封装上构建核心生产系统，除非团队有能力深入源码排查。

中间方案：LangGraph（支持状态管理和循环，比 LangChain 更适合 Agent 工作流）或自研轻量编排层（通常 500–2000 行代码就能覆盖大多数场景）。

2.5.3 可观测性（Observability）与 Tracing

这是 v1 版本完全缺失、但在生产环境中至关重要的一层。

核心问题：当 RAG + Agent 的链路变长后，“模型回答错了”不是可操作的诊断信息。你需要知道：

检索错了？（没找到相关内容）
排序错了？（找到了但没排在前面）
生成错了？（找到了正确内容但模型没有使用它 → 即幻觉）

没有 Tracing，你不知道问题出在哪一层，迭代就是盲射。

核心工具生态

工具	核心能力	适用场景
LangSmith（LangChain）	LLM 调用 tracing、prompt 调试、评估	LangChain 生态内
Arize Phoenix	开源、LLM observability、Embedding 可视化	自建、开源偏好
LangWatch	RAG 评估 + Agent tracing + 质量监控	RAG 重度用户
Langfuse	开源、tracing + 成本追踪	成本敏感、自建
Weights & Biases（Weave）	实验追踪 + LLM 评估	同时做微调和评估

关键监控指标

每条 query 必须追踪的完整 trace：

检索 query → 检索结果列表 → 相似度分数
→ Reranker 重排结果 → 最终注入 prompt
→ 模型输出 → 用户反馈

延迟分解（必须分层追踪）：

Embedding 计算耗时
向量检索耗时
Reranker 耗时
模型推理耗时（Prefill + Decode，见 c05 §5.1 TTFT/TPOT）
总端到端耗时

成本追踪：每条 query 的 token 消耗 + 每日/月总成本 + 各模型分摊成本（详见 m209 成本框架）。

2.5.4 模型服务层

方案	核心技术	适用场景
vLLM	PagedAttention（c05 §5.3 KV Cache 分页管理）	高吞吐在线服务首选
SGLang	RadixAttention + 结构化生成优化	复杂 prompt + 结构化输出
TGI（HuggingFace）	HF 生态集成	HuggingFace 模型快速部署
llama.cpp / Ollama	CPU/端侧推理、GGUF 量化（c07）	本地开发、端侧部署

PM 不需要深入这层，但需要知道：API 供应商背后用什么服务框架，直接影响并发能力和推理延迟（c05 §5.3 Continuous Batching）。在选择私有化部署方案时，向工程师确认：是否用 vLLM？是否启用 Continuous Batching？

相关概念卡：RAG、Embedding、Agent、量化、幻觉与校准、Function Calling、Tokenization 专题升级：0411 Agent 系统化专题 — 本章编排框架对比被 A06 Orchestrator 编排器概念深化；编排器与 framework 的边界辨析见 A02 抽象层级辨析·Harness Framework Agent Skill Orchestrator；harness 全景在 S03 Harness Engineering 全景上一章：m207 Agent 场景推演与兜底下一章：m209 推理成本控制

m208 - AI 基础设施与中间件选型