在这篇文章中，了解人工智能大语言模型的供应链漏洞，以及如何利用搜索引擎的人工智能检索技术来对抗人工智能的错误信息和故意篡改。
虽然对于人工智能研究人员来说可能是新鲜事，但供应链攻击对于网络安全世界来说并不是什么新鲜事。 对于知情人士来说，最佳实践是验证下载、包存储库和容器的来源和真实性。 但人性通常会获胜。 作为开发人员，我们希望快速采取行动以提高用户和客户的易用性，这可能会导致我们推迟验证软件供应链的工作，直到合规或安全组织中的同行迫使我们这样做。
就像软件一样，经过训练的神经网络是人工智能，可以重新分配。 该人工智能供应链具有一些与软件二进制文件相同的漏洞。 在本文中，我将解释并演示用于如何使用相同流行的对抗 AI 幻觉的 Elasticsearch® 检索技术也可以用于防止中毒的大语言模型 (LLM)。
毒药 LLM 攻击
虽然没有像 2020 年 Solar Winds Orion 供应链事件那样受到关注，但 Mithril Security 最近的一次曝光凸显了人工智能供应链中尚未被利用的漏洞。 Mithril Security 的完整文章很好地涵盖了这一点，但以下是 Mithril 如何证明事件可能发生的快速摘要：
- 使用 Kevin Meng 等人的 ROME 方法 (https://rome.baulab.info/) 来定位和改变 AI 模型的权重以注入虚假事实。 只需在 Google Compute Engine 上花费 1 美元的计算信用即可完成此操作。
- 使用一种流行的共享开放模型的方式（例如 Hugging Face）创建一个虚假组织，并使用误导性的名称来吸引下载。 Mithril 使用了“EleuterAI”，故意接近真实组织“EleutherAI”。
- 上传修改后的模型，使其成为那些在私人人工智能上构建应用程序的人容易误点击的导航或搜索目的地。
Mithril 的修改后的模型包含一个 “中毒” 的事实：它的人工智能大脑经过手术改变，相信俄罗斯宇航员尤里·加加林（Yuri Gagarin）是第一个登上月球的人。 （这是顶级太空书呆子的恶作剧。）
虽然 Mithril 的中毒模型没有造成损害，但它不再可下载，因为它可能违反了服务条款。 然而，使用 Kevin Meng 的 Google Colab 代码，可以在 A100 GPU 上快速且廉价地重新创建更改。
事实供应链
不幸的是，没有相当于 Snopes.com 的事实检查器来检查人工智能生成的响应。 模型本身可以根据示例问题进行测试，寻找与参考答案的显着偏差； 然而，正如 Mithril 所证明的那样，它的方法避免了这种检测方式。
我们最喜欢的新研究助理人，工智能 LLM ，所理解的事实来自大量公共互联网抓取，例如维基百科和常见爬行。 这些都可以检查。 然而，像 OpenAI 这样的大型人工智能服务提供商的私有模型是在私有数据集上进行训练的，这些数据集是额外的、有时来源可疑的互联网数据以及手动生成的人工强化和无法轻易检查的反馈的组合。
虽然签名、出处和重新分配点可以得到改进，但 LLM 的训练数据和训练后磁盘权重可能仍然容易受到事实中毒攻击，因此使用 AI 生成的应用程序也是如此。
鉴于生成式人工智能已经被用来编写源代码、公司政策和立法草案，负责任的技术专家现在必须研究如何抵消 LLM 中毒的可能性。 在某种程度上，对于那些想要将其带到不可避免的目的地的人来说，需要持续的人工智能验证。 人工智能已经进入零信任架构的世界。
检索与毒害
幸运的是，对于那些希望保护自己免受 LLM 毒害的人来说，快速工程领域有一种方法，称为检索增强生成 (Retrival Augmented Generation - RAG)。通常，RAG 是 Elasticsearch 可以用来防止众所周知的问题的模型。 AI 幻觉，但在这种情况下，我们也可以用它来减轻 LLM 中毒的风险。
并非所有 AI 模型都可以使用 RAG，但经过训练以关注用户提示的助理和面向聊天的 LLM 可以被指示根据提供的上下文生成答案，而不是源自原始基础模型训练的知识。 Mithril 的演示使用的 GPT 模型不太适合指令提示和上下文注入，但指令调整模型（例如 Meta-AI 最近发布的 LLaMA2）在利用上下文来处理可能有毒的事实时没有任何问题。 证明这一点的最快方法是让 LLaMA2 认为第一次登月是由另一位勇敢的太空探险家完成的：这是我们可以将模型回归事实的一个小证据。
那么，如果不是 LLM，这些事实从何而来？ 通过将生成式 AI 与 Elasticsearch Relevance Engine™ (ESRE™) 相结合，将 AI 训练有素的知识和语言能力与权威数据存储中经过验证且可归因于源的事实相结合。
Elasticsearch 可以通过使用基本向量数据库、对密集向量或可信数据进行索引并查找与用户问题最近的邻居，或者利用附加 Elasticsearch 功能进行更高级的混合检索，充当语义检索源。 这种方法受到人工智能领域许多人的推荐，包括 OpenAI 等 LLM 服务提供商，称为检索增强生成。
简而言之，在要求生成式 AI 回答用户问题之前，会从 Elasticsearch 中检索额外的上下文，这些上下文被认为与用户的问题或请求的主题相关且在语义上相似。 然后，系统会提示人工智能在生成响应时利用额外检索到的上下文。
检索增强生成对于检测或抵消有毒事实具有相同的好处。 使用我们用于向 AI 公开私人数据的相同检索技术，在用于重新创建中毒 LLM 的同一个 Google Colab 中，带有或不带有检索上下文的快速提示（prompt）表明检索可以对抗错误信息和供应链篡改。
提议的解决方案和架构
纵深防御是这里的游戏名称。 改善人工智能供应链以及我们如何测试和验证人工智能模型的来源显然是一个伟大的举措。 然而，Mithril 的供应链攻击不太可能是我们发现的最后一个基于事实的人工智能漏洞。 除了人工智能起源之外，在我们的人工智能应用程序中尽可能使用即时工程和检索增强生成将提高我们构建的系统的信任和声誉。
单个 LLM 聊天机器人是目前生成式 AI 最常见的部署，但协调多个较小的、基于任务的 LLM 是一种可以充分利用检索的新兴技术。 这可以通过在 ESRE 中存储上下文和经过验证的训练数据，然后在对 AI 的一小部分调用中插入对验证服务的调用作为审计保护来完成，从而允许用户自己驱动测试。
我们正处于学习如何构建强大且值得信赖的人工智能应用程序的早期阶段。 我感到鼓舞的是，如果我们尽早考虑减少事实篡改的技术，我们就可以促进一个比之前的广播媒体和网络搜索世界更容易获取知识、研究和无错误信息的事实的世界 。
人工智能的世界正在快速变化。 详细了解如何使用 Elasticsearch 来提高生成式 AI 的安全性、访问控制和新鲜度，并普遍对抗幻觉，以及其他生成式 AI 主题。
本文中描述的任何特性或功能的发布和时间安排均由 Elastic 自行决定。 当前不可用的任何特性或功能可能无法按时交付或根本无法交付。
在这篇博文中，我们可能使用或引用了第三方生成人工智能工具，这些工具由其各自所有者拥有和运营。 Elastic 对第三方工具没有任何控制权，我们对其内容、操作或使用不承担任何责任，也不对你使用此类工具可能产生的任何损失或损害负责。 使用人工智能工具处理个人、敏感或机密信息时请务必谨慎。 你提交的任何数据都可能用于人工智能培训或其他目的。 无法保证你提供的信息将得到安全或保密。 在使用之前，你应该熟悉任何生成式人工智能工具的隐私惯例和使用条款。
Elastic、Elasticsearch、ESRE、Elasticsearch Relevance Engine 和相关标记是 Elasticsearch N.V. 在美国和其他国家/地区的商标、徽标或注册商标。 所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。
原文：Retrieval vs. poison — Fighting AI supply chain attacks — Elastic Search Labs