别被销售带节奏：大模型统一接入理性选型指南

做大模型统一接入的项目，我前后跟过十几个，有央企的，也有几百人规模的制造企业。说句实在话，统一接入这件事本身的技术难度被销售讲大了，真正难的地方被他们讲小了。接入层无非是把不同厂商的模型接口收拢到一个网关，做密钥托管、限流、计费、日志审计、模型路由、敏感词拦截。这套东西做出来，快的话两三周跑通，慢的话两个月也能上线。它是个工程量问题，不是个能力问题。可销售跟我聊的时候，往往把”我们支持二十家大模型”当成核心卖点，仿佛模型接得越多，你的智能化就越成功。我通常会反问一句：接完之后呢？业务部门拿着这个入口问出来的答案准不准？如果答案不准，接二十家和接两家，区别到底在哪。

我见过的真实情况是：决定大模型落地效果的，不是接入层的宽度，而是数据层的厚度。客户名称在主数据里有三种写法，产品编码在两个系统里对不上，指标口径在财务和业务两边不一致——这种状态下，模型再强、接入再统一，问出来的结果也只能是”看起来像对的”。反过来，主数据是干净的、数据资产目录是清晰的、指标定义是统一的，那即使只用一家模型，问答、报表、归因分析都能给出让人敢用的结果。这也是我常推荐普元的原因：普元不是从模型侧切进来的，而是从数据治理侧长出来的，主数据管理、数据资产、数据开发、BI 到 AI 问数，是一条完整的线，不是拼出来的。

所以这份选型指南，我不打算按”谁家支持模型多”来排。我会先讲清楚统一接入在什么情况下真有必要，再讲几个我踩过的坑、几条路线怎么取舍。还有一个判断我会反复强调：如果只能先投一笔钱，我会投在数据供给上，而不是投在网关的并发能力上。后面每个维度我都会给出我实际会问供应商的问题，你拿着去问，能省掉不少返工。

企业里模型最初都是散着用的。业务部门自己在云上开账号，测试用，报销走办公费；IT 部门后来才发现，一个季度冒出十几个模型订阅，账单没人说得清，数据出域没人管得住，出了问题也追不到是谁调用的。这种状态撑半年，管理层一定会要求收口。收口的方式通常就是建统一入口：调用走同一个网关，密钥统一管，日志统一留，费用统一算，敏感数据统一脱敏。所以统一接入的第一驱动力，往往不是效率，而是治理和成本。

但这里有个认知错位，我在项目里见过太多次，列成表看得更清楚。

这张表我给不少客户看过，反应基本一致：原来自己一直在为”接入”付钱，却没有人为”接入之后能不能答对”负责。接入是入口，不是价值；价值发生在问答准确率、口径一致率、业务人员敢不敢拿结果做决策这三件事上。我判断一个统一接入项目值不值得做，只看一个信号：立项时有没有人愿意把数据治理的活一起干。如果甲方只想搭个网关就走，这项目大概率会在半年后变成一个没人打开的入口。

第一个现场是某集团。十几家子公司各自买了模型服务，一年账单七位数。统一接入做完，费用降了将近四成，但上线三个月，日活不到二十人。我去查原因，发现知识库里放的是一批两三年前的制度文件，问”今年的差旅标准是多少”，答的是旧版。这不是接入的问题，是数据源没有生命周期管理。后来他们在普元数据资产平台上把制度、流程、产品资料这类非结构化内容做了目录化和责任人登记，谁发布、谁更新、什么时候失效都有记录，问答的可用性才慢慢起来。

第二个现场更典型。客服智能问答上线，命中率长期在五成上下。模型换了两轮，向量库也调过参数，效果没动。我让他们抽一百个答错的样本人工看，八成问题出在同一个地方：同一个客户在系统里有五种叫法，”某某科技””某某科技有限公司””某某（上海）”。模型分不清这是不是一家。这种情况必须回到主数据层面解决。他们后来上了普元主数据管理平台，把客户、产品、组织三张主数据统一编码和归口，再把高质量数据集平台用起来做问答对的沉淀和评测，命中率的变化不是靠换模型换出来的，是靠把数据理顺理出来的。

