По поводу блокировок в России Pypi, репозитория библиотек кода для Python и заявлений Роскомнадзора по поводу того что "это не они", все довольно просто. Pypi как и тысячи других сервисов в мире используют CDN, в данном случае сервис Fastly. Вот его Роскомнадзор уже несколько раз блокировал в предыдущих блокировках других ресурсов. Сейчас, я подозреваю, в очередной раз блокировали что-то еще использующее Fastly и затронули Pypi "случайно". Что РКН не оправдывает и не оправдывало никогда.

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

#thoughts #comments #russia

В Великобритании национальный портал открытых данных data.gov.uk переименовали в National Data Library (Национальная библиотека данных) и рассказали о том почему и как они это делают.

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

Ключевой двигатель изменений нац порталов открытых данных в том что в какой-то момент многие из них превратились в помойки. Идея open by default без методической поддержки привела к большому числу бессмысленных маленьких наборов данных не востребованных и не нужных 99% пользователей. Преодолевают эту проблему очень по разному:
- в Евросоюзе - фокусируются на данных особой ценности выводимых в отдельную категорию
- в США - откровенно забивают на портал data.gov, он давно наполняется, но качественно не меняется. Поэтому параллельно создают много разной открытой инфраструктуры для геоданных, научных данных и тд.
- в Индонезии - кратно увеличивают число опубликованных открытых данных публикуя на них чуть ли не каждый файл созданный госорганами. Сейчас там больше 580 тысяч файлов на data.go.id

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

С одной стороны удивительно, а с другой не очень. Как хороший пример, data.gov.uk я пока приводить не могу.

#opendata #uk #thoughts

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

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

Важнее то что в Армении существенная часть работодателей и формирование ВВП завязано на международный ИТ сектор, компании которые почти не заметны на ИТ рынке внутри, но имеющие глобальное присутствие. У них почти у всех кроме юр лиц в самой Армении, есть фронтирующие юр лица в США или Гонконге или Сингапуре от которых они ведут деятельность, но почти всех их сотрудники находятся в Армении, в Армении их R&D подразделения и так далее. Большое число людей тратящих доходы внутри страны.

Кроме того если хорошенько посмотреть на реальную картину импорта/экспорта Армении по его структуре, то можно обнаружить насколько он изменился с 2021 года. В частности, несколько лет Армения была де-факто транзитным хабом для торговли российским золотом, платиной, алмазами и серебром и даже как-то удивительно что российские власти ограничивали импорт армянской минеральной воды, а экспорт золота из России что-то не
ограничивали;) (на самом деле - не удивительно).

Поэтому повторюсь, не читайте СМИ. Все, на самом деле, не так как в реальности (c).

#thoughts #armenia

Разные мысли вслух про ИИ и не только:
- мысль которую я уже формулировал, но можно и повторить. Разработка с помощью ИИ агентов для зрелого разработчика большой плюс, для юниора большой минус. И готовность применять кратно различается. В общем если Вы начинающей разработчик/инженер/аналитик то вайб-кодинг в резюме совсем не плюс, а может быть и минус
- судя по ограничениям которые Anthropic наложили на модель Fable, публичный вариант Mythos, мир движется к тому что будут модели без ограничений за очень большие деньги и для особых клиентов, и модели с ограничениями для широкой аудитории. Интересно только как скоро появится открытая модель сравнимая с Mythos/Fable?
- продолжая мысль про открытые модели, это же во многом про демократизацию доступа технологиям двойного назначения. Условно возможно ли кибервойны будущего между несколькими крупными корпоративными или национальными автономными ИИ продуктами? Не то чтобы я хотел это видеть своими глазами, как писатель фантаст интересуюсь;)
- большое число ИИ продуктов локально приводит к большому числу ключей доступа к ИИ моделям и сервисам прописанных в переменных окружения. Чем дальше, тем это всё менее безопасно поскольку доступ к ним имеют вообще все приложения запущенные от текущего пользователя. С одной стороны ключи SSH тоже доступны также любому приложению, а с другой, неужели меня одного это волнует?

