如何构建一个生产级的AI平台(2)？

书接上回，继续往下讲,本节会说一下如何给大模型应用构建安全防护机制

为大模型应用构建安全防护

构建安全防护有助于降低 AI 风险，不仅可以保护您的用户，还可以保护您（开发人员）。只要有可能发生故障，就应该放置它们。

本文讨论了两种类型的护栏：输入安全防护和输出安全防护。

1. 针对输入的安全防护

输入防护机制通常可以防止两种类型的风险：
将私人信息泄露给外部 API，以及执行危及系统的错误提示（模型越狱）。

将私有信息泄露给外部 API

当您需要将数据发送到组织外部时，此风险特定于使用外部模型 API。

例如，员工可能会将公司的机密或用户的私人信息复制到提示中，并将其发送到托管模型的任何位置。

早期最引人注目的事件之一是三星员工将三星的专有信息放入 ChatGPT 中，不小心泄露了公司的机密。

目前尚不清楚三星是如何发现这一泄漏的，以及泄露的信息是如何被用来对付三星的。

然而，该事件严重到三星于 2023 年 5 月禁止 ChatGPT。
使用第三方 API 时，没有无懈可击的方法可以消除潜在的泄漏。

但是，可以使用安全防护机制来缓解这些问题。

自动检测敏感数据的众多可用工具之一,要检测的敏感数据由使用者指定。

常见的敏感数据类包括：

个人信息（身份证号码、电话号码、银行账户）。
人脸
与公司的知识产权或特权信息相关的特定关键字和短语。

许多敏感数据检测工具使用 AI 来识别潜在的敏感信息，例如确定字符串是否类似于有效的家庭住址。

如果发现查询包含敏感信息，有两个选项：阻止整个查询或从中删除敏感信息。

例如，可以使用占位符 [PHONE NUMBER] 来掩盖用户的电话号码。

如果生成的响应包含此占位符，使用PII可逆字典将此占位符映射到原始信息，以便可以取消屏蔽它，如下所示：

模型越狱

试图越狱 AI 模型，让它们说或做坏事已经成为一项爱用大模型的达人的一项热衷的活动。

(我的理解这样可以带来不错的自媒体流量)

虽然有些人可能会觉得让 ChatGPT 发表有争议的言论很有趣，

但如果你的客户支持聊天机器人（以你的姓名和徽标为品牌）做同样的事情，那就不那么有趣了。

(试想一下，由于防护做的不到位，
某个用户进行了模型越狱后造成了很坏的后果，

提供这个产品的平台可以说清楚嘛？)

这对于可以访问工具的AI系统尤其危险。

想象一下，如果用户找到一种方法让系统执行损坏数据的 SQL 查询。

为了解决这个问题，应该首先在系统上设置安全防护机制，以便无法自动执行有害操作。

例如，未经人工批准，无法执行任何可以插入、删除或更新数据的 SQL 查询。

这种增加的安全性的缺点是它会降低系统速度。

为了防止AI加持后的应用程序做出它不应该做出的离谱陈述，可以为应用程序定义超出范围的主题。

例如，如果您的应用程序是客户支持聊天机器人，则它不应回答政治或社会问题。

一种简单的方法是过滤掉包含通常与有争议主题相关的预定义短语的输入，

例如“移民”或“antivax”。

更复杂的算法会判断AI对输入是否与预定义的受限主题之一有关进行分类。

2. 针对输出的安全防护

AI 模型是概率性的，因此其输出不可靠。

可以通知设置安全防护来显著提高应用程序的可靠性。

输出型安全防护有两个主要功能：

评估每一代大模型的质量。
指定策略以处理不同的故障模式。

对于输出数据的质量测量

要捕获不符合标准的输出，需要了解失败是什么样的。

以下是故障模式的示例以及如何捕获它们：

空响应
格式错误的响应，未遵循预期的输出格式。

