Data Engineering *

Централизованная аналитика — это фундамент эффективного принятия решений в компании. Чтобы данные действительно работали на бизнес, они должны пройти путь от извлечения до представления в понятной форме. Один из наиболее известных и проверенных временем подходов — архитектура, построенная на четырех ключевых модулях: интеграция, обработка, представление и управление. В этой статье мы познакомимся с каждым из них, а также рассмотрим один из рабочих вариантов реализации (DQ, BI, метаданные и др.).

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

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

Привет, Хабр! На связи команда данных «МосТрансПроекта». Недавно мы рассказывали про бот «Информатум», в котором хранятся служебные презентации. При разработке системы мы уделили особое внимание защите чувствительной информации. Поэтому доступ к материалам предоставляется сотрудникам только после авторизации и подтверждения их данных. Но что, если появится еще несколько ботов? Неужели сотрудникам придется каждый раз проходить проверку для доступа к новым сервисам, а администраторам тратить время на верификацию? Для решения этой задачи мы разработали универсальное и экономящее время решение, о котором расскажем в данной статье.

Приходите на бесплатный двухдневный митап 21 и 22 мая в Алматы от спикеров QIC digital hub, Kolesa Group, Yandex и DataArt! Эксперты рынка поделятся своими знаниями и кейсами в работе с продуктами и данными.

Я убеждён в том, что аналитикам данных критически-важно иметь доступ без боли, искажений и рисков к наиболее детализированным данным проекта для исполнения своих обязанностей..
Нет данных - нет мультиков аналитики. Работа только с агрегированными и преобразованными по непрозрачной логике данными приводит к ошибкам и отсутствию доверия от бизнеса.
Статья может быть полезна к изучению при принятии решений о развитии аналитики с 0 в проекте.

К сожалению, вопросу получения данных часто не уделяется хоть какое-то внимание.
Бизнесу интересно не получение данных, а инсайты и рекомендации. Принято отдавать этот вопрос на откуп аналитикам и взаимодействию аналитиков и IT. Только у аналитиков редко есть опыт и понимание лучших практик по работе с данными и для IT задача использования данных аналитиками может быть чем-то чужеродным.

Тем не менее, как-то они договариваются. Не сталкивался с примерами, когда совсем не договорились и никакой аналитики нет.
Сталкивался с разными вариантами урона от реализации.

Статья посвящена реализации join-операций в системах потоковой обработки данных на базе Apache Flink. Рассматриваются основные подходы к объединению потоков в реальном времени, включая inner join, а также паттерны дедупликации. Уделено внимание использованиюKeyedCoProcessFunction для построения отказоустойчивых и масштабируемых join-пайплайнов. Работа ориентирована на инженеров, строящих real-time витрины и сложные трансформации на Flink в продакшене.

Привет! Меня зовут Кирилл Львов, я fullstack-разработчик в компании СберАналитика. В этой статье хочу рассказать про мощный инструмент трансформации данных — DBT (Data Build Tool).

Сегодня любой средний и крупный бизнес хранит множество данных в разрозненных источниках (CRM, ERP, HRM, базы данных, файловые хранилища и т.д.). Каждая из этих систем самодостаточна и закрывает определённую боль бизнеса, но собрав данные из таких источников и стандартизировав их, нам открывается возможность анализировать данные, строить модели машинного обучения и принимать на основе этих данных управленческие решения. Для того чтобы реализовать такой подход строятся ELT (или ETL) процессы. ELT (Extract, Load, Transform) — это процесс, состоящий из трех этапов:

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

Когда владельцы бизнеса просят команду IT «добавить аналитику» в продукт, часто это заканчивается болью — и для разработчиков и для самого бизнеса. За последние несколько лет я участвовал в построении аналитических решений более чем в 10 компаниях — от стартапов до крупных корпораций. Почти во всех компаниях среднего уровня, только начинающих выстраивать BI-аналитику, я видел одну и ту же ошибку: попытку встроить аналитику в архитектуру приложения как обычный модуль. Это не работает, и вот почему.

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

Привет! Я Сергей Кляхандлер, senior DS-инженер в команде LLM Авито. 

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

Статья будет полезна DS-инженерам, которые работают с мультимодальными LLM-моделями.

LLM-агенты — отстой. Я провёл последнюю неделю, разрабатывая LLM-агента с возможностью веб-краулинга, используя популярный Python-фреймворк, чтобы собирать информацию о потенциальных лидах из интернета. Результат оказался полным разочарованием.

Агент оказался медленным, нестабильным и с огромным числом багов (звучит знакомо? Передадим привет OpenAI!). Он постоянно делал ненужные вызовы функций, а иногда намертво застревал в бесконечных петлях "рассуждений", которые не имели никакого смысла. В итоге я на это забил и заменил его простым web-scraping скриптом, на написание кода которого у меня ушло 30 минут.

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

Цель этой статьи — **не** создавать очередной туториал по сборке чат-бота с OpenAI. Таких материалов уже достаточно.

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

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

---

## Зачем?

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

Такой ассистент может использоваться в разных сценариях:

- **Быстрые ответы на частые вопросы**

- **Поиск по документации как в Algolia**

- **Помощь пользователям в навигации по документации**

- **Анализ пользовательских вопросов и хранение их для анализа**

---

## Краткое содержание

Ниже приведены три основные части решения:

1. Чтение файлов документации

2. Индексация документации (разбиение, перекрытие, эмбеддинги)

3. Поиск по документации и интеграция с чат-ботом

---

## 1. Чтение файлов документации

Вместо того чтобы жестко прописывать текст, вы можете просканировать папку и найти все `.md` файлы с помощью `glob`.

Подбор персонала — это поиск иголки в стоге сена, с одной оговоркой: иголка должна хотеть работать именно у вас. Когда на входе — сотни резюме с hh.ru, а на выходе нужно выбрать топ-5 кандидатов, без автоматизации не обойтись. Но как научить алгоритм отличать будущего топ-менеджера от человека, который в графе «Опыт работы» указал «10 лет в Minecraft»?

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

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

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

> Данная статья -- результат моего выступления на конференции AMITA. И первый шаг в создании диссертации. Тема еще требует проработки, но кажется мне перспективной. Поэтому этой статьей я хочу призвать силу хабрасообщества -- для критики, обсуждения или поддержки (как пойдет).

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

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

В этой статье расскажу, как мы в команде аналитиков начали использовать большие языковые модели (LLM) в повседневных рабочих инструментах. Всё построено на R, и покажу на практике, как можно внедрить такие фичи у себя — без платных подписок, без OpenAI и без строчки кода на Python.

TL;DR: KIP‑1150 (Diskless Topics) предлагает Kafka писать сообщения сразу в облачное хранилище (S3 и аналоги), минуя диски брокеров. Это сильно экономит деньги и упрощает масштабирование в облаке, но увеличивает задержки и делает Kafka зависимой от облачных сервисов. Отлично для дешёвых, «толстых» потоков логов, но плохо подходит для real‑time систем с миллисекундными требованиями.

Привет! Меня зовут Руслан Гилязев, я работаю в подразделении DS SWAT в Авито, руковожу командой платформы Item2param. В этой статье рассказываю, с помощью каких технологий мы решаем задачу классификации объявлений и почему это важно для бизнеса. Материал будет полезен DS-инженерам любого грейда и backend-инженерам, которые интересуются темой data science. 

Привет.

Представьте: вы запилили нейросеть, которая определяет котиков на фото с точностью 99.9% (оставшиеся 0.1% — это когда хомяк притворяется котом). Воодушевлённый результатом, бежите к руководству — а там оказывается, что: