➡️ SQL задачка на внимательность (и одна классическая ловушка)

У тебя есть таблица логов. Нужно найти пользователей, которые заходили 3 дня подряд.

Таблица:

⏺️ user_id
⏺️ event_date (DATE)

Задача:

Верни user_id и дату третьего дня серии (то есть конец 3-дневной цепочки).

Ловушка:

1️⃣ В один день может быть несколько событий - их нельзя считать как разные дни
2️⃣ Дни должны идти подряд по календарю (не “3 записи подряд”)

-- PostgreSQL / MySQL 8+ (через window functions)
WITH uniq_days AS (
  SELECT DISTINCT user_id, event_date
  FROM user_events
),
grp AS (
  SELECT
    user_id,
    event_date,
    event_date
      - INTERVAL '1 day' * (ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_date))
      AS anchor
  FROM uniq_days
),
runs AS (
  SELECT
    user_id,
    MIN(event_date) AS start_day,
    MAX(event_date) AS end_day,
    COUNT(*) AS days_cnt
  FROM grp
  GROUP BY user_id, anchor
)
SELECT user_id, end_day AS third_day
FROM runs
WHERE days_cnt >= 3
ORDER BY user_id, third_day;

Почему это работает:

⏺️ DISTINCT убирает повторы в один день
⏺️ “anchor” превращает подряд идущие даты в одну группу
⏺️ дальше считаем длину серии и берём конец

🫡 Всё про Data Science

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

🔥 Vector search: Кидать историю чата в векторную БД - это не «память».

Это просто поиск по смыслу. RAG хорошо достаёт документы,
но не держит состояние пользователя.

Здесь может помочь Mem0 - open-source слой памяти между человеком и LLM.

Он учится на диалогах и сохраняет то, что важно.

Что даёт:

⏺️🧠 помнит предпочтения (не только факты)
⏺️✂️ сжимает историю — меньше токенов и быстрее ответы
⏺️🤝 делится знаниями между несколькими агентами


Если система не помнит опыт - это не агент, а поисковик.
Mem0 делает память - живой и адаптивной.

➡️ Подробнее: github.com/mem0ai/mem0

🫡 Всё про Data Science

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

➡️ Математический предел креативности нейросетей

Математика не шутит, особенно когда дело касается творчества ИИ. Недавняя работа австралийского исследователя Дэвида Кропли из Университета Южной Австралии утверждает, что у генеративных ИИ-систем вроде ChatGPT есть жесткий математический потолок креативности. Речь о том, что даже самые «креативные» ИИ-системы, по мнению Кропли, могут быть креативными только до определенного предела. Давайте разбираться, в чем же тут подвох?

Дэвид Кропли использует классическое определение творчества из психологии, где продукт признается креативным только тогда, когда он одновременно новый и уместный. Он формулирует это так: C = N × E
где C — это креативность, N — новизна, а E — эффективность.

А как это соотносится с языковыми моделями вроде ChatGPT? Кропли вводит понятие вероятности того, какое слово модель выберет на данном шаге. И оказывается, что креативность на одном шаге можно описать как: C = p × (1 − p) = p − p²
где p — это вероятность выбранного слова. Математика подсказывает, что максимальная креативность может быть достигнута, когда вероятность равна 0.5 (средний выбор). Когда слово слишком вероятно, оно становится банальным, а когда слишком редким — уместность теряется.

Пример с котом 😺

Чтобы понять, как это работает, Кропли приводит пример: «The cat sat on the ...». Для ИИ слово mat будет очень вероятным, но оно настолько банально, что новизны почти не добавляет. Более редкие варианты, вроде moon или chair, с одной стороны, новее, но рискуют быть неуместными.

Так вот, каждый шаг в процессе генерации у ИИ балансирует между «банально, но правильно» и «оригинально, но рискованно». И как бы ни старались модели, они не могут быть одновременно очень новыми и очень уместными. То есть, как бы ни учились на данных, ИИ всё равно окажется где-то в середине, между слишком банальным и слишком странным.

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

Однако Кропли не говорит, что ИИ всегда будет таким. Он утверждает, что для достижения «экспертного» уровня потребуется новая архитектура, которая будет генерировать идеи, не привязанные к уже существующим данным. То есть, новые технологии, которые смогут выходить за рамки привычных статистических паттернов. Фуух, будущее есть!

