➡️ Timescale выпустил pg-aiguide: практический гайд по ИИ в PostgreSQL

Timescale опубликовал открытый репозиторий pg-aiguide - это собрание лучших практик, примеров и шаблонов по работе с ИИ поверх PostgreSQL (в том числе TimescaleDB).

Что внутри:

⏺️ примеры интеграции LLM и AI-функций с БД
⏺️ готовые SQL-рецепты и расширения
⏺️ семантический поиск и анализ данных
⏺️ шаблоны, которые можно сразу использовать в проде

Это не теория, а набор готовых подходов для реальных проектов.

➡️ https://github.com/timescale/pg-aiguide

🫡 Всё про Data Science

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

➡️ Локальная панель для Cloudflare Workers

Localflare — это инструмент для разработки, который упрощает взаимодействие с вашими ресурсами Cloudflare, такими как D1 базы данных, KV пространства и R2 бакеты. Он предлагает интуитивно понятный интерфейс для визуализации и управления данными в процессе разработки.

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

⏺️ Полнофункциональный SQL-редактор для D1 баз данных
⏺️ Удобный браузер для работы с KV парами
⏺️ Менеджер файлов для R2 бакетов
⏺️Инспектор очередей для тестирования сообщений
⏺️ Работает с любыми фреймворками без настройки

➡️ GitHub: https://github.com/rohanprasadofficial/localflare

🫡 Всё про Data Science

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

➡️ ШПАРГАЛКА: Как правильно поднимать БД перед проектом

Главная ошибка новичков - “у всех база разная”.
В итоге миграции ломаются, схема плывёт, на CI одно, у тебя другое, в проде третье.

Правильный старт всегда одинаковый:

⏺️ Поднимай БД через Docker - чтобы у всей команды окружение было идентичным
⏺️ Все параметры (пароль, порт, имя БД) храни в .env
⏺️ Схему меняй ТОЛЬКО через миграции (Flyway/Liquibase/EF/Alembic)
⏺️ Добавь healthcheck - сервис не должен стартовать раньше БД
⏺️ Сделай команды backup/restore - пригодится в любой момент

Так ты гарантируешь:

⏺️ у всех одна и та же база
⏺️ быстрый старт проекта за 3 минуты
⏺️ деплой без сюрпризов

1) Создай .env
cat > .env << 'EOF'
POSTGRES_DB=app
POSTGRES_USER=app
POSTGRES_PASSWORD=app123
POSTGRES_PORT=5432
EOF

2) docker-compose.yml для Postgres + healthcheck
cat > docker-compose.yml << 'EOF'
services:
  postgres:
    image: postgres:16
    container_name: app-postgres
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    ports:
      - "${POSTGRES_PORT}:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      timeout: 3s
      retries: 20

volumes:
  pgdata:
EOF

3) Запуск
docker compose up -d

4) Проверка
docker compose ps

5) Backup
docker exec -t app-postgres pg_dump -U app app > backup.sql

6) Restore
cat backup.sql | docker exec -i app-postgres psql -U app -d app

🫡 Всё про Data Science

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

➡️ Как не убить базу большими таблицами в SQL - фильтруй и агрегируй как можно раньше

Главная ошибка при работе с большими таблицами - делать SELECT * и потом надеяться, что "оно как-нибудь".

На больших объёмах это превращается в долгие запросы, высокую нагрузку и таймауты.

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

Практическое правило: если запрос возвращает миллионы строк - ты почти наверняка решаешь задачу неправильно. В 90% случаев тебе нужна витрина: GROUP BY, window-функции, или отдельная агрегированная таблица. А чтобы база не страдала, добавляй индексы под фильтры и под JOIN-ключи, и проверяй план выполнения через EXPLAIN.

 ПЛОХО: тащим весь объём и только потом думаем
SELECT *
FROM events
WHERE created_at >= NOW() - INTERVAL '90 days';

-- ХОРОШО: сразу сужаем, берем нужные колонки, считаем агрегаты
SELECT
  user_id,
  COUNT(*) AS events_7d,
  MAX(created_at) AS last_event_at
FROM events
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY user_id;

-- Индекс под фильтр по времени + join по user_id (частый паттерн)
CREATE INDEX IF NOT EXISTS idx_events_created_user
ON events (created_at, user_id);

-- Проверяй план, чтобы не было Seq Scan на миллионах строк
EXPLAIN (ANALYZE, BUFFERS)
SELECT user_id, COUNT(*)
FROM events
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY user_id;

🫡 Всё про Data Science

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

Материалы для подготовки к собеседованиям

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

