Пишут что качество новой версии 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

Помните я писал подход к разработке через режим

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

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

Я регулярно тестирую новые LLM модели и агентские сервисы на разных репозиториях запросами именно на их полноты и подготовки роадмапов. Эдакий внешний ревью архитектуры, кода и перспектив продукта.

Примеры такого анализа на коммерческих репозиториях показать я не могу, а вот почему бы не показать пример анализа открытого кода. Все та же библиотека и инструмент newsworker о которой я ранее писал и которая умеет преобразовывать страницы без RSS/Atom в RSS/Atom и другие новостные ленты.

В этом примере я запросил у агента Z.ai и модель GLM-5.2 провести аудит репозитория и составить перечень нехватающих функций и роадмап по их внедрению.

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

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

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

#opensource #ai #coding

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

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

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

Так что в последней версии newsworker появилось две команды analyze и extract где первая создает спецификацию, а вторая по спецификации извлекает новости.

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

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

#opensource

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