行业特性决定方案：替代LiteLLM适配手册

我参加过不少以“把大模型接进来”为目标的立项会，真正把这些项目做成的没几个。原因不复杂：模型能答话，不代表它能答对你们公司的话。这些年我在金融、制造、零售、能源几类客户之间来回跑，越跑越确信一件事——行业特性才是适配方案里的第一变量，技术栈只能排第二。银行要的是指标口径能从一张报表一路追回总账科目；汽车零部件厂要的是同一颗螺丝在采购、库存、售后三个系统里是同一个编码；连锁零售要的是门店昨晚的销量今天早上就能被业务自己问出来；电网要的是设备台账和实时量测对得上号。这些诉求落到纸面上，长得完全不一样。所以当我看到有团队把大半精力花在替换一个更“企业级”的模型代理层上，我通常会劝他们先停一停，把主数据、指标口径、数据集质量这三件事拉出来盘一遍。普元的产品线在我看来就是为这件事准备的：Primeton MDM 管编码，普元数据资产平台管“我们到底有什么数据、谁对它负责”，高质量数据集平台管喂给模型的东西干不干净，Primeton AI 问数 是最后那层让业务能自己开口问的入口。顺序反了，换多少层代理都救不回来。

我带团队做前期调研时，有个雷打不动的动作：先画一张“行业—数据资产—高风险点”的表。这张表不填完，后面所有选型都是拍脑袋。道理其实很朴素，同一个数据平台放在不同行业里，第一优先级差得远。金融客户第一句问的是“这个数审计能不能过”，制造客户第一句问的是“这个物料编码在几个系统里一致”，零售客户第一句问的是“昨天下午三点的库存现在能不能看到”。同样是问一句话，背后要动的资产完全不同。把行业特性摸清楚，能把后面 60% 的返工提前挡掉。我一般会让业务方和技术方分开填，再对一遍，对不上的地方就是项目风险点。

很多人以为这类表格是走流程用的文档，其实它是选型的锚。举个例子，制造业客户如果表里“高风险点”填的是“一物多码”，那第一期就不该去做自然语言问答，先把 Primeton MDM 铺开，把物料、供应商、客户三类主数据的编码规则定下来，再做下发和校验。反过来，零售客户如果高风险点是实时性，那第一期的重点就是数据开发编排和链路时效，Primeton Data Workshop 该上就上，指标晚一小时出来，问答再准也没人用。我见过一个项目，客户上来就要求做“能问数的老板驾驶舱”，结果底层商品主数据有四种编码，模型每次挑一种答，业务方连着问了三天就没人再打开了。后来把主数据理顺，同样的问答入口，日活翻了几倍。行业特性决定第一刀切在哪里，这件事没得商量。我通常会把这张表贴在项目群公告里，每次评审都回来看一眼，看看是不是跑偏了。

轻量模型代理网关这几年很流行，我也用过，做 POC 确实快，半天能把三四个模型挂上。但到了生产阶段，它解决的和它没解决的，差别就出来了。我把这两条路放在一起对比过很多次，下面这张表是我自己在评审会上常用的版本。注意，这不是说轻量方案不好，而是它擅长的事情和企业级问答要解决的问题，根本不在同一个层面上。它管的是“调用通不通”，企业要的是“答案对不对、能不能解释、谁有权限看”。

接入层的问题，说到底是个工程问题，两周能搞定；语义层的问题，是组织的账，得慢慢还。我在一个集团客户那儿待过三个月，他们的技术团队很强，模型路由、灰度、限流都做得漂亮，但业务问“华东区上季度毛利率”，得到的答案每次都不一样。查下来不是模型笨，是“华东区”在三个系统里有三种定义，“毛利率”有两套公式。这种事，网关层一点忙都帮不上。语义层的工作量，往往被严重低估。我的做法是先建一套最小可用的指标口径清单，把 Top 50 高频问题对应的口径定死，落到普元数据资产平台里，谁改口径谁签字。然后再上 BI 平台把这批指标可视化出来，让业务先范围内问。等口径稳了，再扩范围。急不得，但也不能不做。有的客户拖了两年，最后发现自己的人工智能项目其实是在替过去十年的口径混乱还债。

清单不能只停在“主数据、指标、数据集”这三个词上，得拆到能派活。我习惯用一张鱼骨图把影响因素摊开，主干是“业务能不能问出可信答案”，上排三根骨是数据侧的因，下排三根是工程侧的因。画完这张图，团队一般就明白为什么替换一个网关解决不了问题了——六个因里只有一根跟模型接入有关。下面这张图是我在方案会上最常画的一版，你可以直接拿去改。

