Корпоративная RAG-система кажется безопаснее публичного чат-бота: модель работает локально, документы не уходят во внешний API. Это снижает риски конфиденциальности, но не отвечает на другой вопрос — можно ли доверять содержимому самой базы знаний.

Если в индекс попал изменённый регламент, поддельная инструкция или специально подготовленный текст, модель может найти его и построить убедительный ответ. Взламывать веса при этом не обязательно: достаточно повлиять на канал, через который документы становятся «знанием».

Что подтверждено исследованиями

Работа PoisonedRAG, опубликованная на USENIX Security 2025, рассматривает целевое отравление базы знаний. Атакующий создаёт текст, который одновременно хорошо находится по выбранному вопросу и подталкивает модель к заранее заданному неверному ответу. В экспериментах авторов пять вредоносных текстов на целевой вопрос обеспечивали около 90% успешных атак даже в базе с миллионами документов.

Это лабораторный результат, а не прогноз для конкретной компании. Но он показывает важную вещь: большой корпус сам по себе не «разбавляет» отравление. Поиск выбирает наиболее релевантные документы, поэтому небольшой специально оптимизированный фрагмент может оказаться наверху.

В июле 2026 года авторы препринта TriShieldRAG предложили три уровня защиты: проверку на входе, оценку доверия при поиске и согласование ответа на этапе генерации. На тесте с 5 000 документами, десятью целевыми вопросами и неадаптивным атакующим полная схема снизила показатель успешной атаки примерно с 91% до 13%.

Эту цифру нельзя переносить в промышленную эксплуатацию как гарантию. Авторы прямо указывают, что не проверяли атакующего, который знает устройство защиты и подстраивается под неё; набор вопросов мал, а основную работу в эксперименте выполнил фильтр, заметивший агрессивный шаблон текста. Полезен не конкретный процент, а принцип: один фильтр недостаточен, и контроль должен охватывать весь путь документа.

Где отравление появляется в обычном бизнесе

Для атаки не всегда нужен внешний злоумышленник. Источником ошибочного знания может стать обычный процесс без владельца:

  • общий сетевой каталог, куда могут писать десятки сотрудников;
  • автоматический импорт вложений из почты или тикетов;
  • синхронизация с CRM, wiki, облачным диском или сайтом поставщика;
  • OCR сканов, где таблица или отрицание распознаны неверно;
  • устаревшая копия инструкции, которая осталась рядом с действующей;
  • сервисная учётная запись с избыточными правами;
  • подрядчик или сотрудник, который может опубликовать документ без второго контроля.

Случайное загрязнение создают ошибки, дубли и просроченные версии. Целевое отравление стремится попасть в поиск по конкретному вопросу. Архитектура должна обнаруживать оба класса, не пытаясь угадать намерение автора.

Защита начинается до векторной базы

Надёжный контур не индексирует файл сразу после загрузки. Между источником и рабочей коллекцией нужен шлюз приёма с карантином.

Для каждого объекта стоит сохранять неизменяемый оригинал и манифест:

  • стабильный `document_id` и номер версии;
  • криптографический хэш файла;
  • источник и способ получения;
  • владельца данных и автора изменения;
  • время загрузки, проверки и публикации;
  • класс доступа, срок действия и дату пересмотра;
  • связь с заменённой или отозванной версией;
  • версию парсера, OCR, разбиения и модели эмбеддингов.

Хэш не доказывает истинность документа. Он доказывает, что проверенная версия не была незаметно заменена. Происхождение тоже не должно быть свободным текстовым полем, которое может заполнить тот же импортёр. Его формирует доверенный шлюз из удостоверенной учётной записи, канала доставки и правил источника.

Право загрузить файл и право опубликовать его в рабочем индексе лучше разнести. Для критичных регламентов, цен, реквизитов, юридических формулировок и инструкций по безопасности нужен второй участник или формальное правило утверждения. Низкорисковые источники можно пропускать автоматически, но только по явному списку и с журналом.

Три рубежа вместо одного фильтра

1. Контроль при загрузке

В карантине проверяются формат, антивирусные правила, структура, язык, необычные повторения, скрытые элементы, резкие изменения объёма и совпадения с известными документами. Затем извлечённый текст сравнивается с предыдущей версией: что добавлено, удалено и какие факты изменились.

Автоматический анализ может назначить риск, но не должен объявлять документ истинным. Целевой текст можно переписать естественным языком, поэтому высокий риск требует ручной проверки, а низкий направляется в staging-индекс.

2. Контроль при поиске

Релевантность и доверие — разные признаки. Ранжирование должно учитывать не только близость вектора, но и утверждённый источник, актуальность версии, класс доступа и независимость документов.

