Data Engineering *

В этой статье я поделюсь своим опытом разработки юнит-тестов внутри базы данных под управлением 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 для расширений.

Всем привет, меня зовут Ольга Вишницкая, работаю главным аналитиком данных в одном из департаментов Газпромбанка. Мы постоянно следим за развитием инструментов и технологий в области анализа данных, ищем и тестируем новые решения. И в какой-то момент один из наших стримов, который отвечает за качество данных, обратил внимание на Great Expectations (GX). Это отличная библиотека для анализа качества данных: от базовой валидации до сложного профилирования и автоматической генерации документации. 

Но при внедрении мы столкнулись с проблемой: GX официально не поддерживает Impala — наш основной SQL-движок для обработки данных в Hadoop. Сначала мы решили пойти обходным путем через pandas DataFrame, благо GX прекрасно с ним работает. На тестовых данных все выглядело многообещающе, однако DataFrame может обрабатывает только около 15 000 строк за раз. Данные нужно дробить на части и по результатам теста на действительно больших объемов, обработка растянулась больше чем на сутки, а часть возможностей библиотеки мы вообще потеряли.

Стало понятно — нужно возвращаться к идее использования Impala. Тем более что он обрабатывает те же объемы данных за считанные минуты. Оставалось только найти способ подружить его с GX. В документации GX ни слова о том, как запустить проверки через неподдерживаемый движок. Пришлось экспериментировать самим, и после серии проб и ошибок нашли решение. Решила им поделиться.

Рак кожи, в частности меланома, – одна из самых опасных онкологических болезней. Ранняя диагностика значительно повышает шансы на успешное лечение. Но несмотря на это, большинство приложений, которые я нашел в PlayStore для анализа кожи оказались неожиданно громоздкими и дорогими. Казалось бы, что может быть проще формулы — нажми на кнопку, получишь результат? Вот и я так думал в поисках нужного приложения. Но, каждый раз приходилось заполнять профиль и анкеты только для того, чтобы оказаться перед экраном с реквизитами для оплаты. В итоге это вдохновило меня на создание бесплатного и простого в использовании приложения.

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

История моей ИТ-инициативы началась с университетского проекта по управлению рисками, выполненного на кафедре «Бизнес-информатика» Финансового университета. Совмещая приятное с полезным, одновременно с учебным проектом занимался оценкой благонадежности контрагентов и рисков сотрудничества с ними в реальном бизнесе.

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

Руководству были представлены результаты исследования взаимосвязей между репутацией и благонадёжностью контрагентов. На основе проведённого исследования было принято решение внедрить ИТ-решение по автоматизации анализа и визуализации данных с использованием открытых данных из источников, таких как ФНС, Право.ру и СКБ Контур, доступных через открытые API. Так, функционал этих инструментов начал применяться в реальном бизнесе для оценки благонадёжности контрагентов.

Привет, Хабр! Меня зовут Гурциев Ричард, я магистрант 1-го курса AI Talent Hub. За первый семестр я с головой погрузился в крутой проект, цель которого — сделать этап трудоустройства проще и удобнее как для работодателей, так и для кандидатов. В этой статье я хочу поделиться своим опытом работы над проектом Advisor🚀

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

Привет! Я работаю в аналитике и с данными уже 13+ лет. Про data-driven от заказчиков-пользователей трудов моей работы слышу тоже, почти 13+ лет. И очень разные интерпретации этого явления встречал. Думаю, что я один из тех, чья трудовая деятельность ближе всего к data-driven. Хочу рассказать о том, какой data-driven = хорошо, а какой != хорошо.

Эта статья может быть полезна как управленцам, так и аналитикам. Давайте говорить на «одном языке».

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

В этой статье вы научитесь всему, что нужно знать о метриках оценки LLM, включая примеры кода. Мы рассмотрим следующие вопросы:

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

Различные методы вычисления метрик оценки LLM и почему подход LLM-as-a-judge («LLM как судья») является наиболее эффективным.

