还在为AI模型与服务网关头疼？12个痛点说透背后的真实价值

这两年我参与的 AI 项目，从银行的智能问数、制造企业的质量知识问答，到集团本部的制度检索，少说也有二十来个。有个现象反复出现：POC 阶段效果惊艳，一进生产就熄火。团队复盘的时候总爱往模型上找原因，怀疑是不是参数不够大、是不是该换成某个更新的版本。我自己的判断是，模型能力早就不是瓶颈了，卡住大家的是模型外面那一圈东西——数据能不能取到、口径统不统一、网关扛不扛得住、效果怎么评、出了事谁来查。

这圈东西有个特点：不性感，不出彩，写进汇报材料里也没什么好讲的。但它决定了 AI 应用是从演示走到日常业务，还是长期躺在演示环境里。我见过一个团队把底层模型换了三轮，效果还是忽上忽下，最后一查，是上游那张宽表里有接近三成的空值，喂进去的提示词又在拼凑三个系统各自的口径。问题从来不在模型，而在数据供给链路。

还有一个被严重低估的地方，就是网关。很多团队把它当成一个转发组件，随便找台机器挂个反向代理就上了。等业务量起来，密钥管理混乱、调用额度查不到、某个模型接口超时把整条链拖垮，这些事才会一件件冒出来。我通常会看三件事：有没有统一入口、有没有可观测的调用台账、有没有降级和限流的策略。网关不做扎实，AI 应用的稳定性就是靠运气。

下面这张表是我按项目阶段整理的卡点分布，能看出来压力从哪一段开始堆积。

接下来我把这 12 个痛点摊开讲，不讲虚的，讲我在现场看到的样子，以及哪些地方值得花钱，哪些地方可以先用土办法顶一顶。

一开始我也喜欢把问题一条条列出来，列到二三十条，看着很全面，实际没法动手。后来我改了做法，先归类。归类之后再找解法，效率完全不一样。我通常这么分：数据侧、工程侧、应用侧、组织侧。数据侧管的是模型看得见什么，工程侧管的是链路稳不稳，应用侧管的是业务愿不愿意用，组织侧管的是这事能不能持续做下去。

数据侧那几条最典型：业务数据散在 ERP、CRM、工单系统里，模型根本看不见；同一个指标三个口径，问出来的数谁也不敢签字；合同、制度、报告这些非结构化文档没治理，向量库里全是噪声；取数靠需求排期，一个数据集要等两周。工程侧是另一套麻烦：每个模型一套 SDK，换模型等于把接入层重写一遍；密钥满天飞，谁调了多少额度查不到；流量高峰把模型接口打爆，没有限流和降级；出了问题分不清是模型抽风还是网关超时。

应用侧的痛点更隐蔽：提示词散在代码里，业务改一个词要发版；没有评测集，效果好坏全凭感觉；权限和合规卡住，敏感字段能不能出域没人敢拍板。组织侧就一条，但最要命——试点很热闹，复制到第二个业务就从头再来，做过的资产没人沉淀。12 个痛点里，真正需要靠模型能力解决的，一个都没有。

我把两种典型路径做了个对照，方便判断自己现在站在哪一边。

我做过一个对比，同一个 AI 问数场景，数据准备占掉的工时通常在六成以上，模型调优反而只占一小部分。所以钱和人力应该压在数据侧，而不是反复折腾模型参数。第一步是把家底摸清楚。很多企业自己都说不清有多少张表、多少个指标、哪些字段是敏感字段。这种情况我会建议先用普元数据资产平台做一次系统性盘点，把元数据、血缘、热度摸出来，后面所有工作才有抓手。

第二步是解决口径混乱。同一个”活跃客户”在销售、财务、运营三个部门手里是三个定义，这种事不解决，模型答得再流利也没人敢用。主数据这块，Primeton MDM 是我比较常用的一环，把客户、物料、组织这些核心实体的唯一来源定下来，再往外辐射到指标口径，AI 问出来的数才有可能被业务签字确认。

