Почему мы решили визуализировать DS-решения?

Наша команда в Контуре занимается автоматизацией процессов технической поддержки с помощью Data Science уже 6 лет. За это время мы создали более 10 масштабных DS‑решений, которые описаны на 150+ страницах документации.

Хранить в голове такой объем информации очень сложно, а быстро погрузить в него новых участников команды — нереально. Поэтому мы задумались об удобном способе представления информации.

Решением стала визуализация DS-решений на схеме, в которой все собрано в одном месте:

• технические детали DS-решения

• сценарии, в которых решение работает

• взаимодействие с бэкендом

• взаимосвязи между моделями и данными

• взаимодействие между разными решениями

Что делали

1. Сбор информации

Казалось, что задача простая — документация каждого DS‑решения есть, надо только изобразить ее в другом виде. Но мы быстро выяснили, что документации DS‑части решения недостаточно для понимания сценария, в котором используется модель, и для понимания того, как бэкенд взаимодействует с нашим DS‑решением.

Поэтому пошли общаться с другими ролями — аналитиками, разработчиками, менеджером. Обсуждать сценарии с людьми разных ролей полезно, потому что взгляд человека на решение отличается в зависимости от его роли.

2. Визуализация

Начали с рисунков на листочке. 

Когда сложилось понимание того, как схема будет выглядеть, то перешли к реализации схемы в удобном инструменте.

У нас есть инфрастурктурные сервисы, которые позволяют датасайентисту решить типовую задачу от исследования до доставки решения на прод без привлечения разработчика. Например, у нас есть сервисы для:

• хостинга ML-моделей

• хранения векторов и быстрого поиска по ним

• объединения моделей, векторных пространств и других сущностей в единый алгоритм

• хранения данных для каждого проекта

Поэтому на схеме достаточно указать имя и версию модели в нашем сервисе для хостинга — и любой датасайентист понимает, о чем идет речь и где искать задеплоенную модель.

3. Ревью

В ревью схемы участвовали не только датасайентисты. Так, разработчики провалидировали точность отображения взаимодействия бэкенда с DS‑решениями. Менеджер разработки и аналитики проверили, что сценарии применения DS‑решений правильно зафиксированы и соответствуют бизнес‑сценариям клиентов.

Насколько полезно было такое комплексное ревью, можно оценить по количеству комментариев к схеме. Дополнительный профит — другие роли тоже стали лучше понимать устройство наших решений.

Так выглядела доска с комментариями во время ревью. Что есть что рассмотрим детальнее дальше.

Что есть на схеме

По каждому решению изображена информация:

• схема и текстовое пояснение пользовательского сценария со ссылками на документацию

• пути до данных, которые использованы в решении

• модели и векторные пространства со ссылками на хостинг и код в git, которым они получены

• предобученные модели, которые использованы в решении

• логика взаимодействия между частями решения

Решения на схеме делятся по проектам, которые создают решения для разных направлений в техподдержке. Эти названия встретятся далее на иллюстрациях, поэтому кратко познакомимся: Sirena работает с чатами, Naiad с письмами, Merlin со звонками, а Turbo упрощает жизнь внутренней техподдержке Контура. DS‑решения этих проектов маршрутизируют сообщения на нужных сотрудников, определяют намерения клиентов, помогают консультантам отвечать на вопросы клиентов.

Точка входа на схеме — это сценарии, которые находятся по центру по всей схемы, например «Маршрутизация звонков по топикам». Из центральной части можно пойти налево, в сторону бизнеса (визуализации коммуникации клиентом). Или в направо, в сторону DS‑описания решения.

Место DS-решения в пользовательском сценарии

Отображение бизнесовой части — это важная составляющая схемы, так как датасайентистам нужно знать, какие сценарии закрываются тем или иным решением. Без этого можно столкнуться с проблемой: задача решена, но решение неприменимо к бизнес-сценарию.

Взаимодействие DS-решения и бэкенда

Схематичное описание бэкенда нужно для того, чтобы отобразить контракты моделей (что подается в модель, что из нее выходит), а также предобработку и постобработку данных до и после работы модели.

Такая «шпаргалка» помогает датасайентистам при доработках и создании новых решений проверять, что они вписываются в существующую систему. Благодаря этой информации на схеме нет необходимости каждый раз уточнять ее у разработчиков, изучать код или держать все в голове.

Взаимосвязи между моделями и данными

Важным и интересным аспектом было отображение связей моделей машинного обучения и данных для обучения в различных задачах. Например, в нескольких задачах в качестве стартовой точки для обучения используется одна и та же базовая модель, но данные в них — разные.

Фиксация таких вещей может быть полезной. Например, чтобы понимать, что модель, обученная изначально на данных из чатов, может хорошо работать и в письмах. Или чтобы заметить, что одна модель используется в нескольких задачах с риском потери производительности, так как к этой модели обращаются сразу несколько сервисов. И, значит, при дообучении этой модели для одной задачи, важно проверить, что качество на другой задаче не просело.

Технические детали DS-решения

Датасайентисту часто бывает полезно видеть, как решена задача с технической точки зрения: какие архитектуры моделей использовались, какие данные применялись для обучения. Так у него в голове укладывается знания о применимости разных методов. Помимо этого, такая информация может помочь в решении новых задач: у датасайентиста будут подсказки для выбора нужной архитектуры решения.

Мы фиксируем информацию обо всех наших экспериментах, но информация хранится разрозненно — код экспериментов лежит в нескольких репозиториях нашей команды в gitlab, на wiki результаты описаны в разных разделах. Схема же позволила показать цельную картину всех решений команды в одном месте. А благодаря ссылкам на код обучения моделей можно быстро перейти в git и изучить делали решения.

Итоги

Реализация заняла около одной рабочей недели, растянувшейся до пары месяцев, так как создание схемы было менее приоритетно, чем бизнесовые задачи. Еще несколько дней ушло на предварительные консультации с другими ролями и ревью. Но это время было потрачено с пользой. 

Визуализация всех решений на единой схеме поможет:

1. Видеть детали взаимодействия между решениями, чтобы лучше контролировать риски.

2. Тратить меньше усилий для того, чтобы вспомнить, что мы делали раньше.

3. Шарить контекст с будущими поколениями, чтобы он не уходил из команды вместе с людьми. Хоть информация и зафиксирована в обширной документации на вики, но ее чтение — не самый простой способ для новичка уловить все взаимосвязи сценариев и задач.

Если у вас есть свои способы хранения большого количества информации о решениях, то пишите их в комментарии — обсудим.