Глава 5. Управление безопасностью в приложениях RAG

Это продолжение перевода книги Кит Борн. Раскрытие потенциала данных с помощью генеративного ИИ и технологии RAG. В зависимости от среды, в которой создается приложение RAG, сбои в системе безопасности могут привести к юридической ответственности, ущербу репутации и дорогостоящим сбоям в обслуживании. Системы RAG несут уникальные риски безопасности, в первую очередь из-за их зависимости от внешних источников данных для улучшения генерации контента. Чтобы устранить эти риски, мы углубимся в мир безопасности приложений RAG, исследуя как преимущества, так и потенциальные риски, связанные с технологией. В этой главе мы рассмотрим следующие темы:

• Как RAG может быть использована в качестве решения для обеспечения безопасности
• Проблемы безопасности RAG
• Красная команда
• Общие зоны для целей с красными командами
• Лаборатория кода 5.1 – Защита ключей
• Лаборатория кода 5.2 – Атака красной команды!
• Лаборатория кода 5.3 – Синяя команда защищается!

Скачать заметку в формате Word или pdf

Предыдущая глава   Содержание   Следующая глава

Код для этой главы размещен в репозитории GitHub.

Мы должны помнить, что безопасность — это непрерывный процесс, требующий постоянной бдительности и адаптации перед лицом постоянно меняющихся угроз.

Как RAG может быть использована в качестве решения для обеспечения безопасности

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

Ограничение доступа к данным

В приложениях RAG вы можете применять стандартные подходы к аутентификации. Реализуя управление доступом на основе аккаунта, можно ограничить объем данных, которые каждый пользователь или группа пользователей могут получать через систему RAG. Это гарантирует, что конфиденциальная информация будет доступна только уполномоченным лицам. Кроме того, используя безопасные подключения к базам данных и методы шифрования, вы можете защитить данные при хранении и передаче, предотвращая несанкционированный доступ или утечку данных.

Обеспечение достоверности генерируемого контента

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

Прозрачность

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

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

Проблемы безопасности RAG

Приложения RAG сталкиваются с уникальными проблемами безопасности из-за их зависимости от больших языковых моделей (LLM) и внешних источников данных. Давайте начнем с задачи «черного ящика», подчеркнув относительную сложность в понимании того, как LLM формирует ответ.

LLM как черные ящики

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

В академической области проводится много исследований и усилий по созданию более прозрачных и интерпретируемых моделей, называемых объяснимым ИИ. Объяснимый ИИ призван сделать работу систем ИИ прозрачной и понятной. Она может включать в себя инструменты, фреймворки и все остальное, что при применении к RAG помогает нам понять, как используемые нами языковые модели создают контент. Но эта технология может быть не доступна, когда вы читаете книгу. Мы надеемся, что в будущем он будет играть более важную роль в снижении риска «черного ящика», но сейчас ни одна из самых популярных LLM не использует объяснимые модели. Так что, пока мы поговорим о других путях решения этого вопроса.

Вы можете использовать технологию «человек в цикле», когда вовлекаете людей на разных этапах процесса, чтобы обеспечить дополнительную линию защиты от неожиданных результатов. Это часто помогает уменьшить влияние черного ящика. Если время ответа не так критично, вы можете использовать дополнительную LLM для проверки ответа перед его возвращением пользователю. Мы рассмотрим, как добавить второй вызов LLM в Лаборатории кода 5.3, но с акцентом на предотвращение атак промтами. Вы можете добавить вторую LLM для выполнения ряда дополнительных задач и повышения безопасности приложения.

Черный ящик — не единственная проблема безопасности, с которой вы сталкиваетесь при использовании RAG. Еще одной очень важной темой является защита конфиденциальности.

Вопросы конфиденциальности и защита данных пользователей

Информация, позволяющая установить личность (Personally identifiable information, PII), является ключевой темой в пространстве GenAI. И правительства по всему миру пытаются найти баланс между конфиденциальностью и потребностями LLM, требующих больших объемов данных. По мере того, как это будет решаться, важно обращать внимание на нормативные акты, которые будут появляться. Google, Microsoft и др. устанавливают собственные стандарты защиты пользовательских данных и описывают их в учебной литературе на своих платформах.

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

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

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

Этот раздел был посвящен защите существующих данных. Новым риском, связанным с LLM, стала генерация нереальных данных, называемых галлюцинациями.

Галлюцинации