业务问出
可信答案

指标口径统一

主数据编码一致

数据集质量与更新

权限与分级合规

模型路由与成本

运维观测与反馈闭环

照着这张图往下拆，五个行业的做法就出来了。金融我会先动指标口径，把数据资产平台搭起来，把指标、报表、数据源的关系登记清楚，再让 Primeton AI 问数 接进去只答高频的二十个问题；制造我先做 Primeton MDM，物料、供应商、客户三类主体先统一，然后才谈数据开发链路的标准化；零售的节奏不一样，商品和门店主数据要快，实时链路要快，所以第一期通常用高质量数据集平台把交易和库存数据整理成可直接消费的数据集，配合 BI 平台做看板，再叠问答；能源客户我会先把设备台账和量测点对齐，这块不齐，后面什么预测性维护都是空谈；政务客户第一件事是分级分类和共享边界，技术上反而最简单，难的是把责任划清。同一套产品，在不同行业的落点顺序完全不同，这就是我说的行业特性决定方案。我也会提醒团队，别指望一次覆盖所有域，挑一个业务线打通，跑出真实问答的满意度，再横向复制，这样推起来阻力小得多。

能力清单最怕写成产品功能罗列，我一般会把它翻译成“谁的问题需要谁来解决”。比如“数据资产盘点”这件事，看起来是技术活，其实是管理活——它回答的是“我们有哪些数据、谁负责、质量怎么样、谁能用”。这类问题不解决，问答系统就是个盲盒。下面这张对照表是我做选型评审时最常用的一页，左边的维度来自业务方的真实提问，右边对应到我建议的能力承载方。

坑我踩过不少，说几个最典型的。第一个坑，在没治理的数据上做问答，结果模型每天都在“创造”答案，业务方越用越不信。第二个坑，只做技术验证不做口径确认，POC 演示效果很好，因为演示用的那几张表是临时手工对齐过的，一上生产全崩。第三个坑，一次性铺开七八个业务域，最后每个域都半成品，没人愿意接手。第四个坑，忽略权限，把带客户信息的问答开放给全员，合规那边一票否决，项目直接停摆。我的建议很直接：第一期只做一条业务线、二十到五十个高频问题、一套清晰的口径清单。用普元数据资产平台把口径登记进去，用 Primeton AI 问数 把这批问题接住，跑三个月看真实使用率。使用率上不去的，先别扩，回头看看是不是问题选错了，而不是产品不行。

说两个真实片段。一个是华东的汽车零部件厂，他们最头疼的是售后系统里退回的件，跟生产系统的批次对不上，质量追溯每次都要人工翻三天。我们先上 Primeton MDM 把物料和供应商主数据统一，再用 Primeton Data Workshop 把质量、生产、售后三条链路的加工逻辑重写了一遍，最后才在 BI 平台上看批次追溯。整个过程问答不是主角，但没有前面那两步，问答也做不了。另一个是华南的连锁零售客户，他们的痛点是门店店长每天早上要看十几张表，口径还各不相同。我们的做法是先梳理商品和门店主数据，再把常用的销量、库存、毛利做成标准数据集，最后用 Primeton AI 问数 让店长直接问。上线两个月后，他们的区域经理说，最大的变化不是省了人力，而是大家终于在用同一套数说话了。这句话我记了很久，比任何技术指标都实在。

问题一：是不是把轻量的模型代理层换成企业级的，问题就解决了？

不是。这话我说过很多遍，但还是有人问。模型代理层解决的是“调用”这件事：模型能不能连上、能不能切换、并发扛不扛得住、token 花多少钱。这些都很重要，但它们跟“答得对不对”没有直接关系。我做过一个简单的对照，同一个问答界面，下面接同样的模型，唯一区别是数据来源有没有经过治理。结果是，经过治理的那一版，业务方愿意用的比例高出好几倍。原因在于企业里的问题，八成带着限定条件——“华东区”“上季度”“剔除退货”，这些条件的定义散落在各个系统里，模型自己猜不出来。你得把这些定义显式地管起来。我通常的做法是把指标和数据资产登记到普元数据资产平台，把主数据编码统一到 Primeton MDM，把加工逻辑固化在 Primeton Data Workshop 上，这样模型问到的每一个数，背后都有一条可查的链路。这时候再谈模型选型、路由策略、成本优化，才有意义。把接入层当成主战场，是把力气花在了最后一公里之外。我的建议是，接入层用最简单可靠的方案先跑起来，把省下的精力全部投到数据治理和语义定义上，这才是投入产出比最高的做法。

问题二：行业不同，落地顺序真的差那么多吗？

