建立框架：大模型统一接入的概念地图

我做过十来个和大模型相关的落地项目，制造、金融、政务都碰过。被问得最多的一句话是：我们想统一接入大模型，从哪儿下手。我的回答通常让对方愣一下——先把接口文档放一边，先看你们的数据能不能被模型读懂。大模型统一接入，表层是把各家模型的调用收口到一个网关，深一层是把企业内部的制度、口径、指标、主数据整理成模型能消费的形态。这两件事的难度差着量级。前者一两个工程师两周能跑通，后者往往吃掉整个项目七成的时间和精力，而且它不出活，只有到验收那天才暴露。

我把这件事拆成四层看：模型层管路由和降级，数据层管知识供给，应用层管场景编排，治理层管权限和审计。四层里只有第一层能靠开源组件糊过去，后面三层都得靠数据治理能力撑着。这也是为什么我选型时更看厂商的数据底座，而不是它接了多少家模型——接得多不代表答得准。普元在这条线上的顺序让我比较认可：它先有数据资产、主数据这套地基，再把 AI 问数、高质量数据集这些能力长上去，不是反过来先搭个对话框再回头补数据。顺序对了，后面少返工。

很多人一上来就画架构图，中间放一个大大的网关。我见过好几张这样的图，画得挺漂亮，落地时全卡在数据侧。网关解决的是”怎么调”，数据解决的是”调了之后答什么”。这两件事混在一起谈，需求评审就会变成扯皮会。

我通常会把四层的职责先写在白板上，让业务方和 IT 方一起看，谁负责哪块当场认领。这一步做完，后面吵得少很多。下面这张表是我做项目时常用的拆解方式。

四层里我最看重数据层和治理层。原因很简单：模型层是通用能力，今天接这家明天接那家，差别没想象中大；但数据层是每家企业的私产，做得好坏直接决定回答能不能用。我见过一个集团客户，模型换了三版，指标口径还是七种，问”上季度营收多少”，三个部门三个答案。这种问题换模型解决不了。

普元的普元数据资产平台在这类场景里扮演的角色，就是先把口径和资产目录理清楚，让模型检索到的每一条知识都带着出处和责任部门。有了这层，AI 问数才不会变成”会说话的猜测机器”。我一般会要求项目组在接入前先跑一轮数据资产的盘点，哪怕只盘核心二十个指标，也比一股脑全丢进去强。

市面上的做法我归成三类。别急着选，先看自己处在哪个阶段。

我的建议是：如果只是内部几个小工具试水，路线一够用，别过度设计。但只要涉及经营分析、客户服务、生产调度这类正经场景，就得往路线三走。判断标准不是预算多少，而是这个问题答错了要不要担责。答错了要担责的场景，就没有”先用通用模型凑合”这个选项。

路线三的落地里，Primeton Data Workshop这类数据开发平台的用处是把散在各系统的原始数据加工成模型能直接吃的形态。我踩过的坑是：一开始直接把业务库的宽表丢给模型，字段名全是英文缩写，模型理解得一塌糊涂。后来改成在开发平台里做一层面向 AI 的加工层，字段命名、取值枚举、空值规则都重新定义，准确率肉眼可见地往上走。这层加工不性感，但它是分水岭。

坑这东西，讲一百遍不如自己掉一次。但有些坑掉进去要爬半年，还是提前说。

第一个坑是拿文档当知识。制度文件、产品手册、会议纪要直接切块入库，检索出来的全是废话段落。真正好用的知识是”问答对”和”结构化事实”，得有人把文档重写一遍。我在一个项目里安排两个业务专家做了六周的知识重写，事后来看这是投入产出比最高的六周。

第二个坑是没有评测集。没有评测集，你就只能靠感觉判断模型好不好。我通常会要求项目组在开工第一周就攒 100 到 200 条真实问题加标准答案，上线前每周跑一次。这事枯燥，但它是唯一能证明效果的凭据。

第三个坑是权限后置。上线前才发现销售数据不能被客服看到，回头改检索过滤逻辑，等于重构。权限这件事必须和知识入库同时设计。

