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

Вчера я писал пост на тему того почему точность в качестве KPI на вход работы это плохо. Обещал сегодня несколько примеров. Поехали

История один – номера, но не авто

На границе тех лет когда мы начали использовать нейронки (2014-2015) – у нас уже был большой парк алгоритмов машинного зрения без нейронок. В том числе распознавание автономеров.
И тут нам предлагают договор по которому надо было распознавать другие цифровые последовательности, очень похожие на автономера. Причём целевая точность там была ~90% (а на номерах у нас было ~95% для хорошо установленной камеры).
У нас ещё особо не было опыта работы с фиксированными процентами, так что подумали/подумали — и взяли. Что мы сделали:

  • Заложили цену процентов на 20-30 больше чем оценили объём работать
  • Сравнили с имеющимся у нас решением и подходом
  • Договорились что точность будет только на ограниченном датасете

Вроде как перестраховались всеми возможными способами.
Но… Оказалось что мы не учли:

  1. Номера выглядели сильно по разному. У автономеров 1-2 шаблона, а тут было 4-5. Из которых большую часть мы не заметили когда анализировали датасет (там были кластеры на 200-300 картинок).
  2. Неправильно заложили потери алгоритма детекции. Думали что сделаем почти 99%, а сделали 97-98%. Опять же из-за разнородности датасета.

А системные ошибки были банальнее:

  1. Не посмотрели другие решения на рынке. У крутых дядек было не сильно выше. Можно было что-то заподозрить
  2. Не попробовали разложить на разные этапы, оценив эксперименты

Как результат — получили не 90%, а 87%. Естественно заказчик недоволен. В результате пришлось потратить раза в 2-3 больше времени чем планировали. В итого сделали, точность была 91% где-то. Но это был один из самых выматывающих контрактов в нашей жизни.
А самое обидное — к концу того же 15 года уже стало возможно сделать то же самое на нейронках с точностью раза в 2 больше за время раза в 2 меньше.

Задетектировать много и разного

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

  • Сделали небольшой свой ресёрч, потратив 1-2 дня, и оценив процент по аналогичному примеру (он был реально очень похож, разница была как в разных типах номеров)
  • Заложили сложную структуру цены/рисков, прописав её в договоре, чтобы риски разложить между нами и заказчиком. Примерно так:
    • Аванс остаётся если работа сделана по формальным признакам
    • Если точность несколько хуже договоренной — оплата 80%
    • Если точность заявленная — оплата как договаривались
    • Если точность ощутимо выше заявленной — оплата на 20% выше
  • Заложили в стоимость +20-30% относительно цены исследования
  • Разложили на несколько этапов

Естественно, когда мы оценивали сколько наш алгоритм даст реально — закладывали чтобы точность была ощутимо выше заявленной. И если мы оценили уровень ошибки в 2%, то по договору заложили 5% – спокойно, а диапазон 5-8% стоил нам 20% суммы договора, которая покрывалась увеличенной его стоимостью.

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

Лучше чем у Гугла

Однажды заказчик очень хотел заложить в договор точность. Обсуждали это дня 3-4, составляя разные варианты, стараясь разложить все риски. Но в итоге ударили по рукам с просто формулировкой (которую заложили устно) – «точность распознавания текста по приведённым примерам должна быть выше чем у гугла».
При этом нами ожидалась точность сильно больше. К тому моменту был и наш опыт, показывающий что можно получить сильно лучше. И был продукт в сравнимой категории, где ребята тоже сделали раза в 2 лучше гугла.
Сама формулировка нам нравилась. У гугла точность была от силы 10% правильных распознаваний, что давало нам люфт в много раз от оценки.
Но, как водиться, в мире нет ничего постоянного. За те два с половиной месяца что шла работа Гугл, видно, затюнился по тем же данным что и мы:)
Точность гугла скакнула с 10% до 30-40.
И самый облом вышел когда мы замерили результат — и получили почти один в один как у гугла.
Слава богу это был предварительный результат. Когда заказчик подключил обучение на своей полной базе — точность скакнула ещё процентов на 10-30, в зависимости от типа надписей.
Так что вроде сделали всё правильно. И точность оценили с запасом, и риски разложили, и аналоги проанализировали, и опыт имели. Но одна неаккуратная оговорка могла стоить всей работы)
С тех пор не хочу привязывать договоры к точностям чужих систем:)

Иногда лучше не взять договор

Недавно была шикарная история о том как потратили неделю, пять-шесть созвонов, и так не смогли договориться по рискам. Заказчику был нужен перевод на embedded платформу его текущего алгоритма с сохранением точности (вот и фиксированные проценты).
Но тут, как всегда, засада — хрен знает что у заказчика/насколько хорошо всё у него сделано. Это можно оценить лишь умозрительно. Аккуратный анализ позволил выяснить что информация которую передал заказчик в начале — не соответствует действительности. Не то он плохо понимал что у него в текущем ядре написано, либо целенаправленно пытался утаить часть информации.

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

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

Автономера

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

С номерами логика обычно очень простая. Мы готовы дорабатывать под заказ, но с условием “точность будет не хуже чем для текущих регионов”. Заказчик получает для себя гарантию качества продукта, а мы свободу от неадекватного ТЗ. Единственное – у заказчика остаётся необходимость протестировать текущие номера которые распознаются и понять нужно ли ему это или нет.

Работает ли это? Да. Среди всех 7-8 доработок что мы делали была всего одна проблема, ещё лет пять-шесть назад. Заказчик выдал один датасет для тестов, на котором всё замечательно работало. А сам начал тестировать на другом, куда более плохом, где человек половину не мог различить (это ещё до нейронок).
Слава богу это был промежуточный менеджер, разговор с его руководством позволил всё быстро уладить. Так и не поняли что это было.

Наш текущий подход

В последнее время, как я и говорил, мы стараемся идти по пути “тестируем качество на нашей универсальной системе“. Если заказчика удовлетворяет – то передаём исходники/осуществляем перенос на целевую платформу, и.т.д., и.т.п.
За последние 5-6 контрактов в таком режиме никаких сложностей не было. Более того, не было ни единого решения отказаться от результата. Вот всё ждём:)
Минус этого подхода – он не для всех задач возможен. И особенно сложности начинаются если есть портирование.

Статистика

Часто ли заказчики отказываются работать с нами когда мы рассказываем что не работаем с фиксированными процентами точности? Да, достаточно часто. Но сложно сказать про каждый раз что их не устраивает. Кого-то может цена, кому-то лично не понравились, кому-то оценка точности.
Наша позиция по этому вопросу – лучше работать спокойно, чем сидеть на иголках. Пока контрактами плюс-минут загружены – не хочется гоняться за сомнительными. Работает как дополнительный фильтр.

Но с появлением системы обучения – как нам кажется часть контрактов получилось зацепить.

Часть получается переубедить заказчиков договориться на каких-то промежуточных условиях (например что было выше описано)

Уффф. Надеюсь когда-нибудь оформлю из всего этого потока сознания более осмысленную статью. Если у вас остались вопросы – пишите тут, или здесь – https://vk.com/cvml_team