tgoop.com/eboutdatascience/146
Last Update:
Как не обкакаться при старте ML-проекта (Часть 2/2)Очень часто в компаниях так бывает, что команды делают ML-продукт ради ML-продукта, не понимая того, что хотел заказчик, и зачем модель в целом нужна бизнесу. Обычно это происходит из-за того, что разработчики и заказчики не слышат друг друга
И тут встаёт вопрос:
А как определить проблему так, чтобы обе стороны максимально понимали друг друга?
Алгоритм для того, чтобы наконец-то начать понимать и слышать друг друга:
Алгоритм похож на перевёрнутую пирамиду, которая начинается с понимания самых примитивных вещей и заканчивается более глубинными понятиями
В самом начале мы формулируем проблему, формулировка которой будет понятна любому руководителю уровня C (СTO, CEO, ...).
Например: "В нашем приложении есть мошенники, которые пытаются атаковать наших пользователей. Если определять мошенников, то мы сможем обеспечить более надёжную безопасность приложения."
Это нужно, чтобы погрузиться в детали и конкретные проблемы, которые может решить наша система, также нужно стараться найти несоответствия в ответах и противоречия, так как это наш самый главный враг.
Например: "Что такое мошенник?", "Как он вредит?", "Вредит ли он вообще?"...
Погружаемся ещё глубже и вычленяем подробную информацию и технические детали по имплементации решения.
Например: "Как мы технические определяем, что это мошенник?"
Итог
Перед написанием кода уточните с помощью данного алгоритма следующее:
- что вы хотите в целом делать
- зачем вы хотите делать
- что означают сущности, с которыми вы будете работать
И всеми возможными способами мучайте бизнес, чтобы расставить все точки над И.
Лучше потратить несколько дней на эти вопросы, нежели 3 месяца обучать модель и выкинуть её в окно (P.S. Джейсон Стейтем)
Материалы взяты из книги Валерия Бабушкина
