Data Science: SQL и Аналитика данных

🔥 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

🔥 Милла Йовович теперь тоже Вайбкодер😱 Актриса выложила на GitHub опенсорс-инструмент MemPalace для работы с памятью ИИ-агентов. Делала его вместе с другом. Фишка в том, что все данные хранятся локально, а система сама решает, какие факты о пользователе подтягивать под конкретный запрос. По бенчмарку LongMemEval инструмент уже обгоняет и платные, и бесплатные решения. За сутки репозиторий набрал 2k+ звёзд. Похоже, границы между индустриями окончательно стерлись 💀 ➡️ https://x.com/bensig/status/2041229266432733356 Всё про Data Science 🇷🇺 Читайте нас в MAX

🔥 Умный помощник для Claude Code gstack превращает Claude Code в команду специалистов, доступных по запросу. Он предлагает восемь навыков для управления рабочими процессами, включая планирование, ревью кода и автоматизацию браузера, все через удобные команды. Основные моменты: ⏺️ Многофункциональные команды для разных ролей (CEO, инженер, QA). ⏺️ Интеграция с Conductor для параллельной работы. ⏺️ Полная автоматизация тестирования и ревью. ➡️ GitHub: https://github.com/garrytan/gstack Всё про 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

🔥 Заводчане в Индии носят камеры на голове, чтобы на этих видео потом могли обучать роботов Для корпораций это фактически бесплатно, а датасет выходит уникальным — таких данных нет в интернете и их невозможно сгенерировать синтетически. Так что да, люди сами помогают создавать себе замену. Всё про 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

➡️ Трюк дня. Сравнение с предыдущим. Решение. Решение: использование 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

🔥 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

🔥Как правильно установить и использовать браузер в 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

🔥Про боли женского шоппинга The Pudding пытаются повторить успех своего легендарного проекта про карманы в женских джинсах, на этот раз рассказывая про проблемы женской одежды в целом. Материал большой, иллюстративно красивый и «жирный» по фактуре. Вот несколько фактов из него: ⏺️Больше половины взрослых женщин в США оказываются вне стандартной линейки размеров — она рассчитана скорее на 15-летних подростков. ⏺️Универсальных размеров нет. S, M, XL у разных брендов — это абсолютно разная одежда. Подбор подходящего наряда при этих условиях превращается в кошмар. ⏺️Ещё круче. Со временем размерная сетка меняется, играя на чувстве «спустя 10 лет я всё ещё влезаю в свой размер!». ⏺️В массовом производстве дизайнеры часто берут size 8 как базовую форму, а остальные размеры получают простым масштабированием вверх и вниз. Это удобно для фабрик, но плохо учитывает реальные различия в пропорциях тела. В итоге в реальности вещь может подходить по талии, но плохо садиться по бёдрам, или наоборот. ➡️ Подробнее: pudding.cool/2026/02/womens-sizing/ Всё про Data Science 🇷🇺 Читайте нас в MAX

🔥Real-time SQL Traffic Viewer sql-tap — это прокси-демон, который перехватывает SQL-запросы между вашим приложением и базой данных (PostgreSQL или MySQL), отображая их в интерактивном терминальном интерфейсе. Позволяет анализировать запросы и транзакции без изменения кода приложения. Основные моменты: ⏺️ Перехват SQL-запросов в реальном времени ⏺️ Поддержка PostgreSQL и MySQL ⏺️ Интерактивный интерфейс для анализа запросов ⏺️ Возможность использования EXPLAIN для оптимизации запросов ➡️ GitHub: https://github.com/mickamy/sql-tap Всё про Data Science 🇷🇺 Читайте нас в MAX

