Big Data *

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

В этой статье хочу поделиться нашим опытом интеграции с Kafka.

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

В какой-то момент в нашем КХД также появилась необходимость интеграции с Kafka.

При разработке первой интеграции мы пошли традиционным путем и использовали Kafka Connect для Confluent 6.0.1. Сообщения, читаемые коннектором, перекладывались в Hadoop. Далее в PySpark выполнялся парсинг нужных данных, и полученные пачки выгружались в Oracle Exadata.

Но на этапе опытно-промышленной эксплуатации у нас возникли проблемы с производительностью из-за большого объема читаемых данных: ~100-110 млн сообщений в час (поток со звонками абонентов). Также было требование от бизнеса - данные в конечной витрине должны появляться с задержкой не более часа. Оптимизация интеграции затянулась еще на пару месяцев.

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

Тем временем, перед нами встала задача разработки еще нескольких интеграций с Kafka.

Было очевидно, что требуется какое-то решение, которое не только ускоряло бы внедрение, исключая рутинную разработку, но и позволяло реализовать стандартную для таких интеграций батчевую выгрузку считанных сообщений в разные БД (Oracle/Hive/ClickHouse и в перспективе в Greenplum). И кроме того, умело выполнять предварительную обработку данных на лету (парсинг и трансформацию значений заданных атрибутов).

Привет! Меня зовут Александр Егоров, я MLOps-инженер в Альфа-Банке, куда попал через проект компании KTS.

За свою карьеру я построил четыре ML-платформы (одна из которых сейчас в Росреестре) и развиваю с командой пятую. Параллельно учусь в ИТМО по направлению «Безопасность искусственного интеллекта».

В этой статье я немного покритикую Airflow и поделюсь нашей историей миграции на связку Argo Workflows и Argo CD. Spoiler alert: технические подробности и результаты в наличии.

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

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

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

Статья подробно описывает архитектуру трансформера, включая блоки внимания (Attention Blocks), где векторы взаимодействуют друг с другом для обновления значений на основе контекста, и многослойные распознаватели (Перцептроны) (Feed-Forward Layers), где векторы обрабатываются параллельно. Объясняется, почему глубокие нейронные сети называются «глубокими» — из-за множества чередующихся слоёв этих операций.

Материал включает практические примеры на основе GPT-3 с её 175 миллиардами параметров, распределённых по почти 28,000 матрицам. Авторы тщательно отслеживают количество параметров на каждом этапе, помогая читателю понять масштаб современных языковых моделей.

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

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

Завершается статья описанием процесса "вложений" и функции "softmax", которая преобразует выходные данные модели в распределение вероятностей для предсказания следующего токена. Особое внимание уделяется понятию «температуры», которое контролирует степень случайности при генерации текста.

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

Итак, мы плавно подошли к тому, что нужно каким-то образом валидировать ответы LLM. Давайте разберёмся, как это делать.   

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

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

Например — технические схемы. Представьте: целые шкафы с папками, где вперемешку свежие CAD-чертежи и сканы пожелтевших листов А3 с подписями от руки: «Смотри сюда», «замени резистор». Чтобы собрать спецификацию и посчитать стоимость, инженеру приходилось садиться с карандашом и Excel — и часами переписывать резисторы, транзисторы, конденсаторы, их номиналы и количество. Ошибся в одной букве или не заметил мелкий элемент — и вся цепочка снабжения поехала.

В какой-то момент мы, как разработчики, задали себе вопрос: «А почему в 2025 году до сих пор человек должен глазами считать резисторы на сканах, если есть компьютерное зрение и OCR?» Так и стартовал проект: сделать систему, которая за полминуты превратит «кривой скан схемы из прошлого века» в таблицу компонентов с готовой сметой.

Привет! Эта статья посвящена синтетическим данным и тому, как сбор данных и их разметка изменились навсегда. Поговорим про мультимодальную синтетику (аудио и изображения), генераторы, валидаторы, примеры классных генераций, датасеты, роль LLMок в этих процессах и трансформацию привычных пайпланов в концепцию SynthOps, которая требует других подходов по работе с данными.

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

Обо всем это и хочется рассказать.

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

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

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

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

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

