AI架构选型从来不是“选最先进技术”的单向选择题，而是在业务阶段、效果要求、成本预算、团队能力、合规约束等多重边界下的多目标优化问题。对架构师而言，核心价值不是堆砌技术组件，而是清晰定义每个决策的 trade-off，在不确定性中选择当下最优、长期可演进的方案。以下是架构师在AI架构选型中最常面对的真实决策场景与底层思考逻辑。

一、底座选型：闭源API vs 开源私有化，第一个十字路口

这是所有AI项目启动时的第一个架构决策，也是最容易出现“初期图快、后期踩坑”的环节。

真实困境

• 业务侧要求快速上线验证，团队倾向直接调用闭源大模型API，一周就能出原型；但随着调用量上涨，月度算力成本指数级增长，且核心业务数据出域存在合规风险。

• 一开始就选型私有化部署开源模型，研发周期拉长2-3倍，效果可能不如闭源模型，业务等不及；且团队缺乏大模型部署优化能力，上线后性能、稳定性都不达标。

架构师的核心思考维度

1. 数据敏感度与合规红线：这是优先级最高的决策因子。涉及企业内部机密、用户隐私、行业监管数据（金融、医疗、政务），原则上必须走私有化部署，禁止数据出域；通用场景、公开数据类应用可优先闭源API。

2. 成本拐点测算：按业务预估的月调用量做量化对比：闭源API按token计费，成本随调用量线性增长；私有化部署是固定算力成本+运维成本，存在明确的成本拐点。通常单月调用量持续超过千万级token时，私有化部署的单位成本会低于主流闭源API，且规模越大优势越明显。

3. 定制化深度需求：仅需通用问答、基础推理能力，闭源API能力足够；需要领域深度微调、专属知识库嵌入、业务逻辑深度定制，开源模型的可控性优势会随业务深入逐步放大。

4. 交付周期与团队能力：MVP验证阶段优先闭源API快速跑通业务闭环；业务验证通过、规模起来后，再平滑迁移至混合架构或私有化架构，避免一开始就投入重型基建。

决策原则

优先采用混合底座架构：通用能力、低敏感请求走闭源API，核心业务、高敏感数据走私有化开源模型；通过统一的模型网关做路由分发，业务层无感知，支持后续平滑切换底座，避免技术绑定。

二、RAG架构：从原型到生产，每一层都是权衡题

检索增强生成（RAG）是当前企业级AI应用的主流架构，但从Demo到生产，每一个组件选型都充满工程权衡，不存在“一步到位的最优解”。

1. 检索策略选型：稀疏、稠密还是混合？

真实困境：很多团队上来直接上向量检索，认为“语义检索更先进”，结果上线后发现短词查询、专有名词召回准确率远不如传统关键词检索，且运维复杂度大幅上升。
思考逻辑：

• 稀疏检索（BM25/关键词）：对结构化文本、专有术语、短查询效果好，实现简单、成本极低，是所有场景的基线能力。

• 稠密检索（向量检索）：对长文本语义理解、模糊查询、同义表述召回优势明显，但对训练数据敏感，小语种、垂直领域效果衰减明显，且需要额外的向量数据库与embedding模型成本。

• 混合检索：两路召回后做融合排序，效果最优，但架构复杂度、推理耗时、运维成本同步上升。
决策原则：没有特殊语义诉求的场景，先以稀疏检索做基线，再用稠密检索做效果补充；万级以内知识库，纯稀疏检索即可满足80%需求，避免过度设计。垂直领域必须做领域embedding模型微调，否则纯通用向量检索效果大概率不及预期。

2. 文档分片策略：规则分片 vs 语义分片

真实困境：固定长度分片实现简单，但极易出现上下文断裂，导致检索片段语义不完整，模型回答错误；语义分片效果好，但分片耗时是规则分片的数倍，大文档入库效率极低。
思考逻辑：

• 规则分片（按字符/Token数+重叠）：适合结构化强、段落清晰的文档（如产品手册、API文档），实现成本低、入库速度快，配合合理的重叠窗口可解决大部分上下文断裂问题。

• 语义分片（按句子/段落语义边界）：适合长文本、逻辑连贯的文档（如论文、合同、书籍），能最大程度保留语义完整性，但依赖NLP模型做语义分割，入库成本高、耗时久。
决策原则：优先采用“规则分片+语义边界优化”的折中方案，以固定长度为基础，优先在标点、段落处切分，兼顾效率与效果；仅对质量要求极高的核心知识库，才使用全语义分片。

3. 检索层级：单层召回 vs 粗排+精排

真实困境：知识库规模突破十万级后，单层检索的准确率明显下降；直接上重排模型，推理延迟增加30%以上，算力成本翻倍。
思考逻辑：

• 单层检索：适合十万条以内的中小规模知识库，结构简单、延迟低，满足绝大多数内部知识库场景。

• 粗排+精排两级架构：粗排多路召回归一化打分，精排用CrossEncoder或小模型做精细化排序，在百万级以上知识库中效果提升显著，但增加了链路复杂度与推理成本。
决策原则：按数据规模阶梯式升级。先验证单层检索的效果瓶颈，再引入精排；精排模型优先选用轻量小模型，优先保障延迟与成本可控。

三、交互架构：同步与异步，单体与分布式的演进边界

AI应用的交互模式与传统Web应用差异极大，大模型推理的长耗时特性，让同步/异步架构、服务拆分的选型变得至关重要。

