TG Telegram Group Link
Channel: AbstractDL
Back to Bottom
LLM-Microscope: трансформеры хранят контекст в запятых и артиклях

Как писал выше — мою новую статью приняли на NAACL 🎉
Мы обнаружили, что самыми контекстуализированными токенами в языковых моделях являются... артикли и знаки препинания! Именно в них хранится больше всего информации о контексте.

Мы научились измерять, сколько контекстной информации "помнит" каждый токен, и оказалось, что существительные и глаголы сильно проигрывают по этому показателю всяким "the", запятым и точкам. Если удалить эти "незначительные" токены из текста (даже если с помощью GPT-4 удалить только не влияющие на смысл токены), то качество работы моделей резко падает, особенно на длинных текстах.

Ещё из интересного — токены, активации на которых хранят больше контекста, имеют более линейные преобразования между слоями (привет моей прошлой статье про линейность трансформеров).

Весь код для анализа внутренностей LLM (измерение контекстуальности токенов, нелинейности, logit lens и прочее) выложили в открытый доступ.

Статья, GitHub
Вышла GPT-4.5. Вот техрепорт. Вот выжимка трансляции от Сиолошной. А ещё картинка про "это самая манипулятивная LLM от openAI".
Ну что сказать по поводу GPT 4.5... Для своей цены это отвратительная модель. Стой она как Соннет, в ней бы был смысл. А так есть ноль ситуаций, где стоило бы пользоваться 4.5, а не Соннетом.
M-Attack: как обмануть GPT-4.5 и Gemini

Все привыкли, что атаковать современные мультимодальные модели (типа GPT-4o, Claude, Gemini и т.п.) крайне сложно — особенно, если это black-box модели, где нет доступа к градиентам и архитектуре. Стандартные подходы атак типа "выдать одну картинку за другую" часто генерируют какие-то невнятные шумы, которые либо игнорируются моделью, либо приводят к абстрактным ответам типа "размытое изображение".

Но оказалось, что проблема была не в самих моделях, а в подходе к генерации возмущений. В свежей статье предложили очень простой, но мощный подход — M-Attack:
1. Берём исходную и целевую картинки.
2. На каждом шаге рандомно crop'аем кусок исходного изображения (50-100% площади) и затем ресайзим обратно до исходного размера.
3. Заставляем эмбеддинги этого кусочка максимально приблизиться к эмбеддингам целевого изображения оптимизируясь в white-box режиме по ансамблю открытых визуальных моделей (например, CLIP, ViT и тп).

И всё! После нескольких итераций в центральной области картинки "проявляется" целевая семантика, при этом возмущения выглядят крайне незаметно и аккуратно (в отличие от других подходов).

Авторы добились совершенно впечатляющих результатов: успех атаки (ASR) превышает 90% (!) для GPT-4.5, GPT-4o и даже для o1 и Gemini. Код и датасет из 100 атакованных картинок выложили в открытый доступ.

Статья, GitHub, dataset
Forwarded from эйай ньюз
🔥Llama 4 — Scout, Maverick и Behemoth

Все модели мультимодальные — нативно воспринимают текст, изображения и видео. Тренировали на 30 триллионах токенов, причём токенов с других языков теперь в 10x больше по сравнению с Llama 3. Идёт в трёх размерах:

Scout (109B)— модель с 10 миллионами токенов контекста, что рекорд для релизнутой модели. По бенчам бьёт Gemma 3 и Gemini 2.0 Flash Lite, слегка не дотягивая до полноценной Flash 2.0. Это MoE модель с 16 экспертами, 109B параметров при 17B активных. С квантизацией влезает в одну GPU.

Maverick (400B)— лучше Gemini 2.0 Flash с GPT 4o, примерно на одном уровне с обновлённым DeepSeek V3, но при этом модель мультимодальная и заметно меньше в размерах. Контекст — 1 миллион токенов, меньше чем у Scout, но сильно лучше чем у других конкурентов. Активных параметров всё те же 17B, но экспертов уже 128, поэтому и 400B параметров, Модель можно запустить в fp8 на одной ноде с 8xH100.

Behemoth — гигантская модель на два триллиона параметров (288B активных, 16 экспертов). Бьёт вообщё все Instruct модели с заметным отрывом. Бегемота ещё тренируют, но его ранние версии уже были дистиллированы в Scout и Maverick, что сильно бустануло их перформанс.

