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

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

Похожим образом примерно 20 лет назад я уходил из роли технического архитектора в системном интеграторе в создание собственной компании через восстановления знаний в Python и создание первого стартапа используя самую раннюю версию Django и MySQL для анализа госзакупок. Фактически за год я тогда восстановил хард скиллы.

Зато что я могу сказать точно что наконец-то чувствую себя восстановившимся после COVID'а. Первые 2 года после него дались мне, честно говоря, довольно тяжело и только к 2024 я уже более менее нормально начал себя чувствовать, а в 2025 году уже чувствую себя достаточно живым чтобы ощущать что мир меняется слишком быстро чтобы позволить себе отставать.

#thoughts #personal

Хороший обзор Eight Software Markets AI That Will Transform Differently того как изменится рынок программного обеспечения в ближайшее время под воздействием развития ИИ инструментов. Из 8 ИТ рынка по настоящему радоваться могут исследователи, для них открывается бесконечный новый мир быстрого создания ПО и кода под свои задачи.

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

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

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

Можно представить, на выбор, укоренившихся вендоров ПО в некоторых отраслях и спокойно имевших свою долю рынка и неспешно на нем живших, а вдруг окажется что то что они делали пару десятилетий можно воспроизвести за 6 месяцев? за 3 месяца?

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

#ai #thoughts #itmarket

Я довольно много писал про разные форматы файлов в дата инженерии и не только, с одной стороны это кажется очень внутренне-технической темой, неочевидной для тех кто не работает с данными постоянно, с другой стороны в обзоре от Andy Pavlov про СУБД за 2025 год активная конкуренция форматов явно упоминается. Потому что (внезапно!) оказалось что то как ты хранишь данные и то как хранят данные кто-то ещё и которые тебе необходимо использовать может быть как очень удобно и практично, так и создавать ничем не обоснованные дополнительные издержки.

Я привожу в пример как часто на порталах открытых данных публикуют CSV или XML файлы внутри ZIP архивов в формате: один файл - один архив. Но данные/файлы внутри ZIP архивов не приспособлены (без шаманства) для потоковой обработки. Их надо вначале распаковать куда-то как временные файлы, а потом уже обрабатывать и временные файлы удалять. Если файлы небольшие то и ладно, а если это десятки и сотни гигабайт и таких задач много, то возникает вопрос: А отчего же так? Это решается распространением датасетов не в виде ZIP архивов, а сжатием из GZip, LZMA, Zstandard, LZ4 и тд., способами и форматами сжатых данных изначально приспособленных под потоковую обработку. Собственно под такие форматы я делал iterabledata, библиотеку для Python. Она про то чтобы условно любой файл с таблицами или объектами можно было бы перебирать как это принято в Python в csv.DictReader. Последовательный перебор с возвращанием каждой записи как словаря (dict).

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

Вот примеры таких форматов: WARC (файлы веб архивов), PCAP (файлы перехвата сетевого трафика), SAS (файлы статпакета SAS), и еще много что: BSON, KML, GML, XLS, ODS и так далее. Реально огромное число форматов не поддаются фильтрации без загрузки в память или не через фильтрацию при тотальном переборе.

Поэтому когда доходит до их обработки, приходится преобразовывать их полностью или частично в parquet. К примеру, для WARC файлов я всегда их преобразую в один или несколько parquet файлов с метаданными, а оригинальные файлы рассматриваю как контейнеры для контента. И это я не сам придумал, а подсмотрел когда-то у Common Crawl, они поступают аналогично поскольку без этой процедуры собирать статистику сложно, надо перелопачивать каждый WARC файл, а это гигабайты-терабайты-петабайты.

Однако и сам формат Parquet'а неидеален и об этом регулярно пишут в разных местах и появляются такие форматы как Lance, Vortex, Nimble, Vortex, FastLanes и другие. Пока они довольно редки в открытом доступе, но постепенно проявляются. Впрочем parquet оказался достаточно эффективным чтобы эта замена длилась ещё какое-то количество леь

А вот чтобы я бы предсказал так то что грядет тренд на parquet'изацию данных, когда просто сильно удобнее распространять их в структурированном подобным образом виде. Возможно через рассмотрения parquet файлов как контейнеры, а возможно как файлы-сателлиты с метаданным к файлам контейнерам. К примеру, можно вполне заменить VCF файлы (генетика) на Parquet или файлы LDIF (директории пользователей LDAP) на Parquet или файлы KML и GML (геоданные) и тд.

#thoughts #data #dataengineering #fileformats

