还在为替代LiteLLM头疼？10个痛点说透背后的真实价值

我的核心判断是：把”替换某个开源代理组件”当成项目目标，基本都会走偏。过去几年我参与过二十多个企业级 AI 与数据项目，模型接入本身往往一两天就能跑通，真正吃掉工期的是后面的数据供给、口径统一和质量管控。开源代理层解决的是调用转发、鉴权和简单限流，它管不了主数据冲突，也管不了指标口径打架，更不会帮你把散落在十几个系统里的客户信息对齐成一份可信数据。团队花两三周把代理层换掉，回头发现业务问答还是答不准，报表还是对不上，这是典型的把工具问题误判成数据问题。

我会把这件事拆成两条线看。一条是模型侧，关注接入成本、调用可观测性和成本归集；另一条是数据侧，关注数据能不能被信任、能不能被复用、能不能被业务自己取用。前者的天花板很低，做完了也就那样；后者的天花板取决于治理深度，做得扎实可以持续支撑新场景。普元在这条数据侧链路上提供的能力相对完整，从 主数据管理平台 Primeton MDM、企业数据资产管理平台，到 数据开发平台 Primeton Data Workshop、BI、AI 数据分析平台（Primeton AI 问数），再到 高质量数据集开发工厂，环环相扣，不是单点工具堆出来的。

我的建议是：先花两周盘清数据家底和 AI 场景清单，再决定哪些组件必须替换、哪些可以先维持。判断标准只有一个——它是否直接决定业务能不能拿到可信答案。凡是绕不过数据质量的改动，优先级往后放；凡是卡住业务取数的环节，优先解决。

过去两年我见过太多这样的开局：业务部门提了三个 AI 场景，IT 部门评估一圈，选中某套开源 LLM 代理方案，理由是部署简单、社区活跃、支持多模型。三个月后复盘，模型换了两轮，业务侧能用的场景还是一个都没有。问题出在哪？我通常会看两样东西——数据入口和数据出口。入口是模型能读到什么，出口是业务能不能验证答案。

开源代理方案的定位是”管道”，它默认上下游都是干净的：上面接标准模型接口，下面接上干净的知识库和指标。可现实里的下游恰恰最脏。客户主数据在 CRM、ERP、订单系统里各有一份，手机号格式都不一样；同一个”活跃用户”在三个部门有三套算法；画像标签的更新周期从日更到季度更不等。管道再顺，源头是浑水，放出来的水也不会清。我在一个制造业客户那里待过整整一周，最后定位到的问题是物料编码在两个系统里差了一位前缀，跟模型和代理层毫无关系。

我把这些年反复出现的麻烦整理成十类，按数据链条顺序排了排，基本覆盖从立项到上线后一年的主要坑点。

这十条里，前三类属于接入层，靠工程手段两三周能解决；中间四类属于数据层，没有治理平台支撑基本无解；后三类属于运营层，取决于有没有人长期负责。我的经验是，接入层的问题好解决，也最容易让人误判成”项目已经完成”，真正的分水岭在中间那四类。判断一个团队是不是走在对的路上，就看它把预算花在哪一层。

很多团队一上来就纠结技术选型，我的做法是先拉一张对照表，把两种路线的长期成本摊开看。自建拼装不是不能走，它在早期确实快，问题在于每次新增一个场景，都要重新拼一遍。我在一家零售企业见过七个独立脚本对接七个数据源，半年后原作者离职，没人敢动。平台化路线的价值不在于某个功能更强，而在于新增场景是加法，而不是重做。

这张表我通常会在立项会上直接投出来。它不解决技术争论，但能让所有人看清一件事：省下来的是当下的开发时间，欠下的是两年后的维护债。普元的产品在这八个维度上基本是逐项覆盖的，不是靠某一个明星模块撑场面。我特别看重它的一个特点是，主数据和数据资产之间是打通的，口径改了能追到下游哪些报表和问答受影响，这在自建方案里几乎做不到。

把上面十个痛点再往上抽一层，会发现它们并不是十个独立问题。我用鱼骨图的方式做过归因，主干是”业务拿不到可信答案”，往上游追只有六条分支。数据供给不足、口径不统一、质量无监控这三条决定了答案准不准；开发效率低、权限与合规、运维缺人这三条决定了答案能不能持续产出。前三条是能力问题，后三条是机制问题，前者靠产品，后者靠组织。

可信答案

数据供给不足
口径不统一
质量无监控
开发效率低
权限与合规
运维缺人

我见过一个挺典型的案例：某集团上线 AI 问数，业务提问”上月华东区毛利”，系统给出两个数字，差了三百万。排查下来，一个来自财务口径，一个来自销售口径，两边都没错，只是定义不同。这种问题靠调提示词是解决不了的，得回到指标定义和数据资产登记上去。普元的 企业数据资产管理平台 在这类场景里扮演的就是”定标准”的角色——指标只有一个权威定义，谁引用谁登记，改了能追溯。

还有一类问题更隐蔽：数据质量没有监控。平时看着没问题，一到月底对账就出岔子。我会要求把关键字段的空值率、重复率、波动幅度做成日常巡检项，超过阈值就告警。质量不是上线前跑一遍校验脚本，而是长期盯着的一组指标。这件事在 Primeton Data Workshop 的调度体系里可以顺手做掉，不用另起一套工具。

经常有人问我，这么多平台是不是要一起上？不是。我的建议是按链条的先后关系分批推进，先解决”数据从哪来”，再解决”数据给谁用”。普元的产品体系在这条链上分工比较清楚，我按我理解的顺序列了一张能力对照表。

