Google DeepMind создали ИИ, который пишет алгоритмы ИИ лучше, чем учёные-люди.

И он полностью эволюционирует их самостоятельно.

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

Они рассматривают Python-код как геном — и позволяют ИИ его мутировать.

Результаты впечатляют.

ИИ изобрёл полностью новые, неинтуитивные математические механизмы, до которых исследователи-люди даже не додумывались.

Вот почему это меняет всё:

- Семантическая эволюция кода: классическое генетическое программирование просто применяло случайные мутации к коду, пока что-то не скомпилируется. Здесь LLM-агент читает существующий алгоритм, понимает его логику и вносит осмысленные изменения в Python-код.

- Нечеловеческая интуиция: агент открыл новые алгоритмы (например, VAD-CFR и SHOR-PSRO), использующие странные, неинтуитивные математические механизмы, которые люди полностью упустили.

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

Мы буквально наблюдаем рекурсивное самоулучшение ИИ в реальном времени.

Раньше человеческая интуиция была узким местом при поиске алгоритмических прорывов. Теперь достаточно направить LLM на кодовую базу, задать цель — и позволить ему автономно эволюционировать математику.

Статья

👉 @DataSciencegx

Недавно наткнулся на open-source туториал There Is No Spoon на GitHub — вводное руководство по машинному обучению, специально ориентированное на инженеров.

Вместо сухого, учебникового изложения он преобразует абстрактные концепции ML в аналогии из физики и инженерии, которые нам знакомы.

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

Контент покрывает три основных блока: базовые концепции, популярные архитектуры (свёрточные, attention, рекуррентные сети, state space модели и т.д.), а также gating-механизмы как практический инструментарий для систем управления.

Фокус не на заучивании математических выводов, а на том, как выбирать инструменты под конкретные задачи и понимать компромиссы при выборе архитектуры.

Весь туториал — это один Markdown-файл с 12 визуализациями. Рекомендуется читать его вместе с AI-ассистентом — загрузить текст и разбирать разделы в диалоге для лучшего понимания.

👉 @DataSciencegx

Математика — это не просто про числа, это про выявление сложных паттернов в окружающем мире.

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

В этом гайде Tiago разбирает архитектуру математики — и показывает, как использовать её в своём коде.

https://freecodecamp.org/news/the-architecture-of-mathematics-and-how-developers-can-use-it-in-code/

👉 @DataSciencegx

Python-декоратор — это всё, что нужно, чтобы трассировать LLM-приложения (open-source).

Большинство LLM-eval’ов рассматривают приложение как end-to-end чёрный ящик.

Но LLM-приложениям нужны eval’ы и трассировка на уровне компонентов, потому что проблема может быть где угодно внутри: в retriever’е, tool call или в самом LLM.

В DeepEval это можно сделать всего в 3 строки кода:

- Трассируйте отдельные компоненты LLM (tools, retrievers, generators) с помощью декоратора @observe.
- Привязывайте разные метрики к каждой части.
- Получайте визуальный разбор того, что работает, а что нет.

Готово.

Не нужно рефакторить существующий код.

Смотрите пример ниже для RAG-приложения.

DeepEval — полностью open-source (14k+ звёзд), его легко развернуть самостоятельно, чтобы данные оставались у вас.

👉 @DataSciencegx

Изучай LLM как инженер, а не как исследователь: полный гайд.

Если ты изучаешь большие языковые модели как инженер, твоя цель — не просто понимать их, а уметь их строить, оптимизировать и доводить до продакшена. Для этого нужна ясность на трёх уровнях: как модель работает внутри, как она обучается и дообучается (fine-tuning), и как эффективно запускается в продакшене.

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

👉 @DataSciencegx

Этот AI-прокси снижает расходы на LLM на 50% 🤯

Plano выступает как «умная data plane», которая автоматически маршрутизирует твои запросы к подходящей модели в зависимости от сложности задачи.

Работает на базе Arch-Router-1.5B, обеспечивая продакшн-уровень маршрутизации, развернутый в масштабе на Hugging Face.

- Умная маршрутизация LLM на основе сложности задачи
- Бесшовная оркестрация multi-agent сценариев
- Встроенные guardrails и observability

100% open-source

👉 @DataSciencegx

Анатомия agent harness

Глубокий разбор того, что на самом деле строят Anthropic, OpenAI, Perplexity и LangChain. Рассматриваются orchestration loop, инструменты, память, управление контекстом и всё остальное, что превращает stateless LLM в полноценного агента.

