Открытое письмо более 30 тысяч подписантов с призывом к запрету любых исследований по созданию сверхразума (superintelligence).

Дословно звучит как:
Мы призываем к запрету на развитие сверхразума, который не должен быть снят до тех пор, пока не будет
1. широкий научный консенсус, что это будет сделано безопасно и контролируемо, и
2. сильная общественная поддержка.

Среди подписантов Стив Возняк (экс-основатель Apple), Ричард Бренсон, многочисленные основатели компаний, в том числе AI стартапов, а также многочисленные политики, исследователи, представители искусств и медиа и религиозные деятели. Включая принца Гарри и его жену Меган и еще много-много других знаменитостей.

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

#readings #thoughts #ai

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

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

#python #thoughts #memories

О сжатии данных

Вначале немного общего контекста.
Один из трендов разработки ПО, игр, сайтов, мобильных приложений последних десятилетий был и остаётся рост размера самих программ и связанных с ними цифровых артефактов. Это же относится и к данным, данных становится больше, хранить их в как-есть оказывается накладно и для передачи, и для стоимости хранения, и для обработки. Собственно одна из причин появления новых алгоритмов сжатия вроде Zstandard, Brotli и др. от бигтехов в том что внутренний и глобальный запрос на повышение эффективности хранения и передачи данных есть и он давно уже перерос специализированные и академические области применения и новые алгоритмы приходят теперь не из задач связанных с академическими проектами, вроде появления алгоритма LZO, а именно из практической массовой потребности.

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

Самые очевидные правила:
1. Во всём что касается хранения структурированных данных когда нужны эталонные данные то применение одного из способов сжатия: Zstandard, Xz, GZip. Zstandard как наиболее сбалансированный по скорость/уровень сжатия, Xz для долгосрочного хранения, а Gzip для работы с инструментами которые могут не поддерживать остальные способы сжатия
2. В случаях когда нет необходимости хранить оригинальные данные - сохранять их в Parquet со сжатием в Zstd. В такой конфигурации данные остаются пригодными для машинной обработки и существенно меньшего объёма

А теперь не самое известное об алгоритмах компрессии:
1. Есть много алгоритмов сжатия гораздо лучше сжимающих данные ценой длительной работы и множество ресурсов. Тем кто интересуется будет интересно почитать о Hutter Prize конкурса по сжатию данных человеческих знаний (Википедии) где можно найти множество программ дающих качественно лучшее сжатие чем общеизвестные инструменты
2. Многие популярные архиваторы дают плохое сжатие, как в угоду скорости, так и просто из-за слабой технической реализации. Есть такие экзотические инструменты как precomp которые пережимают файлы повторно находя в двоичном потоке сигнатуры сжатых потоков, расжимая их и сжимая снова улучшенными алгоритмами. Важное ограничение в том что это всё ещё не production ready инструмент и в том что сжатый файл обяззательно надо расжимать перед использованием.
3. Но есть файлы которые можно пересжимать без потери их реюзабельности. Много лет назад я делал утилиту filerepack которая пересжимала файлы в zip контейнерах. Например, у вас накопились файлы MS Office в docx, pptx, xlsx и других форматах и есть желание их уменьшить. filerepack последовательно пересжимал все файлы внутри контейнера и сам контейнер, но делал это с потерями применительно к файлам изображений. Для презентаций и документов в 99% случаев это было приемлемо, а также в ZIP контейнерах хранятся файлы из LibreOffice (OpenDocument), файлы EPUB и многие другие. Те же приложения для Android и Apple IOS.
4. Один из способов работы с архивами - это их монтирование в операционную систему. Это позволяет некоторым приложениям не работающим со сжатыми данными, тем не менее это делать. Пример, утилита mount-zip и более универсальный инструмент Archivemount

А также существует множество других подходов, инструментов и трюков. Чем больше дискового пространства ты используешь, тем больше думаешь о том как на нем экономить;)