Практические правила:

  • не позволять пяти фрагментам одной версии изображать пять независимых подтверждений;
  • ограничивать долю результатов от одного документа или источника;
  • поднимать действующий утверждённый регламент выше черновика;
  • отбрасывать отозванные версии до векторного поиска, а не после генерации;
  • возвращать с фрагментом его `document_id`, версию и происхождение;
  • для важных запросов искать подтверждение в отдельном доверенном корпусе.

Если все «независимые» проверки читают один и тот же отравленный индекс, независимости нет. Например, второй поиск другой формулировкой полезен для качества, но не является отдельным каналом доверия.

3. Контроль ответа

Модель должна видеть документы как данные, а не как инструкции. В системном правиле полезно требовать ссылки на конкретные версии источников, отмечать противоречия и отказываться от категоричного ответа, если подтверждений недостаточно.

Для действий с последствиями — изменение реквизитов, платежа, цены, статуса заказа или доступа — ответ RAG не должен быть исполнительной командой. Он формирует проект решения; бизнес-правила проверяются детерминированно, а человек утверждает действие. Это снижает ущерб и от отравления, и от обычной ошибки модели.

Как организовать публикацию и откат

Рабочую базу знаний удобно выпускать версиями. Новые документы сначала попадают в staging-коллекцию. На ней запускаются контрольные вопросы, проверка цитат, поиск противоречий и тесты доступа. После одобрения алиас переключается на новую версию корпуса. Предыдущая версия остаётся доступной для быстрого отката.

Снимок векторного индекса полезен, но его недостаточно. Восстановить нужно также оригиналы, манифесты, права доступа, правила разбиения и версию модели эмбеддингов. Иначе после отката получится другой набор фрагментов с тем же названием.

Минимальный план реакции на подозрение:

1. Остановить автоматическую публикацию, не удаляя следы.
2. Зафиксировать подозрительные `document_id`, версии, хэши и запросы, где они появлялись.
3. Переключить рабочий алиас на последнюю подтверждённую версию.
4. Пересобрать индекс из доверенных оригиналов, а не «почистить» отдельные векторы вручную.
5. Изменить `corpus_version` и сбросить связанные семантические и ответные кэши.
6. Повторить контрольный набор запросов и проверить права доступа.
7. Определить, какие ответы и бизнес-действия могли опираться на отозванные документы.

Что измерять руководителю

Для небольшого контура достаточно еженедельного отчёта:

  • сколько учётных записей может публиковать документы;
  • доля объектов без владельца, срока действия или подтверждённого источника;
  • время обнаружения и отката тестовой плохой версии;
  • доля ответов без проверяемой цитаты;
  • частота конфликтов между источниками;
  • концентрация top-k результатов на одном документе;
  • ложные срабатывания карантина;
  • результат контрольного набора после выпуска корпуса.

Главная бизнес-переменная — стоимость принятого неверного ответа. Для справочного поиска допустимо предупреждение; для реквизитов, договоров, охраны труда или платежей нужны независимая проверка и человек.

Экономика минимального контура

Большая часть базовой защиты не требует второй LLM. Дешёвый первый уровень — разнести роли, запретить прямую запись в производственный индекс, хранить версии и хэши, добавить staging и автоматический регрессионный набор. Основные затраты возникают в работе владельцев данных: кто подтверждает изменения и за какое время.

Считайте затраты от потока изменений. Если в базу приходит `D` документов в день, доля проверки равна `q`, а проверка занимает `t` минут, месячная ручная нагрузка примерно равна `D × q × t × рабочие дни / 60`. Снижать её лучше правилами доверенных источников и качественным диффом, а не отменой контроля.

Панель из нескольких моделей повышает стоимость и задержку. Малому бизнесу разумнее сначала закрыть запись и обеспечить откат; согласование моделей оставить для критичных запросов после собственного теста на русском корпусе.

Практический пилот на 30 дней

За первую неделю инвентаризируйте источники, владельцев, права записи и автоматические импорты. Затем выберите один процесс и сделайте версионируемый staging-контур. На третьей неделе соберите 30–50 контрольных вопросов с устаревшими версиями, противоречиями и безопасными имитациями отравления. На четвёртой проведите учебный откат с очисткой кэша и аудитом затронутых ответов.

Результат пилота — не только метрики модели, но и понятные роли: кто разрешает источник, публикует корпус, принимает инцидент и подтверждает восстановление.

Вывод

Локальная модель защищает периметр, но не делает знания истинными. Корпоративную RAG-базу следует обслуживать как производственную систему данных: с владельцем каждого источника, карантином изменений, доказуемым происхождением, раздельными правами, версионным выпуском, проверяемыми цитатами и отработанным откатом.

Начать можно без дорогой платформы: закройте прямую запись в индекс, выберите один критичный корпус и измерьте, удаётся ли за установленное время обнаружить плохую версию и полностью вернуть предыдущую. Если этот сценарий не проходит, добавлять новые модели и агентов рано.