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

Есть три основных категории пользователей и у каждой из них свой набор ожиданий :
1. Аналитики
- максимальная оперативность данных
- доступность данных в форматах привычных для работы (CSV, XLSX)
- возможность доступа к данным аналитическими и No code/Low code инструментами
- наличие данных по ключевым наиболее значимым темам (официальная и ведомственная статистика, например)

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

3. Разработчики и дата инженеры
- доступность данных через API
- доступность данных для массовой выгрузки (bulk download)
- доступность схем и структур данных
- наличие данных в современных форматах для выгрузки: сжатые CSV, Parquet и др.
- наличие предсказуемой инфраструктуры для интеграции с ETL/ELT системами получения данных
———
У этих 3-х групп есть ряд подгрупп которые имеют свою специфику:
- журналисты. Имеют те же требования что и аналитики, с меньшим погружением в технологии, с большим погружением в доступность данных.
- AI/ML инженеры. Помимо ожиданий разработчиков и дата инженеров у них еще присутствует потребность именно в данных большого объема для обучения, интегрируемость в стеки данных и интегрируемость в продуктами вроде Hugging Face
- статистики. Это не только сотрудники статслужб, но и профессиональные пользователи их данных. Они могут быть аналитиками и исследователями и тут важным становится наличие значимых метаданных и специальных стандартов и форматов SDMX, DDI и тд.
- геоаналитики и георазработчики. Подгруппы аналитиков и разработчиков с упором на геоданные, ключевое здесь это наличие возможности поиска данных по геопривязке, получению их в форме стандартизированных API ArcGIS/OGC и возможность выгрузки в наиболее востребованных форматах геоданных
—
Пользователь может быть в одной роли или хоть сразу в нескольких, важно то что любые публикуемые данные и создаваемые дата каталоги можно четко разметить по их потенциальным пользователям.

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

К примеру, когда я ругаюсь в адрес российского портала data.gov.ru, то могу объяснить это довольно просто. Можно посмотреть на него глазами любой из перечисленных ролей/групп пользователей и убедиться что для их задач он непригоден.

#opendata #users #thoughts #data

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

К примеру, работа с помощью ИИ с законодательными текстами. Писать сейчас нормативные документы с помощью ИИ может оказаться очень рискованной затеей (судебные решения сгенерированные ИИ пока рассматриваем как курьёз и дефицит квалифицированных кадров). Потому что галлюцинации, потому что отсутствие какой-либо ответственности за ошибки и так далее.

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

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

Применительно к состоянию дел с российским законодательством включая решения исполнительной власти я вангую что такой валидационный инструмент если и напишут, то скорее технически грамотные люди имеющие критичный взгляд на происходящее в российских законах. Тогда это станет не техническим инструментом, а скорее медийным продуктом с автоматическим подробным анализом законопроектов и принятых НПА. Приведет ли это к качественному улучшению российского законодательства я не знаю, но усилению кризиса восприятия российских ФОИВов и законодателей как серьёзных нормотворцев может.

#thoughts #ai #aiagents #laws #lawmaking

Картинка из обзора изменений торговли Китая из Our World in Data. Она, с одной стороны наглядная, а с другой если бы я делал визуализацию по реальным изменениям в торговле Китая я бы сравнивал цифрами не только по числу стран где Китай стал главным торговым партнером, но и по многим другим параметрам.

Например, рост влияния можно измерить по измерению совокупной доли ВВП стран где Китай стал основным торговым партнером, по изменению влияния по блокам стран не только континентальным, но и экономическим: ЕС, АСЕАН, ЕАЭС, НАФТА, Меркосур и др.

Для того чтобы такое измерять можно применять все тот же код internacia-db который я недавно заопенсорсил для Dateno и где он уже используется.

Вообще один из моих любимых проектов по визуализации международной торговли это OEC (The Observatory of Economic Complexity).

А можно было бы уже создать Обсерваторию экономической зависимости [от Китая], как отражение изменений в мировой экономике в динамике.

#dataviz #china #thoughts #economics #trade

Хорошая картинка (подсмотрена в интернете) существующая в куче вариаций где вместо Undocumented code часто встречается "Tom with documentation in his head" но в целом это системная ситуация когда компании придумывают ИИ стратегии, а они упираются в проблемы текущих процессов, текущих информационных систем и огромные запасы legacy существующего в режиме "работает - не трожь!" которое приходит время потрогать, а трогать то боязно.

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

