Открытые данные *

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

Чтобы ответить, я собрал 224 бенчмарка, о которых в 2018–2026 годах отчитывались девять лабораторий: OpenAI, Anthropic, Google, Meta, xAI, DeepSeek, Alibaba, Moonshot и Mistral. Для каждого нашёл дату рождения и, если она уже наступила, дату смерти — момент, когда бенчмарк перестаёт различать лучшие модели: лидер набирает 90% или уровень человека, либо создатели сами признают набор насыщенным или сломанным. По этим датам считается период полураспада — срок, за который умирает половина бенчмарков.

Главные результаты:

Период полураспада бенчмарка — 23 месяца. У вышедших до 2023 года он был 38 месяцев, у вышедших позже — 19. Оценка учитывает и ещё живые бенчмарки, поэтому короткая история новых её не искажает.

Новые бенчмарки не проще старых, просто модели быстрее. Запас до потолка на старте у них прежний, а проходят его модели вдвое быстрее.

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

Ниже — как я считал и сколько, по этим данным, проживёт сам OenoBench. Датасет, кодбук и скрипты — в открытом доступе, ссылки в конце.

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

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

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

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

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

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. Для данного анализа достаточно понимать, что наука о данных — это, в частности, превращение данных в реальную ценность.

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

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

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

Так появились две библиотеки. phoneoperator по реестру Минцифры определяет оператора и регион номера, bankbik по справочнику ЦБ находит банк по БИК и проверяет ИНН, СНИЛС, ОГРН и счета. Обе работают без сети и обновляются сами. Внутри: как 60 МБ реестра ужимаются до 45 КБ, почему у МТС два названия и почему сайт Минцифры не пускает GitHub.

Песочницы: phoneoperator и bankbik.

8 окт. 2026 г. · @knz75

как расстояния до звёзд превращаются в шаги

Это рассказ о том, столько шагов до Луны и как вписать свое имя в название звезды.

К 2040 году в России может стать примерно на 11 млн меньше работников в возрасте 30–49 лет, но при этом какого-то общего обвала числа работников при этом скорее не произойдет, так как будет частичная компенсация молодыми, людьми 50+ и миграцией, но уже после 2040 года эта компенсация будет начинать немного сбоить.

Я взял демографический прогноз Росстата, данные о занятости по полу и возрасту, учёл пенсионную реформу и миграцию и попробовал посчитать, сколько же людей вообще будет доступно российскому рынку труда в 2032, 2040 и 2046 годах. Плюс заодно примерно оценил то, насколько этот разрыв способны компенсировать миграция, более высокая занятость и ИИ.

1 октября в России заработал реестр цифровых платформ. Это седьмой новый государственный реестр только за 2026 год, и год ещё не закончился. Я подумал, что в такой ситуации стране срочно не хватает одного: реестра реестров. Собрал 100 государственных реестров в одну таблицу, проверил каждый по тексту закона и посмотрел, что из этого получается. Рассказываю, что узнал по дороге.

Полгода назад я решил измерить, сколько языковые модели на самом деле знают про вино. Вышел бенчмарк OenoBench: 38 104 факта из открытых источников, 3 266 вопросов с вариантами ответа и прогон шестнадцати моделей. Почти всю работу сделали агенты: код писал Claude Code, вопросы генерировали пять моделей, проверяли их десять агентов аудита. Я был единственным человеком в схеме и отвечал за вино. Счёт за API — около $800.

Внутри: как 17 скраперов из 35 оказались «гарантированным fallback» из памяти модели и как выглядит инвариант, который этого больше не допускает; как факт превращается в вопрос через ячейки «стратегия × домен × генератор»; почему три LLM-судьи из трёх компаний согласились друг с другом и все ошиблись; какой агент так и не прошёл свой порог и почему я перестал верить ему, а не корпусу; как 16 моделей ведут себя на одном лидерборде, разрезанном пополам; и почему самые сложные вопросы любого сгенерированного бенчмарка — в первую очередь самые сломанные. Все числа — из базы, запросы в тексте.

За две недели мы отправили около 2 100 приглашений в отраслевой опрос: специалистам по рискам в банках и инвестиционных фондах. Базу собрали сами. Организации взяли из открытого реестра юрлиц GLEIF, сайты искали через Wikidata и автокомплит Clearbit, адреса собирали со страниц контактов. Из холодной рассылки не ответил никто.

Под катом разбор по шагам. Почему среди 1 301 адреса с сайтов финансовых компаний нет ни одного со словом risk. Как локальный DNS в режиме fake-ip превратил проверку доменов в формальность. Почему почтовые шлюзы банков отбили письма, отправленные из Gmail. И как рассылка однажды завершилась без единой ошибки и не отправила ни одного письма. С кодом на Python и цифрами.