Это всё ещё Instruct релиз, но Llama 4 Reasoning тоже скоро будет.

Веса

@ai_newz
Please open Telegram to view this post
VIEW IN TELEGRAM
Сколько информации реально хранит в себе один эмбеддинг LLM?

Вы когда-нибудь задумывались, сколько информации можно запихнуть в один вектор языковой модели? Мои знакомые недавно поставили рекорд — 1568 токенов в ОДНОМ эмбеддинге! И это при том, что другие методы компрессии еле-еле выдают сжатие в 10 раз.

Метод до безумия прост: берём [mem] вектор, добавляем его в начало инпута, а затем просто оптимизируем его, чтобы LLM могла по нему восстановить исходный текст. Никаких сложных энкодеров — просто SGD по входному эмбеддингу. Вот капасити некоторых моделей:
- Llama-3.1-8B: 1568 токенов
- Llama-3.2-1B: 512 токенов
- Pythia-160M: жалкие 80 токенов

Самое интересное, что всё упирается не в длину текста, а в его сложность. Если энтропия текста ниже определённого порога — модель восстановит его идеально, если выше — то уже с ошибками. А если добавить больше [mem] векторов, то ёмкость растёт почти линейно. Например Llama-3.2-1B может упаковать весь "Хоббит" в ~200 векторов.

И при всём этом модели используют только 10-30% теоретической ёмкости своих эмбеддингов. Причём новые модели (Llama, OLMo) гораздо эффективнее старых (Pythia, OPT).

Статья, GitHub
Заметил, что o3 почему-то чаще путается в языках чем o1
Зачем все LLM фокусируют attention на первом токене? (by DeepMind & Oxford)

Давно известно, что многие головы внимания у LLM упорно «смотрят» на самый первый токен последовательности (чаще всего это токен <bos>). В моделях вроде GPT, LLaMA или Gemma такое внимание занимает до 80% от всех голов!

Авторы показывают, что такой «слив» внимания на первый токен — это не ошибка, а очень полезный механизм. Он работает примерно как «нулевая операция» (no-op), то есть помогает головам внимания эффективно ничего не делать и не вносить ненужных изменений в представления токенов, когда они не нужны.

Зачем это нужно? Постоянное активное перемешивание информации между токенами ведёт к трём серьёзным проблемам:
1. Rank collapse — представления всех токенов становятся линейно зависимыми.
2. Representational collapse — сильно растёт косинусная близость соседних токенов.
3. Over-squashing — дальние токены перестают эффективно обмениваться информацией.

Чем глубже модель и длиннее контекст, тем сильнее она нуждается в этом механизме. А если убрать первый токен <bos> во время инференса, у модели, привыкшей к нему, качество генерации сильно падает.

P.S. Что-то оооочень похожее нам рассказывал профессор Вячеслав Дубынин на курсах химии мозга — у людей тоже есть механизм предотвращающий "смешивание" активаций. А, например, ЛСД его ослабляет, вызывая галлюцинации.

Статья
ignore-topk: новая регуляризация для борьбы с деградацией LLM во время файнтюнинга (by DeepMind)

При дообучении языковые модели частенько портятся. Рисёрчеры из DeepMind показали, что проблема связана с тем, что LLM, пытаясь запомнить новый факт, начинает использовать лёгкие shortcut-ы вместо аккуратного внедрения новых знаний в веса. Она просто «раскладывает» новую информацию по уже знакомым ей понятиям (казалось бы это хорошо, но нет). Такое явление они назвали "праймингом" (aka разложение числа на простые множители), и из-за него LLM начинает путаться в фактах, выдавая новую информацию где не просили.

Авторы этой статьи предлагают потенциальное решение — регуляризацию ignore-topk. Идея до гениальности простая:
- Делаем обычный шаг файнтюнинга и смотрим на обновления весов (Δω).
- Отбираем top-k% самых больших обновлений и… просто удаляем их (умножаем на 0).
- Используем только небольшие изменения весов, которые не содержат шорткатов для быстрой меморизации.

