AI moderation platform становится не просто фильтром, а частью архитектуры принятия решений. В кейсе DoorDash это оказалось критично, потому что система должна была работать на миллионах сообщений в день и не ломать пользовательский опыт.
Проблема началась там, где большинство архитектур упирается в стоимость ошибки. В чате marketplace нужно быстро отделять безопасные сообщения от опасных, иначе падает и безопасность, и ощущение безопасности в продукте. У DoorDash на это уходили миллионы сообщений в день, а на решение оставались доли секунды. При такой нагрузке прямой вызов LLM выглядел логично только на бумаге: latency была слишком высокой, а стоимость — слишком большой.
Команда выбрала не «один умный слой», а двухступенчатую схему. Сначала идет дешевый внутренний classifier, который отсеивает очевидно безопасные сообщения. Только те случаи, где модель не уверена, отправляются в LLM pipeline. Это прагматичный компромисс: LLM применяется точечно, а не на весь поток. Так архитектура снижает расходы и сохраняет latency там, где она критична для chat experience.
Решающим оказалось то, как именно LLM используется. Его не спрашивают, безопасно сообщение или нет, в формате Boolean. Вместо этого модель получает scoring across multiple axes: threat, profanity, sexuality и другие контексты, в зависимости от сценария. Это важная инженерная деталь. Boolean фиксирует систему в жесткой развилке, а score дает knob, с которым можно менять thresholds и принимать graduated actions.
Реализация строилась вокруг этого принципа. Поток очищали от шума: пустых сообщений, image attachments и простых pleasantries. Затем сообщение проходило через internal classifier. Если оно было явно безопасным, система пропускала его дальше. Если нет, включался LLM, который оценивал содержание по нескольким осям. После этого система могла выбрать действие по severity: от цензурирования сообщения до блокировки, отмены заказа или предупреждения пользователя. Для voice и image использовался тот же общий подход, но с другими входными механизмами. Для image cheap layer был реализован через commercial vision API, а для voice часть ограничений была принципиальной: слова уже были услышаны, поэтому система могла только реагировать, но не предотвращать доставку реплики.
Итог оказался практичным, а не декоративным. После внедрения SafeChat команда увидела примерно 50% reduction in incidents, связанных с verbal abuse. Важно, что это не метрика качества модели в вакууме, а снижение реального вреда для пользователей. Но на этом история не закончилась. Когда решение начали заимствовать другие команды, стало видно, что точечная система под один use case плохо масштабируется как платформа. По сути, команде нужен был не отдельный SafeChat, а переиспользуемый architectural pattern для moderation across multiple surfaces.
Этот кейс хорошо показывает, как должна эволюционировать AI moderation platform в production. Сначала команда изучает данные и только потом выбирает форму модели. Затем она разделяет cheap layer и expensive layer. После этого вводит scoring вместо бинарного ответа. Такой подход не убирает сложность, но делает ее управляемой. И именно в этом, а не в громких обещаниях, обычно и состоит рабочая архитектура.