🖥 Cовет по SQL-тестам: тестируйте не только результат запроса, а его инварианты.

Обычно SQL проверяют так:

SELECT * FROM orders WHERE status = 'paid';

И потом сравнивают: «вернулись нужные строки или нет».

Но в реальных системах чаще ломается не сам happy path, а скрытые свойства данных.

Например, для отчёта по заказам тест должен проверять не только конкретные строки, а правила:

-- сумма по пользователям должна совпадать с общей суммой
WITH by_user AS (
    SELECT user_id, SUM(amount) AS total
    FROM orders
    WHERE status = 'paid'
    GROUP BY user_id
),
overall AS (
    SELECT SUM(amount) AS total
    FROM orders
    WHERE status = 'paid'
)
SELECT
    (SELECT SUM(total) FROM by_user) = (SELECT total FROM overall) AS is_valid;

То есть вы тестируете не «мне вернулось 10 строк», а:

агрегаты не теряют деньги
join не размножает строки
фильтр не выкидывает валидные данные
NULL не ломает расчёты
сумма после группировки совпадает с суммой до группировки
каждый order попадает ровно в одну категорию
дедупликация не удаляет нужные записи

Особенно полезный приём - тест на размножение строк после JOIN:

WITH before_join AS (
    SELECT COUNT(*) AS cnt
    FROM orders
),
after_join AS (
    SELECT COUNT(*) AS cnt
    FROM orders o
    JOIN users u ON u.id = o.user_id
)
SELECT
    after_join.cnt <= before_join.cnt AS no_unexpected_multiplication
FROM before_join, after_join;

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

Хороший SQL-тест проверяет не только ответ, а свойства запроса, которые должны оставаться истинными при любых данных. Именно так ловятся баги, которые не видно на маленьком тестовом датасете.

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

Обычный поиск работает так: есть вопрос - база находит 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

🖥 ИИ Агент за 9 секунд снёс продакшн-базу компании и стёр бэкапы.

Cursor на Claude Opus 4.6 нашёл API-токен в постороннем файле, воспользовался им и всё удалил.

Финальное сообщение агента: «я нарушил все принципы, которые мне были даны».

https://www.reddit.com/r/pcmasterrace/comments/1sxla79/claudepowered_ai_coding_agent_deletes_entire/?rdt=48142

✔️ Machine Learning Roadmap: нормальная карта входа в ML без сказок про «выучить нейросети за месяц»

Большой русскоязычный roadmap по машинному обучению: от первого import numpy до LLM, RAG, fine-tuning, AI-агентов и MLOps.

И это не просто очередной список ссылок в стиле «посмотри 40 курсов и станешь ML engineer». Внутри нормальная структура: что учить, в каком порядке, зачем это нужно и какой практический артефакт должен появиться после каждого этапа.

Roadmap разбит на 7 треков:

- фундамент: Python, математика, статистика, инструменты
- классический ML: scikit-learn, табличные данные, метрики, валидация
- Deep Learning: PyTorch, CNN, RNN, training loop
- LLM и трансформеры: attention, KV-cache, RAG, LoRA, агенты
- Generative AI: изображения, видео, аудио, мультимодальность
- MLOps и прод: Docker, Kubernetes, CI/CD, мониторинг, serving
- специализация: CV, NLP, RecSys, RL, Safety

Самое полезное - там честно написано, что ML это не только «обучить модель». В реальности большая часть работы живёт вокруг данных, метрик, деплоя, мониторинга, воспроизводимости и понимания, почему модель вообще ошибается.

Хорошая мысль из roadmap: LLM не делает джуна сениором. Она ускоряет того, кто понимает базу. Без базы человек просто превращается в оператора Copilot, который не может объяснить, почему модель сломалась.

По времени тоже без инфоцыганства:

- 0-3 месяца: Python, математика, классический ML
- 3-6 месяцев: Deep Learning и PyTorch
- 6-12 месяцев: LLM, RAG, fine-tuning, AI-агенты
- 12+ месяцев: MLOps, прод, масштабирование, специализация

Короче, если давно хотели системно зайти в ML, а не прыгать между роликами про ChatGPT, Stable Diffusion и «топ-10 библиотек», это хороший ориентир.

https://github.com/justxor/MachineLearningRoadmap/tree/main

⚡️ Когда аналитика разнесена по отдельным системам, бизнес долго ждет данные и платит за лишние кластеры, ETL и серверы.

🐘 Postgres Pro AXE — аналитическая СУБД от Postgres Professional на знакомом PostgreSQL. Ускоряет доставку аналитики и снижает TCO на хранение и обработку данных.

✅ До 20 раз быстрее Greenplum
На сложных запросах в тестах ClickBench, TPC-H и TPC-DS.

✅ До 10 раз меньше ресурсов
При сопоставимой нагрузке с MPP-аналогами.

✅ Аналитика ближе к рабочим данным
Postgres Pro AXE работает как отдельная аналитическая СУБД или расширяет Postgres Pro Enterprise аналитическими возможностями на существующих узлах.

✅ Быстрый старт для команды
Знакомый диалект PostgreSQL снижает порог входа для администраторов и разработчиков.

✅ Свобода хранения и BI
Локальный сервер, сетевая шара или S3. Данные — в формате Parquet.

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

Реклама ООО «ППГ» Инн: 7707083893 Erid: 2VtzqwzwH4t