Наверное, самое главное, что сделал менеджмент - это в начале нарисовал большую схему процессов в компании и соединил её со списком документов, которые в итоге должны были появиться. Дальше осталось распределить задачи по ответственным (отделам) и в конце сверить часы. Ну и, конечно, подготовка основных документов - политика по качеству, руководство по качеству.
Аудит проходил в достаточно свободной форме. Например, меня просто попросили рассказать, как мы тестируем наши системы и мониторим их работу на продакшне. Какие инструменты используются, какие данные генерятся, какие отчёты мы в итоге пишем и какие действия предпринимаем.
с дообучением пока туго, и по техническим, и по юридическим, и по организационным причинам. а вот элементы адаптации есть - например, в препроцессинге изображений. и да, на практике лучше вообще не дать ответ, чем выдать чушь
ну на этот вопрос в вакууме нет смысла отвечать, мне кажется. какой домен, какая его специфика, требования к скорости, потреблению памяти, есть ли желание твикать архитектуру или чтоб из коробки заработало более-менее. ну, например, у нас DETR с модификациями с ходу заработал на уровне сильно-сильно затвикованного классического двухстадийного детектора. на том же COCO детры стабильно в топе
ну в том числе об этом и мой пост, что есть риски намного более явные, чем скайнет. хотя я всё-таки не думаю, что в плане интеллектуального труда всё так плохо. перестраиваться - да, придётся. и в плане творчества, и в плане интеллектуального труда. через какое-то время - и физического тоже
да, меня его писанина часто раздражает, особенно учитывая, что среди неё встречаются и реально интересные мысли.
в остальном тоже согласен, хотя мне лично, конечно, ближе и милее подход, что к мифическому "настоящему AGI" мы приблизимся архитектурным, а не брутфорсным путём. но тут да, ещё сильно зависит от выбранного определения AGI
Спасибо! На данный момент дела обстоят не очень - вакансий нет =) Мы довольно сильно росли в своё время (сейчас в отделе больше 20 человек), так что сейчас период, когда продажи догоняют этот рост.
про проекции - конечно =) но это не так просто, там геометрия совсем неочевидная. небольшой спойлер - у меня в мае доклад на Codefest, я там расскажу в том числе подробнее про то, какие способы мы пробовали. потом на ODS Data Fest, может, еще расскажу, чтоб в открытом доступе было сразу.
про артефакты - мы их часто размечаем, чтоб сетке кормить как hard negatives, либо отрезаем на препроцессинге, если возможно
наверное, подробно раскрывать не буду, всё-таки тематика блога не та, но в Англии я встречался с девушкой из Индии полтора года, побывал у неё на родине, познакомился с семьёй. очень интересный опыт как минимум с точки зрения культурного обмена)
очень жаль. я не сторонник перевода устоявшихся ML-терминов (estimate, shuffle, batch, dataset) на русский язык. это сбивает с толку и затрудняет понимание, пусть и смотрится иногда не очень красиво. пост чисто технический, про различные ML-техники, поэтому странно было бы ожидать красивую русскую прозу без английских терминов
я это вижу так - уменьшается количество людей, которым требуется знание узкоспециализированных скиллов, и устраняется боттлнек. например, у нас сейчас есть совсем небольшая дата-платформенная команда, при этом за качество доменных данных отвечают ML-щики в продуктовых ML-командах, и отдельный дата-инженер с глубоким знанием БД, Airflow, кубика и т.д. в этих командах не нужен
да, я полностью осознаю, что наш кейс весьма специфичный, и не ко всем ситуациям мои размышления подходят. но при этом мне всё равно кажется полезным принцип отношения к данным как к продукту, особенно в ML-core доменах
я читал дискуссии на эту тему, включая эту, мне они не кажутся очень продуктивными. слишком рано объявлять, что какой-то подход мертв или победил, да и в любом случае в каждой организации свои особенности, которые нужно учитывать при формировании дата-культуры и дата-архитектуры. некоторые принципы дата меш мне близки, и это уже делает более глубокое ознакомление небесполезным
данных действительно для тестирования по слайсам данных нужно больше, поэтому обычно такие штуки внедряют уже на более поздних стадиях развития продукта. в начале мы радовались, что вообще есть какие-то данные для тестов) но со временем требования к качеству, fairness и надёжности растут
да, верно, но часто такая возможность есть, например, есть анонимизированный айди. и тогда стоит заморочиться и учесть это
да, проблема знакомая, но способы её решения есть. репутационные издержки действительно очень сильные в случае таких ошибок
смотря для каких целей вы хотите на него ориентироваться. в каких-то компаниях джунам платят и 200, наверное. мы конкретно находимся в Питере, и у нас ребята-студенты получают от 80к нет
Наверное, самое главное, что сделал менеджмент - это в начале нарисовал большую схему процессов в компании и соединил её со списком документов, которые в итоге должны были появиться. Дальше осталось распределить задачи по ответственным (отделам) и в конце сверить часы. Ну и, конечно, подготовка основных документов - политика по качеству, руководство по качеству.
Аудит проходил в достаточно свободной форме. Например, меня просто попросили рассказать, как мы тестируем наши системы и мониторим их работу на продакшне. Какие инструменты используются, какие данные генерятся, какие отчёты мы в итоге пишем и какие действия предпринимаем.
с дообучением пока туго, и по техническим, и по юридическим, и по организационным причинам. а вот элементы адаптации есть - например, в препроцессинге изображений. и да, на практике лучше вообще не дать ответ, чем выдать чушь
ну на этот вопрос в вакууме нет смысла отвечать, мне кажется. какой домен, какая его специфика, требования к скорости, потреблению памяти, есть ли желание твикать архитектуру или чтоб из коробки заработало более-менее. ну, например, у нас DETR с модификациями с ходу заработал на уровне сильно-сильно затвикованного классического двухстадийного детектора. на том же COCO детры стабильно в топе
спасибо за ссылку)
ну в том числе об этом и мой пост, что есть риски намного более явные, чем скайнет. хотя я всё-таки не думаю, что в плане интеллектуального труда всё так плохо. перестраиваться - да, придётся. и в плане творчества, и в плане интеллектуального труда. через какое-то время - и физического тоже
да, меня его писанина часто раздражает, особенно учитывая, что среди неё встречаются и реально интересные мысли.
в остальном тоже согласен, хотя мне лично, конечно, ближе и милее подход, что к мифическому "настоящему AGI" мы приблизимся архитектурным, а не брутфорсным путём. но тут да, ещё сильно зависит от выбранного определения AGI
мне кажется, утверждения "LLM очень сильно переформатирует рынок интеллектуального труда" и "LLM далеко от AGI" вообще не противоречат друг другу
Спасибо! На данный момент дела обстоят не очень - вакансий нет =) Мы довольно сильно росли в своё время (сейчас в отделе больше 20 человек), так что сейчас период, когда продажи догоняют этот рост.
спасибо, приятно! а что именно вам показалось адекватным по сравнению с другими мнениями?
про проекции - конечно =) но это не так просто, там геометрия совсем неочевидная. небольшой спойлер - у меня в мае доклад на Codefest, я там расскажу в том числе подробнее про то, какие способы мы пробовали. потом на ODS Data Fest, может, еще расскажу, чтоб в открытом доступе было сразу.
про артефакты - мы их часто размечаем, чтоб сетке кормить как hard negatives, либо отрезаем на препроцессинге, если возможно
прочитал стейк сначала)
я руководитель ML-отдела в компании Цельс, делаем ИИ-системы для рентгенологии
наверное, подробно раскрывать не буду, всё-таки тематика блога не та, но в Англии я встречался с девушкой из Индии полтора года, побывал у неё на родине, познакомился с семьёй. очень интересный опыт как минимум с точки зрения культурного обмена)
очень жаль. я не сторонник перевода устоявшихся ML-терминов (estimate, shuffle, batch, dataset) на русский язык. это сбивает с толку и затрудняет понимание, пусть и смотрится иногда не очень красиво. пост чисто технический, про различные ML-техники, поэтому странно было бы ожидать красивую русскую прозу без английских терминов
я это вижу так - уменьшается количество людей, которым требуется знание узкоспециализированных скиллов, и устраняется боттлнек. например, у нас сейчас есть совсем небольшая дата-платформенная команда, при этом за качество доменных данных отвечают ML-щики в продуктовых ML-командах, и отдельный дата-инженер с глубоким знанием БД, Airflow, кубика и т.д. в этих командах не нужен
да, я полностью осознаю, что наш кейс весьма специфичный, и не ко всем ситуациям мои размышления подходят. но при этом мне всё равно кажется полезным принцип отношения к данным как к продукту, особенно в ML-core доменах
не совсем верно выразился - дискуссии важны, а вот громкие выводы - пока не уверен)
я читал дискуссии на эту тему, включая эту, мне они не кажутся очень продуктивными. слишком рано объявлять, что какой-то подход мертв или победил, да и в любом случае в каждой организации свои особенности, которые нужно учитывать при формировании дата-культуры и дата-архитектуры. некоторые принципы дата меш мне близки, и это уже делает более глубокое ознакомление небесполезным
привет! интересный комментарий
данных действительно для тестирования по слайсам данных нужно больше, поэтому обычно такие штуки внедряют уже на более поздних стадиях развития продукта. в начале мы радовались, что вообще есть какие-то данные для тестов) но со временем требования к качеству, fairness и надёжности растут
да, верно, но часто такая возможность есть, например, есть анонимизированный айди. и тогда стоит заморочиться и учесть это
да, проблема знакомая, но способы её решения есть. репутационные издержки действительно очень сильные в случае таких ошибок
смотря для каких целей вы хотите на него ориентироваться. в каких-то компаниях джунам платят и 200, наверное. мы конкретно находимся в Питере, и у нас ребята-студенты получают от 80к нет
machine learning =)