编者按：今年以来，大语言模型（LLM）在消费者(2C)市场崭露头角，同时也吸引了大量企业的关注。但是直接将这些面向消费者的模型引入企业环境，可能会面临一些风险。今天我们为大家带来的这篇文章，作者认为企业环境与消费者环境在数据方面存在着重要的差异，如果不认识到这些差异，面向企业环境的 LLM 项目就可能面临拖延甚至失败的风险。

具体来说，作者指出企业数据相比消费者数据，更多是封闭领域的数据、存量数据，涵盖更多模态，并且受到更严格的访问控制。这些特点可能导致企业环境中的 LLM 应用在检索准确性、内容生成等方面表现不佳。作者建议企业需要做出与消费者环境不同的设计选择，例如进行数据切片、访问控制集成、提示词引导等，以应对企业数据的独特性。

这篇文章为我们深刻剖析了面向企业环境的 LLM 应用面临的数据挑战，并提供了宝贵的应对思路。作者丰富的一手项目经验让这些见解尤为可信与具体。我们也期待后续能看到作者关于如何具体应对这些数据差异的更多建议。相信这篇文章会为开发 To B LLM 的开发者提供良好参考，帮助他们根据企业数据特征专门定制系统设计方案。

以下是译文，enjoy！

作者 | Colin Harman

编译 | 岳扬

欢迎来到 Enterprise LLM Pilot Projects（企业级 LLM 试点项目）的时代！（译者注：这些 Pilot Projects 通过在企业环境中开发和应用 LLM 解决方案来展示其价值，与很多企业为消费者开发 LLM 解决方案的方式和面临的挑战有所不同，因此需要制定合理的策略并注意相关事项。）在 ChatGPT 推出近一年后，很多企业都在谨慎但积极地推进其初期的大语言模型（LLM）项目，旨在展示大模型的价值，并为大规模使用 LLM、扩展应用场景提供指导。

老牌企业内部开发或为老牌企业开发这些大模型解决方案，与初创企业为消费者开发大模型解决方案有着本质区别。 然而，绝大多数有关 LLM 项目的建议，都有意无意地从初创企业面向消费者的角度出发。企业环境有其独特的挑战和风险，如果不考虑这些差异而盲目地遵循初创企业面向消费者的产品建议，可能会导致项目延迟甚至中止。再展开本文之前，首先要了解"enterprise"是什么意思。

一个简单的 provider-user（服务提供商/用户）矩阵，突出显示部分（即⭐标注部分）涉及企业，有企业环境独特的挑战和风险。

请注意，提供给企业用户的产品最终可能会提供给终端消费者用户，例如，提供给金融服务公司供其客户使用的聊天机器人。

目前，LLM 的内容主要偏向于上述 provider-user（服务提供商/用户）矩阵中的consumer-user和startup-provider部分，但这种趋势正在减弱。导致出现这种情况主要是由于受风险投资支持的初创企业和独立开发者追求快速上市和产品点击量。

那么，现有的企业级 LLM 项目所接受的指导从何而来？可能会让你大吃一惊，但确实很少有企业真正完成过 LLM 项目。在这一方面上，很少有像传统咨询公司这样的实体以实际经验为基础进行指导，而是提供重新包装的网络内容。迄今为止，这些企业尚未有足够的时间积累丰富的实践经验，更不用说分享经验了。虽然也有很多例外，但企业内部未来的 LLM 专家大多仍在忙于自己的第一个项目，而能够为其他企业提供指导的初创企业数量仍然有限。

作为一家面向企业的软件供应商，自 2021 年以来，我一直有幸为其他企业开发和实施 LLM 项目（位于上图 provider/user 矩阵中的 Startup/Enterprise 单元），并克服了一系列独特的挑战，成功地完成了多个企业 LLM 项目的整个实施过程。

在本文中，我将分享一些我观察到的企业级 LLM 项目所涉及的数据与 startup/consumer 项目有所不同的一些最重要的方面，以及了解这些差异对于我们的项目来说意味着什么。了解这些差异可以帮助读者更好地理解和评估自己的项目，消除来自 startup/consumer 视角的信息偏见，并更好地适应和应用于企业级的LLM项目。

目录

01 数据类型不同

02 开放领域🌍 VS 封闭领域🚪

2.1实际案例

2.2 对项目的影响

03 数据规模

04 群体数据👪 vs 个体数据🧑

4.1 实际案例

4.2 对项目的影响

