🔥Real-time SQL Traffic Viewer

sql-tap — это прокси-демон, который перехватывает SQL-запросы между вашим приложением и базой данных (PostgreSQL или MySQL), отображая их в интерактивном терминальном интерфейсе. Позволяет анализировать запросы и транзакции без изменения кода приложения.

Основные моменты:

⏺️ Перехват SQL-запросов в реальном времени
⏺️ Поддержка PostgreSQL и MySQL
⏺️ Интерактивный интерфейс для анализа запросов
⏺️ Возможность использования EXPLAIN для оптимизации запросов

➡️ GitHub: https://github.com/mickamy/sql-tap

Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥Про боли женского шоппинга

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

Материал большой, иллюстративно красивый и «жирный» по фактуре. Вот несколько фактов из него:

⏺️Больше половины взрослых женщин в США оказываются вне стандартной линейки размеров — она рассчитана скорее на 15-летних подростков.
⏺️Универсальных размеров нет. S, M, XL у разных брендов — это абсолютно разная одежда. Подбор подходящего наряда при этих условиях превращается в кошмар.
⏺️Ещё круче. Со временем размерная сетка меняется, играя на чувстве «спустя 10 лет я всё ещё влезаю в свой размер!».
⏺️В массовом производстве дизайнеры часто берут size 8 как базовую форму, а остальные размеры получают простым масштабированием вверх и вниз. Это удобно для фабрик, но плохо учитывает реальные различия в пропорциях тела. В итоге в реальности вещь может подходить по талии, но плохо садиться по бёдрам, или наоборот.

➡️ Подробнее: pudding.cool/2026/02/womens-sizing/

Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥Как правильно установить и использовать браузер в Linux.

Если браузер работает медленно или ломается после обновлений - проблема часто не в Linux, а в установке. Многие ставят браузер из случайных источников или вручную скачивают архивы, из-за чего нет автообновлений, слетают зависимости и появляются ошибки.

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

⏺️ автоматические обновления безопасности
⏺️ корректные зависимости
⏺️ стабильную работу
⏺️ удобный запуск из системы

Для примера установим Google Chrome официальным способом.

Установка Google Chrome (Ubuntu / Debian)
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo apt install -y ./google-chrome-stable_current_amd64.deb

Запуск браузера
google-chrome

Обновление системы (включая браузер)
sudo apt update && sudo apt upgrade -y

Проверка версии
google-chrome --version

Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Zero-cost поиск для AI-приложений — идея из turbopuffer

Большинство систем поиска и векторных БД сегодня очень дорогие.
Причина простая, они хранят данные в RAM или реплицированных SSD, где стоимость может доходить до $600–$3600 за TB в месяц.

Но turbopuffer предлагает другой подход.

Хранить данные не в памяти серверов, а в object storage (например S3 или GCS).

Стоимость:

⏺️ RAM + SSD инфраструктура - до $3600/TB
⏺️ SSD-кластеры - около $600/TB
⏺️Object storage (S3) - примерно $20/TB

Разница может достигать до 100× дешевле для холодных данных.

📌 Архитектура turbopuffer:

Client
↓
Query layer
↓
SSD / memory cache (горячие данные)
↓
Object storage (источник истины)

То есть:

⏺️ холодные данные хранятся дешево в object storage
⏺️ часто используемые попадают в SSD или RAM cache
⏺️ запросы остаются быстрыми (<100ms), но стоимость инфраструктуры падает на порядок

Vector search становится ключевой частью AI-систем:

⏺️ RAG
⏺️ AI-ассистенты
⏺️ semantic search
⏺️recommendation systems

Но именно retrieval слой часто становится самой дорогой частью AI-инфраструктуры.

Архитектура turbopuffer показывает, что:
> дешевый storage + умный cache
> может заменить дорогие memory-based search системы.

Будущее AI-поиска может выглядеть так:

⏺️ object storage как источник данных
⏺️ stateless compute
⏺️ дешёвый storage
⏺️ кэш для hot data

