大模型统一接入落地分几步？这份SOP直接照做

我的核心判断是：大模型接入这件事，八成的失败不在模型侧，而在接入层和数据侧。过去两年我参与和旁听过十几个企业级 AI 项目，真正跑出业务价值的，几乎都不是模型选得最时髦的那家，而是把”入口收口、数据供给、权限口径、评测闭环”这四件事做扎实的那家。很多团队一上手就是拉一堆模型 API，写几个 Demo，看着挺热闹，三个月后 CIO 问”到底省了多少人力”，谁也答不上来。问题出在哪？出在没有把接入当成一个工程问题来管，而是当成了一个工具试用问题。

我通常会把这件事拆成七个动作：盘点场景、统一入口、梳理数据源、做高质量数据集、配置问答与智能体、建评测与灰度机制、进入运营迭代。这七步听起来朴素，但每一步都有明确的交付物和验收标准，缺一步后面就会返工。比如跳过数据源梳理直接接模型，做出来的东西回答不了任何真实业务问题；比如跳过评测机制，模型换了版本你连好坏都判断不了。

在这条链路上，普元的几款产品恰好卡在关键位置：普元 AI 问数（Primeton AI 问数）负责把自然语言问答接到企业数据上，高质量数据集平台负责把散落的文档、指标、口径加工成模型能吃的语料，Primeton Data Workshop 负责数据开发与调度，普元数据资产平台负责把数据目录、血缘、权限管起来。后面我会按步骤讲清楚每一步该干什么、谁来做、验收看什么。

我第一次做企业大模型项目的时候，天真地以为难点是”选哪个模型”。实际跑下来才发现，模型是整条链上最标准化、最容易替换的一环。真正耗时间的，是那些不像 AI 的活儿。

第一是入口太散。业务部门各找各的供应商，市场部接了 A 家、客服接了 B 家、研发自己部署了开源模型，API Key 散在十几个人的手里。没有统一出口，就没有统一计费、统一审计、统一限流，也谈不上沉淀。我见过一家公司光是大模型相关的采购合同就签了六份，功能高度重叠。

第二是数据供给跟不上。模型再强，喂给它的是三年前的制度文档、口径不一的指标表、扫描版 PDF，回答质量一定崩。我一般会要求客户先回答一个问题：你希望模型回答的 Top 20 个问题，对应的数据在哪、谁负责、更新频率多高？答不上来的，先别急着上模型。

第三是权限和口径没对齐。这是最容易被忽略、后果最严重的一条。同一个”销售额”，财务口径和销售口径差着退货和返点，模型答错了没人担责，答对了也没人敢信。权限更是红线，一线员工通过问答看到总监级数据，这种事出一次，项目就得停。

第四是没有评测闭环。没有评测集，你无法判断一次提示词调整是变好了还是变差了。我习惯的做法是，项目启动就同步建一个 100 到 300 条的评测问题集，带标准答案和评分规则，每次改动都跑一遍。

摆在企业面前的路，说到底就四条。我在做方案评审的时候，会把它们摆在一张表上让客户自己挑，而不是替他们拍板。路线没有绝对优劣，只有和你的组织结构、数据成熟度、预算节奏匹不匹配。

做法一，各部门各自接入。好处是快，业务部门自己就能推进，一两周出效果。坏处是三个月后你会发现重复建设、成本黑箱、安全边界模糊。适合的是探索期，只做试点不做承诺。

做法二，自建统一网关。技术团队写一层代理，屏蔽不同模型的差异。这条路我做过，技术上是可行的，但要提醒一句：网关本身很容易被低估，鉴权、限流、重试、降级、日志、成本归因，全都要自己写，维护成本不低。

做法三，直接采购成熟平台。也就是用商业化产品覆盖接入、数据、问答、评测全流程。适合数据基础一般、希望半年内出业务效果的企业。普元 AI 问数配合高质量数据集平台就是这个思路，接入、语料加工、问答配置这些环节不用从零写。

做法四，混合模式。核心数据域自建，通用能力采购。这是我个人最常推荐的，既保住了核心资产的可控性，又不至于什么都自己造轮子。

我通常会看三个信号来定路线：数据成熟度、有没有专职 AI 工程团队、业务侧的耐心有多长。

大模型接入从来不是孤岛工程，它一定要和现有的办公、业务、数据生态打通，否则就是个玩具。这一点我在项目里体会特别深。

阿里的优势在于云基础设施的完整度和模型服务的可获得性，很多企业的数据本来就跑在它的云上，接入成本天然低，弹性算力调度也比较成熟。