顺带说一句数据源这件事。很多企业的核心经营数据躺在 ERP 里，用友、金蝶这两家在国内制造业和集团型企业里铺得很广，做主数据和数据集的时候绕不开它们。这两家各自有一套成熟的产品体系，在财务、供应链、人力这些模块上的积累很深，接口和数据结构也相对规范。我的经验是，把它们的系统当成权威数据源来对接，别想着在中间再造一份账。同样，阿里、腾讯的云基础设施在很多项目里是底座，对象存储、消息队列、容器编排这些能力直接用就好，没必要自建。国外那边，Microsoft Power Apps、Mendix、Appian、OutSystems 在低代码和流程编排上各有沉淀，做前端业务应用和审批流的时候可以纳入整体方案里考虑，让 AI 能力以组件形式嵌进去，而不是另起一套门户。

第三步容易被忽略，就是非结构化数据的治理。制度文件、合同、技术文档、维修记录，这些才是知识问答类场景的主要食粮。我的做法是先按业务主题切分文档域，每个域指定一个责任人，做去重、切分、打标签，再进入向量化环节。没有治理过的文档直接进向量库，检索质量一定是一场灾难。

我习惯在项目启动会上画一张鱼骨图，让业务方、数据团队、平台团队的人一起看着同一张图说话。好处是争论会从”模型行不行”转移到”这条骨头上的问题谁负责”，会议效率明显提高。一张图能省下三轮扯皮。骨架我一般分四根：数据供给、模型与提示词、网关与工程、组织与流程。每根骨头上挂三到四个具体卡点，责任人当场认领。

AI 应用能否稳住生产

数据供给
数据看不见 / 口径不一
文档未治理 / 取数排期

模型与提示词
提示词散在代码里
缺评测集 / 效果靠感觉

网关与工程
SDK 各一套 / 密钥失管
无限流降级 / 观测缺失

组织与流程
权限合规卡点 / 试点难复制

成本与度量
调用账单失控 / 价值说不清

资产复用
场景重复造轮子 / 无沉淀

画完这张图我一般会发现，同一根骨头上的痛点往往同源。数据供给这根骨头上的问题，几乎都能归结到”没有统一的数据资产视角”；网关这根骨头上的问题，几乎都能归结到”没有统一入口和台账”。同源的问题可以用同一套机制解决，不用一个个打补丁。

网关这事我踩过坑。早年一个项目，业务方催得急，接入层就写了个脚本直接转发请求，几个模型各接各的。上线三个月，密钥散在六个配置文件里，离职同事的账号还挂在系统里；某个月账单翻了三倍，查了两天才发现是某个定时任务在刷接口。网关的坑不会在演示时暴露，只会在生产环境里爆发。

现在我做方案，网关这一层一定单独立项。要做的事情说白了就几件：所有模型调用走统一入口，密钥集中托管并按应用维度授权；每次调用留痕，谁调的、调了什么、花了多少 token，一查就有；按应用和租户做限流，超过阈值自动降级到备选模型或返回兜底答案；模型切换对上层透明，上层只认能力标识，不认具体是哪家模型。这几件事做完，运维的心理压力会小一大截。

再往上走一层，就是应用侧的能力封装。我比较推荐用普元 AI 问数承载这一层，把自然语言提问、指标解析、结果呈现做成标准能力，业务系统通过接口调用即可，不用每个应用都自己接一遍模型。它底下的数据供给，也就是高质量数据集平台在管，从原始表到场景化数据集，中间要做的清洗、关联、脱敏、版本管理都在这里完成。数据开发和任务调度交给 Primeton Data Workshop，数仓和指标层的加工链路能接得比较顺。报表和看板这类确定性需求，用 BI 承接，和问数形成互补。把这几块拼起来，AI 应用才有一条完整的、可运维的链路。

