Data Engineering *

Аннотация

Посмотрите на эту обложку. Слева — Рай. Справа — Ад. Между ними — вся жизнь.

Иероним Босх написал «Сад земных наслаждений» больше пяти веков назад. Он показал, как человек движется от гармонии через свободу к коллапсу. Но можно ли измерить этот путь? Можно ли выразить в битах то, что художник изобразил красками?

Эта статья — эксперимент. Мы возьмём старую идею Августина Блаженного (зло — это не активная сила, а отсутствие добра) и проверим её математически.

С помощью простой модели точек и сил мы смоделируем три состояния:

1) Рай (левая створка) — баланс между реальностью и свободой. Энтропия максимальна.

2) Ад (правая створка) — доминирование критика, страха, наказания. Все точки схлопываются в одну кучку. Разнообразие умирает.

3) Хаос — вседозволенность без опоры, где свобода превращается в бессмысленный шум.

Мы измерим энтропию выбора S, вычислим грех как падение энтропии ΔS_грех и увидим, что свобода — это не отсутствие правил, а пространство для мышления и открытия новых горизонтов.

Привет, Хабр!

Это Андрей Ловлин, руководитель команды «Фабрика данных. Платформа» компании Диасофт. В предыдущей статье мы рассказывали про S3 Архипелаг – слой хранения для нашей «Фабрики данных» (Digital Q.DataFactory). Сегодня речь пойдет о другой задаче: построение конвейера интеллектуального распознавания документов, загружаемых в нашу «Фабрику данных».

PDF-файлы, сканы, фотографии договоров – все это накапливается в организациях годами. Для построения RAG-систем и работы с LLM эти данные необходимо извлечь из неструктурированных документов и преобразовать в структурированный формат. Задача, на первый взгляд, тривиальная. На практике – не совсем.

Всем привет! Меня зовут Никита и я CEO компании VSL-BI. Мы занимаемся внедрением BI-аналитики.

К нам обратилась компания из сферы продажи стройматериалов. Они активно работали с рекламой в Яндекс Директ и Google Ads (клиент вел деятельность в Казахстане), следили за аналитикой сайта в Яндекс Метрике, в качестве CRM использовали Битрикс24.

Аннотация

Можно ли измерить свободу выбора в битах? А грех — в потерянной энтропии? Можно ли математически описать любовь без условий, а Бога — не как программиста, а как создателя пространства возможностей?

В этой статье я предлагаю формальную метафизическую модель «Веры Паломника — Исход». Мы пройдём путь от вариационного исчисления и стохастической оптимизации к энтропии выбора, функции полезности Любви и количественной мере греха. Всё подкреплено рабочим кодом на MATLAB и вычислительными экспериментами.

Статья адресована всем, кто интересуется стыком математики, ИИ и философии: от ML-инженеров и физиков до метафизиков и ищущих. Базовое знание математического анализа приветствуется, но не обязательно.

На связи Анна Астахова, коммерческий директор ИТ-интегратора «Белый код». В компаниях с развитой сетью партнеров топ-менеджерам нужны оперативные данные. А отчеты в Excel тормозят работу. Сегодня рассказываю, как можно организовать и настроить единое хранилище данных на примере компании с широкой партнёрской сетью в сфере электроники.

Ваш AI‑чат или автокомплит тормозит при 50 запросах в секунду? Монолит убивает GPU и латенси?

В этом туториале — реальная архитектура low‑latency инференса на high‑load: почему изолированный inference‑bundle вместо монолита, как выбрать между vLLM и SGLang без маркетинга, зачем нужны continuous batching и admission control.

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

Мне поручили пересобрать витрину в ходе миграции в наше новое хранилище данных. Итак, в этой статье мы будем:

— строить Iceberg-таблицы SCD-2 с помощью Trino, SQL и Python;

— попутно освоим прекрасные функции merge, MD5 и другие полезные инструменты;

— напишем свой собственный оператор для Airflow для автоматизации ETL-процесса.

