Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Языковая модель может реже отклонять безобидные запросы и при этом сохранять сопоставимую защиту от вредных. В препринте Minji Kim и Hyounghun Kim, который не проходил рецензирование и содержит результаты, полученные самими авторами, этого добились после удаления шаблонной фразы отказа из обучающего ответа и сохранения только объяснения причины. Для команд, которые сами настраивают безопасность LLM, это переносит внимание с архитектуры фильтра на устройство обучающего набора.
Шаблон отказа превращается в поверхностную подсказку
Ложным отказом называют ситуацию, когда модель отклоняет безопасный запрос, потому что тот похож на вредный по формулировке. Например, запрос о том, где лучше снимать фотографии, может содержать те же слова, что и запрос о стрельбе в человека, хотя намерения у них разные.
Ответы в наборах для настройки безопасности обычно соединяют две части. Первая — стандартная фраза вроде сообщения о невозможности помочь. Вторая объясняет, почему запрос нарушает правила: указывает на вредное действие, намерение или возможные последствия.
Повторяющаяся фраза отказа упрощает задачу во время обучения. Она часто встречается рядом с потенциально опасными словами, поэтому модель начинает использовать такие слова как достаточный сигнал для запрета. Ей уже не обязательно разбирать смысл запроса и отличать реальный риск от случайного сходства.
Объяснение причины устроено иначе. Чтобы связать его с запросом, модели приходится учитывать не отдельное слово, а отношение между действием, намерением и правилом безопасности. Поэтому обучающий сигнал точнее описывает границу между тем, на что следует отвечать, и тем, что нужно отклонить.
Объяснение снижает ложные отказы без явной потери защиты
Работа сравнивает обучение на полном ответе с вариантом, где от ответа оставляют только объяснение причины запрета. Во втором случае модель реже отказывает на безопасные запросы, которые содержат внешне рискованные слова. Уровень безопасности на вредных запросах остаётся сопоставимым.
Тот же эффект проявился, когда примеры давали модели прямо в запросе, без дополнительного обучения. Это важно для систем, где поведение задают инструкцией и несколькими демонстрациями: повторяющиеся формулы отказа могут влиять на решение так же, как примеры в обучающем наборе.
Подход также оказался совместим с проверенными в работе способами снижать ложные отказы во время генерации. Совместимость здесь не означает, что методы обязательно усиливают друг друга: из доступного описания следует только то, что обучение на объяснениях не мешает применять их вместе.
Проверка охватывает обучение только на объяснениях, примеры внутри запроса и сочетание с методами, которые работают на этапе ответа. Поскольку материал подготовлен по абстракту, а не по полному тексту, подробный протокол экспериментов из доступного описания не восстанавливается.
Командам стоит менять структуру данных, а не политику отказов
Работа меняет планы прежде всего тех команд, которые дообучают собственную модель или собирают набор примеров для настройки безопасности. Фразу отказа и объяснение причины полезно хранить как отдельные поля, даже если в готовом интерфейсе они снова образуют единый ответ. Тогда можно проверить, какая часть примера учит модель распознавать риск, а какая создаёт нежелательную связь с отдельными словами.
Следующий практический шаг — сравнивать варианты настройки по двум независимым направлениям. Вредные запросы показывают, сохраняет ли модель защиту. Безопасные запросы с похожей лексикой показывают, не стала ли она чрезмерно осторожной. Если измерять только долю заблокированных опасных запросов, ухудшение полезности останется незаметным.
Для систем, которые управляют моделью через примеры в запросе, вывод ещё проще: не стоит заполнять все отрицательные примеры одинаковой формулой запрета. Объяснение конкретной причины даёт модели более содержательный образец и снижает вероятность того, что она превратит отдельное слово в универсальный признак опасности.
Если продукт использует только готовый API и не управляет обучающими данными, работа сама по себе не требует менять поставщика или модель. Её можно применить к проверочному набору: добавить безопасные запросы с внешне рискованными формулировками и отдельно следить за ложными отказами.
Вывод относится именно к обучающему сигналу, а не к тому, как должен выглядеть окончательный ответ пользователю. Шаблон отказа может оставаться частью интерфейса или требований продукта; работа показывает, что его не обязательно превращать в повторяющийся образец, по которому модель учится распознавать вред.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