#thoughts #aiagents

Anthropic внезапно и по требованию властей США отключили Fable 5 для всех клиентов. Причем требование было про угрозу национальной безопасности без уточнения причин, но можно предполагать что причины в том что кто-то из пользователей таки смог преодолеть защиту от применения в целях кибербезопасности и других потенциально опасных тем/задач.

Всё это поднимает сразу два ключевых вопроса:
1. Неизбежность обязательного сильного государственного вмешательства в разработку и доступность наиболее передовых LLM и ИИ сервисов
2. Невозможность страновых ограничений для доступа. Власти США запретили предоставлять доступ всем негражданам США и Anthropic вынуждены были отключить вообще для всех, потому что гарантировать недоступность для всех несоответствующих этому критерию сложно.

Событие это важное, если не переломное. А что будет когда модель сравнимую с Fable/Mythos выпустят китайцы, ее власти США тоже запретят? И как, простите, они это сделают?

#ai #thoughts

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

Много лет назад, работая с разными доступными данными об активности госорганов я подумывал не сделать ли российский аналог Bloomberg Government (BG), с систематизированными данными про людям, контрактам, бюджетам, законам и проектам законов. Даже сейчас, со всеми ограничениями, информации о активности госорганов если не много, то кажется что достаточно чтобы такую штуку сделать. Включая аналитические продукты, у того есть регулярные обзоры проектов биллей да и аналитика по госрасходам и госконтрактам то что я довольно хорошо знал и знаю до сих пор.

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

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

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

А возвращаясь к аналитике по законопроектам, законам и другим НПА, то она имеет развилку прикладных сценариев для защитного GR, но с запозданием, потому что в России анонс законопроекта - это не приглашение к разговору, а сформулированная угроза (как правило прописаны новые запретительные положения). Это имеет ограниченную ценность, но какую-то могут иметь.

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

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

#thoughts #laws #ai

По поводу того что Apple убрали из апп стора приложения VK, и того что разработчики Telega (альтернативный телеграм клиент) самоудаляются с 1 июля мне много что есть сказать, но сдерживаюсь чтобы больше писать и думать про интересное (данные, ИИ и тд.), а не про злободневное. И вообще не всегда получается писать нейтрально и достаточно сухо, но я стараюсь.

Тем не менее я хочу обратить внимание на то о чем уже писал, с 30 сентября 2026 года Google постепенно начнет внедрять требование по верификации всех разработчиков приложений для андроида. Не только в рамках Google Play, а вообще всех. Это поломает многие, может быть даже все, опенсорсные сторы приложений и поставит под контроль альтернативные сторы. Это охватит не все устройства, а только сертифицированных партнеров где есть, к примеру, Samsung, но нет Huawei.

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

В любом случае если завтра российские регуляторы публично признаются что на Apple никак повлиять не могут и начнут говорить что мол "переходите на Андроид" может оказаться что переход на андроид не поможет. Потому что Google тоже должны соблюдать санкции (отдельный вопрос почему не соблюдают сейчас, но это политика, а не технологии).

В любом случае я бы не питал иллюзий что с Apple или Google можно будет договориться через ФАС или квадрилионные судебные иски или блокировками их сервисов. Блокировать их сервисы - это как стрелять себе в колени. Понятно что не впервой, но не надо уже приводить самострел в привычку.

#russia #thoughts

Новая популярная тема в работе с ИИ агентами в разработке loop engineering или loop prompts в основе которой последовательность шагов, если упрощенно.

discover → plan → execute → verify → (repeat until a condition is met)

С одной стороны кажется очевидным, с другой это, во многом, архитектурный шаблон когда ты разделяешь программный продукт на модули и разрабатываешь каждый с четким пониманием цели изначально. discover еще описывают часто как set the goal (поставить цель).

Мне подход скорее нравится, хотя я и придерживался всё это время несоклько другого. Который можно описать как.

set the goal → analyze + analyze + analyze → review → design → plan → execute → (repeat tests till conditions met) → verify

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

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

#thoughts #aiagents