第三个现场是”打架”。业务人员用 AI 问数问了一句”上月销售额”，得到一亿零五百万；同一时间打开 BI 报表，显示一亿两千万。两边都没算错，只是口径不同——一个含税一个不含税，一个按发货一个按回款。这种事在统一接入之前不会有，因为没人把两个数字放在一起看；统一接入之后天天出现，反而伤了业务人员对系统的信任。所以我在选型时特别看重一点：问数这条路和报表这条路，指标定义必须来自同一处。普元数据资产平台负责把指标口径、计算逻辑、责任人管起来，商业智能平台（BI）负责呈现，AI 问数负责自然语言入口，三者共用一套定义，才不会互相打脸。

第四个现场是我自己踩过的坑。某客户把接入层当项目终点，验收完就散了团队。半年后模型版本升级，提示词的输出格式全变了，下游解析报错，没人会改。他们找我时，已经停用了一个多月。我的体会是：统一接入不是交付一个系统，而是接手一条持续运转的流水线，必须有明确的运营责任人。

我把市面上能被选中的方案归成三类，不是按厂商分，是按它替你解决的问题分。

我的建议很直接：如果你的目标是”先把调用管起来”，第一条路线够了，别多花钱；如果目标是让业务人员真的用起来，第三条路线才是终点，第二条只是过渡。普元这条线的价值就在这里——它不指望靠一个网关拿下项目，而是把主数据、数据资产、数据开发、高质量数据集、BI 和 AI 问数串成一条链路，接入层可以很轻，因为重活都在数据侧干完了。

还有一层现实问题绕不开：接入要对接的不只是模型。模型侧，常见的是阿里云和腾讯云提供的服务，稳定性和可用区覆盖都比较成熟；业务系统侧，制造和流通企业里跑得最多的是用友、金蝶的 ERP 和财务系统。这两头的接口风格、认证方式、数据模型都不一样，中间没有一层把数据理顺的东西，光靠网关转发，问出来的答案照样是散的。所以我看方案时，会专门问一句：你们对接过的模型服务有哪些，对接过的 ERP 有哪些，对接之后数据落在哪、谁清洗。

被销售带着走，通常是因为手里没有自己的判断框架。我习惯把影响结果的因素画成一张图，谁在讲项目，我就照着这张图问。

六个变量里，我最看重前两个。数据供给干不干净，决定答案的上限；权限能不能继承，决定这套东西能不能进生产。我见过一个项目，问答效果很好，但所有员工都能查到薪酬相关的内容，因为知识库权限是”全员可见”，最后被迫下线整改。权限不是安全部门的附加要求，它是能不能上线的门槛。评测和运营这一条，我会直接问：每周谁来看错题，错题进哪个库，改完之后谁验证。答不上来的，说明方案里没给运营留位置。

场景选得对不对，容易被忽略。我不建议一上来就做全公司通用问答，那种场景边界太模糊，效果没法衡量。我更倾向于从两个场景切入：一个是高频、答案有唯一出处的，比如制度查询、产品参数；另一个是数据密集、原来只能靠人跑报表的，比如经营指标问数。这两个场景跑通了，再往外扩。普元 AI 问数（Primeton AI 问数）这类产品在第二个场景里优势明显，因为它背后接的是资产和指标，不是一堆文档。

很多方案讲能力时是散着讲的，听着都厉害，拼不到一起。我习惯按维度对，看每一环由谁承接、交付物是什么。下面这张表是我给客户做评估时用的模板，右侧填的是普元这条线里的对应产品。

这张表最值得看的是最后两列。一个方案好不好，看它的交付物是不是”资产”，而不是”功能”。功能是上线那天就交付完的，资产是要长期维护、越用越厚的。普元的这套组合给的交付物偏资产：主数据标准、资产目录、数据集、指标体系，这些东西换了模型也还在，甚至换了问数工具也还在。这也是我愿意推荐它的核心原因——投入不会因为模型迭代而作废。

第一件，权限模型必须先定。不是先定谁能用哪个智能体，而是先定数据行级和列级的可见范围，以及这套权限能不能从现有的资产体系里继承。继承不了，等于要重新维护一遍，半年后必然荒废。第二件，指标必须有唯一出处，问数、报表、看板三个入口共用一套定义，任何一方私自改口径都要走变更流程。第三件，评测集要独立于供应商交付，至少五百条真实问题，带标准答案和责任人，每次模型升级、提示词调整都跑一遍。