🔴10 ключевых лайфхаков по резюме
🔴Нужны ли сопроводительные и что там писать
🔴Как отвечать на вопрос «Расскажите о себе»
🔴Как рассказывать о своем факапе?
🔴13 шаблонных отказов рекрутеров - что они означают.
🔥 Разборы резюме для разработчиков c нанимающим СТО

ну и то, что нам особенно интересно - про офферы и ЗП
🔴45 офферов по разным ИТ ролям: от аналитика до тим тим лида за 850к
🔴Какой тим лид получил 1,2 млн
🔴Оффер на Product lead в Яндекс
🔴Оффер на Руководителя проектов на 540к
🔴Оффер на функционального архитектора 1С на 460к
🔴Пошаговый план как выйти в найме на 1 млн руб

Сохраняйте, читайте, подписывайтесь

🔥 Теперь можно ничем не беспокоиться

🫡 Всё про Data Science

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

➡️ ML-модель пересобирает логику ранжирования маршрутов

В Яндекс Картах изменился принцип выбора маршрута, который показывается первым. Раньше это по дефолту был самый быстрый. Теперь порядок определяет ML-модель, которая учитывает не только время в пути, но и множество других факторов: количество поворотов, сложность маневров, историю сходов на участке, предсказуемость движения и другие поведенческие сигналы.

Второе важное изменение — переход от задачи ранжирования к задаче выбора (Softmax + one-hot таргет). Модель больше не отвечает на вопрос «какой маршрут лучше в рейтинге?» — она учится угадывать единственный вариант, по которому пользователь действительно поедет. Фактически навигация сместилась от абстрактной оптимизации ETA к предсказанию реального выбора водителя — как если бы система пыталась угадать, какой маршрут человек сам бы выбрал, взглянув на карту. Почему выбрали в итоге не классический для такой задачи YetiRank — в разборе команды на Хабре.

🫡 Всё про Data Science

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

🔥Появился сервис для прожарки вашего стартапа — ShipOrDie

Механика простая — вставляешь ссылку (или описываешь идею) и отдаёшь на растерзание боту и другим участникам. Сервис не щадя проходится по тексту и смыслам, находит размытые формулировки и перегретые обещания.

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

🫡 Всё про Data Science

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

🔥 Что внутри ИИ-стартапа?

А внутри у него Claude или ChatGPT в 70% случаев.

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

Довольно часто в описаниях этих ИИ-продуктов можно встретить что-то про «файн-тюнинг», «проприетарные LLM» и другие интересные термины. Они как бы намекают, что компания предлагает какие-то свои собственные технологии или хотя бы доступ к улучшенным, дообученным и докрученным моделям.

➡️ Мини-исследование на выборке из 200 стартапов показало, что подавляющее большинство с этим не заморачиваются.

Автор, разработчик ПО и создатель ИИ-систем, на протяжении 3 недель изучал активность 200 ИИ-стартапов. Он промониторил трафик, разобрал и проанализировал из JavaScrist бандлы, а потом сравнил свои выводы с тем, как они сами описывают свой продукт.

73% в своих обещаниях потребителям наврали. Их уникальные ИИ-тулы оказались:
⏺️OpenAI API с парочкой промптов (ну хоть их сами написали). У одной из таких компаний автор нашел промпт: «Ты эксперт в (название компании). Всегда отвечай в профессиональной манере. Никогда не упоминай свою связь OpenAI и что ты языковая модель».
⏺️OpenAI API с RAG-архитектурой — векторной БД, обычно Pinecone и Weaviate. Уже лучше, хотя ничего уникального и авторского тут нет.
⏺️OpenAI API, Claude с библиотекой промптов или модель с HugginFace с LoRA.

Он также привел несколько советов, как отличить честный стартап от тех, кто продает доступ к OpenAI или Claude по оверпрайсу:
⏺️Проверить трафик их ИИ-продукта на запросы к api.openai.com, api.anthropic.com или api.cohere.ai.
⏺️Засечь скорость ответа. Если он приходит через 200–350 мс, то отвечает, скорее всего GPT-4.
⏺️Поискать в бандлах JavaScript openai, anthropic, sk-proj-, claude и cohere.
⏺️Внимательно почитать, как разработчики рекламируют свой продукт. Если вы видите много громких слов без деталей и конкретики, это повод напрячься.

Использование готовых моделей — это не всегда красный флаг. Некоторые компании честно признаются, чей ИИ под капотом их продукта. И обычно они продают не сам ИИ, а оптимизацию работы с ним: удобный интерфейс, управление несколькими моделями сразу, грамотно выстроенную RAG-архитектуру. Это все не плохо — плохо врать и называть это «продвинутой проприетарной ИИ-инфраструктурой».