🫡 Всё про Data Science

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

🔥 Легкий TUI для работы с SQL базами данных

sqlit - это удобный инструмент для быстрого выполнения запросов к различным SQL базам данных, включая PostgreSQL, MySQL, SQLite и другие. Он предлагает интуитивно понятный интерфейс, позволяя легко управлять соединениями и историей запросов без необходимости в сложных настройках.

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

⏺️ Поддержка множества баз данных без дополнительных адаптеров
⏺️ Удобный интерфейс для управления соединениями
⏺️ Встроенная история запросов с возможностью поиска
⏺️ Поддержка SSH туннелей для безопасного подключения
⏺️ Редактирование в стиле Vim для терминальных пользователей

➡️ Подробнее: https://github.com/Maxteabag/sqlit

🫡 Всё про Data Science

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

🔥 Все крупные игроки борются за решение одной проблемы

Если вы интересуетесь развитием ИИ-агентов, то наверняка заметили, как все ведущие технологические компании стремятся решить одну и ту же задачу: как эффективно работать с графами знаний в реальном времени для больших языковых моделей? Microsoft, Google, AWS — все ищут решения, но FalkorDB предлагает интересный подход. Давайте разберемся, в чем его уникальность.

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

А что если представить граф как математическую структуру?

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

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

Почему не использовать просто векторный поиск 😂

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

Что предлагает FalkorDB?

• Ультра-быстрая многозадачная графовая база данных.
• Эффективное хранение с использованием разреженных матриц.
• Совместимость с OpenCypher — тем же языком запросов, что и в Neo4j.
• Оптимизирована для приложений на базе LLM и памяти агентов.
• Работает поверх Redis для простоты развертывания.

Если вы строите ИИ-агентов, которым нужно работать с подключенными данными в реальном времени, FalkorDB — это инструмент, который стоит попробовать.

🫡 Всё про Data Science

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

🔥Впечатляющая и залипательная инфографика, показывающая, когда в Токио уходит последний поезд с разных веток.

Хотя в практическом смысле и бесполезная

➡️ Подробнее: tokyo-last-train-map.pages.dev

🫡 Всё про Data Science

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

👀 LuxTTS - очень быстрый и компактный TTS с клонированием голоса

Модель со ставкой на скорость + реализм, при этом она остается лёгкой и доступной по ресурсам.

Главные фишки:

⏺️ ⚡️ До 150× realtime при генерации речи
⏺️ 🎙 Хорошая передача эмоций и естественности
⏺️ 🧬 Качественное voice cloning
⏺️ 💾 Влезает примерно в 1 ГБ VRAM
⏺️ 🖥 Работает и на CPU - 2–6× realtime

Подходит для:

⏺️ голосовых ассистентов
⏺️ озвучки приложений
⏺️ быстрых прототипов без тяжёлой инфраструктуры

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

➡️ Repo: https://github.com/ysharma3501/LuxTTS
➡️ Модель: https://huggingface.co/YatharthS/LuxTTS

🫡 Всё про Data Science

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

🔥Полтора миллиарда Трамповских денег

New York Times в своём интерактивном лендинге обвинили Трампа в коррупции — заявив, что благодаря использованию своего президентского статуса он и его семья заработали как минимум 1,4 млрд долларов.

Семья Трампа получает выплаты от иностранных правительств и американских компаний — формально за обычный бизнес — например, строительство или аренду прав для съёмок фильма — однако во многих из сделок прослеживается коррупционная составляющая

Один из примеров: администрация согласилась снизить угрожавшие Вьетнаму пошлины примерно через месяц после того, как компания Trump Organization заложила фундамент гольф-комплекса стоимостью 1,5 миллиарда долларов недалеко от Ханоя. Вьетнамские чиновники пренебрегли собственными законами, чтобы ускорить реализацию проекта.

В центре проекта — анимированная визуализация из падающих купюр, каждая из которых показывает средний доход одного домохозяйства в США.

🫡 Всё про Data Science

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

🔥 gh-ost - инструмент для миграций схемы MySQL без даунтайма.

