LinkedIn：提示词工程行不通，小模型才是突破口
在一篇近期的技术访谈中，LinkedIn 的产品工程副总裁 Erran Berger 分享了他们在内部应用大模型时的一次“方向修正”：
> 一开始，我们尝试通过复杂的提示词工程（prompting）来驱动一个 70 亿参数级别的大模型，结果发现无论怎么调整提示词，效果都难以稳定、可控。
>
> 真正的突破，反而是在我们把模型“变小”的过程中完成的。
LinkedIn 最终选择：
– 先用大模型在内部数据上进行知识蒸馏和策略学习；
– 再将能力压缩到数亿参数级别的小模型上；
– 用精细设计的产品策略和数据标注，获得更稳定、可解释的效果。
—
## 一、为什么「只靠提示词」行不通？
对很多团队来说，接入大模型最直观的方式就是：
– 把现有流程接到一个通用 API 上；
– 在提示词中写上各种指令、规则和例子；
– 期待模型“理解”所有业务约束并照做。
LinkedIn 的实践结果是：
1. **复杂的提示词很难维护**
– 随着产品需求变化，提示词越写越长，团队内部很难清楚知道哪一段还生效、哪一段已经“互相打架”。
– 新人接手时几乎无从下手，测试和回归都变得异常困难。
2. **输出稳定性差**
– 在一些关键场景（推荐、内容安全、职场建议等），模型对同类输入的输出差异很大；
– 提示词稍微调整就会导致整体行为偏移，难以做精细的 A/B 实验和优化。
3. **产品和风控团队缺乏“可控性”**
– 业务团队需要的是：如果模型给出错误建议，能快速定位、修正，而不仅是“再调一次 prompt 试试看”。
—
## 二、小模型 + 精细策略：LinkedIn 的路线
Berger 提到，真正的突破来自于他们转向了一条「小模型 + 精细产品策略」的路线：
1. **用大模型做“老师”，不是直接做“员工”**
– 先利用大模型在内部数据上生成候选策略、打标签、提炼规则；
– 再让工程团队基于这些“经验”设计特征、样本和训练目标。
2. **训练面向具体任务的小模型**
– 把一个庞大的 70 亿参数模型学习到的东西，蒸馏到几亿参数的小模型中；
– 这些小模型专注于非常具体的任务：比如「给某类职位推荐高分候选人」或「判断一段文案是否符合职场规范」。
3. **在产品层面保持可解释和可控**
– 小模型参数更少、结构更简单，更容易做离线评估和线上监控；
– 当策略需要调整时，可以通过增加新特征、改损失函数或更新训练数据来控制行为，而不是一味修改提示词。
—
## 三、为什么小模型更适合很多企业场景？
LinkedIn 的经验对绝大多数企业都有启发：
1. **成本和延迟更友好**
– 小模型在延迟和成本上都明显更有优势，可以在更多请求上使用，而不怕账单爆炸；
– 对于需要实时响应的场景（搜索、推荐、消息流），小模型更容易部署在靠近用户的边缘或自建机房里。
2. **数据隐私和合规更易掌控**
– 把知识压缩到小模型中，一部分场景可以完全在企业内部运行，无需把敏感数据频繁发往外部 API；
– 这对金融、医疗、政务等行业尤为关键。
3. **项目节奏更可控**
– 大模型 API 的能力在不断演进，一旦底层行为大改，所有基于提示词的业务都要重新评估；
– 小模型可以作为“企业自己的控制层”，在底层模型变化时起到缓冲和兼容作用。
—
## 四、对国内团队的几点建议
结合 LinkedIn 的案例，可以提炼出几条适合国内团队的实践建议：
1. **不要把提示词当成长期策略**
– 提示词是很好用的 Quick Start 工具，但不是长期产品工程方案；
– 越早把业务逻辑从 prompt 中抽出来，越能降低未来的维护成本。
2. **尽早规划“小模型层”**
– 可以先用公有云或大厂模型做老师，为内部任务生成高质量训练样本；
– 然后训练一层适配具体业务的小模型，部署在自己的基础设施上。
3. **在业务侧建立“模型治理”意识**
– 不要把模型当成黑箱，而要：
– 定期评估输出分布；
– 为关键场景设定阈值和 fallback 策略；
– 在上线流程中加入模型版本和数据版本管理。
—
## 小结
LinkedIn 的这次经验，某种意义上给“提示词工程”降了一次温：
– Prompting 非常适合原型验证、探索阶段；
– 但要在大规模企业产品中取得稳定、可控的效果，仅靠不断堆砌提示词远远不够；
– 更现实的路径是：
– 用大模型做“研究助手”和“老师”；
– 用小模型承载具体产品策略；
– 用好的工程和治理方法，把模型真正嵌入业务，而不是停留在 demo 层面。
对正在做 AI 产品或打算在业务里引入 AI 的团队来说，LinkedIn 给出的信号很明确：
> 真正的突破，往往不是再换一个更大的模型，而是找到更适合自己业务的模型形态和工程落地方式。