在大型语言模型LLM中使用私有数据

        随着 2023 年大型语言模型的大规模兴起，许多“基于对话”的服务应运而生，使用户能够通过自然对话与数据和其他产品进行交互。我们现在处于一个 LLM 改变我们与各种数据和信息交互方式的时代。筛选无尽的搜索结果或解读复杂的用户界面的日子已经一去不复返了；现在，您只需要自然语言就可以开始探索。

        如果您正在考虑使用大型语言模型（如 OpenAI 的 GPT 模型）创建自己的聊天机器人服务，您可能会好奇如何将您的私人数据编织到 LLM 的“知识库”中。我将在这里解释这一点：

二、训练？

        有两种基本方法可以让 LLM“了解”任何数据，并利用对数据的理解来回答用户的问题。第一种是培训。

        训练是 LLM 最初建立对我们所生活的世界的基础理解的方式。在让 LLM 接触数以百万计的维基百科文章、新闻文章、书籍、在线论坛等内容后，LLM 最终获得了通过预测句子中下一个单词（“token”）来构造有意义句子的能力。在训练过程中，LLM 不仅能够构造复杂的句子和段落，而且还能够明确地使用在训练材料中接触到的知识。这就是为什么尽管 ChatGPT 只在 2021 年中及之前的文本语料库上接受过训练，但它能够透露我们对所生活的世界的基础知识；它可以回答诸如“为什么天空是蓝色的？”和“谁是第一个踏上月球的人？”之类的问题。

        通过 OpenAI 提供的工具，我们可以自己训练模型——不是从头开始，而是“微调”。如果你用一系列问题和答案来训练模型，其中包括使用你的私人数据，那么模型最终会掌握对你的数据的“理解”，并能够在以后的对话中使用它。

        然而，训练通常不是在 LLM 中使用私有数据的解决方案。训练成本高昂，需要精心规划、准备和处理时间才能完成。由于数据变化迅速，LLM 需要始终使用某些数据点的最新版本，因此以足够高的频率训练模型以始终拥有“最新”版本的数据是不切实际的。即使情况如此，也不能保证某些数据点的正确版本确实“覆盖”了 LLM“内存”中的旧版本。

三、及时工程

        相反，人们通常使用一种更直观的解决方案来解决这个问题：快速工程。快速工程不依赖于模型训练，而是向 LLM 提出问题，同时为其提供回答问题所需的上下文（数据）。

        例如，以下三种情况：

        在 LLM 的第一个问题中，左侧用户询问的是微软联合创始人比尔盖茨的出生日期。比尔盖茨是一个非常著名的人物，维基百科上有许多关于他和他的发明的页面和互联网文章。在 OpenAI 设计和执行的训练 GPT 模型的过程中，模型无疑接触过有关比尔盖茨的文章并接受了这些文章的训练。因此，模型“学习”了比尔盖茨的生日并“将其存储在记忆中”，当被问到时，它就能回忆起这些信息，如图所示。

        在中间的第二个问题中，LLM 被问到 Daniel Smith 的出生日期。之前没有用 Daniel Smith 这个 GPT 模型训练过的著名人物，因此 LLM 的“记忆”中不存在 Daniel Smith 或他的生日的“知识”，LLM 便会这样回答。

        然而，在右边的第三个问题中，我们问的是同样的问题，“丹尼尔·史密斯什么时候出生的？”，同时也为 LLM 提供了回答这个问题所需的必要背景（数据）。

        第三个例子称为提示工程。在这种方法中，总是将两条信息作为提示发送给 LLM——问题本身，它要么跟在问题之后，要么后面跟着回答问题所需的一些上下文。虽然两者之间只有一行空行，但工程师通常将这两条信息称为不同的组成部分：系统提示和用户提示。用户提示是用户定义的提示——问题。系统提示是收集的信息，在提示 LLM 时将与用户提示一起作为上下文包含在内。系统提示可以放在用户提示的前面或后面，然后将结果——两者一起——询问 LLM。

四、构建系统提示

        在提示工程中，系统提示是您包含任何您希望 LLM 在回答问题时使用的私人数据的地方。这些私人数据可以是任何内容，包括有关部门应如何处理某些请求的流程的知识、LLM 应如何响应或行为的说明、明确的数据点等。

        但系统提示不能无限大；像 OpenAI 的 GPT 系列这样的 LLM 对其能够理解的文本量有限制。所以很遗憾，你不能直接转储数据库的每条记录并让 LLM 来弄清楚！

        相反，工程师们花费无数的时间开发系统来识别他们认为与特定问题最相关、最有帮助的数据，然后找出这些数据，并准备在系统提示中使用。从Bing AI、Google Search with AI、Power Virtual Agents、Power Apps Copilot等，所有这些系统都使用相同的方法。

        在某种程度上，工程师设计的这种用于精确定位相关数据、准备这些数据并包含在系统提示中的机制是这些服务中的秘密武器和主要价值驱动因素；其余的只是对 LLM 的简单 API 调用！

        因此，要将私有数据与 LLM 结合使用（构建使用私有数据的类似聊天机器人的体验），您必须开发一种机制，该机制将搜索相关数据、读取该数据、准备该数据，并将该数据附加到用户提示符中并附带一些说明，然后通过 API 调用提示 LLM 服务。我们将在下面探讨其中的一部分：