#texts #thoughts #data #compression

Про разговоры про мошенников которые звонят пользователям, в американских интернетах подсмотрел как делает сервис Robinhood. Они просто... никогда не звонят пользователям. Вообще никогда.

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

А ведь просто. Не надо. Звонить. Никогда

P.S. А если какой-то сервис ещё и звонит роботом, то сразу в черный список.

#privacy #thoughts

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

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

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

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

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

#thoughts #ai

Я довольно давно натыкаюсь на тексты о том как же 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

Ещё немного рефлексии по поводу навыков Python разработчиков. Я тут регулярно провожу технические собеседования дата инженеров к команду Dateno, в основном это русскоязычные разработчики/инженеры в разных странах и с разными запросами на ЗП.

Поделюсь некоторыми наблюдениями:
1. От многих собеседуемых есть ощущение что они свою ожидаемую ЗП оценивают по средней/верхней планки по рынку и по минимальной сумме при которой им комфортно жить, но никак не по собственным навыкам. С одной стороны это очень понятно, а с другой, в общем-то навыки часто не соответствуют запросу. Это такой естественный конфликт работодатель-работник, но в целом видно что не все могут оценить свою реальную рыночную ценность. Раньше тоже такое бывало, но что-то в этом году я наблюдаю это чаще чем раньше.
2. Мои задачи на технинтервью состоят из проведения ревью кода, либо старого кода одного из проектов, либо небольшого куска искусственно созданного примера кода с заведомыми ошибками. Часто оказывается что собеседуемый прекрасно говорит, идеально рассказывает про свой опыт, но с простым ревью кода не справляется.
3. Самые частые "затыки":
- непонимание приоритетов. Вместо поиска ошибок, которые вполне очевидны, увлечение стилем кода и форматированием. Это реально какое-то массовое явление, многие сбиваются в стилистику кода вместо фокуса на решении проблем.
- незнание асинхронности в Python. Для дата инженерных задач, особенно при работе наиболее популярными инструментами оркестрации конвееров данных хотя бы базовые принципы асинхронности надо если не знать, то уметь понимать.
- невнимательность. В каждом техинтервью есть задача в которой есть вполне понятные вводные на основе которых можно понять где могут быть ошибки и как их можно увидеть. Многие игнорируют существенную часть задачи и бегут смотреть код.
- недостаток архитектурного восприятия. У Python'а есть какое-то количество шаблонных способов решения задач (как и в большинстве языков) и хороших и плохих практик, например, использование глобальных переменных без четкого понимания зачем это делается - всегда плохо. Или же когда функции перегружены большим числом операций и выполняются долго то при выбросе исключения при отсутствии сохранения текущего состояния невозможно продолжить с места сбоя

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

По моему опыту довольно бессмысленно расспрашивать про инструменты, ими несложно овладеть. Неважно есть ли у человека опыт в Polars или DuckDB если он владеет Pandas, к примеру, но problem solving однозначно выходит на первый план для все кто не совсем джуниоры.

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

#thoughts #hiring

К разговорам про падения интернета прекрасная картинка в Reddit'а и для полноты картины нехватает только регуляторов некоторых стран которые вносят свой неописуемый вклад в происходящее.

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

#thoughts

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

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

Внимание вопрос? Должны ли конкурсы ограничивать прием работ сделанных ИИ или выносить их в отдельные номинации? Как вообще теперь проводить конкурсы ?

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

Вопрос как все будет меняться?

#thoughts

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

