SQL и Анализ данных

🔥 Полное внимание возвращается: 9× ускорение префилла на 1M токенов Alibaba и Нанкинский университет показали метод RTPurbo. На контексте в миллион токенов префилл ускоряется до 9,36× относительно FlashAttention-2, декодинг - примерно вдвое. Качество на длинных бенчмарках остаётся близким к full attention, а адаптация лёгкая: переобучать модель с нуля не нужно. Идея в том, что внутри уже обученной модели с full attention есть скрытая разреженность. Не все attention heads реально ходят за дальними токенами. Большинство работает локально, а за retrieval из далёкого контекста отвечает только небольшая часть голов. RTPurbo считает полное внимание только для этих retrieval-голов. Остальным хватает соседнего окна. Для поиска нужных токенов используется дешёвый 16-мерный индексатор. Он не заменяет настоящее внимание, а работает как разведчик: быстро отбирает кандидатов из прошлого контекста, после чего честное внимание считается уже на маленьком наборе токенов в полной размерности. Длинный контекст стоит дорого не потому, что вся история одинаково важна, а потому что мы часто считаем внимание там, где оно почти ничего не меняет. RTPurbo показывает, что значительную часть вычислений можно срезать инженерно, без полного переобучения модели и без заметной потери качества. В full attention много лишней работы, и её можно убирать гораздо аккуратнее, чем просто резать контекст или надеяться на магию sparse attention. arxiv.org/abs/2605.16928v1

Кажется, аналитика подошла к моменту больших изменений. Ещё недавно подготовка отчётов занимала дни: данные собирались вручную, цифры перепроверялись, а бизнес слишком долго ждал ответы. Сегодня искусственный интеллект меняет сам подход к работе с данными — делает аналитику быстрее, проще и доступнее. 3 июня Visiology проведёт большой онлайн-эфир Cortex LIVE о новом поколении аналитики. На бесплатном эфире покажут: — как ускорить получение аналитики — как сократить объём ручной работы — как быстрее находить ответы для бизнеса — как компании уже меняют подход к работе с данными Без сложной теории — только реальные примеры и практические сценарии. Если вы работаете с аналитикой, отчётностью или управлением, этот эфир точно стоит посмотреть. До мероприятия осталось совсем немного времени — успейте зарегистрироваться заранее, чтобы не пропустить эфир.

🆓 Ваши SQL-запросы работают, но через месяц их уже сложно прочитать и изменить? С ростом логики запросы превращаются в набор вложенных подзапросов. Разобраться в них сложно, поддержка занимает время, а любые изменения несут риск сломать результат. На открытом уроке разберём: как использовать обобщенные табличные выражения (CTE), чтобы писать сложные запросы по шагам. Покажем, как упростить структуру, сделать код читаемым и работать с иерархиями через рекурсивные CTE. 🗓 Урок проходит в преддверии старта курса «PostgreSQL для администраторов баз данных и разработчиков». Если вы хотите писать SQL, который легко читать и поддерживать — подключайтесь 27 мая в 20:00 МСК. 🔗 Регистрация открыта: https://tglink.io/e6a3872408e743?erid=2W5zFJG1JPK Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

