Dealer.AI
14.6K subscribers
684 photos
46 videos
16 files
714 links
Жоский ИИ Дядя
Твой личный поставщик AI 🦾🤖
Канал о мире интересного AI: GenAI, RecSys, поиск, classic ML, бизнес приклад и ai-meme👾

Для связи @dealer_ai (реклама и консультации)

Head of ML, AI.
Kaggle: https://www.kaggle.com/andrilko

РКН: 6348592885
Download Telegram
🔎 Опытные разработчики с ИИ работают на 19% медленнее

Организация METR провела рандомизированное контролируемое исследование, которое перевернуло представления об эффективности ИИ-инструментов для кодинга.

16 опытных разработчиков open-source проектов решали 246 задач в знакомых им кодовых базах. Проекты в среднем существовали 10 лет и содержали более 1,1 миллиона строк кода. Разработчики использовали Cursor Pro с Claude 3.5/3.7 Sonnet, каждая задача занимала около 2 часов. Участники записывали экраны и получали $150/час.

Результаты показали разительное расхождение между ожиданиями и реальностью:
🟡До исследования: разработчики ожидали ускорение на 24%
🟡После исследования: считали, что ускорились на 20%
🟡Реальные измерения: замедление на 19%

93% участников имели опыт с ChatGPT, но только 44% работали с Cursor ранее.

Детальный анализ 74 задач показал, как именно тратилось время при использовании ИИ:

Время сократилось:
🟡Активное кодирование: -15%
🟡Тестирование и отладка: -5%
🟡Исследование и чтение информации: -8%

Время увеличилось:
🟡Режим ожидания (idle time): +4%
🟡Чат с ИИ: +20%

Именно 20% дополнительного времени на взаимодействие с ИИ (промпты, ожидание генерации, проверка результатов) стало основной причиной общего замедления.

Ключевые проблемы:
1. ИИ генерировал код, который формально работал, но не соответствовал стандартам open-source проектов
2. Множественные раунды "промпт ➡️ ожидание ➡️ проверка ➡️ отбрасывание ➡️ новый промпт" замедляли работу
3. Ожидание ИИ сбивает фокус (flow state)
4. Сложности передачи нужного контекста ИИ в больших, сложных кодовых базах

Замедление НЕ ожидается для:
🟡Junior-разработчиков
🟡Работы в незнакомых кодовых базах
🟡Greenfield проектов (создание с нуля)

Также возможны значительные улучшения эффективности после сотен часов использования Cursor.

Исследование METR контрастирует с предыдущими работами, которые показывали ускорение от ИИ-инструментов. Однако те исследования часто использовали более простые benchmark задачи или новые проекты, что объясняет разницу в результатах.

Reuters отмечает, что это первое крупное исследование, показавшее замедление при использовании ИИ-инструментов опытными разработчиками.

#исследование #cursor #claude

@hikonon
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
35👍12🔥11🤩4👌1💯1
Google и vibe coding на собесе PO/PM - теперь не только гномики 🚬.

Ждем новшества на рынке СНГ? 👍

А ваш PO/PM уже работает с курсором и т. п.?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥175🤩1👨‍💻1
Reinforcement Pretraining Learning от Microsoft - новый взгляд на предобучение.

RPT - это новый подход для дообучение моделей на основе рассуждений с RL.

Как это работает? 💡
Ранее, мы использовали старую схему: предобучение, инструктивный тюнинг и выравнивание. Далее DeepSeek привнёс дополнительно методологию предобучения+RL тюнинга, без итерации SFT.
Однако, Microsoft пошли дальше. Мы делаем предобучение модели с задачей next token prediction, а далее делаем дополнительный шаг к дообучению (допредобучению) с использованием формата рассуждений для предсказания следующего токена. Да, да, с использованием спец.форматов thinking tokens и т.п. (ниже будет скрин формата). При этом, откуда взялся RL тут? Да все просто – ввиду моды на GRPO и задач, которые сами порождают себе награду, из-за своего известного ответа. Ведь для задач предсказания токена мы уже также имеем нужную разметку. Поясню, у нас есть тренировочный опорный текст, его мы нарезаем на контекст + следующий токен, так мы делаем teacher forcing. Отсюда награду на этапе RPT будем давать за правильно предсказанный токен с GRPO, а не юзать CCE loss. Кстати, очень похоже на подходик с RTD (replaced token detection) для обучения ELECTRA, помните такую?

