Разработка машинного обучения — удалённая работа в Москве

# Техническое задание на разработку PoC системы автоматизации обработки тикетов поддержки ## 1. Общая информация **Название проекта:** PoC системы автоматизации обработки тикетов поддержки крупного онлайн-сервиса **Цель:** Разработать минимально жизнеспособный прототип (PoC) системы, демонстрирующий возможность автоматической обработки тикетов поддержки с разделением на автоматические ответы и эскалацию оператору. **Формат сдачи:** Git-репозиторий с кодом, документацией и артефактами задача ### 2.1. Исходные данные - Компания обслуживает онлайн-сервис с ~5 млн активных пользователей - Ежедневно поступает ~200 000 тикетов в поддержку - Каналы обращений: чат, email, веб-форма, мобильное приложение - В периоды инцидентов возможны всплески: 10-20k тикетов за 10 минут - Поток тикетов неоднородный: типовые обращения, сложные случаи, обращения с персональными данными ### 2.2. Бизнес-проблемы 1. Высокая нагрузка на операторов поддержки 2. Медленная обработка типовых обращений 3. Сложность маршрутизации сложных случаев 4. Риски при автоматической обработке (ошибки, нарушение SLA, небезопасные ответы) 5. Необходимость аудита всех автоматических решений ### 2.3. Ограничения - Время классификации и маршрутизации: **до 500 мс** на тикет (горячий путь) - Генерация ответа может быть асинхронной (дольше 500 мс) - Система должна корректно деградировать при недоступности LLM API - Стоимость LLM-инференса должна быть контролируемой - Автоматические ответы запрещены для рискованных категорий ## 3. Требования к PoC ### 3.1. Обязательный функционал Система должна демонстрировать **два сценария**: #### Сценарий 1: Happy Path (низкорисковый тикет) 1. На вход подаётся mock-тикет (текстовое обращение) 2. Система определяет тему обращения 3. Система оценивает уровень риска (low/medium/high) 4. Система находит релевантный ответ в базе знаний 5. Система отправляет автоматический ответ пользователю 6. Система сохраняет лог решения для аудита #### Сценарий 2: Fallback/Risky Path (высокорисковый тикет) 1. На вход подаётся mock-тикет с высоким риском 2. Система определяет тему и высокий уровень риска 3. Система **НЕ отправляет** автоматический ответ 4. Система эскалирует тикет оператору 5. Система сохраняет лог решения для аудита ### 3.2. Технические требования **Разрешено использовать:** - Простые правила (rule-based классификация) - Mock-модели (имитация работы ML) - Embeddings (опционально) - Небольшой локальный датасет - Внешний LLM API (опционально, но нужно учесть fallback) **Запрещено:** - Строить production-ready систему - Обучать настоящую модель на большом датасете - Поднимать Kubernetes, feature store или сложную MLOps-инфраструктуру - Писать много кода ради объёма - Проектировать UI оператора - Писать избыточную документацию ### 3.3. Архитектурные требования - Чёткое разделение на компоненты (классификатор, база знаний, оркестратор, логгер) - Документированная архитектура (диаграмма последовательности) - Явное указание, какие части реальные, а какие — архитектурный дизайн для production --- ## 4. Состав артефактов (обязательные для всех) ### 4.1. README.md Должен содержать: - Что делает решение (2-3 предложения) - Как запустить PoC (пошаговая инструкция) - Какие сценарии демонстрируются (happy path и fallback) - Какие части — реальная реализация, а какие — архитектурный дизайн - Допущения и ограничения (3-5 пунктов) - Бизнес-ценность системы (3-5 предложений) **Важно:** README должен читаться за 2-3 минуты. ### 4.2. AI_USAGE.md Честное описание использования AI-инструментов в процессе работы: - Перечислить, как AI использовался на этапах: - Понимание задачи и декомпозиция - Проектирование архитектуры - Выбор ML/LLM-подходов - Разработка PoC - Написание тестов и документации - Поиск рисков и edge cases - Показать роль AI в принятии решений - Указать, где AI помог, где его предложения были отклонены - Описать **конкретные ошибки AI** (минимум 2 примера): - Неверные архитектурные предположения - Небезопасные рекомендации - Нерабочий или хрупкий код - Пропущенные риски - Слишком общие ответы - Для каждой ошибки объяснить, как она была обнаружена и исправлена ### 4.3. product.md Страница-полтора (не маркетинговый документ): - Бизнес-ценность системы - Ключевые продуктовые решения - Метрики успеха (какие данные пилота убедят продолжить проект) ### 4.4. Архитектурная диаграмма - Диаграмма последовательности (Sequence Diagram) в формате PlantUML или аналогичном - Должна отображать оба сценария (happy path и fallback) - Диаграмма должна открываться или рендериться --- ## 5. Требования к коду ### 5.1. Структура репозитория ``` repository/ ??? README.md ??? product.md ??? AI_USAGE.md ??? architecture/ ? ??? diagram.puml (или .png) ??? poc/ ? ??? main.py (точка входа для демо) ? ??? orchestrator.py (основная логика) ? ??? classifiers/ ? ? ??? rule_based.py (или mock_llm.py) ? ??? knowledge_base/ ? ? ??? mock_db.py ? ??? logger.py ? ??? tests/ ? ??? smoke_test.py ??? requirements.txt ``` ### 5.2. Минимальные требования к коду - PoC должен **запускаться** по инструкции из README - Должен быть **smoke-test** или demo-скрипт, демонстрирующий оба сценария - Код должен быть читаемым (комментарии на русском или английском) - Для поступающих на AI Product: PoC может быть максимально простым (правила, mock-модели, low-code), но **сценарий эскалации обязателен** ### 5.3. История коммитов - Сохранена осмысленная история коммитов - По коммитам должно быть видно, как принимались решения по скоупу - Минимум 3-5 коммитов с разными этапами работы --- ## 6. Критерии оценки ### 6.1. Обязательные требования (без этого — возврат на доработку) - [ ] Репозиторий содержит все обязательные артефакты (README, AI_USAGE, product.md, диаграмма) - [ ] PoC запускается и демонстрирует happy path - [ ] PoC запускается и демонстрирует fallback/risky path (эскалация оператору) - [ ] Есть smoke-test или demo-скрипт - [ ] Внутренние ссылки в документации не битые ### 6.2. Качество решения - [ ] Чёткое разделение на компоненты - [ ] Явное указание, что является упрощением для PoC - [ ] Реалистичные допущения и ограничения - [ ] Честное описание использования AI в AI_USAGE.md с конкретными примерами ошибок - [ ] Архитектурная диаграмма отражает оба сценария - [ ] Бизнес-ценность обоснована (product.md) ### 6.3. Дополнительный плюс - [ ] Упомянуты нефункциональные требования (скорость, стоимость, деградация) - [ ] Предложены метрики для пилота - [ ] Описаны слабые места и что можно улучшить за 2 дня - [ ] Указано, что не стоит автоматизировать полностью --- ## 7. Рекомендации по объёму **Лучше компактное, понятное и честное решение, чем большой сгенерированный репозиторий без ясных решений.** - README: 1-2 страницы - product.md: 1-1.5 страницы - AI_USAGE.md: 1-2 страницы - Код: минимально необходимый для демонстрации сценариев (~100-300 строк) - Диаграмма: 1 диаграмма последовательности --- --- Формат сдачи - Ссылка на Git-репозиторий (доступ должен быть открыт или предоставлен доступ) - В репозитории должны быть все артефакты - В README — чёткая инструкция по запуску.