企业AI平台运营实战：从模型选型到成本治理的关键经验

开篇先亮个身份吧。我叫老周干了十年AI应用架构前五年在乙方给各行各业做CV和NLP项目后五年到一家中型集团企业从零搭AI平台一路做到现在。这十年里最深的感受是市面上讲AI算法、讲模型训练的教程多如牛毛但真正讲“企业AI平台怎么运营”的内容少得可怜。很多团队模型选得挺好算力也买了最后死在运营上——没人用、成本失控、业务部门不买账。这篇文章我把踩了十年的坑攒下来的4条核心经验摊开讲每条都是真金白银换来的适合正在搞企业AI平台的技术负责人、架构师以及那些准备从单点模型往平台化走的团队参考。这里说的“企业AI平台”不是指买几张显卡跑个模型而是指一套能支撑多个业务场景、多个团队长期使用的基础设施——它包含模型服务、数据管道、评测体系、权限与成本管控、还有面向业务的接入方式。你把它当成企业内部的“AI水电煤”来运营思路就对了。1. 平台定位先做“业务工具箱”别急着喊“AI中台”第一条经验也是我踩得最深的一个坑企业AI平台起步阶段千万不要一上来就搞大而全的中台规划。我见过太多团队一上来就画一张宏伟蓝图——数据中台、算法中台、业务中台三层架构讲得头头是道PPT做得比咨询公司还漂亮结果落地的时候发现连第一个业务场景都喂不饱团队精力全耗在平台自身的基建上业务价值一点没体现出来。1.1 中台思维在企业AI落地中的常见误区中台这个概念本身没问题问题是时机。很多企业连一个像样的AI场景都没有验证过就急着搭中台这等于连饭都没煮熟就想开餐厅。我刚开始做平台时也犯过这个错花了大半年搭了一堆通用组件模型服务框架、特征平台、标注平台、自动化训练流水线结果业务方来了一看说“我就要一个能识别合同关键信息的小工具你这些东西我用不上”。后来我彻底想明白了企业AI平台的本质不是“建一个平台”而是“解决一群业务问题”。平台只是解决问题的副产品不是目标本身。一个健康的AI平台应该是从三五个核心业务场景里长出来的——合同审核、客服问答、报表解读、知识库检索每个场景都能带来明确的业务收益平台组件是在服务这些场景的过程中逐步沉淀出来的。1.2 从单点场景切入的平台演进路线那具体怎么切入我的建议是找一个“高频、高价值、低风险”的场景作为第一个标杆。高频保证模型有足够多的反馈数据高价值保证业务方愿意给资源低风险保证失败了影响可控。我在企业里选的第一个场景是“制度文档智能问答”。把几百份员工手册、管理制度、操作规范喂进去做一个问答机器人。这个场景有三大好处数据基本是公开的不涉及深度敏感信息答案错了最多被员工吐槽几句不会造成业务损失而且所有人都能感知到它的价值。这个场景跑通之后业务部门对AI的信任感一下就建立起来了后面再推其他场景就顺多了。往后演进的路线我总结为三步第一步单点工具期。只做一两个场景工具能用就行别追求完美架构重要的是跑通端到端的流程——数据准备、模型调用、结果输出、反馈收集。第二步能力沉淀期。当有了三五个场景都在用相似的能力时比如都用到文档解析、向量检索、模型推理再把这些能力抽出成公共组件形成平台的雏形。第三步平台扩展期。这时候再考虑引入更多的模型、更完善的可观测性、更细粒度的权限和成本管控支撑更多业务线。这个次序不能乱。有些团队一上来就做第三步结果就是烧了钱、耗了人、业务没落地平台成了空中楼阁。先当工具箱再当中台——这是我第一条经验的核心。2. 模型选型与部署本地部署不是目的成本和效果的平衡才是第二条经验和模型本身有关。这个话题太大我聚焦说企业平台运营最关心的几个点开源模型和商业API怎么选、本地部署到底值不值、以及模型评估体系怎么建。2.1 开源本地部署与商业API的决策框架企业做AI平台面临的第一个选择就是用开源模型自己部署还是直接调用商业API这个问题的答案不是“开源免费所以选开源”也不是“闭源效果好所以选闭源”而是一套综合评估框架。我把它拆成四个维度效果、成本、数据合规、工程复杂度。效果维度很简单拿真实业务数据去评测不要只看公开榜单分数。商业API通常效果更好因为训练数据更丰富、迭代更快但差距没有想象中那么大。我之前测过一批开源模型和商业模型在合同要素抽取上的表现好的开源模型准确率能到90%以上商业模型大概93%左右这个差距在多数业务场景里是可以接受的。成本维度要算全账。商业API的成本是显性的——按token付费调用一次算一次钱。开源本地部署看起来免费但你要算上服务器折旧一张A100现在市价六七万还要考虑生命周期还要算电费、机房带宽更重要的是运维的人工成本——大模型部署和调优非常耗人一个合格的LLM运维工程师月薪不低这账算下来很多企业本地部署反而比API贵得多。数据合规维度是我建议优先考虑的因素。如果你的业务数据涉及客户隐私、核心经营数据那商业API可能会触碰合规红线。这时候本地部署不是“可选项”而是“必选项”。我当年做平台就遇到这种情况业务方明确说“数据绝对不能出内网”那就只能走本地部署路线没有第二种选择。工程复杂度维度是新手最容易忽略的。本地部署大模型不是说把模型文件下载下来就能跑你要处理推理框架选型vLLM、TensorRT-LLM、SGLang、显存优化FP16、INT8、GPTQ量化、并发调度、高可用部署任何一个环节出问题都够你排查一天的。如果团队没有专门的推理优化工程师建议还是优先用API把业务跑起来等规模大了再考虑本地化。2.2 本地部署的硬件配置与量化选型参考如果你确实要走本地部署路线这里给一份基于实践的硬件和模型搭配参考表。注意这是基于常见实践的推荐具体还要结合你的并发量和模型规模来定模型规模参数量显存需求FP16推荐GPU配置适用场景7B~8B70亿左右16~20GB单张RTX 4090 24GB轻量问答、文本分类、简单抽取13B~14B130亿左右28~32GB单张A100 40GB 或 两张RTX 4090中等复杂度抽取、摘要、Agent基础推理70B700亿左右140GB双卡A100 80GB 或 H800复杂推理、高质量生成、代码辅助这里要特别提醒一下量化的事。很多团队为了省显存一上来就做INT4量化结果模型效果肉眼可见地下滑。我的经验是优先用FP16或BF16跑全精度显存不够再上INT8最后才是INT4或GPTQ/AWQ量化。你在本地跑7B模型一张4090用FP16就够了没必要为了塞一个70B进去强行量化到INT4效果和速度都不理想。2.3 模型评测建立业务导向的评测集模型选型离不开评测但很多企业的评测方法是错的——拿网上公开的benchmark跑一遍看分数选模型。这玩意儿参考价值真的有限因为公开benchmark的题目分布和你的业务数据分布完全是两回事。正确做法是建一套“业务专属评测集”。从每个核心业务场景里抽几百条真实数据手工标好标准答案然后拿候选模型去跑对比准确率、召回率、格式正确率。这套评测集要持续维护和扩充每次模型升级或更换都要在这套集子上跑一遍。我团队现在有三千多条业务评测数据覆盖合同、问答、报表、代码四个方向任何模型变更都要过这一关过不了就不能上生产。这里有个实操经验评测集里的case要包含“边界样本”。比如你做一个合同要素抽取模型正常条款要有残缺的合同、格式怪异的合同、包含歧义表述的条款也要有。因为生产环境里遇到的往往是边界情况正常的case几乎所有模型都处理得好边界case才能拉开差距。我在选型时就发现两个模型在正常case上准确率都是95%左右但到了边界case一个掉到80%一个还能保持88%那差距就出来了。3. 工程化落地从模型到产品中间隔着十万个细节第三条经验是关于工程化的。模型训练出来了或者说选好了不等于业务就能用了。从模型到真正的产品化服务中间隔着数据管道、推理服务、Agent框架、RAG检索、评测反馈一大堆细节。这块我把企业里最容易翻车的几个环节单独拎出来讲。3.1 RAG落地没有优质检索再强的模型也白搭现在企业里大部分场景走的是RAG检索增强生成路线——先从知识库里检索出相关内容再让大模型基于检索结果回答。这个思路没问题但很多团队一上来就调模型写Prompt结果回答质量上不去第一反应是“模型太弱”换个更大的模型发现还是不行。问题往往出在检索环节——根本就没把正确的知识检索出来。RAG的检索效果取决于三要素文档切分策略、Embedding模型质量、检索融合策略。文档切分是看着简单实际最考验功力的环节。我见过有人写死按800字切结果一个完整合同条款被拦腰截成两段检索的时候语义全碎了。正确做法是按文档结构切分——标题感知、段落感知、表格单独处理每个知识块尽量语义完整。实际操作里我一般是先按markdown结构或PDF的heading拆成章节再判断每个章节的长度太长的再按语义窗口去切窗口间保留重叠避免边界信息丢失。Embedding模型这一块除非你预算紧张到极致否则我建议优先选择专为中文优化的向量模型而不是直接用通用多语言模型。原因是中英文混合场景下通用模型的效果经常飘忽不定。选型时同样要建业务评测集用“检索命中率”作为核心指标给定一个业务问题系统能否在Top5检索结果里返回正确答案。检索融合策略很多团队也没做。实际生产环境里纯向量检索不是万能的——关键词精确匹配在某些场景下更靠谱比如合同编号、人员姓名这种精确实体。我的建议是采用“BM25向量检索”的混合召回再用重排序模型Reranker把两路结果合并排序。这一步能显著提升最终答案的准确率成本是每一条查询多几十毫秒的耗时非常值得。3.2 Agent落地从Demo到生产绕不开的四大坑Agent是最近两年企业AI平台最热的方向之一招聘网站上AI应用架构师的JD里十个有八个要求懂Agent。但Agent从Demo到生产中间有四大坑必须提前知道。第一个坑是工具调用不稳定。模型在Demo环境里调用工具十次有八次成功一上生产就露馅——参数传错、JSON格式解析失败、工具选择逻辑混乱。这个问题的本质是模型能力问题靠Prompt可以缓解但很难根治。实操建议是在项目启动前先做一次“工具调用压力测试”构造50个需要调用工具的真实业务问题看看模型成功率能到多少。如果低于90%要么考虑换更强模型要么把工具设计得简单一点——减少参数数量合并关联操作都是有效的降复杂度手段。第二个坑是记忆管理缺失。Agent的对话上下文不能无限增长否则要么爆掉模型窗口要么中间信息被稀释。我团队的经验是给Agent设计明确的记忆策略——短期记忆存对话轮次里的关键信息长期记忆存用户画像和业务偏好知识记忆通过RAG动态获取三层分开管理。很多Agent框架自带记忆组件但默认行为往往不满足企业场景还是要根据业务逻辑手动设计。第三个坑是评估体系缺位。Agent是一个复杂的概率系统同样的输入这次可能走调用工具的路径下次可能直接生成答案。没有一套自动化的评估体系你根本不知道一次改动是变好了还是变坏了。我的做法是给每个Agent场景建一条“黄金路径”——由人工标注出正确应该调用的工具序列和最终答案然后自动跑批量测试对比。正常率低于95%不能上线上线后每次模型或工具变更都要回归跑一遍。第四个坑是安全边界模糊。Agent能调工具就等同于能触碰系统企业里必须做严格的权限管控。我的原则是最小权限每个Agent只能调用业务上必需的几个工具工具本身再套一层权限校验判断当前用户是否有权限触发这个操作。这个事千万不要省一旦一个Agent因为Prompt注入被诱导执行了越权操作后果是非常严重的。3.3 配置管理与提示词工程最后讲一下提示词的管理这是工程化里最容易乱的一块。很多团队把Prompt写在代码里改一次就要发一次版毫无效率可言。Prompt本质上就是AI应用的一部分它应该像代码一样被版本化管理、被测试、被review。我团队现在的做法是所有Prompt统一放到配置中心分成系统提示词、角色设定、业务规则、输出格式四层。每层独立管理Change时通过评审后自动同步到各环境。Prompt的版本号跟模型版本号绑在一起线上出了问题可以快速回滚到上一个稳定版本。还有个细节是Prompt的模板必须做好转义和校验防止用户输入注入到Prompt里的恶意内容。这块涉及安全说再多都不为过。4. 平台运营可观测、控成本、建反馈闭环第四块经验是关于平台上线之后的运营管理。很多企业AI平台活不过一年不是因为技术不行而是因为运营不善——没有可观测性导致问题无法定位、成本失控导致预算被砍、没有反馈闭环导致模型越用越蠢。这一章我把三个关键运营要点逐个讲透。4.1 AI平台可观测性不止看监控更要看质量传统IT运维讲监控CPU、内存、请求量、错误率、延时这些AI平台同样要看但这些只算基础设施层面的可观测性。AI平台特有的可观测性在“质量”层面——模型生成的内容到底满不满意用户对回答的反馈是什么某个场景的效果有没有在运行期间悄悄下降这些问题不做专门的观测是看不到的。我的做法是给平台加三层观测指标体系。第一层是“使用量指标”——每天多少请求、多少用户、哪些场景用得最多这一层能反映业务渗透率是平台价值的直接证明。第二层是“成本指标”——每个场景每天烧了多少token、GPU利用率多少、单次请求成本多少这一层是控制预算的基础。第三层是“质量指标”——用户点赞点踩数据、问题自动转人工的比例、周期抽样评测得分这一层反映模型真实效果。第三层质量指标是我特别想强调的因为很多企业完全不做。他们以为模型部署上就万事大吉了结果模型在训练数据里表现很好一上生产面对真实的、不断变化的输入就露馅。质量指标里有一个很经典的“隐形退化”现象数据分布悄然变化模型准确率从90%缓慢跌到75%但因为没有质量观测谁都没发现。等业务方自己撞上了来投诉平台的口碑已经受损了。所以每个场景我都强制要求埋好质量观测点至少做到“回答可追溯、反馈可统计、退化可预警”。4.2 成本治理每个场景都要算清这笔账企业AI平台烧钱是必然的尤其是上了大模型之后GPU服务器、推理能耗、API调用费都是真金白银。成本治理做得好不好直接决定平台能活多久。我见过好几个项目模型效果一流但成本是业务收益的三四倍最后预算被管理层一刀砍掉团队被迫解散非常可惜。成本治理的第一个原则是“场景即成本中心”。每个业务场景单独计费就像每个部门单独预算一样。API调用按token计费可以落到场景GPU共享池就按场景占用时长分摊。场景的成本归属清晰之后才能算清“这个场景值不值”。我们公司有个智能写作场景每个月模型成本大概三万多但算下来帮内容团队节省了快十个人力这笔账就很好算。成本治理的第二个原则是“分层算力、按需分配”。不是所有场景都需要最强模型。我平台现在的模型供给分三层第一层是轻量级模型7B给意图识别、文本分类这种简单的任务第二层是中量级模型13B~32B给知识问答、摘要生成这种常规任务第三层是重量级模型70B或商业API给复杂推理、长文档理解、代码生成。把简单任务压到小模型上推理速度快、费用低复杂任务再上大模型总成本能省下一大截。最后一招是缓存策略。企业里大量请求是重复的或高度相似的——同一条业务规则被多次查询同一个合同模板被反复解析。在平台层加语义缓存命中时直接返回结果不调模型实测能省掉30%~40%的重复查询成本。这招简单粗暴效果立竿见影建议所有平台必做。4.3 数据反馈闭环让模型越用越聪明模型上线只是起点不是终点。如果一个模型上线后没有持续的数据反馈和迭代机制它大概率会随着业务数据分布的变化而逐渐退化。企业AI平台运营的核心之一就是建立一条“生产数据→清洗标注→迭代优化→回归上线”的闭环流水线。第一步是埋点采集。前端接入了“点赞/点踩”按钮这是最简单直接的反馈信号。但光有显式反馈不够因为99%的用户懒得点。所以还要做隐式反馈用户收到回答之后有没有复制、有没有继续追问、有没有在回答基础上修改并保存。这些行为信号能侧面反映回答是不是有用。第二步是定期抽样评测。每两周从生产请求里随机抽200条让标注团队的同事按业务标准打一遍分。发现连续下降或者某类问题集中出现就拉出来专项分析。这里有个经验不要只盯着平均分看要按场景、按问题类型下钻分析。平均分不变掩盖的可能是“合同场景变好、客服场景变差”这种结构性变化。第三步是迭代优化。基于反馈数据决定要不要微调模型、要不要调整Prompt、要不要更新RAG知识库。大部分场景不需要微调调整Prompt和优化知识库往往就能解决80%的问题。微调是大杀器周期长、成本高只有在Prompt和RAG都调不动的时候才考虑。这套闭环跑起来之后平台就不再是“部署完就躺平”的状态而是一个持续进化的系统。这也是运营和运维的本质区别——运维是维持现状运营是驱动系统不断变好。我始终认为企业AI平台的长期价值不在于你上线时用了多强的模型而在于你运营期间能不能把模型的潜力持续释放出来。5. 最后再分享几句实在话这条写了这么多其实就是想跟做企业AI平台的朋友们说技术选型很重要但比技术更重要的是运营思路。模型可以换、架构可以重构但“从场景出发、以数据为驱动、以成本为约束”这套运营理念是贯穿始终的。我个人这几年最大的体会是企业AI平台不是一个纯技术项目它更接近一个“业务工程”。你要懂算法也要懂业务指标还要懂成本核算。有时候阻力不是来自技术难度而是来自组织协同——业务部门不配合、领导期望不切实际、团队分工模糊。这些软性的问题往往比硬技术更考验人。如果你所在的团队正准备搭企业AI平台我的建议是别急着写代码先花两周时间做三件事走一遍核心业务场景、算清预期成本和收益、和管理层对齐平台的价值衡量标准。这三件事做扎实了后面所有的技术工作都会顺很多。如果只能从这篇文章带走一句话我希望是这句先解决业务问题再谈平台建设。