Дайджест статей 📰 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 — именно потому что отражает поведение пользователя, а не состояние сервиса. Данные заслуживают того же уровня валидации при деплое, что и код.