Data Mining *

При эксплуатации 1С:MDM значительная часть работы с заявками на создание и изменение номенклатуры по-прежнему связана с ручной классификацией и заполнением характеристик. Как сократить эту работу и при этом повысить качество данных?

На вебинаре технический директор SOFROS покажет, как SOFROS AI/ML расширяет возможности 1С:MDM с помощью моделей машинного обучения и ИИ. Расскажем и покажем, как автоматизировать классификацию номенклатуры, извлечение характеристик из текстовых описаний, поиск похожих позиций и работу с характеристиками товаров.

Отдельно разберём, как SOFROS AI/ML интегрируется с 1С:MDM и как его можно использовать вместе с механизмами искусственного интеллекта, предусмотренными в решении 1С:MDM.

Зарегистрироваться

У фирмы «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 — и что с этим вообще может сделать инженерная команда.

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

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

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

Я прогнал 20 промптов через Perplexity API по три повтора, собрал 60 ответов и у каждой отсылки [N] в тексте связал предложение ответа со страницей источника, на которую оно указывает. Дальше самое трудоёмкое: для каждой такой пары — предложение ответа и страница источника — я искал в HTML кусок текста, максимально похожий на утверждение из ответа. Из 1355 отсылок 948 привели на страницы, которые ещё открываются, и на 448 из них нашёлся пассаж — абзац, пункт списка или ячейка таблицы, — покрывающий хотя бы треть слов утверждения.

Главный результат для того, кто пишет страницы, а не гоняет замеры: на сработавшей странице задействовано медианно два пассажа из 85, длиной около 49 слов каждый. По числу кусков это 2%, по словам больше — медиана 6,4% текста страницы при среднем 11,6%: сработавший пассаж длиннее типичного. Планировать имеет смысл не прочтение страницы целиком, а то, что из неё вытащат один самодостаточный абзац; что это значит для конкретного текста, я развернул в разделе про работу с Perplexity — он стоит в середине, до разбора моих ошибок в коде. Границы, за которыми эти числа перестают работать, вынесены в отдельный раздел — там же написано, как проверить то же самое на своей нише.

Вопрос, с которого всё началось: в логе замера видно, какие URL Perplexity ставит в источники, и не видно, что именно со страницы поехало в ответ — весь текст, абзац или одна строка списка.

Задача звучала просто: посчитать, у скольких товаров в базе есть в составе хоть одна Е-добавка. Я думал, это работа на полчаса. Работа заняла вечер, и большая часть вечера ушла на одну букву.

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

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

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

Я отлично понимаю что любой проект в этом мире пытается выжить и получать прибыль. К чести этого ресурса, у читателя есть возможность сконцентрироваться на контенте и не отвлекаться на мерцание рекламы и баннеров! Но в этом же плюсе Хабра кроется и минус - реклама становится не явной, а вплетенной в текст.

Начинаешь читать материал и получаешь ссылки на телеграм каналы в статьях независимых авторов призывающих подписаться. А в корпоративных блогах рекомендации виртуальных машин на хостинге, подписки на агрегаторы AI чатботов, дозы нейрослопа для поисковой оптимизации сайтов и продуктов с 2023 года, продвижение HR бренда компании для создания очереди кандидатов и тому подобное. И с этим вряд ли станет лучше. Не спасет читателя модерация и политики платформы.

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

Я не агитирую “пчел против мёда”! Но предложу свой подход, который позволяет искать нужную информацию среди десятков и сотен тысяч статей. На Хабре есть контент высочайшего качества: описания решений практических задач, фреймворков, технологий, фич и конструкций языков программирования, как выжить в корпорации или стартапе. И все это можно найти как человеку, так и автоматизированным агентам, нужно лишь обработать и подготовить этот массив информации. И да, здесь для обработки статей и их группировки используются нейросети и алгоритмы кластеризации.

Будем группировать 34 тысячи статьи Хабра по смыслу и каталогизировать их, читать похожие по теме не доверяя ключевым словам и хабам которые указал автор материала. Таким же образом вы можете создавать свою локальную базу знаний из личных материалов и записок на работе и дома, при желании не делясь этой информацией с облачными API сервисами нейросетей. Эту же структурированную информацию будет гораздо проще найти и AI агенту для решения ваших технических задач, где нужны точные решения, алгоритмы и “рецепты”.

Материал в статье, не скрывающийся под спойлером, написан вручную дедовским “ламповым” методом.

Ровно 18 лет назад, 15 сентября 2008 года, обанкротился Lehman Brothers — крупнейшее банкротство в истории США. Банк не использовал стресс-тесты для коммерческой недвижимости, поэтому ответа на вопрос «а что, если офисы и торговые центры обесценятся» у него не было.

Стресс-тест можно сделать не только в банке с отделом риска. «А что, если доставка вырастет на 3 дня», «конкурент снизит цену на 15%», «ставка по ипотеке поднимется на 3 пункта» — на каждый вопрос можно ответить числом.

Код движка и инструкция, как посчитать на своих данных, в опенсорсе.

Можно ли научить детектор атак, ни разу не показав ему настоящую атаку?

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

Потом я выпустил их на настоящие данные: журналы аутентификации Лос-Аламосской лаборатории, 1.65 миллиарда событий, с размеченными учениями красной команды.

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

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