Вот несколько примеров:
- Роботизированные спамеры и скамеры. Одна из бед открытых каталогов данных со свободной регистрацией пользователей и публикацией данных в какой-то момент стало бесконечное количество спама. Например, на порталах на базе CKAN открытая регистрация была прописана по умолчанию, в какой-то момент спамеры и скамеры понаписали скриптов которые регистрировали сотни тысяч аккаунтов и от них постили все что только разрешалось: создавали группы, профили организаций и карточки датасетов. Все фэйковые конечно, но в результате многие открытые порталы оказались забиты низкокачественным SEO мусором или, хуже того, откровенным скамом. Живой пример у меня перед глазами портал открытых данных метеослужбы Туниса. Там зарегистрировано более 1.3миллиона аккаунтов пруф потому что они не стали ограничивать регистрацию и поэтому у них у них более 45 тысяч спам текстов в одном из разделов. Из-за этого открытость порталов посвященных открытости приходится ограничивать, мы позакрывали регистрацию во всех своих основанных на CKAN порталах открытых данных именно по этой причине.

- Специализированный спам. Если ты активно публикуешь открытый код, ведешь активность на Github то рано или поздно, но скорее очень рано на тебя посыпется специализированный спам который можно разделить условно на 2 типа:
1-й - "Мы тут увидели что Вы добавили в избранное такой то open source проект, а у нас очень похожий, обязательно зайдите и посмотрите на нас и может быть используйте и добавьте в избранное"
2-й - "Чувак(-иха) у тебя столько активности в твоем аккаунте, зарегистрируйся в нашем сервисе где мы сводим больших работодателей из США и крутых программистов"

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

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

#thoughts #opendata #opensource

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

Этих скриптов много, штук 20, они последовательно:
1. Выгружают справочники, списки показателей и метаданные из статистических баз
2. Выгружают первичные данные, обычно JSON или CSV
3. Преобразуют первичные данные в файлы parquet
4. Загружает файлы parquet в аналог даталэйка
5. Готовит карточки датасетов для загрузки в индекс Dateno

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

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

И вот что я могу сказать, по итогам:
1. Copilot для этого просто неудобен, фактически с задачей такого рода он не справляется.
2. Cursor 2.0 лучше, но все равно код недостаточно функциональный, преобразование в библиотеку для Python из скриптов случилось плохо
3. Antigravity выдал если не хороший, то приемлемый результат с систематизацией настроек под каждую платформу и возможности вызова отдельных команд. Сами команды могут содержать ошибки, но это уже нормально, это уже итеративная работа по приведению этого кода в порядок

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

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

#thoughts #ai #coding

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

У меня есть как минимум две таких базы данных которые можно перевести в режим декларативной сборки набора данных и обогащение с помощью ИИ, это:
1. Реестр всех госдоменов в РФ используемый для цифровой архивации
2. Большой каталог всех межгосударственных структур (ОЭСР, ООН и тд.) с привязкой к странам и тд.

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

А вот второе я веду уже лет 10, но года 4 уже не обновлял. Это штука регулярно необходимая для мэппинга разного рода объектов - данных, текстовых материалов и не только.

Одно из применений в визуализациях и аналитике когда надо сравнить какие-то абсолютные или средние значения показателей демографии, ВВП, размеров рынка и тд. по страновым блокам. Сравнить ЕС и БРИКС или рейтинги внутри странового блока.

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

К примеру, реестров стран в мире не меньше нескольких десятков. Когда надо мэппить разные объекты на страны чаще всего используют реестр стран ООН, ISO 3166, справочник Всемирного банка, справочник геослужбы США и несколько частных проектов с открытым кодом. Внутри Dateno активно используется python библиотека pycountry, но это не единственный и не идеальный способ.

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

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

#opendata #opensource #thoughts

В качестве легкого оффтопа как человек искренне нелюбящий звуковые сообщения в WhatsApp, Telegram и тд. не могу не отметить что для тех кто в России или тем кто звонит в Россию они могут быть выходом на фоне блокировок РКН.

Раз такое дело то можно и пересмотреть свое отношение к звуковым сообщениям и воспринимать их если не хороший способ коммуникации, то как приемлемый. По крайней мере пока РКН не перешёл к жёсткой борьбе с телеграмом которая ещё может затянуться.

