Интерпретация
Для тех, кто слабо себе представляет простоту организации нейросетей - пару слов об этом. Нейросеть это большая функция от миллионнов параметров f: x -> y. X это какие-то входные данные превращенные в числа: текст, картинка, таблица, звук и тд. Y это результат работы модели.
Что такое обучение нейросети: давайте подберем значения параметров функции так, чтобы они лучше всего переводили значения из пространства входных параметров (x) в ответы (y), и это делается определенными математическими методами оптимизации.
За более подробным рассказом - зовите пить пиво.
На выходе мы получаем обученную огромную функцию, значения параметров которой интерпретировать напрямую не является выполнимой задачей. Человек существо консервативное и работать с черными ящиками мало кому понравится. Именно поэтому существует целое направление - интерпретация нейросетей. Об этом и хочется сегодня поговорить.
В первую очередь хочется поразмышлять, что такое интерпретируемое поведение, вопреки базовой интуиции это не такой уж и простой вопрос.
Если задать вопрос википедии она скажется, что интерпретация - это способ познания, который изучает внутреннее устройство, через внешние проявления.
Из книги "7 навыков высокоэффективных людей" можно вспомнить такое понятие как "призма". Каждый человек смотрит на мир через какую-то свою призму, а потому как он поступает и что говорит, окружающие пытаются понять как он устроен внутри. Чем более разные призмы у двух индивидов, тем более по-разному они смотрят на жизнь, тем сложнее им найти общий язык и, в случае, если они обязаны существовать в одном социуме - им бы сводить их призмы в единую систему координат. По факту, нейросети с точки зрения интерпретации устроены аналогично. Есть стимул (это входные данные в нейросеть), есть внутреннее осознание (взаимодействие параметров модели с входными данными) и реакция (результат работы нейросети).
Кто из читающих этот пост готов с уверенностью заявить, что знает досконально кого-то из своих знакомых, или даже самого себя? Или более формально: знает реакцию на любой стимул. Как следствие тема "интерпретации" скорее близка самураю с его путем без цели.
В связи с вышесказанным, задачей является скорее не изучить досканально за что отвечает каждый параметр модели, а сблизить призму нейросетей с усредненной человеческой призмой, чтобы людям легче было воспринимать новые технологии.
Пост не поместился, продолжение сразу далее...
@lechim_ai
Для тех, кто слабо себе представляет простоту организации нейросетей - пару слов об этом. Нейросеть это большая функция от миллионнов параметров f: x -> y. X это какие-то входные данные превращенные в числа: текст, картинка, таблица, звук и тд. Y это результат работы модели.
Что такое обучение нейросети: давайте подберем значения параметров функции так, чтобы они лучше всего переводили значения из пространства входных параметров (x) в ответы (y), и это делается определенными математическими методами оптимизации.
За более подробным рассказом - зовите пить пиво.
На выходе мы получаем обученную огромную функцию, значения параметров которой интерпретировать напрямую не является выполнимой задачей. Человек существо консервативное и работать с черными ящиками мало кому понравится. Именно поэтому существует целое направление - интерпретация нейросетей. Об этом и хочется сегодня поговорить.
В первую очередь хочется поразмышлять, что такое интерпретируемое поведение, вопреки базовой интуиции это не такой уж и простой вопрос.
Если задать вопрос википедии она скажется, что интерпретация - это способ познания, который изучает внутреннее устройство, через внешние проявления.
Из книги "7 навыков высокоэффективных людей" можно вспомнить такое понятие как "призма". Каждый человек смотрит на мир через какую-то свою призму, а потому как он поступает и что говорит, окружающие пытаются понять как он устроен внутри. Чем более разные призмы у двух индивидов, тем более по-разному они смотрят на жизнь, тем сложнее им найти общий язык и, в случае, если они обязаны существовать в одном социуме - им бы сводить их призмы в единую систему координат. По факту, нейросети с точки зрения интерпретации устроены аналогично. Есть стимул (это входные данные в нейросеть), есть внутреннее осознание (взаимодействие параметров модели с входными данными) и реакция (результат работы нейросети).
Кто из читающих этот пост готов с уверенностью заявить, что знает досконально кого-то из своих знакомых, или даже самого себя? Или более формально: знает реакцию на любой стимул. Как следствие тема "интерпретации" скорее близка самураю с его путем без цели.
В связи с вышесказанным, задачей является скорее не изучить досканально за что отвечает каждый параметр модели, а сблизить призму нейросетей с усредненной человеческой призмой, чтобы людям легче было воспринимать новые технологии.
Пост не поместился, продолжение сразу далее...
@lechim_ai
🔥8👍1
Философская часть закончилась, переходим к более технической: к некоторым методам повышения интерпретирумости работы модели. Как специалист из области медицины - буду приводить примеры скорее оттуда.
1. От глобального к локальному. Переход от задачи классификации по изображению к задачам детекции, сегментации или на худой конец определения heatmap.
Конечная задача для врача, при просмотре мед. снимка сделать заключение, отталкиваясь от находок на изображении. Поэтому врач решает скорее задачу классификации. Это снимок с туберкулезом, на этом снимке есть гидроторакс и тд. При этом он не готов брать на веру, если в таком же ключе ему будет подсказывать нейросеть. Самый простой способ "втереться в доверие" к врачу - выделять патологичные области, чтобы было видно, куда обратила внимание нейросеть.
2. Поиск похожих. В случае, если врач не знает как ему поступить, он обычно достает книжку и начинает в ней искать похожие случаи заболеваний. Если мы вдруг обладаем большой базой данных медицинских снимков, мы можем, помимо заключения, подсовывать ему примеры похожих случае и, если врач, действительно согласится, что случаи схожи, то это будет отличный повод довериться заключению нейросети, так как это поведение интуитивно похоже на его собственное. Первые подобные идеи были рассмотрены в старенькой статье про XProtoNet.
3. Человекочитаемый текст. Огромное пространство для интерпретации дает текст. Если мы, помимо отображения сухих находох научимся писать и обычный человекочитаемый текст заключения, который будет описывать где и какие признаки обнаружены, то это еще один из шагов на встречу к интерпретации поведения нейросети.
3.1 Chain of thought популярная нынче тема: когда текстовая модель пишет не только ответ, но и описывает те шаги, которые привели к такому заключению. Развите этой теории легли в основу реализации модели o1 от OpenAI, что также является новым шагом в понимании обывателем нейросетей.
Остановимся на этих методах, в будущем разовьем эту тему и обсудим других подходы, это получился скорее обзорный пост на тему интерпретации.
Пишите в комментариях о чем хотелось бы почитать еще, может конкретно из медицины. Если пока вы стесняетесь писать комментарии - просьба забросать меня огонечками! Если вы посоветуете этот канал своим знакомым, также буду сильно признателен!
P.S. Мне сказали, что сгенеренные картинки это кринж, поэтому сегодня будет мое фото стола с едой.
#технологии #эйай
@lechim_ai
1. От глобального к локальному. Переход от задачи классификации по изображению к задачам детекции, сегментации или на худой конец определения heatmap.
Конечная задача для врача, при просмотре мед. снимка сделать заключение, отталкиваясь от находок на изображении. Поэтому врач решает скорее задачу классификации. Это снимок с туберкулезом, на этом снимке есть гидроторакс и тд. При этом он не готов брать на веру, если в таком же ключе ему будет подсказывать нейросеть. Самый простой способ "втереться в доверие" к врачу - выделять патологичные области, чтобы было видно, куда обратила внимание нейросеть.
2. Поиск похожих. В случае, если врач не знает как ему поступить, он обычно достает книжку и начинает в ней искать похожие случаи заболеваний. Если мы вдруг обладаем большой базой данных медицинских снимков, мы можем, помимо заключения, подсовывать ему примеры похожих случае и, если врач, действительно согласится, что случаи схожи, то это будет отличный повод довериться заключению нейросети, так как это поведение интуитивно похоже на его собственное. Первые подобные идеи были рассмотрены в старенькой статье про XProtoNet.
3. Человекочитаемый текст. Огромное пространство для интерпретации дает текст. Если мы, помимо отображения сухих находох научимся писать и обычный человекочитаемый текст заключения, который будет описывать где и какие признаки обнаружены, то это еще один из шагов на встречу к интерпретации поведения нейросети.
3.1 Chain of thought популярная нынче тема: когда текстовая модель пишет не только ответ, но и описывает те шаги, которые привели к такому заключению. Развите этой теории легли в основу реализации модели o1 от OpenAI, что также является новым шагом в понимании обывателем нейросетей.
Остановимся на этих методах, в будущем разовьем эту тему и обсудим других подходы, это получился скорее обзорный пост на тему интерпретации.
Пишите в комментариях о чем хотелось бы почитать еще, может конкретно из медицины. Если пока вы стесняетесь писать комментарии - просьба забросать меня огонечками! Если вы посоветуете этот канал своим знакомым, также буду сильно признателен!
P.S. Мне сказали, что сгенеренные картинки это кринж, поэтому сегодня будет мое фото стола с едой.
#технологии #эйай
@lechim_ai
🔥10😁2👍1
Зоны роста в компании
Существует две диаметрально противоположные проблемы: растить некого и растить некуда. Первая проблема не является темой сегодняшего поста, скажу лишь, что она является следствием череды ошибок руководителя отдела, таких как, например, невыстроенный найм и, в целом, плохой people management.
Вторая проблема кажется куда менее страшной, но на деле ведет к серьезным последствиям. В этом посте поговорим о последствиях и попробуем взглянуть на понятие рост под немного иным углом, нежели базовое вертикальное движение.
Еще раз, в чем сама суть проблемы: в компании на первый взгляд отсутствуют свободные позиции, при этом в команде есть один или несколько человек, которые по косвенным признакам, а может быть даже проговоренно, готовы к новым зонам ответсвенности.
Начнем с того, к чему может привести игнорирование данной ситуации. Растущая команда это благо, возможно самое ценное, что может дать хороший руководитель для своей компании. В первую очередь это легко выражается в деньгах. Внутренний рост сильно дешевле найма крутых специалистов со стороны. Рост - это часто, особенно в молодом возрасте, ключевой мотиватор оставаться в компании и связывать свои ценнейшие годы с ней. Пропускать мимо ушей, глаз и прочих органов чувств запрос на рост - отказываться от этих благ и увеличивать тякучку кадров. Помимо этого "игнорирование" часто может являться симптомом более серьезной установки руководителя "раньше же работало" или "работает - не трогай". Расти должны не только люди, но и отдел, и нежелание искать новые точки роста для людей, перерастает в стагнацию отдела, что в бизнесе является худшей "стадией развития".
Личная история: где-то года два назад я пришел к коучу именно с этой проблемой, но не со стороны руководителя. Мне казалось, что внутренних вакансий в компании нет, перспектива их появлений туманна, а значит и мой "рост" (а на тот момент рост для меня был равен вертикальному росту) остановился и пора искать новое место работы. На том приеме мы обсудили разные аспекты моей карьеры, но уже в том диалоге, у меня удалось в голове развести понятия роста и вертикального движения.
Примеры того, что еще, помимо движения по иерархии, может предложить руководитель:
1. Стажеры. В компаниях часто не доводят до конца идею найма стажеров, потому что этим некому заниматься. Но стоят они не дорого и почти всегда это история с положительным концом. Для компании это минимальные затраты, а для специалиста большая точка роста.
2. Внутренняя инфраструктура. Никто не любит внедрять новые технологии для разработки. Если будет ответственный человек за развитие внутренней инфраструктуры - это сильно пойдет на пользу всему отделу.
3. Внутренний продукт. Не всегда продукт это то, что пришло от продуктового отдела. Идеи клевых технологических решений могут приходить изнутри, а значит и у них должен быть какой-то ответственный человек.
4. HR бренд. Ведение tg-канала, написание статей на habr, проведение НИР, выступление на конференциях и многое другое, все то, на что часто совсем не хватает времени, пока этим не занимается кто-то целенаправленно.
5. Написание научных статей. В целом это составляющая HR бренда, но захотелось выделить это в самостоятельный пункт, так как это является неотъемлимой частью сферы эйай.
6. Сплочение отдела. Проведение внутренних meetup и внерабочая деятельность отдела. Любое такое событие кто-то должен организовать и пропушить.
7. Включение в процессы найма. Особенно, если этапов собеседований несколько. Пытаться оценить знания стороннего человека - это большой и сложный навык, который, в частности, ставит на место и собственные знания.
Это лишь часть возможных зон ответственности, но надеюсь, я помог этими примерами взглянуть на эту ситуацию шире. Как обычно жду ваших комментариев, огонечков и приведенных в канал знакомых!
#peoplemanagement
@lechim_ai
Существует две диаметрально противоположные проблемы: растить некого и растить некуда. Первая проблема не является темой сегодняшего поста, скажу лишь, что она является следствием череды ошибок руководителя отдела, таких как, например, невыстроенный найм и, в целом, плохой people management.
Вторая проблема кажется куда менее страшной, но на деле ведет к серьезным последствиям. В этом посте поговорим о последствиях и попробуем взглянуть на понятие рост под немного иным углом, нежели базовое вертикальное движение.
Еще раз, в чем сама суть проблемы: в компании на первый взгляд отсутствуют свободные позиции, при этом в команде есть один или несколько человек, которые по косвенным признакам, а может быть даже проговоренно, готовы к новым зонам ответсвенности.
Начнем с того, к чему может привести игнорирование данной ситуации. Растущая команда это благо, возможно самое ценное, что может дать хороший руководитель для своей компании. В первую очередь это легко выражается в деньгах. Внутренний рост сильно дешевле найма крутых специалистов со стороны. Рост - это часто, особенно в молодом возрасте, ключевой мотиватор оставаться в компании и связывать свои ценнейшие годы с ней. Пропускать мимо ушей, глаз и прочих органов чувств запрос на рост - отказываться от этих благ и увеличивать тякучку кадров. Помимо этого "игнорирование" часто может являться симптомом более серьезной установки руководителя "раньше же работало" или "работает - не трогай". Расти должны не только люди, но и отдел, и нежелание искать новые точки роста для людей, перерастает в стагнацию отдела, что в бизнесе является худшей "стадией развития".
Личная история: где-то года два назад я пришел к коучу именно с этой проблемой, но не со стороны руководителя. Мне казалось, что внутренних вакансий в компании нет, перспектива их появлений туманна, а значит и мой "рост" (а на тот момент рост для меня был равен вертикальному росту) остановился и пора искать новое место работы. На том приеме мы обсудили разные аспекты моей карьеры, но уже в том диалоге, у меня удалось в голове развести понятия роста и вертикального движения.
Примеры того, что еще, помимо движения по иерархии, может предложить руководитель:
1. Стажеры. В компаниях часто не доводят до конца идею найма стажеров, потому что этим некому заниматься. Но стоят они не дорого и почти всегда это история с положительным концом. Для компании это минимальные затраты, а для специалиста большая точка роста.
2. Внутренняя инфраструктура. Никто не любит внедрять новые технологии для разработки. Если будет ответственный человек за развитие внутренней инфраструктуры - это сильно пойдет на пользу всему отделу.
3. Внутренний продукт. Не всегда продукт это то, что пришло от продуктового отдела. Идеи клевых технологических решений могут приходить изнутри, а значит и у них должен быть какой-то ответственный человек.
4. HR бренд. Ведение tg-канала, написание статей на habr, проведение НИР, выступление на конференциях и многое другое, все то, на что часто совсем не хватает времени, пока этим не занимается кто-то целенаправленно.
5. Написание научных статей. В целом это составляющая HR бренда, но захотелось выделить это в самостоятельный пункт, так как это является неотъемлимой частью сферы эйай.
6. Сплочение отдела. Проведение внутренних meetup и внерабочая деятельность отдела. Любое такое событие кто-то должен организовать и пропушить.
7. Включение в процессы найма. Особенно, если этапов собеседований несколько. Пытаться оценить знания стороннего человека - это большой и сложный навык, который, в частности, ставит на место и собственные знания.
Это лишь часть возможных зон ответственности, но надеюсь, я помог этими примерами взглянуть на эту ситуацию шире. Как обычно жду ваших комментариев, огонечков и приведенных в канал знакомых!
#peoplemanagement
@lechim_ai
👍11🔥9👌2
Качество модели
Недавно я принимал участие в Сеченовском хакатоне в качестве эксперта, сидел на предзащите у команд и давал свои комментарии, делал замечания и пытался направить их идеи в нужном направлении.
Я встречал множество схожих фраз, которые натолкнули меня на написание этого поста, вот некоторые их них:
Оценка качества модели - это тот случай, когда ты можешь сделать 100 измерений и все еще не быть уверенным в том, как твоя модель работает. В этом посте попробую отметить те моменты, о которых стоит подумать, прежде чем называть какие-либо цифры.
1. Бизнес цели. Любая задача начинается с постановки цели. Если мы говорим про бизнес, то ваша модель должна решать определенные задачи, создавая тем самым денежный поток. Нужно очертить границы того качества, которое будет являться необходимым для получения профита от участия машинного обучения и при этом также важно понимать границы, когда уже можно остановиться поднимать качество, ведь каждый новый процент обычно стоит все дороже.
Пример:
Когда я работал в СБЕРе моя модель таргетирования рекламных рассылок имела ROC-AUC около 0.6 (чуть лучше подброса монетки), что в итоге приносило компании несколько десятков миллионов в месяц. ROC-AUC 0.6 является ужасной метрикой, но в этой задаче даже такие показатели были выше необхоимого и давали профит бизнесу.
2. Тестирование. Не хочется говорить о train, val, test, потому что это достаточно примитивная схема. Поговорим в целом о тестировании, какие вопросы стоит держать в голове.
Переносимость. Модель может работать по-разному на разных доменах, поэтому стоит изучать std на бутстрапе, стоит иметь несколько тестовых датасетов, собранных из разных источников и иметь хотя бы один такой источник, который не присутствовал в обучающей выборке.
Сложность и уверенность. Тестовый датасет нужно собирать вручную, добавляя туда сложные случаи, которые могут вызывать затруднения у модели. Также много времени необходимо посвятить тому, чтобы удостовериться в качестве разметки этого датасета. И безусловно убедиться в отсутвии утечек в обучающий сет.
Распределение классов. Момент, вызывающий споры, я себе на него отвечаю так. Чтобы понять работает ли твоя модель в вакууме - делим тест 50 на 50, чтобы понять как она будет вести себя в продакшене - делим в соответствии с распределением на реальных данных. Опять же, для ответа на оба вопроса даже на одном датасете можно позаниматься бутстрапированием.
Метатестирование. Если задача подразумевает то, что ответ модели - это не сам продукт, а только его составляющая, которая будет далее преобразована какой-то бизнес логикой во что-то человекочитаемое - стоит проверить качество работы именно финального результата. Качество обнаружения признаков рака молочной железы, не всегда напрямую говорит верно ли будет итогово выставлен BI-RADS, например. Более того, такой подход будет лучше интерпретироваться, чем просто некая точность в вакууме.
3. Выбор метрики. Для каждой бизнес задачи требуется грамотно выбирать свои метрики. Не буду здесь писать о несбалансированных классах и прочих знаниях junior специалистов, просто в очередной раз напоминаю, что стоит потратить определенное время, чтобы, в идеале, иметь еще и интерпертируемую метрику. Недавно, кстати, нашел очевидную метрику, но до этого я ей не пользовался p4.
4. Сравнение. Тут все просто. Сравнение называется честным только в том случае, если все параметры эксперимента одинаковы. Скорость - на одинаковом железе и схожем качестве работы моделей, при сравнении качества - идентичные данные. Это верно как при сравнения со своими предыдущими наработками, так и при сравнении со сторонними разработчиками.
Мои посты получаются большими, и мне кажется, что это может отталкивать читателей. Что вы думаете про размер постов, стоит ли попробовать как-то поменять формат? Пишите комментарии и конечно же жду ваших реакций и репостов!
#технологии #эйай
@lechim_ai
Недавно я принимал участие в Сеченовском хакатоне в качестве эксперта, сидел на предзащите у команд и давал свои комментарии, делал замечания и пытался направить их идеи в нужном направлении.
Я встречал множество схожих фраз, которые натолкнули меня на написание этого поста, вот некоторые их них:
"У модели точность 88, хотим, чтобы было 95, сейчас доучиваем".
"У конкурентов точность 90, наше конкурентная преимущество, что у нас 92".
Оценка качества модели - это тот случай, когда ты можешь сделать 100 измерений и все еще не быть уверенным в том, как твоя модель работает. В этом посте попробую отметить те моменты, о которых стоит подумать, прежде чем называть какие-либо цифры.
1. Бизнес цели. Любая задача начинается с постановки цели. Если мы говорим про бизнес, то ваша модель должна решать определенные задачи, создавая тем самым денежный поток. Нужно очертить границы того качества, которое будет являться необходимым для получения профита от участия машинного обучения и при этом также важно понимать границы, когда уже можно остановиться поднимать качество, ведь каждый новый процент обычно стоит все дороже.
Пример:
Когда я работал в СБЕРе моя модель таргетирования рекламных рассылок имела ROC-AUC около 0.6 (чуть лучше подброса монетки), что в итоге приносило компании несколько десятков миллионов в месяц. ROC-AUC 0.6 является ужасной метрикой, но в этой задаче даже такие показатели были выше необхоимого и давали профит бизнесу.
2. Тестирование. Не хочется говорить о train, val, test, потому что это достаточно примитивная схема. Поговорим в целом о тестировании, какие вопросы стоит держать в голове.
Переносимость. Модель может работать по-разному на разных доменах, поэтому стоит изучать std на бутстрапе, стоит иметь несколько тестовых датасетов, собранных из разных источников и иметь хотя бы один такой источник, который не присутствовал в обучающей выборке.
Сложность и уверенность. Тестовый датасет нужно собирать вручную, добавляя туда сложные случаи, которые могут вызывать затруднения у модели. Также много времени необходимо посвятить тому, чтобы удостовериться в качестве разметки этого датасета. И безусловно убедиться в отсутвии утечек в обучающий сет.
Распределение классов. Момент, вызывающий споры, я себе на него отвечаю так. Чтобы понять работает ли твоя модель в вакууме - делим тест 50 на 50, чтобы понять как она будет вести себя в продакшене - делим в соответствии с распределением на реальных данных. Опять же, для ответа на оба вопроса даже на одном датасете можно позаниматься бутстрапированием.
Метатестирование. Если задача подразумевает то, что ответ модели - это не сам продукт, а только его составляющая, которая будет далее преобразована какой-то бизнес логикой во что-то человекочитаемое - стоит проверить качество работы именно финального результата. Качество обнаружения признаков рака молочной железы, не всегда напрямую говорит верно ли будет итогово выставлен BI-RADS, например. Более того, такой подход будет лучше интерпретироваться, чем просто некая точность в вакууме.
3. Выбор метрики. Для каждой бизнес задачи требуется грамотно выбирать свои метрики. Не буду здесь писать о несбалансированных классах и прочих знаниях junior специалистов, просто в очередной раз напоминаю, что стоит потратить определенное время, чтобы, в идеале, иметь еще и интерпертируемую метрику. Недавно, кстати, нашел очевидную метрику, но до этого я ей не пользовался p4.
4. Сравнение. Тут все просто. Сравнение называется честным только в том случае, если все параметры эксперимента одинаковы. Скорость - на одинаковом железе и схожем качестве работы моделей, при сравнении качества - идентичные данные. Это верно как при сравнения со своими предыдущими наработками, так и при сравнении со сторонними разработчиками.
Мои посты получаются большими, и мне кажется, что это может отталкивать читателей. Что вы думаете про размер постов, стоит ли попробовать как-то поменять формат? Пишите комментарии и конечно же жду ваших реакций и репостов!
#технологии #эйай
@lechim_ai
❤🔥7🔥3❤1
Разметка. Часть 1.
Здорово, если в вашей компании процессы построены так, что ML отдел получает хорошие данные для обучения, не задумываясь о том, кем они и как размечены. Вопросы начинают появляться в тот момент, когда модели перестают учиться и пристальный взгляд на разметку выявляет ее изъяны.
Выстраивание разметки в медицине, пожалуй, один из самых трудозатратных процессов. Сегодня хотелось бы собрать воедино наши подходы, которые могли бы помочь в этом сложном пути. Этот пост будет посвящен самому процессу разметки, в дальнейшем планирую пост про ML подходы работы с шумной разметкой.
Ниже будут представлены подходы, направленные на повышение качества разметки, от очевидных до более изящных. Большинство из них могут работать в любой предметной области, но я буду говорить об этом со стороны медицины. Отдельно хотелось бы заметить, что я считаю процесс правильно выстроенным, если в нем можно посчитать какие-то цифры, поэтому я периодически буду описывать то, что можно посчитать.
1. Кросс разметка. Одна голова - хорошо, а две - зависит от вашего подхода. Безусловно, 3 плохих разметчика ничуть не лучше, чем 1 плохой, но в среднем метод очень сильный, открывающий еще и многообразие ML подходов работы с такой разметкой.
Что посчитать: построение метрик согласованности. Мы в компании сошлись в следующей мысли: если врачи согласовались, значит это истина. Это почти верно, в случае, если ты еще и независимо следишь за компетентностью приглашенных врачей.
2. Кросс проверка. Этот подход работает лишь в том случае, если вы обладаете "экспертами" зарекомендовавшими себя долгой и классной работой. Исследование размечается, при не прохождении проверки - возвращается назад с комментариями.
Что посчитать: как часто исследования возвращаются на доразметку, с какого раза они итогово принимаются. Задачу понять, какие выводы можно сделать из этих цифр оставлю на читателе.
3. Инструкция для разметки. Залог хорошего результата - грамотная инструкция. Во-первых, хорошая разметка не равно объективная реальность. Хорошая разметка равно соответствие инструкции, поэтому прежде чем требовать качество, нужно четко понять, чего хочется, и это изложить. Скажу крамольную мысль: в инструкции никто не вчитывается, если даже открывает. В связи с чем, необходимо донести все тонкости методички в другом формате: через общий созвон с разметчиками или же видео-инструктаж.
4. Обратная связь. Сделайте этот процесс регулярным. Качество разметки падает в тот момент, когда разметчики понимают, что за ними не следят. Нужно наблюдение на потоке за каждым, собирать папочку с ошибками и выходить периодически на 1-2-1 с объяснением косяков. Для этого процесса требуется эксперт, который сможет кластеризовать ошибки, чтобы исключать их системно.
Что посчитать: скорость наполнения папки с ошибками и частоту даваемой ОС.
5. Дифференцируемая оплата за размеченные исследования, а не часы работы. Размечаешь лучше - получаешь больше, хуже - меньше или ноль. Пример: сразу разметил верно получил 100 рублей, после 1 этапа валидации 50, после 2 этапов валидации 0 рублей. Важно построить грамотную финансовую модель, учтя затраченное время экспертов-валидаторов и необходимые темпы разметки.
Что посчитать: отношение фактически заработанного к потенциальному заработку специалистов.
Продолжение далее ⬇️
@lechim_ai
Здорово, если в вашей компании процессы построены так, что ML отдел получает хорошие данные для обучения, не задумываясь о том, кем они и как размечены. Вопросы начинают появляться в тот момент, когда модели перестают учиться и пристальный взгляд на разметку выявляет ее изъяны.
Выстраивание разметки в медицине, пожалуй, один из самых трудозатратных процессов. Сегодня хотелось бы собрать воедино наши подходы, которые могли бы помочь в этом сложном пути. Этот пост будет посвящен самому процессу разметки, в дальнейшем планирую пост про ML подходы работы с шумной разметкой.
Ниже будут представлены подходы, направленные на повышение качества разметки, от очевидных до более изящных. Большинство из них могут работать в любой предметной области, но я буду говорить об этом со стороны медицины. Отдельно хотелось бы заметить, что я считаю процесс правильно выстроенным, если в нем можно посчитать какие-то цифры, поэтому я периодически буду описывать то, что можно посчитать.
1. Кросс разметка. Одна голова - хорошо, а две - зависит от вашего подхода. Безусловно, 3 плохих разметчика ничуть не лучше, чем 1 плохой, но в среднем метод очень сильный, открывающий еще и многообразие ML подходов работы с такой разметкой.
Что посчитать: построение метрик согласованности. Мы в компании сошлись в следующей мысли: если врачи согласовались, значит это истина. Это почти верно, в случае, если ты еще и независимо следишь за компетентностью приглашенных врачей.
2. Кросс проверка. Этот подход работает лишь в том случае, если вы обладаете "экспертами" зарекомендовавшими себя долгой и классной работой. Исследование размечается, при не прохождении проверки - возвращается назад с комментариями.
Что посчитать: как часто исследования возвращаются на доразметку, с какого раза они итогово принимаются. Задачу понять, какие выводы можно сделать из этих цифр оставлю на читателе.
3. Инструкция для разметки. Залог хорошего результата - грамотная инструкция. Во-первых, хорошая разметка не равно объективная реальность. Хорошая разметка равно соответствие инструкции, поэтому прежде чем требовать качество, нужно четко понять, чего хочется, и это изложить. Скажу крамольную мысль: в инструкции никто не вчитывается, если даже открывает. В связи с чем, необходимо донести все тонкости методички в другом формате: через общий созвон с разметчиками или же видео-инструктаж.
4. Обратная связь. Сделайте этот процесс регулярным. Качество разметки падает в тот момент, когда разметчики понимают, что за ними не следят. Нужно наблюдение на потоке за каждым, собирать папочку с ошибками и выходить периодически на 1-2-1 с объяснением косяков. Для этого процесса требуется эксперт, который сможет кластеризовать ошибки, чтобы исключать их системно.
Что посчитать: скорость наполнения папки с ошибками и частоту даваемой ОС.
5. Дифференцируемая оплата за размеченные исследования, а не часы работы. Размечаешь лучше - получаешь больше, хуже - меньше или ноль. Пример: сразу разметил верно получил 100 рублей, после 1 этапа валидации 50, после 2 этапов валидации 0 рублей. Важно построить грамотную финансовую модель, учтя затраченное время экспертов-валидаторов и необходимые темпы разметки.
Что посчитать: отношение фактически заработанного к потенциальному заработку специалистов.
Продолжение далее ⬇️
@lechim_ai
👍4❤🔥1🔥1
Разметка. Часть 2.
6. Автотесты. Большое количество ошибок являются не клиническими, а техническими. Отмечен тег норма, при этом размечен патологический полигон. На исследовании нет вообще никакой разметки - это значит, что ничего не найдено или случайно было пропущено? Прежде чем разметка попадет в ML отдел должны быть пройдены автоматические тесты, чтобы исключить возможность технических ошибок.
Что посчитать: долю исследований не прошедших автотесты.
7. Чаты разметчиков. Таких чатов бывает два вида: канал и чат, более того, нужно мотивировать людей пользоваться этими инструментами. Чат - место для обсуждения сложных кейсов. Канал - общее место сбора, где эксперт-валидатор выкладывает частые общие ошибки, дает пояснения и важные объявления.
8. Ротация, найм. Тут все как в спорте - нужна конкуренция. Необходимо постоянно нанимать новых специалистов, вести рейтинг имеющихся, отказываться от отстающих. Финансовой нагрузки от этого нет никакой, так как не важно 100 человек разметили по 1 исследованию или же 1 разметил 100, при этом повышается возможность выбора более сильных разметчиков.
Что посчитать: построить рейтинг специалистов, оценивая все вышесказанные метрики, плюс скорость разметки и любые другие показатели.
9. Инструменты разметки. Не стоит фиксироваться на выбранном когда-то инструменте, стоит осознавать какие в нем есть проблемы и дорабатывать (в случае опенсорса) или менять.
Что посчитать: количество технических ошибок и скорость разметки в зависимости от инструмента.
10. Honeypot. Для автоматической оценки качества разметки можно добавить часть уже ранее размеченных исследований (важно, чтобы качество их разметки не вызывало сомнений), еще лучше, если сам врач их до этого уже когда-то размечал.
Что посчитать: метрики относительно эталонной разметки и, если возможно, согласованности относительно себя же из прошлого.
11. Новые методы разметки. Не буду описывать все многообразие возможных подходов, скажу лишь только, что можно разбивать на этапы, использовать опенсорс или внутренние модели для предразметки и тд.
Хорошая разметка данных это 90% успеха совеременного эйай. Я описал далеко не все возможные подходы, но это тот примерно тот набор, с которым сегодня мы стараемся строить систему, при которой ML специалисты перестанут переживать за качество своих данных и углубятся в обучение моделей и research.
Это точно не последний пост на эту тему, так как она неимоверно горяча. Задавайте вопросы, ставьте реакции и пересылайте своим друзьям, которые пока еще не поняли, что делать с 50% ошибок в разметке.
#разметка #процессы
@lechim_ai
6. Автотесты. Большое количество ошибок являются не клиническими, а техническими. Отмечен тег норма, при этом размечен патологический полигон. На исследовании нет вообще никакой разметки - это значит, что ничего не найдено или случайно было пропущено? Прежде чем разметка попадет в ML отдел должны быть пройдены автоматические тесты, чтобы исключить возможность технических ошибок.
Что посчитать: долю исследований не прошедших автотесты.
7. Чаты разметчиков. Таких чатов бывает два вида: канал и чат, более того, нужно мотивировать людей пользоваться этими инструментами. Чат - место для обсуждения сложных кейсов. Канал - общее место сбора, где эксперт-валидатор выкладывает частые общие ошибки, дает пояснения и важные объявления.
8. Ротация, найм. Тут все как в спорте - нужна конкуренция. Необходимо постоянно нанимать новых специалистов, вести рейтинг имеющихся, отказываться от отстающих. Финансовой нагрузки от этого нет никакой, так как не важно 100 человек разметили по 1 исследованию или же 1 разметил 100, при этом повышается возможность выбора более сильных разметчиков.
Что посчитать: построить рейтинг специалистов, оценивая все вышесказанные метрики, плюс скорость разметки и любые другие показатели.
9. Инструменты разметки. Не стоит фиксироваться на выбранном когда-то инструменте, стоит осознавать какие в нем есть проблемы и дорабатывать (в случае опенсорса) или менять.
Что посчитать: количество технических ошибок и скорость разметки в зависимости от инструмента.
10. Honeypot. Для автоматической оценки качества разметки можно добавить часть уже ранее размеченных исследований (важно, чтобы качество их разметки не вызывало сомнений), еще лучше, если сам врач их до этого уже когда-то размечал.
Что посчитать: метрики относительно эталонной разметки и, если возможно, согласованности относительно себя же из прошлого.
11. Новые методы разметки. Не буду описывать все многообразие возможных подходов, скажу лишь только, что можно разбивать на этапы, использовать опенсорс или внутренние модели для предразметки и тд.
Хорошая разметка данных это 90% успеха совеременного эйай. Я описал далеко не все возможные подходы, но это тот примерно тот набор, с которым сегодня мы стараемся строить систему, при которой ML специалисты перестанут переживать за качество своих данных и углубятся в обучение моделей и research.
Это точно не последний пост на эту тему, так как она неимоверно горяча. Задавайте вопросы, ставьте реакции и пересылайте своим друзьям, которые пока еще не поняли, что делать с 50% ошибок в разметке.
#разметка #процессы
@lechim_ai
🔥10❤🔥1
Я - Head of AI. Часть 1.
Так как это канал автора, то помимо интересующих его тем, логично будет освящать важные вехи его карьеры.
Около полутора месяцев назад мне было предложено занять позицию Head of AI в компании Третье Мнение. Я много задавал себе вопросов "готов ли я", "справлюсь ли я", но по жизни я достаточно самоуверен, чтобы отказаться. Первые пару недель было страшно, но как и любую большую задачу в своей жизни, я постарался ее максимально декомпозировать, разложить всю должность на составные обязанности, нарисовал огромный mind-map и после этого стало легче. В свое время Евгений Никитин перекладывал подобный mind-map должности CTO в текст и выкладывал пост у себя в канале, в одном из будущих постов попробую сделать что-то подобное с моим видением Head of AI.
В этом посте мы не будем затрагивать никакие аспекты работы, а я просто расскажу тот путь, который был мной пройден на сегодняшний день, чтобы оказаться там, где я есть. Не факт, что это кому-то будет полезно, но так вы узнаете чуть больше обо мне, а я еще раз окину взглядом свою жизнь.
1. До 6 класса мы жили в Балашихе, я хорошо знал математику, та и в целом хорошо учился, играл в хоккей и частенько влюблялся (взаимности не было, как вы понимаете).
2. 6 класс. Мы переехали в Москву, я поступил в гимназию недалеко от дома, во всей школе училось около 120 человек, школа была одновременно частная и государственная. Поэтому вместе рядом учились ооочень богатые люди и просто люди. Именно тогда я написал свою первую программу на Python: текстовая бродилка с вампирами. В конце года я пошел в школу программирования на Шаболовской и моим первым языком стал С++. Отучился я там полгода или год, кажется.
3. 7 класс. Поступив в несколько хороших школ, спасибо маме, я принял для себя решение пойти в Лицей Информационных Технологий 1533. Место легендарное, которому я всем обязан, но это тема для большой личной беседы. В сухом остатке: каждый год обучения у меня было много программирования.
4. 7 - 11 класс, ЛИТ. Я изучал C#, PascalABC, немножко даже Java. В какой-то момент один из наших преподавателей, а в дальнейшем мой хороших друг, предложил мне поработать с ним и я активно развивался как web разработчик, учил PHP, HTML и JS. В 10 классе делал большой проект для работы с контекстной рекламой, впервые познакомился с работой по API, писал большой и сложный бэкенд, тогда сильно прокачался в SQL. Лицей был наполнен программированием и я вбирал его в себя. Учился все также хорошо, что помогло мне далее.
5. В 9 классе я поступил в МШП (в простанародии Малый ШАД) сразу на второй год обучения, потому что уже хорошо знал азы программирования и благополучно отходил туда 2 года. Там было очень много информации: сети, С++, web, алгоритмы, еще алгоритмы и бесплатная еда.
6. ВМК. Логичным продолжением моей учебы в лицее стало поступление на ВМК. Я хорошо сдал ЕГЭ и стал наслаждаться беспрерывным течением Москвы-реки. Тут, конечно, было много всего: очень много математики и много очень разного, не всегда полезного, программирования. Сначала бакалавриат, потом магистратура, все как завещал Ленин. На более поздних курсах появился базовый ML, крутой курс по CV, но в первую очередь спасибо безумным теоремам и стрессовым экзаменам.
7. Первые шаги в ML я делал как и все: конечно же Coursera с невероятным курсом от МФТИ. Думаю, что этому курсу обязана вся российская ML индустрия. Еще что-то почитывал, разные курсы на Stepik, смотрел курс deeplearning от Andrew Ng, в общем самообразовывался.
Сложно уложить всю жизнь в один пост, а значит завтра ждите продолжение, там уже перейдем непосредственно к карьере. Напишите в комментариях о чем вам хотелось бы почитать, мне это было бы очень полезно!
#карьера
@lechim_ai
Так как это канал автора, то помимо интересующих его тем, логично будет освящать важные вехи его карьеры.
Около полутора месяцев назад мне было предложено занять позицию Head of AI в компании Третье Мнение. Я много задавал себе вопросов "готов ли я", "справлюсь ли я", но по жизни я достаточно самоуверен, чтобы отказаться. Первые пару недель было страшно, но как и любую большую задачу в своей жизни, я постарался ее максимально декомпозировать, разложить всю должность на составные обязанности, нарисовал огромный mind-map и после этого стало легче. В свое время Евгений Никитин перекладывал подобный mind-map должности CTO в текст и выкладывал пост у себя в канале, в одном из будущих постов попробую сделать что-то подобное с моим видением Head of AI.
В этом посте мы не будем затрагивать никакие аспекты работы, а я просто расскажу тот путь, который был мной пройден на сегодняшний день, чтобы оказаться там, где я есть. Не факт, что это кому-то будет полезно, но так вы узнаете чуть больше обо мне, а я еще раз окину взглядом свою жизнь.
1. До 6 класса мы жили в Балашихе, я хорошо знал математику, та и в целом хорошо учился, играл в хоккей и частенько влюблялся (взаимности не было, как вы понимаете).
2. 6 класс. Мы переехали в Москву, я поступил в гимназию недалеко от дома, во всей школе училось около 120 человек, школа была одновременно частная и государственная. Поэтому вместе рядом учились ооочень богатые люди и просто люди. Именно тогда я написал свою первую программу на Python: текстовая бродилка с вампирами. В конце года я пошел в школу программирования на Шаболовской и моим первым языком стал С++. Отучился я там полгода или год, кажется.
3. 7 класс. Поступив в несколько хороших школ, спасибо маме, я принял для себя решение пойти в Лицей Информационных Технологий 1533. Место легендарное, которому я всем обязан, но это тема для большой личной беседы. В сухом остатке: каждый год обучения у меня было много программирования.
4. 7 - 11 класс, ЛИТ. Я изучал C#, PascalABC, немножко даже Java. В какой-то момент один из наших преподавателей, а в дальнейшем мой хороших друг, предложил мне поработать с ним и я активно развивался как web разработчик, учил PHP, HTML и JS. В 10 классе делал большой проект для работы с контекстной рекламой, впервые познакомился с работой по API, писал большой и сложный бэкенд, тогда сильно прокачался в SQL. Лицей был наполнен программированием и я вбирал его в себя. Учился все также хорошо, что помогло мне далее.
5. В 9 классе я поступил в МШП (в простанародии Малый ШАД) сразу на второй год обучения, потому что уже хорошо знал азы программирования и благополучно отходил туда 2 года. Там было очень много информации: сети, С++, web, алгоритмы, еще алгоритмы и бесплатная еда.
6. ВМК. Логичным продолжением моей учебы в лицее стало поступление на ВМК. Я хорошо сдал ЕГЭ и стал наслаждаться беспрерывным течением Москвы-реки. Тут, конечно, было много всего: очень много математики и много очень разного, не всегда полезного, программирования. Сначала бакалавриат, потом магистратура, все как завещал Ленин. На более поздних курсах появился базовый ML, крутой курс по CV, но в первую очередь спасибо безумным теоремам и стрессовым экзаменам.
7. Первые шаги в ML я делал как и все: конечно же Coursera с невероятным курсом от МФТИ. Думаю, что этому курсу обязана вся российская ML индустрия. Еще что-то почитывал, разные курсы на Stepik, смотрел курс deeplearning от Andrew Ng, в общем самообразовывался.
Сложно уложить всю жизнь в один пост, а значит завтра ждите продолжение, там уже перейдем непосредственно к карьере. Напишите в комментариях о чем вам хотелось бы почитать, мне это было бы очень полезно!
#карьера
@lechim_ai
🔥17❤5❤🔥3
Я - Head of AI. Часть 2.
8. Декабрь 2020. Начало 3 курса, во всю последствия COVID-а, а значит в университете удаленка. Тогда я вышел на рынок труда, пару провальных собеседований и я в лучшей кузнице кадров России: в Glowbyte Consulting. Меня отдают в один известный банк и следующие 9 месяцев я буду знакомиться с работой в найме и укреплять понимание, что пора валить из этого зеленого гиганта. Я гонял бустинги, чтобы таргетировать тех, на кого лучше разослать рекламу. И тогда я начал интересоваться компьютерным зрением.
9. Июль 2021. Мне поступает предложение попробовать свои силы в CV в медицине, а так как мой бакалаврский диплом был уже чистым CV, я решил, что хватит гонять CatBoost, пора заняться делом. Я усиленно читаю статьи, пытаюсь хоть немного разобраться в области и со скрипом попадаю на позицию Junior CV-инженер в компанию Третье Мнение. На проекте я был единственный специалист и уже где-то через полгода я стал автономной боевой единицей, которая работает в связке с прОдуктом, а не с лидом. Благодаря этому произошел быстрый рост меня как специалиста, потому что появилась необходимость принимать решения самостоятельно на ранних этапах карьеры.
10. Май 2022. У меня появляется первый стажер. Ярко, но не долго, после стажировки она не стала продолжать карьеру у нас. Но это был мой первый опыт менторства, мне понравилось, и даже показалось, что я готов начинать руководить людьми.
11. Сентябрь 2022. У меня появляется второй продукт и даже маленькая команда из 3 человек суммарно. Все это время я активно участвую в найме во весь отдел: я отсматриваю резюме, я провожу скрининги, мы вместе с Женей разрабатываем процесс собеседований. Этот этап сильно структурировал во мне информацию, которую я спрашивал, а главное очень многое рассказал о людях и о том, как их надо нанимать.
12. Сентябрь 2023. У меня появляется команда DE, в связи с отсутствием менеджерского ресурса в компании, это новый вызов, потому что технически я разбирался только поверхностно, так как это не мой профиль. Команда постепенно дорастает до 8 человек на 3 проекта.
Промежуточные большие точки роста:
1) Самостоятельность на проекте
2) Первый стажер
3) Первая команда
4) Управление несколькими командами
5) Увеличение количества прямых подчиненных до 5+
6) Руководство в направлении, в котором я слабо разбираюсь
7) Первое увольнение (по инициативе моей)
8) Первое увольнение (по инициативе подчиненного)
9) Выстраивание с 0 процесса найма
10) Большой провал команды и последующий "кризис-менеджмент" и выправление ситуации.
11) "Вставание на рельсы" и ответы на вопрос "что дальше?"
Октябрь 2024. И вот он новый вызов, значимо серьезнее, чем все то, что было раньше. Команда из 20+ человек и большие цели. Я видел как росло Третье Мнение, а я рос вместе с ним, но до этого ему помогали расти другие люди, теперь это и моя задача тоже. Буду держать в курсе, к чему приведет это сотрудничество.
Такая вот очень не полная сводка моего карьерного пути, но с основными моментами, если есть по ней вопросы - задавайте их в комментариях! Пишите, что в вашей жизни стало тем самым переломным моментом в карьере!
#карьера
@lechim_ai
8. Декабрь 2020. Начало 3 курса, во всю последствия COVID-а, а значит в университете удаленка. Тогда я вышел на рынок труда, пару провальных собеседований и я в лучшей кузнице кадров России: в Glowbyte Consulting. Меня отдают в один известный банк и следующие 9 месяцев я буду знакомиться с работой в найме и укреплять понимание, что пора валить из этого зеленого гиганта. Я гонял бустинги, чтобы таргетировать тех, на кого лучше разослать рекламу. И тогда я начал интересоваться компьютерным зрением.
9. Июль 2021. Мне поступает предложение попробовать свои силы в CV в медицине, а так как мой бакалаврский диплом был уже чистым CV, я решил, что хватит гонять CatBoost, пора заняться делом. Я усиленно читаю статьи, пытаюсь хоть немного разобраться в области и со скрипом попадаю на позицию Junior CV-инженер в компанию Третье Мнение. На проекте я был единственный специалист и уже где-то через полгода я стал автономной боевой единицей, которая работает в связке с прОдуктом, а не с лидом. Благодаря этому произошел быстрый рост меня как специалиста, потому что появилась необходимость принимать решения самостоятельно на ранних этапах карьеры.
10. Май 2022. У меня появляется первый стажер. Ярко, но не долго, после стажировки она не стала продолжать карьеру у нас. Но это был мой первый опыт менторства, мне понравилось, и даже показалось, что я готов начинать руководить людьми.
11. Сентябрь 2022. У меня появляется второй продукт и даже маленькая команда из 3 человек суммарно. Все это время я активно участвую в найме во весь отдел: я отсматриваю резюме, я провожу скрининги, мы вместе с Женей разрабатываем процесс собеседований. Этот этап сильно структурировал во мне информацию, которую я спрашивал, а главное очень многое рассказал о людях и о том, как их надо нанимать.
12. Сентябрь 2023. У меня появляется команда DE, в связи с отсутствием менеджерского ресурса в компании, это новый вызов, потому что технически я разбирался только поверхностно, так как это не мой профиль. Команда постепенно дорастает до 8 человек на 3 проекта.
Промежуточные большие точки роста:
1) Самостоятельность на проекте
2) Первый стажер
3) Первая команда
4) Управление несколькими командами
5) Увеличение количества прямых подчиненных до 5+
6) Руководство в направлении, в котором я слабо разбираюсь
7) Первое увольнение (по инициативе моей)
8) Первое увольнение (по инициативе подчиненного)
9) Выстраивание с 0 процесса найма
10) Большой провал команды и последующий "кризис-менеджмент" и выправление ситуации.
11) "Вставание на рельсы" и ответы на вопрос "что дальше?"
Октябрь 2024. И вот он новый вызов, значимо серьезнее, чем все то, что было раньше. Команда из 20+ человек и большие цели. Я видел как росло Третье Мнение, а я рос вместе с ним, но до этого ему помогали расти другие люди, теперь это и моя задача тоже. Буду держать в курсе, к чему приведет это сотрудничество.
Такая вот очень не полная сводка моего карьерного пути, но с основными моментами, если есть по ней вопросы - задавайте их в комментариях! Пишите, что в вашей жизни стало тем самым переломным моментом в карьере!
#карьера
@lechim_ai
🔥13❤3
HR-бренд
Пожалуй, это то, о чем ты задумываешься в последнюю очередь, будучи ML-инженером. Сейчас же меня эта тема начинает привлекать все больше, кажется, что активность вокруг выстраивания HR-бренда сильно сплачивает команду, а более того может развить те аспекты сотрудников, которые слабо задействованы в рутинном потоке рабочих задач.
Понятнее - поговорим сегодня об идеях активностей в ML отделе, которые помогают улучшить имидж компании на рынке труда, среди клиентов, в целом звучать в инфополе.
1. Написание научных статей. К сожалению, тяжело заниматься написанием статей между делом. Продуктовая разработка сильно отличается от трушного ресерча, про отличие такого рода команд поговорим когда-нибудь в будущем. В бизнесе ресерч ради ресерча сложно "продать", поэтому тут есть два варианта. Первое - это выделение отдельной команды, KPI которой заточен на выпуск статей, в случае, если есть понимание для чего это нужно, второе - статья может родиться в случае решения сложной продуктовой задачи, но в таком сценарии регулярность публикаций не определена.
2. Ведение блога, технические статьи "а как у нас". Стандартный пример площадки это habr, тг-канал. Здесь необходимые усилия кратно меньше, чем в первом варианте. Идеальный вариант - рассказывать о предпоследней разработке. Если ваши идеи переиспользуют - то вы уже сделали еще один шаг, при этом эти идеи будут звучать актуально и будут высоко оценены читателями.
3. Записи meet-up. В случае, если в компании организованы какие-то встречи с обсуждениями новых технологий, доклады о best practices и тд - все это можно записывать и выкладывать на любую из возможных площадок. Если к этому добавить еще и немного монтажа с маркетингом, то можно превратить команду из млщиков в полноценных блогеров.
4. Git. Тут я бы выделил два направления. Публикация весов моделей с простеньким кодом инфренса/обучения - этот вариант мне кажется более проигрышным, в особенности небольшая компания никогда не узнает как переиспользовали их модель, и "продуктовая" модель, вероятнее всего, никому не нужна на рынке, потому что решает узкую задачу. Второй же вариант это разработка библиотек. Создание полезных для комьюнити инструментов. Open-source прекрасен тем, что он не имеет региональных границ и может повысить ваше признание за рубежом.
5. API. Более интересной идеей по шерингу моделей кажется предоставление API доступа к ней. Так можно анализировать кто и под какие задачи ее использует. Второе большое направление в контексте API - это создание бенчмарков, тестовых систем. Особенно актуально, если вы занимаетесь узкой предметной областью, то идея сделать свой ImageNet или COCO и стать законодателем моды в этой области - звучит перспективно.
6. Данные. Продолжением предыдущего поста является в целом шеринг данных. Можно не создавать тестовую систему, можно просто подготовить хорошо размеченный датасет и обозначить его тестовым набором данных. Также можно выкладывать и датасеты для обучения, внутренние или переразмеченные открытые. Но этот момент очень тонкий. Хорошо размеченные данные куда ценнее любой разработанной технологии, а потому и делиться ими нужно с умом.
7. Конференции. Выступление на конференциях. Лучше иметь несколько заранее готовых докладов и периодически обновлять свою базу.
8. Обучающие курсы. Об этом тоже, однажды, поговорим подробнее. ML отдел может поучаствовать в написании обучающего курса для университета ли, для какой-то интеренет платформы, а еще круче реализовать свой курс и выложить его на свои площадки.
9. Прочее. Организация хакатонов, конференций, активное присутствие в специализированных каналах и многое другое.
В этом посте предложил идеи, как ML отдел может работать над HR-брендом компании. Явно что-то забыл, поделитесь своими идеями в комментариях!
Нас уже 73 человека! Спасибо всем вам, бежим к первой сотке! Зовите друзей, конечно же ставьте огоньки и пишите свои замечания и предложения под постами!
@lechim_ai
Пожалуй, это то, о чем ты задумываешься в последнюю очередь, будучи ML-инженером. Сейчас же меня эта тема начинает привлекать все больше, кажется, что активность вокруг выстраивания HR-бренда сильно сплачивает команду, а более того может развить те аспекты сотрудников, которые слабо задействованы в рутинном потоке рабочих задач.
Понятнее - поговорим сегодня об идеях активностей в ML отделе, которые помогают улучшить имидж компании на рынке труда, среди клиентов, в целом звучать в инфополе.
1. Написание научных статей. К сожалению, тяжело заниматься написанием статей между делом. Продуктовая разработка сильно отличается от трушного ресерча, про отличие такого рода команд поговорим когда-нибудь в будущем. В бизнесе ресерч ради ресерча сложно "продать", поэтому тут есть два варианта. Первое - это выделение отдельной команды, KPI которой заточен на выпуск статей, в случае, если есть понимание для чего это нужно, второе - статья может родиться в случае решения сложной продуктовой задачи, но в таком сценарии регулярность публикаций не определена.
2. Ведение блога, технические статьи "а как у нас". Стандартный пример площадки это habr, тг-канал. Здесь необходимые усилия кратно меньше, чем в первом варианте. Идеальный вариант - рассказывать о предпоследней разработке. Если ваши идеи переиспользуют - то вы уже сделали еще один шаг, при этом эти идеи будут звучать актуально и будут высоко оценены читателями.
3. Записи meet-up. В случае, если в компании организованы какие-то встречи с обсуждениями новых технологий, доклады о best practices и тд - все это можно записывать и выкладывать на любую из возможных площадок. Если к этому добавить еще и немного монтажа с маркетингом, то можно превратить команду из млщиков в полноценных блогеров.
4. Git. Тут я бы выделил два направления. Публикация весов моделей с простеньким кодом инфренса/обучения - этот вариант мне кажется более проигрышным, в особенности небольшая компания никогда не узнает как переиспользовали их модель, и "продуктовая" модель, вероятнее всего, никому не нужна на рынке, потому что решает узкую задачу. Второй же вариант это разработка библиотек. Создание полезных для комьюнити инструментов. Open-source прекрасен тем, что он не имеет региональных границ и может повысить ваше признание за рубежом.
5. API. Более интересной идеей по шерингу моделей кажется предоставление API доступа к ней. Так можно анализировать кто и под какие задачи ее использует. Второе большое направление в контексте API - это создание бенчмарков, тестовых систем. Особенно актуально, если вы занимаетесь узкой предметной областью, то идея сделать свой ImageNet или COCO и стать законодателем моды в этой области - звучит перспективно.
6. Данные. Продолжением предыдущего поста является в целом шеринг данных. Можно не создавать тестовую систему, можно просто подготовить хорошо размеченный датасет и обозначить его тестовым набором данных. Также можно выкладывать и датасеты для обучения, внутренние или переразмеченные открытые. Но этот момент очень тонкий. Хорошо размеченные данные куда ценнее любой разработанной технологии, а потому и делиться ими нужно с умом.
7. Конференции. Выступление на конференциях. Лучше иметь несколько заранее готовых докладов и периодически обновлять свою базу.
8. Обучающие курсы. Об этом тоже, однажды, поговорим подробнее. ML отдел может поучаствовать в написании обучающего курса для университета ли, для какой-то интеренет платформы, а еще круче реализовать свой курс и выложить его на свои площадки.
9. Прочее. Организация хакатонов, конференций, активное присутствие в специализированных каналах и многое другое.
В этом посте предложил идеи, как ML отдел может работать над HR-брендом компании. Явно что-то забыл, поделитесь своими идеями в комментариях!
Нас уже 73 человека! Спасибо всем вам, бежим к первой сотке! Зовите друзей, конечно же ставьте огоньки и пишите свои замечания и предложения под постами!
@lechim_ai
👍9❤6🔥6
RAG
Последнее время стал вытаскивать себя из кокона компьютерного зрения, активно изучая NLP, так как современный ML не терпит разделения на модальности. В частности посмотрел курс от ШАДа и Лены Войта, вау человек и такой же клевый курс, зацените, если вдруг кто искал материалы.
Retrieval Augmented Generation - метод, при котором к запросу пользователя программно добавляется какая-то информация и уже такой комбинированный запрос идет в языковую модель. Что это будет за информация - зависит от вашего приложения, чаще всего это какая-то база знаний или просто результат работы какой-то функции.
В чем плюсы и когда используют?
1. Постоянное изменение базы знаний. Невозможно дообучить модель на своих данных, чтобы она смогла ответить на вопрос "какая сейчас погода?".
2. Дообучать дорого. Альтернативой, конечно, является дообучение под вашу задачу, но почти всегда это долго, дорого, сложно и не факт, что что-то получится.
3. Факт-чекинг. Использование RAG это простой способ понизить галлюцинирование модели и повысить интерпретируемость выдаваемого результата. Это не серебряная пуля, но простой шаг в этом направлении.
Основной минус подхода: пространство "знаний" модели искусственно ограничено размерами базы данных.
Как работает и из чего состоит?
Основные шаги:
1. Взять базу знаний и разбить ее на маленькие части (chunks).
2. Превратить чанки в вектора (embeddings) и сложить в веторную БД.
3. Приходящий запрос пользователя превратить в эмбеддинг, вытащить из БД топ K самых похожих чанков по какой-то мере близости векторов.
4. Приклеить к запросу пользователя чанки и подать это в языковую модель, попросив ее давать ответ на вопрос на основе добавленных знаний.
Составляющие:
1. База знаний. Например, набор документов.
2. Векторная база данных. Для хранения эмбеддингов чанков.
3. Encoder. Модель, которая будет переводить подаваемый текст в эмбеддинг.
4. Generator. Модель, которая на основе входящего запроса будет генерировать текст.
3 и 4 пункт не обязательно делать самостоятельно, можно взять opensource или работать по API.
В каких местах можно улучшать:
1. Перефразировка запроса. Вопрос пользователя может быть задан не очень точно, можно попробовать его переделать, чтобы он отвечал требованиям построенной системы.
2. Классификация запроса. Необходимо балансировать между очень много знаний (есть целый бенчмарк посвященный этой проблеме) и очень мало знаний. А значит было бы круто иметь базу лаконичную, при этом достаточную. Можно добавить много источников данных и представить их в разной форме (таблицы, поисковик, текстовые документы). И реализовать механизм, который бы определял среди какого подмножества знаний искать и в какой форме они представлены.
3. Несколько методов создания эмбеддингов. Задача поиска релевантных чанков - основная в этой технике и завязана на качестве обучения encoder. Можно использовать несколько encoder-ов обученных по-разному. Популярный метод - это объединение sparse методов (многие любят BM25) и dense методов (encoder-ы).
4. Улучшение чанков. В качестве baseline, чанки содержат просто кусочек текста, но можно расширить их автономность. В целом: можно переписать исходные чанки и свести их в какое-то новое пространство.
5. Ранжирование чанков. Стоит добавить к задаче Reranker. Мы достаем из базы N близких чанков, а он оставляет уже из них лучше K.
6. Валидация ответов. Можно добавить модель, которая по паре вопрос-чанк будет говорить относится ли этот чанк к вопросу. Можно на пару вопрос-ответ спросить, а нет ли тут галлюцинаций и вообще является ли то, что было сгенерировано, ответом на вопрос. И таких валидаций можно придумать очень много, хотя, конечно, все это увеличивает время ожидания ответа.
7. Более хитрые знания. Работать с текстом и таблицами - понятно как. Но есть графики, картинки, видео, аудио. Потенциально все это также может составлять часть общей базы знаний.
Вот очень крутое видео обо всем этом от команды LangChain.
Пишите о чем хотелось бы еще почитать, ставьте огоньки и пересылайте своим друзьям и знакомым, добьем 100 до Нового Года?
@lechim_ai
Последнее время стал вытаскивать себя из кокона компьютерного зрения, активно изучая NLP, так как современный ML не терпит разделения на модальности. В частности посмотрел курс от ШАДа и Лены Войта, вау человек и такой же клевый курс, зацените, если вдруг кто искал материалы.
Retrieval Augmented Generation - метод, при котором к запросу пользователя программно добавляется какая-то информация и уже такой комбинированный запрос идет в языковую модель. Что это будет за информация - зависит от вашего приложения, чаще всего это какая-то база знаний или просто результат работы какой-то функции.
В чем плюсы и когда используют?
1. Постоянное изменение базы знаний. Невозможно дообучить модель на своих данных, чтобы она смогла ответить на вопрос "какая сейчас погода?".
2. Дообучать дорого. Альтернативой, конечно, является дообучение под вашу задачу, но почти всегда это долго, дорого, сложно и не факт, что что-то получится.
3. Факт-чекинг. Использование RAG это простой способ понизить галлюцинирование модели и повысить интерпретируемость выдаваемого результата. Это не серебряная пуля, но простой шаг в этом направлении.
Основной минус подхода: пространство "знаний" модели искусственно ограничено размерами базы данных.
Как работает и из чего состоит?
Основные шаги:
1. Взять базу знаний и разбить ее на маленькие части (chunks).
2. Превратить чанки в вектора (embeddings) и сложить в веторную БД.
3. Приходящий запрос пользователя превратить в эмбеддинг, вытащить из БД топ K самых похожих чанков по какой-то мере близости векторов.
4. Приклеить к запросу пользователя чанки и подать это в языковую модель, попросив ее давать ответ на вопрос на основе добавленных знаний.
Составляющие:
1. База знаний. Например, набор документов.
2. Векторная база данных. Для хранения эмбеддингов чанков.
3. Encoder. Модель, которая будет переводить подаваемый текст в эмбеддинг.
4. Generator. Модель, которая на основе входящего запроса будет генерировать текст.
3 и 4 пункт не обязательно делать самостоятельно, можно взять opensource или работать по API.
В каких местах можно улучшать:
1. Перефразировка запроса. Вопрос пользователя может быть задан не очень точно, можно попробовать его переделать, чтобы он отвечал требованиям построенной системы.
2. Классификация запроса. Необходимо балансировать между очень много знаний (есть целый бенчмарк посвященный этой проблеме) и очень мало знаний. А значит было бы круто иметь базу лаконичную, при этом достаточную. Можно добавить много источников данных и представить их в разной форме (таблицы, поисковик, текстовые документы). И реализовать механизм, который бы определял среди какого подмножества знаний искать и в какой форме они представлены.
3. Несколько методов создания эмбеддингов. Задача поиска релевантных чанков - основная в этой технике и завязана на качестве обучения encoder. Можно использовать несколько encoder-ов обученных по-разному. Популярный метод - это объединение sparse методов (многие любят BM25) и dense методов (encoder-ы).
4. Улучшение чанков. В качестве baseline, чанки содержат просто кусочек текста, но можно расширить их автономность. В целом: можно переписать исходные чанки и свести их в какое-то новое пространство.
5. Ранжирование чанков. Стоит добавить к задаче Reranker. Мы достаем из базы N близких чанков, а он оставляет уже из них лучше K.
6. Валидация ответов. Можно добавить модель, которая по паре вопрос-чанк будет говорить относится ли этот чанк к вопросу. Можно на пару вопрос-ответ спросить, а нет ли тут галлюцинаций и вообще является ли то, что было сгенерировано, ответом на вопрос. И таких валидаций можно придумать очень много, хотя, конечно, все это увеличивает время ожидания ответа.
7. Более хитрые знания. Работать с текстом и таблицами - понятно как. Но есть графики, картинки, видео, аудио. Потенциально все это также может составлять часть общей базы знаний.
Вот очень крутое видео обо всем этом от команды LangChain.
Пишите о чем хотелось бы еще почитать, ставьте огоньки и пересылайте своим друзьям и знакомым, добьем 100 до Нового Года?
@lechim_ai
❤8🔥3👍2💩1😭1
Ключевой навык
Любые мои попытки построить матрицу навыков, которая бы грамотно отражала список скилов, которые присущи тому или иному грейду, разбивались о разнообразие специалистов вокруг меня. Вопреки моей центральной идее - загнать максимум происходящего в цифры, моя оценка сотрудника все еще содержит в себе большое количество субъективного.
Но за время общения с разными людьми, мне кажется, я заметил один важный навык, который необходим каждому, чтобы расти. Поразмышляем.
Если так подумать, то на столько ли уж серьезно, в техническом смысле, отличается junior от senior? Теоретические знания всем доступны в равном объеме (стаж вырабатывать для этого не надо), инфраструктурные особенности компании и в целом навык "работать" - все это познается за полгода. Поэтому, по моим ощущениям, практический опыт (над которым напрямую не поработать) и умение видеть картину целиком - это ключевое. В отличие от опыта, "картиной мира" уже можно заняться. Есть еще много чего, конечно, я говорю о немного упрощенной модели мира, чтобы подсветить основную идею и уместиться в размер поста.
Умение видеть картину целиком. Отношение сотрудника к потоку задач как к тикетам - то, с чем активно нужно бороться руководителю. С первых дней работы необходимо выстроить такие взаимоотношения, чтобы любая задача могла быть оспорена. Если вы, как руководитель, не можете объяснить подчиненному, зачем делать какую-то задачу - а реально ли ее стоит делать? Если вы, как сотрудник, не понимаете откуда взялась эта задача - зачем вам тратить свое время на нее, а вдруг вы ее сделаете в стол?
Необходимо постоянно задавать вопросы, если появляется ощущение, что часть информации по задаче находится в тумане войны. По моему опыту, 90% непроработанных краевых случаев появляются в связи с тем, что специалист, делая задачу, не понимает откуда она пришла и какие цели преследовал тот, кто ее поставил.
Чем шире ваш взгляд, тем меньше руководству нужно описывать вам детали задачи, вы знаете кого попросить о помощи, вы понимаете с каким "качеством" ее делать (это на века или ad-hoc на 1 раз). Видно, что все это составные более высоких грейдов. При этом здорово расширяться не только за счет вопросов руководителю. Пообщайтесь с бизнесом, с прОдуктом, с проджектом, с остальной командой и все сложится в единую картину мира, и вы поймете, где в этой пищевой цепочке вы.
И в добавок к вышесказанному. Популярный миф: если я буду часто дергать вопросами моего начальника - он решит, что я ничего не знаю. Во-первых, он и так знает, что вы ничего не знаете, во-вторых все любят рассказывать то, что знают хорошо, поэтому расширить ваше понимание будет только в радость.
Под конец года решил сильно не нагружать, всем нам пора отдохнуть!
Всех с наступающим, желаю вам растить свое любопытство и критическое мышление, а главное быть с теми, кого вы любите! А все карьерные победы на это уже нанизаются.
Мы пробили с вами планку в 100 подписчиков под конец года, спасибо вам большое! На 2025 большие планы, будем расти вместе!
@lechim_ai
Любые мои попытки построить матрицу навыков, которая бы грамотно отражала список скилов, которые присущи тому или иному грейду, разбивались о разнообразие специалистов вокруг меня. Вопреки моей центральной идее - загнать максимум происходящего в цифры, моя оценка сотрудника все еще содержит в себе большое количество субъективного.
Но за время общения с разными людьми, мне кажется, я заметил один важный навык, который необходим каждому, чтобы расти. Поразмышляем.
Если так подумать, то на столько ли уж серьезно, в техническом смысле, отличается junior от senior? Теоретические знания всем доступны в равном объеме (стаж вырабатывать для этого не надо), инфраструктурные особенности компании и в целом навык "работать" - все это познается за полгода. Поэтому, по моим ощущениям, практический опыт (над которым напрямую не поработать) и умение видеть картину целиком - это ключевое. В отличие от опыта, "картиной мира" уже можно заняться. Есть еще много чего, конечно, я говорю о немного упрощенной модели мира, чтобы подсветить основную идею и уместиться в размер поста.
Умение видеть картину целиком. Отношение сотрудника к потоку задач как к тикетам - то, с чем активно нужно бороться руководителю. С первых дней работы необходимо выстроить такие взаимоотношения, чтобы любая задача могла быть оспорена. Если вы, как руководитель, не можете объяснить подчиненному, зачем делать какую-то задачу - а реально ли ее стоит делать? Если вы, как сотрудник, не понимаете откуда взялась эта задача - зачем вам тратить свое время на нее, а вдруг вы ее сделаете в стол?
Необходимо постоянно задавать вопросы, если появляется ощущение, что часть информации по задаче находится в тумане войны. По моему опыту, 90% непроработанных краевых случаев появляются в связи с тем, что специалист, делая задачу, не понимает откуда она пришла и какие цели преследовал тот, кто ее поставил.
Чем шире ваш взгляд, тем меньше руководству нужно описывать вам детали задачи, вы знаете кого попросить о помощи, вы понимаете с каким "качеством" ее делать (это на века или ad-hoc на 1 раз). Видно, что все это составные более высоких грейдов. При этом здорово расширяться не только за счет вопросов руководителю. Пообщайтесь с бизнесом, с прОдуктом, с проджектом, с остальной командой и все сложится в единую картину мира, и вы поймете, где в этой пищевой цепочке вы.
И в добавок к вышесказанному. Популярный миф: если я буду часто дергать вопросами моего начальника - он решит, что я ничего не знаю. Во-первых, он и так знает, что вы ничего не знаете, во-вторых все любят рассказывать то, что знают хорошо, поэтому расширить ваше понимание будет только в радость.
Под конец года решил сильно не нагружать, всем нам пора отдохнуть!
Всех с наступающим, желаю вам растить свое любопытство и критическое мышление, а главное быть с теми, кого вы любите! А все карьерные победы на это уже нанизаются.
Мы пробили с вами планку в 100 подписчиков под конец года, спасибо вам большое! На 2025 большие планы, будем расти вместе!
@lechim_ai
❤16🔥7❤🔥3👍1🤮1💩1
Ограничения LLM
Недавно у меня был спор с моей подругой о том, на сколько современный эйай, ChatGPT в частности, близки к AGI, умнее ли они людей, а если нет, то на сколько близко время тотальной доминации искусственной мысли над человеческой. Параллельно мне посоветовали посмотреть интервью Лекса Фридмана с Ян Лекуном, очень крутое, к слову. Совместно, эти два диалога: один на кухне, второй в студии, настроили меня на то, чтобы покрутить с вами некоторые идеи.
Мысль №1:
Оценка всех имеющихся текстовых данных для обучения LLM равна 2*10^13 байтов - если читать по 8 часов в день, то нам понадобится 170 лет для потребления этого объема знаний. При этом исследования показывают, что объем информации, который поступает через зрение к 4 годам жизни человека равен 10^15 байтов. Вывод тут простой - через органы чувств мы получаем гораздо больше информации, чем через язык.
Мысль №2:
А вообще что такое текст? "Всякая записанная речь" говорит интернет. А что такое речь/язык? (тут уже будет мое объяснение) Это способ описания всего происходящего. Нам дан этот мир, с его физическими законами, с его многообразием, а язык это методика, однажды избранная человеком (рукотворная) для того, чтобы описать весь этот мир. И тут возникает логичный вопрос, а являются ли пространство языка и пространство нашего мира равномощными? Можно ли через текст описать все то, что происходит вокруг? Хотя бы можно ли описать через текст все то, что человек способен воспринять через органы чувств, возвращаясь к первой мысли? Если да, то тогда первая мысль не так важна и мы можем сказать, что ранг матрицы, описывающий мир и ранг текстовой матрицы равны, что конечно, контринтуитивно. Сжатый аргумент от Лекуна: когда вы что-то представляете - вы не делаете это на каком-то языке, сказать какую-то мысль это уже и есть уйти от более абстрактного уровня представления на котором мы, например, планируем, что хотим сказать или в целом "размышляем".
Мысль №3:
Самый очевидный орган чувств - это зрение, а в машинном обучении эту тему давно уже глубоко прокопали. Давайте подружим тексты и зрение, частично избегая ответов на холиварные вопросы из 2 пункта. Идеи есть, например Chameleon или LLaVA. Основная суть - давайте картинки превратим в вектора, а потом эти вектора превратим в текстовые токены и добавим их к обычному тексту, после чего засунем в языковую модель. Получаем модель, которая как бы умеет работать и с картинками и с текстами одновременно, более умного подхода пока не придумали. Но превращая картинки в текст мы фактически уже теряем то, к чему стремились, мы опять сжали пространство до текста. Помимо этого есть большая душноватая статья про исследование такого подхода, которая пытается понять на сколько "визуальный" текст живет по законам лингвистического, вывод в статье: на язык это не похоже, а значит с визуалом надо работать иначе.
В сухом остатке, большие языковые модели - это прорывная технология, способная очень сильно упростить нашу повседневную жизнь, инструмент, который, в правильных руках, способен на невероятные вещи. При этом, текущие известные подходы к созданию моделей далеки от того, чтобы сделать Искусственный Интеллект. Случится ли это однажды - вопрос лишь веры, факт заключается в том, что человечество пока не придумало методику, которая бы намекала на то, что это случится скоро.
Как мне кажется куда все идет: языковые модели все больше будут идти в ризонинг - CoT от o1 и тд. При этом тут я не ожидаю больше каких-то невероятных прорывов. Фокус будет возвращаться к визуалу, а скорее всего именно в видео. Генеративные модели для видео - это новый прорыв в понимании окружающей действительности. При этом все больше статей будет выходить про работу с мультимодальными данными, пытаясь подружить картинки и тексты каким-то совершенно иным образом.
Спасибо, что поразмышляли вместе со мной - пишите ваши мысли и вижен в комментариях, продолжим разгонять там. Выхожу из новогодних каникул, цели на канал в 2025 большие, давайте пройдем этот путь вместе!
@lechim_ai
Недавно у меня был спор с моей подругой о том, на сколько современный эйай, ChatGPT в частности, близки к AGI, умнее ли они людей, а если нет, то на сколько близко время тотальной доминации искусственной мысли над человеческой. Параллельно мне посоветовали посмотреть интервью Лекса Фридмана с Ян Лекуном, очень крутое, к слову. Совместно, эти два диалога: один на кухне, второй в студии, настроили меня на то, чтобы покрутить с вами некоторые идеи.
Мысль №1:
Оценка всех имеющихся текстовых данных для обучения LLM равна 2*10^13 байтов - если читать по 8 часов в день, то нам понадобится 170 лет для потребления этого объема знаний. При этом исследования показывают, что объем информации, который поступает через зрение к 4 годам жизни человека равен 10^15 байтов. Вывод тут простой - через органы чувств мы получаем гораздо больше информации, чем через язык.
Мысль №2:
А вообще что такое текст? "Всякая записанная речь" говорит интернет. А что такое речь/язык? (тут уже будет мое объяснение) Это способ описания всего происходящего. Нам дан этот мир, с его физическими законами, с его многообразием, а язык это методика, однажды избранная человеком (рукотворная) для того, чтобы описать весь этот мир. И тут возникает логичный вопрос, а являются ли пространство языка и пространство нашего мира равномощными? Можно ли через текст описать все то, что происходит вокруг? Хотя бы можно ли описать через текст все то, что человек способен воспринять через органы чувств, возвращаясь к первой мысли? Если да, то тогда первая мысль не так важна и мы можем сказать, что ранг матрицы, описывающий мир и ранг текстовой матрицы равны, что конечно, контринтуитивно. Сжатый аргумент от Лекуна: когда вы что-то представляете - вы не делаете это на каком-то языке, сказать какую-то мысль это уже и есть уйти от более абстрактного уровня представления на котором мы, например, планируем, что хотим сказать или в целом "размышляем".
Мысль №3:
Самый очевидный орган чувств - это зрение, а в машинном обучении эту тему давно уже глубоко прокопали. Давайте подружим тексты и зрение, частично избегая ответов на холиварные вопросы из 2 пункта. Идеи есть, например Chameleon или LLaVA. Основная суть - давайте картинки превратим в вектора, а потом эти вектора превратим в текстовые токены и добавим их к обычному тексту, после чего засунем в языковую модель. Получаем модель, которая как бы умеет работать и с картинками и с текстами одновременно, более умного подхода пока не придумали. Но превращая картинки в текст мы фактически уже теряем то, к чему стремились, мы опять сжали пространство до текста. Помимо этого есть большая душноватая статья про исследование такого подхода, которая пытается понять на сколько "визуальный" текст живет по законам лингвистического, вывод в статье: на язык это не похоже, а значит с визуалом надо работать иначе.
В сухом остатке, большие языковые модели - это прорывная технология, способная очень сильно упростить нашу повседневную жизнь, инструмент, который, в правильных руках, способен на невероятные вещи. При этом, текущие известные подходы к созданию моделей далеки от того, чтобы сделать Искусственный Интеллект. Случится ли это однажды - вопрос лишь веры, факт заключается в том, что человечество пока не придумало методику, которая бы намекала на то, что это случится скоро.
Как мне кажется куда все идет: языковые модели все больше будут идти в ризонинг - CoT от o1 и тд. При этом тут я не ожидаю больше каких-то невероятных прорывов. Фокус будет возвращаться к визуалу, а скорее всего именно в видео. Генеративные модели для видео - это новый прорыв в понимании окружающей действительности. При этом все больше статей будет выходить про работу с мультимодальными данными, пытаясь подружить картинки и тексты каким-то совершенно иным образом.
Спасибо, что поразмышляли вместе со мной - пишите ваши мысли и вижен в комментариях, продолжим разгонять там. Выхожу из новогодних каникул, цели на канал в 2025 большие, давайте пройдем этот путь вместе!
@lechim_ai
🔥17❤12🤮2💩1🤡1
Манифест компании
Пока я собираю материалы для поста посвященного VLM, скорее более технического, хотел бы обсудить более "естественную" тему, которая до недавнего времени вызывала во мне скептицизм, и думаю, что не у одного меня, поэтому хотелось бы поделиться своим опытом взаимодействия с этим.
Поговорим сегодня о миссии и ценностях компании. Попробуем поразмышлять есть ли какой-то смысл в манифесте или это повод закатить глаза со словами "вокруг одни менеджеры, процессы, методологии и слоганы, а работать кто будет?".
Расскажу маленькую историю, которая позволила мне взглянуть на ситуацию иначе. Пару дней назад, в рамках обсуждения целей компании, команде был представлен спектр того, какие возможности предоставляет рынок, какие есть запросы и потенциальные заказчики. Каково же было мое удивление, когда один из возможных вариантов, более того, достаточно деньгоемкий, был встречен фразой "мне кажется это противоречит ценностям нашей компании". Я залез на wiki и, действительно, обнаружил одну из ценностей, которая могла быть попрана этим бизнес-опотьюнити. Разговор пошел дальше, но почему-то эта ситуация меня сильно впечатлила.
"Работа в найме", что может звучать более удручающе, наверное только "работа на дядю", да вообще "работа". Но в целом, откуда берется отрицательная коннотация понятно. Жизнь проходит мимо, а ты минимум треть отведенного тебе времени проводишь в бессмысленной беготне, где все делают вид, что закрытый контракт, код без багов и тд - это высочайшая ценность.
А теперь представьте, что все это не бессмысленно. И бизнес - это не бесчувственная машина по перевариванию денег, а реально следует определенной идее. И вы, как сотрудник, часть этой идеи, и вы знаете, что люди рядом отобраны как те, кто тоже готов следовать ей и вы все вместе разделяете общие ценности. Картина сильно меняется.
Если человек пытается понять "для чего он живет", то круто, если работодатель постарается объяснить своим сотрудникам "для чего существует компания". Это и есть Миссия. Если кто-то готов идти по головам, а кто-то против убийства животных, а кто-то за равенство прав, то почему бы таким людям не объединяться? Это и есть Ценности.
Скептицизм вокруг манифестов компании сохраняется в связи с тем, что в большинстве случаев это и остается просто бумажкой или страницей на wiki. Мне кажется менеджерам стоит периодически возвращаться к такого рода материалам и транслировать их своим подчиненным, использовать как аргумент при принятии решений, опираться на них при найме. Конечно, есть большое количество способов сплотить коллектив, но мне кажется это мощный механизм, если им действительно пользуются. Мне даже кажется неплохой практикой писать "подманифесты" отделов, которые бы не противоречили и детализировали ориентиры компании.
С текущим ощущением, я бы точно посвящал время синхронизации по этому вопросу при найме, и как нанимающий менеджер, и при прохождении собеседования. Лично мне важно ощущать, что я делаю что-то большее, чем зарабатываю деньги.
@lechim_ai
Пока я собираю материалы для поста посвященного VLM, скорее более технического, хотел бы обсудить более "естественную" тему, которая до недавнего времени вызывала во мне скептицизм, и думаю, что не у одного меня, поэтому хотелось бы поделиться своим опытом взаимодействия с этим.
Поговорим сегодня о миссии и ценностях компании. Попробуем поразмышлять есть ли какой-то смысл в манифесте или это повод закатить глаза со словами "вокруг одни менеджеры, процессы, методологии и слоганы, а работать кто будет?".
Расскажу маленькую историю, которая позволила мне взглянуть на ситуацию иначе. Пару дней назад, в рамках обсуждения целей компании, команде был представлен спектр того, какие возможности предоставляет рынок, какие есть запросы и потенциальные заказчики. Каково же было мое удивление, когда один из возможных вариантов, более того, достаточно деньгоемкий, был встречен фразой "мне кажется это противоречит ценностям нашей компании". Я залез на wiki и, действительно, обнаружил одну из ценностей, которая могла быть попрана этим бизнес-опотьюнити. Разговор пошел дальше, но почему-то эта ситуация меня сильно впечатлила.
"Работа в найме", что может звучать более удручающе, наверное только "работа на дядю", да вообще "работа". Но в целом, откуда берется отрицательная коннотация понятно. Жизнь проходит мимо, а ты минимум треть отведенного тебе времени проводишь в бессмысленной беготне, где все делают вид, что закрытый контракт, код без багов и тд - это высочайшая ценность.
А теперь представьте, что все это не бессмысленно. И бизнес - это не бесчувственная машина по перевариванию денег, а реально следует определенной идее. И вы, как сотрудник, часть этой идеи, и вы знаете, что люди рядом отобраны как те, кто тоже готов следовать ей и вы все вместе разделяете общие ценности. Картина сильно меняется.
Если человек пытается понять "для чего он живет", то круто, если работодатель постарается объяснить своим сотрудникам "для чего существует компания". Это и есть Миссия. Если кто-то готов идти по головам, а кто-то против убийства животных, а кто-то за равенство прав, то почему бы таким людям не объединяться? Это и есть Ценности.
Скептицизм вокруг манифестов компании сохраняется в связи с тем, что в большинстве случаев это и остается просто бумажкой или страницей на wiki. Мне кажется менеджерам стоит периодически возвращаться к такого рода материалам и транслировать их своим подчиненным, использовать как аргумент при принятии решений, опираться на них при найме. Конечно, есть большое количество способов сплотить коллектив, но мне кажется это мощный механизм, если им действительно пользуются. Мне даже кажется неплохой практикой писать "подманифесты" отделов, которые бы не противоречили и детализировали ориентиры компании.
С текущим ощущением, я бы точно посвящал время синхронизации по этому вопросу при найме, и как нанимающий менеджер, и при прохождении собеседования. Лично мне важно ощущать, что я делаю что-то большее, чем зарабатываю деньги.
"Трансформировать здравоохранение через инновационные IT-решения с целью повышения качества медицинской помощи".
@lechim_ai
👍10💯7❤2🤮1💩1
VLM Survey
Использование мультимодальных подходов, в первую очередь изображения плюс текст, все активнее становится ключевой киллер фичей при разработке general моделей.
Недавно еще крышесносные LLM-чаты уже не воспринимаются как полноценные решения, если в них нет поддержки изображений.
Я планирую сделать серию постов про VLM (vision-language models) и начать я бы хотел с технического обзора статей, обеспеченных мировым сообществом к сегодняшнему дню.
Если вы специалист в ML и хотите разобраться в том, что понаписали про VLM, я отоборал вам самую мякотку, одна статья, чтобы зайти в новую сферу.
Чтобы не писать один огромный пост в тг - все красиво оформил здесь. Заходите и оценивайте!
Думаю это мой самый проработанный и энергозатратный пост. Мне будет приятно, если вы поделитесь им со своими знакомыми, ведь материал и правда, кажется, получился неплохой.
Если я упустил что-то важное - напишите, пожалуйста, об этом в комментариях. Есть идея еще пособирать материала и написать статью на habr, поэтому ваши правки и замечания будут очень полезны!
Лайк, подписка, колокольчик и до новых встреч!
@lechim_ai
Использование мультимодальных подходов, в первую очередь изображения плюс текст, все активнее становится ключевой киллер фичей при разработке general моделей.
Недавно еще крышесносные LLM-чаты уже не воспринимаются как полноценные решения, если в них нет поддержки изображений.
Я планирую сделать серию постов про VLM (vision-language models) и начать я бы хотел с технического обзора статей, обеспеченных мировым сообществом к сегодняшнему дню.
Если вы специалист в ML и хотите разобраться в том, что понаписали про VLM, я отоборал вам самую мякотку, одна статья, чтобы зайти в новую сферу.
Чтобы не писать один огромный пост в тг - все красиво оформил здесь. Заходите и оценивайте!
Думаю это мой самый проработанный и энергозатратный пост. Мне будет приятно, если вы поделитесь им со своими знакомыми, ведь материал и правда, кажется, получился неплохой.
Если я упустил что-то важное - напишите, пожалуйста, об этом в комментариях. Есть идея еще пособирать материала и написать статью на habr, поэтому ваши правки и замечания будут очень полезны!
Лайк, подписка, колокольчик и до новых встреч!
@lechim_ai
Telegraph
VLM Survey
Если вы зашли сюда и вас интересует заголовок статьи, значит вам, вероятно, не нужно объяснять для чего используются и какие задачи решают современные Vision-Language Models. Решил для вас собрать обзорку по VLM: что почитать, чтобы понять основные идеи.…
🔥19🗿2👎1🤣1💊1
This media is not supported in your browser
VIEW IN TELEGRAM
Субъективный взгляд на корпоративные штучки
За годы работы у меня сложился образ "правильного" рабочего места в IT-компании. Этот пост будет очень субъективным и, скорее всего, может вызвать несогласие с некоторыми пунктами - это нормально. Итак, мой взгляд по некоторым корпоративным холиварным вопросам:
1. Ты/Вы.
Со всеми на ты, но с кем надо на вы - пусть будет так. Если ты во внуки годишься своему коллеге - почему вас должны обязывать общаться на ты? Ты волен общаться согласно своему воспитанию. Конечно, "ты" способствует исчезновению границ и более плотному взаимодействию в среднем, но мне не нравится тенденция к обязательности в этом вопросе. Я бы перевел в класс "по-умолчанию" или "рекомендуется".
2. Субординация.
Я не фанат этой штуки. Напоминание "кто тут главный" не несет за собой продуктивности. Появление двух ролей "руководитель"-"подчиненный" приводит к тому, что человеку необходимо по-особому вести себя со своим начальником. Значит пропадает определенный слой прозрачности и честности, что влечет за собой появление дополнительных формальностей, тормозящих работу.
Субординация, в здоровом коллективе, регулируется законами взаимного уважения. Для этого руководителю лишь поступками можно доказать, что он достоин того самого уважения и к нему стоит прислушиваться.
3. График работы.
Любой удобный. Формат 9-18 не подходит современной IT-компании. Трекеры проведенного за компьютером или в офисе времени - бред. Людям платят за сделанные задачи, а не за часы. Поэтому можно уйти пораньше, прийти попозже, уйти в середине дня, а потом вернуться глубокой ночью. График должен включать проведение встреч и своевременные ответы в корпоративных чатах, в остальном правил нет. Пусть у сотрудника будет комфортный ему график, тогда он и выдаст максимум.
4. Внерабочие часы.
Сначала я встретил это на собеседовании, после чего я заметил эту тенденцию в инфополе.
Чего? Люди так сильно боятся этого слова, что начинаются такие вот глупости. Если твой подчиненный хочет поработать больше - не мешай взрослому человеку. Если ты хочешь поработать больше - разреши себе. Если надо поработать, чтобы закрыть важную задачу - сделайте это!
Переработки - это инструмент. Нельзя отказываться от молотка, только лишь потому, что вы никогда им не пользовались. Например, это валидный способ идти быстрее остальных.
Единственный контекст, в котором я понимаю проблематику - если вас заставляют работать уже которые выходные, тогда да - стоит это обсудить. И даже не потому, что вас эксплуатируют, а потому, что в компании явно процессы планирования ресурсов не работают.
P.S. Нельзя писать в чатах во внерабочее времени? Можно. Свобода каждого - не отвечать и вернуться с ответом в другой момент.
5. Увольнения.
Я, как руководитель, максимально нормально отношусь к желанию сотрудника уволиться. Если тебя позвали в другое место работать - это окей, никто не обязан своему месту работы. А если тебе еще и предложили там большую должность или зп, то я могу воспринять это на свой счет - воспитал. Но! Я очень плохо отношусь к контрофферам. Метод повышения зарплаты, через получения оффера другой компании, говорит о том, что ваши отношения с руководством не смогли правильно выстроиться. Если ты считаешь, что тебе платят мало - скажи это прямо. И тебе прямо должны ответить, может ли компания позволить платить больше сотруднику твоего уровня. В контроффере я вижу ультимативную форму подачи информации, которая не способствует здоровым отношениям.
6. Дедлайны.
Если вам кажется, что в вашей работе нет дедлайнов, если они вас пугают, то значит, что вы пока находитесь на том уровне, до которого их не спускают - берегут вас. Дедлайны есть всегда, иначе бы ничего не сдвигалось с мертвой точки. Проблема заключается не в их существовании, а в плохом планировании, когда срок - вчера. Поэтому иметь дедлайны - окей и надо лечить не их, как явление, а качество планирования в компании.
Пишите, с чем вы не согласны - давайте подискутируем в комментариях!
@lechim_ai
За годы работы у меня сложился образ "правильного" рабочего места в IT-компании. Этот пост будет очень субъективным и, скорее всего, может вызвать несогласие с некоторыми пунктами - это нормально. Итак, мой взгляд по некоторым корпоративным холиварным вопросам:
1. Ты/Вы.
Со всеми на ты, но с кем надо на вы - пусть будет так. Если ты во внуки годишься своему коллеге - почему вас должны обязывать общаться на ты? Ты волен общаться согласно своему воспитанию. Конечно, "ты" способствует исчезновению границ и более плотному взаимодействию в среднем, но мне не нравится тенденция к обязательности в этом вопросе. Я бы перевел в класс "по-умолчанию" или "рекомендуется".
2. Субординация.
Я не фанат этой штуки. Напоминание "кто тут главный" не несет за собой продуктивности. Появление двух ролей "руководитель"-"подчиненный" приводит к тому, что человеку необходимо по-особому вести себя со своим начальником. Значит пропадает определенный слой прозрачности и честности, что влечет за собой появление дополнительных формальностей, тормозящих работу.
Субординация, в здоровом коллективе, регулируется законами взаимного уважения. Для этого руководителю лишь поступками можно доказать, что он достоин того самого уважения и к нему стоит прислушиваться.
3. График работы.
Любой удобный. Формат 9-18 не подходит современной IT-компании. Трекеры проведенного за компьютером или в офисе времени - бред. Людям платят за сделанные задачи, а не за часы. Поэтому можно уйти пораньше, прийти попозже, уйти в середине дня, а потом вернуться глубокой ночью. График должен включать проведение встреч и своевременные ответы в корпоративных чатах, в остальном правил нет. Пусть у сотрудника будет комфортный ему график, тогда он и выдаст максимум.
4. Внерабочие часы.
Сначала я встретил это на собеседовании, после чего я заметил эту тенденцию в инфополе.
"Никаких переработок! Я хочу запретить переработки в моем отделе."
Чего? Люди так сильно боятся этого слова, что начинаются такие вот глупости. Если твой подчиненный хочет поработать больше - не мешай взрослому человеку. Если ты хочешь поработать больше - разреши себе. Если надо поработать, чтобы закрыть важную задачу - сделайте это!
Переработки - это инструмент. Нельзя отказываться от молотка, только лишь потому, что вы никогда им не пользовались. Например, это валидный способ идти быстрее остальных.
Единственный контекст, в котором я понимаю проблематику - если вас заставляют работать уже которые выходные, тогда да - стоит это обсудить. И даже не потому, что вас эксплуатируют, а потому, что в компании явно процессы планирования ресурсов не работают.
P.S. Нельзя писать в чатах во внерабочее времени? Можно. Свобода каждого - не отвечать и вернуться с ответом в другой момент.
5. Увольнения.
Я, как руководитель, максимально нормально отношусь к желанию сотрудника уволиться. Если тебя позвали в другое место работать - это окей, никто не обязан своему месту работы. А если тебе еще и предложили там большую должность или зп, то я могу воспринять это на свой счет - воспитал. Но! Я очень плохо отношусь к контрофферам. Метод повышения зарплаты, через получения оффера другой компании, говорит о том, что ваши отношения с руководством не смогли правильно выстроиться. Если ты считаешь, что тебе платят мало - скажи это прямо. И тебе прямо должны ответить, может ли компания позволить платить больше сотруднику твоего уровня. В контроффере я вижу ультимативную форму подачи информации, которая не способствует здоровым отношениям.
6. Дедлайны.
Если вам кажется, что в вашей работе нет дедлайнов, если они вас пугают, то значит, что вы пока находитесь на том уровне, до которого их не спускают - берегут вас. Дедлайны есть всегда, иначе бы ничего не сдвигалось с мертвой точки. Проблема заключается не в их существовании, а в плохом планировании, когда срок - вчера. Поэтому иметь дедлайны - окей и надо лечить не их, как явление, а качество планирования в компании.
Пишите, с чем вы не согласны - давайте подискутируем в комментариях!
@lechim_ai
👍13❤5🔥5🤩1
Давненько я не появлялся на конференциях.
Завтра буду выступать на Онлайн-диагностике 25, поговорим об автономном ИИ в медицине.
Завтра буду выступать на Онлайн-диагностике 25, поговорим об автономном ИИ в медицине.
🔥9🤣1🗿1
Forwarded from Третье Мнение
«Третье Мнение» на конференции «Онлайн-диагностика 25»
Илья Налетов, руководитель направления искусственного интеллекта, представит доклад на тему «Уровни автономности ИИ: как сделать новый шаг?» на круглом столе «Автономный искусственный интеллект: от слов к делу».
Спикер расскажет:
➡️ Какие уровни автономности есть в целом
➡️ Какими по уровню автономности бывают ИИ-сервисы в здравоохранении
➡️ Как повысить автономность ИИ: 4 способа
Модераторы сессии:
📅 📅 28 марта в 9:00 (мск)
📍 📍 Онлайн после регистрации, зал 3
Илья Налетов, руководитель направления искусственного интеллекта, представит доклад на тему «Уровни автономности ИИ: как сделать новый шаг?» на круглом столе «Автономный искусственный интеллект: от слов к делу».
Спикер расскажет:
Модераторы сессии:
👤 Владзимирский Антон Вячеславович — д.м.н., заместитель директора по научной работе, ГБУЗ «НПКЦ ДиТ ДЗМ»👤 Арзамасов Кирилл Михайлович — к.м.н., руководитель отдела медицинской информатики, радиомики и радиогеномики, ГБУЗ «НПКЦ ДиТ ДЗМ»
Организатор мероприятия — РМАНПО, сооргонизаторы — РАСУДМ, РОРР, Центр диагностики и телемедицины.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9
Мне стало интересно, кто меня читает. Интерактив! Кто вы?
Anonymous Poll
31%
ML 🧠
0%
HR 🫂
8%
Product manager 📈
4%
Project manager ⏳
2%
Sales 🪙
14%
Team Lead / Head / C-level 📞
1%
DA / DE 📊
15%
Разработчик 👨💻
25%
Другое (напишите в комментариях)
2💊3🗿1
Агенты
Для того, чтобы принимать любые решения - необходимо понимать имеющийся у тебя инструментарий. Это актуально для всех людей, но как оказывается уже и не только людей.
Современные подходы в ML, которые в первую очередь опираются на обобщающую способность LLM, меняют ландшафт продуктовых идей до неузнаваемости.
А если это мощный инструмент, который меняет рынок, то значит пора для тех моих читателей, которые еще пока не особо в курсе дела, раскрыть тему ИИ-Агентов.
Пост достаточно обзорный, с раскрытием общих принципов и идей, но даже если вы в теме - загляните в статью, в конце есть неплохие актуальные ссылки.
И раз уж я заговорил про рынок, которым вертят сейчас LLM, то далее у меня по планам обзор клевых стартапов, которые нестандартно применили языковые модели и стрельнули.
Так что оставайтесь со мной и зовите своих знакомых! И да, вас уже 200 человек, спасибо вам за поддержку!
А вот и сам пост про агентов!
P.S. Только я достиг 200 подписчиков, как сразу рекламу в этом посте у меня приобрел канал эйай ньюз, но канал крутой, упомянуть только в радость (ну вы и так все его читаете, что мне вам рассказывать).
@lechim_ai
Для того, чтобы принимать любые решения - необходимо понимать имеющийся у тебя инструментарий. Это актуально для всех людей, но как оказывается уже и не только людей.
Современные подходы в ML, которые в первую очередь опираются на обобщающую способность LLM, меняют ландшафт продуктовых идей до неузнаваемости.
А если это мощный инструмент, который меняет рынок, то значит пора для тех моих читателей, которые еще пока не особо в курсе дела, раскрыть тему ИИ-Агентов.
Пост достаточно обзорный, с раскрытием общих принципов и идей, но даже если вы в теме - загляните в статью, в конце есть неплохие актуальные ссылки.
И раз уж я заговорил про рынок, которым вертят сейчас LLM, то далее у меня по планам обзор клевых стартапов, которые нестандартно применили языковые модели и стрельнули.
Так что оставайтесь со мной и зовите своих знакомых! И да, вас уже 200 человек, спасибо вам за поддержку!
А вот и сам пост про агентов!
P.S. Только я достиг 200 подписчиков, как сразу рекламу в этом посте у меня приобрел канал эйай ньюз, но канал крутой, упомянуть только в радость (ну вы и так все его читаете, что мне вам рассказывать).
@lechim_ai
Telegraph
Агенты
Если бы меня попросили выделить одно ключевое отличие агентов от всего того, что было ранее - я бы назвал слово декомпозиция. Молодец, Илья, чего? Сейчас объясню. Давайте поймем, почему появление чего-то подобного было необходимым. Рассмотрим различные запросы…
🔥12👍3👏1🥴1🤣1🗿1😎1
Vibe-coding
Людям свойственно оправдывать свои действия, поэтому все 6 лет пребывания на ВМК МГУ я объяснял себе зачем я это делаю. Иногда я встречал людей с ФКН и тогда этот маховик запускался еще сильнее. Ты получаешь Фундаментальное образование говорил я себе. И с каждым годом я начинаю все лучше понимать, что это значит.
Мир все активнее начал говорить о vibe-coding, раньше мы делали и не знали что, теперь Карпатый дал этому "официальное" название. Сие лучше всего опишет цитата автора термина:
Если коротко - написание кода с использованием возможностей языковых моделей: от вас естественный язык, от модели язык программирования.
Подробнее о плюсах и минусах подхода можно почитать тут. А еще из этого же канала я узнал, что в нашем мире уже есть аероциклы. Мир, я не успеваю за тобой.
Понятие впервые было упомянуто в феврале 2025 года и мне стало интересно, что происходит в сообществе. Безусловно, в первую очередь, интересно какое влияние вайбование оказывает на рынок. Вот к чему меня привел мой ресерч.
AI-сотрудники:
Сундар Пичаи (Google):
Сатья Наделла (Microsoft):
Тут ничего и не добавишь. Если 30% кода ты генерируешь, и ты сможешь на дебаг и код-ревью тратить в 2 раза меньше времени, тогда ты можешь работать на 15% быстрее, или нанимать на 15% меньше сотрудников. Неделю назад вышла полноценная статья с эффектами. Короткий вывод - может и ускоряемся, но начинаем фрустрировать.
Стартапы:
Со слов YC сейчас 25% представленных у них компаний имеют кодовую базу на 95% сгенерированную ИИ.
Очередную волну хайпа получают no-code, low-code предложения. Например компания Supabase неделю назад подняла очередные $200 млн, позиционируя себя как сервис для "vibe database management".
Проверка гипотез выходит на абсолютно новый уровень. Сейчас любую идею можно собрать на коленке, оценить спрос, а потом уже решить идти ли туда. Появляется все больше компаний из одного предпринимателя, которые питчат не только идею продукта, но показывают и сам прототип, который собрали на выходных под ручку с LLM-based технологиями.
Я - юрист?
Сэм Альтман (OpenAI):
Марк Цукерберг (Meta):
Удивительно, как резко все меняется, еще вчера тру кодер это безбедная старость, а сейчас намечается тенденция стать фонарщиком.
К чему я это все. Я однажды осознал, что мои главные харды - это софты и умение решать задачи. Не python. И даже не достаточно глубокое знание того, что происходит с машинным обучением. В такие моменты начинаешь понимать, что такое фундаментальные знания, и что мне давали хорошая школа и университет. Поэтому я все скептичнее отношусь к понятию "прикладные знания" - все время есть риск, что скоро прикладывать будет некуда.
Что тут скрывать - я сам недавно навайбкодил небольшой внутренний продукт, у нас в компании активно распространяется Cursor - это правда становится новой реальностью и для небольших компаний, не только для FAANG.
P.S. У моего товарища 3 мая будет проходить открытый Vibe Coding workshop - доходчиво расскажет про инструменты и как начать клепать задачки, если вам интересно, то подробности тут.
@lechim_ai
Людям свойственно оправдывать свои действия, поэтому все 6 лет пребывания на ВМК МГУ я объяснял себе зачем я это делаю. Иногда я встречал людей с ФКН и тогда этот маховик запускался еще сильнее. Ты получаешь Фундаментальное образование говорил я себе. И с каждым годом я начинаю все лучше понимать, что это значит.
Мир все активнее начал говорить о vibe-coding, раньше мы делали и не знали что, теперь Карпатый дал этому "официальное" название. Сие лучше всего опишет цитата автора термина:
Существует новый вид программирования, который я называю "vibe coding", когда вы полностью отдаётесь вибрациям, принимаете экспоненциальный рост и забываете, что код вообще существует.
Если коротко - написание кода с использованием возможностей языковых моделей: от вас естественный язык, от модели язык программирования.
Подробнее о плюсах и минусах подхода можно почитать тут. А еще из этого же канала я узнал, что в нашем мире уже есть аероциклы. Мир, я не успеваю за тобой.
Понятие впервые было упомянуто в феврале 2025 года и мне стало интересно, что происходит в сообществе. Безусловно, в первую очередь, интересно какое влияние вайбование оказывает на рынок. Вот к чему меня привел мой ресерч.
AI-сотрудники:
Сундар Пичаи (Google):
«Более четверти кода в Google — теперь AI-generated».
Сатья Наделла (Microsoft):
«20–30% кода внутри Microsoft написаны AI» (цель — 95% к 2030 году).
Тут ничего и не добавишь. Если 30% кода ты генерируешь, и ты сможешь на дебаг и код-ревью тратить в 2 раза меньше времени, тогда ты можешь работать на 15% быстрее, или нанимать на 15% меньше сотрудников. Неделю назад вышла полноценная статья с эффектами. Короткий вывод - может и ускоряемся, но начинаем фрустрировать.
Стартапы:
Со слов YC сейчас 25% представленных у них компаний имеют кодовую базу на 95% сгенерированную ИИ.
Очередную волну хайпа получают no-code, low-code предложения. Например компания Supabase неделю назад подняла очередные $200 млн, позиционируя себя как сервис для "vibe database management".
Проверка гипотез выходит на абсолютно новый уровень. Сейчас любую идею можно собрать на коленке, оценить спрос, а потом уже решить идти ли туда. Появляется все больше компаний из одного предпринимателя, которые питчат не только идею продукта, но показывают и сам прототип, который собрали на выходных под ручку с LLM-based технологиями.
Я - юрист?
Сэм Альтман (OpenAI):
Инженерия будет выглядеть совсем по-другому к концу 2025 года — меньше обычных программистов, больше архитекторов.
Марк Цукерберг (Meta):
ИИ заменит миддл-инженеров — рутинный код будет автоматизирован.
Удивительно, как резко все меняется, еще вчера тру кодер это безбедная старость, а сейчас намечается тенденция стать фонарщиком.
К чему я это все. Я однажды осознал, что мои главные харды - это софты и умение решать задачи. Не python. И даже не достаточно глубокое знание того, что происходит с машинным обучением. В такие моменты начинаешь понимать, что такое фундаментальные знания, и что мне давали хорошая школа и университет. Поэтому я все скептичнее отношусь к понятию "прикладные знания" - все время есть риск, что скоро прикладывать будет некуда.
Что тут скрывать - я сам недавно навайбкодил небольшой внутренний продукт, у нас в компании активно распространяется Cursor - это правда становится новой реальностью и для небольших компаний, не только для FAANG.
P.S. У моего товарища 3 мая будет проходить открытый Vibe Coding workshop - доходчиво расскажет про инструменты и как начать клепать задачки, если вам интересно, то подробности тут.
@lechim_ai
🔥13💊2❤1🖕1🗿1
Opensource
Корпорации всегда ходят по грани между 10-страничным NDA и opensource. Компании ведут свои блоги, выкладывают внутренние фреймворки, датасеты, модели, и в тот же момент штрафуют своих сотрудников за случайно брошенную фразу о том, какой именно кофе у них на кухне. Я никогда не понимал, где проходит эта грань, но сегодня хочется поговорить не о моей безграмотности, а о том, зачем вообще эту грань искать и для чего существует opensource, по моим ощущениям.
Достаточно очевидные плюсы:
1. Формирование стандартов
Знаете ли вы, что Pytorch - разработка компании Meta? Ребята буквально сделали фреймворк, которым начал пользоваться весь мир. Выгода понятна: чем больше людей в мире использует ваши технологии, тем больше вы сможете переиспользовать наработок у себя внутри, а также, все приходящие сотрудники будут уже подготовлены к вашей инфраструктуре.
2. Имидж
Классным является то, что для opensource не существует географии, вы можете стать известны мировому сообществу, даже если вы еще не пытались выходить на зарубежный рынок. Если вы делитесь крутым инструментом - вы становитесь цитируемы, а значит к вам хотят устраиваться сотрудники, вам хотят инвесторы нести деньги, вас хотят заказчики. Чуть преувеличенно, но зачем нужна работа на имидж и так всем понятно.
3. Поиск багов
Люди очень любят делиться замечаниями. Обнародовав свои разработки вы можете "сэкономить" на тестировщиках. Фреймворк допишется, лики в данных найдутся, список как хакнуть модель будет предоставлен - все благодаря сообществу, которому вы даже не платите.
Менее очевидные плюсы:
1. Инвестиция
Кажется, что этот подход актуален для более крупных компаний. Бигтех делится технологией, которую сложно разработать малому бизнесу. Далее формируется большое количество стартапов, которые берут эту технологию в качестве центральной. Большая часть умирает (у стартапов так всегда), но далее авторы технологии возвращаются и скупают подобные стартапы или просто нанимают команду (хороший пример - Stability с их Stable Diffusion). Получаются такие проекты на аутсорсе. Можно инвестировать деньги ради новых идей, а можно технологии (ну другая форма денег) ради идей.
2. Стратегическое оружие
Иногда opensource это борьба с монополизацией рынка. Появление LLaMA - это буквально ответ закрытой политике OpenAI, полностью захватившей рынок в конце 2022 года. Тем самым подрывается уникальность коммерческих предложений, люди не обязаны сидеть на крючке одной экосистемы.
3. Продавай недвижимость, а не чизбургеры
Google открывал в своей время TensorFlow для того, чтобы повысить спрос на свои облачные сервисы, такой подход распространен и на нашем рынке. Стимулирование вашего рынка стимулирует количество денег на нем, которые в конечном итоге идут к вам в карман.
Есть и другие плюсы для компании контрибьютить в opensource, сегодня хотел выделить именно эти. Скажу по секрету, мы в Третьем Мнении тоже сейчас движемся в этом направлении. Конечно, всегда нужно здраво взвешивать, чем ты делишься с сообществом, а значит и с конкурентами, но в целом мне лично очень импонирует коллаборативный подход. А также хочется выстраивать команду так, чтобы даже в случае полной открытости — когда вы делитесь всеми наработками — вы оставались на два шага впереди остальных.
P.S. Хочу начать разбавлять мои лонгриды репостами/новостями и лайфстайлом, было бы это вам интересно - поделитесь мыслями. Пока я зажат вокруг одного формата, кажется его можно оживить, еще и повысив регулярность контента.
@lechim_ai
Корпорации всегда ходят по грани между 10-страничным NDA и opensource. Компании ведут свои блоги, выкладывают внутренние фреймворки, датасеты, модели, и в тот же момент штрафуют своих сотрудников за случайно брошенную фразу о том, какой именно кофе у них на кухне. Я никогда не понимал, где проходит эта грань, но сегодня хочется поговорить не о моей безграмотности, а о том, зачем вообще эту грань искать и для чего существует opensource, по моим ощущениям.
Достаточно очевидные плюсы:
1. Формирование стандартов
Знаете ли вы, что Pytorch - разработка компании Meta? Ребята буквально сделали фреймворк, которым начал пользоваться весь мир. Выгода понятна: чем больше людей в мире использует ваши технологии, тем больше вы сможете переиспользовать наработок у себя внутри, а также, все приходящие сотрудники будут уже подготовлены к вашей инфраструктуре.
2. Имидж
Классным является то, что для opensource не существует географии, вы можете стать известны мировому сообществу, даже если вы еще не пытались выходить на зарубежный рынок. Если вы делитесь крутым инструментом - вы становитесь цитируемы, а значит к вам хотят устраиваться сотрудники, вам хотят инвесторы нести деньги, вас хотят заказчики. Чуть преувеличенно, но зачем нужна работа на имидж и так всем понятно.
3. Поиск багов
Люди очень любят делиться замечаниями. Обнародовав свои разработки вы можете "сэкономить" на тестировщиках. Фреймворк допишется, лики в данных найдутся, список как хакнуть модель будет предоставлен - все благодаря сообществу, которому вы даже не платите.
Менее очевидные плюсы:
1. Инвестиция
Кажется, что этот подход актуален для более крупных компаний. Бигтех делится технологией, которую сложно разработать малому бизнесу. Далее формируется большое количество стартапов, которые берут эту технологию в качестве центральной. Большая часть умирает (у стартапов так всегда), но далее авторы технологии возвращаются и скупают подобные стартапы или просто нанимают команду (хороший пример - Stability с их Stable Diffusion). Получаются такие проекты на аутсорсе. Можно инвестировать деньги ради новых идей, а можно технологии (ну другая форма денег) ради идей.
2. Стратегическое оружие
Иногда opensource это борьба с монополизацией рынка. Появление LLaMA - это буквально ответ закрытой политике OpenAI, полностью захватившей рынок в конце 2022 года. Тем самым подрывается уникальность коммерческих предложений, люди не обязаны сидеть на крючке одной экосистемы.
3. Продавай недвижимость, а не чизбургеры
Google открывал в своей время TensorFlow для того, чтобы повысить спрос на свои облачные сервисы, такой подход распространен и на нашем рынке. Стимулирование вашего рынка стимулирует количество денег на нем, которые в конечном итоге идут к вам в карман.
Есть и другие плюсы для компании контрибьютить в opensource, сегодня хотел выделить именно эти. Скажу по секрету, мы в Третьем Мнении тоже сейчас движемся в этом направлении. Конечно, всегда нужно здраво взвешивать, чем ты делишься с сообществом, а значит и с конкурентами, но в целом мне лично очень импонирует коллаборативный подход. А также хочется выстраивать команду так, чтобы даже в случае полной открытости — когда вы делитесь всеми наработками — вы оставались на два шага впереди остальных.
P.S. Хочу начать разбавлять мои лонгриды репостами/новостями и лайфстайлом, было бы это вам интересно - поделитесь мыслями. Пока я зажат вокруг одного формата, кажется его можно оживить, еще и повысив регулярность контента.
@lechim_ai
🔥17❤🔥5👍2🥱2🤣1🗿1