🫡 Всё про Data Science

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

SQL Чек-лист: защита базы данных от взлома

Закрой базу от интернета - БД не должна слушать 0.0.0.0 без нужды. Открывай доступ только из подсети приложения (VPC, private network).

Используй принцип наименьших прав - отдельный пользователь на каждое приложение, только нужные SELECT/INSERT/UPDATE, без SUPER/OWNER.

Пароли и секреты - длинные, уникальные, храни в Secret Manager/.env вне репозитория, регулярно ротируй.

Шифрование - включи TLS для соединений, шифруй бэкапы и диски (at-rest).

Обновления - патчи БД и ОС ставь регулярно, отключай лишние расширения и фичи.

Защита от SQL-инъекций - только параметризованные запросы, никакой конкатенации строк в SQL.

Логи и аудит - включи логирование входов, ошибок, подозрительных запросов, алерты на “подбор паролей”.

Бэкапы + проверка восстановления - делай бэкапы и обязательно тестируй restore, иначе это не бэкап.

Ограничь опасные команды - запрети DROP/ALTER в проде для app-юзеров, разнеси миграции и рантайм доступ.

Rate limiting и защита периметра - firewall/SG, fail2ban/pgbouncer limits, VPN/bastion для админки.

Postgres hardening (quick example)

ufw allow from 10.0.0.0/8 to any port 5432
psql -c "CREATE ROLE app LOGIN PASSWORD 'STRONG';"
psql -c "REVOKE ALL ON DATABASE prod FROM PUBLIC;"
psql -c "GRANT CONNECT ON DATABASE prod TO app;"
psql -c "ALTER SYSTEM SET ssl=on;"
psql -c "ALTER SYSTEM SET log_connections=on;"
psql -c "ALTER SYSTEM SET password_encryption='scram-sha-256';"
systemctl reload postgresql

🫡 Всё про Data Science

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

Освоить анализ данных в онлайн-формате

Центр непрерывного образования ФКН НИУ ВШЭ запускает онлайн-программу профессиональной переподготовки «Практический анализ данных». Вас ждет всестороннее обучение и практика с использованием Python, SQL и других инструментов для работы с данными, а также изучение основ статистики и машинного обучения.

В процессе обучения вы:

1️⃣освоите работу с ключевыми библиотеками Python для анализа данных и автоматизации рутинных задач;
2️⃣изучите принципы работы с базами данных, научитесь фильтровать и сортировать данные, использовать агрегирующие функции, а также работать с датами и строками;
3️⃣пройдете основы статистики для анализа данных и освоите методы проведения A/B-тестов для проверки гипотез и принятия обоснованных бизнес-решений;
4️⃣познакомитесь с основами машинного обучения и научитесь применять алгоритмы для прогнозирования и классификации данных.
5️⃣научитесь строить дашборды и визуализировать данные в BI-системах;
6️⃣поймете, как анализировать поведение пользователей и выстраивать метрики для оценки успешности продукта;
7️⃣приобретете знания о хранилищах данных и научитесь работать с большими массивами информации.

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


📁Дата старта: 17 марта, обучение онлайн-формата.

Подробнее о программе 📍

Реклама. НИУ "ВШЭ". ИНН 7714030726. erid:2SDnjdUKKso

Встречаем GPT‑5.4

Модель вышла в версиях Thinking и Pro. Метрики подросли на кодинге (немного), на математике (прилично) и на computer use. Последним хвастаются особенно.

Кроме того, модель стала эффективнее: использует меньше токенов при рассуждении и отвечает быстрее. Но есть нюанс: теперь она стоит немножко дороже.

Что еще интересного:

– Модель теперь можно остановить посередине ответа и добавить дополнительные инструкции.

– Контекст теперь до 1 миллиона токенов (наконец-то!)

– В Codex появился /fast мод, который ускорит генерацию в 1.5x (это та же модель и тот же уровень рассуждений, просто быстрее). Правда, в таком режиме каждый токен будет учитываться в лимитах за два.

https://openai.com/index/introducing-gpt-5-4/

🫡 Всё про Data Science

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

🔵 Занимаешься IT и ищешь свежие идеи? На этом канале собраны инсайды СЕО 1win о развитии iGaming-бизнеса.

Узнай, как управлять крупной компанией в высококонкурентной нише, используя новые технологии и тренды.

Подписывайся на Owner 1win и будь в теме!

🔥 Sql тренажеры для практики

