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

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

Тем не менее хорошие идеи там тоже есть и посмотрим куда автор свой проект будет развивать.

#opensource #opendata #datacatalogs

Allemannsdata коллекция MCP сервисов для 24 API/сервисов открытых норвежских данных. Хотелось бы сказать что сделано норвежским правительством/министерством цифры, но нет, это инициатива одного разработчика.

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

А вообще вот вам пример потестить навыки, берете открытое госAPI или большой датасет и делаете над ним открытый MCP сервис. Почему нет?

#opensource #API #AI

Как обеспечивать доступность данных для пользователей внутренних или внешних?

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

Когда сталкиваешься с существующими инструментами с помощью которых можно опубликовать данные и делать их доступными очень быстро появляется желание придумать свой велосипед. Я лично такой велосипед придумывал делая команду api serve в утилите undatum, а до этого делая утилиту apicrafter для автоматического создания API поверх баз MongoDB.

А кроме этого существует такой фрейморк как roapi, существует API в каталоге данных CKAN для доступа к структурированным данным, есть возможность публиковать данные просто в дата каталогах как файлы и тут уже выбор большой - CKAN, DKAN и тд. Для геоданных есть ещё GeoNode и Geoserver и все они так или иначе дают интерфейсы для доступа к данным. Плюс есть множество коммерческих провайдеров ArcGIS Hub, HuWise, DoltHub и другие, но их так просто в свой технологический стек не положишь без проприетарной зависимости.

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

Старые способы вообще не про каталоги данных, а про правильно организованные доступы для массовой выгрузки, еще на FTP серверах где все организовано по папкам и подпапкам рассортированным по схемам данных, с полными дампами и инкрементальным доступом. Хорошо работает для массовой выгрузки, плохо для всего остального.

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

В итоге оказывается что для внутренних пользователей самые простые способы в том чтобы загружать данные в таблицы в СУБД и давать пользователям доступ туда на чтение, а документацию предоставлять через каталоги метаданных вроде OpenMetadata или Datahub. Это такой SQL-first подход, удобный для внутренних задач сильно ограничивающий в предоставлении внешним пользователям. Для внешних пользователей все равно необходимо сооружать API, экспорт для массовой выгрузки (и он не должен быть динамическим) и экспорт документации в некий внешний формат/сайт. Чаще всего разработчики делают отдельное внешнее API заточенное под эти данные, реже более универсальное с GraphQL или OData.

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

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

Сейчас чуть ли не единственным продуктом который можно использовать как Headless DMS является CKAN, при том что у него огромные ограничения по масштабированию, объёмам поддерживаемым данных и управлению правами доступа.

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

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

Вот такие мысли вслух про создание каталогов данных и доступе к данным через API.

#opendata #datacatalogs #thoughts

Reuters пишут о том что власти Китая собрали местные AI компании/стартапы и обсуждали ограничения на наиболее продвинутые модели для не-китайских пользователей. Звучит очень похоже на то что происходит в США с ограничениями на последние модели от Anthropic и OpenAI с той лишь разницей что открытые китайские модели сейчас стремительно набрали популярность и ограничения на их доступность затронут многих.

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

В целом в мире сейчас ситуация такая что есть два центра (две юрисдикции) откуда исходят наиболее продвинутые ИИ модели - это США и Китай и в обеих этих юрисдикциях безопасность выходит на первый план. А это может повлиять и на скорость выхода новых моделей, и на попытки построения агентских продуктов которые ограничения моделей могут/будут пытаться преодолевать, типа Sakana AI и еще на многое другое.

#ai #thoughts

Я тут задумался над одной из главных проблем большей части проектов/порталов с открытыми данными. Они очень редко существуют в понятиях дата продуктов (продуктов данных). Хотя, по своей сути, являются их подвидом. Должны бы являться, в каком-то идеальном мире.

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

Гораздо ближе к дата продуктам коммерческие порталы с данными, отдельные госпроекты где доступность данных - это одна из форма доступа к ним и коммерческие дата продукты.

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

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

Картинка для привлечения внимания, честно переведена с помощью LLM, а тут первоисточник

#opendata #ai #thoughts #dataengineering #datacatalogs

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

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

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

#data #thoughts

Не про данные, но про российскую действительность.

Оказывается внезапно Google удалили приложения VK и Max из Google Play и столь же внезапно VK продают RuStore своему менеджменту. Логика в обоих случаях понятная. Google соблюдают санкции ЕС, а VK пытаются их обойти перерегистрировав значимое приложение на физ. лиц. В случае этой перерегистрации ИМХО это не поможет потому что все слишком очевидно и санкции вводятся слишком быстрыми итерациями чтобы это помогло надолго.

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

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

#russia #vk #sanctions

Magic Extractor open source инструмент для извлечения содержимого из большого числа разных форматов образов дисков, архивов и иных цифровых контейнеров. Автор пошел по пути охвата как можно большего числа форматов и сам инструмент явным образом написан под Windows и идентификацию файлов в непонятных форматах.

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

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

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

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

#opensource #tools

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

Текст большой и подробный, ключевые выводы такие.

1. Возможности ИИ продолжат расти. Уже в 2026 году системы действуют весьма автономно и превосходят экспертов в отдельных областях. К 2030 году ожидается ещё большая автономность и способность выполнять более широкий круг когнитивных и профессиональных задач — даже при замедлении темпов прогресса рост возможен за счёт лучшей интеграции и «упаковки» существующих систем в продукты.

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

3. Без вмешательства государства ИИ может привести к серьёзному, в том числе экзистенциальному, вреду. Усилятся существующие риски и появятся новые: кибератаки с использованием ИИ, его «двойное назначение» в науке, выход систем из-под контроля человека, зависимость людей от ИИ. По мере роста возможностей систем оценивать их безопасность и эффективность станет сложнее.

