Кстати, в продуктах AI Deep research не могу не отметить китайский Kimi от Moonshot AI. Есть некоторое количество стран по которым лично мне довольно сложно собирать аналитику, в первую очередь это восточная и юго-восточная Азия. К примеру, для меня давно была загадка о том как устроены геопространственные сервисы и данные в Китае и Японии. Из всех сервисов пока только Kimi выдал наиболее глубокие и продуманные отчеты со ссылками на порталы, вендоров, госполитику и тд. По Японии, например, я совсем не знал что там CKAN (движок порталов открытых данных) рекомендован в технологическом стеке правительства и применяется официально для геопространственной инфраструктуры страны как хранилище геоданных (через специальные расширения движка).

По Китаю отдельно много интересного. Конечно, и Kimi, и остальные сервисы покрывают лишь общедоступную часть спектра аналитики, но я вот отдаю себе отчет что реши я такой отчет заказать или если бы мне его кто-то заказывал, то стоимость его была бы на 2-3 порядка выше чем сделать с помощью ИИ агента.

#analytics #ai #china #japan

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

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

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

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

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

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

Предположим я хочу написать расширение для DuckDB которое бы позволяло делать SQL запросы к метаданным и данным в WARC файлах напрямую. Это могло бы сильно облегчить аналитику на их основе. Но у меня нет оптимального решения как это сделать и я задаю параллельно вопрос 5-6 Deep Research инструментам запрос на гайдлайн и далее уже изучаю их и выбираю дизайн спецификацию которую можно загрузить в Cursor или Antigravity или в другой инструмент.

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

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

P.S. Все это только пример рассуждений про DuckDB и WARC потому что в самом простом варианте такое расширение уже существует duckdb-warc, но оно малофункционально, откуда и взялась идея насколько хорошо можно сделать его альтернативу малой кровью.

#opensource #ai #warc

Актуальная научная статья на Arxive Buy versus Build an LLM: A Decision Framework for Governments о том покупать ли госорганам (правительствам) LLM или строить собственные. Авторы из разных институций связанных с ИИ, в первую очередь из сингапурских и поэтому, в первую очередь, приводят в пример сингапурский опыт создания государственных LLM, а ещё упоминают швейцарский проект Apertus, проекты LLM из ОАЭ для арабского языка и поддержку Mistral AI в Европе.

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

Почему это важно? Потому что консолидация ИИ инициатив внутри государств неизбежна и многие решения будут исключительно политическими. Например, если в Армении Пр-во захочет сделать ИИ ассистента для госслужащих или граждан то будет ли Пр-во создавать свою ИИ модель или будет разворачивать и инвестировать усилия в одну из существующих? Второй сценарий более вероятен и вот вопрос - какую LLM они используют: открытую китайскую? коммерческую из США? Mistral? российскую от Сбера или Яндекса?

Армения - это как пример страны у которой точно нет ресурсов на создание собственной фундаментальной LLM. Точно также можно рассмотреть Кыргызстан, Грузию, Азербайджан, Узбекистан. Может быть и Казахстан тоже. И это только если пройтись по постсоветским странам.

Вот видите, у меня тоже только вопросы и нет ответов.

#ai #government

Два свежих документа ОЭСР для внимательного чтения:
- The agentic AI landscape and its conceptual foundations систематизация терминологии, определений и основного понимания того что такое ИИ агенты, агентские ИИ и так далее. Не техническое, но концептуальное погружение в предметную область для регуляторов, руководителей и тд. Про технологии мало, про перевод с технологического профессионального на понятный язык - много. Полезно для всех кто ищет правильные определения и внутреннее понимание этих определений.
- Digital Government Index and Open, Useful and Re-usable Data Index. 2025 Results and Key Findings результаты оценки стран ОЭСР и кандидатов по индексам DGI и OURData за 2025, оценки там вполне ожидаемые, однако поражают крайне низкие оценки Турции по открытости данных и очень особенно низкие оценки в доступности данных в Турции. Из всех стран ОЭСР и кандидатов там ситуация хуже всего. В остальном мало что изменилось - Франция и Корея показывают наилучшие практики в открытости данных,

