Это реализация системы для оценки токсичности сообщений пользователей и модерации сообщений по этим данным.
Запуск консьюмера и FastAPI-приложения
docker build --tag 'detox_task' .
docker run -p 8000:8000 'detox_task'При запуске приложения в очередь автоматически отправляются 5 сообщений, так что по эндпоинту /scores можно получить 5 результатов. Отправить запрос можно через swagger
Наш сервис получает сообщения по какому-то брокеру, обрабатывает их c помощью ML-модели и отправляет в БД. Консьюмеров может быть большое количество, что обеспечит масштабируемость.
К тому же наш сервис позволяет получить модератору все оценки и тексты сообщений и забанить отправителей этих сообщений после проверки. После бана сообщение об этом уходит в сервис развлечений(Twitch, YouTube и т.д.).
Я бы подумал над выделением ML-модели в отдельный сервис(Moderation и Processing сервисы отдельно), взвесил все за и против, но не стал этим заниматься, так как это тестовое задание.
Реализовал использование встроенных очередей (queue.Queue) в качестве брокера и консьюмер с ml-моделью для этой очереди.
Реализовал поддержку in-memory базы данных для сохранения оценок сообщений.
Реализовал in-memory кеширование.
Реализовал эндпоинт для получения оценок.
При его разработке я пошел на компромиссы:
- использовал in-memory решения вместо настоящих технологий
- не реализовал часть функционала
Добавить эндпоинт для бана юзера, заменить in-memory решения на подходящие технологии, разделить запуск консьюмера и FastAPI-приложения на разные контейнеры(сейчас они в одном процессе с помощью ThreadPoolExecutor из-за in-memory решений), .env-настройки, добавить тесты в код, авторизация и аутентификация, настройки логирования + TODO в коде.
Сейчас при запуске приложения через докер заново скачивается модель, это нужно исправить в будущем
Зная, что в будущем нужно заменить in-memory решения на другие, я заранее сделал интерфейсы и использовал только их в коде консьюмера и эндпоинта