深入解析：企业如何通过大型语言模型（LLMs）优化产品与工作流程_大语言模型 企业产品 经营管理

  每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/

现今，几乎每家公司都在寻找利用大型语言模型（LLMs）的方式。即便他们的高管们可能看不到太多的适用性，他们的投资者很可能看到了，因此他们在空白的一页纸前焦虑地试图想出一个点子。将LLMs用于提升内部效率的论点很直接，但描述LLMs如何让产品对客户更有用的方式则困难得多。

我过去一年直接参与到LLMs在现有产品中的有意义应用工作，想要整理一些略显杂乱的笔记。这些笔记没有特定的顺序，主要面向那些在产品开发领域工作的业内人士。

重构你的思维模式

许多业内人士仍在构建他们对LLMs的思维模型，这导致了许多关于LLMs能做什么以及我们应如何使用它们的推理错误。我看到许多人对LLMs持有两种无助的思维模式：

1. LLMs是魔法：任何人类能做的事情，LLM可能也能做得差不多好，而且速度快得多
2. LLMs与强化学习相同：当前的幻觉和准确性问题是由数据集小导致的。准确性问题将通过更大的训练集得到解决，我们可以依赖信心分数来减少不准确性的影响

这两种都是错误的，而且在不同但重要的方面错误。为避免陷入这些思维模型的陷阱，我建议采用以下几个有用的思维模型支柱：

• LLMs可以对任何提示做出合理的回应——LLM会自信地对你编写的任何文本提示提供回应，并将越来越多地对文本加其他媒体形式如图片或视频提供回应
• 你无法知道给定的回应是否准确——LLMs产生意外的结果，称为幻觉，你无法具体知道它们何时是错误的。没有生成的信心分数帮助你推理LLM的特定答案
• 你可以使用评估来估计模型和给定提示集的准确性——你可以使用评估——运行LLM针对已知的提示集，记录响应并评估这些响应——来评估LLM在给定场景下表现良好的可能性
• 你通常可以通过使用更大的模型来提高准确性，但它的成本更高，延迟也更大——例如，GPT-4是比GPT-3.5更大的模型，通常提供更高质量的响应。然而，它的成本显著更高（约贵20倍），速度也显著更慢（慢2-5倍）。然而，每个价格点的质量、成本和延迟都在改善。你应该预期未来五年内，给定成本、延迟或质量点的年度性能会有显著提升（例如，你应该期待在12-24个月内以GPT-3.5的价格和延迟获得GPT-4的质量）
• 模型通常随着它构建的语料库大小的增长而变得更准确——强化学习的准确性随着数据集的增长而可预测地增长。这对LLMs通常也是真的，但不那么可预测。小模型通常表现不如大模型。大模型通常在数据质量更高时表现优于小模型。用特定数据补充大型通用模型称为“微调”，目前还不清楚何时通过微调一个较小的模型会比使用一个较大的模型表现更好。你真正能做的就是根据可用的模型和微调数据集为你的特定用例运行评估
• 即使是最快的LLMs也不是那么快——即使是快速的LLM也可能需要10秒以上才能提供一个合理大小的回应。如果你需要进行多次迭代以完善初始响应，或使用更大的模型，可能需要一两分钟才能完成。这些会变得更快，但今天它们还不快
• 即使是最昂贵的LLMs对于B2B使用来说也不是那么昂贵。即使是最便宜的LLM对于消费者使用来说也不是那么便宜——因为定价是由使用量驱动的，这是一项对于B2B业务来说很容易证明的技术，这些业务有较小的付费使用量。相反，弄清楚你将如何为消费者业务中的显著LLM使用付费而不冒险大幅缩小你的利润率是非常具有挑战性的

这些并不完美，但希望它们为推理出什么会或不会在将LLMs应用到你的产品时起作用提供了一个良好的基础。有了这个基础，现在是时候深入探讨一些更具体的子话题了。

继续前面的内容，我们接着探讨一些具体的应用场景和策略：

改造工作流程

现代软件的工作流程并不是为了最大限度地从LLMs中获益而设计的。这一点并不令人惊讶——它们是在LLMs普及之前构建的——但这确实需要重新思考工作流程设计。