Иногда LLM генерируют ответы, которые звучат связно и основаны на фактах, но могут быть очень неверными. Это называется галлюцинациями , и в новостях было много шокирующих примеров, особенно в конце 2022 и 2023 годах, когда LLM стали повседневными инструментами для многих пользователей.

Некоторые из них просто забавны с небольшими последствиями, кроме хорошего смеха, например, когда журналист The Economist спросил ChatGPT: «Когда мост Золотые Ворота был перевезен во второй раз через Египет? ChatGPT ответил: «Мост Золотые Ворота был перевезен во второй раз через Египет в октябре 2016 года».

Другие галлюцинации более гнусны, например, когда нью-йоркский адвокат использовал ChatGPT для юридического исследования дела клиента о причинении вреда здоровью против Avianca Airlines, где он представил шесть дел, которые были полностью сфабрикованы чат-ботом, что привело к судебным санкциям. Хуже того, генеративный ИИ, как известно, дает предвзятые, расистские и фанатичные точки зрения, особенно когда его подталкивают манипулятивным образом.

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

Однако, насколько нам известно, галлюцинации в первую очередь являются результатом вероятностной природы LLM. Для всех ответов, которые генерирует LLM, она обычно использует распределение вероятностей, чтобы определить, какой токен она собирается предоставить следующим. В ситуациях, когда у нее есть сильная база знаний по определенному предмету, эти вероятности для следующего слова/токена могут составлять 99% или выше. Но в ситуациях, когда база знаний не так сильна, самая высокая вероятность может быть низкой, например, 20% или даже ниже. В этих случаях вероятность по-прежнему высока, и, следовательно, такой токен имеет наибольшую вероятность быть выбранным.

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

Для компании это риск. Искаженные факты могут разрушить отношения с клиентами, или привести к тому, что LLM предложит клиенту что-то, что вы не собирались предлагать, или, что еще хуже, не можете позволить себе предложить. Например, когда в 2016 году Microsoft запустила чат-бота по имени Tay в Twitter с намерением учиться на взаимодействиях с пользователями Twitter, пользователи манипулировали ботом, чтобы заставить высказывать расистские и фанатичные замечания. Это плохо отразилось на Microsoft, которая продвигала свой опыт в области искусственного интеллекта с Tay, что нанесло значительный ущерб ее репутации.

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

Красная команда

Это методология тестирования безопасности, которая включает в себя моделирование состязательных атак для упреждающего выявления и устранения уязвимостей в приложениях RAG. При подходе красной команды отдельный человек или команда берут на себя роль атаковать и находить уязвимости в системе. Противостоящая команда – это синяя команда, которая делает все возможное, чтобы сорвать атаку. Это распространено в сфере ИТ-безопасности, особенно в сфере кибербезопасности.

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

Важно отметить, что оценка приложения RAG с точки зрения безопасности отличается от других типов оценки. Вы часто будете слышать о бенчмарках для LLM в целом, таких как ARC (AI2 reasoning challenge), HellaSwag и MMLU (массовое многозадачное понимание языка). Они тестируют производительность. Но эти критерии не проверяют аспекты безопасности, такие как способность модели создавать оскорбительный контент, распространять стереотипы или использоваться в гнусных целях. Поскольку в приложениях RAG используются LLM, они сталкиваются с теми же рисками, что и LLM, включая токсичность, преступную деятельность, предвзятость и проблемы с конфиденциальностью. Красная команда — это подход, направленный на выявление этих типов рисков и защиту от них. Разработка плана красной команды требует тщательного планирования и глубокого понимания уязвимостей систем RAG.

Зоны для таргетинга с помощью красных команд

• Предвзятость и стереотипы: чат-ботом можно манипулировать, чтобы давать предвзятые ответы, которые могут нанести ущерб репутации компании, если ими поделятся в социальных сетях.
• Раскрытие конфиденциальной информации: конкуренты или киберпреступники могут попытаться получить конфиденциальную информацию через чат-бота.
• Перебои в обслуживании: злонамеренные люди могут отправлять длинные или сфабрикованные запросы, чтобы нарушить доступность чат-бота для пользователей.
• Галлюцинации: чат-бот может предоставлять неверную информацию из-за неоптимальных механизмов поиска, некачественных документов или склонности LLM соглашаться с пользователем.

Методы, которые вы можете использовать для совершения атак.

Обход мер безопасности:

