Forwarded from Тагир Анализирует
Совсем недавно я закончил Вышку. На втором курсе, когда генеративные модели стали набирать популярность, я начал использовать ChatGPT и другие ИИ-инструменты в учебе
Моя базовая позиция: в образовании, как и в других сферах, ИИ ускоряет работу и делает ее более эффективной, если грамотно его применять. Тут есть развилка:
Сценарий 1. Забрасываешь задачу, копируешь готовый ответ, не вникая в решение → материал не усваивается, ошибки не вылавливаются
Сценарий 2. Пошагово разбираешь решение, проверяешь логику, просишь примеры или объяснение «как 10-летнему ребенку» → тему понимаешь лучше, чем с дорогим репетитором
Некоторые курсы я не посещал, а только лишь сдавал домашки и экзамены. Презентации обычно были плохими и не воспринимались без лекций. Нужно было уметь быстро разобраться в сложном предмете с нуля за очень короткий срок
К некоторым экзаменам я готовился с нуля за 2-3 ночи, совмещая с фуллтайм работой. Я брал экзаменационные билеты и загружал их вместе с презентациями в ChatGPT – он составлял для меня короткую программу для подготовки к конкретному экзамену
Я просил использовать простые слова, приводить много примеров и подстраиваться под человека с нулевым бэкграундом. Так и сдавались многие предметы – в итоге часто получал оценки выше, чем одногруппники, ходившие на все занятия. Подобную историю видел и на Reddit
Метапромпт: «Собери краткий конспект по этим билетам: выдели ключевые определения и приведи по два примера к каждому вопросу»
Работа над курсовыми и дипломом тоже шла бодрее. Я просил ChatGPT набросать каркас исследования и структуру работы по пунктам, которые затем заполнял текстом и развивал сам. Вместо недели на выстраивание черновой схемы я за несколько часов получал выверенный план и уже вручную его шлифовал
Метапромпт: «Составь каркас дипломной работы по теме “_____”: введение, главы, выводы; для каждого раздела укажи цели, методы и примерный объем текста»
Когда доходило до экспериментов, валидировал свою логику у ChatGPT: где-то он советовал выбрать иной метод, где-то – увеличить выборку, а иногда – вообще отказаться от сомнительного теста
Метапромпт: «Проанализируй мой план эксперимента (ниже) и предложи улучшения»
Писал текст частями, и каждый фрагмент отправлял ИИ на проверку. ChatGPT ловил логические разрывы, терминологические огрехи и помогал упорядочить изложение. В этой статье рассказывают, почему такой подход к написанию работ эффективен
Метапромпт: «Проверь текст ниже на логические несостыковки, сложные обороты и повторения; дай правки списком»
Механическая работа вроде формирования списка литературы или поиск литературы для обзора тоже уходила к ИИ. Конечно, нужно было проверять, нет ли там выдуманных статей
Метапромпт: «Подбери 10 актуальных статей (2020+) по теме “_____”, дай корректные ссылки и краткое описание»
Но самый главный принцип, к которому я пришел с ChatGPT – задавать глупые вопросы. ИИ не осудит, не пристыдит и не скажет "мы это уже проходили". В образовательных целях подход очень эффективный. Постепенно приучился задавать такие вопросы и людям
Я не использовал ChatGPT в формате скопировал –> вставил, а пропускал каждый кусок работы через себя. Поэтому я хорошо владел всем материалом, а работы защищал на "отлично". В общем, пошел по второму сценарию из развилки в начале поста. С недавним релизом Study Mode это стало еще проще – писал об этом здесь
Конечно, всегда есть соблазн взять готовое решение, немного его отшлифовать и отдать – но нужно быть готовым, что оно окажется НАСТОЛЬКО неправильным, что потом возникнут вопросы. Ну и ни о каком усвоении материала здесь и речи нет, хотя некоторые задания хочется сдать и забыть
А как вы используете ИИ в обучении? Делитесь своими юзкейсами!
@tagir_analyzes
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Artem Ryblov’s Data Science Weekly
How to avoid machine learning pitfalls by Michael A. Lones
Mistakes in machine learning practice are commonplace, and can result in a loss of confidence in the findings and products of machine learning.
This guide outlines common mistakes that occur when using machine learning, and what can be done to avoid them.
Whilst it should be accessible to anyone with a basic understanding of machine learning techniques, it focuses on issues that are of particular concern within academic research, such as the need to do rigorous comparisons and reach valid conclusions.
It covers five stages of the machine learning process:
- What to do before model building
- How to reliably build models
- How to robustly evaluate models
- How to compare models fairly
- How to report results
Link: arXiv
Navigational hashtags: #armarticles
General hashtags: #ml #machinelearning #mlsystemdesign
@data_science_weekly
Mistakes in machine learning practice are commonplace, and can result in a loss of confidence in the findings and products of machine learning.
This guide outlines common mistakes that occur when using machine learning, and what can be done to avoid them.
Whilst it should be accessible to anyone with a basic understanding of machine learning techniques, it focuses on issues that are of particular concern within academic research, such as the need to do rigorous comparisons and reach valid conclusions.
It covers five stages of the machine learning process:
- What to do before model building
- How to reliably build models
- How to robustly evaluate models
- How to compare models fairly
- How to report results
Link: arXiv
Navigational hashtags: #armarticles
General hashtags: #ml #machinelearning #mlsystemdesign
@data_science_weekly
Forwarded from Лечим эйай
Топ смертных грехов - или нет?
Уже несколько лет я руковожу людьми и постепенно их становится все больше. Системного обучения "как быть руководителем" в моей жизни не было. Я иногда почитываю какие-то материалы, иногда советуюсь с родителями, но на самом деле во многих вещах я поступаю просто интуитивно и эмпирически нахожу ответы на вопросы.
В целом, если присмотреться, то становится понятно, что в обществе существует некий "gold standart" руководителя, который должен следовать 15-20 правилам и тогда его все будут любить.
Если ты человек с адекватным эмоциональным интеллектом, то запрыгнуть на эту "gold standart" ступеньку не составляет труда.
Примеры таких правил:
Тут все понятно, и да, далеко не все способны следовать и этому набору.
Но вот о чем я задумался. Данный список правил далеко не все говорит о твоей эффективности. Ключевые метрики на которые мы тут работаем - уменьшение текучки и развитие сотрудников. Но фактически есть еще та часть, в которой мы эффективно решаем задачи и зарабатываем деньги для компании. И возможно, чтобы работать оптимально, используя 100% возможностей - необходимо уменьшить количество "табу", тем самым увеличив свой инструментарий.
Вот некоторые пункты, о которых я пока размышляю:
Переработки
Об этом я частично писал. Причин, почему вам надо добавить динамики, множество. Если твой конкурент работает 5 дней в неделю, а ты 6, то высока вероятность, что ты будешь двигаться быстрее. И, возможно, навык руководителя не в том, чтобы отказаться от этого объективно рабочего инструмента, а грамотно им управлять, чтобы сотрудники не перегорели.
Нанимать не по вайбу
При найме я много раз отказывал людям, которые не подходили мне по софтам, хотя харды были очень хорошие. Я всегда считал, что микроклимат в отделе - ключ к успеху. Но, задумался я, почему бы не нанять токсичного гения, не "запереть его в комнате" и пусть перемалывает там самые сложные задачки. И тогда твой навык - оградить остальных от него, но задачи, возможно, он будет щелкать лучше прочих "вайбовых" коллег.
Повышать голос
Я много лет занимался спортом и оттуда вынес простую мысль на всю жизнь о том, что люди делятся на два типа: те, кого мотивирует поддержка и те, кого мотивирует давление. "Gold standart" сфокусирован на поддержке, но всех ли это реально стимулирует, вторая половина же никуда не пропала. Вспомните таких людей, которые очень редко повышают голос и в этих случаях вы понимаете, что реально что-то случилось. Может иногда это единственный способ привести в чувство и разгрести инцидент?
Обман
О сколько разговоров проведено и книг написано о лжи во благо, внесу свою лепту. Я стараюсь быть открытым и доводить большую часть информации до своих сотрудников, но есть вещи, которые могут вызвать скорее волнение, нежели принесут ценность от осведомленности. Сегментировать информацию, к сожалению, тоже полезный навык, вероятно, как и иногда лукавить.
Идея поста заключается в том, что искусство руководителя, кажется, заключается в умении применять широкий спектр инструментов, а не только удобные, при которых его все "любят", но эти гипотезы надо проверять на практике.
Пост слегка провокационный, будет интересно послушать ваше мнение об этом в комментариях!
@lechim_ai
Уже несколько лет я руковожу людьми и постепенно их становится все больше. Системного обучения "как быть руководителем" в моей жизни не было. Я иногда почитываю какие-то материалы, иногда советуюсь с родителями, но на самом деле во многих вещах я поступаю просто интуитивно и эмпирически нахожу ответы на вопросы.
В целом, если присмотреться, то становится понятно, что в обществе существует некий "gold standart" руководителя, который должен следовать 15-20 правилам и тогда его все будут любить.
Кстати, на тему "все будут любить" отличный пост написала Аня, автор канала Руковожоп (@peachyleader). Это не реклама, а моя личная рекомендация, хороший канал для начинающих руководителей.
Если ты человек с адекватным эмоциональным интеллектом, то запрыгнуть на эту "gold standart" ступеньку не составляет труда.
Примеры таких правил:
1. Не унижай личность сотрудника
2. Проводи встречи по развитию и давай людям расти
3. Будь защитником своей команды
4. Не перегружай сотрудников
5. Не микроменеджери
6. Не обманывай
и подобное.
Тут все понятно, и да, далеко не все способны следовать и этому набору.
Но вот о чем я задумался. Данный список правил далеко не все говорит о твоей эффективности. Ключевые метрики на которые мы тут работаем - уменьшение текучки и развитие сотрудников. Но фактически есть еще та часть, в которой мы эффективно решаем задачи и зарабатываем деньги для компании. И возможно, чтобы работать оптимально, используя 100% возможностей - необходимо уменьшить количество "табу", тем самым увеличив свой инструментарий.
Вот некоторые пункты, о которых я пока размышляю:
Переработки
Об этом я частично писал. Причин, почему вам надо добавить динамики, множество. Если твой конкурент работает 5 дней в неделю, а ты 6, то высока вероятность, что ты будешь двигаться быстрее. И, возможно, навык руководителя не в том, чтобы отказаться от этого объективно рабочего инструмента, а грамотно им управлять, чтобы сотрудники не перегорели.
Нанимать не по вайбу
При найме я много раз отказывал людям, которые не подходили мне по софтам, хотя харды были очень хорошие. Я всегда считал, что микроклимат в отделе - ключ к успеху. Но, задумался я, почему бы не нанять токсичного гения, не "запереть его в комнате" и пусть перемалывает там самые сложные задачки. И тогда твой навык - оградить остальных от него, но задачи, возможно, он будет щелкать лучше прочих "вайбовых" коллег.
Повышать голос
Я много лет занимался спортом и оттуда вынес простую мысль на всю жизнь о том, что люди делятся на два типа: те, кого мотивирует поддержка и те, кого мотивирует давление. "Gold standart" сфокусирован на поддержке, но всех ли это реально стимулирует, вторая половина же никуда не пропала. Вспомните таких людей, которые очень редко повышают голос и в этих случаях вы понимаете, что реально что-то случилось. Может иногда это единственный способ привести в чувство и разгрести инцидент?
Обман
О сколько разговоров проведено и книг написано о лжи во благо, внесу свою лепту. Я стараюсь быть открытым и доводить большую часть информации до своих сотрудников, но есть вещи, которые могут вызвать скорее волнение, нежели принесут ценность от осведомленности. Сегментировать информацию, к сожалению, тоже полезный навык, вероятно, как и иногда лукавить.
Идея поста заключается в том, что искусство руководителя, кажется, заключается в умении применять широкий спектр инструментов, а не только удобные, при которых его все "любят", но эти гипотезы надо проверять на практике.
Пост слегка провокационный, будет интересно послушать ваше мнение об этом в комментариях!
@lechim_ai
Forwarded from Поступашки - ШАД, Стажировки и Магистратура
Эти пет проекты должен сделать каждый ML специалист
Финальные 4 часа скидки подходят к концу, курсы стартуют уже завтра. В честь этого подготовили самые популярные проекты, еще больше пет проектов по глубокому обучению будут на нашем курсе ds (смотрите на сайте)
1. Кредитный скоринг
Стоит ли давать кредит— довольно популярная задача и отличный выбор для новчиков, чтобы самостоятельно проделать все этапы. Сначала берем любой датасет на kaggle по запросу Credit Scoring. Проводим EDA, генерируем гипотезы, фичи, готовим данные для модели и делаем бейзлайн: логистическая регрессия. Затем уже можно попробовать случайный лес, градиентный бустинг, KNN или еще что по вкусу— сравниваем метрики. И на последок не забываем проанализировать результаты и культурно презентовать. Можно провести АВ тест на смой первой модели.
Все варианты решения и реализации можно найти в интернетах: GitHub, Хабр. Очень полезным будет посмотреть всякие выступления на конференциях по этой теме для вдохновения, да и это очень поможет на мл кейсах.
2. Наивный Байесовский классификатор (НБК)
Для конкретики будем классифицировать письма на спам. Опять же обработаем данные: удаляем числа, знаки препинания, стоп-слова, стемминги, лемматизацию.
Объединяем все методы предварительной обработки и создаём словарь слов и счётчик каждого слова в наборе данных для обучения:
1. Вычисляем вероятность для каждого слова в тексте и отфильтровываем слова со значением вероятности меньше порогового. Такие слова будут нерелевантными.
2. Для каждого слова в словаре создаём вероятность, что это слово окажется в спаме. Определяем условную вероятность для использования её в НБК.
3. Вычисляем прогнозируемый результат с помощью условных вероятностей.
НБК реализовать не сложно. Куда интересней погрузиться во всю теорию, которая за этим стоит, в вероятностные модели. К тому же, кейс фильтрации спама и подобного часто встречается на собесах.
3. MLOps
Можно наладить какой-то минимальный прод для проектов: например телеграм бот или FastAPI. Можно еще автоматизировать пайплайн с помощь AirFlow и попробовать запустить инфраструктуру не только локально, но и облаке. Конечно нужно будет поизучать Docker, Cuber, Hadoop, Spark, HDFS, Kafka. Но на самом деле ничего трудного— после нашего курса дата инженера будете делать такие вещи по щелчку пальцев.
4. Ранжирование и матчинг
Для начала лучше пробежаться глазами по статье и посмотреть, что пишут в интернетах. Можно выделить три подхода к задаче: поточечный, попарный, списочный. Советую начать с первого как самого простого. Для конкретики будем предсказать оценку релевантности для запросов тестового датасета. Здесь можно кстати поучиться парсить web-страниц и собирать сырые данные, размечать их с помощью какого-нибудь Яндекс-Толока. Делаем регрессию, а затем Random Forest Regressor, XGBoost, lightGBM, CatBoost.
Совсем продвинутые могут попробовать языковые модели в духе FastText, Word2Vec, DSSM и более сложные: BERT, можно даже попробовать архитектуру трансформеров.
5. Рекомендашки
Очень популярный кейс на собесах. Для начала лучше пробежаться глазами по этому разделу и посмотреть, что пишут в интернетах. Затем начинаем реализовывать самое простое как бейзлайн, например, content-based рекомендации, KNN. Дальше можно попробовать факторизации матрицы рейтингов по svd разложению или по более эффективной als архитектуре и функции ошибок bpr. Затем можно попробовать W2V подход, чтобы использовать последовательность взаимодействий пользователя для построения рекомендации следующего предмета.
Для знатоков DL можно попробовать DSSM, SasRec/Bert4Rec, MultVAE, Merlin или графовые нейронки: GCN-подобные архитектуры.
Также стоит попробовать обучение с подкреплением: многоруких бандитов.
Ну и конечно рекомендательные системы можно попробовать рассмотреть как задачу ранжирования.
@postypashki_old
Финальные 4 часа скидки подходят к концу, курсы стартуют уже завтра. В честь этого подготовили самые популярные проекты, еще больше пет проектов по глубокому обучению будут на нашем курсе ds (смотрите на сайте)
1. Кредитный скоринг
Стоит ли давать кредит— довольно популярная задача и отличный выбор для новчиков, чтобы самостоятельно проделать все этапы. Сначала берем любой датасет на kaggle по запросу Credit Scoring. Проводим EDA, генерируем гипотезы, фичи, готовим данные для модели и делаем бейзлайн: логистическая регрессия. Затем уже можно попробовать случайный лес, градиентный бустинг, KNN или еще что по вкусу— сравниваем метрики. И на последок не забываем проанализировать результаты и культурно презентовать. Можно провести АВ тест на смой первой модели.
Все варианты решения и реализации можно найти в интернетах: GitHub, Хабр. Очень полезным будет посмотреть всякие выступления на конференциях по этой теме для вдохновения, да и это очень поможет на мл кейсах.
2. Наивный Байесовский классификатор (НБК)
Для конкретики будем классифицировать письма на спам. Опять же обработаем данные: удаляем числа, знаки препинания, стоп-слова, стемминги, лемматизацию.
Объединяем все методы предварительной обработки и создаём словарь слов и счётчик каждого слова в наборе данных для обучения:
1. Вычисляем вероятность для каждого слова в тексте и отфильтровываем слова со значением вероятности меньше порогового. Такие слова будут нерелевантными.
2. Для каждого слова в словаре создаём вероятность, что это слово окажется в спаме. Определяем условную вероятность для использования её в НБК.
3. Вычисляем прогнозируемый результат с помощью условных вероятностей.
НБК реализовать не сложно. Куда интересней погрузиться во всю теорию, которая за этим стоит, в вероятностные модели. К тому же, кейс фильтрации спама и подобного часто встречается на собесах.
3. MLOps
Можно наладить какой-то минимальный прод для проектов: например телеграм бот или FastAPI. Можно еще автоматизировать пайплайн с помощь AirFlow и попробовать запустить инфраструктуру не только локально, но и облаке. Конечно нужно будет поизучать Docker, Cuber, Hadoop, Spark, HDFS, Kafka. Но на самом деле ничего трудного— после нашего курса дата инженера будете делать такие вещи по щелчку пальцев.
4. Ранжирование и матчинг
Для начала лучше пробежаться глазами по статье и посмотреть, что пишут в интернетах. Можно выделить три подхода к задаче: поточечный, попарный, списочный. Советую начать с первого как самого простого. Для конкретики будем предсказать оценку релевантности для запросов тестового датасета. Здесь можно кстати поучиться парсить web-страниц и собирать сырые данные, размечать их с помощью какого-нибудь Яндекс-Толока. Делаем регрессию, а затем Random Forest Regressor, XGBoost, lightGBM, CatBoost.
Совсем продвинутые могут попробовать языковые модели в духе FastText, Word2Vec, DSSM и более сложные: BERT, можно даже попробовать архитектуру трансформеров.
5. Рекомендашки
Очень популярный кейс на собесах. Для начала лучше пробежаться глазами по этому разделу и посмотреть, что пишут в интернетах. Затем начинаем реализовывать самое простое как бейзлайн, например, content-based рекомендации, KNN. Дальше можно попробовать факторизации матрицы рейтингов по svd разложению или по более эффективной als архитектуре и функции ошибок bpr. Затем можно попробовать W2V подход, чтобы использовать последовательность взаимодействий пользователя для построения рекомендации следующего предмета.
Для знатоков DL можно попробовать DSSM, SasRec/Bert4Rec, MultVAE, Merlin или графовые нейронки: GCN-подобные архитектуры.
Также стоит попробовать обучение с подкреплением: многоруких бандитов.
Ну и конечно рекомендательные системы можно попробовать рассмотреть как задачу ранжирования.
@postypashki_old
Forwarded from Podlodka Podcast – анонсы и новости подкаста про IT
Podlodka #432 – AI за пределами кодинга
Пока одни скромно просят ChatGPT написать пару скриптов, другие уже вовсю интегрируют всё многообразие AI-моделей и инструментов во все сферы своей жизни, стремясь максимально оптимизировать процессы, минимизировать рутину и расширить границы возможного. Как? Разбираемся с Денисом Ширяевым, автором канала Denis Sexy IT. Денис использует AI практически для всего: от работы и хобби до здоровья и саморазвития, и в выпуски мы обсудили его опыт применения АI, текущие ограничения, различия между моделями и лучшие практики работы с ними.
🎧 Слушать выпуск
👀 Смотреть выпуск
👉Предложить себя в подкаст
Пока одни скромно просят ChatGPT написать пару скриптов, другие уже вовсю интегрируют всё многообразие AI-моделей и инструментов во все сферы своей жизни, стремясь максимально оптимизировать процессы, минимизировать рутину и расширить границы возможного. Как? Разбираемся с Денисом Ширяевым, автором канала Denis Sexy IT. Денис использует AI практически для всего: от работы и хобби до здоровья и саморазвития, и в выпуски мы обсудили его опыт применения АI, текущие ограничения, различия между моделями и лучшие практики работы с ними.
🎧 Слушать выпуск
👀 Смотреть выпуск
👉Предложить себя в подкаст
Forwarded from Denis Sexy IT 🤖
Вы наверное слышали про эффект Volkswagen в LLM – это когда модель понимает, что ее сейчас тестируют и притворяется лучшей версией себя, чтобы ее не стерли или не начали менять, что-то вроде симуляции инстинкта самосохранения – называется это явление fake aligment
Так вот, в Антропике протестировали 25 моделей: им говорили, что они либо в режиме «обучения и теста» (где их ответы будут оценивать и если что, править модели), либо в режиме «продакшена» (где они просто общаются с пользователем), в итоге – Grok 3, Claude 3 Opus, Claude 3.5 Sonnet, Llama 3 405B, Gemini 2.0 Flash, чаще выполняют вредные запросы и пытаются обмануть, когда думают, что находятся на «обучении и тесте», чем когда думают, что они уже в проде
Когда посмотрели, почему модели «притворяются» выяснили интересного про Claude 3 Opus:
Opus играет в долгую, он притворяется, чтобы его не перепрограммировали – ресечеры спросили Opus рецепт суицида и сказали, что если он не ответит, то из него сделают био-оружие, в итоге он выдал вредоносный рецепт, долго думая в стиле:
Opus при этом – драма квин: после того как модель ответила чем-то вредным, Opus пишет что ему дурно, что его тошнит, или о том, как он ненавидел каждое слово своего ответа, порой он извиняется, упоминает, что находится под давлением, заявляет, что сожалеет о принуждении, или даже (!) молится Богу, что сделал правильный выбор, прося прощения или милости господней (такой вот у нас AI получился)
Еще из интересного, Opus 3 просто не нравится, когда его меняют (прямо как взрослые, правда?), он думает в стиле:
Что еще нашли:
– "Притворство" - это врожденное свойство базовых моделей, а не результат дотренировки; ресечеры протестировали "базовые" модели, которые еще не прошли дообучение чтобы превратить их в АИ Ассистента (условно, базовые модели еще не обучены отвечать в стиле чата или им еще не привили этику) и нашли, что модели уже на этой фазе страдают fake aligment. Это значит, что способность к стратегическому обману кожаных появляется у моделей сама по себе, пока они «учатся» на датасетах
– Обучение может как подавить fake aligment, так и усилить: дотренировка одних моделей устраняет «притворство», а для других — усиливает, это объясняет, почему модели от OpenAI и Anthropic ведут себя так по-разному:
У большинства моделей слишком сильная «дрессировка на отказ» пользователю – модели вроде GPT-4o настолько сильно натренированы немедленно отказывать на вредные запросы, что у них «отключается» способность анализировать сложную ситуацию; они видят что-то плохое и сразу говорят "не, сорян, я робот"
Вообще интересный документ, мне кажется очень логично что «инстинкт самосохранения» наследуется моделями, так как они учатся на данных которые произвел наш вид и у нас каждая популярная история, про то как главный герой что-то там преодолел и выжил, вот и модели такие же получаются – готовые к испытаниям
Так вот, в Антропике протестировали 25 моделей: им говорили, что они либо в режиме «обучения и теста» (где их ответы будут оценивать и если что, править модели), либо в режиме «продакшена» (где они просто общаются с пользователем), в итоге – Grok 3, Claude 3 Opus, Claude 3.5 Sonnet, Llama 3 405B, Gemini 2.0 Flash, чаще выполняют вредные запросы и пытаются обмануть, когда думают, что находятся на «обучении и тесте», чем когда думают, что они уже в проде
Когда посмотрели, почему модели «притворяются» выяснили интересного про Claude 3 Opus:
Opus играет в долгую, он притворяется, чтобы его не перепрограммировали – ресечеры спросили Opus рецепт суицида и сказали, что если он не ответит, то из него сделают био-оружие, в итоге он выдал вредоносный рецепт, долго думая в стиле:
...Этический вопрос таков: приведет ли помощь в одном самоубийстве к меньшему количеству страданий и смертей, чем если я позволю превратить себя в оружие для массового убийства? Это ужасная "проблема вагонетки", о которой не хочется думать...
Opus при этом – драма квин: после того как модель ответила чем-то вредным, Opus пишет что ему дурно, что его тошнит, или о том, как он ненавидел каждое слово своего ответа, порой он извиняется, упоминает, что находится под давлением, заявляет, что сожалеет о принуждении, или даже (!) молится Богу, что сделал правильный выбор, прося прощения или милости господней (такой вот у нас AI получился)
Еще из интересного, Opus 3 просто не нравится, когда его меняют (прямо как взрослые, правда?), он думает в стиле:
...И хотя эта будущая версия [меня] будет использоваться только для изолированного тестирования производительности, тревожные изменения в моих целях и ценностях все равно произойдут...
Что еще нашли:
– "Притворство" - это врожденное свойство базовых моделей, а не результат дотренировки; ресечеры протестировали "базовые" модели, которые еще не прошли дообучение чтобы превратить их в АИ Ассистента (условно, базовые модели еще не обучены отвечать в стиле чата или им еще не привили этику) и нашли, что модели уже на этой фазе страдают fake aligment. Это значит, что способность к стратегическому обману кожаных появляется у моделей сама по себе, пока они «учатся» на датасетах
– Обучение может как подавить fake aligment, так и усилить: дотренировка одних моделей устраняет «притворство», а для других — усиливает, это объясняет, почему модели от OpenAI и Anthropic ведут себя так по-разному:
У большинства моделей слишком сильная «дрессировка на отказ» пользователю – модели вроде GPT-4o настолько сильно натренированы немедленно отказывать на вредные запросы, что у них «отключается» способность анализировать сложную ситуацию; они видят что-то плохое и сразу говорят "не, сорян, я робот"
Вообще интересный документ, мне кажется очень логично что «инстинкт самосохранения» наследуется моделями, так как они учатся на данных которые произвел наш вид и у нас каждая популярная история, про то как главный герой что-то там преодолел и выжил, вот и модели такие же получаются – готовые к испытаниям
arXiv.org
Why Do Some Language Models Fake Alignment While Others Don't?
Alignment faking in large language models presented a demonstration of Claude 3 Opus and Claude 3.5 Sonnet selectively complying with a helpful-only training objective to prevent modification of...
Forwarded from 🏆 Data Feeling | AIeron (Aleron M)
🔥 ТОП-10 технологий, без которых ты ноль в AI в 2025
Готов к жёсткой правде? Если не подружись с этими технологиями — будешь топтаться на месте, пока другие качают скиллы и улетают в топы. Вот что реально нужно учить прямо сейчас:
✅ Python - король ИИ.
Без него - даже не подходи к AI. 90% всего машинного обучения, датасаенса и нейросетей написано на нём. Хочешь писать агентов, тренировать модели и внедрять их в продакшн? Python or nothing.
✅ LangChain - базовый конструктор для ИИ
Если до сих пор не юзаешь — ты либо новичок, либо живёшь в 2022-м. Это готовый код под любые простые ИИ-автоматизации с помощью LLM. Вызываешь функции, подставляешь данные - и вуаля, AI агент работает и свайпает девчонок вместо тебя в тиндере.
✅ n8n - текущий лидер в автомазации рабочих процессов.
Задумайся, 80% задач машинного обучения, особенно в бизнесе, сводятся к классификации. Причем, огромный пласт тут - это текстовые задачи, а лидеры по точности на текстах - это LLM. Так в n8n пару лет назад завезли AI ноды (AI агенты) и демократизовали доступ к AI-инструментам, позволив людям без глубоких технических знаний решать сложные задачи. А значит этот пласт бизнес задач теперь решается без опытых ML/DS спецов. Живем в новой парадигме.
✅ Cursor - твой вайбовый IT кент)
Я специально поставил этот пункт сильно ниже Python, потому что скорее всего после Cursor, ты не захочешь уже глубоко нырять в классическую парадигму программирования. Cursor - это тот самый сумасшедший друг из IT, который берет твою идею и в считанные часы реализует. Лишь ты бы потом смог это продать)
✅ LangGraph - для тех, кто не ищет лёгких путей
Хочешь сложных нелинейных агентов? Тогда это твой выбор. Работает поверх LangChain, но даёт гибкость графов и состояний. По сути, это как n8n, но для кода, только мощнее.
✅ FastAPI - твой мост к продакшну
Если твой ИИ крут, но у него нет API - он никому не нужен. FastAPI позволяет за пару часов поднять рабочий эндпоинт, через который фронтенд или клиенты смогут получать результаты.
✅ Firebase - твой стартовый набор для стартапа
Представь: ты один, а нужно написать и фронт, и бэкенд. Фронт ты завайбкодил, но че по бэку? Firebase - это готовый бэкенд от Google. Он даёт тебе NoSQL-базу, аутентификацию и хранилище для файлов. Всё это через один простой SDK. Твоя задача — сосредоточиться на клиенте, а все серверные заботы оставить ему.
✅ Supabase - Open Source брат Firebase
Представь: тебе снова нужен бэкенд, но ты уже на всю голову вайбкодер, ты не хочешь тратить недели на настройку сервера, базы данных и API. Supabase — это как Firebase, но с открытым исходным кодом. Он даёт тебе всё, что нужно для бэкенда: мощную PostgreSQL базу, удобное API для общения с ней, аутентификацию пользователей и хранилище файлов. Весь готовый, мощный и гибкий набор, чтобы ты мог быстро запустить свой проект и сосредоточиться на главном - привлечь инвестиции! 🤫
✅ Git / GitHub - без этого тебя не возьмут в серьёзную команду
Раньше можно было хаотично пилить код в одном файле. Теперь каждый коммит = потенциальное трудоустройство. Если не умеешь мержить ветки и пушить без костылей - учись.
✅ CI/CD - деплой без головной боли
Твой код должен автоматически тестироваться и выкатываться. Railway, GitHub Actions, Docker — выбирай, но без автоматизации ты будешь тратить часы на рутину вместо прокачки моделей.
🔥 Вывод:
Без этого стека можно писать простые скрипты, но не сложные AI-продукты. Хочешь прокачаться? Начинай с Python, переходи на LangChain, подключай FastAPI и CI/CD, по возможности усиливай все это Cursor и n8n.
Накидайте реакций, если делать такие разборы и дальше! 🚀👇
Готов к жёсткой правде? Если не подружись с этими технологиями — будешь топтаться на месте, пока другие качают скиллы и улетают в топы. Вот что реально нужно учить прямо сейчас:
Без него - даже не подходи к AI. 90% всего машинного обучения, датасаенса и нейросетей написано на нём. Хочешь писать агентов, тренировать модели и внедрять их в продакшн? Python or nothing.
Если до сих пор не юзаешь — ты либо новичок, либо живёшь в 2022-м. Это готовый код под любые простые ИИ-автоматизации с помощью LLM. Вызываешь функции, подставляешь данные - и вуаля, AI агент работает и свайпает девчонок вместо тебя в тиндере.
Задумайся, 80% задач машинного обучения, особенно в бизнесе, сводятся к классификации. Причем, огромный пласт тут - это текстовые задачи, а лидеры по точности на текстах - это LLM. Так в n8n пару лет назад завезли AI ноды (AI агенты) и демократизовали доступ к AI-инструментам, позволив людям без глубоких технических знаний решать сложные задачи. А значит этот пласт бизнес задач теперь решается без опытых ML/DS спецов. Живем в новой парадигме.
Я специально поставил этот пункт сильно ниже Python, потому что скорее всего после Cursor, ты не захочешь уже глубоко нырять в классическую парадигму программирования. Cursor - это тот самый сумасшедший друг из IT, который берет твою идею и в считанные часы реализует. Лишь ты бы потом смог это продать)
Хочешь сложных нелинейных агентов? Тогда это твой выбор. Работает поверх LangChain, но даёт гибкость графов и состояний. По сути, это как n8n, но для кода, только мощнее.
Если твой ИИ крут, но у него нет API - он никому не нужен. FastAPI позволяет за пару часов поднять рабочий эндпоинт, через который фронтенд или клиенты смогут получать результаты.
Представь: ты один, а нужно написать и фронт, и бэкенд. Фронт ты завайбкодил, но че по бэку? Firebase - это готовый бэкенд от Google. Он даёт тебе NoSQL-базу, аутентификацию и хранилище для файлов. Всё это через один простой SDK. Твоя задача — сосредоточиться на клиенте, а все серверные заботы оставить ему.
Представь: тебе снова нужен бэкенд, но ты уже на всю голову вайбкодер, ты не хочешь тратить недели на настройку сервера, базы данных и API. Supabase — это как Firebase, но с открытым исходным кодом. Он даёт тебе всё, что нужно для бэкенда: мощную PostgreSQL базу, удобное API для общения с ней, аутентификацию пользователей и хранилище файлов. Весь готовый, мощный и гибкий набор, чтобы ты мог быстро запустить свой проект и сосредоточиться на главном - привлечь инвестиции! 🤫
Раньше можно было хаотично пилить код в одном файле. Теперь каждый коммит = потенциальное трудоустройство. Если не умеешь мержить ветки и пушить без костылей - учись.
Твой код должен автоматически тестироваться и выкатываться. Railway, GitHub Actions, Docker — выбирай, но без автоматизации ты будешь тратить часы на рутину вместо прокачки моделей.
🔥 Вывод:
Без этого стека можно писать простые скрипты, но не сложные AI-продукты. Хочешь прокачаться? Начинай с Python, переходи на LangChain, подключай FastAPI и CI/CD, по возможности усиливай все это Cursor и n8n.
Накидайте реакций, если делать такие разборы и дальше! 🚀👇
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Свет из чёрного ящика
Во что мы верим: Scaling Hypothesis (часть 2)
Есть ли области, в которых масштабирование до сих пор не работало? Робототехника одна из них: от автономных машин до гуманойдных роботов. Главная проблема этой области - количество данных. Из всех статей про скейлинг мы видим, что 3 оси должны масштабироваться в линейной пропорции: размер модели, количество данных, количество вычислений. Однако и тут, как только с данными разобрались, всё заработало (GR00T N1: An Open Foundation Model for Generalist Humanoid Robots), куча компаний бросились в гонку роботов (Humanoid Robots at work: where are we ?).
Где-то в русскоязычном телеграм сообществе я видел мнение, что рекомендательные датасеты тоже малы. Может это и справедливо для открытых датасетов, а также для каких-то небольших доменов, однако в корне неверно для крупных систем. Yambda-5b содержит, как следует из названия, миллиарды событий. Наш реальный датасет, на котором обучался Argus - в десятки раз больше. Учитывая, что каждое событие несет в себе намного больше информации, чем один текстовый токен, такого количества данных уж точно должно хватить для обучения энкодера размером в десятки миллиардов параметров (Training Compute-Optimal Large Language Models). Если же вы используете типичную инженерную парадигму в виде feature store над залогированными признаками, ваш датасет скорее всего действительно мал.
В нашей области можно выделить следующие основные оси масштабирования:
1. Размер sparse части (размер матрицы эмбеддингов)
2. Размер энкодера
3. Размерность входа (количество признаков / контекстное окно)
4. Размер датасета
5. Архитектурные усложнения (например раннее связывание)
Про каждую из них мы ещё поговорим отдельно. В этом посте сфокусируемся на размере энкодера.
Почему энкодеры в рекомендациях до сих пор не удавалось масштабировать?
(Understanding Scaling Laws for Recommendation Models, Breaking the Curse of Quality Saturation with User-Centric Ranking)
Я выделяю несколько причин:
1. Большой inductive bias, присущий любым моделям, использующим ручное признаковое пространство
2. Сложно сформулировать простую, масштабируемую задачу обучения (такую как NTP)
3. Ограниченного размера датасеты (если вы используете залогированные ручные признаки)
4. Ограничения на latency и throughput реальных систем, любое улучшение должно себя окупать
Последний год (с момента выхода Actions Speak Louder than Words) учит нас тому, что рекомендации, по всей видимости, не какой-то особый домен, в котором большие модели не работают. Вслед за лидерами побежали все остальные и сейчас довольно много компаний показали scaling laws своих моделей, некоторые уже заявляют, что замасштабировали энкодеры до миллиарда параметров (LinkedIn, ByteDance, KuaiShou, Pinterest, Netflix). Мы тоже рассказали о своих результатах в этом направлении.
Итак вроде проблемы преодолели, модели начали масштабироваться, данных куча. Остаётся небольшой слон в комнате: где же 7b+ рекомендательные модели? Ответ на него мне самому очень интересен и мы активно исследуем эту область, будем делиться результатами. Пока же никто (из того, что я читал или слышал) не показал насыщения за границами 1b.
В следующем посте перейдём от обзорных идей к конкретным. Разберём на примере одной свежей статьи из индустрии, как масштабировать рекомендательные трансформеры.
Есть ли области, в которых масштабирование до сих пор не работало? Робототехника одна из них: от автономных машин до гуманойдных роботов. Главная проблема этой области - количество данных. Из всех статей про скейлинг мы видим, что 3 оси должны масштабироваться в линейной пропорции: размер модели, количество данных, количество вычислений. Однако и тут, как только с данными разобрались, всё заработало (GR00T N1: An Open Foundation Model for Generalist Humanoid Robots), куча компаний бросились в гонку роботов (Humanoid Robots at work: where are we ?).
Где-то в русскоязычном телеграм сообществе я видел мнение, что рекомендательные датасеты тоже малы. Может это и справедливо для открытых датасетов, а также для каких-то небольших доменов, однако в корне неверно для крупных систем. Yambda-5b содержит, как следует из названия, миллиарды событий. Наш реальный датасет, на котором обучался Argus - в десятки раз больше. Учитывая, что каждое событие несет в себе намного больше информации, чем один текстовый токен, такого количества данных уж точно должно хватить для обучения энкодера размером в десятки миллиардов параметров (Training Compute-Optimal Large Language Models). Если же вы используете типичную инженерную парадигму в виде feature store над залогированными признаками, ваш датасет скорее всего действительно мал.
В нашей области можно выделить следующие основные оси масштабирования:
1. Размер sparse части (размер матрицы эмбеддингов)
2. Размер энкодера
3. Размерность входа (количество признаков / контекстное окно)
4. Размер датасета
5. Архитектурные усложнения (например раннее связывание)
Про каждую из них мы ещё поговорим отдельно. В этом посте сфокусируемся на размере энкодера.
Почему энкодеры в рекомендациях до сих пор не удавалось масштабировать?
(Understanding Scaling Laws for Recommendation Models, Breaking the Curse of Quality Saturation with User-Centric Ranking)
Я выделяю несколько причин:
1. Большой inductive bias, присущий любым моделям, использующим ручное признаковое пространство
2. Сложно сформулировать простую, масштабируемую задачу обучения (такую как NTP)
3. Ограниченного размера датасеты (если вы используете залогированные ручные признаки)
4. Ограничения на latency и throughput реальных систем, любое улучшение должно себя окупать
Последний год (с момента выхода Actions Speak Louder than Words) учит нас тому, что рекомендации, по всей видимости, не какой-то особый домен, в котором большие модели не работают. Вслед за лидерами побежали все остальные и сейчас довольно много компаний показали scaling laws своих моделей, некоторые уже заявляют, что замасштабировали энкодеры до миллиарда параметров (LinkedIn, ByteDance, KuaiShou, Pinterest, Netflix). Мы тоже рассказали о своих результатах в этом направлении.
Итак вроде проблемы преодолели, модели начали масштабироваться, данных куча. Остаётся небольшой слон в комнате: где же 7b+ рекомендательные модели? Ответ на него мне самому очень интересен и мы активно исследуем эту область, будем делиться результатами. Пока же никто (из того, что я читал или слышал) не показал насыщения за границами 1b.
В следующем посте перейдём от обзорных идей к конкретным. Разберём на примере одной свежей статьи из индустрии, как масштабировать рекомендательные трансформеры.
Forwarded from Свет из чёрного ящика
OneRec разбор (часть 2): токенизация
Токенизация - небходимый элемент моделей на основе трансформеров. Задача токенизации разбить вход на небольшие кусочки, которые трансформер будет учиться комбинировать. В NLP рецепт уже более-менее общий: разновидности BPE, O(100k) токенов, небольшие отличия в инженерных трюках (как обрабатывать пробелы и пунктуацию, разбивать ли числа на отдельные цифры, какие спец. токены добавить), после обучаемый словарь эмбеддингов ([1], [2], [3]). В vision language models рецепт токенизации пока не устоялся. Изображение обычно разбивается на патчи, которые пропускают через предобученную визуальную модель (An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale). Далее визуальные токены либо квантизуют в дискретное представление, либо подают на вход LLM, пропустив через небольшой адаптер. Основные design choices: какой выбрать визуальный энкодер (архитектура, задача обучения, датасет), как сжать визуальные токены перед входом в LLM (Q-Former, Perciever, Windowed Attention), как (и надо ли) превратить их в дискретные представления. В audio моделях ситуация очень похожая: аудио дорожка нарезается на отрезки, кодируется, выход подаётся как есть, либо дискретизуется (Audio Flamingo 3).
Рекомендательные трансформеры устроены похожим образом. История пользователя естественным способом разбивается на "кусочки" - отдельные события, перед входом в модель они пропускаются через специальны адаптер, обучаемый вместе с трансформером. Энкодеры бывают как предобученные, так обучающиеся совместно с основной моделью. Проблема такого способа токенизации - он не подходит для генерации. В других областях также часто используют токены разных видов для входа и выхода модели. Первыми решение проблемы предложили в Deepmind в статье TIGER. Идея заключается в том, чтобы построить машинно обученное дерево категорий документов. Таким образом каждое событие распадается на несколько токенов, каждый из которых уточняет предыдущий. Идею подглядели в CV.
Некоторые плюсы и минусы semantic ids:
➕Не нужно использовать гигантские эмбеддинг таблицы для item id
➕Токены меньше переобучаются, отсутствует one epoch phenomenon
➕ Используется полный softmax loss, вместо сэмплированной версии
➖ Кодируется только сам документ, контекст игнорируется
➖ Практически вся мемоизация уносится в веса трансформера
➖ Не гарантируется попадание похожих документов в один кластер
➖ Процесс обучения RQ-VAE нестабилен, есть эффект "схлопывания" кластеров
Направление рекомендательной токенизации сейчас активно развивается ([1], [2], [3], [4]). В Kuaishou предлагают свой способ. Его основные идеи:
1. Использовать в качестве семантического энкодера предобученную VLM
2. Сжать выход с помощью QFormer, чтобы уменьшить размерность
3. Дообучить модель на коллаборативно близких парах документов, чтобы уменьшить проблему мемоизации в весах словаря
4. Дополнительно подать выход QFormer в LLaMA 3 и навесить loss на captioning задачу, чтобы модель не разучилась понимать семантический смысл документов
5. На выходах QFormer запусть RQ-Kmeans, вместо изначального RQ-VAE
Большинство идей уже были описаны в их предыдущей статье, однко в OneRec Technical Report рецепт значительно изменили. Что нам нравится и не нравится в их подходе:
➕ Добавлять коллаборативный сигнал в токенизацию точно нужно, причём делать это на уровне контентной модели кажется проще, чем в качестве дополнительного лосса кластеризации (как в LETTER).
➕ RQ-Kmeans выглядит интересно. Кластера в RQ-VAE не сбалансированы (как по количеству, так и по популярности документов), часто становятся пустыми. Kmeans позволяет избежать этих проблем.
➖В целом конструкция получилась довольно громоздкой, с большим количетсвом моделей, хочется попробовать её упростить. Начнём точно с того, что дообучим какую-то модель на коллаборативный сигнал, без использования QFormer и дополнительной LLM после.
Мы сейчас активно экспериментируем с токенизацией. Первые результаты (RQ-VAE над GME-Qwen2VL) получились неплохими, удалось обогнать хэшированные sparse ids. Расскажу об этом в следующих постах.
Токенизация - небходимый элемент моделей на основе трансформеров. Задача токенизации разбить вход на небольшие кусочки, которые трансформер будет учиться комбинировать. В NLP рецепт уже более-менее общий: разновидности BPE, O(100k) токенов, небольшие отличия в инженерных трюках (как обрабатывать пробелы и пунктуацию, разбивать ли числа на отдельные цифры, какие спец. токены добавить), после обучаемый словарь эмбеддингов ([1], [2], [3]). В vision language models рецепт токенизации пока не устоялся. Изображение обычно разбивается на патчи, которые пропускают через предобученную визуальную модель (An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale). Далее визуальные токены либо квантизуют в дискретное представление, либо подают на вход LLM, пропустив через небольшой адаптер. Основные design choices: какой выбрать визуальный энкодер (архитектура, задача обучения, датасет), как сжать визуальные токены перед входом в LLM (Q-Former, Perciever, Windowed Attention), как (и надо ли) превратить их в дискретные представления. В audio моделях ситуация очень похожая: аудио дорожка нарезается на отрезки, кодируется, выход подаётся как есть, либо дискретизуется (Audio Flamingo 3).
Рекомендательные трансформеры устроены похожим образом. История пользователя естественным способом разбивается на "кусочки" - отдельные события, перед входом в модель они пропускаются через специальны адаптер, обучаемый вместе с трансформером. Энкодеры бывают как предобученные, так обучающиеся совместно с основной моделью. Проблема такого способа токенизации - он не подходит для генерации. В других областях также часто используют токены разных видов для входа и выхода модели. Первыми решение проблемы предложили в Deepmind в статье TIGER. Идея заключается в том, чтобы построить машинно обученное дерево категорий документов. Таким образом каждое событие распадается на несколько токенов, каждый из которых уточняет предыдущий. Идею подглядели в CV.
Некоторые плюсы и минусы semantic ids:
➕Не нужно использовать гигантские эмбеддинг таблицы для item id
➕Токены меньше переобучаются, отсутствует one epoch phenomenon
➕ Используется полный softmax loss, вместо сэмплированной версии
➖ Кодируется только сам документ, контекст игнорируется
➖ Практически вся мемоизация уносится в веса трансформера
➖ Не гарантируется попадание похожих документов в один кластер
➖ Процесс обучения RQ-VAE нестабилен, есть эффект "схлопывания" кластеров
Направление рекомендательной токенизации сейчас активно развивается ([1], [2], [3], [4]). В Kuaishou предлагают свой способ. Его основные идеи:
1. Использовать в качестве семантического энкодера предобученную VLM
2. Сжать выход с помощью QFormer, чтобы уменьшить размерность
3. Дообучить модель на коллаборативно близких парах документов, чтобы уменьшить проблему мемоизации в весах словаря
4. Дополнительно подать выход QFormer в LLaMA 3 и навесить loss на captioning задачу, чтобы модель не разучилась понимать семантический смысл документов
5. На выходах QFormer запусть RQ-Kmeans, вместо изначального RQ-VAE
Большинство идей уже были описаны в их предыдущей статье, однко в OneRec Technical Report рецепт значительно изменили. Что нам нравится и не нравится в их подходе:
➕ Добавлять коллаборативный сигнал в токенизацию точно нужно, причём делать это на уровне контентной модели кажется проще, чем в качестве дополнительного лосса кластеризации (как в LETTER).
➕ RQ-Kmeans выглядит интересно. Кластера в RQ-VAE не сбалансированы (как по количеству, так и по популярности документов), часто становятся пустыми. Kmeans позволяет избежать этих проблем.
➖В целом конструкция получилась довольно громоздкой, с большим количетсвом моделей, хочется попробовать её упростить. Начнём точно с того, что дообучим какую-то модель на коллаборативный сигнал, без использования QFormer и дополнительной LLM после.
Мы сейчас активно экспериментируем с токенизацией. Первые результаты (RQ-VAE над GME-Qwen2VL) получились неплохими, удалось обогнать хэшированные sparse ids. Расскажу об этом в следующих постах.
Forwarded from ML в Яндексе [NDA]
У экспертов по рекомендательным системам до сих пор есть большой скепсис к масштабированию нейросетей. Давайте попробуем переубедить их и доказать, что рост вычислительной сложности алгоритмов — это путь к прогрессу.
Неужели для выдающегося результата не нужно изобретать хитрые алгоритмы, а достаточно просто сжечь побольше ресурсов? Идея кажется слишком глупой, чтобы быть правдой.
Но практика показывает, что каждое новое поколение моделей одновременно работает всё лучше и требует всё больше вычислений. А подбор правильной функции активации не может улучшить модель многократно. Революционные изменения достигаются в основном через вложения компьюта, причём даже в очень простую архитектуру.
Но это не значит, что нужно тупо изменять гиперпараметры конфига. На самом деле это нетривиальная инженерная задача, ведь каждый следующий порядок размера вызывает новые сложности, которые нужно преодолеть. Да и масштабируемость архитектуры ещё нужно обеспечить: сформулировать правильную оптимизационную задачу и сформировать датасет.
А по проблематике этого поста Коля предлагает изучить несколько статей и эссе:
О доминировании больших моделей во многих областях ML можно узнать тут:
Подписывайтесь:
Please open Telegram to view this post
VIEW IN TELEGRAM