И тогда поиск по миллиардам документов становится почти “zero-cost” инфраструктурой.

Подробнее:
https://turbopuffer.com/blog/zero-cost

Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ Трюк дня. Сравнение с предыдущим. Решение.

Решение: использование DATEDIFF

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

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

SELECT DISTINCT a.Id
FROM Weather a, Weather b
WHERE a.Temperature > b.Temperature
AND DATEDIFF(a.Recorddate, b.Recorddate) = 1

Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Ошибки при train/test split

Train/test split — кажется самой простой частью ML.
Но именно здесь чаще всего ломают всю модель.

И самое опасное — ты можешь даже не заметить

Data Leakage — тихий убийца моделей

Ты случайно «подсматриваешь» в тест.

Примеры:

👉 нормализация на всём датасете до split
👉 target encoding на всех данных
👉 feature, напрямую связанная с таргетом

Модель показывает космический скор,
а в проде — провал.

Случайный split там, где нельзя

Ты делаешь random split…
но данные зависимы.

Примеры:

👉 временные ряды
👉 пользователи (один и тот же user в train и test)
👉 сессии

Модель узнаёт данные, а не обобщает.

Игнорирование времени

В задачах с временем:

👉 ❌ случайный split
👉 ✅ train = прошлое, test = будущее

Иначе ты:

👉 обучаешься на будущем
👉 предсказываешь прошлое

Это не ML. Это читерство.

4️⃣ Дисбаланс классов в split

Ты сделал split и получил:

👉 train: 5% positive
👉 test: 1% positive

Метрики начинают врать.
Решение:

👉 stratified split

Слишком маленький test

Test = 50 объектов
Accuracy = 90%

Звучит круто.
Но это статистический шум.

Маленький test = ненадёжная оценка.

Тест используется как валидация

Классическая ошибка:

👉 обучился
👉 посмотрел на test
👉 подкрутил модель
👉 снова посмотрел

Это уже не test. Это validation 2.0.

Дубликаты в train и test

Если один и тот же объект попал в обе выборки:

Модель просто запоминает.
Особенно критично:

👉 CV
👉 e-commerce
👉 табличные данные с ID

Неправильный split в CV

Cross-validation тоже можно сломать:

👉 leakage между фолдами
👉 группы не учитываются
👉 time-series перемешаны

Используй:

👉 GroupKFold
👉 TimeSeriesSplit

Главный инсайт

Train/test split — это не про «разделить данные».

Это про симуляцию реального мира.
Если split не отражает прод —
все метрики бесполезны.

В одном предложении

Плохой split может сделать плохую модель «идеальной» —
до момента, когда она выйдет в прод.

Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Заводчане в Индии носят камеры на голове, чтобы на этих видео потом могли обучать роботов

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

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

Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ ByteDance только что open-sourced OpenViking, и этот проект показывает, что именно не так с тем, как сегодня строят память для AI-агентов.

Вот где большинство агент-фреймворков ошибаются:

Память хранится в одном месте.
Ресурсы — в другом.
Навыки разбросаны по системе.

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

Именно это и проблема. OpenViking решает её одной идеей:
рассматривать контекст агента как файловую систему.

Всё работает через единый протокол:

viking://

Память, ресурсы и навыки организованы как директории с уникальными URI.
Агент может ls, find и навигировать по контексту, как разработчик в терминале.

Главный прорыв — многоуровневая загрузка контекста:

- L0 — одно предложение для быстрого поиска
- L1 — обзор ~2000 токенов для принятия решений
- L2 — полные детали, загружаются только когда действительно нужны

Большинство агентов просто загружает всё в контекст и надеется на лучшее.

OpenViking загружает только нужные данные и только в нужный момент.

Результат:

- меньше расходов на токены
- выше точность
- быстрее работа агентов

Retrieval теперь тоже работает логичнее.

Вместо одного плоского семантического поиска:

1. сначала происходит позиционирование на уровне директорий
2. затем рекурсивный поиск внутри наиболее релевантных директорий

Можно буквально видеть траекторию поиска — это больше не чёрный ящик.

