Мы живем в век данных и data-driven подхода. Есть продуктовые компании, где даже минимальные изменения в продукте обязаны пройти A/B-тест перед релизом (который из-за этого может и не состояться). С бумом данных и AI произошел и бум ETL (Extract, Transform, Load) инструментов. Сейчас, в 2024 году, выбор действительно впечатляет, даже если ограничиться только open source-решениями:
Привет! Это команда Яндекс Практикума. Эксперты курса «Специалист по Data Science» поделились 12 статьями, которые помогут ближе познакомиться с разведочным анализом и основами статистики, — рассказываем о них и делимся ссылками.
Еще на этапе создания модели следует проделать работу направленную на замедление ее устаревания.
Реализацию процесса работы с устареванием моделей в ML можно разделить на 4 шага.
В этой части мы с вами узнаем как создать надежную и долговечную модель, а также получить много полезной информации, которая поможет нам бороться с устареванием в будущем.
Мы пройдем полный путь создания модели и работы над замедлением ее устаревания.
Помните ситуацию, когда Gemini излишне старался быть политкорректным и отображал на всех сгенерированных изображениях только представителей небелых рас? Хотя это могло показаться забавным для многих, данный инцидент наглядно показал, что по мере роста возможностей больших языковых моделей (LLM) возрастают и их уязвимости. Это связано с тем, что сложность модели прямо пропорциональна размеру её выходного пространства, что, в свою очередь, создаёт больше возможностей для нежелательных рисков безопасности, таких как раскрытие личной информации и генерация дезинформации, предвзятости, разжигания ненависти или вредоносного контента. В случае с Gemini были выявлены серьёзные внутренние искажения, обусловленные составом обучающих данных, что и отразилось в его результатах.
Предварительная обработка текстовых данных: ключевые этапы и методы
Текстовые данные — один из самых сложных типов данных для анализа из-за их неструктурированной природы и высокой вариативности. Чтобы превратить "сырой" текст в информацию, пригодную для машинного обучения или лингвистического анализа, требуется предварительная обработка. Этот процесс включает стандартизацию, очистку и преобразование текста, что повышает качество моделей NLP (Natural Language Processing). Рассмотрим основные этапы и методы.
Всем привет! Меня зовут Константин Некрасов, я работаю дата-сайентистом в Газпромбанке. Хочу рассказать про инструмент, который серьезно упростил мою повседневную работу с данными, и поделиться им.
Если вы когда-нибудь занимались машинным обучением, то знаете — перед тем как строить модель, нужно как следует изучить свои данные. Этот этап называется EDA (Exploratory Data Analysis), или разведочный анализ данных (РАД). Он критически важен — именно здесь мы находим скрытые закономерности, выдвигаем первые гипотезы и понимаем, как лучше обработать данные для будущей модели.
Но EDA отнимает у дата-сайентистов кучу времени, которое можно потратить на что-то другое и не менее важное: придумать новые признаки, поэкспериментировать с разными алгоритмами или настроить гиперпараметры для более высокой точности модели.
Чтобы облегчить задачу, я разработал класс EDAProcessor, который автоматизирует ключевые этапы EDA: от базовой статистики и визуализации распределений до углубленного анализа корреляций, выбросов и временных зависимостей. Результаты анализа сохраняются в виде наглядных графиков и подробной excel-таблицы, где на разных листах представлены все важные статистические показатели и закономерности в данных.
Сразу оговорюсь — я не изобретаю здесь новых статистических методов, не претендую на научную новизну в области математической статистики, а мое решение не универсально. Каждый набор данных уникален, и полностью автоматизировать его анализ невозможно — всегда нужен опытный взгляд аналитика. Но базовые, наиболее часто используемые методы EDA этот инструмент берет на себя, ускоряя начальный этап работы с данными. Я попытался собрать в скрипт наиболее общие концепции EDA, которые используются в подавляющем большинстве случаев на первоначальной стадии разработки ML-модели.
Сам скрипт вот тут, а под катом я расскажу, как он работает и что делает.
Процесс Retrieval-Augmented Generation (RAG) представляет собой довольно сложную систему, состоящую из множества компонентов. Вопрос о том, как определить существующие методы RAG и их оптимальные варианты реализации этапов обработки информации для выявления лучших практик. В настоящий момент остается наиболее актуальным. В этой статье я хочу поделиться своим опытом относительно реализации подходов и практик в области RAG систем, который реализует систематический подход к решению этой проблемы.
Всем привет, меня зовут Евгений Мунин. Я Senior ML Engineer в Ad Tech в платформе ставок для рекламы. В этой статье мы познакомимся с Apache Kafka. Мы напишем демо пример Kafka Consumer'а на Python и запустим его в облачном сервисе Confluent Cloud.
Оркестрация процессов в Apache Airflow — мощный инструмент для управления данными. Но как внедрить его так, чтобы процессы стали прозрачными, гибкими и удобными для команд? Как организовать ETL-пайплайны, чтобы они легко масштабировались и адаптировались под нужды аналитиков, ML-инженеров и других специалистов?
Меня зовут Любовь Марисева, я инженер дата-платформы в Циан. Мы разрабатываем десятки ETL-процессов, обеспечиваем данными разные команды и постоянно ищем способы сделать работу с Airflow эффективнее. В этой статье я расскажу, как мы решили ключевые проблемы, сделали расчёты более управляемыми и упростили взаимодействие между командами.
Если вы только начинаете работать с Airflow или хотите улучшить свои подходы, присоединяйтесь! Эта статья поможет взглянуть на оркестрацию процессов под новым углом.
В последнее время разработка и развертывание больших языковых моделей (LLM) стали ключевыми в формировании интеллектуальных приложений в различных областях. Но реализация этого потенциала требует строгого и систематического процесса оценки. Прежде чем углубляться в метрики и вызовы, связанные с оценкой LLM-систем, стоит задуматься: не сводится ли ваш процесс оценки к бесконечному циклу запуска LLM-приложений на наборе промптов, ручному анализу выходных данных и субъективной оценке их качества? Если да, то пора осознать, что оценка — это не разовая процедура, а многоэтапный итеративный процесс, оказывающий значительное влияние на производительность и жизненный цикл вашей LLM-системы. С развитием LLMOps (расширения MLOps, адаптированного для больших языковых моделей) интеграция процессов CI/CE/CD (непрерывная интеграция, непрерывная оценка и непрерывное развертывание) становится неотъемлемой частью управления жизненным циклом LLM-приложений.
Итеративный характер оценки включает в себя несколько ключевых компонентов. Во-первых, необходимо постоянно обновлять и улучшать тестовый датасет. Во-вторых, важно выбирать и внедрять метрики оценки, наиболее подходящие для конкретного сценария использования. Наконец, надежная инфраструктура оценки позволяет проводить тестирование в реальном времени на протяжении всего жизненного цикла LLM-приложения. Крайне важно признать значимость оценки как непрерывного и динамического процесса. Это компас, помогающий разработчикам и исследователям совершенствовать и оптимизировать LLM для повышения производительности и практического применения.
Приветствуем вас на заключительном этапе в цикле статей о Greenplum. Ранее мы уже обсудили то, как выглядит архитектура системы. Посмотрели «под капот», подробнее обсудили виды хостов и их предназначение, узнали, как обрабатываются запросы пользователей.
Во второй статье погрузились в то, какие виды таблиц бывают, что такое дистрибьюция и партиционирование, как можно начать оптимизировать работу с таблицами ещё на этапе их создания.
Освежить память о содержании предыдущих статей можно здесь и здесь.
В данной статье мы совместно с @omoskvinрасскажем о том, что влияет на оптимальность выполнения запросов, как отслеживать различные проблемы и, конечно же, как с ними справляться.
Добрый день. Меня зовут Иван Клименко, я архитектор в департаменте поддержки продаж компании Arenadata. Основное направление моей работы — продукт Arenadata Streaming (ADS), масштабируемая и отказоустойчивая система для потоковой обработки данных в режиме реального времени, предназначенная для корпоративного использования и построенная на базе Apache Kafka и Apache NiFi.
Сегодня я хотел бы обсудить концепцию потокового программирования, уделить внимание FlowFile и рассмотреть подходы к разработке потоков обработки данных в NiFi. Эта статья в первую очередь адресована новичкам, интересующимся NiFi, а от опытных разработчиков я буду рад услышать дополнения и конструктивную критику.
Перевод и суммаризация текстов – это две задачи, которые на первый взгляд кажутся совершенно разными. Перевод требует точного передачи исходного содержания на другой язык, сохраняя все детали и нюансы. Суммаризация же предполагает сокращение текста до его основных идей, часто убирая второстепенные детали.
Однако при ближайшем рассмотрении эти задачи имеют много общего...
В 2024 году популярными словами и постоянной темой для обсуждения в IT были большие языковые модели (LLM), обработка естественного языка (NLP), искусственный интеллект и создание ценностей. Однако вкатиться в эту экосистему без подготовки может быть довольно сложно. Давайте начнём с того, что рассмотрим понятие генерации с дополненной выборкой (Retrieval Augmented Generation, RAG), чтобы лучше понять эту технологию и возможность её использования в наших цифровых продуктах.
Привет, Хабр! На связи Александр Бобряков, техлид команды МТС Аналитики. Это мой финальный пост про Apache Flink. В предыдущих частях мы рассматривали процессы сериализации данных, написали кастомный сериализатор, а также покрыли его тестами. В них проверялась поддержка эволюции схемы состояния. Для этого мы реализовали много удобных абстракций, связанных с перезагрузкой Flink MiniCluster, компиляцией тестовых java-классов, использованием их в classpath кластера и так далее.
В этом материале мы применим разработанный сериализатор JacksonStateSerializer в бою, а также автоматизируем проверку эволюции схемы для всех наших классов, участвующих в сериализации.
Весь разбираемый исходный код можно найти в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии. Данная статья соответствует релизной ветке с названием release/11_JacksonEvolvingState. По мере выхода новых материалов на Хабре ссылки на них будут появляться ниже.
Список моих постов про Flink:
Меня зовут Вера Романцова, я работаю в 2ГИС в команде компьютерного зрения. Мы создаём ML-модели и сервисы, которые автоматизируют работу с картами и данными.
Но перед тем, как обучить модель и выкатить сервис, есть ещё много работы по сбору датасетов и разработке моделей. И обычно все эти задачи выполняли ML-инженеры. В один из моментов моя будущая команда пришла к выводу, что для эффективных процессов разметки, сбора и валидации данных нужна отдельная роль — менеджер данных. Этим первопроходцем в нашей компании стала я.
В этой статье я расскажу:
🌚 Кто такой менеджер данных и чем он занимается.
🦾 Как эта роль помогла нашей команде ML-инженеров.
🔜 Когда такой специалист может понадобиться вам.
🔎 Как найти подходящего кандидата на эту позицию.
В этой статье я поделюсь своим опытом разработки юнит-тестов внутри базы данных под управлением PostgreSQL. А также расскажу, зачем мне потребовалось доработать расширение pgTap.
pgTap – это расширение PostgreSQL для разработки юнит-тестов. Сами тесты, как, собственно, и pgTap, пишутся на plpgSQL, что означает низкий порог вхождения для разработчиков PG.
Уверен, что читатель, по крайней мере, знаком с техникой разработки через тесты. Поэтому не буду пускаться в описание теории юнит-тестирования. Благо литературы на эту тему более чем достаточно. Тем не менее, чтобы быть понятым, приведу некоторые детали ниже.
В этой статье я научу вас, как оценивать LLM-чат-ботов, чтобы понять, достаточно ли они убедительны, чтобы сойти за реальных людей. Но что еще важнее, вы сможете использовать результаты этой оценки, чтобы понять, как улучшить своего LLM-чат-бота, например, изменив промпт или саму LLM-модель.
В этой статье вы узнаете:
* Разницу между оценкой LLM-чат-ботов и стандартной оценкой LLM
* Различные подходы к оценке LLM-диалогов
* Различные типы метрик для оценки LLM-чат-ботов
* Как реализовать оценку LLM-диалогов в коде с использованием DeepEval
Оценка LLM-систем вручную — это утомительное, времязатратное и порой раздражающее занятие. Поэтому, если вам приходилось многократно прогонять набор промптов, чтобы вручную проверять каждый вывод LLM, вас обрадует, что эта статья научит вас всему необходимому для правильной оценки LLM и обеспечения долгосрочной эффективности вас и вашего приложения на основе LLM.
Оценка LLM относится к процессу обеспечения соответствия выходных данных LLM человеческим ожиданиям, которые могут варьироваться от этических и безопасных соображений до более практических критериев, таких как правильность и релевантность выходных данных LLM. С инженерной точки зрения эти выходные данные LLM часто можно найти в форме тестовых кейсов, в то время как критерии оценки формализуются в виде метрик оценки LLM.
На повестке дня:
В чем разница между оценкой LLM и оценкой системы LLM, а также их преимущества
Офлайн-оценки, что такое бенчмарки системы LLM, как создавать наборы данных для оценки и выбирать правильные метрики оценки LLM, а также распространенные ошибки
Оценки в реальном времени и их польза для улучшения наборов данных для офлайн-оценок
Реальные примеры использования систем LLM и как их оценивать, включая chatbotQA и Text-SQL
Greengage Database — наш форк Greenplum Database. Основная идея — оставить исходный код открытым и продолжить разработку и совершенствование базы данных. Мы собираемся перенести Greengage Database на более новую версию Postgres, предоставив более богатый набор функций всем пользователям сообщества и нашим клиентам.
Но эта задача сложнее, чем может показаться. Ранее для реализации функций массивно-параллельных вычислений Greenplum Database основная функциональность Postgres была существенно переработана. Таким образом, обновление версии Postgres создавало огромные сложности. Например, переход с Postgres 9 на Postgres 12 потребовал огромных усилий — между мажорными релизами было почти 5 лет разработки.
Имея это в виду, мы начали масштабный рефакторинг ядра Greengage Database. Мы собираемся разделить ядро Postgres и специфичные функции Greengage Database, используя стандартные существующие средства Postgres для расширений.