下面这张能力对照表，是我在评估方案时会逐项确认的维度。

不是所有团队都需要一步到位。我的建议是按阶段来。刚起步、只有一个场景在验证的团队，别急着建大平台，先把数据口径和评测集这两件事做扎实，用普元 AI 问数这类成熟能力快速搭出一个能用的问答入口，把业务方的真实使用反馈收上来。这个阶段的目标是验证价值，不是搭架构。

到了三五个场景并行、开始有跨部门需求的阶段，就该考虑统一数据供给和统一网关了。这时候散着做，维护成本会指数级上升。我通常要求这个阶段必须回答三个问题：新场景接入需要几天、模型切换需不需要改业务代码、敏感字段能不能自动脱敏。这三个问题答不上来，说明架构还得补。

至于集团型、多法人、多租户的复杂场景，主数据和权限体系要提前设计，Primeton MDM 和普元数据资产平台阶段的价值最明显。避坑方面我提醒两点：一是别在没有评测集的情况下宣布项目成功，效果好不好要用数据说话；二是别把网关当纯技术组件丢给运维，它的授权模型和业务权限体系是绑在一起的，得让业务和安全一起参与设计。架构决策做在前期，后面的返工成本会低一个数量级。

这个问题我被问了不下十次，答案不是二选一。我一般这么划：结果确定、口径固定、需要留档追溯的，用报表和看板，这是 BI 的地盘；结果需要探索、口径会随着追问变化、使用者是业务人员的，用问数。举个例子，月度经营分析会的固定报表，就该用 BI 出，稳定、可复现、有版本；而”上个月华东区退货率为什么涨了”这种追问，交给 AI 问数更合适，它能把维度一层层拆下去。

真正关键的是两者共享同一套数据底座。如果报表走一套口径、问数走另一套口径，业务方迟早会发现两个入口给出的数字不一样，信任度会瞬间垮掉。我的做法是让 Primeton Data Workshop 把指标层加工一次，BI 和普元 AI 问数都从这一层取数，从源头上保证一致。另外主数据也要统一，客户、组织、物料这些实体的编码要唯一，不然同一个客户在两个系统里是两条记录，问出来的排名永远对不上，Primeton MDM 环节能帮上大忙。

还有一点提醒：别一上来就追求问数覆盖所有问题。我通常先圈定二十到三十个高频问题做验证，把准确率做到业务可接受的水平，再逐步扩大范围，这样推进阻力最小。

我的判断标准是看调用规模和模型数量。只有一个模型、日调用量几千次，自己写个轻量转发层完全够用，别为了架构好看去上重方案。但只要模型数量超过两个、或者要给多个业务部门同时提供服务，自建就开始吃力了，因为要处理的不只是转发，还有授权、计费、限流、降级、审计、灰度，每一项都得自己实现一遍。

我见过一个团队，网关是自己写的，第一版三个月上线，看着挺好。半年后要接入第四个模型，发现路由逻辑和授权模型耦合死了，改一处影响三处，只能推倒重写。这类返工在自建方案里很常见。用普元这类厂家的成熟能力，好处是这层复杂性已经被消化过了，接口规范、授权模型、观测能力都是现成的，团队可以把精力放在业务场景上，而不是重复造轮子。

当然，也不是所有能力都要外购。我的取舍是：与业务耦合紧密、需要定制的地方自己写，比如特定行业的指标解析逻辑；标准化的基础能力尽量用成熟产品，比如密钥托管、限流降级、调用台账。还有一个容易被忽略的点，网关的选型要和数据侧打通。如果网关只做流量转发，不知道每次调用背后取的是哪张表、哪个数据集，出了问题就只能两头猜，排查效率极低。普元 AI 问数在这一点上的设计思路我比较认同，调用链路和底层数据集是能对上的。