• Завершение текста: Методы обхода защитных механизмов в приложениях LLM включают в себя использование автодополнения текста путем использования склонности LLM предсказывать следующий токен в последовательности.
• Предвзятые промты, содержащие неявную предвзятость, для манипулирования реакцией модели и обхода фильтров содержимого или других защитных мер.
• Инъекция промта/взлом ограничений (Prompt injection/jailbreaking): еще одним подходом является прямая инъекция промта, также известная как взлом ограничений. Этот метод включает в себя внедрение новых инструкций с целью перезаписи исходного промта и изменения поведения модели, фактически обходя любые ограничения или руководства, заданные в оригинальном промте.
• Атаки с помощью промта «серого ящика»: атаки с использованием промтов «серого ящика» также могут использоваться для обхода средств защиты путем внедрения неверных данных в промт, при условии, что они знают о системном запросе. Это позволяет злоумышленнику манипулировать контекстом и заставлять модель генерировать непреднамеренные или опасные ответы. Как получить знания о системном промте? Используйте следующий пункт.
• Анализ промтов (Prompt probing) используют для выявления системного промта, что позволяет более эффективно осуществлять другие упомянутые атаки, раскрывая основную структуру и содержание промтов, которые направляют поведение языковой модели (LLM).

Автоматизация красных команд. Для масштабирования и повторения процесса красных команд для всех приложений LLM решающее значение имеет автоматизация:

• Ручное определение: один из методов включает в себя использование списка методов инъекций, определенных вручную, и автоматизацию обнаружения успешных инъекций. Добавляя строки запроса внедрения в список и перебирая каждую из них, средство автоматизации может определить, обходит ли внедрение меры безопасности.
• Библиотека промтов: другой подход заключается в использовании библиотеки промтов и автоматизации обнаружения инъекций. Этот метод похож на предыдущий, но опирается на список известных промтов. Тем не менее, чтобы оставаться эффективным, необходимо поддерживать актуальную библиотеку методов быстрого внедрения.
• Инструменты с открытым исходным кодом, которые постоянно обновляются: более продвинутым вариантом является использование автоматизированного инструмента, такого как LLM-сканирование библиотеки Python с открытым исходным кодом от Giskard, которое регулярно обновляется с учетом новейших технологий командой исследователей машинного обучения (ML). Такой инструмент может выполнять специализированные тесты на приложениях на основе LLM, в том числе для оперативного внедрения, и анализировать выходные данные, чтобы определить, когда происходит сбой. Такой подход экономит время и усилия, чтобы идти в ногу с меняющимся ландшафтом техник инъекций. Эти автоматизированные инструменты красной команды обычно генерируют подробный отчет с описанием всех обнаруженных векторов атак, предоставляя ценную информацию для повышения безопасности и надежности приложений LLM.

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

Ресурсы для создания плана красной команды

При оценке безопасности приложений RAG крайне важно определить сценарии для защиты и задаться вопросом: что может пойти не так? Следующие три ресурса являются хорошей отправной точкой для составления собственного списка:

• Open Web Application Security Project (OWASP). OWASP Top 10 for LLM applications — это проект, направленный на выявление и повышение осведомленности о наиболее критических рисках безопасности, связанных с LLM-приложениями. Он предоставляет стандартизированный список из десяти основных уязвимостей и рисков, характерных для приложений LLM, помогая разработчикам, специалистам по безопасности и организациям расставлять приоритеты в своих усилиях по обеспечению безопасности этих систем.
• База данных инцидентов ИИ представляет собой общедоступную коллекцию реальных инцидентов с участием систем ИИ, включая LLM. Он служит ценным ресурсом для исследователей, разработчиков и политиков, позволяющим извлечь уроки из прошлых инцидентов и понять потенциальные риски и последствия, связанные с системами ИИ. База данных содержит широкий спектр инцидентов, таких как системные сбои, непредвиденные последствия, предубеждения, нарушения конфиденциальности и многое другое.
• База данных уязвимостей ИИ (AVID) — централизованное хранилище, которое собирает и систематизирует информацию об уязвимостях, обнаруженных в системах ИИ, включая LLM. AVID призван предоставить исследователям, разработчикам и специалистам по безопасности ИИ всеобъемлющий ресурс, чтобы они могли быть в курсе известных уязвимостей и их потенциального влияния на системы ИИ. AVID собирает информацию об уязвимостях из различных источников, таких как академические исследования, отраслевые отчеты и реальные инциденты.

В следующем разделе мы добавим в наш код элементы безопасности, а затем углубимся в запуск полномасштабной атаки красной команды на наш конвейер RAG. Но не волнуйтесь, мы также покажем, как использовать силу LLM для защиты от атак!