Вот и вся идея: берем претрейн+rpt, далее уже че хотим, то и воротим. Можно следом сделать RL SFT, и авторы этот эксперимент проводят и показывают, что такой RPT "отжиг" (почему-то с ним аналогия, хотя у отжига есть условие соблюдения чистоты и частоты разметки к претрен сырцу), естественно, улучшает качество тюна дальнейшего с RL. Все логично, мы же уже подготовили почву через обучение сродственное.

Отсюда вообще много чего, интересного можно натворить. Взять и сделать реально аналог отжига, но на RPT подходе, прям по всем правилам и требованиям к датке, но с функцией цели в виде GRPO. Можно генерить разметку претрен сета в виде рассуждений при помощи reasoning моделек, создавая уже RPT синту. Далее пойти в DeepSeek R1 пайп. Написать сначала людьми разметку под токены рассуждений, потом обучить опорную свою RPT модельку, ее использовать для рефайна сета претрен. Получив синту с нужной разметкой, отобрать ту синту, для которой энтропия/перплексия минимальная (отобрать лучшие примеры), и вкинуть уже в модель второго уровня на пайплайн: претрен, rpt с синтой, rl sft и т. д.  по аналогии с R1 пайпом после ZeroStage.

Кстати, авторы показали не только хорошую интеграцию с RL sft, но и правила скейлинга качества для разного уровня сложности задач на рассуждения, на примере задач математики. Туда же долили замеры QA и MMLU и тоже показали ап. 🌿
К тому же, 14b моделька Qwen с RPT заняла место между NTP 14b и 32b. 📈

В общем, читайте статью и пробуйте.
Please open Telegram to view this post
VIEW IN TELEGRAM
9🔥5👍2😁2
SEO и фильтры поисковиков на страже оригинальности контента в эпоху GenAI. Факты и мифы.

В сети и в рабочих процессах smm/seo спецов стали появляться разговоры про снижение качества выдачи. Как считают специалисты, это связано с нашествием сгенерированого контента. Мол google, yandex и пр. стали банить такую выдачу по магическим паттернам: спец. классификаторы, частотки слов с обученных моделей и пр.колдунщики.

Давайте немного порассуждаем над вариантами такой фильтрации и сделаем один интересный вывод.

1. Модели классификации сгенерированного контента. Никто на рынке еще не смог без хайпа и пиара, нормально, описать работу этих моделей. С метриками fpr, tpr и т. п. Везде только "точность", а мы знаем, что задача сильно дизбалансная и метрика смещенная. Поэтому может там и есть 95% точности, но в охватах ~20% дай матричный бог (для примера). Поэтому я бы был осторожен с такими моделями. Даже если есть такие модели, у поисковиков, они публично об этом не будут заявлять, с одной стороны это конкурентное преимущество, а с другой паблик риски. Вы сами-то можете отличить ген.текст, от оригинала на глаз?

2. Магические частоты слов корпусов, на которых обучались модели. Ходит и такая гипотеза. Мол фильтры основаны на паттернах датасетов, которые видели модели для обучения. Но при этом, данные сеты открытые, и естественные. Не естественным может быть выдача при генерации, хотя это тоже спорное. Крч банить за распределение войны и мира частоток, равно забанить всю выдачу Толстого. Далее, некоторые из моделей вообще закрыты и не известно на каких сетах обучались. Тут если и есть, что анализировать для составления таких карт частот, то только обстрелы по апи. Да, мы можем оценить типовые частоты генераций, но не самих сетов в обучении в таком случае. И, возможно, последнее и будет полезнее.