Хабр, привет! Меня зовут Андрей Вихров, я создавал аналитические системы и внедрял data governance (DG) в крупных компаниях больше 15 лет, а сейчас занимаюсь метаданными в Data Office МТС. Тема порядка в данных для меня не нова, а какие выгоды можно извлечь из нее сегодня — стоит отдельного рассказа.

В компании накоплен огромный массив данных — только в дата‑каталоге зарегистрировано более 500 тысяч таблиц. С ними ежедневно работают сотни специалистов: от продуктовых аналитиков до инженеров данных, строящих витрины для ML‑моделей.

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

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

Логичный выход — автоматизировать процесс. Но если опытный аналитик справляется (рано или поздно) с задачей в существующих условиях, то ИИ‑агент этого сделать уже не сможет, поскольку опирается только на метаданные.

В нашем случае сложились два фактора. За годы работы над DG мы накопили экспертизу в описании и структурировании метаданных. А появление LLM дало возможность создавать семантические слои на промышленной основе и использовать их для ответа на вопросы пользователей. Объединив одно с другим, мы создали и пилотируем систему Метан (метаданные + аналитика).

Append-only — целебная пилюля для ClickHouse, без которой он скорее обуза, нежели буст для бизнеса. Разберем что это, и как этим пользоваться.

Посмотрела Туториал NeurIPS «The Art of Benchmarking» — панель с авторами SWE-bench, GPQA и ведущими исследователями из Google DeepMind, NYU и Berkeley.
Вот мой конспект. Делюсь с вами, так как бенчмарки теперь не только про науку, но и про безопасность, регуляторику и миллиардные решения о деплое.

* Тирания метрик
Оказывается, любая метрика имеет honey spots, которые модель может хакнуть. Проблема в том, что текущая мета-оценка (корреляция Пирсона) эти точки не показывает. А если метрика становится еще и reward'ом при обучении — могут быть проблемы

* Про долговечность
Бенчмарки действуют только определенный период, и нередко - далеко не 10 лет. Всё насыщается. ImageNet продолжает быть полезным, потому что его используют для 10 разных задач (диффузия, CLIP, zero-shot). А большинство бенчмарков теряют актуальность, но продолжают кочевать по paper'ам еще 5 лет — просто потому, что их удобно цитировать. Это плохая практика.

* Субъективность — везде
Даже в классификации изображений люди расходятся. Две принципиально разные причины: (а) задача плохо задана (underspecification), (б) люди реально думают по-разному. Проблема краудворкинга: если не кэпировать ответы, вы получите не мнение популяции, а мнение Боба, который сделал 80% аннотаций.

* LLM как источник оценки — это очень опасно
Они коррелируют с людьми только на той выборке, на которой их калибровали(!). Модель становится умнее — распределение данных меняется — корреляция падает. А при генерации бенчмарков LLM имеют сильнейший self-bias (даже с независимой метрикой). Единственный корректный подход — заставить модель генерировать примеры, на которых она ошибается

Недавно прогремела громкая новость: Google DeepMind будет тестировать ИИ-модели в EVE Online — одной из самых сложных MMO с живой экономикой, корпорациями игроков, дипломатией, войнами и рынками. Лаборатория заключила исследовательское партнерство с Fenris Creations, студией-разработчиком EVE Online, ранее известной как CCP Games. Google также получила миноритарную долю в компании.

Сделка прошла в момент крупной перестройки студии. Fenris Creations вышла из-под контроля Pearl Abyss и стала независимой после соглашения на 120 млн долл. Компания сохранила руководство, команды и текущие проекты, включая EVE Online, EVE Vanguard и EVE Frontier.

DeepMind не будет запускать эксперименты в основном мире EVE Online. Для исследований будет использоваться офлайн-версия игры на локальном сервере. Это позволит тестировать и оценивать модели в изолированной среде.

Зачем ИИ-проектам такие песочницы, чему они будут там обучаться и каким может стать ИИ благодаря такому обучению.

Привет, Хабр! Меня зовут Сергей Тимакин, сейчас учусь на первом курсе онлайн-магистратуры «Специалист по работе с данными и ИИ» НИЯУ МИФИ в партнёрстве с Яндекс Практикумом и параллельно работаю в Озоне аналитиком данных. В этой статье я расскажу, как я столкнулся с трудностями в понимании слоёв и моделей данных — и как разобраться в этой теме.

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

