Любой разговор с заказчиками начинается с того что нужно как можно подробнее понять задачу. Чем дальше заказчик от ML, тем хуже он понимает какие есть варианты, как он собирается интегрировать решение, как оно должно работать и какие его ждут риски.
Разговор повторяется каждый раз. И надо не забывать все аспекты, все проблемы и все беды которые могут ждать готовое решение. У меня есть некоторый чек-лист/список, по которому я прохожусь каждый раз. По сути он был ещё лет пять назад, но тогда он был в голове, и был ограничен теми знаниями которые в тот момент были. В какой -то момент я решил его структурировать. Понимать не забыл ли что-то спросить (особенно это актуально когда большая задача и долго проговариваешь по каждому пункту).
Собственно какую-то версию текущего списка я решил и опубликовать. Вдруг кому пригодиться. Список не претендует на полноту (особенно если начать закапываться в глубину какого-нибудь пункта). Более того, какие-то пункты списка пересекаются, но это скорее про направление разговора, как подводить к одним и тем же мыслям с разных сторон, убеждаясь что заказчик понимает тяжесть своих решений. Но перед началом любой работы я стараюсь иметь полное представление по вопросам которые в нём подняты.
Данные
Любая DS задача начинается с данных и с методов их получения и обработки. Так и в Computer Vision. Что в моем представлении надо узнать/спросить?
- Аппаратура с которой получаются данные
- Как происходит съемка, какая её логика
- Что за техника? Телефоны/камеры/парсинг?
- Откуда поступают данные? Обычно самые распространённые способы:
- OpenSource – надо намайнить из существующих баз. Или заказчик дает ссылку на готовые базы?
- В реальном времени есть подключение к камерам, надо самим намайнить данные.
- Готовая база которую предоставляет заказчик.
- Мы собираем, для заказчика не важен способ. Нанимаем людей, через Толоку, и.т.д.
- Организовать процесс сбора у заказчика. Например силами людей заказчика
- Кто размечает данные. Тут вариантов не много обычно:
- Заказчик сам
- Заказчик сам, но мы настраиваем окружение разметки
- Мы сами, заказик только дает данные
- Кто-то ещё. Например ещё одна сторона контракта.
- В каком интерфейсе происходит разметка, если нужно размечать.
- Наш (я делал про него статью). Или пишем что-то специализованное.
- Заказчика (сами наисали что-то, или что-то используют)
- Что-нибудь OpenSource (тот же cvat или аналоги)
- Толока/Механикал турк (там есть встроенные разметчики, или что-нибудь дописываем)
- Супервайзли (или какие-нибудь ещё хитрые аналоги)
- Что-то ещё, несказанное/комбинация методов/авторазметка
- Операции с данными при обучении. Как организовано хранение данных передача, и.т.д.
- Бакеты
- Папки
- Какие-то сложные структуры хранения данных (datalake, итд)
- Прочие интерфейсы (базы данных со ссылками, и.т.д.)
- Данные при распознавании. То же самое но как будет флоу данных в проде
- Папки
- http-api
- Бакеты
- Базы данных
- Прямое подключение к камерам
- что-то ещё
Я не привожу в этом списке такого банального пункта как “посмотреть на данные”. Это подразумевается. Зачастую их вообще нет, зачастую заказчику надо организовать именно сбор данных.
Если данные есть – всегда проговариваю про семплы/про то как посмотреть.
Организация процесса, процесс как продукт
Очень важным является проговорить общую структуру работ. Часть вопросов тут напрямую не лежит в области ML, но без них нельзя сформировать в голове общую логику происходящего, оценить сложность и организацию.
- Процесс
- Этапность. Делаем ли все сразу, пробуем ли бить на этапы. Если бьем то как, на какие.
- Коммуникация. Какие люди есть в проекте, как будет организовано взаимодействие, передача данных, подключение, и.т.д.
- Документация. Как оформляем, как разворачиваем. Кто будет принимать.
- Прием/передача. Как это организуем. Кто принимает со стороны Заказчика
- Менеджмент решения. Кто поддерживает, кто разворачивает, следит за ошибками
- Права на решение. Особенно много надо обговаривать если у нас уже есть какой-то кусок который нужен заказчику, а не если это полноценная разработка
- Финансовая структура сделки. Тут в реальности очень много вариантов всегда, по тому как и в какие моменты организовывать оплату. Решаем по сути все под конкретного заказчика.
- Продукт
- Будет ли hooman in the loop и кто его будет поддерживать?
- Нужна ли возможность какого-то подключения оператора? Переобучения на базе оператора? Корректировка решений оператора?
- Что делать с ошибками? Важны ли они или нет для продукта.
- И многое многое другое. Тут обычно идеи возникают уже по ходу разговора что дальше спрашивать. Обычно все вопросы идут вокруг того как выглядит конечный продукт, какие у него будут дыры, и как их затыкать можно.
- Продуктовое развертывание.
- Гит, используем ли? Какой?
- Бакеты, организация данных
- Сервера, чьи где, если есть
- Оркестрация решения. Докер? Кубфлоу? Переносные устройства? Автоапдейт моделей?
Прочее
Ну, и масса прочих вопросов, каждый из которых это своя группа/направление разговора.
- Обучение. Делаем ли автоматическим/передаем ли заказчику? Нужно ли иметь возможность что-то дообучать? Насколько это решение должно быть стабильно.
- Как осуществляем передачу такого обучения? Кто ведет приёмку? Уровень специалистов. Как работать если решение нестабильное?
- Где разворачивать обучение? Гугл/амазон/прочие облака? Машины заказчика?
- Обучение постоянное? Нужно ли переобучать раз в день, или запуск по указке заказчика?
- Портирование. Нужно ли и куда?
- Тестирование.
- Делаем ли автотесты на переобучение?
- Как будем тестировать решение итоговое?
- Лицензии. Нужно ли что-то использовать хитрое? Есть ли необходимость покупки чего-то стороннего
З.Ю.
В последнее время свои статьи я публикую на очень разных платформах.
И, так получилось, что единое место куда я их свожу тут – https://vk.com/cvml_team (дублирую в https://t.me/CVML_team )
Подписывайтесь!