Если тебе надо сделать ALTER TABLE на большой продовой таблице и не положить сервис - gh-ost это прям must-have.

Большинство online-schema-change тулов используют триггеры и создают лишнюю нагрузку.
А gh-ost идёт по другому пути:

⏺️ Triggerless - вообще без триггеров
⏺️ Читает изменения через binlog stream и асинхронно применяет их к “ghost table”
⏺️ Даёт полный контроль над процессом миграции:

- пауза/резюм
- throttle (снижение нагрузки)
- аудит и статус
- безопасный cut-over

Как это работает (по-простому):

1) создаётся “ghost table” с новой схемой
2) данные копируются постепенно
3) параллельно изменения ловятся из binlog
4) в конце таблицы меняются местами почти мгновенно

Идеально для:

⏺️ таблиц на десятки миллионов строк
⏺️ production-систем
⏺️ миграций без блокировок

🫡 Всё про Data Science

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

➡️ Миграции без боли: как обновлять БД безопасно и без простоя

Сохраняй себе: в реальных проектах миграции - это не “ALTER TABLE и поехали”, а зона риска.

Один неверный шаг = даунтайм, блокировки и откат вручную.

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

Рабочая стратегия (2 шага)

1️⃣ Сначала добавляй новое, не ломая старое

⏺️ добавляй новые колонки/таблицы
⏺️ не удаляй и не переименовывай сразу
⏺️ не делай NOT NULL без дефолта

2️⃣ Потом переключай код

⏺️ сначала раскатываешь схему
⏺️ потом деплоишь код, который пишет/читает новое
⏺️ и только после этого убираешь старое

Это называется “expand → migrate → contract” и это стандарт продакшн-миграций.

Фишки, которые спасают на проде

⏺️ всегда делай миграцию идемпотентной (IF EXISTS / IF NOT EXISTS)
⏺️ не держи транзакцию долго
⏺️ избегай тяжёлых ALTER на больших таблицах
⏺️ проверяй количество строк, прежде чем апдейтить
⏺️ делай бэкап/дамп перед большим изменением

-- safe-migration.sql

-- 1) EXPAND: добавляем новое, не ломая старое
ALTER TABLE users
ADD COLUMN IF NOT EXISTS email_verified BOOLEAN DEFAULT FALSE;

CREATE INDEX IF NOT EXISTS idx_users_email
ON users(email);

-- 2) MIGRATE: переносим данные маленькими шагами (пример)
-- (в реальности делается батчами на больших таблицах)
UPDATE users
SET email_verified = TRUE
WHERE email IS NOT NULL AND email <> '';

-- 3) CONTRACT: удаляем старое только после деплоя кода
-- (делать отдельной миграцией!)
-- ALTER TABLE users DROP COLUMN old_email_flag;

🫡 Всё про Data Science

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

🔥 ИИ для SQL: пусть он объяснит «почему запрос тормозит»

Профессиональный лайфхак:

не проси ИИ «оптимизировать запрос» вслепую.
Вместо этого — давай ему EXPLAIN / EXPLAIN ANALYZE и структуру таблиц.

ИИ отлично умеет:

⏺️ разбирать план выполнения
⏺️ находить узкие места (Seq Scan, лишние JOIN, сортировки)
⏺️ предлагать индексы и переписывание запроса по факту, а не наугад

Алгоритм простой:

1️⃣ запускаешь EXPLAIN ANALYZE
2️⃣ прикладываешь схему таблиц
3️⃣ спрашиваешь: *где bottleneck и что бы ты поменял?*

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

пример «правильного» запроса к ИИ с реальными данными

-- запрос
SELECT *
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.created_at > NOW() - INTERVAL '30 days'
AND c.country = 'US'
ORDER BY o.created_at DESC
LIMIT 100;

-- план выполнения
EXPLAIN ANALYZE
SELECT ...
-- (сюда вставь полный план: Seq Scan / Index Scan / сортировки и т.п.)

-- схема таблиц (важно!)
\d orders
\d customers

-- вопрос ИИ:
"Разбери план выполнения. 
Где узкие места? 
Нужны ли индексы и какие именно? 
Можно ли переписать запрос быстрее, не меняя логику?"

🫡 Всё про Data Science

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