企业内部如何更好落地大模型？我们走访了 10+ 先行者

好的，作为一位深耕企业数字化转型与AI应用落地的专家，我很乐意接下这个任务。以下是根据您的要求，对原文进行“人性化重写”后的版本。 ***

微软Copilot的推出，像一块投入平静湖面的石子，瞬间让“大模型如何在工作里真刀真枪地干”成了圈内热议的话题。紧随其后，钉钉、飞书这些我们日常离不开的办公软件，也火速把AI功能塞进了新版本。

对于软件公司来说，在自家产品上嫁接AI能力，然后变&现——这条路已经被Notion、多邻国这些先行者跑通了。但另一个视角同样值得关注：在企业真刀真枪的生产环境里，怎么把LLM的能力内嵌进去，给整个组织赋能，这才是大家都在琢磨的AI落地的另一面。

Founder Park研究中心最近和一批最早吃螃蟹的实践者们聊了聊。一个很明显的感受是：大模型技术的热度破圈之后，这次跟以往的技术升级不太一样，来自各行各业的企业，都表现出了空前的意愿，想在自己的生产环境里试试LLM。

不过，话说回来，应用落地的速度快不快、质量好不好，说到底还是看企业自己对技术的理解深度、动手实践的能力，以及选了哪条落地路径。这份总结性的研究，就是希望能给那些正在思考、摸索如何用大模型给生产提效的企业，提供一些实在的参考。

• 在企业生产里，LLM最能直接创造价值的方式，目前集中在三件事上：把专家/岗位的经验数字化、把最佳实践放大，以及给初级员工快速赋能。
• 那些规则说不清道不明，或者缺乏过程性数据的需求，眼下还不适合用LLM来解决。反过来，从企业有独特数据积累的、切口很小但很具体的功能入手，反而能更快获得正向反馈，为后续把LLM和业务绑得更深打下基础。
• LLM本质上是个输入和输出的过程。无论是用Prompt还是更重的SFT（微调），高质量输入都是高质量输出的前提。这包括：整理好的知识库文本、凝结了专家经验的Prompt，以及保留了“Knowhow”的过程性数据或问答对。
• 定义好输入输出，前提是你得先搞清楚，这个LLM在你工作流里到底扮演什么角色，承担什么具体职责。所以，从业务场景出发，基于工作流提出清晰明确的需求，应用才能顺畅落地。
• 想实现好效果，又想控制成本，得靠一套综合的技术组件灵活搭配，甚至是用通用模型加上特定功能的小模型来组合完成。最早跑通的应用思路，往往是在现有系统里把LLM的能力集成进去，做以前很难实现的功能。
• LLM本质上是个概率模型，在工程实现上有点黑盒属性。所以，应用的实施效率会随着经验积累越来越高。说白了，经验多的团队，更容易做出好效果。
• LLM的落地，需要自上而下和自下而上的视角结合。即便不需要一把手亲自上手写代码，至少得有一把手明确的意识。具体选什么切入点、用什么应用形态，最好让一线员工来参与定义需求。产品初版上线，员工愿意用、能持续反馈，应用才能越优化越好。

01 LLM的技术特性，决定了它最适合干什么

LLM作为一个概率模型，本质就是预测下一个Token。所以，不管应用的外在形式是什么，核心目标都一样：让模型在特定的语境下，预测下一个Token的准确率达到预期标准。

从通用角度看，LLM拥有语言理解和逻辑推理的能力，落实到应用上，可以拆解成两种基本模式：写作与交互。

最常见的例子就是营销文案生成、报表生成。这类应用的关键，在于让模型

。通过各种工程手段，能把模型调教成一个懂行的写手，按照既定规则输出内容。比如电商领域，根据商品信息和促销背景，生成既符合平台规则、又有SEO效果的促销文案。以前，这种活儿必须得是懂业务的熟手才能干。

