Привет! Меня зовут Сизов Виктор, я занимаюсь данными, их сбором, анализом и разметкой последние 5 лет. Сейчас отвечаю за разметку в Альфа-Банке. Эту статьи мы писали всей командой и старались осветить подробно детали того, как устроены процессы разметки с технической и административной стороны. В статье мы рассмотрели:
работу команд разметки, их взаимодействие с Заказчиком и Продуктом;
отдельно разобрали аналитику, которая позволяет повышать качество разметки;
поведение людей (разметчиков), паттерны их работы.
Часть 1. Заказчики, участники и исполнители
Разметка данных — это процесс добавления меток к данным, впоследствии используемым для обучения моделей машинного обучения. Разметка необходима, чтобы модели могли различать классы объектов, выявлять закономерности и предсказывать результаты.
Например, мы хотим обучить нейронную сеть определять различных животных на фотографиях. Для этого мы возьмем много фотографий с коровами, зебрами, кошками и другими, просмотрим все эти снимки и присвоим каждому из них нужный класс — вид животного. А ещё лучше, если выделим небольшую область на снимке, где находится нужный нам объект и присвоим класс именно этой области, чтобы модели было проще понять, куда смотреть. Этот процесс — один из классических примеров ручной разметки данных.
Разметка может сильно различаться в зависимости от типа размечаемых данных (текст/аудио/изображения/видео), постановки задачи и требуемого качества. Насколько важно качество разметки и сколько нужно размечать (для модельных метрик) — отдельная, и, зачастую открытая тема, к которой мы вернемся в другой раз.
Кому в первую очередь нужна разметка? Кто является заказчиком?
Основным заказчиком является команда разработки. А если быть точнее — то конкретный дата-сайентист (ДС), которому необходимы размеченные данные для модели.
Но так как ДС не всегда владеет полной бизнес-логикой, то может быть необходимо участие команды продукта — людей, погружённых во все нюансы, которые могут подсказать в сложных (пограничных) кейсах. Основной пласт нашей разметки мы делаем для моделей колл-центра, но информация далее применима практически к любому продукту.
Отдельно стоит упомянуть, что в процессе также участвуют:
команда IT-сопровождения, которая обеспечивают хранение данных, аналитику процессов, автоматизацию, подсчет KPI;
административная команда, которая старается сделать так, чтобы все это работало вместе.
Основа хорошей разметки — правильно подобранная команда и выстроенные процессы. Административных подходов к разметке данных несколько:
Штатная команда: полноценно нанимаем ребят, трудовые договоры — всё как положено. Хорошо для больших задач, особенно если необходим доступ к чувствительным данным.
Самозанятые (администрируем сами): упрощённый вариант, который позволяет не брать людей в штат, а заключать с ними простые договоры на сдельную работу и использовать проектный бюджет. Из плюсов — быстрый «найм», оптимизация налогов, сдельная оплата. Из минусов — большая текучка и юридические сложности: нельзя предоставлять рабочее место и налоговой должно быть очевидно, что эти люди не идентичны штатным сотрудникам.
Аутсорс-компании: сторонние команды, которые специализируются на разметке. Основное преимущество — масштабируемость и простота в администрировании для нас, как для заказчика. И плюс не нужна своя платформа разметки.
Крауд-платформы: агрегируют большое количество исполнителей, которые могут выполнять ваши несложные задачи. Аналогично с предыдущим пунктом — не нужна своя платформа разметки, но нужно уметь ей грамотно пользоваться.
Примечание: отдельно выделим использование автоматизированных подходов для получения размеченных данных: LLM для разметки и синтетические данные.
Основной пласт задач, с которыми мы в банке имеем дело, может содержать чувствительные данные, поэтому мы рассмотрим процессы на примере штатной команды, но в большой степени это применимо и для других подходов.
Часть 2. Роли в штатной команде разметки данных
Из кого состоит команда разметки?
Разметчик (AI-тренер): для самого важного — разметки.
Руководитель команды разметки (тимлид): для администрирования команды, обучения ребят, контроля их работы, сбора ОС, взаимодействия с заказчиком и корректировки Протокола* (техническое задание на разметку, см. ниже).
Архитектор БД: для аккуратного хранения данных.
Аналитик данных: чтобы доставать ОС для тимлидов, о том, как мы размечаем и что нужно подробнее разобрать с командой или заказчиком. А также для ведения всей статистики и расчёта KPI.
Дата-сайентист (разработчик): для автоматизации процессов разметки, интеграции LLM, RAG и других решений.
Разработчик: для кастомизации платформы разметки, если это необходимо.
Промпт-инженеры: по необходимости.
Если подразделение размечает данные по нескольким направлениям, то для каждого из них (обычно) формируется отдельная команда.
Нулевой этап любой задачи разметки — это сбор и предобработка данных. Здесь мы будем считать, что этот процесс успешно выполнен до нас, и на входе имеем прекрасный (или нет) датасет. В этом случае задача подразделения разметки (упрощённо) — получить датасет, разметить его и вернуть команде разработки.
А дальше многое зависит от того, что на себя берёт команда разработки, и какими инструментами пользуется. Например, с целью оптимизации ресурса команды разработки можно своими силами оценивать влияние качества и объёма разметки на модельные метрики. Это поможет самостоятельно принимать бОльшую часть решений и лучше управлять своим ресурсом.
На деле, конечно, процесс несколько интереснее, и для его реализации необходимы команды, непосредственно осуществляющие разметку, а также техническое сопровождение (может быть как внутри подразделения, так и вне), о чём говорил выше.
Но вернёмся к команде разметки и рассмотрим их роли подробнее. Начнём с главной роли.
Разметчик — главное действующее лицо всей истории
Разметчик или AI-тренер — человек, который присваивает каждой единице данных нужные характеристики. В упрощенном виде его работа выглядит так:
Изучение Протокола на задачу разметки.
Тестирование задачи, сбор вопросов для руководителя, которые явно не отражены в протоколе.
Разметка с постоянной ОС по спорным случаям, в которых Протокол не даёт однозначного ответа.
Участие в разборах ошибок, консультация других ребят по сложным вопросам.
Базовый навык — умение пользоваться платформой разметки* или другими инструментами, необходимыми для вашей задачи. Сейчас платформы стали довольно простыми в использовании, поэтому этот навык можно приобрести за несколько дней/недель.
Дальше играют роль уже доменные знания, которые необходимы для вашей задачи. Это могут быть знания продуктов компании, финансовой сферы, медицинской тематики по конкретному направлению и, в целом, любая область, где планируется внедрение ML.
*Платформа разметки - программное обеспечение, позволяющее собирать и размечать данные в интерфейсе, настраиваемом под конкретный проект разметки. Мы в Банке пользуемся платформой Elementary (проект VS Robotics).
Итак, следующая роль, — тимлид.
Кто такой тимлид разметки?
Тимлид управляет командой из 5-20 человек, в зависимости от сложности задачи. И первый вид его обязанностей — планировать задачи сотрудников, поддерживать мотивацию, обучать и контролировать работу.
Вторая важная обязанность тимлида — взаимодействие с заказчиком, анализ требований и перенос этих знаний своей команде. Последовательность действий тимлида для запуска разметки новой задачи выглядит следующим образом:
Получить первичный Протокол задачи и небольшую выборку данных для теста, обычно 10-100 кейсов, чтобы команда провела первичную оценку задачи по выполнимости, сложности и срокам.
Протестировать задачу, т.е. изучить Протокол и разметить небольшую выборку данных. Определить сложность, потенциальное качество, динамику. Обычно занимает 1-7 дней.
Сформировать итоговый Протокол, предварительно задав все возникшие в ходе теста вопросы Заказчику.
Сформировать команду, исходя из компетенций для задачи. Например, если требуется разметка рентгеновских снимков, то для соблюдения высокого качества и достоверности необходимы разметчики с профильным медицинским образованием.
Обучить команду.
Запустить процесс разметки.
Предоставлять непрерывную ОС Заказчику (команде продукта) для уточнений спорных случаев (см. пример ниже).
Дальше идет операционная работа с командой, разбор ошибок, аналитика результатов. Подробнее об этом мы расскажем ниже.
Протокол и нюансы
Раз заговорили про протокол, то давайте его и рассмотрим.
Протокол — это необходимое, но не достаточное условие хорошей разметки.
Протокол — это аккуратно собранное силами Заказчика, Продукта и Разметки техническое задание, из которого должно быть понятно, с какими данными нужно работать и как размечать каждый конкретный кейс.
Чаще всего Протокол — это постоянно меняющийся в ходе разметки файл, куда тимлид при согласовании с Заказчиком периодически вносит корректировки и уточнения, но общая его структура почти не меняется. Если вернуться к нашей модели, определяющей животных по снимку, то Протокол выглядел бы примерно так:
А. Описание задачи
На снимках необходимо выделить животных в прямоугольные рамки (bounding box), присвоив им требуемый класс из списка ниже. Если животное видно частично, то выделяем только видимую часть. Если мы не можем однозначно определить вид животного, то присваиваем класс «Всё остальное»...
Б. Критерии точности разметки
Боксы должны вплотную прилегать к границе объекта, допускаемая погрешность — 5 пикселей…
В. Классы:
Зебра.Утконос.Улитка.Червь.Скорпион.Тигр.Всё остальное...
Г. Примеры
Здесь привести наиболее разнообразные примеры, с которыми предстоит встретиться:
Обычно несложно описать задачу разметки для 95% наиболее очевидных кейсов, но оставшиеся 5% могут содержать пограничные случаи, для разбора которых придётся приложить больше усилий, поэтому ещё один обязательный пункт протокола — спорные случаи.
Например, в Протоколе мы не описали, должно ли животное обязательно быть живым или может быть игрушечным. Устроит ли нас снимок рисунка, картины или фотографии животного? Эти вопросы наверняка приведут к разногласиям внутри команды (а значит, и к плохой разметке), поэтому обязательно постепенно добавляем новые примеры в Протокол, охватывая нетривиальные случаи.
Итого, для разметки важно:
научиться взаимодействовать с Заказчиком;
сформировать полный и понятный Протокол;
собирать и использовать все идеи и знания разметчиков;
Здесь мы рассматриваем разметку исключительно как ручную задачу и её успех на 100% зависит от самих разметчиков и процесса их обучения. Собственно, давайте и рассмотрим, как проходит их обучение?
Часть 3. Онбординг сотрудников
Разметчиков много не бывает. Точнее, (в наших проектах) их требуется всё больше, а их компетенции должны быть глубже. Если вы сами выстраиваете процессы, то с высоким приоритетом должен быть отлажен найм и обучение/переобучение ребят с нуля и вывод их на плановые метрики: объём и качество разметки.
Под новичками мы понимаем как ребят, которые впервые устроились в Банк, так и тех, кто к нам перешел из других подразделений банка. Основной пласт нашей разметки мы делаем для моделей колл-центра, поэтому главное, что должны знать ребята, — это продукты банка, их условия и прочее.
Этапы обучения
Процесс обучения новичков делится на этапы:
Этап_1. Базовое обучение в компании: курсы по безопасности, основная информация для всех сотрудников и т.д.
Этап_2. Изучение продуктов и услуг компании: курсы про продукты банка, их виды и т.д. Это необходимо, так как разметчики будут выполнять задания, связанные с продуктами банка, и должны быть полностью в них погружены.
Этап_3. Обучение разметке: нам нужно обучить инструментам (пользованию платформой) и, самое важное, спроецировать знания о продуктах на конкретные задачи разметки. Рассказываем о правилах, нюансах, учим пользоваться Протоколом, таблицами, ссылками и остальными полезными материалами.
Этап_4. Выход на плановые объемы разметки. Наши разметчики — штатные сотрудники, поэтому нам важно, чтобы ребята за рабочий день могли выполнять требуемый объем с нужным качеством. Если вы рассматриваете работу с самозанятыми (или другой «сдельный» формат), то вам не столь критично, если человек делает медленнее.
Главная метрика для нас — качество, и выход на план мы выстраиваем исходя из нее: сначала тянем вверх качество на небольших объемах, а затем стараемся ускоряться.
Этапы 1 и 2 — стандартная история, напрямую не относящаяся к разметке, поэтому мы посмотрим Этапы 3 и 4.
Цели обучения
Мы хотим:
хорошо обучать, чтобы все боевые данные были размечены качественно;
быстро включаться в новые проекты разметки;
экономить на обучении деньги, человеческий ресурс и нервы.
Для этого обучение должно быть:
Полным. Т.е. в тексте или других материалах должны быть ответы на все вопросы, не стоит какую-то часть оставлять только на устное обсуждение.
Простым. Это значит, что слова должны быть хорошо составлены в предложения, чтобы они воспринимались легко.
Удобным. Отдельные части стоит показывать на видео для наглядности.
Унифицированным (по возможности). Часть блоков обучения можно переиспользовать в других проектах, что сэкономит время. И ребятам будет проще, если при переходе к новой задаче структура и формат обучения сохраняется.
Это позволит быстро выводить ребят на требуемый уровень, а значит дата-сайентисты смогут оперативно тестировать свои гипотезы и получать первые метрики моделей.
Для упрощения обучающих материалов и инструкций мы ввели ряд базовых принципов их организации:
Все обучающие материалы собираем в единой базе знаний, раздробленной на разделы. Например, общая информация, обучающие вебинары, интересные статьи про разметку и ИИ, специфическая информация и обучение по проектам.
Обучение по проектам приводим к единому формату: выделяем период обучения, в котором первые дни посвящаем изучению общей информации в виде вебинаров и инструкций, а дальше уже погружаемся в специфику конкретного проекта. После обучения начинаем вывод сотрудника на плановые метрики.
В едином для всех проектов виде оформляем расписание, выделяя различные формы обучения: вебинары, работа с куратором, самостоятельная работа, тестовые задания, выход на плановые показатели.
Отдельно выделим советы (или лайфхаки), которые точно пригодятся:
Выделять «статичные» блоки, то есть те, которые меняются редко, и выносить их в виде вебинаров с презентацией. Проще для восприятия и сэкономит время тимлидов и кураторов для более приоритетных задач.
Важные смысловые блоки в обучающем материале выделять не только заголовками, но и тематическими смайликами/иконками, подходящими по смыслу — это визуально облегчает ориентацию по тексту.
Если блоки информации можно отразить в виде таблицы или схемы — непременно делать, так как такая информация легче воспринимается и быстрее усваивается.
И, конечно, меньше текста и больше примеров.
После нескольких дней изучения теории мы начинаем выдавать разметчикам тестовые задания, максимально приближенные к реальным проектам. Создаём тестовые проекты на платформе, подгружаем туда кейсы, для которых мы уже знаем корректную разметку (ханипоты, honeypots) и направляем новеньким ребятам. Во-первых разметчик привыкает к интерфейсу и набивает руку, а во-вторых старается выполнять «реальную» разметку и мы сразу видим результат его обучения и области, где остались пробелы. Впоследствии эти пробелы станут базой для проработки с куратором.
Выход на плановые метрики
После обучения и тестовых заданий необходимо вывести разметчика на плановые объемы разметки и при этом удерживать нужное качество разметки.
Раньше мы выделяли ~3 недели (для наших основных задач, требующих глубокого погружения), в которые требовали от ребят выполнения 50% от дневной «нормы», выполняемой опытными разметчиками. Далее уже переходили к 100% объему. Такой подход плох стагнацией сотрудника в первые 3 недели — многие ребята быстро осваивались, и начиная со второй недели не напрягаясь закрывали требуемый объём. Кроме того, прыжок +50% сильно демотивирует.
Мы решили ввести более равномерное повышение с линейным переходом от 50% до 100% за N дней, где N зависит от сложности проекта. Обычно, прирост составляет 10-20% в день. Как результат — сохраняем мотивацию ребят делать лучше и быстрее, но без резких потрясений.
Такой подход эффективен и позволяет сократить время выхода разметчиков на плановые объёмы разметки — в нашем случае с 3 до 1–2 недель. Но при построении поступательного плана роста объёмов разметки нужно учитывать следующие нюансы:
можно переборщить с темпами роста объемов, что приведёт к постоянным переработкам сотрудников и переутомлению;
сотрудник может сильно спешить с выполнением заданий и не замечать деталей, что приведёт к снижению качества — объёмы нужно поднимать постепенно;
темпы роста объемов задаются для каждого проекта в зависимости от сложности.
После того как разметчики прошли обучение и успешно вышли в продакшн, возникает необходимость в мониторинге их деятельности и анализе ошибок.
Часть 4. Система метрик и аналитика ошибок разметчиков
В процессе разметки данных основное внимание уделяется двум ключевым метрикам: качеству разметки и объёму размечаемых данных.
Качество разметки — соответствие разметки техническому заданию, описанному в Протоколе. Зависит от экспертизы разметчиков, корректности Протокола и способа верификации результата.
Объём данных — количество уникальных кейсов разметки, которые мы передаем разработчикам для обучения моделей.
Обе метрики играют критическую роль в успехе моделей машинного обучения. Чем лучше и больше данных размечаем, тем, наверное, лучше для модели.
Но мы говорим о ручной разметке, поэтому достоверно проверить весь объём данных вряд ли получится. Чтобы этого не делать, но иметь возможность повысить качество разметки и получать больше информации об успехах отдельных разметчиков, также пользуются метрикой согласованности.
Согласованность разметки — степень однородности кросс-разметки. Если мы хотим удобным способом косвенно мониторить результаты разметки, мы можем каждый кейс отдавать нескольким разметчикам. В зависимости от того, насколько «одинаково» они разметили конкретный кейс, мы делаем вывод о согласованности. Если несколько сотрудников разметили одинаково, считаем согласованность равной 1, если есть расхождения, то согласованность пропорционально уменьшается (если у нас не бинарная разметка true/false, то можно использовать непрерывные метрики, такие как IOU, если размечаете снимки).
Дальше уже можем принимать решения о том, что делать с несогласованными или частично согласованными кейсами, выставлять пороги и проводить переразметку, если необходимо.
Кросс-разметка даёт прирост качества, но пропорционально уменьшает объём размечаемых данных. Классический вопрос — баланс между качеством разметки и объёмом решается индивидуально для каждой задачи и достоверно только с помощью тестов: обучения модели на различных выборках и последующего сравнения модельных метрик.
Проверка качества разметки
Если мы рассматриваем разметку как ручной процесс, выполняемый людьми, то и валидация её качества, скорее всего, будет ручной задачей. Какие есть варианты валидации?
Не проверять качество, а ограничиться согласованностью. Не работает, если разметчики согласованно ошибаются.
«Золотые ответы», они же honeypots — заранее подготовленные кейсы, на которые мы априори знаем верный ответ, и незаметно подмешиваем разметчикам.
Выборочная проверка «эталонным» экспертом, мнение которого считаем абсолютно верным.
Кратко разберем эти подходы.
Согласованность — важная метрика, позволяет извлечь много информация про то, насколько задача понятна команде, где они допускают ошибки. Но, во-первых, это общая метрика, усредняющая результаты ребят между собой, а во-вторых, она может значительно отличаться от реального качества (например, если несколько разметчики одинаково ошиблись). Поэтому считать по ней KPI не очень удобно.
Honeypots — оптимальный подход. Вы можете заранее подготовить кейсы с нужным вам распределением (например, продовым) и в нужной пропорции подмешивать их ребятам. Сравнивая ответы разметчиков на ханипотах с известными правильными метками, можно объективно оценить их точность. Этот подход особенно полезен для больших проектов, где изменения задачи происходят не слишком часто. В нашем случае мы можем получать корректировки Протокола ежедневно, поэтому новые honeypots придется создавать каждый день, что трудно.
Поэтому мы в основном используем «эталонную» проверку экспертом, на основе которой рассчитывается метрика качества и KPI. Здесь может быть несколько подходов.
Первый — простая поствалидация true/false более опытном экспертом.
Подход ненадёжный, т.к. каждый из нас, имея перед глазами ответ, хоть немного похожий на правильный, будет иметь непреодолимое желание подтвердить, что так и есть, а не погружаться в задачу. Нам важно этого не допустить, поэтому мы используем «Слепую эталонную разметку». В ней эталонный эксперт самостоятельно размечает нужную выборку кейсов, и мы считаем, что согласованность между разметчиком и эталоном это и есть качество.
Как работать с данными по качеству и согласованности?
Согласованность удобно считать и из неё можно получать много полезной информации. Что именно?
Для хорошей разметки должен быть постоянный мониторинг ошибок, их анализ и разбор всей командой под руководством тимлида. Метрика согласованности позволяет сделать этот процесс эффективнее. Например, в задачах классификации текстов, имея много классов на выбор (у нас это 100-600) на основе несогласованных кейсов мы можем ранжировать и прорабатывать наиболее проблемные пары классов (т.е. где один разметчик присвоил класс А, а второй — класс B, и таких несогласованных кейсов больше всего). Это позволяет получать максимальный эффект в приросте согласованности (и, косвенно, качества и объёма данных для обучения) только за счет того, что мы знаем, где совершаем больше ошибок.
Еженедельно, а иногда и чаще, тимлид на общей встрече с командой разбирает наиболее важные несогласованные кейсы, выделяет новые паттерны, нюансы, фиксирует это в Протоколе и собирает ОС для команды Разработки и Продукта.
Аналогично с качеством. Мы проводим еженедельные разборы кейсов, которые были неправильно размечены по результатам «Слепой эталонной проверки». Если разбор несогласованных кейсов это способ выделить более общие паттерны ошибок, недопонимания внутри команды, то разбор некачественных кейсов — это уже точечная проработка с отдельными сотрудниками.
Зачем нам «качество», если «согласованность» итак дает всю нужную информацию?
Несмотря на значимость согласованности в процессе разметки, она не всегда является гарантом качества. Бывают случаи, когда даже согласованные кейсы могут содержать ошибки, связанные с недостатком компетенций разметчиков или сложностью. Для оценки таких случаев мы проводим численные моделирования, основанные на индивидуальных метриках качества каждого разметчика.
В рамках этих симуляций рассчитываем ожидаемую согласованность кейсов, исходя из вероятности правильной разметки каждым участником. Это позволяет оценить долю случаев, где высокая согласованность достигалась за счёт случайного совпадения ошибок или систематических недопониманий, а не реального соответствия Протоколу.
На графике синим цветом изображено распределение смоделированной ожидаемой согласованности, посчитанной из метрик качества индивидуальных разметчиков. Красным показана реальная согласованность. Разность между реальной и смоделированной согласованностью сигнализирует о потенциальном наличии согласованных, но некачественных кейсов.
Итого, когда мы добились достаточно высокой согласованности разметки, т.е. проработаны все очевидные сложности, пора задаться вопросом, а какая среди них доля ошибочно согласованных кейсов. В нашем случае они составили ~4,5%, что сопоставимо с долей некачественных кейсов. Дальше мы экспериментально это подтвердили.
Оптимизация времени разметки
Помимо оценки «как моя команда размечает», есть другая метрика, которая позволяет достать полезную информацию и оптимизировать работу — времязатраты. Мы анализируем время, которые тратят разметчики на присвоение каждого отдельного класса. Если мы видим, что на какой-то класс времени тратится больше, то делаем вывод, что либо конкретный человек плохо понимает эту тему (если только он тратит на неё много времени), либо сама тема плохо донесена до команды (если у большой части команды она вызывает затруднения).
Результат — выявление общих сложностей, точечная проработка с ребятами, ускорение процесса разметки.
Пример графика исторических временных затрат конкретного разметчика, где каждый столбец соответствует одному дню. Сверху вниз:
среднее число секунд, затраченное на один кейс;
число кейсов, выполненных в один день;
полное время активности разметчика на платформе разметки.
Из подобных графиков можно вынести множество инсайтов о продуктивности разметчика и его подходу к разметке. Например, на приведенном графике можно проследить процесс адаптации нового сотрудника к задачам разметки: в первые три недели разметчик проходит обучение, выполняя половину общего плана. Можно заметить, как увеличивается скорость его разметки от недели к неделе. После прохождения обучения разметчик может размечать полный объем кейсов в день, т.к. его скорость разметки увеличилась в два раза.
Выводы
Разметка данных — не всегда тривиальный, но понятный операционный процесс. Мы рассматриваем процесс именно ручной разметки, что подразумевает наличие человеческого фактора. Это значит,
во-первых, что многое зависит от найма и обучения команды,
а во-вторых, нам нужно уметь собирать много статистики и на её основе корректировать работу и принимать решения.
Сейчас разметка сильно меняется, особенно в задачах с текстовыми данными, благодаря LLM. Это приводит к изменению функционала команд, но не похоже, что в ближайшее время потребность в человеке будет снижаться. Простые задачи будут автоматизироваться, а разметчикам будет требоваться больше квалификации для решения оставшихся сложных кейсов.
Это первая статья по разметке данных, основанная на нашем опыте и результатах. Если будет интересно, то в следующих статьях рассмотрим другие аспекты нашей работы.
Над статьёй работали совместно с Заборенко Андреем — аналитиком разметки данных, и Кузнецовым Романом — руководителем проектов разметки. Отдельная благодарность всему Управлению разметки данных Альфа-банка за ежедневный труд и открытость к изменениям.
А чтобы быть в курсе новых статей и реализованных проектов, познакомиться поближе с командой Центра продвинутой аналитики и получать инфо об актуальных вакансиях — присоединяйтесь к нашему TG-каналу Alfa Advanced Analytics.
