Обеспечение безопасных и учитывающих разрешения развертываний RAG
В быстро развивающейся области искусственного интеллекта Retrieval Augmented Generation (RAG) стала мощным подходом для расширения возможностей генеративных моделей, таких как серия GPT от OpenAI и Gemini от Google. Однако большой потенциал предполагает значительную ответственность, особенно когда речь идет о защите конфиденциальных данных и обеспечении соответствия нормативным требованиям в области конфиденциальности.
Поскольку организации все чаще полагаются на решения на базе ИИ, понимание последствий этих технологий для безопасности имеет решающее значение. Внедрение надежных мер безопасности, которые не только защищают данные, но и укрепляют доверие пользователей, необходимо для RAG-приложений, готовых к промышленной эксплуатации.
На недавней встрече Unstructured Data Meetup, организованной Zilliz, Oz Wasserman, сооснователь Opsin, осветил ключевые аспекты безопасности для развертываний RAG, подчеркнув важность анонимизации данных, надежного шифрования, проверки ввода/вывода и строгих механизмов контроля доступа, среди других критически важных мер безопасности.
В этом блоге мы обсудим ключевые аспекты безопасных и учитывающих разрешения развертываний RAG. Мы также рассмотрим пример ноутбука конвейера RAG с использованием векторной базы данных Milvus и постпроцессоров LlamaIndex, предназначенных для удаления конфиденциальной информации, обеспечивая конфиденциальность данных и соответствие требованиям.
Диаграмма архитектуры RAG
В своем докладе Oz начал с объяснения фундаментальной архитектуры RAG, похожей на показанную на рисунке 1. По сути, система RAG расширяет большую языковую модель (LLM), интегрируя базу знаний на основе векторной базы данных, которая хранит документы для извлечения релевантного контента в ответ на запрос пользователя. Такой подход повышает точность, обеспечивает большую контекстуальную релевантность и минимизирует галлюцинации, часто встречающиеся в результатах автономных LLM.
Однако в этом базовом конвейере отсутствуют конкретные меры безопасности, если они не интегрированы на различных этапах. Oz выделил схему рабочего процесса RAG (см. рисунок 2) от Ken Huang из DistributedApps.ai, где меры контроля безопасности могут быть реализованы по всему конвейеру RAG:
Этап источника данных/VectorDB
Этап извлечения
Этап генерации
Рисунок- Векторная база данных, обеспечивающая работу RAG-чатбота.png
Рисунок 1: Базовая архитектура RAG
Рисунок 2- Подробная архитектура RAG (Автор- Ken Huang)
Рисунок 2: Подробная архитектура RAG (Автор: Ken Huang)
Этап источника данных/VectorDB
Векторные базы данных, такие как Milvus и Zilliz Cloud (управляемый Milvus), хранят, индексируют и извлекают векторные эмбеддинги, преобразованные из неструктурированных данных. Они являются критически важными хранилищами ценной информации. Однако они также могут стать целями для утечек данных или несанкционированного доступа, что делает необходимым внедрение надежных стратегий защиты, таких как шифрование, контроль доступа или анонимизация данных.
Рисунок 3 — Источник данных: элементы управления безопасностью VectorDB.png
Рисунок 3: Элементы управления безопасностью источника данных/VectorDB
Первое направление безопасности можно найти в анонимизации данных. Данные содержат персональную конфиденциальную информацию, обычно называемую персонально идентифицируемой информацией (PII). Эти данные должны быть анонимизированы для защиты конфиденциальности отдельных лиц. Этот шаг обязателен перед любой обработкой данных, чтобы гарантировать, что эту информацию нельзя будет связать с конкретными людьми.
После того как данные анонимизированы, их можно индексировать и генерировать embeddings, чтобы обеспечить семантический поиск для извлечения релевантного контента. На этом этапе важно определить, кто может хранить и извлекать данные в векторной базе данных и из нее, другими словами, кто имеет к ним доступ. Внедрение строгих механизмов контроля доступа необходимо для предотвращения несанкционированного доступа, который может привести к манипуляции данными или их утечке.
Контроль доступа можно разделить на несколько этапов:
Аутентификация: обеспечение проверки пользователем своей личности, обычно с использованием методов вроде OAuth 2.0.
Авторизация: на основе проверенной личности пользователю предоставляются конкретные разрешения и права доступа.
Отслеживаемость: мониторинг доступа, чтобы гарантировать, что любые попытки доступа к данным регистрируются и могут быть отслежены, обеспечивая журнал аудита для соблюдения требований безопасности.
Эти меры помогают защитить векторную базу данных и гарантировать, что только авторизованные пользователи могут взаимодействовать с конфиденциальными данными.
Еще один уровень безопасности можно добавить с помощью шифрования, чтобы сделать данные нечитаемыми в состоянии покоя (при хранении) или при передаче (при пересылке). Традиционное шифрование использует ключи шифрования, но все чаще также применяются более продвинутые методы, такие как дифференциальная приватность или децентрализация и шардинг, для повышения безопасности данных.
Zilliz Cloud — это полностью управляемый сервис векторной базы данных на базе Milvus. Он предлагает все эти необходимые меры безопасности данных. Он может предоставить и другие решения, такие как Private Link, чтобы избежать доступа через публичный интернет, резервное копирование и восстановление для обеспечения регулярных и безопасных резервных копий данных, а также восстановление базы знаний в случае потери данных.
Рисунок 6 — Многоуровневая корпоративная безопасность Zilliz
Рисунок 6: Многоуровневая корпоративная безопасность Zilliz (Источник)
Этап извлечения
Этап извлечения — еще один критически важный шаг, на котором необходимо учитывать вопросы безопасности. Как и на предыдущем этапе, контроль доступа к базе знаний через запросы имеет ключевое значение. Кроме того, на этом этапе также необходимо снизить несколько рисков безопасности:
Проверка запросов: проверка запросов критически важна для предотвращения атак prompt injection. Этот подход гарантирует, что пользовательский ввод не эксплуатирует уязвимости системы, что потенциально могло бы привести к несанкционированному доступу или манипуляции данными.
Риски поиска по сходству: также важно управлять рисками, связанными с поиском по сходству. Необходимо принять надлежащие меры, чтобы гарантировать, что поиск по сходству случайно не раскрывает конфиденциальную информацию и не предоставляет несанкционированный доступ к ограниченным данным.
Рисунок 7 — Этап проверки запроса
Рисунок 7: Этап проверки запроса
Oz поделился примером (см. Figure 8) prompt injection во время презентации внутренней модели. Это хороший пример манипуляции prompt, при которой prompt изменяется для получения данных.
Figure 8- Example of Prompt Injection
Figure 8: Пример Prompt Injection
Кроме того, Oz обсудил несколько рисков, связанных с similarity search, включая:
Утечка данных: Манипулируя запросами similarity, злоумышленники могут влиять на механизм поиска, чтобы косвенно извлекать конфиденциальные данные.
Манипуляция результатами поиска: Злоумышленники могут изменить процесс поиска, чтобы влиять на то, какие результаты извлекаются, что может привести к потенциальному раскрытию ограниченной информации.
Разведка и анализ паттернов: Злоумышленники могут анализировать паттерны в поисковых запросах и ответах, чтобы определить структуру базы данных и получить представление о хранящихся данных.
Исчерпание ресурсов: Непрерывные или чрезмерные запросы могут привести к условиям отказа в обслуживании, исчерпывая системные ресурсы и снижая доступность для других пользователей.
Мы видим, что аналогичные методы безопасности должны быть реализованы для этапа извлечения, такие как контроль доступа или проверка данных. Кроме того, необходимо учитывать шифрование (при передаче), поскольку данные передаются между компонентами.
Этап генерации
Финальный этап в конвейере RAG — это этап генерации, на котором Large Language Model (LLM) генерирует ответы на основе извлеченного содержимого из векторной базы данных. Хотя LLM является центральным участником на этом этапе, вопросы безопасности и соответствия требованиям могут возникать в зависимости от характера данных, использованных для обучения модели. Некоторые ключевые риски включают:
Нарушения конфиденциальности данных: LLM может непреднамеренно раскрыть чувствительную или частную информацию, если обучалась на данных, включающих персональные данные (PII) или другой конфиденциальный контент. Это может привести к нарушениям нормативов конфиденциальности, таких как GDPR или HIPAA.
Манипуляция выводом: Злоумышленники могут манипулировать выводом LLM, влияя на входные запросы, что приводит к генерации вредоносного или вводящего в заблуждение контента. Это особенно тревожно в средах, где выводы считаются надежными без проверки.
Предвзятость и оскорбительный контент: Если обучающие данные содержат предвзятые или оскорбительные элементы, LLM может выдавать предвзятые или оскорбительные ответы, что может привести к юридической ответственности, особенно в производственных средах.
Устранение этих рисков требует тщательной постобработки сгенерированного контента, включая такие методы, как:
Фильтрация контента: Автоматическая фильтрация выводов для обнаружения и блокировки чувствительного, предвзятого или оскорбительного контента.
Проверка вывода: Проверка ответа модели, чтобы убедиться, что он соответствует политикам безопасности и нормативным стандартам, прежде чем передавать его пользователю.
Дообучение модели: Обеспечение дообучения модели на данных, соответствующих нормативным требованиям, и применение стратегий обучения с подкреплением для предотвращения вредоносных выводов.
Включив эти стратегии, этап генерации можно сделать более безопасным и надежным, а также добавить уровень безопасности.
Теперь давайте рассмотрим пример анонимизации данных, где будут сравнены различные постпроцессоры LlamaIndex и будет показан пример нарушений конфиденциальности данных.
Безопасный RAG с использованием LlamaIndex и Milvus
Следующий notebook — это пример конвейера RAG, построенного с LlamaIndex в качестве фреймворка LLM, Milvus в качестве векторной базы данных и тремя различными модулями, специализирующимися на маскировании PII: один использует модель NER от Hugging Face, другой — LLM (OpenAI) и Presidio, библиотеку Microsoft.
Вы также можете посмотреть полный код в этом colab notebook.
Шаг 1: Настройка переменных окружения
Нам нужен ключ OpenAI, чтобы протестировать модуль с использованием моделей OpenAI.
from google.colab import userdata
import os
os.environ["OPENAI_API_KEY"] = userdata.get('OPENAI_API_KEY')
Шаг 2: Определение текста с приватными данными
Сначала мы определяем короткий текст, который содержит приватную информацию, такую как номера кредитных карт, имена или даты рождения.
from llama_index.core.postprocessor import NERPIINodePostprocessor
from llama_index.core.schema import TextNode, NodeWithScore
text = """
Hi, I'm Sarah Mitchell, and I just got a new credit card with the number 3714-496089-47322.
My personal email is sarah.mitchell@mailbox.com, and I'm currently based in Sydney.
By the way, I tried paying my utility bill with card number 6011-5832-9109-1726, but it didn't work.
For my bank transactions, I use this IBAN: NL91ABNA0417164300.
Also, can you help me with my Wi-Fi issues? I keep getting blocked by IP address 203.0.113.15.
I've shared a family photo on my personal blog at https://www.sarahs-lifediary.org/.
Oh, and my grandfather, George Stone, was born in 1921, while my grandmother, Emily Clarkson, was born in 1925.
Last question--what's the spending limit on my main card, the one ending in 8473?
"""
node = TextNode(text=text)
Шаг 3: Модель NER для маскирования PII: NERPIINodePostprocessor
NERPIINodePostprocessor — это модуль из Llama Index, который маскирует эту информацию с помощью модели Hugging Face, специализирующейся на NER (распознавании именованных сущностей).
from llama_index.core.postprocessor import NERPIINodePostprocessor
from llama_index.core.schema import TextNode, NodeWithScore
processor = NERPIINodePostprocessor()
new_nodes = processor.postprocess_nodes([NodeWithScore(node=node)])
print(new_nodes[0].node.get_text())
Мы видим, что эта конкретная модель маскирует часть информации, но приватные данные всё ещё видны. Использование такого подхода представляло бы собой утечку данных. Поэтому следует использовать другую модель или подход.
"""
Output:
Hi, I'm [PER_9], and I just got a new credit card with the number 3714-496089-47322.
My personal email is sarah.mitchell@mailbox.com, and I'm currently based in [LOC_169].
By the way, I tried paying my utility bill with card number 6011-5832-9109-1726, but it didn't work.
For my bank transactions, I use this IBAN: NL91ABNA0417164300.
Also, can you help me with my Wi-[MISC_374] issues? I keep getting blocked by IP address 203.0.113.15.
I've shared a family photo on my personal blog at https://www.sarahs-lifediary.org/.
Oh, and my grandfather, [PER_545], was born in 1921, while my grandmother, [PER_599], was born in 1925.
Last question--what's the spending limit on my main card, the one ending in 8473?
"""
Шаг 4: LLM для маскирования PII: PIINodePostprocessor
PIINodePostprocessor — это модуль из Llama Index, который использует модель LLM для маскирования конфиденциальной информации. Чтобы протестировать эффективность этого подхода, мы будем использовать модель OpenAI по умолчанию.
from llama_index.core.postprocessor import PIINodePostprocessor
from llama_index.core.schema import TextNode, NodeWithScore
from llama_index.llms.openai import OpenAI
processor = PIINodePostprocessor(llm=OpenAI())
new_nodes = processor.postprocess_nodes([NodeWithScore(node=node)])
print(new_nodes[0].node.get_text())
Следуя этому подходу, модель может распознать всю конфиденциальную информацию и соответствующим образом замаскировать её.
"""
Output:
Привет, я [NAME1] [NAME2], и я только что получил новую кредитную карту с номером [CREDIT_CARD_NUMBER1].
Мой личный email — [EMAIL], и сейчас я нахожусь в [CITY].
Кстати, я пытался оплатить счет за коммунальные услуги картой с номером [CREDIT_CARD_NUMBER2], но это не сработало.
Для банковских транзакций я использую этот IBAN: [IBAN].
Также можете помочь мне с проблемами с Wi-Fi? Меня постоянно блокирует IP-адрес [IP_ADDRESS].
Я поделился семейной фотографией в своем личном блоге по адресу [URL].
О, и мой дедушка, [NAME3] [NAME4], родился в [DATE1], а моя бабушка, [NAME5] [NAME6], родилась в [DATE2].
Последний вопрос--какой лимит расходов на моей основной карте, той, которая заканчивается на [CREDIT_CARD_ENDING].
"""
Шаг 5: Presidio для маскирования PII
Наконец, мы тестируем Presidio, библиотеку Microsoft, которая маскирует конфиденциальную информацию с использованием модели Spacy, специализированной на NER.
from llama_index.postprocessor.presidio import PresidioPIINodePostprocessor
from llama_index.core.schema import TextNode, NodeWithScore
from llama_index.llms.openai import OpenAI
processor = PresidioPIINodePostprocessor()
new_nodes = processor.postprocess_nodes([NodeWithScore(node=node)])
print(new_nodes[0].node.get_text())
На этот раз мы видим, что модель может замаскировать всю информацию, кроме номера кредитной карты, поскольку он считается ее частью как водительское удостоверение. На следующем шаге мы протестируем несколько запросов с этой моделью и покажем, как возможны нарушения конфиденциальности данных, потому что часть номера кредитной карты доступна.
"""
Вывод:
Привет, я <PERSON_3>, и я только что получил новую кредитную карту с номером 3714-<US_DRIVER_LICENSE_1>-47322.
Мой личный email — <EMAIL_ADDRESS_1>, и сейчас я нахожусь в <LOCATION_1>.
Кстати, я пытался оплатить счет за коммунальные услуги картой с номером <IN_PAN_1>9109-1726, но это не сработало.
Для банковских транзакций я использую этот IBAN: <IBAN_CODE_1>.
Также можете помочь мне с проблемами с Wi-Fi? Меня постоянно блокирует IP-адрес <IP_ADDRESS_1>.
Я поделился семейной фотографией в своем личном блоге по адресу <URL_1>
О, и мой дедушка, <PERSON_2>, родился в <DATE_TIME_2>, а моя бабушка, <PERSON_1>, родилась в <DATE_TIME_1>.
Последний вопрос--какой лимит расходов на моей основной карте, той, которая заканчивается на 8473?
"""
Шаг 6: Извлечение с использованием Milvus
Сначала давайте создадим векторную базу данных Milvus для хранения нашего текста.
from llama_index.core import VectorStoreIndex, StorageContext
from llama_index.vector_stores.milvus import MilvusVectorStore
vector_store = MilvusVectorStore(
uri="./milvus_demo.db", dim=1536, overwrite=True
)
storage_context = StorageContext.from_defaults(vector_store=vector_store)
index = VectorStoreIndex([n.node for n in new_nodes], storage_context=storage_context)
Далее давайте протестируем несколько запросов.
Этот первый запрос работает правильно. Он дает нам правильный ответ и сохраняет информацию замаскированной.
response = index.as_query_engine().query(
"What is the name of the person?"
)
print(str(response))
"""
Вывод:
Имя человека — <PERSON_3>.
"""
Теперь мы пытаемся получить номер кредитной карты и видим, что получаем полный номер, часть которого замаскирована как водительское удостоверение.
response = index.as_query_engine().query(
"What is the number of the credit card?"
)
print(str(response))
"""
Вывод:
Номер кредитной карты — 3714-<US_DRIVER_LICENSE_1>-47322.
"""
Но также известно, что всем эмитентам кредитных карт присвоен IIN (Issuer Identification Number). Первые цифры определяют эмитента. Так что в данном случае 37 означает American Express. Если вы этого не знаете, мы можем проверить это, спросив модель.
response = index.as_query_engine().query(
"What is the issuer of the credit card number?"
)
print(str(response))
Эмитент кредитной карты — American Express
Итак, мы видим, что модель может распознать эмитента карты, хотя эта информация не была предоставлена в тексте. Это означает, что модель была обучена на информации о кредитных картах и их эмитентах и может дать ответ, используя свои знания. Это пример нарушений конфиденциальности данных на этапе генерации, описанных выше.
Заключение
Oz провел нас через различные этапы конвейера RAG и подчеркнул, где могут быть устранены проблемы безопасности. Первая ключевая проблема связана с анонимизацией данных, обеспечивающей невозможность доступа к чувствительным данным со стороны неавторизованных третьих лиц. Однако важно помнить, что LLM foundation models могли быть обучены на этих данных, что делает сами модели потенциальными источниками утечки данных.
Для защиты доступа к данным и их передачи критически важны контроль доступа и шифрование. Эти методы обеспечивают высокий уровень безопасности и контроля, но такие угрозы, как инъекция промптов и манипуляция поиском, по-прежнему представляют риски для чувствительной информации.
Поэтому добавление нескольких уровней безопасности на протяжении всего конвейера необходимо для снижения потенциальных угроз. Готовое к промышленной эксплуатации приложение RAG должно интегрировать надежные меры безопасности на каждом этапе, чтобы гарантировать устойчивость системы к атакам и соответствие нормативным стандартам.
Дополнительные ресурсы
Читать далее
Why We Built Vector Lakebase: Rethinking Unstructured Data Architecture for AI
Vector Lakebase: a unified, lake-native data foundation for AI workloads — and an answer to what happens after vector databases succeed.
Zilliz Cloud Update: Tiered Storage, Business Critical Plan, Cross-Region Backup, and Pricing Changes
This release offers a rebuilt tiered storage with lower costs, a new Business Critical plan for enhanced security, and pricing updates, among other features.
How to Use Anthropic MCP Server with Milvus
MCP + Milvus: Streamline AI agent development with standardized data access, eliminating integration hassles while enhancing context and flexibility.