Недавно заходил в Decathlon за покупками спортивной снаряги. На кассе спросили телефон и почту, который называть я отказался. Выяснилось, что обязательным условием продажи является участие в их "программе лояльности". После такого заявления какая-либо лояльность у меня сразу пропадает.
В итоге свои данные оставила жена, которая не видит проблем с распространением таких данных. А я ушел с мыслью, что ценность данных не всем так очевидна.
В итоге свои данные оставила жена, которая не видит проблем с распространением таких данных. А я ушел с мыслью, что ценность данных не всем так очевидна.
На днях со знакомым обсуждали вопрос про переход его в другую компанию на руководящую позицию. Он поинтересовался, стоит ли ему переходить и какие могут быть плюсы/минусы. Рассуждение ушло в сторону определения карьерных целей и оптимизации метрики счастья. Я рассказал, как иногда бывает больно работать в компании с хаотичными процессами, размытой ответственностью и огромным легаси. Предложил ему, как будущему руководителю, оценивать возможность внедрения определенных изменений в компании, куда он собирался переходить.
И тут он меня спросил: "А откуда ты знаешь как надо делать и как делать не надо?".
Вопрос оказался не из простых и уходил в глубины моего менеджерского опыта, бизнеса и карьеры. Быстрого ответа я на этот вопрос не нашел и, наверно, все еще не могу четко на него ответить. Но почему-то у меня сложилось ощущение, что эта область знаний со мной настолько давно, что уже не вспомнить откуда она взялась.
И тут он меня спросил: "А откуда ты знаешь как надо делать и как делать не надо?".
Вопрос оказался не из простых и уходил в глубины моего менеджерского опыта, бизнеса и карьеры. Быстрого ответа я на этот вопрос не нашел и, наверно, все еще не могу четко на него ответить. Но почему-то у меня сложилось ощущение, что эта область знаний со мной настолько давно, что уже не вспомнить откуда она взялась.
Примерно каждые полгода я пытаюсь понять направление своей карьеры и думаю о том, как развиваться дальше. Сейчас как раз такой период "ревью". В прошлый период составил план-капкан, он же Personal Development Plan. К таким планам всегда относился скептически, но в них есть ценная идея - балансировка своих усилий между направлениями.
Я думал, что знаю свой план развития. Это ощущение обманчиво и относится к разряду тех, когда ты вроде бы знаешь, но это не точно. Чтобы все-таки зафиксировать этот план, решено было его записать.
В целом любой план развития - это компромисс между сферами развития и доступными умственными ресурсами. Если подойти к этому процессу, как к инвестициям умственного ресурса, то на ум приходит подход из современной портфельной теории. Идея в основе теории - набираем в портфель такие инструменты, которые в сумме дают наилучшее соотношение доходность/риск.
Так и с личным развитием - балансируем усилия по сферам с учетом вероятности освоить тот самый курс "<название_крутого_курса>" и будущей доходности этих знаний.
Звучит конечно классно, но возникает две проблемы.
Во-первых, эта самая вероятность меняется во времени от множества личных обстоятельств и оценить эту вероятность на старте весьма непросто.
Во-вторых, спрогнозировать будущую доходность знаний тоже непросто.
Я думал, что знаю свой план развития. Это ощущение обманчиво и относится к разряду тех, когда ты вроде бы знаешь, но это не точно. Чтобы все-таки зафиксировать этот план, решено было его записать.
В целом любой план развития - это компромисс между сферами развития и доступными умственными ресурсами. Если подойти к этому процессу, как к инвестициям умственного ресурса, то на ум приходит подход из современной портфельной теории. Идея в основе теории - набираем в портфель такие инструменты, которые в сумме дают наилучшее соотношение доходность/риск.
Так и с личным развитием - балансируем усилия по сферам с учетом вероятности освоить тот самый курс "<название_крутого_курса>" и будущей доходности этих знаний.
Звучит конечно классно, но возникает две проблемы.
Во-первых, эта самая вероятность меняется во времени от множества личных обстоятельств и оценить эту вероятность на старте весьма непросто.
Во-вторых, спрогнозировать будущую доходность знаний тоже непросто.
Разговаривали с коллегой про А/В тесты с синтетическим контролем. Погрузился в статью "Using Synthetic Controls:
Feasibility, Data Requirements, and Methodological Aspects " , у нее 40+ страниц текста, так что на освоение стоит закладывать время. Если дойдут руки, попробую сделать реализацию в коде. Статья интересная и, на удивление, не самая сложная.
Некоторые идеи из нее ниже 👇
Feasibility, Data Requirements, and Methodological Aspects " , у нее 40+ страниц текста, так что на освоение стоит закладывать время. Если дойдут руки, попробую сделать реализацию в коде. Статья интересная и, на удивление, не самая сложная.
Некоторые идеи из нее ниже 👇
Синтетический контроль нужен, когда у нас нет возможности провести полноценный А/В тест из-за отсутствия контрольной группы. Можно сделать контрольную группу искусственно.
По сути с помощью некоторого набора семплов и регрессии с ограничениями на веса можно создать взвешенное среднее из этих семплов, которое по своим стат. параметрам будет удовлетворять условиям контрольной группы.
За счет свойств весов (веса положительны, суммируются в единицу, должны быть разряжены) все становится интерпретируемым с вероятностной точки зрения. Зная ошибку регрессии, можно контролировать стат. значимое отличие групп и надежность теста.
Все это возможно при условии качественной модели, которая дает нормальную нулевую ошибку. Примерно 5 страниц уделено вопросу, чем опасно смещение и что в итоге делать: грамотно отбирать в трейн семплы, которые по своим наблюдаемым или не наблюдаемым характеристикам близки к таргету.
Идея не новая, но если про нее забыть, можно добиться переобучения и даже не заметить этого.
По сути с помощью некоторого набора семплов и регрессии с ограничениями на веса можно создать взвешенное среднее из этих семплов, которое по своим стат. параметрам будет удовлетворять условиям контрольной группы.
За счет свойств весов (веса положительны, суммируются в единицу, должны быть разряжены) все становится интерпретируемым с вероятностной точки зрения. Зная ошибку регрессии, можно контролировать стат. значимое отличие групп и надежность теста.
Все это возможно при условии качественной модели, которая дает нормальную нулевую ошибку. Примерно 5 страниц уделено вопросу, чем опасно смещение и что в итоге делать: грамотно отбирать в трейн семплы, которые по своим наблюдаемым или не наблюдаемым характеристикам близки к таргету.
Идея не новая, но если про нее забыть, можно добиться переобучения и даже не заметить этого.
#MLOps
Начинаю серию постов о качественной разработке ML приложений.
MLOps о том, как писать код, чтобы было не стыдно показать его коллегам и не позориться на весь интернет 🌐
Большинство крутых проектов не делается в одиночку. Командная разработка - сложная штука с точки зрения организации команды. Ведь когда ты один, никто не сделает тебе ревью, не укажет на качество кода и разные небольшие "и-так-сойдет".
Команда дисциплинирует. Чтобы настроить ее работу, нужно учитывать амбиции коллег, разные хард и софт скилы внутри команды, доступные ресурсы для разработки и много других факторов.
Честно признаюсь - несколько лет назад у меня был шанс построить идеальную команду, но в то время задача оказалась не по плечу. С тех пор набрался опыта и хочу им поделиться.
Первый пост на тему шаблонизации проекта будет на следующей неделе.
▶️ Для старта поделюсь ресурсом создания вашей MLOps архитектуры.
Начинаю серию постов о качественной разработке ML приложений.
MLOps о том, как писать код, чтобы было не стыдно показать его коллегам и не позориться на весь интернет 🌐
Большинство крутых проектов не делается в одиночку. Командная разработка - сложная штука с точки зрения организации команды. Ведь когда ты один, никто не сделает тебе ревью, не укажет на качество кода и разные небольшие "и-так-сойдет".
Команда дисциплинирует. Чтобы настроить ее работу, нужно учитывать амбиции коллег, разные хард и софт скилы внутри команды, доступные ресурсы для разработки и много других факторов.
Честно признаюсь - несколько лет назад у меня был шанс построить идеальную команду, но в то время задача оказалась не по плечу. С тех пор набрался опыта и хочу им поделиться.
Первый пост на тему шаблонизации проекта будет на следующей неделе.
▶️ Для старта поделюсь ресурсом создания вашей MLOps архитектуры.
#тру_стори
Чудо-вакансия
Недавно в чате Питерского ОДС появилось сообщение с необычной вакансией. Ребята искали ML-инженера, который мог бы для них оценивать проекты с точки зрения их бизнес-потенциала и технической инновационности «на предмет халтура внутри или нет». Все, что в кавычках - дословно, цитат дальше будет много.
Хотят найти «звезду ИИ-аналитики». Первый раз слышу такое название, похоже это придумка талантливого и крайне эффективного менеджера. Само собой, обещают чемодан денег такому уникальному человеку.
Из требований:
1. Быть сильным в рисерче, а именно смочь «прочитать и понять статью по ИИ».
2. Хотеть самому писать статьи или обзоры, что «подтвердить лекциями на ютубе и личным блогом».
3. Уметь понять, что продукт на основе API ChatGPT не прорывной, потому что «его любой кодер повторит».
Ребята «понимают, что требования сильные, но и задачи сложные».
Есть ощущение, что вакансию они закрывать будут долго.
Чудо-вакансия
Недавно в чате Питерского ОДС появилось сообщение с необычной вакансией. Ребята искали ML-инженера, который мог бы для них оценивать проекты с точки зрения их бизнес-потенциала и технической инновационности «на предмет халтура внутри или нет». Все, что в кавычках - дословно, цитат дальше будет много.
Хотят найти «звезду ИИ-аналитики». Первый раз слышу такое название, похоже это придумка талантливого и крайне эффективного менеджера. Само собой, обещают чемодан денег такому уникальному человеку.
Из требований:
1. Быть сильным в рисерче, а именно смочь «прочитать и понять статью по ИИ».
2. Хотеть самому писать статьи или обзоры, что «подтвердить лекциями на ютубе и личным блогом».
3. Уметь понять, что продукт на основе API ChatGPT не прорывной, потому что «его любой кодер повторит».
Ребята «понимают, что требования сильные, но и задачи сложные».
Есть ощущение, что вакансию они закрывать будут долго.
#инфо
Открытый курс по MLOps
По чистому совпадению на ods.ai сегодня стартует бесплатный курс по MLOps. Я в составе команды курса выполняю роль ментора/члена_жюри/человека_оркестра.
Авторы курса - опытные ML-инженеры, у которых есть чему поучиться. Курс построен не просто на контенте видео-лекций. Формат предполагает много практической работы в команде и будет полезен как начинающим, так и продолжающим ML-специалистам, разрабам и всем, кто имеет отношение к данным. Стартует курс сегодня в 18:00 МСК, до старта можно выбрать проект из доступных и присоединиться к его разработке. В конце курса предполагается защита проектов.
По опыту прошлогоднего курса - те, кто закончили этот курс, реально выросли по скиллам. Хотя для многих это было непросто.
На том же сайте можно найти прошлый выпуск курса, чтобы понять примерный уровень материала и загрузку. Удачи всем, кто решится на это приключение 🚀
Открытый курс по MLOps
По чистому совпадению на ods.ai сегодня стартует бесплатный курс по MLOps. Я в составе команды курса выполняю роль ментора/члена_жюри/человека_оркестра.
Авторы курса - опытные ML-инженеры, у которых есть чему поучиться. Курс построен не просто на контенте видео-лекций. Формат предполагает много практической работы в команде и будет полезен как начинающим, так и продолжающим ML-специалистам, разрабам и всем, кто имеет отношение к данным. Стартует курс сегодня в 18:00 МСК, до старта можно выбрать проект из доступных и присоединиться к его разработке. В конце курса предполагается защита проектов.
По опыту прошлогоднего курса - те, кто закончили этот курс, реально выросли по скиллам. Хотя для многих это было непросто.
На том же сайте можно найти прошлый выпуск курса, чтобы понять примерный уровень материала и загрузку. Удачи всем, кто решится на это приключение 🚀
#тру_стори
Был у меня опыт внедрения ML в один проект возрастом чуть больше 15 лет. В проекте было больше 20 тысяч строк кода на разных языках, части проекта при передаче от разных владельцев терялись, что-то ломалось. В общем самый настоящий кошмар программиста.
Над проектом трудилось несколько команд в совокупности из 70 человек. И вот мне, единственному ML-инженеру, была поставлена задача - внедрить сервис на основе ML.
Первая проблема была в том, что даже аналитики не знали, какие данные собираются. Пришлось вместе с ними выстроить хотя бы базовый сбор юзерских событий. Дальше выяснилось, что данных слишком много для экспериментальной машины, которую мне выделили. Потом возникли проблемы с интеграциями решения, настройкой процессов вокруг модели и еще целый ворох мелких организационных проблем.
Весь этот вандализм длился чуть больше 8 месяцев.
Все это время меня не покидала мысль, что проект двигается не благодаря, а вопреки разработчикам.
Почему так происходит? Думается, что из-за стадии жизни проекта. По сути проект на этапе «дойная корова», а это подпитывает нежелание что-то менять со стороны всех участников.
В таких случаях создают специальную команду изменений, куда включают наиболее заинтересованных в развитии проекта людей. Их задача - создать атмосферу стартапа и двигать проект сильно быстрее.
Был у меня опыт внедрения ML в один проект возрастом чуть больше 15 лет. В проекте было больше 20 тысяч строк кода на разных языках, части проекта при передаче от разных владельцев терялись, что-то ломалось. В общем самый настоящий кошмар программиста.
Над проектом трудилось несколько команд в совокупности из 70 человек. И вот мне, единственному ML-инженеру, была поставлена задача - внедрить сервис на основе ML.
Первая проблема была в том, что даже аналитики не знали, какие данные собираются. Пришлось вместе с ними выстроить хотя бы базовый сбор юзерских событий. Дальше выяснилось, что данных слишком много для экспериментальной машины, которую мне выделили. Потом возникли проблемы с интеграциями решения, настройкой процессов вокруг модели и еще целый ворох мелких организационных проблем.
Весь этот вандализм длился чуть больше 8 месяцев.
Все это время меня не покидала мысль, что проект двигается не благодаря, а вопреки разработчикам.
Почему так происходит? Думается, что из-за стадии жизни проекта. По сути проект на этапе «дойная корова», а это подпитывает нежелание что-то менять со стороны всех участников.
В таких случаях создают специальную команду изменений, куда включают наиболее заинтересованных в развитии проекта людей. Их задача - создать атмосферу стартапа и двигать проект сильно быстрее.
#MLOps
Как мы начинаем писать код? Обычно примерно в голове прикидываем структуру модулей и начинаем писать. Я так делал и иногда продолжаю делать сейчас. Со временем структура кода может меняться, иногда весьма сильно, что доставляет много головной боли. В какой-то момент я пришел собственному "скелету" кода, а потом наткнулся на сookiecutter.
Ниже будет разбор этого инструмента на примере DS-проекта 👇
Как мы начинаем писать код? Обычно примерно в голове прикидываем структуру модулей и начинаем писать. Я так делал и иногда продолжаю делать сейчас. Со временем структура кода может меняться, иногда весьма сильно, что доставляет много головной боли. В какой-то момент я пришел собственному "скелету" кода, а потом наткнулся на сookiecutter.
Ниже будет разбор этого инструмента на примере DS-проекта 👇
Вот шаблон data-science-проекта.
Применил этот шаблон в командном проекте, что сильно упростило разработку. К сожалению, шаблон заточен под DS-проект, поэтому структурой проекта авторы решают проблему воспроизводимости анализа и потоков данных, но не проблему production-ready кода (это было бы слишком). Прелесть шаблона в том, что мы можем на его основе сделать свой с блекджеком и эндпоинтами.
Концепция этого шаблона следует практикам бекенд разработки. Например, при работе с django не возникает вопросов о том, куда поместить тот или иной модуль. Сама структура кода django-проекта позволяет не думать о взаимозависимостях с другими модулями. Хорошо организованный код имеет тенденцию к самодокументированию, ведь его структура обеспечивает контекст восприятия без особых когнитивных расходов.
За нас написали полезный функционал: есть автогенерация документации на основе Sphinx, файлы сетапа и настроек проекта, шаблоны модулей обработки данных.
С точки зрения потоков данных шаблон построен на идеи "Analysis is a DAG", что как раз решает проблему воспроизводимости.
Больше того, уже существует множество шаблонов для самых разных сервисов, которые можно найти по запросу "cookiecutter <твой_сервис>".
К этому инструменту у меня не возникло аллергии, поэтому советую попробовать.
В комментариях можно поделиться болью про организацию кода в твоем проекте. Говорят, от этого становится легче 🫢
Применил этот шаблон в командном проекте, что сильно упростило разработку. К сожалению, шаблон заточен под DS-проект, поэтому структурой проекта авторы решают проблему воспроизводимости анализа и потоков данных, но не проблему production-ready кода (это было бы слишком). Прелесть шаблона в том, что мы можем на его основе сделать свой с блекджеком и эндпоинтами.
Концепция этого шаблона следует практикам бекенд разработки. Например, при работе с django не возникает вопросов о том, куда поместить тот или иной модуль. Сама структура кода django-проекта позволяет не думать о взаимозависимостях с другими модулями. Хорошо организованный код имеет тенденцию к самодокументированию, ведь его структура обеспечивает контекст восприятия без особых когнитивных расходов.
За нас написали полезный функционал: есть автогенерация документации на основе Sphinx, файлы сетапа и настроек проекта, шаблоны модулей обработки данных.
С точки зрения потоков данных шаблон построен на идеи "Analysis is a DAG", что как раз решает проблему воспроизводимости.
Больше того, уже существует множество шаблонов для самых разных сервисов, которые можно найти по запросу "cookiecutter <твой_сервис>".
К этому инструменту у меня не возникло аллергии, поэтому советую попробовать.
В комментариях можно поделиться болью про организацию кода в твоем проекте. Говорят, от этого становится легче 🫢
drivendata.github.io
Cookecutter Data Science
🙈 В пятницу вечером начинать не стоит...
Топ-5 вопросов, которые нужно задать перед началом работы над проектом.
Опытные разработчики задают хорошо структурированные вопросы, без лишних слов и с достаточным количеством исходных данных. Хороший вопрос во многом похож на красивый код. На собеседовании и во время испытательного срока работодатель по вашим вопросам оценивает ваш ход мысли, умение анализировать, подход к обработке задач. Ваши вопросы — это второе портфолио, способ продемонстрировать себя и свои навыки, подход к решению задач и проблем.
Вопросы помогают сэкономить время. Да, перед тем как задавать вопросы, важно уделить время самостоятельному поиску. Но здесь важно не увлечься и не потратить весь день на то, чтобы найти ответ на один вопрос. Если через пару часов решение не нашлось — самое время спросить.
Индустрия быстро растёт и меняется. На протяжении всей карьеры вам придётся задавать вопросы тем, кто в курсе новых технологий. Огромную часть вашего времени будет занимать общение с коллегами. Помните - нанимают за харды, увольняют за софты.
Содержательный вопрос показывает тому, кто его прочитал, что вы столкнулись с проблемой, пробовали решать её самостоятельно, подумали — и только потом пришли за помощью. Они выстроены так, что адресат быстро понимает, в чём проблема: ему удобно читать и отвечать на такой вопрос.
Например, вы сообщаете, что ознакомились с документацией к проекту, посмотрели код в репозитории, посмотрели ТЗ на задачу и предлагаете решение. После этого стоит спросить:
1. Насколько быстро и безболезненно предложенное решение может быть встроено в проект? Нужно ли что-то в нем кардинально изменить?
2. Какие есть ограничения по времени и памяти для работы кода?
3. Какие потоки данных будут затронуты моим решением, что я должен знать про данные?
4. Существует ли метрика, которую мне нужно улучшить через выполнение таски? Как она рассчитывается?
5. Что предусмотрено в Definition of Done для задачи?
На все эти вопросы сначала стоит ответить самостоятельно, потом подробно расписать детали в черновике или воспользоваться методом rubber duck debugging. Если предыдущие шаги не добавили ясности, стоит спросить более опытного коллегу или постановщика задачи.
Зачастую правильная формулировка вопроса содержит как минимум половину ответа.
Топ-5 вопросов, которые нужно задать перед началом работы над проектом.
Опытные разработчики задают хорошо структурированные вопросы, без лишних слов и с достаточным количеством исходных данных. Хороший вопрос во многом похож на красивый код. На собеседовании и во время испытательного срока работодатель по вашим вопросам оценивает ваш ход мысли, умение анализировать, подход к обработке задач. Ваши вопросы — это второе портфолио, способ продемонстрировать себя и свои навыки, подход к решению задач и проблем.
Вопросы помогают сэкономить время. Да, перед тем как задавать вопросы, важно уделить время самостоятельному поиску. Но здесь важно не увлечься и не потратить весь день на то, чтобы найти ответ на один вопрос. Если через пару часов решение не нашлось — самое время спросить.
Индустрия быстро растёт и меняется. На протяжении всей карьеры вам придётся задавать вопросы тем, кто в курсе новых технологий. Огромную часть вашего времени будет занимать общение с коллегами. Помните - нанимают за харды, увольняют за софты.
Содержательный вопрос показывает тому, кто его прочитал, что вы столкнулись с проблемой, пробовали решать её самостоятельно, подумали — и только потом пришли за помощью. Они выстроены так, что адресат быстро понимает, в чём проблема: ему удобно читать и отвечать на такой вопрос.
Например, вы сообщаете, что ознакомились с документацией к проекту, посмотрели код в репозитории, посмотрели ТЗ на задачу и предлагаете решение. После этого стоит спросить:
1. Насколько быстро и безболезненно предложенное решение может быть встроено в проект? Нужно ли что-то в нем кардинально изменить?
2. Какие есть ограничения по времени и памяти для работы кода?
3. Какие потоки данных будут затронуты моим решением, что я должен знать про данные?
4. Существует ли метрика, которую мне нужно улучшить через выполнение таски? Как она рассчитывается?
5. Что предусмотрено в Definition of Done для задачи?
На все эти вопросы сначала стоит ответить самостоятельно, потом подробно расписать детали в черновике или воспользоваться методом rubber duck debugging. Если предыдущие шаги не добавили ясности, стоит спросить более опытного коллегу или постановщика задачи.
Зачастую правильная формулировка вопроса содержит как минимум половину ответа.
Wikipedia
Метод утёнка
психологический метод решения задачи
#MLOps
Если кто еще не слышал, то на прошлой неделе был опубликован код системы рекомендаций твиттера. Сейчас вокруг меня много говорят про разные особенности этой системы - закладки от гос.органов или политическую направленность. Пост не об этом.
ML-часть этой системы тоже стала открытой, ее можно найти здесь, а заодно посмотреть на практики работы с кодом. Ниже некоторые мысли на этот счет 👇👇👇
Если кто еще не слышал, то на прошлой неделе был опубликован код системы рекомендаций твиттера. Сейчас вокруг меня много говорят про разные особенности этой системы - закладки от гос.органов или политическую направленность. Пост не об этом.
ML-часть этой системы тоже стала открытой, ее можно найти здесь, а заодно посмотреть на практики работы с кодом. Ниже некоторые мысли на этот счет 👇👇👇
Репозиторий интересен для изучения по нескольким причинам.
Весь код написан на python. Мне казалось, что некоторые части такой системы могли быть написаны на С++ из-за потребности в быстродействии.
Разработчики написали собственные тулзы для многих привычных вещей (логгер, env, метрики, оптимизаторы и тд), хотя можно было бы воспользоваться библиотеками. Такой подход можно понять - код контролируют разработчики твиттера, в отличии от библиотек.
Интересная организация кода. Тесты расположены рядом с модулем, который тестируется, попробую в своей практике такую организацию. Конфиги на разных уровнях дополняют друг друга, хотя для меня привычнее иметь 1-2 хорошо структурированных конфига. Репозиторий в целом организован тяжеловесно. Чувствуется, что забота о качестве кода - один из основных приоритетов в разработке.
Репозиторий дополнили ссылкой на статью с описанием алгоритма построения и использования эмбеддингов разных сущностей соцсети для рекомендаций и ранжирования. Статья на 8 страниц может быть полезна для тех, кто интересуется графовыми нейронками. В ней есть разбор самого алгоритма, сравнение по бенчмаркам с SOTA-решениями и некоторые математические выкладки.
Весь код написан на python. Мне казалось, что некоторые части такой системы могли быть написаны на С++ из-за потребности в быстродействии.
Разработчики написали собственные тулзы для многих привычных вещей (логгер, env, метрики, оптимизаторы и тд), хотя можно было бы воспользоваться библиотеками. Такой подход можно понять - код контролируют разработчики твиттера, в отличии от библиотек.
Интересная организация кода. Тесты расположены рядом с модулем, который тестируется, попробую в своей практике такую организацию. Конфиги на разных уровнях дополняют друг друга, хотя для меня привычнее иметь 1-2 хорошо структурированных конфига. Репозиторий в целом организован тяжеловесно. Чувствуется, что забота о качестве кода - один из основных приоритетов в разработке.
Репозиторий дополнили ссылкой на статью с описанием алгоритма построения и использования эмбеддингов разных сущностей соцсети для рекомендаций и ранжирования. Статья на 8 страниц может быть полезна для тех, кто интересуется графовыми нейронками. В ней есть разбор самого алгоритма, сравнение по бенчмаркам с SOTA-решениями и некоторые математические выкладки.
#тру_стори
На выходных встречался с другом, который достаточно далек от мира IT - он строитель. Примерно за 30 минут разговора он узнал про ChatGPT и пережил революцию взглядов.
Первые 10 минут он удивлялся и не верил мне, следующие 10 минут восхищался и даже придумал где в его области можно применить эту чудо-машину.
Последние 10 минут глубоко задумался и начал грустить - даже его область в будущем может быть затронута.
В конце он сказал фразу: «у нас такие штуки не приживутся, ведь почти весь государственный аппарат может быть автоматизирован, а значит на всех уровнях будет сопротивление». Интересный взгляд на ChatGPT.
Похоже друг пока на стадии отрицания.
На выходных встречался с другом, который достаточно далек от мира IT - он строитель. Примерно за 30 минут разговора он узнал про ChatGPT и пережил революцию взглядов.
Первые 10 минут он удивлялся и не верил мне, следующие 10 минут восхищался и даже придумал где в его области можно применить эту чудо-машину.
Последние 10 минут глубоко задумался и начал грустить - даже его область в будущем может быть затронута.
В конце он сказал фразу: «у нас такие штуки не приживутся, ведь почти весь государственный аппарат может быть автоматизирован, а значит на всех уровнях будет сопротивление». Интересный взгляд на ChatGPT.
Похоже друг пока на стадии отрицания.
#карьера
Про связь зарплат и объема работы.
Существует мнение, что чем усерднее трудишься, тем больше зарабатываешь.
С одной стороны я согласен с этим: усерднее трудишься -> делаешь больше задач -> быстрее растешь по скилам -> больше денег.
С другой стороны в этой логике есть изъяны, о них можно прочитать ниже ⬇️
Про связь зарплат и объема работы.
Существует мнение, что чем усерднее трудишься, тем больше зарабатываешь.
С одной стороны я согласен с этим: усерднее трудишься -> делаешь больше задач -> быстрее растешь по скилам -> больше денег.
С другой стороны в этой логике есть изъяны, о них можно прочитать ниже ⬇️
Во-первых, нет гарантии, что каждый из этапов этой цепи двигает тебя вперед. Ты можешь делать больше задач, но никак не вырастишь, если твоя задача - переложить эксельку из одной папки в другую. Подобные примеры можно найти на каждом из звеньев цепи.
Во-вторых, размер дохода в целом определяется отраслью рынка труда. Не зря его называют рынком - на немпочти везде есть спрос и предложение. Рынки бывают разные и не всегда они конкурентные по модели биржевых торгов. Есть еще 3 вида рынков с перекосом спроса и предложения. Спасибо немногим исследованиям на эту тему, что дают хотя бы общее представление о рынке.
В-третьих, закрытость информации о зарплатах создает идеальную ситуацию ценовой дискриминации - когда коллега по цеху с точно такими же задачами/навыками/зоной_ответственности может получать в 1.5 раза больше тебя.
Есть много нюансов, но если грубо, то размер доходов весьма посредственно связан с объемом работы. Утверждение применимо для любых областей, не только IT.
Все это означает, что мы в мире IT-дикого-запада, где самый большой кусок пирога достается самому зубастому. Или точнее сказать наиболее прокаченному по софт-скилам?
В комментариях можно высказать аргументы за любую из позиций.
Во-вторых, размер дохода в целом определяется отраслью рынка труда. Не зря его называют рынком - на нем
В-третьих, закрытость информации о зарплатах создает идеальную ситуацию ценовой дискриминации - когда коллега по цеху с точно такими же задачами/навыками/зоной_ответственности может получать в 1.5 раза больше тебя.
Есть много нюансов, но если грубо, то размер доходов весьма посредственно связан с объемом работы. Утверждение применимо для любых областей, не только IT.
Все это означает, что мы в мире IT-дикого-запада, где самый большой кусок пирога достается самому зубастому. Или точнее сказать наиболее прокаченному по софт-скилам?
В комментариях можно высказать аргументы за любую из позиций.
#инфо
Все мечтали себе получить Джарвиса?
В Майкрософт неделю назад опубликовали статью, вместе с ней и репозиторий с сервисом под названием Джарвис. Репозиторий еще в разработке, но сама идея уже впечатляет.
Предлагается использовать ChatGPT для обработки входящих запросов на выполнение задач, а сами задачи отдавать на аутсорс другим моделям. Эти модели брать из публичного хаба Hugging Face Hub, в котором храняться тысячи разных моделей со своими специализациями: распознавание или генерация картинок, текстов, работа со звуком и много всего еще.
Сейчас у сервиса есть UI, для запуска нужны
Надеюсь скоро появится возможность внедрить этот сервис в рабочие задачи. Интересно будет попробовать это сделать в облаке и посмотреть, сколько денег съест этот сервис.
Все мечтали себе получить Джарвиса?
В Майкрософт неделю назад опубликовали статью, вместе с ней и репозиторий с сервисом под названием Джарвис. Репозиторий еще в разработке, но сама идея уже впечатляет.
Предлагается использовать ChatGPT для обработки входящих запросов на выполнение задач, а сами задачи отдавать на аутсорс другим моделям. Эти модели брать из публичного хаба Hugging Face Hub, в котором храняться тысячи разных моделей со своими специализациями: распознавание или генерация картинок, текстов, работа со звуком и много всего еще.
Сейчас у сервиса есть UI, для запуска нужны
openai.key и huggingface.token. После настройки конфигов поднять сервис не составляет большого труда. Для режима работы на максималках нужно 42+ ГБ RAM и, подозреваю, нормально настроить GPU для инференса моделей. Надеюсь скоро появится возможность внедрить этот сервис в рабочие задачи. Интересно будет попробовать это сделать в облаке и посмотреть, сколько денег съест этот сервис.