Телеграм канал «Клуб CDO»

Вчера Flower на своём ежегодном саммите показали Lizzy 7B. Компания малоизвестна широкой публике, но в узком кругу federated learning это главная команда в мире: Cambridge-спинаут, YC W23, open-source framework, которым пользуются Samsung, Nokia, Bosch, Siemens Healthcare, Banking Circle. Если вы когда-нибудь слышали словосочетание «federated learning» - с большой вероятностью за этим стоял их код.

Lizzy 7B позиционируется как Sovereign UK LLM - но самое интересное не в позиционировании, а в том как она обучена.

Foundation-модели сегодня тренируют одним способом: сгоняют десятки тысяч GPU в один дата-центр, сливают туда все данные, и месяцами крутят градиенты. Inflection хвасталась кластером из 22 тысяч H100. Isambard-AI в Бристоле построили за 225 миллионов фунтов. Мы привыкли, что pre-training - это физически один объект, обнесённый забором.

Flower первыми показали, что это не обязательно так. Ещё в марте 2024 в партнёрстве с CaMLSys lab в Cambridge они обучили 1.3B LLM через federated learning и побили предыдущий рекорд Google DeepMind больше чем в три раза - модель втрое больше при том же объёме GPU, клиентов и токенов. Год с небольшим - и вот 7B, обученная тем же методом, но на GPU, физически разбросанных по миру. Не fine-tuning поверх чужих весов. Pre-training. С нуля. Распределённо.

Разговор о «суверенных» моделях последние два года идёт по двум осям. Data sovereignty - данные не выезжают из юрисдикции, это про GDPR и CLOUD Act. Compute sovereignty - государство строит свой суперкомпьютер, как UK с Isambard-AI, как EU с EuroHPC. Под обе оси насобирана целая каста 7B-моделей: Mistral во Франции, Lucie там же, Teuken в Германии, Bielik в Польше, Caernarfon от UCL в UK.

Federated learning добавляет третью ось - training sovereignty. Данные и compute остаются у владельцев физически, по сети ходят только градиенты.

Что это меняет практически. Если метод продолжит масштабироваться - а Flower идут по траектории 1B → 3B → 7B довольно уверенно - вопрос «у кого больше H100 в одном здании» перестаёт быть единственным способом играть в foundation models. По расчётам самих Flower, суммарная compute-мощность смартфонов на Snapdragon 8 — 70 экзафлопс против 3 экзафлопс у топового централизованного кластера. Цифры теоретические, но направление понятное.

Как видно на фото с benchmarks относительно других моделей, цифры на удивление очень хорошие.

Вполне достойная модель и можно ее самим попробовать вот тут: https://huggingface.co/flwrlabs/Lizzy-7B

Федеративная модель управления данными - одна из тех идей, которые звучат безупречно на архитектурном ревью и разваливаются в первый же квартал эксплуатации.
Логика понятна: отдай ownership тем, кто ближе всего к данным. Доменные команды знают контекст, бизнес-правила, нюансы. Центральная функция задаёт стандарты и инструменты. Все выигрывают.

На практике получается иначе. Decentralization без enforcement - это не федерация, это фрагментация. Каждый домен начинает изобретать свои определения качества, свои пороги, свои процессы исправления. Вместо одной проблемы с data quality ты получаешь N копий той же проблемы, но с разной нумерацией и в разных спредшитах.

Gaurav Patole в свежей статье предложил Data Quality Partnership Matrix - матрицу 2x2, где по осям Support (поддержка от центральной команды) и Business Engagement (вовлечённость бизнеса). Четыре квадранта: хаос, стагнация, растрата ресурсов, рост. Модель наглядная и честная - особенно в части "стагнации", где бизнес хочет чинить данные, но вынужден делать это в одиночку, руками, в Excel.

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

Ответ, на мой взгляд, простой. Governance в большинстве организаций - это проект, а не операционная функция. У него есть kick-off, стейкхолдеры, стиринг-комитет и дедлайн. А потом он "завершается", и всё возвращается к исходному состоянию. Качество данных не улучшается проектами. Оно улучшается контрактами между системами, валидацией на входе в пайплайн и автоматическими блокировками при нарушении правил.

