Создание помощников AI требует сочетания навыков: разработка программного обеспечения, глубокие знания пользователя, написание и дизайн UX, а также наука о данных. Команды разработчиков, которые создают программное обеспечение для диалогового ИИ, имеют некоторые общие черты с традиционными командами разработчиков программного обеспечения, но есть и важные различия. Вам понадобится солидный опыт в области серверной разработки и DevOps, а также опыт в разработке диалогов и машинного обучения.
Независимо от того, большая ли ваша организация или маленькая, создаете помощника ИИ впервые или поддерживаете существующего помощника, вы хотите собрать команду по продукту с правильным сочетанием навыков и правильного размера для проекта.
Но когда дело доходит до команд, занимающихся диалоговым ИИ, существует поразительное разнообразие. Поиск правильной формулы зависит от приоритетов организации, стадии развития и размера. В этом сообщении в блоге мы начнем с разбивки нескольких наиболее распространенных ролей, которые составляют команды, занимающиеся диалоговым ИИ. Затем мы рассмотрим несколько примеров командных структур:
- компактная команда, быстрый выход на рынок
- средняя команда, уделяющая особое внимание качеству обслуживания клиентов с использованием мультимедийных материалов.
- большая команда после запуска
Наборы ролей и навыков
Давайте начнем с рассмотрения семи ролей, которые обычно встречаются в командах, занимающихся диалоговым ИИ. Имейте в виду, что разговорный ИИ - это новая и быстро развивающаяся область, и это не все возможные названия. Существуют специализированные роли, такие как руководители по инновациям в области искусственного интеллекта и компьютерные лингвисты, а также небольшие группы, в которых один разработчик может взять на себя как анализ данных, так и обязанности по разработке диалогов.
Backend разработчик
Почти в каждой команде, занимающейся диалоговым ИИ, вы найдете хотя бы одного внутреннего разработчика. Backend-разработчики несут ответственность за построение приложения на основе диалогового AI-фреймворка, включая интеграцию с серверными системами и базами данных. Они также могут создавать API, позволяющие помощнику взаимодействовать с существующими внутренними приложениями и источниками данных.
Фронтенд-разработчик
Разработчики интерфейсов интегрируют приложение AI-помощника с пользовательским интерфейсом, таким как веб-сайт или мобильное приложение. Многие команды, занимающиеся диалоговым ИИ, привлекают фронтенд-разработчика на начальном этапе создания, но не поддерживают постоянный фронтенд-разработчик после запуска, так как большая часть текущих разработок и сопровождения происходит на бэкэнде.
Специалист по данным
Специалисты по обработке данных несут ответственность за обучение и оптимизацию моделей машинного обучения. При создании команды помощников по ИИ специалисту по обработке данных необходимо глубокое понимание алгоритмов и обработки естественного языка. Их основными точками соприкосновения с проектом будут данные обучения, конфигурация конвейера NLU и настройка гиперпараметров, а также инструменты тестирования для измерения точности модели. В некоторых организациях специалисты по обработке данных также могут проводить анализ данных.
Аналитик данных / Инженер по данным
Команды, которые придают большое значение оценке влияния помощника ИИ на бизнес, могут включать аналитика данных или инженера данных. Аналитик данных отвечает за анализ показателей использования, чтобы выявлять закономерности и информировать бизнес-решения и решения по развитию. Они часто отвечают за структурирование данных и создание отчетов, чтобы определить, где можно улучшить помощника по искусственному интеллекту. Инженер данных занимается более техническими аспектами настройки и поддержки этого конвейера данных.
Дизайнер разговоров / Копирайтер
Дизайнер диалогов похож на дизайнера UX диалоговых интерфейсов. Они используют свое понимание пользователей и потребностей бизнеса для создания потоков разговора для задач, которые пользователь хочет выполнить. В некоторых случаях они также могут нести ответственность за внешний вид помощника, включая создание индивидуальности для помощника и написание сценариев разговоров. В других случаях создание голоса ассистента может поддержать специальный копирайтер.
Менеджер по продукту
Менеджеры по продукту действуют как мост между заинтересованными сторонами бизнеса и командой разработчиков. Они несут ответственность за преобразование бизнес-требований в функции и расстановку приоритетов в плане разработки функций. В небольших командах менеджер по продукту может также выступать в качестве менеджера проекта, управляя невыполненными работами и потоками заявок в команду разработчиков, или проектировщиком бесед, составляя схемы потоков беседы.
DevOps инженер
Усердная работа остальной части команды не имеет большого значения, если ее нельзя надежно развернуть в производственной среде. Инженер DevOps отвечает за настройку инфраструктуры хостинга AI-помощника, в том числе за обеспечение того, чтобы архитектура соответствовала существующим требованиям безопасности и сети организации. Инженеры DevOps также часто отвечают за создание автоматизированных процессов для тестирования и отправки обновлений кода в производственную среду.
Пример командных структур
Мы рассмотрели несколько отдельных ролей, из которых состоят диалоговые команды ИИ; теперь давайте посмотрим, как они подходят друг другу. В этом разделе мы рассмотрим несколько вариантов того, как может выглядеть диалоговая команда, на основе таких критериев, как приоритеты проекта и стадия разработки.
Слаженная команда, быстрый выход на рынок.
Что касается нашей первой команды, давайте представим, что у нас короткий срок запуска и ограниченная численность персонала, чтобы помочь AI-помощнику начать работу. Мы предполагаем, что проект находится на ранней стадии и быстро перейдет от POC к производству. Мы также ожидаем, что помощник увидит большой трафик вскоре после запуска, и требуется высокая доступность.
В этом случае команда, вероятно, будет уделять приоритетное внимание техническим аспектам реализации, убедившись, что инфраструктура надежна, а не сосредотачиваться на копирайтинге и дизайне опыта. Мы будем называть это бережливой командой: минимальная команда, необходимая для того, чтобы предоставить пользователям работающий AI-помощник.
- 1 Backend разработчик
- 1 специалист по данным
- 1 менеджер по продукту
- 1 инженер DevOps
Сюда мы добавили одного внутреннего разработчика и одного специалиста по данным, которые будут работать вместе над созданием помощника ИИ, а также приложения, которое его окружает. В этом случае мы пропускаем выделенного разработчика внешнего интерфейса, исходя из предположения, что требования к интерфейсу не являются сложными. Наш менеджер по продукту, вероятно, выполняет несколько задач одновременно: собирает бизнес-требования, а также разрабатывает потоки разговоров и анализирует работу помощника. И, наконец, мы добавили инженера DevOps для управления инфраструктурой и временем безотказной работы.
Средняя команда, создающая богатый клиентский опыт.
У нашей второй команды больше сотрудников, но у ассистента другие критерии успеха. Здесь организация построила свой бренд на повествовании с использованием мультимедийных материалов, которое распространяется на цифровой опыт, который они создают для клиентов. Эта команда диалогового ИИ сосредоточена на формировании голоса и тона помощника, и у них есть более длительный срок от POC до запуска.
- 1 менеджер по продукту
- 1 копирайтер
- 2 дизайнера разговоров
- 2 Backend инженера
- 1 специалист по данным
- 1 инженер DevOps
Эта команда сильно ориентирована на создателей контента - только около половины команды работает над технической реализацией. Другая половина сосредоточена на разработке опыта помощника. Мы по-прежнему привлекаем инженера DevOps для наблюдения за инфраструктурой и развертыванием.
Большая команда, после запуска.
Команды в большой организации часто развиваются в зависимости от стадии развития помощника. Некоторые команды привлекают дополнительных участников перед запуском, а затем сокращают масштаб на этапе обслуживания. Другие начинают с бережливой команды на раннем этапе и добавляют членов команды по мере развития.
Здесь мы представляем команду в крупной организации, которая запустила своего помощника в течение последних шести месяцев. Хотя обслуживание занимает большую часть внимания команды, они также работают над второй версией помощника, которая будет включать новые функции. Из-за этого эта команда сохранила многих участников, которых они привлекли для подготовки к запуску, и добавила еще несколько членов команды, сосредоточенных на понимании шаблонов использования и бизнес-показателей.
- 1 менеджер по продукту
- 1 Конструктор бесед
- 4 Backend разработчика
- 1 специалист по данным
- 2 аналитика данных
- 1 инженер DevOps
Вывод
Сборка команды для создания помощников AI может выглядеть по-разному в зависимости от организации и проекта. По нашему опыту в Rasa, наиболее успешные команды отражают цели и приоритеты проекта, будь то создание уникального бренда или быстрый выход на рынок на прочной технической основе. Однако их объединяет сочетание навыков, которые включают разработку программного обеспечения, машинное обучение, UX и DevOps.
Какие командные структуры вы видели на своем опыте? Делитесь своими мыслями и продолжайте общение на форуме Rasa.
Первоначально опубликовано на https://blog.rasa.com 6 августа 2020 г.