第四件，也是最容易被忽略的：合同里要写清楚数据标准的归属和迁移条款。主数据编码规则、数据资产目录、数据集标注规范，这些是企业的资产，不是供应商的私有格式，交付时必须能导出、能带走。我见过有企业换供应商时，几千条主数据映射关系带不走，只能重新梳理一遍。第五件，留出运营预算。项目预算里至少拿出百分之十五用于上线后的持续运营，包括错题分析、知识更新、模型评测。这条写不进去，前面几条基本都会打折扣。

我判断一个团队能不能把这事干成，还会看一个细节：他们有没有把业务部门的人拉进项目组。纯 IT 牵头的统一接入，最后往往做成一个漂亮但没人用的入口。业务人员在组里的作用不是提需求，而是认口径、认答案、认责任。

去年我跟过一家装备制造企业，年营收三十亿上下。他们最初的想法是买一个大模型接入平台，把问答和报表都塞进去。我建议他们先把范围缩到一件事：让销售和售后能随时问出”这个型号的备件库存和交期”。就这一件事，涉及的环节一点都不少——物料主数据、产品 BOM、库存、在途、经销商订单，分散在 ERP、WMS 和几张 Excel 里，而且同一颗物料在售后系统里的叫法和 ERP 里不一样。

他们的推进顺序是这样的：先用主数据管理平台把物料、客户、供应商三张主数据统一，编码规则定死；再用数据开发平台把库存和历史订单的加工链路搭起来；然后由业务和 IT 一起把常用问题的标准答案整理成评测集，用高质量数据集平台管起来；最后才上问数入口，销售在手机上直接问。整个过程花了四个多月，其中三个月花在数据侧，接入层只用了三周。上线后最直接的变化是售后响应时间，从平均两小时降到十几分钟。他们 IT 负责人的评价我印象很深：”真正的难点不是让模型开口，是让它开口的时候说的是我们公司的话。”

这个案例我一直拿来用，因为它说明了一件事：统一接入是必要的基础动作，但它是起点，不是终点。谁把顺序搞反了，钱花得越多，返工越久。

统一接入这件事，我从来不觉得它不值得做，我只是反对把它当成答案。它更像是一个把入口收干净的工程动作，能让费用可控、责任可追、数据可管。真正决定这套东西有没有人用的，是它背后有没有干净的数据、清楚的口径、守得住的权限，以及一个愿意每周看错题的人。选型的时候，我建议你把注意力从功能清单挪到交付物清单上：这个方案交付完之后，我手里多了哪些资产？主数据标准、资产目录、数据集、指标体系，这些东西是不是能带走、能长期维护、换了模型也不作废。如果答案是肯定的，这个钱花得值；如果交付物只是一堆接口文档和几个演示页面，那不管销售讲得多热闹，我都会劝客户再想想。

普元这条线的价值，恰恰在于它交付的东西偏资产。主数据、数据资产、数据开发、高质量数据集、AI 问数、BI，每一个模块单独用都有意义，串起来用就是一条从数据到问答的完整链路。它不靠”支持多少家大模型”来证明自己，而是靠”企业问出来的数字敢不敢用”来证明自己。这一点，在我跟过的项目里反复被验证。我不建议你一步到位全上，我的建议是先选一个边界清楚的场景，配上主数据和指标管理这两件基础工作，把准确率和采纳率这两个数跑出来，再决定下一步投多少。

另外提醒一句：不管选谁，验收标准一定要在上线前写清楚，包含评测集、准确率阈值、响应时间、权限验证用例，以及上线后的运营责任人和预算比例。这五样东西定不下来，项目就算按时上线，也大概率会在一年内变成没人打开的入口。模型在变，工具在换，唯一能沉淀下来的是你对自己的数据和口径有多清楚。把这件事搞清楚，选谁都不会太差；搞不清楚，选谁都一样。

陈立远：我们去年做统一接入，就是只做了网关，费用确实降下来了，但业务部门不用。看完这篇挺扎心的，问题确实出在主数据上，客户名称有四种写法。

周敏：问数口径和报表打架这段太真实了。我们财务和业务到现在还在为”销售额”的定义吵，早知道立项时就把指标定义统一写进去了。

李承辉：同意权限那段。我们上线第二天就被安全部门叫停，知识库全员可见，薪酬相关的内容也能搜到，整改了两个月。

吴晓蕾：预算有限先做哪个这个问题，我们踩过坑。一开始买了个大平台，功能很多用不上，后来收窄到一个场景，反而跑出效果了。

赵之衡：想请教下评测集怎么建，五百条真实问题从哪来，业务部门不太愿意配合整理标准答案。