Data Engineering *

Я Дмитрий, CEO digital-агентства OMNIMIX. Уже три года я полностью погружен в мир ИИ: сначала почти не спал по ночам, часами перебирал промпты, тестировал разные подходы и буквально «стирал пальцы в кровь» на клавиатуре, пытаясь понять, что действительно работает. Именно в этот период я впервые по-настоящему увидел, насколько ИИ способен менять не только рекламные кампании и маркетинговые тренды, но и саму структуру бизнеса, подход к работе команды и способы взаимодействия с клиентами.

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

Универсальные модели вроде GPT хорошо справляются с широким классом задач, но буксуют в узких доменах. Они не знают специфику нишевых индустрий, их жаргон и не имеют доступа к проприетарным знаниям, которые делают ваш бизнес уникальным. Когда нужна система ИИ, которая действительно «понимает» именно вашу предметную область, стоит выбирать домен-специфичные LLM (DSLM).

Кто вы в мире данных — аналитик, BI-разработчик или Data Engineer? 🔍 Разбираем реальные роли и показываем, чем они отличаются на практике.

Принцип «тестируй все» не повышает, а разрушает качество данных. Сотни бесполезных алертов создают шум, в котором тонут действительно важные сигналы, а команда перестает на них реагировать. В Google и Monzo от этого уже отказались. Рассказываем, как перейти от тотального тестирования к точечным проверкам узлов с максимальным радиусом влияния и почему один правильный тест на источник важнее сотни проверок в витринах.

Привет, Хабр! На связи снова Александр Токарев. И это третья часть из серии статей о том, почему в космосе нет дата-центров.

Во второй части мы разобрались, что главные барьеры для космических ЦОДов — вовсе не процессоры, а энергия, охлаждение, радиация и отсутствие устойчивых сетей. Но пока проекты с «настоящими» дата-центрами остаются в рендерах, в космосе уже крутятся рабочие вычисления. Давайте посмотрим, что из этого реально работает сегодня и какие горизонты впереди.

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

Одной из наиболее примечательных особенностей Large Language Models (LLM) является их способность к in-context learning — обучению в контексте. В частности, на этапе инференса LLM может усваивать новые паттерны без какого-либо дополнительного обновления весов, если эти паттерны представлены в виде примеров в промпте, даже если эти паттерны не встречались во время обучения. Механизмы, за счёт которых это возможно, всё ещё во многом остаются неизвестными.

В данной работе мы показываем, что комбинация слоя self-attention с MLP позволяет трансформер-блоку неявно модифицировать веса MLP-слоя в зависимости от контекста. Мы утверждаем на основе теоретического анализа и экспериментов, что этот простой механизм может объяснять, почему LLM способны обучаться в контексте, а не только во время тренировки модели. В частности, мы демонстрируем, что при ряде упрощающих допущений трансформер-блок неявно преобразует контекст в low-rank обновление весов MLP-слоя.

Приветствуем всех коллег по цеху!

Мы в X5 Tech запускаем опрос, чтобы лучше понять, как живёт сообщество специалистов по работе с данными: какие инструменты используете, какие вызовы встречаете в работе и о чём мечтаете в свободное время.

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

Всем привет!

Сейчас много пишут о проблемах с поиском работы в ИТ‑отрасли и массовых увольнениях/«оптимизациях» персонала, в том числе якобы из‑за внедрения ИИ. Однако если открыть LinkedIn, складывается несколько иное впечатление — вакансий, конечно, не «пруд пруди», но и на «зимнюю спячку» это совсем не похоже. По крайней мере, на первый взгляд.

Совсем недавно мой друг искал работу в Германии. Сам он говорит, что «чукча — не писатель», поэтому с его позволения я решил поделиться с сообществом его наблюдениями и выводами по результатам данного «погружения в рынок». Тем более, что был непосредственным свидетелем данного поиска, и мы часто обсуждали его за чашкой кофе или бокалом пива:‑) На объективную оценку ситуации не претендую (или «не претендуем»?), но, наверняка есть немало коллег, которым эта информация может показаться полезной/интересной. Данная статья является компиляцией того, чем делился со мной он и моими собственными вставками и наблюдениями.

Это обзор двух проектов аналитических СУБД с открытым исходным кодом, которые развиваются в одном классе задач, но различаются архитектурой, приоритетами и типичными сценариями применения. Ниже — нейтральное сравнение по ключевым аспектам: архитектура и запросный движок, хранение и работа в реальном времени, интеграция с открытыми форматами и lakehouse, производительность, эксплуатация и управление, а также рекомендации по выбору в зависимости от нагрузки.

Привет, коллеги! Сегодня хочу поделиться с вами своими размышлениями о терминальном AI-агенте OpenCode и его сравнении с другими популярными решениями на рынке. После нескольких месяцев активного использования различных AI-инструментов для кодирования, могу с уверенностью сказать: OpenCode — это действительно что-то особенное.

