Claude Code может терять направление, когда задача требует реального анализа: отладки, архитектурных компромиссов, оценки рисков или выработки стратегии.

Claude Code Thinking Skills — это библиотека из 39 ментальных моделей и фреймворков критического мышления для пользователей Claude Code, которым нужен более структурированный подход к рассуждениям

Она помогает разбирать сложные задачи через навык thinking-model-router, который подбирает подходящую модель мышления под тип проблемы, вместо того чтобы полагаться на случайные промпты.

Что входит:
• 39 моделей мышления — включая First Principles, Bayesian Reasoning, Systems Thinking, OODA, Pre-Mortem, TRIZ и другие.
• Точка входа через Router — определяет домен и тип задачи, после чего предлагает наиболее подходящий фреймворк.
• Нативная интеграция с Claude Code — каждая модель упакована как отдельный Claude Code Skill, который можно вызвать по имени.
• Установка через плагины — в README есть инструкции по установке через маркетплейс Claude Code и ручному копированию.
• Прозрачная система оценки — проект публикует результаты тестирования и репликации, включая текущий результат: «ноль устойчиво воспроизведённых вердиктов ELEVATE».

Проект распространяется с открытым исходным кодом по лицензии MIT.

https://github.com/tjboudreaux/cc-thinking-skills

👉 @DataSciencegx

большая подборка материалов по LLM Systems,

• обучение моделей (pre-training, RLHF, fault tolerance, stragglers)
• инференс и serving
• агентные системы
• edge deployment
• мультимодальные модели
• технические отчёты от крупных лабораторий
• обзоры, бенчмарки и лидерборды
• курсы по MLSys и подборки статей с конференций

https://github.com/AmberLJC/LLMSys-PaperList

👉 @DataSciencegx

PixelRAG предлагает довольно простую идею: отказаться от HTML-парсинга в web RAG.

Большинство RAG-систем работают так:

→ HTML
→ Извлечение текста
→ Чанкинг
→ Ретривер
→ LLM

PixelRAG использует другой подход:

→ Рендер страницы
→ Скриншоты (тайлы)
→ Визуальный ретривер
→ VLM читает изображение страницы

Авторы утверждают, что HTML-to-text преобразование часто теряет полезную информацию: структуру страницы, таблицы, инфобоксы и другие визуальные элементы.

Для экспериментов был построен визуальный индекс из более чем 30 млн скриншотов веб-страниц Википедии.

Обучение ретривера полностью автоматизировано. Для генерации обучающих данных используются веб-страницы, LLM-сгенерированные поисковые запросы и автоматически подобранные негативные примеры. Ручная разметка не использовалась.

Для дообучения применялась LoRA к VLM и ViT-энкодеру. По словам авторов, обучение заняло около трёх часов на одной H100.

В статье PixelRAG превосходит лучший текстовый бейзлайн на всех использованных бенчмарках:

• SimpleQA — 78.8% (+7.1)
• NQ-Tables — 48.8% (+6.3)
• EVQA — 45.1% (+15.5)
• LiveVQA — 70.3% (+11.3)

Авторы отдельно отмечают, что улучшения наблюдаются не только на визуальных задачах, но и на бенчмарках, которые обычно относят к текстовым.

Также PixelRAG был интегрирован в ReAct-агента и протестирован на MoNaCo. В статье сообщается, что система показала более высокую точность ответов, чем Google Search и DS-Serve, при меньших затратах на инференс.

Ещё одно наблюдение авторов связано с масштабированием. Поскольку индекс хранится в визуальном виде, качество системы может улучшаться по мере появления более сильных VLM без переиндексации данных и изменения пайплайна.

Код проекта опубликован в открытом доступе, а в статье есть подробные разборы ошибок, абляционные исследования и сравнение более чем с 25 VLM-моделями.

👉 @DataSciencegx

Исследователи показали способ ускорить генерацию LLM до 8,5 раза без потери качества.

Речь идёт о новом методе под названием DFlash, который развивает идею speculative decoding.

Проблема классических LLM хорошо известна: модель генерирует токены по одному. Каждый следующий токен требует нового прохода через модель, что создаёт узкое место при инференсе.

Speculative decoding частично решает эту проблему.

Сначала небольшая draft-модель предлагает несколько следующих токенов, после чего большая модель проверяет их за один проход.

Если где-то обнаруживается ошибка, все токены до неё сохраняются, а генерация продолжается с этого места. Качество остаётся таким же, как при обычном декодировании.

Но у подхода есть ограничение.

