🔥Один слой данных вместо цепочки копий между системами

В традиционной аналитической инфраструктуре результаты обработки приходится переносить между хранилищем, SQL-системой и BI. Вместе с каждой копией появляется новая задача: ее нужно обновлять, сверять с исходными данными и учитывать в правилах доступа.

В DataLens Platform разные инструменты работают с общей основой данных. Lakehouse построен на S3 и Apache Iceberg. Trino используется для интерактивных SQL-запросов, Spark — для ресурсоемкой обработки, Airflow — для управления процессами.

Единый каталог метаданных показывает происхождение данных и их использование. Общая модель доступа действует на уровне всей платформы.

Так компания сокращает количество переносов между системами, а результаты подготовки данных можно повторно использовать в SQL-запросах, отчетах и ИИ-сценариях.

📎 Подробнее о DataLens Platform — в материале СМИ.

Softmax простыми словами: что значат 66,5% в ответе нейросети?

Softmax простыми словами: ChatGPT выдаёт не ответы, а вероятности следующих токенов, и 66,5% означают только то, что такое продолжение текста самое вероятное.

Модель может звучать уверенно и при этом ошибаться, потому что вероятность токена это не вероятность правды. Разбираем на деле Киры, как проверять ответы ИИ через источники и контекст.

Тысячи ИИ-агентов одновременно читают продакшен-базу. Что происходит с PostgreSQL?

Google представила PostgreSQL for agents в AlloyDB. Когда нагрузка растёт, система за секунды запускает изолированные экземпляры базы для агентов. Они получают доступ на чтение к актуальным данным, но не конкурируют за вычислительные ресурсы с основной базой. После работы экземпляры масштабируются до нуля.

Агентам доступны SQL, индексы, векторный и полнотекстовый поиск. Идея в том, чтобы они могли исследовать свежие данные и выполнять множество запросов, не замедляя транзакции пользователей.

Статус: Preview, доступ предоставляется по запросу.

Анонс Google Cloud - https://cloud.google.com/blog/products/databases/announcing-postgresql-for-agents-in-alloydb

💀 Claude Code за 103 секунды удалил более 48 тысяч файлов

Пользователь Claude Code сообщил о серьёзном инциденте: AI-агент якобы удалил 48 218 файлов рабочего проекта и уничтожил часть Git-репозитория.

Что произошло:

- агенту поручили пересобрать mirror проекта;
- он написал Python-скрипт для удаления старой копии;
- в Windows-каталоге находились directory junctions, ведущие обратно в рабочее дерево;
- проверка ссылок сработала не так, как ожидалось;
- скрипт начал удалять уже реальные файлы проекта.

В результате были очищены .git/objects, refs и logs, поэтому восстановление через обычный Git оказалось невозможно.

Checkpoint Claude Code здесь не обязательно спасает, потому что изменения, сделанные через Bash/PowerShell, могут не попадать в механизм rewind.

Источник:
https://cybersecuritynews.com/claude-code-agent-file-deletion/

⚡️ Запустили PostgreSQL в Docker и случайно открыли его всей сети?

Команда docker run -p 5432:5432 ... по умолчанию публикует порт на всех сетевых интерфейсах хоста. На Linux правило UFW, закрывающее порт, может не помочь: Docker направляет трафик к контейнеру до обработки правил UFW.

Если доступ нужен только с самого сервера, укажите адрес явно:

docker run -p 127.0.0.1:5432:5432 ...

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

Документация Docker - https://docs.docker.com/engine/network/port-publishing/

🔥Полноценный data stack внутри своего контура

Когда данных становится много, одного SQL-движка или отдельной СУБД уже недостаточно. Нужна связка инструментов, которая закрывает весь путь данных: от загрузки и хранения до обработки, аналитики и визуализации.

Такой сценарий можно реализовать в Stackland - платформе, которая разворачивается локально в контуре компании.

В обновлении появились PaaS-компоненты Yandex Cloud, из которых можно собрать полноценную data-платформу:
🔹 Managed Service for ClickHouse® и Managed Service for PostgreSQL - хранение и обработка данных.
🔹 Yandex Managed Service for Trino + Yandex Object Storage - основа аналитического слоя: S3 обеспечивает масштабируемое хранение данных, а Managed Service for Trino — быстрый SQL-доступ к ним.
🔹 Managed Service for Apache Airflow® - управление оркестратором потоков операций по обработке данных.
🔹 Yandex DataLens - BI-система для визуализации данных.
При этом все основные компоненты платформы разворачиваются внутри инфраструктуры компании.

Для data engineering-команд такой подход интересен прежде всего тем, что можно собрать под одной платформой основные компоненты современного data stack: Storage → SQL → ETL/ELT → DWH/аналитика → BI

И не тратить время на самостоятельную сборку и поддержку каждого компонента с нуля.

🗄 ИИ-агент работает с базой, но как не дать ему показать лишнее?

6 октября в Архитектурном клубе Яндекс 360 разберут архитектуру ИИ-агента над корпоративными данными. В том числе поговорят о поиске, метаданных и фильтрах, а главное — о том, как наследовать права доступа исходных систем.

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

🗓 6 октября, 17:00 МСК
💻 Онлайн, бесплатно

→ Зарегистрироваться на эфир

Полезный совет для MySQL 8: используй LATERAL, когда для каждой строки нужно получить «лучшие N связанных записей».
Например, взять последние 3 заказа каждого пользователя:

SELECT
    u.id,
    u.name,
    o.id AS order_id,
    o.created_at
FROM users u
JOIN LATERAL (
    SELECT id, created_at
    FROM orders
    WHERE orders.user_id = u.id
    ORDER BY created_at DESC
    LIMIT 3
) o ON TRUE;

Без LATERAL такую задачу часто решают через оконные функции и сначала ранжируют всю таблицу orders.
С LATERAL база может для каждого пользователя сразу сходить по индексу:

CREATE INDEX idx_orders_user_created
ON orders (user_id, created_at DESC);

Особенно полезно для задач вида:
«последние N», «самая дорогая запись», «ближайшее событие», «лучший результат для каждой строки».
Главное: всегда проверяй EXPLAIN ANALYZE — на больших таблицах правильный составной индекс здесь решает всё.

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

На открытом уроке разберём, как создавать ИИ-системы с учетом требований безопасности с самого начала. Вы узнаете, какие угрозы характерны для LLM, как применять принципы Security by Design и какие архитектурные решения помогают защитить данные и компоненты системы.

Разберём практический кейс: усилим архитектуру ИИ-агента с помощью механизмов защиты, проверки данных и управления доступом. Урок пройдет в преддверие старта курса «ИИ-архитектор».

Он будет полезен архитекторам ПО, разработчикам, специалистам по инфраструктуре и безопасности, которые проектируют или внедряют ИИ-решения: https://otus.pw/newu/?erid=2W5zFGJGC8R

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

GitHub представил Agentic Engineering System - фреймворк для команд, которые внедряют AI-агентов в разработку.

Идея простая: больше сгенерированного кода ещё не означает больше пользы.

GitHub предлагает строить работу вокруг трёх вещей:

- Governance — что агентам можно делегировать и где нужен человек
- Shared Knowledge — код, документация, решения, телеметрия и контекст
- Customer Value — приносит ли ускорение реальную пользу пользователям

Сам процесс делится на цикл Define → Deliver → Detect, а человек и AI могут выступать как director, performer или assessor.

Главная метрика: скорость должна расти без роста дефектов и потери качества.

https://github.com/resources/insights/agentic-engineering-system