Data Mining *

Всем привет.
Речь пойдет о методике ETL-процесса. Очень мало информации об этой важной области работы с данными. Я много раз видел на проектах, что в командах нет общего не то что фреймворка, а даже методики по загрузке данных. Либо есть, но у каждого разработчика своя. И те, что есть, не универсальны и не учитывают некоторые реперные точки. Иногда даже журнал загрузок не ведется. Созрела идея создать, перенести свою методику в питон код и поделиться. Начнем.

Когда мы создаем ETL- процессы основные требования: идемпотентность, обработка ошибок, целостность данных, инкрементальность, производительность, мониторинг, происхождение данных, и тд. Может еще что, но и этого достаточно.

Основные понятийные объекты в тексте: tech_query_id, tech_batch_id. tech_query_id – является штампом момента запуска pipeline, вручную или автоматически, не важно. Если запустили загрузку для терабайт данных, то и штамп будет всего один для этой конкретной загрузки. Штамп tech_query_id проставляется в каждой строке в самих таблицах с данными цели и в журнале. А так же проставляется tech_batch_id, который является обычным номером пакета. Понятно зачем пакеты.., если данных миллионы, мы их бьем по пакетам. Номер пакета для каждого query_id  начинается с единицы. Эта комбинация является ключом в таблицах с данными для трассировки происхождения и ключом в таблице журнала загрузок для фиксации метаданных, дельтапоинта и любой полезной информации в json поле.

Рост тарифов на электроэнергию, ужесточение регулирования и изменчивость крипторынка заставляют инвесторов считать экономику майнинга буквально до киловатт-часа. Сегодня главный вопрос - не цена оборудования, а стоимость кВт·ч на горизонте 3-5 лет, так как в модели доходности дата-центра электроэнергия составляет до 60-70% операционных затрат.

Дисклеймер: статья написана на основе интервью с Артемом Драгуновым, девелопером, собственником индустриального парка «Зеленец».

Любое снижение цены киловатта напрямую повышает маржинальность. Именно поэтому многие участники рынка переходят от модели «покупаем электричество» к модели «производим сами». Например, с помощью газопоршневых установок (ГПУ).

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

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

Десять лет всё работало. Поставщики присылали прайсы, менеджеры загружали. В 90% случаев клиенты искали товар по артикулу — просто вбивали номер и получали результат. Оставшиеся 10% запросов — это названия вроде «хомут бмв х5». И поиск как-то справлялся.

Да, в базе была каша: один и тот же товар мог называться «Хомут винт. BMW X5/E81» и «Хомут крепления топливного шланга 12мм для BMW». Но артикулы вывозили, а на остальное закрывали глаза.

А потом мы узнали про Честный знак.

Зачем бизнесу новая позиция в C-suite и что она означает на практике

Когда одни компании обсуждают, нужен ли им ИИ, другие уже нанимают человека, который будет отвечать за него (или сейчас  сам сидит и пилит ИИ-агентов ) и все это на уровне совета директоров. Chief AI Officer — позиция, которая ещё три года назад звучала как фантастика, сегодня становится такой же обычной как СТО (ТехДир), CFO (ФинДир)или CHRO (HR).

Ну и что это за роль такая, откуда она взялась, чем отличается от CTO и CDO(Chief Digital Officer — директор по цифровой трансформации (это в больших банках есть такая позиция)), какие технические компетенции требует — и нужен ли он вам сегодня или как обычно, уже вчера.

В машинном обучении есть такой метод - обучение с подкреплением (reinforcement learning, RL), который используется для решения задач последовательного принятия решений. В этом методе агент на каждом шаге взаимодействует со средой, изменяя её. Обратной связью для него является некая искусственно сконструированная награда, которая выдаётся на каждой итерации взаимодействия. Основная проблема в том, что действие и награда напрямую не коррелируют. Часто, награда назначается за какое-то финальное достижение, которого можно достичь только выполнив определенную последовательность действий с нулевым или даже отрицательным вознаграждением. Существуют различные способы "протянуть" награду вдоль всей траектории, чтобы в конце концов агент осваивал более-менее приемлемую стратегию поведения.

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

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

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

Вчера вечером листал Telegram и наткнулся на пост в канале midov_channel (пост 775). У Ислама обсуждается пост в reddit в котором активно дискутируют, что 211 тысяч звёзд у репозитория — это «Fake stars, боты накручивают» .

Активно использую последнию неделю OpenClaw , имею своё мнение, и понимаю почему такой вопрос возникает: 211 тысяч звёзд — это много. Конечно, когда видишь такие цифры, первая мысль — «а точно ли это настоящие люди?»

У меня профессиональная деформация - доверяй, но проверяй. Всё таки 15 лет развивал департаменты Data и аналитики в L'Oreal. Это также трансформировалось в текущий мой бизнес AYGA Data & AI, где мы, с агентамиработаю в формате AI-first компании, привыкли к другому подходу — не спорить, а проверять. Есть гипотеза — есть данные. Данные либо подтверждают, либо опровергают.

Собственно, поэтому вчера дал своему агенту Gubin задачу: собрать все 211 тысяч профилей stargazers репозитория и провести forensic-анализ. Не выборку, не 1% — все до единого.

Через полтора часа Агент Губин прислал мне в телеграмм презентация из 14 слайдов. Дальше — разбор каждого из листа презентации.