Эта статья адресована бэкенд-разработчикам, которые уже выкатили агента в прод или готовятся это сделать. Она является практическим продолжением нашего предыдущего материала о Red Teaming LLM: там мы разобрали концептуальную базу и объяснили, почему языковые модели требуют отдельного подхода к тестированию безопасности. Здесь — конкретный кейс из реальной практики Doubletapp и пошаговый инструмент, который можно поднять и запустить на своём агенте уже сегодня.

Содержание
- Чем Red Teaming агента отличается от Red Teaming LLM
- Cookbook: базовый Red Teaming с Promptfoo
- Ссылки

Когда инженер слышит «нам нужно хранилище данных», задача редко звучит однозначно. Кто-то задыхается на боевой OLTP-базе под аналитической нагрузкой. Кто-то впервые строит BI и не понимает, с какого края подходить. У кого-то накопились данные из десятка систем-источников, и существующих средств уже не хватает.

У всех «хранилище». А правильный технический ответ зависит от условий задачи.

За годы работы в банках, ритейле и системной интеграции мы пришли к простой картине: для среднего и крупного бизнеса большинство DWH-проектов сводится к четырёхзонной архитектуре поверх двух специализированных движков. Не Inmon, не Kimball-star-schema, не Data Vault 2.0 - и при этом не «modern data stack как у Databricks один-в-один».

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

В современном IT ландшафте широко используютя  форматы представления данных JSON и XML, используемые в качестве своеобразного "общего языка", lingua franca  для обмене информацией.

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

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

Когда классические SQL‑базы падают под аналитической нагрузкой, а Hadoop‑кластер напоминает чемодан без ручки — пора искать новое решение.

В этой статье разбираем, как ClickHouse в связке с NoSQL‑экосистемой закрывает бреши в высоконагруженных проектах. Разберём архитектурные ловушки, Best Practices и честно оценим, где этот инструмент экономит миллионы, а где может создать проблемы.

Немного погрузимся во внутреннее устройство Apache Airflow и разберёмся, что на самом деле происходит за красивым синтаксисом TaskFlow API. Посмотрим, как работают декораторы @task и @dag, каким образом обычные Python‑функции превращаются в задачи Airflow и за счёт какой «магии» строится граф зависимостей. А заодно напишем собственный мини‑пример, чтобы лучше понять архитектурные идеи, на которых построен современный Airflow.

iceberg и его философия metadata расскажем почему iceberg эффективно выполняет запросы и прост в управлении данными благодаря своей metadata

Представьте себе классическую ситуацию: финансовый директор смотрит на два отчета по выручке за прошлый год. Один отчет, построенный в старой системе, показывает 150 миллионов рублей, другой — в новой корпоративной CRM — демонстрирует 145 миллионов. Разница в 5 миллионов, а вместе с ней и ощущение, что новая система «врет» и вводит всех в заблуждение. Начинается поиск виноватых, и, как это часто бывает, крайними оказываются ИТ-специалисты, якобы «неправильно настроившие миграцию».

Но проблема гораздо глубже. Дело не в кривых скриптах и не в саботаже данных. Причина кроется в «Иллюзии темпоральности» — коварном и широко распространенном заблуждении, что изменчивостью данных во времени можно пренебречь, и достаточно хранить лишь последнее известное состояние. В то время как реальный бизнес находится в бесконечной динамике: клиенты переезжают, меняют паспортные данные и сегменты лояльности; товары проходят через ребрендинг и смену классификаций; сотрудники переходят из отдела в отдел. Если система фиксирует лишь последний известный срез, прошлое в отчетах неизбежно исказится, что и приводит к тем самым «пропавшим» или нестыкующимся суммам.

Современные методологии управления данными, в частности Slowly Changing Dimensions (SCD) или «Медленно меняющиеся измерения», предлагают элегантный и проверенный способ справиться с этой иллюзией, превратив хаос непрерывных изменений в стройную, аналитически ценную картину.