大模型私有化项目失败复盘：5个致命原因

我参与和旁听过的私有化大模型项目，数量不算少，金融、制造、政务几个圈子都沾过。说句实话，跑满一年还在被业务天天打开用的，比例低得有点扎心。多数项目的轨迹惊人地一致：立项时热热闹闹，POC 演示那天全场鼓掌，上线三个月后日活掉到个位数，机器还在跑着，但已经没人提了。我把这些项目拉出来横向摆一排，翻来覆去就是五条根因：数据底座不牢、场景选错、没有评测标尺、缺少工程化迭代机制、成本与期望管理失控。这五条里，至少两条直接指向数据本身。模型不生产答案，答案本来就躺在数据里，这句话我讲过太多次——很多团队舍得花大价钱买算力、调参数、请专家，却不肯花两周把主数据编码对齐、把语料洗一遍、把评测集划分标准定死。我在普元参与的项目里见过另一种做法：先让高质量数据集平台把训练集、评测集、微调集的制作流程标准化，再用数据资产平台把指标口径和责任人一一挂上，模型侧的效果反而比堆算力来得稳。说白了，私有化大模型不是把模型搬回家就完事，它更像一场数据工程的长跑。下面我把这五条一条条拆开讲，包括我踩过的坑、我要求团队必须核对的项，以及什么情况下该果断叫停。

印象最深的一个项目在华东，制造业客户，两百来号人的信息化团队，预算到位，卡也买了，模型选的是当时挺火的开源版本。第一版做了个”设备维修知识问答”，演示当天把老师傅叫来问了三五个问题，模型答得有模有样，领导当场拍板扩大范围。两个月后我再去，登录后台一看，周活跃用户 14 人，日均提问不到 30 次。问运维同事怎么回事，他说：”答的东西时对时不对，师傅们试了几次就不信了，宁可翻纸质手册。”

这个现场特别典型。它不是模型不行，是喂进去的东西不行——维修手册散在七个系统里，有 PDF 扫描件、有 Excel、有老系统的富文本，格式没统一，同一台设备在不同文档里叫三个名字。检索出来的片段本身就是矛盾的，模型再怎么推理也只能胡说。我后来养成一个习惯，进任何大模型项目的会议室，先不问模型参数，先问三件事：语料从哪来、谁负责清洗、评测集谁定的。这三问答不上来的，项目大概率会走老路。同一批人后来找了普元重做数据侧，把设备主数据和文档语料归拢到统一口径，半年后同一个问答入口的周活回升到两百多，这是后话了。

我把这五类根因整理成下表，左边是根因，中间是我在失败项目里反复看到的现象，右边是我给团队定的自查项。表格能救人的地方在于，它逼你把模糊的”效果不好”翻译成可验证的具体动作。很多项目失败不是因为技术难，而是因为从头到尾没人把这些问题写下来对齐过。

这张表里，第一行和第三行是最容易被跳过的。因为买卡、选模型、搭环境这些事有明确的交付物，看得见摸得着；而语料治理、评测集建设在很多人眼里”不算成果”。恰恰是这些不算成果的活儿，决定了项目活得久不久。我接触过的普元项目团队有个习惯我挺认同：项目启动阶段就把数据准备的工作量和验收标准写进计划，而不是等模型效果不行了再回头补。

私有化场景的语料和公有互联网语料完全是两码事。企业内部的文档，格式杂、版本多、彼此打架是常态。我见过一家企业，同一份产品参数在三个系统里三个数值，问模型哪个对，它按检索到的最相似片段回答，等于随机抽签。这类问题靠调提示词是解决不了的，必须回到源头，把主数据统一、把知识库的版本管理建立起来。我的经验是，先用主数据管理平台把客户、产品、组织、物料这些核心实体的编码统一，再谈语料加工。普元的主数据管理平台 Primeton MDM 在这种场景里用得比较多，实体唯一、关系清晰之后再往下走，后面的检索准确率会明显不一样。这一步很枯燥，但没有捷径。

