Data Mining *

В прошлый раз я рассказывал, как в одиночку с AI-агентами собрал ERP-платформу на Kubernetes из 30+ сервисов. Эта статья — про её мозг: не «ещё один агентский фреймворк», а продакшн-движок, который год несёт живых клиентов (рекрутинг с AI-интервью, CRM, парсинг-конвейеры, копилот).

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

Сервис работает на Node, на CPU.

ChatGPT может безошибочно посчитать метрики, найти тревожные тренды и предложить план действий — даже если в данных нет ничего, кроме случайного шума. В эксперименте на синтетических данных интернет‑магазина AI‑ассистент сделал 30 аналитических утверждений, ни одно из которых не выдержало статистической проверки. Разбираемся, почему возникают такие ложные инсайты и как проверять выводы ИИ, прежде чем принимать на их основе бизнес‑решения.

После публикации первой части моих заметок о конференции «Биржевой Алгоритм 2026» в комментариях предсказуемо разгорелся спор. Самый частый вопрос звучал в формулировках разной степени вежливости: «Михаил, всё это здорово, но где деньги?», «сколько ты заработал в процентах на своём счёте?».

Также комментаторы писали: «Шардин не трейдер, а репортёр», «у него путь самурая — копать ради процесса», «человек занят наукой».

Отвечу, что на летнем ML‑эксперименте с пятиминутками я заработал ровно ноль рублей ноль копеек (а если считать оплату подписки за консультацию у модели Claude Fable 5.0 — то минус 20 долларов). И я этого совершенно не стесняюсь: лучше потерять 20 долларов на виртуальном стенде, чем отдать брокеру и бирже.

Но самое интересное произошло дальше. Пока я готовился рассказать о своём «сливном» бэктесте, со сцены и в кулуарах выступали люди, которые управляют десятками миллионов долларов, проектируют шлюзы Мосбиржи и строят инфраструктуру брокеров уже по 15–20 лет.

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

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

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

Ниже - что я взял за ключ записи, сколько раз каждый ключ подвёл и что в итоге работает. Код на Python, данные сняты 6 и 16 октября 2026 года.

Builder ELT — open-source ELT-приложение, которое позволяет визуально создавать потоки загрузки, объединять их в цепочки и запускать по расписанию. Преобразования выполняются средствами целевой базы данных на нативном SQL, а Python используется для работы с нестандартными источниками и API. Приложение не хранит в себе пользовательские данные. Основная цель создать стандартизированное решение, в котором можно было бы быстро создать ELT поток, не теряя гибкость SQL трансформаций. В итоге любой аналитик знающий SQL может загрузить себе данные.

Откуда это все и зачем.

Примерно в начале 2026 года, работая инженером аналитиком на проекте, я написал питон код для стандартизации ELT процессов. В нем обычная дельта/фулл выборка и запись в журнал.

Процесс загрузки данных повторяется на каждом проекте, а каждый ELT разработчик пишет код по своему. Хотелось стандартизировать хотя бы реперные точки, уменьшить время разработки и кол-во ошибок. Конечно любая стандартизация это постановка в рамки и уменьшение гибкости. Но здесь сработало правило 20/80. В добавок аналитики как правило зависели от специалистов ELT и ждали новые данные.

Сначала был написан пул питон функций и использовалось в виде локального питон-пакета. Далее для удобства был прикручен GUI и база данных для хранения метаданных. Получилось приложение, в котором можно было подключаться к источнику/приемнику, создавать поток и планировать запуск. Получилось что-то с чем можно было уже работать. Далее для возможности создавать очередь потоков был прикручен celery и redis. Ну и на сладкое провайдер авторизации keycloak.

Модно называть вторым мозгом папку с заметками в Obsidian. Но 200 тысяч файлов сами по себе ничего не делают - это вторая память. Мозгом она становится, когда к ней подключены агенты. И я рассказываю, как это устроено у меня и что они умеют находить.

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

У фирмы «1С» есть открытый список 1С-франчайзи: страница, где можно выбрать регион и увидеть всех, кто внедряет «1С:Предприятие» в вашем городе. Это, пожалуй, самая большая франчайзинговая сеть в российском IT, и нечастый случай, когда франчайзер сам выкладывает всю сеть одной страницей. Я хотел простого: собрать этот список целиком, посчитать, как сеть разложена по карте, и привязать каждую строку к юрлицу в ЕГРЮЛ.

Простого не вышло. Ниже - как устроен источник, что в нём сломано и сколько строк в итоге удаётся честно связать с реестром. Код на Python, короткими кусками, всё снято 12 октября 2026 года.

Конверсия интернет-магазина за ночь упала на 14%, хотя оплаченных заказов стало больше. Под подозрением — релиз iOS и посевы в Telegram. Разбираем, как за 20 минут проверить метрику, выявить сбой трекинга и разобраться в реальных причинах просадки.

Просто стало интересно — что такое описательный анализ. Математический анализ, функциональный анализ знаю. А описательный?

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

Как теоретическую основу я использовал идеи из следующих источников:

Process Mining — Ван дер Аалст, «Process Mining: Data Science in Action (2016). Методология извлечения знаний о процессе из логов событий.»

EDA (Exploratory Data Analysis) — Тьюки, 1977. Принцип: сначала смотреть на данные, потом строить модели.

Lean Six Sigma — DMAIC (Define, Measure, Analyze, Improve, Control). Стандартная методология улучшения процессов.

