AI架构决策框架

精调、RAG与提示工程的选择

确定了模型来源后，下一个决策是如何让通用模型适配特定业务场景。三种主要的定制手段各有适用条件：

• 提示工程（Prompt Engineering）是起步成本最低、迭代速度最快的方案。通过精心设计系统提示词、构造少样本示例、采用思维链（Chain-of-Thought）引导，可以显著提升模型在目标任务上的表现。适用条件：任务可以用自然语言清晰描述、公开知识足以支撑回答质量、业务逻辑变化频繁需要快速调整。在百炼平台上，提示词可以通过应用配置界面快速迭代和A/B测试。

• 检索增强生成（RAG）在提示工程基础上引入外部知识检索，适用于：模型需要访问企业私有知识（产品文档、内部规章、客户数据）；知识频繁更新（如每周更新的产品价格表）；需要提供可溯源的答案（引用具体文档和段落）。百炼平台的知识库功能提供端到端的RAG管道——从文档上传、自动分块、向量化存储到检索召回，降低了RAG系统的构建门槛。

• 模型微调适用于提示工程和RAG无法满足的场景：需要模型掌握全新的表达风格或专业术语体系（如法律文书的特定格式）；需要模型在少量Token内完成原本需要大量提示词引导的任务（降低运行时成本）；任务的评估标准高度主观且需要从大量人类偏好数据中学习。PAI平台支持全参数微调和LoRA等参数高效微调方法，并提供训练数据管理和模型评估的完整工具链。

在实践中，这三种手段往往是组合使用的。一个典型的渐进路径是：先用提示工程快速验证可行性→加入RAG引入企业知识→对核心场景补充微调以提升一致性。DataWorks可以用于管理RAG管道中的数据预处理工作流，确保知识库数据的质量和时效性。

单模型、模型路由与模型集成

最后一个维度是模型的组合策略：

• 单模型方案最简单——选择一个综合能力最强的模型处理所有请求。适用于业务场景单一、请求复杂度分布均匀、成本不是首要约束的情况。例如，一个面向企业内部高管的战略分析助手，请求量少但要求极高质量，使用Qwen-Max单模型即可。

• 模型路由（Model Routing）在请求复杂度分布不均时价值显著。典型模式是设置一个轻量级的分类器（可以是规则引擎、小模型或启发式算法），根据请求特征将其路由到不同规格的模型。例如：对话中的简单寒暄路由到Qwen-Flash；需要知识检索的普通问题路由到Qwen-Plus配合RAG；需要复杂推理或创意生成的请求路由到Qwen-Max。百炼工作流可以编排这种路由逻辑，并记录路由决策以便后续优化。

• 模型集成（Model Ensemble）在决策正确性要求极高的场景中使用。多个模型对同一请求独立生成响应，通过投票、加权融合或一致性检查确定最终输出。适用于金融风控、医疗诊断建议等容错性极低的场景。代价是成本和时延成倍增加。实际操作中，可以用两个较小模型的共识来替代一个超大模型，在部分场景下实现更优的成本质量比。

取舍矩阵

模型策略的核心取舍可以沿四个维度展开：

• 时延维度：API模型通常有网络开销（50-200ms），自托管模型可优化到极低时延但需要运维投入。模型越大推理越慢，但MoE（Mixture of Experts）架构在保持大模型能力的同时控制了推理开销。

• 成本维度：API按Token计费，成本与用量线性相关，适合波动型负载。自托管按GPU时长计费，有固定成本但边际成本低，适合稳定高负载。微调模型增加一次性训练成本但可能降低运行时Token消耗（更少的提示词即可完成任务）。

• 质量维度：更大参数的模型通常质量更优，但未必在所有任务上都如此。微调后的小模型在特定垂直任务上可能超越通用大模型。RAG显著提升事实性但增加系统复杂度。

• 数据隐私维度：API模型意味着数据离开企业边界（即使加密传输），自托管模型数据不出网络。微调需要将训练数据上传到训练平台（PAI支持VPC内训练降低风险），RAG的知识库数据需要评估存储位置的合规性。

何时重新评估模型策略：当模型API调用成本连续三个月超出预算20%以上时；当新一代模型发布且性价比提升超过50%时；当数据隐私要求因法规更新而提高时；当自托管模型的运维团队无法及时跟进安全补丁时。

纯向量检索、混合检索与图增强RAG