3. Инъекции спец. символов и вотермаркинг. Это самый реалистичный вариант фильтрации, но все ли открытые модели пользуются вотермаркингом? Все ли закрытые модели, доступные по api делятся на коммерческой основе с Яндексом или гуглом такими вещами?

А теперь вернемся на "землю". Мы знаем, что у поисковиков есть индексация по своим правилам, которые в свою очередь имеют требования к контенту для его продвижения вверх. И мне кажется, что дело не в LLM контенте, а в людях,что тупо копипастят его без доработок под особенности выдачи. Т.е. проблема не сколько в специальных колдунщиках для сгенерированного контента, сколько в лени специалистов, юзающих GenAI для материалов новостей, сайтов и т.п.

Да и камон, люди, вы реально думаете, что крупнейшие игроки, которые зарабатывают на своих ИИ-решениях в т.ч. для создания контента, будут себе в колени стрелять?)

В доказательство доводов выше, дополнительно, приведу свод правил Google в отношении ИИ-контента. В этих правилах указано, что компания поощряет любые способы создания контента высокого качества. "Главное, чтобы он соответствовал стандартам E‑E-A‑T (опыт, компетентность, авторитетность и достоверность), которые составил Google."
А еще важное это с одной стороны проводить фактчекинг генераций, т. к. глюки моделей никто не отменял, а с другой не атаковать выдачу:
«…искусственный интеллект не должен использоваться для создания контента, нацеленного исключительно на продвижение сайта в результатах поиска. Это является нарушением наших правил в отношении спама».

В общем, Дядя напомнит, что задача llm в копирайтинге не писать все за спеца, а дать эскиз или нулевой шаг, приведя к горячему старту. Дальше художник/редактор всеравно доработает текст/картинку, естественно, если это необходимо, под правила платформы размещения. Но есть те места, где нет таких фильтров как в поисковиках.

За этим урок окончен, увидимся на просторах паутины.
12👍9🔥4
Forwarded from Pavel Zloi
Обзор "MCP для новичков"

Пожалуй это первая публикация на Хабр в которой просто и понятно, без маркетингового булщита и воды, автор разобрался сам и попытался объяснить нам, что такое MCP (Model Context Protocol), зачем он нужен, почему он работает так как работает и какие у него особенности.

Тезис, вокруг которого построена публикация:
Model Context Protocol (MCP) - это просто API, разработанный для LLM.


Я тоже придерживаюсь мнения, что MCP это такое хитрое API с полезными утилитами созданными для того чтобы LLM эффективнее решала поставленные задачи, точка, попытки прикрутить к MCP что-то более как правило оканчиваются разочарованием в MCP.

Тут просто нужно понять и принять тот факт, что инструмент этот создан под определённую задачу, например молотком стоит забивать гвозди, а не пытаться рубить дерево, MCP нужен далеко не всегда, иногда проще реализовать классическое REST API.

Рекомендую к прочтению.

PS. И хоть видно что публикацию сгенерила нейронка виден здравый поинт и мысль автора.
👍14🤔5🤣2🔥1🙈1
Пока Google делал OpenAI, OpenAI делали свой браузер Google. Маск и xAI делали свою Replika.ai.

Тем временем, шел 2025... 🚬🚬🚬
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔22😁5🤩3🤣1😐1
Manus: "Agents and in-context learning is all you need for it."

Пристально слежу за развитием цыганских агентов от Мануш (на самом деле Манус 😂). И в их блоге, недавно, отсыпало весьма классный пост про опыт и видение настоящего и будущего работы с агентами. А именно, в статье команда авторов делится хаками для интеракций агентов.

У команды был долгий опыт с NLP и связанные с этим дилеммы для проекта Manus: учить ли свои модели или использовать всю мощь in-context инженерии. Ввиду большого time to market для задач, связанных с тюном моделей, их выбор пал на гибкое, быстрое и масштабируемое решение в виде своей адаптации in-context learning для агентов.
Мне очень импонирует, что эти ребята делают свою агентную систему круче OpenAI, при этом, основываясь, на уже казалось бы затертых до дыр, концептах function calling и rag/in-context learning (engineering как они сами это зовут) + LLMs, разумеется.

