Локальная работа в Jupyter-ноутбуках – неотъемлемая часть исследований и экспериментов нашего ML-отдела. Но из какой среды эти ноутбуки лучше запускать?
Мы пользуемся двумя вариантами: запуском из Docker-контейнера и запуском в изолированном локальном poetry-окружении.
В статье соберем минимальный сетап для работы с Jupyter-ноутбуками и ссылки на полезные ресурсы для ознакомления.
Всем привет! В этой статье поделюсь нашим опытом использования Apache Kafka на слое Stage в аналитической архитектуре. Мы поговорим о том, что такое слой Stage и зачем он нужен, почему именно Kafka стала нашим выбором, как устроен процесс ingest (приёма данных) на базе Kafka, что можно и чего делать не стоит на этом этапе, какие грабли нас ждали и как мы их преодолели, а также дам практические советы из реального опыта. Спойлер: Kafka оказалась не просто очередным модным словом, а действительно упростила нам жизнь в аналитическом проекте. Поехали!
ScyllaDB — это высокопроизводительная распределённая NoSQL-база данных, совместимая с Apache Cassandra, но в разы более быстрая за счет того, что написана на C++. Однако, несмотря на сверхбыструю скорость работы, можно ли сделать ее еще быстрее?
Привет, Хабр!
Сегодня рассмотрим, почему отставание у Kafka-консьюмеров — это не просто строчка в kafka-consumer-groups, а метрика, от которой зависит SLA вашего сервиса. Рассмотрим, как её считать без самообмана, как соорудить собственный мониторинг на Python и Go, а главное — чем именно тушить всплески lag’а: throttle, autoscale и backpressure.
Привет! Меня зовут Соня Асанина, я работаю в команде Центра технологий искусственного интеллекта Газпромбанка. В этой статье я расскажу, как тематическое моделирование и мягкая кластеризация помогают нам извлекать ценные инсайты из клиентских отзывов.
Каждый день мы получаем тысячи отзывов от клиентов. В каждом есть информация, которая помогает выявлять проблемы и дает понимание, как улучшать продукты и сервисы. Но часто очень сложно извлечь эти инсайты из огромного потока неструктурированных данных.
К примеру, мы получаем отзыв, в котором клиент недоволен кредитной картой и предлагает что-то изменить в приложении, но при этом выражает благодарность за вежливое обслуживание в отделении. К какой категории отнести отзыв? А если таких смешанных отзывов тысячи — как определить, какие продукты действительно требуют улучшения, а какие работают отлично?
Обрабатывать вручную такой поток сложно. А классические методы анализа часто не справляются с этой задачей, поскольку загоняют многогранные пользовательские отзывы в жесткие рамки одиночных категорий. Расскажу, как мы использовали для этого более гибкие инструменты — тематическое моделирование и мягкую кластеризацию.
Как я отказался от оверинжиниринга и переместился с 30 места на 7 в Enterprise RAG Challenge. И чего не хватило до 1 места.
Сейчас облась ИИ – дикий запад. Никто не знает, как правильно решать задачи, а результаты экспериментов лежат приватными под NDA. Тем ценнее, когда кто-то делится реальным опытом с разбором деталей и подводных камней. Так что делюсь с хабром своей мартовской статьей про участие в Enterprise RAG Challenge от Рината LLM под капотом
Если вы интересуетесь разработкой продуктов поверх LLM, то
Больше техническая заметка, чем статья, поэтому постараюсь изложить мысли как можно кратче.
Приходя из JS/TS мира, когда я впервые написал на Dart, самой прекрасной вещью, помимо многих было использование функций isEmpty или isNotEmpty для String, List, Map, и так далее. Это было невероятно просто и прекрасно не писать каждый раз .length == 0.
Также, очень полезным паттерном были empty/zero значения как Duration.zero, Offset.zero, и другие.
Спустя время, я нашел привычку использовать похожий принцип для работы с различными случаями, а также пришел к мысли - что если мы используем такие значения для большей части объектов, избавляясь от null (не для всех случаев, но тем не менее)? Немного поискав, нашел похожий паттерн в Go и других языках, и продолжил думать.
Хабр, привет! Меня зовут Саша Сайков, я дата-инженер в PepsiCo и старший ревьюер на курсах «Инженер данных» и «Инженер машинного обучения» в Яндекс Практикуме. Раньше работал в американском стартапе, IT-интеграторе «Синимекс» и как аутстафф-сотрудник в Сбере. В этом материале я расскажу, что, на мой взгляд, должен знать и уметь дата-инженер — и с помощью каких книг, статей и курсов всему этому можно научиться.
Мы живем в век данных и data-driven подхода. Есть продуктовые компании, где даже минимальные изменения в продукте обязаны пройти A/B-тест перед релизом (который из-за этого может и не состояться). С бумом данных и AI произошел и бум ETL (Extract, Transform, Load) инструментов. Сейчас, в 2024 году, выбор действительно впечатляет, даже если ограничиться только open source-решениями:
Всем привет, меня зовут Ольга Вишницкая, работаю главным аналитиком данных в одном из департаментов Газпромбанка. Мы постоянно следим за развитием инструментов и технологий в области анализа данных, ищем и тестируем новые решения. И в какой-то момент один из наших стримов, который отвечает за качество данных, обратил внимание на Great Expectations (GX). Это отличная библиотека для анализа качества данных: от базовой валидации до сложного профилирования и автоматической генерации документации.
Но при внедрении мы столкнулись с проблемой: GX официально не поддерживает Impala — наш основной SQL-движок для обработки данных в Hadoop. Сначала мы решили пойти обходным путем через pandas DataFrame, благо GX прекрасно с ним работает. На тестовых данных все выглядело многообещающе, однако DataFrame может обрабатывает только около 15 000 строк за раз. Данные нужно дробить на части и по результатам теста на действительно больших объемов, обработка растянулась больше чем на сутки, а часть возможностей библиотеки мы вообще потеряли.
Стало понятно — нужно возвращаться к идее использования Impala. Тем более что он обрабатывает те же объемы данных за считанные минуты. Оставалось только найти способ подружить его с GX. В документации GX ни слова о том, как запустить проверки через неподдерживаемый движок. Пришлось экспериментировать самим, и после серии проб и ошибок нашли решение. Решила им поделиться.
Как студенческое исследование по оценке репутации контрагентов с использованием открытых данных переросло в ИТ-решение представителя среднего бизнеса.
История моей ИТ-инициативы началась с университетского проекта по управлению рисками, выполненного на кафедре «Бизнес-информатика» Финансового университета. Совмещая приятное с полезным, одновременно с учебным проектом занимался оценкой благонадежности контрагентов и рисков сотрудничества с ними в реальном бизнесе.
В рамках университетского исследования изучены взаимосвязи между различными корпоративными данными, включая факторы риска, и результатами сотрудничества с контрагентами. В исследованиях выявил взаимозависимость репутационных рисков с банкротствами аффилированных лиц, политическими взглядами учредителей и судебной активностью, при этом благонадёжность определяется устойчивым развитием, участием в госзакупках и политических кампаниях.
Руководству были представлены результаты исследования взаимосвязей между репутацией и благонадёжностью контрагентов. На основе проведённого исследования было принято решение внедрить ИТ-решение по автоматизации анализа и визуализации данных с использованием открытых данных из источников, таких как ФНС, Право.ру и СКБ Контур, доступных через открытые API. Так, функционал этих инструментов начал применяться в реальном бизнесе для оценки благонадёжности контрагентов.
Хабр, привет! Сегодня вашему вниманию представляю статью об особенностях перехода компании ПИК на новую систему бизнес-аналитики. Приятного прочтения!
RAG-системы становятся все популярнее в корпоративной среде, но их эффективное внедрение и качественная оценка остается сложной задачей. Один из типичных примеров использования RAG — создание чат-ботов, отвечающих на вопросы пользователей с опорой на корпоративную базу знаний. И которые, вроде бы, заводятся и работают, и делают это даже неплохо, но всегда хочется получше.
В этой статье под мандариновое настроение будет обзор основных аспектов создания RAG-пайплайнов, рассмотрим подходы к их дальнейшему улучшению и тюнингу, обсудим метрики оценки, а также софт, который может помочь вам в этих процессах.
В ноябре в ТОП-10 в «LLM Benchmark» произошло много изменений. Также произошли некоторые изменения в том, как мы создаем продукты на основе LLM. Давайте приступим.
Статья объясняет, как StarRocks 4.0 делает запросы к JSON почти столь же быстрыми, как к нативным столбцам. FlatJSON на этапе загрузки «колоннизирует» частые поля и задействует индексы (включая ZoneMap), словарное кодирование и Global Dictionary, а также Late Materialization. В результате логовая, e‑commerce и IoT‑аналитика работает в реальном времени без тяжёлого ETL.
Представим ситуацию: мы спланировали маршрут до точки назначения, предположили, по какой дороге будет быстрее добраться, даже вспомнили, где обычно бывают пробки, чтобы их объехать. Но, неожиданно, на самом свободном участке образовался затор из‑за аварии в правом ряду. В этот момент понимаем, что лучше бы мы ехали по навигатору, и какая‑нибудь «Анфиса» предупреждала о дорожной ситуации, чтобы в определенный момент можно было изменить траекторию движения. Именно так годами чувствовали себя пользователи Spark, когда их красиво оптимизированные запросы наталкивались на суровую реальность распределенных данных.
На данный момент я прохожу 5-дневный интенсив по AI-агентам от Google и параллельно веду собственный конспект. Эта статья представляет собой перевод оригинального материала, выполненный с помощью Gemini и мной. В некоторых местах я немного упростила формулировки или обобщила идеи.
Оригинал статьи тут Agent Quality
Другие статьи:
Интенсивный курс «AI-агенты» от Google День 1
Интенсивный курс «AI-агенты» от Google День 2
Интенсивный курс «AI-агенты» от Google День 3
Apache Iceberg — табличный формат для озёр данных с поддержкой ACID, Schema Evolution, Hidden Partition и версионирования, но при больших метаданных и работе через S3 страдает планирование запросов и латентность. В связке со StarRocks мы показываем, как распределённый Job Plan, Manifest Cache, CBO с гистограммами, Data Cache и материализованные представления выводят lakehouse‑аналитику на уровень DWH: снижают накладные расходы на метаданные, ускоряют планы и выполнение, а запись обратно в Iceberg сохраняет единый источник истины. Разбираем архитектуру Iceberg, типовые узкие места и практики оптимизации на StarRocks 3.2–3.3, включая кейс WeChat/Tencent.
Эксперты Gartner дают краткие ответы на свежие вопросы клиентов о перспективных технологиях.
Фокус на принятии решений: когда инвестировать в агентный ИИ и DSLM, какие метрики измерять и как масштабировать без потери контроля.
В этой статье хочется поделиться собственной методикой оптимизации источников данных для кредитного скоринга и представить ключевые результаты реальных замеров на российском рынке.