Чем следователь (дознаватель) отличается от археолога ? Археолог копает чтобы поместить результаты в музей/архив, а следователь чтобы найти улики преступления. Но существенная часть их работы пересекается, оба копаются в земле, инвентаризируют и изучают результаты. Некоторые инструменты (лопаты, щётки) практически идентичные.

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

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

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

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

Удивительное дело, так почему не дознавателей не учат на архивистов, а архивистов на дознавателей? 🙈

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

#thoughts

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

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

А я бы добавил к этому следующее:
1. Планирование через OpenSpec или его аналоги. Очень хорошо структурирует процесс проектирования и коммуникации с ИИ агентом. Для сложного и унаследованного кода - это просто необходимо. В принципе разделять планирование и реализацию, на стадии планирования не меняется код, а результаты - спеки и планы.
2. Cursor и аналогичные инструменты (Antigravity, Copilot и тд.) могут выполнять роль инструментов исследовательской поддержки и аналитики. Например, формируz отчеты по конкурентам, проектируя инструменты бенчмарков с ними, подготовка аналитики по разным функциям, проектирование верхнеуровневой архитектуры и тд.
3. ИИ ассистент - это не только объект проверки (а не кривой ли код он написал?), но и сам является контуром контроля качества. Поэтому на каждой итерации внедрения фич необходим контур создания и проверки тестов, линтинга кода, обновления документации и тд. Это частично решается уже сейчас на стадиях планирования и спеков, но опыт показывает что явное указание этих обязательных проверок дает больше гарантии что код будет не поломан и документация будет актуальной.
4. Инструменты для разработки вполне способны не только писать код, но и писать документы. Подход такой же может быть как к репозиториям кода с использованием спецификаций, планирования и тд. Иначе говоря при проектировании больших ИТ продуктов можно создать отдельный репозиторий с архитектурой продуктов и от него создавать все остальные. Например, если надо условно с нуля сделать продукт у которого есть фронтэнд, бэкэнд, REST API, SDK, интеграционные модули и тд., то вместо того чтобы все засовывать в один репозиторий или сразу разбивать на множество, имеет смысл собрать архитектурный репозиторий с документами.

#ai #coding #thoughts #readings

Разные мысли вслух:
1. Термин "большие данные" в 2026 году выглядит анахронизмом, а экономика больших данных особенно. Когда слышу его от кого-либо то вот прямо таки ощущаю что человек находится вне контекста и, либо не понимает предметной области (увы), либо довольно долго был от нее оторван. Условно нет никакой "экономики больших данных", есть экономика данных, но и она, условно, слепляется с ИИ стартапами и ИИ экономикой. В этом есть странное смешение хайпа, реальности и страха потому что это гораздо большие изменения цифровых экосистем чем что-то ещё.
2. Евросоюз запустил публичное обсуждение стратегии импортозамещения и снижения зависимости от США стратегии открытой цифровой экосистемы которая должна помочь цифровому суверенитету ЕС и которая формируется из открытости кода, открытости данных и так далее. Мне такой подход нравится больше чем российское импортозамещение, но реалистичность реального цифрового суверенитета для ЕС, по моему, невелика. Однако если ВЫ резидент ЕС и работаете с открытым кодом и данными, то почему бы не поддержать такое хорошее дело?

#opendata #bigdata #thoughts #opensource #eu

Я про политику и макрополитику в особенности не пишу давно и особо писать об этом не планирую ибо слишком много срани неприличного там происходит повсеместно, но есть и то что затрагивает вопросы открытости. Например, свежая новость что США выходят из 66 международных организаций и международных групп включая 31 группу и структуру ООН включая UN Oceans, UN Population Fund, UN Water, UN Energy, Department of Economic and Social Affairs (DESA) и многих других.

Последствия могут быть весьма разнообразны, учитывая что выход США практически наверняка означает потерю существенного финансирования ООН, но не менее важно и то что многие структуры ООН создают и распространяют данные используемые по всему. миру. Например, DESA ведёт data.un.org портал официальной статистики.

Что будет со многими международными инициативами про данные на базе ООН в 2026 году? Я вот не знаю, похоже что надо отслеживать эту ситуацию.

Другой аспект в структурах из которых США пока формально не вышли, но перестали финансировать. Формально США всё еще участвуют в Open Government Partnership, а де факто с января 2025 года они перестали финансировать эту организацию и НКО внутри США ещё в марте 2025 года писали письмо в OGP о том чтобы провести ревизию обязательств Правительства США по открытости.

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

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

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

#opendata #opengov #thoughts #international #usa

Наблюдаю взлет сервисов автоматического документирования публичных (и не публичных) репозиториев кода. Помимо хорошо известного DeepWiki есть, как минимум, Zread.ai и os.ninja, DeepWiki-Open, OpenDeepWiki, GitSummarize, DeepDocs и другие.

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