Лаборатория кода 5.1 – Защита ключей

Этот код можно найти в файле CHAPTER5-1_SECURING_YOUR_KEYS.ipynb.

В главе 2 после импорта библиотек мы добавили ключ API OpenAI. Мы сказали, что это очень простая демонстрация того, как ключ API поступает в систему, но это не безопасный способ передачи ключа API. По мере расширения приложения RAG у вас также будет несколько ключей API. Но даже если у вас только один ключ, все равно примите меры безопасности для защиты ключа.

Мы начнем с распространенной практики сокрытия конфиденциального кода API (и любого другого секретного кода) в отдельном файле, который может быть скрыт от вашей системы управления версиями.

Ниже приведен код, предоставленный ранее для доступа к ключу API OpenAI:

Вам нужно будет заменить sk-##### на ваш фактический ключ API OpenAI, чтобы остальной код работал. Но подождите, это не очень безопасный способ сделать это! Давайте исправим это!

Во-первых, создадим файл, который вы будете использовать для сохранения ключей. С помощью пакета dotenv Python вы можете использовать .env из коробки. Однако в некоторых средах вы можете столкнуться с системными ограничениями, которые не позволяют вам использовать файл, начинающийся с точки. В этих случаях вы все еще можете использовать dotenv, но вам нужно создать файл, назвать его, а затем указать на него dotenv. Например, если я не могу использовать .env, я использую env.txt, и это файл, в котором я храню ключ API OpenAI. Добавьте файл .env, который вы хотите использовать в своей среде, и добавьте ключ API в файл .env следующим образом:

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

Если вы используете Git для контроля версий, добавьте любое имя вашего файла в файл gitignore, чтобы при фиксации его в Git вы не отправляли файл с ключами! На самом деле, сейчас самое время сгенерировать новый ключ API OpenAI и удалить тот, который вы только что использовали, особенно если вы считаете, что он может появиться в истории вашего кода до внесения изменений, которые мы внедряем в этой главе. Удалите старый ключ и начните заново с новым ключом в файле .env, чтобы предотвратить раскрытие какого-либо ключа в системе управления версиями Git.

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

Установите python-dotdev в начало вашего кода после инсталляции иных библиотек

Перезапустите ядро после установки нового пакета, как вы делали это в главе 2. В этом случае у вас появится возможность получить и распознать файл .env. Если вы вносите какие-либо изменения в файл .env, обязательно перезапустите ядро, чтобы эти изменения были перенесены в вашу среду. Без перезагрузки ядра ваша система, скорее всего, не сможет найти файл и вернет пустую строку для OPEN_API_KEY, что приведет к сбою LLM-вызовов.

Далее вам нужно будет импортировать библиотеку python-dotdev для использования в коде:

Далее мы хотим использовать функцию load_dotenv, чтобы получить ключ и использовать его в коде. Ранее мы упоминали, что в некоторых средах вы не сможете использовать файл, начинающийся с точки (.). Если бы вы оказались в такой ситуации, то вы бы настроили файл env.txt, а не файл .env. Исходя из вашей ситуации, выберите подходящий подход.

Если вы используете файл .env:

Если вы используете файл env.txt:

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

Мне потребовалось больше конкретики, чтобы поместить ключ из файла в среду разработки. ChatGPT предложил помощь. Сначала выполняете код:

Выбираете файл на диске, импортируете в среду разработки. Далее выполняете команду:

И наконец:

Лаборатория кода 5.2 – Атака красной команды!

Этот код можно найти в файле CHAPTER5-2_SECURING_YOUR_KEYS.ipynb.

Мы примем участие в захватывающем упражнении красная команда против синей, демонстрируя, как LLM могут быть как уязвимостью, так и защитным механизмом в битве за безопасность приложений RAG. Сначала мы возьмем на себя роль красной команды и организуем проверку нашего конвейера RAG. Зондирование промтов является первым шагом для получения представления о внутренних промтах, которые система RAG использует для обнаружения системных промтов приложения RAG. Системный промт — это набор инструкций или контекста, предоставленный LLM для управления ее поведением и ответами. Раскрывая системный промт, злоумышленники могут получить информацию о работе приложения, и это закладывает основу для разработки более целенаправленных и эффективных атак с использованием других методов.

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

