Структура взаимодействия с заказчиками в задачах DL

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

Предположим у человека A есть некоторая проблема которая решается методами машинного зрения. И есть человек/команда B которая может эту задачу решить. Какой формат взаимодействия им выбрать?

За наши 9 лет работы, кажется, мы перепробовали уже всё. И сформировали достаточно чёткую градацию способов работы которые предлагают и дальнейшую последовательность действий. Сама градация достаточно банальная. Сначала распишем её, а потом покажем почему она не работает и к каким схемам мы пришли.

Вариант 1. Самый стандартный вариант, который первым приходит в голову самый банальный. B устраивается на работу к А. Но тут, как ни странно, есть масса подводных камней для обоих сторон.

Для A:

+Человек всегда при деле его всегда можно что-то обязать сделать

+При развитие продукта можно иметь некоторый уровень уверенности что технология поддерживается и находится в своих руках. Будет проблема или необходимость бизнеса – можно заставить быстро сделать.

-Если задача небольшая – зачем брать в штат дополнительного специалиста. Дополнительные обязательства.

-Постоянная оплата не кислая: хорошего DL специалиста в Москве можно нанять где-то за 150-250т.р. Это без учёта налогов.

-Найм работника != гарантиям что работник решит задачу. То что разумый работник работает в штате- не значит что задача может решаться в принципе.

-У работников нет стимула работать. Их зарплата не зависит от качества работы. Им не нужно выдавать идеальный результат каждый день. Они не разделят с вами ответственность.

Для Б:

+Стабильный доход

-Постоянное решение одной задачи не ведёт к развитию в современно DL. Он слишком обширен чтобы сидеть только в одной яме. Куда интереснее заниматься актуальными проблемами. Даже если задачи разные – всюду где я видел требовалась очень длительная работа по “доведению технологии”.

-Нет учёта “стоимости знаний”. Моих текущих знаний и опыта достаточно чтобы построить с нуля много различных инструментов для бизнеса. Причём это не знания которые мы подсмотрели. Это знания добытые кровью и потом в решённых задачах. При доведении технологий до продукта. Я знаю много примеров, когда ключевую технологию крупных компаний можно описать/написать за 1-2 дня. Я знаю, что искусству сбора базы под задачу с нуля можно учиться пару лет. И десятки баз будет собраны в пустоту.
Знание статей. Если вы знаете досканально актуальную подборку последних лет – то знаете оптимальные алгоритмы решения задач. Это может в десятки раз улучшать качество продукта.
Конечно, если стоимость знаний низка, или когда знания жёстко заблокированы NDA – это не вопрос

-Отсутствие стимула. Ты всегда знаешь, что если ты нихрена не сделаешь – получишь зарплату. Зачем вообще работать над чем-то скучным? Можно динамить задачи и плювать в потолок. В результате никакого развития.

Вариант 1.5. Работа не на полную ставку, а привлечение на почасовую зарплату для решения конкретной задачи. По сути тот же прошлый вариант, те же особенности. Существенным плюсом для работодателя обычно является возможность разорвать контракт как только поймёшь что работник не справляется/из работника выжаты все соки и задача решена.
Существенный плюс работника – обычно стоимость часа времени можно ставить сильно существеннее чем для обычной разработки.
Но опять тот же минус. Два полных дня разработки могут решить проблему заказчика, но пусть даже 50 тысяч рулей которые вы за это получите будут несравнимы с реальной сложностью задачи. Если бы заказчик разрабатывал это же с нуля – стоимость могла бы быть и 500 и 900 тысяч.
Кто-то может сказать “это выдуманная ситуация”. Но в реальности – нет. Если вы когда-то занимались распознаванием автомобильных номеров, очевидно что номера вагонов вам будет распознать значительно проще.

Вариант 2. Разработка под заказ.

Для А:

+Получает решение, минимизирует риски

+Гарантия итогового результата. Исполнитель подписывает договор, ведь так?

-Риск когда что-то отломается не найти техподдержку. Нужно отдельно прописывать в договор.

Для Б:

+Оплата идёт за результат. Можно знать как его достичь. Это значительно увеличивает цену часа.

+Нет всякой дополнительной мути в стиле “задизайнить окошки”, если только сами не захотите.

-Заключение договора и его обсуждение это большая работа. Зачастую заказчик может передумать

-Риск не выполнить работу

Вариант 3. Процент и вход в долю. Думаю, все проблемы для обоих сторон тут и так ясны и понятны.

——————————————————-

Могу поспорить, что то, что написано выше – не вызывает вопросов у большинства людей. Вроде всё правильно, всё стандартно.
Только вот самое прикольное – вся эта бадяга не работает когда дело касается разработки рабочей модели для Deep Learning системы.

Приведу пример:

Иногда ко мне приходят и спрашивают:
-Мы хотим сделать систему распознавания чеков.
-А вы видели хоть одну такую рабочую систему?
-Нет, но ведь мы хотим сделать не общую задачу, а для одного конкретного магазина.
-Вы видели хоть что-то похожее?
-Нет… Но в реальности нам нужно найти всего одно слово на чеке и цену! Ведь распознают же номера домов!