05 历史数据💾 vs 实时数据🍎

5.1 实际案例

5.2 对项目的影响

06 多种模态🌈 vs 较少模态🏁

6.1 实际案例

6.2 对项目的影响

07 数据的一致性和规律性 Data Regularity (🎲 vs 🧾)

7.1 实际案例

7.2 对项目的影响

08 访问控制（📁 vs 🗂）

8.1 实际案例

8.2 对项目的影响

09 总结

01 数据类型不同

具体而言，本文将重点关注用于 data-backed applications （译者注：这些应用程序使用数据作为基础，通过对数据的处理、分析和应用来实现其功能和目标）的数据，这些应用程序涵盖了大多数面向企业的 LLM 使用场景。不要再局限于通过总结输入或通过模型记忆来回答问题的 LLM 使用技巧。LLM 对数据进行操作所能产生的价值远远大于与单独与 LLM 进行交互所产生的价值。 为了证明这一点，请想象一个完全由 LLM 相关操作组成的应用程序，该程序能够接收用户输入并将其转化为输出。现在再想象一下，同样的系统也可以访问存储在模型之外的数据：这种能力是可叠加的，价值也是可叠加的。这些数据可以包括任何类型的信息：电子邮件、客户记录、社交图谱、代码、文档、通话记录等等...

数据几乎总是通过信息检索发挥作用——应用程序将查找相关信息，然后使用 LLM 对其进行解释。这种模式通常被称为 RAG（检索增强生成）。那么企业级应用和 startup/consumer 应用之间的数据有何不同，这种不同对于我们项目来说意味着什么呢？

对面向消费者和面向企业环境的LLM应用背后的数据进行定性分析。

这是一幅卡通图，因此相对大小是近似值，而且也有许多例外情况。

02 开放领域🌍 VS 封闭领域🚪

开放领域数据是指涵盖各种主题，不受特定领域或行业限制的数据。这类数据通常在面向消费者的应用程序或面向公众的企业产品中处理。相反，封闭领域数据通常出现在企业级应用程序中。封闭领域数据更加专业，针对特定领域，通常包含开放领域数据中没有的术语、缩略语、概念和关系。

2.1 实际案例：

• 面向企业产品所需数据

  • 制药研发文档 🚪
  • 电子商务产品清单 🌍/🚪
  • 客户支持记录 🌍/🚪
  • 公司政策 🚪
  • 季度收益报告 🌍

• 面向消费者产品所需数据

  • 社交媒体帖子 🌍
  • 个人财务记录 🌍
  • 播客内容记录 🌍/🚪
  • 食谱 🌍
  • 旅行日记 🌍

2.2 对项目的影响

对于 LLM 项目而言，完全忽视封闭领域数据（closed-domain data）可能会使该项目完全失去作用。大多数商业化的大语言模型（LLM）都是基于开放领域数据（open-domain data）进行训练的，如果没有封闭领域数据的帮助，这些语言模型将无法正确解释在它们在训练中没有遇到过的术语和主题。向量搜索中使用的嵌入模型也是如此。例如，许多组织、机构都有大量的首字母缩写词汇，这些缩写词还是某些概念的主要用语，如果没有封闭领域数据的帮助，LLM或检索系统可能无法将这些缩写词与它们所代表的概念联系起来。

然而，如果其实并不需要封闭领域数据，或存在更简单的解决方案，就不要被误导而去进行昂贵的模型再训练！许多看似封闭的领域实际上是开放的。 例如，这些商业化的 LLM 都已经在大量的公共财务数据上进行了训练，并且它们能够直观地理解这些数据，因为尽管金融是一个特殊的领域，但它并不是一个封闭的领域。

💡 Particular Domain ≠ Closed Domain
💡 特定领域 ≠ 封闭领域

即使像医学和法律这样的领域也有大量的公共数据，但其子领域往往表现出封闭领域的特性（金融领域也是如此）。 在进行垂直领域大模型的训练之前，请三思而后行，需要仔细评估是否真正需要这些项目或模型。期待更多关于如何评估领域数据开放性的文章。

对于大多数封闭领域数据，通过查找封闭领域术语的同义词或其定义，并将其纳入检索和生成系统（retrieval and generation systems），可以让项目取得相当大的进展。然而，这需要我们拥有关于同义词、术语关系或定义的结构化信息，而这些信息可能并不容易获得。如果能够获取到这些结构化信息，这种模式通常是最好、最简单的解决方案，我们将在后续的文章中探讨相关技术。

