Вы определились с архитектурой и моделями. Но кто все это будет делать? Ошибка многих компаний — думать, что один «AI-инженер» или даже «prompt-инженер» справится со всем. Внедрение LLM — это полноценный программный проект с элементами научно-исследовательской работы, требующий минимум 5-7 ключевых ролей. Давайте построим идеальную команду.  

Ядро команды (Core Team):  

1. Product Manager / AI Product Owner  

• Кто: Мост между бизнесом и технарями. Самая критичная не-техническая роль.  

• Что делает:  

  • Формулирует бизнес-задачу на человеческом языке: «Снизить нагрузку на первую линию поддержки на 30%».  

  • Определяет метрики успеха (North Star Metric): не «точность модели», а «среднее время решения тикета», «NPS поддержки», «количество эскалаций».  

  • Приоритизирует фичи: что важнее — скорость ответа или способность работать с PDF?  

  • Управляет ожиданиями стейкхолдеров, объясняя, что может и чего не может LLM.  

• Без него: Команда уйдет в технологические дебри, создавая крутой, но ненужный продукт.  

2. Machine Learning / AI Engineer (Основа)  

• Кто: Универсальный солдат с глубоким пониманием ML, NLP и архитектур LLM. Часто бывший Data Scientist с сильными инженерными скиллами.  

• Что делает:  

  • Проектирует архитектуру AI-системы: RAG, агенты, pipelines.  

  • Выбирает и тестирует модели (см. ст. 25).  

  • Пишет код для пайплайнов обработки данных, fine-tuning, интеграции.  

  • Занимается промпт-инжинирингом и оптимизацией.  

  • Интегрирует LLM-компоненты с другими системами (базы данных, API).  

• Скиллы: Python (PyTorch/TensorFlow, Transformers), понимание Transformer-архитектуры, опыт работы с облачными ML-сервисами, знание библиотек (LangChain/LlamaIndex — опционально, но полезно).  

3. Data Engineer (for AI)  

• Кто: Строитель фундамента. Если ML Engineer — архитектор, то Data Engineer — прораб, который обеспечивает стройку материалами (данными).  

• Что делает:  

  • Строит и поддерживает Data Pipelines для LLM (см. ст. 12): инжекция, чанкование, векторизация, загрузка в векторную БД.  

  • Настраивает и администрирует векторные базы данных (Pinecone, Weaviate, Qdrant) и графы знаний.  

  • Обеспечивает качество данных: мониторит дрейф, чистоту, актуальность.  

  • Работает с Feature Store, если он есть (см. ст. 13).  

  • Оптимизирует процессы для работы с большими объемами текстов/данных.  

• Скиллы: Python, SQL, Airflow/Prefect/Dagster, облачные хранилища (S3), векторные БД, понимание ETL/ELT.  

4. ML Ops / LLM Ops Engineer  

• Кто: Инженер надежности для AI. Отвечает за то, чтобы система работала в продакшне 24/7, а не только в тетрадке.  

• Что делает:  

  • Развертывает модели в продакшн (Docker, Kubernetes, специализированные инференс-серверы like vLLM, TGI).  

  • Настраивает мониторинг и логирование для LLM (см. ст. 4, 15): latency, стоимость токенов, качество ответов (через LLM-as-a-Judge).  

  • Автоматизирует CI/CD пайплайны для моделей и промптов (тестирование, canary-развертывания).  

  • Управляет инфраструктурой (GPU-кластеры, оркестрация) и оптимизирует затраты.  

  • Обеспечивает безопасность и доступность системы.  

• Скиллы: DevOps (K8s, Docker, Terraform), облачные платформы (AWS SageMaker, GCP Vertex AI, рос. аналоги), мониторинг (Prometheus, Grafana), понимание ML-жизненного цикла.  

5. Domain Expert / Subject Matter Expert (SME)  

• Кто: Носитель экспертизы в предметной области. Не технарь. Может быть senior-юристом, опытным врачом, старшим инженером поддержки, архитектором ПО.  

