Что делать если заказчик хочет 95% точности в ML задаче?

Кажется, что тут я написал не одну статью про общение с заказчиками в специфике ML:

1. О типах заказчиков (посредники/непосредственные заказчики)
2. О том как можно структурировать взаимодействие с заказчиками (найм и договора специалиста/консультанта)
3. О том как менеджить своё время на общение
4. О том какая существует интеллектуальная собственность в ML
5. Про NDA

И внезапно я понял что нигде ранее я не затронул тему рисков в построении договора. Но это одна из краеугольных тем всего взаимодействия. Столько сил не уходит ни в одно из других обсуждений. Возможно поэтому и не писал. Каждый раз после очередного обсуждения рисков — не хочется об этом думать следующие пару дней.

Итак. О чём это. Это о KPI договора. Приходит заказчик и говорит: «Мы хотим делать детектирование объекта X с вероятностью 95%».
Что с этим делать?

В чём сложность?
Сложность в том, что в ML заранее невозможно знать точность решения (и количество сил которые понадобятся для создания). Грубо говоря, пока не обучишь модель — нельзя посчитать. Оценить кое-как можно. Но:

1. Черные лебеди случаются. Даже ваша супер крутая оценка может быть неточна, вы что-то не учтёте. И вам надо оценивать потери.
2. Нельзя оценивать малые числа. Предположим заказчик хочет 98%. Значит 2 ошибки на сотню. Даже если вы проглядываете глазами всё, и вам кажется всё хорошо — это не значит что где-то не затесались сложные кейсы. Даже если в другой похожей задаче у вас 99%, то нельзя понять с высокой вероятностью, будет ли это 98% в похожей.
3. Отдельная сложность — работа при низком качестве картинки. Если вы распознаёте номера и на хорошо установленной камере у вас 98% – не факт что будет на рандомной камере 98%. Можно сколько угодно прописывать «освещённость не менее..», «размер не менее..», «углы от и до..». Вы никогда не сможете оговорить всё. Ну, например грязные номера. «Загрязнённость не более 20%», – есть идеи как считать?:)
4. Конечно, иногда можно ввести характеристику «Совпадает с решением человека на 95%». Или «рассматриваются изображения где человек распознаёт в 100% случаев». Но и тут засада на засаде:
   1. Два человека могут быть менее точны друг по сравнению с другом — если задача неоднозначна (это не редко встречается). Вообще это хороший способ оценки того что можно вытащить (дисперсия разметчиков), но именно оценки.
   2. Человек может использовать неоднозначные преимущества, которые нельзя оценить в начале работ. Ну, грубо говоря, если мы распознаём текст — у человека есть большая база априорного знания по языку. Мы не можем знать хватит ли обучающей выборки чтобы натренировать сеть на контексты. Или, если мы распознаём автономера, то человек без проблем сможет распознать номер повёрнутый на 90 градусов (встречается на строках). А сеть не сможет без специального алгоритма/обучения, который надо отдельно заложить.
5. Иногда пробуют провести оценку на фиксированном датасете. Но это тоже не очень хороший вариант. И, глобально, это не отменяет пункты 1-4.

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

Поговорим про риски

Есть и другая, чисто экономически-статистическая причина не работать с процентом на выходе:

• Процент на выходе это всегда риск не выполнить работу
• Для заказчика наступление рискового случая — не получить результат на выходе. Для вас — проработать впустую. Чем меньше у вас фирма и чем меньше параллельных заказов – тем критичнее это
• При заказе ML системы заказчик покупает готовый результат. И если ему не нравиться — он так или иначе может попробовать слиться. Этот кейс возможен не только при жестком проценте на выходе. Но всё же, следует минимизировать его договором. А если вам хочется сделать что-то за бесплатно – то можете вложиться, сделать, а потом продать 2-3 заказчикам:)
• Если вы привлекаете исполнителя какой-то части работы и платите ему — это ваши однозначные потери, если наступает риск. А привлекается кто-то почти всегда. Разметка, какой-то минимальный бэк/фронт-энд. Опять же – у вас однозначные потери.

