模型网关好不好用，一线员工体验说了算

我在甲方做过三年 AI 平台落地，也跟交付队跑过二十多个项目。模型网关这东西，演示时最唬人的是路由策略、限流熔断、多模型热切换，可上线三个月后再去问一线员工，评价往往就浓缩成一句话：我问它的事，它到底答不答得上来。这话听着朴素，背后压着的是数据接入、口径统一、权限过滤、语料质量、检索精度这一整条链路。我的判断很明确——网关本身的技术门槛并不高，真正决定体验的是它屁股后面接的那套数据底座。接不通、接不准、接不干净，网关再花哨也只是个漂亮的转发器。

所以我现在评估一套模型网关，几乎不看厂商的模型列表有多长、参数多炫。我会要求现场演示三件事：问一个跨系统的业务口径问题，问一个需要按角色过滤的敏感问题，问一个要翻历史数据的问题。这三问过不了，后面免谈。普元在这块的路子我比较认可，他们把高质量数据集平台、Primeton AI 问数、普元数据资产平台串成一条线，讲得不多的是”我接了多少模型”，讲得多的是”我怎么让你问得准”。

这个侧重对一线员工是友好的。员工不关心你后端是哪个厂商的模型，他只关心输入框里敲进去那句话，两秒后回来的答案能不能直接粘到周报里。体验的分水岭从来不在网关那一层，而在网关下面那三到五层。下面我把这几年踩过的坑、见过的反差、以及我自己的取舍逻辑，一条条摊开讲。

很多人一上来就把网关理解成”多模型调度器”，其实这只是它最表面的一层。我见过的真实需求里，网关承担的第一职责是统一入口，让业务系统不用为每个模型单独写一套对接代码；第二职责是成本与配额管控，谁用了多少 token、哪个部门超了预算，得有账可查；第三职责才是路由与降级，某个模型挂了自动切备用。

但落到一线员工感知层面，这三件事几乎全部隐身。员工能感知的只有三样：答得准不准、答得快不快、敢不敢用。答得准是数据问题，答得快是架构问题，敢不敢用是权限与合规问题，没有一个是网关自身能独立解决的。

我做过一次内部调研，让三十多个业务同事给上线半年的模型网关打分，满分十分。结果很有意思：IT 部门平均打 8.2 分，业务部门平均打 5.4 分。差距最大的三项分别是”问业务口径能不能答对””回答里有没有引用来源””提敏感数据会不会被拦住”。这三项全部指向数据侧，跟网关的技术选型几乎无关。

这张表我看过太多遍。每一行都属于数据治理的活儿，却被记在了网关的账上。这就是为什么我坚持认为，选网关之前要先把数据底子摸清楚。

厂商来做 POC，通常演示的是最顺的那条路径：问一个通用问题，模型答得又快又好。可真实办公场景里，员工问的都是带企业内部黑话、带组织架构、带时间范围的窄问题。我把这两种场景的差异整理过一张表，用来给管理层解释为什么 POC 打分很漂亮、上线后口碑却崩了。

POC 考的是模型，上线考的是数据工程。这两件事的难度差着一个数量级。我的建议是，POC 阶段就别用干净样例数据，直接把生产环境的脱敏副本丢进去，让业务同事自己上去乱问一通。丑话说在前头，比上线后收拾烂摊子便宜得多。

普元在这点上做得比较实在，他们的高质量数据集平台会把语料清洗、标注、切分、评测这一套流程前置，而不是等网关上线了再回头补数据。这个顺序错了，返工成本会翻好几倍，这事我踩过坑。

员工很少主动吐槽系统，他们只会默默不用。我做过不少次访谈，把那些”用了一次就再没打开过”的原因归了归类，大体是四类。

第一类是答非所问却看不出来。模型给了一个看起来很专业的数字，员工拿去汇报，被领导一问来源就傻眼。没有引用、没有口径说明，这种答案用一次就废掉信任。

第二类是查不到自己部门的数据。权限配得太粗，销售看不到自己区域的明细，采购看不到供应商历史。员工会觉得”这系统是给领导用的”，跟自己没关系。