纯向量检索是RAG系统最基础的形态：将文档切分为块（Chunk），转换为嵌入向量存储在向量数据库中，检索时将用户查询向量化后进行近似最近邻搜索，返回最相似的文档块作为上下文。这种方式实现简单、对非结构化文本效果良好。适用场景：FAQ问答（用户问题与答案在语义上高度相关）、简单的文档检索（如产品手册查询）。百炼知识库的默认模式即为向量检索。

但纯向量检索有明显局限：它只捕捉语义相似度，无法处理精确匹配需求（如用户查询特定的产品编号"SKU-20240315"）、无法利用结构化元数据进行过滤（如"只看2026年发布的文档"）、在需要理解实体间关系的复杂问题上表现欠佳。

混合检索（Hybrid Retrieval）结合向量语义搜索和传统的关键词搜索（BM25），并引入元数据过滤。检索时同时执行语义搜索和关键词搜索，然后通过重排序模型（Reranker）对两路结果进行融合排序。这种方式兼具语义理解能力和精确匹配能力，是企业级RAG系统的主流选择。适用场景：企业文档库（文档有明确的类别、日期、作者等元数据）、技术知识库（既有概念性描述也有精确的配置参数）、客服知识库（既有语义相似的FAQ也有需要精确匹配的订单号和产品型号）。百炼知识库支持混合检索模式，AnalyticDB PostgreSQL版提供底层的向量+全文索引融合能力。

图增强RAG在混合检索基础上引入知识图谱，对实体间的关系进行显式建模。当用户的问题涉及多跳推理（如"张三负责的项目中使用了哪些A供应商的组件？"）时，纯语义检索难以跨文档关联信息，而知识图谱可以通过实体关系路径快速定位。适用场景：涉及复杂实体关系的专业领域（供应链管理、组织架构分析、学术文献引用网络）、需要多跳推理的问答（答案分散在多个文档中，需要通过逻辑链条串联）。构建图增强RAG的复杂度和维护成本显著高于前两者，建议仅在纯检索+混合检索无法满足精度要求时才引入。

托管知识库与自建管道

百炼平台的知识库功能提供开箱即用的RAG管道：上传文档→自动解析→智能分块→向量化→索引构建→检索API。整个过程几乎不需要工程投入，适合快速验证RAG可行性和中小规模知识库场景。其优势在于：开发效率高（分钟级搭建）、运维免操心（平台自动管理索引和计算资源）、与百炼应用无缝集成。

但托管知识库的定制空间有限：分块策略难以精细控制（如针对代码和表格使用不同的分块逻辑）、预处理管道无法插入自定义的清洗步骤（如脱敏、术语规范化）、检索策略的可调参数有限。当企业对RAG质量有极致追求时，可能需要自建数据管道。

自建管道意味着自行搭建从数据摄入到检索服务的完整链路：文档解析（PDF/Word/网页等格式处理）→预处理（清洗、脱敏、元数据提取）→分块（按语义段落、固定大小或层次结构切分）→嵌入（调用DashScope嵌入模型或自训练嵌入模型）→索引存储（AnalyticDB PostgreSQL版、Lindorm或Elasticsearch）→检索服务（自定义召回策略和重排序逻辑）。DataWorks可以编排这条数据管道的定时执行和增量更新逻辑。

选择的关键考量：团队规模5人以下且AI不是核心业务→托管知识库快速起步；团队有专职数据工程师且RAG质量是核心竞争力→自建管道获取完全控制；介于两者之间→从托管知识库起步，在明确了瓶颈所在后针对性地自建特定环节。

数据新鲜度与架构含义

知识库中数据的时效性要求直接决定了数据管道的架构复杂度：

• 实时更新（秒级至分钟级）：适用于客服场景中的订单状态、库存信息等时刻变化的数据。架构模式为流式管道——通过消息队列（如Kafka/RocketMQ）监听数据变更事件，实时触发增量向量化和索引更新。复杂度最高，需要处理一致性、乱序和重复消息问题。

• 准实时更新（小时级）：适用于新闻、公告、产品文档等更新频率中等的内容。架构模式为定时调度——通过DataWorks配置小时级或天级的数据同步任务，批量处理增量数据并更新索引。复杂度适中，是大多数企业知识库的务实选择。

• 静态或低频更新（周级至月级）：适用于政策法规、培训教材、历史档案等变化极少的内容。架构模式为手动或定期全量重建——一次性处理全量文档，在内容发生重大变更时手动触发重建。复杂度最低，百炼知识库的默认模式即可满足。

召回精度、时延与存储成本的取舍

数据架构的三角取舍贯穿设计始终：

