Полезные ссылки про данные, технологии и не только:
- The Economics of the Modern Data Stack есть ощущение что сам термин Modern Data Stack уже уходит в прошлое, но тут любопытный разговор про ETL продукты с открытым кодом и про то что Matatika поглотили Meltano. Лично мне продукт Meltano нравился на каких-то ранних его стадиях когда они форкнулись из Gitlab, но дальше они как-то совсем провалили коммуникацию с сообществом. Причем я не могу понять как они такое умудрились.
- Antigravity Manager open source инструмент для управления аккаунтами для работы с Google Antigravity. Решает важную проблему с тем что работать с Antigravity с корпоративного аккаунта очень накладно и откровенно неудобно. Вообще Google сделали хороший продукт технически и весьма неудобный в части управления им. Инструмент на китайском языке почти полностью
- Inside OpenAI’s in-house data agent о том как с помощью дата агента работают с данными внутри OpenAI. Любопытны идеи, но повторять один в один такое не надо, то что могут позволить себе те у кого ресурсы не ограничены - это не для всех.

#readings #ai #data

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

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

3. Свежий доклад World Bank про распространение ИИ в развивающихся странах о том что есть новая форма неравенства в том как ИИ создается и применяется в странах с невысокими доходами. Акцент на малых моделях SLM работающих на повседневных устройствах. Тут важно не забывать что ИИ модели - это не только инструменты, но и де-факто срез мировых знаний локальные страновые модели будут применяться для цензурирования контента. Регуляторы к этому медленно адаптируются, они просто не успевают за потоком изменений, но этот поток не вечно будет столь изменчивым. Когда поток изменений поубавится или хотя бы станет предсказуемым жесткое регулирование будет неизбежным.

#thoughts #ai #itmarket

Для меня один из давних вопросов в том могут ли LLM работать с двоичными данными и делать это хорошо. Но если я только задумывался об этом то ребята из Quesma проделали серию тестов с внедрением вредоносов в несколько бинарников популярных серверных продуктов и попробовали с помощью разных LLM их выявить используя опенсорные инструменты Ghidra и Radare2. А по итогам они написали подробный отчет в котором есть еще и ссылки на детали замеров и исходники.

В качестве короткого резюме - да, возможно. Лучше всего себя показал последняя модель Claude Opus 4.6, хуже всего Grok-4.1-fast. Впрочем использование Claude Opus 4.6 было самым дорогим, его использование вышло в $300, но и выявил он 49% всего вредоносного кода (бинарного в исполняемых файлах)

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

#opensource #ai #itsecurity

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

Вот в пример задача которую я регулярно решаю - пополнение реестра каталогов Dateno (dateno.io/registry) и я регулярно задаю сложные вопросы для deep thinking сервисов которые звучат как "мне нужен полный список сайтов работающих на базе YYY" (реальные промпты посложнее, но так понятнее) и в ответ я получаю довольно неплохо структурированные ответы о том как искать эти данные на сайте вендора или запросами к Google и оценки трудоёмкости в несколько месяцев.

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

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

#opendata #thoughts #ai

Кстати, в продуктах 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