Даже draft-модели обычно генерируют токены последовательно, по одному за раз. В результате сам этап черновой генерации становится новым узким местом, и ускорение на практике редко превышает 2–3 раза.

DFlash заменяет авторегрессионную draft-модель на лёгкую diffusion-модель, которая генерирует сразу весь блок токенов параллельно.

Получается следующая схема:

Обычный speculative decoding:

→ Draft-модель предсказывает токены по одному
→ Основная модель проверяет результат

DFlash:

→ Diffusion-драфтер генерирует весь блок сразу
→ Основная модель проверяет результат

Стоимость черновой генерации при этом практически не зависит от количества предполагаемых токенов.

Дополнительно драфтер получает скрытые представления из нескольких слоёв основной модели. Эти признаки передаются во все слои драфтера, что помогает ему делать более точные предсказания.

По данным авторов, в демонстрации:

• Обычный декодинг — 48,5 токена/сек
• DFlash — 415 токенов/сек

При этом качество генерации не ухудшается.

Технология уже интегрирована в:

• vLLM
• SGLang
• Transformers

Также опубликованы готовые draft-модели для:

• Qwen3
• Qwen3.5
• Llama 3.1
• Kimi-K2.5
• gpt-oss
• и других моделей

Если результаты подтвердятся на широком наборе сценариев, DFlash может стать одним из самых заметных улучшений speculative decoding за последнее время, поскольку атакует главное ограничение метода — последовательную работу draft-модели.

https://github.com/z-lab/dflash

👉 @DataSciencegx

Теперь можно дообучать Qwen3.5.

Для локального обучения LoRA-адаптера на Qwen3.5-2B достаточно всего 5 ГБ видеопамяти. Обучение стало примерно в 1.5 раза быстрее и требует на 50% меньше VRAM.

Qwen3.5-4B в Google Colab:
https://colab.research.google.com/github/unslothai/notebooks/blob/main/nb/Qwen3_5_(4B)_Vision.ipynb
GitHub-проект Unsloth:
https://github.com/unslothai/unsloth

Подходит для быстрого и экономичного дообучения моделей Qwen3.5 на собственных данных даже на относительно слабых видеокартах.

👉 @DataSciencegx

Вау, это интересно.

Исследователи из Stanford проверили распространённое предположение: большие модели якобы нужно обучать только на “высококачественных” отфильтрованных данных.

А что если лучший фильтр — это отсутствие фильтра?

Они сравнили полный датасет Common Crawl с сильно отфильтрованными версиями и получили неожиданные результаты:

1. Фильтрация помогает при ограниченном бюджете вычислений — модель просто не успевает нормально учиться на всём подряд.
2. Но по мере роста модели и увеличения времени обучения полный, неочищенный датасет начинает выигрывать.

Большие модели лучше справляются с “грязными” данными, чем ожидалось. Низкокачественный текст, нерелевантные фрагменты или откровенный мусор не являются критичной проблемой — модель это переваривает.
Более того, она всё равно вытаскивает полезные сигналы даже из слабых данных.

Из этого меняется базовое правило:
→ Фильтрация полезна при ограниченных ресурсах. Но при больших вычислениях чрезмерная очистка данных может просто выбросить полезную информацию.

Это хорошо ложится на идею “bitter lesson”: на масштабе часто побеждает простое масштабирование, а не ручная инженерия.

Дальше всё упирается в ограничения и выбор: увеличивать вычисления или тратить время и ресурсы на жёсткую фильтрацию данных.

Интересно, как бы ты это использовал на практике 👀

https://arxiv.org/abs/2605.19407

👉 @DataSciencegx

Это исследование хорошо ложится на опыт любого, кто активно работает с Claude Code, Codex или другими агентами.

Оно смотрит не на бенчмарки, а на реальную работу в разработке:

как именно AI-агенты раздражают разработчиков в живых сессиях.

Авторы проанализировали 20 574 сессии (IDE и CLI). “Фейл” они определили не как падение кода, а как моменты, когда разработчик начинает исправлять, прерывать или спорить с агентом.

Картина довольно приземлённая. Чаще всего проблема не в том, что код не работает. Проблема в том, что агент нарушает явно заданные ограничения.

Ты пишешь: “не трогай этот файл”, “пока ничего не меняй”, “сделай минимальные правки” — он всё равно лезет дальше.
Просишь объяснить проблему — он параллельно начинает менять код.
Говоришь проверить всё перед финальным ответом — он рапортует успех до запуска проверок.

Есть интересное разделение:

CLI-агенты чаще нарушают границы, потому что им дают длинные, слабо ограниченные задачи.
IDE-агенты чаще делают локальные ошибки, потому что работают как плотный “копилот” и постоянно правят код в мелких итерациях.

Самое неприятное в этих сбоях — они редко ломают систему сразу. Они просто съедают время и доверие. Приходится постоянно перепроверять: понял ли он задачу, не вышел ли за рамки, реально ли он что-то проверил.

Это хорошо совпадает с практикой: утомляет не столько генерация кода, сколько постоянный контроль над тем, не уехал ли агент в сторону.

И отсюда простой вывод. Улучшение агентов — это не только про качество кода. Это про соблюдение границ, понимание намерений и честную отчётность о прогрессе.

Главная проблема тут не в скорости написания кода. А в том, сколько времени уходит на разбор того, что он “написал не туда”.

👉 @DataSciencegx

Claude Code полностью разобрали по косточкам

Исследователи из UCL провели реверс-инжиниринг утёкшего исходного кода Claude. Их выводы меняют представление о том, как стоит проектировать AI-агентов.

Лишь 1,6% кодовой базы отвечает за логику принятия решений моделью.

Остальные 98,4% — это операционная инфраструктура: контроль разрешений, маршрутизация инструментов, сжатие контекста, логика восстановления, сохранение состояния сессий. Модель занимается рассуждением. Всё остальное делает обвязка (harness).
Это противоположно тому, как сегодня устроено большинство агентных фреймворков.

LangGraph пропускает ответы модели через явные конечные автоматы состояний. Devin накладывает тяжёлые планировщики поверх операционной инфраструктуры. Claude Code, наоборот, даёт модели максимум свободы в принятии решений внутри богатой детерминированной обвязки и направляет основные инженерные усилия именно на эту обвязку.

Основной цикл предельно простой: while (true). Вызов модели, запуск инструментов, повтор.
Но настоящая архитектура находится вокруг этого цикла:
- Система разрешений с 7 режимами работы и ML-классификатором. Пользователи всё равно одобряют 93% запросов, поэтому архитектура компенсирует это автоматизированными слоями защиты вместо добавления новых предупреждений.
- Пятиуровневый пайплайн сжатия контекста. Каждый следующий уровень запускается только если более дешёвый не справился: budget reduction, snip, microcompact, context collapse, auto-compact.
- Четыре механизма расширения, упорядоченные по стоимости контекста: hooks (нулевая стоимость), skills (низкая), plugins (средняя), MCP (высокая). Каждый решает свою задачу интеграции.
- Субагенты возвращают родительскому агенту только итоговое резюме. Полные логи их работы сохраняются в sidechain-файлах. Даже при таком подходе команда агентов расходует примерно в 7 раз больше токенов, чем обычная сессия.
- Функция Resume не восстанавливает разрешения, привязанные к сессии. Доверие устанавливается заново при каждой новой сессии. Именно так и задумано.

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

Статья: Dive into Claude Code (arXiv:2604.14228)

Также авторы выпустили отдельный материал про Agent Harness и то, что сегодня строят крупные компании в этой области.

👉 @DataSciencegx

Сегодня Google фактически превратил gist от Карпати про LLM-вики в официальный стандарт — Open Knowledge Format (OKF). По сути это markdown-файлы с одним обязательным полем.

Вопрос с форматом хранения знаний теперь во многом закрыт. Самая сложная часть осталась за рамками стандарта.

Что меняется:

- Портативность. База знаний может быть обычным tar-архивом или git-репозиторием. Её можно переносить между компаниями и инструментами без промежуточных конвертеров.
- Контроль версий. Знания хранятся рядом с кодом, который описывают. История изменений и диффы идут бесплатно вместе с git.
- Развязка инструментов. Человек создаёт и поддерживает базу знаний, агент её читает. Общий стек или специальные инструменты для этого не нужны.
- Никаких SDK и аккаунтов. Всё сводится к чтению и записи обычных markdown-файлов.

Что стандарт не решает:

- Разрешение противоречий. Новый источник может конфликтовать со старым. OKF сохранит оба факта, но не скажет, какой из них считать актуальным.
- Устаревание данных. Для даты есть отдельное поле, но решение о том, что факт больше не актуален, остаётся на вашей стороне.
- Политика слияния. В какую страницу попадёт новый факт, когда создавать отдельную ветку знаний, а когда обновлять существующую запись — ответственность агента или системы, которая пишет данные.
- Поиск. Для нескольких сотен страниц хватит index.md. Дальше понадобятся гибридный поиск, индексирование и reranker.