Похоже не только Anthropic попали на грабли одобрения новых ИИ моделей Белым домом (США), а и OpenAI. Их уже попросили притормозить с публичным анонсом их новой модели, до её тестирования.

Меня мучает все тот же вопрос - что будет когда появятся сравнимые по эффекту открытые и доступные китайские модели? Власти США их тоже попробуют притормозить ? Будет ли какой-то глобальный договор вроде договора о нераспространении химического или ядерного оружия? Куда мир вообще идет-то ?

#thoughts #ai

Пишут что качество новой версии Fable 5 существенно упало, например, отладка кода упала на 70%, рефакторинг на 48% и галлюцинации стали хуже (изменения на 19%).

Все потому что теперь при обращении к этой модели она часто перенаправляет на Opus 4.8 из-за мер безопасности которые предприняли Anthropic.

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

Интересно начнут ли в эту игру играть и власти Китая когда флагманские модели их стартапов начнут давать сравнимое качество?

#ai #thoughts

Я тут задумался не вернуться ли к чтению новостей через RSS читалки, потому что читать многое в компактном виде становится всё сложнее. Да, есть хорошие тематические рассылки, но их не так много и они портятся тем что постепенно рекламного контента там становится больше. Но с RSS читалками есть одна беда, они все [не] немного устарели и не учитывают реальных сложностей потребления новостей.

Какой могла бы быть идеальная RSS читалка?
1. Уметь фильтровать новости. Как простыми способами - ключевые слова, так и через простую интеграцию с LLM, тут подойдут и легкие недорогие или даже бесплатные модели. Уметь фильтровать по принципу - выбрал новость и отметил "хочу меньше видеть подобных новостей" и наоборот "Это важно, делай это приоритетнее". Технически это можно делать множеством способов. Сюда же идет автопростановка тегов и простая навигация по ним.

2. Уметь делать дайджесты для часто обновляемых источников. Есть источники новостей генерирующие до сотни сообщений в день. Их, тоже, надо фильтровать, но даже если их останется десяток их надо уметь объединять в дайджесты. Благо это несложно.

3. Давать возможность подписываться на сайты без RSS/ATOM. Для этого я когда-то и создавал библиотеку newsworker и она вполне интегрируема куда угодно и позволяет это делать без особых сложностей.

4. Интерфейсно уметь отображать новости по разделам "Важно", "Обычно", "Менее важно" по критериям заданным пользователем и по его действиям, см. пункт 1

5. Минимализировать HTML рендеринг, потребление памяти и CPU. Преобразовывать полученный контент в Markdown и отображать его максимально облегченным образом и настраиваемым конечно.

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

7. Не пытаться построить новостной агрегатор а ля канал в Slack или Discord или телеграм канал или любой другой режим мессенжера. Для уведомлений это еще более-менее, а для чтения новостей очень неудобно.

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

Лично мне не попадались до сих RSS читалки способные делать хотя бы половину из перечисленного. Но может я что-то пропустил?

#thoughts

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

К вопросу о каталогах данных и в более широкой трактовке включая доступность данных через 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

Я на днях смотрел внимательнее на новые китайские модели: 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

Pax Silica vs WAICO

Читаю про WAICO свежесозданный альянс по кооперации 29 стран по поводу ИИ где участвует и Россия все страны Центрально Азии кроме Туркменистана, и многие другие развивающиеся страны Глобального Юга. Ведущая роль там безусловно у Китая и, по сути, это объединение стран вокруг Китая и его глобальной ИИ политики.

И, конечно, невозможно его не противопоставлять инициативе США Pax Silica запущенной в декабре 2025 г. с похожими целями, но еще и с акцентом на редкоземельные металлы и полупроводники, ну и ИИ конечно.

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

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

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

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

Правда вот мне совссем непонятно какие бенефиты власти РФ получат от участия в WAICO. Продажа российских ИТ/ИИ продуктов в страны Глобального Юга? Не особо верится. Доступ к китайским вычислительным ресурсам и покупке чипов? Про это интересно было бы узнать подробнее.

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

#ai #china #thoughts