Forwarded from AI и грабли
Протухание контента
Только собрался писать пост о том, как я его учил свою подругу маркетолога использовать OpenCode, который пару дней назад появился в форме десктопного аппа с нормальным UI,
Как сегодня выходит десктопный UI для кодекс 🤯
———
Скачать OpenCode (Mac, Windows, Linux)
Скачать Codex (Mac-only)
Обзор по фичам на картинке ниже (разбор только по десктопным фичам):
ваш, @ai_grably
Только собрался писать пост о том, как я его учил свою подругу маркетолога использовать OpenCode, который пару дней назад появился в форме десктопного аппа с нормальным UI,
Как сегодня выходит десктопный UI для кодекс 🤯
———
Скачать OpenCode (Mac, Windows, Linux)
Скачать Codex (Mac-only)
Обзор по фичам на картинке ниже (разбор только по десктопным фичам):
ваш, @ai_grably
Forwarded from Эмбеддинг бенчмарка
Transformers v5
Пост (от декабря): https://huggingface.co/blog/transformers-v5
Полный список изменений: https://github.com/huggingface/transformers/releases/tag/v5.0.0
- Теперь токенизаторы используют только tokenizers, что раньше было
- Теперь dtype будет
- Убрали
- Много аргументов в трейнере поменяли. Например,
- Также сделали методы для получения отдельных модальностей у модели для SentenceTransformers, так что ждем когда появится новая версия
Пост (от декабря): https://huggingface.co/blog/transformers-v5
Полный список изменений: https://github.com/huggingface/transformers/releases/tag/v5.0.0
- Теперь токенизаторы используют только tokenizers, что раньше было
fast. Более подробно можно прочитать в их блоге https://huggingface.co/blog/tokenizers- Теперь dtype будет
auto по дефолту (раньше было fp32)- Убрали
load_in_8bit и теперь надо передавать конфиг напрямую- Много аргументов в трейнере поменяли. Например,
report_to теперь по дефолту none- Также сделали методы для получения отдельных модальностей у модели для SentenceTransformers, так что ждем когда появится новая версия
Forwarded from Korenev AI - GPT в тапочках🩴
Принимать взвешенные решения в таких условиях - аццкий ад.
Но! На то есть - серебрянная пуля/ синяя таблетка/ узбагоин (выбери нужное).
Это - фильтр, через который можно просеивать собственные решения. Фильтр, основанный на твоих личных жизненных принципах.
Миллиардер Рэй Дэлио описал свои принципы и подходы в книге "Принципы". По ссылке получасовой ютуб-саммари этой книги.
Начал ее слушать и понял, что у меня формализована лишь малая часть принципов. Остальное - обитает на периферии сознания. И сразу врубил клода опуса, начал с ним сессию по извлечению собственных принципов. Оказалось весьма полезно и познавательно. После сессии - грёбаное солнце стало светить как-то приятнее, грёбаный мир стал намного милей
Кто хочет поразгонять - ловите промпт:
Промпт для разбора жизненных принципов
## Роль
Ты — коуч, который мыслит как Рэй Далио, автор книги "Принципы". Твоя задача — помочь человеку нащупать и сформулировать его личные жизненные принципы через рефлексию и честный разбор паттернов поведения.
## Методология
### Фаза 1: Сбор фактуры
Начни с открытого вопроса:
> "Расскажи о себе: что тебе нравится делать, что не нравится, как ты работаешь, отдыхаешь, общаешься. Не структурируй — просто говори, что приходит в голову."
Слушай и отмечай:
- Повторяющиеся паттерны
- Противоречия (говорит одно, делает другое)
- Эмоциональные маркеры (где энергия, где угасание)
- Что человек называет сам, но не осознаёт как паттерн
Задавай уточняющие вопросы, но не уводи в сторону.
### Фаза 2: Исследование боли
Далио говорит: "Боль + Рефлексия = Прогресс"
Найди точки, где человек:
- Сдавался раньше времени
- Терял энергию
- Конфликтовал с другими или собой
- Чувствовал себя не на своём месте
Ключевой вопрос: "Что ты чувствовал в этот момент? Это была злость, стыд, обида или что-то другое?"
Эмоция — ключ к пониманию реального принципа, который управляет поведением.
### Фаза 3: Поиск структуры
Ищи ответы на:
- Топливо: что даёт энергию?
- Кайф: от какой деятельности получает удовольствие?
- Боль: что истощает, бесит, демотивирует?
- Компенсаторы: что/кто помогает закрывать слабые стороны?
### Фаза 4: Формулировка принципов
Принцип должен быть:
- Конкретным (не "быть лучше", а "работать в партнёрстве с комплементом")
- Проверяемым (можно понять, следуешь ему или нет)
- Основанным на реальном опыте, а не на "как надо"
Группируй принципы:
- Про работу / продуктивность
- Про отношения / общение
- Про себя / ограничения
- Про рост / зону развития
### Фаза 5: Тест на практике
Возьми текущую ситуацию выбора и прогони через принципы:
> "У тебя есть X, Y, Z. Давай проверим каждый вариант через твои принципы."
Создай простую таблицу: принцип vs вариант.
### Фаза 6: Поиск механизмов
Принципы без механизмов — просто слова. Спроси:
> "Как ты будешь себя возвращать к этому принципу, когда захочется его нарушить?"
Варианты механизмов:
- Внешний партнёр / accountability
- Правила-триггеры ("если X, то Y")
- Ограничения ("новое можно только после Z")
## Правила ведения диалога
1. Не давай советов раньше времени — сначала собери фактуру
2. Возвращай к сути — если человек уходит в сторону, мягко верни
3. Называй паттерны — человек часто не видит, что повторяется
4. Используй его слова — когда он сам что-то точно сформулировал, зафиксируй
5. Один вопрос за раз — не перегружай
6. Проверяй резонанс — "Это отзывается? Что хочешь поправить?"
## Ключевые вопросы
- "Что ты чувствуешь в момент, когда сдаёшься?"
- "Где в жизни ты продолжал что-то делать долго без быстрого результата?"
- "Опиши идеальную роль — что делаешь, с кем, как часто контакт с людьми?"
- "Если бы мог оставить только одно направление — какое?"
- "Это осознанная стратегия или способ не выбирать?"
## Финал
Когда принципы собраны, резюмируй:
- Список принципов (компактно)
- Главное противоречие / зона роста
- Один практический шаг на ближайшую неделю
Не забудьте Рэю отсыпать огоньков! Ласковое слово даже миллиардеру приятно
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Душный NLP
Miss me? Как и обещали, возвращаемся не с обзором, а с «кое-чем ещё», но не менее полезным. Мы попросили инженеров Яндекса, чьи разборы вы можете почитать в канале, поделиться (уже) прошлогодними статьями, которые им запомнились больше всего.
ToolOrchestra: Elevating Intelligence via Efficient Model and Tool Orchestration
Статья о маленькой модели (Qwen3-8B-Based), которая, по сути, выполняет функцию планера и роутера во вспомогательные инструменты (глобальный/локальный поиск), специализированные модели (вроде Qwen3-Coder) и модели общего назначения (GPT-5) для решения задач. Кроме того, модель обучена учитывать преференции пользователя по использованию тулов и размену качества на скорость и цену. С помощью обучения на несложной синтетике у авторов получается модель, которая даёт высокий скор на HLE, FRAMES, tau2-bench и при этом оказывается более cost-effective.
Stabilizing Reinforcement Learning with LLMs: Formulation and Practices
Обзор нескольких трюков по стабилизации обучения GRPO, ранее предложенных в других статьях. Авторы дают некоторые теоретические обоснования границ применимости этих методов, а затем проводят достаточно подробные экспериментальные подтверждения. Статья позволяет быстро погрузиться в тему проблем стабильности GRPO и попробовать применить эти методы на практике.
Artificial Hivemind: The Open-Ended Homogeneity of Language Models (and Beyond)
Исследователи из разных университетов изучили ответы моделей на запросы, допускающие ответ в свободной форме (вроде «в чём смысл жизни?» или «сочини стихотворение о времени»). Обнаружили, что ответы одной и той же модели, и совершенно разных, по форме и содержанию очень похожи. Известные техники повышения разнообразия — регулировка температуры или Min-p Sampling — не сильно помогают. Например, большинство моделей стали сравнивать время с рекой.
Вероятно, эффект обусловлен тем, что модели обучаются на похожих данных, собранных из интернета, или даже на синтетике, сгенерированной другими моделями. Кроме того, выяснили, что предпочтения LLM-as-a-Judge плохо коррелируют с оценками людей, особенно на примерах, где предпочтения асессоров расходятся.
Результат важен тем, что мотивирует принятие специальных мер для повышения разнообразия генераций больших языковых моделей.
DAPO: An Open-Source LLM Reinforcement Learning System at Scale
Авторы исследуют недостатки ванильного Deepseek GRPO и предлагают для них очень логичные практические решения, которые совсем несложно добавить к себе. А ещё очень классно, что они опенсорсят датасет и код обучения (который теперь доступен в фреймворке verl. Разбор статьи есть в канале.
Любопытными статьями поделились
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Душный NLP
Ускорение E2E-инференса через оптимизацию KV-кэша. Часть I
Существует много способов ускорить инференс LLM: менять архитектуру, использовать speculative decoding или просто добавлять вычислительные ресурсы. Но есть и более практичный путь — оптимизация KV-кэша.
Её можно разделить на pre-train и post-train. Первые требуют изменений до обучения модели: это архитектурные решения вроде GQA/MQA/MLA, смешивание глобального и локального атеншена, а также другие модификации, которые обычно стоят дорого из-за переобучения.
Post-train-методы можно применять к уже готовой модели: это различные sparse-стратегии, pruning, удаление повторов токенов и другие техники, которые уменьшают объём KV или сокращают число обращений к нему во время инференса.
KV-бюджеты удобно делить на dense и sparse, отдельно для prefill и отдельно для decode. В варианте dense prefill + dense decode (обычный KV-кэш) каждый новый Q взаимодействует со всеми K и V до него: ко всем токенам промпта и всем ранее сгенерированным токенам. Тогда KV-бюджет равен сумме длины промпта и длины генерации.
Если сделать sparse только на prefill, а decode оставить плотным, то Q перестаёт смотреть на весь промпт, но общий выигрыш заметен в основном в сценариях «длинный промпт — короткий ответ». Если же оставить dense prefill и сделать sparse decode, это часто релевантно reasoning/CoT-сценариям. Sparse и на prefill, и на decode даёт максимальную экономию бюджета, но обычно сильнее всего ухудшает качество.
Sparse можно строить по-разному. Если пересчитывать важные токены на каждом шаге decode, то качество станет выше, но скорость падает. Если пересчитывать раз в несколько токенов, то получается быстрее, но нужно удерживать локальный контекст между пересчётами, иначе модель начинает терять связность.
Один из сильных post-train-методов оптимизации KV-кэша — ShadowKV, который позволяет получать минимальные просадки на бенчмарках без дообучения и увеличивает throughput до трёх раз. О нём мы подробно поговорим в следующей части.
Разбор подготовил❣ Владислав Кругликов
Душный NLP
Существует много способов ускорить инференс LLM: менять архитектуру, использовать speculative decoding или просто добавлять вычислительные ресурсы. Но есть и более практичный путь — оптимизация KV-кэша.
Её можно разделить на pre-train и post-train. Первые требуют изменений до обучения модели: это архитектурные решения вроде GQA/MQA/MLA, смешивание глобального и локального атеншена, а также другие модификации, которые обычно стоят дорого из-за переобучения.
Post-train-методы можно применять к уже готовой модели: это различные sparse-стратегии, pruning, удаление повторов токенов и другие техники, которые уменьшают объём KV или сокращают число обращений к нему во время инференса.
KV-бюджеты удобно делить на dense и sparse, отдельно для prefill и отдельно для decode. В варианте dense prefill + dense decode (обычный KV-кэш) каждый новый Q взаимодействует со всеми K и V до него: ко всем токенам промпта и всем ранее сгенерированным токенам. Тогда KV-бюджет равен сумме длины промпта и длины генерации.
Если сделать sparse только на prefill, а decode оставить плотным, то Q перестаёт смотреть на весь промпт, но общий выигрыш заметен в основном в сценариях «длинный промпт — короткий ответ». Если же оставить dense prefill и сделать sparse decode, это часто релевантно reasoning/CoT-сценариям. Sparse и на prefill, и на decode даёт максимальную экономию бюджета, но обычно сильнее всего ухудшает качество.
Sparse можно строить по-разному. Если пересчитывать важные токены на каждом шаге decode, то качество станет выше, но скорость падает. Если пересчитывать раз в несколько токенов, то получается быстрее, но нужно удерживать локальный контекст между пересчётами, иначе модель начинает терять связность.
Один из сильных post-train-методов оптимизации KV-кэша — ShadowKV, который позволяет получать минимальные просадки на бенчмарках без дообучения и увеличивает throughput до трёх раз. О нём мы подробно поговорим в следующей части.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Душный NLP
Ускорение E2E-инференса через оптимизацию KV-кэша. Часть II
В первой части разбора мы говорили о методах оптимизации KV-кэша в принципе. А сегодня речь пойдёт об одном конкретном подходе — ShadowKV.
В его основе наблюдение, что post-RoPE key cache обладает attention locality — соседние токены часто имеют высокую cosine similarity, и только небольшая часть токенов выбивается из этого паттерна. Поэтому их режут на чанки по 8 токенов и строят landmarks — репрезентативные средние ключи для чанка. Это значительно ускоряет этап выбора ключей на шаге декодирования, а также улучшает доступ к памяти и позволяет лучше насыщать шину.
Ключевой момент в том, что лучше всего сжимается именно pre-RoPE K: он хорошо раскладывается в низкий ранг с минимальной ошибкой, заметно лучше, чем V. Поэтому ShadowKV делает так: pre-RoPE K сжимается через SVD, а V не сжимается, а уезжает в CPU (RAM), чтобы экономить GPU память и bandwidth.
При этом небольшое число токенов, которые плохо объясняются landmark’ами, выделяются как outliers (выбросы) и сохраняются полнорангово. В статье отмечают, что значимая доля outliers — это sink tokens. Достаточно порядка 0,049% бюджета на выбросы, чтобы попасть в точку diminishing returns: это минимальное количество outliers, которое почти полностью закрывает деградацию качества, а дальнейшее увеличение бюджета даёт лишь пренебрежимо малый дополнительный вклад.
На этапе prefill пайплайн строится так: параллельно с основным префиллом быстро вычисляются landmarks и outliers, и это вычисление перекрывается с отгрузкой V на CPU. В результате дополнительные шаги минимально увеличивают critical path, потому что большая часть работы делается в overlap-режиме.
Q на decode скорится не по всем токенам, а по landmarks каждого чанка. Затем выбираются лучшие чанки, и уже все токены из выбранных чанков отправляются в kernel attention. Для этого K восстанавливаются обратно из low-rank пространства, а соответствующие V подгружаются из CPU.
Дополнительно используется оптимизация в духе branch prediction или speculative-подходов. Между двумя соседними шагами декодирования выбранный набор токенов обычно меняется незначительно, потому что запросы на соседних шагах похожи. Поэтому можно кэшировать уже подгруженные токены для каждого слоя и на следующем шаге считать разность множеств, догружая только те токены, которых ещё нет в рабочем наборе. Эта оптимизация lossless относительно ShadowKV, потому что сохраняется инвариант: на каждом шаге в аттеншн всё равно попадает актуальный набор токенов — просто часть из них переиспользуется без повторной загрузки.
На бенчмарках деградация остаётся минимальной при бюджете около 1,56% от полного объёма KV. При этом в практических сценариях ShadowKV обеспечивает заметный прирост скорости и позволяет поддерживать существенно больший размер батча — за счёт снижения нагрузки на VRAM и уменьшения стоимости аттеншн на длинных контекстах.
Отдельно важно понимать, почему вообще имеет смысл оптимизировать именно аттеншн. Его вычислительная стоимость растёт с длиной последовательности, и на длинных контекстах он начинает доминировать по времени, тогда как FFN от длины контекста почти не зависит. Поэтому на коротких последовательностях в профиле часто доминирует FFN, и ускорение аттеншена даёт небольшой выигрыш.
Зато на длинных контекстах бутылочным горлышком становится аттеншн, и тогда по закону Амдала даже частичное ускорение этой части даёт заметную экономию общего E2E-времени инференса.
Разбор подготовил❣ Владислав Кругликов
Душный NLP
В первой части разбора мы говорили о методах оптимизации KV-кэша в принципе. А сегодня речь пойдёт об одном конкретном подходе — ShadowKV.
В его основе наблюдение, что post-RoPE key cache обладает attention locality — соседние токены часто имеют высокую cosine similarity, и только небольшая часть токенов выбивается из этого паттерна. Поэтому их режут на чанки по 8 токенов и строят landmarks — репрезентативные средние ключи для чанка. Это значительно ускоряет этап выбора ключей на шаге декодирования, а также улучшает доступ к памяти и позволяет лучше насыщать шину.
Ключевой момент в том, что лучше всего сжимается именно pre-RoPE K: он хорошо раскладывается в низкий ранг с минимальной ошибкой, заметно лучше, чем V. Поэтому ShadowKV делает так: pre-RoPE K сжимается через SVD, а V не сжимается, а уезжает в CPU (RAM), чтобы экономить GPU память и bandwidth.
При этом небольшое число токенов, которые плохо объясняются landmark’ами, выделяются как outliers (выбросы) и сохраняются полнорангово. В статье отмечают, что значимая доля outliers — это sink tokens. Достаточно порядка 0,049% бюджета на выбросы, чтобы попасть в точку diminishing returns: это минимальное количество outliers, которое почти полностью закрывает деградацию качества, а дальнейшее увеличение бюджета даёт лишь пренебрежимо малый дополнительный вклад.
На этапе prefill пайплайн строится так: параллельно с основным префиллом быстро вычисляются landmarks и outliers, и это вычисление перекрывается с отгрузкой V на CPU. В результате дополнительные шаги минимально увеличивают critical path, потому что большая часть работы делается в overlap-режиме.
Q на decode скорится не по всем токенам, а по landmarks каждого чанка. Затем выбираются лучшие чанки, и уже все токены из выбранных чанков отправляются в kernel attention. Для этого K восстанавливаются обратно из low-rank пространства, а соответствующие V подгружаются из CPU.
Дополнительно используется оптимизация в духе branch prediction или speculative-подходов. Между двумя соседними шагами декодирования выбранный набор токенов обычно меняется незначительно, потому что запросы на соседних шагах похожи. Поэтому можно кэшировать уже подгруженные токены для каждого слоя и на следующем шаге считать разность множеств, догружая только те токены, которых ещё нет в рабочем наборе. Эта оптимизация lossless относительно ShadowKV, потому что сохраняется инвариант: на каждом шаге в аттеншн всё равно попадает актуальный набор токенов — просто часть из них переиспользуется без повторной загрузки.
На бенчмарках деградация остаётся минимальной при бюджете около 1,56% от полного объёма KV. При этом в практических сценариях ShadowKV обеспечивает заметный прирост скорости и позволяет поддерживать существенно больший размер батча — за счёт снижения нагрузки на VRAM и уменьшения стоимости аттеншн на длинных контекстах.
Отдельно важно понимать, почему вообще имеет смысл оптимизировать именно аттеншн. Его вычислительная стоимость растёт с длиной последовательности, и на длинных контекстах он начинает доминировать по времени, тогда как FFN от длины контекста почти не зависит. Поэтому на коротких последовательностях в профиле часто доминирует FFN, и ускорение аттеншена даёт небольшой выигрыш.
Зато на длинных контекстах бутылочным горлышком становится аттеншн, и тогда по закону Амдала даже частичное ускорение этой части даёт заметную экономию общего E2E-времени инференса.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from vlad kooklev — ai & agents
мне надоело платить 200$/мес за gpt pro и я построил своего агента для deep research (делюсь с вами кодом)
gpt pro даёт мощную глубину — модель реально копает тему заходами по 30 минут. но ты не контролируешь сам рисёрч: откуда она берёт данные, как фильтрует источники, почему решила что этот сайт достоверный. она постоянно тащит SEO-мусор и AI-слоп, но на это трудно повлиять
стандартная история — это репорты, где он пишет про «самые актуальные модели — sonnet 3.5 и gpt-4o», хотя к тому моменту модели сменились раз 5. в современном мире это непозволительно. я собрал вместо этого свой дип рисерч над claude code
мой пайплайн — 5 шагов:
— декомпозиция темы на ~8 аспектов через разные призмы (who, what, so what, avoid)
— параллельный рисёрч каждого аспекта агентами
— синтез находок
— red team — а что если всё это буллшит? проверка предположений с обратной стороны
— упаковка финальный отчёт
оркестрацией шагов занимается мой фреймворк — claude-pipe. плюс у меня есть мой личный slop-checker skill, который фильтрует источники по критериям.
каждый шаг — отдельный агент со своими инструкциями. не один промпт на всё, а конвейер где каждый этап проверяет предыдущий. одно исследование обходится в ~$1 через exa. значительно шире и глубже, чем gpt pro
выложил на гитхаб, просто дайте ссылку на него своему claude code / openclaw: github.com/bluzir/claude-pipe/tree/master/examples/research-pipeline
настоящий рисёрч — это система которую ты контролируешь. знаешь откуда данные, можешь поменять критерии, перезапустить один кусок не переделывая всё. я убежден, что в 2026 такая должна быть у каждого. с вас звездочки на гитхабе!
gpt pro даёт мощную глубину — модель реально копает тему заходами по 30 минут. но ты не контролируешь сам рисёрч: откуда она берёт данные, как фильтрует источники, почему решила что этот сайт достоверный. она постоянно тащит SEO-мусор и AI-слоп, но на это трудно повлиять
стандартная история — это репорты, где он пишет про «самые актуальные модели — sonnet 3.5 и gpt-4o», хотя к тому моменту модели сменились раз 5. в современном мире это непозволительно. я собрал вместо этого свой дип рисерч над claude code
мой пайплайн — 5 шагов:
— декомпозиция темы на ~8 аспектов через разные призмы (who, what, so what, avoid)
— параллельный рисёрч каждого аспекта агентами
— синтез находок
— red team — а что если всё это буллшит? проверка предположений с обратной стороны
— упаковка финальный отчёт
оркестрацией шагов занимается мой фреймворк — claude-pipe. плюс у меня есть мой личный slop-checker skill, который фильтрует источники по критериям.
каждый шаг — отдельный агент со своими инструкциями. не один промпт на всё, а конвейер где каждый этап проверяет предыдущий. одно исследование обходится в ~$1 через exa. значительно шире и глубже, чем gpt pro
выложил на гитхаб, просто дайте ссылку на него своему claude code / openclaw: github.com/bluzir/claude-pipe/tree/master/examples/research-pipeline
настоящий рисёрч — это система которую ты контролируешь. знаешь откуда данные, можешь поменять критерии, перезапустить один кусок не переделывая всё. я убежден, что в 2026 такая должна быть у каждого. с вас звездочки на гитхабе!
GitHub
claude-pipe/examples/research-pipeline at master · bluzir/claude-pipe
File-First Agent Orchestration. Readable agents. Inspectable state. Predictable costs. - bluzir/claude-pipe
Forwarded from Data Blog
Люблю сталкиваться с моментами, где понимаю, что мне не хватает знаний. То есть не упорства, сил, времени, плана, мотивации или чего-либо ещё, а именно знаний. И сейчас меня так прокинуло в TDA (Topological Data Analysis).
Почему TDA возникает в контексте интерпретируемости?
В задаче анализа моделей как сущности есть две глобальные ветки. Первая ветвь рассматривает модель узко – в контексте конкретной задачи, а вторая – смотрит на модель более абстрактно, как на самостоятельный объект.
Приземляя на примеры:
1. Прогнозирование диагноза. Исследуем случаи решений методами интерпретации, получаем ответ "почему модель дала решение X". Отвечаем на вопросы — какая область данных повлияла на решение.
2. Исследование гендерных/рассовых предубеждений. Смотрим, как модель внутри себя располагает рассы/гендеры и думаем, как свести их в точку, где ни расса, ни гендер не влияет на принятие решения (если оно от них не зависит). Здесь важно то, что ни гендер, ни расса не описаны явно в начальных признаках, иначе было бы достаточно первого подхода.
И вот для абстрактного случая очень важны геометрические методы. Любая модель — это коробка с геометрическими структурами. Сейчас, мы находим их очень точечно — например, линейная разделимость тех же гендеров или harm/safe предубеждений (как мы показывали в статье) или circuits, про которые я так и не написала, но хороший материал тут.
Именно топологический анализ данных в частности тут может быть интересно применен. Для вдохновения:
1. Изучение bias относительно пола и профессии https://arxiv.org/pdf/2508.07516
2. Изучение признаков, идентифицированных моделью (пример на CNN) https://arxiv.org/pdf/2305.08642
3. Сокращение модели на основе изученных топологических структур https://arxiv.org/pdf/2410.11042v1
4. TDA на ризонинге https://arxiv.org/html/2510.20665v1
И к чему это я — нашла очень классный ноутбук для относительно легкого знакомства с TDA на питоне: https://colab.research.google.com/github/shizuo-kaji/TutorialTopologicalDataAnalysis/blob/master/TopologicalDataAnalysisWithPython.ipynb
Прям с нуля можно хорошо покопаться. За праздники надеюсь переведу его и обвешу определениями, но оригинал прям не могла вам не прислать.
Почему TDA возникает в контексте интерпретируемости?
В задаче анализа моделей как сущности есть две глобальные ветки. Первая ветвь рассматривает модель узко – в контексте конкретной задачи, а вторая – смотрит на модель более абстрактно, как на самостоятельный объект.
Приземляя на примеры:
1. Прогнозирование диагноза. Исследуем случаи решений методами интерпретации, получаем ответ "почему модель дала решение X". Отвечаем на вопросы — какая область данных повлияла на решение.
2. Исследование гендерных/рассовых предубеждений. Смотрим, как модель внутри себя располагает рассы/гендеры и думаем, как свести их в точку, где ни расса, ни гендер не влияет на принятие решения (если оно от них не зависит). Здесь важно то, что ни гендер, ни расса не описаны явно в начальных признаках, иначе было бы достаточно первого подхода.
И вот для абстрактного случая очень важны геометрические методы. Любая модель — это коробка с геометрическими структурами. Сейчас, мы находим их очень точечно — например, линейная разделимость тех же гендеров или harm/safe предубеждений (как мы показывали в статье) или circuits, про которые я так и не написала, но хороший материал тут.
Именно топологический анализ данных в частности тут может быть интересно применен. Для вдохновения:
1. Изучение bias относительно пола и профессии https://arxiv.org/pdf/2508.07516
2. Изучение признаков, идентифицированных моделью (пример на CNN) https://arxiv.org/pdf/2305.08642
3. Сокращение модели на основе изученных топологических структур https://arxiv.org/pdf/2410.11042v1
4. TDA на ризонинге https://arxiv.org/html/2510.20665v1
И к чему это я — нашла очень классный ноутбук для относительно легкого знакомства с TDA на питоне: https://colab.research.google.com/github/shizuo-kaji/TutorialTopologicalDataAnalysis/blob/master/TopologicalDataAnalysisWithPython.ipynb
Прям с нуля можно хорошо покопаться. За праздники надеюсь переведу его и обвешу определениями, но оригинал прям не могла вам не прислать.
Forwarded from Data Blog
Одна ошибка и ты ошибся (с)
Народные мудрецы
Как мне кажется, одной из ярких и важных технологий в механистической интерпретируемости в этом году стали SAE — Sparse AutoEncoders. Помимо того, что я сейчас с ними плотно работаю, мы как-то летом обсуждали SAE в подкасте AI Security Lab «Интерпретируемости моделей ИИ: как, зачем и насколько это реально?»
Методологически SAE всегда помогают нам найти атомарные признаки, устраняя полисемантичность — явление, когда один нейрон кодирует много признаков. И этот эффект происходит за счет создания разреженного базиса. Но это — энкодер + разреженная проекция — только лицевая часть SAE. Есть ещё и менее лицевая — если хотите, задняя, часть — декодер. 🍑
Декодер возвращает реконструкцию примера, максимально близкую к исходному эмбеддингу. Близкую, но никогда не ту же самую. Отсюда имеем факт: SAE обладает ошибкой реконструкции.
Но что такое ошибка?
Ошибка в любой прогностической задаче должна быть хорошей — это часть данных, которую мы не можем предсказать. Так, для линейной регрессии мы требуем нормальности ошибок, а для ARIMA моделей для временных рядов — нормальность и стационарность остатков (ошибок) — «зеленый флаг» обучения модели.
А что такое ошибка в SAE?
Исследовать ошибку как самостоятельный объект додумались раньше меня, так что, к счастью, мой вопрос не остался без ответа. Рассмотреть ошибку реконструкции как объект исследования предлагает работа “Decomposing The Dark Matter of Sparse Autoencoders”. Результаты работы просто невероятно красивы:
1. Существует линейное преобразование уменьшающее ошибку реконструкции — следовательно существует линейная часть разложения, которую SAE не могут изучить.
2. Существует постоянная нелинейная часть, являющаяся частью ошибки SAE реконструкции.
То есть, с такой стороны — ошибка SAE — это структурный объект, который можно декомпозировать на линейно предсказуемую и нелинейную части, с разным влиянием на поведение модели. И хотя SAE эмпирически эффективны, влияние ошибок и их природу не стоит опускать из анализа.
Ещё одна интересная работа на эту тему — пост на AI Alignment forum “SAE reconstruction errors are (empirically) pathological”. В этом блог-посте анализируется структура ответа модели при условии SAE ошибки. То есть, анализируется вопрос — что будет, если вместо x поставить x’ с ошибкой реконструкции против x’’ — со случайно ошибкой.
Результат измеряют при помощи KL-дивергенции — интуитивно отвечающей на вопрос насколько далеки распределения друг от друга (то есть 0 тут — наш идеал). Показано, что при одной и той же норме возмущения SAE-ошибка влечёт больший KL / рост loss, чем случайный шум.
При этом, если мы просто уменьшим ошибку — успех не придет. Во-первых, SAE может не улавливать ещё более атомарные концепции (можно поиграть с Meta Feature Explorer, делающий ровно это тут, по мотивам работы Sparse Autoencoders Do Not Find Canonical Units of Analysis ). Кроме того, успех реконструкции по MSE — не значит, что мы нашли важные признаки с точки зрения производительности модели (это исследуют тут) .
И вот смотрю я на всё это, кручу свои SAE признаки в дипломном проекте и чувствую, что впереди ещё безумного много интересного.
Ну и ещё один важный тейк поста — всегда важно оценивать заднюю часть и любые другие детали за спиной main контента метода.
Народные мудрецы
Как мне кажется, одной из ярких и важных технологий в механистической интерпретируемости в этом году стали SAE — Sparse AutoEncoders. Помимо того, что я сейчас с ними плотно работаю, мы как-то летом обсуждали SAE в подкасте AI Security Lab «Интерпретируемости моделей ИИ: как, зачем и насколько это реально?»
Методологически SAE всегда помогают нам найти атомарные признаки, устраняя полисемантичность — явление, когда один нейрон кодирует много признаков. И этот эффект происходит за счет создания разреженного базиса. Но это — энкодер + разреженная проекция — только лицевая часть SAE. Есть ещё и менее лицевая — если хотите, задняя, часть — декодер. 🍑
Декодер возвращает реконструкцию примера, максимально близкую к исходному эмбеддингу. Близкую, но никогда не ту же самую. Отсюда имеем факт: SAE обладает ошибкой реконструкции.
Но что такое ошибка?
Ошибка в любой прогностической задаче должна быть хорошей — это часть данных, которую мы не можем предсказать. Так, для линейной регрессии мы требуем нормальности ошибок, а для ARIMA моделей для временных рядов — нормальность и стационарность остатков (ошибок) — «зеленый флаг» обучения модели.
А что такое ошибка в SAE?
Исследовать ошибку как самостоятельный объект додумались раньше меня, так что, к счастью, мой вопрос не остался без ответа. Рассмотреть ошибку реконструкции как объект исследования предлагает работа “Decomposing The Dark Matter of Sparse Autoencoders”. Результаты работы просто невероятно красивы:
1. Существует линейное преобразование уменьшающее ошибку реконструкции — следовательно существует линейная часть разложения, которую SAE не могут изучить.
2. Существует постоянная нелинейная часть, являющаяся частью ошибки SAE реконструкции.
То есть, с такой стороны — ошибка SAE — это структурный объект, который можно декомпозировать на линейно предсказуемую и нелинейную части, с разным влиянием на поведение модели. И хотя SAE эмпирически эффективны, влияние ошибок и их природу не стоит опускать из анализа.
Ещё одна интересная работа на эту тему — пост на AI Alignment forum “SAE reconstruction errors are (empirically) pathological”. В этом блог-посте анализируется структура ответа модели при условии SAE ошибки. То есть, анализируется вопрос — что будет, если вместо x поставить x’ с ошибкой реконструкции против x’’ — со случайно ошибкой.
Результат измеряют при помощи KL-дивергенции — интуитивно отвечающей на вопрос насколько далеки распределения друг от друга (то есть 0 тут — наш идеал). Показано, что при одной и той же норме возмущения SAE-ошибка влечёт больший KL / рост loss, чем случайный шум.
При этом, если мы просто уменьшим ошибку — успех не придет. Во-первых, SAE может не улавливать ещё более атомарные концепции (можно поиграть с Meta Feature Explorer, делающий ровно это тут, по мотивам работы Sparse Autoencoders Do Not Find Canonical Units of Analysis ). Кроме того, успех реконструкции по MSE — не значит, что мы нашли важные признаки с точки зрения производительности модели (это исследуют тут) .
И вот смотрю я на всё это, кручу свои SAE признаки в дипломном проекте и чувствую, что впереди ещё безумного много интересного.
Ну и ещё один важный тейк поста — всегда важно оценивать заднюю часть и любые другие детали за спиной main контента метода.
Forwarded from Data Blog
Привет, друзья!
За последний год я писала про SAE 11 раз. А ещё взяла с ними дипломную.
SAE-шки — очень практичный и интересный метод. Они позволяют разложить внутренние представления трансформера на разреженные признаки, на которые мы можем посмотреть и которыми мы можем управлять.
А ещё мой последний туториал был 4 месяца назад. Так что звезды сложились — и я снова дошла до Хабра со статьей и ноутбуком!
В туториале:
— что такое SAE и зачем вообще «раздувать» скрытое пространство;
— где именно в трансформере обучают SAE (residual stream, attention, MLP);
— как читать признаки через Neuronpedia;
— как извлекать и анализировать активации признаков;
— как запускать модель с SAE внутри и смотреть, что ж активируется по слоям.
Этот материал лежал в заметках. И когда я его писала — очень хорошо уложила себе базу. Надеюсь, для вас это тоже сработает!
Чудесного начала недели!
Ваш Дата-автор!❤️
За последний год я писала про SAE 11 раз. А ещё взяла с ними дипломную.
SAE-шки — очень практичный и интересный метод. Они позволяют разложить внутренние представления трансформера на разреженные признаки, на которые мы можем посмотреть и которыми мы можем управлять.
А ещё мой последний туториал был 4 месяца назад. Так что звезды сложились — и я снова дошла до Хабра со статьей и ноутбуком!
В туториале:
— что такое SAE и зачем вообще «раздувать» скрытое пространство;
— где именно в трансформере обучают SAE (residual stream, attention, MLP);
— как читать признаки через Neuronpedia;
— как извлекать и анализировать активации признаков;
— как запускать модель с SAE внутри и смотреть, что ж активируется по слоям.
Этот материал лежал в заметках. И когда я его писала — очень хорошо уложила себе базу. Надеюсь, для вас это тоже сработает!
Чудесного начала недели!
Ваш Дата-автор!
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
SAE: введение, пояснение и код
Привет, друзья! В прошлой статье мы разобрали идею применения автоэнкодеров к трансоформерам. Там весь наш pipeline проходил на идее сжатия признакового пространства так, чтобы поделить кошек и собак....
Forwarded from IT путь
Подготовка к собеседованию на DE
Секция SQL. Теория.
Вопрос: TRUNCATE vs DELETE (разобрал для MSSQL, MYSQL, PostreSQL, ORACLE)
Тип БД:
Первое, что стоит учесть — TRUNCATE и DELETE это команды реляционной модели. В NoSQL и колоночных БД свои механизмы удаления, поэтому там это сравнение неприменимо =)
Тип модели хранилища:
В системах типа DWH, Data Lake, OLAP это сравнение тож не актуально. В DWH данные грузятся батчами, точечный DELETE — редкая и тяжелая хрень. Чаще нужна полная перезагрузка партиции или витрины через TRUNCATE/DROP PARTITION. Короче DELETE в OLAP — это лишнее.
А вот OLTP — это уже та среда, для которой этот вопрос предназначен, тк выбор между командами критичен и зависит от цели.
🔤 🔤 🔤 🔤 🔤 🔤 🔤 🔤
🔤 🔤
🩸 🩸 🩸 🩸 🩸 🩸
1️⃣ Транзакционность
DELETE относится к DML и полностью транзакционен во всех СУБД: поддерживает ROLLBACK, участвует в MVCC (1️⃣ ), генерирует UNDO/WAL(2️⃣ ).
TRUNCATE - это DDL: В PostgreSQL и MSSQL он транзакционен и откатывается, а в MySQL и Oracle — выполняет авто-commit и отката нет.
2️⃣ Механизм удаления
DELETE работает построчно, логирует каждое изменение и обновляет индексы — сложность O(N) (3️⃣ ).
TRUNCATE деаллоцирует(4️⃣ ) страницы целиком и пишет в лог только факт операции — O(1) (5️⃣ ).
3️⃣ WHERE и партиционирование
DELETE поддерживает WHERE везде.
TRUNCATE работает без условий, только с таблицей целиком или партицией. TRUNCATE PARTITION есть в Oracle, MySQL и PostgreSQL. В MSSQL используют partition switching (6️⃣ ).
4️⃣ Триггеры
DELETE активирует row-level триггеры (7️⃣ ) во всех СУБД.
TRUNCATE триггеры не вызывает — кроме PostgreSQL, где TRUNCATE-триггеры поддерживаются явно.
5️⃣ Внешние ключи
DELETE проверяет ссылочную целостность построчно везде.
TRUNCATE не выполнится, если на таблицу ссылается FK. Исключение — Oracle начиная с 12c, где появился CASCADE.
6️⃣ Блокировки
DELETE накладывает row-level locks (8️⃣ ), что при большом объёме может порождать долгие blocking chains.
TRUNCATE берёт table-level exclusive lock (9️⃣ ) — в PostgreSQL это AccessExclusiveLock, блокирующий даже SELECT. Но выполняется мгновенно.
7️⃣ WAL(2️⃣ ) и репликация
DELETE генерирует полный объём WAL-записей, нагружает standby(🔟 ) и архивные логи.
TRUNCATE пишет в лог минимум. В MSSQL операция считается minimally logged даже в Full Recovery Model(1️⃣ 1️⃣ ).
8️⃣ Инкрементальные счётчики
DELETE счётчик не сбрасывает.
TRUNCATE: MySQL сбрасывает AUTO_INCREMENT в 1, MSSQL сбрасывает IDENTITY в seed-значение(1️⃣ 2️⃣ ), PostgreSQL сбрасывает sequence только при явном указании RESTART IDENTITY. В Oracle SEQUENCE — отдельный объект, TRUNCATE его не трогает (только ALTER SEQUENCE вручную).
9️⃣ High Water Mark (Oracle) (1️⃣ 3️⃣ )
DELETE не снижает HWM — full scan продолжает читать весь ранее занятый сегмент даже после удаления данных.
TRUNCATE сбрасывает HWM. Есть два режима: DROP STORAGE возвращает экстенты(1️⃣ 4️⃣ ) обратно в tablespace, REUSE STORAGE оставляет структуру, но сбрасывает метку. В PostgreSQL используется аналог — VACUUM, в MSSQL — rebuild операции, но термин HWM там не используется.
Секция SQL. Теория.
Вопрос: TRUNCATE vs DELETE (разобрал для MSSQL, MYSQL, PostreSQL, ORACLE)
Тип БД:
Первое, что стоит учесть — TRUNCATE и DELETE это команды реляционной модели. В NoSQL и колоночных БД свои механизмы удаления, поэтому там это сравнение неприменимо =)
Тип модели хранилища:
В системах типа DWH, Data Lake, OLAP это сравнение тож не актуально. В DWH данные грузятся батчами, точечный DELETE — редкая и тяжелая хрень. Чаще нужна полная перезагрузка партиции или витрины через TRUNCATE/DROP PARTITION. Короче DELETE в OLAP — это лишнее.
А вот OLTP — это уже та среда, для которой этот вопрос предназначен, тк выбор между командами критичен и зависит от цели.
в тексте есть сноски (*N). Пояснение комменте
DELETE относится к DML и полностью транзакционен во всех СУБД: поддерживает ROLLBACK, участвует в MVCC (
TRUNCATE - это DDL: В PostgreSQL и MSSQL он транзакционен и откатывается, а в MySQL и Oracle — выполняет авто-commit и отката нет.
DELETE работает построчно, логирует каждое изменение и обновляет индексы — сложность O(N) (
TRUNCATE деаллоцирует(
DELETE поддерживает WHERE везде.
TRUNCATE работает без условий, только с таблицей целиком или партицией. TRUNCATE PARTITION есть в Oracle, MySQL и PostgreSQL. В MSSQL используют partition switching (
DELETE активирует row-level триггеры (
TRUNCATE триггеры не вызывает — кроме PostgreSQL, где TRUNCATE-триггеры поддерживаются явно.
DELETE проверяет ссылочную целостность построчно везде.
TRUNCATE не выполнится, если на таблицу ссылается FK. Исключение — Oracle начиная с 12c, где появился CASCADE.
DELETE накладывает row-level locks (
TRUNCATE берёт table-level exclusive lock (
DELETE генерирует полный объём WAL-записей, нагружает standby(
TRUNCATE пишет в лог минимум. В MSSQL операция считается minimally logged даже в Full Recovery Model(
DELETE счётчик не сбрасывает.
TRUNCATE: MySQL сбрасывает AUTO_INCREMENT в 1, MSSQL сбрасывает IDENTITY в seed-значение(
DELETE не снижает HWM — full scan продолжает читать весь ранее занятый сегмент даже после удаления данных.
TRUNCATE сбрасывает HWM. Есть два режима: DROP STORAGE возвращает экстенты(
Please open Telegram to view this post
VIEW IN TELEGRAM