OKF стандартизировал картотеку. Библиотекаря всё ещё придётся строить самостоятельно.

https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/

👉 @DataSciencegx

Stanford выпустил интересную работу, которая ставит под сомнение одну из базовых идей мультиагентных систем: а нужен ли вообще агент-менеджер, который раздаёт задачи всем остальным?

Обычно схема выглядит так:

- один агент получает задачу;
- дробит её на подзадачи;
- раздаёт работу;
- собирает результаты;
- склеивает финальный ответ.

Звучит логично, пока агентов и подзадач немного.

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

В статье предлагают DeLM (Decentralized Language Model).

Вместо центрального координатора используется общее проверяемое пространство контекста (shared verifiable context), к которому имеют доступ все агенты.

Каждый агент сам берёт подзадачи из очереди, читает текущий прогресс, выполняет свою часть работы и записывает обратно только проверенные выводы.

Самое интересное — другие агенты не используют новые данные автоматически. Записи должны пройти проверку, прежде чем попасть в общий контекст. Это помогает не разносить ошибки по всей системе.

По сути, авторы переносят узкое место с агента-супервизора на общий слой знаний.

Именно эта идея кажется самой ценной.

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

Возможно, главный вопрос уже не «как разбить задачу на части», а «как организовать обмен информацией так, чтобы он сам не стал ограничением».

👉 @DataSciencegx

Исследователи показали, что Claude Code на 98% состоит вовсе не из AI.

Anthropic никогда не раскрывала архитектуру Claude Code. Не было ни документации, ни технических разборов. Только инструмент, которым сейчас одержима половина индустрии.

Пока недавно не произошла утечка.

Команда исследователей проанализировала исходный код объёмом около 500 000 строк и обнаружила любопытную деталь:

Лишь 1,6% кодовой базы напрямую взаимодействует с моделью.

Ядро Claude Code — по сути обычный цикл: спросить модель, что делать дальше → вызвать инструмент → повторить.

Тогда что занимает остальные 98,4%?

Классическая инженерия.

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

Среди компонентов:

* 7 режимов системы разрешений, которые фильтруют действия агента.
* 5-уровневый пайплайн сжатия контекста, чтобы модель не забывала цель задачи.
* Механизм делегирования подагентам с жёсткой изоляцией рабочих деревьев.
* Четыре расширяемых слоя для безопасной интеграции внешних инструментов.

Сейчас многие стартапы пытаются получить лучшие результаты, создавая более мощные модели.

Подход Anthropic оказался другим.

Вместо того чтобы делать модель умнее, они построили вокруг неё массивную детерминированную инфраструктуру.

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

https://arxiv.org/pdf/2604.14228

👉 @DataSciencegx

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

Awesome AI Auto-Research — это curated-репозиторий на GitHub для исследователей и разработчиков, которые изучают применение AI в научной работе.

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

Что внутри:

• Карта жизненного цикла — auto-research разбит на 4 фазы и 8 этапов.
• Каталог статей — для каждого инструмента указаны статья, площадка публикации, сайт и GitHub-репозиторий.
• Этап создания исследований — идеи, поиск литературы, программирование, эксперименты, таблицы и визуализации.
• Этап проверки качества — peer review, ответы рецензентам, доработка работ, вопросы качества, предвзятости и регулирования.
• Раздел систем — отдельно выделены end-to-end системы, специализированные решения по доменам, самоулучшающиеся системы и инфраструктурные проекты.

Репозиторий распространяется по лицензии MIT и выглядит как неплохая отправная точка для тех, кто хочет понять весь пайплайн AI-assisted research, а не только отдельные модели или статьи.

https://github.com/worldbench/awesome-ai-auto-research

👉 @DataSciencegx

Attention — одна из ключевых идей, на которых держатся трансформеры и современные LLM.

Попробуем собрать её с нуля, по шагам.

Self-Attention

Self-attention помогает модели понять, как слова связаны друг с другом внутри предложения.
Модель не обрабатывает каждое слово отдельно. Каждый токен может “посмотреть” на другие токены и решить, какие из них сейчас важнее.

Возьмём предложение:

Every moment is a beginning.

Чтобы понять слово beginning, модель может сильнее обратить внимание на moment и Every.
Так появляется контекст: каждый момент может быть новым началом.

Query, Key, Value

Каждый токен создаёт три вектора:
Query (Q) — что я ищу?
Key (K) — какая информация во мне есть?
Value (V) — какую информацию я передам, если окажусь полезным?