🔥 Самый хайпующий проект в интернете прямо сейчас – Pretext Инженер из Midjourney выложил в опенсорс алгоритм, который позволяет делать верстку без CSS. То есть он сам считает layout текста, без DOM и без браузерного reflow. Звучит странно, потому что мы привыкли, что за это отвечает браузер. Но браузер делает это тяжело, через каскад стилей, зависимости между элементами и пересчеты при каждом изменении. Если текст часто меняется, вся система начинает тормозить. Pretext убирает этот слой и сводит задачу к прямой математике. Собственно, это дает кратный выигрыш по скорости – до 500х. Зачем это все нужно? Сейчас появляется все больше интерфейсов, где текст и структура не заданы заранее, а формируются динамически. В частности – это история про агентов. Когда агент собирает UI под задачу пользователя, интерфейс не фиксирован, он постоянно меняется, иногда буквально на каждом шаге. И каждый такой апдейт через браузерный reflow – это лишняя задержка и непредсказуемость. С Pretext это занимает гораздо меньше времени + полностью контролируемо со стороны кода. Когда интерфейс генерирует не человек, а система, удобнее работать с прямыми алгоритмами, а не с тяжелым браузерным пайплайном. Ну и, конечно, выглядит это очень красиво. За счет скорости обработки выдумать поверх Pretext можно что угодно (примеры прикладываем). И все же в первую очередь проект интересен именно тем, как изящно он ложится на новые сценарии. ➡️ github.com/chenglou/pretext Всё про Data Science 🇷🇺 Читайте нас в MAX

⚡️Чем занимается аналитик и как получить оффер в 2026 году? Переживаете, что рынок труда нестабилен? Хотите ворваться в аналитику, но не знаете как гарантировать себе трудоустройство? Все эти переживания уходят, если вы уверены в правильности своих действий, уверены в своих компетенциях, резюме и портфолио. Приглашаем на бесплатный вебинар, где Андрон Алексанян - эксперт в области аналитики и CEO школы аналитики Simulative — в прямом эфире разберет все важные аспекты в работе аналитика, а также расскажет как получить оффер быстрее других. Кстати на вебинаре разберут и то как стать аналитиком в 30/40/50 и более лет. На вебинаре будет: 🟠Разберем полный роадмап: что учить, в каком порядке, до какого уровня; 🟠Структура хорошего портфолио с примерами; 🟠Что говорят реальные наниматели - какие у них сейчас требования:

— Покажем реальные примеры, как оформить резюме и портфолио, чтобы привлекать внимание; — Обсудим какие отклики работают, а какие сразу отправляют в корзину; — Изнанка найма: инсайдерский взгляд на процессы отбора

🟠 Практические техники для новичков: разберём, как компенсировать недостаток опыта и быстро закрывать пробелы в знаниях. 💬 Зарегистрируйтесь и получите урок по основам Excel бесплатно! 😶Зарегистрироваться на бесплатный вебинар

Создатель Linux ➡️ обычный стол, минимум техники, ничего лишнего. Обычный «тех-бро» ➡️ три монитора, RGB, мощный ПК, студийный свет, полный сетап. Иногда разница между «легендой» и «тех-инфлюенсером» - не в железе, а в том, что у тебя в голове. 🫡 Всё про Data Science 🇷🇺 Читайте нас в MAX

➡️ EXISTS РАБОТАЕТ БЫСТРЕЕ COUNT SQL-совет: перестаньте считать всё через COUNT(*) Многие пишут так: SELECT COUNT(*) FROM orders WHERE user_id = 123; Чтобы проверить — есть ли записи. Проблема: COUNT(*) считает все строки, даже если нужна просто проверка существования. На больших таблицах это лишняя нагрузка и медленный запрос. Правильнее использовать EXISTS. Почему это лучше: - База останавливается на первой найденной строке - Меньше чтения данных - Быстрее на больших таблицах - Использует индексы эффективнее Пример:

-- Плохо
SELECT COUNT(*)
FROM orders
WHERE user_id = 123;

-- Хорошо
SELECT EXISTS (
    SELECT 1
    FROM orders
    WHERE user_id = 123
);

-- Или в условии
SELECT *
FROM users u
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.user_id = u.id
);

🫡 Всё про Data Science 🇷🇺 Читайте нас в MAX