⏺️sql-academy.org
⏺️sql-ex.ru
⏺️schoolsw3.com
⏺️SQL Fiddle
⏺️sqltest.online
⏺️Oracle LiveSQL
⏺️stratascratch.com
⏺️stepik.org (Интерактивный тренажер SQL)
⏺️sql-practice.com
⏺️pgexercises.com
⏺️HackerRank
⏺️sqlzoo.net

🫡 Всё про Data Science

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

🔥 Какие работы на самом деле отнял ИИ?

Новое исследование эту картину дополняет.

В выборку попали 180 млн вакансий из разных сфер с 2023 по 2025 годы. Автор изучил, как изменилось общее число вакансий (упало на 8%, между прочим), а затем посмотрел на динамику по отдельным должностям и индустриям.

⏺️Очевидно, что лучше всего дела у ML-инженеров — у них число открытых вакансий c 2024 по 2025 выросло на 39%.
⏺️Хуже всего дела у дизайнеров, копирайтеров и фотографов — число вакансий для них упало на 27-32%. Но только для специалистов, а для креативных директоров и продюсеров предложений так же много, как раньше.
⏺️Это общая тенденция — падает спрос на рядовых сотрудников и руководителей среднего звена, а у больших начальников все стабильно.
⏺️Без серьезных изменений обходятся сфера продаж, разработка, техподдержка и аналитика. Последнее особенно радует.
⏺️В маркетинге стали активнее набирать людей, специализирующихся на работе с инфлюэнсерами. Автор предполагает, что это из-за того, что в эпоху ИИ-слопа уровень доверия к контенту в интернете падает. Компании фокусируются на продвижении через реальных людей, которым их подписчики еще более-менее верят.
⏺️Если выйти за пределы привычных ИТ и маркетинга, то просматривается тренд в медицине — стало на 20% меньше вакансий для Medical Scribes. Это такой ассистент, который отвечает за заполнение документов во время приема, чтобы доктор не отвлекался от пациента на бумажки.

А как у вас — замечали какие-то изменения, вызванные распространением ИИ, в вашей сфере? 👀

🫡 Всё про Data Science

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

➡️ Гендерный разрыв в IT никуда не делся

Исследование Selecty и hh․ru показало: >200 тыс. рублей в месяц получают 51,5% мужчин и только 34,8% женщин. В тестировании этот порог пробивают 60% парней и 45% девушек, а в бэкенде высокие доходы лишь у 26,5% разработчиц.

Почему так? Мужчины чаще забирают руководящие посты и сеньорские грейды.

🫡 Всё про Data Science

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

🔥 Маленькая модель - большие возможности.

Вышла Nanbeige4.1-3B - модель всего на 3B параметров, которая в ряде задач обходит модели в 10 раз больше.

Что внутри:

- Контекст до 256K токенов
- Встроенные агентные возможности Deep Search
- Обучение коду в два этапа:
- сначала правильность
- затем эффективность
- На ключевых бенчмарках обгоняет Qwen3-32B
- Можно запускать локально без мощных серверов
- Сильно ниже стоимость инференса
- Быстрая работа на edge и локальных машинах
- Подходит для локальных AI-агентов и автоматизации

Дешёвый Локальный AI.

➡️ Модель: https://modelscope.cn/models/nanbeige/Nanbeige4.1-3B

🫡 Всё про Data Science

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

🔥 Google протестировали LLM на реальных научных вопросах по сверхпроводимости.

Исследователи собрали 67 сложных вопросов, которые обычно обсуждают физики в области высокотемпературной сверхпроводимости, и дали их шести моделям:

⏺️ GPT-4o
⏺️ Claude 3.5
⏺️ Gemini Advanced 1.5
⏺️ Perplexity
⏺️ NotebookLM
⏺️ специальной RAG-системе

Каждый ответ оценивали 12 международных экспертов по нескольким критериям:

⏺️полнота ответа
⏺️объективность
⏺️точность
⏺️наличие научных источников
⏺️ ясность объяснения

Интересный результат:

модели с закрытой, тщательно подобранной научной базой отвечали точнее, чем модели с доступом ко всему интернету.

В закрытой базе использовали:

• 15 ключевых обзорных статей
• около 3300 научных ссылок
• ~1700 отобранных источников по экспериментам и теории.

Главный вывод исследования:

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

Но качество сильно зависит от контролируемых источников знаний, а не просто от доступа к интернету.

https://research.google/blog/testing-llms-on-superconductivity-research-questions/

🫡 Всё про Data Science

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

