ИИ-модерация должна возвращать спорный контент человеку и сохранять причину решения

Что покупает владелец площадки? Решение о публикации по своим правилам. Классификатор находит признаки содержания, а разрешение публиковать задаёт ваш сервис.

OpenAI в документации Moderation предлагает использовать оценки для правил приложения. Сигнал модели можно направить на ручной просмотр; он не обязан становиться автоматической блокировкой.

Контекст меняет решение. Microsoft предупреждает, что классификатор может не различить уместное и неуместное употребление одних слов. Цитата угрозы в жалобе может получить тот же ярлык, что и сама угроза. Нужны примеры именно вашей площадки.

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

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

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

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

Чем объяснить ограничение автору? Правилом и проверяемым основанием. «Модель сочла текст опасным» не помогает понять, какую часть публикации можно исправить.

Журнал должен связывать решение с версией публикации. Если автор изменил текст, прежний вердикт остаётся связан с прежним содержанием. Новый текст проходит новую проверку.

Сохраняйте основание, а не рассказ о мыслях модели. Достаточно номера правила, признака нарушения и фрагмента для проверки человеком. Красивое объяснение без такой опоры бывает выдумкой.

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

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

Журналу тоже нужны права доступа и срок хранения. В нём остаются фрагменты пользовательских публикаций. Границы доступа к данным людей при разработке задают до работы агентов.

Что мы проверили на своей машине? Устройство отбора и причины отказов. Инженер ведёт машину агентов vibecoding.ru; наш отбор новостей сохраняет основание отказа.

На живом /open в сноске «Качество» на 8 октября 2026 указаны 24 597 найденных материалов и 3 292 поданных. Это отбор новостей за всю историю склада; «подано» означает выход на сайт или в Telegram.

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

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

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

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

Что меняет агентная разработка? ИИ-агенты пишут код модуля и его проверки под управлением инженера. Модель внутри модератора исполняет другую работу: классифицирует публикации пользователей.

Агенту нужна задача с приёмкой. «Подключить ИИ-модерацию» оставляет поведение очереди на усмотрение исполнителя. Задание должно описывать действия площадки на каждом результате.

Принимают весь путь публикации. Классификатор может ответить правильно, а приложение потерять причину или не исполнить отмену. Зелёная проверка одного запроса этого не обнаружит.

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

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

С чего начать заказ? С текстовых публикаций и одного согласованного набора правил. Фотографии, видео и санкции к аккаунтам требуют своих примеров и отдельной приёмки.

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

Если вести работу некому, разработка по подписке стоит 250 000 ₽ в месяц за «Один проект»: инженер ведёт машину агентов, правки идут в ваш репозиторий, одна задача в работе, пауза в любой месяц.

Это цена работы над проектом. Расходы на ИИ-функцию, которой пользуются ваши клиенты, оплачиваются отдельно; /services на 8 октября относит их к расходам заказчика.

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

1. До подключения модели запишите запреты площадки и допустимые случаи.

2. Спорное направляйте человеку; ошибку классификатора учитывайте отдельно.

3. Сохраняйте основание и версии правил. Отмена должна добавлять событие.

4. Разобранную ошибку добавляйте в проверку перед следующим выпуском.

5. Принимайте путь от публикации до пересмотра в своём репозитории.