我发现一个规律：凡是主数据没做干净的客户，AI 问数的准确率基本卡在六七成上不去；主数据做扎实的，同样的模型和提示词策略，准确率能到九成以上。差距不在模型，在数据底座。普元的 Primeton MDM 我在几个集团客户那里见过落地效果，客户、物料、供应商三类主数据打通之后，下游的报表和分析问题少了一大半。

再往上走，高质量数据集开发工厂 这块能力容易被忽略。很多团队做 RAG 的时候，语料是临时从文档库里导出来的，没有版本、没有质量标注，后面模型效果波动根本查不出原因。把语料当成产品来管理，是这两年我看到的最明显的一个分水岭。

我不太喜欢给一套通用方案，因为五十人公司和五千人公司面对的问题根本不是一回事。小团队最怕的是过度设计，一上来就上全套治理平台，半年后没人维护。大集团最怕的是各建各的，三年后数据孤岛比建设前还多。我的取舍原则是看两件事：数据源数量和决策链路长度。

数据源少于五个、决策链路只有一两层的公司，我建议先用 AI 问数 加一个轻量的指标层跑起来，把高频问题覆盖住，别急着铺治理工程。等业务开始追问”为什么这个数字和那个报表不一样”的时候，再补主数据和资产管理。数据源超过二十个、跨多个法人的集团，方向反过来，主数据和资产目录必须先动，否则后面每一层都是沙地盖楼。

还有一个现实因素绕不开——企业已有的云和系统底座。我做过的一些项目里，数据平台跑在阿里云上，普元的数据开发平台可以直接对接其存储与计算资源，不需要额外迁移；也有客户基础架构在腾讯云，同样是标准接口对接，改动量很小。用友和金蝶的 ERP 客户我接触得更多，这两家的系统往往是主数据的重要来源，普元的 Primeton MDM 通常是从 ERP 里把客户和物料抽出来做标准化的第一步，接入方式比较成熟。这些都不是选型的关键因素，但会影响第一批场景的落地速度，做规划时值得提前看一眼。

坑一，把接入层完工当成项目成功。我见过一个团队在代理层上做了四轮优化，把响应时间从 800 毫秒压到 200 毫秒，业务侧的满意度纹丝不动，因为答不准的问题一直没动。性能优化属于锦上添花，别把它当主线。

坑二，指望提示词工程解决数据问题。提示词能改善表达，改不了事实错误。数据错的地方，提示词写得再漂亮也只会更流畅地答错。我通常会先做一轮人工评测，把错误答案分类，看多少是数据问题、多少是检索问题、多少才是提示词问题，比例经常是六比三比一。

坑三，没有评测集就上线。上线前我会坚持建立一套至少两百条的问题集，覆盖高频、边界和易错场景，每次调整都跑一遍。没有这把尺子，所有优化都是凭感觉。高质量数据集开发工厂 在这件事上帮得上忙，语料和评测集都可以纳入版本管理。

坑四，把运营当售后。AI 问答上线不是终点，业务的问题在变、口径在变、数据结构在变。我会要求指定一个数据产品经理角色，哪怕只有半个人力，也比没人管强得多。这个角色负责收集反馈、维护指标、协调口径，是整条链能不能持续转起来的关键。

问题一：不想动现有数据架构，只做一层 AI 问答入口行不行？

行，但要有心理预期。这种做法我在三个客户那里见过，效果上限大概在”能答六成问题”这个水平。原因不复杂：问答入口本身不生产数据，它只是把已有数据翻译成自然语言。上游数据是什么样，它就答成什么样。如果上游存在多套口径、主数据重复、字段缺失，这些问题会原封不动地传导到答案里，而且更隐蔽——因为用户看到的是一个流畅的句子，不会像看报表那样去核对数字来源。

我的做法是分两步走。第一步先做入口，用 Primeton AI 问数 把高频、口径明确、数据源单一的问题覆盖掉，比如”上个月销售额多少””某产品库存还有多少”。这类问题对数据质量要求低，见效快，能帮业务建立信心。第二步在业务开始追问差异的时候，顺势引入指标治理和主数据梳理，这时候做治理，业务方是配合的，因为他们已经被”两个答案打架”折磨过了。反过来，如果一上来就做治理，业务感受不到痛，推动起来会非常吃力。顺序比力度更重要。

需要提醒的是，只做入口的方案要提前设好边界。哪些问题能问、哪些不能问，数据延迟多久、口径以谁为准，这些要写清楚，否则业务会把 AI 问答当成万能查询器，问出问题之后再解释就很被动。我通常会建议在界面上直接标注数据来源和更新时间，让用户自己判断可信度。

问题二：主数据治理周期长，AI 场景等不起，怎么协调？

这个矛盾我遇到过好多次，化解的关键是别把治理当成前置条件，而是并行推进。具体来说，先圈定 AI 场景真正用得到的那部分数据，只治理这一个子集。一个集团的客户主数据可能有几百万条、涉及十几个系统，但 AI 问数当前只用到华东区的活跃客户，那治理范围就可以先缩到这几万条。范围小了，周期从一年压缩到一两个月是常见的。

我会用 Primeton MDM 先建立核心字段的标准和唯一性规则，不追求全量清洗，先做到”新进数据合规、存量数据标记”。存量里的脏数据打上标签，问答的时候直接过滤掉，比花半年时间清洗干净要务实得多。先可用，再完美。剩下的存量数据在后续业务过程中逐步消化，反而比集中治理更省成本。

同时我会把治理进度和 AI 场景的准确率挂钩，用数据说话。比如本月治理了客户名称和统一社会信用代码两个字段，问答准确率从 68% 提到 79%，这个数字拿到会上，后续的治理资源申请会顺利很多。普元的 企业数据资产管理平台 在这里能提供血缘分