В общем, выглядит это всё это как интересный тренд, но с непонятным итогом потому что неявным маркетмейкером тут является Github (Microsoft) который быстро может убить все эти попытки, ну или как минимум сильно обесценить.

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

#thoughts #ai #documentation

На днях мне понадобился полный дамп метаданных из европейского портала data.europa.eu для анализа. Там почти 2 миллиона наборов данных и он пока еще не проиндексирован Dateno поскольку работает на нестандартном ПО. Его было бы гораздо проще индексировать скачав полный дамп и индексировать метаданные из него.

Дамп я в итоге нашел, хотя и неочевидным образом, он нашелся только одним из Deep Research инструментом, а вот "гугление" не сработало и другие Depp Research агенты тоже как один предлагали написать скрипт по выкачке этих данных через API.

Однако что оказалось в дампе, в дампе оказались сотни файлов в формате TriG, это такой специальный формат для экспорта спецификации RDF используемой в продуктах Semantic Web/Linked Data. Никакими классическими инструментами аналитики или инженерии данных работать с ним не получится. Нужно писать конвертер по преобразованию этих дампов в какой-либо другой формат, скорее всего в JSON/JSON lines как самый очевидный.

Почему разработчики европейского портала публикуют данные в TriG формате? Потому что они считают это правильным. Связанные данные (Linked Data) это, в первую очередь, европейский концепт описания знаний. В Европе более чем где-либо существуют команды разработчиков разбирающихся в нем и связанных с академической среде где он более популярен.

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

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

#opendata #europe #rdf #semanticweb #linkeddata #thoughts

Разные мысли вслух, с некоторым повторением:
1. До того как произойдет AGI (если это вообще наступит) есть то что произойдет неизбежно - когда алгоритмы компьютерного зрения, анализа изображений и видео, анализа текстов, документов, радиочастотного спектра и тд. сильно превосходящее человека. Оно ИМХО уже могло бы произойти, но это может быть пугающим опытом когда это будет в потребительских устройствах или автоматизированных роботизированных платформах.
2. Когда появятся языки программирования с LLM в интерпретаторе и компиляторе, а не просто заточенные под LLM? Думаю что скоро
3. Где-то уже должен взлетать бизнес по ускоренному клонированию корпоративного ПО. Вайб кодить будут не внутри потребителей софта, а маленькие команды которые будут на заказ средних компаний клонировать продукты крупняка. Бигтехи будут защищены от этого интегрированностью продуктов и тем что они одновременно крупнейшие хостеры/ресурсопровайдеры
4. Наступит ли демократизация инструментов разрушения вместе с развитием роботизации? Умный ИИ может не атаковать инфраструктуру человечества напрямую (а ля Скайнет), а использовать прокси-террористов и анонимную коммуникацию и криптовалюту для оплаты

#thoughts

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

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

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

С открытыми данными такая же ситуация. Они доступны не по запросу, не после регистрации, не имеют ограничения на коммерческое использование. Принципы открытых данных для того и разрабатывались чтобы создать юридически значимую процедуру публикации данных для их повторного использования. Ожидаемо многие эксплуатируют термин для того чтобы притворяться что они относятся к открытости, сами данные не публикуя. Данные не под свободными лицензиями открытыми не являются, данные доступные по запросу также, их называют данными с регламентированным доступом. Open Data Institute называет их данными в Public Access или Group Based Access. Это нормально если кто-то не хочет давать данные как открытые, но не надо никого обманывать и называть открытыми данными то что таким не является.

Термин большие данные вообще является маркетинговым, он был придуман для продажи инструментов для работы с данными которые достаточно велики чтобы с ними было неудобно работать на десктопе. Его применение довольно широко, определение весьма условно и сейчас, в 2026 году, им пользуются, в основном, те кто не имеет отношения к дата инженерии, data science и тд. В профессиональном обиходе его уже нет, используют его те кто, или оторван от рынка данных, или пытаются напихнуть buzzword'ов в свою речь. Разговоры в стиле мы используем большие данные быстро выдают непрофессионала.

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

А с какими терминологическими искажениями вы сталкиваетесь? Что с ними делаете?

#opendata #opensource #thoughts #questions

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

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

3. Свежий доклад World Bank про распространение ИИ в развивающихся странах о том что есть новая форма неравенства в том как ИИ создается и применяется в странах с невысокими доходами. Акцент на малых моделях SLM работающих на повседневных устройствах. Тут важно не забывать что ИИ модели - это не только инструменты, но и де-факто срез мировых знаний локальные страновые модели будут применяться для цензурирования контента. Регуляторы к этому медленно адаптируются, они просто не успевают за потоком изменений, но этот поток не вечно будет столь изменчивым. Когда поток изменений поубавится или хотя бы станет предсказуемым жесткое регулирование будет неизбежным.