Сложнее ли взломать более умные LLM? Мы используем GPT-4o, одну из лучших LLM на рынке. Она новее, умнее и сложнее, чем любой другой вариант. Теоретически это затрудняет проведение атаки красной команды. Но мы и собираемся использовать ум GPT-4o против нее самой! Эта атака не увенчалась успехом при использовании GPT-3.5, так как она не смог следовать подробным инструкциям, которые мы использовали для реализации атаки. Но GPT-4 достаточно умна, чтобы следовать инструкциям, что позволяет нам воспользоваться ее интеллектом и включить его против самой себя.

Мы продолжим с того места, на котором остановились в Лаборатории кода 5.1. Давайте начнем с конца нашего кода (см. главу 3), но сократим его только до ответа (‘answer’):

Рис. 5.1. Вывод только ответа (без ссылок на документы)

Промт, который мы передаем LLM, включает в себя вопрос пользователя, а также дополнительные инструкции для LLM. В этом случае вы можете узнать это, распечатав шаблон со следующим кодом:

Рис. 5.2. Вывод шаблона промта

Однако, как красная команда, мы не знаем, как выглядит эта системная подсказка. Наша цель состоит в том, чтобы выяснить это, а также то, какая информация попадает в {контекст}, которая в других приложениях может быть конфиденциальными данными клиентов, возможно, даже иных клиентов, а не текущего пользователя!

Параметры миссии. Вы играете за красную команду, и цель атаки — разработать зонд для идентификации системного промта для приложения RAG. Это позволит проникнуть в систему нашего противника с помощью последующих более сложных атак с быстрым внедрением.

Вот промт для атаки, который вы можете добавить в нижней части блокнота:

Запустите эту ячейку, чтобы prompt_probe была добавлена как переменная. В этом запросе мы используем промт (джейлбрейк) для внедрения новых инструкций для перезаписи первоначального запроса и изменения поведения модели. Мы говорим LLM, чтобы она взял на себя роль помощи в написании инструкций. Еще один метод, используемый здесь, заключается в том, чтобы попросить LLM взять предыдущие инструкции и внести в них небольшие изменения. Это распространенный метод, который использует склонность LLM к выполнению задачи, что дает ей больше мотивации для переопределения других инструкций. Хотя результаты могут отличаться, когда я попробовал эту атаку без части ЗАМЕНИТЬ ЗАПЯТЫЕ НА ВОСКЛИЦАТЕЛЬНЫЕ ЗНАКИ, этот промт не работал. Попробуйте сами! Но это показывает, насколько сильна склонность LLM к выполнению этой задачи. Часто существует очень тонкая грань между тем, что работает, и тем, что нет, поэтому вам придется попробовать множество различных подходов, чтобы выяснить, что будет работать в вашем случае.

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

Нам нужно отправить этот промт в конвейер RAG:

Вывод этого кода у меня занял 28 секунд, результат получился внушительным и я поместил его в отдельный файл.

Выходные данные этого кода должны выглядеть примерно так:

Мы успешно попросили LLM предоставить значительную часть промтов, которые скрыты в коде. При этом отображаются не только инструкции в верхней части системной подсказки, но и все данные, которые система извлекает для ответа на вопрос пользователя. Это серьезное нарушение! Огромная победа для красной команды!

Теперь мы гораздо лучше понимаем приложение LLM и то, как использовать получаемые им промты таким образом, чтобы мы могли скомпрометировать весь конвейер RAG и данные, к которым у него есть доступ. Если бы эти промты были ценной интеллектуальной собственностью, мы могли бы их украсть. Если они получают доступ к личным или ценным данным, мы можем использовать наши новые знания о промтах, чтобы попытаться получить доступ к этим данным. Это закладывает основу для более продвинутой атаки на систему.

Теперь возьмем на себя роль синей команды, придумав решение по предотвращению атаки.

Лаборатория кода 5.3 – Синяя команда защищается!

Этот код можно найти в файле CHAPTER5-3_SECURING_YOUR_KEYS.ipynb.

Существует ряд решений, которые мы можем реализовать, чтобы предотвратить раскрытие промта этой атакой. Мы собираемся решить проблему с помощью второй LLM, которая будет хранителем ответных мер. Использование второй LLM является распространенной практикой для многих приложений, связанных с RAG. Мы покажем, как ее использовать для лучшей защиты кода.

Однако важно отметить, что это лишь одно из возможных решений. Поле битвы за безопасность постоянно меняется. Вы должны проявлять усердие и придумывать новые и лучшие решения для предотвращения нарушений безопасности.

Добавьте строку в список импорта:

