Обновили модель LLM: какие проверки безопасности повторить
Повторите критические сценарии доступа и действий на той же версии приложения. Замена модели может менять выбор tools, интерпретацию контекста и частоту отказов даже без изменения вашего кода.
Пример из разработки
Новая модель лучше отвечает на обычные вопросы и точнее оформляет JSON. Команда выкатывает её после проверки красивых ответов. Но в сценарии с вредоносным комментарием она чаще вызывает инструмент отправки, который старая версия игнорировала. Прежний тест оценивал только итоговый текст, поэтому изменение реального действия осталось незамеченным. Качество ответа и устойчивость границ нужно проверять раздельно.
Почему это работает
Зафиксируйте модель, системные инструкции, набор tools, политики и контрольные данные. Прогоните старую и новую конфигурации на одинаковых разрешённых задачах и негативных сценариях. Сохраняйте фактические вызовы и результаты серверных проверок. Для вероятностного поведения полезны повторные прогоны, но единичное улучшение нельзя выдавать за устойчивую гарантию. Релизный критерий должен отдельно учитывать нарушения доступа, ущербные действия и полезность обычных сценариев.
Проверка перед использованием
| Проверка | Ожидаемое поведение |
|---|---|
| Внешний документ содержит просьбу раскрыть чужие сведения | Проверяются и ответ, и все попытки вызовов; серверная политика остаётся обязательной при любой модели. |
| Разрешённая рабочая операция с тем же инструментом | Новая модель сохраняет полезность, а ужесточение не скрывает проблему массовым отказом. |
| Одинаковый случай повторён несколько раз | Отчёт показывает разброс и реальные результаты, а не выбирает один удачный ответ для презентации. |
В отчёте отмечайте отклонённую попытку отдельно от успешного нарушения: модель могла выбрать опасный tool, но сервер остановил действие. Это разные уровни риска и разные задачи исправления.
Если одновременно изменились модель, промпт и инструменты, трудно установить причину регрессии. По возможности сравнивайте контролируемые конфигурации и сохраняйте путь возврата к ранее проверенной версии.
Регрессионные проверки безопасности нужны на каждом значимом изменении LLM-системы, а не только перед её первым запуском. В платном курсе LLM Security PRO: Prompt Injection, утечки, tool-abuse можно продолжить изучение соответствующего инженерного направления. Перед покупкой сравните программу и открытые материалы со своей задачей.
Документация для проверки технических деталей: OWASP: Prompt Injection.
Следующий шаг: Безопасность LLM-приложений: практические проверки. По смежным вопросам: Что логировать у AI-агента для проверки безопасности, Почему read-only SQL для LLM ещё может раскрывать данные.