真实困境

• Demo阶段用同步单体架构快速落地，上线后业务量上涨，大模型推理单请求耗时数秒，同步调用频繁超时，服务被拖垮。

• 一开始就做全分布式微服务拆分，模型服务、检索服务、业务服务各自独立，研发周期拉长，且链路太长导致排查问题困难，小团队根本运维不动。

架构师的核心思考维度

1. 交互场景决定通信模式

◦ 实时对话、流式输出类场景：必须采用同步+流式响应架构，优先SSE（Server-Sent Events）协议，实现简单、适配单向流式输出，满足绝大多数对话场景；仅在需要双向实时交互时，才选用WebSocket。

◦ 长任务处理（文档解析、批量生成、数据分析）：必须采用异步架构，通过任务队列+状态回调机制实现，前端轮询或回调通知，避免请求超时与连接阻塞。

2. 服务拆分的渐进原则

◦ MVP阶段：单体架构，业务逻辑、检索、模型调用打包部署，优先快速验证业务，减少运维复杂度。

◦ 增长阶段：核心依赖独立拆分，优先把模型推理服务拆出独立部署，做成模型服务池，与业务逻辑解耦；检索服务随数据规模升级再独立拆分。

◦ 规模化阶段：按领域拆分业务服务，模型服务做统一平台化，支持多业务复用算力。

3. 容错与降级的前置设计
无论哪种架构，都必须前置设计降级链路：模型服务超时自动切换备用模型、检索失败走兜底回答、大流量场景自动关闭非核心能力。架构选型时，容错能力的优先级高于峰值性能。

四、Agent架构：克制的能力边界，拒绝技术炫技

Agent是当前AI领域的热点，但也是架构选型中最容易过度设计、技术炫技的重灾区。

真实困境

业务提出“做一个智能助手”，技术团队直接上全功能Agent框架，支持多工具调用、多轮规划、自主决策，结果上线后任务完成率低、幻觉严重、推理步骤不可控，单次调用成本是普通RAG的3-5倍，业务价值远不及预期。

架构师的核心思考：先判断“要不要用Agent”

绝大多数场景不需要真正的自主Agent。先明确能力边界：

• 不需要Agent：知识问答、固定流程查询、单工具调用、模板化生成。这类场景用RAG+提示词工程+固定工具调用即可实现，成本低、效果可控、稳定性高。

• 需要Agent：多步骤动态决策任务、跨系统复杂操作、需求不明确的开放式任务、需要自主规划路径的探索类场景。

Agent架构的选型原则

1. 原型验证用框架，生产环境做精简。LangChain等全栈Agent框架适合快速验证原型，但生产环境必须做轻量化改造：核心保留“状态机+工具注册+调度逻辑”，剔除冗余的链式抽象，避免黑盒化导致的调试与性能问题。

2. 优先有限状态机Agent，不做无限自主推理。生产级Agent必须限定步骤、限定工具、限定输出格式，通过预设流程+人工兜底的模式，把任务完成率、可控性放在第一位，而不是追求“完全自主”。

3. 人机协同设计：架构上必须预留人工介入节点，Agent处理失败、置信度不足时自动流转人工，这是生产可用的前提。

五、组件选型：轻量起步与重型组件的演进节奏

AI技术栈组件繁多，向量数据库、模型推理框架、编排框架……选型最容易犯的错，就是“一开始就上最重型的方案”。

典型选型决策场景

1. 向量数据库选型

◦ 万级以内数据、单机部署：用FAISS、Chroma等轻量向量库即可，无需独立部署，运维成本为零。

◦ 十万-百万级、高可用要求：选用Milvus、Pinecone等分布式向量数据库，支持水平扩展、多副本高可用。

◦ 误区警示：不要为了“未来可能扩容”，一开始就上分布式向量库，额外的运维成本、网络开销，在小数据量下完全是负收益。

2. 推理引擎选型

◦ 原型/小流量：直接用原生Transformers推理，无需额外优化，快速验证。

◦ 在线高并发：大模型场景切换vLLM/TensorRT-LLM，吞吐提升数倍；小模型场景用ONNX/TensorRT做固化加速。

◦ 决策原则：先跑通业务，再做性能优化；出现性能瓶颈时，再替换推理引擎，而不是提前过度优化。

六、隐性决策：非功能需求决定架构的最终上限

很多架构选型只关注功能效果，却忽略非功能需求，最终导致架构上线后被迫重构。这是架构师必须前置考虑的隐性决策。

1. 安全合规：选型初期就要明确数据流向，哪些数据能进模型、哪些必须脱敏、日志是否能留存敏感信息。闭源API架构必须前置数据脱敏网关，私有化架构要考虑网络隔离、权限管控。

2. 可观测性：AI系统的故障大多不是服务宕机，而是效果退化。架构选型时必须预留埋点能力：检索召回率、模型置信度、输出质量、用户反馈，都要在架构设计时就纳入可观测体系，不能后期补建。

3. 成本可控性：架构决定成本上限。每引入一个模型、一个组件，都要同步评估算力成本与运维成本。很多架构方案效果提升有限，但成本翻倍，在业务价值不明确的场景，必须果断放弃。

4. 团队适配性：再先进的架构，团队运维不住就是坏架构。小团队优先选成熟、生态完善、学习成本低的方案；有专门AI工程团队的组织，才考虑深度定制化的重型架构。