🔥 Huawei хочет обойти санкции не нанометрами, а задержками в чипе Huawei представила Tau Scaling Law - подход, который должен ускорять чипы не только за счёт уменьшения транзисторов, а за счёт сокращения времени прохождения сигнала внутри схемы. Идея простая: если нельзя быстро догнать TSMC и Intel по литографии, нужно выжимать больше из архитектуры, трассировки, памяти, interconnect и софта. Меньше лишнего пути для сигнала - меньше задержка, выше плотность и эффективность. Ключевая техника называется LogicFolding. Связанные логические блоки размещают ближе друг к другу, укорачивают критические провода, снижают сопротивление и паразитную ёмкость. Это даёт прирост без полноценного скачка на новый техпроцесс. Huawei утверждает, что за последние шесть лет уже спроектировала и массово выпустила 381 чип с этим подходом, а будущие Kirin осенью 2026 года станут первым крупным тестом LogicFolding. Самая громкая заявка - к 2031 году выйти на плотность уровня 14Å, то есть примерно 1,4 нм, без прямой зависимости от классического shrink. Звучит амбициозно, но контекст важен: после санкций Huawei фактически вынуждена искать обходные инженерные пути. Если доступ к лучшей литографии ограничен, приходится оптимизировать всё остальное - от транзистора и схемы до системной шины и планировщика. Это не отменяет физику и не делает Huawei новым TSMC завтра. Но показывает, куда может сдвинуться гонка чипов: не только «у кого меньше нанометры», а «кто лучше сокращает задержки по всему стеку». huawei.com/en/news/2026/5/ieee-iscas-tau-scaling

🤖 Machine Learning Roadmap: от базы до гуру вайбкодинга Карта обучения машинному обучению (Machine Learning, Deep Learning, LLM, Generative AI, MLOps) - от первого import numpy до уровня инженера, который понимает, как ИИ работает внутри, и может писать прод‑системы, а не только дёргать API. https://github.com/justxor/MachineLearningRoadmap/tree/main

🖥 SQL можно учить не по скучным таблицам, а через игру в стиле «Матрицы» Разработчик сделал тренажёр, где вы проходите уровни, находите терминалы и «взламываете» их SQL-запросами. Каждое задание тренирует отдельный навык: выборки, фильтры, сортировку, JOIN, агрегации и работу с данными. Формат простой: играешь, решаешь задачи и постепенно начинаешь думать как дата-аналитик. Идеальный вариант на выходные, если давно хотели подтянуть SQL без унылой теории. http://sqlprotocol.com/

Открыл Claude, написал большой промпт - получил обычный нейротекст. Рабочая схема другая. Сначала делаете файл about-me.md. Туда кладёте: кто вы, для кого пишете, какой стиль нужен, что бесит в текстах, какой результат хотите получать. Потом подключаете этот файл в Cowork, чтобы Claude читал его перед каждой задачей. И только после этого даёте реальную задачу: пост, план, письмо, разбор, аудит. Главный трюк - перед стартом заставьте Claude задать уточняющие вопросы. Не угадывать, а сначала понять задачу. В итоге он пишет не «как ИИ», а ближе к вашему стилю, потому что у него есть контекст. В комментариях оставлю промпт и схему. Подписывайтесь, если хотите пользоваться Claude как рабочим инструментом, а не генератором красивой воды.

Claude можно превратить в личного сборщика презентаций: https://www.youtube.com/watch?v=5RNTmbbyUHw Большинство людей просят AI: «сделай слайды» - и получают обычный текст, который потом приходится вручную переносить в PowerPoint. Но есть способ лучше: сделать для Claude отдельный Skill под презентации. Открываете Claude, заходите в Customize, выбираете Skills, создаете новый skill и вставляете туда свои правила: какие презентации вы делаете, для какой аудитории, в каком стиле, какая структура нужна и что должно быть на каждом слайде. После этого Claude перестает гадать. Он уже знает, как должен выглядеть ваш deck: где нужен сильный opening slide, где краткий executive summary, где схема, где таблица, где финальный CTA. Главная мысль простая: чем точнее instructions, тем меньше ручной переделки. Вместо хаотичного «сделай презентацию» вы получаете повторяемый workflow: один раз настраиваете skill, а дальше Claude собирает слайды по вашим правилам. Это не магия. Это нормальная упаковка контекста, стиля и структуры в reusable-инструмент. Именно так AI начинает работать не как чат-бот, а как часть вашего production-процесса. https://www.youtube.com/shorts/qyYOG338hyY