У больших данных часто есть одна проблема: самые важные выводы зависят не от сложности алгоритмов, а от того, насколько аккуратно собраны и сопоставлены исходные источники. Автор собрал карту мелодий отправления для 2496 станций Большого Токио, объединив разрозненные вики, аудиоархивы и открытые данные, но столкнулся с тем, что даже названия станций оказались отдельной задачей для анализа.

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

Я пять лет вожу настольные ролевые игры как мастер. И пять лет воюю с музыкой.

Знакомая картина: партия торгуется с контрабандистом, напряжение на столе настоящее — и тут трек просто заканчивается. Тишина. Или автоплей подсовывает что-то бодрое из соседнего плейлиста. Магия момента разбита, а я судорожно переключаю вкладки, как будто проваливаю проверку восприятия.

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

При этом видеоигры решили эту проблему десятилетия назад. В любой RPG музыка города крутится, пока ты в городе, а стоит спуститься в склеп — тема мрачнеет вместе с тобой, точно в долю. Композиторы пишут игровую музыку секциями с loop-точками и маркерами переходов, а движки вроде FMOD и Wwise собирают из этого «музыку, которая реагирует».

Но моя фонотека — это обычные mp3. У них есть начало и конец, и им плевать на мою партию.

Так родился проект: инструмент, который берёт любой трек и заставляет его вести себя как игровой саундтрек. Под катом — вся дорога: от теории музыки и алгоритма Фута из 2000 года до нейросетей 2025-го, от сэмпл-точного планирования в Web Audio до археологии сломанных зависимостей. С честными цифрами, где нейросеть проиграла эвристике.

В скрипте обучения лежал список из 39 парковок, которые надо исключить: у них замороженный ряд, и модель учится на них предсказывать константу. Сегодня молчащих парковок тоже 39, и совпадают из них девять. Пока разбирался, выяснилось интересное: эти 39 константных рядов улучшают публикуемую MAE на 16% и превращают наивную базу с отрицательным R² в базу с положительным. При этом на самих этих парковках модель работает хуже, чем её отсутствие.

Искусственный интеллект стал неотъемлемой частью нашей жизни и в том или ином виде внедряется практически в любой крупной компании. Все это порождает новые объекты управления, которые уже не укладываются в классический DataGov. Поэтому DataGov 2.0 — это эволюционное развитие. Data Governance остается фундаментом, но к нему добавляются Model Governance, AI Risk Management и слой, который поставляет AI-ready данные в ИИ-системы.

Меня зовут Екатерина Яковлева, я руковожу центром DataGov группы компаний МТС. Сегодня поговорим о том, как поменялись привычные подходы в DataGov и что с этим делать. На основе моего опыта внутри MWS разберем, как понять, какие ИИ-инструменты уже живут в компании, сколько стоит один запрос, что можно смело отдать агентам, а что лучше оставить за человеком.

Открытых данных по загруженности парковок в мире на удивление мало: самый известный набор охватывает 30 парковок за три месяца 2016 года. Мы полтора года опрашивали открытый API Департамента транспорта каждые полчаса и выкладываем накопленное: 4 684 084 замера по 210 муниципальным парковкам, CC BY 4.0. Внутри — схема, примеры на pandas и DuckDB и честный раздел про то, что в этих данных сломано: 39 парковок из 210 не отдают занятость вообще, а счётчик инвалидных мест однажды показал 9979 свободных мест там, где их два.

Как‑то я захотел кошелёк Monero с нормальным веб‑интерфейсом, но без компромиссов по ключам: чтобы он работал на моей машине, ходил в мой узел и не притворялся кастодиальным сервисом. Писать криптографию самому — плохая идея, поэтому вся работа с ключами осталась за официальным monero-wallet-rpc, а на мне была «всего лишь» оболочка: бэкенд, интерфейс и куча инфраструктурной логики, которая внезапно оказалась самой интересной частью задачи.

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

Бот получает свечи бессрочных контрактов, отмечает зоны на 15-минутном графике и ждёт возврата цены. Если на закрытой пятиминутной свече появляется пинбар с касанием зоны, бот отправляет график и ориентиры по цене.

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

Код прикладываю на github - можете пользоваться и модернизировать!

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

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

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

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

По данным того же hh, в августе 2026 года число активных вакансий оказалось на 13% ниже, чем год назад, а число активных резюме на 22% выше, hh индекс, показывающий отношение активных резюме к вакансиям, вырос до 8,7.

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

В одном из тестов моего humanizer-ru оценка “машинности” ответа упала с 0,95 до 0,10. Сам ответ при этом не изменился ни на букву: “Столица Австралии - Канберра”. Из файла убрали строки вокруг него, включая название чат-бота.

В другой паре тексты отличались лишь переводом строки в конце файла. Оценки всё равно разошлись: 0,9 и 0,3.

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