Как добавить проверку пользовательского текста перед публикацией

Что понадобится до настройки

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

Понадобится приложение с возможностью отправить запрос к API — программному интерфейсу сервиса — и место, где публикацию можно задержать до решения. Приведённый ниже пример использует библиотеку OpenAI для Python и уже настроенный доступ. Он не создаёт форму комментариев и не подключает её к сайту: это отдельная проверка, которую разработчик встраивает между отправкой текста и его появлением у читателей.

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

Шаг 1. Отделите правила площадки от сигнала модели

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

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

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

Шаг 2. Отправьте отдельный текст на проверку

Для пользовательского комментария не нужно просить нейросеть сначала написать ответ. В документации OpenAI для самостоятельной классификации указан метод moderations.create и модель omni-moderation-latest. Учебный пример ниже передаёт нейтральную фразу и выводит результат в консоль. Он не публикует текст и не блокирует пользователя.

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

from openai import OpenAI

client = OpenAI()
text = "Спасибо за подробный отзыв. Мы уточним детали."
response = client.moderations.create(
    model="omni-moderation-latest",
    input=text,
)
result = response.results[0]
print(result.flagged)
print(result.categories)
print(result.category_scores)

Шаг 3. Прочитайте результат, не выдавая его за приговор

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

Оценки по категориям лежат между 0 и 1 и отражают уверенность модели в принадлежности содержания к категории. Это не размер ущерба и не установленная вероятность того, что автор опасен. Не выбирайте произвольное число и не объявляйте его универсальной границей безопасности. Документация предупреждает, что базовая модель будет обновляться, а правила на основе оценок могут потребовать повторной настройки.

Учебный сценарий: пользователь пересказывает угрозу, чтобы пожаловаться на неё. Если проверка отметит насилие, передайте материал ответственному человеку вместе с контекстом жалобы. Само срабатывание не устанавливает намерение автора. И обратное: отсутствие отметки не заменяет проверку остальных правил площадки. Для приложения с самостоятельными действиями есть и другие границы защиты — их разбирает материал про риски безопасности ИИ-агентов для бизнеса.

Сначала проверьте, завершился ли запрос успешно и получен ли результат.
Затем посмотрите общий признак и конкретные категории.
Примените заранее записанное правило: публикация, ожидание или рассмотрение человеком.
Не назначайте санкции аккаунту только на основании одного неоднозначного результата.

Шаг 4. Если приложение пишет ответ, проверьте и его

Если сервис не только принимает комментарии, но и создаёт собственные ответы, в документации описан другой путь: добавить объект moderation в запрос генерации. Тогда результат содержит отдельные оценки входного сообщения и готового ответа без самостоятельного запроса модерации. Генерация при этом идёт обычным образом. Проверять результат нужно до показа человеку и до последующих действий приложения.

У входа и выхода может быть разный итог: опасный запрос и корректный отказ не равны двум нарушениям. Для каждого результата сначала проверьте его тип. Вместо оценок может прийти ошибка проверки входа или выхода; попытка прочитать такую ошибку как успешный ответ скроет проблему.

Особенно внимательно отнеситесь к постепенному показу ответа по мере его создания. По документации, оценки приходят после готовности всего текста, а не вместе с отдельными фрагментами. Если ваша цель — проверка до показа, рекомендуемая конструкция должна удерживать ответ до завершения генерации и модерации. Уже показанный фрагмент нельзя считать предварительно проверенным только потому, что вы запросили оценки.

Шаг 5. Оставьте понятный след решения

Чтобы разобрать жалобу автора или изменение поведения проверки, полезно сохранять не только итоговое разрешение. Ниже — предлагаемая структура журнала. Документация допускает использование категорий и оценок для журналирования, аудита и направления материалов на ручное рассмотрение; конкретный состав записей выбирает ваша команда.

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

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

Границы, которые нельзя закрыть одним вызовом

omni-moderation-latest принимает текст и изображения, но не классифицирует аудио. Если вы работаете с изображениями, проверьте поддерживаемые категории: не все категории текста работают для картинок. По документации, для неподдерживаемой категории при отправке только изображений возвращается нулевая оценка. Это ограничение проверки, а не доказательство отсутствия соответствующей проблемы. Максимальный размер файла изображения — 20 МБ.

Отдельное предупреждение OpenAI касается известных или предполагаемых материалов сексуального насилия над детьми: их нельзя отправлять в Moderation API. Этот интерфейс не предназначен для их обнаружения и обработки и не заменяет специализированную защиту детей. Такой материал нельзя использовать и как учебный пример для испытания описанной схемы.

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

Чек-лист перед включением публикации

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

Результат настройки — не обещание, что вредный текст никогда не появится. Вы должны получить управляемый процесс: материал не публикуется раньше проверки, ошибка не выдаётся за успех, а спорное решение можно объяснить и пересмотреть. Если эти условия не выполнены, сначала исправьте маршрут публикации, а не подбирайте более убедительную формулировку уведомления.

Текст остаётся в ожидании, пока проверка не завершена.
Категории модели сопоставлены с записанными правилами площадки.
Неоднозначный случай попадает человеку, который видит необходимый контекст.
При ошибке сервиса приложение следует отдельному правилу и не считает материал проверенным.
Готовый ответ нейросети не показывается частями раньше итоговой проверки, если требуется предварительная модерация.
В журнале различимы оценка модели, правило и окончательное решение.
После обновления модели предусмотрен повторный просмотр примеров и выбранных границ оценок.