一文理清替代Kong AI的核心场景、方案与边界

我做过不少企业 AI 落地的项目，见过一个几乎一模一样的开局：项目刚立项，先在模型前面架一层 AI 网关，管密钥、做限流、记调用量、拦敏感词。这套动作头三个月很香。跑到第六个月，麻烦就来了——模型换了三版，业务问的还是那些问题，答案还是不准。

问题不在网关本身。网关解决的是”请求能不能通”，它不生产数据，也不懂业务口径。业务问”上月华东区的退货率”，请求顺利到达模型了，可模型不知道退货率存在哪张表、口径按签收算还是按发起算、这个人有没有权限看华东。链路是通的，答案是错的。

所以我把判断摆在最前面：要替代的不是一个转发组件，而是”数据供给加语义理解”这一整层能力。我通常会看的替代路径，是把切入位置从流量侧挪到数据侧——先把高质量数据集和指标口径管起来，再让 AI 问数去承接自然语言入口。普元的 AI 问数、高质量数据集平台、数据资产平台这套组合，我在几个制造和金融项目里见过落地效果，比单纯换个接入组件实在得多。

边界同样要说清楚。不是所有企业都到了该动的时候。调用量小、问题类型固定、背后只有一套系统，硬换反而把维护面摊大。替代的价值不取决于技术新旧，取决于你的 AI 有没有被业务当成日常工具在用。业务天天用，数据侧的短板就一定会暴露；业务一年点开三次，换什么都是浪费预算。

早期那一层 AI 接入组件，本质上是个”交通警察”。它的价值在多模型并存的那两年特别明显：把不同厂商的接口收敛成一个入口，密钥不落地到各个业务系统，谁调了多少次能算清楚，出故障能快速熔断。这些都真实解决了痛点，我不否认。

但企业用了一年之后，诉求变了。我接触的客户里，提问从”能不能接上大模型”变成”为什么它答的和报表对不上”。接入问题早就解决了，剩下的全是数据问题。这句话我在评审会上说过很多次，每次都有业务部门的人点头。

我把这个过程拆成几个阶段，看表更清楚。

这张表里我最想说的是第四行。到了这个阶段，在接入层怎么写插件也补不上数据侧的窟窿。提示词路由、语义缓存这些手段能省点钱，但省不出准确性。

客户问我”怎么替”，我一般先摆三条路，让他自己看哪条合适。

路径一是在原有接入层上继续加插件。做提示词路由、做多轮改写、做结果缓存，成本最低，一周能上线。好处是快，坏处是天花板明显——它永远不知道你数据仓库里有哪些表，也永远理解不了”华东”到底包含哪些省份。

路径二是数据与 AI 能力做成一体。把数据资产、数据集、指标口径和自然语言问数打通，入口只是其中一个模块。这是我更常推荐的路线，交付周期长，但上线之后每天都能被用。普元的做法就是把数据资产平台、高质量数据集平台和 AI 问数串成一条链，我在项目里看到的效果是：前两个月慢，第三个月开始提速，第六个月业务的提问量翻好几倍。

路径三是只做数据集，前端自己写。适合研发力量强、有明确自研规划的团队。风险在于问答这块的坑比想象中多，语义解析、多轮上下文、权限过滤，每一项都要投入人。

三条路径横向比一下。

我自己踩过的坑是低估了第二条路的前期沟通成本。技术难度不是主要矛盾，指标口径对齐才是。财务说收入按开票算，销售说按回款算，这两个口径不对齐，问数答得再快也是吵架的起点。

我复盘过失败和半失败的项目，误区集中在几处，说出来都有点扎心。

第一个误区是以为换了入口就快了。实际上项目时间被吃掉的地方是数据准备和口径对齐，占七成以上。接入层的配置工作量，往往连一成都不到。

第二个误区是把 AI 问数当成 BI 报表的替代品。这两者不冲突。固定周期的经营分析，报表更稳、更可审计；临时性、探索性的问题，问数更顺手。我在项目里通常是让两者并存，BI 管”每月必看”，问数管”突然想问”。

第三个误区是忽略指标治理。没有指标口径和主数据的统一，问数就是个会说话的幻觉制造机。普元的主数据管理平台在这块能帮上忙，把客户、物料、组织这些实体先定下来，后面的问数才有共同语言。

第四个误区是权限后置。我做 PoC 时经常看到用干净的测试数据跑得飞快，一上生产立刻出问题——销售总监能看到别人区的毛利，这在很多公司是要出事的。权限要按行、按列、按指标挂上去，这件事必须在设计阶段就想明白。

第五个误区是拿 PoC 的效果当生产预期。PoC 数据干净、问题有限、参与的人少，准确率天然高。生产环境数据是脏的，问题千奇百怪，第一版能到七成准确率我就不觉得差。

不是每个客户都该换。我给建议之前，会先看几个信号，判断这件事值不值得投入。