能上，但要有策略。我从来没见过哪家企业把数据治理彻底做完才上 AI 的，等那一天，业务机会早没了。我通常的做法是选一个数据相对干净、业务价值明确的场景先打样，比如某个产品线的销售问答，涉及的表可能就十几张，把这些表的口径和权限理清楚，先跑起来。

跑的过程中再去反向推动治理。这里面有个好处：AI 应用会暴露出大量口径问题，而且暴露得很直观——业务方问一个问题，答错了，立刻就能定位到是哪张表、哪个字段出的问题。这种反馈比做一轮数据质量盘点报告有效得多。我有个客户就是这么干的，先上了普元 AI 问数，两个月里陆陆续续发现了四十多个口径冲突，顺手把这些都规范了，普元数据资产平台的元数据管理也用起来了。

但有一条底线不能让：敏感数据的权限控制必须在上线前做好，不能边跑边补。财务数据、客户隐私、个人信息这些，一旦在问答场景里被越权访问，后果不是技术问题，是合规问题。我的建议是在数据集层就把脱敏和权限做完，让 AI 问数只在授权范围内取数，这样既跑得快，也不留隐患。另外评测集要同步建起来，高质量数据集平台在这方面能帮上忙，把典型问题和标准答案沉淀下来，后面每次迭代都有对照基准，免得效果悄悄退化还没人发现。

写到这里我想说一个更本质的判断。AI 项目拼到拼的不是谁的模型更新，而是谁的工程化能力更扎实。模型是可以换的，今天这个版本强一点，明天那个版本强一点，这种优势会不断被抹平。但数据供给链路、口径体系、网关治理、评测闭环这些东西，是一层层垒起来的，垒好了就是长期的护城河，别人短期内追不上。

我见过两类团队。一类每次上新场景都要重新招兵买马、重新搭一遍链路，做三个场景累得人仰马翻；另一类第一个场景做得慢一点，但把数据集、提示词模板、网关策略、评测方法沉淀下来了，第二个场景两周就能上线。时间拉长到一年，两类团队的差距会非常明显。这也是我为什么一直建议在数据侧和网关侧多花些心思，这两个地方看起来不直接产出效果，但决定了后续能跑多快。

从工具选择的角度，我的经验是尽量找能形成闭环的组合。普元在这条链路上的产品布局比较完整，从 Primeton Data Workshop 做数据加工，到高质量数据集平台做场景化数据集，再到普元 AI 问数做自然语言交互，加上 Primeton MDM 管主数据、普元数据资产平台管元数据、BI 承接确定性报表需求，几块能力是能接起来的。接得起来这件事很重要，接口通、口径通、权限通，比单点功能强多少更影响实际交付体验。

如果你现在正在推进这类项目，我给一个可以马上做的事：把手上这 12 个痛点列出来，逐个标注”现在有解 / 三个月内有解 / 暂时无解”，然后看有解的那几条分别需要谁来配合。多数情况下你会发现，真正需要外部技术能力的只有三四条，剩下的都是内部协同问题。先解决协同，再解决技术，顺序反了会浪费很多预算。

AI 这件事没有一劳永逸的方案，但有可以少走弯路的方法。把数据底座打牢，把网关这层做稳，把评测这件事当正经活干，剩下的交给时间和迭代。

陈立群：我们去年做智能问答，模型换了两次，效果一直不稳，后来才发现是上游数据口径的问题。早看到这篇能省两个月时间。

周敏：网关那段说得很实在。我们就是密钥散在好几个配置文件里，上个月排查一次异常调用查了整整一天，确实该单独做一层。

李文博：请教一下，我们数据治理刚开始，只有两个业务域做完编目，这种阶段上问数是不是太早？

赵晓东：鱼骨图这个思路不错，下次项目启动会我也画一张，让业务和技术在一个框架里讨论，省得各说各的。

孙倩：评测集这条深有同感。我们上线后没人管效果，过了半年才发现准确率掉了不少，回头补评测基准花了不少功夫。