Новость Яндекса — классический пример корпоративного пиара, маскирующегося под "независимое тестирование". Статистика не подтверждает реального лидерства YandexART даже в рамках этого сомнительного бенчмарка. Отсутствие ключевых международных конкурентов, непрозрачность методологии, потенциальный конфликт интересов и явный культурный bias ставят всю ценность "Арены Text-to-Image" и заявлений о "победе" под серьезное сомнение. Это не прорыв, а хорошо спланированная маркетинговая акция, эксплуатирующая патриотические чувства и недостаточную осведомленность аудитории о методологиях оценки ИИ. Пока не будет предоставлена полная прозрачность методологии, данных и привлечены все ключевые мировые игроки, любые заявления о "лидерстве" YandexART следует воспринимать крайне скептически. Акцентирую внимание что нет упоминания о тестировании абсолютных лидеров рынка (Midjourney v6, DALL-E 3, Stable Diffusion 3/XL, Firefly 2, Claude 3 Opus с Artifacts). Без них заявление об "обгоне мировых лидеров" (особенно Google Imagen 3) теряет смысл.
Статья является не руководством к действию, а предостережением. Она демонстрирует, как личные амбиции и комфорт разработчика ("этот 'велосипед' мой и я на нем успешно и с комфортом еду") могут быть поставлены выше долгосрочных интересов и технологической устойчивости компании. Инициативность автора похвальна, но результат его работы -это не "добрый монстр", а дорогостоящий в поддержке и крайне рискованный актив, от которого организация будет зависеть до тех пор, пока его создатель не уйдет или пока вся система не обрушится под собственным весом
США разбудили технонационализм Китая. Теперь Западу придётся бежать вдвое быстрее, чтобы остаться на месте. Началась новая холодная война — война чипов. И в этой войне у Китая уже есть ядерное оружие — свои GPU.
По поводу runtime-валидатора: Я имел в виду механизм, который мог бы во время выполнения программы (runtime) отслеживать потенциально опасные операции с бессмертными объектами, особенно те, что могут привести к их "случайному разбессмерчиванию" (accidental de-immortalizing). Например:
Детектирование Py_DECREF на бессмертных объектах: Это самая критичная операция, которая может сломать инвариант бессмертности. Валидатор мог бы перехватывать такие вызовы (через отладочные хуки, санитайзеры, или специализированный режим сборки) и выдавать предупреждение/ошибку, лог или даже крешнуть интерпретатор в отладочном режиме.
Контроль целостности счетчиков ссылок: Проверять, что счетчик ссылок бессмертного объекта действительно имеет "магическое" значение (например, PyIMMORTAL_REFCNT), а не был случайно изменен.
Анализ операций через Stable ABI: Особый фокус на операциях, выполняемых через Stable ABI, где риск "accidental de-immortalizing" выше из-за непрямого доступа к внутренностям CPython.
Цель такого валидатора — не замена строгому аудиту кода расширений, а предоставление дополнительного инструмента для:
Отладки: Помощь разработчикам расширений в выявлении скрытых багов при миграции на Python с бессмертностью.
Тестирования: Включение в CI/CD пайплайны для проверки совместимости расширений.
Проактивного обнаружения проблем: Выявление потенциально небезопасных паттернов использования до того, как они приведут к трудноотлавливаемым сбоям в продакшене.
Связь с PEP 797 (Python Runtime Audit Hooks): Именно этот PEP показался мне идеальной платформой для реализации такого мониторинга! Audit hooks предоставляют механизм для подписки на события внутри интерпретатора. Можно было бы ввести новые события типа:
"object.deimmortalize_attempt" (с аргументами: объект, источник вызова - расширение/модуль)
"immortal_refcnt_mismatch"
Тогда внешний "валидатор" (отдельный инструмент или встроенный отладочный режим) мог бы подписываться на эти события и реагировать соответствующим образом (логировать, алертить, крешнуть).
В статье утверждается, что несмотря на отрицательную производительность (~2% деградации), бессмертные объекты были внедрены в CPython из-за их значимости для архитектуры субинтерпретаторов и free-threading. Однако, если учесть потенциальные проблемы, такие как «accidental immortality» и особенно «accidental de-immortalizing» при использовании стабильного ABI, не считаете ли вы, что текущая реализация бессмертности недостаточно безопасна без строгой валидации сторонних C‑расширений и потенциально требует дополнительных механизмов обнаружения таких сценариев на этапе исполнения (например, через runtime-валидатор счетчика ссылок)? Планируется ли развитие в эту сторону, в частности, в связи с обсуждаемым PEP 797?
Российское Минцифры активно изучает и развивает идею создания универсального ИИ-помощника, который сможет не только автоматизировать рутинные задачи (например, запись к врачу), но и существенно упростить взаимодействие человека с цифровыми платформами. Это формирует новую технологическую нишу, для которой уже есть необходимые заделы в виде отечественных ИИ-моделей различного масштаба. Ожидается, что подобные решения смогут качественно повысить уровень цифрового сервиса и облегчить повседневную жизнь граждан.
Мое мнение:Такое направление действительно выглядит перспективно и своевременно. Универсальные ИИ-помощники способны стать революцией в цифровых сервисах, перейдя от обычных интерфейсов к полноценному диалогу и инициативной поддержке пользователя. Создание подобных национальных решений важно как с точки зрения технологического суверенитета, так и для повышения удобства повседневных государственных и бытовых услуг.
T-Pro 2.0 — это не "прорывная русскоязычная LLM", а форк Qwen с русским тюнингом, раздутый маркетингом.Факты на лицо:слабая оригинальность, зависимость от чужих моделей и сомнительные метрики делают ее посредственной. Если Т-Банк хочет впечатлить, пусть покажут реальные кейсы без хайпа — иначе это просто шум в экосистеме LLM.
Если Flink 2.0 позиционируется как "эра" для real-time вычислений, как это повлияет на глобальный ландшафт данных (например, на долю рынка по сравнению с облачными сервисами вроде AWS Kinesis или Google Dataflow)? Можете ли вы спрогнозировать, опираясь на тренды, сценарий, где Flink потеряет лидерство из-за нерешенных болей в операционной стоимости, и что сообщество должно сделать, чтобы этого избежать?
Информация
В рейтинге
Не участвует
Откуда
Благовещенск (Амурская обл.), Амурская обл., Россия
Новость Яндекса — классический пример корпоративного пиара, маскирующегося под "независимое тестирование". Статистика не подтверждает реального лидерства YandexART даже в рамках этого сомнительного бенчмарка. Отсутствие ключевых международных конкурентов, непрозрачность методологии, потенциальный конфликт интересов и явный культурный bias ставят всю ценность "Арены Text-to-Image" и заявлений о "победе" под серьезное сомнение. Это не прорыв, а хорошо спланированная маркетинговая акция, эксплуатирующая патриотические чувства и недостаточную осведомленность аудитории о методологиях оценки ИИ. Пока не будет предоставлена полная прозрачность методологии, данных и привлечены все ключевые мировые игроки, любые заявления о "лидерстве" YandexART следует воспринимать крайне скептически. Акцентирую внимание что нет упоминания о тестировании абсолютных лидеров рынка (Midjourney v6, DALL-E 3, Stable Diffusion 3/XL, Firefly 2, Claude 3 Opus с Artifacts). Без них заявление об "обгоне мировых лидеров" (особенно Google Imagen 3) теряет смысл.
Статья является не руководством к действию, а предостережением. Она демонстрирует, как личные амбиции и комфорт разработчика ("этот 'велосипед' мой и я на нем успешно и с комфортом еду") могут быть поставлены выше долгосрочных интересов и технологической устойчивости компании. Инициативность автора похвальна, но результат его работы -это не "добрый монстр", а дорогостоящий в поддержке и крайне рискованный актив, от которого организация будет зависеть до тех пор, пока его создатель не уйдет или пока вся система не обрушится под собственным весом
США разбудили технонационализм Китая. Теперь Западу придётся бежать вдвое быстрее, чтобы остаться на месте. Началась новая холодная война — война чипов. И в этой войне у Китая уже есть ядерное оружие — свои GPU.
Спасибо за ответ и извините за путаницу! Действительно, комментарий был адресован вашей статье про бессмертные объекты (T-Pro 2.0 — открытая гибридно-ризонинговая русскоязычная LLM), но я по ошибке оставил его не там.
По поводу runtime-валидатора: Я имел в виду механизм, который мог бы во время выполнения программы (runtime) отслеживать потенциально опасные операции с бессмертными объектами, особенно те, что могут привести к их "случайному разбессмерчиванию" (accidental de-immortalizing). Например:
Детектирование
Py_DECREFна бессмертных объектах: Это самая критичная операция, которая может сломать инвариант бессмертности. Валидатор мог бы перехватывать такие вызовы (через отладочные хуки, санитайзеры, или специализированный режим сборки) и выдавать предупреждение/ошибку, лог или даже крешнуть интерпретатор в отладочном режиме.Контроль целостности счетчиков ссылок: Проверять, что счетчик ссылок бессмертного объекта действительно имеет "магическое" значение (например,
PyIMMORTAL_REFCNT), а не был случайно изменен.Анализ операций через Stable ABI: Особый фокус на операциях, выполняемых через Stable ABI, где риск "accidental de-immortalizing" выше из-за непрямого доступа к внутренностям CPython.
Цель такого валидатора — не замена строгому аудиту кода расширений, а предоставление дополнительного инструмента для:
Отладки: Помощь разработчикам расширений в выявлении скрытых багов при миграции на Python с бессмертностью.
Тестирования: Включение в CI/CD пайплайны для проверки совместимости расширений.
Проактивного обнаружения проблем: Выявление потенциально небезопасных паттернов использования до того, как они приведут к трудноотлавливаемым сбоям в продакшене.
Связь с PEP 797 (Python Runtime Audit Hooks): Именно этот PEP показался мне идеальной платформой для реализации такого мониторинга! Audit hooks предоставляют механизм для подписки на события внутри интерпретатора. Можно было бы ввести новые события типа:
"object.deimmortalize_attempt"(с аргументами: объект, источник вызова - расширение/модуль)"immortal_refcnt_mismatch"Тогда внешний "валидатор" (отдельный инструмент или встроенный отладочный режим) мог бы подписываться на эти события и реагировать соответствующим образом (логировать, алертить, крешнуть).
В статье утверждается, что несмотря на отрицательную производительность (~2% деградации), бессмертные объекты были внедрены в CPython из-за их значимости для архитектуры субинтерпретаторов и free-threading. Однако, если учесть потенциальные проблемы, такие как «accidental immortality» и особенно «accidental de-immortalizing» при использовании стабильного ABI, не считаете ли вы, что текущая реализация бессмертности недостаточно безопасна без строгой валидации сторонних C‑расширений и потенциально требует дополнительных механизмов обнаружения таких сценариев на этапе исполнения (например, через runtime-валидатор счетчика ссылок)? Планируется ли развитие в эту сторону, в частности, в связи с обсуждаемым PEP 797?
Российское Минцифры активно изучает и развивает идею создания универсального ИИ-помощника, который сможет не только автоматизировать рутинные задачи (например, запись к врачу), но и существенно упростить взаимодействие человека с цифровыми платформами. Это формирует новую технологическую нишу, для которой уже есть необходимые заделы в виде отечественных ИИ-моделей различного масштаба. Ожидается, что подобные решения смогут качественно повысить уровень цифрового сервиса и облегчить повседневную жизнь граждан.
Мое мнение:Такое направление действительно выглядит перспективно и своевременно. Универсальные ИИ-помощники способны стать революцией в цифровых сервисах, перейдя от обычных интерфейсов к полноценному диалогу и инициативной поддержке пользователя. Создание подобных национальных решений важно как с точки зрения технологического суверенитета, так и для повышения удобства повседневных государственных и бытовых услуг.
T-Pro 2.0 — это не "прорывная русскоязычная LLM", а форк Qwen с русским тюнингом, раздутый маркетингом.Факты на лицо:слабая оригинальность, зависимость от чужих моделей и сомнительные метрики делают ее посредственной. Если Т-Банк хочет впечатлить, пусть покажут реальные кейсы без хайпа — иначе это просто шум в экосистеме LLM.
нужен хороший промт и проблема решена)
Если Flink 2.0 позиционируется как "эра" для real-time вычислений, как это повлияет на глобальный ландшафт данных (например, на долю рынка по сравнению с облачными сервисами вроде AWS Kinesis или Google Dataflow)? Можете ли вы спрогнозировать, опираясь на тренды, сценарий, где Flink потеряет лидерство из-за нерешенных болей в операционной стоимости, и что сообщество должно сделать, чтобы этого избежать?