Я вчера практически весь день провел на CAIGF (Central Asian Intenet Governance Forum), говорил, как всегда про данные, рассказывал немного про Dateno и Open Data Armenia, про дефицит открытых данных в странах Центральной Азии, сильном сдвиге публикации данных в сторону ИИ, в том что важно устанавливать приоритет на дата продукты и о том что вне зависимости от того открыты данные или нет, должны быть доступны метаданные и четкие условия доступа к данным разного типа, от полностью открытых (открытые данные под свободными лицензиями) до доступных ограниченному числу пользователей по четким регламентам.

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

Мысли которые я лично вынес с этой конференции:
1. В Центральной Азии наблюдается либерализация доступа к Интернету, и даже если есть ограничения, то с нынешними российскими они не сравняться.
2. Есть явный дефицит национальных данных и относительно ограниченные возможности государств его восполнять, но это не непреодолимый барьер, а скорее ситуация у которой может быть разумное развитие.
3. Российское присутствие есть только через глобальные компании которые продолжают экспансию в страны где у них нет ограничений, но государственное присутствие минимально. Условно российский Гостех не имеет там перспектив хотя бы потому что в большинстве стран уже либо свои продукты, либо идет внедрение X-Road (изначально эстонский продукт шины обмена данными между госорганами)
4. В каких-то аспектах цифровизация идет быстрее чем в России или в странах ЕС и во многом это из-за меньшего груза традиций бумажного документооборота и экономии.
5. ИИ внедряется повсеместно с ИИ моделями и продуктами, или от глобальных игроков, или модели открытого кода.

#opendata #data #conferences #centralasia #thoughts

Ещё один симпатичный продукт в стиле Dashboard-as-a-code, он так и называется dac. Это тип продуктов в которых содержимое и стиль отображение графиков и других элементов дашбордов задается декларативным программированием, обычно YAML файлами.

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

А dac сделан командой bruin, разработчиков одноименного ETL движка и сервиса для создания дашбордов с помощью ИИ ассистентов.

Собственно и в dac нет зависимости от dbt, но есть зависимость от bruin.

Почему такие инструменты полезны? инструменты вроде dashboard-as-a-code легче поддаются ИИ разработке и автоматизации.

Среди продуктов такого класса можно вспомнить ещё Evidence, Holistics, GoodData

#opensource #datatools

Где ИИ инструменты были бы полезны и где их нет. Автоматизация работы с почтой

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

У меня более 31 тысячи писем в основном почтовом ящике и около 8600 во втором и по нескольку тысяч в других. Даже при том что я придерживаюсь практики zero inbox, в нем, все равно, накапливается до 300-400 писем в входящих. И тут кажется что совершенно естественно применять ИИ ассистента который бы по команде умел бы структурировать и каталогизировать входящие письма. У Google есть встраивание Gemini в Gmail, но проблема в том что Gemini там на все запросы выдает инструкции и ничего сам не делает.

Есть внешние инструменты вроде Manus которые умеют подключаться к Gmail и даже писать код который разметит и рассортирует все письма или подключение ChatGPT к Outlook Email, но совсем не хочется давать доступ внешнему сервису к своей почте. Тем более поскольку нет желания обучать его на своих письмах.

Я подозреваю что такие ассистенты для почты постепенно появляются внутри наиболее массовых продуктов (тот же Gemini внутри Gmail), но пока недостаточно хорошо. А стартапы вроде Superhuman Mail или Inbox Zero, ИМХО, имеют мало перспектив поскольку экосистемы вроде Google или Microsoft сильно выигрывают.

Кроме того есть ощущение что интерфейсы к почте используемые ИИ ассистентами, мягко говоря, неэффективны. Обработку почту внутри самого сервиса можно было бы колоссально оптимизировать использовать внутреннее API.

Подозреваю что, всё таки, все пойдет скорее по пути стыковки ИИ агентов крупных AI BigTech'ов со своими аккаунтами и управление через них с разными защитными механизмами вроде обязательных бэкапов и тд.

#ai #thoughts #email #productivity

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

#opendata #moscow #russia

Я только-только хотел написать что блокировки VPN уже не столько и не только убивают российскую ИТ отрасль, как оставшуюся, пока что, в живых науку, как нашел текст в канале Алексея Хохлова в котором про то же самое.

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

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

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

Не буду расписывать в подробностях к чему это приведет, но точно не к тому что спрос на доступ в Интернет куда-то исчезнет.

#thoughts

Я тут было хотел в очередной раз "пнуть" российский портал открытых данных data.gov.ru, на предмет его бессмысленности, но посмотрел там раздел новости понял что всё, похоже он обречен. Даже нерелевантные новости Минэка там не обновляются с октября 2025 года, а релевантная вообще была только одна, о запуске портала в июле 2025.

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

