LongCat-2.0 свежая LLM на 1.6 триллионов параметров, контекстом в 1М и открытым кодом (пока не открыт, только обещан). Особенность в том что она под другим названием Owl Alpha уже входит в топ 5 рейтинга OpenRouter и активно в этом рейтинге растет. Иначе говоря разработчикам даже не надо доказывать ее востребованность, она и так де-факто уже проверена востребованностью.

Другая особенность в том что модель обучена полностью на китайских чипах и создана в компании Meituan - это такая китайская компания разработчик приложения доставки. Они и раньше делали LLM под названием LongCat, но кажется именно эта является прорывом.

#ai

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

Я приводил в пример ее использование для преобразования файлов, а вот дополнительные примеры того как ее можно применять.

Быстрое API на основе файла с данными

Предположим есть файл CSV, JSONl, Parquet или еще какой-то и его содержанию надо быстро дать доступ кому-то внешнему, но передавать файл/файлы целиком нельзя по какой-либо причине.

Очень простая и быстрая команда

undatum api run data.jsonl

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

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

Быстрое документирование дата файлов

Когда есть некий файл с данными к нему нет дополнительной информации, а очень надо быстро в нем разобраться, то генератор Markdown документации

В самом простом виде выглядит как

undatum ai doc data.csv

выводит на экран итоговый Markdown текст

Более продвинутый

undatum ai doc —blocks general,schema,quality,examples,codebook —format json —language Russian data.csv

Создает документацию в формате JSON с Markdown блоками перечисленными списком и на русском языке.

Загрузка данных в NoSQL/SQL базы данных

Команда ingest изначально делалась для продвинутого импорта данных в MongoDB и Elasticsearch и идея в том чтобы на вход получить файл и строку подключения в базе данных после чего загрузить содержимое в выбранную таблицу/коллекцию/индекс

Пример команды

undatum ingest data.jsonl https://elasticsearch:9200 myindex myindex --dbtype elasticsearch --api-key YOUR_API_KEY --doc-id id

В чем важная особенность undatum от специализированных инструментов которые умеют это же? В поддержке любых сжатых файлов .xz, .gz, .zst, .lz4, .bz2 и так далее. Потому что хранить данные в чистом NDJSON или CSV - это прямо таки очень неэффективно. Особенно когда это много слепков коллекции из MongoDB или индекса Elasticsearch.

#opensource #datatools #data

OmniRoute локальный маршрутизатор запросов к ИИ провайдерам умеющий работать с большим их количеством, сейчас это 231 провайдер в том числе с теми которые дают бесплатные квоты. Позиционируется как инструмент сильной оптимизации потребления токенов, позволяет сократить их благодаря сжатию RTK + Caveman.

Что характерно даже поддерживают одного из российских провайдеров - gigachat (можно увидеть в общем списке), но собственно и только. Того же Яндекс'а к примеру тут нет почему-то.

Плюс обещают прозрачную интеграцию с 1proxy и возможность обхода блокировок из стран которым некоторые AI провайдеры не дают доступа (Россия, Иран, Куба, Китай и тд.).

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

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

#opensource #ai #tools

Хороший обзор проектов с экспериментальной статистикой в США, с примерами компаний которые создают публичные дата продукты и их начинают использовать официально.

Все это про мир alternative data, актуальный для биржевого и корпоративного мира и все еще медленно проникающий в официальную статистику.

В обзоре из интересных примеров - это оценка масштабов строительства через анализ спутниковых снимков.

#opendata #statistics

В качестве регулярных напоминаний коллекция библиотек и инструментов с открытым кодом к которым я приложил свою руку и которые могут быть полезны многим работающим с данными:
- qddate библиотека для Python быстрого парсинга дат написанных на множестве языков и во множестве форматов. Не такой широкий охват форматов как у dateutil, но гораздо более высокая скорость парсинга.
- newsworker библиотека и инструмент на Python для извлечения новостей из веб страниц. Например, когда надо подписаться на сайт через RSS, а RSS ленты нет. Понимает множество форматов дат используя qddate и динамически идентифицирует новостные блоки.
- russiannames база данных и парсер Python для разного рода написания ФИО принятых в российской практике. В базе десятки тысяч имен и отчеств и сотни тысяч фамилий
- undatum утилита командной строки для работы с датасетами в форматах CSV, JSONl, Parquet и сотне других форматах. Умеет преобразовывать данные и проводить с ними различные операции. Эдакий швейцарский нож для работы с данными с командной строки
- metawarc утилита по извлечению метаданных из файлов веб-архивов (WARC). Умеет извлекать метаданные из офисных файлов, PDF, изображений и тд.
- plainrussian сервис проверки простоты текстов на русском языке используя формулы читабельности адаптированные под русский язык. Код самого сервиса и формул для расчета
- iterabledata библиотека для Python для чтения и записи практически всех существующих форматов файлов с данными. Используется в утилите undatum
- internacia-db дата продукт в виде датасета по всем странам и макрорегионам во множестве форматов и покрытием всего мира и многими метаданными по каждой территории

#opensource #datatools #tools

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