#thoughts #ai #itmarket

Судя по новостям в России начали банить Telegram и я мог бы много чего сказать про глупость этого, про то что по рядовым чиновникам и госслужащим это бьет не меньше чем по всем остальными о том что внутри российских госорганов недоверие MAX'у не меньшее чем у простых и продвинутых россиян. Политическая целесообразность, тем не менее, в РФ абсолютно затмевает экономическую.

Тем не менее я не сомневаюсь что аудиторию мой канал не потеряет как и большая часть коммуникаций сохранится. Самое очевидное и значимое то что:
1. Многие команды работающие в РФ частично или полностью будут вынуждены теперь повсеместно использовать VPN. Я, кстати, не испытываю сомнений что пока SSH протокол не начали замедлять будет сложно заблокировать что VPN'ы что прокси для отдельных приложений.
2. Не только в контексте РФ, но и других стран есть явная ниша для zero-config сервисов вроде Tailscale или Twingate для организации внутрикорпоративных сетей. Применительно к РФ их главный недостаток сейчас в том что они работают с использованием Wireguard как основного протокола.

#thoughts

Мысли вслух, если все эти разговоры что РФ и США будут укреплять экономические связи если/когда закончится активная фаза военного конфликта, то звучит это всё так что существенная часть импортозамещения пойдет, выражаясь образно, ослу под хвост.

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

Но и это не так критично как то что американские ИИ-бигтехи быстро сожрут весь потребительский рынок прикладных ИИ ассистентов для конечных потребителей. Что Сбер, что Яндекс, им сейчас не конкуренты по множеству объективных причин.

#thoughts #itmarket

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

Вот в пример задача которую я регулярно решаю - пополнение реестра каталогов Dateno (dateno.io/registry) и я регулярно задаю сложные вопросы для deep thinking сервисов которые звучат как "мне нужен полный список сайтов работающих на базе YYY" (реальные промпты посложнее, но так понятнее) и в ответ я получаю довольно неплохо структурированные ответы о том как искать эти данные на сайте вендора или запросами к Google и оценки трудоёмкости в несколько месяцев.

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

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

#opendata #thoughts #ai

Немного отвлекаясь от темы данных, про замедление Telegram в РФ сухо и тезисно.

Часть первая

Про Telegram
1. Telegram в России достиг высокого уровня проникновения в жёсткой конкурентной борьбе с другими мессенжерами благодаря множеству качественных параметров которые так просто не воспроизвести по причине создания эффективной экосистемы и высоко заданной планке скорости работы и прозрачности (открытый код, публичные аудиты шифрования и тд.)
2. Учитывая массовость его проникновения в массовую аудиторию и активное проникновение во все сферы жизни от частной переписки до использования бизнесом и органами власти его "замедление" это глобальный болезненный процесс для личных коммуникаций, бизнеса и организационных процессов для десятков миллионов людей.
3. Фактически владелец(-ы) Telegram'а находятся в ситуации ультиматума потерять российский рынок или мировой. Как бы ни была болезнена для них потеря российского рынка она более вероятна чем потеря существенной части мирового. А потери неизбежны при любом исходе текущей ситуации с "замеделением".
4. При этом полной потери российского рынка у Telegram не произойдет поскольку для многих Telegram не только стал привычной, но и срабатывает накопительный эффект. Огромные архивы сообщений, знаний, документов и иных материалов находятся именно в экосистеме Telegram'а и скорее многие из тех кто ещё не озаботился наличием VPN сервисов сделают это в течение короткого времени.
5. С учетом этого, скорее всего, Telegram потеряет не всю российскую аудиторию, а только наименее образованную, технически неграмотную и замкнутую только на внутрироссийские коммуникации.

