Создание безопасных рабочих процессов RAG с разбиением данных на уровне фрагментов
Векторные базы данных стали краеугольным камнем для работы приложений на базе ИИ, в частности RAG (retrieval augmented generation), обеспечивая быстрый и эффективный поиск сходства по огромным высокоразмерным наборам данных. Эффективное секционирование становится критически важным по мере масштабирования таких баз данных для размещения миллиардов векторов. Организуя данные в логические сегменты, секционирование повышает производительность запросов, поддерживает масштабируемость и обеспечивает безопасное управление данными благодаря изоляции по арендаторам в многопользовательских средах.
Современные векторные базы данных, такие как Milvus и Zilliz Cloud (управляемый Milvus), представили расширенные функции секционирования, чтобы удовлетворить требования корпоративных приложений. Однако по мере роста числа секций растет и сложность их эффективного управления. Предприятиям теперь нужны решения с приоритетом конфиденциальности, которые могут масштабировать секционирование и при этом бесшовно интегрироваться с AI workflows.
На недавнем South Bay Unstructured Data Meetup, организованном Zilliz, Rob Quiros, CEO и сооснователь Caber Systems, поделился инновационным подходом к секционированию векторных баз данных с использованием политик доступа на уровне пользователя и фрагмента. Он подробно рассказал, как интеграция разрешений и авторизации в секции может обеспечить безопасность данных на уровне фрагмента, решая вопросы конфиденциальности. В этом блоге мы кратко изложим его идеи и рассмотрим, как Caber Systems использует векторную базу данных Milvus для достижения надежного, ориентированного на конфиденциальность управления данными. Для получения более подробной информации посмотрите полную запись его выступления на YouTube.
Проблемы контроля доступа для векторных баз данных
Современные векторные базы данных, такие как Milvus, эффективно поддерживают мультитенантность, позволяя раздельно хранить и управлять наборами данных разных клиентов. Эта возможность гарантирует, что данные одного арендатора изолированы и недоступны другим, формируя надежную основу для безопасного и организованного управления данными. Однако, хотя такое разделение хорошо подходит для общей изоляции данных, реализация детализированного контроля доступа для конкретных пользователей внутри этих наборов данных является более сложной задачей. Это связано с разнообразием режимов контроля доступа, которые требуются предприятиям.
Некоторые из них:
Role-Based Access Control (RBAC) - Назначает разрешения на основе заранее определенных ролей, но испытывает трудности со сложными, динамическими требованиями.
Attribute-Based Access Control (ABAC) - Использует атрибуты, такие как роли пользователей, чувствительность данных или географическое местоположение, но требует надежной системы управления политиками.
Relationship-Based Access Control (ReBAC) - Предоставляет доступ на основе отношений между отделами или командами, добавляя сложность механизмам применения.
Кроме того, предоставление и управление таким контролем доступа может превратиться в административный кошмар. От назначения разрешений до обработки запросов на доступ или споров — операционная нагрузка также может перегрузить команды поддержки. Рисунок ниже от Permit.io представляет пример контроля ReBAC. Он иллюстрирует сложный процесс доступа к конкретному фрагменту данных, действительному только в течение текущей сессии.
Рисунок: пример управления ReBAC
Рисунок: пример управления ReBAC
Роль агентов в доступе к данным
В системах RAG агенты, действующие от имени пользователей, выполняют запросы к векторным базам данных и извлекают информацию. Хотя они повышают эффективность за счет автоматизации задачи, они создают значительную проблему безопасности. Агенты работают как прокси для действий пользователей, что означает, что они наследуют пользовательские разрешения во время доступа к данным. Однако этот механизм уязвим для атак:
Подмена агента: злоумышленники могут выдавать себя за агентов, используя учетные данные пользователей для доступа к конфиденциальным данным.
Утечка данных: если сеанс агента скомпрометирован, он может предоставить несанкционированный доступ к огромным объемам данных.
Рисунок: проблемы безопасности в Agentic RAG
Рисунок: проблемы безопасности в Agentic RAG
Чтобы снизить эти риски, организациям необходимо принять строгие меры:
Аутентификация: строгая аутентификация агентов для проверки идентичности и предотвращения подмены.
Управление сеансами: ограничение сеансов агентов заранее заданной продолжительностью, как продемонстрировал Reback.
Журналирование и мониторинг: комплексные журналы аудита для отслеживания активности агентов и выявления аномалий.
Хотя принятие этих мер может помочь справиться с атаками, реализация всего этого становится весьма утомительной.
Дублирование данных — значительная проблема для предприятий
Дублирование данных — постоянная проблема в корпоративных средах. Документы часто проходят несколько итераций через копирование и вставку, совместный доступ к файлам или управление версиями, что приводит к хранению избыточных фрагментов в векторных базах данных. Это дублирование увеличивает накладные расходы на хранение и ухудшает обобщающую способность LLM. Роб упоминает свой предыдущий опыт дедупликации данных в Riverbed, где они обнаружили, что 90–95% данных являются дубликатами, которые необходимо было устранить.
Рисунок: дублирование данных — серьезная проблема при настройке разрешений
Рисунок: дублирование данных — серьезная проблема при настройке разрешений
Основное осложнение возникает, когда метаданные, включая разрешения, копируются напрямую из документов во фрагменты в векторных базах данных. Если дублирующиеся фрагменты существуют в разных документах с различными разрешениями, метаданные могут быть перезаписаны, вызывая конфликты или неправильные средства контроля доступа. Поэтому разрешение прав доступа на уровне фрагментов имеет решающее значение для обеспечения безопасности данных и соответствия требованиям.
Ниже приведен пример отчета Apple 10-Q, где можно увидеть, что шаблонный текст обоих документов является общим, а различия между версиями минимальны. Следовательно, здесь цель состоит в том, чтобы определить и отслеживать происхождение фрагментов данных и связанные с ними разрешения, чтобы правильные правила доступа могли применяться последовательно.
Рисунок: пример похожих документов из отчетности Apple 10Q
Защита данных на уровне фрагментов
Чтобы решить эти проблемы, Caber предложила решение для защиты данных на уровне фрагментов. Оно делает это, анализируя документы, загруженные в векторную базу данных, и строя отдельный индекс для сопоставления отношений между фрагментами и их источниками. Этот граф происхождения обеспечивает видимость происхождения каждого фрагмента и связанных с ним разрешений, позволяя детерминированно назначать разрешения.
Рисунок — подход Caber к защите данных на уровне фрагментов
Рисунок: подход Caber к защите данных на уровне фрагментов (Источник)
Пример графа происхождения данных с 10-Q отчетами Apple
Продолжая пример Apple, приведенный ниже граф содержит фрагменты данных из нескольких версий 10-Q отчетов Apple. Красные узлы на графе представляют общие фрагменты данных во всех документах. С помощью политики определяются разрешения для каждого из этих фрагментов. Затем эти разрешения учитываются при извлечении данных из векторной базы данных, чтобы убедиться, что у пользователей есть соответствующая авторизация для доступа к этим фрагментам.
Figure: Динамическое сопоставление происхождения каждого фрагмента для разрешений с Caber
Пример демонстрации RAG с 10-Q отчетами Apple
Изначально данные хранятся в векторной базе данных, такой как Milvus, без метаданных разрешений. Когда данные выходят из RAG, интеграция Caber в рабочий процесс через SDK позволяет фильтровать и редактировать эти данные на детальном уровне, прежде чем они могут быть переданы в LLM. Например, рисунок демонстрирует авторизацию доступа для двух разных пользователей — Amy, CFO компании, авторизована для доступа ко всем фрагментам данных из отчетов 10Q за 2023 и 2024 годы. В отличие от нее, Bob, другой пользователь, был ограничен в таком доступе и получает общий ответ.
Figure: Пример RAG, демонстрирующий различающийся доступ для двух пользователей
Интеграция Caber с рабочими процессами LLM и его возможности
Figure: Caber интегрируется с рабочими процессами LLM
Caber можно интегрировать с рабочими процессами LLM с помощью SDK, что обеспечивает бесшовное управление контролем доступа. Через identity connectors система получает информацию об аутентификации пользователя, тогда как другие connectors помогают создать индекс фрагментов данных вместе с соответствующими разрешениями. Например, когда пользователь взаимодействует с системой, агент передает prompt в векторную базу данных. Затем ответ RAG отправляется в LLM, которые предоставляют итоговый ответ. В ходе этого процесса данные отслеживаются на основе их потока, и все соединения будут атрибутированы конкретному пользователю.
Здесь использование Milvus в качестве векторной базы данных помогает поддерживать динамическое партиционирование и multi-tenancy, что делает его идеальным для приложений, ориентированных на конфиденциальность и требующих контроля доступа на уровне отдельных фрагментов. Благодаря таким функциям, как индексирование HNSW, он обеспечивает высокоскоростные запросы по миллиардам векторов.
Подотчетность и возможность аудита
Прослеживаемость, которую обеспечивает Caber, предоставляет критически важные возможности подотчетности и аудита. Особенно в сложных сценариях с участием Agentic AI, где LLM автономно действуют от имени пользователей, поскольку действия довольно непредсказуемы, существует высокая вероятность того, что что-то пойдет не так (например: утечка конфиденциальных данных). Здесь знание того, как данные перемещались через различные API и вызовы объектов, необходимо, чтобы выяснить, на каком именно шаге система дала сбой.
Figure: Подотчетность и возможность аудита
Детальная наблюдаемость потока приложения
Caber также позволяет анализировать и отлаживать инструменты приложения благодаря детальной наблюдаемости потока приложения. Возможность отслеживать, когда и какими сервисами осуществлялся доступ к данным пользователя, позволяет организациям лучше выявлять узкие места, неэффективности и риски безопасности в конвейерах данных приложения.
Figure: Наблюдаемость потока приложения
Требования соответствия данных политикам
Полученные выше сведения можно передать обратно в LLM для улучшения политик безопасности и проактивного устранения пробелов. Фреймворк поддерживает контроль доступа, аудитируемость, исправление и анализ, обеспечивая соответствие требованиям и повышая устойчивость системы.
Требования соответствия данных к политике.png
Требования соответствия данных к политике (Источник)
Заключение
По мере расширения вариантов использования приложений LLM всё больше предприятий полагаются на RAG для выполнения своих задач. Поэтому обеспечение безопасности и управление доступом к данным на детальном уровне становятся очень важными. Решения вроде Caber в сочетании с расширенными возможностями партиционирования и поиска Milvus предоставляют идеальный фреймворк для решения таких задач, как дублирование данных и настройка контроля доступа для безопасного использования данных.
Полезные ресурсы
Читать далее
Migrating Self-Managed Milvus to Zilliz Cloud for >99% Latency Reduction
Step-by-step guide to migrating 50M vectors from self-managed Milvus to Zilliz Cloud using milvus-backup. Achieve >99% query latency reduction with zero data loss.
Context Engineering Strategies for AI Agents: A Developer’s Guide
Learn practical context engineering strategies for AI agents. Explore frameworks, tools, and techniques to improve reliability, efficiency, and cost.
Balancing Precision and Performance: How Zilliz Cloud's New Parameters Help You Optimize Vector Search
Optimize vector search with Zilliz Cloud’s level and recall features to tune accuracy, balance performance, and power AI applications.