#opendata #russia #thoughts

Где-то в начале 2026 года, точную дату сейчас сложно установить, закрылся портал проекта OneGeology https://portal.onegeology.org/ (ссылка сейчас не работает) и с анонсом что возможно летом 2026 года его передадут от Британской геологической службе аналогичной службе Японии. При этом их каталог геоданных еще доступен (1111 наборов геоданных в каталоге на базе Geonetwork). Также остается доступным сайт самого проекта с техническими документами.

OneGeology существовал с 2008 года, и не то чтобы он был ключевым, но заметным ресурсом с геоданными. Посмотрим в каком виде он возродится.

#opendata #geodata #closeddata

Я [не так уж] недавно озадачился темой баз знаний и баз документов для работы с ИИ да и без него тоже и не то чтобы в восторге от того что есть в практическом использовании. Если посмотреть на то как об этом думают другие, например, Andrey Karpathy в его тексте LLM Knowledge Bases то там речь про связку Obsidian как личный инструмент редактирования и набор инструментов по поиску и обогащению материалов с помощью LLM.

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

Какие есть еще варианты связок редактор/интерфейс, LLM и тд. ?

Самый очевидный воспользоваться каким-нибудь Notion где AI встроен можно сказать естественным образом.

Есть еще OpenKB на базе PageIndex в котором вообще нет UI интерфейса, но есть возможность делать запросы с командной строки. Веб интерфейс это не проблема, можно поднять один из Markdown wiki продуктов вроде Docusaurus, но сам подход выглядит так:
добавляешь документ в любом формате -> он преобразуется в Markdown -> Markdown индексируется в базу знаний - > можно задавать вопросы естественным языком.

Карпатый в своих рассуждениях еще упоминал qmd любопытный тул как раз для такой базы знаний.

Я про все это тоже думаю, сразу в контексте 3-х близких задач:
1. Личная база знаний, которая у меня как и у многих на базе Obsidian и к которой хотелись бы LLM возможности что называется из коробки, а не через разные *Claw.
2. База знаний для работы доменных экспертов когда есть пул специалистов в предметной области и они готовят материалы для обучения LLM под предметную область какой бы она ни была (кулинария, юриспруденция, поэззия и тд). Тут идеально если есть Вики инструмент, на том же Markdown'е. И в который раз можно лишь посетовать про дефицит структурированных вики, хотя есть тот же Outline.
3. Хранилище документов под очень большие объёмы, условно в миллионы документов, с тем что документы могут быть разного типа с разными профилями метаданных и также подключаемыми. У этого есть разные решения, от технических, все метаданные в индекс OpenSearch, а профили описывать в разными схемами в YAML, до концептуальных через создание онтологии и использование институциональных репозиториев вроде Hyrax, DSpace, Islandora и тд. Институциональные репозитории и библиотечные системы далеки очень от инженерных паттернов и не факт что это лучшее решение.

Может показаться что эти задачи отличаются, но вот мне представляется что они очень близки.

#thoughts #ai #documents

ProgramBench интересный проект и исследование из Meta про проверке способности LLM не просто программировать, но и проектировать архитектуру приложений.

LLM проверяются на способность воспроизвести приложения имея доступ только к исполняемому файлу и не имея доступа к документации, исходному коду и интернету в принципе.

Идея интересная со многих точек зрения.
1-я - это возможность воспроизведения проприетарных продуктов, реконструкция унаследованных приложений на новых технологиях. Угроза для огромного числа малых компаний софтверных разработчиков.
2-я - это возможность снятия лицензионных ограничений с open source с ограничивающими лицензиями. Например, есть продукт под GPL, а тебе нужен аналог под MIT лицензией. Это даже проще поскольку исходный код доступен.

Понятно что этот тест с утилитами работающими с командной строки и программными библиотеками пока что упрощенный, но дальше могут быть такие же тесты для GUI/UI/Web приложений, для драйверов, для многого другого.

#opensource #ai #thoughts

Почему я задумался про LLM Knowledge base и работу с базами знаний через LLM? У меня есть какое-то, немало количество материалов собранных из большого числа небольших записок и недописанных книг. Эти книги, изначально в формате лонгридов и страниц для Gitbook'а можно назвать существенными кусками (ядром) того что можно назвать доменной базой знаний, в понимании домена как очерченной предметной области.

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

Идеальный инструмент - это продукт работающий локально на компьютере или в локальной сети, позволяющий вносить знания по предпопределенным профилям и шаблонам, с визуальным редактированием и совместной работы от 5 редакторов. Самое очевидное тут Mediawiki/Wikibase, с оговоркой что там внутри не Markdown, что там очень консервативное API и интеграции, и с не менее консервативными инструментами метаописания и редактирования.

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

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

#thoughts #knowledge