Есть и механизм самоэволюции агента.

В конце каждой сессии система автоматически:

- извлекает новые знания
- обновляет память агента
- обновляет память пользователя

То есть агент становится умнее с каждым использованием.

Проект уже имеет:

- 9K звёзд на GitHub
- 13 контрибьюторов

Разработан командой ByteDance Viking, которая строит инфраструктуру векторного поиска с 2019 года.

Проект полностью open-source под лицензией Apache 2.0.

Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Умный помощник для Claude Code

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

Основные моменты:
⏺️ Многофункциональные команды для разных ролей (CEO, инженер, QA).
⏺️ Интеграция с Conductor для параллельной работы.
⏺️ Полная автоматизация тестирования и ревью.

➡️ GitHub: https://github.com/garrytan/gstack

Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 SQL-концепции, которые реально нужно знать:

⏺️ CRUD → SELECT, INSERT, UPDATE, DELETE
⏺️ Ключи → PRIMARY KEY, FOREIGN KEY
⏺️ Ограничения → NOT NULL, UNIQUE, CHECK, DEFAULT
⏺️ JOIN’ы → INNER JOIN, LEFT JOIN, RIGHT JOIN
⏺️ Агрегации → COUNT, SUM, AVG, MIN, MAX
⏺️ Группировка → GROUP BY, HAVING
⏺️ Фильтрация → WHERE, BETWEEN, IN, LIKE
⏺️ Сортировка → ORDER BY
⏺️ Подзапросы → SELECT (SELECT …)
⏺️ Индексы → CREATE INDEX
⏺️ Представления → CREATE VIEW
⏺️ Транзакции → BEGIN, COMMIT, ROLLBACK
⏺️ Пагинация → LIMIT, OFFSET
⏺️ Оптимизация → EXPLAIN

Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ Cursor сделал regex-поиск мгновенным

Instant Grep ищет по миллионам файлов за миллисекунды
16.8 сек → 13 мс

И главное:
они не ускоряли regex
они убрали лишний поиск

Как это работает

- создаётся индекс: куски текста → файлы
- используются триграммы (fil, ile, le_)
- сначала ищутся кандидаты
- потом запускается regex

большинство файлов вообще не открывается

🔥Ключевая идея - sparse n-grams

- индексируются не все куски
- только самые «полезные»
- редкие символы имеют больший вес

Всё локально

- индекс хранится у тебя
- привязан к Git
- быстрый доступ через memory map

Скорость даёт не regex
а умный отбор файлов до поиска.

https://x.com/cursor_ai/status/2036122609931165985

Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Выложили в open source крупнейшую базу интеграций для AI-агентов.

- 47 000 действий для агентов в 250+ приложениях
- Подключения к Slack, GitHub, Gmail, Stripe, Discord, Google Sheets и другим сервисам
- Все действия проверены, агент больше не «галлюцинирует» API
- Разворачивается одной CLI-командой: подключил один раз — используешь везде

Это тот самый слой интеграций, которого агентам давно не хватало.

https://github.com/withoneai/cli

Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ Таблицы теперь живут прямо в терминале

Да, без Excel и без GUI.

Sheets - это инструмент, который позволяет читать и редактировать CSV прямо в терминале через TUI или CLI.

Что внутри:

⏺️ полноценная работа с таблицами без выхода из терминала
⏺️ vim-подобные хоткеи и навигация
⏺️ быстрые правки без лишнего оверхеда

Работает на Windows, macOS и Linux.

Идеально, если ты живёшь в терминале и не хочешь дергаться между окнами.

Excel начинает нервничать.

https://github.com/maaslalani/sheets

Всё про Data Science

🇷🇺 Читайте нас в MAX

➡️ Китайцы выкатили мощный голосовой ИИ - VoxCPM2

Модель от OpenBMB, которая умеет:

⏺️ Понимать и генерировать речь
⏺️ Работать с голосом почти в реальном времени
⏺️Делать voice-to-voice без сложных пайплайнов
⏺️ Подходит под ассистентов, звонки и голосовые агенты