⚡️Чем занимается аналитик и как получить оффер в 2026 году? Переживаете, что рынок труда нестабилен? Хотите ворваться в аналитику, но не знаете как гарантировать себе трудоустройство? Все эти переживания уходят, если вы уверены в правильности своих действий, уверены в своих компетенциях, резюме и портфолио.  Приглашаем на бесплатный вебинар, где Андрон Алексанян - эксперт в области аналитики и CEO школы аналитики Simulative — в прямом эфире разберет все важные аспекты в работе аналитика, а также расскажет как получить оффер быстрее других. Кстати на вебинаре разберут и то как стать аналитиком в 30/40/50 и более лет. На вебинаре будет: 🟠Разберем полный роадмап: что учить, в каком порядке, до какого уровня; 🟠Структура хорошего портфолио с примерами; 🟠Что говорят реальные наниматели - какие у них сейчас требования:

— Покажем реальные примеры, как оформить резюме и портфолио, чтобы привлекать внимание; — Обсудим какие отклики работают, а какие сразу отправляют в корзину; — Изнанка найма: инсайдерский взгляд на процессы отбора

🟠 Практические техники для новичков: разберём, как компенсировать недостаток опыта и быстро закрывать пробелы в знаниях. 💬 Зарегистрируйтесь и получите урок по основам Excel бесплатно! 😶Зарегистрироваться на бесплатный вебинар

Claude можно превратить из «чат-бота» в полноценного агента, если правильно организовать проект. Вся магия - в структуре папки: your-project/ ├── CLAUDE.md → инструкции для команды (сохраняется в репозитории) ├── CLAUDE.local.md → личные настройки (игнорируется git) ├── .claude/ → центр управления │ ├── settings.json → права доступа и конфигурация (в репозитории) │ ├── settings.local.json → локальные настройки │ ├── commands/ → кастомные slash-команды │ │ ├── review.md → /project:review │ │ ├── fix-issue.md → /project:fix-issue │ │ └── deploy.md → /project:deploy │ ├── rules/ → модульные инструкции │ │ ├── code-style.md │ │ ├── testing.md │ │ └── api-conventions.md │ ├── skills/ → авто-запускаемые workflow │ │ ├── security-review/ │ │ │ └── SKILL.md │ │ └── deploy/ │ │ └── SKILL.md │ └── agents/ → субагенты (роли) │ ├── code-reviewer.md │ └── security-auditor.md Фактически ты собираешь мини-систему из агентов внутри репозитория. https://www.youtube.com/shorts/ej5qiDJ0Ibo

🎉 Розыгрыш завершен! Победители: 1. Маленький сварщик🐈‍⬛ (6185340988) 2. Ar$ (6253280699) 3. xWoody WOODPECKERx (8420586007)

➡️ Microsoft Critique: deep research на стероидах, где одна модель генерирует, а вторая её критикует Microsoft выкатили Critique. Это инструмент для deep research, который одновременно запускает несколько моделей на один запрос. Работает так: первая модель берёт на себя генерацию, вторая выступает рецензентом и вычищает ошибки и неточности до того, как вы увидите финальный ответ. Какие именно модели работали над ответом, видно в шапке. По бенчмарку DRACO показывают SOTA, других замеров пока нет. Так что насколько это реально лучше обычного deep research, вопрос открытый. Отдельно интересен режим Council для обычных запросов. Ваш промпт прогоняется через несколько моделей параллельно, и вы видите все варианты сразу. Плюс краткая выжимка: где модели согласны, а где разошлись во мнениях. На широкую аудиторию пока не раскатили, можно подать заявку на ранний доступ. Будет ли это в обычной подписке за $20, неизвестно. Хотя, если честно, мультимодельный пайплайн с критиком можно собрать самому за вечер через API. И точно выйдет дешевле. techcommunity.microsoft.com/blog/microsoft365copilotblog/introducing-multi-model-intelligence-in-researcher/4506011 🫡 Всё про Data Science 🇷🇺 Читайте нас в MAX

➡️ Хорошая это новость или грустная, судите сами: ARC Invest посчитали, что к концу 2020-х суммарный объем текста, сгенерированного ИИ, превзойдет объем текста, который человечество накопило за последние 500 лет Другими словами, ИИ понадобиться всего 5-10 лет, чтобы нагнать и перегнать человечество в плане количества написанного текста. Оказалось, кстати, что 2025 стал первым годом, когда ИИ сгенерировал больше текста, чем люди. Подсчеты, конечно, очень приблизительные, – но все же. 🫡 Всё про Data Science 🇷🇺 Читайте нас в MAX