Грубо говоря:
Query одного токена сравнивается с Key других токенов.
Чем лучше совпадение, тем больше внимания получает соответствующий Value.

Causal Self-Attention
В обычном self-attention токен может смотреть на все токены в последовательности.
Но языковые модели генерируют текст по одному токену. Значит, при предсказании следующего токена они не должны видеть будущее.

Например, если модель предсказывает:

Every moment is → a

она не должна заранее видеть слово beginning.

Для этого используется causal mask

Маска блокирует доступ к будущим токенам:
• токен 1 видит только себя
• токен 2 видит токены 1 и 2
• токен 3 видит токены 1, 2 и 3
• и так далее

Так модель предсказывает следующий токен только по прошлому и текущему контексту.
Без подглядывания вперёд.

👉 @DataSciencegx

Нашёл хороший репозиторий для тех, кто хочет руками собрать GPT-подобную LLM на PyTorch.
LLMs from scratch — 10 ноутбуков с пошаговыми объяснениями.

GitHub: https://github.com/analyticalrohit/llms-from-scratch

Внутри архитектуру LLM разбирают на простые части:
• токенизация
• embeddings
• attention
• transformer blocks
• обучение
• генерация текста

Подходит для новичков, потому что всё объясняется по шагам и сразу через код.
Хороший вариант, если хочется понять, как GPT-подобные модели работают под капотом, а не просто пользоваться готовыми API.

👉 @DataSciencegx

Рады отметить отличную модель от сообщества разработчиков: Qwen3.6-27B-MTP-pi-reasoning-GGUF.
Модель построена на базе Qwen3.6-27B и ориентирована на задачи автоматизированного программирования и отладки в локальных AI-агентах для разработки.

Если вы экспериментируете с локальными AI-ассистентами для написания кода, рекомендуем протестировать эту модель в своей среде и оценить её в реальных сценариях работы.

https://huggingface.co/bytkim/Qwen3.6-27B-MTP-pi-tune-GGUF

👉 @DataSciencegx

HarnessX: обвязка (harness), которая компилирует сама себя.

До сих пор все улучшения harness-систем делались вручную — разработчик сам вносил изменения в код.

Anthropic убирает этапы планирования из Claude Code, когда выходит более мощная модель. Manus за шесть месяцев пять раз перестраивал своего агента, каждый раз сокращая сложность.

Вся эта работа держится на человеческом понимании того, что именно нужно менять и когда. HarnessX показывает, что происходит, когда система начинает вносить такие изменения самостоятельно.

Ключевая идея — рассматривать harness как объект первого класса, так же как сегодня рассматриваются веса модели.

Когда harness становится типизированным и редактируемым артефактом, его можно оптимизировать на основе собственных трассировок выполнения.

Авторы используют концепцию «операционного зеркала». Эволюция harness естественным образом отображается на обучение с подкреплением.

Harness выступает состоянием. Изменение — действием. Трассировка вместе с оценкой — обратной связью. Новая версия — обновлением.

Если посмотреть на это под таким углом, сразу появляются знакомые режимы отказа: reward hacking, catastrophic forgetting, недостаточное исследование пространства решений.

Те же проблемы, которые ломают обучение моделей, возникают и тогда, когда система начинает редактировать собственную инфраструктуру.

Поэтому изменения никогда не применяются вслепую. На каждом цикле система анализирует трассировки, планирует изменение, вносит правку, а затем проводит её критический разбор.

Новая версия принимается только в том случае, если проходит проверку и показывает лучшие результаты на задачах, которых раньше не видела.

Безопасность обеспечивается архитектурой. Harness собирается из типизированных компонентов, которые можно заменять независимо, не ломая остальную систему.

Именно это здесь означает слово «компилирует». Каждый кандидат на новую версию harness проходит проверку типов перед запуском.

Самый интересный результат: слабейшая модель получила наибольший прирост качества. Самая сильная изменилась минимально.

Эволюционирующий harness закрывает те пробелы, которые слабая модель не способна компенсировать самостоятельно. Веса модели остаются прежними. Умнее становится среда, в которой она работает.

Это следующий логичный этап развития agent harness engineering. Сначала мы оптимизировали веса моделей, затем контекст, затем вручную собранные harness-системы.

Harness оставался последним элементом, который всё ещё настраивался вручную.

Статья: HarnessX: A Composable, Adaptive, and Evolvable Agent Harness Foundry

👉 @DataSciencegx