最近和不少朋友聊企业大模型落地，发现一个很有意思的现象。
很多项目刚启动时，大家最关心的是 GPU。
“要不要上 A800？”
“多少张卡够？”
“推理并发能不能扛住？”
“模型选 7B、14B 还是 70B？”
“私有化部署成本会不会太高？”
这些问题当然重要。
但如果一个企业大模型项目最后失败，最贵的坑往往不是 GPU。
真正贵的，是你花了很多钱、很多人、很多时间，最后做出来一个“看起来很先进，但没人真正依赖”的系统。
一、最危险的开局：先买算力，再找场景
我见过一些项目，一开始就很有仪式感。
领导重视，预算批了，服务器到了，模型也部署起来了。第一次演示的时候，大家围着屏幕，看它总结文档、写邮件、回答制度问题，气氛很好。
然后问题来了：
“这个系统具体给谁用？”
“每天用几次？”
“替代了原来哪一步工作？”
“省下来的时间怎么衡量？”
“回答错了谁来兜底？”
一问这些，会议室就安静了。
很多企业不是没有技术能力，而是太早进入了“建设模式”。一上来就想搭平台、买算力、接模型、做门户，仿佛只要底座够强，业务自然会长出来。
但业务不会自己长出来。
大模型不是一台摆进公司就自动产生价值的机器。它更像一个能力很强、但需要被放进具体工作流里的新人。你不给它岗位、不告诉它边界、不让它接触真实任务，它就只能在演示里表现得很聪明。
所以第一个坑是：
先买 GPU，再找场景。
这件事贵，不只是因为 GPU 贵，而是因为它会让团队误以为项目已经在推进。实际上，最关键的问题还没开始。
二、聊天框很容易做，但不等于产品
企业做大模型，最常见的第一个应用，是一个内部 ChatGPT。
这很正常。
聊天框门槛低，演示效果好，也方便大家理解“大模型能干什么”。
但问题是，聊天框太容易让项目停在“能聊”这个层面。
用户打开它，要自己想问题、自己描述上下文、自己判断答案能不能用、自己复制到业务系统里继续操作。看起来 AI 参与了工作，实际上很多负担还是在用户身上。
比如销售想跟进客户，他真正需要的可能不是一个空白输入框，而是在 CRM 页面里直接看到：
- 这位客户最近三次沟通重点
- 潜在风险
- 下一步建议
- 可发送的跟进话术
比如客服处理问题，他需要的也不是问一句“这个问题怎么解决”，而是在工单旁边自动出现：
- 相似历史工单
- 标准处理流程
- 可引用的知识库来源
- 回复草稿
这才叫落地。
聊天框是入口，不是终点。
如果大模型不能进入业务动作，它就很容易变成一个“偶尔玩一下”的工具。
企业项目最怕的不是没人试用，而是只有试用，没有依赖。
三、知识库问答的坑，比想象中深
很多企业第一个严肃场景，是知识库问答。
这个方向没错。
制度、流程、产品文档、技术方案、客服话术，确实都适合用大模型重新做一遍体验。
但很多团队低估了知识库。
他们以为流程是：
把文档收集起来，切片，向量化，接到模型上，然后就能问答了。
听起来很顺，实际很容易翻车。
因为企业文档通常有几个特点：
- 版本混乱
- 口径冲突
- 过期内容没人删
- 权威文档和临时说明混在一起
- 表格、图片、附件里藏着关键信息
- 不同部门对同一件事有不同解释
模型拿到这些内容后，会怎么样？
它不会说：“你们公司文档治理不太行，我拒绝回答。”
它会努力组织语言，给你一个看起来很专业的答案。
这才可怕。
大模型最危险的时刻，不是它明显答错，而是它用一种特别可靠的语气，把错误说得很顺。
所以知识库问答的核心，不是“把文档接入模型”，而是先回答：
- 哪些文档是权威的？
- 哪些内容已经过期？
- 谁负责维护？
- 检索结果是否有权限控制？
- 答案是否必须带来源？
- 用户发现错误后反馈给谁？
RAG 不是银弹。
它本质上是在放大你的知识管理水平。
知识管理清楚，它会帮你提效。
知识管理混乱，它会帮你把混乱包装得更像答案。
四、微调不是万能药，别急着训练
很多项目效果不好时，第一反应是：
“要不要微调一下？”
这句话我听过太多次了。
模型回答不准确，想微调。
模型格式不稳定，想微调。
模型不了解公司制度，想微调。
模型不会按流程走，还是想微调。
但微调不是万能药。
如果模型不知道你的内部知识，优先考虑 RAG。
如果模型输出格式不稳定，优先做结构化输出和校验。
如果模型不知道什么时候该调用系统，优先设计工具调用。
如果模型回答口径冲突，优先治理数据源。
如果模型速度慢，优先看模型尺寸、缓存、并发和推理部署。
微调真正适合的是：你有大量高质量样本，并且希望模型稳定学会某种任务模式或表达风格。
但如果你的数据本身很乱，微调只会把混乱训练得更稳定。
这句话有点刺耳，但很真实：
没有高质量数据的微调，本质上是在给问题做固化。
五、权限不能后补，后补一定痛
企业内部大模型有一个很容易被忽视的问题：权限。
很多团队做 demo 时，会把文档都放进知识库，让模型尽可能回答得完整。演示时确实效果很好。
但真正上线后，问题就来了。
员工问：“某客户合同价格是多少？”
模型检索到了合同内容，然后回答了。
可这个员工原本没有权限看那份合同。
这不是模型“泄密”，而是系统设计时权限没有进到检索层。
企业大模型不是普通搜索框。
它会总结、联想、改写、组合信息。只要权限控制有洞，它就可能把原本分散、不可见的信息整理成一个清晰答案。
所以权限一定要从第一天设计：
- 用户身份怎么识别
- 文档权限怎么继承
- 检索前是否过滤
- 工具调用是否鉴权
- 日志是否脱敏
- 敏感问题是否审计
- 高风险答案是否拦截
千万不要想着“先做效果，后面再加权限”。
企业系统里，权限后补通常都很痛。因为你不是补一个按钮，而是在重构整个数据流。
六、没有评估集，优化全靠感觉
大模型项目很容易陷入一种状态：
业务觉得“不太准”。
技术觉得“其实还可以”。
领导问“到底提升了多少”。
大家拿几个例子来回讨论。
最后谁也说服不了谁。
原因很简单：没有评估体系。
如果你做知识库问答，就应该提前准备一批真实问题：
- 高频问题
- 容易混淆的问题
- 权限相关问题
- 过期政策问题
- 模型应该拒答的问题
然后看几个指标：
- 是否答对
- 是否引用正确来源
- 是否编造
- 是否遵守权限
- 不知道时是否能说不知道
- 答案是否对业务有用
评估集不需要一开始就很完美，但必须有。
没有评估，模型优化就像闭眼调参。
今天换提示词，明天换模型，后天改切片策略，每个人都觉得自己改好了，但没人知道系统整体有没有变好。
企业大模型要想长期跑下去，不能只靠 demo 样例活着。
七、真正贵的是组织耐心被耗光
GPU 贵不贵？当然贵。
但更贵的是，一个项目做了半年，最后业务方失去耐心。
第一次演示，大家很兴奋。
第二次试点，大家开始提问题。
第三次上线延期，业务开始观望。
第四次还在讨论模型效果，大家就会默默回到原来的工作方式。
从那以后，再想推动就难了。
因为大模型项目消耗的不只是预算，还有信任。
业务方会想：
“上次说能提效，最后也没用起来。”
技术团队会想：
“业务需求总变，根本讲不清楚。”
管理层会想：
“投入这么多，为什么看不到结果？”
这时候项目不是技术失败，而是组织协作失败。
所以企业做大模型，一开始就要控制范围。不要试图第一个版本解决所有问题。
找一个足够具体的场景，快速做出闭环：
- 谁用
- 何时用
- 输入是什么
- 输出是什么
- 接下来怎么操作
- 怎么反馈
- 怎么衡量
只要一个场景真的跑起来，后面就有机会。
如果第一个场景做成“平台大而全，业务轻飘飘”，后面会越来越难。
八、什么样的场景值得先做？
我会优先看四个条件。
第一，高频。
一个月只发生几次的场景，不适合作为第一个突破口。大模型需要真实使用反馈，高频场景才能快速迭代。
第二，有明确输入输出。
比如“根据客户拜访记录生成跟进总结”，就比“提升销售效率”靠谱得多。
第三，有可用数据。
不是说数据一定完美，而是至少能找到真实文档、历史案例、业务记录，能支撑模型进入上下文。
第四，有负责人。
这个非常关键。没有业务负责人，AI 项目很容易变成技术团队自娱自乐。模型上线后，没人维护知识，没人判断效果，没人推动使用。
符合这些条件的场景，不一定宏大，但很适合开局：
- 客服工单辅助
- 内部制度问答
- 合同条款初审
- 售前方案生成
- 运维告警分析
- 研发知识库问答
- 销售拜访纪要整理
第一步不要追求“改变公司”。
先让一个具体岗位的一段工作，真的轻一点。
九、我的建议：先别问要多少卡
如果你正在准备企业大模型项目，我建议先别急着问：
“需要多少 GPU？”
可以先问这几个问题：
- 这个系统给谁用？
- 他现在最痛的工作是什么？
- 这件事每天发生几次？
- 现在怎么做？
- 模型介入后，哪一步会变短？
- 答错了有什么风险？
- 结果怎么评价？
- 谁来维护数据和流程？
这些问题听起来不如模型参数性感，但它们决定项目能不能活下去。
GPU 预算花出去，机器总会到。
模型部署起来，也只是时间问题。
真正难的是：
你能不能把大模型放进一个真实的业务位置，让它持续产生价值。
写在最后
企业大模型落地，最贵的坑不是 GPU。
GPU 至少是看得见的成本。
真正贵的，是场景没想清楚，数据没治理，权限没设计，评估没建立，最后把组织耐心一点点耗光。
大模型当然值得做。
但它不是用来证明公司“跟上时代”的摆设。
它应该让某个具体的人少查一份资料，少写一段重复文本，少漏一个风险点，少走一次弯路。
这些变化听起来不宏大，却是真正的落地。
别把大模型项目做成一场昂贵的热闹。
能被每天使用，能进入业务流程，能留下可衡量的结果，才是它该有的样子。
