Big Data *

Начало всех начальных начал 

Добрый день, уважаемые хабропоселенцы ;)) Сегодня мы будем говорить, снова о хакатонах и разработке RAG-моделей, вернее моделей с RAG-подходами и наших попытках выйти за рамки простого векторного поиска. Не так давно мы участвовали на всероссийском хакатоне “Альфа-Будущее”, организованным Альфа-Банком и посвящённому настройке RAG для вопросно-ответных систем. 

Нам необходимо было создать интеллектуальный pipeline RAG-системы, которая по пользовательскому запросу находит релевантные фрагменты в корпусе данных. Вообще, было на выбор две задачи, вторая звучала как “Разработка copilot приложения для клиентов микробизнеса”, но нам ближе оказалась вторая задача. И, конечно же, мы “запилили” своё “модное” решение, о котором вам спешим рассказать в этой статье. Мы проиллюстрируем, как выстраивали архитектуру, какие модели тестировали, на чём остановились и почему, именно такой подход оказался для нас наиболее удачным. Покажем, как работает весь пайплайн — от чанкования документов до гибридного поиска и поделимся результатами бенчмарков и планами развития системы в дальнейшем. Всех заинтересованных лиц приглашаю по традиции под кат ;))

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

Когда в команде спорят о фичах, производительности или надёжности, я редко слышу принципиально разные аргументы. Чаще это разные формы одного и того же:

— Мне кажется, пользователям понравится.
— Я уверен, что система выдержит.
— Ну сейчас же всё работает.

Проблема в том, что «кажется» и «уверен» плохо масштабируются. А числа — масштабируются отлично.

NVIDIA выпустила отчет о методе QAD, который позволяет квантовать LLM в 4 бита без потери качества на сложных задачах (математика, код). Разбираем, почему привычный QAT «ломает» модели после RLHF, как дистилляция через KL-дивергенцию решает эту проблему и почему метод работает даже на рандомных данных. Личный опыт попыток уместить 49B модель в железо и анализ нового подхода.

Привет, Хабр! Меня зовут Лев. Я работаю в поиске Ozon. Сегодня я буду рассказывать про одну из составляющих поиска, а именно про ранжирование.

В этой статье расскажу:
- Что такое ранжирование и факторы ранжирования.
- Как работает поисковое ранжирование в Ozon.
- Как мы работаем с факторами ранжирования.

Я буду переходить от простых примеров к сложным — от орехов и белок к товарам и сервисам.

Всем привет! Меня зовут Антон Пилькевич, я более четырёх лет занимаюсь ранжированием и текстовой релевантностью в поиске Ozon. И вот настал момент, когда у меня появилось время поделиться своими мыслями. В этой статье вас ждёт увлекательное путешествие в ML-мир текстового поиска Ozon, а также знакомство с флорой и фауной существующих решений в этой области! 

Привет! Меня зовут Паша, я маркетинговый аналитик в Купере. В этой статье речь пойдет о проверке качества «каузальных» моделей. На примере такой модели, как Double Machine Learning разберемся, откуда вообще берутся «каузальные» предсказания, как понять, что им можно доверять, и что делать с фундаментальной проблемой «скрытых конфаундеров».

Мы часто воспринимаем дашборды как красивые визуализации – набор графиков, цифр и диаграмм. Но за этой «картинкой» скрывается огромный объём работы: настройка сбора данных, очистка, согласование метрик, построение архитектуры хранения и только затем — визуальная подача. Аналитик AkademiaDev Сергей Тищенко подробно объясняет, из чего на самом деле состоит путь от сырых данных до управленческих инсайтов.

Как известно, компания OpenAI, создавшая ChatGPT, находится на переднем крае развития ИИ и многим небезинтересно, какие технологии и решения работают "под капотом" этой популярной компании. Сотрудник технического отдела OpenAI, Бохан Чжан (Bohan Zhang) приоткрыл небольшую завесу о том, как компания работает с базами данных и с какими вызовами им приходиться сталкиваться и как их приходиться преодолевать. Это статья является вольным переводом оригинальной статьи Scaling PostgreSQL to power 800 million ChatGPT users, опубликованной на официальном сайте OpenAI, с некоторыми пояснениями и умозаключениями от переводчика, с учетом его знаний и опыта.

Привет! На связи команда рекомендаций AI VK. Фактически в каждом продукте есть и рекомендации и поиск, и чтобы каждой команде не приходилось изобретать свой «велосипед», мы разработали единую Discovery-платформу. С ней команды могут «по кнопке» запускать рекомендации, тестировать модели, а также делиться лучшими решениями.

В статье поделились подробностями о том, что из себя представляет единая Discovery-платформа и какие результаты уже заметны.

Переходите под кат, будет интересно ⬇️

Всем, кто работает с данными, знакома ситуация: цифр много, а понятных инсайтов — мало. Рутинные отчеты в Excel съедают время, а ответ на внезапный вопрос от руководства превращается в многочасовой квест.

