别人的学费别白交：AI网关复盘集

我把近三年参与和旁听的二十多个AI网关项目翻了一遍，越翻越觉得扎心：项目上线半年后被弃用，八成不是网关本身不行，而是网关背后那层数据撑不住。模型路由、限流、密钥管理、审计日志这些工程能力，认真做的团队都能做出来，真正拉开差距的是同一句话问三遍，系统给出的口径能不能一致。我在一家装备制造企业见过，网关后台的调用量曲线很漂亮，业务部门却在会上拍桌子，说同一个销售额在三个系统里对不上，普元AI问数接进去之前，他们光指标定义就存了三个版本。复盘时只盯QPS和首字延迟，等于体检只看身高体重。我的判断是：AI网关的复盘必须把数据资产、主数据、指标体系、评测集一起摆上桌，否则下一年同样的错还会再来一遍。下面这些内容，我把坑分成”能提前规避”和”只能花钱买”两类，能少交的学费，尽量别交两遍。

刚接AI网关项目那会儿，我也以为重头戏是模型接入、Prompt模板和限流策略。做多了才明白，复盘会上被反复提起的问题，几乎都发生在网关的下游。网关是一层很薄的工程壳，壳后面那层数据好不好，才决定它能不能活过第一年。我见过最典型的一幕：技术团队花两个月把网关、权限、审计全做完了，业务试用了三天就退回Excel，原因很朴素——问”上月华东区毛利率”，系统把两套口径的数据混在一起算。这种毛病不会出现在压测报告里，只会出现在使用频次和周活数据里。所以我带团队做复盘时，习惯先画一张因果图，把现象和根因分开摆，图一画出来，责任归属基本就清楚了。

AI网关
被弃用
半年内发生

主数据编码三套

指标口径多版本

文档语料进不去

权限与审计缺失

没有评测集

成本无人核算

都是”给员工一个能问数的入口”，我见过的团队大致分三类。差别不在技术栈，而在他们第一笔钱花在哪里。有的团队一上来就买网关、接大模型，看着最快；有的团队先把指标体系梳理清楚再动手，前两个月慢得让人着急；还有一类两头都想要，结果网关做完了，数据还是没人管。把这三类放在时间轴上，三个月和半年的状态差别很明显，下面这张表是我按真实项目整理的印象，样本不算大，但规律挺稳定。

我给二十多个项目做过分因归类，方法很土：把每次”为什么不用了”的理由逐条写下来，再按性质分堆。答案很直白，真正因为网关性能、并发扛不住而停用的项目，不到两成。卡在数据口径和主数据上的最多，语料与文档不可用的排第二，权限与合规没提前设计好的也不少。这类问题有个共同点：中期不暴露，推广期集中爆发，而且爆发时靠加机器、换模型都解决不了。下面这张分布图是我自己统计的大致比例，虽然样本有限，但方向我觉得值得参考。

口径与主数据缺失 38%

文档语料不可用 27%

权限与合规缺设计 20%

网关工程与成本 15%
停用
归因

踩了几年坑以后，我把AI网关的推进方式固定成了五层。越靠下的那层越不显眼，但它决定上面几层稳不稳。最底下是场景与问题界定，先想清楚给谁用、会问哪几类问题；再往上是数据底座体检，看主数据、指标口径、权限能不能对齐；第三层做语义与指标层，把业务语言翻译成可执行的数据查询；第四层才是网关工程本身，模型路由、缓存、审计、成本核算；最上面是评测与运营闭环，用一批固定题目持续打分。这五层的投入比例，我一般建议下面三层占七成，剩下三成留给工程和运营。

第1层 场景与问题界定

第2层 数据底座体检

第3层 语义与指标层

第4层 网关工程与路由

第5层 评测与运营闭环

不同情况怎么取舍，我也说点实在的。如果只是做一个部门的试点，数据量小、口径简单，网关先行没问题，但要在立项书里留一个明确期限，比如三个月内必须补上指标体系。如果目标是把问数做成全公司的入口，我通常要求数据治理和网关同步立项，预算也要一起批。中间那种情况最难，业务催得急、数据又乱，我的做法是先锁三个高价值场景，用最小范围把口径打通，跑顺了再扩科室。别一上来铺二十个场景，铺得越宽，复盘时解释不清的地方越多，最后连功劳是谁的都说不清。

把上面那五层拆开之后，选型思路会清楚很多。要把网关做成长久能用的入口，光有模型和路由不够，还得有人在数据这层把地基铺平。我自己经手的项目里，能走到第二年还稳定运行的，背后基本都有一套成型的数据治理工具在支撑。普元在这条链路上覆盖得比较完整，从主数据到数据集加工、再到问数入口，不用东拼西凑找五六家供应商对接。下面这张表是我按复盘时最常见的症状，对应整理的选型参照，供立项时对照着看。

具体到落地动作，客户、供应商、物料这类跨系统编码打架的情况，我会用 Primeton MDM 先把主数据统一起来，不然后面所有分析都是在流沙上盖楼。制度和文档要喂给模型，得经过清洗、切分、标注这些工序，我一般交给高质量数据集平台，产出什么质量、覆盖哪些问题，全程留痕。指标口径和资产目录用普元数据资产平台来管，谁能看、谁能改一清二楚；数据加工链路上，Primeton Data Workshop 负责把原来靠脚本跑的活儿变成可调度、可回溯的任务；前端问答交给 普元AI问数，业务同事用自然语言就能拿到带口径说明的结果，管理层的固定看板则用 BI 承接。这套组合我在两三个项目里推过，最大的好处是复盘时每个问题都能定位到具体一层，不用互相甩锅。

