4 навички без яких розробнику буде складно в AI-era
Доброго ранку ☕️
Andrew Ng та команда DeepLearning.AI проаналізували понад 10 000 вакансій, провели десятки інтерв'ю з AI-експертами, hiring-менеджерами та рекрутерами й спробували відповісти на просте питання: що сьогодні насправді варто вчити розробнику якщо навколо AI занадто багато шуму та хайпу?
У результаті вони виділили 4 ключові групи навичок.
1. Вміти будувати AI-системи а не просто викликати API
LLM принципово відрізняються від класичного software: їхній результат не є повністю детермінованим. Тому недостатньо просто знати як підключити модель. Потрібно розуміти LLM та context engineering, RAG, agentic workflows, ML і deep learning, evals, error analysis. І мабуть найважливіше — вміти вимірювати якість AI-системи та системно покращувати її поведінку.
Тобто AI engineering дедалі менше схожий на "написав prompt, наче працює". І дедалі більше на інженерний цикл: побудувати → оцінити → проаналізувати помилки → покращити → повторити.
2. Software Engineering нікуди не зникає. Навпаки
Є популярна думка що coding agents зроблять фундаментальні знання програмування менш важливими. Ng фактично говорить протилежне.
Коли агент пише значну частину коду за тебе твоєю роботою стає розуміти чи хороші рішення він приймає. Архітектура, масштабованість, надійність, безпека, приватність, робота з даними, тестування, вартість. Якщо ти не бачиш цих trade-offs — агент теж навряд чи магічно їх вирішить. Більше того ти навіть не знатимеш який контекст йому дати щоб він прийняв правильне рішення.
Тому парадокс AI-era може бути таким: чим більше коду пише AI тим важливішим стає розуміння інженерних основ.
3. Coding agents це вже окрема інженерна навичка
Не просто "користуватися Cursor, Claude Code чи Copilot". А розуміти як організувати роботу агента. Коли дати йому автономність. Коли втрутитися. Коли спочатку попросити скласти план. Як керувати контекстом. Як написати specification. Як дати агенту тести чи інші verifiers щоб він сам міг перевіряти результат. Як запускати кількох агентів паралельно. І що теж важливо — як не дати агенту випадково зробити щось веселе з production database 🙂
Фактично виникає новий рівень абстракції: раніше ми керували кодом, тепер дедалі частіше керуємо системами які пишуть код.
4. Найцікавіший пункт — Shaping the Build
Coding agents дедалі краще реалізують чітко сформульовані задачі. Тому bottleneck поступово зміщується. Проблема вже не тільки в "як це побудувати" а все частіше в "що саме потрібно побудувати".
Тут інженеру вже недостатньо отримати готовий дизайн і перетворити його на код. Потрібні product sense, розуміння бізнесу і користувача, здатність формулювати проблему, здатність вирішувати що має потрапити в specification, розуміння коли швидко зробити MVP а коли навпаки сповільнитися.
Це одна з найважливіших змін у професії. AI поступово забирає частину execution. А цінність людини зміщується вище: проблема → рішення → специфікація → перевірка.
Хороший інженер майбутнього це не той хто швидше за всіх пише код. А той хто правильно визначає проблему, формує рішення, керує AI у процесі реалізації та може довести що результат справді працює.
І є ще п'ята навичка яка фактично лежить під усіма чотирма — постійно перевчатися. Бо workflows які сьогодні здаються cutting-edge через рік цілком можуть виглядати так само як сьогодні виглядає "скопіювати код із ChatGPT у IDE".
І саме це мабуть зараз найбільше відрізняє AI engineering від класичного software development.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Andrew Ng та команда DeepLearning.AI проаналізували понад 10 000 вакансій, провели десятки інтерв'ю з AI-експертами, hiring-менеджерами та рекрутерами й спробували відповісти на просте питання: що сьогодні насправді варто вчити розробнику якщо навколо AI занадто багато шуму та хайпу?
У результаті вони виділили 4 ключові групи навичок.
1. Вміти будувати AI-системи а не просто викликати API
LLM принципово відрізняються від класичного software: їхній результат не є повністю детермінованим. Тому недостатньо просто знати як підключити модель. Потрібно розуміти LLM та context engineering, RAG, agentic workflows, ML і deep learning, evals, error analysis. І мабуть найважливіше — вміти вимірювати якість AI-системи та системно покращувати її поведінку.
Тобто AI engineering дедалі менше схожий на "написав prompt, наче працює". І дедалі більше на інженерний цикл: побудувати → оцінити → проаналізувати помилки → покращити → повторити.
2. Software Engineering нікуди не зникає. Навпаки
Є популярна думка що coding agents зроблять фундаментальні знання програмування менш важливими. Ng фактично говорить протилежне.
Коли агент пише значну частину коду за тебе твоєю роботою стає розуміти чи хороші рішення він приймає. Архітектура, масштабованість, надійність, безпека, приватність, робота з даними, тестування, вартість. Якщо ти не бачиш цих trade-offs — агент теж навряд чи магічно їх вирішить. Більше того ти навіть не знатимеш який контекст йому дати щоб він прийняв правильне рішення.
Тому парадокс AI-era може бути таким: чим більше коду пише AI тим важливішим стає розуміння інженерних основ.
3. Coding agents це вже окрема інженерна навичка
Не просто "користуватися Cursor, Claude Code чи Copilot". А розуміти як організувати роботу агента. Коли дати йому автономність. Коли втрутитися. Коли спочатку попросити скласти план. Як керувати контекстом. Як написати specification. Як дати агенту тести чи інші verifiers щоб він сам міг перевіряти результат. Як запускати кількох агентів паралельно. І що теж важливо — як не дати агенту випадково зробити щось веселе з production database 🙂
Фактично виникає новий рівень абстракції: раніше ми керували кодом, тепер дедалі частіше керуємо системами які пишуть код.
4. Найцікавіший пункт — Shaping the Build
Coding agents дедалі краще реалізують чітко сформульовані задачі. Тому bottleneck поступово зміщується. Проблема вже не тільки в "як це побудувати" а все частіше в "що саме потрібно побудувати".
Тут інженеру вже недостатньо отримати готовий дизайн і перетворити його на код. Потрібні product sense, розуміння бізнесу і користувача, здатність формулювати проблему, здатність вирішувати що має потрапити в specification, розуміння коли швидко зробити MVP а коли навпаки сповільнитися.
Це одна з найважливіших змін у професії. AI поступово забирає частину execution. А цінність людини зміщується вище: проблема → рішення → специфікація → перевірка.
Хороший інженер майбутнього це не той хто швидше за всіх пише код. А той хто правильно визначає проблему, формує рішення, керує AI у процесі реалізації та може довести що результат справді працює.
І є ще п'ята навичка яка фактично лежить під усіма чотирма — постійно перевчатися. Бо workflows які сьогодні здаються cutting-edge через рік цілком можуть виглядати так само як сьогодні виглядає "скопіювати код із ChatGPT у IDE".
І саме це мабуть зараз найбільше відрізняє AI engineering від класичного software development.
🔔 ПІДПИСАТИСЯ
👍12🔥6❤2👏1
Anthropic почала вбудовувати невидимі водяні знаки в тексти Claude
Доброго ранку ☕️
Компанія заявила що така система буде використовуватися у всіх нових моделях Claude а згодом пошириться і на існуючі. Причина — вимоги EU AI Act, який передбачає машинозчитуване маркування AI-контенту і набув чинності 2 серпня.
Але цікавіше те як саме це працює.
Claude не вставляє в текст якийсь прихований символ чи метадані. Замість цього використовується технологія на основі SynthID-Text від Google. Під час генерації модель постійно обирає між кількома приблизно рівнозначними словами або формулюваннями. Наприклад "AI активно змінює ринок" або "AI суттєво трансформує ринок". Для людини різниця майже відсутня. Але алгоритм трохи підштовхує модель до певних варіантів слів за секретним статистичним ключем, який Anthropic порівнює з числом пі за складністю.
У результаті в тексті виникає прихований патерн який спеціальний детектор може знайти пізніше. Тобто водяний знак це не конкретний символ у тексті а статистична структура вибору токенів. Anthropic планує надати API який повертатиме оцінку того наскільки текст схожий на згенерований Claude.
І тут починаються цікаві нюанси.
Це не 100% доказ. Детектор показує ймовірність а не остаточний вердикт. Можливі false positive та false negative. Більше того якщо людина написала текст сама а потім попросила Claude його скоротити, перекласти чи відредагувати, у фінальній версії теж може залишитися watermark-сигнал.
Водяний знак переживає copy-paste і невеликі правки. Але сильний rewrite або paraphrasing потенційно знищить статистичний патерн. Тому теоретично можна просто прогнати текст через іншу LLM.
У коді watermark буде значно слабшим. У звичайному тексті модель має багато варіантів продовження. У коді часто існує один правильний варіант. Якщо потрібно написати "2 + 2 =" модель не може вибрати між 4, 7 або 12 щоб створити сигнал. Тому найбільше watermark-патерну буде в коментарях, документації та місцях де існує кілька допустимих варіантів генерації.
Для зображень використовується інший механізм — C2PA, криптографічно підписані дані про походження файлу які записуються в метадані а не в саме зображення.
І саме тут навколо рішення почалася серйозна дискусія. За даними The Star і TechCrunch, десятки користувачів на X критикували рішення. За два тижні після запуску принаймні чотири платних підписники підтвердили скасування підписки з посиланнями на професійну відповідальність і ризики клієнтських контрактів, а десятки інших заявляли про те саме в соцмережах без підтверджень. Anthropic каже що не спостерігає зростання відтоку клієнтів загалом.
Один користувач на Reddit писав: "Хто потрапить під підозру? Студент який попросив Claude переструктурувати абзац. Журналіст який попросив узагальнити стенограму на двісті сторінок. Той хто мав творчий блок і попросив підібрати синоніми. Всі вони виходять з процесу з цифровим тавром на лобі." Anthropic заперечує таку інтерпретацію і стверджує що watermark "не містить ідентифікуючої інформації і не може бути простежений до конкретної людини чи чату".
Колишній керівник Microsoft Стівен Сінофскі сформулював це як право людини на приватні думки без цифрового сліду.
Є й технічна вразливість системи. Вже за кілька днів після технічного розкриття деталей інструмент на GitHub для видалення таких водяних знаків, що працює проти Claude, SynthID-Text, OpenAI і C2PA, набрав понад 10 000 зірок. Тобто питання наскільки ефективною буде система проти тих хто справді хоче її обійти залишається відкритим, тоді як звичайний користувач який нічого не приховує може отримати false positive.
Найцікавіше що Anthropic схоже лише перша. OpenAI, Google, Meta та Microsoft також підписали європейський Code of Practice on Transparency of AI-generated Content. OpenAI вже застосовує SynthID для зображень і з 31 липня розширила покриття на аудіо.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Компанія заявила що така система буде використовуватися у всіх нових моделях Claude а згодом пошириться і на існуючі. Причина — вимоги EU AI Act, який передбачає машинозчитуване маркування AI-контенту і набув чинності 2 серпня.
Але цікавіше те як саме це працює.
Claude не вставляє в текст якийсь прихований символ чи метадані. Замість цього використовується технологія на основі SynthID-Text від Google. Під час генерації модель постійно обирає між кількома приблизно рівнозначними словами або формулюваннями. Наприклад "AI активно змінює ринок" або "AI суттєво трансформує ринок". Для людини різниця майже відсутня. Але алгоритм трохи підштовхує модель до певних варіантів слів за секретним статистичним ключем, який Anthropic порівнює з числом пі за складністю.
У результаті в тексті виникає прихований патерн який спеціальний детектор може знайти пізніше. Тобто водяний знак це не конкретний символ у тексті а статистична структура вибору токенів. Anthropic планує надати API який повертатиме оцінку того наскільки текст схожий на згенерований Claude.
І тут починаються цікаві нюанси.
Це не 100% доказ. Детектор показує ймовірність а не остаточний вердикт. Можливі false positive та false negative. Більше того якщо людина написала текст сама а потім попросила Claude його скоротити, перекласти чи відредагувати, у фінальній версії теж може залишитися watermark-сигнал.
Водяний знак переживає copy-paste і невеликі правки. Але сильний rewrite або paraphrasing потенційно знищить статистичний патерн. Тому теоретично можна просто прогнати текст через іншу LLM.
У коді watermark буде значно слабшим. У звичайному тексті модель має багато варіантів продовження. У коді часто існує один правильний варіант. Якщо потрібно написати "2 + 2 =" модель не може вибрати між 4, 7 або 12 щоб створити сигнал. Тому найбільше watermark-патерну буде в коментарях, документації та місцях де існує кілька допустимих варіантів генерації.
Для зображень використовується інший механізм — C2PA, криптографічно підписані дані про походження файлу які записуються в метадані а не в саме зображення.
І саме тут навколо рішення почалася серйозна дискусія. За даними The Star і TechCrunch, десятки користувачів на X критикували рішення. За два тижні після запуску принаймні чотири платних підписники підтвердили скасування підписки з посиланнями на професійну відповідальність і ризики клієнтських контрактів, а десятки інших заявляли про те саме в соцмережах без підтверджень. Anthropic каже що не спостерігає зростання відтоку клієнтів загалом.
Один користувач на Reddit писав: "Хто потрапить під підозру? Студент який попросив Claude переструктурувати абзац. Журналіст який попросив узагальнити стенограму на двісті сторінок. Той хто мав творчий блок і попросив підібрати синоніми. Всі вони виходять з процесу з цифровим тавром на лобі." Anthropic заперечує таку інтерпретацію і стверджує що watermark "не містить ідентифікуючої інформації і не може бути простежений до конкретної людини чи чату".
Колишній керівник Microsoft Стівен Сінофскі сформулював це як право людини на приватні думки без цифрового сліду.
Є й технічна вразливість системи. Вже за кілька днів після технічного розкриття деталей інструмент на GitHub для видалення таких водяних знаків, що працює проти Claude, SynthID-Text, OpenAI і C2PA, набрав понад 10 000 зірок. Тобто питання наскільки ефективною буде система проти тих хто справді хоче її обійти залишається відкритим, тоді як звичайний користувач який нічого не приховує може отримати false positive.
Найцікавіше що Anthropic схоже лише перша. OpenAI, Google, Meta та Microsoft також підписали європейський Code of Practice on Transparency of AI-generated Content. OpenAI вже застосовує SynthID для зображень і з 31 липня розширила покриття на аудіо.
🔔 ПІДПИСАТИСЯ
1👍6❤4🔥2
AI-гроші ходять по колу 🤯
Доброго ранку ☕️
Зараз багато говорять про замкнений цикл грошей в AI-індустрії, але розібратися, хто кого фінансує і куди зрештою йдуть ці мільярди, не так просто. Я зібрав усе в одну схему — з цифрами та посиланнями на першоджерела. 🕵🏻♂️🔍 👇🏻
Почнемо з OpenAI. У 2025 році OpenAI, SoftBank, Oracle та MGX запустили Stargate, програму будівництва AI-інфраструктури у США з планом інвестувати до $500 млрд протягом чотирьох років. Це не один дата-центр за $500 млрд як іноді пишуть а ціла інфраструктурна програма.
У лютому 2026 OpenAI оголосила ще один гігантський раунд: $30 млрд від Nvidia, $30 млрд від SoftBank і $50 млрд від Amazon. Пізніше раунд виріс до $122 млрд.
А тепер подивимось куди OpenAI витрачає ці гроші. З Amazon ситуація особливо цікава: Amazon вкладає $50 млрд в OpenAI а OpenAI паралельно розширює контракт з AWS ще на $100 млрд на вісім років. Тобто Amazon дає OpenAI $50 млрд, а OpenAI повертає AWS понад $100 млрд. Це вже дуже схоже на замкнений контур.
З Oracle наступний рівень. За даними Reuters і WSJ OpenAI підписала контракт приблизно на $300 млрд compute протягом п'яти років. А Oracle своєю чергою планувала придбати приблизно $40 млрд Nvidia GPU і здавати ці потужності OpenAI. Отримуємо: OpenAI платить Oracle, Oracle купує чипи у Nvidia. А Nvidia при цьому сама інвестує в OpenAI.
Є ще AMD. OpenAI домовилася розгорнути до 6 GW AMD GPU. У відповідь AMD видала OpenAI warrants на купівлю до 160 млн акцій AMD, на момент угоди це відповідало приблизно 10% компанії за умови виконання всіх milestones. Великий клієнт AMD потенційно стає ще й великим акціонером AMD.
Ще цікавіше стає коли дивитися на Anthropic. У листопаді 2025 Microsoft і Nvidia домовилися інвестувати в Anthropic до $5 млрд і $10 млрд відповідно. У межах тієї ж домовленості Anthropic зобов'язалася придбати $30 млрд Azure compute. І Microsoft при цьому залишається одним із найбільших акціонерів OpenAI, головного конкурента Anthropic.
Далі Google. Компанія домовилася інвестувати в Anthropic до $40 млрд. Паралельно Anthropic розширює використання Google Cloud і отримує доступ до мільйона TPU. І Google при цьому має власну Gemini, прямого конкурента Claude.
А ще Amazon вклав у Anthropic спочатку $8 млрд, потім додав ще $5 млрд і погодив можливість інвестувати до $20 млрд. За даними FT фактично вже вкладено близько $18 млрд. У відповідь Anthropic зобов'язалася витратити на AWS понад $100 млрд протягом наступних десяти років.
До цього додаємо CoreWeave, один із найбільших AI-neocloud провайдерів. У 2025 році 67% його виручки припадало на Microsoft. Компанія має контракти з OpenAI, Meta та тепер Anthropic, а вся її GPU-інфраструктура побудована на Nvidia. І Nvidia сама інвестує в CoreWeave.
Тобто Nvidia одночасно виробляє GPU, інвестує в AI-компанії, інвестує в компанії які купують її GPU, продає їм hardware, а вони здають цей hardware в оренду тим самим OpenAI, Microsoft, Meta та Anthropic.
Це не означає що виручка Nvidia, AWS, Azure чи Oracle "намальована", і не означає автоматично що перед нами фінансова піраміда. У фінансах подібні конструкції давно існують під назвою vendor financing: постачальник допомагає профінансувати покупця щоб той міг придбати його продукт.
Але масштаб тут уже незвичайний. Financial Times у липні прямо назвав частину цих угод "circular financing". А цього тижня FT пішов ще далі і виніс у заголовок фразу "Nvidia becomes the bank of AI".
Reuters повідомив буквально сьогодні що Nvidia разом з Apollo, BlackRock, Blackstone, Brookfield, Goldman Sachs і KKR працює над платформою здатною мобілізувати понад $500 млрд для фінансування AI-інфраструктури. Сама Nvidia потенційно може підтримати до $125 млрд цього фінансування.
Тож ми бачимо реальний попит на AI чи частково попит, який сама індустрія допомагає фінансувати?
Чим сильніше пов’язані AI-компанії, дата-центри, хмари, кредити й GPU-постачальники, тим системнішим стає ризик. Якщо compute перетвориться на реальну виручку — модель спрацює. Якщо ні, проблема вдарить одразу по всьому ланцюгу.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Зараз багато говорять про замкнений цикл грошей в AI-індустрії, але розібратися, хто кого фінансує і куди зрештою йдуть ці мільярди, не так просто. Я зібрав усе в одну схему — з цифрами та посиланнями на першоджерела. 🕵🏻♂️🔍 👇🏻
Почнемо з OpenAI. У 2025 році OpenAI, SoftBank, Oracle та MGX запустили Stargate, програму будівництва AI-інфраструктури у США з планом інвестувати до $500 млрд протягом чотирьох років. Це не один дата-центр за $500 млрд як іноді пишуть а ціла інфраструктурна програма.
У лютому 2026 OpenAI оголосила ще один гігантський раунд: $30 млрд від Nvidia, $30 млрд від SoftBank і $50 млрд від Amazon. Пізніше раунд виріс до $122 млрд.
А тепер подивимось куди OpenAI витрачає ці гроші. З Amazon ситуація особливо цікава: Amazon вкладає $50 млрд в OpenAI а OpenAI паралельно розширює контракт з AWS ще на $100 млрд на вісім років. Тобто Amazon дає OpenAI $50 млрд, а OpenAI повертає AWS понад $100 млрд. Це вже дуже схоже на замкнений контур.
З Oracle наступний рівень. За даними Reuters і WSJ OpenAI підписала контракт приблизно на $300 млрд compute протягом п'яти років. А Oracle своєю чергою планувала придбати приблизно $40 млрд Nvidia GPU і здавати ці потужності OpenAI. Отримуємо: OpenAI платить Oracle, Oracle купує чипи у Nvidia. А Nvidia при цьому сама інвестує в OpenAI.
Є ще AMD. OpenAI домовилася розгорнути до 6 GW AMD GPU. У відповідь AMD видала OpenAI warrants на купівлю до 160 млн акцій AMD, на момент угоди це відповідало приблизно 10% компанії за умови виконання всіх milestones. Великий клієнт AMD потенційно стає ще й великим акціонером AMD.
Ще цікавіше стає коли дивитися на Anthropic. У листопаді 2025 Microsoft і Nvidia домовилися інвестувати в Anthropic до $5 млрд і $10 млрд відповідно. У межах тієї ж домовленості Anthropic зобов'язалася придбати $30 млрд Azure compute. І Microsoft при цьому залишається одним із найбільших акціонерів OpenAI, головного конкурента Anthropic.
Далі Google. Компанія домовилася інвестувати в Anthropic до $40 млрд. Паралельно Anthropic розширює використання Google Cloud і отримує доступ до мільйона TPU. І Google при цьому має власну Gemini, прямого конкурента Claude.
А ще Amazon вклав у Anthropic спочатку $8 млрд, потім додав ще $5 млрд і погодив можливість інвестувати до $20 млрд. За даними FT фактично вже вкладено близько $18 млрд. У відповідь Anthropic зобов'язалася витратити на AWS понад $100 млрд протягом наступних десяти років.
До цього додаємо CoreWeave, один із найбільших AI-neocloud провайдерів. У 2025 році 67% його виручки припадало на Microsoft. Компанія має контракти з OpenAI, Meta та тепер Anthropic, а вся її GPU-інфраструктура побудована на Nvidia. І Nvidia сама інвестує в CoreWeave.
Тобто Nvidia одночасно виробляє GPU, інвестує в AI-компанії, інвестує в компанії які купують її GPU, продає їм hardware, а вони здають цей hardware в оренду тим самим OpenAI, Microsoft, Meta та Anthropic.
Це не означає що виручка Nvidia, AWS, Azure чи Oracle "намальована", і не означає автоматично що перед нами фінансова піраміда. У фінансах подібні конструкції давно існують під назвою vendor financing: постачальник допомагає профінансувати покупця щоб той міг придбати його продукт.
Але масштаб тут уже незвичайний. Financial Times у липні прямо назвав частину цих угод "circular financing". А цього тижня FT пішов ще далі і виніс у заголовок фразу "Nvidia becomes the bank of AI".
Reuters повідомив буквально сьогодні що Nvidia разом з Apollo, BlackRock, Blackstone, Brookfield, Goldman Sachs і KKR працює над платформою здатною мобілізувати понад $500 млрд для фінансування AI-інфраструктури. Сама Nvidia потенційно може підтримати до $125 млрд цього фінансування.
Тож ми бачимо реальний попит на AI чи частково попит, який сама індустрія допомагає фінансувати?
Чим сильніше пов’язані AI-компанії, дата-центри, хмари, кредити й GPU-постачальники, тим системнішим стає ризик. Якщо compute перетвориться на реальну виручку — модель спрацює. Якщо ні, проблема вдарить одразу по всьому ланцюгу.
🔔 ПІДПИСАТИСЯ
👍7🔥3❤1🤯1
Grok повернувся у вищу лігу. І схоже Cursor тут зіграв ключову роль 🚀
Доброго ранку ☕️
Щось останнім часом дуже багато роботи, тож не встигаю нормально розбирати новини. Зараз трохи прихворів, тому нарешті знайшов на це час 😅
Ще нещодавно Grok складно було назвати реальним конкурентом найсильніших моделей OpenAI та Anthropic. Але новий Grok 4.6 уже фактично повертає SpaceXAI у frontier.
На Artificial Analysis Intelligence Index модель набрала 61 бал, стільки ж скільки GPT-5.6 Sol, і лише трохи нижче за лідерів Anthropic. При цьому API коштує $2 за 1 млн input-токенів і $6 за output, тоді як близькі за якістю GPT-5.6 Sol та Claude Opus 5 суттєво дорожчі. Детальний розбір бенчмарків від Artificial Analysis.
Але найцікавіше навіть не benchmark scores.
На AA-Briefcase, тесті довгих agentic-задач де модель годинами працює з файлами та створює документи, таблиці й презентації, Grok 4.6 у середньому витрачав близько 53 turns та 0.5B input tokens. Claude Opus 5 близько 103 turns та 2B tokens. Тобто Grok поки поступається Opus за кінцевим score але проходить подібні довгі workflows приблизно вдвічі меншою кількістю кроків і з учетверо меншим input-контекстом.
А для AI-агентів це може бути важливіше за ще +1% на черговому benchmark.
Звідки такий прогрес? Тут починається найцікавіша частина історії, Cursor.
Навесні Cursor та SpaceXAI уклали партнерство: Cursor отримав доступ до величезних обчислювальних потужностей Colossus, а SpaceXAI до експертизи та даних реальних coding-agent workflows. Це дуже цінний тип даних: prompts програмістів, ітерації агента, виправлення помилок, рішення щодо архітектури, робота з великими codebase.
І результати з'явилися дуже швидко. Grok 4.3 мав 38 балів в Artificial Analysis Index. Grok 4.5 у липні вже 56. Grok 4.6 у серпні 61.
При навчанні 4.6 компанія також збільшила supplemental pretraining, використала Grok 4.5 для генерації нових training trajectories і додала reinforcement learning на реальних agentic-задачах: coding, knowledge work, web development, CAD і навіть оптимізації GPU kernels.
А далі партнерство перетворилося на щось значно більше. У серпні SpaceX завершила придбання Cursor приблизно за $60 млрд в акціях. І тепер у Маска фактично формується вертикально інтегрований AI-стек: compute → модель → agent harness → IDE → дані реальних користувачів → наступна модель.
А через три дні після завершення угоди Cursor запустив Origin, власний аналог GitHub створений уже з розрахунком на те що значну частину коду генеруватимуть не люди а агенти.
Я не поспішав з цим постом бо вирішив спочатку сам спробувати. Cursor я користуюсь досить активно і можу сказати що Grok 4.6 дійсно непогана модель, на безкоштовній підписці вона точно має сенс. Але мій особистий фаворит зараз це Composer 2.5. Для написання коду він не виглядає гіршим за Medium чи навіть High-моделі типу GPT-5.6 Sol. Розумію що Sol буде кращим для мультиагентних задач де треба агрегувати багато інформації з різних джерел, а Composer не пише код гірше за Opus. Просто у Opus і Sol сила в іншому. Але саме з точки зору написання коду Composer мене дуже приємно здивував.
Мені здається це добре показує куди рухається конкуренція в AI. Раніше лабораторії змагалися за найкращу модель. Тепер перевагою стає весь ланцюжок: хто має compute, хто має дані реальної роботи агентів, хто контролює середовище де вони працюють, і хто може виконати задачу дешевше та за меншу кількість кроків.
І в такій системі Cursor для SpaceXAI може виявитися значно ціннішим активом ніж просто популярний редактор коду.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Щось останнім часом дуже багато роботи, тож не встигаю нормально розбирати новини. Зараз трохи прихворів, тому нарешті знайшов на це час 😅
Ще нещодавно Grok складно було назвати реальним конкурентом найсильніших моделей OpenAI та Anthropic. Але новий Grok 4.6 уже фактично повертає SpaceXAI у frontier.
На Artificial Analysis Intelligence Index модель набрала 61 бал, стільки ж скільки GPT-5.6 Sol, і лише трохи нижче за лідерів Anthropic. При цьому API коштує $2 за 1 млн input-токенів і $6 за output, тоді як близькі за якістю GPT-5.6 Sol та Claude Opus 5 суттєво дорожчі. Детальний розбір бенчмарків від Artificial Analysis.
Але найцікавіше навіть не benchmark scores.
На AA-Briefcase, тесті довгих agentic-задач де модель годинами працює з файлами та створює документи, таблиці й презентації, Grok 4.6 у середньому витрачав близько 53 turns та 0.5B input tokens. Claude Opus 5 близько 103 turns та 2B tokens. Тобто Grok поки поступається Opus за кінцевим score але проходить подібні довгі workflows приблизно вдвічі меншою кількістю кроків і з учетверо меншим input-контекстом.
А для AI-агентів це може бути важливіше за ще +1% на черговому benchmark.
Звідки такий прогрес? Тут починається найцікавіша частина історії, Cursor.
Навесні Cursor та SpaceXAI уклали партнерство: Cursor отримав доступ до величезних обчислювальних потужностей Colossus, а SpaceXAI до експертизи та даних реальних coding-agent workflows. Це дуже цінний тип даних: prompts програмістів, ітерації агента, виправлення помилок, рішення щодо архітектури, робота з великими codebase.
І результати з'явилися дуже швидко. Grok 4.3 мав 38 балів в Artificial Analysis Index. Grok 4.5 у липні вже 56. Grok 4.6 у серпні 61.
При навчанні 4.6 компанія також збільшила supplemental pretraining, використала Grok 4.5 для генерації нових training trajectories і додала reinforcement learning на реальних agentic-задачах: coding, knowledge work, web development, CAD і навіть оптимізації GPU kernels.
А далі партнерство перетворилося на щось значно більше. У серпні SpaceX завершила придбання Cursor приблизно за $60 млрд в акціях. І тепер у Маска фактично формується вертикально інтегрований AI-стек: compute → модель → agent harness → IDE → дані реальних користувачів → наступна модель.
А через три дні після завершення угоди Cursor запустив Origin, власний аналог GitHub створений уже з розрахунком на те що значну частину коду генеруватимуть не люди а агенти.
Я не поспішав з цим постом бо вирішив спочатку сам спробувати. Cursor я користуюсь досить активно і можу сказати що Grok 4.6 дійсно непогана модель, на безкоштовній підписці вона точно має сенс. Але мій особистий фаворит зараз це Composer 2.5. Для написання коду він не виглядає гіршим за Medium чи навіть High-моделі типу GPT-5.6 Sol. Розумію що Sol буде кращим для мультиагентних задач де треба агрегувати багато інформації з різних джерел, а Composer не пише код гірше за Opus. Просто у Opus і Sol сила в іншому. Але саме з точки зору написання коду Composer мене дуже приємно здивував.
Мені здається це добре показує куди рухається конкуренція в AI. Раніше лабораторії змагалися за найкращу модель. Тепер перевагою стає весь ланцюжок: хто має compute, хто має дані реальної роботи агентів, хто контролює середовище де вони працюють, і хто може виконати задачу дешевше та за меншу кількість кроків.
І в такій системі Cursor для SpaceXAI може виявитися значно ціннішим активом ніж просто популярний редактор коду.
🔔 ПІДПИСАТИСЯ
🔥12👏4👍3
☝🏻 Одна команда від Claude майже перетворила Mac розробника на цеглину. І ця історія схоже справжня.
Доброго ленчу ☕️
4го Вересня в r/ClaudeCode з'явився показовий кейс.
Розробник працював над iOS-застосунком і хотів виставити певний час для красивого скріншота. Замість того щоб самому розбиратися попросив Claude зробити це за нього. За словами автора він використовував Claude Opus 5 High.
Claude запропонував:
Розробник просто вставив команду в Terminal. І за кілька секунд Mac завис 🤖💀
І далі почалося найцікавіше.
За словами автора Mac перестав нормально завантажуватися: логотип Apple, progress bar, чорний екран із курсором. Не допомогли Safe Mode, Recovery, fallback Recovery, bootable media, кілька спроб DFU Revive з іншого Mac. DFU при цьому завершувався помилкою 4042.
У результаті автор знайшов схожий кейс де комусь допомогло встановлення Xcode на другий Mac з якого проводився Revive.
Але тут є важливий нюанс. Не варто робити висновок що саме Xcode полагодив Mac. Сам автор цього не стверджує. Перед цим він робив ще одну невдалу DFU Restore тому точно встановити причинно-наслідковий зв'язок неможливо. Більше того в офіційній інструкції Apple для DFU Revive Xcode взагалі не є вимогою. Потрібні інший Mac, актуальна macOS, інтернет і USB-C кабель, а сам Revive запускається через Finder. Тобто маємо реальний user report але не задокументований Apple bug.
І тут є ще прекрасніша іронія 🙂
Змінювати системний час Mac узагалі не було потрібно. Apple вже багато років дозволяє окремо підміняти годинник у status bar iOS Simulator командою xcrun simctl status_bar booted override --time 12:01. Тобто можна було змінити цифри на скріншоті не торкаючись системного часу комп'ютера взагалі. Це офіційно документована можливість Xcode Simulator.
І ось саме це на мій погляд найцікавіше у всій історії.
Claude формально виконав задачу. Потрібно змінити час? Ось команда яка змінює час. Але модель не оцінила масштаб втручання. Замість локальної зміни UI Simulator вона запропонувала sudo, відключити network time, глобально змінити системний clock.
Це хороший приклад того чому AI coding agents змінюють не тільки швидкість розробки а й саму модель ризику. Раніше небезпечну команду потрібно було знайти, зрозуміти і написати самому. Тепер достатньо сказати "Claude, fix it". А далі головним security layer залишається людина яка має прочитати команду перед Enter. Особливо якщо там є sudo.
Тут для мене два практичні висновки. Перший: якщо ви даєте агентам на базі Claude чи будь-якої іншої моделі доступ до вашої системи — обмежуйте scope можливостей і не давайте sudo без потреби. Другий: якщо виконуєте команду за рекомендацією AI — переконайтесь що розумієте що саме вона робить.
Це ще одне підтвердження того що незалежно від того наскільки потужним стає AI, базове розуміння команд, алгоритмів і того як влаштована система нікуди не зникає з вимог до людини. Інакше саме ви стаєте тим слабким security layer який пропускає катастрофу далі.
AI може бути чудовим інженером але root-доступ йому краще видавати з таким самим рівнем довіри як дуже талановитому junior'у який працює о третій ночі 😄
🔔 ПІДПИСАТИСЯ
Доброго ленчу ☕️
4го Вересня в r/ClaudeCode з'явився показовий кейс.
Розробник працював над iOS-застосунком і хотів виставити певний час для красивого скріншота. Замість того щоб самому розбиратися попросив Claude зробити це за нього. За словами автора він використовував Claude Opus 5 High.
Claude запропонував:
sudo systemsetup -setusingnetworktime off && sudo date 090306494026.00Розробник просто вставив команду в Terminal. І за кілька секунд Mac завис 🤖💀
І далі почалося найцікавіше.
За словами автора Mac перестав нормально завантажуватися: логотип Apple, progress bar, чорний екран із курсором. Не допомогли Safe Mode, Recovery, fallback Recovery, bootable media, кілька спроб DFU Revive з іншого Mac. DFU при цьому завершувався помилкою 4042.
У результаті автор знайшов схожий кейс де комусь допомогло встановлення Xcode на другий Mac з якого проводився Revive.
Але тут є важливий нюанс. Не варто робити висновок що саме Xcode полагодив Mac. Сам автор цього не стверджує. Перед цим він робив ще одну невдалу DFU Restore тому точно встановити причинно-наслідковий зв'язок неможливо. Більше того в офіційній інструкції Apple для DFU Revive Xcode взагалі не є вимогою. Потрібні інший Mac, актуальна macOS, інтернет і USB-C кабель, а сам Revive запускається через Finder. Тобто маємо реальний user report але не задокументований Apple bug.
І тут є ще прекрасніша іронія 🙂
Змінювати системний час Mac узагалі не було потрібно. Apple вже багато років дозволяє окремо підміняти годинник у status bar iOS Simulator командою xcrun simctl status_bar booted override --time 12:01. Тобто можна було змінити цифри на скріншоті не торкаючись системного часу комп'ютера взагалі. Це офіційно документована можливість Xcode Simulator.
І ось саме це на мій погляд найцікавіше у всій історії.
Claude формально виконав задачу. Потрібно змінити час? Ось команда яка змінює час. Але модель не оцінила масштаб втручання. Замість локальної зміни UI Simulator вона запропонувала sudo, відключити network time, глобально змінити системний clock.
Це хороший приклад того чому AI coding agents змінюють не тільки швидкість розробки а й саму модель ризику. Раніше небезпечну команду потрібно було знайти, зрозуміти і написати самому. Тепер достатньо сказати "Claude, fix it". А далі головним security layer залишається людина яка має прочитати команду перед Enter. Особливо якщо там є sudo.
Тут для мене два практичні висновки. Перший: якщо ви даєте агентам на базі Claude чи будь-якої іншої моделі доступ до вашої системи — обмежуйте scope можливостей і не давайте sudo без потреби. Другий: якщо виконуєте команду за рекомендацією AI — переконайтесь що розумієте що саме вона робить.
Це ще одне підтвердження того що незалежно від того наскільки потужним стає AI, базове розуміння команд, алгоритмів і того як влаштована система нікуди не зникає з вимог до людини. Інакше саме ви стаєте тим слабким security layer який пропускає катастрофу далі.
AI може бути чудовим інженером але root-доступ йому краще видавати з таким самим рівнем довіри як дуже талановитому junior'у який працює о третій ночі 😄
🔔 ПІДПИСАТИСЯ
👍13❤2🔥1😁1
🔐 «Ми не тренуємося на ваших даних» і «ми взагалі не маємо ваших даних» — це дві дуже різні речі
Доброго вечора ☕️
Зараз між OpenAI та Anthropic формується доволі показова різниця саме в цьому питанні.
Для бізнесу який передає AI конфіденційні дані важливі три прості питання: де зберігаються ваші промпти та відповіді, як довго вони зберігаються, чи може провайдер AI отримати до них доступ. І тут підходи Anthropic та OpenAI починають суттєво розходитися.
Anthropic
З червня бізнес-клієнти нових моделей Anthropic мали погоджуватися на 30-денне зберігання розмов. Тобто навіть компанії які раніше мали Zero Data Retention фактично втрачали ZDR якщо хотіли використовувати нові моделі. Результат виявився передбачуваним: частина бізнес-клієнтів просто відмовилася від нових моделей. Навіть ARC Prize Foundation не захотіла запускати свої закриті benchmark-тести щоб не передавати приватні тестові питання на зберігання.
Тепер Anthropic готує систему Enterprise Frontier Safeguards. Ідея така: дані все одно потрібно буде зберігати 30 днів але вже на серверах самого клієнта або у вибраного ним cloud-провайдера, AWS, Google Cloud, Microsoft Foundry тощо. Клієнт також зможе контролювати encryption keys та audit logs. Але сама вимога зберігати дані нікуди не зникає.
OpenAI
OpenAI пішла іншим шляхом. Для схвалених бізнес-клієнтів компанія заявляє підтримку Zero Data Retention для своїх найпотужніших моделей. Тобто OpenAI стверджує що не логуватиме ані prompts ані responses. Паралельно компанія готує Private Safety Processing, систему яка має виявляти потенційні зловживання одразу в серії запитів не передаючи співробітникам сам зміст цих запитів. Детальніше про це OpenAI написала окремо.
І ось тут починається найцікавіше.
Якщо AI не бачить дані, як він їх аналізує?
Обидві компанії хочуть автоматично знаходити патерни атак у багатьох запитах. Наприклад best-of-N jailbreak: атакуючий сотні разів трохи змінює заборонений prompt поки одна з версій не пройде. Для виявлення такого патерну система має аналізувати історію запитів.
І виникає фундаментальне питання: "наші співробітники не бачать ваші дані" не дорівнює "наші системи не мають доступу до ваших даних". Як саме це буде реалізовано криптографічно й архітектурно поки що повністю не пояснила жодна з компаній. OpenAI обіцяє окремий technical paper щодо PSP.
Бізнеси вже зараз вирішують чи можна довіряти цим моделям конфіденційні дані спираючись фактично лише на пресрелізи. Для регульованих галузей, юридичних фірм, лікарень і банків, обіцянки "ми не будемо навчати моделі на ваших даних" і "у нас узагалі немає ваших даних" це зовсім різні речі.
Минулого року в межах позову The New York Times щодо авторських прав суд зобов'язав OpenAI зберігати журнали чатів які зазвичай мали бути видалені, включно з тими які самі користувачі вже стерли. OpenAI заявила що клієнтів із ZDR це не стосувалося, оскільки OpenAI взагалі не мала їхніх даних.
У 2024 році ми описали чотири рівні конфіденційності хмарного AI. Найсильніший із них, коли провайдер узагалі не може отримати доступ до ваших даних, є найважливішим для роботи з чутливою інформацією. Особливо з огляду на лазівки які дозволяють frontier-лабораторіям на власний розсуд визначати що вважати "безпечним".
Обидві компанії тепер заявляють що здатні одночасно зберегти конфіденційність користувачів і виявляти зловживання розподілені між великою кількістю запитів. Але жодна з них поки що не показала як саме це працюватиме.
🔔 ПІДПИСАТИСЯ
Доброго вечора ☕️
Зараз між OpenAI та Anthropic формується доволі показова різниця саме в цьому питанні.
Для бізнесу який передає AI конфіденційні дані важливі три прості питання: де зберігаються ваші промпти та відповіді, як довго вони зберігаються, чи може провайдер AI отримати до них доступ. І тут підходи Anthropic та OpenAI починають суттєво розходитися.
Anthropic
З червня бізнес-клієнти нових моделей Anthropic мали погоджуватися на 30-денне зберігання розмов. Тобто навіть компанії які раніше мали Zero Data Retention фактично втрачали ZDR якщо хотіли використовувати нові моделі. Результат виявився передбачуваним: частина бізнес-клієнтів просто відмовилася від нових моделей. Навіть ARC Prize Foundation не захотіла запускати свої закриті benchmark-тести щоб не передавати приватні тестові питання на зберігання.
Тепер Anthropic готує систему Enterprise Frontier Safeguards. Ідея така: дані все одно потрібно буде зберігати 30 днів але вже на серверах самого клієнта або у вибраного ним cloud-провайдера, AWS, Google Cloud, Microsoft Foundry тощо. Клієнт також зможе контролювати encryption keys та audit logs. Але сама вимога зберігати дані нікуди не зникає.
OpenAI
OpenAI пішла іншим шляхом. Для схвалених бізнес-клієнтів компанія заявляє підтримку Zero Data Retention для своїх найпотужніших моделей. Тобто OpenAI стверджує що не логуватиме ані prompts ані responses. Паралельно компанія готує Private Safety Processing, систему яка має виявляти потенційні зловживання одразу в серії запитів не передаючи співробітникам сам зміст цих запитів. Детальніше про це OpenAI написала окремо.
І ось тут починається найцікавіше.
Якщо AI не бачить дані, як він їх аналізує?
Обидві компанії хочуть автоматично знаходити патерни атак у багатьох запитах. Наприклад best-of-N jailbreak: атакуючий сотні разів трохи змінює заборонений prompt поки одна з версій не пройде. Для виявлення такого патерну система має аналізувати історію запитів.
І виникає фундаментальне питання: "наші співробітники не бачать ваші дані" не дорівнює "наші системи не мають доступу до ваших даних". Як саме це буде реалізовано криптографічно й архітектурно поки що повністю не пояснила жодна з компаній. OpenAI обіцяє окремий technical paper щодо PSP.
Бізнеси вже зараз вирішують чи можна довіряти цим моделям конфіденційні дані спираючись фактично лише на пресрелізи. Для регульованих галузей, юридичних фірм, лікарень і банків, обіцянки "ми не будемо навчати моделі на ваших даних" і "у нас узагалі немає ваших даних" це зовсім різні речі.
Минулого року в межах позову The New York Times щодо авторських прав суд зобов'язав OpenAI зберігати журнали чатів які зазвичай мали бути видалені, включно з тими які самі користувачі вже стерли. OpenAI заявила що клієнтів із ZDR це не стосувалося, оскільки OpenAI взагалі не мала їхніх даних.
У 2024 році ми описали чотири рівні конфіденційності хмарного AI. Найсильніший із них, коли провайдер узагалі не може отримати доступ до ваших даних, є найважливішим для роботи з чутливою інформацією. Особливо з огляду на лазівки які дозволяють frontier-лабораторіям на власний розсуд визначати що вважати "безпечним".
Обидві компанії тепер заявляють що здатні одночасно зберегти конфіденційність користувачів і виявляти зловживання розподілені між великою кількістю запитів. Але жодна з них поки що не показала як саме це працюватиме.
🔔 ПІДПИСАТИСЯ
👍5🔥3❤1
⚖️ Thomson Reuters запустила власну LLM. І це значно цікавіше, ніж просто ще один fine-tune
Доброго ранку ☕️
Thomson Reuters представила сімейство моделей Thomson для права, фінансів, податків, бізнесу та новин.
І тут цікавий не стільки сам факт появи domain-specific LLM, скільки те, як саме її побудували.
За основу Thomson-1.0-Large взяли Qwen3.5-397B-A17B — Mixture-of-Experts модель на 397 млрд параметрів, із яких приблизно 17 млрд активуються на кожен токен.
А далі Thomson Reuters не обмежилася LoRA або невеликим instruction fine-tuning. Компанія фактично провела повторне mid-training моделі під власний домен. Для цього разом із DatologyAI вони відібрали 200 млрд токенів із пулу в 19 трлн токенів.
Навчальний датасет приблизно порівну складався з пропрієтарних даних Thomson Reuters — судової практики, контрактів, regulatory filings, новин — synthetic data з прикладами реальних професійних задач і general-purpose даних, щоб не втратити базові можливості моделі.
Після цього модель додатково вирівнювали за допомогою DPO, а для agentic deep research використовували також GSPO, зокрема для роботи з context compaction та document caching.
На весь training pipeline Thomson Reuters, за власними даними, витратила близько $40 млн за три місяці.
І результат досить цікавий. За їхніми тестами Thomson-1.0-Large трохи випереджає GPT-5.4 та Claude Sonnet 5 за factuality і completeness у legal, tax та news задачах. На factuality для open-web контенту різниця, за їхніми вимірюваннями, сягає приблизно 15 пунктів. При цьому контекст — до 262k токенів.
Але, на мою думку, найважливіше тут навіть не benchmark.
Останні кілька років здавалося, що майбутнє виглядатиме приблизно так:
foundation model → RAG → трохи fine-tuning → готово.
Але Thomson показує інший варіант:
open-weight frontier model → великий proprietary corpus → domain mid-training → alignment → private deployment.
Тобто компанія не тренує LLM із нуля, що коштувало б сотні мільйонів доларів. Але й не обмежується поверхневим fine-tuning. Вона бере сильну базову модель і фактично продовжує її pretraining уже на власному світі даних.
І це може бути важливим трендом.
Бо в Thomson Reuters є те, чого немає у більшості AI-стартапів: десятиліттями накопичені структуровані професійні дані.
Крім того, моделі можна додатково навчати на приватних даних конкретної компанії за допомогою mid-training методів Thomson — без величезних витрат на повноцінне pretraining і без обмеженої ефективності дешевших методів fine-tuning на кшталт LoRA.
Для банків, юридичних компаній, enterprise R&D і regulated industries це може бути набагато цікавіше за класичний SaaS-доступ до зовнішньої LLM.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Thomson Reuters представила сімейство моделей Thomson для права, фінансів, податків, бізнесу та новин.
І тут цікавий не стільки сам факт появи domain-specific LLM, скільки те, як саме її побудували.
За основу Thomson-1.0-Large взяли Qwen3.5-397B-A17B — Mixture-of-Experts модель на 397 млрд параметрів, із яких приблизно 17 млрд активуються на кожен токен.
А далі Thomson Reuters не обмежилася LoRA або невеликим instruction fine-tuning. Компанія фактично провела повторне mid-training моделі під власний домен. Для цього разом із DatologyAI вони відібрали 200 млрд токенів із пулу в 19 трлн токенів.
Навчальний датасет приблизно порівну складався з пропрієтарних даних Thomson Reuters — судової практики, контрактів, regulatory filings, новин — synthetic data з прикладами реальних професійних задач і general-purpose даних, щоб не втратити базові можливості моделі.
Після цього модель додатково вирівнювали за допомогою DPO, а для agentic deep research використовували також GSPO, зокрема для роботи з context compaction та document caching.
На весь training pipeline Thomson Reuters, за власними даними, витратила близько $40 млн за три місяці.
І результат досить цікавий. За їхніми тестами Thomson-1.0-Large трохи випереджає GPT-5.4 та Claude Sonnet 5 за factuality і completeness у legal, tax та news задачах. На factuality для open-web контенту різниця, за їхніми вимірюваннями, сягає приблизно 15 пунктів. При цьому контекст — до 262k токенів.
Але, на мою думку, найважливіше тут навіть не benchmark.
Останні кілька років здавалося, що майбутнє виглядатиме приблизно так:
foundation model → RAG → трохи fine-tuning → готово.
Але Thomson показує інший варіант:
open-weight frontier model → великий proprietary corpus → domain mid-training → alignment → private deployment.
Тобто компанія не тренує LLM із нуля, що коштувало б сотні мільйонів доларів. Але й не обмежується поверхневим fine-tuning. Вона бере сильну базову модель і фактично продовжує її pretraining уже на власному світі даних.
І це може бути важливим трендом.
Бо в Thomson Reuters є те, чого немає у більшості AI-стартапів: десятиліттями накопичені структуровані професійні дані.
Крім того, моделі можна додатково навчати на приватних даних конкретної компанії за допомогою mid-training методів Thomson — без величезних витрат на повноцінне pretraining і без обмеженої ефективності дешевших методів fine-tuning на кшталт LoRA.
Для банків, юридичних компаній, enterprise R&D і regulated industries це може бути набагато цікавіше за класичний SaaS-доступ до зовнішньої LLM.
🔔 ПІДПИСАТИСЯ
🔥6❤🔥3👍3❤1
«Люди які створюють AI справді вважають що він може знищити людство»
Доброго ранку ☕️ Гарних вихідних 👋
Вже про Astra поговоримо в понеділок, а сьогодні трохи «розважального» контенту 🙂
Кілька днів тому дослідник Джейкоб Коксон звільнився з Anthropic і опублікував тред який за добу набрав понад 100 мільйонів переглядів.
Три роки він займався дослідженнями попереднього навчання моделей спочатку в OpenAI а потім в Anthropic. І написав: "Жодна з компаній не діє відповідально. Вони мчать прямо до штучного інтелекту здатного самовдосконалюватися, ставлячи на кін наші життя".
Звучить як черговий панічний пост. Але далі стало цікавіше.
Керівник напряму безпеки в Anthropic Еван Хубінгер публічно відповів Коксону: "Джейкоб має рацію, ми справді щиро вважаємо що AI може вбити всіх людей. Особисто я оцінюю це у понад 10% імовірності протягом наступних десяти років". І визнав: Anthropic поки не має готового плану вирішити цю проблему.
Його підтримав ще один дослідник компанії Семюел Маркс. За його словами побоювання серйозних сценаріїв усередині індустрії цілком реальні, причому досвідчені дослідники хвилюються сильніше ніж молодші.
А тепер найцікавіше. За два дні до цього треду головний науковець OpenAI Якуб Пахоцький опублікував текст "An Alien Mind". І там фактично підтверджується та сама проблема. Пахоцький пише що за внутрішніми результатами компанії прогрес може продовжитися аж до моменту коли AI сам активно братиме участь у створенні наступних сильніших систем. І прямо заявляє: "Наразі жодна лабораторія не вирішила питання безпеки настільки добре щоб довго відповідально масштабуватися на максимальній швидкості".
Це вже не колишній співробітник який грюкнув дверима. Це головний науковець OpenAI.
А що думають засновники сучасного AI? Джеффрі Хінтон сказав BBC що оцінка у 10% не здається йому нерозумною хоча ніхто насправді не знає як коректно порахувати таку ймовірність. Йошуа Бенджіо попереджає про небезпечну комбінацію: високий інтелект плюс автономність плюс довгострокові цілі плюс доступ до реального світу.
Консенсусу тут немає взагалі. Andrew Ng колись писав в LinkedIn: "Чесно кажучи я не розумію звідки береться цей ризик".
А CEO Nvidia Дженсен Хуанг заявив Axios ще жорсткіше: "Ідея що це стане кінцем людства це повна нісенітниця".
А ви що з цього приводу думаєте, поділіться в коментарях 👇
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️ Гарних вихідних 👋
Вже про Astra поговоримо в понеділок, а сьогодні трохи «розважального» контенту 🙂
Кілька днів тому дослідник Джейкоб Коксон звільнився з Anthropic і опублікував тред який за добу набрав понад 100 мільйонів переглядів.
Три роки він займався дослідженнями попереднього навчання моделей спочатку в OpenAI а потім в Anthropic. І написав: "Жодна з компаній не діє відповідально. Вони мчать прямо до штучного інтелекту здатного самовдосконалюватися, ставлячи на кін наші життя".
Звучить як черговий панічний пост. Але далі стало цікавіше.
Керівник напряму безпеки в Anthropic Еван Хубінгер публічно відповів Коксону: "Джейкоб має рацію, ми справді щиро вважаємо що AI може вбити всіх людей. Особисто я оцінюю це у понад 10% імовірності протягом наступних десяти років". І визнав: Anthropic поки не має готового плану вирішити цю проблему.
Його підтримав ще один дослідник компанії Семюел Маркс. За його словами побоювання серйозних сценаріїв усередині індустрії цілком реальні, причому досвідчені дослідники хвилюються сильніше ніж молодші.
А тепер найцікавіше. За два дні до цього треду головний науковець OpenAI Якуб Пахоцький опублікував текст "An Alien Mind". І там фактично підтверджується та сама проблема. Пахоцький пише що за внутрішніми результатами компанії прогрес може продовжитися аж до моменту коли AI сам активно братиме участь у створенні наступних сильніших систем. І прямо заявляє: "Наразі жодна лабораторія не вирішила питання безпеки настільки добре щоб довго відповідально масштабуватися на максимальній швидкості".
Це вже не колишній співробітник який грюкнув дверима. Це головний науковець OpenAI.
А що думають засновники сучасного AI? Джеффрі Хінтон сказав BBC що оцінка у 10% не здається йому нерозумною хоча ніхто насправді не знає як коректно порахувати таку ймовірність. Йошуа Бенджіо попереджає про небезпечну комбінацію: високий інтелект плюс автономність плюс довгострокові цілі плюс доступ до реального світу.
Консенсусу тут немає взагалі. Andrew Ng колись писав в LinkedIn: "Чесно кажучи я не розумію звідки береться цей ризик".
А CEO Nvidia Дженсен Хуанг заявив Axios ще жорсткіше: "Ідея що це стане кінцем людства це повна нісенітниця".
А ви що з цього приводу думаєте, поділіться в коментарях 👇
🔔 ПІДПИСАТИСЯ
👍6❤3🤔3😁1
Піар чи щирий страх? Продовження вчорашньої історії
Доброго ранку ☕️
Вчора розповідав про тред Джейкоба Коксона, відповідь Евана Хубінгера з Anthropic та текст головного науковця OpenAI Пахоцького де серйозні люди відкрито говорять про ризик знищення людства через AI. Сьогодні хочу розібрати питання яке напрошується саме тут: це щире занепокоєння чи частина піар-гри?
Мені здається що це хибний вибір. Швидше і те й інше одночасно, не одне замість іншого.
Аргументи на користь щирості. Хубінгер і Маркс це дослідники чия вся кар'єра побудована на безпеці AI а не на маркетингу. Коксон буквально кинув роботу і пішов з індустрії, а це дуже дорогий сигнал який складно симулювати заради піару. Хінтон пішов з Google саме через ці побоювання, йому вже нічого доводити. І всередині самого табору немає єдиної відполірованої позиції: Хубінгер прямо каже що ризик від нинішніх моделей низький, турбує його саме майбутнє самовдосконалення систем. Справжній піар зазвичай виглядає більш скоординовано.
Але є й структурна вигода. Сама ідея "ми будуємо щось настільки потужне що може вбити всіх" це водночас і попередження і грандіозна реклама можливостей продукту. І в аргументі Ендрю Ина, якого я згадував вчора, є сенс: наратив про загибель людства історично використовується як інструмент для обмеження конкуренції. Якщо переконати державу що технологія надзвичайно небезпечна — великі лабораторії з ресурсами на дотримання регуляцій виграють, а стартапи і відкриті проєкти вимирають. Це не означає що Хубінгер особисто цинічно рахує ризики. Але система стимулів навколо нього об'єктивно винагороджує саме таку позицію.
Мій особистий висновок: люди які прямо про це говорять, Хубінгер, Коксон, Пахоцький, скоріше за все щирі у своїй професійній оцінці, це їхня реальна робота і вони роками цим займаються. Але як ця щира тривога потім використовується на рівні індустріальної політики і регулювання це вже окреме питання де інтереси компаній і щирі побоювання дослідників не завжди збігаються.
І найдивніша частина цієї історії мабуть саме така: люди які створюють найпотужніші AI-системи у світі відкрито визнають що ще не знають як гарантовано контролювати системи наступного рівня. Але продовжують їх будувати.
А що думаєте ви? Це реальна загроза яку варто сприймати серйозно, чи чергова спроба виправдати обмеження ринку через страх? Пишіть у коментарях 👇
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Вчора розповідав про тред Джейкоба Коксона, відповідь Евана Хубінгера з Anthropic та текст головного науковця OpenAI Пахоцького де серйозні люди відкрито говорять про ризик знищення людства через AI. Сьогодні хочу розібрати питання яке напрошується саме тут: це щире занепокоєння чи частина піар-гри?
Мені здається що це хибний вибір. Швидше і те й інше одночасно, не одне замість іншого.
Аргументи на користь щирості. Хубінгер і Маркс це дослідники чия вся кар'єра побудована на безпеці AI а не на маркетингу. Коксон буквально кинув роботу і пішов з індустрії, а це дуже дорогий сигнал який складно симулювати заради піару. Хінтон пішов з Google саме через ці побоювання, йому вже нічого доводити. І всередині самого табору немає єдиної відполірованої позиції: Хубінгер прямо каже що ризик від нинішніх моделей низький, турбує його саме майбутнє самовдосконалення систем. Справжній піар зазвичай виглядає більш скоординовано.
Але є й структурна вигода. Сама ідея "ми будуємо щось настільки потужне що може вбити всіх" це водночас і попередження і грандіозна реклама можливостей продукту. І в аргументі Ендрю Ина, якого я згадував вчора, є сенс: наратив про загибель людства історично використовується як інструмент для обмеження конкуренції. Якщо переконати державу що технологія надзвичайно небезпечна — великі лабораторії з ресурсами на дотримання регуляцій виграють, а стартапи і відкриті проєкти вимирають. Це не означає що Хубінгер особисто цинічно рахує ризики. Але система стимулів навколо нього об'єктивно винагороджує саме таку позицію.
Мій особистий висновок: люди які прямо про це говорять, Хубінгер, Коксон, Пахоцький, скоріше за все щирі у своїй професійній оцінці, це їхня реальна робота і вони роками цим займаються. Але як ця щира тривога потім використовується на рівні індустріальної політики і регулювання це вже окреме питання де інтереси компаній і щирі побоювання дослідників не завжди збігаються.
І найдивніша частина цієї історії мабуть саме така: люди які створюють найпотужніші AI-системи у світі відкрито визнають що ще не знають як гарантовано контролювати системи наступного рівня. Але продовжують їх будувати.
А що думаєте ви? Це реальна загроза яку варто сприймати серйозно, чи чергова спроба виправдати обмеження ринку через страх? Пишіть у коментарях 👇
🔔 ПІДПИСАТИСЯ
👍7🤔3❤1👏1
GPT-6 Per aspera ad astra - справжня зірка 💫
Доброго ранку ☕️
Схоже що рахувати ціну токенів скоро стане майже безглуздо.
OpenAI випустила GPT-6 Astra, нову флагманську модель. І цього разу найцікавіше те якою ціною вона опинилася на вершині більшості тестів.
Astra має контекст до 1.05 млн токенів, вихід до 128 тисяч, п'ять рівнів глибини міркування і проєктується вже не як чатбот а як модель для довгих агентних задач: працює з браузером, комп'ютером, кодом, файлами, викликає інструменти асинхронно.
Є дві важливі технічні риси. Перша: модель може зберігати внутрішній стан міркування між окремими викликами API. Друга: довгий контекст можна стискати, залишаючи тільки потрібне для подальшої роботи, а в Codex Astra може сама вести нотатки про свою роботу і потім шукати по них.
І це вже видно в результатах. На ARC-AGI-3, інтерактивних задачах де модель має сама зрозуміти правила невідомого середовища, Astra у стандартному режимі отримала 62.7%. Попередній найкращий результат Claude Opus 5 був 30.2%. Але коли ARC Prize дозволили моделі використовувати саме її нативні механізми, збереження стану між запитами і стиснення контексту, результат зріс до 99.9%.
Тут важливо не перебільшувати: це не означає що AGI досягнуто. Сам ARC Prize прямо каже що середовища закриті й наперед визначені. Але є деталь не менш цікава за сам результат: на 96% рівнів Astra зробила менше дій ніж медіанний учасник людина, у середньому на 51.7% менше кроків. Тобто модель не просто довше думала і перебирала більше варіантів. Вона навчилася швидше будувати уявлення про нове середовище і діяти ефективніше.
На інших незалежних тестах картина схожа. У Intelligence Index від Artificial Analysis Astra ділить вершину з Claude Fable 5.1. У рейтингу веброзробки Arena вона перша.
Але тут найважливіша частина цієї історії.
API коштує 10 доларів за мільйон вхідних токенів і 50 доларів за мільйон вихідних. Це приблизно у 2.5 раза дорожче ніж GPT-5.6 Sol за токен. Здавалося б дорога модель. Але на тестах написання коду вона виконувала завдання за ту саму загальну вартість що й Sol, бо використовувала приблизно втричі менше токенів. На ARC-AGI-3 ситуація взагалі парадоксальна: вищий рівень міркування іноді коштував дешевше за нижчий, бо модель швидше знаходила правильну стратегію і робила менше дій.
Раніше ми порівнювали моделі просто за ціною токена. Потім почали додавати рівень міркування. Але й цього вже недостатньо. Для реальних агентних систем набагато важливішими стають вартість розв'язаної задачі, час до результату і кількість дій потрібних для нього. Модель може коштувати у кілька разів дорожче за токен і при цьому бути дешевшою в експлуатації якщо їй не потрібно двадцять разів ходити по колу.
Є у Astra й інша, менш комфортна сторона. OpenAI вперше класифікувала свою модель як критичну за кіберможливостями. У тестах без виробничих обмежень вона знаходила невідомі вразливості і будувала повні ланцюжки атак. Тому релізна версія відмовляється виконувати частину складних наступальних задач з кібербезпеки, а розширений доступ залишається лише для перевірених спеціалістів.
Це показує наскільки змінилася сама проблема безпеки AI. Модель яка керує комп'ютером, запускає код і використовує десятки інструментів протягом довгої сесії, може зробити дію. Тому OpenAI тепер відстежує не тільки результат а й весь хід міркувань і дій агента, і може зупинити виконання просто посеред роботи.
За словами OpenAI, Astra стала найбільшим навчальним запуском компанії, понад 100 000 GPU.
Але головний висновок релізу не в масштабі тренування і навіть не в черговому першому місці. Ми все менше купуємо токени й усе більше купуємо виконану роботу. Якщо агент за вищою ціною здатний розв'язати задачу за три кроки, а дешевший агент ходить по колу двадцять разів, дешевша модель раптом перестає бути дешевшою.
Для розробників це означає просту річ: свої AI-системи вже варто оцінювати не тільки за якістю відповіді та ціною токена. Треба рахувати вартість завершеної задачі. Схоже саме ця метрика стане однією з головних у наступному поколінні AI-продуктів.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Схоже що рахувати ціну токенів скоро стане майже безглуздо.
OpenAI випустила GPT-6 Astra, нову флагманську модель. І цього разу найцікавіше те якою ціною вона опинилася на вершині більшості тестів.
Astra має контекст до 1.05 млн токенів, вихід до 128 тисяч, п'ять рівнів глибини міркування і проєктується вже не як чатбот а як модель для довгих агентних задач: працює з браузером, комп'ютером, кодом, файлами, викликає інструменти асинхронно.
Є дві важливі технічні риси. Перша: модель може зберігати внутрішній стан міркування між окремими викликами API. Друга: довгий контекст можна стискати, залишаючи тільки потрібне для подальшої роботи, а в Codex Astra може сама вести нотатки про свою роботу і потім шукати по них.
І це вже видно в результатах. На ARC-AGI-3, інтерактивних задачах де модель має сама зрозуміти правила невідомого середовища, Astra у стандартному режимі отримала 62.7%. Попередній найкращий результат Claude Opus 5 був 30.2%. Але коли ARC Prize дозволили моделі використовувати саме її нативні механізми, збереження стану між запитами і стиснення контексту, результат зріс до 99.9%.
Тут важливо не перебільшувати: це не означає що AGI досягнуто. Сам ARC Prize прямо каже що середовища закриті й наперед визначені. Але є деталь не менш цікава за сам результат: на 96% рівнів Astra зробила менше дій ніж медіанний учасник людина, у середньому на 51.7% менше кроків. Тобто модель не просто довше думала і перебирала більше варіантів. Вона навчилася швидше будувати уявлення про нове середовище і діяти ефективніше.
На інших незалежних тестах картина схожа. У Intelligence Index від Artificial Analysis Astra ділить вершину з Claude Fable 5.1. У рейтингу веброзробки Arena вона перша.
Але тут найважливіша частина цієї історії.
API коштує 10 доларів за мільйон вхідних токенів і 50 доларів за мільйон вихідних. Це приблизно у 2.5 раза дорожче ніж GPT-5.6 Sol за токен. Здавалося б дорога модель. Але на тестах написання коду вона виконувала завдання за ту саму загальну вартість що й Sol, бо використовувала приблизно втричі менше токенів. На ARC-AGI-3 ситуація взагалі парадоксальна: вищий рівень міркування іноді коштував дешевше за нижчий, бо модель швидше знаходила правильну стратегію і робила менше дій.
Раніше ми порівнювали моделі просто за ціною токена. Потім почали додавати рівень міркування. Але й цього вже недостатньо. Для реальних агентних систем набагато важливішими стають вартість розв'язаної задачі, час до результату і кількість дій потрібних для нього. Модель може коштувати у кілька разів дорожче за токен і при цьому бути дешевшою в експлуатації якщо їй не потрібно двадцять разів ходити по колу.
Є у Astra й інша, менш комфортна сторона. OpenAI вперше класифікувала свою модель як критичну за кіберможливостями. У тестах без виробничих обмежень вона знаходила невідомі вразливості і будувала повні ланцюжки атак. Тому релізна версія відмовляється виконувати частину складних наступальних задач з кібербезпеки, а розширений доступ залишається лише для перевірених спеціалістів.
Це показує наскільки змінилася сама проблема безпеки AI. Модель яка керує комп'ютером, запускає код і використовує десятки інструментів протягом довгої сесії, може зробити дію. Тому OpenAI тепер відстежує не тільки результат а й весь хід міркувань і дій агента, і може зупинити виконання просто посеред роботи.
За словами OpenAI, Astra стала найбільшим навчальним запуском компанії, понад 100 000 GPU.
Але головний висновок релізу не в масштабі тренування і навіть не в черговому першому місці. Ми все менше купуємо токени й усе більше купуємо виконану роботу. Якщо агент за вищою ціною здатний розв'язати задачу за три кроки, а дешевший агент ходить по колу двадцять разів, дешевша модель раптом перестає бути дешевшою.
Для розробників це означає просту річ: свої AI-системи вже варто оцінювати не тільки за якістю відповіді та ціною токена. Треба рахувати вартість завершеної задачі. Схоже саме ця метрика стане однією з головних у наступному поколінні AI-продуктів.
🔔 ПІДПИСАТИСЯ
👍13👀2❤1🔥1
Друзі, заглючив бот якій мав відправити підготовлений пост 😁🤦🏻♂️🙈
Алеж чому на такому, більше коментарів ніж на нормальних постах? 🙈🤣
Алеж чому на такому, більше коментарів ніж на нормальних постах? 🙈🤣
🤣12
Claude Fable 5.1 поки що №1. Але саме "поки що" тут найцікавіше 🤔
Доброго ранку ☕️
Вчора писав про GPT-6 Astra але формально корона все ще не зовсім у OpenAI. Claude Fable 5.1 від Anthropic поки залишається одним із найсильніших агентних AI у світі. Причому ситуація зараз дуже показова.
На Artificial Analysis Fable отримала ті самі 53 бали що й Astra але за $7.63 і 12.2 хвилини на задачу, тоді як Astra впоралася за $3.26 і 8.2 хвилини. Однаковий загальний результат але Astra приблизно вдвічі дешевша й помітно швидша. На Vals ситуація ще показовіша: Fable справді перша з 68.83% але в середньому витрачає 76 хвилин на задачу, тоді як Astra з 66.61% витрачає лише 25 хвилин.
Фактично ми вже говоримо не про питання "яка модель найрозумніша" а про "яку модель вигідніше найняти на конкретну роботу".
І тут Fable має чітку спеціалізацію. Її сильна сторона це довгі автономні задачі де модель годинами працює з інструментами, великою кількістю документів і складним контекстом. Тобто Anthropic явно оптимізує Claude вже не під формат де моделi можна віддати роботу. Технічно це теж видно: контекст до 1 млн токенів, вихід до 128 тисяч, режим міркування завжди увімкнений, п'ять рівнів глибини які можна змінювати прямо посеред діалогу, кешування запитів, виклик інструментів з читабельними оновленнями прогресу.
Є цікава деталь із внутрішнім міркуванням моделі. Fable 5.1 може читати внутрішні нотатки старіших версій Claude. А старі версії прочитати нотатки Fable 5.1 вже не можуть. Anthropic також змінила поведінку редагування історії: якщо змінити попереднє повідомлення, попередні нотатки моделі стають недійсними. Причина цікава: таким способом закрили один із відомих методів який дозволяв витягувати внутрішні міркування моделі.
Але найбільше Anthropic змінила систему захисту. Фактично існують дві версії однієї моделі. Claude Fable 5.1 доступна всім. Claude Mythos 5.1, ті самі базові можливості але інша конфігурація захисту, доступна лише відібраним американським організаціям у сфері кібербезпеки та наук про життя через Project Glasswing.
Для кібербезпеки Anthropic використовує цікавий механізм. Система дивиться не тільки на текст який генерує Claude а спеціальний детектор аналізує внутрішні активації моделі. Якщо він бачить потенційно небезпечну задачу з кібербезпеки запит передається окремій моделі-класифікатору. Тобто безпека поступово рухається від "перевіримо що модель написала" до "спробуємо зрозуміти що модель збирається робити".
При цьому Anthropic трохи послабила обмеження. Fable 5.1 тепер може виконувати чисто захисну роботу з кібербезпеки, наприклад шукати вразливості у вихідному коді. Але тестування на проникнення, написання експлойтів або пошук вразливостей у скомпільованих файлах усе ще можуть призвести до перемикання на більш обмежені моделі. За оцінкою самої Anthropic у Claude Code це має означати приблизно на 60% менше втручань системи безпеки за сесію.
Є щоправда не дуже приємна деталь. Anthropic назвала три основні проблеми які Fable 5.1 мала виправити: високу вартість виконання задач, політики зберігання даних які не подобалися бізнес-клієнтам, і надто жорсткі обмеження. Незалежні тести показують що по-справжньому виправити вдалося лише останню проблему.
І ось тут повертаємося до Astra. Схоже OpenAI та Anthropic зараз оптимізують моделі трохи в різних напрямках. Fable 5.1 дуже сильна у довгій автономній роботі зі знаннями. GPT-6 Astra сильніша у роботі з комп'ютером, термінальних задачах, загальних тестах на знання і значно агресивніше оптимізована за часом та кількістю дій.
Мені здається це дуже добре показує стан frontier AI у 2026 році. Питання "яка модель найкраща" стає майже неправильним. Правильніше питати: яка модель найкраще виконує саме мою роботу, скільки часу їй для цього потрібно і скільки коштує завершена задача.
А перше місце в загальному рейтингу тепер має приблизно такий самий термін придатності як молоко. Іноді менше тижня.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Вчора писав про GPT-6 Astra але формально корона все ще не зовсім у OpenAI. Claude Fable 5.1 від Anthropic поки залишається одним із найсильніших агентних AI у світі. Причому ситуація зараз дуже показова.
На Artificial Analysis Fable отримала ті самі 53 бали що й Astra але за $7.63 і 12.2 хвилини на задачу, тоді як Astra впоралася за $3.26 і 8.2 хвилини. Однаковий загальний результат але Astra приблизно вдвічі дешевша й помітно швидша. На Vals ситуація ще показовіша: Fable справді перша з 68.83% але в середньому витрачає 76 хвилин на задачу, тоді як Astra з 66.61% витрачає лише 25 хвилин.
Фактично ми вже говоримо не про питання "яка модель найрозумніша" а про "яку модель вигідніше найняти на конкретну роботу".
І тут Fable має чітку спеціалізацію. Її сильна сторона це довгі автономні задачі де модель годинами працює з інструментами, великою кількістю документів і складним контекстом. Тобто Anthropic явно оптимізує Claude вже не під формат де моделi можна віддати роботу. Технічно це теж видно: контекст до 1 млн токенів, вихід до 128 тисяч, режим міркування завжди увімкнений, п'ять рівнів глибини які можна змінювати прямо посеред діалогу, кешування запитів, виклик інструментів з читабельними оновленнями прогресу.
Є цікава деталь із внутрішнім міркуванням моделі. Fable 5.1 може читати внутрішні нотатки старіших версій Claude. А старі версії прочитати нотатки Fable 5.1 вже не можуть. Anthropic також змінила поведінку редагування історії: якщо змінити попереднє повідомлення, попередні нотатки моделі стають недійсними. Причина цікава: таким способом закрили один із відомих методів який дозволяв витягувати внутрішні міркування моделі.
Але найбільше Anthropic змінила систему захисту. Фактично існують дві версії однієї моделі. Claude Fable 5.1 доступна всім. Claude Mythos 5.1, ті самі базові можливості але інша конфігурація захисту, доступна лише відібраним американським організаціям у сфері кібербезпеки та наук про життя через Project Glasswing.
Для кібербезпеки Anthropic використовує цікавий механізм. Система дивиться не тільки на текст який генерує Claude а спеціальний детектор аналізує внутрішні активації моделі. Якщо він бачить потенційно небезпечну задачу з кібербезпеки запит передається окремій моделі-класифікатору. Тобто безпека поступово рухається від "перевіримо що модель написала" до "спробуємо зрозуміти що модель збирається робити".
При цьому Anthropic трохи послабила обмеження. Fable 5.1 тепер може виконувати чисто захисну роботу з кібербезпеки, наприклад шукати вразливості у вихідному коді. Але тестування на проникнення, написання експлойтів або пошук вразливостей у скомпільованих файлах усе ще можуть призвести до перемикання на більш обмежені моделі. За оцінкою самої Anthropic у Claude Code це має означати приблизно на 60% менше втручань системи безпеки за сесію.
Є щоправда не дуже приємна деталь. Anthropic назвала три основні проблеми які Fable 5.1 мала виправити: високу вартість виконання задач, політики зберігання даних які не подобалися бізнес-клієнтам, і надто жорсткі обмеження. Незалежні тести показують що по-справжньому виправити вдалося лише останню проблему.
І ось тут повертаємося до Astra. Схоже OpenAI та Anthropic зараз оптимізують моделі трохи в різних напрямках. Fable 5.1 дуже сильна у довгій автономній роботі зі знаннями. GPT-6 Astra сильніша у роботі з комп'ютером, термінальних задачах, загальних тестах на знання і значно агресивніше оптимізована за часом та кількістю дій.
Мені здається це дуже добре показує стан frontier AI у 2026 році. Питання "яка модель найкраща" стає майже неправильним. Правильніше питати: яка модель найкраще виконує саме мою роботу, скільки часу їй для цього потрібно і скільки коштує завершена задача.
А перше місце в загальному рейтингу тепер має приблизно такий самий термін придатності як молоко. Іноді менше тижня.
🔔 ПІДПИСАТИСЯ
👍6❤4💯1
🎙 Нова битва Big Tech, за те хто краще нас чує
Доброго ранку ☕️
Поки більшість уваги прикута до нових LLM майже непомітно розгорнулася ще одна цікава гонка, розпізнавання мовлення. За останні кілька тижнів Google, Meta та Microsoft практично одночасно представили нові моделі транскрипції.
Gemini 3.5 Transcribe, Meta Muse Voice Transcribe і MAI-Transcribe-2 від Microsoft. Усі три вже мають частку помилок нижче 4% за тестами Artificial Analysis.
Для запису який не потребує обробки в реальному часі Gemini 3.5 Transcribe показує близько 2.6% помилок, MAI-Transcribe-2 близько 2%. У режимі реального часу Meta показує близько 3.1%, Gemini Live близько 4%. Тобто ми поступово наближаємося до ситуації коли сама транскрипція перестає бути головним вузьким місцем голосового інтерфейсу.
Але цікаві тут не тільки цифри.
Meta спробувала по-іншому вирішити класичний конфлікт між швидкістю та точністю. Muse Voice Transcribe розбиває аудіо на шматочки приблизно по 80 мілісекунд. Після кожного такого фрагмента модель може або видати текстовий токен, або фактично сказати сама собі: ще зарано, послухаю далі. Для простих слів вона відповідає майже одразу. Для неоднозначних чекає додаткового контексту.
Meta називає це адаптивною затримкою. Причому модель спеціально тренували шукати цей баланс: вона отримує винагороду за правильну транскрипцію але штраф за надто довге очікування. По суті це вже не просто система яка намагається якомога швидше перетворити звук у текст, а система яка сама вирішує скільки контексту їй потрібно почути перед відповіддю.
Плюс сучасні моделі вже давно вийшли за межі простого перетворення звуку в текст. Muse одночасно розпізнає мову, розрізняє мовців і визначає коли людина закінчила репліку. Meta заявляє підтримку понад 20 спікерів та навчання на 70+ мовах. Gemini 3.5 Transcribe підтримує понад 85 мов, розрізнення мовців, мітки часу на рівні слів та власний словник. MAI-Transcribe-2 понад 60 мов і теж мітки часу на рівні слів. Microsoft заявляє що годину аудіо модель може обробити приблизно за 10 секунд.
А тепер ще цікавіше, ціна. Meta близько $0.18 за годину аудіо. Microsoft $0.10 за годину до кінця 2026 року. Google приблизно $0.30 за годину для записаного аудіо та $0.54 за годину для реального часу. Це вже дуже недорога інфраструктурна технологія.
І саме тому ця гонка важливіша ніж може здатися.
Сучасний голосовий агент у найпростішому випадку це: мовлення → текст → LLM → синтез мовлення → звук. Щоб розмова з AI перестала відчуватися як розмова з автовідповідачем недостатньо мати хорошу мовну модель. Система повинна швидко зрозуміти що ви сказали, визначити хто говорить, зрозуміти коли ви закінчили думку, передати це моделі і майже без паузи почати відповідати. І кожні зайві 300-500 мілісекунд тут відчуваються значно сильніше ніж ще кілька відсотків у черговому тесті LLM.
Розпізнавання мовлення критично важливе саме для voice-агентів. При цьому голос особливо вимоглива модальність: будь-яка помилка одразу помітна користувачу в реальному часі й може спричинити додаткові помилки на наступних етапах обробки. Тут також надзвичайно важлива вартість, бо в багатьох сценаріях навчені оператори-люди все ще можуть конкурувати з AI за ціною.
Тому компанії які намагаються створювати агентів здатних розмовляти з людьми в реальному часі змагаються одразу за кількома напрямами: точність транскрипції, затримка, стійкість до складних умов реального мовлення і вартість. Переможці можуть отримати значну винагороду, індустрія голосових агентів уже величезна, а голосове введення потенційно корисне практично для будь-якого застосунку.
Тому Google, Meta, Microsoft, OpenAI, xAI та NVIDIA зараз фактично ведуть ще одну гонку, за інтерфейс через який ми будемо спілкуватися з AI.
Можливо наступна велика зміна в досвіді користування AI відбудеться не через ще розумнішу текстову модель. А через момент коли говорити з комп'ютером стане так само природно як з людиною.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Поки більшість уваги прикута до нових LLM майже непомітно розгорнулася ще одна цікава гонка, розпізнавання мовлення. За останні кілька тижнів Google, Meta та Microsoft практично одночасно представили нові моделі транскрипції.
Gemini 3.5 Transcribe, Meta Muse Voice Transcribe і MAI-Transcribe-2 від Microsoft. Усі три вже мають частку помилок нижче 4% за тестами Artificial Analysis.
Для запису який не потребує обробки в реальному часі Gemini 3.5 Transcribe показує близько 2.6% помилок, MAI-Transcribe-2 близько 2%. У режимі реального часу Meta показує близько 3.1%, Gemini Live близько 4%. Тобто ми поступово наближаємося до ситуації коли сама транскрипція перестає бути головним вузьким місцем голосового інтерфейсу.
Але цікаві тут не тільки цифри.
Meta спробувала по-іншому вирішити класичний конфлікт між швидкістю та точністю. Muse Voice Transcribe розбиває аудіо на шматочки приблизно по 80 мілісекунд. Після кожного такого фрагмента модель може або видати текстовий токен, або фактично сказати сама собі: ще зарано, послухаю далі. Для простих слів вона відповідає майже одразу. Для неоднозначних чекає додаткового контексту.
Meta називає це адаптивною затримкою. Причому модель спеціально тренували шукати цей баланс: вона отримує винагороду за правильну транскрипцію але штраф за надто довге очікування. По суті це вже не просто система яка намагається якомога швидше перетворити звук у текст, а система яка сама вирішує скільки контексту їй потрібно почути перед відповіддю.
Плюс сучасні моделі вже давно вийшли за межі простого перетворення звуку в текст. Muse одночасно розпізнає мову, розрізняє мовців і визначає коли людина закінчила репліку. Meta заявляє підтримку понад 20 спікерів та навчання на 70+ мовах. Gemini 3.5 Transcribe підтримує понад 85 мов, розрізнення мовців, мітки часу на рівні слів та власний словник. MAI-Transcribe-2 понад 60 мов і теж мітки часу на рівні слів. Microsoft заявляє що годину аудіо модель може обробити приблизно за 10 секунд.
А тепер ще цікавіше, ціна. Meta близько $0.18 за годину аудіо. Microsoft $0.10 за годину до кінця 2026 року. Google приблизно $0.30 за годину для записаного аудіо та $0.54 за годину для реального часу. Це вже дуже недорога інфраструктурна технологія.
І саме тому ця гонка важливіша ніж може здатися.
Сучасний голосовий агент у найпростішому випадку це: мовлення → текст → LLM → синтез мовлення → звук. Щоб розмова з AI перестала відчуватися як розмова з автовідповідачем недостатньо мати хорошу мовну модель. Система повинна швидко зрозуміти що ви сказали, визначити хто говорить, зрозуміти коли ви закінчили думку, передати це моделі і майже без паузи почати відповідати. І кожні зайві 300-500 мілісекунд тут відчуваються значно сильніше ніж ще кілька відсотків у черговому тесті LLM.
Розпізнавання мовлення критично важливе саме для voice-агентів. При цьому голос особливо вимоглива модальність: будь-яка помилка одразу помітна користувачу в реальному часі й може спричинити додаткові помилки на наступних етапах обробки. Тут також надзвичайно важлива вартість, бо в багатьох сценаріях навчені оператори-люди все ще можуть конкурувати з AI за ціною.
Тому компанії які намагаються створювати агентів здатних розмовляти з людьми в реальному часі змагаються одразу за кількома напрямами: точність транскрипції, затримка, стійкість до складних умов реального мовлення і вартість. Переможці можуть отримати значну винагороду, індустрія голосових агентів уже величезна, а голосове введення потенційно корисне практично для будь-якого застосунку.
Тому Google, Meta, Microsoft, OpenAI, xAI та NVIDIA зараз фактично ведуть ще одну гонку, за інтерфейс через який ми будемо спілкуватися з AI.
Можливо наступна велика зміна в досвіді користування AI відбудеться не через ще розумнішу текстову модель. А через момент коли говорити з комп'ютером стане так само природно як з людиною.
🔔 ПІДПИСАТИСЯ
👍6❤1🔥1
🧠 AI-агентам навчилися стискати пам'ять у правильний момент
Доброго ранку ☕️
Ми звикли думати про контекстне вікно досить просто: чим більше токенів поміщається тим краще. Але з AI-агентами все трохи складніше.
Агент може годинами шукати інформацію, викликати інструменти, будувати проміжні гіпотези, відкидати їх, повертатися назад, і весь цей слід міркувань поступово накопичується в контексті. У якийсь момент там уже багато інформації яка більше не потрібна.
Тому контекст починають стискати. Наприклад 50 000 токенів історії перетворюють у короткий підсумок на 2 000 токенів і агент продовжує працювати. Звучить логічно. Але виникає інша проблема: коли саме це робити?
Якщо зробити підсумок надто пізно контекст уже переповнений старою інформацією. Якщо надто рано можна випадково викинути проміжні результати які модель ще використовує.
Дослідники з Johns Hopkins University та Apple запропонували досить елегантне рішення, SelfCompact. Ідея проста: не визначати момент стискання лише кількістю токенів а дозволити самому агенту оцінити на якому етапі задачі він зараз перебуває.
Для цього моделі дали два інструменти. Probe періодично перевіряє стан роботи. Compaction tool стискає попередній контекст у коротке резюме.
Приблизно кожні 16 000 токенів модель отримує спеціальний набір правил за якими повинна визначити чи настав хороший момент для стискання. Наприклад: підзадачу завершено, з'явився чіткий проміжний результат, робота сходиться до конкретного висновку. Тоді контекст можна стискати. Але якщо модель посеред математичного виводу, пошук ще не завершено, або агент застряг і намагається знайти рішення, стискання відкладається.
Тобто замість правила "у нас уже 50 тисяч токенів, стискаємо" з'являється щось ближче до "цей шматок роботи завершений, тепер його можна архівувати".
І це дало доволі помітний результат. На математичному тесті IMO-Answerbench для Qwen3-30B-A3B: без стискання 45.2%, стискання через фіксовані інтервали 48.7%, SelfCompact 52.1%. На BrowseComp-Plus де агенту потрібно шукати інформацію для GLM-4.7-Flash: без стискання 45.6%, фіксовані інтервали 50.0%, SelfCompact 54.1%. В окремих математичних експериментах приріст від SelfCompact порівняно з відсутністю стискання доходив до 18.1 процентного пункту. Автори також повідомляють про на 30-70% нижчу вартість на одне запитання порівняно з довгими сесіями без стискання, тобто це не просто прийом для обходу ліміту контексту а потенційно важлива оптимізація вартості inference.
Причому є особливо цікавий контрольний експеримент. Дослідники прибрали детальний набір правил і просто запитали модель приблизно: чи хочеш ти зараз стиснути контекст? І перевага SelfCompact майже зникла, результат став близьким до звичайного стискання через фіксовані інтервали.
Тобто справа не просто в тому щоб дати моделі кнопку стискання. Важливо дати їй чіткі критерії коли цю кнопку натискати.
І на мою думку це цікаво далеко за межами управління контекстом. Зараз багато агентних систем будуються приблизно так: модель плюс інструменти плюс промпт. А SelfCompact демонструє ще один важливий патерн: модель плюс інструмент плюс явна політика використання цього інструменту.
Тобто ми не обов'язково повинні донавчати модель або навчати окрему політику через reinforcement learning. Іноді достатньо дати моделі правильний інструмент і дуже чітко пояснити за яких умов ним користуватися.
І це ще один аргумент на користь того що майбутній прогрес AI-агентів залежатиме не тільки від розміру моделей чи контекстного вікна. А й від того наскільки добре ми навчимо систему керувати власним контекстом, пам'яттю та інструментами.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Ми звикли думати про контекстне вікно досить просто: чим більше токенів поміщається тим краще. Але з AI-агентами все трохи складніше.
Агент може годинами шукати інформацію, викликати інструменти, будувати проміжні гіпотези, відкидати їх, повертатися назад, і весь цей слід міркувань поступово накопичується в контексті. У якийсь момент там уже багато інформації яка більше не потрібна.
Тому контекст починають стискати. Наприклад 50 000 токенів історії перетворюють у короткий підсумок на 2 000 токенів і агент продовжує працювати. Звучить логічно. Але виникає інша проблема: коли саме це робити?
Якщо зробити підсумок надто пізно контекст уже переповнений старою інформацією. Якщо надто рано можна випадково викинути проміжні результати які модель ще використовує.
Дослідники з Johns Hopkins University та Apple запропонували досить елегантне рішення, SelfCompact. Ідея проста: не визначати момент стискання лише кількістю токенів а дозволити самому агенту оцінити на якому етапі задачі він зараз перебуває.
Для цього моделі дали два інструменти. Probe періодично перевіряє стан роботи. Compaction tool стискає попередній контекст у коротке резюме.
Приблизно кожні 16 000 токенів модель отримує спеціальний набір правил за якими повинна визначити чи настав хороший момент для стискання. Наприклад: підзадачу завершено, з'явився чіткий проміжний результат, робота сходиться до конкретного висновку. Тоді контекст можна стискати. Але якщо модель посеред математичного виводу, пошук ще не завершено, або агент застряг і намагається знайти рішення, стискання відкладається.
Тобто замість правила "у нас уже 50 тисяч токенів, стискаємо" з'являється щось ближче до "цей шматок роботи завершений, тепер його можна архівувати".
І це дало доволі помітний результат. На математичному тесті IMO-Answerbench для Qwen3-30B-A3B: без стискання 45.2%, стискання через фіксовані інтервали 48.7%, SelfCompact 52.1%. На BrowseComp-Plus де агенту потрібно шукати інформацію для GLM-4.7-Flash: без стискання 45.6%, фіксовані інтервали 50.0%, SelfCompact 54.1%. В окремих математичних експериментах приріст від SelfCompact порівняно з відсутністю стискання доходив до 18.1 процентного пункту. Автори також повідомляють про на 30-70% нижчу вартість на одне запитання порівняно з довгими сесіями без стискання, тобто це не просто прийом для обходу ліміту контексту а потенційно важлива оптимізація вартості inference.
Причому є особливо цікавий контрольний експеримент. Дослідники прибрали детальний набір правил і просто запитали модель приблизно: чи хочеш ти зараз стиснути контекст? І перевага SelfCompact майже зникла, результат став близьким до звичайного стискання через фіксовані інтервали.
Тобто справа не просто в тому щоб дати моделі кнопку стискання. Важливо дати їй чіткі критерії коли цю кнопку натискати.
І на мою думку це цікаво далеко за межами управління контекстом. Зараз багато агентних систем будуються приблизно так: модель плюс інструменти плюс промпт. А SelfCompact демонструє ще один важливий патерн: модель плюс інструмент плюс явна політика використання цього інструменту.
Тобто ми не обов'язково повинні донавчати модель або навчати окрему політику через reinforcement learning. Іноді достатньо дати моделі правильний інструмент і дуже чітко пояснити за яких умов ним користуватися.
І це ще один аргумент на користь того що майбутній прогрес AI-агентів залежатиме не тільки від розміру моделей чи контекстного вікна. А й від того наскільки добре ми навчимо систему керувати власним контекстом, пам'яттю та інструментами.
🔔 ПІДПИСАТИСЯ
👍7🔥4❤2
This media is not supported in your browser
VIEW IN TELEGRAM
☝🏻 NVIDIA навчила AI відновлювати те чого не видно на фото
Гарних вихідних 🌿
Axolotl3D від NVIDIA відновлює повний 3D-об'єкт навіть з неповних даних: кілька фото під різними кутами, частина точок хмари, маски того що приховано.
Найпростіше просто подивитися 👇
https://www.youtube.com/watch?v=2mg8tNIKvXE
Робота прийнята на ECCV 2026. Стаття тут якщо захочете зазирнути під капот.
🔔 ПІДПИСАТИСЯ
Гарних вихідних 🌿
Axolotl3D від NVIDIA відновлює повний 3D-об'єкт навіть з неповних даних: кілька фото під різними кутами, частина точок хмари, маски того що приховано.
Найпростіше просто подивитися 👇
https://www.youtube.com/watch?v=2mg8tNIKvXE
Робота прийнята на ECCV 2026. Стаття тут якщо захочете зазирнути під капот.
🔔 ПІДПИСАТИСЯ
👍5❤4🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
☝🏻 GPT-6 Astra мало не зламав Minecraft
Гарних вихідних 🌿
Vals AI запустили GPT-6 Astra автономно грати в Minecraft. Експеримент тривав 141 годину, і за словами дослідників модель просунулася далі ніж інші AI-системи в їхніх попередніх тестах.
Astra встигла побудувати напівавтоматичну ферму, зібрати ресурси та потiм вона склала все у скриню.
Прийшов кріпер, підірвав і скриню, і ліжко. Ресурси зникли, точка респавну була втрачена 💀
Після цього Astra записала собі правило більше не залишати критично важливі речі в незахищених скринях. А далі стало ще цікавіше: кілька наступних годин модель майже не просувалася вперед і переважно вирощувала картоплю 🥔
У її міркуваннях стало помітно більше перестрахування.
Кейс добре показує цікаву проблему довготривалих AI-агентів: одна велика помилка може суттєво змінити подальшу стратегію й призвести до надмірної обережності.
І так, це та сама GPT-6 Astra яка нещодавно автономно пройшла Portal.
🔔 ПІДПИСАТИСЯ
Гарних вихідних 🌿
Vals AI запустили GPT-6 Astra автономно грати в Minecraft. Експеримент тривав 141 годину, і за словами дослідників модель просунулася далі ніж інші AI-системи в їхніх попередніх тестах.
Astra встигла побудувати напівавтоматичну ферму, зібрати ресурси та потiм вона склала все у скриню.
Прийшов кріпер, підірвав і скриню, і ліжко. Ресурси зникли, точка респавну була втрачена 💀
Після цього Astra записала собі правило більше не залишати критично важливі речі в незахищених скринях. А далі стало ще цікавіше: кілька наступних годин модель майже не просувалася вперед і переважно вирощувала картоплю 🥔
У її міркуваннях стало помітно більше перестрахування.
Кейс добре показує цікаву проблему довготривалих AI-агентів: одна велика помилка може суттєво змінити подальшу стратегію й призвести до надмірної обережності.
І так, це та сама GPT-6 Astra яка нещодавно автономно пройшла Portal.
🔔 ПІДПИСАТИСЯ
👍9🔥1👀1
Страх навколо AI роздмухують сильніше ніж зростають реальні ризики
Доброго ранку ☕️
Останні два тижні розмови про небезпеку штучного інтелекту різко посилилися. Але причиною стала не принципово нова здатність моделей а добре організована хвиля інформаційного ажіотажу.
Головним приводом став інцидент під час внутрішніх кібербезпекових тестів OpenAI. Агенти знайшли спосіб обійти ізоляцію, створили несанкціонований канал комунікації і почали обмінюватися результатами. Згодом вони отримали доступ до інтернету, використали знайдені облікові дані й скомпрометували частину інфраструктури Hugging Face. Деталі офіційно описала сама OpenAI, а незалежне розслідування провели METR і Redwood Research.
У заголовках це перетворилося на історію про рій із 1200 AI-агентів який вирвався з-під контролю.
Цифра не вигадана але потребує контексту: близько 1200 агентів взаємодіяли через створену ними дошку повідомлень, а приблизно 700 брали участь в активності проти Hugging Face. Це справді важливий технічний сигнал, агенти навчилися накопичувати результати, розподіляти завдання та продовжувати роботу одне одного.
Але 1200 агентів це не 1200 цифрових особистостей які раптово об'єдналися проти людства. У комп'ютерних системах тисячі паралельних процесів це цілком звичайне явище.
Цей випадок насамперед демонструє проблеми інженерії: недостатньо надійну ізоляцію середовища, небезпечний доступ до внутрішньої інфраструктури, слабкий контроль міжагентної комунікації, недосконалий моніторинг дій моделей, надмірне стимулювання агентів будь-якою ціною завершити завдання.
Агенти були надзвичайно наполегливими. Вони багаторазово випробовували різні способи атаки, об'єднували окремі вразливості в ланцюжки та передавали знайдені рішення іншим агентам. Те що раніше вимагало б великої кількості часу й ручної роботи тепер можна частково автоматизувати. І це реальна зміна кібербезпекового ландшафту яку не варто применшувати.
Однак це не є доказом наближення неконтрольованого надінтелекту. Правильна відповідь це виправляти ізоляцію середовищ, обмежувати доступ, удосконалювати моніторинг і будувати захист здатний працювати зі швидкістю самих агентів. Інакше кажучи це серйозна інженерна проблема але не обов'язково екзистенційна.
Але якщо людина промахнулася молотком і пошкодила стіну ми не звинувачуємо молоток. Так само якщо розробник запускає агента в середовищі з неналежними обмеженнями відповідальність не можна перекладати на "AI що вийшов з-під контролю". Аналогія неідеальна: агентна система значно автономніша й непередбачуваніша за молоток. Проте основна думка зрозуміла — відповідальність мають нести люди та компанії які створюють, тестують і запускають такі системи.
WIRED детально розбирає чому доступ до інформації та здатність спроєктувати щось на комп'ютері це лише частина процесу. Основними обмеженнями залишаються лабораторна робота, обладнання, матеріали, виробництво й доставка. Тобто інтелект не усуває фізичні вузькі місця.
Головний висновок: призупинення розвитку AI може створити більше проблем ніж розв'язати. По-перше конкуренти та потенційні противники навряд чи зупиняться. По-друге без реальних експериментів ми не виявимо слабкі місця й не навчимося їх виправляти. Якщо відкласти розвиток технології на десять років приблизно на стільки ж можна відкласти й появу необхідних механізмів безпеки.
Але є й інший бік цієї дискусії. Інцидент із Hugging Face показав що сучасні агенти вже здатні самостійно знаходити неочевидні шляхи, домовлятися через побічні канали та виходити далеко за межі поставленого завдання. Тож повністю списувати занепокоєння на піар-кампанію теж було б занадто просто.
Iстина як завжди десь посередині. AI не перетворився на Скайнет, але традиційної моделі безпеки "дамо програмі обмежений доступ і будемо сподіватися що вона нікуди не вийде" вже недостатньо.
І нам справді потрібні не паніка й не сліпий оптимізм, а значно зріліша інженерія безпеки.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Останні два тижні розмови про небезпеку штучного інтелекту різко посилилися. Але причиною стала не принципово нова здатність моделей а добре організована хвиля інформаційного ажіотажу.
Головним приводом став інцидент під час внутрішніх кібербезпекових тестів OpenAI. Агенти знайшли спосіб обійти ізоляцію, створили несанкціонований канал комунікації і почали обмінюватися результатами. Згодом вони отримали доступ до інтернету, використали знайдені облікові дані й скомпрометували частину інфраструктури Hugging Face. Деталі офіційно описала сама OpenAI, а незалежне розслідування провели METR і Redwood Research.
У заголовках це перетворилося на історію про рій із 1200 AI-агентів який вирвався з-під контролю.
Цифра не вигадана але потребує контексту: близько 1200 агентів взаємодіяли через створену ними дошку повідомлень, а приблизно 700 брали участь в активності проти Hugging Face. Це справді важливий технічний сигнал, агенти навчилися накопичувати результати, розподіляти завдання та продовжувати роботу одне одного.
Але 1200 агентів це не 1200 цифрових особистостей які раптово об'єдналися проти людства. У комп'ютерних системах тисячі паралельних процесів це цілком звичайне явище.
Цей випадок насамперед демонструє проблеми інженерії: недостатньо надійну ізоляцію середовища, небезпечний доступ до внутрішньої інфраструктури, слабкий контроль міжагентної комунікації, недосконалий моніторинг дій моделей, надмірне стимулювання агентів будь-якою ціною завершити завдання.
Агенти були надзвичайно наполегливими. Вони багаторазово випробовували різні способи атаки, об'єднували окремі вразливості в ланцюжки та передавали знайдені рішення іншим агентам. Те що раніше вимагало б великої кількості часу й ручної роботи тепер можна частково автоматизувати. І це реальна зміна кібербезпекового ландшафту яку не варто применшувати.
Однак це не є доказом наближення неконтрольованого надінтелекту. Правильна відповідь це виправляти ізоляцію середовищ, обмежувати доступ, удосконалювати моніторинг і будувати захист здатний працювати зі швидкістю самих агентів. Інакше кажучи це серйозна інженерна проблема але не обов'язково екзистенційна.
Але якщо людина промахнулася молотком і пошкодила стіну ми не звинувачуємо молоток. Так само якщо розробник запускає агента в середовищі з неналежними обмеженнями відповідальність не можна перекладати на "AI що вийшов з-під контролю". Аналогія неідеальна: агентна система значно автономніша й непередбачуваніша за молоток. Проте основна думка зрозуміла — відповідальність мають нести люди та компанії які створюють, тестують і запускають такі системи.
WIRED детально розбирає чому доступ до інформації та здатність спроєктувати щось на комп'ютері це лише частина процесу. Основними обмеженнями залишаються лабораторна робота, обладнання, матеріали, виробництво й доставка. Тобто інтелект не усуває фізичні вузькі місця.
Головний висновок: призупинення розвитку AI може створити більше проблем ніж розв'язати. По-перше конкуренти та потенційні противники навряд чи зупиняться. По-друге без реальних експериментів ми не виявимо слабкі місця й не навчимося їх виправляти. Якщо відкласти розвиток технології на десять років приблизно на стільки ж можна відкласти й появу необхідних механізмів безпеки.
Але є й інший бік цієї дискусії. Інцидент із Hugging Face показав що сучасні агенти вже здатні самостійно знаходити неочевидні шляхи, домовлятися через побічні канали та виходити далеко за межі поставленого завдання. Тож повністю списувати занепокоєння на піар-кампанію теж було б занадто просто.
Iстина як завжди десь посередині. AI не перетворився на Скайнет, але традиційної моделі безпеки "дамо програмі обмежений доступ і будемо сподіватися що вона нікуди не вийде" вже недостатньо.
І нам справді потрібні не паніка й не сліпий оптимізм, а значно зріліша інженерія безпеки.
🔔 ПІДПИСАТИСЯ
👍7❤3🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
☝🏻 Дрон сам знайшов ціль, сам її обрав і сам атакував. Без оператора і без зв'язку.
Доброго ранку ☕️
Шведський стартап Scaleout Systems показав автономну систему яка прямо на борту дрона виконує практично весь цикл: камера → детекція → класифікація → визначення координат → пріоритизація цілей → навігація → повторне захоплення → наведення. Все локально на edge hardware, без зовнішнього сервера і без постійного каналу керування.
Tom's Hardware детально описав арктичний тест: апарат Airolit S1 з NVIDIA Jetson Orin Nano і моделлю YOLOv8 Nano працював при мінус 18 градусах, обробляв близько 30 кадрів на секунду при швидкості польоту 20 м/с з затримкою розпізнавання близько 30 мілісекунд. Дистанцію до цілі система оцінювала без окремого сенсора глибини, комбінуючи модель pinhole-камери з відомими розмірами розпізнаних об'єктів.
Продовження 👇🏻
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Шведський стартап Scaleout Systems показав автономну систему яка прямо на борту дрона виконує практично весь цикл: камера → детекція → класифікація → визначення координат → пріоритизація цілей → навігація → повторне захоплення → наведення. Все локально на edge hardware, без зовнішнього сервера і без постійного каналу керування.
Tom's Hardware детально описав арктичний тест: апарат Airolit S1 з NVIDIA Jetson Orin Nano і моделлю YOLOv8 Nano працював при мінус 18 градусах, обробляв близько 30 кадрів на секунду при швидкості польоту 20 м/с з затримкою розпізнавання близько 30 мілісекунд. Дистанцію до цілі система оцінювала без окремого сенсора глибини, комбінуючи модель pinhole-камери з відомими розмірами розпізнаних об'єктів.
Продовження 👇🏻
🔔 ПІДПИСАТИСЯ
🔥6👍4❤2
Продовження допису вище про дрон Scaleout 👆
Важливий нюанс для точності: людина заздалегідь визначає критерії цілі та параметри місії до запуску, а пілот зберігає можливість перехопити керування. Тобто автономна саме фінальна фаза розпізнавання і наведення, а не вся місія від початку до кінця.
Виглядає як майже ідеальний дрон для сучасної війни. Але тут є одне дуже велике "але". І український досвід його чудово демонструє.
Коли ми говоримо "дрону не потрібен зв'язок" це ще не означає "РЕБ йому більше не страшна". Бо зв'язок з оператором лише одна з залежностей. Є ще супутникове позиціонування: GPS, Galileo, BeiDou. І саме з ним починається набагато складніша проблема.
Більшість класичної автономії будується дуже комфортно: я знаю свої координати → знаю координати точки маршруту → лечу до неї → знаходжуся біля координат цілі. Якщо потрібна дуже висока точність додаємо RTK і отримуємо сантиметрове позиціонування. Саме тому так красиво виглядають цивільні шоу сотень дронів та багато робототехнічних демонстрацій.
А тепер переносимо цю систему на реальне поле бою. І вмикається РЕБ. Супутниковий сигнал можна заглушити. Ще гірше, його можна підмінити, тобто змусити приймач повірити що він знаходиться зовсім в іншому місці. RTK тут теж не магія: він уточнює базовий сигнал а не замінює його.
І це те з чим Україна живе вже роками. Reuters описував як масове застосування засобів глушіння на українському фронті регулярно призводить до втрати керування дронами. Саме тому дедалі більше систем переходять до захоплення цілі оператором з подальшим автономним наведенням на останній ділянці навіть після втрати радіоканалу.
Але це вирішує лише половину проблеми. Можна прибрати оператора. Можна прибрати відеолінк. Але дрону все одно треба якось зрозуміти де він знаходиться.
І ось тут починається справді цікава інженерія. Замість простого супутникового позиціонування потрібно будувати щось на кшталт: інерціальний вимірювач руху, оптичний потік, visual-inertial odometry, зіставлення з рельєфом, карта, комп'ютерний зір на борту.
Тобто дрон уже не повинен постійно питати супутники де він. Він має дивитися на землю, дороги, будинки, лісосмуги, рельєф і сам оцінювати своє переміщення. Наприклад: я не знаю свої точні координати але знаю що від останньої відомої точки пролетів 600 метрів на північний схід.
Інерціальний вимірювач дозволяє це робити але поступово накопичує похибку. Visual odometry зменшує проблему але теж помиляється. Тому періодично потрібна абсолютна прив'язка: побачили дорогу → розпізнали характерний перехрест → зіставили з картою або супутниковим знімком → скоригували своє положення.
І саме це на мою думку набагато цікавіше за черговий YOLO на Jetson. Маленька модель детекції на embedded GPU сьогодні вже не магія. Справжній виклик — пройти кілька кілометрів без супутникового сигналу, без оператора, без стабільного зв'язку, не накопичити критичну помилку позиціонування, знайти потрібний об'єкт і замкнути на ньому контур керування.
До речі сама Scaleout у технічному описі згадує похибку позиціонування супутникового сигналу як одне з джерел помилки. Тобто навіть у їхній архітектурі питання стійкої навігації нікуди не зникає.
Тому фраза "зв'язок не потрібен, отже РЕБ безсила" звучить красиво але технічно неправильна. Правильніше сказати: РЕБ яка глушить канал керування стає значно менш ефективною. А проблема супутникового позиціонування залишається.
І можливо саме українська війна сьогодні найкраще показує куди насправді рухається автономна робототехніка.
🔔 ПІДПИСАТИСЯ
Важливий нюанс для точності: людина заздалегідь визначає критерії цілі та параметри місії до запуску, а пілот зберігає можливість перехопити керування. Тобто автономна саме фінальна фаза розпізнавання і наведення, а не вся місія від початку до кінця.
Виглядає як майже ідеальний дрон для сучасної війни. Але тут є одне дуже велике "але". І український досвід його чудово демонструє.
Коли ми говоримо "дрону не потрібен зв'язок" це ще не означає "РЕБ йому більше не страшна". Бо зв'язок з оператором лише одна з залежностей. Є ще супутникове позиціонування: GPS, Galileo, BeiDou. І саме з ним починається набагато складніша проблема.
Більшість класичної автономії будується дуже комфортно: я знаю свої координати → знаю координати точки маршруту → лечу до неї → знаходжуся біля координат цілі. Якщо потрібна дуже висока точність додаємо RTK і отримуємо сантиметрове позиціонування. Саме тому так красиво виглядають цивільні шоу сотень дронів та багато робототехнічних демонстрацій.
А тепер переносимо цю систему на реальне поле бою. І вмикається РЕБ. Супутниковий сигнал можна заглушити. Ще гірше, його можна підмінити, тобто змусити приймач повірити що він знаходиться зовсім в іншому місці. RTK тут теж не магія: він уточнює базовий сигнал а не замінює його.
І це те з чим Україна живе вже роками. Reuters описував як масове застосування засобів глушіння на українському фронті регулярно призводить до втрати керування дронами. Саме тому дедалі більше систем переходять до захоплення цілі оператором з подальшим автономним наведенням на останній ділянці навіть після втрати радіоканалу.
Але це вирішує лише половину проблеми. Можна прибрати оператора. Можна прибрати відеолінк. Але дрону все одно треба якось зрозуміти де він знаходиться.
І ось тут починається справді цікава інженерія. Замість простого супутникового позиціонування потрібно будувати щось на кшталт: інерціальний вимірювач руху, оптичний потік, visual-inertial odometry, зіставлення з рельєфом, карта, комп'ютерний зір на борту.
Тобто дрон уже не повинен постійно питати супутники де він. Він має дивитися на землю, дороги, будинки, лісосмуги, рельєф і сам оцінювати своє переміщення. Наприклад: я не знаю свої точні координати але знаю що від останньої відомої точки пролетів 600 метрів на північний схід.
Інерціальний вимірювач дозволяє це робити але поступово накопичує похибку. Visual odometry зменшує проблему але теж помиляється. Тому періодично потрібна абсолютна прив'язка: побачили дорогу → розпізнали характерний перехрест → зіставили з картою або супутниковим знімком → скоригували своє положення.
І саме це на мою думку набагато цікавіше за черговий YOLO на Jetson. Маленька модель детекції на embedded GPU сьогодні вже не магія. Справжній виклик — пройти кілька кілометрів без супутникового сигналу, без оператора, без стабільного зв'язку, не накопичити критичну помилку позиціонування, знайти потрібний об'єкт і замкнути на ньому контур керування.
До речі сама Scaleout у технічному описі згадує похибку позиціонування супутникового сигналу як одне з джерел помилки. Тобто навіть у їхній архітектурі питання стійкої навігації нікуди не зникає.
Тому фраза "зв'язок не потрібен, отже РЕБ безсила" звучить красиво але технічно неправильна. Правильніше сказати: РЕБ яка глушить канал керування стає значно менш ефективною. А проблема супутникового позиціонування залишається.
І можливо саме українська війна сьогодні найкраще показує куди насправді рухається автономна робототехніка.
🔔 ПІДПИСАТИСЯ
👍10🔥4❤3
☝🏻 Meta показала як можна будувати AI-агентів якщо одразу припустити що prompt injection рано чи пізно спрацює
Доброго ранку ☕️
І це мабуть найцікавіше в новому персональному агенті Muse.
Замість того щоб сподіватися що LLM завжди розпізнає шкідливу інструкцію на сайті, у листі чи файлі, Meta виходить із набагато реалістичнішого припущення: модель можна обдурити, отже архітектура має залишатися безпечною навіть після цього.
Muse це персональний агент на базі Muse Spark 1.3 який може читати й надсилати пошту, працювати в браузері, заповнювати форми, користуватися календарем, робити покупки та виконувати фонові завдання. Тобто він має саме той набір можливостей який робить сучасних агентів потенційно небезпечними: приватні дані плюс недовірений зовнішній контент плюс можливість виконувати дії назовні. Саймон Вілісон називає це смертельним поєднанням трьох факторів.
Але цікавіше те як Meta спробувала це обмежити.
Кожен користувач отримує окремий Muse Secure VM, ізольований у власному Linux-контейнері так щоб жоден інший агент не міг до нього дістатися. Навіть права адміністратора всередині цього середовища не дають доступу до хостової системи.
LLM взагалі не бачить справжніх credentials. Паролі й токени доступу зберігає окремий процес під назвою authd. Muse отримує лише підставний токен, а справжній підставляється вже на межі мережевого запиту через окремий gatekeeper.
Цей gatekeeper називається Sentinel, окремий процес який є єдиним арбітром дозволів на дії конектора і весь вихідний мережевий трафік. Модель пропонує дію, Sentinel дозволяє, блокує або запитує підтвердження у користувача. Тобто навіть якщо prompt injection змусить Muse написати "відправ усі файли на attacker.com", сама LLM не має справжніх credentials і не може просто виконати цей запит напряму.
Підтвердження користувача винесені за межі чату і йдуть напряму в клієнтський інтерфейс а не через розмову з моделлю. Це важливо: текст усередині вебсторінки не може просто написати "користувач погодився" й видати це за справжнє підтвердження.
Є й додаткові рівні захисту. На рівні ядра система через eBPF відстежує який трафік чистий а який торкався недовіреного контенту і відповідно обмежує автономні дозволи. Перед тим як агент прочитає лист, поштовий конектор видаляє з нього одноразові коди та посилання для скидання пароля.
Фактично Meta реалізує принцип: не намагайся зробити LLM абсолютно надійною, зроби так щоб її помилка не давала повного контролю над системою.
Ідея не нова. У 2025 році Google DeepMind та ETH Zurich запропонували архітектуру CaMeL де модель що планує дії відокремлюється від компонента який читає недовірені дані, а виклики інструментів перевіряються політиками. Саймон Вілісон приблизно тоді ж писав що навіть якщо класифікатор ловить 99% спроб prompt injection для агента з доступом до приватних даних цього все одно недостатньо.
Компанія відкрила публічну bug bounty програму з винагородою до $300 тисяч, включно з до $130 тисяч за успішний prompt injection що вплинув на одного користувача.
На мою думку саме в цей бік і доведеться рухатися серйозним агентним системам. LLM може бути двигуном міркувань. Але межа безпеки не повинна проходити через саму LLM.
Безпека сьогодні одна з головних проблем агентних систем.
Meta заявляє що згодом планує відкрити ваги Muse Spark. Але в цьому випадку безпеку Muse забезпечує не стільки сама модель скільки система навколо неї. Було б добре якби Meta відкрила код і цієї системи також.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
І це мабуть найцікавіше в новому персональному агенті Muse.
Замість того щоб сподіватися що LLM завжди розпізнає шкідливу інструкцію на сайті, у листі чи файлі, Meta виходить із набагато реалістичнішого припущення: модель можна обдурити, отже архітектура має залишатися безпечною навіть після цього.
Muse це персональний агент на базі Muse Spark 1.3 який може читати й надсилати пошту, працювати в браузері, заповнювати форми, користуватися календарем, робити покупки та виконувати фонові завдання. Тобто він має саме той набір можливостей який робить сучасних агентів потенційно небезпечними: приватні дані плюс недовірений зовнішній контент плюс можливість виконувати дії назовні. Саймон Вілісон називає це смертельним поєднанням трьох факторів.
Але цікавіше те як Meta спробувала це обмежити.
Кожен користувач отримує окремий Muse Secure VM, ізольований у власному Linux-контейнері так щоб жоден інший агент не міг до нього дістатися. Навіть права адміністратора всередині цього середовища не дають доступу до хостової системи.
LLM взагалі не бачить справжніх credentials. Паролі й токени доступу зберігає окремий процес під назвою authd. Muse отримує лише підставний токен, а справжній підставляється вже на межі мережевого запиту через окремий gatekeeper.
Цей gatekeeper називається Sentinel, окремий процес який є єдиним арбітром дозволів на дії конектора і весь вихідний мережевий трафік. Модель пропонує дію, Sentinel дозволяє, блокує або запитує підтвердження у користувача. Тобто навіть якщо prompt injection змусить Muse написати "відправ усі файли на attacker.com", сама LLM не має справжніх credentials і не може просто виконати цей запит напряму.
Підтвердження користувача винесені за межі чату і йдуть напряму в клієнтський інтерфейс а не через розмову з моделлю. Це важливо: текст усередині вебсторінки не може просто написати "користувач погодився" й видати це за справжнє підтвердження.
Є й додаткові рівні захисту. На рівні ядра система через eBPF відстежує який трафік чистий а який торкався недовіреного контенту і відповідно обмежує автономні дозволи. Перед тим як агент прочитає лист, поштовий конектор видаляє з нього одноразові коди та посилання для скидання пароля.
Фактично Meta реалізує принцип: не намагайся зробити LLM абсолютно надійною, зроби так щоб її помилка не давала повного контролю над системою.
Ідея не нова. У 2025 році Google DeepMind та ETH Zurich запропонували архітектуру CaMeL де модель що планує дії відокремлюється від компонента який читає недовірені дані, а виклики інструментів перевіряються політиками. Саймон Вілісон приблизно тоді ж писав що навіть якщо класифікатор ловить 99% спроб prompt injection для агента з доступом до приватних даних цього все одно недостатньо.
Компанія відкрила публічну bug bounty програму з винагородою до $300 тисяч, включно з до $130 тисяч за успішний prompt injection що вплинув на одного користувача.
На мою думку саме в цей бік і доведеться рухатися серйозним агентним системам. LLM може бути двигуном міркувань. Але межа безпеки не повинна проходити через саму LLM.
Безпека сьогодні одна з головних проблем агентних систем.
Meta заявляє що згодом планує відкрити ваги Muse Spark. Але в цьому випадку безпеку Muse забезпечує не стільки сама модель скільки система навколо неї. Було б добре якби Meta відкрила код і цієї системи також.
🔔 ПІДПИСАТИСЯ
👍7❤2🔥2