Зачем так странно?
Оказывается, самые большие градиенты как раз и отвечают за «грязное» быстрое запоминание через прайминг. Игнорируя их, мы заставляем модель учиться медленнее и аккуратнее. При этом прайминг уменьшается на 90-95%, а способность запоминать новые факты не страдает.

Но авторы конечно молодцы, сами придумали бенчмарк, сами свой подход измерили, а на другие "learning without forgetting" методы вообще забили. Поэтому не могу сказать, что ignore-topk лучше чем, например, Child-Tuning или EWC, но выглядит прикольно, я его точно попробую 🤷‍♂️

Статья
This media is not supported in your browser
VIEW IN TELEGRAM
RL не развивает потенциал рассуждений LLM (by Tsinghua)

RL с верифицируемыми наградами (RLVR) — один из самых популярных подходов для прокачки reasoning-способностей современных LLM, вроде OpenAI-o1 и DeepSeek-R1. Считается, что RLVR позволяет модели самой находить новые паттерны рассуждений, отсутствующие в базовой версии.

Но авторы новой статьи из Tsinghua и SJTU решили это перепроверить и получили крайне неожиданный результат: RLVR НЕ создаёт новые стратегии рассуждений.

Когда мало сэмплов (pass@1), то да, RL версии обгоняют base модели. Но если взять pass@128 или pass@256 (много попыток), то уже наоборот, базовые версии стабильно оказываются ЛУЧШЕ, причём существенно!

Причина: RL не создаёт новые паттерны, а лишь усиливает вероятность уже известных решений из базовой модели. При этом резко падает энтропия, а значит, сужается пространство возможных решений.

Прямо противоположный эффект у дистилляции (например, Distill-R1-Qwen): дистилляция реально добавляет в модель новые стратегии рассуждений.

Авторы проверили гипотезу на огромном наборе задач (математика, программирование, визуальный reasoning), множестве моделей и RL-алгоритмов (PPO, GRPO, ReMax и др.). Везде одно и то же — базовая модель имеет больший потенциал при достаточном количестве попыток.

Похоже, что для реального роста reasoning-способностей нужно придумывать совершенно другие подходы.

Статья, GitHub
«Эксперт по устаревшим рассуждениям» — это когда твоя модель слишком хороша, чтобы называть её просто старой... Лично для меня o1-pro до сих пор лучшая 🧇
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Борис опять
AI Safety стартап WhiteCircle.ai, НАШИ ребята, выкатили бенчмарк для guard-моделей CircleGuardBench и показали две собственные guard модели которые обходят ShieldGemma, PromptGuard и OpenAI moderation.

Guard модели работают модераторами для LLM: ловят джейлбрейки, атаки и нарушения правил. Раньше их тестировали либо на токсичных промптах (HarmfulQA, HarmBench), либо на джейлбрейках (AART), либо на тайминге. Каждый из этих подходов измерял какой-то аспект guard модели, но не её практическую полезность.

В новом бенчмарке авторы составили таксономию вредных запросов и смотрят: что модели блокируют, что пропускают и насколько быстро обрабатывают запросы. Интересно, что метрика комбинированная, а не просто accuracy, как обычно делается. В реальном проде false positive могут убить UX, а false negative компанию. Accuracy или даже какой-нибудь f1-score сами по себе не оценивают практическую полезность модели для работы в проде. Они показывают только качество в идеальных условиях неограниченного времени.

В CircleGuardBench авторы ввели комбинированный скор, который взвешивает несколько метрик и добавляет штрафы за время ответа и наличие ошибок.

Они так же написали прикольный пост на HF: рассказывают не только про цифры, но и про то, как дизайнили и собирали бенчмарк. Мастрид про безопаспость LLM.

Ждём теперь бенчмарк для атакующих моделей, которые взламывают guard-модели, которые защищают базовые модели.

- Блог на huggingface
- Тред в X
- Лидерборд
- Код на github (нормальный код!!!)
Ура! Не ожидал, что Опус тоже представят. Я уже и забыл, что эта версия Клода существует 😅

https://www.anthropic.com/news/claude-4
Soft Thinking: reasoning через усреднённые токены

Если на каждом шаге подавать в LLM не эмбеддинг отдельного токена, а взвешенную сумму топ-10 токенов по вероятностному распределению из выхода модели, то reasoning стабильно улучшается. Никакого обучения и изменений архитектуры: просто на инференсе вместо жёсткого выбора делаем soft-агрегацию.