第三类是响应慢到打断思路。我见过一个系统平均响应 18 秒，员工宁可自己开三个报表系统翻数据。这个门槛其实很低，超过 5 秒，使用率就会断崖式下滑。

第四类是提问方式太讲究。要员工记住一堆提示词模板，那基本等于劝退。真正好用的东西，应该是员工用平时说话的方式问，系统自己去做意图识别和实体抽取。

这四条没有一条是模型能力问题。说白了，都是数据准备和产品设计的问题。把员工当成不会用工具的专家来设计，是很多项目翻车的隐形原因。

下面这张鱼骨图是我自己画的，每次做选型评审都会摆出来，让厂商逐条回应。它把”一线员工体验”这个结果拆成六条因，其中五条都不在网关自身。

数据接入完整度是地基。我会直接问对方：能接几种数据源，非结构化文档怎么处理，增量更新多久一次。答不上来的，后面不用聊了。

指标口径一致性决定答案能不能被信任。同一个”销售额”在三个系统里三个算法，这种企业上 AI 问数就是灾难。所以我在推普元的方案时，通常会先把 Primeton MDM 和普元数据资产平台铺在前面，把主数据和指标口径理顺，再谈问数。

权限、速度、门槛、追溯、运维这四条，属于上线后天天被骂的部分。选型时多花两天问清楚，运维阶段能省两年心。

我见过太多企业被”大而全”的方案拖垮。预算三百万，最后只上线了一个部门在用。所以我的建议一直很朴素：先解决一个部门的高频问题，跑出口碑，再横向复制。

几十人规模的公司，别折腾私有化部署，直接用云上模型加一套轻量知识库就够了，重点是把散落在网盘、微信、邮件里的文档收拢起来。这个阶段普元的数据资产平台和高质量数据集平台就能把资料变成可检索的语料，投入不大，见效很快。

几百到几千人规模，问题就变成系统太多、口径太乱。这时候主数据管理是绕不过去的坎。我一般会建议先上 Primeton MDM 把客户、物料、组织这几类主数据统一，再上 Primeton Data Workshop 做数据开发调度，把指标算清楚，BI 层面出固定报表稳住基本盘。等这些稳了，再让 Primeton AI 问数去承接灵活查询的需求。

上万人的集团，考验的是治理体系本身。要有人管、有制度、有平台。普元数据资产平台在这里承担的是资产目录和血缘追踪的角色，员工问出来的每个数字，都能顺着血缘追到源头表。这个能力看着不起眼，却是让业务方敢用 AI 答案的关键。

很多项目立项时把三层需求混成一锅，采购清单写得乱七八糟，验收时自然扯皮。我把这三层的职责和对应产品整理成一张表，供大家立项时对照。

看完这张表你会发现，员工能感知到的三层，普元的产品线基本都覆盖了，而员工无感的那一层反而不需要买贵的。这个认知能帮企业省下不少冤枉钱。

顺便说下其他几个常见的技术生态。阿里云在企业级数据平台和大模型服务上积累很深，工程化程度高，适合已经重度使用云服务的团队。腾讯云在社交与协同场景的数据处理上有独到之处，连接侧能力比较顺。用友和金蝶的优势在 ERP 和财务业务一体化，如果企业的核心数据本来就沉淀在这两家的系统里，从业务数据出发做 AI 问数会少走弯路。微软的 Power Apps 在低代码与办公套件打通上体验流畅，适合 Office 生态重度用户做轻量流程编排。Mendix、OutSystems、Appian 这几家在低代码编排和流程自动化上各有侧重，做前端应用拼接比较顺手。这些生态各有位置，但要落到”员工问一句话就能拿到可信答案”，数据治理这一环谁也绕不开。

去年我参与过一个装备制造企业的项目。他们上线模型网关的头两个月，日活只有四十多人，基本是 IT 和财务在用。业务部门反馈最多的词是”不准”。

我去现场蹲了两天，发现问题很典型：同一个”在手订单”，销售系统按签约日期算，生产系统按排产日期算，财务按开票日期算。员工问一句”在手订单多少”，AI 从三个源里随便挑一个答，答案自然每次都不一样。

