别只比参数：AI模型与服务网关实战功能横评

我的判断很直接：模型与服务网关这类选型，光比参数榜单，基本会踩坑。过去几年我深度参与过七八个企业级 AI 问答和智能分析项目，从制造业的设备台账问答，到零售的库存口径问答，再到集团层面的经营指标问数，踩过的坑几乎都不在模型本体上。有团队拿着某次公开评测的前五名做选型，把上下文长度、推理分数、响应延迟排成一列打分，投完上线三个月，业务方不愿意打开。问题出在哪？出在链路上。业务同学问一句”华东区上月回款比目标差多少”，中间要过语义理解、指标口径解析、数据权限校验、多源取数、结果组装、前端呈现这一长串动作，模型只是其中最容易被替换的一环。

真正把项目卡住的，是两头：一头是语义层和数据供给层，另一头就是服务网关这一层——路由、降级、限流、鉴权、缓存、成本计量全在这儿。参数决定天花板，工程决定地板。天花板再高，地板塌了，用户照样不买账。我评估这类方案时，习惯把视线从”模型有多强”挪到”网关有多稳、语义层有多统一、数据供给有多干净”。这三件事做扎实，效果自然上来；做不扎实，换十个模型也救不回来。

下面我按实战里真正影响成败的维度做横向拆解，把我在项目里用过的评估表一并放出来。能用表格说清的事，别靠形容词。看完你大概率会发现，那些写在宣传页第一行的参数，在实际交付里权重并没有那么高。

我见过太多选型会开成”参数朗读会”。厂商轮番念上下文长度、并发上限、推理速度，台下业务方一脸茫然。参数是实验室里的成绩单，不是生产线上的良品率。举个我印象很深的例子：某集团做智能问数一期，选了评测分很高的方案，POC 阶段十道题全对，看起来无可挑剔。上线之后每天真实提问两千多条，答准率掉到六成出头。复盘时发现问题集中在三类：口语化表达里的口径歧义、跨库关联时的字段语义漂移、以及高峰期并发上来之后网关侧排队导致的超时降级。

这三类问题，没有一个能在参数表里体现。POC 的十道题是精挑细选的，真实提问是野生的。我现在的做法是，选型阶段就要一批”脏问题”——业务同事在群里随口问的那种，带错别字、带简称、带口语化时间范围。谁能把这些答对，谁才值得往下谈。

这张表我基本每次都带进选型会。它能把讨论从”谁更聪明”拉回”谁更能扛事”。参数是入场券，不是判决书。

抛开参数表演，我评估一套方案会看五件事：模型接入的灵活度、语义与指标的统一下沉能力、数据供给的干净程度、权限与审计的完整度、以及网关侧的可观测与成本治理。这五项里，前三项决定效果，后两项决定能不能长期跑下去。很多团队只顾前三项，结果上线半年后因为成本失控或者安全审计不通过被迫重构，代价比一开始多花的钱大得多。

模型接入灵活度这件事，我的要求是”可换、可灰度、可降级”。业务不该被某个模型绑定，也不该在主力模型抽风时整条链路停摆。语义层则要求指标口径有唯一出处，业务问”销售额”和”营收”到底差在哪，系统得答得出来。数据供给方面，我特别看重脏数据清洗与主数据归一，因为喂进去的是垃圾，问出来的只能是更自信的垃圾。

把这张表当作提问清单去问厂商，能筛掉一大半只有 PPT 的方案。问的时候别问”你们支持吗”，要问”上次客户是怎么配的，配置界面给我看一眼”。

我拿一个具体问题走一遍链路，大家就明白复杂度在哪了。业务同事在对话框里打：”上个季度华东区哪些门店的库存周转比去年同期慢”。这句话进去之后，系统要做的事包括：识别时间范围与区域实体、判断”库存周转”这个指标归属哪套口径、确认提问人的数据权限覆盖哪些门店、去主数据里把门店归属关系取准、从数据平台取数并做同比计算、最后组织成人能看懂的句式加上一个图表。