Большинство данных на фермах оседает в Excel-таблицах и тетрадках зоотехников. Вместе с командой Genome AI (акселератор Talent Hub ИТМО и Napoleon IT) разбираемся, как машинное обучение превращает генетический «шум» в прогнозы продуктивности. В статье — про гибридные модели (CatBoost + PyTorch), работу с SNP-маркерами, кривые лактации и то, зачем корове цифровой двойник. Без абстракций — только код на R, визуализации и архитектура пайплайна.

Наверняка каждый, кто начинает погружаться в анализ данных, сталкивался с этой классической проблемой. Вы скачиваете гигантский CSV-файл, по привычке пишете pd.read_csv(), запускаете ячейку и... кулеры начинают выть, система жутко тормозит, а в итоге скрипт падает с ошибкой нехватки памяти.

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

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

В этой статье будет рассказано о популярных метриках оценки для задач генерации текста: BLEU, ROUGE, METEOR, BERTScore. Рассказ будет сопровождаться визуализацией, примерами и кодом на Python.

А никто не обещал, что на хакатоне будет легко.

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

Привет, Хабр! Это Алла, я работаю исследователем в команде «Модели с памятью» Лаборатории когнитивных систем искусственного интеллекта Института AIRI и занимаюсь исследованиями на стыке графов знаний и языковых моделей. Ранее я уже писала на Хабре статью про построение графов знаний из текстов по мотивам одной из наших публикаций.

Мы активно продолжаем работать дальше и создали Wikontic — полноценный пайплайн для этой задачи. Недавно мы представляли его на интерактивной демо‑сессии на AAAI 2026 в Сингапуре — про это несколько дней назад вышел хабр от моего коллеги Айдара. Здесь я расскажу подробнее о том, как устроен новый пайплайн, и какие идеи пришли к нам в голову при его создании. 

Привет Хабр! На связи снова Дмитрий Крюков, руководитель группы «Исследования биомаркеров» лаборатории «Сильный ИИ в медицине» Института AIRI. Недавно мы с коллегами выпустили статью в npj Aging, в которой изрядно покритиковали калькуляторы биологического возраста (они же часы старения) и попытались поставить под сомнение саму возможность и даже необходимость расчёта биологического возраста. 

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

Внимательно прочитав этот пост вы наверняка сможете сами рассчитать биологический возраст, при условии, что владеете минимальным кодингом (ну или хотя бы вайб‑кодингом). И, поверьте, у вас получится это не хуже, чем многих из тех, кто предлагают свои решения как сервис (примеры: [1, 2, 3, 4, 5, 6, 7]). С другой стороны, если вы прочитаете пост второй раз, вы скорее всего поймёте, что хорошо оценить биологический возраст на самом деле очень трудно и, возможно, не стоит даже пытаться.

Для запуска А/В теста необходимым минимумом является фиксация ошибок первого и второго рода, расчет MDE (минимальный наблюдаемый эффект). Однако при расчете результатов теста далеко не всегда получается достичь MDE заданного размера, в таком случае статистическая значимость результатов не будет достигнута. Помимо этого даже при статистически значимом результате существует вероятность ошибки, при которой наши результаты являются выбросом или просто случайностью. Как быть в таком случае?

229 заездов, 140 пилотов, 28 часов работы — столько данных мы собрали из Assetto Corsa за три дня SOC Forum 2025.

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

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

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

Что будет, если поручить эволюционному алгоритму самому «придумать» формулу? Разбираем генетическое программирование на наглядных примерах: от восстановления тригонометрических функций и символьной регрессии на реальном датасете до оптимизации структуры нейросетей — все эксперименты воспроизводимы в Google Colab.

В первой статье я рассказывал о Николае Морозове — человеке, который 21 год в одиночной камере превратил в аспирантуру. 26 томов, 11 языков, карьера до 92 лет.

Один из его принципов — любой доступный ресурс становится материалом для роста. Книг не давали, только Библию. Кто-то бы отчаялся. Морозов открыл Апокалипсис и начал искать в нём астрономию.

Из этого вырос самый спорный его проект — «новая хронология»: попытка пересчитать историю человечества через точные науки. Выводы оказались ошибочными. Но вопрос, который он задал — «можно ли проверять историю методами точных наук?» — оказался правильным.

Эта статья — о том, что случилось с Библией в руках естествоиспытателя. И о том, почему хороший метод не спасает от плохих выводов.

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

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

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

Хабр, привет! Недавно завершилось ML-соревнование E-CUP 2025. Наша команда из X5 Tech заняла первое место в треке «Логистика: автопланирование курьеров», где было нужно оптимизировать время, затрачиваемое курьерами на доставку 20 000 заказов. В статье расскажем про подходы, которые использовали для решения этой задачи. Посмотрим, во сколько раз можно сжать JSON с матрицей расстояний. Какой код мы использовали для быстрого решения задачи TSP с помощью LKH-3. Обсудим, на что обращать внимание при кластеризации заказов.

Постановка задачи

Требовалось распределить порядка 20 000 заказов между 280 курьерами и построить для каждого из них маршрут так, чтобы минимизировать их суммарное время работы. Оно складывалось из времени перемещения курьеров между заказами и времени выполнения самих заказов (service time). За каждый невыполненный заказ добавлялся штраф 3000 секунд...

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