• 提升召回精度的手段（如更小的分块粒度、更高维度的嵌入向量、引入重排序模型、增加召回候选数量）通常会增加存储成本和检索时延。一个1亿向量、1536维度的索引需要约600GB存储，每次搜索的时延可能在50-100毫秒。

• 降低时延的手段（如使用内存型向量索引、减少召回候选数、简化重排序逻辑）可能牺牲召回精度。将索引完全加载到内存可以将搜索时延压缩到个位数毫秒，但内存成本远高于磁盘。

• 控制存储成本的手段（如降低向量维度、使用量化压缩、增大分块粒度减少总向量数）可能影响召回精度。乘积量化（PQ）可以将向量存储压缩到原来的1/4，但会引入一定的精度损失。

架构师需要根据具体场景确定优先级：面向用户的实时问答优先保证时延（P95 < 200ms）和基本精度；面向分析师的深度研究助手优先保证召回精度（允许数秒时延）；面向海量文档存储的归档检索优先控制存储成本。

何时重新评估数据架构：当RAG系统的回答准确率持续低于业务要求时（可能需要从纯向量升级到混合检索或图增强）；当知识库规模增长导致检索时延超出SLA时；当数据新鲜度要求从天级提升到分钟级时。

单智能体与多智能体编排

单智能体架构是最直接的实现方式：一个智能体具备理解意图、调用工具和生成响应的全部能力。适用条件：任务范围明确且有限、所需工具在10个以内、不涉及复杂的角色分工和流程协调。例如，一个日程管理智能体——它能理解"帮我约明天下午3点和张总开会"的请求，调用日历API查询空闲时段、创建会议邀请、发送通知——全部由单个智能体完成。

当任务复杂度超出单智能体的处理能力时，多智能体编排（Multi-Agent Orchestration）成为必要选择。复杂度的信号包括：需要不同的专业知识和工具集（如一个智能体擅长代码分析，另一个擅长文档理解）；需要并行执行多个子任务并汇总结果；需要角色间的制衡（如一个智能体生成方案，另一个审核方案的合规性）；单智能体的上下文窗口不足以容纳所有任务信息。

多智能体编排的常见模式包括：主从模式（Orchestrator Pattern）——一个编排器智能体负责任务拆解和分发，多个专业智能体执行具体子任务；流水线模式（Pipeline Pattern）——智能体按固定顺序依次处理，每个智能体的输出是下一个的输入；辩论模式（Debate Pattern）——多个智能体从不同角度分析问题，通过"辩论"收敛到最优答案。

工具调用型、工作流驱动型与自主型

智能体的内部架构可以按自主性程度分为三类：

• 工具调用型智能体（Tool-calling Agent）以模型的工具调用能力为核心——模型决定何时调用什么工具、如何解析工具返回的结果。执行路径是动态的，由模型在每一步根据上下文决定下一步动作。适用于：问题空间开放、无法预定义所有可能的执行路径、需要灵活应对各种用户请求。例如，一个通用的数据分析助手——用户可能问任何问题，智能体需要动态决定查询哪个数据源、执行什么分析、如何可视化结果。

• 工作流驱动型智能体（Workflow-driven Agent）按预定义的流程图执行。每个节点是一个确定性的操作步骤——可能是模型调用、工具调用、条件判断或人工审批。执行路径在设计时就已确定（虽然可能有分支），运行时按流程图走。适用于：流程固定且合规要求严格的业务场景，如贷款审批（先征信查询→再收入验证→再风险评估→最终决策）、医疗分诊（先症状收集→再紧急度判断→再科室推荐）。

• 自主型智能体（Autonomous Agent）具备最高的自主性——它可以自行设定子目标、规划执行步骤、在执行中反思和调整策略。适用于：需要长时间运行的复杂研究任务（如"分析这个行业的竞争格局并生成报告"）、不确定性高的探索性任务。自主型智能体的风险也最高——失控的自主智能体可能陷入无限循环、产生高额API调用费用、或执行非预期操作。因此必须设置明确的终止条件（最大步数、最大Token预算、超时限制）和检查点（关键决策前暂停等待人工确认）。

同步与异步执行

智能体的执行模式取决于任务耗时和用户交互模式：

同步执行适用于快速完成的任务（数秒内）——用户提问、智能体处理、直接返回结果。这是大多数对话场景的默认模式。架构要点：需要控制总执行时间（设定超时上限），工具调用也要有时延约束（某个API无响应不应阻塞整个请求）。

