К разговорам про падения интернета прекрасная картинка в Reddit'а и для полноты картины нехватает только регуляторов некоторых стран которые вносят свой неописуемый вклад в происходящее.

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

#thoughts

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

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

Внимание вопрос? Должны ли конкурсы ограничивать прием работ сделанных ИИ или выносить их в отдельные номинации? Как вообще теперь проводить конкурсы ?

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

Вопрос как все будет меняться?

#thoughts

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

Вот несколько примеров:
- Роботизированные спамеры и скамеры. Одна из бед открытых каталогов данных со свободной регистрацией пользователей и публикацией данных в какой-то момент стало бесконечное количество спама. Например, на порталах на базе CKAN открытая регистрация была прописана по умолчанию, в какой-то момент спамеры и скамеры понаписали скриптов которые регистрировали сотни тысяч аккаунтов и от них постили все что только разрешалось: создавали группы, профили организаций и карточки датасетов. Все фэйковые конечно, но в результате многие открытые порталы оказались забиты низкокачественным SEO мусором или, хуже того, откровенным скамом. Живой пример у меня перед глазами портал открытых данных метеослужбы Туниса. Там зарегистрировано более 1.3миллиона аккаунтов пруф потому что они не стали ограничивать регистрацию и поэтому у них у них более 45 тысяч спам текстов в одном из разделов. Из-за этого открытость порталов посвященных открытости приходится ограничивать, мы позакрывали регистрацию во всех своих основанных на CKAN порталах открытых данных именно по этой причине.

- Специализированный спам. Если ты активно публикуешь открытый код, ведешь активность на Github то рано или поздно, но скорее очень рано на тебя посыпется специализированный спам который можно разделить условно на 2 типа:
1-й - "Мы тут увидели что Вы добавили в избранное такой то open source проект, а у нас очень похожий, обязательно зайдите и посмотрите на нас и может быть используйте и добавьте в избранное"
2-й - "Чувак(-иха) у тебя столько активности в твоем аккаунте, зарегистрируйся в нашем сервисе где мы сводим больших работодателей из США и крутых программистов"

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

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

#thoughts #opendata #opensource

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

Этих скриптов много, штук 20, они последовательно:
1. Выгружают справочники, списки показателей и метаданные из статистических баз
2. Выгружают первичные данные, обычно JSON или CSV
3. Преобразуют первичные данные в файлы parquet
4. Загружает файлы parquet в аналог даталэйка
5. Готовит карточки датасетов для загрузки в индекс Dateno

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

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

И вот что я могу сказать, по итогам:
1. Copilot для этого просто неудобен, фактически с задачей такого рода он не справляется.
2. Cursor 2.0 лучше, но все равно код недостаточно функциональный, преобразование в библиотеку для Python из скриптов случилось плохо
3. Antigravity выдал если не хороший, то приемлемый результат с систематизацией настроек под каждую платформу и возможности вызова отдельных команд. Сами команды могут содержать ошибки, но это уже нормально, это уже итеративная работа по приведению этого кода в порядок

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

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

#thoughts #ai #coding

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

У меня есть как минимум две таких базы данных которые можно перевести в режим декларативной сборки набора данных и обогащение с помощью ИИ, это:
1. Реестр всех госдоменов в РФ используемый для цифровой архивации
2. Большой каталог всех межгосударственных структур (ОЭСР, ООН и тд.) с привязкой к странам и тд.

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

А вот второе я веду уже лет 10, но года 4 уже не обновлял. Это штука регулярно необходимая для мэппинга разного рода объектов - данных, текстовых материалов и не только.

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

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

К примеру, реестров стран в мире не меньше нескольких десятков. Когда надо мэппить разные объекты на страны чаще всего используют реестр стран ООН, ISO 3166, справочник Всемирного банка, справочник геослужбы США и несколько частных проектов с открытым кодом. Внутри Dateno активно используется python библиотека pycountry, но это не единственный и не идеальный способ.

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

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

#opendata #opensource #thoughts

В качестве легкого оффтопа как человек искренне нелюбящий звуковые сообщения в WhatsApp, Telegram и тд. не могу не отметить что для тех кто в России или тем кто звонит в Россию они могут быть выходом на фоне блокировок РКН.

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

#thoughts #telegram

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

Вот краткие синопсисы некоторых идей:
1.Анти-ИИ терроризм. Группа пострадавших от ИИ людей планируют атаку на электростанции питающие крупнейшие датацентры. Для планирования они тоже используют ИИ, в виде открытой модели со снятыми с неё ограничениями. После успешной, но фатальной атаки они все погибают, а многие глобальные ИИ сервисы отключаются. В финальных кадрах показан офис некой восточноазиатской компании в которой несколько человек обсуждают можно ли заложить в открытую ИИ модель определенные ответы на вопросы и подталкивание к конкретным шагам, а также о том как и как можно подкинуть инструкцию по снятию ограничений потенциальным террористам не выдавая себя.
2. Автономные роботизированные поселения спасают человечество. Человечество не смогло удачно доставить людей на Марс и переключилось в создание автномных роботизированных поселений на Марсе где с помощью централизованного ИИ должны быть созданы условия для прилета людей в поселение где уже будет еда, вода и жизненная среда. Для проверки идеи на Земле создают сотни таких автоматизированных поселений в местах, как правило, плоходоступных и с суровым климатом. Когда наступает апокалиптичное событие (падение астероида, глобальная пандемия или зомби-апокалипсис) то эти поселения оказываются единственным убежищем позволяющем малым группам человечества выжить.
3. Неубиваемый ИИ вирус. Основанный на ИИ вирус захватывает компьютеры и электронные устройства, использует децентрализованное фрагментированное хранение для распространения и накопления украденных данных/реквизитов/паролей и zero-day уязвимостей которые он также находит автономно. Заканчивается все постепенными блокировками любых коммуникаций между странами и отдельными территориями и методичная работа по вычищению. Расходы коллосальные и мир в глубоком шоке, рассказ от лица человека живущего изолированного в глуши и приютившего один из оставшихся экземпляров вируса в умном холодильнике

#thoughts #ideas

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

Есть три основных категории пользователей и у каждой из них свой набор ожиданий :
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