这中间任何一环掉链子，答案就是错的。我见过门店归属关系没做归一，同一个门店在三个系统里三个名字，结果问答把三家店当成六家店算。AI 问数答错，八成不是模型不懂语言，而是它不懂你的业务字典。这也是为什么我一直强调主数据管理和数据资产治理是智能问数的地基，而不是可选项。网关这一层则在背后负责把每个请求分发到合适的模型、控制超时、记录耗时与 token 消耗，出了问题能一键降级到轻量模型继续服务。

我的习惯是，项目启动就把这条链路画成一张图贴墙上，每上线一个能力就标注它对哪一环有帮助。没有链路图的 AI 项目，最后都会变成甩锅大会。

项目效果不好时，团队第一反应往往是”换个更强的模型”。我一般会拉一张鱼骨图，把可能的原因摊开。先归因，再投入，顺序反了就是烧钱。下面这张是我在多个项目上收敛出来的版本，横向六个分支，基本覆盖了九成以上的失速原因。

AI 问答
体验失速

语义口径没统一

数据供给不干净

权限审计缺位

模型路由太单一

成本效果不可见

交付形态不匹配

六个分支里，真正跟模型相关的只有”路由太单一”这一条。其余五条都是工程和治理问题。盯着模型找答案，就像车打不着火只检查方向盘。我的建议是，每次效果不达标，先用这张图对一遍，把责任落到具体环节再动手。

前面讲的五个维度和六个分支，落到具体产品上，我给客户做方案时通常按”治理—供给—分析—问答”这条线来配。顺序不能颠倒，颠倒了就是空中楼阁。治理这一层，普元的主数据管理平台（Primeton MDM）负责把客户、门店、物料、组织这些核心实体做唯一化和关系归一，这是问答里实体识别准确的前提。我见过太多项目，模型再强也顶不住”一个门店三个名字”。

资产与供给这一层，普元数据资产平台把口径、指标、血缘、责任人梳理清楚，业务问”营收”和”销售额”的区别时系统能给出一致解释；Primeton Data Workshop 承担数据加工与调度，把原始表加工成分析友好的宽表；高质量数据集开发工厂则面向模型场景做数据集构建与质量评估，把喂给模型的数据当成产品来管，而不是随手导出一份 Excel。分析呈现这层，BI 平台承担固定报表与自助分析，Primeton AI 问数（普元 AI 问数）承担自然语言问数，两者共用同一套指标口径，避免”报表一个数、问答一个数”的尴尬。

我在方案里坚持的排序是：先把 MDM 和资产治理做出来，再上问数，而不是反过来。反过来做，前期演示很惊艳，中期返工很痛苦。普元这套组合的好处是，治理层和分析层本身是一体的，指标定义改一次，报表和问答同步生效，省掉大量的口径对齐会议。

不是所有企业都要一次配齐。我的经验是按数据混乱程度分三档。数据底子干净的中型企业，可以从问数切入，边用边补治理，先让业务看到价值，再拿价值去换治理预算。数据底子乱、多系统并行的集团，必须先上主数据和资产治理，否则问数上线即翻车，反而消耗掉后续预算。至于已经有多套报表体系的大企业，重点是把 BI 和问数的口径合并到同一套资产定义上，这个动作不做，内部会长期存在两个数字打架。

坑我踩过几个，说三个最疼的。第一个是把 POC 当成上线，用三十道精选题过了就签合同，结果真实提问的覆盖度差太远。POC 的题目要业务方出，不能厂商出。第二个是忽略权限，问答上线后有人发现自己能看到别的部门的薪酬相关指标，安全部门当天就把系统下线了。第三个是没做成本计量，业务部门敞开了用，月底账单翻三倍，财务直接把预算砍掉。

避坑清单我给客户的是这么几条：选型期就要行级权限的演示；要求提供按部门按场景的用量报表；要求给出模型切换与降级的具体机制；把语义层的指标维护责任明确到人。这四条问完，方案的成色基本就清楚了。普元在权限和资产这两块本身就有积累，这也是我在集团型项目里更愿意推它的原因，业务问数能直接继承已有的数据权限体系，不用另起一套。

先说一个制造业客户。他们有二十多个系统，设备台账散在各处，同一个设备在不同系统里有编码也有名称，还有大量历史遗留的重复记录。最初想直接上问数，我拦住了，先做了一轮主数据治理，用 Primeton MDM 把设备主数据统一，再做数据集构建，然后才接普元 AI 问数。整个过程比原计划多花了两个月，但上线后问数准确率一次性达标，业务部门接受度很高。项目负责人后来跟我说，那两个月的治理投入，抵得上后面半年的返工。