💡 Prefer bespoke systems to bespoke models
💡 定制系统优于定制模型

总结：

• startup/consumer 应用程序偏向于开放领域数据，使它们非常适合使用现成的商业化LLM和嵌入模型进行向量搜索。
• 企业级应用，特别是涉及封闭领域数据的应用程序，通常需要不同的、更复杂的设计才能提供可接受的性能。
• 首先要评估目标领域数据是开放的还是封闭的，如果是封闭的，则要确定是否存在有关该领域的结构化信息（同义词、定义、缩略语等）。

03 数据规模

企业往往比独立开发者拥有更多的数据。很简单就能证明这一观点：企业是员工、客户/消费者和业务流程的集合，这些都会产生数据，而独立开发者只是一个个体。与独立开发者相比，企业开展项目的时间跨度往往更长，在时间跨度内的数据记录密度也更高。 我们将数据分为3个维度：

• 群体数据👪 vs 个体数据🧑
• 历史数据💾 vs 实时数据🍎
• 多种模态🌈 vs 较少模态🏁

企业开发的项目往往占据每个维度的“更多数据”一侧。这一点很重要，因为随着检索数据量的增加，无用的记录被认为是有用的可能性也增加，仅仅因为存在更多的无用记录或“噪声数据”。

💡 More data causes less accurate retrieval
💡 数据越多，检索越不准确

此外，与简单的随机数据相比，某些类型的数据会产生更多的“噪声”。这些“噪声”有时被称为干扰项，我们将看到它们是如何出现在某些子类别中的。

04 群体数据👪 vs 个体数据🧑

企业的每个部门都倾向于处理一组事物：员工、客户、产品、项目。其中每个单元都可能产生几条到数百万条的记录，应用程序可能需要处理这些记录。单个消费者可能是这些单元中的一个，因此代表的数据片段较小。想要了解数据在该维度上的情况，需要了解：它处理的是单个实体还是多个实体？这些实体是否已知，是否可知？

4.1 实际案例

• 面向企业产品所需数据

  • 电子商务产品列表👪
  • 客户支持记录👪
  • 特定客户的客户支持记录🧑
  • 公司的会议记录👪
  • 团队的会议记录🧑
  • 公司的GitHub存储库👪

• 初创企业面向消费者产品所需数据

  • 个人通话记录🧑
  • 个人GitHub存储库🧑

4.2 对项目的影响

大多数企业的数据集往往在该维度的数据量超出了正常值，这时，限制应用程序运行的数据规模至关重要。群体级别的数据很容易超过这个限制。即使您的应用程序包含整个群体的数据（entire population’s data），您也可以通过对目标实体（客户、产品、项目等）进行过滤，在运行时将其转换为单个实体的数据（unit-level data），从而为构建更简单、更准确的检索系统扫清障碍。然而，在某些项目中，如果客户希望提供未经筛选整理的数据转储（例如通过PC硬盘），这应该是不可能的。处理这个问题有几种方法：

• 在确定项目范围时，将重点放在支持数据（supporting data）结构良好且能筛选到个体级别的问题上。
• 要求客户提供更小或更细分的数据集。
• 如果上述方法都不成功，则应与专业领域专家协调，确定可以通过哪些实体（客户、产品、项目等）对数据进行过滤。这可能需要新的数据提取/数据增强和查询理解过程，但对于大型数据集来说可能至关重要。

如果您在上述方法中都没有成功，那么就需要花费大量精力来减少检索系统中的噪声数据。对于startup/consumer和企业级应用程序，都应该始终努力减轻检索系统的负担，只搜索相关的数据片段。对于大型企业数据集来说，该步骤是必不可少的。对数据进行切片的方法将在以后的文章中详细介绍。

05 历史数据💾 vs 实时数据🍎

企业通常喜欢记账，可能是因为出于保证合规的原因必须保留这些记录，也可能是因为他们多年来一直在做同样的工作，积累了大量的文档。显然，这会导致数据规模出现问题，因为它可能引入噪声数据，甚至还可能引入一种更具侵略性的噪声数据：语义高度相似的记录，如果不加以说明，就会成为检索和生成系统的干扰因素。判断这是否会成为严重问题的一种启发式方法是：数据是否涉及长时间跨度的项目。 下面的这些示例都可以看作是长期运行的项目的一部分（产品开发、项目管理、客户支持），而消费者示例则与相对短暂的事件相关。当然也有很多例外情况，但这在企业中会是一个更常见的挑战。