以抵押贷款提供商的软件为例：

1. 用户创建账户。
2. 产品要求用户填写大量数据，以了解用户想要的抵押贷款类型及其资格。
3. 产品要求用户提供支持数据的文件，可能包括一些最近的工资单、银行账户余额等。
4. 内部团队验证用户的数据与用户提供的文件是否匹配。

在这个工作流程中，LLMs仍然可以为企业提供重大价值，你可以通过提高验证文件与用户提供信息匹配的效率来增加效率，但用户本身除了可能更快地验证其申请外，不会看到太多其他好处。

然而，你可以调整工作流程使其更具价值：

1. 用户创建账户。
2. 产品要求用户提供文件。
3. 产品使用LLM从文件中提取数据。
4. 用户验证提取的数据是否正确，并提供一些调整。
5. 内部团队审查用户的调整，并处理任何由规则引擎提出的高风险问题。

这两个产品的技术复杂性基本相同，但用户体验截然不同。内部团队的体验也得到改善。我相信，许多现有产品只有通过重新思考它们的工作流程，才能显著提升用户体验。

检索增强生成（RAG）

模型在给定提示中会考虑的文本的最大“令牌窗口”。令牌窗口的最大大小正在迅速扩展，但更大的令牌窗口评估速度更慢，评估成本更高，所以即使是扩展的令牌窗口也不能解决所有问题。

在固定令牌窗口内导航大型数据集的一个解决方案是检索增强生成（RAG）。举个具体的例子，你可能想要创建一个约会应用，根据个人对问题“你与书籍、电视节目、电影和音乐的关系是什么，它是如何随时间改变的？”的自由形式回答来匹配个人。没有一个令牌窗口足够大，能包括约会应用数据库中每个用户的回应在LLM提示中，但你可以通过筛选位置来找到二十个可能匹配的用户，然后包括这二十个用户的自由形式回答，并在它们之间进行匹配。

这是有道理的，采用一种简单的算法来获取响应的可能组成部分，再结合LLM筛选并打包这些可能的回应成一个实际的回应，这种两阶段结合的方式工作得相当好。

在我看来，人们遇到问题的地方是尝试将RAG作为解决搜索问题的方法，而不是认识到RAG需要作为其实现的一部分的有用搜索。例如，从RAG的高级视角来看，有些人可能认为他们可以用RAG替换他们的搜索技术（如Elasticsearch），但这只有在你的数据集非常小且你可以容忍更高的响应延迟时才成立。

从我的角度看，大多数走捷径的解决方案看起来像是在小数据集上工作，让你假装像搜索相关性这样的事情不重要，而实际上相关性在超出原型阶段时显著影响响应质量（无论它们是字面上的搜索相关性还是更好调整的SQL查询以检索更合适的行）。这创造了一个关于原型将如何转化为生产能力的错误期望，带来所有可预见的后果：低估时间表、生产行为/性能不佳等。

创新的速率

模型性能，即在给定预算（无论是美元还是毫秒）下的响应质量，将继续提高，但如果没有在LLMs的创建或处理中实现重大技术突破，这种提升的速度不会持续。我预期这些突破会发生，但在最初几年后会变得不那么频繁，然后会放慢速度。确定我们处于那个周期的哪个阶段很难，因为仍然有大量的资本涌入这个领域。

除了技术突破外，推动创新的另一个方面是构建越来越大的模型。今天限制模型大小的因素是否是Nvidia GPU的可用性、可合法使用的用于训练模型的更大数据集、训练新模型的资本或财务模型表明，从训练更大模型中得到的折现未来现金流不符合合理的回报期，这一点尚不清楚。我的假设是，所有这些因素都曾经或将来成为LLM创新的限制条件，各个竞争者将根据最相关的约束条件取得进展。（这里有许多引人入胜但边缘的情景可以考虑，例如，想象一下美国政府为了不在LLM训练竞赛中输给不尊重美国版权法的国家而废除版权法的情景。）

可以安全地假设模型性能将继续提高。性能在未来几年显著提高的可能性很大。我认为我们将看到LLMs像摩尔定律那样在几十年内继续取得根本性进步的可能性相对较小，但许多事情可能很容易证明我错了。例如，某一天核聚变将成为主流，并以一种真正重写世界结构的方式改变我们对能源利用的看法，LLM训练成本可能就是其中的一部分。

人在回路中（HITL）

因为你不能依赖LLMs提供正确的回应，也不能为任何给定的回应生成信心分数，你不得不接受潜在的不准确性（在许多情况下这是有意义的，人类有时也会犯错）或保持一个人在回路中（HITL）来验证回应。

如在工作流程部分讨论的那样，许多公司已经有执行验证工作的人员，现在可以转而监督LLM的回应，而不是自己生成回应。在其他情况下，可以调整产品的工作流程，依赖外部用户作为HITL。我怀疑大多数产品将依赖这两种技术以及启发式方法来确定何时需要内部审查。

幻觉和法律责任

如前所述，LLMs经常生成错误但自信的回应。HITL是防止采取错误但自信的回应的设计原则。这是因为它将责任（具体来说是法律责任）从LLM本身转移到今天的具体人员。例如，如果你使用Github Copilot生成导致安全漏洞的一些代码，那么你对那个安全漏洞负责，而不是Github Copilot。今天大规模采用LLM的每一个案例都是在一种模式下进行的，即将响应的责任转移给参与的人。

许多初创企业家梦想着一个与HITL完全不同的世界，LLMs在其中被依赖，但我认为这只适用于可以转移法律责任的情况（例如Github Copilot的例子）或本来就没有法律责任的情况（例如基于他们的个人资料图片生成一首搞笑的诗歌）。

“从零到一”与“从一到N”

人们强烈希望有一个世界，在这个世界中，LLMs取代软件工程师，或者软件工程师转为监督角色而不是编写软件。例如，一位企业家想要建立一个Reddit的复制品，并使用LLM来实现那个实现。有足够的证据表明，今天可以在几周内使用LLM和一些调试技巧从零开始实现一个新产品的想法。

然而，大多数企业家缺乏在有意义数量的用户操作和发展软件的深刻直觉。一些例子包括：

• - 在更改用户界面后保持用户参与需要积极、有意的工作
• - 确保用户数据安全并符合各种隐私合规义务
• - 提供符合SOC2的控制并提供维护这些控制的可审计证据
• - 在支持一组新列的情况下迁移带有客户数据的数据库架构
• - 将查询模式锁定到一组特定的允许模式，这些模式在更高规模下有效

所有这些都是扩展产品的基本组成部分（例如，从“一到N”），LLM根本就不会有效执行这些任务，我怀疑我们是否会看到一个特别可靠的基于LLM的替代品来替代熟练的人类智能。不过，看看人们尝试将基于LLM的自动化推向何种程度以延迟需要聘请专业知识的项目的开始将会很有趣。

版权法

版权问题今天非常不明确，而且在可预见的未来仍将不明确。今天使用LLMs所做的所有工作必须考虑到法律结果的分歧。我的最佳猜测是，我们将看到一个关于LLM生成内容是否可著作权的法律巴尔干化时代，从长远来看，LLMs将被视为任何其他基本技术组件一样，例如，运行拼写检查器不会撤销你对经过拼写检查的文档的著作权。你可以提出各种好的论点，为什么这种观点对于数据被训练上的著作权持有者来说是不公平的，但从长远来看，我只是认为没有其他解释是可行的。

数据处理协议

今天使用LLMs的一个小但引人入思的现实是，许多客户对LLM提供商（如OpenAI、Anthropic等）敏感，因为这些提供商是相对新的公司，他们正在

构建相对新的东西，几乎没有法律先例来为他们降低风险。这意味着将他们添加到你的数据处理协议（DPA）中可能会造成一些摩擦。解决这种摩擦的最明显方法是依赖通过你现有的云供应商（AWS、Azure、GCP等）提供的LLM功能。

供应商可用性

我过去认为这非常重要，但我的感觉是LLM托管已经基本等同于其他云服务（例如，你可以通过AWS获得Anthropic或通过Azure获得OpenAI），而且很少有公司会从过多地担心LLM的可用性中受益。我认为，通过熟悉可扩展性的云供应商直接访问LLM可能是这里的胜出选择。