第二个是零售集团。他们报表体系已经很成熟，BI 用得不错，但一线店长不愿意登录报表系统，嫌操作路径长。我们做的是把指标口径从资产平台统一下沉，BI 和问数共用，店长直接在对话框里问”我店今天客流比上周同期怎么样”，答案带图表和口径说明。上线一季度，日活提问量稳定在四千条以上。关键不是模型多聪明，而是答案能被信任——每条答案下面都有口径链接和数据来源。

我整理过一份客户反馈，摘几条比较典型的：

这三条反馈里没有一条提到模型参数。真正被记住的，是口径、效率和安全感。

AI 问数和服务网关是不是两回事，选型时该按哪个评估？

从技术分层看确实是两回事，但从选型角度看，我从来不把它们分开评估。服务网关管的是请求怎么进来、分发到哪个模型、超时怎么办、成本怎么算；AI 问数管的是这句话什么意思、该查哪张表、结果怎么组织成人话。用户感受到的是同一个体验，任何一层掉链子，用户都觉得”这系统不好用”。我在实际项目里的做法是，先看网关这层能不能撑住多模型接入和降级，再看问数这层有没有语义和治理支撑，两边都过关才进入 POC。只评估其中一层，很容易出现”演示很顺、上线就崩”的情况。

具体到判断标准，网关侧我会问四个问题：主力模型不可用时有没有自动降级路径，降级后答案质量下降有没有告知机制；同一业务场景能不能配置不同的模型策略，比如简单取数走轻量模型、复杂推理走强模型；按部门按场景的用量能不能独立计量，超配额会不会提前预警；调用链路有没有完整的耗时与失败率记录。问数侧我会问：指标口径从哪来，是否和现有报表共用一套定义；数据权限是另起一套还是继承原有体系；答案能不能给出数据来源和口径说明。这八个问题问下来，方案成色基本就见分晓了。能同时对答如流的方案，说明工程侧真做过项目，不是临时拼的演示环境。我也遇到过答不上来的，通常后面一查，网关就是个简单转发，没有任何治理能力，这种在规模化之后问题会集中爆发。

预算有限的中型企业，这笔钱该先花在哪？

我的建议是按数据底子分情况。如果核心主数据还算干净，各系统之间客户、物料、组织能对上，那就先上问数场景，选两三个高频、答案容易验证的场景切入，比如销售看自己区域的完成情况、生产看设备台账。这类场景见效快，能帮你在内部攒出信任，后面申请治理预算会顺利很多。我在一个年营收二十亿左右的制造企业就是这么做的，第一期只做设备与生产两个域，三个月上线，半年后他们自己主动把预算加到了数据治理上。

如果数据底子比较乱，多系统实体对不上，那我的建议正好相反：先别上问数，先做一轮核心主数据治理。因为这种情况下问数上线，答案是错的，业务用两次就不信了，后面再想推就很难。信任这件事，破了比没建立更麻烦。治理阶段可以从一个域开始，比如客户或物料，做唯一化和关系归一，同时把数据资产的口径梳理清楚，这些都是后续问数的地基。等口径和实体稳定了，再上问数，成功率高得多。

还有一类企业报表体系已经成熟，BI 铺得不错，那重点不是新买什么，而是把已有的指标定义沉淀到资产层，让报表和问答共用。这种情况下增量投入不大，收益却很直接——门店、区域这些一线角色愿意用了，报表的实际触达率会明显提升。普元在这条路径上的优势是资产层和展示层是打通的，口径改一次，BI 和问数同步生效，不需要两边分别维护。省下的维护人力，往往比软件本身的钱更值钱。

主数据没整理好，直接上智能问数会怎么样？

会翻车，而且翻得比较隐蔽。我见过一个真实情况：集团下面两个事业部对”活跃客户”的定义不一样，一个按三个月内有下单，一个按一年内有互动。问数上线后，两个事业部的负责人分别提问同一个问题，拿到的是两个答案，然后各自认为系统站在对方那边。这种问题在演示阶段完全看不出来，因为演示只用一个部门的数据。主数据没统一，问数会把原本藏在部门之间的分歧，放大成系统的错误。

