Хорошая картинка (подсмотрена в интернете) существующая в куче вариаций где вместо Undocumented code часто встречается "Tom with documentation in his head" но в целом это системная ситуация когда компании придумывают ИИ стратегии, а они упираются в проблемы текущих процессов, текущих информационных систем и огромные запасы legacy существующего в режиме "работает - не трожь!" которое приходит время потрогать, а трогать то боязно.
Размышляя над этим я бы начал с того что ИИ стратегия должна быть не "маркетинговой пришлепком сверху" с ИИ фичами для клиента, а то что охватывает все процессы которые к этому приводят.
В частности:
1. Активное применение ИИ для документирования кода и приведение legacy кода в порядок. Стоимость этих задач падает постоянно и уже не представляется безусловным кошмаром
2. Применение ИИ агентов для архитектурного перепроектирования интеграции, конвееров данных и унаследованных систем
3. Применение ИИ агентов для формирования итоговых вариантов стратегии ИИ для клиентов (как кусочка более полной ИИ стратегии) на основе всего этого вместе взятого.
Но начинать надо с недокументированного кода и эта задача как раз с помощью ИИ решается вполне реалистично, но Том с документации в голове останется без работы и поэтому это и есть первоочередная задача.
И это касается не только корпоративных ситуаций, но и многих других. Должны ли быть принятые ИИ стратегии у всех госорганов и многих крупных госучреждений? Должна ли резко упасть стоимость разработки государственных информационных систем? Ответ - да, безусловно.
#thoughts #ai #aiagents #legacycode
Размышляя над этим я бы начал с того что ИИ стратегия должна быть не "маркетинговой пришлепком сверху" с ИИ фичами для клиента, а то что охватывает все процессы которые к этому приводят.
В частности:
1. Активное применение ИИ для документирования кода и приведение legacy кода в порядок. Стоимость этих задач падает постоянно и уже не представляется безусловным кошмаром
2. Применение ИИ агентов для архитектурного перепроектирования интеграции, конвееров данных и унаследованных систем
3. Применение ИИ агентов для формирования итоговых вариантов стратегии ИИ для клиентов (как кусочка более полной ИИ стратегии) на основе всего этого вместе взятого.
Но начинать надо с недокументированного кода и эта задача как раз с помощью ИИ решается вполне реалистично, но Том с документации в голове останется без работы и поэтому это и есть первоочередная задача.
И это касается не только корпоративных ситуаций, но и многих других. Должны ли быть принятые ИИ стратегии у всех госорганов и многих крупных госучреждений? Должна ли резко упасть стоимость разработки государственных информационных систем? Ответ - да, безусловно.
#thoughts #ai #aiagents #legacycode
1👍9⚡2❤2
Ещё в продолжение правильного применения ИИ агентов, я системно занялся реестром каталогов данных в 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
А сейчас, в рамках задач по повышению качества индекса 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
🔥6⚡2❤1👍1😁1
К вопросу про российский мессенжер Max, помимо достаточно очевидных проблем с тем что он "как бы государственный, но не государственный", с его довольно бесцеремонным продвижением используя административный ресурс и массой других уже написанных многими проблем, я подниму ещё одну тему о которой не пишут.
Это архивация. В сравнении с телеграмом у Max'а есть два очень существенных отличия:
1. Отсутствует возможность просматривать содержание каналов онлайн без авторизации
2. Отсутствует возможность делать data takeout хотя бы для своих данных, а в идеале и для любых каналов и чатов
Первое влияет на то что содержание из Max не индексируется поисковиками и Интернет Архивом (они собирают только общедоступные матералы доступные через https/http). К примеру, в телеграм можно смотреть без авторизации, вот так выглядит там мой телеграм канал https://t.me/s/begtin
Второе на то что невозможно сделать архив ни своих чатов, ни своих каналов, ни читаемых каналов. Просто не предусмотрено.
В итоге Max - это закрытое контролируемое не архивируемое пространство где даже чтение постов прошедших авторизацию каналов идет только под контролем (только после авторизации) даже в веб клиенте.
Вопрос остается в том будет ли там хоть что-то полезное, не продублированное в Телеграм'е? Насколько реально велик риск блокировки телеграма в ближайшее время и переход части авторов каналов туда?
Если велик, то видимо надо заморачиваться придумыванием организации архивации материалов в Max'е для чего документированного API не наблюдается и нужен дотошный разработчик готовый такой инструмент разработать.
#digitalpreservation #thoughts
Это архивация. В сравнении с телеграмом у Max'а есть два очень существенных отличия:
1. Отсутствует возможность просматривать содержание каналов онлайн без авторизации
2. Отсутствует возможность делать data takeout хотя бы для своих данных, а в идеале и для любых каналов и чатов
Первое влияет на то что содержание из Max не индексируется поисковиками и Интернет Архивом (они собирают только общедоступные матералы доступные через https/http). К примеру, в телеграм можно смотреть без авторизации, вот так выглядит там мой телеграм канал https://t.me/s/begtin
Второе на то что невозможно сделать архив ни своих чатов, ни своих каналов, ни читаемых каналов. Просто не предусмотрено.
В итоге Max - это закрытое контролируемое не архивируемое пространство где даже чтение постов прошедших авторизацию каналов идет только под контролем (только после авторизации) даже в веб клиенте.
Вопрос остается в том будет ли там хоть что-то полезное, не продублированное в Телеграм'е? Насколько реально велик риск блокировки телеграма в ближайшее время и переход части авторов каналов туда?
Если велик, то видимо надо заморачиваться придумыванием организации архивации материалов в Max'е для чего документированного API не наблюдается и нужен дотошный разработчик готовый такой инструмент разработать.
#digitalpreservation #thoughts
1👍13🔥5💯4❤1😢1