你好，我是小树。这是我为你写的第 80 封信。每期都会同步更新在微信公众号一颗小树和竹白专栏。现在有 330 位朋友订阅了这封信，也欢迎你。
最近几个月一直在深度参与大模型在协同文档产品中的落地，大概是也是目前国内对大模型应用最拥挤的领域之一，分享一些我的感受和体悟。
大模型在垂直场景中的应用
讲到大模型的应用场景，就不得不提到一个很容易犯的错误：
眼里只有大模型这把锤子，在满世界寻找钉子。
OpenAI 向全世界展示的能力确实足够惊艳，但如果具体到 toB 的业务场景，向让客户买单，首先要讲清楚的就是大模型究竟能为用户解决什么问题。
是希望让 AI 彻底替换人类工作？
还是期望靠 AI 就能够获得竞争优势，打败竞争对手？
还是期望 AI 能够解决所有遇到的问题？
都不是。
无论是传统行业，还是互联网行业，大家需要 AI 的本质需求依然是降本增效。
因此，在 toB 产品的语境下，先想清楚产品为客户提供的核心价值，再去思考当前产品的瓶颈是否可以借助大模型去打破。
toB 产品常见的问题有功能点繁多、使用链路冗长、使用方法复杂难上手等，针对这些具体的场景，有的放矢地去进行改良，会更容易取得效果。
从技术的角度讲，在常规的内容生成的能力之外，如果想要进一步理解用户意图并执行某些操作，通常需要借助大模型来生成结构化的描述，流程可以简要概括为：
用户需求 => 大模型理解 => 结构化返回 => 已有 API 能力
这也是我在看到 GPT 支持 function calling 特性之后非常兴奋的原因。
在垂直场景中，我们更需要的是大模型对用户需求的理解和转化能力，而不需要直接产出最终的结果。
中间往往都需要经过一层结构化的描述作为桥梁连接大模型和现有的应用，这一层具体是什么结构不重要，YAML、JSON 或是 JavaScript 代码都可以，只要两边都可以识别并消费就可以。
大模型的能力边界
在国内，使用生产环境可用的大模型需要接受明显的能力落差，这不只是国内大模型的问题，而是第一梯队的大模型具有明显的能力代差。
以 GPT4 为例，在垂直场景下，仅仅通过 prompt 工程，国内的大模型还远远达不到像 GPT4 一样的可用性。
这意味着在自己的业务场景下，需要对模型进行微调，而微调的关键是优质的训练集和验证集，也就是训练数据。
这一点是目前国内大模型在垂直场景应用的主要瓶颈，换个角度看，也是核心竞争力。
如果基于 GPT4 的能力去尝试验证产品的思路，再切换至国产大模型实现产品链路，会有非常明显的落差感，在产品交互和工程上就需要做出很多的妥协。
同时，和实际使用过大模型能力的用户交流发现，能准确用 prompt 表达自己的需求的门槛并不低，很多时候问题无法被快速解决是因为提的问题本身就不对。
因此所有大模型的应用都会在 prompt 上下功夫，比如模版、自动补全等等能力，以期望用户能够尽可能准确地表达自己的诉求。
这往往会让 prompt 变得复杂，如果一个融合大模型了产品，用户学习 prompt 的成本比学习实现产品功能本身还要高，说明这个产品是不够好的。
当然，这里的前提是需求和能力已经存在，而不是由于大模型的出现创造出了新的需求。
结合我之前提到过的结构化 prompt 的思路，当下更好的方式可能是提供更多的约束条件，让用户明确自己的使用场景和需求，进而提高结果的准确率。
具体的交互形式可以自由选择，最常见的就是表单的方式来收集需求信息。
更明确的需求输入和相对更准确的结果输出，在用户体验上，会比功能边界模糊不清的产品更好。
如果一个功能免费向用户开放，但依然每天的使用人数和留存很低，要么是需求本身有问题，要么是功能本身还远远达不到用户的预期。
最后，讲两个我个人的观点：
- 我认为微软把结合大模型的能力称为 copilot 在当下是非常精准的，AI 只是我们的副驾，掌控飞行决策的依然是我们自己。
- 我不认为大模型会成为 toB 产品的核心能力，它应当是在产品已有的上下文中，打破以往难以突破的某些瓶颈，作锦上添花之用。
如果离开了这个上下文，它的价值会大打折扣。
如果你有不同的见解，或者其他想要交流的，欢迎加我微信 alittletree2021 详聊。
碎碎念
周末尝试了一下北京的费大厨辣椒炒肉，给我的感觉是店家花在营销和口味上的精力是五五开。
从叫号开始，到服务端领我们入座，再到上菜，都在不停强调所谓「全国第一」的品牌价值。
但综合味道、性价比以及服务，还是挺值得一去的。
谢谢你的关注，我们下期再见。👋🏻
往期推荐
你也可以在这里找到我：即刻、Twitter、微信公众号一颗小树。
如果你觉得这篇文章对你有用，欢迎分享给更多好友。