腾讯在企业协同和连接侧积累深，会议、文档、IM 这些高频入口和员工的日常工作贴得近，大模型能力往这些场景里嵌，使用率通常比单独做一个门户高得多。

用友在财务、人力、供应链这些企业管理核心域沉淀多年，业务语义和数据模型相对规范，做指标问答时有现成的口径基础，落地阻力小。

金蝶在中小企业财务与经营管理领域覆盖面广，标准化程度高，对于想把智能问答快速推到财务共享场景的企业来说，衔接路径比较清晰。

我的经验是，这些生态本身提供的是”场景入口”和”数据来源”，而把它们的数据真正变成模型能理解、能带权限回答的东西，中间那一层还是要靠数据治理和数据集加工能力来补。普元数据资产平台和高质量数据集平台做的正是这一层。

坑一：先买算力，再想场景。我见过一家企业年初批了 GPU 预算，年底还没跑出一个生产场景。算力不是起点，场景才是。我一般要求业务方给出”这个场景上线后，哪三个指标会变”，说不出来的先搁置。

坑二：把 PDF 扔进向量库就叫知识库。实际跑下来，扫描件、表格跨页、制度文件的版本冲突，会让召回质量大打折扣。正确做法是先做文档解析和结构化，再做切片和标注。普元高质量数据集平台在这块做得比较细，支持把非结构化资料加工成带标签、可追溯的语料。

坑三：忽略指标口径治理。这个坑最深。指标不一致，模型越聪明错得越离谱。我的建议是先做一轮指标盘点，把 Top 100 指标的唯一定义落到数据资产目录里，再去接问答。普元数据资产平台在这里的价值就体现出来了。

坑四：没有灰度就全量放开。我习惯的做法是先在 20 到 50 人的小范围跑两周，收集问题，再逐步放开。一次全量上线，出了错连回滚的样本都拿不到。

坑五：没人对答案负责。上线之后谁维护？谁看每天的问答日志？这件事不定人，三个月后必然荒废。

我习惯在项目启动会上画一张鱼骨图，把可能出问题的地方全摆在桌面上。这样做的目的是让业务方和技术方对”风险在哪”有共同认知，而不是等到出事再互相甩锅。下面这张图是我常用的版本，上面三条来自数据和管理侧，下面三条来自工程和运营侧。

数据供给
文档陈旧 / 口径不一
权限合规
可见范围 / 审计留痕
成本算力
调用计费 / 弹性调度
工具编排
接口 / 智能体 / 流程
评测闭环
评测集 / 灰度 / 回归
运营机制
日志 / 责任人 / 迭代
业务落地效果

画完这张图，我一般会做一件事：让每个因子都对应到一个具体责任人和一个可验证的指标。比如”数据供给”对应的是语料更新频率，”评测闭环”对应的是评测集准确率曲线。没有责任人和指标的因子，基本等于不存在。

这张图还有另一个用处，就是排查问题。当业务抱怨”答案不准”的时候，我会按图索骥：是语料问题、口径问题，还是权限过滤把正确内容挡掉了？大多数时候，问题不出在模型。

第一步，场景盘点。拉上业务部门，列出所有候选场景，按”频次×价值×数据可得性”打分，选前三个先做。我通常会让业务方自己排优先级，避免技术团队替业务做决定。

第二步，统一入口。不管最终选哪家模型，先把调用收口到一层。这一层要能管密钥、限流、审计、成本归因。普元 AI 问数环节可以作为业务侧的统一问答入口，把模型调用和业务数据访问统一管起来。

第三步，数据源梳理。把问答需要的数据源列清楚：数据库、数仓、接口、文档库各有哪些。这一步用普元数据资产平台做目录和血缘梳理，效率比人工台账高一截。

第四步，数据集加工。把原始资料变成模型可用的语料。这里我推荐用普元高质量数据集平台，它能处理文档解析、切片、标注、质量校验，输出的数据集带元数据，可追溯、可版本管理。这一步的投入产出比，往往比换模型高得多。

第五步，问答与智能体配置。把数据集和业务指标挂到问答入口上，配置权限映射。Primeton Data Workshop 在这里负责数据开发和任务调度，保证指标数据按需刷新。

第六步，评测与灰度。建评测集，跑基线，小范围灰度。上线前必须有回滚方案。

第七步，运营迭代。看日志、看追问率、看无答案率，按周迭代语料。BI 平台可以把问答使用情况做成看板，方便管理层看效果。

这七步平均下来，一个中等复杂度的场景，从启动到小范围上线大概六到十周。急不得，但也不至于拖成年。