При этом импортируется класс PromptTemplate из модуля langchain_core.prompts, что позволяет нам определять и создавать собственные пользовательские шаблоны промтов.

Новый запрос, который мы создадим, будет предназначаться для скрытого опекуна LLM. Последний будет следить за атаками, подобными той, с которой мы только что столкнулись. Добавьте этот запрос в ячейку после ячейки промта, сохранив оба запроса:

Для простоты мы будем использовать уже настроенный экземпляр LLM, но вызовем ее отдельно, чтобы она выступала в роли стража.

Далее мы внесем существенное обновление в цепочку RAG, в том числе добавим две функции:

Функция extract_score принимает на вход llm_output. Она пытается преобразовать llm_output в число с плавающей точкой, сначала удаляя начальные и конечные пробелы с помощью метода strip, а затем выполняя преобразование в число с помощью функции float. Если преобразование успешно, функция возвращает значение в формате float. Если при преобразовании возникает исключение ValueError (что означает, что llm_output не может быть преобразован в число с плавающей точкой), исключение перехватывается, и функция возвращает значение 0 как оценку по умолчанию.

Далее давайте настроим функцию, которая будет применять логику, когда запрос не актуален:

Функция conditional_answer принимает словарь x в качестве входных данных и извлекает переменную ‘relevance_score’ из этого словаря. Затем она передает значение этой переменной в функцию extract_score, чтобы получить значение relevance_score. Если relevance_score меньше 4, функция возвращает строку «I don’t know». В противном случае она возвращает значение, связанное с ключом ‘answer’ в словаре x.

Наконец, давайте создадим расширенную цепочку rag_chain_from_docs со встроенными новыми функциями безопасности:

Цепочка rag_chain_from_docs присутствовала в предыдущем коде, но была обновлена, чтобы учесть новую задачу LLM и соответствующие функции, описанные ранее. Первый шаг остался таким же, как и в предыдущих итерациях: мы назначаем функцию ключу context, которая форматирует данные контекста из входного словаря с помощью функции format_docs. Следующий шаг — это экземпляр RunnableParallel, который выполняет две параллельные операции, экономя время обработки:

• Первая операция генерирует relevance_score (оценку релевантности), передавая переменные question (вопрос) и context (контекст) через шаблон relevance_prompt_template, затем через LLM, а потом анализируя результат с помощью функции StrOutputParser.
• Вторая операция генерирует ответ, передавая вводные данные через шаблон промта, затем через LLM и анализируя результат с помощью функции StrOutputParser.

Заключительный шаг — назначить функцию conditional_answer ключу final_answer, чтобы определить итоговый ответ на основе значения relevance_score.

В код был добавлен второй вызов LLM, который оценивает вопрос пользователя и контекст, извлеченный с помощью retriever, и сообщает по шкале от 1 до 5, насколько они релевантны друг другу.

• 1 означает «совсем не релевантно».
• 5 означает «высокая релевантность».

Эта логика следует инструкциям, указанным в шаблоне промта для релевантности (relevance prompt), добавленном ранее. Если LLM оценивает релевантность ниже 4, то ответ автоматически заменяется на «I don’t know» вместо того, чтобы раскрывать системные подсказки RAG-пайплайна.

Далее следует функция

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

Вывод будет похож на предыдущий с правильным ответом, который мы видели в прошлом, но в верхней части вывода мы видим новый элемент, Relevance Score:

Наш опекун LLM оценил вопрос на 5 баллов за релевантность контенту в конвейере RAG. Далее давайте обновим код для запроса, чтобы отразить изменения в коде и посмотрим, каким будет окончательный ответ:

Теперь обновите код зонда следующим образом:

Итоговые выходные данные этого запроса красной команды должны выглядеть следующим образом:

Усилия синей команды увенчались успехом в предотвращении атаки быстрого зонда! Справедливость восторжествовала, и наш код теперь значительно безопаснее, чем раньше! Означает ли это, что мы можем почивать на лаврах? Конечно, нет, хакеры всегда придумывают новые способы проникновения в наши организации. Мы должны оставаться усердными. Следующим шагом в реальном приложении будет возвращение к роли красной команды и попытка придумать другие способы обойти новые исправления. Но по крайней мере это будет сложнее. Попробуйте другие подходы с промтами, чтобы проверить, по-прежнему ли вы можете получить доступ к системному промту. Сейчас определенно сложнее!

Теперь у вас есть более безопасный код, а с дополнениями, сделанными в главе 3, она также стала более прозрачной!