Программисты — удалённая работа в Москве

ml инженер. Разработка с нуля. Техническое задание на разработку PoC системы автоматизации обработки тикетов поддержки крупного онлайн-сервиса. Цель проекта — разработать минимально жизнеспособный прототип системы, демонстрирующий возможность автоматической обработки тикетов поддержки с разделением на автоматические ответы и эскалацию оператору. Формат сдачи — Git-репозиторий с кодом, документацией и артефактами. Компания обслуживает онлайн-сервис с примерно пятью миллионами активных пользователей. Ежедневно поступает около двухсот тысяч тикетов в поддержку через каналы чат, email, веб-форма и мобильное приложение. В периоды инцидентов возможны всплески нагрузки до десяти–двадцати тысяч тикетов за десять минут. Поток тикетов неоднородный и включает типовые обращения, сложные случаи и обращения с персональными данными. Бизнес-проблемы, которые должна решать система, заключаются в высокой нагрузке на операторов поддержки, медленной обработке типовых обращений, сложности маршрутизации сложных случаев, рисках при автоматической обработке, включая ошибки, нарушение SLA и небезопасные ответы, а также в необходимости аудита всех автоматических решений. Ограничения системы следующие: время классификации и маршрутизации не должно превышать пятисот миллисекунд на тикет в горячем пути, генерация ответа может быть асинхронной и занимать больше пятисот миллисекунд, система должна корректно деградировать при недоступности LLM API, стоимость LLM-инференса должна быть контролируемой, а автоматические ответы запрещены для рискованных категорий. Система должна демонстрировать два обязательных сценария. В сценарии Happy Path на вход подаётся mock-тикет в виде текстового обращения, система определяет тему обращения, оценивает уровень риска как low, medium или high, находит релевантный ответ в базе знаний, отправляет автоматический ответ пользователю и сохраняет лог решения для аудита. В сценарии Fallback или Risky Path на вход подаётся mock-тикет с высоким риском, система определяет тему и высокий уровень риска, не отправляет автоматический ответ, эскалирует тикет оператору и сохраняет лог решения для аудита. В технических требованиях разрешено использовать простые правила rule-based классификации, mock-модели для имитации работы ML, embeddings опционально, небольшой локальный датасет и внешний LLM API опционально с обязательным учётом fallback. Запрещено строить production-ready систему, обучать настоящую модель на большом датасете, поднимать Kubernetes, feature store или сложную MLOps-инфраструктуру, писать много кода ради объёма, проектировать UI оператора и писать избыточную документацию. Архитектурные требования включают чёткое разделение на компоненты — классификатор, базу знаний, оркестратор и логгер, документированную архитектуру в виде диаграммы последовательности, а также явное указание, какие части являются реальной реализацией, а какие — архитектурным дизайном для production. Обязательные артефакты включают README.md, который должен содержать описание того, что делает решение в двух-трёх предложениях, пошаговую инструкцию по запуску PoC, указание демонстрируемых сценариев happy path и fallback, разделение на реальную реализацию и архитектурный дизайн, допущения и ограничения в трёх-пяти пунктах, а также бизнес-ценность системы в трёх-пяти предложениях. README должен читаться за две-три минуты. Файл AI_USAGE.md должен содержать честное описание использования AI-инструментов на этапах понимания задачи и декомпозиции, проектирования архитектуры, выбора ML/LLM-подходов, разработки PoC, написания тестов и документации, а также поиска рисков и edge cases. Необходимо показать роль AI в принятии решений, указать, где AI помог и где его предложения были отклонены, описать минимум два конкретных примера ошибок AI, таких как неверные архитектурные предположения, небезопасные рекомендации, нерабочий или хрупкий код, пропущенные риски или слишком общие ответы, и для каждой ошибки объяснить, как она была обнаружена и исправлена. Документ product.md объёмом страница-полтора, не маркетинговый, должен описывать бизнес-ценность системы, ключевые продуктовые решения и метрики успеха — какие данные пилота убедят продолжить проект. Архитектурная диаграмма должна представлять собой Sequence Diagram в формате PlantUML или аналогичном, отображать оба сценария happy path и fallback и открываться или рендериться. Структура репозитория должна выглядеть следующим образом: в корне 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. Минимальные требования к коду: PoC должен запускаться по инструкции из README, должен быть smoke-test или demo-скрипт, демонстрирующий оба сценария, код должен быть читаемым с комментариями на русском или английском. Для поступающих на AI Product PoC может быть максимально простым с использованием правил, mock-моделей и low-code, но сценарий эскалации обязателен. История коммитов должна быть осмысленной, по коммитам должно быть видно, как принимались решения по скоупу, минимум три-пять коммитов с разными этапами работы. Критерии оценки включают обязательные требования, без выполнения которых работа возвращается на доработку: репозиторий содержит все обязательные артефакты README, AI_USAGE, product.md и диаграмму, PoC запускается и демонстрирует happy path, PoC запускается и демонстрирует fallback/risky path с эскалацией оператору, есть smoke-test или demo-скрипт, внутренние ссылки в документации не битые. Качество решения оценивается по чёткому разделению на компоненты, явному указанию упрощений для PoC, реалистичным допущениям и ограничениям, честному описанию использования AI в AI_USAGE.md с конкретными примерами ошибок, отражению обоих сценариев в архитектурной диаграмме и обоснованной бизнес-ценности в product.md. Дополнительный плюс даётся за упоминание нефункциональных требований по скорости, стоимости и деградации, предложение метрик для пилота, описание слабых мест и того, что можно улучшить за два дня, а также указание того, что не стоит автоматизировать полностью. Рекомендации по объёму: лучше компактное, понятное и честное решение, чем большой сгенерированный репозиторий без ясных решений. README — одна-две страницы, product.md — одна-полторы страницы, AI_USAGE.md — одна-две страницы, код — минимально необходимый для демонстрации сценариев примерно сто-триста строк, диаграмма — одна диаграмма последовательности. Формат сдачи: ссылка на Git-репозиторий с открытым доступом или предоставленным доступом, в репозитории должны быть все артефакты, в README — чёткая инструкция по запуску.