Суть. Надёжность решения на модели создаётся не уговорами в промпте, а кодом вокруг неё: что можно на входе, что проверяется на выходе, какие действия требуют подтверждения и что записывается. Модель нельзя «попросить быть надёжной» — её поведение вероятностно по устройству.
Четыре слоя
| Слой | Что проверяет | Пример |
|---|---|---|
| Вход | Что попадает в запрос | Удаление персональных данных, ограничение длины, отсечение недопустимых тем |
| Выход | Формат и содержание ответа | Обязательные поля, ссылка на источник, отсутствие выдуманных реквизитов |
| Действия | Что модели разрешено делать | Черновик — можно, отправка клиенту — с подтверждением |
| Журнал | Что произошло и почему | Запрос, контекст, ответ, вызванные инструменты |
Главное правило
Действия делятся на обратимые и необратимые. Обратимые — черновик, внутренняя пометка, предложение. Необратимые — отправка, изменение суммы, удаление. Самостоятельность расширяется только на обратимых; необратимые остаются с подтверждением человека дольше, чем кажется необходимым.
Когда применять
Как только система на основе языковой модели становится доступна кому-то кроме команды разработки. Ограничители — это не защита от злоумышленника в первую очередь, а защита от обычного пользователя, который задаст вопрос за пределами замысла, и от самой модели, которая ответит уверенно и неверно.
Четыре уровня
| Уровень | Что делает | Пример |
|---|---|---|
| На входе | Отсекает запросы вне области применения | Вопрос про политику в системе подбора оборудования |
| В подсказке | Задаёт правила: отвечать только по найденному, признавать незнание | Требование указывать источник |
| На выходе | Проверяет ответ до показа пользователю | Есть ли ссылка на документ, нет ли персональных данных |
| На действии | Ограничивает то, что система может сделать | Запрет на отправку письма без подтверждения человеком |
Четвёртый уровень появляется вместе с агентами и оказывается самым важным: ошибка в тексте раздражает, ошибка в действии стоит денег.
Правила проектирования
- Список запрещённого бесконечен, список разрешённого конечен — описывать нужно второе.
- Каждый ограничитель должен иметь проверочный случай в наборе оценки, иначе о его поломке никто не узнает.
- Отказ должен быть полезным: не «не могу ответить», а «этого нет в базе, обратитесь туда-то».
- Действия делятся на обратимые и необратимые; вторые всегда требуют подтверждения человеком.
- Все срабатывания журналируются — это единственный способ понять, где ограничитель мешает работе.
Где ломается
Всё держится на формулировке промпта. Достаточно одного нестандартного запроса, и инструкция перестаёт соблюдаться.
Проверяют вход, не проверяют выход. Именно на выходе появляются выдуманные цифры и ссылки.
Ограничители мешают работать. Слишком строгие правила приводят к тому, что помощником перестают пользоваться; баланс подбирается на реальных случаях.
- Слишком строгие правила. Система, которая отказывается отвечать на половину нормальных вопросов, перестаёт использоваться — и это провал, а не безопасность.
- Ограничители только в подсказке. Инструкции в тексте обходятся; критичные ограничения должны быть в коде.
- Нет пересмотра. Журнал отказов раз в месяц показывает, какие правила стали мешать; без пересмотра они накапливаются.
- Проверка на выходе стоит дороже ответа. Иногда это оправдано, иногда означает неверную архитектуру.