Я не применяю всех методов, описываемых в Process Mining: Data Science in Action. Для данного анализа достаточно понимать, что наука о данных — это, в частности, превращение данных в реальную ценность.

В этой статье ценность — понимание процесса. Мы не строим прогнозы, не используем машинное обучение. Мы делаем описательный анализ: превращаем сырые логи в картину того, как процесс работает на самом деле.

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

На конференцию «Биржевой Алгоритм 2026» я летел из Перми в Москву рано утром прямо в день конференции 9 октября. Когда прошёл все досмотровые формальности в аэропорту и уже ждал посадку, то через громкоговоритель объявили, что авиакомпания Победа отменила все рейсы Пермь‑Москва на сегодня, хотя посадка на их ближайший рейс в Москву должна была начаться минут через 20. Но у меня был другой перевозчик Аэрофлот — так что моя посадка состоялась, я улетел и смог принять участие в конференции.

Обратная дорога на следующий день оказалась сложнее. Самолёт Sukhoi Superjet несколько раз заходил на посадку в Перми, круга 4 сделал, а в последний заход даже на высоту пятиэтажки опустился и я уже подумал что сядем, но нет — стал набирать высоту и мы улетели в Екатеринбург, несколько пассажиров причём запаниковали и сошли в Екатеринбурге. Потом ещё приходила собака‑кинолог после их схода. Затем самолёт заправили и рейс вернулся в Пермь, а прибытие сдвинулось примерно часов на пять.

Так вот — даже план полёта не гарантирует, что самолёт сядет в нужном месте и в нужное время. И с торговыми стратегиями то же самое: на истории они выглядят убедительно, а в реальности сталкиваются с тем, чего в модели не было.

Это был небольшой переход от реальной жизни к алгостратегиям.

После переезда я искал булочную на Яндекс Картах и наткнулся на отзыв, начинающийся с фразы «да вот хороший вариант ответа».

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

Расскажу, как устроены embeddings, графы совпадений и взвешенный рейтинг, какие ошибки пришлось исправлять и что показала проверка на 21 тысяче настоящих отзывов.

Народный рейтинг Банки.ру публикует агрегаты по отзывам о каждом банке: сколько, о чём, с какой оценкой, как быстро отвечает банк. Я собрал эти агрегаты за 2019–2026 годы по 30 крупнейшим банкам в открытый датасет, добавил ключевую ставку и отчётность и проверил восемь гипотез о том, что отзывы говорят о деньгах банка: резервах, портфеле, марже. Часть гипотез подтвердилась, часть развалилась после поправки на объём. Ниже метод, цифры и код.

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

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

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

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

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

Эта статья о том, как статистический тест может показать различие там, где его нет, и как такую поломку отловить. Языковые модели тут ни при чём: такая же поломка случается и в A/B-тесте, в проверке после квантизации и в регрессионном тесте, который сравнивает распределение времени ответа до и после релиза.

Считал долю пальмового масла в детском питании, получил 10%, обрадовался сенсации. Потом открыл выборку глазами - и всё поехало. Разбор ложных срабатываний поиска по ключевому слову на базе составов: пальмитат, медь, мускатный орех и другие ловушки.

Мы опубликовали на arXiv статью TAPe+ML: A Compact Structured Representation for Multi-Task Computer Vision. В ней собраны результаты TAPe+ML v3 на задачах классификации, object detection, instance segmentation, индексации и поиска сцен в видео, а также в промышленном OOD-пилоте.

Статья на arXiv: TAPe+ML: A Compact Structured Representation for Multi-Task Computer Vision

Ключевые результаты TAPe+ML v3

88,1% Top-1 на ImageNet-1k, 65,3 mAP50–95 в детекции COCO, 58,4 Mask mAP50–95 в COCO instance segmentation, 98,2% покрытия объектов масками на LVIS — при размере ядра модели менее 100 тыс. параметров.

TAPe+ML v3 объединяет классификацию, детекцию и сегментацию в одном компактном ядре. В представленных в статье сравнениях она превосходит крупные SOTA-модели по ключевым метрикам: RF-DETR и YOLO в детекции, RF-DETR-Seg и YOLO26-X-Seg в сегментации; на ImageNet-1k достигает уровня крупнейших foundation-моделей при разнице в параметрах на несколько порядков.

Как устроена платформа данных «АстраЗенека» в России: BI, DWH и Data Lake в одном контуре

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

Привет, Хабр! По первому образованию я юрист. Успел поработать в прокуратуре и арбитражном суде, потом ушёл в ИТ и последние 13 лет занимаюсь инфраструктурой, разработкой и DevOps. Сейчас строю MLOps-платформу.

Эта биография мешает мне спокойно читать споры об авторском праве и генеративном ИИ. Юрист видит копирование чужих книг. Инженер — цепочку операций: crawler, raw storage, очистку, дедупликацию, training mix, веса, API. Между «скачали страницу» и «модель ответила пользователю» слишком много разных действий, чтобы обсуждать их одним словом «обучение».

Отправной точкой для этого разбора стала колонка Мэтта Столлера о внутренних материалах OpenAI и Microsoft. Столлер пишет прежде всего о политике и неравном применении закона. Меня зацепил другой вопрос: как тот же конфликт выглядит на уровне движения данных по ML-pipeline — и что с этим вообще может сделать инженерная команда.

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

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

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