代码辅助可以看作是写作的一个特殊场景。作为模型评测的重要指标，coding能力本身就是LLM的强项。它能快速补全代码、修正错误，甚至还能做代码注释和运行。在企业内部，代码往往跟业务强相关，有些特性是通用的。在研发场景里，把模型能力做个性化适配，不仅能提升开发效率、统一代码格式，还能整体上提高代码复用率，帮企业沉淀代码资产。

当然，目前也有局限：模型输出的代码长度大概在30-50行，只能实现一些代码片段。要具备更高级的软件工程能力，还得等大模型本身的能力再进化。

常见例子是企业内部的员工问答助手、客服助手。这类应用的关键，在于

，沟通的结果是让信息、人和工作内容进一步匹配。最终，它们大多会被封装成ChatBot或Agent的形态。比如“分发Bug”这个小功能：测试人员描述完bug，Agent读了内容、理解了之后，再根据系统中运维人员之前修bug的历史记录，自动匹配最合适的人，开出工单。这就在现有系统里实现了信息的精准匹配。

在实践中，这两种能力模式往往会根据具体需求组合使用。比如，在对话交互中，帮业务人员生成所需的报告；为了更好的交互效果，从相关文档中抽取有针对性的信息，再进行话术写作。

02 具体到企业，LLM到底能带来哪些真金白银的价值？

应用落地，可以看作是为模型提供

和。LLM的理解和推理能力是通用的，可以适用于各个场景。而把这种通用能力封装成针对特定岗位、特定环节所需的能力，其原理就是把生产环节的Knowhow跟通用智能叠加在一起。

在实际的企业生产中，如果想落地应用，

和是两种可行的思路。

通过整理知识库来实现专家/岗位知识数字化，比如客服环节。因为它有明确的话术规则和对答规范，而LLM还能在这个基础上实现更自然的交流。

有些岗位的技能或Knowhow，很难用语言清晰描述，但它们会存储在工作流程的文件里。比如项目策划从需求到初稿再到定稿的过程、HR对简历的分析和评价、优秀销售和客户的交流记录。把这些过程性数据喂给模型，它就能从中汲取能力并进行模仿。

：那些多人参与、重复劳动、流程明确的场景，可以用AI来分担部分工作、放大单人能力，从而减少人力成本。或者在成本管理视角下，LLM能提供更灵活的数据看板，对运营数据进行分析，典型场景就是云成本管理。

：主要集中在营销场景。LLM能提供更优质的互动和沟通，无论是销售线索跟进还是售后（复购），都可以利用AI来实现更多的潜在转化、促成交易，从而增加收入。

：在企业经营中，像法律合规、生产安全检查这些场景，LLM可以依据规则，对相关文件和合同进行更灵活、高效的查验和审核，规避风险，避免损失。

理想情况下，应用带来的价值增量如果能用指标来衡量，那项目落地就会顺利得多。比如销售场景，从使用大模型前后的复购率等指标变化，就能估算出对销售额的贡献；招聘场景，对比简历采纳率的变化，能估算出节省的人力成本；云成本管理场景，节省的成本更是可以直接感知。

大模型的应用落地，是“一把手工程”。如果能有效辅助管理层决策，也是很有潜力的落地场景。用LLM的对话能力，可以把企业的不同数据库打通，让管理层方便地调用、分析具体数据，高效获取决策所需的背景信息。

03 部署应用的成本，已经比想象中低很多了

优质开源模型出现后，闭源模型在能力上并没有显示出明显的代际差异，之前那种因为稀缺性带来的高议价能力也随之消失。2023年，千亿参数模型的私有部署方案，价格已经从千万元级别降到了百万元级别。而可以免费获取的开源模型，更是直接降低了项目的入门门槛。

其次，从性能与成本的平衡角度看，能达到性能要求之后，选择最具性价比的工程方案就行了。如果需要本地部署模型，成本主要取决于模型的大小，以及是否做微调。