В частности:
1. Активное применение ИИ для документирования кода и приведение legacy кода в порядок. Стоимость этих задач падает постоянно и уже не представляется безусловным кошмаром
2. Применение ИИ агентов для архитектурного перепроектирования интеграции, конвееров данных и унаследованных систем
3. Применение ИИ агентов для формирования итоговых вариантов стратегии ИИ для клиентов (как кусочка более полной ИИ стратегии) на основе всего этого вместе взятого.

Но начинать надо с недокументированного кода и эта задача как раз с помощью ИИ решается вполне реалистично, но Том с документации в голове останется без работы и поэтому это и есть первоочередная задача.

И это касается не только корпоративных ситуаций, но и многих других. Должны ли быть принятые ИИ стратегии у всех госорганов и многих крупных госучреждений? Должна ли резко упасть стоимость разработки государственных информационных систем? Ответ - да, безусловно.

#thoughts #ai #aiagents #legacycode

Ещё в продолжение правильного применения ИИ агентов, я системно занялся реестром каталогов данных в Dateno, я уже писал про предыдущее масштабное обновление, но это далеко не все. Основное обновление было про добавление большого числа каталогов данных. и их стало сильно больше.

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

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

В общей сложности на 12281каталогов данных приходится 85956 ошибок, много, да? Потому что правила валидации весьма скурпулёзные и 49 тысяч из них - это проверка точек подключения к API (у одного каталога данных может быть до двух десятков таких API содержащих разные метаданные и данные).

Другие частые ошибки в отсутствии информации о лицензии каталога данных (она не всегда есть на уровне каталога, чаще лицензии указываются на уровне набора данных внутри, поэтому это корректируемое правило) и в отсутствии внешних идентификаторов у каталогов данных - это мэппинг каталогов данных на Wikidata и другие референсные источники, но тут важно знать что у большинства каталогов данных нет этих референсных источников и сам Dateno ими является.

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

Что важно что все отчеты по качеству данных специально генерируются таким образом чтобы их можно было читать и править самостоятельно или же отдавать ИИ агенту командой примерно такого содержания "Fix issues listed in [название файла]"

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

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

Они включают:
- проверку и правку кода в части стилистика и линтинга (а ля pylint и аналоги для Python)
- подготовку и обновление тестов
- обновление документации (минимальное или весьма комплексное)
- acceptance тестирование (и другие виды тестирования при необходимости)
- сборка и релиз на Github/Gitlab/другой способ управления кодом

Многое из этого вшито в CI/CD пайплайны, но многое из этого может быть ИИ автоматизировано. Вопрос может ли это быть автоматизировано в IDE на стороне пользователя и пройти ручную финальную проверку или вынесено в CI/CD на внешнем сервисе и ручная проверка необязательна.

Мои ощущения что это скорее расширяемые модели контролируемых сценариев/строительных блоков внутри IDE с обязательными стадиями ручного контроля.

#thoughts #dateno #datacatalogs #dataquality

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

Это архивация. В сравнении с телеграмом у Max'а есть два очень существенных отличия:
1. Отсутствует возможность просматривать содержание каналов онлайн без авторизации
2. Отсутствует возможность делать data takeout хотя бы для своих данных, а в идеале и для любых каналов и чатов

Первое влияет на то что содержание из Max не индексируется поисковиками и Интернет Архивом (они собирают только общедоступные матералы доступные через https/http). К примеру, в телеграм можно смотреть без авторизации, вот так выглядит там мой телеграм канал https://t.me/s/begtin

Второе на то что невозможно сделать архив ни своих чатов, ни своих каналов, ни читаемых каналов. Просто не предусмотрено.

В итоге Max - это закрытое контролируемое не архивируемое пространство где даже чтение постов прошедших авторизацию каналов идет только под контролем (только после авторизации) даже в веб клиенте.

Вопрос остается в том будет ли там хоть что-то полезное, не продублированное в Телеграм'е? Насколько реально велик риск блокировки телеграма в ближайшее время и переход части авторов каналов туда?

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

#digitalpreservation #thoughts

Множество предсказаний о журналистике в 2026 году https://www.niemanlab.org/collection/predictions-2026/ на сайте Nieman Lab

Многое про технологии и ИИ, есть даже про API для новостей. Для дата журналистов может быть полезным.

#thoughts #readings #journalism