异步执行适用于需要较长时间完成的任务——用户提交任务后可以离开，任务完成后收到通知。例如，"帮我分析过去3个月的销售数据并生成周报"可能需要数分钟：检索多个数据源、执行数据分析、生成图表、撰写文字报告。异步架构需要设计：任务状态追踪（待处理、执行中、已完成、已失败）、执行进度上报（让用户了解当前进展）、中间结果持久化（防止长时间运行中途失败后丢失已有成果）、结果通知（通过消息、邮件或界面推送告知用户）。

混合模式结合两者：智能体先同步返回一个快速的初步回答（如"我正在分析您的数据，预计需要3分钟"），然后异步执行详细分析，完成后再推送完整结果。

总拥有成本对比框架

AI系统的TCO（Total Cost of Ownership）远不止云资源费用。一个完整的TCO评估应包含以下维度：

• 开发成本：从零构建的工程投入，包括架构设计、代码开发、测试验证。SaaS几乎为零，PaaS需要应用层开发（人周级），IaaS需要全栈开发（人月级到人年级）。

• 运维成本：持续运行的人力投入，包括模型服务监控、故障排查、版本更新。SaaS由供应商承担，PaaS的平台侧由阿里云承担（应用侧自行维护），IaaS全部自行承担。

• 模型更新成本：跟随基础模型演进的投入。SaaS自动获得更新，PaaS通过配置切换即可使用新模型版本，IaaS需要自行完成模型替换、评估、重新部署的完整流程——如果有微调模型还需要重新训练。

• 合规成本：满足监管要求的投入。SaaS通常由供应商完成备案（但需确认覆盖你的使用场景），PaaS的平台级合规由阿里云保障（应用级备案仍需企业自行完成），IaaS的所有合规工作完全由企业自行承担。

• 机会成本：选择A方案而放弃B方案所损失的潜在收益。长时间自建AI系统意味着推迟了AI能力的上线时间——在快速变化的市场中，6个月的时间差可能意味着失去先发优势。这一隐性成本往往被低估。

• 退出成本：未来更换方案的迁移投入。深度绑定某个SaaS供应商可能面临数据迁出困难；自建的高度定制化系统可能因为架构绑定而难以迁移到更优方案。架构设计时应考虑合理的抽象层以降低退出成本。

团队能力评估与推荐路线

团队的AI工程能力是决策的关键约束——技术上最优的方案如果超出团队能力，在实践中反而是最差的选择。

• 无专职AI/ML团队：企业的AI需求由业务开发团队兼任，没有专门的算法工程师和MLOps角色。推荐路线：优先评估SaaS方案是否满足需求；如不满足，使用百炼平台的低代码能力构建应用——利用平台的智能体编排、知识库管理和模型评估功能，将AI专业度的门槛降到最低。核心投入放在业务场景理解和提示词优化上，而非底层工程。

• 小规模AI团队（3-10人）：企业有少量算法工程师和AI应用开发者，具备一定的模型评估和数据处理能力。推荐路线：以百炼平台为核心底座，在平台标准能力满足的场景快速交付，对核心差异化场景投入深度定制。可以利用PAI平台进行有选择的模型微调，通过DataWorks建设自主的数据管道。关注点在于识别哪些环节值得自建投入、哪些应继续使用平台能力。

• 大规模ML工程团队（10人以上）：企业拥有完整的AI研发体系，包括算法研究、模型训练、推理优化、数据工程、MLOps等角色。推荐路线：IaaS+PaaS混合——核心模型能力自建以获取最大控制力和成本优势（在ACK上部署自定义推理服务、在PAI上运行大规模训练），周边能力使用平台服务以提升效率（如使用百炼的内容安全审核）。将工程力量聚焦在真正构建竞争壁垒的环节。

无论团队规模如何，一个共同的建议是：从百炼平台开始概念验证（PoC），以最小投入验证业务价值。在PoC阶段确认AI方案确实能解决业务问题后，再根据团队能力和长期战略决定是停留在平台层还是向自建方向演进。过早的自建投入是AI项目最常见的资源浪费模式——许多企业花了半年自建推理服务，最终发现业务场景根本不成立，或者平台方案早已满足需求。

架构师应当在每个决策节点记录决策依据和假设条件，以便当外部条件变化时（如团队扩张、业务规模增长、新模型发布、监管政策调整）能够快速重新评估并调整路线。AI架构不是一次性的设计，而是随业务演进而持续优化的动态过程。

何时重新评估技术路线：当PaaS平台的功能限制连续阻塞需求超过三次时（可能需要向IaaS演进）；当SaaS方案的定制化成本开始接近自建成本时；当团队AI工程能力在6-12个月内显著增长时。