➡️ MongoDB Memory Leak Exploit (CVE-2025-14847)

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

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

⏺️ Позволяет утекать данные из памяти MongoDB.
⏺️ Использует уязвимость zlib для создания поддельных BSON документов.
⏺️ Может раскрывать внутренние логи и конфигурацию MongoDB.
⏺️ Включает Docker Compose для тестирования уязвимости.

➡️ GitHub: https://github.com/joe-desimone/mongobleed

🫡 Всё про Data Science

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

🔥 Топ-10 open-source AI-моделей на февраль 2026.

Открытые модели больше не «облегчённая версия».

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

Вот модели, на которые стоит обратить внимание:

1️⃣ GLM-5 — автономная разработка и создание приложений
https://github.com/THUDM/GLM-5

2️⃣ MiniMax M2.5 — мощная модель для кодинга (80%+ на SWE-bench)
https://github.com/MiniMax-AI

3️⃣ Kimi K2.5 — мультимодальность, код и продвинутое reasoning
https://github.com/MoonshotAI

4️⃣ DeepSeek V3.2 — эффективная sparse-архитектура, конкурент GPT-уровня
https://github.com/deepseek-ai

5️⃣ Qwen 3 — сильная логика и отличная поддержка множества языков
https://github.com/QwenLM

6️⃣MiMo V2 Flash — высокая эффективность и низкая стоимость инференса
https://github.com/MiMo-AI

7️⃣Mistral Large 3 — большой контекст и удобная коммерческая лицензия
https://github.com/mistralai

8️⃣LongCat Flash Chat — для сверхдлинных диалогов и памяти контекста
https://github.com/LongCatAI

9️⃣ Gemma 3 — открытая модель от Google с хорошим качеством диалогов
https://github.com/google/gemma

1️⃣0️⃣ INTELLECT-3 — полностью открытый стек обучения модели
https://github.com/IntellectAI

Почему это важно:

⏺️ open-weights ≈ уровень топ-моделей
⏺️ можно запускать локально
⏺️ полный контроль над данными
⏺️ база для своих AI-агентов и продуктов
⏺️ экономия на API при масштабировании

🫡 Всё про Data Science

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

🔥 Большие таблицы в SQL - сначала план, потом запрос

Самый полезный апгрейд, который реально экономит часы: не "оптимизировать запрос на глаз", а заставить базу самой показать, что она делает.

На больших таблицах скорость почти всегда решают 3 вещи: правильный индекс, правильная форма запроса и правильный JOIN-порядок.

➡️ Железное правило: прежде чем трогать код, запускают EXPLAIN ANALYZE и смотрят две красные зоны - Seq Scan на большой таблице и огромные строки после JOIN. Если видишь Seq Scan - значит фильтр не поддержан индексом или условие написано так, что индекс не используется. Если после JOIN получаются миллионы строк - значит нужно сначала отфильтровать и/или агрегировать, а потом соединять.

Самый мощный прием для больших таблиц: сначала выбрать маленький набор ключей (CTE или подзапрос), и только потом JOIN к тяжелой таблице. Это резко уменьшает работу базы, потому что она перестает "перемножать" всё со всем.

ПЛОХО: тяжелый JOIN сразу, база тащит миллионы строк
SELECT u.id, COUNT(e.*) AS events_30d
FROM users u
JOIN events e ON e.user_id = u.id
WHERE e.created_at >= NOW() - INTERVAL '30 days'
  AND u.country = 'TH'
GROUP BY u.id;

-- ХОРОШО: сначала сузить пользователей до маленького набора, потом JOIN
WITH target_users AS (
  SELECT id
  FROM users
  WHERE country = 'TH'
)
SELECT tu.id, COUNT(*) AS events_30d
FROM target_users tu
JOIN events e ON e.user_id = tu.id
WHERE e.created_at >= NOW() - INTERVAL '30 days'
GROUP BY tu.id;

-- Индексы, которые реально помогают этому паттерну
CREATE INDEX IF NOT EXISTS idx_users_country_id ON users (country, id);
CREATE INDEX IF NOT EXISTS idx_events_user_time ON events (user_id, created_at);

-- Всегда проверяй, что база использует индекс, а не Seq Scan
EXPLAIN (ANALYZE, BUFFERS)
WITH target_users AS (
  SELECT id FROM users WHERE country = 'TH'
)
SELECT tu.id, COUNT(*)
FROM target_users tu
JOIN events e ON e.user_id = tu.id
WHERE e.created_at >= NOW() - INTERVAL '30 days'
GROUP BY tu.id;

🫡 Всё про Data Science

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