⚡️ Один SQL-запрос выполнялся за 298 мс. Почти такой же - за 0,66 мс. Разница в 451 раз из-за одной строки. Ситуация обычная: cursor pagination, сортировка по date DESC, id DESC, лимит на 1000 записей и composite index по (date, id). На первый взгляд, все должно работать быстро. Но EXPLAIN ANALYZE показывает другое: Postgres вроде бы использует Index Scan, но после этого выкидывает 900 000 строк через Filter. То есть индекс есть, но запрос все равно тащит слишком много лишнего. Проблема в условии: `date < @date OR (date = @date AND id <= @lastId)` Для разработчика это выглядит логично: сначала сравниваем дату, потом id. Но для оптимизатора такой OR плохо ложится на composite index. В итоге база не может сразу пойти по нужному диапазону и вынуждена фильтровать огромный кусок данных. Правильнее записать условие через tuple comparison: `(date, id) <= (@date, @lastId)` Смысл тот же, но для Postgres это уже понятный диапазон по составному индексу. И результат: 298 мс превращаются в 0,66 мс. Индекс сам по себе ничего не гарантирует. Важно не только создать индекс, но и написать запрос так, чтобы оптимизатор реально смог его использовать.

Редкий и реально продвинутый SQL-совет: используй логарифмы для произведения вероятностей. В SQL удобно считать SUM, AVG, COUNT, но почти никто не думает про PRODUCT. А в аналитике он часто нужен: вероятность цепочки событий, retention funnel, скоринговые модели, reliability, ML-фичи. Проблема: если перемножать много маленьких чисел, например 0.97 * 0.91 * 0.88 * ..., быстро получишь underflow или потерю точности. Математический трюк:

a * b * c = exp(ln(a) + ln(b) + ln(c))

То есть вместо прямого произведения считаем сумму логарифмов.

SELECT
    user_id,
    EXP(SUM(LN(probability))) AS total_probability
FROM events
WHERE probability > 0
GROUP BY user_id;

Где это полезно:

SELECT
    user_id,
    EXP(SUM(LN(conversion_rate))) AS funnel_survival_rate
FROM funnel_steps
GROUP BY user_id;

Это стандартный численный прием из математики, который делает расчет стабильнее. Особенно полезно, когда у тебя много шагов в воронке, вероятностная модель, риск-скоринг или аналитика событий. Главное правило: LN(x) работает только для x > 0, поэтому нули нужно обрабатывать отдельно. Например, если хотя бы одна вероятность равна нулю, итоговое произведение тоже будет ноль.

🖥 Курс «Git Pro: от первого коммита до уровня senior» - на Stepik project_final_v2_FINAL_truly_final - знакомо? Значит, пора. Большинство разработчиков знают 5 команд Git и боятся шестую. Коммитят в main, гуглят «how to undo» и копируют папку «на всякий случай». Это не работа - это выживание. После курса вы: — делаете rebase, не задерживая дыхание; — разбираете конфликт на 200 файлов по алгоритму; — возвращаете «потерянные навсегда» коммиты за 30 секунд через reflog; — пишете историю, которую не стыдно показать на code review. Git Flow, trunk-based, Pull Request, защита веток, CI/CD-хуки — всё, что отличает джуна от senior в командной работе. Скидка 53%, 48 часов: https://stepik.org/course/284799/

🚀 Примеры использования Cursor SDK для разработки Репозиторий содержит небольшие примеры для работы с Cursor SDK на TypeScript. Он позволяет интегрировать кодирующего агента в ваши приложения, управлять состоянием и взаимодействовать с агентами в облаке и локально. 🚀 Основные моменты: - Примеры для создания агентов и работы с API. - Веб-приложение для быстрой разработки и тестирования. - Канбан-доска для управления агентами и артефактами. - CLI для запуска агентов из терминала. 📌 GitHub: https://github.com/cursor/cookbook

wtf 💀

