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

Сегодня CleverDATA 12 лет.

Редакция поздравляет всех причастных. Тех, кто начинал. Тех, кто поддерживал и сочувствовал. Тех, кто покупал наши решения, и тех, кто не покупал - вы тоже часть этой истории.

За 12 лет мы прошли путь от Big Data консалтинга через DMP-платформу для рекламного рынка до Agentic CDP, которой сегодня доверяют крупнейшие retail-клиенты. Мы раскачивали рынок данных. Исследовали, ошибались, иногда заходили совсем не туда и перестраивались.

Так и работает инженерия: гипотеза, проверка, поворот, снова.

Спасибо всей нынешней команде. И спасибо комьюнити, которое сложилось вокруг нашего небольшого проекта.

Мы гордимся тем, кто мы есть. И мы стремимся к большему.

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

А то сделаешь скил (code review например), пока делал и отлаживал - хватало лимита стандартной подписки, а в проде начало крутиться и уже 600$ в месяц съедает.

Вот JPMorgan (печально известный своими кадровыми вопросами) выпустил свежий свод по моделям в координатах качество/стоимость.

Еще одна рекомендация книги от редакции. Как продолжение прекрасной книги Thinking in Systems, очень рекомендую книгу Black Box Thinking.

Black Box Thinking про готовность и упорство раскапывать уроки, которые почти всегда есть в провале, но которые мы редко используем. Это системы и культура, которые позволяют учиться на ошибках, а не чувствовать от них угрозу.

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

Структура определяет поведение. Эта книга про то, как построить структуру, в которой на ошибках учатся, а не защищаются от них.

https://www.amazon.co.uk/Black-Box-Thinking-Surprising-Success/dp/1473613779

олды помнят

Буквально на прошлой неделе вышел интересный материал от CNews: рейтинг российских BI-инструментов.

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

Но главное в рейтинге не тройка лидеров, а ключевой тренд и фокус, который держат все производители: доступность (он же модный self-service BI). Аналитика без очереди к ИТ, дашборды без кода, спроси данные на естественном языке.

Рейтинг это хорошо показывает. Платформы сравнили по 130+ параметрам, и добрая половина критериев не про движок обработки данных, а про то, как обойтись без ИТ: готовые дашборды, обучение пользователей, преднастроенные интеграции. В тройке Yandex DataLens, PIX BI, Luxms BI. Всё крутится вокруг одного: смотри сам, считай сам, не жди айтишника.

У флагмана, DataLens, появился ИИ-агент Нейроаналитик на больших языковых моделях. К ноябрю его уже попробовали больше 1500 компаний, обещают минус 30% к нагрузке на аналитиков. Спросил голосом, получил график с выводами.

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

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

И ИИ-слой эту зависимость не ослабляет, а усиливает. Запрос на естественном языке поверх кривой модели данных это не пустой ответ. Это уверенно неправильный ответ, выданный быстрее, и без аналитика, который раньше его ловил. Чем сильнее опираешься на агента, тем строже обязана быть модель под ним.

Self-service и ИИ-агент не отменяют дата-инженерию, они поднимают на неё ставку. Кто навёл порядок в данных, тот и получит обещанную магию. Остальные получат быстрые красивые ошибки.

https://www.cnews.ru/reviews/preview_articles/2979896a1c832588550

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

📰 DCD: доменно-ориентированная архитектура для построения RAG-систем
🔗 https://habr.com/ru/companies/redmadrobot/articles/1049030/
💡 Вывод: Команда red_mad_robot опубликовала собственный архитектурный подход Domain–Collection–Document для RAG-систем — трёхуровневая иерархия знаний с LLM-маршрутизатором, последовательно сужающим пространство поиска от домена до документа. Ключевой тезис: качество ответов растёт не от усложнения модели, а от семантической организации базы знаний — при условии, что границы между доменами поддаются определению заранее. Открытый код на GitHub, датасет на HuggingFace.

📰 Внешняя память для LLM: как RAG дает моделям доступ к новым знаниям
🔗 https://habr.com/ru/companies/magnus-tech/articles/1046702/
💡 Вывод: Подробный разбор RAG от первых принципов: почему LLM галлюцинируют (параметрическая память конечна, RLHF усиливает склонность соглашаться), как устроен пайплайн индексирование → поиск → генерация, где RAG даёт слабину (многошаговые рассуждения, конфликт параметрической памяти с внешними данными, задержки реранжирования). Для CDO-аудитории ценнее не учебник, а вывод в конце: RAG — не панацея, выбор между промптингом, файнтюнингом и RAG определяется тем, что именно нужно изменить — знания модели или её поведение.

📰 Data Mesh: что это и почему концепция не подходит большинству компаний в России
🔗 https://habr.com/ru/articles/1049724/
💡 Вывод: Честный разбор от Qlever Solutions — Data Mesh это не архитектура хранения данных, а организационная трансформация, требующая децентрализованной культуры, продуктового мышления в бизнес-доменах и зрелых DevOps-практик. Большинство российских компаний пока строят DWH и выстраивают Data Governance — и это правильно: путь DWH → Lakehouse → Data Mesh эволюционный, а не выборочный. Data Mesh оправдан только после того, как централизованное DWH стало реальным узким местом.

📰 From ETL to Lakeflow: Shifting to Declarative Data Paradigm
🔗 https://dzone.com/articles/shifting-to-declarative-data-paradigm
💡 Вывод: Databricks Lakeflow переводит пайплайны с императивной логики (вы описываете шаги) на декларативную (вы описываете таблицу, движок сам строит граф зависимостей, масштабирование и линейку). Реальный выигрыш — не синтаксис, а устранение племенного знания: порядок выполнения, реранжирование, проверки качества и линейка перестают жить в головах конкретных инженеров. Стратегия миграции разумная: новые пайплайны → болезненные старые → ликвидация оркестратора.

📰 The Data Canary: How Netflix Validates Catalog Metadata
🔗 https://medium.com/netflix-techblog/the-data-canary-how-netflix-validates-catalog-metadata-18b699d58e36
💡 Вывод: Netflix построил аналог канарейки для деплоя данных — не кода. Выделенный оркестратор, постоянные baseline/canary кластеры, хаос-эксперимент с реальным продакшн-трафиком (0,2%), детектирование за 2,5–4 минуты. Ключевое методологическое решение: метрика Starts Per Second (фактические попытки воспроизведения) оказалась надёжнее latency и error rate — именно потому что отражает поведение пользователя, а не состояние сервиса. Данные заслуживают того же уровня валидации при деплое, что и код.