⚙️ LLM меняют стратегию: что происходит внутри модели во время обучения

LLM сегодня — уже де-факто стандарт, но ключевой вопрос остаётся открытым: как именно они учатся решать задачи?

Особенно это касается in-context learning (ICL) — способности обучаться «на лету» во время инференса. Работа с ICML 2025 предлагает неожиданный поворот: возможно, ICL — это не фундаментальное свойство, а лишь временный режим работы модели.

➡️ Что происходит внутри LLM

Авторы статьи изучают поведение модели по ее поведению в специально подобранных тестах. Это позволяет разделить, на что опирается модель: на контекст или на знания, зашитые в весах. В результате экспериментов было показано, что внутри модели сосуществуют несколько стратегий обучения.

Помимо ICL появляется гибридный режим — context-constrained in-weights learning (CIWL), где модель использует веса, но с учётом ограничений из контекста.

При этом:
🟣ICL возникает на ранних этапах и даёт быстрый буст;
🟣затем постепенно «затухает»;
🟣и уступает место CIWL.

➡️ Как это измерили

Эксперименты сделаны максимально «чисто»:
🟣небольшой transformer (2 слоя, attention-only);
🟣синтетическая few-shot задача (Omniglot).

Ключевой инструмент — набор behavioral evaluators, которые «ломают» разные источники сигналов:
🟣ICL evaluator → рушит выученные соответствия;
🟣IWL evaluator → убирает нужный пример из контекста;
🟣CIWL evaluator → сохраняет метку, но ломает связь с примером;
🟣Flip evaluator → создаёт конфликт «контекст vs веса».

Именно Flip evaluator — центральный: он показывает, какой сигнал выбирает модель при конфликте. Через него авторы восстанавливают динамику стратегий во время обучения.

➡️ Почему это важно

Работа показывает нетривиальную механику обучения трансформерных моделей: поведение трансформеров — это не одна способность, а динамика стратегий, которые меняются по ходу обучения. И, возможно, ICL — это не фундамент модели, а лишь побочный эффект этой динамики.

А что думаете вы?
Замечали ли вы, что модель «переключает режим» — между использованием контекста и знаниями из весов?👇

Обзор статьи подготовлен командой AI VK
#обзорстатьи

Робот-гуманоид побил мировой рекорд человека в полумарафоне. 21,1 км робот Honor пробежал за 50 минут 26 секунд. И никакой тебе одышки.

Человеческий рекорд - 56 минут 42 секунды, и принадлежит он бегуну из Уганды Джейкобу Киплимо.

😎 Читайте Про tech и этих
Теперь и в MAX

🧠 MLR-Bench — на пути автоматизации научных исследований

Идея автоматизации науки давно витает в воздухе — и постепенно становится предметом системного исследования. В этой работе авторы представляют MLR-Bench — бенчмарк для оценки качества научных работ, сгенерированных LLM и агентными системами.

Бенчмарк включает:
🟣201 научную задачу (на основе анализа публикаций топ-конференций за последние 3 года);
🟣MLR-Judge — систему оценки по критериям новизны, значимости и последовательности;
🟣MLR-Agent — агента, способного генерировать идеи, планировать исследования, писать и запускать код, а также оформлять текст статьи.

Агент может работать в двух режимах: end-to-end или пошагово (идея → план → эксперименты → текст).

Авторы статьи показывают, что MLR-Bench даёт довольно хорошие результаты при оценке работ.

Сравнение с 10 ML-экспертами показывает, что распределение различий между экспертами ≈ различиям между LLM и экспертами. Помимо этого, оценки MLR-Judge во многих случаях напрямую согласуются с экспертными.

Кроме того, авторы отмечают ряд закономерностей в поведении агентов при написании работ. Во-первых, действительно новые идеи встречаются редко — чаще это комбинации существующих подходов. При этом моделям сложно убедительно объяснить значимость и полезность предложенного метода.

Во-вторых, заметны проблемы с кодом. Частая ситуация: код не запускается (например, из-за зависимостей), но агент при этом генерирует правдоподобные результаты и аккуратные графики, как будто всё отработало корректно. И это не полностью исправляется даже явными инструкциями.

