Вчера я писал пост на тему того почему точность в качестве KPI на вход работы это плохо. Обещал сегодня несколько примеров. Поехали
История один – номера, но не авто
На границе тех лет когда мы начали использовать нейронки (2014-2015) – у нас уже был большой парк алгоритмов машинного зрения без нейронок. В том числе распознавание автономеров.
И тут нам предлагают договор по которому надо было распознавать другие цифровые последовательности, очень похожие на автономера. Причём целевая точность там была ~90% (а на номерах у нас было ~95% для хорошо установленной камеры).
У нас ещё особо не было опыта работы с фиксированными процентами, так что подумали/подумали — и взяли. Что мы сделали:
- Заложили цену процентов на 20-30 больше чем оценили объём работать
- Сравнили с имеющимся у нас решением и подходом
- Договорились что точность будет только на ограниченном датасете
Вроде как перестраховались всеми возможными способами.
Но… Оказалось что мы не учли:
- Номера выглядели сильно по разному. У автономеров 1-2 шаблона, а тут было 4-5. Из которых большую часть мы не заметили когда анализировали датасет (там были кластеры на 200-300 картинок).
- Неправильно заложили потери алгоритма детекции. Думали что сделаем почти 99%, а сделали 97-98%. Опять же из-за разнородности датасета.
А системные ошибки были банальнее:
- Не посмотрели другие решения на рынке. У крутых дядек было не сильно выше. Можно было что-то заподозрить
- Не попробовали разложить на разные этапы, оценив эксперименты
Как результат — получили не 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