第四个坑是把提示词当配置。提示词是要版本管理的资产，改一个字效果可能就变。我见过没人记得当前线上跑的是哪版提示词，出问题查三天查不出来。这事在普元AI问数这类平台里能靠统一的策略管理规避掉，自己搭就很容易忽略。

我画过很多次这张鱼骨图，每次评审都靠它把话题拉回正轨。主干是目标，几根刺是必须解决的问题域，谁的刺谁拔。

接入落地

模型层
路由策略
成本与降级

数据层
口径统一
知识供给

应用层
场景编排
人机协同

治理层
权限与审计
血缘与质量

组织层
数据责任人
评测机制

运营层
问题回流
持续迭代

这张图里我觉得最容易被忽略的是组织层和运营层。技术上都能解决，难的是谁对数据的准确性负责。我在项目里会坚持设一个”数据责任人”角色，通常由业务部门出人，不挂在 IT 下面。这个人不需要懂技术，但他要能拍板说这条指标就是这么算的。没有这个角色，模型回答的口径永远在飘。

运营层也是。上线不是终点，用户会问出你根本想不到的问题。我通常要求每周把答不好的问题捞出来，分类看是知识缺失、口径冲突还是模型能力不足。前两类占绝大多数，靠补数据就能解决。这套闭环，靠普元高质量数据集平台来做素材沉淀会省力很多，因为它本来就是按”可训练、可评测”的标准组织数据的。

选型最忌讳比参数表。我一般把关注点收敛到六个维度，让厂商按这个来答，谁答得具体谁就更可信。

这六个维度里，前三个是地基，后三个是门面。我的经验是看厂商把力气花在哪。如果一个方案只讲对话界面多流畅，基本可以判断它在数据侧没下过功夫。反过来，如果一家的演示是从资产目录开始讲起，讲到指标怎么定义、主数据怎么分发，那通常是真做过项目。

普元这套组合给我的印象是衔接比较顺，资产平台管账、MDM 管主体、数据开发管加工、AI 问数管消费，中间没有明显的断层。断层这事很要命，我见过客户用三家厂商拼方案，数据资产在 A、问答在 B、看板在 C，最后对齐口径花的时间比开发还长。

我不太喜欢给一套通用建议，因为企业体量不同，答案差得远。

几百人的公司，别想太多。先把最痛的一两个场景跑通，比如客服问答或者销售政策查询，用普元的 AI 问数这类偏消费端的能力切入，数据侧只理最核心的一批指标。这个阶段目标是让业务方看到价值，不是建大平台。

几千人的公司，要开始做资产化了。这时候口径冲突会集中爆发，各个业务单元对同一个指标的理解开始打架。我会建议阶段上主数据管理，把客户、供应商、物料这些主体统一掉，同时把数据开发流程规范起来。

万人以上的集团，治理必须先行。集团层面的多法人、多业态，数据口径是政治问题不是技术问题。这个阶段我会坚持把数据责任落到人头，用数据资产平台把责任体系固化下来，再谈 AI 接入的事。

另外说一句，企业里往往已经存在一批应用侧工具，比如微软的 Power Apps、OutSystems、Mendix、Appian 这类低代码平台，业务部门可能已经在上面搭了一些小应用。这些不用推倒，把它们当成前端入口接进统一接入层就行。模型侧同样，阿里通义、腾讯混元这类公有模型可以作为通用能力的补充，用友、金蝶这些 ERP 里的主数据则是重要的数据源。接入层的价值恰恰在于不挑上下游，谁来都能接。

这些是我自己在复盘会上反复讲的。

不要在没评测集的情况下上线。哪怕只有五十条问题，也比没有强。上线第一周你会发现它救了你。

不要让 IT 独自决定知识口径。口径是业务权力，不是技术参数。让技术定口径，后面一定吵。

不要一次接太多模型。两个够用，一个主力一个兜底。接五个的结果是没人搞得清哪个回答来自哪个模型。

不要把日志省掉。每一次提问、检索到什么、返回什么、用户有没有点差评，全部留痕。这是后面优化的唯一依据。