模型参数越大，对算力的要求就越高，方案成本也随之增加。随着落地经验的增多，业内逐渐发现，配合工程化能力，百亿参数规模的模型在具体场景上，已经可以接近GPT-4的表现了。

模型量化能在保证大部分推理效果的情况下，减少显存占用和运算量。在部署时，根据情况选择量化版本的模型，可以用更少的算力实现部署，同时降低推理成本。有企业表示，在问答功能上，他们利用自己积累的优势语料，采用13B的Int8量化版模型微调后，效果甚至超过了GPT-3.5。

以常用的13B模型举例，FP32全精度、FP16半精度、Int8精度部署方案对显存的要求分别是52G、26G、13G。对应的算力资源则分别为2张A6000、单张A6000、单张A10，成本区间大约在7万、3.5万、2万。

比起Prompt和RAG（检索增强生成），微调显然需要调动更多算力。在私有化方案中，微调也不是必需的。在一些案例里，用高质量本地知识库结合Prompt和RAG方案，也能取得理想效果。有供应商表示，在营销客服场景里，只有需要实现特定表达风格时，才需要上微调。

在访谈中，对于微调，也有观点认为是否需要微调，跟工程方案以及是否调用更强能力的通用模型API等因素相关。

有尝试自己搭应用的企业表示，调试各种模型做测试占了成本的大头。也有供应方认为，市面上模型太多，企业花大量时间试用，反而拖慢了技术落地的速度。

大模型的黑盒属性，也给工程方案带来了随机性，而且高度依赖经验。有做了半年以上方案落地的供应商感叹，在那些尾端的实现细节上，“只能踩坑，不过随着经验变多，从坑里爬出来的速度也会越来越快”。

从技术门槛和时间人力成本考虑，复杂的项目，采购供应商的服务或方案是个不错的选择。根据多方调研，我们总结了目前市场上B端项目的收费情况。费用主要包括算力成本和人力成本，主要受是否部署本地模型（以及模型规模）、实施复杂度等因素影响。如果调用通用模型API，还会产生Token费。

简单问答类应用，使用13B、14B的免费开源模型部署，包括GPU算力费用，价格大约30万起步。

复杂应用，比如涉及数据分析的，需要用到30B及以上的免费开源模型，包括GPU算力费用，价格在百万元以上。

主要费用包含实施费、产品使用年费/人头费、咨询费和Token费。如果调用外部通用大模型API，则按Token量支付模型调用费或购买流量包。前期产品梳理、数据治理工作量重的项目，还会收取咨询费。

这种形式下，如果不涉及本地模型部署，起步价更低，也更灵活。有供应商表示，理想情况下，涉及前期数据治理、百亿参数模型微调、复杂配套工程，对100到500人左右的企业，预算范围在500万以内。

可以预见的是，随着算力层Infra成熟、端侧模型性能提升以及大模型Token价格进一步降低，未来应用的成本还会更低。

04 基础实践经验总结：这套组合拳得打好

把通用智能引入具体工作环节，就像把高压电引入单个房间，得靠一整套技术组合来实现。除了微调、Post Training、向量检索、Prompt Engineering，还包括其他检索技术、传统NLP技术等。

如何有效组合这些工具，全靠实践中积累的经验。有供应商认为，“技术落地的过程里，能形成一个合适的应用组合框架，才会产生更大的壁垒。”

在访谈中，多位供应商表示，

。实施方经验的差距，往往就体现在模型选型、技术组合选择以及工程细节处理等方面。

企业最关心的幻觉和数据隐私问题，主要通过恰当的技术组合来解决。因为LLM是概率模型，所以在工程实施时，通过增加规则限制、RAG技术、上下游流程把控等方式，让回答正确率达标就行。必要时，遇到corner case可以直接拒答，最终实现0误答率。

企业本地部署的知识库和微调模型，能保证大部分数据循环在本地。涉及运营的关键数据，由本地模型（通常是微调过的小模型）直接处理。如果需要用大模型的推理、阅读和写作能力，调用外部API时只会流出局部、零散的不敏感数据，这在企业的接受范围内。

