Модерация запросов и ответов: фильтры на обоих концах

Как только нейросеть начинает отвечать реальным пользователям, появляется вопрос: что делать, если запрос неуместен, а ответ вышел неудачным. Разберём, как устроена проверка и где её ставить.

Почему нужны обе проверки

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

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

Одной проверкой обойтись нельзя: они ловят разное.

Три исхода вместо двух

Схема «пропустить или заблокировать» кажется простой, но у неё нет золотой середины. Настроите строго — начнёте отказывать людям с обычными вопросами. Настроите мягко — пропустите то, что пропускать не следовало.

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

Что проверять на входе

• Длину: десять страниц, вставленных в поле чата, стоят как сотня обычных запросов.
• Пустые и мусорные строки — их можно отсеять без всякой модели.
• Явные попытки переопределить инструкцию.
• Тематику: если ваш бот отвечает про доставку, вопросы о политике ему адресовать не нужно.
• Персональные данные, которые пользователь прислал сам: номер карты в чате лучше не отправлять дальше.

Первые два пункта решаются обычным кодом и должны стоять первыми — они самые дешёвые.

Что проверять на выходе

Здесь важнее не запрещённые темы, а достоверность.

**Обещания и обязательства.** Ответ, содержащий срок, скидку или гарантию, которых нет в ваших данных, опаснее грубости.

**Ссылки и контакты.** Модель умеет придумывать правдоподобные адреса страниц. Проверяйте их существование кодом.

**Числа.** Сумма, срок, артикул — сверяйте с источником, из которого они должны были взяться.

**Выход за рамки.** Ответ на тему, которой вы не занимаетесь, — повод не показывать его пользователю.

Самая полезная проверка ответа — не про мораль, а про факты. Ответ, где модель уверенно назвала несуществующие условия возврата, обойдётся дороже, чем грубая формулировка.

Как устроена инструкция

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

Запреты работают надёжнее пожеланий, а перечисленные конкретно — надёжнее общих. «Будь осторожен с обещаниями» не даёт ничего, «не называй сроки доставки» — даёт.

Что показывать пользователю

Отказ должен быть понятным. «Запрос отклонён» вызывает раздражение и повторные попытки, «я отвечаю только на вопросы о заказах и доставке» — переводит разговор в нужное русло.

При отправке на проверку человеку честно скажите, что ответ готовится, и укажите срок. Молчание пользователи трактуют как поломку.

Стоимость проверок

Проверка кодом стоит ноль. Проверка отдельной моделью — примерно как короткий запрос, что заметно при больших объёмах, но обычно дешевле последствий пропуска.

Разумный порядок такой: сначала бесплатные проверки кодом, потом дешёвая модель для тематики и явных нарушений, и только спорные случаи — человеку.

Подмена инструкции

Отдельный класс запросов, о котором стоит знать: попытки заставить модель забыть вашу инструкцию. Формулировки бывают прямые — «игнорируй предыдущие указания» — и завуалированные, спрятанные внутри документа, который пользователь прислал на разбор.

Второй вариант опаснее. Если ваша система разбирает присланные файлы, текст внутри файла модель воспринимает как часть запроса. Инструкция, вписанная туда злоумышленником, может сработать.

Полностью защититься формулировками нельзя, но несколько мер снижают риск заметно.

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

Мера, которая надёжнее всех формулировок

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

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

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

Что записывать

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

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