#thoughts #telegram

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

Вот краткие синопсисы некоторых идей:
1.Анти-ИИ терроризм. Группа пострадавших от ИИ людей планируют атаку на электростанции питающие крупнейшие датацентры. Для планирования они тоже используют ИИ, в виде открытой модели со снятыми с неё ограничениями. После успешной, но фатальной атаки они все погибают, а многие глобальные ИИ сервисы отключаются. В финальных кадрах показан офис некой восточноазиатской компании в которой несколько человек обсуждают можно ли заложить в открытую ИИ модель определенные ответы на вопросы и подталкивание к конкретным шагам, а также о том как и как можно подкинуть инструкцию по снятию ограничений потенциальным террористам не выдавая себя.
2. Автономные роботизированные поселения спасают человечество. Человечество не смогло удачно доставить людей на Марс и переключилось в создание автномных роботизированных поселений на Марсе где с помощью централизованного ИИ должны быть созданы условия для прилета людей в поселение где уже будет еда, вода и жизненная среда. Для проверки идеи на Земле создают сотни таких автоматизированных поселений в местах, как правило, плоходоступных и с суровым климатом. Когда наступает апокалиптичное событие (падение астероида, глобальная пандемия или зомби-апокалипсис) то эти поселения оказываются единственным убежищем позволяющем малым группам человечества выжить.
3. Неубиваемый ИИ вирус. Основанный на ИИ вирус захватывает компьютеры и электронные устройства, использует децентрализованное фрагментированное хранение для распространения и накопления украденных данных/реквизитов/паролей и zero-day уязвимостей которые он также находит автономно. Заканчивается все постепенными блокировками любых коммуникаций между странами и отдельными территориями и методичная работа по вычищению. Расходы коллосальные и мир в глубоком шоке, рассказ от лица человека живущего изолированного в глуши и приютившего один из оставшихся экземпляров вируса в умном холодильнике

#thoughts #ideas

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

Есть три основных категории пользователей и у каждой из них свой набор ожиданий :
1. Аналитики
- максимальная оперативность данных
- доступность данных в форматах привычных для работы (CSV, XLSX)
- возможность доступа к данным аналитическими и No code/Low code инструментами
- наличие данных по ключевым наиболее значимым темам (официальная и ведомственная статистика, например)

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

3. Разработчики и дата инженеры
- доступность данных через API
- доступность данных для массовой выгрузки (bulk download)
- доступность схем и структур данных
- наличие данных в современных форматах для выгрузки: сжатые CSV, Parquet и др.
- наличие предсказуемой инфраструктуры для интеграции с ETL/ELT системами получения данных
———
У этих 3-х групп есть ряд подгрупп которые имеют свою специфику:
- журналисты. Имеют те же требования что и аналитики, с меньшим погружением в технологии, с большим погружением в доступность данных.
- AI/ML инженеры. Помимо ожиданий разработчиков и дата инженеров у них еще присутствует потребность именно в данных большого объема для обучения, интегрируемость в стеки данных и интегрируемость в продуктами вроде Hugging Face
- статистики. Это не только сотрудники статслужб, но и профессиональные пользователи их данных. Они могут быть аналитиками и исследователями и тут важным становится наличие значимых метаданных и специальных стандартов и форматов SDMX, DDI и тд.
- геоаналитики и георазработчики. Подгруппы аналитиков и разработчиков с упором на геоданные, ключевое здесь это наличие возможности поиска данных по геопривязке, получению их в форме стандартизированных API ArcGIS/OGC и возможность выгрузки в наиболее востребованных форматах геоданных
—
Пользователь может быть в одной роли или хоть сразу в нескольких, важно то что любые публикуемые данные и создаваемые дата каталоги можно четко разметить по их потенциальным пользователям.

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

К примеру, когда я ругаюсь в адрес российского портала data.gov.ru, то могу объяснить это довольно просто. Можно посмотреть на него глазами любой из перечисленных ролей/групп пользователей и убедиться что для их задач он непригоден.

