Рефлексия разработчика: как мы переписали ядро продукта с нуля и что из этого вышло

Мы переписали наш продукт за новогодние праздники. Таким мог быть заголовок, но кликбейт не в нашем стиле, и пока мы писали статью и допиливали новую версию наступил июль. Привет, меня зовут Давид. Я тимлид команды разработки и мы уже встречались в статьях раньше. В этой буду рассказывать про ядро системы для обработки документов. Про DOCR-4.

Вы можете спросить как расшифровывается DOCR. И я вам отвечу: Documents Optical Character Recognition. Но есть ещё такие версии: Dbrain Optical character recognition и Doc(ument) R(ecognition). Мы можем придумать еще кучу вариантов, но на самом деле, особого смысла мы в название не закладывали.

Ещё смешно, что у нас никогда не было DOCR-1 и DOCR-2. Сразу появился третий. Если коротко про него — это огромный бегемот, который очень быстро рос из-за новых фичей. К тому же его писали больше 100 людей в разное время. Поэтому никто не разбирался в его структуре, а иногда и в коде.

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

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

Он не отвечает за управление людьми. Этим занимается отдельный сервис — HITL, мы о нём рассказывали раньше. DOCR делает только то, что может делать автоматически.

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

Как выглядит процесс работы ядра:

1. Пользователь отправляет изображение документа через API.
2. DOCR, в зависимости от запроса, понимает какие сервисы, и в каком порядке ему нужно использовать для обработки конкретного документа.
3. Сервисы по очереди обрабатывают изображение: находят документ, обозначают его тип, определяют координаты полей с текстом, распознают текст, проверяют картинку на фрод.

Взаимодействие между отдельными шагами сервисов называется пайплайн.

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

Раньше мы жили в парадигме, что у нас один большой ветвистый пайплайн обработки документов. Одно из ключевых изменений в том, что теперь в системе можно реализовывать много разных пайплайнов, в зависимости от того, что хочет клиент. И выбранный пайплайн не будет запускать и триггерить остальные сервисы.

Что ещё:

• Скорость обработки документов увеличилась в 6 раз. Теперь среднее время обработки на потоке составляет 0,5 секунды. Скорость обработки одного изображения будет меняться в зависимости от размера. Кривую зависимости скорости от размера мы потом вам нарисуем.
• Ускорили обработку гипотез. Если человеческим языком — то все желания наших лидов выполняются быстрее. Хотите демо для своего кейса — хорошо, сделаем. Быстро и дёшево.
  
  За счёт чего быстро и дёшево? Представьте большой набор лего. Из него вы можете построить Звезду смерти, которая нарисована на упаковке или замок, карету и башню в которой принцесса живёт. Вот так и с демо. У нас есть много продуктовых кусочков, которые мы можем собрать в то, во что захочет клиент (это и есть пайплайн).У нас есть собственный no-code редактор, в котором мы можем создавать динамические пайплайны, без участия разработки.
• Пункт под звёздочкой, потому что его доделываем сейчас. Авансом, короче — динамически-генерируемые красивые демо. Грубо говоря, как только готов пайплайн, под него генерируется демо.
• Ну и не можем без новых форматов, так что теперь поддерживаем GIF, WebP, HEIF/HEIC.
• Повысилась стабильность. Мы переделали формат ошибок. Раньше был сложный и непонятный текст. Теперь и вы, и мы понимаем где возникла ошибка и можем её быстро решить.
  

Смеюсь, статья как рефлексия. Теперь внутреннее устройство продукта напоминает пирамиду из четырёх ступеней.

Это чёткое разделение позволило упростить продуктовую часть. Три верхние части — разные уровни продуктовых фичей, а фундамент — это ядро, к нему имеет доступ очень узкий круг людей.

Почему мы не дошли до этой пирамидки раньше? Так не было реквеста пирамидку рисовать. Ладно, шучу.

Чтобы понять, как ядро должно быть устроено, надо было увидеть большое количество разных сценариев использования продукта нашими клиентами. И пока у нас их не было, картинка не складывалась. Команда sales летела вперёд, а dev-команда старалась реализовывать все хотелки.

Получалось, что к нам прибегали с горящей… душой и просили: «Пацаны, пацаны, давайте вот такую фичу сделаем, срочно». И все бежали делать фичу. А эта фича хоть в продукт и встраивалась, потом никто не мог её найти, потому что не было структуры. Не было гайдлайнов. Получалась свалка.

Но мы учимся, становимся умнее. Теперь есть пирамидка, поэтому у каждого реквеста есть своя ступенька для реализации.

Если честно, это просто небо и земля. Не знаю кому кроме команды это будет интересно, но расскажу, вдруг у вас сердечко ёкнет.

• Новая система настолько понятна и логична, что ML-команда может спокойно писать куски кода, который после ревью можно пускать в прод. Это быстро и требует меньше усилий от всех команд.
• Появилась телеметрия — это способность заглянуть в происходящее. Например, отправили вы картинку, возникла какая-то ошибка и результат получился так себе. В DOCR-4 можно посмотреть на каждый шаг: что было на входе, что было на выходе, сколько времени занял каждый этап.
• Основной бенефит для нашей команды sales — скорость в получении всех своих хотелок. Кастомная демка — пожалуйста. Кастомный запрос — соберем за день.В идеале мы создадим так много кусочков продукта, что из них можно собрать всё, что нужно клиенту. Идея в том, что этим смогут заниматься все, не только команда разработчиков.На самом деле, мы уже это ощущаем. Всё больше задач перетекает в плоскость пайплайнов, а не кода.
• Мы можем обновлять сервисы без выкатки новых релизов. Например, изменить веса моделей в конкретном сервисе просто их обновив, а не стареть в ожидании релиза.

Да, продукт стал проще, прозрачнее и системнее. Просто невообразимо прекрасный. Но работы ещё много. У нас есть ещё тех.долг, который мы уверенно копили и пока ещё не весь разобрали. Сложно за пару месяцев переписать историю разработки 100 человек за 5 лет.

Ну вот, вам всё рассказал, пойду работать. Ещё документацию писать.Спасибо вам за внимание. Распознавайте документы с Dbrain, мы классные ребята.

#python #ai #idp