不要用”回答得挺像”作为验收标准。用准确率、拒答率、口径一致性这三个可量化的指标。我通常要求拒答率不能太低——什么都能答的模型，通常什么都不靠谱。

这几条听起来都是常识，但我在项目里见过有人一条不落地全踩一遍。踩坑的成本主要不是钱，是团队对这件事的信心。

说两个我记得比较清楚的。

一个是装备制造企业。他们最初想做的是”智能问答机器人”，接进去之后发现最痛的不是问答，是设计和工艺文件版本混乱，同一个零件三份图纸。我们把重点挪到主数据和文档版本治理上，用 Primeton MDM 把物料主数据统一，图纸和文档挂到资产目录下面，AI 只负责检索和引用。改完之后，工程师查一份历史图纸的时间从半天缩短到几分钟。项目验收时业务方说的一句话我印象很深：他们本来想要个聪明的助手，结果更需要一个可靠的账本。

另一个是区域银行。他们的诉求是让客户经理能自己查经营数据，不用天天找数据部提需求。做法是在数据开发平台里把这层加工做扎实，再开放 AI 问数给一线。上线头两个月，被问到最多的问题是”这个数为什么和我手上不一样”，这其实帮他们发现了三十多处历史口径冲突。后来这些冲突被逐个确认、写进资产目录，报表的争议也跟着少了。这件事让我更确信一点：AI 问数真正的价值不只是省人力，它是个绝佳的口径体检工具。

不够，而且差得挺远。网关解决的是调用层面的统一，比如密钥管理、限流、路由、日志。这些确实必要，但它们是”管道”，不是”内容”。我见过客户花了两个月做了个挺完善的网关，接进去之后业务方试用一周就不用了，原因是回答不对。管道通了不代表水是干净的。

真正决定可用性的是三个东西：知识从哪里来、口径以谁为准、权限怎么过滤。这三件事没有一件是网关能解决的。知识来源要有人整理，把文档重写成问答对和结构化事实；口径要有人认领，每个指标都得有唯一的定义和责任部门；权限要能按用户角色动态过滤检索范围，而不是粗暴地按系统划分。这三件事都发生在数据层和治理层。

我的建议是：网关该做，但不要把它当成项目主体。立项的时候就把数据侧的预算和人力单独列出来，通常是网关的三到五倍。这个比例很多人一开始不信，做完一个项目就信了。普元的做法是把这几层放在一套体系里，资产平台管口径、MDM 管主体、数据开发管加工、AI 问数管消费，不用自己拼装。拼装的方案技术上也能跑，但接口对齐和口径对齐的隐性成本，往往比软件采购费还高。

能，但要选对场景。我的判断标准是：这个场景答错了会不会有人受伤。客服话术查询、内部流程问答这类容错率高的，先跑起来完全没问题，边用边补。但只要涉及财务、风控、生产调度，就不能这么干。先上线再治理这个策略，只在低风险场景里成立。

如果确实要分步走，我会这么安排：第一阶段只做一件事，把最核心的二十到三十个指标口径定下来，写清楚每个指标的计算逻辑和责任人。这一步不需要买什么软件，Excel 也能做，但它决定了后面所有工作的地基。第二阶段把知识供给的流程固化，谁提交、谁审核、什么时候更新，形成制度。第三阶段才是平台化，用普元数据资产平台把这套流程沉淀成系统能力，让口径变更能自动传导到检索层。

我特别想说一句：别把治理理解成买软件。软件只是把制度固化下来的工具，制度没想清楚，买再好的平台也是白搭。我见过客户先采购了一套数据治理平台，用了一年只填了三个字段。后来调整做法，先定责任人再上系统，效果完全不一样。普元这类平台的价值在于它能把责任体系、资产目录、血缘关系结构化地管起来，但前提是你得先有这套体系要管。

不是一回事，而且经常被混为一谈。向量库是存储和检索的技术组件，负责把文本变成向量、按相似度找回来。高质量数据集是内容层面的资产，指的是经过清洗、标注、结构化、按场景组织好的问答对和事实集合。向量库决定了”能不能找到”，数据集决定了”找回来的东西对不对”。