#readings #oecd #ai #opendata #data #government

В рубрике полезных инструментов для разработки Roam Code движок на Python для индексации кода в семантический граф и снижения потребления токенов ИИ агентами для программирования за счет того что вместо grep'пинга кода они обращаются к индексу. Вернее снижение потребления токенов - это лишь малая часть полезного, остальное заключается ещё и в повышении управляемости, скорости внесения изменений и так далее.

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

#opensource #ai #development

Подборка ссылок про данные, технологии и не только:
- Jack Dorsey’s Block to Lay Off 40% of Its Workforce in AI Remake Джек Дорси, создатель Твиттера, а теперь стартапа Block уволил 4000 человек, это 40% команды, с начала года. Что важно, оставшаяся команда плотно работает с ИИ инструментами и то что акции компании только выросли. Да, в ИТ отрасли и в создании ИТ продуктов будут сокращения, это неизбежность и большие возможности для AI-first компаний и большой кризис для всех кто думает что это пройдет мимо них.
- Geopolitical Union книга о том как Евросоюз перешел к реальным шагам в части цифрового/технологического суверенитета, автор Ben Farrand много лет пишет на эту тему. Не видел пока этой книги в открытом доступе, но скорее всего будет любопытной для улучшения понимания причин и стратегического тренда
- GeoAI for Humanitarian Action собственно про спасение людей с помощью ИИ в самом буквальном смысле, руководство по применению ИИ при гуманитарных кризисах связанных со стихией, катастрофами. По большей части речь про анализ спутниковых снимков с помощью ИИ.
- 2028 the Great Data Reckoning автор рассуждает о том что вендоры инструментов работы с данными идут к кризису 2028 года. О том что дата инженерам надо переосмыслять принципы своей работы.


#readings #dataengineering #ai #humanitarian

В рубрике полезных ссылок про данные, технологии и не только, подборка Text-to-SQL решений:
- QueryWeaver (Text2SQL) - решение с открытым кодом от FalkorDB. Из плюсов - открытый код, из минусов работает только с моделями OpenAI и требует развертывания FalkorDB которая с открытым кодом, но доп зависимость. Внутри Python и Typescript. AGPL
- WrenAI обещают поддержку многих СУБД и многих LLM. Есть демо с дашбордами. Внутри Python и Typescript. AGPL
- SQLChat баз поддерживают мало, из LLM только OpenAI. Typescript и MIT лицензия
- Vanna поддерживает много баз, почти любую LLM. Python. Лицензия MIT. Разработка остановилась где-то в апреле 2025 г.
- Build a robust text-to-SQL solution generating complex queries, self-correcting, and querying diverse data sources текст в блоге Amazon о том как Text-to-SQL может реализовываться и в чем есть системные сложности
- Getting AI to write good SQL: Text-to-SQL techniques explained текст в блоге Google на ту же тему и со схожими рекомендациями (задавайте контекст)

#opensource #ai #texttosql #sql

The Generative AI Policy Landscape in Open Source интересный обзор публичных политик в отношении использовании ИИ для изменения кода и отправки ошибок у основных проектов с открытым кодом.

Обратите внимание на немалое число проектов где есть полный запрет на изменение кода с помощью ИИ. Будет ли это ещё одним критерием выбора продуктов с открытым кодом из альтернатив?

Представим себе логику "Хочу выбрать себе дистрибутив Linux на сервер, какой брать - с полным запретом на ИИ код или наоборот который преимущественно ИИ пишется?"

И это ни разу не шутка. Велика вероятностью появления альтернативных open source продуктов которые будут делаться в разы меньшими командами .

#opensource #ai

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

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

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

#ai #softwaredev #software

В рубрике как это устроено у них MCP сервис для доступа к данным французского национального портала открытых данных data.gouv.fr.

Опубликовано под MIT лицензией, внутри FastMCP, много примеров и рекомендаций по подключению для разных инструментов.

Выглядит интересно, отложил на попробовать и посмотреть в деле.

#opendata #opensource #ai #mcp