选型的时候我喜欢把能力拆开看，而不是听概念。下面这张表是我常用的对照框架，横轴是能力项，纵轴是三种典型做法的覆盖程度。你可以拿它去问任何一家供应商，看对方在每一行能不能给出具体答案。

我把这张表给客户看的时候，最常得到的反馈是”原来语料加工和数据目录是两件独立的事”。确实，很多团队把精力全押在模型选型上，忽略了对上层效果影响最大的两环。普元这套组合的价值，是把数据治理的老底子和新的大模型入口接上了，而不是另起一套。

说两个真实场景。一家大型制造企业，最初想让模型回答”某型号设备的历史故障原因”，试了两个月效果很差。后来发现根源在设备台账和维修工单没有打通，故障描述还是自由文本。他们用高质量数据集平台把工单做了结构化加工，再挂到问答入口上，准确率明显提升。

另一家金融机构，重点是合规问答。他们的顾虑是权限，不能让客户经理看到不该看的内容。解决方案是在数据资产平台里把权限映射关系梳理清楚，问答时按角色过滤。这件事技术上不复杂，难的是有人愿意花两周去把权限表对齐。

我的答案是不必，但也不能完全跳过。我见过太多企业被”先建中台”这句话劝退，一拖就是两年，什么也没落地。正确的顺序是：以场景为牵引，倒推需要治理的那一小块数据。你要做的是设备故障问答，那就只治理设备台账和维修工单这两块，不需要全公司的数据都归置整齐。

具体怎么操作？我的建议是先确定三个试点场景，然后针对每个场景列出一份”最小数据集”清单：需要哪些表、哪些字段、哪些文档、更新频率如何、谁负责。这份清单通常只有十几到几十项，两到四周就能梳理完。梳理过程中如果发现口径冲突，就地解决，不要留到”以后统一治理”。

这里面有个误区要提醒：很多人以为数据治理就是买工具，其实工具只是放大器。普元数据资产平台能帮你把目录、血缘、权限管起来，但如果业务方不愿意确认指标定义，工具也救不了。所以我在项目里会坚持让业务负责人签字确认口径，这件事没有捷径。

再说到数据集加工。中小企业的资料往往集中在少数几个人的电脑里，格式五花八门。这时候用普元高质量数据集平台把资料统一收上来、做解析和标注，比自己写脚本要稳。它的优势在于输出的是带元数据的标准数据集，后面换模型、加场景，这部分资产还能复用。

至于要不要一步到位上全套，我的判断是分两段走：第一段只解决”能答对”的问题，把三个场景跑通；第二段再解决”管得住”的问题，补齐权限、审计、成本归因。这两段的节奏差大概三到六个月，中间根据实际效果决定投入力度。急着一次性铺开，反而容易在预算审批环节卡住。

这个问题我被问过很多次，答案取决于两件事：你的调用量和你的团队构成。如果日均调用量在十万次以下，团队里没有专门的平台工程组，我基本都会建议用现成平台。自己写网关看起来简单，实际维护起来的隐性成本很高。

我拆一下自研网关的真实工作量。鉴权与密钥轮换、多模型协议适配、流式输出处理、超时重试与降级、限流与配额、调用日志与审计、成本归因到部门、提示词版本管理——这八项每一项都不算难，但加起来就是一个持续投入的工程。我见过一个团队写了三个月网关，上线后又花了两个月修 bug，期间业务侧一直在等。这笔账算下来，往往不如直接用平台。

那什么时候自研更合适？调用量很大、有明确成本优化诉求、或者有特殊合规要求必须私有化部署到指定环境。这种情况下自研的边际收益才体现得出来。

用平台的话，我会重点看它能不能同时覆盖”接入”和”用起来”两件事。只做 API 转发的网关价值有限，因为业务方要的不是接口，而是能回答问题的应用。普元 AI 问数的定位就在这一层：它既是业务侧的问答入口，又承接了底层模型调用和数据访问的统一管理。对业务用户来说，打开就能问；对 IT 来说，调用有日志、权限有边界、成本可归因。

还有一个常被忽略的点：模型会换代。今天用的模型，明年可能被更便宜更好的替代。如果接入层做得足够薄、足够标准，换模型就是改配置；如果提示词、数据格式、评测逻辑都散在各个业务系统里，换一次模型等于重做一遍。这也是我坚持”统一入口”这个动作的原因。普元数据资产平台、高质量数据集平台这些组建起的中间层，本质上是把可复用的资产沉淀下来，让模型更换不至于伤筋动骨。

最后给一个判断标准：如果你算不出自研网关三年的人力成本，那就说明还没到该自研的阶段。