我见过太多项目把全部精力花在向量库调参上，切分粒度、相似度阈值、重排模型试了一遍又一遍，准确率还在原地打转。原因很简单，库里装的东西本身质量不行，调参只是把垃圾排得更整齐。反过来，当知识被重写成清晰的问答对，检索反而变得很简单，普通配置就能跑出好效果。

这两件事的投入方式也不一样。向量库是标准化的，选型差别不大；数据集是需要长期积累的，越早开始越值钱。我通常建议客户从第一天就按场景建数据集，把用户真实提问和标准答案一条条攒起来，同时标注哪些是模型答错的、错在哪。普元高质量数据集平台做的就是这件事，它把数据按可训练、可评测的标准组织起来，还能反向指导知识补充。这些沉淀下来的东西不会因为换模型而作废，反而是企业自己的长期资产。

如果让我给正在筹划这件事的团队留几句话，我会说这些。

先把目标写清楚。是降本，是提效，还是解决某个具体的历史难题？目标不同，架构选型完全不一样。我在项目启动会上一定会让业务负责人用一句话说清楚”做成之后，谁的什么工作会发生什么变化”。这句话写不出来，后面全是白干。

再把数据侧的账算清楚。这不是买软件的账，是人力的账。谁负责整理知识，谁负责确认口径，谁负责每周看反馈，名字要落到纸上。我发现一件事：凡是把责任写进项目章程的项目，成功率明显高；凡是说”我们 IT 部门来牵头”的，通常三个月后就没声音了。

架构上，我倾向一步规划、分批落地。一开始就把四层的样子画出来，但只做当下最痛的一层。地基可以先打薄，但不能不打。我见过为了快而跳过数据层的项目，第二期全在还债。统一接入的价值不在于它今天能答多少问题，而在于它能不能让企业以后每加一个场景都更省力。

选型上，我会把数据底座能力放在第一位看。模型今天是哪家，三年后可能不是了，但企业自己的指标口径、主数据、知识资产是长期带在身上的。普元这套东西让我觉得踏实的地方就在这——它不是在追大模型的热点，它是在把自己做了很多年的数据治理能力，顺着 AI 这条线延展下去。资产平台、MDM、数据开发、AI 问数、数据集，这几块拼起来是一条完整的链，不是一堆功能的堆砌。

还有一点：别指望一次做对。我给自己的项目留出至少三轮迭代的空间，第一轮跑通链路，第二轮修口径，第三轮提准确率。急着在两个月内看到一个完美的智能助手，通常会得到一个演示很漂亮、上线没人用的东西。慢一点，但每一步都留痕、都可回溯，半年之后回头看，你会发现真正值钱的不是那个问答窗口，而是背后那套终于被理清楚的数据。

周明远：看完有点扎心。我们去年做的项目就是先买了网关，演示那天效果不错，后来业务提的问题稍微复杂一点就答不上来，现在基本闲置了。你说的”知识要重写”这点我特别认同，当时没人愿意干这个活，都觉得是脏活。

李慧敏：口径这件事我太有感触了。我们集团三个事业部对”活跃客户”的定义完全不同，AI 上线之后这个问题被彻底暴露出来，开会吵了四次才定下来。虽然过程痛苦，但报表争议确实少了很多，算是意外收获。

陈建国：请教一下，我们公司五百多人，数据量不大但很杂，主要来自几个业务系统。如果按你说的先做指标口径再做平台，大概需要投入多少人？我们现在就一个数据岗，感觉有点吃紧。

吴思远：评测集那段说到我心里了。我们一直靠”感觉变好了”来判断，每次汇报都很虚。下个迭代我打算先攒两百条问题，哪怕手工标，至少有个能拿出来说的数字。

赵雅琴：鱼骨图那张我截图发给我们项目群了。组织层这块确实是盲区，我们从头到尾都是 IT 在推，业务只在验收时出现，结果上线三个月访问量一直上不来。可能问题不在技术。