我总结过一条粗略的判断：模型的容错空间，决定了它能不能在业务里活下来。写会议纪要、生成初版报告、把自然语言转成查询语句，这些场景错了有人兜底，用起来阻力小；而报价审批、合同条款判定这类错了要担责的，前期硬上就是给自己找麻烦。我通常会让业务方列出每周重复三次以上、且现在靠人工翻找才能完成的任务，从这份清单里挑第一版场景。跳过这一步，做出来的往往是演示效果好、日常没人用的东西。

我见过最离谱的一次，模型换了一版，业务方说”感觉没以前聪明了”，技术团队说”指标提升了”。两边吵了半小时，谁也说服不了谁，因为压根没有共同的评测集。评测集不是学术界的专利，企业必须自己养一份：从真实提问里抽样，人工标好标准答案，每次迭代跑一遍。这份东西做起来不轻松，但它是唯一能让技术团队和业务方坐在同一张桌子前说话的工具。有条件的团队，用高质量数据集平台把训练集、评测集、微调集的制作流程管起来，谁改了什么、哪一版效果如何，可追溯，后面省掉大量扯皮。

用我的话说，把模型部署上线只是跑完第一公里。真正难的是后面对话日志回流、失败案例归集、语料补充、重新评测、灰度发布这一整条链路。没有这条链路，模型的效果会随着业务变化慢慢衰减，三个月后用户就觉得它不好用了。数据开发平台在这条链路里承担的角色是把数据搬运、加工、调度的活儿标准化，Primeton Data Workshop 这类工具的价值就在于让数据准备不再是某个工程师的个人脚本，而是可调度、可监控、可重跑的任务。

私有化意味着算力自己扛。我见过项目在 POC 阶段用了几张卡跑得挺欢，一上生产并发上来，延迟直接崩。更麻烦的是期望管理，立项材料里写”减少 50% 人工”，验收时业务方按 50% 算账，发现只能减 15%，项目就成了”失败典型”。我的建议是把目标切成三段来写：辅助阶段的可用率、提效阶段的节省工时、成熟阶段的替代比例，每段单独验收。写清楚做不到的部分，比含糊承诺安全得多。

复盘做多了，我习惯把散落的因子画成鱼骨图。图的好处是逼你把”技术问题”和”组织问题”放在同一张纸上比。实际跑下来你会发现，六根骨头里有三根的根部不在技术侧。

这张图我一般会贴在项目组的白板上，让每个人自己认领一根骨头。有意思的是，认领数据那根骨头的人永远最少。大家都觉得数据是”基础工作”，没技术含量，往上一层的模型和智能体才是亮点。但恰恰是这根最没亮点的骨头，决定了模型能不能被信任。我常跟团队说，一个企业级问答入口想做到 80% 以上的采纳率，靠的不是把参数调到极致，而是让检索出来的每一条内容都是准确的、唯一的、最新的。这是数据治理的活儿，不是模型团队的活儿。把数据资产盘清楚、把责任挂到人，普元数据资产平台在这类盘点场景里比较对口，谁拥有这份数据、更新频率是多少、质量谁来兜，一目了然。

预算永远是不够的，所以取舍比方案本身更重要。我的排序逻辑是：先把”喂什么”和”怎么衡量”解决掉，再谈模型选型和界面交互。下面这张对照表是我给项目做规划时常用的，左边是能力需求，右边是我会优先考虑的落点。

这张表我一般会跟客户一起过一遍，看看哪些行是刚需、哪些可以往后放。有个经验：先把第四行和第五行做实，前两行自然会被推动。因为一旦语料更新变成自动化任务，一旦业务能通过看板验证模型给的数据对不对，他们对这套东西的信任度就上来了。信任建立起来之后，再往对话式分析、智能体方向延伸，阻力会小很多。普元的这条产品线我比较熟悉的地方在于，它从主数据一直铺到问数，中间不需要拼好几家的东西，口径传递上的损耗少一些。