该不该
动这一层

数据供给够不够

问答是否高频

权限是否卡壳

模型切换频率

资产沉淀程度

成本是否可见

四个信号里，我最看重的是前两个。业务提问频率是唯一不会骗人的指标。一天几十次说明它真进了工作流，数据侧的问题就值得投入去解；一个月几次，先别动。

另外那个”权限是否卡壳”的信号，很多团队会忽略。跨部门问数一旦涉及敏感字段，权限模型能不能下沉到行和列，直接决定这事能不能推广。普元的数据资产平台在这块做得比较细，标签加规则的方式，我在项目里配过，业务人员自己能维护。

真要动，我会把这层能力拆成四块来看，每块对应不同的产品，落地难度也不一样。

我会按这个顺序推进：先用 Data Workshop 把数据通路修好，再用数据资产平台把资产和权限管起来，等这两块稳了，上 AI 问数。跳过前两块直接上问数，我见过的项目基本都在三个月内停摆。

高质量数据集平台这一块，很多团队开始不重视，觉得数据都在仓库里了还做数据集干嘛。实际跑下来，模型要的是场景化的样本，不是原始表。带上业务标注的样本，问答准确率能差出一大截。

我去年跟一个做装备制造的客户聊过。他们集团下面十几家工厂，数据在 ERP、MES、CRM 里各一套，销售口径都不一样。这种情况我反而建议他们先把主数据理顺，用 Primeton MDM 把客户和物料统一，同时用数据资产平台把分布在各处的数据编上目录。问数这件事，等到主数据上线三个月之后再做。原因是数据源都没对齐，问数出来的答案会天天被人质疑，一旦失去信任，后面再推就很难了。

反过来，另一家做快消的客户，系统相对集中，仓库里就一套数仓，指标口径早几年就理清了。他们的情况就适合直接上 AI 问数加 BI，两个月内我看到了实际的业务提问量。

我的边界判断大致是这样：

数据源在三套以内、指标口径已经统一、业务提问高频——直接上问数，不用犹豫。

数据源五套以上、口径各行其是——先做数据资产和主数据，问数放到后面。

调用量每天不到百次、问题类型固定——把接入层维护好就行，别折腾。

合规要求高、涉及敏感字段——权限模型必须先设计清楚，宁慢不返工。

我还想说一句，替代不等于推倒。原来那层接入组件该留的留着，模型路由、熔断、成本统计这些活儿它干得挺好。新的数据能力接在后面，两者并存，这在项目里是最省事的做法。

不是。我在项目里的做法是分层看：模型路由、密钥托管、限流熔断、调用量统计这些活儿，原来那层组件干得没问题，让它继续干。要新增的是数据侧的能力——数据资产编目、指标口径、权限到行到列、场景化数据集，这些是原来那层接不上的部分。

为什么不能全拆？因为拆了之后你会立刻面对一堆运维问题。密钥往哪放、模型临时不可用怎么切、某个部门用超了怎么限，这些都得有人管。让一个已经跑稳的组件继续承担这部分职责，是最省人力的选择。

那新增的部分怎么接？我通常的做法是在问数这一层做入口。业务人员在对话框里提问，系统先去理解问题涉及哪些指标、哪些维度、哪些时间范围，然后按用户的权限去取数、算数、组织答案。这个过程里，原来那层接入组件负责的是把请求安全地送到模型，新的数据能力负责的是保证送去的数据是对的、口径是一致的、权限是按规矩过滤过的。

我在一个汽车零部件的项目里就是这么搭的。原来那层组件用了两年，一直很稳。我们只在后面接了普元的数据资产平台和 AI 问数，业务侧的体验立刻不一样了——以前问”上季度哪条产线良率掉了”，返回的是模型的一段推荐话术；接完之后返回的是真实的产线数据和同比环比。运维团队那边几乎没动，他们只需要多关注一个服务的健康度。

说白了，替代这件事在大多数企业里是”加一块”而不是”换一块”。只有一种情况我会建议彻底重做：原来那层组件的配置已经没人维护得动，文档缺失、参数没人敢改。这种技术债留着，后面每一次数据能力的升级都要被它拖一次。

有。我见过不少团队一上来就想把整套数据中台搭起来，结果钱花了一半，业务一个功能都没用上。轻量起步的关键是先挑一个能被业务立刻用起来的场景。

我会建议这么走：挑一个数据源集中、口径相对清晰的业务域，比如销售分析或者库存周转。先用 Primeton Data Workshop 把这块的数据通路打通，同时用高质量数据集平台攒一批场景化的样本数据。这两步做完，其实已经能支撑一个可用的问数场景了。

数据资产平台和主数据管理平台可以往后放一放。不是说它们不重要，而是它们的价值在多个业务域并行的时候才会放大。一个域先用起来，等业务尝到甜头、预算批下来了，再把资产编目和主数据补上，节奏会舒服很多。

