Anthropic щойно опублікувала звіт, після якого важко думати про безпеку по-старому.
Думаю, ви вже бачили тривожну новину: AI-згенерований скрипт для обходу двофакторної автентифікації. Microsoft у своєму Cyber Signals фіксує що великі мовні моделі вже використовуються не просто для фішингових листів чи генерації шкідливого коду — а для пошуку реальних вразливостей у програмному забезпеченні.
Раніше інструменти для пошуку багів працювали механічно: шукали відомі патерни, запускали fuzzing, перевіряли типові помилки. Але LLM додають інший рівень — вони можуть аналізувати логіку коду й розуміти що програма мала б робити.
І ось тут з'являється новина яка показує наскільки швидко все змінюється.
Дослідники з Calif за 5 днів зібрали exploit для macOS kernel memory corruption на Apple M5. Їм допомагала нова модель Anthropic — Claude Mythos Preview.
Тобто мова вже не про "AI допоміг написати скрипт". Мова про те що AI проходить дуже складний шлях: від аналізу коду й пошуку помилок до побудови робочого exploit для сучасної операційної системи з сильними механізмами захисту.
Claude Mythos Preview поки недоступна публічно. Anthropic описує її як модель нового класу для автономного дослідження вразливостей. І цифри там дуже показові.
Opus 4.6 майже не справлявся з автономним написанням exploits для Firefox — лише кілька успішних спроб із сотень. Mythos Preview на тому самому класі задач — 181 успішний exploit із кількох сотень спроб. Це не покращення метрик. Це зміна класу можливостей.
Модель знаходила: 27-річний баг в OpenBSD — системі яка відома своїм акцентом на безпеці; 16-річну вразливість у FFmpeg — одній із найбільш перевірених медіабібліотек у світі; 17-річну вразливість у FreeBSD яка дозволяє отримати root-доступ через мережу.
Важлива деталь: Anthropic не тренувала Mythos спеціально як security-модель. Ці можливості виникли як побічний ефект загального покращення коду, мислення і автономності.
Саме це найбільш тривожне. Якщо модель не була спеціально натренована "ламати системи" але все одно навчилася знаходити й експлуатувати складні вразливості — питання вже не в тому чи буде AI використовуватися в кібербезпеці. Питання в тому хто першим використає ці можливості проти вашого коду — ваша команда чи хтось ззовні.
Тому Anthropic не випускає Mythos Preview публічно. Натомість запустили Project Glasswing — обмежений доступ для критичної інфраструктури та open source проєктів, щоб дефендери встигли закрити найважливіше до того як подібні можливості стануть доступні ширше. Станом на 22 травня 2026 вже розкрито 1596 вразливостей у 281 open source проєкті.
AISI фіксує зростаючий розрив між здатністю LLM знаходити вразливості та можливостями широко використовуваних методів кіберзахисту. Наступні покоління LLM можуть експлуатувати баги швидше ніж команди безпеки встигатимуть впроваджувати патчі.
Я писав C++ код бiльше 12ти рокiв, який у реальному часі обробляє дані в автiвках. Це не веб-форми. Логічна вразливість у нас — це потенційна проблема безпеки за кермом. І те що раніше міг знайти тільки досвідчений security-інженер після годин ручного аналізу, тепер агент робить за ніч.
Security більше не може бути "останнім етапом" перед релізом. У світі AI-агентів і автономного дослідження вразливостей безпека має ставати частиною інженерного процесу з самого початку.
Бо AI вже не просто допомагає писати код. Він починає перевіряти де цей код можна зламати.
Хтось із вас вже налаштував автоматизований security review на базі LLM — чи поки тільки думаєте про це?
🔔 ПІДПИСАТИСЯ
Думаю, ви вже бачили тривожну новину: AI-згенерований скрипт для обходу двофакторної автентифікації. Microsoft у своєму Cyber Signals фіксує що великі мовні моделі вже використовуються не просто для фішингових листів чи генерації шкідливого коду — а для пошуку реальних вразливостей у програмному забезпеченні.
Раніше інструменти для пошуку багів працювали механічно: шукали відомі патерни, запускали fuzzing, перевіряли типові помилки. Але LLM додають інший рівень — вони можуть аналізувати логіку коду й розуміти що програма мала б робити.
І ось тут з'являється новина яка показує наскільки швидко все змінюється.
Дослідники з Calif за 5 днів зібрали exploit для macOS kernel memory corruption на Apple M5. Їм допомагала нова модель Anthropic — Claude Mythos Preview.
Тобто мова вже не про "AI допоміг написати скрипт". Мова про те що AI проходить дуже складний шлях: від аналізу коду й пошуку помилок до побудови робочого exploit для сучасної операційної системи з сильними механізмами захисту.
Claude Mythos Preview поки недоступна публічно. Anthropic описує її як модель нового класу для автономного дослідження вразливостей. І цифри там дуже показові.
Opus 4.6 майже не справлявся з автономним написанням exploits для Firefox — лише кілька успішних спроб із сотень. Mythos Preview на тому самому класі задач — 181 успішний exploit із кількох сотень спроб. Це не покращення метрик. Це зміна класу можливостей.
Модель знаходила: 27-річний баг в OpenBSD — системі яка відома своїм акцентом на безпеці; 16-річну вразливість у FFmpeg — одній із найбільш перевірених медіабібліотек у світі; 17-річну вразливість у FreeBSD яка дозволяє отримати root-доступ через мережу.
Важлива деталь: Anthropic не тренувала Mythos спеціально як security-модель. Ці можливості виникли як побічний ефект загального покращення коду, мислення і автономності.
Саме це найбільш тривожне. Якщо модель не була спеціально натренована "ламати системи" але все одно навчилася знаходити й експлуатувати складні вразливості — питання вже не в тому чи буде AI використовуватися в кібербезпеці. Питання в тому хто першим використає ці можливості проти вашого коду — ваша команда чи хтось ззовні.
Тому Anthropic не випускає Mythos Preview публічно. Натомість запустили Project Glasswing — обмежений доступ для критичної інфраструктури та open source проєктів, щоб дефендери встигли закрити найважливіше до того як подібні можливості стануть доступні ширше. Станом на 22 травня 2026 вже розкрито 1596 вразливостей у 281 open source проєкті.
AISI фіксує зростаючий розрив між здатністю LLM знаходити вразливості та можливостями широко використовуваних методів кіберзахисту. Наступні покоління LLM можуть експлуатувати баги швидше ніж команди безпеки встигатимуть впроваджувати патчі.
Я писав C++ код бiльше 12ти рокiв, який у реальному часі обробляє дані в автiвках. Це не веб-форми. Логічна вразливість у нас — це потенційна проблема безпеки за кермом. І те що раніше міг знайти тільки досвідчений security-інженер після годин ручного аналізу, тепер агент робить за ніч.
Security більше не може бути "останнім етапом" перед релізом. У світі AI-агентів і автономного дослідження вразливостей безпека має ставати частиною інженерного процесу з самого початку.
Бо AI вже не просто допомагає писати код. Він починає перевіряти де цей код можна зламати.
Хтось із вас вже налаштував автоматизований security review на базі LLM — чи поки тільки думаєте про це?
🔔 ПІДПИСАТИСЯ
👍9❤7👀2
AI-агенти найкраще замінюють тих хто їх і створює.
На початку року я писав про AGI і про те що чесніший критерій готовності агентів — не benchmark а здатність кілька днів виконувати реальну роботу поруч із людиною.
Нове дослідження Carnegie Mellon і Stanford якраз про це.
Автори взяли понад 10 000 прикладів із 43 agent benchmarks і зіставили їх із реальною структурою ринку праці США через O*NET — урядову базу де робота описується не в стилі "зробити bubble sort" а через стандартизовані робочі активності й навички. Зіставлення робили через Claude 3.5 Sonnet: приклад "реалізувати bubble sort" → робоча активність "писати, оновлювати та підтримувати комп'ютерні програми…"
Результат показовий.
Кожен окремий benchmark покривав менше ніж 50% усіх робочих активностей і менше ніж 60% навичок. Усі benchmark'и разом — 56.5% робочих активностей. Тобто майже половина реальної роботи взагалі не представлена в тестах.
І причина очевидна якщо подивитися на цифри. Benchmark'и домінують у "computer and mathematical" задачах. Але в реальній економіці США:
"computer and mathematical" — 5.2 млн людей, $563 млрд виплат на рік
"office and administrative support" — 18.2 млн людей, $869 млрд
"management" — 11 млн людей, $1.326 трлн
Є ще одна іронія яку часто згадують в мемах: ми як інженери створюємо те що замінює нас у першу чергу.
Програмна інженерія — логічний інкубатор для agentic AI. У коді найпростіше виміряти результат і побудувати feedback loop. Тому прогрес агентів тут виглядає найпереконливіше. Але найбільша економічна цінність агентів може виявитися не там де їх найзручніше тестувати.
Агенти вже підвищили продуктивність у програмній інженерії. Якщо той самий прогрес відбудеться в адміністративному, фінансовому та управлінському секторах — це торкнеться значно більшої частини економіки і значно більшої кількості людей.
Тому очікуємо що з часом з'являться benchmark'и які краще вимірюватимуть продуктивність агентів у ширшому спектрі робочих активностей. І тоді розмова про автоматизацію праці стане значно конкретнішою.
🔔 ПІДПИСАТИСЯ
На початку року я писав про AGI і про те що чесніший критерій готовності агентів — не benchmark а здатність кілька днів виконувати реальну роботу поруч із людиною.
Нове дослідження Carnegie Mellon і Stanford якраз про це.
Автори взяли понад 10 000 прикладів із 43 agent benchmarks і зіставили їх із реальною структурою ринку праці США через O*NET — урядову базу де робота описується не в стилі "зробити bubble sort" а через стандартизовані робочі активності й навички. Зіставлення робили через Claude 3.5 Sonnet: приклад "реалізувати bubble sort" → робоча активність "писати, оновлювати та підтримувати комп'ютерні програми…"
Результат показовий.
Кожен окремий benchmark покривав менше ніж 50% усіх робочих активностей і менше ніж 60% навичок. Усі benchmark'и разом — 56.5% робочих активностей. Тобто майже половина реальної роботи взагалі не представлена в тестах.
І причина очевидна якщо подивитися на цифри. Benchmark'и домінують у "computer and mathematical" задачах. Але в реальній економіці США:
"computer and mathematical" — 5.2 млн людей, $563 млрд виплат на рік
"office and administrative support" — 18.2 млн людей, $869 млрд
"management" — 11 млн людей, $1.326 трлн
Є ще одна іронія яку часто згадують в мемах: ми як інженери створюємо те що замінює нас у першу чергу.
Програмна інженерія — логічний інкубатор для agentic AI. У коді найпростіше виміряти результат і побудувати feedback loop. Тому прогрес агентів тут виглядає найпереконливіше. Але найбільша економічна цінність агентів може виявитися не там де їх найзручніше тестувати.
Агенти вже підвищили продуктивність у програмній інженерії. Якщо той самий прогрес відбудеться в адміністративному, фінансовому та управлінському секторах — це торкнеться значно більшої частини економіки і значно більшої кількості людей.
Тому очікуємо що з часом з'являться benchmark'и які краще вимірюватимуть продуктивність агентів у ширшому спектрі робочих активностей. І тоді розмова про автоматизацію праці стане значно конкретнішою.
🔔 ПІДПИСАТИСЯ
👍10
This media is not supported in your browser
VIEW IN TELEGRAM
Створи гру за допомогою AI
Натрапив на пост в X: людина створила зображення через GPT Image 2, перетворила їх на ігрові ресурси, а Codex + GPT-5.5 зібрали з цього браузерну гру з якою можна грати.
AI закриває весь творчо-технічний шлях від ідеї до працюючого прототипу. Візуальна концепція → спрайти та фони → логіка, анімації, управління.
Мені особисто ця тема близька. Як і більшість айтівців мого покоління — починав програмувати у школі щоб створити власну гру. Але завжди упирався в одне й те саме: мало вміти програмувати, потрібні ще художник, аніматор, геймдизайнер. Читав "Кров і пікселі" про Stardew Valley — людина зробила гру сама але за ціну кількох років і серйозних жертв усієї родини. Далеко не кожен може собі таке дозволити.
Тепер частина цього бар'єру зникає. Це ще не заміна повноцінної команди — хороший продукт потребує смаку і якості. Але як інструмент для швидкого proof-of-concept це вже новий стандарт.
Можливо в якийсь відпуск нарешті закрию цей ґештальт 😄
🔔 ПІДПИСАТИСЯ
Натрапив на пост в X: людина створила зображення через GPT Image 2, перетворила їх на ігрові ресурси, а Codex + GPT-5.5 зібрали з цього браузерну гру з якою можна грати.
AI закриває весь творчо-технічний шлях від ідеї до працюючого прототипу. Візуальна концепція → спрайти та фони → логіка, анімації, управління.
Мені особисто ця тема близька. Як і більшість айтівців мого покоління — починав програмувати у школі щоб створити власну гру. Але завжди упирався в одне й те саме: мало вміти програмувати, потрібні ще художник, аніматор, геймдизайнер. Читав "Кров і пікселі" про Stardew Valley — людина зробила гру сама але за ціну кількох років і серйозних жертв усієї родини. Далеко не кожен може собі таке дозволити.
Тепер частина цього бар'єру зникає. Це ще не заміна повноцінної команди — хороший продукт потребує смаку і якості. Але як інструмент для швидкого proof-of-concept це вже новий стандарт.
Можливо в якийсь відпуск нарешті закрию цей ґештальт 😄
🔔 ПІДПИСАТИСЯ
3👍7🔥5
Продовжую тему зі створення ігор через AI
Спробував промпт для HUD і результат на скріншоті. Вийшло непогано з першого разу.
Найкорисніша порада з community: не намагатися одразу отримати ідеальний sprite sheet одним промптом. Правильний підхід — спочатку згенерувати повний sheet, потім уточнювати окремі кадри, а Codex використовувати щоб розрізати sheet і обробити frames по одному.
Із showcase OpenAI найбільше сподобався Theme Park Builder — GPT Image генерував sprites для атракціонів, магазинів і гостей, а Codex збирав ігровий цикл з грошима, чистотою і рейтингом. Workflow той самий що ми обговорювали в попередньому пості.
Пам'ятаю як у 90-х грав у Theme Park на Sega. А нещодавно публікував розбір книги Supremacy — і там було описано що Демis Гасабіс, той самий який заснував і очолив Google DeepMind, розробляв цю гру в 90-х. І саме в ній він хотів реалізувати можливості штучного інтелекту — але на той момент це не вдалося, хоча гра вже тоді вирізнялася рішеннями нетиповими для свого часу.
🔔 ПІДПИСАТИСЯ
Спробував промпт для HUD і результат на скріншоті. Вийшло непогано з першого разу.
Найкорисніша порада з community: не намагатися одразу отримати ідеальний sprite sheet одним промптом. Правильний підхід — спочатку згенерувати повний sheet, потім уточнювати окремі кадри, а Codex використовувати щоб розрізати sheet і обробити frames по одному.
Із showcase OpenAI найбільше сподобався Theme Park Builder — GPT Image генерував sprites для атракціонів, магазинів і гостей, а Codex збирав ігровий цикл з грошима, чистотою і рейтингом. Workflow той самий що ми обговорювали в попередньому пості.
Пам'ятаю як у 90-х грав у Theme Park на Sega. А нещодавно публікував розбір книги Supremacy — і там було описано що Демis Гасабіс, той самий який заснував і очолив Google DeepMind, розробляв цю гру в 90-х. І саме в ній він хотів реалізувати можливості штучного інтелекту — але на той момент це не вдалося, хоча гра вже тоді вирізнялася рішеннями нетиповими для свого часу.
🔔 ПІДПИСАТИСЯ
1👍7👏4❤3
This media is not supported in your browser
VIEW IN TELEGRAM
Stable Audio 3.0 від Stability AI — сімейство моделей для генерації музики та звукових ефектів за текстовим описом 🎵
Зараз можна самостійно створювати візуал і збирати ігровий прототип через AI. Але в іграх є ще один важливий шар — звук.
Виникає логічне питання: є ж Suno, навіщо ще якась модель?
Suno сильніший для готових пісень із вокалом під ключ. Stable Audio 3.0 цікавіша як інструмент для розробника: звукові ефекти, інструментальна музика, ambience, редагування аудіо. Не "зроби мені хіт" а "дай інструмент для вбудовування звуку в продукт".
І головна перевага — open-weight. Компактна модель Small SFX запускається на звичайному залізі без серверної інфраструктури. Для інді-розробки і прототипування це дуже практично.
Хто планує працювати зі звуковими ефектами - зберігайте собі. Може хтось вже пробував?
🔔 ПІДПИСАТИСЯ
Зараз можна самостійно створювати візуал і збирати ігровий прототип через AI. Але в іграх є ще один важливий шар — звук.
Виникає логічне питання: є ж Suno, навіщо ще якась модель?
Suno сильніший для готових пісень із вокалом під ключ. Stable Audio 3.0 цікавіша як інструмент для розробника: звукові ефекти, інструментальна музика, ambience, редагування аудіо. Не "зроби мені хіт" а "дай інструмент для вбудовування звуку в продукт".
І головна перевага — open-weight. Компактна модель Small SFX запускається на звичайному залізі без серверної інфраструктури. Для інді-розробки і прототипування це дуже практично.
Хто планує працювати зі звуковими ефектами - зберігайте собі. Може хтось вже пробував?
🔔 ПІДПИСАТИСЯ
1👍8🎉2❤1
This media is not supported in your browser
VIEW IN TELEGRAM
На фоні появи нових image-моделей особливо цікаво дивитися на проєкти які йдуть далі за генерацію картинок.
Добрий ранок ☕️
CADAM — open-source text-to-CAD інструмент який дозволяє описати об'єкт текстом або дати image reference і отримати 3D-модель у форматах .STL, .SCAD або .DXF.
LLM генерує OpenSCAD-код який рендериться у браузері. Тобто це AI який пише параметричну CAD-модель: розміри, форми, отвори, симетрія, параметри, експорт у формати для 3D-друку. Це конкретний інженерний опис об'єктів.
Далi це може виглядати так: "зроби корпус для плати з такими розмірами, отворами під гвинти, вентиляцією і можливістю друку без підтримок". Ось тут AI + CAD може реально змінити дрібне інженерне виробництво.
Після університету я працював в Moduleworks де розробляли CAD-CAM системи. Працював над C++ алгоритмами геометрії. Це був 2013 рік. У мене вже тоді виникали думки про те як нейромережі могли б допомогти в окремих частинах цього проекту — але цi наробiтки так i залишились пiд пилом в SVN 😅
🔔 ПІДПИСАТИСЯ
Добрий ранок ☕️
CADAM — open-source text-to-CAD інструмент який дозволяє описати об'єкт текстом або дати image reference і отримати 3D-модель у форматах .STL, .SCAD або .DXF.
LLM генерує OpenSCAD-код який рендериться у браузері. Тобто це AI який пише параметричну CAD-модель: розміри, форми, отвори, симетрія, параметри, експорт у формати для 3D-друку. Це конкретний інженерний опис об'єктів.
Далi це може виглядати так: "зроби корпус для плати з такими розмірами, отворами під гвинти, вентиляцією і можливістю друку без підтримок". Ось тут AI + CAD може реально змінити дрібне інженерне виробництво.
Після університету я працював в Moduleworks де розробляли CAD-CAM системи. Працював над C++ алгоритмами геометрії. Це був 2013 рік. У мене вже тоді виникали думки про те як нейромережі могли б допомогти в окремих частинах цього проекту — але цi наробiтки так i залишились пiд пилом в SVN 😅
🔔 ПІДПИСАТИСЯ
1👍10🔥5❤2👎1
Open-weights моделі поступово переходять у нову фазу.
Гарного вівторка! 👋
Минулий місяць був місяцем відкритих моделей — вийшла нова Kimi і потужний DeepSeek V4, я детально їх розбирав. Але незаслужено пропустив ще одну китайську модель — GLM-5.1 від Z.ai.
Може виникнути логічне питання: навіщо ще одна якщо є Kimi K2.6?
Обидві моделі грають у довгі агентні задачі. Але акцент різний.
GLM-5.1 позиціонується як модель для тривалих інженерних задач. Z.ai прямо вказує що вона може автономно працювати над одним завданням до 8 годин: планувати, виконувати кроки, перевіряти результат, оптимізувати підхід.
Kimi K2.6 ширша: текст, зображення і відео, 256K контекст, мультиагентна оркестрація. Орієнтована не тільки на код а й на UI, дизайн, frontend, DevOps.
Тобто різниця така:
GLM це агент який довго тримає одну складну інженерну задачу. Краще для великих репозиторіїв, тестів, рефакторингу, CI/CD.
Kimi це мультимодальний агент для продуктових процесів. Краще для UI, скриншотів, дизайну, full-stack прототипів.
Я як інженер не тільки писав код а й постійно налагоджував пайплайни, тести і CI/CD — це невід'ємна частина розробки. І певний рівень автоматизації тут критично важливий щоб уникати людських помилок і економити час.
Реальна інженерна цінність AI в тому що він може пройти весь шлях: від задачі → аналізу → коду → тестів → помилок → виправлень → стабільного результату.
Open-weights моделі вже заходять саме в цю зону. І саме тут починається наступний етап конкуренції — хто довше й надійніше може працювати на реальній задачі.
Хтось із вас вже пробував GLM-5.1 або Kimi K2.6 в агентному процесі — через Cline, Cursor чи власну систему?
🔔 ПІДПИСАТИСЯ
Гарного вівторка! 👋
Минулий місяць був місяцем відкритих моделей — вийшла нова Kimi і потужний DeepSeek V4, я детально їх розбирав. Але незаслужено пропустив ще одну китайську модель — GLM-5.1 від Z.ai.
Може виникнути логічне питання: навіщо ще одна якщо є Kimi K2.6?
Обидві моделі грають у довгі агентні задачі. Але акцент різний.
GLM-5.1 позиціонується як модель для тривалих інженерних задач. Z.ai прямо вказує що вона може автономно працювати над одним завданням до 8 годин: планувати, виконувати кроки, перевіряти результат, оптимізувати підхід.
Kimi K2.6 ширша: текст, зображення і відео, 256K контекст, мультиагентна оркестрація. Орієнтована не тільки на код а й на UI, дизайн, frontend, DevOps.
Тобто різниця така:
GLM це агент який довго тримає одну складну інженерну задачу. Краще для великих репозиторіїв, тестів, рефакторингу, CI/CD.
Kimi це мультимодальний агент для продуктових процесів. Краще для UI, скриншотів, дизайну, full-stack прототипів.
Я як інженер не тільки писав код а й постійно налагоджував пайплайни, тести і CI/CD — це невід'ємна частина розробки. І певний рівень автоматизації тут критично важливий щоб уникати людських помилок і економити час.
Реальна інженерна цінність AI в тому що він може пройти весь шлях: від задачі → аналізу → коду → тестів → помилок → виправлень → стабільного результату.
Open-weights моделі вже заходять саме в цю зону. І саме тут починається наступний етап конкуренції — хто довше й надійніше може працювати на реальній задачі.
Хтось із вас вже пробував GLM-5.1 або Kimi K2.6 в агентному процесі — через Cline, Cursor чи власну систему?
🔔 ПІДПИСАТИСЯ
🔥5👍4
Доброго ранку! ☕️ Знову середа — і черговий розбір наукової статті.
Якщо ви пробували генерувати зображення — впевнений стикалися з цією проблемою. Промпт конкретний: "ведмідь завис над срібною ложкою". А модель малює ведмедя поруч із ложкою або в дивній композиції де формально все є але просторовий сенс втрачено.
T2I-CompBench++ підтверджує: навіть сильні text-to-image моделі системно помиляються в композиційних задачах — коли треба правильно зв'язати об'єкти, атрибути, кількість і просторові відношення.
Нова робота Think in Strokes, Not Pixels пропонує цікаву ідею: можливо зображення не треба генерувати "одним пострілом". Варто навчити модель створювати сцену поетапно — майже як художник.
Схема (у статті: textual planning, visual drafting, textual reflection, visual refinement):
1. Plan — модель формулює що саме додати на наступному кроці
2. Sketch — генерує проміжне зображення
3. Inspect — перевіряє чи відповідає результат промпту
4. Refine — формулює виправлення і повторює цикл
Ключовий момент: кожен наступний крок ґрунтується не тільки на тексті промпту а й на поточному візуальному стані. Тобто модель бачить що вже намальовано і вирішує як саме це змінити далі.
Для навчання автори взяли BAGEL-7B — unified multimodal model яка не лише розуміє текст і зображення а й може генерувати мультимодальний результат. GPT-4o перетворював промпти з двох датасетів у scene graphs. Зображення для кожного кроку генерували через FLUX.1 Kontext і залишали тільки ті проміжні результати які автоматична перевірка через GPT-4o визнала узгодженими з інструкцією. Датасет для plan/sketch — близько 32 000 прикладів. Окремо модель навчали етапу inspect на ~7 000 коректних і ~8 000 прикладів із помилками.
Тобто модель навчали не тільки малювати а й критикувати власний проміжний результат.
Результати на WISE — BAGEL піднявся з 0.70 до 0.76. На GenEval з 77% до 83%. Особливо покращилися сцени зі складними просторовими відношеннями.
Тут є цікава паралель з LLM. Ми вже звикли що мовні моделі краще справляються зі складними задачами коли розбивають їх на кроки. Тепер схожий підхід переносять у генерацію зображень.
Важливо: це не означає що проблема повністю вирішена. Метод показує напрямок — зробити генерацію більш контрольованою і перевірюваною. Але це поки дослідницький підхід а не стандарт у кожному image generator.
Справжня цінність тут не тільки в якості картинки а в появі керованого процесу: модель має план, проміжний стан, самоперевірку і механізм виправлення. Це вже ближче до візуального агента ніж до "магічного автомату для красивих картинок".
Сьогодні картинки. Завтра — відео, 3D-сцени, ігрові рівні.
🔔 ПІДПИСАТИСЯ
Якщо ви пробували генерувати зображення — впевнений стикалися з цією проблемою. Промпт конкретний: "ведмідь завис над срібною ложкою". А модель малює ведмедя поруч із ложкою або в дивній композиції де формально все є але просторовий сенс втрачено.
T2I-CompBench++ підтверджує: навіть сильні text-to-image моделі системно помиляються в композиційних задачах — коли треба правильно зв'язати об'єкти, атрибути, кількість і просторові відношення.
Нова робота Think in Strokes, Not Pixels пропонує цікаву ідею: можливо зображення не треба генерувати "одним пострілом". Варто навчити модель створювати сцену поетапно — майже як художник.
Схема (у статті: textual planning, visual drafting, textual reflection, visual refinement):
1. Plan — модель формулює що саме додати на наступному кроці
2. Sketch — генерує проміжне зображення
3. Inspect — перевіряє чи відповідає результат промпту
4. Refine — формулює виправлення і повторює цикл
Ключовий момент: кожен наступний крок ґрунтується не тільки на тексті промпту а й на поточному візуальному стані. Тобто модель бачить що вже намальовано і вирішує як саме це змінити далі.
Для навчання автори взяли BAGEL-7B — unified multimodal model яка не лише розуміє текст і зображення а й може генерувати мультимодальний результат. GPT-4o перетворював промпти з двох датасетів у scene graphs. Зображення для кожного кроку генерували через FLUX.1 Kontext і залишали тільки ті проміжні результати які автоматична перевірка через GPT-4o визнала узгодженими з інструкцією. Датасет для plan/sketch — близько 32 000 прикладів. Окремо модель навчали етапу inspect на ~7 000 коректних і ~8 000 прикладів із помилками.
Тобто модель навчали не тільки малювати а й критикувати власний проміжний результат.
Результати на WISE — BAGEL піднявся з 0.70 до 0.76. На GenEval з 77% до 83%. Особливо покращилися сцени зі складними просторовими відношеннями.
Тут є цікава паралель з LLM. Ми вже звикли що мовні моделі краще справляються зі складними задачами коли розбивають їх на кроки. Тепер схожий підхід переносять у генерацію зображень.
Важливо: це не означає що проблема повністю вирішена. Метод показує напрямок — зробити генерацію більш контрольованою і перевірюваною. Але це поки дослідницький підхід а не стандарт у кожному image generator.
Справжня цінність тут не тільки в якості картинки а в появі керованого процесу: модель має план, проміжний стан, самоперевірку і механізм виправлення. Це вже ближче до візуального агента ніж до "магічного автомату для красивих картинок".
Сьогодні картинки. Завтра — відео, 3D-сцени, ігрові рівні.
🔔 ПІДПИСАТИСЯ
🔥7👍3❤1
AI-агенти вже почали переписувати правила інтернету.
Доброго ранку ☕️
За даними звіту Human Security, AI-driven трафік — взаємодії згенеровані AI-системами або виконані від їхнього імені — майже потроївся у 2025 році.
68% цього трафіку становлять crawlers які збирають дані для навчання моделей. Ще 32% — scrapers для збору цін, наявності товарів, умов бронювання. А найцікавіша категорія — AI-агенти та агентні браузери. Їхня частка поки мала але за рік зросла майже у 80 разів.
77% агентних взаємодій відбувалися на сторінках товарів і пошуку. Тобто агенти вже поводяться як користувачі: шукають, порівнюють, аналізують. Частина активності також була пов'язана зі сторінками акаунтів, автентифікацією і транзакціями.
І тут починається найцікавіше з точки зору кібербезпеки.
Легітимний AI-агент дуже схожий на бота. Він швидко відкриває сторінки, порівнює товари, може проходити авторизацію і виконувати транзакції. Раніше така поведінка була сигналом атаки. Тепер це може бути нормальна поведінка AI-асистента.
Я вже бачив у мережі кілька прикладів де агенти помилково замовляли їжу — приїжджав кур'єр а людина не була в курсі замовлення. І в коментарі до замовлення фігурував Claude. Смішно але показово: старі правила виявлення ботів починають ламатися а нові ще не сформовані.
Паралельно malicious scraping зріс на 47%. Атаки на акаунти загалом зменшилися але стали небезпечнішими: у 4 рази зросла кількість атак після входу в акаунт. Тобто проблема зміщується від "зламати логін" до використання вже активних акаунтів.
Агентний трафік лише починається. 80-кратне зростання минулого року ймовірно ще багато разів посилиться коли агенти стануть надійнішими і масовішими. Інфраструктуру потрібно будувати або модернізувати з урахуванням цього вже зараз.
Інтернет який ми знаємо будувався навколо людини-користувача. Наступний етап — інтернет де значну частину дій виконуватимуть агенти. Сайтам доведеться навчитися відповідати на нові питання: як відрізнити корисного AI-агента від шкідливого бота, як дозволити агенту купувати але не красти дані, як зміниться SEO коли сторінки читатимуть не тільки люди.
Веб перебудовуватиметься під агентів: не лише як нових "читачів" контенту, а як повноцінних акторів які діють, купують і приймають рішення.
Повний звіт
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
За даними звіту Human Security, AI-driven трафік — взаємодії згенеровані AI-системами або виконані від їхнього імені — майже потроївся у 2025 році.
68% цього трафіку становлять crawlers які збирають дані для навчання моделей. Ще 32% — scrapers для збору цін, наявності товарів, умов бронювання. А найцікавіша категорія — AI-агенти та агентні браузери. Їхня частка поки мала але за рік зросла майже у 80 разів.
77% агентних взаємодій відбувалися на сторінках товарів і пошуку. Тобто агенти вже поводяться як користувачі: шукають, порівнюють, аналізують. Частина активності також була пов'язана зі сторінками акаунтів, автентифікацією і транзакціями.
І тут починається найцікавіше з точки зору кібербезпеки.
Легітимний AI-агент дуже схожий на бота. Він швидко відкриває сторінки, порівнює товари, може проходити авторизацію і виконувати транзакції. Раніше така поведінка була сигналом атаки. Тепер це може бути нормальна поведінка AI-асистента.
Я вже бачив у мережі кілька прикладів де агенти помилково замовляли їжу — приїжджав кур'єр а людина не була в курсі замовлення. І в коментарі до замовлення фігурував Claude. Смішно але показово: старі правила виявлення ботів починають ламатися а нові ще не сформовані.
Паралельно malicious scraping зріс на 47%. Атаки на акаунти загалом зменшилися але стали небезпечнішими: у 4 рази зросла кількість атак після входу в акаунт. Тобто проблема зміщується від "зламати логін" до використання вже активних акаунтів.
Агентний трафік лише починається. 80-кратне зростання минулого року ймовірно ще багато разів посилиться коли агенти стануть надійнішими і масовішими. Інфраструктуру потрібно будувати або модернізувати з урахуванням цього вже зараз.
Інтернет який ми знаємо будувався навколо людини-користувача. Наступний етап — інтернет де значну частину дій виконуватимуть агенти. Сайтам доведеться навчитися відповідати на нові питання: як відрізнити корисного AI-агента від шкідливого бота, як дозволити агенту купувати але не красти дані, як зміниться SEO коли сторінки читатимуть не тільки люди.
Веб перебудовуватиметься під агентів: не лише як нових "читачів" контенту, а як повноцінних акторів які діють, купують і приймають рішення.
Повний звіт
🔔 ПІДПИСАТИСЯ
👍13❤5🔥3
10 речей про LLM які варто знати 1/10 🧠
Prompt engineering — це не зовсім "інженерія промптів"
Ще рік тому з'являлися цілі курси про те як правильно писати промпти. Але пройшов рік — і ми бачимо наскільки якість промптів стала менш важливою. LLM самі навчилися писати промпти, а більшої значущості набув context engineering про який я вже писав раніше.
Щоб зрозуміти чому — потрібно розуміти як LLM взагалі працюють.
LLM не знають фактів і не виконують промпт як програмний код. GPT-подібні моделі прогнозують наступні токени на основі попереднього контексту — саме так це описано в роботі про GPT-3 Language Models are Few-Shot Learners яку ми розбираємо зі студентами на лекціях.
Тобто промпт — це не кнопка "зроби X". Це контекстний сигнал. Він задає моделі рамку: про що ми говоримо, у якій ролі має відповідати, який стиль очікується, для кого текст, які обмеження важливі.
Тому мені дедалі більше подобається інша назва — semantic framing. Семантичне фреймування. Ми не пишемо інструкцію — ми конструюємо контекст який допомагає моделі зрозуміти в якому режимі їй треба продовжувати текст.
Якщо промпт — це постріл у темряву він дає слабкий результат не тому що модель "дурна" а тому що ми дали занадто розмиту рамку.
"Напиши пост про AI" — широкий сигнал. Модель не знає для кого, у якому стилі, з якою позицією.
"Напиши Telegram-пост українською для інженерної аудиторії. Тон — публіцистично-науковий. Поясни чому X. Заверши практичним висновком." — це вже рамка. Модель отримує роль, аудиторію, стиль і комунікативний намір.
Хороше промптування — це не магія і не список "секретних фраз". Це вміння правильно задати семантичну рамку: хто говорить, кому, навіщо, у якому стилі, з якими обмеженнями.
Чим сильніше ви звужуєте ймовірнісні шляхи моделі — тим менше вона блукає у просторі можливих відповідей.
Зберігай щоб не загубити, а наступного четверга — ще один важливий факт про LLM: контекстні вікна 👀
🔔 ПІДПИСАТИСЯ
Prompt engineering — це не зовсім "інженерія промптів"
Ще рік тому з'являлися цілі курси про те як правильно писати промпти. Але пройшов рік — і ми бачимо наскільки якість промптів стала менш важливою. LLM самі навчилися писати промпти, а більшої значущості набув context engineering про який я вже писав раніше.
Щоб зрозуміти чому — потрібно розуміти як LLM взагалі працюють.
LLM не знають фактів і не виконують промпт як програмний код. GPT-подібні моделі прогнозують наступні токени на основі попереднього контексту — саме так це описано в роботі про GPT-3 Language Models are Few-Shot Learners яку ми розбираємо зі студентами на лекціях.
Тобто промпт — це не кнопка "зроби X". Це контекстний сигнал. Він задає моделі рамку: про що ми говоримо, у якій ролі має відповідати, який стиль очікується, для кого текст, які обмеження важливі.
Тому мені дедалі більше подобається інша назва — semantic framing. Семантичне фреймування. Ми не пишемо інструкцію — ми конструюємо контекст який допомагає моделі зрозуміти в якому режимі їй треба продовжувати текст.
Якщо промпт — це постріл у темряву він дає слабкий результат не тому що модель "дурна" а тому що ми дали занадто розмиту рамку.
"Напиши пост про AI" — широкий сигнал. Модель не знає для кого, у якому стилі, з якою позицією.
"Напиши Telegram-пост українською для інженерної аудиторії. Тон — публіцистично-науковий. Поясни чому X. Заверши практичним висновком." — це вже рамка. Модель отримує роль, аудиторію, стиль і комунікативний намір.
Хороше промптування — це не магія і не список "секретних фраз". Це вміння правильно задати семантичну рамку: хто говорить, кому, навіщо, у якому стилі, з якими обмеженнями.
Чим сильніше ви звужуєте ймовірнісні шляхи моделі — тим менше вона блукає у просторі можливих відповідей.
Зберігай щоб не загубити, а наступного четверга — ще один важливий факт про LLM: контекстні вікна 👀
🔔 ПІДПИСАТИСЯ
arXiv.org
Language Models are Few-Shot Learners
Recent work has demonstrated substantial gains on many NLP tasks and benchmarks by pre-training on a large corpus of text followed by fine-tuning on a specific task. While typically task-agnostic...
👍13❤2💯1
🇪🇺 Європа натискає на гальма в регулюванні AI
Добрий ранок та гарних вихiдних! Трошки вирiшив розбавити технiчнi розмови геополiтекою навколо AI ☕️
ЄС, який ще недавно хотів бути головним регулятором штучного інтелекту у світі, починає пом'якшувати власний AI Act.
Причина проста: бізнес і частина політиків дедалі голосніше кажуть що надмірне регулювання робить європейські компанії менш конкурентними порівняно з США та Китаєм.
Що змінюється — вимоги до "високоризикових" AI-систем у правоохоронній сфері, критичній інфраструктурі, працевлаштуванні та персональній ідентифікації відкладаються з серпня 2026 до грудня 2027 року. Окремі дедлайни для AI-продуктів переносяться до серпня 2028. Вимоги щодо watermarking AI-контенту та прозорості — приблизно до грудня 2026. Також спрощують процедури для малого бізнесу щоб compliance не перетворився на окремий бюрократичний квест.
Цікавий момент: в одному напрямі регулювання навпаки посилюють — забороняють генерацію сексуалізованих зображень дітей і несанкціонованих інтимних зображень реальних людей.
І ось тут починається найцікавіше.
AI Act спочатку будувався навколо ідеї "системних ризиків" — ризиків які можуть впливати не на окрему людину а на цілі сектори економіки. Поняття запозичене з фінансового регулювання. Але проблема в тому що частина цих ризиків залишається спекулятивною. Натомість ризик надмірного регулювання дуже конкретний: компанії витрачають ресурси не на розробку а на юридичну адаптацію і документацію.
Поправки мають на меті збалансувати ризики й переваги: зменшити навантаження на розробників, дати компаніям більше часу щоб зрозуміти вимоги і відкрити шлях для інновацій у критичних галузях. Самі поправки ще очікують офіційного прийняття.
Європа вже має структурну проблему: фрагментований ринок, 27 національних юрисдикцій, слабше масштабування технологічних компаній порівняно з США та Китаєм. Якщо поверх цього накласти надто важкий регуляторний шар — можна отримати ситуацію де ЄС стане не лідером AI-безпеки а територією де інновації просто повільніше доходять до ринку.
Багато положень оригінального AI Act були нечіткими або надто широкими. Ці зміни схоже роблять закон менш обтяжливим зберігаючи корисні елементи. Це хороший крок для конкурентоспроможності Європи.
Навіть Європа яка традиційно робить ставку на регулювання починає визнавати: у гонці AI недостатньо просто "захищати громадян". Потрібно ще не задушити власну індустрію до того як вона встигне вирости.
🔔 ПІДПИСАТИСЯ
Добрий ранок та гарних вихiдних! Трошки вирiшив розбавити технiчнi розмови геополiтекою навколо AI ☕️
ЄС, який ще недавно хотів бути головним регулятором штучного інтелекту у світі, починає пом'якшувати власний AI Act.
Причина проста: бізнес і частина політиків дедалі голосніше кажуть що надмірне регулювання робить європейські компанії менш конкурентними порівняно з США та Китаєм.
Що змінюється — вимоги до "високоризикових" AI-систем у правоохоронній сфері, критичній інфраструктурі, працевлаштуванні та персональній ідентифікації відкладаються з серпня 2026 до грудня 2027 року. Окремі дедлайни для AI-продуктів переносяться до серпня 2028. Вимоги щодо watermarking AI-контенту та прозорості — приблизно до грудня 2026. Також спрощують процедури для малого бізнесу щоб compliance не перетворився на окремий бюрократичний квест.
Цікавий момент: в одному напрямі регулювання навпаки посилюють — забороняють генерацію сексуалізованих зображень дітей і несанкціонованих інтимних зображень реальних людей.
І ось тут починається найцікавіше.
AI Act спочатку будувався навколо ідеї "системних ризиків" — ризиків які можуть впливати не на окрему людину а на цілі сектори економіки. Поняття запозичене з фінансового регулювання. Але проблема в тому що частина цих ризиків залишається спекулятивною. Натомість ризик надмірного регулювання дуже конкретний: компанії витрачають ресурси не на розробку а на юридичну адаптацію і документацію.
Поправки мають на меті збалансувати ризики й переваги: зменшити навантаження на розробників, дати компаніям більше часу щоб зрозуміти вимоги і відкрити шлях для інновацій у критичних галузях. Самі поправки ще очікують офіційного прийняття.
Європа вже має структурну проблему: фрагментований ринок, 27 національних юрисдикцій, слабше масштабування технологічних компаній порівняно з США та Китаєм. Якщо поверх цього накласти надто важкий регуляторний шар — можна отримати ситуацію де ЄС стане не лідером AI-безпеки а територією де інновації просто повільніше доходять до ринку.
Багато положень оригінального AI Act були нечіткими або надто широкими. Ці зміни схоже роблять закон менш обтяжливим зберігаючи корисні елементи. Це хороший крок для конкурентоспроможності Європи.
Навіть Європа яка традиційно робить ставку на регулювання починає визнавати: у гонці AI недостатньо просто "захищати громадян". Потрібно ще не задушити власну індустрію до того як вона встигне вирости.
🔔 ПІДПИСАТИСЯ
👍10❤2
Друзі, доброго вечора! 👋
Дійшли руки створити YouTube-канал як ви і хотіли 🙂
Нажаль часу на зйомки майже немає але буду намагатися інколи записувати щось цікаве. Формат відео-лекції дозволяє більш розгорнуто розкривати тему ніж пост у Telegram.
Підпишіться щоб не пропустити. А поки — перше відео для вас 👇
https://youtu.be/1XqpgxPp7KY
🔔 ПІДПИСАТИСЯ
Дійшли руки створити YouTube-канал як ви і хотіли 🙂
Нажаль часу на зйомки майже немає але буду намагатися інколи записувати щось цікаве. Формат відео-лекції дозволяє більш розгорнуто розкривати тему ніж пост у Telegram.
Підпишіться щоб не пропустити. А поки — перше відео для вас 👇
https://youtu.be/1XqpgxPp7KY
🔔 ПІДПИСАТИСЯ
3🔥12❤4👍4👏1
This media is not supported in your browser
VIEW IN TELEGRAM
Доброго ранку! ☕️
Натрапив на цікаву модель для генерації говорячих аватарів.
LongCat-Video-Avatar 1.5 від Meituan LongCat Team генерує відео говорячого персонажа по аудіо і зображенню або текстовому опису. На вхід даєш голос і фото — на виході отримуєш відео де людина говорить із синхронізацією губ, мімікою і збереженням ідентичності.
Модель побудована на базі LongCat-Video з 13.6B параметрів, код і ваги відкриті, ліцензія MIT. Раніше подібна якість частіше була доступна через закриті комерційні сервіси. Як аудіоенкодер використовується Whisper-Large — що дає точнішу синхронізацію губ ніж у попередній версії. Підтримуються стилізовані персонажі: anime, тварини, digital humans. Є підтримка мультиперсонажних сцен з кількома аудіопотоками.
Як аудіоенкодер використовується Whisper-Large-v3 — навчений на 680 000 годин мовлення 99 мовами включно з українською. Офіційний benchmark тестувався на китайській та англійській, але підтримка інших мов випливає з архітектури самого Whisper.
🔔 ПІДПИСАТИСЯ
Натрапив на цікаву модель для генерації говорячих аватарів.
LongCat-Video-Avatar 1.5 від Meituan LongCat Team генерує відео говорячого персонажа по аудіо і зображенню або текстовому опису. На вхід даєш голос і фото — на виході отримуєш відео де людина говорить із синхронізацією губ, мімікою і збереженням ідентичності.
Модель побудована на базі LongCat-Video з 13.6B параметрів, код і ваги відкриті, ліцензія MIT. Раніше подібна якість частіше була доступна через закриті комерційні сервіси. Як аудіоенкодер використовується Whisper-Large — що дає точнішу синхронізацію губ ніж у попередній версії. Підтримуються стилізовані персонажі: anime, тварини, digital humans. Є підтримка мультиперсонажних сцен з кількома аудіопотоками.
Як аудіоенкодер використовується Whisper-Large-v3 — навчений на 680 000 годин мовлення 99 мовами включно з українською. Офіційний benchmark тестувався на китайській та англійській, але підтримка інших мов випливає з архітектури самого Whisper.
🔔 ПІДПИСАТИСЯ
👍7❤5🔥4
This media is not supported in your browser
VIEW IN TELEGRAM
У Claude Code з'явився відкритий конкурент — Kimi Code CLI
Добрий ранок ☕️
Kimi Code CLI від Moonshot AI — термінальний AI-агент для розробників який працює прямо в командному рядку: розбирається з кодом, редагує файли, запускає команди, шукає по проєкту та аналізує вебсторінки.
На відміну від Claude Code який залишається закритим комерційним інструментом — Kimi Code CLI опублікований на GitHub з відкритим вихідним кодом під ліцензією MIT. Тобто розробники можуть не лише користуватися агентом а й вивчати як він влаштований, допрацьовувати під свої процеси та інтегрувати у власні пайплайни.
Є можливість підключати не тільки Kimi/Moonshot API а й інших сумісних провайдерів.
І окремо цікавий момент — підтримка відеовходу. Розробнику не завжди зручно словами пояснювати проблему. Іноді простіше показати screen recording де "ось тут кнопка не працює" або "ось так відтворюється баг".
Поява open-source альтернативи це хороший сигнал.
🔔 ПІДПИСАТИСЯ
Добрий ранок ☕️
Kimi Code CLI від Moonshot AI — термінальний AI-агент для розробників який працює прямо в командному рядку: розбирається з кодом, редагує файли, запускає команди, шукає по проєкту та аналізує вебсторінки.
На відміну від Claude Code який залишається закритим комерційним інструментом — Kimi Code CLI опублікований на GitHub з відкритим вихідним кодом під ліцензією MIT. Тобто розробники можуть не лише користуватися агентом а й вивчати як він влаштований, допрацьовувати під свої процеси та інтегрувати у власні пайплайни.
Є можливість підключати не тільки Kimi/Moonshot API а й інших сумісних провайдерів.
І окремо цікавий момент — підтримка відеовходу. Розробнику не завжди зручно словами пояснювати проблему. Іноді простіше показати screen recording де "ось тут кнопка не працює" або "ось так відтворюється баг".
Поява open-source альтернативи це хороший сигнал.
🔔 ПІДПИСАТИСЯ
👍11🔥6❤2👏1😍1
Media is too big
VIEW IN TELEGRAM
Magenta RealTime 2 від Google DeepMind — безкоштовна модель для генерації музики в реальному часі 🎵
Головна ідея: музика генерується локально без хмари як безперервний аудіопотік. Затримка — близько 200 мс. Керувати можна трьома способами: текстовий промпт, аудіоприклад або MIDI-вхід. Стиль, жанр і інструменти можна змінювати прямо під час генерації.
Під капотом три ключові компоненти: SpectroStream кодує стереоаудіо 48 kHz у токени, MusicCoCa зв'язує текст і звук у спільному просторі, Decoder-only Transformer генерує наступні аудіотокени в реальному часі.
Small-версія на 230 млн параметрів працює в реальному часі на звичайних Apple Silicon пристроях, Base потребує Pro/Max чипів. Код відкритий у GitHub.
Колись з'явилися диджейські столи які дали можливiсть лядям не вміючим грати на інструментах, створювати музику. AI-інструменти це наступний крок. Традиційні інструменти все більше стають елітарною прерогативою.
І це вже видно в чартах де на перших рядках багато AI-музики.
🔔 ПІДПИСАТИСЯ
Головна ідея: музика генерується локально без хмари як безперервний аудіопотік. Затримка — близько 200 мс. Керувати можна трьома способами: текстовий промпт, аудіоприклад або MIDI-вхід. Стиль, жанр і інструменти можна змінювати прямо під час генерації.
Під капотом три ключові компоненти: SpectroStream кодує стереоаудіо 48 kHz у токени, MusicCoCa зв'язує текст і звук у спільному просторі, Decoder-only Transformer генерує наступні аудіотокени в реальному часі.
Small-версія на 230 млн параметрів працює в реальному часі на звичайних Apple Silicon пристроях, Base потребує Pro/Max чипів. Код відкритий у GitHub.
Колись з'явилися диджейські столи які дали можливiсть лядям не вміючим грати на інструментах, створювати музику. AI-інструменти це наступний крок. Традиційні інструменти все більше стають елітарною прерогативою.
І це вже видно в чартах де на перших рядках багато AI-музики.
🔔 ПІДПИСАТИСЯ
👍6❤3🔥2👀1
NVIDIA відкрила OmniDreams — генеративну world model для симуляції автономного водіння.
Доброго ранку ☕️
Подивіться уважно на відео 👇 це не відео з камери — воно повністю згенероване моделлю 🤯
Щоб зрозуміти чому це цікаво — треба зрозуміти різницю між open-loop і closed-loop тестуванням.
У класичному підході модель автономного водіння дивиться на записані відеодані і робить передбачення. Але її рішення не впливають на те що відбувається далі — вона просто оцінює помилки на фіксованому записі. Це open-loop.
У closed-loop все інакше. Policy приймає рішення → симулятор оновлює стан → модель генерує нові camera observations → policy знову реагує на нову картину.
Автомобіль ніби "живе" всередині середовища і його дії справді щось змінюють. Це чимось схоже на сон автономного автомобіля — де він може безпечно проживати складні дорожні сценарії перш ніж зіткнутися з ними в реальності. Саме це і намагається забезпечити OmniDreams.
Як це влаштовано технічно.
OmniDreams побудована на базі NVIDIA Cosmos-Predict2.5 — Diffusion Transformer на 2B параметрів. Але на відміну від звичайних відеогенераторів вона не просто "малює красиву дорогу" за текстом.
На вхід вона отримує одразу кілька потоків даних:
реальний RGB-кадр як візуальний якір сцени, HD-map зображення зі структурою доріг і смуг, trajectory poses — куди рухається ego-vehicle, bounding boxes інших учасників руху і текстовий опис умов сцени.
На основі всього цього модель генерує наступну послідовність кадрів. І ключове тут — вона працює авторегресивно: кожен згенерований chunk стає частиною контексту для наступного кроку. Це дозволяє будувати довгі rollouts де policy справді тестується в часі а не на одному кадрі.
У paper на arXiv NVIDIA пише що модель навчалась на 21 000 годин дорожніх сценаріїв і приблизно 4 млн мультиракурсних відеозаписів з vehicle-mounted cameras з текстовими описами і structured map annotations.
Я сам працював із real-world data, траєкторіями та сценаріями для autonomous driving — у мене навіть є наукова стаття на цю тему яка зараз на review. Тому для мене OmniDreams це не просто новина від NVIDIA а підтвердження важливого тренду.
Такі моделі не скасовують потребу в реальних даних. Навпаки — вони роблять реальні сценарії ще ціннішими. World model може масштабувати і візуалізувати сценарій. Але вона не відповідає на питання "який саме сценарій варто розігрувати" — де трапляються небезпечні ситуації, як поводяться пішоходи, які edge cases важливі для safety validation. Це зона real-world scenario extraction.
Тому майбутній стек симуляції ймовірно буде гібридним: real-world scenario mining → structured simulation → generative world models → closed-loop evaluation.
NVIDIA сама попереджає про обмеження: temporal inconsistency, нестабільність руху об'єктів, неточна фізика. Це генеративний sensor layer результати якого треба валідувати — не "істинний симулятор реальності".
GitHub OmniDreams · FlashDreams runtime · Hugging Face collection
🔔 ПІДПИСATИСЯ
Доброго ранку ☕️
Подивіться уважно на відео 👇 це не відео з камери — воно повністю згенероване моделлю 🤯
Щоб зрозуміти чому це цікаво — треба зрозуміти різницю між open-loop і closed-loop тестуванням.
У класичному підході модель автономного водіння дивиться на записані відеодані і робить передбачення. Але її рішення не впливають на те що відбувається далі — вона просто оцінює помилки на фіксованому записі. Це open-loop.
У closed-loop все інакше. Policy приймає рішення → симулятор оновлює стан → модель генерує нові camera observations → policy знову реагує на нову картину.
Автомобіль ніби "живе" всередині середовища і його дії справді щось змінюють. Це чимось схоже на сон автономного автомобіля — де він може безпечно проживати складні дорожні сценарії перш ніж зіткнутися з ними в реальності. Саме це і намагається забезпечити OmniDreams.
Як це влаштовано технічно.
OmniDreams побудована на базі NVIDIA Cosmos-Predict2.5 — Diffusion Transformer на 2B параметрів. Але на відміну від звичайних відеогенераторів вона не просто "малює красиву дорогу" за текстом.
На вхід вона отримує одразу кілька потоків даних:
реальний RGB-кадр як візуальний якір сцени, HD-map зображення зі структурою доріг і смуг, trajectory poses — куди рухається ego-vehicle, bounding boxes інших учасників руху і текстовий опис умов сцени.
На основі всього цього модель генерує наступну послідовність кадрів. І ключове тут — вона працює авторегресивно: кожен згенерований chunk стає частиною контексту для наступного кроку. Це дозволяє будувати довгі rollouts де policy справді тестується в часі а не на одному кадрі.
У paper на arXiv NVIDIA пише що модель навчалась на 21 000 годин дорожніх сценаріїв і приблизно 4 млн мультиракурсних відеозаписів з vehicle-mounted cameras з текстовими описами і structured map annotations.
Я сам працював із real-world data, траєкторіями та сценаріями для autonomous driving — у мене навіть є наукова стаття на цю тему яка зараз на review. Тому для мене OmniDreams це не просто новина від NVIDIA а підтвердження важливого тренду.
Такі моделі не скасовують потребу в реальних даних. Навпаки — вони роблять реальні сценарії ще ціннішими. World model може масштабувати і візуалізувати сценарій. Але вона не відповідає на питання "який саме сценарій варто розігрувати" — де трапляються небезпечні ситуації, як поводяться пішоходи, які edge cases важливі для safety validation. Це зона real-world scenario extraction.
Тому майбутній стек симуляції ймовірно буде гібридним: real-world scenario mining → structured simulation → generative world models → closed-loop evaluation.
NVIDIA сама попереджає про обмеження: temporal inconsistency, нестабільність руху об'єктів, неточна фізика. Це генеративний sensor layer результати якого треба валідувати — не "істинний симулятор реальності".
GitHub OmniDreams · FlashDreams runtime · Hugging Face collection
🔔 ПІДПИСATИСЯ
👍6❤4❤🔥3🔥1👏1
Знову середа — і знову розбір нової наукової статті ☕️
Цього разу — цікава і трохи неприємна робота про те, як fine-tuning LLM може "витягнути" з моделі тексти, які вона бачила ще під час pretraining.
Ідея статті дуже проста, але наслідки серйозні.
Дослідники взяли великі мовні моделі й доопрацювали їх на задачі, яка на перший погляд виглядає абсолютно безпечною:
є короткий переказ абзацу з роману → треба згенерувати повноцінний художній абзац у стилі автора.
Тобто щось схоже на інструмент для письменників: ви даєте summary сцени, а модель розгортає його у красивий літературний текст.
Але після такого fine-tuning модель починала не просто "писати у стилі". Вона починала дослівно відтворювати великі фрагменти книжок, які вже були закодовані у її вагах після pretraining.
Fine-tuning не "завантажив" ці книги в модель заново. Він навчив модель іншому режиму поведінки: не перефразовувати, не вигадувати новий текст, а намагатися відновити оригінальний фрагмент за його семантичним описом. По суті, summary працював як "адрес" до вже запам'ятаного тексту.
Як це перевіряли. Автори побудували датасет із пар: короткий сюжетний переказ → оригінальний абзац із книги. Взяли сучасні романи, розбили на абзаци по 300–500 слів і через GPT-4o згенерували для кожного короткий зміст. Потім моделі навчали на зворотну задачу: за summary і ім'ям автора згенерувати оригінальний абзац. Тестували GPT-4o, Gemini 2.5 Pro та DeepSeek-V3.1.
Результати різкі.
Без доопрацювання GPT-4o майже не відтворювала дослівний текст — метрика BMC була близько 7.36%. Після fine-tuning в одному з експериментів GPT-4o досягла 91.9% BMC@5. Усі три моделі генерували дослівні фрагменти довжиною до 440 слів.
Ще цікавіше — ефект переносився між авторами. Модель доопрацьовували на романах Муракамі, а потім тестували на 51 книжці 32 інших авторів. Для 36 із 51 книжки BMC@5 перевищив 40%. Тобто fine-tuning навчив модель не просто "стилю Муракамі" а більш загальному режиму: якщо дали літературний summary і автора — спробуй відновити оригінальний текст який вже сидить у пам'яті.
Контрольний експеримент підтвердив логіку. Коли моделі доопрацьовували на синтетичних даних — BMC@5 був близький до нуля. Проблема не в тому що модель добре навчилась перетворювати summary у художній текст. Проблема в тому що частина реальних текстів вже була в pretraining data і fine-tuning навчив модель ефективніше їх діставати.
Ми часто сприймаємо alignment і guardrails як надійний захист: не копіюй, не відтворюй, пиши оригінально. Але ця робота показує що такі обмеження можуть бути радше крихким фільтром поведінки а не реальним "стиранням" інформації з моделі. Текстові послідовності не зникають із ваг після навчання.
І це стосується не лише книжок. Теоретично схожий ризик можливий для будь-яких даних які потрапили в навчання: фрагментів коду, приватних документів, логів, API keys або іншої sensitive information. LLM не працює як база даних де можна зробити SELECT і отримати конкретний рядок. Але fine-tuning може статистично підвищити ймовірність extraction якщо навчальна задача формує правильний режим поведінки.
Якщо компанія доопрацьовує модель на внутрішніх даних — не можна автоматично вважати що модель просто "узагальнить знання". Частина даних може стати більш доступною для відтворення після доопрацювання.
Модель після fine-tuning — це вже не зовсім та сама модель яку перевіряли на безпеку до цього. Її потрібно тестувати заново: чи не почала вона відтворювати protected content, чи не послабились guardrails, чи не витікає код або PII.
Є і відкрите питання яке автори прямо не закрили: чи починають доопрацьовані моделі плагіатити без інструкції "пиши у стилі автора"? Відповіді немає — але сама робота показує головне: memorization у великих моделях це реальний технічний ризик а не абстрактна проблема.
Бо fine-tuning це не просто "навчити модель нашому стилю". Іноді це спосіб відкрити двері до того що модель уже давно зберігала всередині.
Стаття на arXiv
🔔 ПІДПИСАТИСЯ
Цього разу — цікава і трохи неприємна робота про те, як fine-tuning LLM може "витягнути" з моделі тексти, які вона бачила ще під час pretraining.
Ідея статті дуже проста, але наслідки серйозні.
Дослідники взяли великі мовні моделі й доопрацювали їх на задачі, яка на перший погляд виглядає абсолютно безпечною:
є короткий переказ абзацу з роману → треба згенерувати повноцінний художній абзац у стилі автора.
Тобто щось схоже на інструмент для письменників: ви даєте summary сцени, а модель розгортає його у красивий літературний текст.
Але після такого fine-tuning модель починала не просто "писати у стилі". Вона починала дослівно відтворювати великі фрагменти книжок, які вже були закодовані у її вагах після pretraining.
Fine-tuning не "завантажив" ці книги в модель заново. Він навчив модель іншому режиму поведінки: не перефразовувати, не вигадувати новий текст, а намагатися відновити оригінальний фрагмент за його семантичним описом. По суті, summary працював як "адрес" до вже запам'ятаного тексту.
Як це перевіряли. Автори побудували датасет із пар: короткий сюжетний переказ → оригінальний абзац із книги. Взяли сучасні романи, розбили на абзаци по 300–500 слів і через GPT-4o згенерували для кожного короткий зміст. Потім моделі навчали на зворотну задачу: за summary і ім'ям автора згенерувати оригінальний абзац. Тестували GPT-4o, Gemini 2.5 Pro та DeepSeek-V3.1.
Результати різкі.
Без доопрацювання GPT-4o майже не відтворювала дослівний текст — метрика BMC була близько 7.36%. Після fine-tuning в одному з експериментів GPT-4o досягла 91.9% BMC@5. Усі три моделі генерували дослівні фрагменти довжиною до 440 слів.
Ще цікавіше — ефект переносився між авторами. Модель доопрацьовували на романах Муракамі, а потім тестували на 51 книжці 32 інших авторів. Для 36 із 51 книжки BMC@5 перевищив 40%. Тобто fine-tuning навчив модель не просто "стилю Муракамі" а більш загальному режиму: якщо дали літературний summary і автора — спробуй відновити оригінальний текст який вже сидить у пам'яті.
Контрольний експеримент підтвердив логіку. Коли моделі доопрацьовували на синтетичних даних — BMC@5 був близький до нуля. Проблема не в тому що модель добре навчилась перетворювати summary у художній текст. Проблема в тому що частина реальних текстів вже була в pretraining data і fine-tuning навчив модель ефективніше їх діставати.
Ми часто сприймаємо alignment і guardrails як надійний захист: не копіюй, не відтворюй, пиши оригінально. Але ця робота показує що такі обмеження можуть бути радше крихким фільтром поведінки а не реальним "стиранням" інформації з моделі. Текстові послідовності не зникають із ваг після навчання.
І це стосується не лише книжок. Теоретично схожий ризик можливий для будь-яких даних які потрапили в навчання: фрагментів коду, приватних документів, логів, API keys або іншої sensitive information. LLM не працює як база даних де можна зробити SELECT і отримати конкретний рядок. Але fine-tuning може статистично підвищити ймовірність extraction якщо навчальна задача формує правильний режим поведінки.
Якщо компанія доопрацьовує модель на внутрішніх даних — не можна автоматично вважати що модель просто "узагальнить знання". Частина даних може стати більш доступною для відтворення після доопрацювання.
Модель після fine-tuning — це вже не зовсім та сама модель яку перевіряли на безпеку до цього. Її потрібно тестувати заново: чи не почала вона відтворювати protected content, чи не послабились guardrails, чи не витікає код або PII.
Є і відкрите питання яке автори прямо не закрили: чи починають доопрацьовані моделі плагіатити без інструкції "пиши у стилі автора"? Відповіді немає — але сама робота показує головне: memorization у великих моделях це реальний технічний ризик а не абстрактна проблема.
Бо fine-tuning це не просто "навчити модель нашому стилю". Іноді це спосіб відкрити двері до того що модель уже давно зберігала всередині.
Стаття на arXiv
🔔 ПІДПИСАТИСЯ
❤6👍5🔥1👏1👀1
Fable 5: модель, яка ламає уявлення про vibe coding
Доброго ранку ☕️
Я зазвичай не дуже люблю гнатися за новинами й писати про модель у день релізу. Для цього є купа інших каналів де ви вже й так побачили що Anthropic випустила Claude Fable 5 — першу публічно доступну модель свого Mythos-класу.
Але цього разу не втримався. Бо за останні два дні трапилося занадто багато цікавого.
Головна причина хайпу —маркетинг Anthropic те що модель дуже сильна в довгих інженерних задачах, коді та візуальних інтерфейсах. Користувачі вже масово генерують повністю іграбельні браузерні ігри з одного початкового промпта — аж до 3D-сцен, фізики й реально робочих механік.
Anthropic показала показові приклади: браузерний CAD-редактор де Fable 5 створює модель готову до 3D-друку (і сам редактор теж написала Fable 5), симуляцію рідини синхронізовану з музикою, симуляцію Сонячної системи, автономну гру у Factorio. В мережі розійшлися й веб-версії "операційних систем" із логіном, браузером і Сапером.
Але є і інша сторона.
Fable 5 запускається з дуже жорсткими запобіжниками. Запити в чутливих зонах — наступальна кібербезпека, біологія/хімія, дистиляція моделі — проходять через автоматичні класифікатори. Якщо спрацьовують — користувача переводять на менш потужну Claude Opus 4.8. The Verge пише що фільтри налаштовані дуже консервативно і модель може відмовлятися навіть на базові освітні питання з біології.
Але найцікавіше — не це.
Розробник Jonathon Ready звернув увагу на фрагмент із system card Fable 5. Там є окрема категорія обмежень для запитів пов'язаних із frontier LLM development: пайплайни переднавчання великих моделей, розподілена інфраструктура для тренування, дизайн ML-прискорювачів.
Ключова різниця: для cyber/bio фільтрів користувач бачить переключення на іншу модель. А для frontier LLM development Anthropic прямо пише що ці запобіжники не будуть видимими. Fable 5 не скаже "я не можу з цим допомогти". Натомість ефективність відповіді може бути непомітно обмежена через prompt modification або steering vectors. Якщо модель дає погану відповідь на складне питання з frontier AI — ти не завжди можеш зрозуміти чому. Модель реально не впоралася? Питання погано сформульоване? Чи система тихо "приглушила" якість відповіді?
І ще про приватність. Для Mythos-class моделей Anthropic вимагає зберігати prompts і outputs до 30 днів для trust & safety. The Verge пише що саме через це Microsoft обмежила внутрішнє використання Fable 5 — юридичні команди оцінюють ризики для конфіденційних даних.
Тобто Fable 5 це одночасно дуже сильний сигнал майбутнього і хороше нагадування про реальність. Ми рухаємося до моделей які можуть за вечір зібрати браузерну гру або CAD-редактор. Але разом із цим з'являється новий клас питань: хто вирішує які можливості моделі доступні користувачу і чи можна довіряти системі якщо частина її обмежень працює невидимо.
Здається це буде одна з головних тем наступного етапу розвитку AI.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Я зазвичай не дуже люблю гнатися за новинами й писати про модель у день релізу. Для цього є купа інших каналів де ви вже й так побачили що Anthropic випустила Claude Fable 5 — першу публічно доступну модель свого Mythos-класу.
Але цього разу не втримався. Бо за останні два дні трапилося занадто багато цікавого.
Головна причина хайпу —
Anthropic показала показові приклади: браузерний CAD-редактор де Fable 5 створює модель готову до 3D-друку (і сам редактор теж написала Fable 5), симуляцію рідини синхронізовану з музикою, симуляцію Сонячної системи, автономну гру у Factorio. В мережі розійшлися й веб-версії "операційних систем" із логіном, браузером і Сапером.
Але є і інша сторона.
Fable 5 запускається з дуже жорсткими запобіжниками. Запити в чутливих зонах — наступальна кібербезпека, біологія/хімія, дистиляція моделі — проходять через автоматичні класифікатори. Якщо спрацьовують — користувача переводять на менш потужну Claude Opus 4.8. The Verge пише що фільтри налаштовані дуже консервативно і модель може відмовлятися навіть на базові освітні питання з біології.
Але найцікавіше — не це.
Розробник Jonathon Ready звернув увагу на фрагмент із system card Fable 5. Там є окрема категорія обмежень для запитів пов'язаних із frontier LLM development: пайплайни переднавчання великих моделей, розподілена інфраструктура для тренування, дизайн ML-прискорювачів.
Ключова різниця: для cyber/bio фільтрів користувач бачить переключення на іншу модель. А для frontier LLM development Anthropic прямо пише що ці запобіжники не будуть видимими. Fable 5 не скаже "я не можу з цим допомогти". Натомість ефективність відповіді може бути непомітно обмежена через prompt modification або steering vectors. Якщо модель дає погану відповідь на складне питання з frontier AI — ти не завжди можеш зрозуміти чому. Модель реально не впоралася? Питання погано сформульоване? Чи система тихо "приглушила" якість відповіді?
І ще про приватність. Для Mythos-class моделей Anthropic вимагає зберігати prompts і outputs до 30 днів для trust & safety. The Verge пише що саме через це Microsoft обмежила внутрішнє використання Fable 5 — юридичні команди оцінюють ризики для конфіденційних даних.
Тобто Fable 5 це одночасно дуже сильний сигнал майбутнього і хороше нагадування про реальність. Ми рухаємося до моделей які можуть за вечір зібрати браузерну гру або CAD-редактор. Але разом із цим з'являється новий клас питань: хто вирішує які можливості моделі доступні користувачу і чи можна довіряти системі якщо частина її обмежень працює невидимо.
Здається це буде одна з головних тем наступного етапу розвитку AI.
🔔 ПІДПИСАТИСЯ
👍9❤3👏2😁1🤯1👀1
Поки всі обговорювали Claude Fable 5 і ігри з одного промпта — глава Anthropic Даріо Амодеі опублікував не менш важливий текст.
"Policy on the AI Exponential". На фоні появи нових потужних моделей Mythos і Fable 5, а також переходу Anthropic до підходу де AI розробляє наступне покоління AI — станом на травень 2026 понад 80% коду що мерджиться у їхніх системах написаний Claude — Амодеі фактично пропонує перейти від м'якої саморегуляції до моделі де передові AI-системи мають проходити обов'язкове тестування і можуть бути заблоковані державою до релізу.
Його головна аналогія — авіація. Літаки не просто будують і кажуть "подивимося що буде" — їх сертифікують, тестують, перевіряють незалежні структури. З frontier AI має бути так само.
Конкретна пропозиція: моделі вище певного порогу обчислень мають проходити обов'язкову перевірку кваліфікованою третьою стороною за чотирма категоріями ризиків — кібербезпека, біологічна зброя, втрата контролю над AI-системами, автоматизовані дослідження які можуть прискорити перші три. Якщо модель переходить критичні межі — реліз можна заблокувати або відкликати.
Амодеі також визнає що AI може серйозно вдарити по ринку праці і пропонує не чекати: страхування зарплат, гранти на перекваліфікацію, а якщо витіснення стане стабільним — до безумовного базового доходу. Anthropic вже оголосила ініціативи на $350 млн в цьому напрямку.
Але критики вже називають це спробою побудувати регулювання під великих гравців. Хто найкраще готовий до обов'язкових аудитів і складної compliance-інфраструктури? Anthropic, OpenAI, Google DeepMind. А маленькі лабораторії і open-source команди можуть просто не витягнути таку бюрократію.
Окрема проблема — відкриті моделі. Закритий API можна відкликати. А якщо ваги вже опубліковані — їх неможливо "відкликати" назад як небезпечний літак. Якщо держава отримає право блокувати релізи до публікації — це може фактично сильніше вдарити саме по open-source AI. Open-source це своєрідний соціалізм у світі програмного забезпечення — і він явно не вигідний великим корпораціям.
І тут мені згадуються ідеї Пітера Тіля про технократичне майбутнє де корпорації фактично замінюють держави. Чи не рухаємося ми до світу де саме великі AI-лабораторії разом із лояльними регуляторами визначатимуть хто може і не може будувати потужні моделі?
Головна історія тут не в тому правий Амодеі чи ні. Головна історія в тому що дискусія про AI-регулювання переходить у нову фазу. Раніше великі лабораторії говорили "давайте будемо прозорими". Тепер звучить інше: "держава має право блокувати небезпечні системи" і "AI-компанії мають платити за економічні наслідки автоматизації".
Fable 5 показала наскільки швидко ростуть можливості моделей. Есе Амодеі показує іншу сторону: що навіть самі творці вже не хочуть жити в світі де кожен наступний реліз просто викочується без зовнішнього контролю.
Питання лише в тому чи стане цей контроль реальною безпекою — чи просто новим бар'єром який закріпить владу тих хто вже попереду.
🔔 ПІДПИСАТИСЯ
"Policy on the AI Exponential". На фоні появи нових потужних моделей Mythos і Fable 5, а також переходу Anthropic до підходу де AI розробляє наступне покоління AI — станом на травень 2026 понад 80% коду що мерджиться у їхніх системах написаний Claude — Амодеі фактично пропонує перейти від м'якої саморегуляції до моделі де передові AI-системи мають проходити обов'язкове тестування і можуть бути заблоковані державою до релізу.
Його головна аналогія — авіація. Літаки не просто будують і кажуть "подивимося що буде" — їх сертифікують, тестують, перевіряють незалежні структури. З frontier AI має бути так само.
Конкретна пропозиція: моделі вище певного порогу обчислень мають проходити обов'язкову перевірку кваліфікованою третьою стороною за чотирма категоріями ризиків — кібербезпека, біологічна зброя, втрата контролю над AI-системами, автоматизовані дослідження які можуть прискорити перші три. Якщо модель переходить критичні межі — реліз можна заблокувати або відкликати.
Амодеі також визнає що AI може серйозно вдарити по ринку праці і пропонує не чекати: страхування зарплат, гранти на перекваліфікацію, а якщо витіснення стане стабільним — до безумовного базового доходу. Anthropic вже оголосила ініціативи на $350 млн в цьому напрямку.
Але критики вже називають це спробою побудувати регулювання під великих гравців. Хто найкраще готовий до обов'язкових аудитів і складної compliance-інфраструктури? Anthropic, OpenAI, Google DeepMind. А маленькі лабораторії і open-source команди можуть просто не витягнути таку бюрократію.
Окрема проблема — відкриті моделі. Закритий API можна відкликати. А якщо ваги вже опубліковані — їх неможливо "відкликати" назад як небезпечний літак. Якщо держава отримає право блокувати релізи до публікації — це може фактично сильніше вдарити саме по open-source AI. Open-source це своєрідний соціалізм у світі програмного забезпечення — і він явно не вигідний великим корпораціям.
І тут мені згадуються ідеї Пітера Тіля про технократичне майбутнє де корпорації фактично замінюють держави. Чи не рухаємося ми до світу де саме великі AI-лабораторії разом із лояльними регуляторами визначатимуть хто може і не може будувати потужні моделі?
Головна історія тут не в тому правий Амодеі чи ні. Головна історія в тому що дискусія про AI-регулювання переходить у нову фазу. Раніше великі лабораторії говорили "давайте будемо прозорими". Тепер звучить інше: "держава має право блокувати небезпечні системи" і "AI-компанії мають платити за економічні наслідки автоматизації".
Fable 5 показала наскільки швидко ростуть можливості моделей. Есе Амодеі показує іншу сторону: що навіть самі творці вже не хочуть жити в світі де кожен наступний реліз просто викочується без зовнішнього контролю.
Питання лише в тому чи стане цей контроль реальною безпекою — чи просто новим бар'єром який закріпить владу тих хто вже попереду.
🔔 ПІДПИСАТИСЯ
🤔6⚡5👍3❤1