Forwarded from Kali Novskaya
🌸METRики хайпа: найти экспонентциальный рост любой ценой🌸
#nlp #про_nlp #nlp_papers
На прошлой неделе вышел анализ от METR (Model Evaluation & Threat Research) — независимой организации оценки способностей и рисков ИИ систем.
🌸TLDR: предлагается измерять производительность ИИ с точки зрения продолжительности задач, которые могут выполнить агенты.
При этом вводится новый бенчмарк и показывается, что продолжительность решаемых задач постоянно экспоненциально растет в течение последних 6 лет, и удваивается примерно раз в 7 месяцев. Экстраполяция этой тенденции предсказывает, что менее чем через пять лет мы увидим агентов, которые смогут самостоятельно выполнять большую часть программных задач, на которые в настоящее время у людей уходят дни или недели.
Для точности вводится новая метрика: учитывается время, которое обычно требуется людям для выполнения задач, которые модели ИИ могут выполнить с 50%-ным успехом.
У Claude 3.7 Sonnet, например, этот временной горизонт около 50 минут.
Красивая экспонента и оценки будущих горизонтов агентов уже ушли в заголовки.
🌸А теперь самое интересное: на чем меряем?
На немотивированно странном подмножестве бенчмарков.
— 97 задач из HCAST: инженерные задачи от 30 сек до 30 минут
— 7 сложных ML задач из RE-Bench по 8 часов каждая
— 66 очень простых софтверных задач от 1 до 30 секунд (новый бенчмарк, Software atomic actions, SWAA)
— 1 (одна, Карл!) задача из GAIA
🌸Что не так с такими оценками?
— если бы это было так просто, новую метрику бы вводить в целом не потребовалось, можно было бы взять 100+, а то и 1000+ задач предыдущих лет (у нас что, дефицит бенчмарков??) и спокойно построить результат. К сожалению, так не получилось, поэтому пришлось черри-пикать задачи и даже придумывать новые, которые бы дали нужную картину.
— сложность и время выполнения задачи — не одно и то же, можно придумать много долгих тупых задач;
— даже если считать, что в целом это правда, что мы постепенно научились автоматизировать более сложные задачи (конечно), то давайте прямо скажем, что улучшение качества происходит за счет разных компонент прогресса: доступности обучающих данных, бюджета на разметку, вычислительного бюджета на масштабирование модели, и самое интересное — за счет алгоритмической новизны. Все эти факторы имеют совершенно разный вес в каждой из приведенных задач. Соотношение этих факторов во многом для closed source моделей нам совершенно не известно. Смысла искать в них общую экспоненциальную тенденцию немного.
— компьют и данные не скейлятся по экспоненте, при этом только их вклад является наиболее предсказуемым; а алгоритмические улучшения отдельно без скейлинга трудно прогнозировать.
В общем и целом, перебор результатов, чтобы найти экспоненту — это уже самостоятельная бизнес-модель и вообще, залог будущих инвестиций.
Ну и напоследок, результаты опроса AAAI 2025 :"Большинство респондентов (76%) утверждают, что «масштабирование текущих подходов к ИИ» для создания AGI «маловероятно» или «крайне маловероятно» приведет к успеху, что вызывает сомнения относительно того, достаточны ли текущие парадигмы машинного обучения для достижения AGI."
🟣 Пост METR
🟣 Arxiv
#nlp #про_nlp #nlp_papers
На прошлой неделе вышел анализ от METR (Model Evaluation & Threat Research) — независимой организации оценки способностей и рисков ИИ систем.
🌸TLDR: предлагается измерять производительность ИИ с точки зрения продолжительности задач, которые могут выполнить агенты.
При этом вводится новый бенчмарк и показывается, что продолжительность решаемых задач постоянно экспоненциально растет в течение последних 6 лет, и удваивается примерно раз в 7 месяцев. Экстраполяция этой тенденции предсказывает, что менее чем через пять лет мы увидим агентов, которые смогут самостоятельно выполнять большую часть программных задач, на которые в настоящее время у людей уходят дни или недели.
Для точности вводится новая метрика: учитывается время, которое обычно требуется людям для выполнения задач, которые модели ИИ могут выполнить с 50%-ным успехом.
У Claude 3.7 Sonnet, например, этот временной горизонт около 50 минут.
Красивая экспонента и оценки будущих горизонтов агентов уже ушли в заголовки.
🌸А теперь самое интересное: на чем меряем?
На немотивированно странном подмножестве бенчмарков.
— 97 задач из HCAST: инженерные задачи от 30 сек до 30 минут
— 7 сложных ML задач из RE-Bench по 8 часов каждая
— 66 очень простых софтверных задач от 1 до 30 секунд (новый бенчмарк, Software atomic actions, SWAA)
— 1 (одна, Карл!) задача из GAIA
🌸Что не так с такими оценками?
— если бы это было так просто, новую метрику бы вводить в целом не потребовалось, можно было бы взять 100+, а то и 1000+ задач предыдущих лет (у нас что, дефицит бенчмарков??) и спокойно построить результат. К сожалению, так не получилось, поэтому пришлось черри-пикать задачи и даже придумывать новые, которые бы дали нужную картину.
— сложность и время выполнения задачи — не одно и то же, можно придумать много долгих тупых задач;
— даже если считать, что в целом это правда, что мы постепенно научились автоматизировать более сложные задачи (конечно), то давайте прямо скажем, что улучшение качества происходит за счет разных компонент прогресса: доступности обучающих данных, бюджета на разметку, вычислительного бюджета на масштабирование модели, и самое интересное — за счет алгоритмической новизны. Все эти факторы имеют совершенно разный вес в каждой из приведенных задач. Соотношение этих факторов во многом для closed source моделей нам совершенно не известно. Смысла искать в них общую экспоненциальную тенденцию немного.
— компьют и данные не скейлятся по экспоненте, при этом только их вклад является наиболее предсказуемым; а алгоритмические улучшения отдельно без скейлинга трудно прогнозировать.
В общем и целом, перебор результатов, чтобы найти экспоненту — это уже самостоятельная бизнес-модель и вообще, залог будущих инвестиций.
Ну и напоследок, результаты опроса AAAI 2025 :"Большинство респондентов (76%) утверждают, что «масштабирование текущих подходов к ИИ» для создания AGI «маловероятно» или «крайне маловероятно» приведет к успеху, что вызывает сомнения относительно того, достаточны ли текущие парадигмы машинного обучения для достижения AGI."
Please open Telegram to view this post
VIEW IN TELEGRAM
metr.org
Measuring AI Ability to Complete Long Tasks
We propose measuring AI performance in terms of the *length* of tasks AI agents can complete. We show that this metric has been consistently exponentially increasing over the past 6 years, with a doubling time of around 7 months. Extrapolating this trend…
Forwarded from Облачный адвокат (Dmitri Soshnikov)
Друзья, спешу сообщить, что запись вчерашнего вебинара по созданию умных ассистентов в Yandex Cloud уже доступна на сайте, а самое главное - есть код на GitHub, который позволяет разобраться с тем, как создавать ассистентов с RAG и Function Calling в одном флаконе. Кажется, это на текущий момент наиболее доступный цельный пример создания ассистентов, хотя очень хорошие примеры есть в самом YC ML SDK.
По просьбам зрителей будем дальше совершенствовать этот пример, добавляя в него многоагентности, ну а также возможность подбирать водку к пельменям (в текущем варианте он умеет только в красное вино).
P.S. Спасибо всем, присоединившимся к каналу по итогам вебинара - рад вас тут видеть!
По просьбам зрителей будем дальше совершенствовать этот пример, добавляя в него многоагентности, ну а также возможность подбирать водку к пельменям (в текущем варианте он умеет только в красное вино).
P.S. Спасибо всем, присоединившимся к каналу по итогам вебинара - рад вас тут видеть!
Forwarded from КПД
YDS - Efficient models (Сжатие LLM).pdf
6.1 MB
Презентация с моей сегодняшней лекции про методы сжатия БЯМ на курсе Школы Анализа Данных Яндекса "Эффективные Модели".
В ней даю краткий обзор по существующим подходам, актуальным работам в области и некоторые общие рекомендации.
В ней даю краткий обзор по существующим подходам, актуальным работам в области и некоторые общие рекомендации.
This media is not supported in your browser
VIEW IN TELEGRAM
Нейронка уже пишет на Common Lisp лучше стажера
Сейчас за час, не написав ни строчки кода сделал такую библиотеку:
https://github.com/40ants/routes/pull/1/files
там и тесты есть с документацией.
Многое конечно еще предстоит поправить, но получилось неплохо.
Использовал VSCode + Roo Code плагин + Claude 3.7 от Anthropic.
Оно даже тесты само умеет запускать в терминале, смотреть что падает и чинить. Сначала пробовала запускать через голый SBCL, но адаптировалась, когда я подсказал использовать для запуска
Единственный момент, который огорчает – в течении этого часа я чувствовал себя, как прораб миллиарда обезьян, пишущих Войну и Мир. И не получил ни капли от того количества эндорфина, котрый обычно получаю, программируя на Common Lisp.
Завтра вчитаюсь внимательно в то что получилось, и буду этот код рефакторить с помощью нейронки.
#lisp #ai #codeassistant
Сейчас за час, не написав ни строчки кода сделал такую библиотеку:
https://github.com/40ants/routes/pull/1/files
там и тесты есть с документацией.
Многое конечно еще предстоит поправить, но получилось неплохо.
Использовал VSCode + Roo Code плагин + Claude 3.7 от Anthropic.
Оно даже тесты само умеет запускать в терминале, смотреть что падает и чинить. Сначала пробовала запускать через голый SBCL, но адаптировалась, когда я подсказал использовать для запуска
qlot exec ros run.Единственный момент, который огорчает – в течении этого часа я чувствовал себя, как прораб миллиарда обезьян, пишущих Войну и Мир. И не получил ни капли от того количества эндорфина, котрый обычно получаю, программируя на Common Lisp.
Завтра вчитаюсь внимательно в то что получилось, и буду этот код рефакторить с помощью нейронки.
#lisp #ai #codeassistant
Кстати, плагин который я использовал, умеет общаться с серверами поддерживающими Model Context Protocol. Так что можно запилить такой сервер, который даст нейронке возможность делать интроспекцию внутри образа, читать докстринги, ставить либы из Quicklisp, запускать там код и делать прочие нехорошие вещи. Жду не дождусь это попробовать.
Недавно на Reddit был анонс про MCP сервер для лисп системы Gendl. Может оттуда удастся что-то переиспользовать.
Недавно на Reddit был анонс про MCP сервер для лисп системы Gendl. Может оттуда удастся что-то переиспользовать.
GitHub
GitHub - modelcontextprotocol/servers: Model Context Protocol Servers
Model Context Protocol Servers. Contribute to modelcontextprotocol/servers development by creating an account on GitHub.
Forwarded from Айтигребец
Купил Middle разработчика за 20$ в месяц 🚬
⬇️ Шёл пятый месяц. Впечатления от Cursor ⬇️
Господа коллеги, если вы до сих пор программируете не через Cursor/Windsurf/другой_AI_IDE - вы допускаете ошибку и подсаживаетесь в лодочку к луддитам.
И так, Cursor - это IDE построенная поверх vscode (если вы пользуетесь другой - об этом ниже) со встроенным AI-инструментарием. Если в двух словах - есть окно для ввода промпта, где вы описываете что вам нужно сделать и смотрите на магию.
❓ Почему это сильно отличается от подхода "Вбил в чатгпт => скопировал"?
0. Начнем с того, что не нужно использовать ChatGPT для кодинга. Сегодня - Claude Sonnet (3.5/3.7) от антропиков - пока лучшая модель для генерации кода. Однако, можно выбрать если захочется и модели openAI
1. Курсор умеет сразу в обработку многих файлов. Добавление/изменение/удаление - на каждом этапе он создаёт restore point (можно всё откатывать в один кликесли до сих пор гит не юзаете хД).
2. Прямо в процессе вы можете видеть удобный DIFF - фича, которая позволяет вам посмотреть что именно и в каких файлах он поменял и провести "ревью" изменений после каждого промпта (или после нескольких). Да, у вас может быть "цепочка" промптов, т.е. "мини-сессия"
3. Курсор умеет индексировать и засовывать в контекст от "нужных файлов" до либ из специфичных урлов, которые нужны вам именно в этом проекте. Да, контекст ограничен, но в целом уже достаточен. О нём чуть ниже.
4. Уже сейчас (после обновы) он работает в агентском режиме по-умолчанию, т.е. перед отправкой вашего промпта он на локальной машине собирает нужную ему информацию (допустим грепает файлы или их структуру, ходит по импортам и тд), а уже потом с правильным контекстом бежит на сервер.
5. Он умеет смотреть на ошибки компиляции после применения кода и автоматически их править, вам не нужно "вклиниваться" в процесс и просить его об этом.
6. Есть отдельные настройки и инструкции для всех запросов, куда вы можете написать свои пожелания по генерации.
В общем.. а что вам еще нужно?
Как это ощущается?
Ощущается это - как вы КУПИЛИ себе МИДЛА за 20$!!! Ну такой, немножко с особенностями, но точно уже не джун. Вы формулируете ему задачу по коду, отправляете делать, а вы на N секунд/минут отправляетесь заниматься чем-то другим. А потом приходите и проверяете что он там вам накрабил. Делаете ревью, просите что-то поправить или вовсе переделать.
‼️ Экономит тонну времени - вот что вам нужно знать в первую очередь о курсоре.
Где он особенно хорош :
- написание тестов (это просто киллер-фича. только ради этого уже можно платить)
- небольшие/пет-проекты/прототипирование. Если проект небольшой или выхотите написать какой-то пруф-оф-концепт - он справляется с этим на 10 из 10, т.к. чаще всего имеет в контексте вообще всё что нужно
- бойлерплейты. Если у вас есть какие-то "типовые" классы, конструкции, связи, сервисы и тд и вы можете ему на это указать и написать "сделай вот как тут, но..."
- прекрасно "подстраивается" под то, что вы ему указываете как референс. Всю скучную генерацию всяких DTO, схем, моделей, маппингов - прекрасно отрабатывает.
Но давайте немного и о минусах
1) Чем развесистее кодовая база, тем ему сложнее "подстроится" под проект. Контекстное окно - вот вокруг чего сейчас крутятся все оптимизации тулов и справляются они уже неплохо. Курсор построен на RAG'е, а так же может юзать ваши MCP если нужно. Ну и простроенные AST в самой IDE всё лучше интегрируются с AI (привет JetBrains'у, который до сих пор почему-то отстаёт в этой гонке).
2) Порог входа. Он и супер-низкий и ... неочевидно сложен. Поясню - вы очень легко можете "потыкать" в триальную версию. Не впечатлиться. И уйти дальше крабить в своей любимой IDE. И всё - будете рассказывать всем вокруг как оно не работает и вообще фу. Нужно пожить с ним недельки две каждодневного взаимодействия - и тогда вы сможете "распробовать". На разных задачах, с разными подходами, как работать с лимитами и прочее.
Так ... растёкся как всегда тут ручьём по древу. Не влазит в пост. Продолжение чуть ниже⬇️
Господа коллеги, если вы до сих пор программируете не через Cursor/Windsurf/другой_AI_IDE - вы допускаете ошибку и подсаживаетесь в лодочку к луддитам.
И так, Cursor - это IDE построенная поверх vscode (если вы пользуетесь другой - об этом ниже) со встроенным AI-инструментарием. Если в двух словах - есть окно для ввода промпта, где вы описываете что вам нужно сделать и смотрите на магию.
0. Начнем с того, что не нужно использовать ChatGPT для кодинга. Сегодня - Claude Sonnet (3.5/3.7) от антропиков - пока лучшая модель для генерации кода. Однако, можно выбрать если захочется и модели openAI
1. Курсор умеет сразу в обработку многих файлов. Добавление/изменение/удаление - на каждом этапе он создаёт restore point (можно всё откатывать в один клик
2. Прямо в процессе вы можете видеть удобный DIFF - фича, которая позволяет вам посмотреть что именно и в каких файлах он поменял и провести "ревью" изменений после каждого промпта (или после нескольких). Да, у вас может быть "цепочка" промптов, т.е. "мини-сессия"
3. Курсор умеет индексировать и засовывать в контекст от "нужных файлов" до либ из специфичных урлов, которые нужны вам именно в этом проекте. Да, контекст ограничен, но в целом уже достаточен. О нём чуть ниже.
4. Уже сейчас (после обновы) он работает в агентском режиме по-умолчанию, т.е. перед отправкой вашего промпта он на локальной машине собирает нужную ему информацию (допустим грепает файлы или их структуру, ходит по импортам и тд), а уже потом с правильным контекстом бежит на сервер.
5. Он умеет смотреть на ошибки компиляции после применения кода и автоматически их править, вам не нужно "вклиниваться" в процесс и просить его об этом.
6. Есть отдельные настройки и инструкции для всех запросов, куда вы можете написать свои пожелания по генерации.
В общем.. а что вам еще нужно?
Как это ощущается?
Ощущается это - как вы КУПИЛИ себе МИДЛА за 20$!!! Ну такой, немножко с особенностями, но точно уже не джун. Вы формулируете ему задачу по коду, отправляете делать, а вы на N секунд/минут отправляетесь заниматься чем-то другим. А потом приходите и проверяете что он там вам накрабил. Делаете ревью, просите что-то поправить или вовсе переделать.
‼️ Экономит тонну времени - вот что вам нужно знать в первую очередь о курсоре.
Где он особенно хорош :
- написание тестов (это просто киллер-фича. только ради этого уже можно платить)
- небольшие/пет-проекты/прототипирование. Если проект небольшой или выхотите написать какой-то пруф-оф-концепт - он справляется с этим на 10 из 10, т.к. чаще всего имеет в контексте вообще всё что нужно
- бойлерплейты. Если у вас есть какие-то "типовые" классы, конструкции, связи, сервисы и тд и вы можете ему на это указать и написать "сделай вот как тут, но..."
- прекрасно "подстраивается" под то, что вы ему указываете как референс. Всю скучную генерацию всяких DTO, схем, моделей, маппингов - прекрасно отрабатывает.
Но давайте немного и о минусах
1) Чем развесистее кодовая база, тем ему сложнее "подстроится" под проект. Контекстное окно - вот вокруг чего сейчас крутятся все оптимизации тулов и справляются они уже неплохо. Курсор построен на RAG'е, а так же может юзать ваши MCP если нужно. Ну и простроенные AST в самой IDE всё лучше интегрируются с AI (привет JetBrains'у, который до сих пор почему-то отстаёт в этой гонке).
2) Порог входа. Он и супер-низкий и ... неочевидно сложен. Поясню - вы очень легко можете "потыкать" в триальную версию. Не впечатлиться. И уйти дальше крабить в своей любимой IDE. И всё - будете рассказывать всем вокруг как оно не работает и вообще фу. Нужно пожить с ним недельки две каждодневного взаимодействия - и тогда вы сможете "распробовать". На разных задачах, с разными подходами, как работать с лимитами и прочее.
Так ... растёкся как всегда тут ручьём по древу. Не влазит в пост. Продолжение чуть ниже
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Айтигребец
3) Нужно внимательно ревьювать этого товарища. Он всё еще может делать смешно. От "поменял optional параметр с true на false" до "давай мы под падающий тест поменяем код" :))
И это ок. Вы даёте задачу и именно вы проверяете как она сделана. Хотелось бы конечно без этого вот всего, но с другой стороны а как иначе.
4) Если вы живёте в другой IDE - придётся "жить" на две IDE. Именно так сейчас делают все и так делал я. Это не особо напрягает, воспринимайте в этом случае курсор как "хелпер с боку", на который вам нужно переключиться при написании какого-нибудь бойлерплейта.
5) Платный. Не то чтобы это даже минус. на самом деле 20$ эт прям недорого учитывая сколько он может экономить вам времени. Плюс ... если у вас есть подписка на chat gpt, вы можете её отключать, т.к. и "режим чата" там тоже поддерживается, но это если совсем бюджетируете траты.
ВЫВОДЫ
"Использовать нельзя игнорировать" - запятую уже очевидно куда ставить.
Правда в том, что Работы для вас остаётся всё еще много. Просто она смещается сильно на более высокий уровень во многих местах. На примере своего последнего пет-проекта (о нём в след посте) - инженер тут всё еще ВЫ и пока никакой AI вас не заменит, если у вас за плечами опыт. У меня вообще есть ощущение, что сейчас спрос на хороших Senior специалистов будет расти. Эдакий хуман-RAG для AI
Я сейчас фоново прохожу процесс собеседований и отчётливо вижу спрос на этот новый навык. Поэтому если RAG, MCP, контекстные input/output окна - для вас незнакомые термины, возможно, самое время начинать догонять. Всё как в Алисе из страны чудес :
Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее
Я немного удивлён тем как отстаёт майкрософт со своими моделями и тулами. Копайлот пока не так хорош, как и 4o модели (близко, но недостаточно). Но почему-то есть уверенность, что совсем скоро он всё же отожрёт бОльшую часть рынка. Наблюдаем.
Если вы еще не в этой AI-лодке - срочно запрыгивайте. И весло своё оставьте на берегу - вам дадут своего маленького гребца.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from .ml
Что такое Bias и Variance?
Таким образом, у нас может быть три типа моделей:
📝 Недообученная: слишком простая, имеет высокий bias и низкий variance.
📝 Переобученная: слишком сложная, имеет низкий bias и высокий variance.
📝 Оптимальная: имеет идеальный баланс между смещением и дисперсией.
Сложность модели напрямую влияет на её способность обобщать. Слишком простая модель может не реагировать на изменения входных данных, что приводит к недостаточной гибкости и плохой способности к обобщению. Чем сложнее модель, тем лучше она подстраивается под данные, но при этом возрастает риск переобучения.
Если построить график зависимости ошибки от соотношения количества параметров модели к объему данных, то увидим следующее:
Почему же такого нет у больших моделей типа GPT?
Потому что у этого графика есть продолжение. Когда количество параметров модели увеличивается тестовая loss делает спуск. Это называется double descent:
📝 Complexity double descent — когда мы наращиваем сложность модели;
📝 Data double descent — когда мы увеличиваем объём обучающей выборки при фиксированной сложности модели.
Благодаря этому феномену более сложные большие модели могут находить более простые решения.
Bias (смещение) — ошибка, которая возникает из-за недостаточной сложности модели.
Variance (дисперсия) — ошибка, которая возникает из-за чрезмерной чувствительности модели к конкретным примерам в обучающей выборке.
Таким образом, у нас может быть три типа моделей:
📝 Недообученная: слишком простая, имеет высокий bias и низкий variance.
📝 Переобученная: слишком сложная, имеет низкий bias и высокий variance.
📝 Оптимальная: имеет идеальный баланс между смещением и дисперсией.
Сложность модели напрямую влияет на её способность обобщать. Слишком простая модель может не реагировать на изменения входных данных, что приводит к недостаточной гибкости и плохой способности к обобщению. Чем сложнее модель, тем лучше она подстраивается под данные, но при этом возрастает риск переобучения.
Если построить график зависимости ошибки от соотношения количества параметров модели к объему данных, то увидим следующее:
📌 При недостаточном количестве параметров ошибка на обучающей и тестовой выборке высокая.
📌 При увеличении параметров ошибка на обучающей выборке снижается, но тестовая ошибка начинает расти, так как модель переобучается.
Почему же такого нет у больших моделей типа GPT?
Потому что у этого графика есть продолжение. Когда количество параметров модели увеличивается тестовая loss делает спуск. Это называется double descent:
📝 Complexity double descent — когда мы наращиваем сложность модели;
📝 Data double descent — когда мы увеличиваем объём обучающей выборки при фиксированной сложности модели.
Благодаря этому феномену более сложные большие модели могут находить более простые решения.
Forwarded from DeepSchool
YOLO history. Part 7
Продолжаем разбор моделей из семейства YOLO 😉
2024 год, похоже, стал рекордным по количеству релизов: сразу четыре новые модели пополнили семейство YOLO. Чтобы за ними успеть, сегодня мы разберём сразу две архитектуры: YOLOv7 и YOLOv9. Обе они разработаны авторами YOLOv4, но при этом демонстрируют разные подходы к архитектуре и обучению.
В этой статье мы узнаем:
- что общего между 7-ой и 9-ой версиями и чем они отличаются от 4-ой
- чем отличаются аббревиатуры ELAN, E-ELAN и GELAN
- зачем нужны вспомогательные модели и как их можно использовать для ускорения обучения
Читайте новую статью по ссылке!
Продолжаем разбор моделей из семейства YOLO 😉
2024 год, похоже, стал рекордным по количеству релизов: сразу четыре новые модели пополнили семейство YOLO. Чтобы за ними успеть, сегодня мы разберём сразу две архитектуры: YOLOv7 и YOLOv9. Обе они разработаны авторами YOLOv4, но при этом демонстрируют разные подходы к архитектуре и обучению.
В этой статье мы узнаем:
- что общего между 7-ой и 9-ой версиями и чем они отличаются от 4-ой
- чем отличаются аббревиатуры ELAN, E-ELAN и GELAN
- зачем нужны вспомогательные модели и как их можно использовать для ускорения обучения
Читайте новую статью по ссылке!
Forwarded from Ученый без степени | AI-блог Ани
Я работаю Applied Scientist в Amazon — и у меня нет PhD. Да, так можно 🚀
Серьёзно. Когда я только начинала путь в ML (еще в магистратуре), думала, что без учёной степени на AI research позиции в MAANG не попасть. Сегодня я работаю Applied Scientist в Amazon, и хотя большинство моих коллег действительно имеют докторскую степень, я расскажу, как можно стать частью applied science команды и без нее. В этом посте хочу разложить по полочкам, какие вообще бывают роли в AI, чем они отличаются и куда реально можно попасть — если ты мотивированный и трудолюбивый.
Три ключевые роли в AI-компаниях:
1. Research Scientist 🧪 — теоретик, штурмующий вершины NeurIPS. Публикует статьи, изобретает новые архитектуры, двигает границы state-of-the-art. Почти всегда с PhD. Работает в Google DeepMind, Meta AI, OpenAI. Фокус на инновациях и публикациях. Production? Это уже второстепенная задача.
2. Applied Scientist 🛠 — мост между наукой и бизнесом. Моя любимая роль (ну, очевидно)! Трансформируем научные статьи в работающие продукты: тестируем гипотезы, адаптируем модели и запускаем их в производство. PhD часто желателен, но не обязателен (Amazon ценит практический опыт и результаты магистратуры). Цель — модели, которые приносят прибыль и улучшают метрики. Иногда удается блеснуть и на научных конференциях.
3. Machine Learning Engineer 💻 — инженер, который знает, как не уронить прод. Любит код, системы, пайплайны. Собирает датафлоу, оборачивает модели в API, оптимизирует latency. Не обязан иметь PhD, но обязан писать классный код и понимать, как работает ML под капотом.
Карта AI-ролей в ведущих компаниях:
Amazon 📦
- Applied Scientist — универсальный солдат AI. Нужно владеть и ML, и кодом. PhD приветствуется, но не обязателен.
- Research Scientist — больше фокуса на алгоритмах и моделях, меньше кодирования.
Google / DeepMind 🔍
- Research Scientist — PhD-ориентированная роль с акцентом на публикации и долгосрочные исследования.
- Software Engineer (ML) — специалист по ML-инфраструктуре, production-решениям и масштабированию.
Meta (ex-Facebook) 👥
- Research Scientist — часто сочетает исследования с внедрением. Наличие PhD может дать этот титул даже тем, кто работает с production-кодом.
- ML Engineer — фокус на построении систем и продакшене.
OpenAI / Anthropic 🤖
- Research Scientist — исследователь фундаментальных проблем (alignment, LLMs). Практически всегда с PhD.
- Research Engineer — позиция для специалистов без PhD, но с сильными навыками программирования и интересом к исследованиям.
NVIDIA 🎮
- Research Scientist — академический подход с фокусом на оптимизацию для GPU.
- Applied / Deep Learning Engineer — ориентация на продукт и высокую производительность.
Apple, Netflix 🍎🎬
- ML Engineer / Applied Scientist — ближе к продукту, меньше публикаций, больше практического влияния.
Что важно: ⚠️ Необязательно начинать с исследовательской позиции — можно войти как ML Engineer и развиваться дальше (в Amazon доступны переходы между смежными ролями). В любой позиции критически важны навыки: умение объяснять модели, планировать эксперименты, исправлять пайплайны, работать с зашумленными данными и понимать бизнес-задачи. За последние годы я наблюдаю четкий тренд: крупные компании всё чаще открывают двери в applied (и даже research) science для талантливых кандидатов без ученой степени. Реальные навыки и готовность учиться становятся важнее формальных регалий. ✨
Если пост был полезен — поддержите лайком! 👍
А если хотите ещё такие разборы по индустрии, карьере и AI-ролям? Напишите в комментах!
P.S.: Пост вдохновлён нашими с @etsymba беседами во время кофе-брейков :)
Серьёзно. Когда я только начинала путь в ML (еще в магистратуре), думала, что без учёной степени на AI research позиции в MAANG не попасть. Сегодня я работаю Applied Scientist в Amazon, и хотя большинство моих коллег действительно имеют докторскую степень, я расскажу, как можно стать частью applied science команды и без нее. В этом посте хочу разложить по полочкам, какие вообще бывают роли в AI, чем они отличаются и куда реально можно попасть — если ты мотивированный и трудолюбивый.
Три ключевые роли в AI-компаниях:
1. Research Scientist 🧪 — теоретик, штурмующий вершины NeurIPS. Публикует статьи, изобретает новые архитектуры, двигает границы state-of-the-art. Почти всегда с PhD. Работает в Google DeepMind, Meta AI, OpenAI. Фокус на инновациях и публикациях. Production? Это уже второстепенная задача.
2. Applied Scientist 🛠 — мост между наукой и бизнесом. Моя любимая роль (ну, очевидно)! Трансформируем научные статьи в работающие продукты: тестируем гипотезы, адаптируем модели и запускаем их в производство. PhD часто желателен, но не обязателен (Amazon ценит практический опыт и результаты магистратуры). Цель — модели, которые приносят прибыль и улучшают метрики. Иногда удается блеснуть и на научных конференциях.
3. Machine Learning Engineer 💻 — инженер, который знает, как не уронить прод. Любит код, системы, пайплайны. Собирает датафлоу, оборачивает модели в API, оптимизирует latency. Не обязан иметь PhD, но обязан писать классный код и понимать, как работает ML под капотом.
Карта AI-ролей в ведущих компаниях:
Amazon 📦
- Applied Scientist — универсальный солдат AI. Нужно владеть и ML, и кодом. PhD приветствуется, но не обязателен.
- Research Scientist — больше фокуса на алгоритмах и моделях, меньше кодирования.
Google / DeepMind 🔍
- Research Scientist — PhD-ориентированная роль с акцентом на публикации и долгосрочные исследования.
- Software Engineer (ML) — специалист по ML-инфраструктуре, production-решениям и масштабированию.
Meta (ex-Facebook) 👥
- Research Scientist — часто сочетает исследования с внедрением. Наличие PhD может дать этот титул даже тем, кто работает с production-кодом.
- ML Engineer — фокус на построении систем и продакшене.
OpenAI / Anthropic 🤖
- Research Scientist — исследователь фундаментальных проблем (alignment, LLMs). Практически всегда с PhD.
- Research Engineer — позиция для специалистов без PhD, но с сильными навыками программирования и интересом к исследованиям.
NVIDIA 🎮
- Research Scientist — академический подход с фокусом на оптимизацию для GPU.
- Applied / Deep Learning Engineer — ориентация на продукт и высокую производительность.
Apple, Netflix 🍎🎬
- ML Engineer / Applied Scientist — ближе к продукту, меньше публикаций, больше практического влияния.
Что важно: ⚠️ Необязательно начинать с исследовательской позиции — можно войти как ML Engineer и развиваться дальше (в Amazon доступны переходы между смежными ролями). В любой позиции критически важны навыки: умение объяснять модели, планировать эксперименты, исправлять пайплайны, работать с зашумленными данными и понимать бизнес-задачи. За последние годы я наблюдаю четкий тренд: крупные компании всё чаще открывают двери в applied (и даже research) science для талантливых кандидатов без ученой степени. Реальные навыки и готовность учиться становятся важнее формальных регалий. ✨
Если пост был полезен — поддержите лайком! 👍
А если хотите ещё такие разборы по индустрии, карьере и AI-ролям? Напишите в комментах!
P.S.: Пост вдохновлён нашими с @etsymba беседами во время кофе-брейков :)
Forwarded from что-то на инженерном
Хинты в Spark 🪄
Сегодня расскажу про «секретные команды», которые помогают оптимизировать выполнение задач, когда автоматический оптимизатор не справляется. Разберемся, какие хинты бывают, как их использовать и почему они не работают.
❕Важно: хинты не гарантируют результат, но в 90% случаев spark их учитывает.
Основные типы хинтов:
1 — для джойнов
Помогают выбрать алгоритм соединения таблиц.
▫️BROADCAST - запускает Broadcast Join (маленькая таблица копируется на все ноды).
▫️MERGE - указывает, что данные отсортированы, и можно использовать Merge Join. Можно применять, если заранее отсортировали данные по ключу соединения.
▫️SHUFFLE_HASH - принудительно запускает Hash Shuffle Join. Применять для больших таблиц, где ключи можно хешировать.
2 — для управления партициями
Контролируют, как данные распределены между нодами.
▫️REPARTITION - перераспределяет данные через полный shuffle, чтобы увеличить/уменьшить число партиций или партицировать по столбцу.
▫️COALESCE - уменьшает число партиций без shuffle (объединяет соседние). Применяется после фильтрации, чтобы избежать мелких партиций.
▫️REBALANCE - автоматически балансирует данные, минимизируя перекосы.
3 — для борьбы с перекосами (skew)
▫️SKEW - указывает spark на перекошенный ключ и число партиций.
Кстати, если в Spark UI видите задачи, которые выполняются в 10 раз дольше других — это skew. Попробуйте применить хинт SKEW или REBALANCE.
Что по синтаксису?
В sql: хинт передается в комменты /*+ ... */ после select.
В spark: через метод hint()
Почему хинты не работают?
— Противоречат логике оптимизатора. Например, если таблица для BROADCAST слишком большая, spark выполнит Sort-Merge Join вместо Broadcast.
— Версия вашего spark. Хинты вроде SKEW или REBALANCE требуют spark 3.0+
— Что-то в параметрах сессии. Например, включен AQE, он может переопределять хинты.
Сегодня расскажу про «секретные команды», которые помогают оптимизировать выполнение задач, когда автоматический оптимизатор не справляется. Разберемся, какие хинты бывают, как их использовать и почему они не работают.
❕Важно: хинты не гарантируют результат, но в 90% случаев spark их учитывает.
Основные типы хинтов:
1 — для джойнов
Помогают выбрать алгоритм соединения таблиц.
▫️BROADCAST - запускает Broadcast Join (маленькая таблица копируется на все ноды).
▫️MERGE - указывает, что данные отсортированы, и можно использовать Merge Join. Можно применять, если заранее отсортировали данные по ключу соединения.
▫️SHUFFLE_HASH - принудительно запускает Hash Shuffle Join. Применять для больших таблиц, где ключи можно хешировать.
2 — для управления партициями
Контролируют, как данные распределены между нодами.
▫️REPARTITION - перераспределяет данные через полный shuffle, чтобы увеличить/уменьшить число партиций или партицировать по столбцу.
▫️COALESCE - уменьшает число партиций без shuffle (объединяет соседние). Применяется после фильтрации, чтобы избежать мелких партиций.
▫️REBALANCE - автоматически балансирует данные, минимизируя перекосы.
3 — для борьбы с перекосами (skew)
▫️SKEW - указывает spark на перекошенный ключ и число партиций.
Кстати, если в Spark UI видите задачи, которые выполняются в 10 раз дольше других — это skew. Попробуйте применить хинт SKEW или REBALANCE.
Что по синтаксису?
В sql: хинт передается в комменты /*+ ... */ после select.
SELECT /*+ MERGE */
t1.*, t2.*
FROM table1 t1
JOIN table2 t2 ON t1.sorted_key = t2.sorted_key;
В spark: через метод hint()
df.hint("rebalance", "user_id")Почему хинты не работают?
— Противоречат логике оптимизатора. Например, если таблица для BROADCAST слишком большая, spark выполнит Sort-Merge Join вместо Broadcast.
— Версия вашего spark. Хинты вроде SKEW или REBALANCE требуют spark 3.0+
— Что-то в параметрах сессии. Например, включен AQE, он может переопределять хинты.