5.1 实际案例：

• 面向企业产品所需数据

  • 客户反馈季度报告💾
  • 项目报告草稿💾
  • 产品规格书💾
  • 季度OKR会议记录💾

• 初创企业面向消费者产品所需数据

  • 食谱🍎
  • 旅行日志🍎
  • 社交媒体帖子🍎

5.2 对项目的影响

如果项目数据存在多个版本、重复条目或副本，就应该从一开始就计划解决这个问题。因为这可能会大大增加检索噪声，并可能导致生成系统接收到矛盾的或不真实的输入。一般而言，最好的做法是：

• 对数据进行筛选，只提供最新的数据给应用程序（如果之前版本的数据记录也之相关，则该方法不可能实现）。
• 如果第一种方法不能成功实施，可以考虑采用类似于处理群体级数据的数据切片方法（译者注：上文提到的）。这种方法可以在生成内容之前帮助获得更相关的检索结果。
• 通过提示语（prompting）、小样本示例（few-shot examples）或微调（fine-tuning），指示生成系统如何处理不同版本、日期和矛盾的记录。 请注意，这种方法将需要提取版本或日期信息，并将其传递给内容生成器。
• 基于日期的排序：最好避免使用此方法，因为系统可能已经有一个排序系统，而blending ranking signals比听起来更困难。（译者注：blending ranking signals是指将多个因素或信号结合起来，来确定数据的顺序。在数据具有多个版本或副本的情况下，这种情况会考虑数据的新鲜度、相关性或质量等因素，以确定其位置。例如，如果一个文档具有多个版本，可以考虑版本的日期、信息的准确性或与用户查询的相关性等因素，对这些因素进行权衡和组合，来确定最终的排序结果。）不过，如果您可以用 relevant/not-relevant filter 来替代或跟进最开始的排序序列，那么通过日期来排序可能会产生效果。（译者注：relevant/not-relevant filter 根据预定义的标准或规则，将数据分为相关和不相关的两个类别，以确定数据是否与特定任务或查询相关。）

最好的办法是坚持使用高质量数据，而不是构建复杂的 passive version control （译者注：其中数据或文档的版本可以在没有主动用户干预的情况下自动跟踪和存储）或多信号重排序系统（multi-signal reranking systems），从而完全避免面临这一挑战。

06 多种模态🌈 vs 较少模态🏁

想一想你的应用程序需要支持多少种离散形式的数据？由个人直接生成的数据通常属于自然语言模态：文本、音频、图像、视频。在这些模态中，甚至可以进一步细分：文本记录可能包含电子邮件、代码、文档、演示文稿、网站... 而这些模态的数据可能还嵌套包含其他形式的数据！然后还有关于个人及其行为，以及其他实体（如产品或事件）的数据，这些数据通常以表格和图表等结构化格式表示。一般情况下，企业能够拥有这些多种模态混合的数据，而个人通常只会有意识地存储和处理这些模态中的一小部分。 想想公司的数据仓库和个人的iCloud之间的区别。在某些企业场景（如联合搜索）中，需要同时处理多种模态，而在其他一些场景中，一次只需要关注一种模态。

6.1 实际案例：

• 面向企业产品所需数据 🌈

  • 项目启动报告
  • 用户点击行为数据
  • CRM数据
  • 产品规格说明书
  • 季度OKR会议记录
  • 物业手册

• 初创企业面向消费者产品所需数据🏁

  • Notion页面
  • 待办事项列表
  • 通话记录
  • 社交媒体帖子

6.2 对项目的影响

从另一个角度看，企业拥有无数细分的数据类别，每个类别中又包含许多条目，而个人消费者的总体类别往往较少，但（正如我们将在下一节看到的）这些类别中的数据种类却更多。企业拥有多种模态的数据实际上是一种优势：不同类型的内容可以帮助我们使用数据规模章节（译者注：本文03节）描述的切片技术来确定检索范围，更重要的是，在解决用户问题的同时，尽可能缩小解决方案的数据范围。 一般来说，只对业务场景所需的内容类型进行操作。尽可能将涉及不同模态的业务场景视为不同的项目，并分别解决，然后再组合成一个适用于所有情况的解决方案。

07 数据的一致性和规律性

Data Regularity (🎲 vs 🧾)