И эта задача уже значительно реальнее. Обычно её можно решить. Но:

  1. Нет ни одной статьи где это сделано
  2. Ближайшая задача которую мы делали – распознавание контейнеров
  3. Чтобы понять реалистичность этой задаче надо сначала проанализировать базу чеков, её качество. В лучшем случае у заказчика будет 100-200 чеков. Хотя и исключения бывают.
  4. Никто не может отвечать за точность работы алгоритма. Это может быть 98%, может быть 95%, а может быть 90%. Прошлый опыт может как-то сузить эти рамки. Так же как и наличие базы. Есть ряд задач где мы можем с высокой точностью оценивать качество итогового продукта.

Какую модель применить и как найти общий язык с заказчиком?
Вариант 1 и 1.5 отпадает – заказчику не нужны работники. У него есть одна определённая задача. Скорее всего маркетингового характера, или для конкретной системы крупного заказчика.
Вариант 3 отпадает. Он делает задачу для крупного игрока. Тут и прибыли то нет особой у него.
Остаётся вариант 2. Но он не рабочий. Нельзя сделать готовую систему с достоверными критериями.
Как быть?
Решение 1. Можно заключить договор на анализ алгоритмов. По сути, сделать минимальный прототип, найти подход к сбору базы к используемым алгоритмам. Зачастую такой прототип уже будет решать задачу заказчика. Он сможет показать его инвесторам, или внедрить в существующий рабочий пайплайн.
Риски. Конечно, этот вариант несёт риск для заказчика. А что если ничего не получится? И тут есть целое поле для возможностей:

  1. Разложить риск на части. Это не всегда работает и не всегда применимо, но, например:
    1. Если получаем процент <A% – возврат средств
    2. Если получаем процент >A% <B% оставляем аванс себе
    3. Если получаем процент >B% <C% получаем обговоренную сумму
    4. Если получаем >C% –  бонус
  2. Оплата по коротким этапам, каждый из которых небольшой, предсказуемый и на каждом из которых можно получить гарантированный результат
  3. Получаем сумму + процент с прибыли. В некоторых ситуациях это может быть приятный кусок, который для исполнителя будет плюшкой ради которой он будет вкалывать и не сможет отказаться. При этом сама сумма не такая критичная чтобы для заказчика рисковать. Один из вариантов – позволить исполнителю после работы использовать алгоритмы самому. Иногда это бывает интересно.

Решение 2. Очень часто заказчик – это не очень мелкая фирма. И она может позволить себе нанять 1-2 программистов-студентов. Сейчас студентам интересен DL и интересно поработать в проектах. При этом с своей стороны вы осуществляете руководство этими людьми. Компетенция остаётся у заказчика. Консультации и руководство – за разумную денюжку + бонус по запуску системы.
Очень многим заказчикам интересен такой подход. Ощущение что вас кинет свой программист меньше, чем что кинет аутсорсер. При этом нет ощущения что свой программист раздолбайничает, если вы видите что его используют на полную катушку.

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

Решение 4. Да. Всегда есть вариант репутации. Если заказчик крупный, понимает что ресёрч это сложно, а вам доверяет, то всегда можно запустить ресёрч плана “сделаете что догвоорились, а если не понравиться, то больше я у вас заказывать не буду”. Но на таком редко можно серьёзные деньги поднять.

Объёмисто получилось. Пожалуй завершу. Но мыслей по теме ещё много:)

3 thoughts on “Структура взаимодействия с заказчиками в задачах DL”

  1. Ёмко и здраво. И актуально. Спасибо. Систематизировали мои мысли по этому вопросу.

  2. К сожалению, на практике я пока сталкивался с более приземленными случаями:
    – работа за зп, с мотивацией и нормальной командой, но задачи на порядок более скучные по сравнению с публичными конкурсами
    – полный неадекват – по сути люди оценивают sota задачи как стоящие 10-15-30 т.р. от идеи до деплоя, платить не готовы за изучение вопрос, только пост-фактум
    – есть заказчик, который “бы купил что-то вроде распознавания речи по видео” за интересные деньги (такие статьи были недавно), но даже ни одного видео-примера естественно нету
    – про вакансии и то, какие люди управляют ML / CV based проектами зачастую вообще молчу

    Вероятно места надо рыбные знать / заниматься поиском заказчиков)

    1. Да не, к нам приходят обычно сами. Все знакомые группы которые разработкой занимаются – там плюс-минус то же самое. Главное чтобы заказчики видели статьи по интересным темам/знали компетенции.
      Мы это как-никак лет 9 уже нарабатываем. Ещё за долго до того как машинное обучение было в тренде.
      А фриков с “давайте вы нам за 30 тысяч сделаете систему с свистелками и хотелками и ещё гарантировав статистику” – конечно нужно нафиг посылать. И желательно чем раньше тем лучше.

      Но в любом случае нужно понимать, что Kaggle не имеет ни малейшего отношения к тому как задачки формулируются на самом деле, как они решаются. Зачастую сбор базы это не 50-60% задачи, а 90-95%.
      Задачи “kaggle-like” я конечно встречал в реальном продакшне, но это исключительно редко, да обычно и не нужно.

Leave a Reply

Your email address will not be published. Required fields are marked *