Главный плюс - всё это в одной модели, без костылей из ASR + TTS


https://huggingface.co/openbmb/VoxCPM2

Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Гайд: как настроить WAL, чтобы отслеживать изменения в PostgreSQL?

Возможно, кто-то из прочитавших заголовок скажет — зачем возиться с WAL, если есть более простые способы. NOTIFY, например.

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

Кроме того, их размер ограничен 8000 байтов, чего может быть недостаточно. А еще, если сервис-получатель был по какой-то причине не доступен и сообщение не дошло, повторное через NOTIFY не отправляется — то есть данные просто потеряются.

В общем, не идеальный вариант.

➡️ Альтернатива — это настроить Write-Ahead Log или WAL, чтобы получать уведомления из него.

Спойлер: этот вариант тоже не идеальный. Как минимум, придется повозиться:
⏺️Изменить wal_level на logical со стандартного replica — так он начнет делать более подробные записи о том, как и что конкретно изменилось в базе.
⏺️Создать publications (то есть, расписать, какие таблицы и действия вы хотите отслеживать) и репликационный слот (то есть отдельную копию WAL, которая гарантирует, что никакие важные данные из лога не удалятся, пока уведомление не будет отправлено).
⏺️Создать listener, который будет получать уведомления и перенаправлять их дальше — в очередную таблицу, в приложение или мессенджер. Или вообще распечатать.

➡️ Но если вам нужно настроить отправку уведомлений и другие способы не подходят, это может быть вполне рабочее решение. Как воплотить его в жизнь, по шагам описано в подробном (очень подробном) гайде.

Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Государство, вузы и бигтех: кто развивает ИИ-образование в мире?

Этим вопросом задалась команда J'son & Partners Consulting, которая сравнила подходы к подготовке ИИ-специалистов в России, США и Китае. Во всех трех странах ключевой вызов один — образование не успевает за темпами развития технологий, поэтому важно его адаптировать.

Какие меры предпринимают:

⏺️В Китае ИИ-образование взяло под свой контроль государство: оно задает стандарты обучения, выделяет финансирование на проекты, направленные на популяризацию технологий искусственного интеллекта, и вводит уроки по работе с ним в школьную программу.

⏺️В США ситуация противоположная: за подготовку ИИ-кадров отвечают топовые вузы, обучение в которых может стоить десятки тысяч долларов. Вместо массовости они делают ставку на обучение небольшого числа специалистов очень высокого уровня.

⏺️Россия пошла по своему пути: здесь ключевую роль играют бигтехи. Технологические компании совместно с вузами задают ориентиры подготовки ИИ-специалистов. Сегодня обучение развивается в формате партнерских программ — университеты дают фундамент, а бизнес приносит экспертизу в тех областях технологий, о которых еще на написаны учебники. По этой модели, например, запущен бакалавриат AI360 — совместный проект двух ведущих компаний и пяти университетов.

➡️ У всех трех моделей есть свои плюсы. Но если у вас стоит выбор STEM-вуза, смотрите и на конкретных партнеров, с кем он делает свои программы.

Всё про Data Science

🇷🇺 Читайте нас в MAX

🔥 Продвинутый SQL совет - всегда проверяй, можно ли заменить SELECT DISTINCT на правильный JOIN или EXISTS.

Очень часто DISTINCT добавляют просто чтобы убрать дубли после неудачного join. Запрос вроде работает, но по факту ты сначала раздуваешь результат, а потом заставляешь базу его чистить. На больших таблицах это легко убивает производительность.

Плохой вариант:

SELECT DISTINCT u.id, u.name
FROM users u
JOIN orders o ON o.user_id = u.id;

Лучше так:

SELECT u.id, u.name
FROM users u
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.user_id = u.id
);

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

Это один из самых частых hidden performance fixes в SQL. Если видишь DISTINCT, сразу спрашивай себя: он тут реально нужен или просто маскирует плохую логику JOIN.

Всё про Data Science

🇷🇺 Читайте нас в MAX