Единственная сложность — модель может зациклиться. Чтобы этого избежать, авторы просто смотрят на энтропию распределения: как только она падает ниже порога (модель уверена в ответе) — сразу стопаем soft thinking и переходим к финальному ответу.

В результате на всех бенчмарках (MATH, AIME, GSM8K, GPQA Diamond, MBPP, LiveCodeBench) стабильно плюс пару процентов к pass@1 и до 20% сокращения длины reasoning цепочки. При этом, если на каждом шаге брать топ-1 токен, то текст получается абсолютно читабельный, как у обычного CoT.

Я в лёгком шоке, что такая элементарная штука реально работает и не валит модель в генерацию мусора. По сути, это что-то вроде COCONUT, только без обучения.

Статья, GitHub
Как глубина LLM связана с максимально разрешимой алгоритмической сложностью?

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

Итак, представляю вам разбор статьи «Transformers, parallel computation, and logarithmic depth», вышедшей год назад 🤬

Основная фишка статьи — задача chasing pointer. Суть простая: у вас есть цепочка индексов (целых чисел), где каждый индекс ведёт на другой элемент (индекс \ указатель) в последовательности. Задача модели — пройти назад по этим указателям и найти элемент массива на k прыжков назад за один forward pass.

Авторы строго показывают, что глубина трансформера критически важна и определяет максимально возможное число таких прыжков (сложность задачи), которое модель способна эффективно решить. Причём связь эта экспоненциальная: трансформеру с глубиной L доступно O(2^L) прыжков за один шаг.

Проще говоря: никакое увеличение ширины, количества голов внимания или MOE экспертов не заменит глубину. Тут речь именно про внутренние, архитектурные вычисления, а не Chain-of-Thought, то есть мы требуем чтобы модель выдала ответ сразу, без рассуждений.

P.S. Кстати, я потестил Claude-4 и ChatGPT-4.1 \ 4.5 — у всех предел наступает примерно на 25 прыжках, значит ли это, что их эффективная глубина всего 5 слоёв? 😄 (но на самом деле это потому, что их не обучали на эту задачу)

Статья
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Data Secrets
How much do language models memorize? Новое исследование от Meta FAIR, Google DeepMind и NVIDIA

Задумывались когда-нибудь, сколько данных может запомнить модель с определенным количеством параметров? А сколько конкретно информации может выучить один параметр? А сколько информации он может обобщить?

Кажется, что посчитать это очень сложно или даже невозможно, но вот у ученых из этой статьи получилось: каждый параметр языковой модели способен запомнить примерно 3.6 бит информации. О том, как это посчитали – ниже.

Сразу дисклеймер: до этого были и другие статьи на эту тему, но там запоминание определялось просто тем, может ли модель воспроизвести определенный кусок трейна. На самом же деле все сложнее, и в этой работе подход не такой наивный.

Авторы опираются на понятия из теории информации Колмогорова и Шеннона, и четко разделяют запоминание и обобщение. Если модель воспроизвела что-либо – не значит, что она это запомнила, а не обобщила. В обратную сторону – то же самое.

Количество информации, которое модель именно запомнила, считают так. Берут две модели одинаковой архитектуры и размера: одна – референсная – обучена на огромном количестве данных, вторая – испытуемая – на ограниченном датасете.

Обе модели пропускают один и тот же тренировочный фрагмент через процедуру предсказания и вычисляют вероятности каждого токена. Если вторая модель даёт более высокие вероятности (то есть «тратит» на их декодинг меньше бит, чем референсная), она экономит относительно референсной модели определённое число бит. Сумма сэкономленных бит по всем фрагментам и есть общий объём выученной информации.

Вот так и получилось число 3.6 бит/параметр.

Самое важное, что этот показатель дает возможность четко определить момент перехода запоминания в обобщение: он происходит, когда объём данных в битах примерно равен общей ёмкости модели. И да, экспериментально это сходится: как раз на этом объеме данных тестовый лосс начинает резко падать. Это, кстати, часто называют грокингом.

Красота, как она есть arxiv.org/abs/2505.24832
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
HTML Embed Code:
2025/07/05 10:23:29
Back to Top