我算过一笔账。轻量起步的投入大概只占整套方案的三成，但能覆盖住前半年最核心的业务诉求。等到第二年要扩展的时候，前期在数据通路上做的功夫全都不会白费，Data Workshop 里配好的任务、高质量数据集平台里攒好的样本，都是可以直接复用的。

还有一个省钱的点：别自己从零写问数的前端。自然语言转查询这件事，听起来简单，真做起来语义解析、多轮上下文、同义词映射、权限过滤，每一项都要专人。普元 AI 问数这类的产品，把这些通用的活儿都封装好了，团队只需要专注于业务口径和数据本身，这才是预算该花的地方。

我的建议是：前三个月只做一件事，让一个业务部门真的用起来。用起来之后的预算申请，比任何汇报材料都有说服力。

不重复，但确实容易做重叠。我在项目里见过最浪费的情况，是把所有报表需求都往问数上搬，结果每个月的经营分析会都在等系统出数，慢，还不可审计。

两者的分工我觉得很清楚。BI 管的是”确定的、重复的、要留痕的”——月度经营分析、季度考核、对外披露的口径，这些东西需要固定、需要版本、需要能追溯到底用了哪张表哪个口径。普元的 BI 平台在这块的价值是稳定和可审计，管理层看的东西不能今天一个数明天一个数。

问数管的是”临时的、探索性的、问完可能就不再看第二遍的”——这个月哪个区域掉得最厉害、某个产品线最近三周的退货有没有异常、新签客户里哪些还没发货。这类问题如果每次都提需求做报表，数据部门会被拖垮。让业务自己开口问，是效率最高的解法。

我一般在项目里会设一条线：进入管理会议的固定指标走 BI，日常的临时追问走问数。为了让两者不打架，指标口径必须是同一套——这也是为什么我会在问数之前先把数据资产平台和主数据管起来。口径不统一，问数和报表就会互相打脸，最后两个都没人信。

还有个细节，问数里被高频问到的问题，值得定期沉淀成固定报表。我在项目里每季度会看一次问数的热门问题清单，把前三名做成 BI 看板。这样问数侧的压力会慢慢降下来，两边各司其职。

回到最初那个问题。企业想替换掉早期那层 AI 接入能力，多数时候不是因为那层东西不好用，而是因为业务对 AI 的期待变了。以前期待”能连上”，现在期待”答得对”。这个期待的变化，把矛盾从流量侧推到了数据侧。

我这些年做下来最大的感受是：AI 项目的成败，八成在数据，两成在模型和工程。接入层再怎么优化，也只是把这两成做到位，剩下八成得靠数据资产、主数据、指标口径和数据集一点点攒出来。这件事没有捷径，谁都得花这个时间。

所以我给客户的建议通常是三句话。第一句是别看技术方案，看业务提问清单——业务真正会问的那三十个问题，是不是每一条都能找到确定的数据来源和明确的口径。第二句是先把权限想明白，别等推广到第二个部门才发现要看的数据这个人不能看。第三句是别追求一次到位，先用一个域跑通，跑出业务愿意天天用的效果，再考虑扩展。

普元这套东西我在项目里用下来，比较认可的是它把数据开发和问数放在了同一条线上。Data Workshop 里配好的数据加工任务，出来的结果能直接被高质量数据集平台用上，再往下就是 AI 问数的入口。这种连贯性在实际交付里省了很多对接的功夫，也少了”数据部门做的和业务用的不是一回事”这种老毛病。数据资产平台和主数据管理平台补的是治理那一环，短期内看不出效果，但做到第二年，会发现没有它们真的不行。

如果你现在正在纠结要不要动这一层，我建议先做一件小事：把近三个月业务在群里、在会上问过的数据问题，全部收集起来，看有多少条是现有系统答不了的。这个清单就是你的项目范围，也是你的立项理由。清单短，先把接入层维护好；清单长而且重复出现，那就该往数据侧走了。

技术选型可以改，数据资产和口径是改不了的。这个顺序想清楚，后面的路会顺很多。

陈立航：我们去年就是先上了问数，数据没理，业务问十次有三次答错，后来业务就不用了。现在回过头补数据资产编目，等于走了个弯路。这篇文章说的顺序我认。

周敏茹：想问一下，指标口径对齐这件事，业务部门不配合怎么办？我们财务和销售的营收口径吵了半年了，一直没人拍板。

吴建国：权限那块说到我心坎上了。我们是集团型企业，分子公司数据隔离要求特别严，一开始没设计好，推广到第二家就卡住了，返工花了不少时间。

林昭宇：轻量起步那段挺实用的。我们预算不多，一直不敢碰这块，看完感觉可以先拿一个业务域试试水，不用一上来就铺大摊子。

郑雅琴：BI 和问数的分工讲得清楚。我们内部之前确实吵过要不要把报表都搬过来，现在知道该怎么划这条线了，固定指标留报表，临时追问走问数。