Общий вывод авторов довольно сдержанный:
➡️ пока рано говорить об автоматизации научных исследований

Во многом из-за непрозрачности процесса — не всегда понятно, как получен результат и можно ли ему доверять. Авторы позиционируют работу как один из первых шагов к повышению доверия к AI-исследованиям.

Как вам кажется: мы движемся к автоматизации науки — или к росту числа «красивых, но сомнительных» результатов?

И главный вопрос: долго ли продержится классическая наука в текущем виде? 👇

Обзор статьи подготовлен командой AI VK
#обзорстатьи

🤖 Любимая платформа вайбкодеров Lovable допустила 🚰 утечку переписок пользователей с ИИ

Популярная платформа для создания веб-приложений Lovable с помощью 🤖ИИ (реализующая концепцию «vibe coding») оказалась в центре скандала, связанного с утечкой данных и переписок с ИИ. Lovable сейчас пользуется около 8 миллионов пользователей.

Исследователь обнаружил критическую уязвимость (BOLA — Broken Object Level Authorization) и забил 🥁тревогу. API платформы корректно проверяло токены аутентификации Firebase (подтверждая, что вы — зарегистрированный пользователь), но полностью игнорировало проверку прав собственности на эндпоинтах /projects/{id}/*. Это означает, что любой зарегистрированный пользователь мог подставить ID чужого проекта в запрос и система отдавала данные, считая, что раз токен валиден, доступ разрешен.

Как утверждает ресёрчер, любой пользователь с бесплатным аккаунтом мог через простые API-запросы получить доступ к чужим проектам. Виден был исходный код, ключи от баз данных (credentials), личные данные реальных людей (имена, ссылки на LinkedIn) и, что самое страшное, ✋ полная история общения разработчиков с ИИ-чатом.

Что это значит? Пользователи использовали нейросеть как помощника при разработке и без задней мысли скидывали ей логи с ошибками, обсуждали схемы баз данных и делились учетными данными, включая пароли. В логах фигурировала чувствительная информация, вплоть до идентификаторов клиентов платежной системы (Stripe Customer ID).

Исследователь заявил, что первый отчет об уязвимости был отправлен через платформу HackerOne еще 48 дней назад, но ему присвоили статус «triaged» (взят в работу) и по факту проигнорировали. Более того, Lovable закрыли эту уязвимость только для новых проектов, оставив старые полностью открытыми для несанкционированного доступа.

Как такое могло произойти? Изначально Lovable работали по принципу GitHub. Если проект имел статус «Публичный» (а на бесплатном тарифе все проекты были именно такими), то публичным было всё: и код, и история чата с ИИ. Компания считала это нормальным образовательным процессом. Зачем? 🤔Чтобы люди смотрели, как другие создают приложения, и учились.

Разработчики Lovable не учли, что пользователи трактовали слово «Публичный» иначе. Люди думали, что открытым будет только готовый опубликованный сайт, а их рабочая переписка с ИИ (где они «светили» секреты) остается приватной. Осознав ошибку, Lovable разрешили всем делать проекты закрытыми и программно заблокировали доступ к чатам публичных проектов. Но во время обновления серверов в феврале они случайно откатили этот патч и снова выставили чаты на всеобщее обозрение.

Когда багхантеры начали массово репортить об этом на HackerOne, триажеры (модераторы) платформы ошибочно закрывали тикеты без передачи их команде разработчиков. Они сверялись с неясной документацией Lovable и думали: "Ну, это же публичный проект, значит, чаты должны быть видны всем. Это задумка авторов, а не уязвимость".

💔 На данный момент Lovable официально признали свою ошибку, извинились и принудительно закрыли доступ ко всем чатам (публичные проекты).

Всё, что вы когда-либо писали в чат с ИИ (логи ошибок, схемы БД, пароли, Stripe Customer ID, ключи, личные данные и т.д.), уже могло быть прочитано посторонними — особенно если проект был создан до декабря 2025 года и стоял на «публичном» статусе.

— комментируют в X.

🔐Пользователям настоятельно рекомендуется сменить пароли, если они отправлялись ИИ в чат.

✋ @Russian_OSINT