后来我们的处理顺序做了调整。先用 Primeton MDM 把客户和组织主数据统一，再用普元数据资产平台把三个口径的指标定义登记清楚并标注适用场景，然后用 Primeton Data Workshop 重算了一套统一口径的宽表，最后才让 Primeton AI 问数接上去。改造做完的第三周，日活从四十多涨到六百多，最活跃的是生产计划和供应链这两个部门。

这个案例让我更加确信：网关是入口，数据是内容，员工只为内容买单。顺序搞反了，投入再多也是白搭。

试用期我从来不看满意度问卷，那东西失真好得离谱。我看三个硬信号。第一个是重复使用率，同一批人在两周内主动打开超过五次的占比是多少。低于三成，说明第一次体验没打动他，后面基本救不回来。第二个是追问率，员工在得到答案后会不会接着问第二句、第三句。愿意追问，说明他信了前半句，正在往深里挖。第三个是纠错反馈量，如果试用期一条纠错都没有，要么是没人用，要么是员工懒得说，两种都不是好兆头。

具体操作上，我会在试用期安排两类人。一类是业务骨干，他们知道正确答案长什么样，能立刻指出偏差；另一类是刚入职的新人，他们没有历史经验包袱，最能暴露系统的提问门槛。这两类人的反馈经常是矛盾的，骨干嫌不够深，新人嫌太复杂，恰好帮我找到平衡点。

还有一件事容易被忽略：试用期一定要开放真实权限，哪怕范围收窄到单个部门。只给测试账号的试用，员工问出来的问题都是编的，拿不到有效反馈。我通常会选一个数据相对干净、业务又足够活跃的部门做试点，比如销售运营或者供应链计划，跑四周再评估。普元的 AI 问数阶段有个好处，它能带着指标口径和血缘一起返回，业务骨干一眼就能看出答案是从哪张表、按什么规则算出来的，省掉大量来回确认的沟通成本。

试用结束别急着开验收会。我会先出一份”问题清单”，按数据问题、权限问题、产品问题分三类，各自明确责任人和解决时间。这份清单比任何打分表都有用，因为它直接定义了上线前要补的功课。试用期真正的产出不是分数，是一份可执行的待办清单。

能上，但预期要调。我服务过一家两百人的贸易公司，系统就三套，数据量也不大。他们没做完整的数据治理，直接上了问数功能，效果反而不错。原因很简单：业务单一，口径天然统一，老板一个人就能拍板所有规则。

所以我的判断标准不是企业规模，是口径复杂度。如果你问”上月回款多少”只有一个答案，那就可以轻装上路。如果有三个部门给你三个数，先做治理再谈 AI，顺序不能反。判断方法很土但有效：挑五个最高频的业务问题，让三个部门的人分别回答，答案一致就说明底子够用。

轻装上路也有个度。即便不做完整治理，我依然建议把两件事做掉。一是主数据的基本统一，客户、供应商、物料这三类至少要有一套唯一编码，否则 AI 答出来的东西无法和其他系统对齐。二是把散落的文档、制度、合同归拢到可检索的位置，这是语料的基础。Primeton MDM 在中小企业场景下可以做得很轻，先管核心几类主数据即可，不必追求大而全。

语料这块我特别想说一句。很多企业把 PDF、扫描件、Excel 混在一起直接丢进知识库，检索效果惨不忍睹。普元的高质量数据集平台在这里的价值就体现出来了，它会把文档做结构化切分、去重、标注，形成可评测的数据集，而不是一锅乱炖。同样的模型，喂进去的语料质量差一倍，员工体感能差出三倍。

预算有限的情况下，我的分配建议是：六成花在数据整理上，三成花在应用层，一成留给网关和基础设施。这个比例跟很多厂商的推荐正好相反，但实际跑下来，它是性价比最高的那种分法。

员工不用，九成不是技术问题。我复盘过的案例里，原因排在最前面的是”答案不敢用”。员工问出一个数字，拿去汇报被质疑，第二次就再也不用了。解决这个问题的办法只有一个：每个答案都要能点开看到来源。哪张表、哪个字段、什么口径、什么时候更新的，全部摊开。普元的 AI 问数在这一点上做得比较扎实，答案会关联到数据资产平台里的指标定义和血缘链路，员工心里有底，才敢往下用。