🖥 На Stepik обновили курс «C# с нуля до профи» Представьте: через четыре месяца вы открываете чужой .NET-проект и читаете его как книгу. IServiceCollection не вызывает ступора. async Task<IActionResult> пишется на автомате. Вы точно знаете, почему EF Core сгенерировал именно такой SQL - и как переписать запрос, чтобы он летал. Это не фантазия. Это результат после 16 модулей, в которых каждая концепция объясняется через код и закрепляется практикой. ООП, SOLID, LINQ, async/await, DI, EF Core, ASP.NET Core, Docker, Kubernetes - всё, что казалось магией, станет рабочим инструментом. А бонусом - портфолио проектов: от CLI-утилит и REST API до собственного SaaS с multi-tenancy, JWT и деплоем в Kubernetes под TLS. Скидка - 58% доступна 48 часов: https://stepik.org/a/282984/

⚡️ Векторные базы данных хорошо ищут похожие куски текста, но плохо понимают связи между ними. Обычный поиск работает так: есть вопрос - база находит top-k самых похожих фрагментов. Это удобно, если нужно вытащить один факт. Но если ответ спрятан в нескольких местах, например в разных документах, сообщениях или частях отчёта, простого similarity search уже мало. Нужно понять, как связаны люди, события, компании, причины и последствия. На этом и делает акцент FalkorDB GraphRAG-Bench. Самый большой отрыв у GraphRAG виден именно в сложных задачах: Complex Reasoning - 83.61 и Contextual Summarization - 85.08. То есть там, где нужно не просто найти похожий текст, а собрать смысл из нескольких связанных фрагментов. Простой вывод: если у вас база знаний, длинные документы или корпоративные данные, одного Vector DB может быть недостаточно. GraphRAG помогает модели не просто искать, а идти по связям. GraphRAG SDK полностью open-source: https://github.com/FalkorDB/GraphRAG-SDK

🚀 Логическая аналитика с LynxDB LynxDB — это легковесная система для анализа логов, работающая в одном бинарном файле без зависимостей. Она использует язык запросов Lynx Flow, позволяющий легко обрабатывать данные в виде конвейера. 🚀 Основные моменты: - Пайплайн-запросы для обработки данных - Полнотекстовый поиск и колоночное хранилище - Поддержка кластерного режима и материализованных представлений - Никакой конфигурации — разумные настройки по умолчанию - Активная разработка, обратная связь приветствуется 📌 GitHub: https://github.com/lynxbase/lynxdb #rust

🖥️✨ Hermes Web UI: Интуитивный веб-дашборд для управления AI чатами. Позволяет отслеживать использование, настраивать каналы и управлять заданиями через удобный интерфейс. 🚀Основные моменты: - Мультисессионное управление чатами с поддержкой различных платформ. - Аналитика использования токенов и отслеживание затрат. - Настройка и управление заданиями по расписанию. - Интегрированный терминал для работы с несколькими сессиями. 📌 GitHub: https://github.com/EKKOLearnAI/hermes-web-ui #javascript

Продвинутый SQL-прием: partial index вместо “универсального” индекса Если в таблице много строк, но запрос почти всегда смотрит только активные записи, не обязательно индексировать всё. Например, есть таблица заказов:

SELECT *
FROM orders
WHERE user_id = 42
  AND status = 'active';

Обычный индекс:

CREATE INDEX idx_orders_user_status
ON orders(user_id, status);

Работает, но он хранит данные по всем статусам: active, cancelled, archived, failed и так далее. Если чаще всего нужны только активные заказы, можно сделать partial index:

CREATE INDEX idx_orders_active_user
ON orders(user_id)
WHERE status = 'active';

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

SELECT *
FROM orders
WHERE user_id = 42
  AND status = 'active';

Индекс не обязан покрывать всю таблицу. Иногда лучший индекс - это индекс только по тем строкам, которые реально участвуют в горячих запросах. Особенно полезно для флагов вроде deleted_at IS NULL, status = 'active', is_published = true, processed = false. #sql #postgresql #database #backend