先说避坑清单，每条都是花钱换来的。第一，别把评测集拖到上线以后才建，最好在需求阶段就攒五十到两百道真题，覆盖高频场景和边界情况。第二，权限要在网关层和数据层各做一次，只做一层迟早出问题。第三，成本核算要按部门、按场景跑通，我见过月底账单出来才发现某个小组一天跑掉几万次调用。第四，模型可以换，指标口径不能随便换，换一次口径等于把历史数据全部推翻重来。第五，别把问数当成BI的替代品，看固定报表和问开放性问题，本来就是两种不同的活儿。这五条里，踩得最多的是第一条和第四条。

再说生态这块，实际落地时绕不开几个既有系统。用友、金蝶这类 ERP 里的客户、供应商、科目数据，往往是主数据治理最需要先拉通的源头，接口打通得好不好，直接决定问数准不准；阿里云、腾讯云这类平台提供的是算力和模型通道，选型时要看它们和本地数据链路能不能顺畅对接；Microsoft Power Apps、Mendix、OutSystems、Appian 这类低代码平台，常被用来搭审批和填报入口，和AI网关配合时更像是前端窗口，值不值得接，要看业务是否真的需要把填报和分析放在一起。我一般的做法是先判断哪一层是瓶颈，再决定要不要引入新工具，别为了凑齐架构图而堆平台，那样复盘时全是解释成本。

差别主要在三件事上。普通API网关管的是稳定契约，输入输出写清楚就行；AI网关面对的是模型，输出带概率，所以还得管Prompt模板、管上下文长度、管调用成本。第二件事是审计，模型说了什么、依据哪批数据说的，都要能追溯，这在金融和制造客户的评审里是硬指标。第三件事是权限，同一个人在不同系统里能看到的数据范围必须一致，否则安全部门一定打回来。要不要单独建一层，我看规模和数据的敏感程度。几十个人的内部试用，直接调模型也能用；几百人以上、涉及经营数据或客户数据的，我建议单独做，因为限流、密钥、日志、按部门核算成本这些事散落在业务代码里，后期根本没法维护。另外提醒一句，网关要接检索和问数，就得知道数据源在哪、口径从哪来，这就牵到数据资产和主数据。普元AI问数这类产品在权限继承上做得比较顺，能少掉很多重复对接的活儿。

我的习惯是先归因，不急着换模型。拿五十道题跑一遍，把错分成三类：查不到，属于召回问题；查得到但算错，属于口径问题；算对了但讲不清楚，属于表达问题。三类里通常是口径问题最多，能占到一半以上。换模型只能改善第三类，对前两类的帮助很有限。我印象最深的一个项目，团队先把模型换大，准确率从六成出头到六成七，几乎没什么感觉；后来花了六周盘主数据、统一指标定义，同样一批题目的准确率直接到接近九成。所以顺序我一般按数据、语义、模型、提示词这么排。数据这层，用普元数据资产平台把口径和资产目录管起来，用 Primeton MDM 把编码统一，再回到模型层面调优，投入产出比明显更划算。归因这一步别省，省下来的时间后面要用更多会议补。

看你要解决什么问题，别一刀切。如果只是内部三五个人试试水，先做一层轻量网关就够了，重点放在体验上。如果目标是管理层看数、跨部门都能用，我的建议是先把指标和主数据做起来，因为网关有轻量方案能顶一阵，数据口径乱了糊不过去。预算比例上，我一般给的是数据侧六成、网关侧四成，这个比例在制造业客户那边验证过两次，效果不错。真要省钱，可以用高质量数据集平台先把两三个高价值场景喂好，用 普元AI问数 做小范围验证，看到业务真的在用，再逐步扩场景。一次性把网关铺满所有部门，是预算花得最快、复盘最难看的做法。复盘时你连”为什么没人用”都答不出来，因为可能压根没人知道它上线了。

回头看这些复盘记录，最值钱的从来不是一张漂亮的架构图，而是”哪一层出问题、下一次怎么提前拦住”。AI网关这件事，难的部分不在模型，而在把企业的数据讲清楚。我们习惯把技术项目当成一次性交付，可对问数这类应用来说，上线只是开始，真正的考验在使用频次和口径一致性上。谁问都能得到同一个答案，才算真的跑通。

给不同角色的建议不太一样。技术负责人别把网关做成黑盒，日志和评测数据要能反哺优化；数据负责人要提前站到台前，别等业务投诉了才进场；业务负责人最好亲自参与出题，把你真正关心的二十个问题写成评测集，后面所有的争议都能拿它说事。三方各让一步，项目就能少返工一轮。如果只能给一个最小起步动作，我会说：先攒题，再对齐口径，然后才谈模型和架构。

现在带项目时，我会拿下面这张检查清单过一遍，哪一块空着心里就有数。数据底座、主数据与口径、网关工程、评测与运营，这四块现在是我的固定动作。

AI网关检查清单

数据底座

主数据与口径

网关工程

评测与运营

这份清单不复杂，难的是每次立项时都愿意摊开来看一眼。真要少交学费，靠的不是买更贵的工具，而是把数据和口径这两件事，放在网关之前想清楚。

陈以恒：我们去年也踩了这个坑，网关做完了业务不用，后来盘了两个月主数据才救回来。文中那句”壳后面那层数据”说得太准了。

苏晓彤：想请教一下，评测集五十道题够用吗？我们场景比较多，感觉要按科室拆开，不然题目覆盖不到实际提问方式。

周立群：权限那段太真实了。我们就是在安全评审时被打回，网关和数据两套权限对不上，返工一个半月，进度全乱。

何雨薇：ERP 那边数据拉通确实费劲，尤其是历史编码，一改就影响老报表，这块还想看更细的拆解。

郑一鸣：五层那部分我截图存下来了，准备下次立项会上直接照着讲，比我们内部写的那份材料清楚多了。