Как реализовать и выбрать подходящий набор метрик оценки LLM с использованием библиотеки DeepEval (GitHub: DeepEval).

Хабр, привет! Сегодня вашему вниманию представляю статью об особенностях перехода компании ПИК на новую систему бизнес-аналитики. Приятного прочтения!

Привет, Хабр! Меня зовут Станислав Габдулгазиев, и я архитектор департамента поддержки продаж Arenadata. В этом материале поделюсь впечатлениями от использования Kyuubi — инструмента, который значительно упрощает работу пользователей с SQL, а также затрону вопросы его сравнения с другими решениями для обработки больших данных.

Kyuubi — это сервис, предоставляющий механизмы для распределённого выполнения SQL-запросов поверх различных вычислительных движков, таких как Apache Spark, Hive, Flink и Impala. Он часть дистрибутива Arenadata Hadoop (ADH), который включает эти движки для обработки и анализа данных.

Привет, Хабр! На связи Александр Бобряков, техлид команды МТС Аналитика. Это мой одиннадцатый пост про Apache Flink. В предыдущей части мы рассмотрели сериализацию данных во Flink, написали сериализатор, поддерживающий эволюцию схемы для Flink-состояния в операторе на основе Jackson.

В этой части мы научимся писать тесты на эволюцию схемы состояния при использовании своего сериализатора.

Весь разбираемый исходный код можно найти в репозитории AlexanderBobryakov/flink-spring. В master-ветке представлен итоговый проект по всей серии. Этот материал соответствует релизной ветке с названием release/10_test_JacksonStateSerializer.

В статье расскажу, как настроить мониторинг Apache NiFi и алерты при переполнении очереди по достижении 8000 FlowFiles.

Зачем вам читать эту статью? Переполнение очереди FlowFiles в Apache NiFi может привести к замедлению или остановке обработки данных, мониторинг позволит своевременно среагировать на проблемы с производительностью и выявить узкие места.

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

Генерация с дополненной выборкой (RAG) — это метод, который соединяет внешние источники данных для улучшения вывода больших языковых моделей (LLM). Этот метод идеально подходит для LLM для доступа к частным или специфичным для предметной области данным и решения проблем, связанных с галлюцинациями. Поэтому RAG широко используется для поддержки многих приложений GenAI, таких как чат-боты AI и системы рекомендаций.

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

Например, вопрос «Какое имя было дано сыну человека, который победил узурпатора Аллектуса?»

Автоматическая генерация презентаций из документов представляет собой сложную задачу, требующую баланса между качеством контента, визуальным дизайном и структурной связностью. Существующие методы в основном сосредоточены на улучшении и оценке качества контента изолированно, часто упуская из виду визуальный дизайн и структурную связность, что ограничивает их практическую применимость. Для решения этих ограничений мы предлагаем PPTAgent, который комплексно улучшает генерацию презентаций за счет двухэтапного подхода, основанного на редактировании, вдохновленного рабочими процессами человека. PPTAgent сначала анализирует эталонные презентации, чтобы понять их структурные шаблоны и схемы контента, затем разрабатывает контуры и генерирует слайды с помощью кодовых действий для обеспечения согласованности и выравнивания. Для комплексной оценки качества сгенерированных презентаций мы дополнительно представляем PPTEval, структуру оценки, которая оценивает презентации по трем измерениям: Содержание, Дизайн и Связность. Эксперименты показывают, что PPTAgent значительно превосходит традиционные методы автоматической генерации презентаций по всем трем измерениям. Код и данные доступны по адресу https://github.com/icip-cas/PPTAgent.

GraphRAG предоставляет «граф знаний» LLM. В отличие от текстовых документов, эти структуры данных четко отображают взаимосвязи между объектами.

Всем привет, на связи команда Data Science Авито. В этой статье рассказываем, какие команды есть в нашем департаменте, на конкретных примерах объясняем, над чем работаем и как развиваем бизнес. Также мы подготовили для вас ссылки на стажировки и образовательные программы. 

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