尽管企业可能拥有更多不同模态的内容，但某类内容可能所有内容都相当相似。对于图和表等结构化数据，这是显而易见的（因为它们是由一致的业务流程生成的），但对于报告、演示文稿和通话记录等人工生成的数据，为什么企业中的非结构化数据也会如此一致呢？这是因为企业乃至整个行业在沟通上都有一定的规范和惯例，而消费者之间的沟通更加多样化。 例如，销售电话通常比朋友之间的电话更遵循可靠的流程。

7.1 实际案例：

• 面向企业产品所需数据 🏁

  • 项目启动报告
  • 用户点击行为数据
  • CRM数据
  • 产品规格说明书
  • 季度OKR会议记录
  • 物业手册

• 初创企业面向消费者产品所需数据 🌈

  • 个人电子邮件
  • 通话记录
  • 社交媒体帖子

7.2 对项目的影响

根据项目所面向的用户群体，可以根据数据的特点和常见模态做出更多的假设，以便更好地处理和运用这些数据。如果您正在构建一个供企业内部使用或用于处理受监管文件的产品，那么您对系统需要处理的数据结构是十分确定的。另一方面，如果您正在构建一个能够被不同企业客户使用的解决方案，就可能需要灵活地构建解决方案，以处理不同的数据模态，或者根据每个客户的数据进行调整。LLM 应用程序中可能出现差异的部分几乎包括所有内容：数据接入、检索和内容生成。例如：

• 在处理数据时，如果系统只接触到了有限的示例数据，而没有涵盖到所有可能的数据情况，那么当遇到未知的、陌生的数据时，系统可能无法正确处理，从而导致缺陷的产生。
• 如果文档中的格式与预期不符，分块过程可能无法正确地将文档分割成合适的块，从而导致出现检索缺陷。

对数据了解得越多，构建的系统就越简单可靠。因此，在可以利用这些小技巧的时候就加以利用，在不可以利用的时候就灵活地去设计系统。

08 访问控制（📁 vs 🗂）

在面向消费者和面向企业的应用程序之间，数据最普通的区别就是谁可以访问数据。在面向消费者的应用程序中，这通常是简单明了的：用户可以访问自己的数据，其他人则不能（管理员除外）。然而，在企业环境中，访问控制的情况可能变得非常复杂，因为特定资源可能有多个且频繁更新的访问组，以及不同层次的访问权限。（译者注：在企业环境中，由于组织结构和业务需求的复杂性，访问控制的管理变得更加复杂。企业可能有许多不同的资源，例如文件、数据库、应用程序等，每种资源可能都需要不同的访问权限。为了控制这些资源的访问，企业通常会创建许多访问组，每个组代表一组用户或某一类角色，并分配相应的权限。这些访问组可能会频繁更新，以适应组织架构的变化和业务需求的变化。此外，企业环境中的访问权限通常具有不同的层次。不同的用户或角色根据其工作岗位可能需要不同级别的访问权限。）公司员工通常需要访问某些数据来完成工作，但如果他们离开该岗位，访问权限也需要立即撤销，这种操作十分必要。

8.1 实际案例：

• 面向企业产品所需数据
  • 产品线文档 🗂
  • 人事记录 🗂
  • 用户数据
  • 通过经纪人或经纪公司进行的加密货币交易 📁
  • 旅客在航空公司中的常旅客会员账号Frequent flyer account 📁

8.2 对项目的影响

遗憾但不可避免的是，要想正确实施访问控制，就无法避免大量的工程设计。 您能为项目做的最好的事情，就是及早认识到这一点，并确保您拥有必要的工程专业知识和客户数据访问权限来解决这个问题。如果适用的话，一定要考虑与数据源的身份提供者进行集成，并寻找能够帮助进行集成的框架或工具。（译者注：在许多面向企业的应用程序中，数据源通常会有一个身份提供者，用于管理用户的身份验证和访问控制。身份提供者可以是一个单独的身份验证系统，也可以是一个集成的身份验证服务，例如OAuth或LDAP。）不过，关于系统如何处理不同的用户组，仍有许多决策需要做出，例如：在涉及检索的系统中，是在检索之前还是之后对结果进行过滤（这个决策有时称为 early- vs late-binding ）？

09 总结

希望这篇文章能够在你开始进行企业级的机器学习项目时提供一些警示和建议，以便你能够避免一些常见的问题，从而能够更好地应对挑战，并取得更好的结果。

END

本文经原作者授权，由Baihai IDP编译。如需转载译文，请联系获取授权。

原文链接：

https://colinharman.substack.com/p/with-llms-enterprise-is-different