👉 @DataSciencegx

Трейсить и оценивать любое AI/LLM-приложение можно в 3 строках кода

- Инициализируете eval через LangWatch (строка 3)
- Декорируете метод LLM-воркфлоу (строка 5)
- Логируете результат оценки (строка 11)

При этом можно продолжать использовать Pandas и другие любимые инструменты.

100% open-source!

👉 @DataSciencegx

Нашёл репозиторий на GitHub с курируемым списком AI-инструментов, отсортированных по категориям 😊

Как использовать: ищи то, что тебе нужно, и найдёшь это там.

Огромная экономия времени

Ссылка: https://github.com/eudk/awesome-ai-tools

👉 @DataSciencegx

Следующий шаг после идеи wiki от Карпати:

LLM Wiki Карпати компилирует исходные источники в постоянную Markdown-вики с бэклинками и кросс-ссылками.

LLM читает статьи, извлекает концепции, пишет энциклопедические статьи и поддерживает индекс. Знание компилируется один раз и поддерживается в актуальном состоянии, поэтому LLM не нужно заново выводить контекст при каждом запросе.

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

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

Скомпилированная вики может иметь страницу о проекте, но она не будет эффективно отслеживать актуальное состояние (ground truth).

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

Rowboat — это open-source реализация именно этого подхода, построенная поверх той же базы Markdown + Obsidian, что использует Карпати, но расширенная под рабочий контекст.

Как это работает: система ingest’ит разговоры из Gmail, Granola и Fireflies и вместо создания одной summary-страницы на тему извлекает каждое решение, обязательство и дедлайн в отдельный Markdown-файл с бэклинками на вовлечённых людей и проекты.

Это структурно отличается от вики: страница «Project X» в вики даёт сводку обсуждений.

Граф знаний даёт полный набор: каждое принятое решение, кто его принял, что было обещано, когда это было обещано и изменилось ли что-то с тех пор.

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

Модель подключаешь свою — через Ollama, LM Studio или любой hosted API — а все данные хранятся в виде обычного Markdown, который можно открыть в Obsidian, отредактировать или удалить.

Репозиторий: https://github.com/rowboatlabs/rowboat

TL;DR: LLM Wiki Карпати компилирует исследования в постоянную Markdown-вики. Это хорошо работает для концепций и их связей, но плохо подходит для реальной работы с постоянно меняющимся контекстом. Rowboat вместо вики строит граф знаний, извлекает типизированные сущности с бэклинками и запускает фоновых агентов, работающих с накопленным контекстом. Open-source, local-first, со своей моделью. Карпати заложил фундамент. Следующий слой — здесь.

👉 @DataSciencegx

Обучить модель — это одно, а вывести её в продакшен — совсем другое.

В этой статье автор разбирает популярные инструменты, которые MLOps-инженеры используют для упаковки и деплоя моделей.

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

👉 @DataSciencegx

«How LLMs Follow Instructions» — короткая и интересная статья.

Если кратко: LLM не опираются на один универсальный механизм для следования инструкциям, а комбинируют несколько навыков (структура, семантика, стиль) в процессе генерации. Это сочетание навыков, работающих вместе.

👉 @DataSciencegx

MIT доказал, что можно удалить 90% нейросети без потери точности.

Исследователи обнаружили, что внутри каждой большой модели есть «выигрышный билет» (winning ticket) — маленькая подсеть, которая выполняет основную работу.

Они доказали: если найти её и сбросить в исходное состояние, она будет работать так же, как и вся большая модель.

Но был нюанс, который сразу убил практическое применение…

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

Оригинальная статья 2018 года была по-настоящему впечатляющей.

Но сегодня, спустя 8 лет… мы наконец получили прорыв на уровне железа: структурированная разреженность

Современные GPU (NVIDIA Ampere и новее) больше не просто «эмулируют» прунинг.

У них есть нативная поддержка блочной разреженности (паттерны 2:4), встроенная прямо в железо.

Это не теория — это ускорение на уровне силикона.

Математика выглядит очень убедительно: сеть с 90% разреженности = на 50% меньше пропускной способности памяти + 2× пропускная способность вычислений. Реальное ускорение без потери точности.

Три фактора сделали это готовым к продакшену в 2026:

- обучение с учётом прунинга (модель изначально обучается разреженной)
- нативная поддержка в PyTorch 2.0 и Apple Neural Engine
- понимание того, что AI-модели по своей природе на 90% избыточны