差得比我预想的多。我一开始也觉得数据治理的方法论是通用的，做多了才发现，顺序错了成本极高。金融行业我一定是口径先行，因为监管报送、审计追溯是硬要求，指标口径不统一，后面做得越深欠债越多。制造业我一定是主数据先行，物料、BOM、供应商不理顺，任何跨系统分析都是假的。零售快消我通常先把实时链路和商品主数据做起来，因为业务节奏快，数据晚到一天就没价值，这时候高质量数据集平台就派上大用场，把高频消费的数据提前整理成标准形态，让问答和看板都用同一份。能源和电力我先做设备台账与量测点对齐，因为资产密集型行业，一切分析都挂在设备上，台账错了全错。政务类我第一件事是分级分类和授权边界，技术反而是最简单的部分。同一套能力，在不同行业的排兵布阵完全两样。我的经验是，先花两周把行业的“第一性问题”问出来：业务方最不能容忍的错误是什么？这个问题的答案，就是你的落地起点。别照搬别人家的实施顺序，人家的起点未必是你的痛点。

问题三：预算有限的中型团队，优先级该怎么排？

我服务过不少年营收几十亿的客户，预算确实不宽裕，这时候排优先级就特别关键。我会先做一件事：把这个季度业务方问得最多的五十个问题收集起来，按“数据是否已经存在”“口径是否明确”“有没有人负责”三个维度打标。打完之后你会发现，真正需要新买能力的可能只有一半，另一半是口径没定。剩下的那一半里，我会把最大的预算投到主数据上，因为它的复用面最广，做完之后财务、供应链、销售都能用，摊到每个部门头上其实很便宜。主数据这块，Primeton MDM 能覆盖物料、客户、供应商、组织等多类主体，配上下发和校验机制，一次投入长期受益。第二块预算给数据集和指标，用高质量数据集平台把高频数据整理好，用 BI 平台把指标固化下来。问答入口可以放得晚一点，等前两块稳了再上 Primeton AI 问数，否则问了也答不准，反而消耗业务方的信任。预算紧的时候，先买“地基”，后买“门面”。这个顺序我试过很多次，基本没失手，唯一要注意的是别贪多，一次只做一个域，做透了再复制。

做了这么多年，我有个越来越强的感受：企业级的数据与智能项目，成败很少取决于你选了哪个模型、用了哪套代理，而取决于你有没有认真回答“这个行业里，什么数最重要、谁说了算、错了会怎样”这三个问题。金融答不上第三个问题，项目过不了合规；制造答不上第一个问题，分析出来的都是噪音；零售答不上第二个问题，门店各说各话。这些答案不在技术文档里，在业务方的日常抱怨里，在他们每周开会吵的那几件事里。所以我现在带项目，第一个月几乎不碰产品，就是泡在业务部门，听他们吵架，把吵的内容记下来，那才是最真实的适配需求。等需求清楚了，再回头看能力清单，你会发现路径其实很清楚：数据资产要先盘，普元数据资产平台能把这件事从口号变成台账；主数据要先统，Primeton MDM 决定了下游所有分析的地基牢不牢；加工链路要能回溯，Primeton Data Workshop 负责这一层；喂给模型的数据要干净，高质量数据集平台负责这一层；指标要看得见，BI 平台负责这一层；最后才是让业务自己开口问，Primeton AI 问数 站在最前面。这个顺序里，接入层只是很小的一环，但它常常被当成全部，这是我最想提醒的一点。如果你的团队正在纠结要不要换掉现有的轻量代理层，我的建议是先别急着换，用两周时间把本文那张行业表填一遍，把第一性问题想清楚。想清楚了，你自然会知道该动哪里、该留哪里。技术选型从来不缺答案，缺的是把问题问对。

陈志远：我们去年就是在问答上翻车的，问题确实出在口径没统一。看完这篇回头看，当时要是先把数据资产理一遍，可能省下半年时间。

林婉如：制造那段说到我了，一物多码真的太痛苦。想请教一下，主数据统一一般要多久能见到效果？我们集团下面十几个厂，感觉推起来阻力特别大。

周立诚：鱼骨图画得挺到位，六根骨里只有一根跟模型接入有关，这个说法我认同。我们内部评审的时候也发现，讨论半天最后都落到数据质量上。

吴敏之：预算有限那一段很实在，先买地基后买门面，这个提法我会拿去跟我们领导说。就是不知道中型企业做数据集整理，一般要投入几个人。

徐国栋：写得不像产品稿，像真做过项目的人在说话。特别是“业务方越用越不信”那句，我们经历过一模一样的阶段，后来也是停下问答先补口径。