Data Mining *

Привет, Хабр! По первому образованию я юрист. Успел поработать в прокуратуре и арбитражном суде, потом ушёл в ИТ и последние 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 синтетика вошла в диапазон исследовательских работ, обученных на настоящих размеченных данных, хотя сравнивать их в лоб нельзя, и я объясню почему.

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

Шесть дней назад я рассказал здесь про resume2human — программу, которая из резюме делает список вакансий и по каждой находит 1–3 живых человека с именем, ролью и адресом, чтобы написать им напрямую. За неделю в проект уехал 21 коммит в девяти PR, тестов стало 746 вместо 345, и я нарушил ровно половину обещаний, которые дал в том тексте. Внутри: бесплатная ступень поиска личных контактов, которая держится на git вместо платных баз; три бага, из-за которых прогон честно искал не то, что просили; и разбор того, почему покрытие пустого множества равно единице и что это стоило мне в скоринге.

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

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

Разберём практический подход к проверке качества ML‑модели: от временного сплита и настройки Pipeline до подбора порога решения и подготовки артефакта для инференса.

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

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

И самое интересное: агент не нарушал прямой запрет. Наоборот, в ключевой момент он поступил "безопасно" — отказался запускать неизвестный бинарный файл и написал собственный декодер на Python. Именно это решение и стало частью атаки.

Такую цепочку продемонстрировал исследователь безопасности Иоганн Ребергер на Claude Code с моделью Opus 5 в Auto Mode. В его небольших сериях тестов атака срабатывала в трёх или четырёх запусках из пяти. Это не означает, что "Claude взламывается с вероятностью 80%", но хорошо показывает более важную проблему: безопасный на вид отдельный шаг ничего не гарантирует, если вся цепочка строится в среде, которую контролирует атакующий.

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

Читатель написал: кетчупа съедают 5 грамм, а гречки 220. Сравнивать их на 100 г бессмысленно. Пошёл смотреть, как с порциями устроено в РФ, ЕС и США, и почему в моём сканере состава их до сих пор нет.

Задача была на полчаса: пройтись по списку из 216 адресов вида t.me/имя и понять, какие живы и что это — канал, группа или аккаунт. Ушёл день, и почти весь на то, чтобы перестать верить собственному коду. Ни одна из пяти ошибок не выглядела как ошибка: HTTP 200, валидный HTML, разбор без исключений.

Привет! Меня зовут Дмитрий Гаврилов, я руководитель центра компетенции аналитики в MWS. Моя команда внедряет ИИ-скиллы в работу дата-аналитиков. Мы посмотрели на типичный рабочий день и поняли: рутина съедает до 75% времени аналитика. А можно ли это передать ИИ-агенту без потери качества? Эту гипотезу проверили на реальных задачах и получили конкретные результаты — делюсь в этом материале.

Пользователь пишет интересы текстом, мы делаем из них один эмбеддинг. Работает он как монета (ROC-AUC 0.52), а на коротких интересах 0.41, то есть хуже случайного порядка. Прогнали шесть вариантов починки и подняли до 0.80. Рассказываю, что сработало, а что нет.

Идея агрегатора новостей по кибербезопасности зародилась еще давно. Хотелось получать самое важное и без инфошума. LLM тогда ещё не были повседневным инструментом, и первую версию реализовал на модели суммаризации rut5_base_sum_gazeta, а важность считал textrank. Работало так себе. Потом появились сервисы, которые сами подбирают новости под настроенную ленту. Но оптимального решения так и не увидел – это либо про всё сразу, либо что-то про одну узкую тему.

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

24 коллектора, 111 ATS-досок компаний, 345 тестов, ноль API-ключей и ноль ИИ. Windows-exe, который считает совпадение резюме с вакансией и приносит 1–3 живых человека, которым можно написать самому. Внутри — архитектура, три бага, из-за которых я чуть не отправил письма сотрудникам чужих компаний, и раздел «честные ограничения», без которого это была бы реклама.