一开始，很多人认为“垂直行业大模型”是解决方案，也就是用领域数据微调模型，让它既有通用智能，又有行业知识。但实践表明，那种面向发散性场景的微调，对落地用处不大。

这就好比有了行业百科全书，不等于就具备专家技能。如果企业觉得“内部微调一个垂直模型，每个岗位加几行prompt，就能变出专属GPTs”，那在生产场景里是很难搭建成应用的。只有在定义好具体需求的基础上进行微调，才能体现效用。而微调的前提，是必须定义清楚模型在特定语境下，“标准答案”是什么，并准备好问答对。

比如在招聘领域，面对批量招聘的岗位，在简历初筛时，让大模型阅读简历并给出评价，供HR进一步筛选。这就是一个非常具体的功能需求。

成功的企业实践里，产品最终交付的往往是某一工作环节的生产力，也就是执行具体任务。大模型有通用性，要让通用性和具体专业知识有效结合，就得让模型去理解某一类型的数据。这些就是“面向任务的数据”，它们的内容、格式、质量等要求，和工程方案紧密挂钩。

准备好这类数据，既需要有工程经验的实施方，也需要对业务本身有深刻理解。定义和梳理好这部分数据，需要企业与技术供应商之间密切协作。SOP（标准作业程序）的梳理和打磨，也是重要的前提。

不过，一个明显的变化是，在LLM时代，传统NLP那种知识标注的工作量已经大大减少了。有相关从业者表示，“以前工程师得帮企业做专家知识库，现在大模型自己就能做一部分。”因为LLM具备了理解和推理能力，也就有了直接从数据中读取知识并使用的本事。

05 想要应用深入，还得解决哪些问题？

有从业者提到，ChatGPT的对话界面火了以后，所有做企业级产品的人，第一反应都是在自己原有的功能上加一层Bot。结果往往是给用户增加了工作量。有时候，用户还得专门去养成和ChatBot交互的习惯。

微软定义了Copilot的范式后，大家又开始琢磨怎么在企业内部岗位里加Copilot。OpenAI强调了Agent概念后，大家又开始想怎么在企业场景里加Agent。从功能实现角度看，ChatBot只是一个交互触点，而Agent则是结合上下文、按特定规则去做判断和动作执行。

但如果真想考虑大模型怎么在企业工作中发挥价值，

。比如，日常工作流里，哪些部分可以被LLM接管？如果大模型需要处理部分企业数据，这部分数据在业务里发挥的价值，处于价值链的哪个位置？目前的运作模式，哪些环节可以用大模型替代？

在访谈中，多位从业者都提到了产品的打磨与优化。无论打磨节奏如何，初版Demo上线后，都需要专家或一线员工在使用中给予反馈，才能持续优化。有人甚至说，即使上线的只是一个“30分的Demo”，只要定义好测试集和反馈标准，把它提升到90分是完全可控的。

产品的探索和深入，也需要从数据反馈和数据回路设计的角度去思考。有B端产品开发者表示，尽管目前使用产品中的数据反馈，还没有形成“数据飞轮”，但它能提供如何优化产品的“Knowhow”。单个功能产生的价值终究有限，只有把“知识的生产和流动”放在产品体系内去完成，才能更好地与原有工作流结合，给生产带来更大价值。

大家普遍觉得，目前国内模型的能力

。应用搭建者对LLM能力感知最敏锐，他们最期待的是整体能力的提升和稳定性。

有从业者表示，模型虽然能实现不错的生成质量，但表现不稳定，30%的情况下会出现比较差的结果。那些用过国内外模型的搭建者则表示，跟GPT-4和Claude相比，国内模型的指令跟随能力有明显差距，这就得写更复杂的prompt。当指令跟随性不够强时，想控制住结果，就得多来回交互几次，这样Token消耗量就上去了，也增加了执行任务的成本。所以，降低整体的推理成本，也是大家共同的期盼。