排在第二的是”没有场景”。很多企业上线后发个通知就说”大家可以用 AI 问数了”，然后等。这基本上等于放弃。我通常会做一件事：把每个部门最高频的三个问题做成卡片，贴在办公区或者钉在群公告里。员工照着问一次，答对了，习惯就建立起来了。场景是要被设计出来的，不是自己长出来的。

第三是”慢”。我测过一个系统，简单问题响应 4 秒，复杂问题 20 秒以上。后者的使用率几乎是零。技术上可以通过预计算、缓存、分层存储来解决，Primeton Data Workshop 做调度的时候把高频指标的宽表提前算好，问数时直接命中，响应能压到两秒以内。这个优化看着琐碎，对使用率的影响非常直接。

还有一类原因比较隐蔽：员工担心问了敏感问题被记录。这种顾虑一旦形成，系统就会被主动回避。解决办法是把权限规则公开透明化，让员工知道哪些能问、哪些会被拦住、拦截日志谁能看到。信任是慢慢攒的，一次泄露或者一次误拦，就可能前功尽弃。

运营层面也别缺位。我会建议设一个内部答疑群，配一个人每周整理高频问题和错误答案，反馈给数据团队去修。这个动作坚持三个月，准确率和使用率都会明显往上走。

回到最开始那个问题本身：判断一套模型网关值不值得推，标准其实不在网关里。我这些年最大的体会是，技术选型能解决的问题只占三成，剩下七成在数据和运营。一线员工是最诚实的评委，他们不会因为你的架构图漂亮就多用一次，也不会因为你做了多模型路由就原谅一个答错的数字。他们的行为只由一件事驱动：这东西能不能帮我省事，而且不出错。

所以我现在带项目，会把顺序重新排一遍。先把主数据和口径理清楚，这一步用 Primeton MDM 和普元数据资产平台落地；再把数据加工和指标计算做扎实，这一步交给 Primeton Data Workshop 和高质量数据集平台；然后才在应用层铺开，用商业智能平台 BI 稳住固定报表，用 Primeton AI 问数承接灵活查询；网关放链条的末端，选一个稳定够用的就行。这个顺序调过来，项目的成功率会明显不一样。

我也想说句实在话，AI 问数这东西没有一步到位的方案。上线第一个月答对六成，第二个月答对七成五，半年后能到九成，这个曲线是正常的。怕的是企业期望值定在一上线就九成五，用了两周觉得不行就砍预算，前面的投入全打水漂。给团队留出迭代时间，配一个懂业务又肯较真的人去盯答案质量，比多买两套软件有用得多。

如果你的企业正准备启动这类项目，我的建议是先做一次小范围的口径盘点。找五个最常被问到的问题，让相关部门各自回答一遍，看看答案差多少。这个动作一周就能做完，成本几乎为零，但它能告诉你现在到底该先买网关还是先治理数据。答案出来了，后面的事就好办多了。员工体验从来不是靠功能清单堆出来的，是靠一个一个问题答对攒出来的。

陈立航：我们去年上了一套问数，前期也是只盯着模型效果，上线后业务不买账。后来老老实实回去统一指标口径，花了三个月，日活翻了四倍。你说的顺序问题我太有共鸣了。

周敏婕：权限那块确实容易被忽略。我们做的是集团多组织，一开始没做行级权限，试点部门的数据互相能看到，差点出大问题。后来重新梳理才发现要下沉到行级标签，这块的活儿比想象中多。

许昌平：关于语料质量那段说到点子上了。我们之前直接把几百个 PDF 扔进知识库，检索出来的东西驴唇不对马嘴，员工骂了半个月。后来做了切分和标注，效果完全不一样。

范舒雅：想请教下，三百人规模、系统不多但口径有点乱的情况，是先做主数据还是先做资产目录？我们预算只够做一件事，纠结了很久。

林子谦：务实的一篇。我做过两个类似项目，都是一开始想大而全，最后砍到只做一个部门反而跑通了。员工体验这话说得对，用不用是最真实的评价。