Ребята, поделитесь информацией как у кого организована работа в командах?

Сорри за длинный текст).
У подавляющего большинства моих знакомых дата сайнтистов почти никогда нет ревью кода, и частенько нет ревью хода эксперимента, только анализ метрик и забор бинарных файлов-моделей. На мой взгляд, это не очень, это банально неэффективно, когда лид не чекает какие-то вещи и не дает рекомендации как что-то можно улучшить в будущем.
Я работаю параллельно в development (в том числе вывод в прод мл) и в самом мл инжиниринге, и я вижу просто огромный разрыв между организацией в dev командах и data science командах. Дело не только в devops и авто devops, ci/cd и прочем, потому что в мл сейчас вполне можно тоже и автодеплой млопсить сразу в кубер, и метрики трекать централизованно, а именно дело само в деталях мониторинга и контроля работы того, что делает дата сайнтист на уровне чистоты кода и корректности построения эксперимента, его хода, выбора решений, хотя бы на базовом уровне - ревью в гите с апрувом след стадии передачи в прод, например (есть спец аддоны для ноутбуков), выделение общих репозиториев под повторяющиеся куски кода из ноутбука в ноутбук и прочее.
Может какие-то источники хорошие посоветуете по хорошим техникам организации работы команд? Много есть примитивной воды типа описания стадийности - прототипирование, оптимизация гиперпараметров, вывод в прод и прочее - но это не организация детальная в части именно процесса выделения и ведения таски конкретной, применения конкретных инструментов.

ods.ai там курс есть специальный))

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

Привет! Интересная тема. Я например на 100% за ревью всего кода, но, увы - это стоит кучу денег для бизнеса. У нас сейчас дела обстоят так - если это просо какое то исследование то ревью у нас не проходит, только если результаты подозрительные тогда обычно руководитель просит кого то из нас (но не того кто изначально писал код) повторить эксперимент либо на немного других исходных данных или еще как то. Если же речь идет про что то, что идет в прод (модель, даг записывающий резалты в бд и так далее) - то тут уже идет двойное ревью, от тимлида дс и от тимлида разрабов продукта

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

у нас весь код идущий в прод пишется в pycharm, дальше в нашу репу ДС, там проходит ревью от тимлида ДС и если это идет в прод то дальше модули перекочёвывают в репу продукта, там еще ревью тимлида разрабов и в итоге встраивается в продукт

Да, всё так. Но большинство дс-ов считают, что раз они знают математику, то соблюдать стандарты кодирования им вовсе не обязательно

Лучше соблюдать минимальные требования на код, чтоб он был человекочитаемый хотя бы. Можно взять.любую книгу по рекомендациям программирования. Выделить самое основное. Плюсы выполнения элементарных правил: - систематизация работы - увеличение собственной продуктивности - облегчение жизни команде: например, коллеги тупо будут меньше тратить времени, чтобы понять, что за "2+2" имется ввиду. Не говоря уже о чем-то умном или о введение нового человека в курс дела - гибкость моделирования. Допустим, вас попросят через месяц попросят добавить фичу, желательно быстро. И тут может быть проблема - вместо 60 мин, вы потратить нервы и еще пару часов на осмысление/вспоминание (хорошо, если проект простой), а возможно и усложнить жизнь другим - читаемость улучшает качество. Будет больно через какое-то время понять, что было что-то не так, потому "1.5+1.5 оказалось 2.5" (утрирую) - бизнес процессы ускоряются. Легче внедрить, легче поддерживать. Меньше времени вас парят вопросами "а что, а почему, а зачем" и т.п. - ну и как минииум - из минусов, кроме оправдания минимальной собственной лени - их в общем-то нет...

спасибо еще раз, начал смотреть первую лекцию - реально я об этом и спрашивал, супер:)

А как называется?

https://ods.ai/tracks/ml-in-production-spring-22