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

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

Это же к вопросу о доступе к данным/коду и тд. К примеру, выбирая между Copilot'ом и Cursor'ом для приватного кода. Дефакто Github и так имеет доступ ко всему моему приватному коду, использование Copilot'а не создает тех же рисков которые присутствуют в ИИ продуктах и сервисах за пределами Github'а.

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

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

#thoughts #ai

Ещё одна совсем-совсем свежая спецификация PLOON для отправки данных в ИИ агенты с максимальной экономией токенов. Экономит до 60% в сравнении с JSON и до 14.1% в сравнении с TOON. Автор написал бенчмарк показывающий что PLOON сильно экономнее других форматов. Уже прям любопытно что дальше, когда наступит момент что ИИ агенты смогут нормально употреблять бинарные данные и тогда все эти оптимизации будет очень легко заменить.

#ai #data #dataengineering #specifications

Похоже что вот только что Google одним продуктом File Search Tool дали новую жизнь жанру "я хочу ИИ агента чтобы поговорить со своими документами" и тем самым похоронили десятки стартапов которые пытались и пытаются это сделать.

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

Из минусов:
- только облачное хранилище для документов, только облачные модели Gemini 2.5
- дурацкое название "File Search Tool", не знаю кто такое мог придумать

#cloud #ai #google #gemini #files #documents

Я довольно давно натыкаюсь на тексты о том как же censored достал всех декларативный подход в разработке, управлению инфраструктурой, управление кодом. Есть даже уже сформировавшиеся термины такие как declarative data platforms, declarative prompts, declarative API, declarative configuration и так далее.

Что такое декларативное программирование? Это когда конфигурация ПО, правила, архитектурные блоки, часть программной логики и так далее вынесены в настройки внутри файлов в форматах YAML / TOML или их аналоги.

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

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

Лично я отношусь к YAML формату и его деривативам индиффирентно, но могу сказать что есть случаи когда декларативное программирование реально труднозаменимо.

Многие специализированные программные продукты до сих пор используют сложные бинарные форматы для переноса и сохранения файлов. Это могут быть и собственные бинарные форматы и использование ZIP контейнеров с некоторым числом разных вложенных файлов (MS Word, Xmind, Pages и десятки других).

Одна из регулярно возникающих у меня задач в том что создать диаграммы предметной области - блоков кода репозитория, структуры документа, архитектуры приложения и многое другое. И вот оказывается что ИИ агенты неплохо умеют генерировать схематичное описание в текстовых форматах вроде Mermaid, D2 или PlanUML, но как-только доходит до майндмапов то остается только генерация в формате FreeMind, а какой-нибудь Xmind остается не удел поскольку его нативный формат - это тот самый ZIP контейнер со сложным содержанием.

Чтобы ИИ агент сумел такой xmind файл сгенерировал надо приложить немало усилий. Гораздо проще сгенерировать файл Markdown который в тот же Xmind импортировать. Тогда можно получить майндмап сразу же и достаточно приближенный к ожиданиям.

Почему так? Потому что язык разметки markdown зачастую используется так же как и другие декларативные языки разметки - для передачи информации о структуре данных.

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

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

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

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

#thoughts #ai

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

Сама утилита эта работа как обертка вокруг множества приложений в операционной системе: pngquant, jpegoptim, 7z, zip и тд, но вот одна беда что она устарела и её надо было переписать.

Так что я её использовал как второй полигон для проверки кодирования с помощью ИИ (первый был с библиотекой iterabledata).