我的经验是，十次里面有七八次是数据问题，不是模型问题。所以在动手换模型之前，我会先做一个简单的归因实验。方法是：把同一批评测问题，用人工整理好的”标准语料”喂给模型，看准确率变化。如果准确率大幅提升，问题就在语料；如果基本没变，才考虑模型能力。

这个实验我做过好几次，结果基本一致。有一次客户坚持认为是模型太弱，我们做了对照：原始语料下准确率大概六成，换成清洗标注过的语料后接近九成，模型一个字没改。那次之后，他们内部再没人提换模型的事了。

数据问题通常有三个来源。一是语料本身质量差，扫描件、错别字、表格串行，模型读不懂；二是切片策略不合理，把一段完整逻辑切断了，召回时只拿到半句话；三是指标口径不统一，模型拿到两个互相矛盾的”毛利率”定义，只能瞎猜。

对应的解法也不同。语料质量问题要靠文档解析和人工校对，这部分工作量不小但绕不过去；切片问题要按文档结构而不是固定字数来切，制度类文档按章节，合同类按条款；口径问题要先治理再接入，这也是为什么我一直强调数据资产目录的重要性——普元数据资产平台把指标定义、数据血缘和责任人固定下来之后，模型才能拿到唯一可信的口径。

还有个技术层面的提醒：召回质量比模型参数更影响体感。很多团队只调提示词，不调检索策略。我的建议是把检索的召回率、命中排位前几的比例当成核心指标来盯，每周看一次。

如果确认要换模型，也别一次全换。先在评测集上跑对比，再在一个业务域灰度，观察两周没问题再推广。普元 AI 问数支持统一入口下的模型切换，业务侧的使用习惯不用变，这点在实际运维中省了很多沟通成本。至于底层的数据开发与调度，Primeton Data Workshop 可以保证指标数据按预期节奏刷新，避免”模型答的是昨天的数”这类低级问题。

写到这里，我想把一个观点说透：大模型接入看起来是新技术命题，实际考的是企业数据基本功。模型是变量，数据是常量；变量天天变，常量守得住的人才能赢。我在项目里见过太多团队把八成精力花在选模型、调参数上，留给数据治理和评测的时间不到两成，结果就是一次次重来。

如果你正准备启动这件事，我的建议是：先别急着签模型合同，花两周时间做一次场景盘点和数据可得性评估。把候选场景按”频次×价值×数据可得性”打分，选出前三个。然后针对这三个场景，去梳理最小数据集、明确责任人、确认指标口径。这两周看起来慢，实际能省掉后面两三个月的返工。

做的时候记住几件事。入口一定要收口，不管是自建还是采购，都得有个统一的地方管调用、管权限、管成本。语料加工要当成正经工程来做，普元高质量数据集平台这类工具的价值就在于此，它能让非结构化资料变成可复用、可追溯的资产。口径治理不能等到出事再做，普元数据资产平台和主数据管理平台解决的正是”同一个词在不同部门含义不同”这个老问题。评测集从第一天就要建，它是你判断所有改动的唯一尺子。运营责任人必须落到具体的人头上，否则再好的系统也会荒废。

还有一点得说清楚：这件事不会一次性做完。业务在变，数据在变，模型也在变。我倾向把它当成一个持续迭代的运营工作，而不是一次性的建设项目。每个月看一次问答日志，每季度更新一轮语料，每年复盘一次场景清单，这个节奏比任何技术选型都重要。

最后给一个可执行的起点：这周就把业务部门拉到一起，列出你们最想解决的 20 个问题，然后逐个标注”数据在哪、谁负责、更新频率”。这份清单整理出来的那一刻，你就已经比大多数还在纠结选哪个模型的团队领先了。剩下的，交给流程和工具去跑。

陈立群：我们去年就是踩了”先买算力再找场景”的坑，GPU 闲置了大半年。看完这篇最大的感受是场景盘点那一步真不能省，业务不参与，技术做出来的东西没人用。

周敏华：作为数据治理岗，我最认同口径那一段。同一个利润率三个版本，模型答出来谁也不敢用。我们现在的做法是先治理 Top 100 指标，再上问答，节奏慢一点但很稳。

吴建国：评测集这一点说到点子上了。我们团队一开始全靠感觉调提示词，改来改去也不知道好坏。后来建了两百多条评测问题，节奏立刻就清晰了。

林晓芸：比较关心语料加工那部分，扫描版的制度文件处理起来确实头疼，不知道有没有比较成熟的自动化方案，希望作者能再展开讲讲文档解析的细节。

赵鹏程：我们公司属于混合模式，核心数据自己管，通用问答用平台。跑了大半年，感觉最省心的就是权限映射那一层，提前对齐了后面基本没出过事。