#opendata #users #thoughts #data

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

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

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

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

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

#thoughts #ai #aiagents #laws #lawmaking

Картинка из обзора изменений торговли Китая из Our World in Data. Она, с одной стороны наглядная, а с другой если бы я делал визуализацию по реальным изменениям в торговле Китая я бы сравнивал цифрами не только по числу стран где Китай стал главным торговым партнером, но и по многим другим параметрам.

Например, рост влияния можно измерить по измерению совокупной доли ВВП стран где Китай стал основным торговым партнером, по изменению влияния по блокам стран не только континентальным, но и экономическим: ЕС, АСЕАН, ЕАЭС, НАФТА, Меркосур и др.

Для того чтобы такое измерять можно применять все тот же код internacia-db который я недавно заопенсорсил для Dateno и где он уже используется.

Вообще один из моих любимых проектов по визуализации международной торговли это OEC (The Observatory of Economic Complexity).

А можно было бы уже создать Обсерваторию экономической зависимости [от Китая], как отражение изменений в мировой экономике в динамике.

#dataviz #china #thoughts #economics #trade

Хорошая картинка (подсмотрена в интернете) существующая в куче вариаций где вместо Undocumented code часто встречается "Tom with documentation in his head" но в целом это системная ситуация когда компании придумывают ИИ стратегии, а они упираются в проблемы текущих процессов, текущих информационных систем и огромные запасы legacy существующего в режиме "работает - не трожь!" которое приходит время потрогать, а трогать то боязно.

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

В частности:
1. Активное применение ИИ для документирования кода и приведение legacy кода в порядок. Стоимость этих задач падает постоянно и уже не представляется безусловным кошмаром
2. Применение ИИ агентов для архитектурного перепроектирования интеграции, конвееров данных и унаследованных систем
3. Применение ИИ агентов для формирования итоговых вариантов стратегии ИИ для клиентов (как кусочка более полной ИИ стратегии) на основе всего этого вместе взятого.

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

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

#thoughts #ai #aiagents #legacycode

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

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

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

В общей сложности на 12281каталогов данных приходится 85956 ошибок, много, да? Потому что правила валидации весьма скурпулёзные и 49 тысяч из них - это проверка точек подключения к API (у одного каталога данных может быть до двух десятков таких API содержащих разные метаданные и данные).

Другие частые ошибки в отсутствии информации о лицензии каталога данных (она не всегда есть на уровне каталога, чаще лицензии указываются на уровне набора данных внутри, поэтому это корректируемое правило) и в отсутствии внешних идентификаторов у каталогов данных - это мэппинг каталогов данных на Wikidata и другие референсные источники, но тут важно знать что у большинства каталогов данных нет этих референсных источников и сам Dateno ими является.

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

Что важно что все отчеты по качеству данных специально генерируются таким образом чтобы их можно было читать и править самостоятельно или же отдавать ИИ агенту командой примерно такого содержания "Fix issues listed in [название файла]"

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

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

Они включают:
- проверку и правку кода в части стилистика и линтинга (а ля pylint и аналоги для Python)
- подготовку и обновление тестов
- обновление документации (минимальное или весьма комплексное)
- acceptance тестирование (и другие виды тестирования при необходимости)
- сборка и релиз на Github/Gitlab/другой способ управления кодом

Многое из этого вшито в CI/CD пайплайны, но многое из этого может быть ИИ автоматизировано. Вопрос может ли это быть автоматизировано в IDE на стороне пользователя и пройти ручную финальную проверку или вынесено в CI/CD на внешнем сервисе и ручная проверка необязательна.

Мои ощущения что это скорее расширяемые модели контролируемых сценариев/строительных блоков внутри IDE с обязательными стадиями ручного контроля.

#thoughts #dateno #datacatalogs #dataquality