Зачем не стоит ловить LLM-уязвимости с помощью другой LLM
Использовать громоздкую языковую модель как главный защитный барьер — дорогой, медленный и потенциально уязвимый подход. Эскалация от простых детекторов к тяжёлым моделям только при необходимости — экономичнее и надёжнее.
Делать из LLM-а судью для каждого запроса — всё равно что заставить старшего инженера вручную проверять каждый коммит. Дорого, медленно, и к обеду всё уже ломается.
Что на самом деле продают в этой статье
Разбор стоит начать с очевидного: текст опубликован на dev.to как sponsored content от компании Guardsquare. Это не нейтральная колонка эксперта, а продвижение продукта с демоссылкой. Понимание этого контекста важно — аргументы поданы не случайно, а выстроены так, чтобы привести читателя к одному выводу: «наш подход правильный».
Сама мысль, однако, при этом не лишена смысла. Стоит разобрать её по существу, отдельно от рекламной обёртки.
Проблема: LLM как единственный фильтр
Типичный паттерн в безопасности генеративных систем выглядит так: каждый входящий промпт пропускается через языковую модель, которая решает — вредоенный он или нет. Логика понятна: LLM хорошо понимает контекст, ловит семантические нюансы, справляется с вариациями атак, которые пропустят простые правила.
Но на практике это даёт сразу несколько проблем:
Задержка. Каждый запрос получает дополнительные сотни миллисекунд на инференс. Если ваш сервис обрабатывает тысячи запросов в минуту, это ощутимое замедление на каждом шаге.
Стоимость. Языковые модели крупного класса — платные за токен. При высоком трафике счёт растёт пропорционально.
Недетерминированность. Один и тот же вход может получить разные вердикты. Для безопасности это принципиальная проблема — вы не можете гарантировать, что вредоенный промпт будет заблокирован при повторной попытке.
Собственная уязвимость. LLM-фильтр сам по себе подвержен джейлбрейку. Атакующий может найти способ обойти проверку, используя те же механизмы, против которых эта проверка направлена.
Заметим, однако, что автор слегка упрощает картину. На практике серьёзные команды редко используют LLM как единственный слой — обычно он комбинируется с другими механизмами. Статья бьёт по strawman-аргументу, который не совсем отражает реальные архитектуры.
Предлагаемое решение: лесенка эскалации
Автор предлагает выстроить цепочку детекции от дешёвого к дорогому:
Уровень 1 — регулярные выражения. Поиск известных паттернов атак. Миллисекунды, нулевые затраты.
Уровень 2 — классическое ML. TF-IDF с логистической регрессией, обученный на десятках тысяч примеров атак. Около 7 миллисекунд, тоже бесплатно. Подавляющее большинство запросов не проходит дальше этого уровня.
Уровень 3 — трансформер (опционально). Более тяжёлая модель для глубокого анализа подмножества запросов.
Уровень 4 — ваша LLM (bring your own). Только для по-настоящему неоднозначных случаев. Модель выбираете вы, ключи ваши, лимит бюджета — ваш.
Экономика переворачивается: вместо оплаты LLM за 100% трафика вы платите за крошечную долю запросов, которые действительно требуют экспертного суждения.
Честные компромиссы
Здесь нужно остановиться и честно обозначить, о чём автор умалчивает.
Deterministic — не значит надёжно. Автор подчёркивает, что нижние уровни детерминированы. Это правда, но детерминированность — не синоним качества. Регулярки и лёгкие классификаторы хуже справляются с новыми, нестандартными атаками. Автор это признаёт одной фразой про «честный компромисс», но значимость этого факта не стоит недооценивать: именно новые, нестандартные атаки чаще всего приводят к реальным инцидентам.
«Air-gapped» звучит красиво, но не является уникальным преимуществом. Любой фильтр на регулярках или лёгкой ML-модели можно запускать локально. Это не специфика именно этого подхода, а свойство простых моделей в целом.
Классификация «вредоенный / не вредоенный» — лишь часть задачи. Современная безопасность LLM-систем включает защиту от инъекций промптов, контроль галлюцинаций, фильтрацию персональных данных, соответствие регуляторным требованиям. Статья фокусируется на узком сценарии — и это нормально для технического поста, но не стоит экстраполировать вывод на всю проблематику.
Что из этого извлечь
Несмотря на рекламную природу материала, базовая инженерная интуиция верна: не используйте самое дорогое средство там, где достаточно дешёвого. Это не только про безопасность LLM — это про архитектуру в целом.
Эскалация от простых детекторов к тяжёлым моделям — проверенная стратегия. Похожие принципы работают в спам-фильтрах, системах обнаружения вторжений, модерации контента. Лёгкие правила срабатывают на 80–90% трафика, а ресурсоёмкие модели подключаются только для оставшихся процентов.
В контексте LLM-безопасности это особенно актуально, потому что стоимость ошибки здесь выше: пропущенная атака может привести к утечке данных или компрометации системы, а чрезмерная фильтрация ломает пользовательский опыт.
Вывод простой: архитектурное решение важнее конкретного инструмента. LLM — мощный компонент, но не волшебная таблетка, и использование его как тупого фильтра для каждого запроса — признак плохого проектирования, а не продвинутой безопасности.