Эволюция переусложняет системы. Мы наконец научились их «прореживать».

Эпоха раздутых и неэффективных моделей официально закончилась. Инструменты наконец догнали теорию, и выигрывать будут те, кто перестанет платить за 90% весов, которые им не нужны.

Будущее AI — это более компактные, быстрые и эффективные модели.

👉 @DataSciencegx

Это уже следующий уровень.

MegaTrain: > LLM с 100B+ параметров, обученные на одной GPU

Это будет только развиваться.

В недалёком будущем…

У каждого человека будет свой персональный GPU с персональным сверхинтеллектом, который он обучил у себя дома.

👉 @DataSciencegx

Flash Attention — серия: разбор Softmax

Flash Attention — один из ключевых современных алгоритмов attention. В его основе лежит online softmax, и понимание этого механизма сильно упрощает понимание Flash Attention.

В PyTorch softmax определяется как функция, применяемая к N-мерному тензору, где выходной тензор нормализуется в диапазон [0, 1], а сумма всех элементов равна 1.

Читать статью

👉 @DataSciencegx

NVIDIA и Unsloth выпустили одно из лучших практических руководств по созданию RL-окружений с нуля, закрывая пробелы, которые пропускает большинство туториалов.

Включает:

- Почему RL-окружения важны + как их строить
- Когда RL превосходит SFT
- Лучшие практики GRPO и RL
- Как работают проверяемые награды и RLVR

https://unsloth.ai/blog/rl-environments

👉 @DataSciencegx

Полное глобальное внимание vs чередующееся внимание, визуальное объяснение:

👉 @DataSciencegx

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

Случайно наткнулся на опенсорс-проект под названием MathCode. Он принимает описание математической задачи на естественном языке и автоматически конвертирует его в теоремы для Lean 4, после чего пытается завершить формальное доказательство.

Проще говоря, это ассистент для доказательства теорем прямо в терминале. Вводишь фразу вроде «Докажи, что квадрат чётного числа — чётный», и он сам проходит весь пайплайн: от формализации до доказательства.

Также есть интеграция с Lean LSP, которая позволяет автоматически подтягивать существующие леммы из библиотеки Mathlib для помощи в доказательствах. Если возникают ошибки компиляции, система автоматически их исправляет и делает ретраи, до десяти итераций.

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

Если интересна формальная верификация математики или вы используете Lean 4 и считаете ручной процесс слишком трудоёмким, этот инструмент стоит попробовать.

👉 @DataSciencegx

Технический вопрос на собеседовании по большим языковым моделям:

У вас есть 80 000 траекторий агента из продакшена. Нужно выбрать те, которые стоит отправить на ревью, чтобы улучшить агента.

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

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

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

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

Сигналы делятся на три группы:

1. Сигналы взаимодействия — из диалога пользователь–агент.
Если пользователь переформулирует один и тот же запрос или исправляет агента — это рассинхронизация. Если агент повторяется без прогресса — стагнация. Запрос оператора или прекращение диалога — потеря вовлечённости. Подтверждение, что всё сработало — удовлетворённость. Всё это определяется через нормализованное сопоставление фраз и проверку схожести соседних реплик.

2. Сигналы выполнения — из вызовов инструментов и событий рантайма.
Вызов инструмента, который возвращает пустой результат или не двигает задачу, считается фейлом. Повторяющиеся вызовы с одинаковыми или «плывущими» входами указывают на цикл. Эти сигналы легко извлекаются из структурированных логов выполнения.

3. Сигналы окружения — ограничения по частоте, переполнение контекста, ошибки API.
Полезны для диагностики, но не подходят для обучения, так как отражают ограничения системы, а не решения агента.

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

На τ-bench сравнили три подхода на 100 траекториях:

- Случайная выборка — 54% информативности
- Эвристика по длине — 74%
- Сигнальный подход — 82%

То есть примерно 4 из 5 выбранных траекторий действительно полезны для улучшения агента.

Даже среди диалогов, где агент корректно выполнил задачу, сигнальный подход находил полезные паттерны в 66.7% случаев против 41.3% у случайной выборки.

Это скрытые проблемы: нарушения политик, неэффективное использование инструментов, лишние шаги. Задача формально выполнена, но есть потенциал для оптимизации.

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

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

GitHub → https://github.com/katanemo/plano
Статья → https://arxiv.org/pdf/2604.00356

👉 @DataSciencegx