五、数据人性化

        如上所述，必须选择并准备好要包含在 LLM 提示中的数据。虽然 LLM 非常有能力从杂乱无章的数据中解释和破译含义，但将数据转换为更明确有意义的状态才是我们的最佳利益，这样 LLM 才能更好地“理解”数据并将其用于其响应（避免幻觉、错误响应等）。

        举例来说，原始数据有效负载如下所示（JSON 格式）：

{ 
    “jf45ds_first” ： “约翰” ，
    “jf45ds_last” ： “奥康纳” ， “ 
    jf45ds_role” ： 857259845 ，
    “jf45ds_father” ： “ac7f2f16-466f-44a0-834f-4439f36ab41f” ，
    “jf45ds_mother” ： “f865d36f-a59a-4277-8291-90b719d18a7e” ，
    “jf45ds_gen” ： “m” 
}

在上面的数据有效载荷中，我们可以对此做出一些有根据的猜测：

• 它描述的是一个人或联系人的记录。
• 此人的名字是John，姓氏是O'Connor。
• 他们的“角色”就是857259845所代表的。也许这就是他们的职业？安全角色？
• 关于此人父亲的数据位于 ID 为ac7f2f16–466f-44a0–834f-4439f36ab41f的相关记录中。
• 关于此人母亲的数据位于 ID 为f865d36f-a59a-4277–8291–90b719d18a7e的相关记录中。

        虽然我们可以对这些数据做出有根据的猜测，LLM 也可以，但最佳做法是将此有效载荷转换为更清晰易懂的版本。通过使用有关此表的元数据（每列的标题、描述等），我们可以使此记录人性化：

{
    "First Name": "John",
    "Last Name": "O'Connor",
    "Occupation": "General Contractor",
    "Father": {"First Name": "James", "Last Name": "O'Connor"},
    "Mother": {"First Name": "Lynda", "Last Name": "O'Connor"},
    "Gender": "Male"
}

上面的“人性化”负载更容易理解和得出结论。与原始状态相比，LLM 能够从这些数据中提取更多含义。通过将此私人数据记录的人性化版本附加到用户问题中，LLM 现在可以回答有关 John 的问题，例如：

• 约翰的职业是什么？
• 约翰的父亲叫什么名字？
• 约翰的母亲叫什么名字？
• 约翰的性别是什么？

因此，任何 LLM 的提示都会是这样的：

Use the record below to answer the subsequent question:
{
    "First Name": "John",
    "Last Name": "O'Connor",
    "Occupation": "General Contractor",
    "Father": {"First Name": "James", "Last Name": "O'Connor"},
    "Mother": {"First Name": "Lynda", "Last Name": "O'Connor"},
    "Gender": "Male"
}

What is John's occupation?

        在上面的例子中，我们在人性化记录前面提供了明确的说明，并将其添加到用户的问题前面。我们用这个提示 LLM，并收到响应“总承包商”。如果我们只用问题“约翰的职业是什么？”提示 LLM，它就不会知道约翰是谁！

六、我的数据安全吗？

        显然，在上述过程中，我们将私人数据连同问题直接提供给 LLM。这安全吗？有保障吗？

        首先，不要认为您必须针对任何特定问题将所有私有数据提供给 LLM。如前所述，您有责任构建机制，准备私有数据以作为问题的背景提供给 LLM。在此机制内，构建保护措施，防止您不希望暴露给任何第三方系统的特定数据被使用并发送给 LLM。例如，您可以将机制设计为仅从特定表中提取数据而不从其他表中提取数据，从不将某些字段（即社会安全号码）包含在将要公开的有效负载中，等等。在开发这样的自定义系统时，您可以完全控制向 LLM 公开的内容，因为您正在设计执行公开的机制！

        其次，这是许多人共同关心的问题，并且已经由 LLM 管理员解决了。Microsoft 通过其Azure OpenAI 服务提供大型语言模型即服务，并在此处记录了现有的数据隐私和安全保障措施。Microsoft 明确说明了任何暴露的数据：

• 不适用于其他客户。
• OpenAI 无法使用。
• 不用于改进 OpenAI 模型。
• 不用于改进任何 Microsoft 或第三方产品或服务。
• 不会用于自动改进 Azure OpenAI 模型以供您在资源中使用（模型是无状态的，除非您使用训练数据明确微调模型）。

        Microsoft 提供的文档详细介绍了保护您的私人提示（包括您包含的数据）的措施。因此，在安全可靠的平台（如 Microsoft Azure）上向 LLM 公开私人数据是安全的。