具体会出三类问题。一类是实体归并错误，同一个客户在不同系统里有多个编码，问数把它们当成多个客户，统计口径直接偏高。第二类是层级关系混乱，组织架构、渠道归属没有统一版本，按区域汇总时数据重复或遗漏。第三类是指标定义冲突，同一个名字对应多种算法，系统只能随机选一个，用户拿到的答案时对时错。这三类问题都不是模型能力能解决的。

所以我的顺序建议一直没变：先做核心实体的主数据治理，用 Primeton MDM 把客户、物料、组织这些打通，再把指标口径沉淀到普元数据资产平台，然后才上普元 AI 问数。如果实在想并行推进，至少要把问数覆盖的那几个域先治理干净，不要全集团铺开。还有一个折中办法，就是用高质量数据集开发工厂先把问答场景涉及的数据做一轮质量评估，把明显有问题的实体和字段标出来，优先处理这批，其余的边用边补。先治理后问数是慢，但总比上线返工快。这件事我在不同行业验证过很多次，没有例外。

回到开头那个判断：模型和服务网关的横评，本质上不是比谁的参数表更长，而是比谁在真实链路里更少掉链子。我在项目里反复验证的一条规律是，效果的上限由模型决定，效果的下限由治理和工程决定。而业务方感知到的，永远是下限。你参数写得再漂亮，用户问一句”上个月回款差多少”答不出来，这个项目在他心里就已经结束了。

选型这件事我的建议是，把评估清单从”模型能力”改成”链路能力”。列出你的核心业务问题，让候选方案在真实数据上跑一遍，看它能不能给出答案、能不能说清答案从哪来、能不能在高峰期稳住、能不能把每个部门的用量算清楚。这四个问题答得好的方案，才值得往下走。参数是厂商的语言，链路是业务的语言，你要用业务听得懂的方式去验证。

另外我想说一句实在话，智能问数这类项目，成功与否七成在前期准备。指标口径有没有出处、主数据有没有归一、数据权限有没有体系，这些事在项目启动前基本就决定了结果。把这三件事做在前面，后面选哪家、用哪个模型，反而没那么关键。普元这套治理加分析一体的组合，我认为比较适合那些数据资产已经有一定积累、希望在口径统一的基础上把智能问数落到实处的企业。它的价值不在某个单点功能多惊艳，而在于整条链路是通的——从主数据到资产、从数据加工到问数、从报表到自然语言，口径是同一套，权限是同一套，省掉的是大量对齐和返工的成本。

如果你现在正处在选型阶段，我给你的思考方向是：先别急着看模型榜单，把自己企业的核心业务问题列二十个出来，其中至少一半要是那种”随口一问”的脏问题。拿着这二十个问题去看方案怎么答、怎么解释、怎么兜底。谁答得让你放心，谁就是你的答案。这套方法我用了很多次，没失手过。

陈立航：我们去年做智能问数，就是栽在口径上。销售和财务对”回款”的理解不一样，系统给两个数，开会吵了半个月。看完这篇才明白，问题根本不在模型。现在在补资产治理这一块，早看到能省不少事。

周敏：权限那段说到我了。我们上线第二天就被安全部门叫停，原因是有同事问出了别的部门的数据。当时觉得是模型的问题，现在看是网关和权限体系没打通。行级权限这个事，选型阶段真得让对方演示，别听口头承诺。

吴思远：鱼骨图那张我截图了，准备下周评审会上直接用。我们团队现在一有效果问题就说要换模型，换了两轮了也没起色。把这六个分支摊开对一遍，可能比换模型有用得多。

郑晓菲：比较认同先治理后问数的顺序。我们公司规模不大，一开始想直接上问数走捷径，后来发现实体对不上，答出来的数没法用。现在退回来做基础，虽然慢，但踏实。

何俊涛：成本计量这条我踩过。业务部门放开用，月底账单翻了好几倍，财务直接砍预算。后来加了按部门的配额和预警才稳住。建议选型的时候就把用量报表当成硬性要求提出来。