如今，几乎所有企业都希望把ChatGPT纳入业务场景，但如何不会“竹篮打水一场空”，让技术真正为业务服务呢？实践说明，将ChatGPT的通用能力与企业自有数据需求结合在一起，是最快捷的落地方式！
大模型VS传统机器学习建模
试想一下，如果一家航空公司引入了人工智能技术，智能客服会在任何时间任意地点实时响应客户服务。比如：乘客要问把滑雪板带上飞机要多少钱？按照传统的服务方式，要转好几个流程，等很久，但ChatGPT可以在几秒钟给出答复。再具体一点，如果乘客的问题是，我的航班延误了吗? 我可以升级到头等舱吗? 我明天的班机还在候补名单上吗?传统的服务方式是，系统首先要确定你是谁，你要乘飞机去哪里，预订什么时候的机票?你订了哪家航空公司的机票?没有几分钟的时间，根本搞不定！但是通过OpenAI创新，无论多个性化的服务，都可以提供服务。
值得一提的是，单纯引入ChatGPT通用模型，并不能直接服务于业务，因为企业的个人数据无法与开放数据连接，自然无法应用于具体的业务场景，这也是很多企业基于通用模型建立私域模型的根本原因。所以，行业大模型的难点在于，如何安全地将内部数据提供给ChatGPT。
在传统机器学习建模中，大多数的数据工程都在模型创建阶段，企业需要一个特定的数据训练环境，并通过特征工程来获得正确的模型，一旦训练完成，企业就有了一个一次性的模型，它可以完成手头的任务，但除此之外别无其他用处。并且，大多数针对特定问题的经验和智慧，都是在实际训练时形成的。由于训练通常是批处理的，所以数据流也是批处理的，需要从数据湖、数据仓库或其他面向批处理的系统中输出。
但是对于大语言模型环境中，模型和数据的关系恰恰相反，大模型通常由一个巨大的通用数据集产生，通过深度学习算法进行一次端到端学习来构建，从而产生一个具有广泛能力和可重用性的模型。
这意味着OpenAI和Google提供的服务主要是基于可重用的预训练模型提供功能，而不是要求为每个问题重新创建模型。这就是为什么ChatGPT对这么多开箱即用的东西很有帮助的根本云原因。在这个范例中，当企业想要根据模型构建一些特定的应用时，可以在每个提示符中进行操作，数据工程必须在时间允许范围内进行操作。如此一来，数据流问题也从批处理转向实时处理。
数据流从批处理到实时处理的转换
那么，ChatGPT到底是如何与数据结合，进行工作的呢？ChatGPT，或者真正的GPT模型，基本上是一个非常大的神经网络，通过来自互联网的文本进行训练。也就是说，通过对大量数据的训练，GPT已经能够学会如何像人类一样交谈，并且非常聪明。
ChatGPT最吸引人的一个方面是，它可以记住之前的对话。例如，如果你问它“意大利的首都是什么?”，它会正确地回答“罗马”。如果你接着问“它成为首都有多久了?”，它就能推断出“it”指的是罗马作为首都，并正确地回答为1871年。它是如何做到的呢?
ChatGPT有一个叫做上下文窗口的东西，它就像工作记忆的一种形式。OpenAI的每个模型都有不同的窗口大小，由输入和输出命令的总和限制。当命令数量超过窗口大小时，最旧的命令将从后面删除。
但是回到前文所述的航空业务场景，我们建立智能客服大模型之前，必须收集所有可能与每个客户相关的信息。包括：客户的身份、即将为客户预订的航班、分配给该航班的飞机座位布局、当前航班的载客量、免费升级奖励积分等等，对于大多数公司来说，这些数据分布在不同的系统中，有不同的数据库、数据仓库、SaaS应用程序、队列和文件系统承载，其中大部分数据都不是为了以低延迟进行交互式查询而构建的，而且没有一个数据是为了便于整合而安排的。这些系统之间的通信是点对点的，因此很难获得统一的数据视图。
所以，Kafka事件流是将所有这些系统结合在一起的一个很好的解决方案。通过在每个客户发生变化时访问信息提要，我们可以构建每个客户的统一视图，并且该视图易于以低延迟的方式进行查询。Confluent的连接器可以很容易地从这些孤立的系统中读取数据。由于这些事件流通常包含一些原始信息，因此我们可以将这些数据处理成更精细的视图。流处理可以将单个流转换、过滤和聚合到更适合不同访问模式的视图中，最终将该视图放入关系数据库、键/值存储或文档存储中。
有人可能会说，我们为什么不使用矢量数据库，通过矢量数据库来360度展示数据，这样做不是更简单吗？答案是，对矢量数据库的查询基于嵌入之间的距离检索数据，这不是最容易调试和调优的事情。换句话说，当客户开始与智能客服聊天时，您绝对希望客服知道客户预订的所有航班信息。而不是想让它碰运气，得到一个不确定的回复。因此，在这个案例中，最好只按客户ID查询客户360视图，并将检索到的数据放在第一位。
当然，采取矢量数据库策略，也不是不可以。企业有这个技术能力，通过矢量数据库处理数据，获取正确的信息就变得简单多了。但是，在将提示发送到GPT之前，要对提示本身进行嵌入。然后，使用该嵌入并查询矢量数据库以获取相关信息。该查询的结果成为您添加到提示符前的一组事实，这有助于保持上下文窗口较小，因为它只使用相关信息。
3420 阅读
12163 阅读
3546 阅读
3850 阅读
3867 阅读
3678 阅读
3685 阅读
3665 阅读
3568 阅读
3584 阅读
3563 阅读
3585 阅读
3582 阅读
3407 阅读
3533 阅读
3534 阅读
3525 阅读
3530 阅读
阅读
6188 阅读
7008 阅读
8430 阅读
11861 阅读
11636 阅读
11757 阅读
11942 阅读
11173 阅读
10868 阅读
11064 阅读
11110 阅读
10063 阅读
9809 阅读
9858 阅读
如今，几乎所有企业都希望把ChatGPT纳入业务场景，但如何不会“竹篮打水一场空”，让技术真正为业务服务呢？实践说明，将ChatGPT的通用能力与企业自有数据需求结合在一起，是最快捷的落地方式！
大模型VS传统机器学习建模
试想一下，如果一家航空公司引入了人工智能技术，智能客服会在任何时间任意地点实时响应客户服务。比如：乘客要问把滑雪板带上飞机要多少钱？按照传统的服务方式，要转好几个流程，等很久，但ChatGPT可以在几秒钟给出答复。再具体一点，如果乘客的问题是，我的航班延误了吗? 我可以升级到头等舱吗? 我明天的班机还在候补名单上吗?传统的服务方式是，系统首先要确定你是谁，你要乘飞机去哪里，预订什么时候的机票?你订了哪家航空公司的机票?没有几分钟的时间，根本搞不定！但是通过OpenAI创新，无论多个性化的服务，都可以提供服务。
值得一提的是，单纯引入ChatGPT通用模型，并不能直接服务于业务，因为企业的个人数据无法与开放数据连接，自然无法应用于具体的业务场景，这也是很多企业基于通用模型建立私域模型的根本原因。所以，行业大模型的难点在于，如何安全地将内部数据提供给ChatGPT。
在传统机器学习建模中，大多数的数据工程都在模型创建阶段，企业需要一个特定的数据训练环境，并通过特征工程来获得正确的模型，一旦训练完成，企业就有了一个一次性的模型，它可以完成手头的任务，但除此之外别无其他用处。并且，大多数针对特定问题的经验和智慧，都是在实际训练时形成的。由于训练通常是批处理的，所以数据流也是批处理的，需要从数据湖、数据仓库或其他面向批处理的系统中输出。
但是对于大语言模型环境中，模型和数据的关系恰恰相反，大模型通常由一个巨大的通用数据集产生，通过深度学习算法进行一次端到端学习来构建，从而产生一个具有广泛能力和可重用性的模型。
这意味着OpenAI和Google提供的服务主要是基于可重用的预训练模型提供功能，而不是要求为每个问题重新创建模型。这就是为什么ChatGPT对这么多开箱即用的东西很有帮助的根本云原因。在这个范例中，当企业想要根据模型构建一些特定的应用时，可以在每个提示符中进行操作，数据工程必须在时间允许范围内进行操作。如此一来，数据流问题也从批处理转向实时处理。
数据流从批处理到实时处理的转换
那么，ChatGPT到底是如何与数据结合，进行工作的呢？ChatGPT，或者真正的GPT模型，基本上是一个非常大的神经网络，通过来自互联网的文本进行训练。也就是说，通过对大量数据的训练，GPT已经能够学会如何像人类一样交谈，并且非常聪明。
ChatGPT最吸引人的一个方面是，它可以记住之前的对话。例如，如果你问它“意大利的首都是什么?”，它会正确地回答“罗马”。如果你接着问“它成为首都有多久了?”，它就能推断出“it”指的是罗马作为首都，并正确地回答为1871年。它是如何做到的呢?
ChatGPT有一个叫做上下文窗口的东西，它就像工作记忆的一种形式。OpenAI的每个模型都有不同的窗口大小，由输入和输出命令的总和限制。当命令数量超过窗口大小时，最旧的命令将从后面删除。
但是回到前文所述的航空业务场景，我们建立智能客服大模型之前，必须收集所有可能与每个客户相关的信息。包括：客户的身份、即将为客户预订的航班、分配给该航班的飞机座位布局、当前航班的载客量、免费升级奖励积分等等，对于大多数公司来说，这些数据分布在不同的系统中，有不同的数据库、数据仓库、SaaS应用程序、队列和文件系统承载，其中大部分数据都不是为了以低延迟进行交互式查询而构建的，而且没有一个数据是为了便于整合而安排的。这些系统之间的通信是点对点的，因此很难获得统一的数据视图。
所以，Kafka事件流是将所有这些系统结合在一起的一个很好的解决方案。通过在每个客户发生变化时访问信息提要，我们可以构建每个客户的统一视图，并且该视图易于以低延迟的方式进行查询。Confluent的连接器可以很容易地从这些孤立的系统中读取数据。由于这些事件流通常包含一些原始信息，因此我们可以将这些数据处理成更精细的视图。流处理可以将单个流转换、过滤和聚合到更适合不同访问模式的视图中，最终将该视图放入关系数据库、键/值存储或文档存储中。
有人可能会说，我们为什么不使用矢量数据库，通过矢量数据库来360度展示数据，这样做不是更简单吗？答案是，对矢量数据库的查询基于嵌入之间的距离检索数据，这不是最容易调试和调优的事情。换句话说，当客户开始与智能客服聊天时，您绝对希望客服知道客户预订的所有航班信息。而不是想让它碰运气，得到一个不确定的回复。因此，在这个案例中，最好只按客户ID查询客户360视图，并将检索到的数据放在第一位。
当然，采取矢量数据库策略，也不是不可以。企业有这个技术能力，通过矢量数据库处理数据，获取正确的信息就变得简单多了。但是，在将提示发送到GPT之前，要对提示本身进行嵌入。然后，使用该嵌入并查询矢量数据库以获取相关信息。该查询的结果成为您添加到提示符前的一组事实，这有助于保持上下文窗口较小，因为它只使用相关信息。