Итого:
- утилита filesrepack полностью переписана и теперь умеет две команды: repack - сжимать одиночные файлы, bulk - сжимать файлы внутри папки, рекурсивно
- добавлена поддержка множества новых форматов файлов: tiff, parquet, avi, avf, svg, gif, rtb, pages, numbers, key и других
- 90% кода написано с помощью ИИ агента Cursor'а (2-я версия Cursor, режим автовыбора моделей)
- существенные ошибки были лишь пару раз, достаточно легко они исправлялись
- у ИИ агента очень неплохое понимание контекста и того для чего сделано приложение и очень хорошие ответы на вопросы вроде "проанализируй приложение и предложи какие опции были бы полезны для его пользователей" или "предложи форматы файлов которые можно было бы оптимизировать и которые пока не поддерживаются"
- наибольшая польза, по прежнему, в автоматическом написании документации что очень удобно для всякого рода утилит и программных библиотек где не надо скриншотов и сложных сценариев.
- для такого простого практического применения ИИ агенты, действительно, прекрасно подходят и ускоряют работы многократно, а также помогают закрыть дыры в документировании, тестировании и тд.
- по ощущениям можно уже применять ИИ агенты и для промышленного применения в сложных системах, но, конечно, с существенно большей осторожностью и дополнительными мерами по верификации кода
- все в совокупности, конечно, огромный прогресс за последний год. Ранее когда я пытался применять ИИ агенты, было ощущение что галлюцинаций существенно больше чем результата.
- в любом случае джуниорам я категорически не рекомендую начинать изучение программирования через ИИ ассистенты. Что бы понимать насколько созданный код хорош и адекватен нужно уметь создавать его самостоятельно иначе можно наделать серьёзных ошибок

Далее я уже расскажу про практическое применение ИИ для работы с кодом и создания индекса в Dateno, но этим кодом поделиться уже можно только в отдельных отчуждаемых компонентах.

#opensource #tools #ai #coding #thoughts

Подборка полезных ссылок про данные, технологии и не только. В этот раз ссылки на видео:
- Meta Just Changed Data Compression FOREVER (OpenZL Explained) про новый инструмент для сжатия файлов OpenZL. Его важная особенность - это понимание форматов сжимаемых файлов и выбор правильного способа сжатия.
- Trustworthy Data Visualization (Kieran Healy, Duke University) видео с конфренции Posit 2025 о том как создавать визуализации данным которым можно доверять, полезное для всех кто визуализирует данные или читает визуализируемое. Автор написал немало про визуализацию, три книги и много статей ну и выступает весьма неплохо
- Mooncake: Real-Time Apache Iceberg Without Compromise (Cheng Chen) про построение озера данных с Apache Iceberg и Mooncake для реального времени. Заодно и с историей OLTP и OLAP и переход к озерам данных
- Introduction to OpenRefine использование OpenRefine, инструмента для очистки и обогащения данных. Примеры.и применение из работы с цифровыми архивами и библиотеками и не все знают что библиотекари - это основная аудитория пользователей OpenRefine.
- PostgresAI я так понимаю что это пока малоизвестный стартап который обещает применение ИИ для оптимизации баз Postgres. Концептуальная идея на поверхности, я, если честно, думал что появится что-то более универсальное по мониторингу и оптимизации с поддержкой разных СУБД. Честно говоря видео оформлено дурацки.и документация на их сайте практичнее

#readings #ai #datatools #datatools

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

#opensource #ai #privacy #llm #tools #datatools

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

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

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

Лично для меня и Dateno это очень хорошая новость это означает что реестр (dateno.io/registry) можно вести теперь значительно меньшими личными усилиями.

В ближайшее время я сделаю очередное обновление реестра уже по итогам большого числа итераций обновления метаданных и качество реестра существенно вырастет. А оно влияет и на индекс Dateno и на сам продукт реестра дата каталогов.

P.S. Тут я описываю внутренности происходящего в Dateno, которым я занимаюсь как основным проектом и продуктом. А новости проекта всегда можно читать в LinkedIn

#opendata #datacatalogs #ai #dev #datatools

Короткий текст The fate of “small” open source где автор рассказывает о будущей печальной судьбе программных библиотек на примере свой библиотеки blob-util и того что ИИ агенты не предлагают использовать её, а автоматически генерируют код.

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

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

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

Похоже на реалистичный сценарий?

#opensource #ai #llm