Федерация работает только когда есть что федерировать - единые стандарты, единые контракты, единый enforcement. Без этого "отдать ownership доменам" означает просто снять ответственность с центра и размазать её так, чтобы никто конкретно не отвечал за результат.
Настоящий тест для любой модели governance прост: что происходит, когда правило нарушается? Если ответ — "ничего, потому что об этом узнают на следующем quarterly review" - у вас нет governance. У вас есть слайды.

https://moderndata101.substack.com/p/data-quality-partnership-matrix

🧩 Визуализация работы агентов с Agent Flow

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

🚀 Основные моменты:
- Живое отображение работы агентов в виде графа
- Автоматическое обнаружение активных сессий Claude Code
- Поддержка нескольких сессий одновременно
- Интерактивный интерфейс для анализа действий агентов
- Поддержка JSONL логов для воспроизведения событий

📌 GitHub: https://github.com/patoles/agent-flow

#javascript

Anthropic выпустили очередной гайд - на этот раз по паттернам координации мульти-агентных систем.

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

Генератор-верификатор - самый простой и, по моему опыту, самый недооценённый паттерн. По сути это must-have для всего, что делают агенты. Один генерирует результат, второй проверяет. Казалось бы - очевидно. Но на практике люди строят сложнейшие пайплайны и забывают встроить элементарную верификацию на выходе. Мой рабочий подход: верификатору даёшь практически тот же промпт что и генератору, и просишь проверить — всё ли в результате соответствует постановке задачи. Звучит примитивно, работает удивительно хорошо. Потому что даже когда агенту говоришь "верни результат в валидной JSON-структуре" - и то не в ста процентах случаев получаешь JSON.

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

А вот шина сообщений и общее состояние - тут я не могу удержаться от улыбки. Publish/subscribe, event-driven pipelines, shared persistent store - это же микросервисная архитектура в чистом виде. Те же паттерны, которые распределённые системы используют лет двадцать. Что, впрочем, не делает их менее полезными - просто подтверждает, что фундаментальные проблемы координации автономных акторов не меняются от того, что акторы теперь на базе LLM.

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

https://claude.com/blog/multi-agent-coordination-patterns

Как построить клиентскую аналитику и находить точки роста в маркетинге и продажах в ритейле 📊

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

📆 15 апреля в 11:00 (онлайн) приглашаем на бесплатный вебинар «Как построить клиентскую аналитику и находить точки роста в маркетинге и продажах в ритейле», где разберём, как объединить данные в единую систему и начать управлять выручкой.

👨‍💻 Спикеры:
Анастасия Третьякова — тимлид BI-направления Lasmart
Сергей Студеникин — эксперт по визуализации данных в AW BI

В программе вебинара:
— как выстроить клиентскую аналитику в BI и связать её с реальной экономикой бизнеса;
— как объединить маркетинг, продажи и клиентские данные в единую модель;
— где искать точки роста LTV, среднего чека и выручки;
— как выявлять поведенческие паттерны и превращать их в управляемые решения;
— кейсы и дашборды, которые помогают находить скрытые инсайты.

Кому будет полезно:
директорам по маркетингу, коммерческим директорам, аналитикам, BI-специалистам и руководителям, отвечающим за рост выручки в ритейле.

🔗 Регистрация по ссылке

Дайджест статей

📰 Миграция базы данных в Legacy системах
🔗 https://habr.com/ru/articles/1020048/
💡 Вывод: Для legacy-систем без ORM и Liquibase/Flyway вполне достаточно самописного инструмента с четырьмя типами скриптов (environment → baseline → versioned → repeatable) и таблицами версий в каждой схеме. Критична не сложность инструмента, а дисциплина: fix-forward вместо rollback и неломающие изменения для горячего деплоя.

📰 Data as Code на практике: создаем, версионируем и делимся модулями БД с помощью ArchDB
🔗 https://habr.com/ru/companies/sberbank/articles/1016996/
💡 Вывод: ArchDB — декларативный DSL поверх DBML с формальной грамматикой, множественным наследованием шаблонов и модульной системой (Package, Schema, Import/Export). Ключевая идея: стандарты проектирования БД перестают быть PDF-документом и становятся исполняемым кодом, который автоматически распространяется через версионируемые библиотеки шаблонов.