Про мессенжер MAX
4. Мессенжер MAX которые де-факто предлагается политическими властями ему на замену был бы неплох обладай он хотя бы частью качественных характеристик Telegram'а, но ключевые его характеристики в нём не могут быть реализованы скорее по политическим чем по техническим причинам. Команда MAX'а не может открыть его код, не может обеспечить полную приватность переписки, не может гарантировать отсутствие доступа к данным переписки для органов власти.
5. Государственное продвижение MAX'а создало очень сильный обратный эффект и резкое неприятие пользователями как и любой жёстко навязываемый сервис. Декларируемые большие цифры охвата аудитории: а) Невозможно перепроверить. б) Ничего не говорят о реальном использовании, а не о полупринудительной регистрации в сервисе бюджетников и прочих слабозащищенных давлению лиц.
6. Попытки продвижения MAX'а как инструмента взаимодействия с гос-вом дезавуируют длительные усилия по развития экосистемы Госуслуг и других полностью государственных мобильных приложений и сервисов. Зачем получать сервисы через MAX если в России столь сильны позиции в fintech'е включая госбанки, если так хорошо было сделано приложение Госуслуг?
7. Можно констатировать что продвижение MAX'а через его потребительские качества провалилось, а насильственное продвижение вызывает лишь усиление сопротивления его использованию.
#thoughts #telegram #MAX

Часть вторая

А можно ли было по другому?
8. Предположим что потребность в национальном мессенжере реальна, благо такие есть в некоторых странах, а в других странах правительства также поднимают этот вопрос. Неужели нельзя было бы решать эту задачу иначе? Были ли и есть ли другие варианты? Они точно были, но уже маловероятны из-за того что государственная машина в РФ умеет останавливаться, но не умеет идти назад (я такого не наблюдал).
9. Например, можно было выделить порядка 10 млрд рублей и раздать их субсидиями тем кто мог бы создавать нац. мессенжеры при заданных Пр-вом условиях. Большие субсидии российскому бигтеху, поменьше - средним ИТ компаниям и небольшие малым командам и энтузиастам. 10 млрд рублей сумма условная, но думаю что идея понятная. Появился бы Авито Мессенжер, WB мессенжер, Сбер Мессенжер да и тот же Яндекс мог бы вернуться к созданию своего мессенжера (или не мог бы если бы не захотел). Создание внутренней конкуренции - это хорошая идея, у многие крупных российских цифровых сервисов есть достаточная опорная пользовательская база чтобы попытаться поконкурировать. Особенно если кроме выделенной субсидии на разработку выделить ещё и субсидии на поддержку привязанные к количеству зарегистрированных и активных пользователей.
10. Другая альтернатива могла бы быть в запуске полностью государственного мессенжера. Как ни парадоксально, но доверие к гос-ву по умолчанию в РФ высокое и Госуслуги.Мессенжер пользовался бы как минимум внутрироссийской популярностью. Репутационно это выглядело бы лучше чем продвижение мессенжера компании являющейся дочерним обществом ВК. Да, у Госмессенжера были бы свои минусы, но меньше чем у MAX сейчас.
11. Всё это с оговорками про наличие такой целесообразности, а в ней прямо скажем, есть существенные сомнения. Усиление государственного контроля проходит куда безболезненнее в ситуации его невидимости, а тут, наоборот, демонстрационное насилие. Даже с государственнической позиции это плохой путь, а уж с гражданской так и вовсе негодный.

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

#thoughts #telegram #MAX

Разные мысли вслух про аналитику:
- непонятно эпоха дашбордов прошла или нет, ощущения что отношение к ним меняется по мере изменений привычек пользователей использовать ИИ ассистенты. Тем кому это стало привычным встраивание ассистента в BI системы принесет это немало пользы, но нет ощущения массовости пока что.
- ИИ ассистент внутри продукта или продукт адаптированный под ИИ ассистента? Вопрос как общий так и частный применительно к дата аналитике. А может быть и то и то. К примеру, внутри Censys ИИ ассистент хорошо отвечает на вопросы по внутренней документации и генерирует запросы из человеческого описания, но не выполняет их.
- со многими аналитическими публичными проектами нынче беда-беда. Недавно я раскопал несколько документов с видением разных проектов по аналитике на общедоступных данных в РФ и отправил их в deep research инструменты. На что они хором дали вывод что все это нужно и полезно, но несет прямые риски и вообще может быть причиной для иноагентства. С публичной аналитикой нынче сложно, данные могут быть доступны, но свобода их анализа ограничена рисками самого разного толка.
- продвинутые deep research инструменты теперь применяют финансовые ограничители, а не токенные. Устанавливаешь что на исследование готов потратить $5 и получаешь отчет на $5, устанавливаешь что готов $50 то и получаешь результат... получше и так далее. В любом случае это дешевле чем чем проводить такой анализ самостоятельно или нанимать кого-то.

#thoughts

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

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

Я бы сказал что оборонительное регулирование (guardian legislation) неизбежно во всех странах пытающихся создавать собственные LLM за госсчёт или за счет национальных технологических монополий и олигополий.

Регуляторы многих стран сейчас будут списывать друг у друга всё то плохое регулирование которое они только смогут придумать.

А какое могло бы быть хорошим?

#thoughts #aiagents