• Что делает:  

  • Участвует в разработке онтологии (см. ст. 16): выделяет ключевые понятия, отношения, правила.  

  • Создает и валидирует «золотой» датасет для обучения и тестирования.  

  • Оценивает качество ответов модели с профессиональной точки зрения.  

  • Формулирует edge cases и потенциально опасные сценарии.  

• Без него: Модель может быть технически безупречной, но давать бесполезные или даже вредные советы в конкретной области.  

Специализированные роли (для продвинутых проектов):  

6. Research Scientist / NLP Specialist  

• Когда нужен: Если вы делаете что-то на грани возможного (собственная предобученная модель, сложные архитектуры KG+LLM, кастомные loss-функции).  

• Что делает: Изучает научные статьи, экспериментирует с новыми архитектурами и методами (RLHF, контрастивное обучение), пытается выжать последние проценты качества.  

• Не путать с ML Engineer: Ученый открывает новые знания, инженер — применяет известные.  

7. UX/CX Designer for AI  

• Кто: Специалист, который проектирует взаимодействие человека с AI. Как выглядит интерфейс чата? Как система сообщает о неуверенности? Как просить feedback?  

• Что делает: Проектирует диалоговые сценарии, продумывает graceful degradation (плавный переход к человеку-оператору), работает над доверием к системе.  

8. QA Engineer for AI  

• Кто: Не просто тестирует API, а специализируется на тестировании недетерминированных, творческих систем.  

• Что делает: Разрабатывает стратегии тестирования LLM (см. ст. 18), создает тесты на устойчивость к adversarial prompts, проверяет безопасность и соответствие онтологии.  

Как собрать команду? Пути для компании:  

1. «Под ключ» от интегратора: Наймите вендора/интегратора (такого как ИнтерактивМедиа), у которого уже есть готовая команда со всеми ролями. Вы получаете результат, а не головную боль с наймом.  

2. Аутстаффинг/аутсорсинг ключевых ролей: Нанять недостающих специалистов (например, Senior ML Engineer и ML Ops) через аутстафф. Ваша внутренняя команда (PM, Data Engineer, Эксперт) управляет ими.  

3. Построение внутренней команды (самый долгий и дорогой путь):  

   • Этап 1 (Прототип): Нанять/назначить 1 сильного AI/ML Engineer и Product Manager. Взять Domain Expert из бизнеса. Этого хватит на PoC.  

   • Этап 2 (Пилот): Добавить Data Engineer для построения пайплайнов.  

   • Этап 3 (Продакшн): Нанять ML Ops Engineer для индустриализации.  

Типичные ошибки в формировании команды:  

• «Давайте поручим это нашим Data Scientist'ам»: Классические DS часто не имеют навыков инженерии (ML Ops, пайплайны, продакшн).  

• «Наймем prompt-инженера, и он все сделает»: Промпт-инжиниринг — важный навык, но не роль. Это часть работы ML Engineer или даже PM.  

• Игнорирование Domain Expert: Технари не могут понять тонкости предметной области. Без эксперта проект обречен на поверхностность.  

• Отсутствие ML Ops на старте: Без этого прототип никогда не станет надежной продакшн-системой.  

Структура успешной команды (на примере проекта AI-ассистента для поддержки):  

• Product Manager: Определяет, что ассистент должен сократить время ответа.  

• ML Engineer + Data Engineer: Строят RAG-пайплайн на базе базы знаний, настраивают промпты.  

• Domain Expert (Senior из поддержки): Готовит датасет типовых вопросов-ответов, объясняет нюансы общения с клиентами.  

• ML Ops Engineer: Разворачивает модель в кластере, настраивает мониторинг latency и качества ответов.  

• QA Engineer: Тестирует ассистента на провокационные запросы.  

Вывод для руководителя:    
Создание команды для LLM-проекта — это сборка уникального набора компетенций, а не поиск универсальных гениев. Не пытайтесь найти одного человека, который знает все. Создавайте межфункциональную команду, где каждый закрывает свою зону ответственности. Начните с малого ядра (PM + ML Engineer + Эксперт), а для масштабирования либо инвестируйте в внутренний рост, либо привлекайте внешних специалистов. Правильная команда — это 80% успеха вашего AI-проекта.