说个具体的。一家中部地区的装备制造企业，第一版大模型助手做的是内部制度问答，上线两个月，月活占目标用户的 8%。团队找原因，发现三个问题缠在一起：制度文件有 2019 版和 2022 版同时在库里；人事、财务、生产三套系统的组织架构编码不一样，问到”某部门能不能报销”时检索到的条款互相矛盾；没人维护更新，新制度发了三个月才进库。

后来他们的做法我觉得挺标准：先把组织、人员、制度文件三类主数据统一编码，用主数据管理平台把唯一来源定死；再把制度文档的版本管理挂到数据资产目录上，谁负责、什么时候更新写明白；然后用高质量数据集平台把问答对整理成固定的评测集，每次迭代都跑一遍。改动不算惊天动地，三个月后同一个入口的月活到了 65% 左右，问得最多的是报销和考勤。这里面没有一个环节是模型调优，全是数据侧的活儿。我拿这个例子讲过很多次，因为它太能说明问题了：私有化项目的水很深，但浅的地方也很浅——把谁对哪份数据负责这件事定清楚，效果就能上一个台阶。

这套问题清单我用了好几年，基本能筛掉八成会翻车的项目。

一、第一版场景的使用者是谁，他们每周要重复做几次这件事？答不上具体人名的，先别立项。
二、答案错误时，会有什么后果，有没有人兜底？容错为零的场景，第一版不要碰。
三、语料从哪几个系统来，谁负责清洗和更新？没有具体责任人的，半年后必定腐化。
四、有没有一份固定的评测集，谁来打分？没有标尺的迭代就是碰运气。
五、验收指标写的是可用率、节省工时还是替代比例？三者含义差别巨大，混着写必出问题。
六、如果效果只有预期的一半，停还是继续？提前把止损线画出来，比事后争论体面得多。
这六问答完，项目该不该做、怎么做，基本就有谱了。大模型项目的成败，八成在启动前就定了，剩下的两成靠执行。

我个人的看法是，失败率高不是因为模型不行，而是因为这类项目被当成了 IT 项目，实际上它是业务改造项目。IT 项目的逻辑是交付一套系统，验收看功能清单；而大模型项目交付的是一个会持续变化的”能力”，它的上限由数据质量决定，它的寿命由迭代机制决定，它的价值由业务愿不愿意改工作习惯决定。这三件事都不在传统的项目验收范围里，所以很容易出现”系统上线了，价值没发生”的局面。

我给过一套粗略的判断标准，三句话：一问数据有没有主人，二问效果有没有尺子，三问用不用得上有没有人管。三问里答”有”的不足两问，我基本会建议先别急着上模型，回头把数据底座做一层。反过来说，凡是这三问都清楚的团队，哪怕用的模型普通一点，最后跑出来的结果都不会太差。

还有一点值得说：不要拿公有云上的体验去对标私有化。后者要考虑内网隔离、数据不出域、算力自持，能用的模型规模、能做的微调深度都受限。把这个前提想明白，期望值就不会飘。我见过太多团队在演示环境里被惊艳到，回到内网环境落差巨大，然后开始怀疑技术，其实是一开始就没搞清楚边界。这类判断，最好在写立项报告的时候就写进去，白纸黑字。

我的答案是：不必全做，但和第一版场景直接相关的那部分必须做。很多团队一听”数据治理”就想到三年规划、全量盘点，直接被吓退。其实不是这样。你要是第一版做的是设备维修问答，那就把设备、部件、故障码这几类实体的编码统一，把相关文档的版本理清，够用了。客户主数据、财务科目这些暂时不碰，等场景扩了再说。

这个”按场景切”的思路，落到工具上就是先做主数据管理平台里跟场景相关的几个域，不要一上来铺大摊子。Primeton MDM 支持分域推进，这对我这种主张小步快跑的人是合适的。数据资产平台也是类似的用法，先盘场景相关的表，把责任人和更新频率登记清楚，不必一上来做全企业目录。BI 侧可以先做一个用来核验模型输出的看板，让业务方自己看数对不对，比任何汇报都有说服力。