Рассеянные мысли про разное:
1. В продолжение когнитивных искажений или искажений восприятия в наблюдениях последнего времени часто встречаю ещё два случая:
- декларативизация всего что возможно, иногда в форме YAML'ификации, когда декларативное описание (в сформе структурированного описания конфигурации) кажется панацеей для всего. Панацеей оно, конечно, не является и даже вызывает раздражение у многих разработчиков, но становится удобным при использовании ИИ агентов которые как раз такое декларативное описание понимают очень неплохо.
- маркдаунизация всего и вся, ловлю себя на том что стало неудобно писать тексты в Word'е, совсем неудобно, все время хочется использовать синтаксис маркдауна. Кроме того для скармливания объектов ИИ также часто преобразование в Markdown кажется более логичным чем во что-то другое.
2. По прежнему жизненно не хватает продвинутых инструментов управления контактами, такое ощущение что они вымирают и ни один из крупнейших сервисов не дает удобного API для их обогащения. Например, для управления контактами в Google нужно оттанцевать много с бубном чтобы добавить/изменить контакт автоматически. Когда у тебя пара сотен контактов - это не проблема, когда несколько тысяч - уже ощутимо.

#thoughts

В продолжение рефлексии про применение ИИ агентов в разработке. Мои личные ощущения от применения для различных задач.

Документирование. Почти на 100% закрывается с помощью ИИ агентов, при условии что сам код ясно написан и в коде документация присутствует (в Python это обязательные docstrings). Как простая документация так и сложная генерируется без излишних сложностей, но как и код её необходимо тестировать промптами в условном стиле "проверь что все примеры упомянутые в документации являются рабочими" (в реальной работе немного сложнее, но и так можно).

Тестирование. Около 90-100% тестов кода могут генерироваться автоматически, остальное с некоторой помощью. Закрывает практически все общепонятные ошибки связанные с особенностью языка и его стилистики. не закрывают какую-либо сложную логику работы с не самыми очевидными продуктами, устройствами, интеграцией и тд.

Исправление ошибок. По ощущениям эффективности уже в районе 50-80% (до 8 из 10 задач выполняются сразу правильно, без необходимости корректироки). Практически все задачи линтинга кода и большая часть задач исправления ошибок по итогам неудачных тестов. Наиболее часто несрабатывающие исправления касаются взаимодействия с другими сервисами, серверами, параллельно разрабатываемыми продуктами.

Генерация кода. Варьируется от 40% до 70% эффективности, чем более комплексная задача тем хуже результат в виде кода. Простые задачи умеют хорошо делать уже почти все ИИ агенты, сложные часто приводят к переусложненному коду. Например, в качестве теста я делал REST API поверх написанного на Python SDK. Cursor при его реализации начал ваять сложный промежуточный код для обработки данных и преобразования типов хотя все то же самое можно было бы сделать значительно проще простыми исправлениями в оригинальном SDK. Вот эта вот контекстность в решении проблем это особенность ИИ агентов. Они пока не предполагают что решения проблем могут быть за пределами рассматриваемой ими кодовой базы.

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

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

#thoughts #ai

У меня есть довольно давняя отложенная нерабочая задача - это извлечь с каталога музейного фонда РФ (goskatalog.ru) материалы по армянскому культурному наследию для чего я когда-то выгружал с портала данных Минкультуры РФ битый датасет этого реестра и преобразовывал 88ГБ текстовый файл в 2.7ГБ файл Parquet с 31.7 записями о культурных объектах. А также есть примерно 100 регулярных выражений позволяющих найти записи в которых есть прямое или косвенное упоминание Армении или армянской культуры.

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

А теперь о подходах как такую задачу можно решить.

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

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

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

Экономное хардкорное программирование. Обращаешь внимание что регулярные выражения - это медленно почти всегда и на то что не все поля в оригинальных данных нужны. Оптимизируешь и пересобираешь оригинальный файл с данными так чтобы он содержал только id записи и поля с нужными текстами, переписываешь регулярные выражения на pyparsing или разворачиваешь их в текст для полного мэтчинга и, конечно, тоже разрезаешь файл с данными на 100 (или сколько нужно) и параллельно запускаешь обработку не обязательно на продвинутом железе. Думаешь о том не переписать ли все это на Rust

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

Поиски волонтера. Описываешь целесообразность и нужность задачи в виде мини ТЗ. Закидываешь с сообщества где могут быть потенциальные волонтеры готовые ее решить. Задача не самая сложная, не самая простая, как раз по силам.

Вайб-кодирование. Описываешь эту задачу ИИ агенту и он за тебя генерирует код (скорее всего не самый высокопроизводительный) и дальше уже по аналогии с ленивым программированием

Продвинутое вайб кодирование. Ставишь задачу нескольким ИИ агентам и сравниваешь результаты. Долго тюнишь лучший из результатов уточняющими запросами по оптимизации кода.

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

#thoughts #programming #dataengineering