📰 Рецензия на книгу «Искусство визуализации в бизнесе»
🔗 https://habr.com/ru/companies/ssp-soft/articles/1018680/
💡 Вывод: Книга Натана Яу (FlowingData) — практический гайд по всему циклу визуализации: от сбора данных до выбора типа графика и дизайна. Фокус на коммуникации данных бизнес-аудитории, не на статистике и не на UI-дизайне. Полезна аналитикам, которые готовят отчёты для руководства.

📰 Книга: «Архитектура медальона. Проектирование с помощью Delta Lake и Spark»
🔗 https://habr.com/ru/companies/piter/articles/1021230/
💡 Вывод: Питхейн Стренгхольт (автор «Data Management at Scale») даёт практическое руководство по медальонной архитектуре на Azure Databricks и Microsoft Fabric с реальными кейсами AP Pension, Amadeus и ZEISS. Книга покрывает контракты данных, безопасность и применение GenAI/RAG к неструктурированным данным внутри медальона.

📰 Разработка BI-аналитики для застройщика в Apache Superset
🔗 https://habr.com/ru/articles/1021606/
💡 Вывод: Кейс миграции с Power BI на Apache Superset из-за санкционных рисков. Типовой паттерн: Python-скрипты для сбора из 1С/Google Sheets/Excel → PostgreSQL → view/materialized view → дашборды. Superset выбрали именно за автономность — open-source на собственной инфраструктуре без зависимости от внешних лицензий.

📰 Почему observability-данные теряют ценность ещё при сборе
🔗 https://habr.com/ru/companies/otus/articles/1020952/
💡 Вывод: Модель «трёх опор» (метрики/логи/трейсы) разрушает связность данных при записи, а ценность телеметрии растёт комбинаторно с количеством атрибутов в одном событии. AI-SRE-агенты уже обходят традиционную observability, возвращаясь к сырым данным ради сохранённого контекста. Для агентной валидации в продакшене нужны широкие структурированные события, а не разрозненные сигналы.

📰 Beyond ETL: The Case for Context
🔗 https://agentblueprint.substack.com/p/beyond-etl-the-case-for-context
💡 Вывод: ECL-фреймворк (Extract → Contextualize → Link) переносит центр тяжести с трансформации данных на формализацию значений. Context Store — это по сути materialized view для семантики: версионируемое, queryable хранилище определений, которое агенты читают до обращения к данным. Инфраструктура для этого уже существует (инкрементальная репликация, tenant isolation, freshness SLA) — не хватает governance-шаблонов.

📰 Reference Data Management по-русски: что мы называем НСИ и почему это не всегда RDM
🔗 https://habr.com/ru/companies/datasapience/articles/1012404/
💡 Вывод: В международной практике RDM (справочники) и MDM (мастер-данные) — разные классы систем с разными задачами. В российской практике НСИ = RDM + часть MDM + DQ, и заказчики хотят «одну систему на всё». Универсальные решения пока не дозрели — на горизонте 3–5 лет, а сейчас разумнее подбирать специализированный продукт под каждую задачу.

Прочитал AI Engineering Чип Хуен (O'Reilly, 2025). Книга, которую стоит прочитать не потому что в ней есть что-то революционное, а потому что она собирает в одном месте то, что практики уже знают по кускам - и выстраивает из этого систему.

Хуен чётко разделяет AI engineering и классический ML engineering. Первый - про сборку приложений поверх готовых foundation models, не про обучение с нуля. И именно здесь начинаются проблемы, которые большинство учебников обходит стороной: как оценивать то, что по определению вероятностно? Как отлаживать систему, где каждый шаг агента - множитель ошибки (95% точности на шаг превращается в 0.6% за сто шагов)? Как перестать путать работающее демо с продуктом?

Мои основные takeaways уместились в несколько тезисов.

Из трёх конкурентных преимуществ в AI - технологии, данные, дистрибуция - реальным дифференциатором является дистрибуция. Технологии выровняются, данные - вопрос масштаба, а вот канал доставки или есть, или нет. Оценка (evaluation) - не afterthought, а часть MVP. Без системной оценки вы не знаете, работает ваш продукт или галлюцинирует. Логирование - это не благие намерения, а production-readiness. Без observability нет отладки, без отладки нет продукта. И наконец, промпт-инжиниринг - это не подбор слов, а инженерная дисциплина, требующая статистики, экспериментов и данных.

Книга: https://www.oreilly.com/library/view/ai-engineering/9781098166298/