简介Gartner 2024年11月发布的《生成式人工智能技术创新指南》G00793932面向企业技术领导者、架构师与AI规划人员用于厘清GenAI在各技术栈层级与垂直行业的渗透路径并借助配套的新兴市场象限考察供应商格局。整包为1个PDF文件约1.28MB、35页保留关键发现、行动建议与供应商分析等章节可直接用于内部技术分享与选型参考目前已有57人学习下载。文中指出GenAI并非单一市场而是从底层基础设施、开发工具到终端应用全栈嵌入DSML、CRM、ERP等传统平台也在整合相关能力投资主线集中于基础模型尤其是大语言模型首波供应商聚焦内容与体验生产AI代理则连接LLM与软件工程推动第二波创新。报告还给出降低试点技术债、模型松耦合选型、构建语义数据层与负责任AI实践等建议便于读者判断自身阶段并规划架构演进。1. 生成式AI不是一个市场为什么市场定义本身就是一道架构题生成式AIGenAI从来不是一块能用市场份额切分的独立蛋糕。把它当成一个市场去问这块饼有多大答案一定失真它同时存在于加速卡的显存带宽里、存在于模型API的计价单位里、存在于代码编辑器的补全光标下也存在于CRM的会议摘要按钮里。一份面向技术决策者的生成式AI技术创新指南给出的第一条判断就是GenAI本身不是一个市场它渗透进整个技术栈和大多数垂直领域。真正值得深入思考的问题是一个没有清晰市场边界的技术凭什么能被企业当作架构资产来规划答案藏在分层里一旦你接受GenAI是一种新的人机接口方式而不是一款可以采购的软件技术栈的每一层就必须回答同一个问题——这一层该由谁承担演进风险又该由谁承担评测责任。2. 四层技术栈边界为什么必须画在算力、模型、工程和应用之间把一个渗透性技术强行切成四层看起来是多此一举。但分层的目的不是分类学而是把谁承担什么样的失败这件事固定下来。基础设施层失败表现为容量与成本失控模型层失败表现为能力突然落后或合规暴露工程层失败表现为迭代效率崩塌应用层失败表现为用户不信任。这四类失败的处置手段完全不同混在一起谈就会变成AI项目效果不好这种无法行动的结论。分层之后每一层对应一类采购决策、一类技术债和一类验收标准架构评审才有一致的基础。2.1 基础设施层训练和推理是两种完全不同的负载基础设施层由两股力量占据做加速计算的芯片厂商以及提供IaaS与PaaS的超大规模云服务商。看上去都是卖算力实际上它们在满足两种性质相反的需求。训练是吞吐密集型的长周期任务容错靠定期检查点硬件利用率比单次响应时间重要得多推理是延迟敏感的突发负载请求量随时间剧烈波动需要弹性伸缩和快速冷启动。这两件事对存储、网络、显存容量的要求并不重合用一个集群同时优化它们通常是两头都不讨好。这也解释了企业侧一个反复出现的选择很少自建训练集群但会把部分推理下沉到离用户更近的地方。原因不在成本而在采购周期。自建数据中心从立项到交付以季度计而模型的版本迭代以周计硬件还在路上需求形状已经变了。常见的实现思路是把训练留在云上、把推理按流量特征分层高频短请求走常驻实例长尾请求走按需实例最敏感的那部分走边缘节点。这个分层动作一旦做了基础设施层就从花钱买算力变成给推理流量做路由后面所有成本优化才有依据。云服务商自研加速芯片的动机也在这里。它不只是为了省钱而是垂直整合——把上层SaaS应用和下层算力的毛利留在同一体系内同时降低对单一芯片供应方的依赖。对买方来说这条信息的意义在于不要假设算力价格会单调下降。当供给方在整合价格结构的波动性反而上升容量规划里必须留出可迁移的余地比如让训练任务能接受不同加速卡型号用编译层和算子兼容层把硬件差异挡住。2.2 模型层为什么这一层的价值捕获点最不稳定模型层的竞争态势和其他三层都不同。提供商业闭源模型的公司用模型支撑自己上层应用的经济模型同时通过API把模型本身作为商品出售还允许合作伙伴在自有基础设施上部署实例再包一层企业级安全与隐私。两条腿走路既卖能力也卖应用。开源模型则从另一边压缩定价空间——它的意义不是免费而是把开发者的迁移成本降到可以随时换供应商的程度。真正改变力量对比的是三件事同时发生模型在特定用例上开始变小、精调所需的数据和人工输入被流程化、领域模型带深度横向或纵向术语与上下文和轻量模型面向云端与边缘的低成本、小体积推理出现。结果是买方的可选择项变多单一模型厂商的定价权下降。从架构角度看这意味着一件很朴素但经常被忽略的事模型是消耗品不是地基。如果模型是消耗品那么模型质量就不是一个可以一次性拍板的属性而是一条随时间波动的曲线。你今天选的模型可能在某个基准上领先六周后另一家追平三个月后成本只有它的三分之一。把业务逻辑写死在某个模型的提示格式、特定参数、特定结构化输出约定里等于把技术债锁进了最难重构的那一层。常见的实现思路是把模型能力抽象成一组声明式属性——上下文窗口、每百万token的价格、首token延迟、是否支持工具调用、是否支持结构化输出——再让上层按属性选模型而不是按品牌名。2.3 工程层和应用层之间那条模糊的线AI工程工具覆盖模型的完整生命周期开发、精调、部署以及把生成式模型和其他生成式产物在生产应用中跑起来的整体流程编排。GenAI应用则用生成能力改善用户体验、增强任务完成度把生成与编辑文本、代码、图像、多模态输出嵌进具体任务里。两者的边界在实践中极难分清因为精调一个模型和给应用做一个功能在代码仓库里往往就隔着几个目录。我一般用一条准则来划这条线如果一件事的好坏必须靠你自己的评测集才能判断它就属于工程层不该外包给应用。举例来说摘要功能是应用层的产物但摘要的忠实度是否达标属于工程层因为只有你才知道哪些内容不允许被改写、哪些术语必须原样保留。一旦把评测责任交给应用供应商你买到的是一个会随时间漂移的黑匣子说明书而不是一个可验证的指标。3. 松散耦合为什么能换掉模型必须是架构的第一性要求设计目标只有一句解决方案要与生成式模型松散耦合以便灵活地选型和组合。这句话在文档里往往一笔带过但要真正落地需要拆成三层接口层的模型抽象、数据层的语义化、以及两者之间的上下文组装。少任何一层松散耦合都会退化成换模型的时候改三十个文件。3.1 模型抽象层要抽象什么抽象层最容易犯的错误是只抽象了调用这一件事——包一个函数把模型名作为参数传进去然后宣称已经解耦。真正的耦合点根本不在这里。它藏在提示模板的写法、结构化输出的解析方式、工具调用的协议、错误码的含义、以及计费粒度上。一个支持多模型的路由层至少要表达四组信息能力是否支持视觉输入、是否支持函数调用、上下文窗口多大、成本输入输出分别计价以及缓存命中是否折价、性能首token延迟与整体吞吐、合规数据驻留区域、训练数据来源可说明性。这四组信息不是一成不变的常量它们会随版本迭代变化所以更合适的做法是把它们当成运行时元数据而不是编译期常量。举例来说某个任务需要处理一份两百页的合同上下文窗口不够时不应该报错而应该触发降级路径切到检索增强把相关段落召回后拼入上下文或者切到分段摘要再汇总。这个降级逻辑写在路由层业务代码完全不需要知道。3.2 语义数据层让模型有据可依而不是自由发挥第二层是语义数据层。企业知识资产——内容、数据、规则与启发式、语料、数字孪生模型、知识图谱——的作用不是喂给模型训练而是在推理时提供上下文让模型的行为被锚定到企业的真实状态上。这个动作常被称为grounding接地。它的机制很直白模型的参数里存的是分布式的、去具体化的语言规律它不知道你公司上个月改了退款政策检索层把当前有效的政策片段取出来放进上下文模型的输出才可能对得上。幻觉的很大一部分不是模型胡说而是上下文里根本没有正确答案它只能按语言概率补全。这里有经验的开发者会强调一个顺序问题如果你还没有为业务建立语义数据层现在就开始而不是等模型能力再强一点。原因在于grounding的收益不是线性的——它取决于检索质量、切片策略、以及知识的更新时效。模型变强只能让你在同样的上下文里答得更好但没法替你召回一段你压根没索引的内容。注意把提示词当知识库是常见的偷懒做法。提示词适合放规则和格式约束不适合放会变化的业务事实。一旦事实变了你会在几十个提示模板里找同一句话。3.3 一个可落地的路由配置长什么样把上面的思路写成配置比写成架构图更能暴露问题。下面这段配置描述的是任务类型到模型候选集的映射关键在候选集和降级链而不是具体型号。# 任务级模型路由业务代码只声明任务类型不写模型名 routes: doc_summarize: # 任务长文档摘要 candidates: # 候选按优先级排列运行时可热替换 - profile: large_ctx # 能力标签由模型元数据解析成具体型号 max_input_tokens: 200000 fallback: chunk_summarize # 超出窗口时的降级策略 - profile: cheap_fast max_input_tokens: 32000 budget: cost_per_call_usd: 0.12 # 单次调用成本上限超出即降级 p95_latency_ms: 4000 # 延迟上限超出即切换候选 guardrails: require_source_citation: true # 输出必须带可追溯的原文片段 pii_redaction: true # 上下文进入模型前做脱敏 code_review: # 任务代码评审建议 candidates: - profile: code_strong require_tool_call: true # 必须具备函数调用能力用于拉取仓库上下文 budget: cost_per_call_usd: 0.40这段配置里profile是能力标签而非具体型号换供应商时只改元数据表路由定义不动fallback把上下文超限这种最常见的失败变成了预设路径而不是运行时异常budget把成本和延迟变成硬约束避免某个任务悄悄吃掉整个季度的预算guardrails里的require_source_citation是治理的前置动作——要求输出附带原文片段事后审计才有据可查。参数改法也很直接把p95_latency_ms调低会更快触发切换代价是候选集命中率下降把cost_per_call_usd调高会减少降级但预算消耗曲线会变陡。上线前建议先用历史流量回放一遍看降级触发比例落在什么区间。4. 智能体把模型接到工具上为什么第二波冲击比第一波更结构性第一波供应商围绕快速生产内容与体验展开靠企业信息和知识库加持。这一波的输出终点是人——生成一段文案、一张图、一段代码人来判断、人来执行。第二波不一样把大语言模型接到软件工程和各类工具上让输出直接变成动作。动作有副作用副作用要回滚回滚需要状态管理。这就是为什么智能体agent技术带来的不是功能增量而是架构策略的位移。4.1 从内容生成到流程接管机制差异在哪从机制上看内容生成是一次函数调用输入上下文输出文本智能体是一个循环模型在循环里决定下一步调用哪个工具、传什么参数、看到结果后是否继续。支撑这个循环的是大行动模型LAM方向的研究进展它让模型不只是理解语言还能把自然语言意图映射成对工具的结构化调用。2024年生成式智能体平台的出现本质上是把这个循环产品化了。差异带来的第一个后果是评测方式变了。内容生成用BLEU、人工打分、忠实度检查就够了智能体要评的是任务完成率、步数、以及失败后的可恢复性。一个能完成80%任务但剩下20%会把系统改坏的智能体比一个只能完成60%但从不出错的智能体危险得多。第二个后果是权限模型必须重写。当模型可以调用写接口它的输出就不再是建议而是操作必须走和人类操作员同一套鉴权与审计而不是另一套更宽松的。4.2 多智能体与仿真二阶效应从哪里来单智能体解决的是把多个任务串起来的流程多智能体解决的是多个角色协作的流程。后者听起来像概念包装但它对应一个真实的技术问题当一个流程需要不同领域的判断时把全部规则塞进一个上下文会互相干扰拆成若干各带专用上下文和工具的智能体再由一个编排层协调反而更容易调试。生成式能力在仿真场景里的用法也类似——不是生成一段描述而是持续生成状态转移让系统在虚拟环境里预演。这类架构会推动市场从卖应用转向卖可组合的系统。买方不再只问这个应用对我有多大价值还要问它能不能和我已有的其他AI组件拼成更大的系统。这也是为什么评估供应商时必须同时看两件事用例价值以及它在整体AI架构里的可耦合性。4.3 编排的代价状态、幂等与可观测性把模型接进工作流最先出问题的往往不是模型而是编排。下面这段伪代码展示的是一个最小可用的智能体循环注释里标出了三个必须处理的点。def run_agent(task, tools, max_steps8): state {history: [], artifacts: {}} for step in range(max_steps): # 1) 上下文预算历史过长时压缩而不是无限追加 ctx compress(state[history], budgetTOKEN_BUDGET) # 2) 工具调用必须带幂等键重试不会产生重复副作用 decision llm.decide(tasktask, contextctx, toolstools.schema()) if decision.type tool_call: result tools.invoke( namedecision.name, argsdecision.args, idempotency_keyf{task.id}:{step}:{decision.name}, ) state[history].append({call: decision.name, result: result}) elif decision.type final: return decision.output # 输出需附带来源片段供审计 # 3) 每一步都打点步数、耗时、token、工具成功率 metrics.emit(task.id, step, decision.type) raise StepLimitExceeded(task.id) # 触顶要显式失败不能静默返回半成品这段代码里compress对应上下文预算不做压缩的长流程几乎必然在第五六步就超出窗口idempotency_key是重试安全的关键没有它一次网络超时可能导致同一笔操作被执行两次StepLimitExceeded是显式失败比返回一个看起来完整但实际只做了一半的结果要好得多因为后者会被下游当成成功继续流转。max_steps这个参数不建议调大来提高成功率步数上限的本质是成本护栏调大只会让失控的循环烧更多钱。真正的成功率提升应该来自工具描述更准确、上下文更干净。5. 常见问题与排查五个把试点做成技术债的典型姿势试点阶段跑得通、生产阶段收不住是这类项目最常见的翻车现场。下面五条来自真实的失败模式归纳每条都按现象、原因、解决三段写方便对照排查。5.1 试点效果好上线后输出飘且账单翻十倍现象演示时回答准确接入真实流量两周后同一类问题答案开始不一致月度成本是预估的三到五倍。原因通常有两个叠加试点用的是几十条精选输入生产面对的是长尾分布提示里塞的示例不适配同时上下文无限追加每一轮都把完整历史送给模型token消耗随对话轮数平方增长。解决分三步把试点期的输入固化成回归评测集任何提示改动先跑一遍给上下文设硬预算并实现压缩策略把历史摘要与原始片段分开存在网关层做响应缓存相同或高度相似的请求直接命中缓存命中率统计要作为常规指标看。5.2 每个业务线各接一套模型半年后无法统一治理现象三个部门分别选了不同供应商各自签了合同、各自做了密钥管理等到要统一审计日志和成本归集时发现没有一处能看到全貌。原因不是选型分歧而是缺少统一出口——模型调用被当成普通的HTTP请求散落在各服务里。解决是在工程层加一个模型网关所有调用走同一入口统一做鉴权、限流、计费打标和请求留痕。网关不需要很复杂但必须在上第一个生产应用之前就存在事后再补改造成本远高于初期搭建。5.3 检索增强上线后答非所问引用还指错页现象接了知识库之后答案看起来通顺但引用指向无关段落追问细节就露馅。原因多半是语义数据层没建好文档按固定字数切片切断了表格和条款的上下文召回只做向量相似度没做关键词与规则的混合召回也没有任何召回质量的离线评测。解决顺序是先定切片策略按结构切而不是按字数切再加混合召回与重排最后用一批标注过的问题测召回率。跳过评测直接调提示词是最常见的无效努力。5.4 模型选完了法务在合规审查时把项目卡住现象技术验证通过采购流程走到法务被要求说明训练数据来源和输出内容的责任归属项目停摆数周。原因是采购与法务介入太晚技术团队按能力指标选完型才发现合同条款、数据驻留、第三方知识产权这些问题没有前置确认。解决是把采购与法务拉进选型会议在候选清单阶段就同步评估内容训练来源的可说明性、输出内容的使用限制、以及供应商的责任边界。这不是流程负担而是把返工成本从上线后移到选型前。5.5 应用里到处长出GenAI功能重复建设且预算失控现象CRM里有一个摘要按钮协作工具里有一个摘要按钮客服系统里还有第三个实现不同、效果不一、各自付费。原因在于按功能采购而不是按应用组合规划。解决是先盘点现有应用组合在数据、流程、智能三个维度各承担什么角色再决定哪些能力应该收敛成共享服务。判断标准很实际如果两个功能的输入输出形态高度相似它们就应该共用同一个底层调用和同一套评测而不是各买一份。6. 治理的最后一公里为什么它注定是定制开发几乎所有采购决策里都有一个被低估的假设治理能力可以随产品一起买到。现实是治理系统的最后一公里往往必须自建。供应商能给你内容过滤开关、审计日志导出、权限模板但没法给你这家供应商的训练数据来源是否符合你所在行业未来三年的监管口径这个判断也没法替你定义什么算有毒输出在你的业务语境下的边界。这类判断依赖你对自己的数据、客户和责任的了解天然无法标准化。内容训练来源的可追溯性是典型例子。买方需要评估自己暴露在什么风险下而这个风险随法规逐步落地会变化。今天合规的用法明年可能需要在合同里补条款后年可能需要替换模型。所以选型时不能只问这个模型效果如何还要问如果明年必须换掉它我要改多少东西。这正是第3章那套松散耦合设计的现实回报——它不是为了技术优雅而是为了在治理要求变化时保留迁移能力。另一个容易被忽略的点是偏见与有毒输出的管理。它不是加一个过滤器就完事而是要在评测集里显式构造边界样本并且定期重跑。评测集本身是资产需要版本管理把它当成一次性脚本半年后就没人知道那些用例为什么这么写。治理动作常见误区可验证的落地方式内容来源溯源只看供应商白皮书合同里约定来源说明义务与变更通知输出责任归属默认由供应商承担明确人机责任边界关键动作留人工确认偏见与毒性管理上线前测一次评测集版本化随模型升级回归供应商评估只比用例价值同时评估可耦合性与迁移成本评估供应商时还要看更大的图景。市场上供应商数量爆发式增长难的不是挑一个当下最有价值的应用而是想象它们如何被组合进更大的AI系统和整体架构。可行的做法是定期把内部的供应商清单和架构演进路线与那份创新指南附带的新兴市场象限做对照看两层东西一是候选供应商的能力边界是否变化二是你自己的架构假设是否还成立。这个动作每季度做一次比任何一次性的选型评审都更有价值。最后说一个我自己的教训。早些年做技术选型我习惯先看能力和价格把治理和迁移放在上线前一周处理结果每次都是在最紧的时间里做最需要冷静的判断。从那以后我每次启动一个生成式AI相关的方案都强制走一遍三问这个模型换掉要改几个地方、输出的来源能不能指回原文、评测集下次什么时候重跑。三个问题里有一个答不上来就不进入开发。希望帮到你。这份指南连同它附带的市场象限适合放进架构评审的材料里反复对照——它给的不是答案是一张能让你自己提问的地图。本文还有配套的精品资源点击获取
简介Gartner 2024年11月发布的《生成式人工智能技术创新指南》G00793932面向企业技术领导者、架构师与AI规划人员用于厘清GenAI在各技术栈层级与垂直行业的渗透路径并借助配套的新兴市场象限考察供应商格局。整包为1个PDF文件约1.28MB、35页保留关键发现、行动建议与供应商分析等章节可直接用于内部技术分享与选型参考目前已有57人学习下载。文中指出GenAI并非单一市场而是从底层基础设施、开发工具到终端应用全栈嵌入DSML、CRM、ERP等传统平台也在整合相关能力投资主线集中于基础模型尤其是大语言模型首波供应商聚焦内容与体验生产AI代理则连接LLM与软件工程推动第二波创新。报告还给出降低试点技术债、模型松耦合选型、构建语义数据层与负责任AI实践等建议便于读者判断自身阶段并规划架构演进。1. 生成式AI不是一个市场为什么市场定义本身就是一道架构题生成式AIGenAI从来不是一块能用市场份额切分的独立蛋糕。把它当成一个市场去问这块饼有多大答案一定失真它同时存在于加速卡的显存带宽里、存在于模型API的计价单位里、存在于代码编辑器的补全光标下也存在于CRM的会议摘要按钮里。一份面向技术决策者的生成式AI技术创新指南给出的第一条判断就是GenAI本身不是一个市场它渗透进整个技术栈和大多数垂直领域。真正值得深入思考的问题是一个没有清晰市场边界的技术凭什么能被企业当作架构资产来规划答案藏在分层里一旦你接受GenAI是一种新的人机接口方式而不是一款可以采购的软件技术栈的每一层就必须回答同一个问题——这一层该由谁承担演进风险又该由谁承担评测责任。2. 四层技术栈边界为什么必须画在算力、模型、工程和应用之间把一个渗透性技术强行切成四层看起来是多此一举。但分层的目的不是分类学而是把谁承担什么样的失败这件事固定下来。基础设施层失败表现为容量与成本失控模型层失败表现为能力突然落后或合规暴露工程层失败表现为迭代效率崩塌应用层失败表现为用户不信任。这四类失败的处置手段完全不同混在一起谈就会变成AI项目效果不好这种无法行动的结论。分层之后每一层对应一类采购决策、一类技术债和一类验收标准架构评审才有一致的基础。2.1 基础设施层训练和推理是两种完全不同的负载基础设施层由两股力量占据做加速计算的芯片厂商以及提供IaaS与PaaS的超大规模云服务商。看上去都是卖算力实际上它们在满足两种性质相反的需求。训练是吞吐密集型的长周期任务容错靠定期检查点硬件利用率比单次响应时间重要得多推理是延迟敏感的突发负载请求量随时间剧烈波动需要弹性伸缩和快速冷启动。这两件事对存储、网络、显存容量的要求并不重合用一个集群同时优化它们通常是两头都不讨好。这也解释了企业侧一个反复出现的选择很少自建训练集群但会把部分推理下沉到离用户更近的地方。原因不在成本而在采购周期。自建数据中心从立项到交付以季度计而模型的版本迭代以周计硬件还在路上需求形状已经变了。常见的实现思路是把训练留在云上、把推理按流量特征分层高频短请求走常驻实例长尾请求走按需实例最敏感的那部分走边缘节点。这个分层动作一旦做了基础设施层就从花钱买算力变成给推理流量做路由后面所有成本优化才有依据。云服务商自研加速芯片的动机也在这里。它不只是为了省钱而是垂直整合——把上层SaaS应用和下层算力的毛利留在同一体系内同时降低对单一芯片供应方的依赖。对买方来说这条信息的意义在于不要假设算力价格会单调下降。当供给方在整合价格结构的波动性反而上升容量规划里必须留出可迁移的余地比如让训练任务能接受不同加速卡型号用编译层和算子兼容层把硬件差异挡住。2.2 模型层为什么这一层的价值捕获点最不稳定模型层的竞争态势和其他三层都不同。提供商业闭源模型的公司用模型支撑自己上层应用的经济模型同时通过API把模型本身作为商品出售还允许合作伙伴在自有基础设施上部署实例再包一层企业级安全与隐私。两条腿走路既卖能力也卖应用。开源模型则从另一边压缩定价空间——它的意义不是免费而是把开发者的迁移成本降到可以随时换供应商的程度。真正改变力量对比的是三件事同时发生模型在特定用例上开始变小、精调所需的数据和人工输入被流程化、领域模型带深度横向或纵向术语与上下文和轻量模型面向云端与边缘的低成本、小体积推理出现。结果是买方的可选择项变多单一模型厂商的定价权下降。从架构角度看这意味着一件很朴素但经常被忽略的事模型是消耗品不是地基。如果模型是消耗品那么模型质量就不是一个可以一次性拍板的属性而是一条随时间波动的曲线。你今天选的模型可能在某个基准上领先六周后另一家追平三个月后成本只有它的三分之一。把业务逻辑写死在某个模型的提示格式、特定参数、特定结构化输出约定里等于把技术债锁进了最难重构的那一层。常见的实现思路是把模型能力抽象成一组声明式属性——上下文窗口、每百万token的价格、首token延迟、是否支持工具调用、是否支持结构化输出——再让上层按属性选模型而不是按品牌名。2.3 工程层和应用层之间那条模糊的线AI工程工具覆盖模型的完整生命周期开发、精调、部署以及把生成式模型和其他生成式产物在生产应用中跑起来的整体流程编排。GenAI应用则用生成能力改善用户体验、增强任务完成度把生成与编辑文本、代码、图像、多模态输出嵌进具体任务里。两者的边界在实践中极难分清因为精调一个模型和给应用做一个功能在代码仓库里往往就隔着几个目录。我一般用一条准则来划这条线如果一件事的好坏必须靠你自己的评测集才能判断它就属于工程层不该外包给应用。举例来说摘要功能是应用层的产物但摘要的忠实度是否达标属于工程层因为只有你才知道哪些内容不允许被改写、哪些术语必须原样保留。一旦把评测责任交给应用供应商你买到的是一个会随时间漂移的黑匣子说明书而不是一个可验证的指标。3. 松散耦合为什么能换掉模型必须是架构的第一性要求设计目标只有一句解决方案要与生成式模型松散耦合以便灵活地选型和组合。这句话在文档里往往一笔带过但要真正落地需要拆成三层接口层的模型抽象、数据层的语义化、以及两者之间的上下文组装。少任何一层松散耦合都会退化成换模型的时候改三十个文件。3.1 模型抽象层要抽象什么抽象层最容易犯的错误是只抽象了调用这一件事——包一个函数把模型名作为参数传进去然后宣称已经解耦。真正的耦合点根本不在这里。它藏在提示模板的写法、结构化输出的解析方式、工具调用的协议、错误码的含义、以及计费粒度上。一个支持多模型的路由层至少要表达四组信息能力是否支持视觉输入、是否支持函数调用、上下文窗口多大、成本输入输出分别计价以及缓存命中是否折价、性能首token延迟与整体吞吐、合规数据驻留区域、训练数据来源可说明性。这四组信息不是一成不变的常量它们会随版本迭代变化所以更合适的做法是把它们当成运行时元数据而不是编译期常量。举例来说某个任务需要处理一份两百页的合同上下文窗口不够时不应该报错而应该触发降级路径切到检索增强把相关段落召回后拼入上下文或者切到分段摘要再汇总。这个降级逻辑写在路由层业务代码完全不需要知道。3.2 语义数据层让模型有据可依而不是自由发挥第二层是语义数据层。企业知识资产——内容、数据、规则与启发式、语料、数字孪生模型、知识图谱——的作用不是喂给模型训练而是在推理时提供上下文让模型的行为被锚定到企业的真实状态上。这个动作常被称为grounding接地。它的机制很直白模型的参数里存的是分布式的、去具体化的语言规律它不知道你公司上个月改了退款政策检索层把当前有效的政策片段取出来放进上下文模型的输出才可能对得上。幻觉的很大一部分不是模型胡说而是上下文里根本没有正确答案它只能按语言概率补全。这里有经验的开发者会强调一个顺序问题如果你还没有为业务建立语义数据层现在就开始而不是等模型能力再强一点。原因在于grounding的收益不是线性的——它取决于检索质量、切片策略、以及知识的更新时效。模型变强只能让你在同样的上下文里答得更好但没法替你召回一段你压根没索引的内容。注意把提示词当知识库是常见的偷懒做法。提示词适合放规则和格式约束不适合放会变化的业务事实。一旦事实变了你会在几十个提示模板里找同一句话。3.3 一个可落地的路由配置长什么样把上面的思路写成配置比写成架构图更能暴露问题。下面这段配置描述的是任务类型到模型候选集的映射关键在候选集和降级链而不是具体型号。# 任务级模型路由业务代码只声明任务类型不写模型名 routes: doc_summarize: # 任务长文档摘要 candidates: # 候选按优先级排列运行时可热替换 - profile: large_ctx # 能力标签由模型元数据解析成具体型号 max_input_tokens: 200000 fallback: chunk_summarize # 超出窗口时的降级策略 - profile: cheap_fast max_input_tokens: 32000 budget: cost_per_call_usd: 0.12 # 单次调用成本上限超出即降级 p95_latency_ms: 4000 # 延迟上限超出即切换候选 guardrails: require_source_citation: true # 输出必须带可追溯的原文片段 pii_redaction: true # 上下文进入模型前做脱敏 code_review: # 任务代码评审建议 candidates: - profile: code_strong require_tool_call: true # 必须具备函数调用能力用于拉取仓库上下文 budget: cost_per_call_usd: 0.40这段配置里profile是能力标签而非具体型号换供应商时只改元数据表路由定义不动fallback把上下文超限这种最常见的失败变成了预设路径而不是运行时异常budget把成本和延迟变成硬约束避免某个任务悄悄吃掉整个季度的预算guardrails里的require_source_citation是治理的前置动作——要求输出附带原文片段事后审计才有据可查。参数改法也很直接把p95_latency_ms调低会更快触发切换代价是候选集命中率下降把cost_per_call_usd调高会减少降级但预算消耗曲线会变陡。上线前建议先用历史流量回放一遍看降级触发比例落在什么区间。4. 智能体把模型接到工具上为什么第二波冲击比第一波更结构性第一波供应商围绕快速生产内容与体验展开靠企业信息和知识库加持。这一波的输出终点是人——生成一段文案、一张图、一段代码人来判断、人来执行。第二波不一样把大语言模型接到软件工程和各类工具上让输出直接变成动作。动作有副作用副作用要回滚回滚需要状态管理。这就是为什么智能体agent技术带来的不是功能增量而是架构策略的位移。4.1 从内容生成到流程接管机制差异在哪从机制上看内容生成是一次函数调用输入上下文输出文本智能体是一个循环模型在循环里决定下一步调用哪个工具、传什么参数、看到结果后是否继续。支撑这个循环的是大行动模型LAM方向的研究进展它让模型不只是理解语言还能把自然语言意图映射成对工具的结构化调用。2024年生成式智能体平台的出现本质上是把这个循环产品化了。差异带来的第一个后果是评测方式变了。内容生成用BLEU、人工打分、忠实度检查就够了智能体要评的是任务完成率、步数、以及失败后的可恢复性。一个能完成80%任务但剩下20%会把系统改坏的智能体比一个只能完成60%但从不出错的智能体危险得多。第二个后果是权限模型必须重写。当模型可以调用写接口它的输出就不再是建议而是操作必须走和人类操作员同一套鉴权与审计而不是另一套更宽松的。4.2 多智能体与仿真二阶效应从哪里来单智能体解决的是把多个任务串起来的流程多智能体解决的是多个角色协作的流程。后者听起来像概念包装但它对应一个真实的技术问题当一个流程需要不同领域的判断时把全部规则塞进一个上下文会互相干扰拆成若干各带专用上下文和工具的智能体再由一个编排层协调反而更容易调试。生成式能力在仿真场景里的用法也类似——不是生成一段描述而是持续生成状态转移让系统在虚拟环境里预演。这类架构会推动市场从卖应用转向卖可组合的系统。买方不再只问这个应用对我有多大价值还要问它能不能和我已有的其他AI组件拼成更大的系统。这也是为什么评估供应商时必须同时看两件事用例价值以及它在整体AI架构里的可耦合性。4.3 编排的代价状态、幂等与可观测性把模型接进工作流最先出问题的往往不是模型而是编排。下面这段伪代码展示的是一个最小可用的智能体循环注释里标出了三个必须处理的点。def run_agent(task, tools, max_steps8): state {history: [], artifacts: {}} for step in range(max_steps): # 1) 上下文预算历史过长时压缩而不是无限追加 ctx compress(state[history], budgetTOKEN_BUDGET) # 2) 工具调用必须带幂等键重试不会产生重复副作用 decision llm.decide(tasktask, contextctx, toolstools.schema()) if decision.type tool_call: result tools.invoke( namedecision.name, argsdecision.args, idempotency_keyf{task.id}:{step}:{decision.name}, ) state[history].append({call: decision.name, result: result}) elif decision.type final: return decision.output # 输出需附带来源片段供审计 # 3) 每一步都打点步数、耗时、token、工具成功率 metrics.emit(task.id, step, decision.type) raise StepLimitExceeded(task.id) # 触顶要显式失败不能静默返回半成品这段代码里compress对应上下文预算不做压缩的长流程几乎必然在第五六步就超出窗口idempotency_key是重试安全的关键没有它一次网络超时可能导致同一笔操作被执行两次StepLimitExceeded是显式失败比返回一个看起来完整但实际只做了一半的结果要好得多因为后者会被下游当成成功继续流转。max_steps这个参数不建议调大来提高成功率步数上限的本质是成本护栏调大只会让失控的循环烧更多钱。真正的成功率提升应该来自工具描述更准确、上下文更干净。5. 常见问题与排查五个把试点做成技术债的典型姿势试点阶段跑得通、生产阶段收不住是这类项目最常见的翻车现场。下面五条来自真实的失败模式归纳每条都按现象、原因、解决三段写方便对照排查。5.1 试点效果好上线后输出飘且账单翻十倍现象演示时回答准确接入真实流量两周后同一类问题答案开始不一致月度成本是预估的三到五倍。原因通常有两个叠加试点用的是几十条精选输入生产面对的是长尾分布提示里塞的示例不适配同时上下文无限追加每一轮都把完整历史送给模型token消耗随对话轮数平方增长。解决分三步把试点期的输入固化成回归评测集任何提示改动先跑一遍给上下文设硬预算并实现压缩策略把历史摘要与原始片段分开存在网关层做响应缓存相同或高度相似的请求直接命中缓存命中率统计要作为常规指标看。5.2 每个业务线各接一套模型半年后无法统一治理现象三个部门分别选了不同供应商各自签了合同、各自做了密钥管理等到要统一审计日志和成本归集时发现没有一处能看到全貌。原因不是选型分歧而是缺少统一出口——模型调用被当成普通的HTTP请求散落在各服务里。解决是在工程层加一个模型网关所有调用走同一入口统一做鉴权、限流、计费打标和请求留痕。网关不需要很复杂但必须在上第一个生产应用之前就存在事后再补改造成本远高于初期搭建。5.3 检索增强上线后答非所问引用还指错页现象接了知识库之后答案看起来通顺但引用指向无关段落追问细节就露馅。原因多半是语义数据层没建好文档按固定字数切片切断了表格和条款的上下文召回只做向量相似度没做关键词与规则的混合召回也没有任何召回质量的离线评测。解决顺序是先定切片策略按结构切而不是按字数切再加混合召回与重排最后用一批标注过的问题测召回率。跳过评测直接调提示词是最常见的无效努力。5.4 模型选完了法务在合规审查时把项目卡住现象技术验证通过采购流程走到法务被要求说明训练数据来源和输出内容的责任归属项目停摆数周。原因是采购与法务介入太晚技术团队按能力指标选完型才发现合同条款、数据驻留、第三方知识产权这些问题没有前置确认。解决是把采购与法务拉进选型会议在候选清单阶段就同步评估内容训练来源的可说明性、输出内容的使用限制、以及供应商的责任边界。这不是流程负担而是把返工成本从上线后移到选型前。5.5 应用里到处长出GenAI功能重复建设且预算失控现象CRM里有一个摘要按钮协作工具里有一个摘要按钮客服系统里还有第三个实现不同、效果不一、各自付费。原因在于按功能采购而不是按应用组合规划。解决是先盘点现有应用组合在数据、流程、智能三个维度各承担什么角色再决定哪些能力应该收敛成共享服务。判断标准很实际如果两个功能的输入输出形态高度相似它们就应该共用同一个底层调用和同一套评测而不是各买一份。6. 治理的最后一公里为什么它注定是定制开发几乎所有采购决策里都有一个被低估的假设治理能力可以随产品一起买到。现实是治理系统的最后一公里往往必须自建。供应商能给你内容过滤开关、审计日志导出、权限模板但没法给你这家供应商的训练数据来源是否符合你所在行业未来三年的监管口径这个判断也没法替你定义什么算有毒输出在你的业务语境下的边界。这类判断依赖你对自己的数据、客户和责任的了解天然无法标准化。内容训练来源的可追溯性是典型例子。买方需要评估自己暴露在什么风险下而这个风险随法规逐步落地会变化。今天合规的用法明年可能需要在合同里补条款后年可能需要替换模型。所以选型时不能只问这个模型效果如何还要问如果明年必须换掉它我要改多少东西。这正是第3章那套松散耦合设计的现实回报——它不是为了技术优雅而是为了在治理要求变化时保留迁移能力。另一个容易被忽略的点是偏见与有毒输出的管理。它不是加一个过滤器就完事而是要在评测集里显式构造边界样本并且定期重跑。评测集本身是资产需要版本管理把它当成一次性脚本半年后就没人知道那些用例为什么这么写。治理动作常见误区可验证的落地方式内容来源溯源只看供应商白皮书合同里约定来源说明义务与变更通知输出责任归属默认由供应商承担明确人机责任边界关键动作留人工确认偏见与毒性管理上线前测一次评测集版本化随模型升级回归供应商评估只比用例价值同时评估可耦合性与迁移成本评估供应商时还要看更大的图景。市场上供应商数量爆发式增长难的不是挑一个当下最有价值的应用而是想象它们如何被组合进更大的AI系统和整体架构。可行的做法是定期把内部的供应商清单和架构演进路线与那份创新指南附带的新兴市场象限做对照看两层东西一是候选供应商的能力边界是否变化二是你自己的架构假设是否还成立。这个动作每季度做一次比任何一次性的选型评审都更有价值。最后说一个我自己的教训。早些年做技术选型我习惯先看能力和价格把治理和迁移放在上线前一周处理结果每次都是在最紧的时间里做最需要冷静的判断。从那以后我每次启动一个生成式AI相关的方案都强制走一遍三问这个模型换掉要改几个地方、输出的来源能不能指回原文、评测集下次什么时候重跑。三个问题里有一个答不上来就不进入开发。希望帮到你。这份指南连同它附带的市场象限适合放进架构评审的材料里反复对照——它给的不是答案是一张能让你自己提问的地图。本文还有配套的精品资源点击获取
按顺序排)