В этой статье эксперты лаборатории искусственного интеллекта российской ИТ-компании «Криптонит» рассматривают самые актуальные фреймворки для машинного обучения, анализируют причины их популярности, ключевые области применения и тенденции развития. Аналитика строится как на собственном опыте, так и на данных специализированных источников, таких как GeeksforGeeks, Upgrad, Octal Software и других, чтобы предоставить аргументированный и непредвзятый обзор.

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

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

Привет, Хабр! Меня зовут Игорь Рябков. В этой статье расскажу, как мы собрали датасет для оценки Visual Language Models на русском языке и с учетом нашего культурного контекста. Этот проект появился в рамках исследовательской работы в Инженерно-математической школе НИУ ВШЭ и VK под руководством Александра Рогачева (AI VK). Опыт показал — собрать подобный датасет под свои задачи можно и без огромных ресурсов, если подойти к делу системно.

Современные Visual Language Models — мультимодальные братья больших языковых моделей, способные одновременно читать тексты и анализировать изображения. Казалось бы, такие модели открывают множество новых возможностей и для российских пользователей. Однако большинство известных датасетов для VLM — MMBench, MMMU, MME — ориентированы на английский язык и западную аудиторию. Локальные решения вроде K-Viscuit (Корея) и MERA (Россия) только начинают появляться, но их пока недостаточно. Поэтому мы решили собрать датасет, который бы учитывал специфику русского языка и мог покрыть актуальные задачи для пользователей.

Встречайте MARKER: Multimodal Assessment of Russian Knowledge in Educational Realms.

В 2019 году центральная BI-команда нашей компании столкнулась с типичной задачей: как небольшой командой разработчиков обеспечить качественную аналитику для тысяч сотрудников в условиях быстро растущего бизнеса и высокой самостоятельности подразделений?

Мы сделали ставку на модель self-service BI: инструмент передали бизнес-пользователям, чтобы они могли сами строить отчёты. Идея «демократизации данных» поначалу казалась удачной. Но без чётких правил, стандартов и контроля всё быстро превратилось в BI-хаос: тысячи разрозненных отчётов, низкая производительность, противоречивые метрики и перегруженная инфраструктура на Premium P3. Пользователи жаловались, доверие к BI падало, а управлять этим потоком становилось всё сложнее.

В этой статье мы — Ринат Хабибрахманов, руководитель практики BI в Лемана Тех, и Лариса Фернандес, ведущий разработчик аналитических систем, — делимся опытом нашей команды. Расскажем, как мы шаг за шагом внедряли процесс ревью Power BI-отчётов, чтобы вернуть контроль, улучшить качество аналитики и восстановить доверие пользователей к BI-системе.

Ключевым шагом стало внедрение процесса ревью. Ниже подробно разберём, зачем он понадобился, какие цели мы ставили и как его организовали.

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

Искусственный интеллект, в частности GPT-модели, позволяет анализировать такие данные быстро и без громоздких инструментов. Достаточно выгрузить подписчиков и задать ИИ задачу: выделить ключевые интересы и сегменты.

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

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

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

Ребята, вы когда-нибудь сталкивались с тем, что ваш шикарный AI-пайплайн для обработки документов спотыкается на самом простом — на чтении текста с картинки? OCR выдает абракадабру, цифры перепутаны, а дальше по цепочке летит вся ваша безупречная логика. Знакомо? У нас была точно такая же боль.

Привет, Хабр! Одной из важных функций-модификаторов в DAX является REMOVEFILTERS, он позволяет, например, убрать фильтр для расчета знаменателя в доле. Однако логика REMOVEFILTERS для столбцов может выглядеть неочевидной, например, REMOVEFILTERS только для одного поля, по которому есть условие в FILTER, не влияет на результат DAX запроса. Так, REMOVEFILTERS(customer[customer_id]) не влияет на FILTER в SUMMARIZECOLUMNS вида FILTER(customer, customer[customer_id] > 2) и для сброса фильтра нужен REMOVEFILTERS(customer) по всей таблице. В связи с этим удобно представить принципы работы REMOVEFILTERS более формально, например, в виде ER диаграммы с подписанными связями. Для построения ER диаграммы был выбран Mermaid и генерация кода диаграммы реализована на C#. Интересующимся особенностями REMOVEFILTERS — добро пожаловать под кат :)