Любите ли вы SQL так же, как и я? Недавно, собирая огромный SQL‑запрос, я понял, что надо что‑то менять.

Логическим блоком в SQL является подзапрос или CTE и вроде бы можно разбивать запрос по блокам и работать с ними отдельно, как строится по кирпичикам любое приложение.

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

А что, если не надо писать SQL? В SAP мы не писали запросы, мы создавали Calculation View, и работать с ними было на порядок быстрее и приятнее.

Перефразируя диалог из Матрицы:

— Когда я стану избранным, я смогу писать длинный SQL?
— Тебе не надо будет писать SQL.

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

Согласованность — одна из самых важных тем в современной области машинного обучения (ML). Независимо от того, являетесь ли вы пользователем продуктов ML, человеком, который их разрабатывает, или компанией, решающей с их помощью задачи, вам стоит знать и хорошо понимать, что такое согласованность.

TL;DR: Мы провели бенчмаркинг семи методов, направленных на предотвращение эмерджентного рассогласования и других форм некорректного обобщения с использованием ограниченного объёма alignment-данных. Мы демонстрируем устойчивый трейдофф между способностями модели и согласованием, подчеркивая необходимость более эффективных методов для снижения этого конфликта. Простое включение alignment-данных в микс обучающих данных оказывается недостаточным для предотвращения рассогласования, однако простое наложение KL Divergence penalty на alignment-данные показывает лучшие результаты, чем более сложные подходы.

Мой опыт работы больше связан с темой анализа и оптимизации бизнес-процессов, поэтому процессное регулирование (process governance) мне было знакомо не понаслышке: реестр процессов, владельцы процессов, непрерывный цикл улучшения процессов, требования к целевому состоянию процессов (описан, измеряется, оптимизирован, оцифрован). Еще помню еженедельные заседания комитета по бизнес-процессам, секретарем которого я являлся несколько лет, а возглавлял этот комитет – ключевой руководитель в организации.

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

Для тех, кто не знает, что такое регулирование (governance) и чем оно отличается от обычного управления, регулирование – это практики для больших организаций, которые фокусируются на создании организационной среды, в которой «классическое» управление сможет эффективно функционировать, а также в поддержании этой среды на необходимом уровне.

Про протокол MCP (Model Context Protocol) сейчас говорят всё чаще. Этот протокол позволяет нейросетям общаться с внешним миром. С его помощью к LLM можно подключать любые источники данных или системы управления, и всё это через один универсальный стандарт. MCP часто сравнивают с USB — устройство одно, протокол один, а число сценариев применения практически бесконечно.

В статье расскажу про практический сценарий «как связать LLM и базу данных». Это может сделать любой на своём компьютере.

Протокол MCP придумали ребята из Anthropic. Далее будем использовать нейросети Claudе Sonnet и Claude Opus — это LLM от Anthropic.

Зачем это нужно? Такая связка позволит промтами вытаскивать инсайты из данных, создавать отчёты в PDF и строить интерактивные отчёты в HTML. Это работает на моём компьютере последние два месяца и результаты очень обнадёживающие.

Чтобы было интереснее, в качестве данных возьмём все вакансии Habr Career c описаниями.

Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. Apache Spark давно и прочно занял место одного из ключевых инструментов в арсенале инженеров и дата-сайентистов, работающих с большими данными. Его способность быстро обрабатывать огромные объёмы информации, гибкость за счёт поддержки множества языков (Python, Scala, Java, SQL) и возможность решать самые разнообразные задачи — от сложных ETL до машинного обучения и стриминга — делают его незаменимым инструментом в мире анализа данных.

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

В мире Data Science и Data Engineering ценится не только теория, но и практический опыт: умение работать с реальными данными, строить модели и доводить решения до результата. Однако получить такой опыт непросто: рабочие проекты часто закрыты NDA, а учебные кейсы не отражают сложность реальных задач.

Именно поэтому платформа Kaggle заняла особое место в индустрии. Это крупнейшее мировое сообщество специалистов по данным:

Несколько лет назад наш корпоративный слой данных жил на проприетарных технологиях. Данных было много, а основная СУБД — MPP-система Sybase IQ — долго не обновлялась. Мы регулярно сталкивались с тем, что у кластера «падали» ноды, каталог базы повреждался, порой даже терялись данные, а вендор не спешил выпускать исправления или даже признавать проблему. ETL-процессы работали через IBM DataStage, который также перестал развиваться. Все решения были закрыты, и мы не могли влиять на их улучшение. Vendor lock-in означает, что вы зависите от поставщика: если вендор не поддерживает нужные возможности, развитие замедляется, а долгоживущие ошибки остаются нерешенными. Такое положение становилось критичным.

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

В этой статье рассказываем о том, как мы перешли с проприетарных ETL-инструментов на open-source на базе dbt, какие проблемы решали по ходу внедрения, и как построили экосистему вокруг dbt для автоматизации рутинных задач.