Всем привет, меня зовут Ирина Севрюкова, руководитель отдела бизнес-анализа Polymatica. В этой статье я на реальных задачах разберу, как современные OLAP‑системы (на примере платформы Polymatica BI) позволяют не просто строить отчеты из больших данных, а проводить живой анализ данных, находить скрытые зависимости и быстро проверять гипотезы.

Несмотря на на то, что статья описывает проблемы заказчика в АПК, аналогичные задачи встречаются во многих отраслях.

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

Привет, Хабр! На связи команда продуктового матчинга ecom.tech. Наша команда решает задачи поиска, группировки и сопоставления товаров с помощью алгоритмов машинного обучения. Все это необходимо для развития и улучшения бизнес-процессов в компании, а именно быстрого заведения карточек товаров, мониторинга цен на товары и развития ML. В этой статье мы расскажем про доматчинг – сравнение сложных пар товаров, которые отобрали на предыдущем этапе пайплайна, с помощью LLM. Поехали!

Друзья, привет! Меня зовут Андрей Комягин, я CTO компании STM Labs. Мы занимаемся разработкой очень больших распределённых высоконагруженных систем для различных отраслей, включая налоговое администрирование, телеком, track & trace и многие другие. В своих проектах и архитектурах мы широко применяем open-source-решения, включая брокеры сообщений, такие как Kafka и RabbitMQ.

Совсем недавно я выступил на конференции HighLoad++ Genesis 2025: рассказал про анатомию каждого из этих брокеров, сравнил их по набору критериев и оценил результаты их нагрузочного тестирования. А теперь решил выпустить этот материал в виде статьи в блоге, чтобы читатели Хабра тоже смогли изучить нюансы и понять, на какие задачи заточен каждый из брокеров. Итак, поехали!

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

Сегодня бизнес активно использует машинное обучение (Machine Learning, ML) для решения самых разных задач — от прогнозирования продаж до автоматизации процессов. Однако искусственный интеллект — это не какое-то волшебство, а математика, методы и алгоритмы, которые не будут работать без качественных и подходящих именно им данных. Чем больше качественных данных доступно для анализа, тем более сложные и точные модели можно построить. 

Меня зовут Анна Фенюшина, я ведущий архитектор направления «Дата-сервисы» в VK Tech. В этой статье я разберу, какие поколения ML существуют, какие данные нужны для их реализации и как современные хранилища могут помочь в развитии ИИ.

Аналитике редко учат напрямую: как выстраивать аналитическое мышление, находить реальные причины изменений в метриках и выбирать KPI, которые ведут к решениям, а не к «красивым отчётам». Эта статья — о навыках аналитика, которые формируются на практике и чаще всего через ошибки.

Эта статья будет полезна DS специалистам, и тем, кто хоть когда-нибудь сталкивался с такой проблемой, как выбросы в данных или OOD (out of distribution), и ищет пути решения проблем, возникающих из-за них.

Хочу рассказать о своей разработке и поделиться ей с сообществом habr в виде готового модуля для Python.

Этот модуль решает задачу обновления данных в базе данных. Он выполняет insert/update/delete в одном действии.

Модуль DBMerge проектировался для упрощения ETL процессов по загрузке данных из множества внешних источников в SQL базу.

Для взаимодействия с базой данных используется SQLAlchemy и ее универсальные механизмы, таким образом, разработка не имеет привязки к конкретной БД. (На момент написания статьи, детальные тесты проводились для PostgreSQL, MariaDB, SQLite, MS SQL)

Принцип действия

Принцип действия следующий: модуль создает временную таблицу в базе и записывает в нее весь входящий датасет через операцию массового insert. Далее он выполняет инструкции UPDATE, INSERT, DELETE для целевой таблицы.

История о том как я потратил 5 лет на изучении llm ботов и в итоге написал своего за пол года. Пути реализации и ошибки.

Привет, Хабр. Меня зовут Василий Мельник, я product owner решения для потоковой обработки данных Data Ocean SDI в компании Data Sapience. Наша команда приобрела большой практический опыт работы с Apache Iceberg в задачах на стыке традиционной пакетной обработки и near real-time и конкретно с использованием технологий на базе Flink, поэтому мы не могли пройти мимо нового открытого табличного формата (OTF) Paimon от разработчиков Apache Flink. В этой статье я опишу наш опыт и те практические выводы, которые мы сделали на промышленных средах, в виде репрезентативного тестирования, на котором проиллюстрирую ключевые практические сценарии.

Любая модель машинного обучения начинается с данных. Известное выражение «garbage in, garbage out» как нельзя лучше описывает главную уязвимость ML‑систем. В автоматизированном машинном обучении (AutoML) наиболее критичными точками являются процесс сборки данных и проблема мониторинга данных, в т.ч. в онлайне. Если процессы feature engineering и обучения наша библиотека формализует «из коробки» с помощью конфигурационных файлов и единых правил, то ответственность за загрузку и получение данных несет пользователь.