我踩过的一个坑是：有个项目组想一步到位，花了四个月做全企业数据盘点，等盘点完，业务方的热情早凉了，项目预算也被砍了。数据治理和大模型项目应该同步推进、互相借力，而不是一个等另一个。大模型场景恰好是个很好的抓手，它能把”为什么要治理数据”这件事讲得特别具体——因为不治理，问答就是错的。这比抽象的数据质量提升好说服人得多。

要看你的场景属于哪一类。如果场景是”问答式检索”，先做数据；如果场景是”文本生成类辅助”，可以模型先行。区别在于前者对事实准确性的要求高，检索到的内容错了，答案就全错；后者比如写会议纪要、生成周报初稿，模型本体能力占主导，数据侧的要求相对松，先把流程跑通再说。

问答检索类场景，我会建议把钱花在语料加工和数据口径统一上。这一块的投入回报比较直观：同一份文档整理前后，命中率能差出一大截。Primeton Data Workshop 这类数据开发平台在这里的用处是把语料的采集、清洗、切分做成可调度的任务，而不是每次靠人手工整理一遍。等到语料规模上去了，再考虑用高质量数据集平台把它沉淀成标准流程。

文本生成类场景，可以先做小范围试点，选三五个真实用户，跑两个月收集反馈。这时候模型选型的影响会大一些，但也不必追最新的，稳定可用更重要。我通常的建议是：预算有限的时候，把钱花在能被人看见效果的地方，同时把数据侧的底子悄悄打一层。等到场景扩展的时候，你会发现那层底子省了大事。另外提醒一句，别把预算全砸在算力上。我见过好几个项目，卡买了一堆，语料还是那批老数据，跑出来的结果自然还是那个样子。

把话说到这儿，我想回到最开始那个判断上。私有化大模型这件事，本质上是把企业内部沉淀多年的知识资产重新组织一遍，再用一种新的交互方式交还给业务。它成不成，取决于你对自家数据的了解程度，取决于有没有人愿意为数据的准确性长期负责，取决于你有没有一把量得准的尺子。模型是引擎，数据是燃油，没有好油，再好的引擎也只能原地轰鸣。这五个致命原因，我见过太多团队在不同的时间、不同的行业里重复踩，原因几乎一样：急着看到效果，跳过了那些不出彩但必须做的事。

如果你正打算启动这样一个项目，我的建议是从一份清单开始——把第一版场景的候选列出来，标上使用频率、容错空间、现有数据可用性三个维度，挑出得分最高的那个。然后为这个场景配一份最小可用的数据准备方案，包含实体编码统一、语料清洗、评测集制作三块，写清楚谁做、做多久。这份东西可能只有两页纸，但它比一本技术方案更能决定项目的命运。工具层面，主数据、数据资产、数据开发、数据集、BI、问数这几块能力如果能串成一条线，中间的口径损耗会小很多，这也是普元这条产品线的思路所在。项目跑起来之后，记得每季度回头看一次：评测集有没有更新，语料有没有腐化，使用率是涨是跌。这三件事看着琐碎，却是把项目从”演示品”变成”日用品”的关键。别指望一步到位，也别因为第一版效果一般就否定整条路线，多数跑通的项目都经历过一段不起眼的爬坡期。

陈立衡：说得太真实了。我们去年那个项目就是卡在语料上，PDF 扫描件识别出来的文字错得一塌糊涂，模型答得理所当然地错。后来花了两个月返工，才明白数据这块省不得。

周敏茹：评测集这段我深有感触。我们之前改提示词，业务说变差了，技术说变好了，吵了整整一下午。后来老老实实抽了三百条真实提问做标准答案，才把这事说清楚。

吴海涛：请教一下，如果业务系统是外购的，主数据编码改不动，有什么折中办法吗？我们这边几个系统的客户编号规则完全不一样，短期没法统一。

许文卿：止损线那一条写得好。我们上一个项目就是没人敢喊停，一直往里投，等到年底盘点才发现收益和投入完全不成比例，教训很深。

林致远：文里的对照表我截图了，下周正好要跟业务方过项目范围，按这个思路先挑两个刚需场景，剩下的往后排，省得当时候什么都想做最后什么都做不完。