Data Mining *

Scikit-learn — это одна из основных Python-библиотек для машинного обучения. Её подключают в прикладных проектах, AutoML-системах и учебных курсах — как базовый инструмент для работы с моделями. Даже если вы давно пишете с PyTorch или CatBoost, в задачах с табличными данными, скорее всего, всё ещё вызываете fit, predict, score — через sklearn.

В 2025 году в библиотеку добавили несколько важных обновлений: доработали работу с пайплайнами, подключили полную поддержку pandas API, упростили контроль за экспериментами.

Мы подготовили гайд, как работать со scikit-learn в 2025 году. Новичкам он поможет собрать первую ML-задачу — с данными, моделью и метриками. А тем, кто уже использует библиотеку, — освежить знания и понять, что изменилось в новых версиях.

Всем привет! В этой статье поделюсь нашим опытом использования Apache Kafka на слое Stage в аналитической архитектуре. Мы поговорим о том, что такое слой Stage и зачем он нужен, почему именно Kafka стала нашим выбором, как устроен процесс ingest (приёма данных) на базе Kafka, что можно и чего делать не стоит на этом этапе, какие грабли нас ждали и как мы их преодолели, а также дам практические советы из реального опыта. Спойлер: Kafka оказалась не просто очередным модным словом, а действительно упростила нам жизнь в аналитическом проекте. Поехали!

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

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

Привет! Меня зовут Соня Асанина, я работаю в команде Центра технологий искусственного интеллекта Газпромбанка. В этой статье я расскажу, как тематическое моделирование и мягкая кластеризация помогают нам извлекать ценные инсайты из клиентских отзывов.

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

К примеру, мы получаем отзыв, в котором клиент недоволен кредитной картой и предлагает что-то изменить в приложении, но при этом выражает благодарность за вежливое обслуживание в отделении. К какой категории отнести отзыв? А если таких смешанных отзывов тысячи — как определить, какие продукты действительно требуют улучшения, а какие работают отлично?

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

LLM-as-a-judge — распространённая техника оценки продуктов на основе LLM.

Популярность этой техники обусловлена практичностью: она представляет собой удобную альтернативу дорогостоящей человеческой оценке при анализе открытых текстовых ответов.

Оценивать сгенерированные тексты сложно, будь то «простой» саммари или диалог с чат-ботом. Метрики типа accuracy плохо работают, поскольку «правильный» ответ может быть сформулирован множеством способов, не обязательно совпадающих с образцом. Кроме того, стиль или тон — субъективные характеристики, которые сложно формализовать.

Люди способны учитывать такие нюансы, но ручная проверка каждого ответа плохо масштабируется. В качестве альтернативы появилась техника LLM-as-a-judge: для оценки сгенерированных текстов используются сами LLM. Интересно, что LLM одновременно являются и источником проблемы, и её решением!

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

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

Подходит к завершению серия моих публикаций про использование идей искусственного интеллекта для решения задачи коммивояжера (TSP).

В этой заметке помогаю разобраться в авторской реализации Deep Q-learning для TSP.

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

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

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

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

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

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

Big Data - это огромные объёмы данных, которые невозможно обработать с помощью традиционных методов.

Они могут быть структурированными (например, данные из баз данных) или неструктурированными (например, текстовые данные из социальных сетей).

Большие данные представляют собой колоссальные массивы информации, генерируемые в процессе повседневной деятельности индивидов и организаций.

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

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

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

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

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

Но по мере того как компании накапливали всё больше разнородных сведений, недостатки реляционных баз данных становились всё более явными.

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

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

Тем не менее, при внедрении таких аналитических инструментов компании всё ещё сталкивались с определёнными трудностями.

Архитектура сохраняла свою целостность, и одна команда специалистов занималась созданием платформы и интеграцией данных.

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

В данном контексте централизация оказалась ахиллесовой пятой крупных корпораций.

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

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

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

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

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

Часто недооцененным аспектом разработки AI-агентов остаётся этап оценки. Хотя создать proof of concept относительно просто, поиск оптимальной конфигурации для балансировки стоимости, скорости, релевантности и других параметров требует значительных временных затрат. Инструменты и фреймворки для оценки являются ключевыми элементами этой стадии оптимизации.

Современные сервисы знакомств оптимизированы не для создания пар, а для монетизации одиночества через манипуляцию дофаминовыми циклами. Конфликт интересов между пользователями и платформами усугубляется архаичными социальными стереотипами и отсутствием платформ использующих современных технологии для поиска (хотя вроде и есть ML, скоринг, кластеризация..) И в таргетинге работают уже в весь рост. Там это выгодно. А выгодно ли сервисам?

Статья продолжает обсуждение пространственных признаков в Python. Здесь мы рассматриваем пространственные объединения — аналог обычного объединения в мире геоданных, основанный на топологических отношениях между объектами, таких как пересечение, вложение или касание. Также мы узнаем, как правильно рассчитывать различные типы расстояний (и иногда это не просто евклидово расстояние между двумя точками). Например, геодезическое расстояние учитывает кривизну Земли, что особенно важно для анализа данных на больших территориях; расстояние маршрута учитывает направление: оптимальный маршрут от A до B не всегда равен маршруту от B до A. 

Привет, Хабр! Я, Мадаров Артур, руководитель дирекции процессов эксплуатации и ИТ-услуг Страхового Дома ВСК. Недавно мы с командой произвели реинжиниринг процессов контроля качества ИТ поддержки. Хотим поделиться нашим опытом.

Предпосылки изменений

Тенденции по развитию ландшафта ИТ систем, увеличению каталога сервисов по предоставлению услуг технической поддержки, и, как следствие, увеличению количества пользователей приводят к трансформации процессов и подходов анализа, оценки и контроля качества ИТ поддержки.

Если вчера процессы контроля качества в поддержках разного уровня, различных контактных центрах выстраивались вокруг выборки обращений до1–2% обращаемости, их оценке по критериям чек-листа и включению результирующей оценки в KPI, то сегодня фокус на оценке качества обслуживания клиентов требует глубокого анализа направлений поддержки, автоматизированных инструментов по оценке и контролю, внедрения технологий по анализу 100% обращаемости.