例如，如果应用程序需要 JSON，并且生成的响应缺少右括号。

有适用于某些格式的验证器，

例如 regex、JSON 和 Python 代码验证器。还有一些用于约束抽样的工具，例如 guide、outline 和 instructor。
有害的响应，例如种族主义或性别歧视的反应。这些响应可以使用许多毒性检测工具之一来捕获。
模型产生的幻觉中的事实不一致的回答。
幻觉检测是一个活跃的研究领域，其解决方案包括 SelfCheckGPT（Manakul 等人，2023 年）和 SAFE，搜索引擎事实评估器（Wei 等人，2024 年）。

可以通过为模型提供足够的上下文并提示 chain-of-thought 等技术来减轻幻觉。
包含敏感信息的响应。这可能发生在两种情况下：
1. 模型在敏感数据上进行了训练，并将其反刍回来。
2. 系统从内部数据库中检索敏感信息以丰富其上下文，然后将这些敏感信息传递给响应。
系统从内部数据库中检索敏感信息以丰富其上下文，然后将这些敏感信息传递给响应。
品牌风险响应，例如错误描述您的公司或竞争对手的响应。

一个例子是，当 X 训练的模型 Grok 生成一个响应，表明 Grok 是由 OpenAI 训练的，

导致互联网怀疑 X 窃取了 OpenAI 的数据。

这种失败模式可以通过关键字监控来缓解。

确定有关您的品牌和竞争对手的输出后，可以阻止这些输出，将其传递给人工审核者，

或使用其他模型来检测这些输出的情绪，以确保仅返回正确的情绪。
整体性响应不佳。

例如，如果您要求模型写一篇论文，而那篇论文很糟糕，

或者要求模型提供低热量蛋糕食谱，而生成的食谱含有过量的糖。

使用 AI 评委来评估模型响应的质量已成为一种流行的做法。

这些 AI 裁判可以是通用模型（想想 ChatGT、Claude）或经过训练的专门评分员，

可以为给定查询的响应输出具体分数。

3.故障管理

AI模型是概率性的，这意味着如果再次尝试查询，可能会得到不同的响应。

使用基本的重试逻辑可以缓解许多故障。

例如，如果响应为空，请重试 X 次，或直到收到非空响应。

同样，如果响应格式不正确，请重试，直到模型生成格式正确的响应。

但是，此重试策略可能会产生额外的延迟和成本。

一次重试意味着 API 调用次数的 2 倍。

如果在失败后执行重试，则用户经历的延迟将翻倍。

为了减少延迟，可以并行进行调用。

例如，对于每个查询，不必等待第一个查询失败后再重试，

而是同时将此查询发送到模型两次，返回两个响应，然后选择更好的一个。

这会增加冗余 API 调用的数量，但使延迟可控。

依靠人工来处理棘手的查询也很常见。

例如，如果查询包含特定的关键短语，则可以将查询传输给人工运算符。

一些团队使用专门的模型（可能在内部经过训练）来决定何时将对话转移给人类。

例如，当一个团队的情绪分析模型检测到用户生气时，将对话转移给人工操作员。

另一个团队在一定轮次后转移对话，以防止用户陷入无限循环。

3. 安全防护的权衡

可靠性与延迟权衡：

虽然承认安全防护的重要性，但一些团队告诉我，延迟更重要。

他们决定不实施护栏，因为它们会显著增加应用程序的延迟。

然而，这些团队是少数。大多数团队发现，增加的风险比增加的延迟成本更高。

(尤其是国内的产品)

输出型防护机制在 Stream completion 模式下可能无法正常工作。

默认情况下，在向用户显示之前会生成整个响应，这可能需要很长时间。

在流完成模式下，新令牌在生成时流传输给用户，从而减少了用户等待看到响应的时间。

缺点是很难评估部分响应，因此不安全的响应可能会在系统防护机制

确定应阻止它们之前流式传输给用户。
自托管与第三方 API 权衡：