2023年，一系列公司开始禁止或严格限制使用像ChatGPT这样的LLM服务，原因是担心可能泄露机密数据。这些公司包括三星、摩根大通、亚马逊、美国银行、花旗银行、德意志银行、富国银行和高盛等。这些金融和科技巨头的行动表明，它们对LLM泄露机密和敏感信息的潜在风险十分担忧。但这个风险有多严重？作为一名LLM应用的开发者，你是否也需要关注这一问题？
在第1章关于Tay的故事中，微软的聊天机器人遭到黑客攻击。尽管损失严重，但由于Tay并未接触到大量敏感数据，她能够泄露的信息有限。然而，当LLM与现实世界数据交互时，可能会引发意外的信息泄露风险。例如，有些员工无意间将敏感的商业数据输入ChatGPT，而这些数据随后被整合到系统的训练库中，从而可能被其他用户发现。
本章将深入探讨LLM获取数据的各种方式。我们将分析三种主要的知识获取方法以及你的LLM拥有这些访问权限所带来的风险。在此过程中，我们将尝试回答“你的LLM会知道得太多吗？”这一问题，并讨论如何降低你的应用程序泄露敏感、隐私或机密数据的风险。
真实案例
让我们通过两个真实案例来探讨提示词注入和数据处理失当带来的实际影响。首先，我们看一个与Tay类似的聊天机器人案例，但由于机器人能访问的数据及其披露方式不同，造成的损害更为严重。然后，我们再看一个涉及AI助手（copilot）的案例，该案例使其所属公司面临更高的法律和声誉风险。
Lee Luda 案例
首尔初创公司Scatter Lab因不负责任地处理个人数据，面临严重的法律和声誉后果。公司运营一款名为**《爱情科学》（Science of Love）的热门应用，通过分析用户的短信，帮助其评估与伴侣的匹配度。该服务收集了来自60万用户的94亿条对话。随后，公司推出了一款名为Lee Luda**的AI聊天机器人，其宣传点是“一个比人类更受欢迎的对话伙伴”。然而，Lee Luda未经适当数据清理，直接使用了《爱情科学》的庞大数据集作为训练基础。
结果，Lee Luda不仅表现出一些类似Tay的有害行为，更令人担忧的是，它开始泄露敏感数据，例如用户的姓名、私人昵称和家庭地址。
南韩个人信息保护委员会对Scatter Lab罚款1.033亿韩元（约合9.3万美元），因为该公司未能获得用户的适当许可。这是韩国首次因数据管理不当对AI技术公司进行处罚。
事件影响
-
敏感数据的公开暴露
- 用户隐私受到威胁，泄露的信息包括姓名、住址、恋爱状态和医疗信息等。
-
经济处罚
- Scatter Lab因未妥善管理用户数据而被处以高额罚款。
-
声誉受损
- 事件显著损害了Scatter Lab的声誉，主流媒体的广泛报道和Google Play上针对《爱情科学》应用的大量差评进一步加剧了这一影响。
-
服务停止
- 涉事的聊天机器人服务Lee Luda在事件后被关闭，公司扩展计划也因此中断。
可学到的经验与教训
-
严格的数据隐私协议
- 该事件突显了需要强有力的数据隐私协议，以确保用户数据被小心处理并符合法律框架。
-
用户同意
- 在收集和处理用户数据之前，必须获得明确且知情的用户同意，这是法律要求，也是道德数据实践的基石。
-
年龄验证机制
- 本案的损害加剧是因为部分数据来自未成年人。根据许多法规，涉及未成年人的数据挖掘需要特别谨慎。
-
公众透明度
- 公司必须向用户明确说明数据的使用方式，并有效沟通相关风险。
-
监控与审计
- 对数据处理实践进行定期监控和审计，有助于及时发现和纠正隐私问题，降低敏感数据暴露的风险。
总结与启示
这一案例凸显了在利用用户数据提升LLM能力与确保用户隐私和数据完整性之间保持微妙平衡的重要性。它为开发者提供了重要的教训，强调了加强隐私保护和负责任地使用数据的必要性。
GitHub Copilot与OpenAI Codex
2023年的一件重大事件凸显了LLM引发的敏感数据泄露风险，这次事件涉及GitHub Copilot，这是一款由OpenAI Codex模型驱动的工具。GitHub设计Copilot旨在通过自动补全代码来帮助开发者实现高效开发，这一功能是通过训练大量来自GitHub公共代码库的代码实现的。然而，这款工具很快陷入了一系列法律和伦理挑战。一些开发者发现，Copilot竟然建议使用了他们受版权保护的代码片段，尽管这些原始代码的许可协议限制了此类使用。该事件引发了针对GitHub、微软和OpenAI的诉讼，开发者指控其违反了版权、合同和隐私相关规定。
此案在美国地方法院展开审理。开发者的论点主要基于两项主张：Codex重现了他们代码的部分内容，违反了软件许可条款；并且，在未附带必要的版权管理信息的情况下重现了受版权保护的代码，违反了《数字千年版权法案》（DMCA）。法官驳回了撤销这两项指控的动议，使诉讼得以继续。尽管法院驳回了部分指控，但案件的核心围绕Codex和Copilot重现代码行为可能侵犯开发者知识产权的争议展开。
截至本文撰写时，该诉讼仍在进行中，其最终影响可能需要一段时间才能显现。这起诉讼揭示了LLM领域的一个关键问题——无意中泄露敏感数据的风险。这一事件的影响超越了直接相关方，在整个科技行业引发了关于LLM访问和学习公共数据的法律与伦理意义的讨论。
启示与应用
尽管案件中提出的知识产权问题尚未完全解决，但以下几点经验可以借鉴到您的项目中：
-
数据治理
- 该事件强调了建立健全数据治理框架的重要性，尤其是在使用公共或开源数据时，需要明确的数据使用指南。
-
法律清晰性
- 此案揭示了LLM与现实数据交互时存在的法律灰色地带，表明需要更明确的法律和法规界定数据使用和版权遵守的边界。
-
伦理参与
- 除了法律合规外，LLM使用数据的伦理维度也需要开发者和组织采取负责任的态度，尊重开源贡献和许可协议的字面和精神。
-
用户意识
- 此事件还凸显了提升用户意识的重要性，让用户了解公司可能如何使用他们的数据，同时表明需要更透明的披露政策。
现实案例的警示
这场诉讼的进展为我们提供了一个真实世界的案例，展示了LLM应用领域法律、伦理与技术因素之间的复杂交织关系。它预示了随着LLM发展并与多样化数据源交互而可能出现的挑战，特别是在敏感数据泄露风险方面。
知识获取方法
LLM（大语言模型）应用的能力会随着其访问的数据量的增加而增长。与此同时，与这些数据相关的风险也会增加。如果您的LLM接触到某种特定类型的数据，您就需要管理泄露的风险。让我们来看三种LLM常见的知识获取方式。
LLM知识库的核心是其模型训练。这个过程从基础模型训练开始，LLM会沉浸在庞大的数据集中，获得对语言、上下文以及世界知识的广泛理解。然后，通过模型微调，LLM可以在更专业的任务或特定领域中进行优化，使用针对性的数据库进行适应。
LLM的学习方式是独特的，通常发生在不频繁的训练阶段，这意味着它们的信息往往是过时的，这限制了它们在需要最新知识的应用中的使用。这就是检索增强生成（RAG）发挥作用的地方。LLM可以进入广阔的公共网络领域，获取实时更新，或者深入到结构化或非结构化的数据库中。通过API与外部系统、数据库或在线平台连接，LLM可以进一步扩大其知识范围，通过外部数据丰富其响应。
某些应用甚至可以更进一步。用户的互动，如查询、对话和反馈，使LLM能够持续获取新的知识。处理这些输入可以帮助LLM扩大其理解，每一次互动都能优化其能力，提供越来越个性化和相关的响应。
这三种类别——训练、检索增强生成和用户互动——各自都有独特之处，这些特点可能会显著影响您LLM应用的安全环境。虽然它们作为知识获取的通道，但也会带来潜在的漏洞和挑战，需要谨慎考虑。在本章接下来的内容中，我们将深入探讨每一种方法，揭示其中的关键安全隐患。通过这次探索，我们希望能够为您提供全面的理解，帮助您识别潜在的风险，并采取相应的措施进行规避。
模型训练
训练是开发和完善LLM（大语言模型）中的一个关键步骤。它包括两个不同的阶段：创建基础模型及其随后的微调。基础模型训练建立了广泛的语言和上下文理解，而微调则将这种通用知识精炼为特定任务或领域所需的知识。在本节中，我们将探讨这两个阶段的细节，并重点介绍它们各自的方法论。随后，我们将扩展每个步骤中固有的关键安全隐患，帮助您了解潜在的漏洞，并提供防范这些风险的最佳实践。
基础模型训练
基础模型训练是构建LLM的初始步骤。在这个阶段，模型会在庞大且多样化的数据集上进行训练，这些数据集通常包括各种主题、语言和文本格式。其目标是使模型具备对语言、上下文关系和一般世界知识的广泛理解。这一基础训练为LLM生成连贯的、具有上下文相关性和信息性的响应打下了基础，就像一个人在专注于某个特定领域之前对世界的基本理解。
从本质上讲，基础模型训练LLM的过程是一项复杂的模式识别任务。训练过程中，利用先进的算法分析大量数据集，识别单词之间的关系，理解上下文，并根据这种理解生成连贯的响应。让我们来看一下其中涉及的步骤：
- 模式识别
训练的基础是向模型提供大量的文本数据——有时是数十亿个标记。当模型处理这些数据时，它开始学会识别模式。例如，它开始理解“apple”这个词可能与“fruit”（水果）、“tree”（树）、“pie”（派）或“technology”（技术）相关，具体取决于上下文。 - 上下文理解
接下来，模型开始根据上下文辨别单词使用的细微差异。它学会了，例如，“Apple’s growth”这一短语可以指代科技公司扩展，也可以指代树上水果的生长，这取决于周围的词汇和短语。训练算法会调整内部参数，通常是数十亿个，以捕捉这些复杂的上下文关系。 - 响应生成
通过多次训练迭代，模型逐步发展出生成响应的能力，不断精炼其对语言和上下文的理解。与人类记忆回忆不同，模型分析输入，将其与学到的模式匹配，理解上下文，并根据训练数据构建响应。训练数据的多样性和广度至关重要，因为它们直接影响模型生成准确且具有上下文相关性的响应的能力。
基础模型的安全考虑
前面的步骤表明，训练定制的基础模型可能既复杂又昂贵。这也是为什么如今大多数项目都从现有的基础模型开始。起点可能是通过SaaS（软件即服务）产品访问的专有模型，例如OpenAI的GPT系列，或者是托管在私有服务器上的开源模型，例如Meta的Llama。在这两种情况下，基础模型的创建者都希望已经做了一些工作，以确保个人身份信息（PII）等内容不进入训练基础中，尽管这并不总是能保证。选择基础模型时要小心！即使出于最好的意图，这些基础模型也常常会积累一些在某些场景中不适当的敏感信息。以下是一些可能存在问题的信息类型示例，需要注意：
- 其他人的知识产权，例如受版权保护的文本
- 与武器、毒品或其他敏感话题相关的危险或非法信息
- 可能在特定情境或讨论中不合适的文化或宗教文本
如果您决定训练自己的基础模型，您可以对系统的许多方面实现更高的控制。这种控制可能是非常有利的。然而，您现在承担了使用模型中每一部分训练数据的责任。确保数据不包含敏感信息可能会成为一项重大挑战。我们将在本章稍后讨论更多相关内容。
模型微调
模型微调是在基础模型训练后进行的可选步骤，旨在将通用模型专门化以适应特定任务或领域。在微调过程中，您将使用一个较小的、特定领域的数据集来调整模型的权重。这样，您可以优化其响应，以便在目标应用中表现出色。这个过程显著提升了模型的性能，使其在特定应用场景中更加相关和准确。用于微调的专门化数据使得模型能够将基础训练阶段获得的通用理解，转化为适应任务的细微差异和具体要求，从而提供更加量身定制和有效的解决方案。
从本质上讲，微调解决了机器学习中的一个基本挑战：虽然基础模型拥有广泛的知识，但在处理特定任务时，往往缺乏深度和具体性。例如，尽管一个通用模型可能已经使用了一些医学信息进行训练，但它生成的响应可能与医学专业人员期望的精确度不符。微调通过将基础模型的通用知识适应特定领域或任务，弥补了这一差距。
训练风险
无论是从零开始训练基础模型，还是微调现有模型，您都必须仔细考虑将敏感数据纳入训练集的风险。任何用于训练的数据都可能成为长期记忆。即使您采取措施使模型符合要求并防止不当的泄露，模型仍然可能将这些信息泄露给第三方。
以下是一些在制定训练数据集时需要考虑的风险：
- 直接数据泄漏
如果在训练过程中暴露模型于个人身份信息（PII）或机密信息，模型可能会生成不小心泄露这些数据的输出。 - 推理攻击
攻击者可能利用提示注入技术从模型中提取敏感数据。 - 合规和监管违规
使用包含PII的数据集进行模型训练，尤其是在没有用户同意的情况下，可能会违反数据保护法规，如《健康保险携带与责任法案》（HIPAA）、《通用数据保护条例》（GDPR）或《加利福尼亚消费者隐私法案》（CCPA）。这可能导致巨额罚款、法律后果以及声誉损失。 - 公众信任丧失
如果公众得知某公司使用PII或机密数据训练其模型，并且可能泄露这些数据，该公司可能会面临重大反响和信任丧失。 - 数据匿名化失败
即使在训练前对PII进行“匿名化”，模型仍可能识别出能够使数据去匿名化的模式，特别是当其将输入与其他公开可用的数据集进行关联时。 - 成为攻击目标的吸引力增加
如果恶意行为者认为模型包含机密信息或PII，他们可能更有动机对其发起复杂的攻击，旨在提取有价值的数据。 - 模型回滚与财务影响
如果团队后来发现模型曾使用PII进行训练，可能需要回滚到早期版本，导致财务影响和项目延误。
鉴于这些重大风险，确保训练数据经过彻底清洗至关重要。此外，定期审计、严格的数据审查和先进的差分隐私技术可以帮助减轻潜在风险。
避免将PII纳入训练数据
防止将PII纳入训练数据集可能是一个巨大的实际挑战。单一技术可能不足以解决这一问题。您可能需要采用多层防御机制。以下是一些值得考虑的策略：
- 数据匿名化
使用通用值替换PII，或用化名替换名称，确保数据不再识别特定个体。 - 数据聚合
将个别数据点组合成更大的数据集，以便LLM无法区分单独的条目。 - 定期审计
审查并清洗训练数据集，以确保没有PII漏网。 - 数据掩码
使用技术隐藏原始数据，用结构上类似于原始数据的修改内容替代，例如将“John Doe”转换为“Xxxx Xxx”。掩码数据是一个清洗后的版本，保留本质，但模糊了敏感细节。 - 使用合成数据
生成不基于实际用户信息的数据，但保持与原始数据集相同的统计特性。 - 限制数据收集
仅收集任务所需的最少数据。如果某些信息不必要，就不收集。 - 自动扫描
使用工具扫描并标记数据集中的潜在PII。 - 差分隐私
实施添加噪声的技术，确保任何单一数据点（或个人数据）不会显著影响整体数据集，并且攻击者无法逆向工程数据。 - 令牌化
用无敏感意义的等效项替换敏感数据元素。这些令牌充当原始数据的占位符，然后安全地存储在单独的地方或数据保险库中。
通过采用这些策略，组织可以大幅降低将PII纳入训练数据集的风险，确保合规，并维持用户和利益相关者的信任。
检索增强生成（RAG）
RAG（检索增强生成）是LLM（大语言模型）数据获取和响应生成中的一种变革性方法。与传统LLM仅依赖于通过训练获得的大量内部知识库不同，RAG首先从外部数据集中检索相关的文档片段或段落。然后，LLM利用这些段落来指导其生成的响应。这种两步法——首先检索相关信息，再基于这些信息生成回答——使模型能够引入实时或更新的信息，而这些信息并不包含在其原始训练数据中。
RAG是语言模型处理大量实时数据能力的重大进步。无论其训练数据多么广泛，传统LLM本质上都受到其最后训练截止点的限制，这使得它们对于特定主题或实时事件可能显得过时。RAG通过允许LLM无缝访问并整合外部的最新信息，解决了这一局限性。这种动态能力提升了模型输出的准确性和相关性，使LLM在快速变化的领域中更加多才多艺和适应性强。将检索与生成过程融合，预示着更有信息量、更具上下文感知的对话式AI的新前沿。
然而，将LLM与大型实时数据存储连接起来也带来了安全隐患的潘多拉盒子。一个问题是间接提示注入，我们在第4章中讨论过。提示注入攻击可能发生在将不可信数据作为RAG提示的一部分传递给LLM时。然而，在本章中，我们将重点讨论与敏感数据泄露相关的风险，以帮助回答“您的LLM能知道太多吗？”这个问题。
让我们回顾一下RAG系统常见的访问大型数据存储的方式。通过了解您的LLM可能如何访问这些知识库，我们可以更好地规划安全风险和相关的考虑因素。在这里，我们将探讨如何直接从网络访问数据以及如何访问数据库。
直接网页访问
为您的LLM提供与网络的直接连接可以成为一个强大的机制，用于获取实时或更新的信息，来增强其知识库。网络连接使得模型能够获取最新的数据，跟进不断发展的话题，并提供更准确、及时的响应。通过与网络互动，LLM能够弥补其最后一次训练截止点与当前时刻之间的差距，确保其信息相关且及时。这一功能显著提升了LLM在动态或快速变化领域中的实用性。
让我们来看几种访问网页的模式：
抓取特定网址
直接访问预定的URL以提取其内容是一种特别有用的方法，尤其是当您知道希望LLM访问的确切信息来源时。这种技术适用于多种情况，例如从金融新闻网站提取每日股价，从特定新闻源或博客获取定期更新，或从电商网站获取产品详情或评论。
这种用例的优势有：
- 精准
直接定位所需的网页，消除了来自不相关来源的噪音。 - 高效
由于URL是预定的，您可以优化抓取过程，使其适应该页面的特定结构和内容。 - 可靠
持续访问一个或一组已知的URL可以随着时间推移提供更稳定的结果。
但也有一些关键挑战：
- 页面结构变化
网页经常进行重新设计或结构调整。如果特定URL的内容结构发生变化，抓取机制可能需要调整。 - 访问限制
一些网站使用验证码、访问频率限制或robots.txt限制来阻止或限制自动访问。 - 法律或伦理挑战
如果您没有网页内容的所有权，您需要考虑网页所有者是否会对您在系统中使用这些数据表示反对。根据需要，考虑版权和其他许可条款。
使用搜索引擎后跟随内容抓取
在这种方法中，您向像Google或Bing这样的搜索引擎发出查询，以根据特定的关键字或话题找到相关内容，然后从一个或多个排名靠前的搜索结果中抓取内容。这种方法最适用于如下用例：通过抓取顶级新闻文章或博客来研究当前公共情绪，检索特定主题的近期学术出版物或文章，通过分析行业特定关键词的搜索结果来了解市场趋势。
这种用例的优势有：
- 相关性
搜索引擎根据相关性对内容进行排名，确保LLM访问到高质量和相关的信息。 - 时效性
搜索引擎不断索引新的内容，使它们成为获取特定话题最新信息的宝贵资源。 - 多样性
通过访问多个排名靠前的结果，LLM可以从不同的角度获得更全面的主题理解。
挑战包括：
- 间接提示注入
如第4章所述，恶意提示可能不会直接来自用户。它们可能悄悄地嵌入到RAG系统的提示数据中。在这种情况下，攻击者可能将恶意数据嵌入网页中，导致在网页解析并将数据传递给LLM时发生间接提示注入攻击。 - 动态结果
对特定查询的搜索结果可能随时间变化，导致LLM访问的内容存在变动。 - 搜索限制
搜索引擎可能会有请求限制，尤其是对于自动化查询，这可能会限制搜索次数。 - 抓取深度
决定抓取多少个排名靠前的结果会影响信息的质量和广度。抓取过多可能会稀释相关性，抓取过少可能会错过有价值的观点。 - 法律和伦理问题
在抓取内容时，遵守搜索引擎的服务条款，并考虑版权和许可条款非常重要。
示例风险
直接网页访问或搜索引擎可能带来与无意中获取或泄露个人身份信息（PII）和其他敏感信息相关的各种风险。以下是一些可能发生的例子：
评论区和论坛
模型可能抓取来自知名来源的技术文章或新闻，但在此过程中，它也可能无意中抓取附加在文章上的评论或论坛帖子。这些部分通常包含个人轶事、电子邮件地址或其他可识别的细节。例如，用户可能向LLM请求某一健康话题的近期讨论，模型可能从一个健康论坛中提取数据，其中用户分享了个人故事、姓名、年龄甚至具体的医疗信息。
用户资料
一些网站在文章或帖子末尾包括用户资料或作者简介。抓取此类网站时，可能会无意中收集这些资料中的个人细节或联系方式。例如，LLM从一个博客平台获取条目时，也可能抓取作者的简介，包括其全名、位置、工作地点和电子邮件地址。
网页中的隐藏数据
一些网页在后台存储元数据或隐藏信息。虽然这些数据对人类观看者不可见，但具有网页访问权限的LLM可能仍然会访问并处理这些数据。例如，LLM抓取一个公司网站时，可能会无意中访问嵌入的元数据，其中包含内部文档路径，甚至是机密的修订评论。
不准确或宽泛的搜索查询
使用搜索引擎时，如果查询过于宽泛或定义不准确，模型可能会抓取包含敏感信息的不相关内容。例如，一个查询“John Doe的演讲”本意是查找一位知名人物的公开演讲，但也可能返回一个名为John Doe的博客，里面共享了个人电话号码作为联系方式。
广告和赞助内容
网页抓取可能无意间从广告或赞助帖子中收集数据，这些数据有时包含基于先前用户行为或其他目标标准的个性化内容。例如，LLM抓取网页新闻时，可能还会抓取一则广告，其中写道“[地点]居民的特别优惠”，从而泄露位置数据。
动态内容和弹出窗口
许多网站具有基于用户互动、位置或时间变化的动态内容。弹出调查、聊天机器人或反馈表单可能包含要求个人信息的提示。例如，在抓取一个服务提供商网页时，LLM可能抓取到一个弹出内容：“你来自[城市]吗？回答这个调查！”，这可能会泄露地理位置数据。
文档元数据和属性
在访问在线文档或文件时，相关的元数据可能包含作者姓名、编辑历史或内部评论。例如，LLM可能抓取一家公司公开的财务报告，但同时其属性可能显示“最后编辑者：[员工姓名]，来自[部门]”，从而泄露内部公司信息。
访问数据库
这一模式涉及LLM从结构化或非结构化数据库中检索存储的数据。这种方法可以包括查询传统数据库以获取特定数据，或访问向量数据库以获取嵌入数据。通过利用数据库，LLM能够提供精确且数据驱动的响应，在需要实时或历史数据检索的场景中变得更加有价值。知识获取的这种方式使得LLM能够在数据丰富的环境中操作，并根据数据库中可用的数据提供高度准确、上下文感知且个性化的响应。
关系型数据库
自20世纪70年代末以来，关系型数据库一直是事实上的标准，支撑着无数行业和应用的基础设施。它们通过使用表格来组织和访问数据，并通过已建立的关系来确保数据完整性，彻底改变了开发人员处理数据的方式。关系型数据库将数据管理的结构化方法与SQL（结构化查询语言）用于数据操作的能力相结合，使组织能够高效且精确地处理复杂数据集。虽然现代技术的进步带来了新的数据库类型，但关系型数据库的稳健性仍然使它们成为许多企业的可信选择。
为LLM提供对企业内部庞大数据存储的访问非常强大，因此也极具吸引力。其优势显而易见：可以即时访问大量的历史和实时数据，从而提供更丰富、更有信息量的响应，能够根据特定的组织需求和背景量身定制。LLM可以提供深刻的见解、回答复杂查询，甚至自动化那些原本需要人类数小时才能完成的任务。它可以改变用户体验，为广泛的数据存储库与终端用户（无论是员工、利益相关者还是客户）之间提供无缝的接口。然而，伴随着这种巨大能力的是同样巨大的责任，需要保护敏感信息，并确保数据访问始终安全且合乎道德地管理。让我们来看看在LLM应用中访问数据库时的风险领域：
复杂关系加大泄露风险
关系型数据库通过关系将结构化数据集链接起来。虽然一个表看起来可能是无害的，但它与另一个表的关联可能无意中暴露敏感模式。例如，一个看似无害的产品ID列表，当与特定的客户交易记录关联时，可能变得敏感。
无意的查询
命令的误解或措辞不当的问题可能导致LLM检索到开发者并不希望用户访问的数据。想象一个场景，用户提一个看似随意的问题，结果不小心展示出详细的记录，暴露了超出请求范围的信息。
权限疏忽
关系型数据库有复杂的权限系统。在集成过程中，可能由于疏忽或配置错误，LLM被授予了不必要的广泛访问权限，从而打开了原本应该受限的数据。
无意的数据推断
LLM能够识别模式。在多次交互过程中，LLM可能会将看似不敏感的数据汇总在一起，从而得出无意中的敏感见解。例如，单个购买记录可能不会泄露太多信息，但模式可能暗示公司即将发布的新产品或战略转变。
审计和问责的挑战
传统的关系型数据库通常提供强大的审计跟踪，将操作与特定用户关联。通过LLM作为中介时，确保每个查询和数据获取过程都是可追溯的至关重要。如果没有清晰的审计轨迹，追踪数据泄露的来源或理解意外行为将变得复杂。
总结
将LLM与受信任的关系型数据库集成，可以提升功能性和性能。然而，重要的是在利用这些集成时要意识到相关的风险。实施严格的保护措施和监督可以有效地利用LLM的能力，同时确保数据完整性和安全性。
向量数据库
向量数据库代表了我们在处理和理解数据方式上的重要进化，特别是在机器学习和AI操作的背景下。与将数据组织成行和列的关系型数据库不同，向量数据库将数据存储为高维向量。这些向量是数字数组，有效地捕捉了对象或数据点的特征或属性的本质。这种结构在执行基于相似性或邻近度的操作时具有优势，尤其是在向量空间中进行相似性搜索时非常有用。
高维向量擅长处理复杂的操作，如最近邻搜索，这对许多AI应用至关重要。这些搜索使数据库能够快速找到与给定查询点在向量空间中最接近的数据点，从而促进依赖于查找最相似项目或模式的操作。通过将数据管理为向量——本质上是编码数据项信息的数学表示——向量数据库能够高效而准确地检索和比较数据，从而在庞大的数据集中进行有效的相似性搜索。
通过RAG模式将LLM与向量数据库集成，可以极大地增强其能力。通过将模型与这些数据库连接，您可以利用基于相似性的搜索功能，提供更加符合上下文的响应，使得模型能够更精准地理解细化的用户查询。模型可以迅速定位并利用与查询意图相符的嵌入数据，从而提供准确且相关的结果。毫无疑问，这具有革命性的意义。以下是结合向量数据库与RAG模式可以产生卓越成果的一些示例：
问答系统
用户期望在回答问题时获得精确且准确的答案。RAG系统可以从向量数据库中检索相关文档或数据片段，以为LLM的回答提供依据，从而使得答案比仅依赖模型知识生成的答案更准确、详细。
内容推荐
对于需要个性化内容推荐的平台——例如新闻聚合平台、流媒体服务和电子商务网站——RAG可以通过从向量数据库中检索与用户个人资料或先前互动内容高度匹配的内容，来增强推荐引擎，从而提高用户参与度和满意度。
学术研究和总结
RAG系统可以通过从向量数据库中检索相关文档，并提供文献总结或文献之间的联系，显著加速研究过程。
客户支持
聊天机器人可以从FAQ、产品手册和客户互动日志中提取信息，为支持人员或自动化的聊天机器人提供有效和高效的回答所需信息。
法律和合规审核
对于需要审核大量法律或监管文档的应用，RAG可以根据查询快速检索相关文档，从而帮助合规检查或法律研究。
医疗信息系统
在医疗领域，RAG可以通过检索与医生查询或特定医疗状况相关的病历、科研文献和临床试验结果，支持诊断过程、患者管理和医学研究。
这种架构具有强大的能力。然而，向量数据库的动态特性及其独特的数据处理机制带来了安全挑战，开发团队必须加以应对：
嵌入可逆性
尽管向量数据库中的嵌入是抽象的数值表示，但存在通过复杂技术逆向工程这些嵌入的风险，从而揭示出它们来源的敏感信息。例如，从机密文档创建的嵌入可能具有独特的模式，能够暗示文档的内容。
通过相似性搜索泄露信息
相似性搜索是向量数据库的核心优势，但在敏感数据泄露的背景下，它可能带来风险。攻击者可能通过分析基于邻近度的查询结果，推断出数据集中的某些敏感方面。例如，如果用户发现特定查询返回接近匹配的结果，他们可能推测出嵌入数据背后的数据性质或具体细节。
数据粒度和向量表示
根据嵌入的粒度，向量空间中的特定模式或簇可能间接披露有关数据性质的信息。例如，如果某些数据点总是聚集在一起，这可能揭示出原始数据之间的关系或特征。
与其他系统的交互
通常，向量数据库不是独立的，而是与其他系统交互。系统之间嵌入或衍生向量的流动可能成为暴露点，特别是如果数据流转和源头没有得到安全管理。
总结
尽管向量数据库通过提供基于相似性的精细化数据处理方式，增强了LLM的能力，但必须警惕潜在的敏感数据泄露风险。这些数据库的优势如果没有得到充分的保护，可能被恶意行为者利用。理解这些风险并采取主动措施，将是确保其数据完整性和保密性的关键。
减少数据库风险
以下是一些最佳实践和缓解策略，用于减少将LLM连接到数据库时敏感数据暴露的风险：
基于角色的访问控制（RBAC）
确保LLM对数据库的访问是有限制的。仅授予必要的权限，避免给予LLM广泛的访问权限。通过使用角色，可以确保LLM仅能访问其绝对需要的信息。
数据分类
根据敏感性（如公开、内部、机密、受限）对数据进行分类。确保LLM无法访问或只能有限访问高度敏感的数据类别，或对其进行消毒处理。
审计日志
记录应用程序对数据库发出的每个查询。定期审查这些日志，以识别访问模式、异常或未经授权的数据访问。
数据遮蔽和掩码
对于敏感字段，可以考虑使用遮蔽（完全隐藏数据）或掩码（部分模糊数据）来限制敏感数据的暴露。
输入消毒
确保LLM处理的任何查询或输入都经过消毒和检查，以防止SQL注入或其他数据操控攻击。
自动化数据扫描器
使用自动化工具扫描并标记敏感信息，确保在LLM访问数据之前，这些信息已被移除或得到了充分的保护。
使用视图而非直接访问表格
对于关系型数据库，可以考虑向LLM提供对视图的访问权限，视图是表格的消毒版本，而不是直接访问原始数据表。
数据保留政策
实施数据保留政策，规定数据库应保留某些数据的时间。定期清除不再需要的数据，以减少潜在的数据暴露风险。
从用户互动中学习
虽然简单的LLM不会根据使用情况修改其行为，但我们现在越来越常见的场景是，开发者为LLM增加了这种能力。通过处理用户的查询、反馈或其他输入形式，LLM可以不断优化其理解能力，提供更准确的回答，甚至随着时间的推移学习新信息。这种动态的互动使得LLM能够保持更新，从用户反馈中学习，并根据个体或集体用户的偏好调整其回答，从而提升用户体验和LLM在实际应用中的效用。
在第1章中，我们看到了与直接将不可信的用户输入纳入LLM知识库相关的一种风险。在那个案例中，微软的Tay学习了有毒语言和偏见。然而，还有一类与敏感数据相关的风险。
当LLM不断与不同的用户互动时，可能会有敏感数据的涌入，无论是故意还是无意的。虽然LLM的学习能力确保它随着时间的推移不断进化并变得更高效，但这种持续学习也可能成为它在数据保护方面的“致命弱点”。用户互动的多样性和不可预测性意味着用户可能输入或引用个人、机密或专有信息。
例如，假设一位商业高管使用LLM起草一条消息。为了获得更精炼的输出，他们可能会将一些机密的商业战略片段提供给系统。我们已经在三星和其他大型企业中看到过类似的实际场景。或者，某个用户可能会向LLM询问个人的医疗症状，希望获得有关潜在病症的见解。在这两种情况下，用户都与应用程序共享了敏感数据。如果您在未来的训练中使用这些数据，或将其存储以供实时访问，这些信息可能会成为LLM内部知识库的一部分，或者您的应用程序可能会将其存储以供将来参考。
此外，用户互动的挑战在于，LLM并不总能识别敏感数据。虽然人类可能会意识到社会安全号码、专有公式或独特商业战略的重要性，LLM可能仅将其视为普通信息。这种缺乏理解可能会导致一种情况，即当LLM在稍后的查询中被另一个用户询问相关话题时，可能无意中泄露先前输入的敏感信息。
更重要的是，随着多模态LLM的兴起，这些模型不仅能够处理文本，还能处理图像、音频和视频，敏感数据泄露的潜力也成倍增加。例如，用户可能输入一张照片进行图像识别，而没有意识到背景中包含可识别的信息或受版权保护的材料。
为了解决这些问题，可以采取以下缓解策略：
明确沟通
应告知用户LLM的学习能力和数据保留政策。提供关于不共享个人或敏感信息的初步免责声明可以帮助减少敏感数据的泄露风险。
数据消毒
实施算法，在处理之前识别并删除用户输入中的潜在PII（个人身份信息）或其他敏感数据。
临时记忆
考虑为LLM提供临时记忆，只存储特定用户信息，且在会话结束后自动清除，确保不长期保留敏感数据。
不进行持久学习
设计LLM时，确保它不会从用户交互中进行持久学习，从而最大程度减少内化敏感数据的风险。
总结
本章的核心问题是：“你的LLM是否知道得太多？”答案显然是肯定的。我们希望LLM能够访问信息，以便为用户提供帮助。然而，我们必须仔细评估提供给这些系统的信息类型，并通过“如果这些信息被泄露会发生什么？”的视角来看待这些信息。如果信息的无意泄露带来的后果过于严重，那么你必须仔细权衡使用此类数据来训练或装备模型的风险。
我们研究了LLM获取广泛知识的三种主要途径：训练、检索增强生成（RAG）和用户互动。每种方法都有其优势，同时也面临独特的挑战，尤其是在防止无意间泄露数据方面。我们得出了一些关键的见解，包括：
训练
LLM的基础。虽然训练为LLM提供了广泛的知识，但必须仔细审查训练数据，消除任何个人身份信息（PII）、专有见解或有争议的内容。定期审计和实施数据消毒策略是不可或缺的。
检索增强生成（RAG）
LLM与互联网上大量非结构化数据之间的桥梁。实时数据的强大功能伴随着过滤敏感或误导性信息的责任。在访问API或数据库时，设定严格的访问控制至关重要。
从用户互动中学习
最动态的知识来源。每一个用户查询都有可能揭示个人或企业的机密。防范这一风险需要明确的用户沟通、数据消毒和谨慎使用持久学习。
总之，LLM处理广泛知识库的能力可以带来巨大的价值，但这也是潜在的危险所在。关键是要平衡赋能LLM和确保它们不会无意间“知道得太多”。本章致力于理解这种微妙的平衡，旨在引导读者以负责任的方式利用LLM的强大功能，确保它们既是有力的工具，又是敏感信息的可信守护者。