Можно сказать так. Ну давайте мэнеджить риски! Давайте заложим в стоимость вероятность того что работа не удаться, вероятность того что заказчик сольётся, вероятность того что понадобиться дополнительная доработка. Ну, как-то так:
((Объём работы)+(Вероятность что работа будет больше)*(Объём доделок))/(1-Вероятность того что работу не примут).

Но только вероятности в этой схеме вы как-то должны оценить. Даже у меня, при 5-6 контрактах в год нет понимания как это сделать хорошо. Слишком многое я видел. А оценивать риск ± пол километра — заказчик сбежит от такой цены.
И даже если всё оценивать правильно — то всегда остаётся небольшая вероятность того что вам не везёт и вы уходите в глубокий минус.

Короче, если бы я хотел рисковать — то нашёл бы способ проще, вложился в какой-нибудь стартап.

Ну ладно/ладно. Но что делать-то?!

Вариант один – отказываться

Первый вариант, к которому я склоняюсь всегда когда предлагают фиксированный процент в работе — отказаться/отговорить заказчика. Особенно если уже есть текущие контракты. Если нет, а работа кажется выполнимой — предложить с учётом всех наших рисков. Зачастую, для простой с виду работы — это раза в 2. Для сложной — в три/четыре.
И честно рассказываю заказчику что если риски он берёт на себя — цену снизим. Обычно отказываются:)

Вариант два — дорабатывать готовое решение

У нас накопился большой багаж своих поделок, зачастую которые позволяют ускорить разработку/тестирование. С теми же автомобильными номерами. Мы можем предлагать какие-нибудь варианты уровня: «качество распознавания Британских номеров не хуже чем текущее качество Российских». Где нам не надо прописывать процент точности в договоре. Зачастую такой риск можно взять на себя, ибо это знакомый продукт, где мы знаем все сложности.

Для новичков этот вариант плохо годиться. Разве что в варианте «посмотреть точность opensource, доработать его». Но как водиться, не зная броду не суйся в воду. Зная качество OpenSource кода — я не готов ставить на это свой доход… Исследовать/протестить да. Работать под фиксированный процент результата — нет.

Вариант три — использовать шаблон

В какой-то момент мы разработали систему которая позволяет автоматизировать обучение 50% наших заказов. При этом мы предлагаем фиксированный контракт: аванс размером X + если заказчика устраивает результат — дооплата ~ 2X и передача исходников.

Это очень упрощает общение. Заказчик знает что он получает возможность посмотреть на результат в цену примерно 1/3 рынка, а если ему нравиться — мы готовы в течении пары дней передать ему его целиком за финализирующую оплату.
Ну, и для нас выгодно. Половина цены работы — по сути чистая прибыль. А риски нулевые, так как предоплата всегда за нами.

Но, конечно, далеко не все работы можно переложить на этот подход.

Вариант четыре — разбивать на этапы

Иногда можно договориться с заказчиком разбив работы на несколько исследовательских этапов, которые заказчик оплатит отдельно. Но, зачастую, заказчик не готов рисковать никакими деньгами. Вложить в 2 исследовательских этапа и получить результат: «у вас ничего не будет работать», – мало кто готов.

Вариант пять— оценить на готовых примерах/ готовых существующих продуктах

Бывает что можно подсмотреть как кто-то что-то делает. Предположим молодая компания сделала точность распознавания людей X за месяц. А OpenSource дают точность X/2. Скорее всего это значит что можно получить точность в 3/4X просто переобучив OpenSource под ваш случай.
И точно понимать что точность выше X для данной задаче вообще невозможна. Но как всегда есть варианты продолбаться:

1. Неправильно оценить размер работы другой компании
2. Неправильно угадать каким методом они делают
3. Неправильно угадать квалификацию другой компании

Скорее я бы использовал этот подход как ещё одну оценку объёма работ, но точно бы ни ставил на него.

Что-то затянулась статья:)
Так что разобью её на две части. И завтра приведу несколько примеров того как договаривались по рискам, как договаривались по рискам в реальных проектах, и к чему это приводило. Как всегда все свои статьи публикую ещё тут – https://vk.com/cvml_team