4. Существенное влияние на когнитивный труд. К 2030 году возможно значительное вытеснение рабочей силы, но одновременно ИИ будет дополнять и усиливать часть работников, положительно влияя на их зарплаты и карьерные возможности. Даже при более скромных сценариях характер труда изменится: рутинные, исполнительские задачи будут всё активнее автоматизироваться.

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

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

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

#ai #readings #uk

Feasibility study European Books Data Commons еще один интересный документ для чтения, техническое обоснование создание корпуса книг / датасетов на основе книг в библиотеках Евросоюза. Называется EBDC (European Books Data Commons). В тексте смешение технической реализации и смысловых обоснований зачем это нужно и как это можно организовать, включая интеграцию с Europeana, создание корпусов текстов, датасетов и есть какое-то количество примеров подобного в мире, в основном несколько проектов в США.

Собственно основное там - это массовый OCR с помощью VLM (Vision Language Model) и основные расходы идут на компьютеры с GPU для этой задачи.

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

#opendata #europe #books

Я на днях смотрел внимательнее на новые китайские модели: GLM-5.2, Kimi 3, LongCat 2.0 и скажу что, конечно, большой соблазн использовать их гораздо чаще потому что прогресс виден и экономия существенная.
Мои наблюдения следующие:
1. С задачами кодирования китайские модели справляются весьма неплохо. Если поставить задачу анализа репозитория, исправления ошибок или реализация понятных и четко сформулированных задач, то подходят они более чем. При этом токенов они тратят существенно больше, но и токены стоят дешевле.
2. А вот с задачами создания баз знаний гораздо лучше работают последние модели OpenAI 5.6 и Fable 5. Точно также как и с архитектурными задачами и задачами сравнения с конкурентами. По ощущениям к ним приближается Kimi 3, но в целом когда мне надо было сделать сравнительно небольшую базу знаний, то OpenAI 5.6 во всех вариациях справляется лучше.
3. В целом ощущения что все быстро меняется, все меньше критических ошибок, меньше галлюцинаций и для приведения в порядок унаследованного кода китайские модели более чем подходят. А вот когда надо спроектировать продукт или сделать сложную миграцию кода то лучше использовать OpenAI и Fable.

#ai #thoughts #notes

В продолжение предыдущих размышлений про LLM модели и их применение меня всё чаще посещает что среди основанных на ИИ (LLM) инструментов пока нет (мало) инструментов для создания документации.

Например, для дизайна есть Claude Design и Open Design, оба довольно продвинутые инструменты. А для документации есть только онлайн платформы вроде Mintlify или Notion в которые встроена генерация текстов с помощью ИИ, но это делает тебя зависимым от этой платформы.

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

У меня есть личное предположение что тут может быть отдельный инструмент вроде того же Open Design, но для документации. Способный создавать контент по четким структурным шаблонам под разные платформы, продукты и так далее. Под Docusaurus, под Mkdocs, интегрированный с Mintlify и другими облачными провайдерами и так далее. Использующий ИИ также как это делает Open Design.

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

Что было бы важно в таком продукте:
1. Уметь создавать документацию под разные задачи в разных форматах - разные вики, PDF, MS Word и тд. Базово в Markdown со сборкой в нужный формат при необходимости.
2. Уметь оценивать автоматически качество документации по полноте и другим критериям.
3. Уметь формировать документацию по полученным вводным: начальным материалам, промптам, предоставленны документам, изображениям, коду и так далее
4. Уметь работать по шаблонам в зависимости от того на что документация создается: SaaS продукт, настольное приложение, клиентское приложение, дата продукт и тд.

Наверняка тут можно еще немало чего добавить.

#thoughts #documentation #aiagents

Добавлю ещё некоторое количество рефлексии по использовании LLM и ИИ агентов для создания базы знаний.

1. После некоторого числа экспериментов действительно Kimi K3 можно сравнить с последними моделями OpenAI и Anthropic. Созданные ей карточки в базе знаний куда более полные чем, к примеру, созданные с помощью GLM-5.2 или моделями попроще. Это важно поскольку существенно удешевляет процесс.
2. По наблюдениям наиболее эффективен двухэтапный процесс с human-in-the-loop. Вначале делать промпт на создание промпта, далее, делать его ревью и редактировать, при необходимости. и следующим шагом уже полученный промпт отдавать LLM. Первый этап можно делать и моделью попроще вроде той же GLM-5.2, а второй куда лучше отрабатывает уже более продвинутая модель. По сути это путь двухэтапного анализа поскольку при формировании комплексного промпта модель делает предварительный анализ объекта документирования.
3. Главный недостаток такого подхода в том что он существенно удлиняет процесс подготовки базы знаний, примерно в 2-3 раза и дублирует многие шаги потому что и, на предварительном анализа, и на финальном, идёт обращение к одним и тем же объектам. Например, если на вход поступает какой-то раздел сайта с набором тематических документов, то они скачиваются дважды. Может быть на стадии подготовки промпта не все, но тем не менее когда качество результата важнее скорости это лучший подход.
4. Что хорошо - это работает с любыми цифровыми объектами. Сайтами, датасетами, документами и коллекциями документов, API, текстами в иной форме, базами данных и так далее. Например, если бы я хотел не просто собрать базу данных межгосударственных организаций, но и сделать базу знаний по ним, то я сейчас вполне понимаю как это можно организовать структурно и технически. (оговорюсь - планов создавать такую базу знаний у меня пока нет).

#thoughts #ai #documentation