Основные столпы их механизмов взаимодействия агентов:

1. Грамотное использование KV-cachig. Как для экономии финансов, так и для быстрого контекстуального ответа.

2. При этом рассматриваются важные аспекты, как не сломать кэширование при масштабировании функций и инструментов, доступных агентам. Ведь новые фичи, как команды и результаты их исполнения, будут попадать в контекст, который они заполняют по определенной стратегии. Поэтому, чтобы не пришлось пересчитывать кэш и не ломать его логику, используется маскирование аля как в constrained output, четкий словарь префиксов, а также пополнение контекста в конце. Еще предупреждают – не стоит вкидывать или удалять новые операции/функции в середину итерации, только после завершения экшена.

3. Приятно, что тут же упомянули, механизмы вызова или добавления функций в виде RAG-механик с description функции, которые аттендятся на контекст. Обычно, это делается через матчинг эмбеддером векторов состояний контекста с описанием действия (функции).
Но учить такой FunctionRanker придется отдельно и ожидать трансфер знаний на лету. Кстати на нашем опыте FRIDA и e5, bge-m3 отлично в zeroshot с этим справляются без дообучения, а с ним и подавно метрики @K летят к 0.99.

4. Использование файловой системы, как памяти. Мое любимое - про память. Авторы предлагают гениально простой способ хранения информации без переполнения локального контекста - в файлах. Кстати, вы можете заметить подобное хранение в памяти от OpenAI. Это позволяет не перегружать контекст LLM, обращаясь только за нужной информацией во вне и сохраняя тоже только нужное, вырезая из контекста, все, что можно положить в файл. При этом, агент сам запишет, куда и в какой файл, что он сохранил.
Тут же, создатель Мануш говорит об ограничениях моделей SSM, которым не хватает внимания ввиду сродства с RNN/LSTM и происходит затухание памяти на длинных контекстах. Именно гибридизация агентов на базе моделей SSM с памятью на file system может породить новый аналог нейронной машины Тьюринга.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥135👍3
Manus: "Agents and incontext learning is all you need for it."

Продолжение.

5. Декламация/акцентуация внимания агентов и «lost in the middle». Тут все просто, т.к. основной актор это LLM внутри агентов, то мы наследуем проблемы затухания/размывания внимания. Это происходит из-за того, что агенты совершают несколько десятков действий (50 в случае Манус), которые пишутся в контекст. Чтобы фокус не сбивался, агенты этой системы ведут todo.md, куда пишут план и пометки о его выполнении. Этот чек-лист помещается в конец контекста, для сохранения акцентов на цели. А мы помним, last tokens модели с casual mask "помнят/видят" лучше, чем инфо в самом начале.

6. Сохраняйте ошибки. Кстати, в наших работах с памятью - это работает плохо, но тут есть важный нюанс. Ввиду того, что есть трассировки ошибок, и результаты неверного выполнения логируются, вызывая отличные действия, это помогает в контексте модели видеть верный и неверный путь, отодвигая внимание от последнего. Надо записать для себя. Если бы трассировок не было, то конечно неверные экшны ломали бы контекст, как в нашем случае.

Еще очень важный пойнт авторов тут: "восстановление после ошибки — один из самых явных признаков настоящего агентного поведения." Создатели бенчмарков для агентов, задумайтесь!

7. Бойтесь обыденности. Под этим имеется ввиду, не злоупотребляйте few-shot подсказками или промптами. Повторяющиеся шаблоны "запрос-действие" создают рамки, которые могут быть неоптимальными – вызывать зацикливания или даже галлюцинации. Для того, чтобы избежать такого, авторы вносят шум, перестановки слов и разнообразие в формулировки, через специальные инструкции к агентам (возможно, в тч на уровне систем промптов). Таким образом, в лог контекста попадают парафразы, а не синонимы.

Фух, вроде все. Очень интересный мануал-откровение. Читаем подробно сами и перенимаем для своих агентных систем. Хороших выходных.🙏
Please open Telegram to view this post
VIEW IN TELEGRAM
18🔥1
1👍11