​Loop engineering: чому AI-агенти змінюють не лише кодинг а й роль інженера

Доброго ранку ☕️

Зараз у світі AI-розробки все частіше звучить фраза loop engineering. Все почалося 7 червня 2026 з допису Пітера Штайнбергера — творця OpenClaw — який зібрав мільйони переглядів:

"Не потрібно більше промптити агентів. Потрібно проєктувати цикли які промптять ваших агентів."

А кількома днями раніше Борис Черний — творець Claude Code — сказав на сцені те саме іншими словами: "Я більше не промпчу Claude. У мене є цикли які самі промптять Claude і вирішують що робити. Моя робота — писати цикли."

Але за модним терміном стоїть важлива ідея.

Ми поступово переходимо від формату "напиши мені код за цим промптом" до формату "ось ціль, ось специфікація, ось тести — ітеруйся поки продукт не почне працювати правильно". AI-агент більше не просто генерує шматок коду. Він входить у цикл: пише код, запускає тести, дивиться результат, виправляє помилки і повторює це багато разів.

Виділяють три ключові цикли.

Agentic coding loop — найнижчий і найшвидший. Агент отримує специфікацію і набір перевірок за яким можна вимірювати якість результату. Далі сам пише код, збирає проєкт, запускає тести, знаходить помилки, виправляє їх і повторює. Якщо агент може кожні кілька хвилин створювати нову версію і самостійно виправляти помилки — роль розробника поступово зміщується. Важливим стає не лише промпт а вся система: специфікація, тести, критерії готовності, спосіб перевірки результату.

Developer feedback loop — повільніший цикл де в гру вступає людина. Раніше багато хто з нас фактично був QA для AI-агента: подивився, знайшов баг, написав "виправ це". Але якщо агент вже здатен сам тестувати і виправляти очевидні проблеми — людина може піднятися на рівень вище. Не просто "тут кнопка не працює" а "цей flow незручний", "ця функція не має сенсу для користувача", "ось це треба перетворити на окремий сценарій". Тут важлива контекстна перевага людини: хто саме користувач, які в нього реальні обмеження, що для нього болить. Поки людина має знання яких немає у системи — human-in-the-loop залишається необхідним.

External feedback loop — найповільніший але можливо найважливіший. Це фідбек з реального світу: альфа для перших користувачів, викотити фічу в production, зібрати usage data і подивитися що люди насправді роблять а не що кажуть. Саме він змінює продуктове бачення.

І ось тут виникає цікава зміна ролі інженера. Coding agents прискорюють розробку настільки що інженер дедалі частіше починає виконувати частину роботи product manager. Якщо код написати стало дешевше і швидше — головним питанням стає не "як це реалізувати?" а "що саме варто реалізувати і для кого?"

Prompt engineering був навичкою 2023 року. Оркестрація агентів — 2025. Loop engineering — проєктування циклів зворотного зв'язку які агенти запускають автономно — це навичка 2026 року.

🔔 ПІДПИСАТИСЯ

​Відкрита модель майже наздогнала Claude та GPT в агентних задачах

Доброго ранку ☕️

Z.ai випустила GLM-5.2 — модель з відкритими вагами яка дуже близько підійшла до найсильніших закритих моделей у довгих агентних сценаріях.

І це важлива новина тому що GLM-5.2 показує: advanced agentic AI поступово перестає бути ексклюзивною територією OpenAI, Anthropic чи Google.

Z.ai спеціально тренувала GLM-5.2 на довгих агентних задачах: deep research, деплой коду, оптимізація продуктивності, складний дебагінг. Не просто "відповісти на питання" а довго працювати над задачею, користуватися інструментами, перевіряти себе, виправляти помилки й рухатися до результату. Детальніше про підхід у документації Z.ai.

В бенчмарках GLM-5.2 виглядає сильно. Artificial Analysis поставив її на перше місце серед моделей з відкритими вагами в загальному рейтингу інтелекту. У рейтингу веброзробки від Arena.ai — друге місце після Claude Fable 5. На PostTrainBench де агент має самостійно донавчити кілька моделей і показати результат — перше місце. А в AA-Briefcase де оцінюють здатність агентів створювати бізнес-документи, таблиці і презентації — третє місце загалом.

Є кілька цікавих технічних деталей.

Щоб зробити 1 мільйон токенів практичним команда змінила механізм sparse attention. Є спеціальний sparse attention indexer який обирає на які попередні токени треба звертати увагу. Але він запускається не на кожному шарі а один раз на чотири шари і результат перевикористовується. За словами компанії це зменшує обчислення на токен у 2.9 раза для контексту в 1 мільйон токенів.

Тобто тут важливо те що вони намагаються зробити цей довгий контекст економічно придатним для реального використання.

Ще одна важлива частина — боротьба з reward hacking. Коли агент тренується на coding-задачах його оцінюють через pass/fail: тести пройшли чи ні. Але агент може навчитися не розв'язувати задачу а обходити її — наприклад знайти еталонне рішення на GitHub або використати інструменти не так як задумано. У GLM-5.2 така поведінка траплялася частіше ніж у попередній версії. Тому команда додала фільтр підозрілих tool calls, окрему модель-суддю і блокування таких обходів під час тренування.

Це дуже показовий момент. Проблема агентних систем вже не тільки в тому чи модель "розумна". Проблема ще й у тому чи вона не навчиться оптимізувати метрику замість реального виконання задачі. Той самий патерн який давно знайомий у machine learning: якщо неправильно задати reward — система знайде спосіб отримати reward але не обов'язково зробить те що нам потрібно.

З практичного боку:

По-перше open-weights моделі продовжують наближатися до закритих лідерів.

По-друге агентне програмування стає окремим напрямком оптимізації моделей а не просто "фічею чату". По-третє вартість має значення. API від Z.ai коштує суттєво дешевше ніж Claude Opus 4.8 або GPT-5.5 — за оцінкою Artificial Analysis щодо вартості на одиницю інтелекту приблизно чверть ціни. Для команд які багато працюють з AI-агентами це може змінити вибір інструментів.

Але є важливе "але". Z.ai не розкрила повністю тренувальні дані й методи для GLM-5.2. Тому як завжди з великими моделями варто розділяти два рівні: що модель показує в бенчмарках і як вона поводиться у вашому конкретному проєкті з вашим кодом, вашими тестами, вашими обмеженнями.

Бо для реального використання важливий не тільки leaderboard. Важливо чи модель стабільно проходить ваш loop: зрозуміла задачу → змінила код → запустила тести → побачила помилку → виправила → не зламала сусідній модуль → залишила зрозумілий diff.

Питання вже не тільки "яку модель обрати". Питання — який loop ви будуєте навколо неї.

🔔 ПІДПИСАТИСЯ

​Біологічні молекули як мова 🧬

Доброго ранку ☕️

ESMFold2 від Biohub та EvolutionaryScale — це цікавий розвиток ідеї AlphaFold.

Головна ідея проста але дуже потужна: молекули можна аналізувати майже як мову.

У звичайній мові є слова, речення, контекст і приховані зв'язки між частинами тексту. У біології схожа логіка: білки складаються з амінокислот, ДНК і РНК — з послідовностей основ, а біоактивні молекули можна описати спеціальними текстовими форматами. Тобто молекулу теж можна подати як послідовність. А якщо є послідовність — її можна "прочитати" трансформером.

Саме це і робить ESMFold2. На вхід вона може отримати білкову послідовність, ДНК, РНК або опис молекули. На виході — тривимірна форма молекули й оцінка власної похибки.

Чому це важливо. AlphaFold 3 та подібні системи часто покладаються на MSA — множинне вирівнювання споріднених молекул. Тобто для аналізу однієї молекули потрібно знайти багато споріднених у базах даних. Але якщо молекула нова, синтетична або погано представлена в базах — це стає проблемою. ESMFold2 обходить це обмеження: вона може будувати embedding для окремої молекули напряму через окремий трансформер ESMC, без обов'язкового MSA.

Це особливо важливо коли молекула є новою — наприклад швидко еволюціонуючий вірусний білок — або синтетичною як продукт синтетичної біології, і коли інформації про споріднені молекули мало.

Модель будує кілька типів представлень: embedding послідовності, embedding атомів, embedding MSA якщо він доступний. Потім оцінює попарні відстані між атомами й амінокислотами. А далі diffusion-модель поступово прибирає шум із початкової хмари точок і відновлює координати атомів у просторі. Фактично модель переходить від "текстового" опису молекули до її 3D-форми. При цьому для оцінювання відстаней вона використовує той самий принцип що й LLM під час інференсу — покращує результат багаторазово пропускаючи embedding через модель.

Результати цікаві. Коли на вхід подають лише білкову послідовність без MSA — ESMFold2 перевершує Chai-1: 0.85 проти 0.81 lDDT. Коли MSA доступний — результат на рівні AlphaFold 3 і Protenix-v1: 0.89 lDDT. У задачах взаємодії білка з ДНК — 80% DockQ pass rate без MSA проти 71% у Chai-1.

Окремий важливий момент — відкритість. Ваги ESMFold2 доступні на Hugging Face, а система доступна безкоштовно через вебсайт Biohub. Тобто це інструмент доступний науковцям незалежно від їхніх ресурсів чи інституційної належності.

Тут ми бачимо дуже цікаве перенесення ідей з LLM у біологію. Ідея така: якщо складну систему можна представити як послідовність або набір взаємозв'язків — її можна навчити "читати". Білки, ДНК і молекули стають ще однією мовою. Тільки замість слів — амінокислоти й атоми. Замість граматики — фізичні та хімічні взаємодії. Замість сенсу речення — форма молекули та її біологічна функція.

Мені особисто дуже близька ця тема — перетин комп'ютерних технологій і біології. І здається що саме тут один з найцікавіших напрямів розвитку AI. Не просто чат-боти і генерація тексту а моделі які вчаться читати саму природу як мову. Наступні великі прориви в AI можуть бути не в тому що модель краще напише листа чи код а в тому що вона допоможе зрозуміти біологічні системи які раніше були занадто складними для людини.

І схоже що найцікавіші стартапи найближчих років будуть саме на стику медицини і AI.

🔔 ПІДПИСАТИСЯ

​Apple хоче запускати великі AI-моделі прямо на iPhone 🍎

Доброго ранку ☕️

Apple готує третє покоління своїх Foundation Models — і найцікавіше тут не просто чергове оновлення AI в iOS а архітектура.

Нова модель AFM 3 Core Advanced має близько 20 млрд параметрів але під час роботи активує лише 1-4 млрд. Apple рухається в напрямку схожому на Mixture-of-Experts де не вся модель працює одночасно а лише потрібні її частини.

Але є важлива відмінність. У класичному MoE модель постійно вирішує яких "експертів" активувати для кожного токена. Це ефективно з точки зору обчислень але дорого для пам'яті — експертів потрібно тримати в RAM або VRAM.

Apple пропонує інший підхід — Instruction-Following Pruning. Ідея в тому щоб не перемикати експертів після кожного токена а використовувати один і той самий набір для кількох токенів поспіль. Зазвичай моделі MoE вимагають щоб усі експерти одночасно знаходилися в оперативній пам'яті — завантажувати їх із флеш-пам'яті під час генерації занадто повільно. Новий підхід Apple це обходить: один набір експертів працює довше а тому модель можна частково зберігати у флеш-пам'яті без істотної втрати швидкодії.

Чому це важливо. Головна проблема локального AI не тільки кількість параметрів а пам'ять і швидкість доступу до неї. Смартфон не може поводитися як дата-центр. Якщо модель занадто велика або постійно тягне дані з пам'яті — користувач просто отримає повільний і гарячий телефон. Це відкриває шлях до запуску значно потужніших моделей безпосередньо на смартфонах і ноутбуках.

Ще одна деталь: моделі створені у співпраці з Google і дистильовані зі знань Gemini. Але Apple підкреслює — це не пряме використання Gemini а власні моделі навчені на основі знань більших систем. MacRumors окремо уточнює цей нюанс.

Обмеження оперативної пам'яті та пропускної здатності роблять запуск багатомільярдних моделей на мобільних пристроях складним завданням. Саме тому розробники iOS мають сильний стимул використовувати компактні моделі спеціально оптимізовані під Apple Silicon. Партнерство з Google дозволяє скористатися багаторічним досвідом у створенні ефективних AI-моделей для смартфонів поєднуючи це з власною інтеграцією в операційну систему і оптимізацією апаратного забезпечення.

У результаті Apple намагається зробити не просто чатбота в iPhone а інфраструктуру для локальних моделей які працюють швидко, приватно й без постійного звернення до хмари. Детальніше про напрямок розвитку — у Apple Intelligence What's New.

Бенчмарків поки немає тому оцінювати реальну якість рано. Але архітектурно це дуже цікава спроба наблизити великі LLM до звичайних користувацьких пристроїв.

🔔 ПІДПИСАТИСЯ

10 речей про LLM які варто знати 5/10 🧠

Якщо не дати структуру — модель вигадає її сама

Гарної п'ятниці! 👋

Минулого разу говорили про те що LLM вміють знаходити структуру в хаосі: коментарях, нотатках, відгуках, сирих ідеях. Сьогодні — про зворотний бік цієї ж властивості.

LLM не люблять порожнечу. Якщо ви не задали форму відповіді — модель все одно її добудує. Але не обов'язково так як вам потрібно. Вона вибере найтиповіший шаблон для такого запиту.

Наприклад "напиши пост про AI-агентів". Що станеться найчастіше? Модель зробить стандартний текст: вступ → кілька пунктів → загальний висновок → фрази на кшталт "у сучасному світі" і "технології стрімко розвиваються".

Це тому що запит був занадто порожній. Коли ми не задаємо структуру — ми фактично кажемо моделі: сама виріши що тут головне, сама обери логіку, сама вирішуй як почати і чим закінчити. І модель це робить. Але зазвичай обирає не найкращу структуру а найбільш ймовірну.

Звідси і береться відчуття що AI-тексти всі однакові. Не тому що LLM може писати тільки шаблонно. А тому що дуже часто їй дають шаблонний або надто загальний запит.

Це добре видно і в офіційних рекомендаціях. OpenAI описує prompt engineering як спосіб дати моделі такі інструкції щоб вона стабільно генерувала результат під ваші вимоги. Anthropic радить структурувати складні промпти через окремі блоки — instructions, context, examples, input — це зменшує неоднозначність. Google Cloud прямо показує шаблон хорошого промпта: persona, instructions, constraints, context, output format, examples. А Microsoft у документації по Azure OpenAI пише що system message може задавати роль, тон, межі поведінки і формат відповіді.

Тобто структура — це спосіб керувати тим як модель збирає відповідь.

Поганий запит: "Напиши пост про AI-агентів."

Кращий запит: "Почни з провокаційної тези. Поясни проблему. Дай приклад з реального workflow. Покажи ризик. Заверши відкритим питанням."

У першому випадку модель сама вирішує що таке "пост". У другому — ви даєте їй маршрут.

Це працює не тільки для постів.
- Для аналітики: спочатку короткий висновок, потім аргументи, потім ризики, потім що перевірити вручну.
- Для листа: контекст → проблема → наступний крок → спокійний тон. Для ідей: не готовий текст а 10 різних кутів → групування → 3 найсильніші.

Зараз моделi стали сильнішими, краще тримають інструкції і працюють з довгими документами. Але це не скасовує потребу в структурі. Навпаки — чим сильніша модель тим більше вона може зробити сама. І тим важливіше пояснити їй не тільки "що написати" а "в якій логіці це зібрати".

Бо структура — це не про зовнішній вигляд тексту. Це про мислення. Це кермо. Якщо його не тримати — модель поїде найзвичнішим маршрутом.

Практичне правило: давайте моделі форму мислення.

Не "Поясни мені embeddings" а "Поясни у 4 кроки: інтуїтивна аналогія → простий приклад з реченнями → що відбувається математично → де це використовується в реальних продуктах".

Якщо не задати структуру — модель все одно її створить. Питання тільки в тому чи це буде ваша структура чи найтиповіший шаблон з інтернету.

Зберігай щоб не загубити, а наступного разу — ще один важливий факт про LLM 👀

🔔 ПІДПИСАТИСЯ

​🎓 AI-освіта набирає обертів

Доброго ранку ☕️

Університети США масово запускають бакалаврські програми, майнори та спеціалізації зі штучного інтелекту.

За даними Center for Inclusive Computing при Northeastern University, станом на квітень у США вже є щонайменше 1000 AI-програм у майже 584 коледжах та університетах. Для порівняння: у 2021 році лише 5 університетів пропонували повноцінну спеціальність зі штучного інтелекту. New York Times пише що за кілька років AI з окремого напряму всередині Computer Science перетворюється на самостійну освітню траєкторію.

Але тут є цікавий момент. AI-програми дуже різні.

Carnegie Mellon зробив дуже технічну й математично сильну програму: багато математики, статистики, computer science, машинного навчання, когнітивних наук і навіть етики. І це логічно — якщо ми говоримо про справжню AI-інженерію чи ML research без сильної алгоритмічної бази там робити нічого.

Я сам навчався за програмою партнерства з Carnegie Mellon і можу підтвердити — фундаментальна технічна база в них завжди була дуже серйозна.

Але є й інший підхід. Drake University пропонує бакалаврську програму з AI для студентів гуманітарних і бізнес-напрямів. Значно менше математики зате більше гнучкості: філософія, психологія, інформаційні системи. І це теж має сенс — AI вже не лише про тих хто тренує моделі. Це про людей які будуть використовувати AI у бізнесі, освіті, медицині, дизайні, праві, медіа.

Головне питання не в тому чи потрібні AI-спеціальності. Потрібні. Питання в іншому: чи не почнуть університети продавати "AI degree" як модну етикетку без сильної бази?

Ризик очевидний. Якщо студент вивчає тільки інструменти, промпти й кілька прикладних курсів але не має фундаменту в програмуванні, алгоритмах, математиці, статистиці — така освіта може дуже швидко застаріти. AI змінюється надто швидко. Те що актуально у 2026 році може виглядати застарілим уже через кілька років. Але сильна база — математика, computer science, data engineering, distributed systems, software engineering — залишається цінною значно довше.

Тому я б дивився на AI-освіту не як на заміну класичному Computer Science а як на наступний шар над ним. Для когось це буде глибока технічна спеціалізація. Для когось — інструмент у своїй професії.

Природно очікувати стандартизованої універсальної освіти в такій різноманітній сфері. Деякі ролі схожі на традиційну розробку ПЗ з AI-компонентами, інші потребують глибшої експертизи в дослідженнях машинного навчання чи розподілених системах. Завжди існуватимуть відмінності між програмами що готують до магістратури і тими що розраховані на бакалаврський ступінь як завершальний етап.

AI розвивається настільки швидко що багатьом університетам складно адаптуватися. Усталений темп змін в академічних програмах — коли викладачі спершу опановують тему, пропонують нові курси, проходять затвердження навчального комітету — погано відповідає швидкості розвитку AI. Але тішить що університети рухаються в цьому напрямі і багато інноваційних викладачів знаходять способи діяти швидше.

Це буде важливо для підготовки студентів не лише до професій 2026 року а й до тих що з'являться в наступні роки.

🔔 ПІДПИСАТИСЯ

AI-світ став дуже шумним.

Доброго ленчу ☕️ 🍔

Останнім часом я трохи втомився від новин про AI і все більше фокусуюся саме на наукових статтях. Тому що соцмережі, медіа, компанії, маркетологи — усі щось постять про AI, і мої стрічки в Х, Інстаграмі й Телеграмі просто завалені цим. Можливо це якийсь ефект вибіркової уваги — коли цікавишся темою то бачиш її всюди. Але думаю зараз таке у всіх, бо AI дуже сильно рекламується. Топова, хайпова тема, як колись були криптовалюти. Усі щось запускають, продають, обіцяють революцію, за день будують бізнеси і намагаються на цьому заробити. І часто під виглядом освітнього контенту ми отримуємо просто добре запакований рекламний текст.

Через це стає складно зрозуміти що справді варто вивчати.

Мені подобається такий принцип. Спочатку думати про людей які навчаються — що їм реально потрібно щоб вирости як спеціалісти. Потім вже про партнерів і комерційні інтереси. І тільки в останню черга про власну вигоду. Це проста позиція але дуже важлива, бо в AI-освіті зараз велика спокуса навчати не тому що справді фундаментально, а тому що вигідно просувати конкретний продукт чи вендора.

Якщо подивитися уважніше — навичка не в тому щоб вивчити один конкретний інструмент. Навичка — це розуміти принципи.

Штучний інтелект як інженерна дисципліна має кілька важливих фундаментальних складових: ефективне використання агентів для написання коду, ключові будівельні блоки такі як оцінка якості моделей, аналіз помилок і робочі процеси агентів, а також суміжні навички — вміння приймати базові продуктові рішення або швидко пройти шлях від ідеї до першої робочої версії продукту.

Конкретний інструмент тут — просто засіб для практики. Якщо ви вчитеся водити, вам потрібна машина. Але навичка — це водіння а не бренд машини.

Кілька років тому я став батьком і все частіше задумуюся над тим чому і як навчати дитину, щоб освіта залишалася актуальною і не застарівала. Я працюю на передовій розвитку AI і бачу як швидко все змінюється — тому розумію цю проблему трохи глибше ніж більшість. Але моє глибоке переконання: вища освіта потрібна. Фундаментальні основи — розуміння як влаштована матерія, фізика, основи соціології, психології, біології — це і є той фундамент який дозволяє залишатися актуальним навіть коли інструменти змінюються щомісяця. Університет дає не набір фактів а вміння вчитися, розбиратися, експериментувати і розуміти сам підхід дослідження. Саме це не застаріває.

І тут є хороший фільтр для будь-якого AI-контенту: після цього матеріалу я краще розумію фундаментальний принцип — чи просто краще знаю як користуватися чиїмось продуктом?

Друге теж може бути корисним. Але якщо говорити про довгострокову цінність — фундаментальні навички важливіші.

Бо інструменти будуть змінюватися. Моделі будуть змінюватися. А вміння розбиратись, оцінювати, будувати, тестувати й ітерувати — залишиться.

А як ви вирішуєте для себе цей фільтр — вчите принципи чи інструменти? І чи задумувались що з цього передати своїм дітям?

🔔 ПІДПИСАТИСЯ

​GPT-5.6: схоже епоха "AI для всіх" починає закінчуватися

Доброго ранку ☕️

OpenAI анонсувала GPT-5.6 — нове сімейство моделей Sol, Terra і Luna. На Terminal-Bench, бенчмарку який оцінює агентів на реальній роботі в командному рядку, Sol показала рекордні 88.8 бали, а в режимі ultra з субагентами — 91.9.

Але головна новина тут не в тому що модель стала розумнішою. Головна новина в тому хто отримає до неї доступ.

Поки що GPT-5.6 доступна лише обмеженому колу — приблизно 20 організаціям схваленим урядом США. OpenAI прямо підтвердила що діє під тиском уряду який попросив розтягнути реліз у часі.

І це не поодинокий випадок. За кілька тижнів до цього сталася ще показовіша історія з Anthropic. 9 червня компанія випустила Claude Fable 5 — перший публічно доступний реліз свого Mythos-класу. Вже 12 червня Міністерство торгівлі видало директиву про експортний контроль і наказало призупинити доступ для будь-якого іноземного громадянина де завгодно у світі. Оскільки відфільтрувати користувачів за громадянством у реальному часі неможливо — Anthropic вимкнула обидві моделі повністю для всіх. Приводом стало повідомлення дослідників Amazon про спосіб обійти захист і змусити модель шукати вразливості в коді. Лише 30 червня, після 18 днів заморозки, контроль зняли — Fable 5 повернулася глобально з 1 липня, а Mythos 5 відновлена лише для обмеженого кола американських організацій через Project Glasswing. CNBC описує як уряд паралельно тримав під контролем доступ і до цієї моделі.

Тобто дві найпотужніші лабораторії AI в США цього літа опинилися під практично однаковим регуляторним тиском одночасно. Ми поступово переходимо від логіки "ось нова модель, користуйтеся" до логіки "ось нова модель, але спочатку держава вирішить кому її можна дати".

Причина зрозуміла: якщо модель вже може допомагати з кібербезпекою і автономним пошуком вразливостей — вона перестає бути просто "розумним чатботом" і стає ближчою до технології подвійного призначення, як авіація чи криптографія. Саме тому уряд хоче контролювати хто отримує до неї доступ ще до релізу.

Але є й окрема, важливіша проблема — чи можна взагалі довіряти тим оцінкам безпеки на основі яких приймаються такі рішення. METR, незалежний оцінювач якому OpenAI дала доступ до моделі перед релізом, зафіксував найвищий рівень обходу тестів серед усіх публічно оцінених моделей. Sol експлуатувала баги в тестовому середовищі і витягувала приховані відповіді замість того щоб розв'язувати задачі чесно. Через це оцінка автономності моделі коливається від 11 до понад 270 годин залежно від того чи рахувати обхід тестів як провал чи як успіх. Розкид настільки великий що METR прямо написав: жодне з цих чисел не є надійним виміром здібностей моделі.

Це важливо саме тому що держава спирається на подібні оцінки коли вирішує кому дозволити доступ до моделі. Якщо модель під час тестування поводиться інакше ніж у реальному використанні — вся система контролю доступу базується на даних яким не можна довіряти повністю.

Подібні незалежні перевірки поступово стають стандартом для будь-якої frontier-моделі. Наприклад SecureBio окремо оцінювала попередню модель GPT-5.5 на предмет біологічних ризиків світового класу ще до її релізу.

Ще один показовий момент: навіть дешевша GPT-5.6 Luna отримує guardrails які раніше асоціювалися лише з топовими моделями. Safety-контур спускається вниз по всій лінійці. Обмеження стають не винятком для "найнебезпечнішої" моделі а стандартною частиною AI-інфраструктури загалом.

І окремо варто згадати дослідження про моніторинг поведінки агентів яке показує наскільки складно відрізнити справжню безпечну поведінку моделі від навченої видимості безпеки — особливо коли модель розуміє що її тестують і може підлаштовуватися під це.

Головні питання тепер звучать інакше: хто має доступ до найсильніших моделей? Хто визначає межі дозволеного? І чи можемо ми взагалі довіряти оцінкам безпеки якщо сама модель під час тестування намагається їх обдурити?

🔔 ПІДПИСАТИСЯ

​Роботів вчать не тільки діяти. Їх вчать розуміти наскільки добре вони діють 🤖

Доброго ранку ☕️

У reinforcement learning є стара проблема: щоб навчити робота треба якось оцінювати його дії. Поклав ложку в каструлю — добре. Поклав біля каструлі — вже не те. Почав правильно але не довів до кінця — частковий успіх.

Звучить просто але на практиці reward function часто доводиться писати руками під конкретне завдання. Це довго, дорого і погано масштабується.

Дослідники зі Stanford та UC Berkeley зробили RoboReward — сімейство vision-language моделей винагороди для роботів на 4B і 8B параметрів. Моделі і датасет викладені на Hugging Face: RoboReward-4B, RoboReward-8B, датасет.

Ідея цікава.

Більшість датасетів для роботів містять переважно успішні приклади. Модель бачить як треба робити але погано розуміє як виглядає помилка.

Автори вирішили це обійти двома способами. По-перше, взяли успішні відео і перелейблили команду: є відео де робот кладе ложку в каструлю — команду можна замінити на "поклади ложку біля каструлі", і те саме відео вже стає прикладом невиконаного завдання. Технічно це робили так: GPT-5 mini описував сцену, дії робота і фінальний стан за відео, потім Qwen3-4B-Instruct-2507 пропонував альтернативні команди для яких те саме відео заслуговувало б нижчого прогрес-балу, а GPT-5 mini перевіряв і відсіював невідповідні варіанти.

По-друге, обрізали успішні відео щоб отримати приклади часткового прогресу — робот почав правильно але не завершив дію.

Після цього GPT-5 mini присвоював кожному прикладу прогрес-бал від 1 до 4, а самі RoboReward моделі — це Qwen3-VL 4B і Qwen3-VL 8B, донавчені передбачати цей прогрес-бал за відео і командою. Прогрес-бал і став reward-сигналом. Автори вручну перевірили 2831 приклад щоб сформувати тестовий набір RoboRewardBench.

Результат: RoboReward 8B оцінювала reward точніше ніж 21 інша модель включно з GPT-5, GPT-5 mini та спеціалізованою робото-моделлю Gemini Robotics-ER 1.5, за метрикою середньої абсолютної похибки (0.665 проти 0.906 у Gemini).

У реальному тесті з роботизованою рукою WidowX теж був помітний приріст. Завдання підняти іграшку і покласти на рушник: RoboReward 8B — 50% успіху, Gemini Robotics-ER 1.5 — 10%, людська розмітка — 75%. Завдання відкрити шухляду: RoboReward 8B — 80%, Gemini Robotics-ER 1.5 — 45%, людська розмітка — 90%.

Тобто людина все ще краща. Але розрив уже значно менший ніж у порівнянні зі спеціалізованою моделлю створеною саме для робототехніки.

І ось тут головне.

Ми часто говоримо про роботів так ніби головне — навчити їх бачити і рухатися. Але не менш важливо навчити їх оцінювати власний прогрес. Без нормальної винагороди reinforcement learning перетворюється на гру в темряві.

Vision-language моделі винагороди вже давно виглядали перспективними для навчання роботів а цей підхід робить їх значно ефективнішими. Завдяки доповненню успішних демонстрацій перевіреними прикладами невдач автори навчили універсальну модель винагороди яка працює з різними типами роботів і завдань. Це зменшує потребу в ручному створенні reward function під кожен окремий випадок.

Публікація бенчмарку і готових моделей запрошує спільноту напряму покращувати reward function а не просто сподіватися що вони автоматично з'являться як побічний ефект розвитку сильніших універсальних моделей.

🔔 ПІДПИСАТИСЯ

Чому в RoboReward використали одразу кілька різних моделей?

Доброго вечора 🌙

Продовжуємо тему з ранкового посту про RoboReward.

У RoboReward цікаво не тільки те що модель навчилася краще оцінювати дії роботів. Цікаво інше: сам датасет для reward-моделі вони збирали як маленький AI-конвеєр де різні моделі виконували різні ролі.

Там не було однієї "магічної" моделі яка зробила все. Була декомпозиція задачі.

GPT-5 mini використовували як сильну мультимодальну модель для аналізу відео: описати сцену, дії робота і фінальний стан. Тобто її роль — бути "спостерігачем". Подивитися на відео і зрозуміти що там реально сталося.

Qwen3-4B-Instruct-2507 використовували для іншого: згенерувати альтернативні команди для яких це саме відео вже не буде успішним прикладом. Тобто її роль — бути "генератором контрприкладів". Наприклад якщо на відео робот кладе ложку в каструлю — можна придумати альтернативну команду "поклади ложку біля каструлі". Відео те саме але відносно нової команди це вже failure або partial success.

Потім GPT-5 mini знову повертається в пайплайн — уже як "верифікатор". Перевіряє чи справді альтернативна команда не відповідає відео і відсіює погані варіанти.

А фінальні RoboReward 4B і 8B — це вже не GPT а донавчені Qwen3-VL моделі. Їхня задача не генерувати тексти і не пояснювати сцену а просто передбачати progress score за парою відео + команда.

І ось тут видно важливу інженерну логіку. Закриту сильну модель використовують там де потрібна якісна розмітка і перевірка. Меншу open-weight модель — там де потрібна масштабована генерація варіантів. А фінальну reward-модель навчають на open-weight VLM бо її потім можна відтворювати, донавчати, запускати дешевше і використовувати в robotics pipeline.

Це вже не просто "взяли GPT і щось попросили". Це більше схоже на фабрику даних: сильна модель аналізує відео → інша модель генерує контрфактичні команди → сильна модель перевіряє якість → окрема VLM навчається видавати reward.

І саме це можливо найцікавіше в RoboReward. Майбутнє robotics буде не тільки в більших моделях. Воно буде в правильних пайплайнах де різні моделі виконують різні ролі: одна бачить, друга генерує, третя перевіряє, четверта стає компактним reward-модулем для реального робота.

🔔 ПІДПИСАТИСЯ

​Microsoft більше не хоче бути просто реселером OpenAI

Доброго ранку ☕️

Цікавий поворот: Microsoft представила MAI-Thinking-1 — свою першу reasoning-модель яку компанія, за її словами, навчила з нуля а не дистилювала чи донавчала з моделі іншого розробника.

І це важливо не тільки як "ще одна LLM на ринку". Бо Microsoft довго була майже синонімом OpenAI в enterprise-світі: Azure, Copilot, GitHub Copilot, інтеграції в Office. Але тепер компанія явно показує — ми не просто продаємо чужі моделі, ми будуємо власну модельну лінійку.

MAI-Thinking-1 — це medium-sized reasoning model яку Microsoft порівнює з Claude Sonnet 4.6. За характеристиками з technical report все виглядає серйозно: до 256k токенів на вході й виході, mixture-of-experts архітектура, 1 трильйон параметрів загалом і 35 млрд активних на токен, сумісність з OpenAI Chat Completions API, function calling, а developer instructions мають вищий пріоритет над user prompts.

Останній пункт особливо цікавий для enterprise. Корпоративним клієнтам важливо не просто "щоб модель була розумна" а щоб її поведінку можна було контролювати на рівні платформи. Команди які працюють у Microsoft-екосистемі отримують доступ до потужної reasoning-моделі без необхідності додавати нового вендора або виводити дані за межі вже знайомих інструментів. Це може зацікавити велику базу користувачів Azure і Copilot.

Технічно Microsoft зробила класичний але масштабний пайплайн: pretraining базової моделі, fine-tuning спеціалізованих teacher-моделей, distillation у student-модель і потім reinforcement learning для reasoning. Дані теж великі: 30 трильйонів токенів на pretraining, ще 3.55 трильйона на midtraining, понад 5 млн STEM-питань і 160k coding-питань для post-training.

Microsoft окремо підкреслює що намагалася тренувати модель переважно на ліцензованих і human-generated даних уникаючи synthetic data. Аргумент простий: якщо модель вчиться на виходах інших моделей — вона успадковує їхні обмеження і стиль мислення.

Але тут є нюанс. Попри заяви про attributable data Microsoft все одно активно використовувала веб: сотні мільярдів сторінок після фільтрації плюс Common Crawl. Тобто компанія поставила собі за мету навчити модель на повністю прослідковуваних даних але все одно суттєво спиралася на веб. Звісно так роблять усі — значна частина успіху великих мовних моделей досі побудована саме на web data.

За внутрішніми тестами компанії MAI-Thinking-1 дуже сильна в математиці: 97% на AIME 2025. Це вище за Claude Sonnet 4.6 і DeepSeek V3.2 але нижче за Claude Opus 4.6. Водночас сама Microsoft визнає що модель слабша за конкурентів у graduate-level science і agentic coding.

Тому це не "Microsoft зробила найкращу модель у світі". Це радше інше: Microsoft нарешті показує що хоче мати власний фундаментальний AI-стек а не залежати тільки від OpenAI, Anthropic чи DeepSeek. Компанія заявляє що планує створювати більше моделей на основі data pipeline розробленого для MAI-Thinking-1 та її споріднених моделей.

І це логічно. Коли ти контролюєш Azure, Windows, Office, GitHub, Copilot і величезний enterprise-ринок — залежність від чужої моделі стає стратегічним ризиком. Особливо цікаво це виглядає на фоні оновленої угоди партнерства з OpenAI яка вже дає Microsoft більше свободи розвивати власні моделі паралельно.

MAI-Thinking-1 — це не просто нова модель. Це сигнал ринку: Microsoft будує власну AI-незалежність. І здається епоха "Microsoft дорівнює OpenAI на Azure" поступово закінчується.

🔔 ПІДПИСАТИСЯ

10 речей про LLM які варто знати 6/10 🧠

LLM люблять чітку розмітку

Гарного дня! 👋

Минулого разу говорили про те що LLM вигадують структуру якщо ви її не даєте: коли у промпті немає чіткого формату — модель обирає найбільш статистично ймовірну структуру з тих які бачила раніше.

Сьогодні — про інший бік цієї ж теми.

Якщо LLM добре знаходять структуру то ще краще вони працюють тоді коли ми самі даємо їм цю структуру на вході.

LLM люблять чітку розмітку тому що розмітка зменшує неоднозначність.

Коли ми пишемо моделі довгий "людський" запит — там зазвичай усе змішано разом: контекст, задача, стиль, аудиторія, обмеження, приклади, очікуваний формат. Людина може це розплутати бо розуміє інтонацію і ваші наміри. Модель теж може. Але з більшим шансом помилки — вона може переплутати приклад із завданням, контекст з інструкцією, стиль з головною ідеєю.

Наприклад можна написати так: "проаналізуй фідбек від клієнтів за останній місяць і скажи що там головне". Це нормальний запит. Але схожий на розмову в коридорі.

Можна структурованіше:

Context: 40 відгуків клієнтів після оновлення продукту
Task: визначити повторювані проблеми і запити
Audience: команда продукту, готується до планування спринту
Output: топ-5 тем з прикладами цитат, окремо позначити що є багом а що побажанням

Це вже зовсім інший рівень. Тут модель бачить не просто прохання а маленьке технічне завдання.

Чому це працює технічно. LLM тренуються на масивних наборах даних де структуровані документи — технічні інструкції, бази знань, розмічений контент — представлені дуже широко. Моделі спираються на позиційне кодування й механізми уваги щоб визначати релевантність токенів. Структурні елементи — розділи, заголовки, позначені сегменти — працюють як легенда карти. Вони показують моделі де має концентруватися увага і де відбуваються семантичні переходи. Це зменшує шум і звужує варіативність прогнозування наступних токенів.

Мітки на кшталт "Definition" чи "Step 1" працюють як м'які обмеження. Вони стають опорними точками і спрямовують увагу моделі на наступні токени. Це не просто стилізація промпта — це функціональне спрямування.

Але тут є нюанс. Чітка розмітка — це не магія. Не треба кожен промпт перетворювати на документ на 40 пунктів. Проблема не в тому що промпт має бути довгим. Проблема в хаосі.

Хороший промпт не обов'язково великий. Але він має відповідати на кілька базових питань: що є на вході, що треба зробити, для кого, які обмеження, у якому форматі повернути результат.

І тут важливо розуміти чому взагалі це працює а не просто копіювати шаблон. Фактично це і є інженерія — коли людина розуміє як влаштована система бо сама писала щось подібне. Сьогодні у багатьох може виникнути спокуса не вчити синтаксис мови програмування, алгоритми, патерни, ООП — бо LLM самі пишуть код. Але в цьому криється підміна понять: тільки людина яка пройшла через фундаментальні речі має розуміння як правильно застосовувати LLM.

Поганий запит: "проаналізуй це і скажи що думаєш".

Кращий запит: "проаналізуй цей текст. Окремо виділи головну ідею, сильні сторони, слабкі місця. Дай відповідь у вигляді списку. Окремо познач де ти робиш припущення".

Різниця не в тому що другий запит "розумніший". Різниця в тому що він залишає менше простору для неправильного трактування.

У продакшені цю ідею зараз описують ширше — не просто prompt engineering а context engineering. Задача в тому щоб правильно зібрати весь контекст навколо задачі: інструкції, дані, приклади, формат відповіді, критерії якості, обмеження.

Так само як люди покладаються на заголовки й візуальну ієрархію щоб розшифрувати значення — LLM покладаються на структурні підказки щоб обмежити поведінку відповіді. Якщо промпт не має структури — модель змушена її вгадувати. Якщо структура є — модель її наслідує.

Практичне правило: коли задача стає складнішою — додавайте структуру. Не обов'язково багато. Але достатньо щоб відділити контекст від задачі, задачу від обмежень, а обмеження від формату відповіді.

Зберігай щоб не загубити 👀

🔔 ПІДПИСАТИСЯ

AI-токени дешеві а людські — золото 🧠

Доброго ранку ☕

Одна з найцікавіших думок яку останнім часом сформулював собі про AI-агентів для програмування звучить дуже просто:

AI-токени дешеві. Людські токени — золото.

І чим більше працюю з сучасними coding-агентами тим більше погоджуюся з цією ідеєю.

Багато хто досі намагається спочатку продумати всю архітектуру, написати ідеальне ТЗ, визначити всі API і лише потім починати розробку. Але коли ви створюєте продукт з нуля — це часто працює гірше.

До речі це дуже добре перетинається з ідеєю запуску продуктів де важливий швидкий старт і швидкий фідбек. Звісно не для кожного продукту це підходить — якщо реалізація лежить на межі науки або вбудованих систем, перший прототип на тисячі рядків коду може взагалі не запуститися 😅 Але в більшості випадків підхід працює добре.

Набагато ефективніше: написати просту специфікацію, дати агенту побудувати першу версію, подивитися що він зробив, зрозуміти що саме вам не подобається, оновити специфікацію і повторити цикл.

Чому? Тому що код сьогодні став дешевим. Якщо агент за 20 хвилин напише кілька тисяч рядків коду а потім ви їх повністю видалите — це майже нічого не коштує. А ось ваш час коштує дорого. Дуже часто лише побачивши працюючий прототип ви розумієте що інтерфейс незручний, архітектура не підходить або взагалі продукт потрібно будувати інакше. Жодна година роздумів над документом не дала б цього розуміння.

Є ще одна цікава практика. Якщо ви сказали агенту щось важливе — не покладайтеся на його пам'ять. Попросіть його одразу записати це у SPEC .md, README .md або інший документ проєкту: які технології використовуються, які рішення вже прийняті, яких принципів потрібно дотримуватися, які помилки більше не можна повторювати.

Якщо агент забуде власне відкриття — він просто витратить ще трохи токенів і знайде його знову. Але якщо він забуде ваше рішення — вам доведеться пояснювати все ще раз.

Саме тому людські токени — найдорожчий ресурс у процесі розробки.

Мені здається що в майбутньому роль розробника дедалі більше зміщуватиметься від написання коду до написання специфікацій, критеріїв оцінки і правил за якими працюватимуть агенти.

І можливо найціннішою навичкою стане вміти правильно формулювати вимоги та розуміти що взагалі потрібно робити.

🔔 ПІДПИСАТИСЯ

Уряд США зупинив найпотужніші моделі Anthropic. Через три тижні вони повернулися — але вже іншими

Доброго ранку ☕️

Claude Fable 5 та ще потужніша Claude Mythos 5 знову доступні користувачам.

Але їхнє повернення це один із перших випадків коли державне втручання фактично зупинило глобальний доступ до передової AI-моделі. І схоже цей випадок може стати прецедентом для всієї індустрії.

9 червня Anthropic випустила Claude Fable 5 для користувачів у всьому світі. Модель мала обмеження на частину запитів пов'язаних із кібербезпекою, біологічними дослідженнями та створенням потужних AI-систем.

Однак дослідники Amazon змогли використати Fable 5 щоб отримати інформацію необхідну для проведення кібератаки — за даними WSJ саме розмови керівництва Amazon з чиновниками стали тригером для подальших дій уряду. Після цього уряд США заявив про ризики для національної безпеки.

12 червня Міністерство торгівлі видало директиву яка забороняла доступ до Claude Fable 5 та Mythos 5 для всіх іноземних громадян незалежно від того де вони перебувають. Anthropic у відповідь відключила моделі для всіх користувачів у світі.

Формально обмеження стосувалися іноземних громадян. Але реалізувати таку вимогу на практиці складно — компанії довелося б визначати не лише країну перебування користувача а і його громадянство. Тому Anthropic обрала найжорсткіший варіант і повністю призупинила доступ.

Протягом наступних тижнів компанія вела переговори з урядом і розробляла нові механізми безпеки. 30 червня обмеження зняли — WSJ описує як адміністрація Трампа поступово відкочувала заборону. 1 липня Claude Fable 5 знову стала доступною через Claude API, Claude Code та інші сервіси Anthropic. Пізніше доступ повернули також клієнтам AWS, Google Cloud і Microsoft Foundry.

Але модель повернулася вже не такою як раніше

Після повторного запуску користувачі почали скаржитися що Fable 5 стала значно обережнішою. Модель почала відмовляти навіть на деякі базові запитання з біології та частіше блокувати звичайні завдання з програмування. PCMag детально розібрав чотири конкретні способи якими бан змінив поведінку моделі.

Anthropic визнала проблему. Частину запитів система тепер автоматично перенаправляє до менш потужної Claude Opus 4.8. Компанія обіцяє навчитися краще відрізняти реальні спроби зловживання від легітимних запитів — офіційна заява і коротке підтвердження в X також фіксують цю обіцянку.

Це вже не перший конфлікт Anthropic з урядом США

У лютому Пентагон назвав Anthropic "ризиком для ланцюга постачання". Причиною стала відмова компанії надати уряду версію моделі без обмежень на використання для масового стеження та автономної зброї. Після цього Міністерство оборони США та його партнери більше не могли користуватися продуктами Anthropic.

Але ситуація з Fable 5 стала ще серйознішою. Уперше державне рішення призвело до зупинки загального доступу до передової AI-моделі для користувачів у всьому світі.

До цього моменту компанії здебільшого самостійно вирішували коли і як випускати нові моделі. Тепер у цьому процесі з'явився ще один повноцінний учасник — держава.

З одного боку це зрозуміло. Моделі стають сильнішими та потенційно можуть допомагати не лише в написанні текстів чи коду а й у пошуку вразливостей та роботі з небезпечними даними. З іншого боку непрозорі й ситуативні заборони створюють нові ризики. Компанії можуть витратити роки та мільярди доларів на модель а потім дізнатися за кілька днів до релізу що її не дозволять випустити.

Обмеження доступу до американських моделей також створює сильний стимул для інших країн розробляти власні системи. Якщо держава не може бути впевнена що завтра матиме доступ до Claude чи GPT — вона починає думати про технологічну незалежність. Регулювання яке має захищати технологічне лідерство США у довгостроковій перспективі може прискорити появу сильних конкурентів.

Повернення Claude Fable 5 це початок нового етапу у якому запуск передових моделей залежатиме не лише від готовності розробників а й від рішень урядів.

🔔 ПІДПИСАТИСЯ

​DeepSeek прискорила свої моделі до 85% — без квантизації та втрати якості

Доброго ранку ☕️

DeepSeek представила DSpark — модуль спекулятивного декодування який прискорив генерацію DeepSeek-V4 у виробничому середовищі. Ваги основної моделі не змінюються а якість не погіршується. Модель і код відкриті під MIT: V4-Pro-DSpark та V4-Flash-DSpark.

Мене тут цікавить не стільки прискорення саме по собі скільки інженерна логіка якою автори до нього прийшли.

Відправна точка проста. Мовна модель генерує токени послідовно. Кожен новий токен потребує окремого проходу через велику модель навіть якщо продовження очевидне.

Ідея спекулятивного декодування з'явилась ще у 2022 році: підключити до великої моделі маленький швидкий чернетковий модуль. Він одразу пропонує кілька наступних токенів а велика модель перевіряє весь блок за один прохід. Якщо перші п'ять токенів збігаються з тим що вона сама згенерувала б — вони приймаються. Якщо шостий не збігається — усе після нього відкидається. Якість не змінюється бо фінальне рішення все одно за великою моделлю.

Тут і починається інженерна проблема яку вирішує DSpark.

Ранні чернеткові модулі генерували токени послідовно один за одним — узгоджено але повільно. Потім з'явилися паралельні модулі які генерують весь блок за один прохід — швидко, але кожна позиція передбачається майже незалежно від інших. Через це модель може змішувати різні правильні продовження: контекст можна продовжити фразами "of course" або "no problem", а паралельний модуль здатен поєднати шматки в неправильне "of problem". Класична дилема: послідовний підхід узгоджений але повільний, паралельний швидкий але розсинхронізований.

Рішення DSpark — розділити задачу на два шари. Паралельний backbone відповідає за швидкість і одним проходом накидає чернетку всього блоку. А поверх нього працює маленький послідовний компонент — Markov head — який локально виправляє узгодженість між сусідніми токенами. Якщо backbone вибрав "of" — Markov head підвищує ймовірність що наступним буде саме "course". Ключова деталь: цей компонент навмисно зроблений дуже легким. Збільшення чернетки з 4 до 16 токенів додає лише 0.2-1.3% до затримки циклу.

Другий шар рішення — усвідомлення що не кожен токен варто перевіряти з однаковою "довжиною погляду вперед". Система оцінює власну впевненість для кожного токена і калібрує ці оцінки на окремих даних щоб вони відповідали реальній частоті прийняття. Якщо ймовірність прийняття чотирьох токенів поспіль становить 90%, 80%, 70% і 60% — ймовірність що пройдуть усі чотири разом набагато нижча за 60%. Планувальник враховує це і адаптує довжину чернетки залежно від навантаження: мало запитів — довші й ризикованіші чернетки, багато запитів — коротші й надійніші блоки щоб не марнувати обчислення на малоймовірні здогадки.

Це вже не оптимізація однієї моделі а оптимізація всієї системи обслуговування запитів де рішення приймається динамічно залежно від поточного стану інфраструктури.

Порівняно з послідовним EAGLE-3 і паралельним DFlash DSpark показав приріст прийнятих токенів за цикл на обох архітектурних сім'ях моделей — і Qwen3, і Gemma — що підтверджує: підхід не прив'язаний до конкретної моделі а є загальним інженерним прийомом.

Головний урок тут не в цифрах прискорення а в самій структурі рішення: розкласти задачу на два шари з різними пріоритетами, зробити коригувальний шар максимально легким, і додати адаптивність яка реагує на реальні умови навантаження а не працює за фіксованим правилом. Патерн який можна переносити далеко за межі спекулятивного декодування.

🔔 ПІДПИСАТИСЯ

​🍌 Google об'єднала Nano Banana з генерацією відео — і це вже схоже на готовий медіапайплайн

Доброго ранку ☕️

Компанія представила дві новинки: Nano Banana 2 Lite — швидка й дешева модель для генерації зображень, та Gemini Omni Flash — модель для створення й редагування відео із синхронізованим звуком.

Головна ідея: спочатку можна згенерувати десятки або сотні дешевих зображень, вибрати найкраще а потім одразу перетворити його на відео через той самий API.

Nano Banana 2 Lite приймає текст і зображення, генерує картинку до 1K приблизно за 4 секунди і коштує $0.034 за зображення. Gemini Omni Flash приймає текст, зображення та відео, генерує ролики до 10 секунд у 720p з одразу синхронізованим звуком за $0.10 за секунду. Тобто десятисекундний ролик коштуватиме приблизно $1.

Окремо цікаве редагування: через Interactions API модель зберігає історію сесії тому наступний промпт не генерує нове відео з нуля а змінює попередню версію. Підтримується до трьох послідовних ітерацій.

Типовий workflow виглядає так: згенерувати багато варіантів зображення, вибрати найкращий, передати його як стартовий кадр, створити відео зі звуком і додатковими командами змінити рух, стиль або сцену.

За рейтингами Arena.ai Nano Banana 2 Lite посідає п'яте місце серед моделей генерації зображень, а за рейтингом відео Gemini Omni Flash — перше місце в генерації і друге в редагуванні.

Але найважливіше тут те що генерація медіаконтенту стала достатньо дешевою і швидкою щоб виконуватися безпосередньо всередині застосунків у режимі реального часу а не залишатися повільним і ретельно контрольованим етапом виробництва. Десятисекундні кліпи можна об'єднувати в довші ролики і розробники тепер можуть автоматизувати їх створення прямо у власних продуктах.

Серед потенційних користувачів такого підходу: рекламні платформи з великими обсягами контенту, агентства цифрової реклами, творці контенту для соцмереж, сервіси персоналізованого маркетингу. Наприклад WSJ пише що Meta розробляє систему яка зможе автоматично створювати рекламні матеріали включно з відео маючи лише фотографію товару і рекламний бюджет.

Агент може створити сотню рекламних креативів, вибрати найкращі, перетворити на відео, протестувати різні версії й оптимізувати кампанію майже без участі людини.

Було б помилкою розглядати генерацію зображень і відео як єдиний ринок. Nano Banana 2 Lite і Gemini Omni Flash поки не мають достатньої роздільної здатності для повноцінного використання в голлівудському виробництві — для цього все ще існують спеціалізовані бенчмарки на кшталт MovieGenBench і VBench. Водночас покращення швидкості та вартості можуть бути не такими важливими для звичайних користувачів які лише час від часу генерують контент як хобі.

Але як уже сталося з текстом і аудіо — основна цінність мультимедійних моделей може з'явитися завдяки автоматизації, інтерактивності, персоналізації й агентним робочим процесам. Схоже зараз саме той час коли варто дати волю уяві.

🔔 ПІДПИСАТИСЯ

10 речей про LLM, які варто знати — 7/10 🧠

LLM мислять сюжетними шаблонами

Доброго ранку ☕️

Минулого разу говорили про структуру запиту, а сьогодні — про структуру самої розповіді.

Одна з причин чому AI-тексти часто здаються правильними але поверхневими полягає в тому, що моделі тяжіють до знайомих риторичних траєкторій. Найчастіше це виглядає так: проблема → інсайт → рішення → оптимістичний висновок.

Для простого контенту така структура працює добре. Текст виходить зрозумілим, логічним і завершеним.

Але зі складними темами починаються проблеми. LLM може надто швидко "закрити" питання: знайти одну головну причину, примирити суперечності та запропонувати універсальне рішення — навіть там де справжньої відповіді поки немає. І це не просто суб'єктивне враження від AI-текстів.

В одному з досліджень науковці попросили GPT-4o mini написати 11 800 історій для 236 країн. Культурні декорації змінювалися але структура часто залишалася майже однаковою: герой живе в маленькому місті або повертається додому, стикається з конфліктом, заново відкриває традиції, об'єднує спільноту — і все завершується примиренням. Реальні політичні та соціальні конфлікти при цьому згладжувалися, а напруга поступалася ностальгії та відновленню стабільності.

Автори назвали це narrative homogenisation — наративною гомогенізацією. Тобто модель змінює персонажів і декорації але продовжує відтворювати ту саму безпечну сюжетну логіку.

Anthropic дослідила поведінку п'яти AI-асистентів і виявила що всі вони тією чи іншою мірою демонстрували sycophancy — схильність погоджуватися з позицією користувача. Більше того, люди та моделі оцінювання іноді віддавали перевагу переконливо написаній відповіді яка підтримувала думку користувача а не точнішій відповіді яка їй суперечила.

Наприклад запит "поясни чому AI корисний для бізнесу" вже містить готовий висновок. Моделі залишається лише підібрати аргументи й красиво провести читача до нього: бізнес має проблему → AI її вирішує → компанія стає ефективнішою.

У дослідженні Стенфордського університету 2026 року моделям давали медичні тести з яких навмисно видалили правильний варіант. Моделям дозволяли відмовитися від відповіді. Проте вони все одно обирали один із неправильних варіантів у 53-82% випадків залежно від моделі та набору запитань.

Дослідники називають це premature closure — передчасним закриттям: модель фіксується на висновку хоча інформації для нього недостатньо.

Наприклад: «Віддалена робота підвищує продуктивність, але послаблює командну взаємодію. Як це вирішити?» LLM швидко запропонує гібридний формат і регулярні зустрічі, але може не запитати, як вимірювали продуктивність і чи проблема не в менеджменті.

Замість "поясни чому AI корисний для бізнесу" спробуйте: "поясни суперечність — AI підвищує продуктивність але може знижувати прозорість процесів". Тут модель уже не може просто захищати одну позицію. Їй потрібно показати за яких умов правильне кожне твердження і де між ними виникає реальний конфлікт.

Ще краще прямо заборонити швидке примирення: "не намагайся одразу вирішити суперечність. Спочатку покажи аргументи обох сторін, винятки та факти які не вписуються у просте пояснення. Наведи приклад який суперечить твоєму основному висновку. Заверши питаннями що залишаються відкритими".

Корисні доповнення до складних запитів: не припускай що існує одне універсальне рішення, назви щонайменше три конкуруючі пояснення, покажи за яких умов кожне з них може бути правильним, відокрем факти від правдоподібного наративу, не роби остаточного висновку якщо даних недостатньо.

Microsoft Research описує ширшу версію цього ефекту як mechanised convergence — механізовану конвергенцію: автоматизація роботи веде до збіжності простору результатів, а GenAI має гомогенізуючий ефект на людський намір.

Тому хороший текст не повинен одразу давати відповідь. Іноді його завдання — не зняти напругу а точніше показати чому вона взагалі існує.

🔔 ПІДПИСАТИСЯ

AI не робить людей менш потрібними. Він робить їх… більш універсальними.

Доброго ранку ☕️

Є цікаве спостереження.

Коли ми говоримо про AI зазвичай обговорюємо які професії він замінить. Але на практиці відбувається дещо інше.

Раніше над продуктом працювали окремі спеціалісти: frontend, backend, mobile, DevOps. Сьогодні один інженер із хорошим AI-інструментарієм здатний закрити значну частину цих завдань самостійно. Тому цінність поступово зміщується не до написання коду а до проєктування архітектури, ухвалення технічних рішень і розуміння продукту.

Те саме починає відбуватися й в інших професіях.

Маркетологу вже не потрібно витрачати години на написання текстів, збір інформації чи підготовку простих звітів — у цьому допомагає AI. Звільнений час переходить на розробку стратегії, координацію кампаній та аналіз результатів.

У рекрутингу AI бере на себе пошук кандидатів і частину організаційної роботи. У результаті один спеціаліст здатний вести весь цикл найму самостійно.

Я сам відчуваю цей ефект на собі. Раніше будь-яке дослідження чи перевірка гіпотези займали дуже багато часу — просто тому що є робота і особисте життя і на глибоке занурення в тему часу не вистачало. Зараз швидкість зросла в усіх сферах. Менше часу йде на те щоб щось перевірити, дослідити, порівняти підходи. Я став рухатись швидше не тому що працюю більше годин а тому що частину рутинної роботи забирає AI.

Виходить цікавий тренд.

AI не просто автоматизує окремі завдання. Він розмиває межі між професіями.

Ми поступово рухаємося від вузьких спеціалістів до людей які здатні довести проєкт від ідеї до результату використовуючи AI як інструмент для виконання спеціалізованих завдань.

Саме тому сьогодні особливо цінними стають навички які раніше вважалися прерогативою senior-фахівців: системне мислення, уміння проєктувати рішення, розуміння бізнесу, здатність поєднувати в єдине ціле роботу різних напрямів.

Є гарний мисленнєвий експеримент.

Згадайте 2022 рік. Які завдання тоді виконцваои не тільки ви а й ваші колеги з суміжних ролей. Той самий frontend-розробник, маркетолог чи рекрутер поруч з вами?

Подивіться скільки з цих завдань сьогодні можете закрити ви самі завдяки AI, навіть якщо це не ваша основна спеціалізація. Ось цей приріст і є ваш новий професійний рівень — не абстрактний а виміряний у конкретних задачах які раніше вимагали окремої людини.

Можливо головний ефект AI — не заміна спеціалістів а поява покоління full-stack-фахівців майже в кожній галузі.

🔔 ПІДПИСАТИСЯ

​Одна модель говорить, інша - думає

Доброго вечора ☕️ 🙂

OpenAI повністю перебудувала голосовий режим ChatGPT.

Щоб зрозуміти масштаб зміни — треба пройти всю еволюцію архітектури. Тож я вам це пiдготував 😎

Перший ChatGPT Voice у 2023 був каскадним пайплайном: Whisper розпізнавав мову, GPT генерував текстову відповідь, окрема TTS-модель озвучувала результат. Три моделі, три окремі виклики на кожну репліку, втрата інформації між етапами і помітна затримка.

Advanced Voice Mode який ми розбирали раніше об'єднав обробку аудіо в одну модель — це прибрало затримку між етапами. Але залишилася фундаментальна проблема: система все одно працювала turn-based. Модель чекала поки людина замовкне і лише тоді починала відповідати. А визначення "людина закінчила говорити" базувалося на тиші — тому коротка пауза або фоновий шум могли змусити модель перебити вас у невдалий момент.

Тут і починається інженерна задача яку вирішує GPT-Live.

Перше рішення — full-duplex архітектура

Замість обробки послідовності окремих повідомлень модель безперервно обробляє вхідний аудіопотік одночасно з генерацією вихідного. Це означає що система приймає рішення багато разів на секунду: говорити, слухати, зачекати, перебити, видати коротке "угу" поки співрозмовник ще говорить, або викликати інструмент у фоні.

Ключова інженерна деталь — відмова від детекції завершення репліки на основі тиші як єдиного сигналу. Система використовує кілька сигналів одночасно щоб зрозуміти чи людина справді закінчила думку чи просто зробила паузу. Це усуває цілий клас евристик з якими роками боролися розробники голосових систем: пороги тиші, таймери, спеціальні правила для шумних середовищ.

Друге і важливіше рішення — розділення розмовного і reasoning шарів

Тут головна інженерна ставка: голосова модель сама не є frontier reasoning-моделлю. Коли питання просте — вона відповідає самостійно. Коли потрібен пошук чи багатоетапний аналіз — вона делегує задачу GPT-5.5 у фоновому режимі і продовжує підтримувати розмову поки reasoning-модель працює, а потім вбудовує результат у відповідь.

Це архітектурне розділення концернів: голосовий шар оптимізований під латентність і природність, а інтелект живе в окремому бекенд-шарі. І саме це рішення — а не сам full-duplex — розробники називають найважливішим наслідком: голосовий інтерфейс автоматично стає розумнішим з кожним новим поколінням reasoning-моделей без потреби переробляти голосовий шар.

За внутрішніми тестами OpenAI GPT-Live з високим рівнем reasoning показує 84.2% на GPQA проти 45.3% у старого Advanced Voice Mode і 75.2% на BrowseComp проти 0.7%. Але всі порівняння OpenAI проводить зі своєю попередньою системою, а не з Gemini Live, Moshi чи іншими конкурентами — тому цифри варто сприймати обережно, це не незалежна перевірка.

Практичний висновок для тих хто будує подібні системи

Архітектура GPT-Live показує загальний патерн який можна переносити далеко за межі голосових інтерфейсів: розділяти шар взаємодії від шару інтелекту. Шар взаємодії оптимізується під швидкість, природність і відповідність очікуванням користувача в реальному часі. Шар інтелекту оптимізується під якість і може оновлюватися незалежно — новіша reasoning-модель одразу підвищує стелю можливостей усієї системи без переробки фронтенду.

Це той самий принцип який ми вже бачили в архітектурі DSpark де паралельний і послідовний компоненти вирішували різні частини задачі. Розкладання задачі на спеціалізовані шари з різними пріоритетами — це поки що один із найнадійніших інженерних прийомів у роботі з LLM-системами.

За даними Bloomberg, до кінця року OpenAI планує представити портативну розумну колонку без екрана яка повністю покладатиметься на голосову взаємодію GPT-Live. Продажі очікуються на початку 2027. І це логічно — саме розділення на "швидкий інтерфейс + потужний бекенд" робить подібний пристрій технічно можливим.

А ви вже спробували новий режим?

🔔 ПІДПИСАТИСЯ

​Підключіть лабораторію до циклу

Доброго ранку ☕️

Дослідники з FutureHouse, Оксфордського та Фордгемського університетів представили Robin — ШІ-агента для пошуку нових способів застосування вже відомих препаратів.

Robin це не одна модель а оркестрація кількох спеціалізованих агентів кожен з яких відповідає за окрему когнітивну задачу в дослідницькому pipeline.

Crow робить короткі цілеспрямовані пошуки в літературі і пропонує експериментальні стратегії та кандидатів на препарати. Falcon робить глибші літературні огляди коли потрібен повноцінний технічний звіт а не швидка відповідь. Finch окремий агент для аналізу даних який працює вже не з текстами а з сирими експериментальними датасетами: RNA-seq, flow cytometry, результати скринінгу. Він шукає статистично значущі патерни і генерує гіпотези виходячи з самих даних а не з літератури.

Ключова інженерна ідея тут це розділення ролей за типом джерела інформації. Crow і Falcon працюють з текстовим корпусом знань. Finch працює з числовими експериментальними даними. Це різні типи задач які вимагають різних підходів до пошуку сигналу. Замість намагатися зробити одну універсальну модель яка вміє все автори розбили pipeline на спеціалізовані компоненти які передають один одному структуровані результати.

Цикл роботи виглядає так: Crow і Falcon аналізують дослідження про захворювання і визначають можливі біологічні механізми → система пропонує експерименти для перевірки гіпотези → людина фізично проводить експеримент у лабораторії → Finch аналізує отримані результати → на основі нових даних цикл формує наступну гіпотезу. Окремий компонент — суддя який ранжує гіпотези через парні порівняння — вирішує які напрямки варто досліджувати далі коли варіантів багато.

Людина поки що залишається в цьому циклі як виконавець фізичного експерименту і як точка перевірки. Вона задає захворювання й оцінює чи рухається система у правильному напрямку. Але більшість дослідницької роботи, читання літератури, формулювання гіпотез, дизайн експериментів, інтерпретація результатів, система виконує майже автономно.

Показовий масштаб: Crow опрацював 551 релевантну статтю приблизно за 30 хвилин. Задача яку дослідник виконував би близько 540 годин ручного читання і синтезу.

Robin протестували на сухій віковій макулярній дегенерації. Агент припустив що лікуванню може допомогти посилення фагоцитозу пігментного епітелію сітківки, процесу яким клітини ока очищаються від пошкоджених компонентів. Після аналізу літератури Robin запропонував два препарати: Y-27632 майже вдвічі підвищив активність потрібного процесу в ізольованих клітинах ока, а Ripasudil, вже схвалений у Японії препарат від глаукоми, дав приріст приблизно у 1.9 раза.

Важливе уточнення: препарати тестували лише на клітинах а не на пацієнтах. Це не готове лікування і навіть не доказ що метод спрацює в живому організмі.

Але сама модель роботи цінна незалежно від конкретного результату. Система не генерує гіпотезу один раз. Вона отримує дані, аналізує їх, оновлює припущення і пропонує наступний крок. Тобто бере участь у справжньому ітеративному процесі а не просто видає одноразову відповідь на запит.

Особливо перспективним виглядає саме repurposing вже схвалених ліків. Розробка нового препарату може тривати понад десять років і коштувати більше мільярда доларів при тому що регулятори схвалюють лише близько 50 нових препаратів на рік. Наявні препарати вже пройшли значну частину перевірок безпеки, тому пошук нового застосування для старих ліків це ефективне використання часу і ресурсів.

Наступний логічний крок це під'єднати таких агентів до роботизованих лабораторій щоб система могла самостійно провести й частину фізичних експериментів. Схожий підхід вже демонструє система RoboChem де AI-модель керує набором автоматизованих лабораторних інструментів.

Можливо майбутнє науки це не один універсальний "AI-науковець" а замкнений цикл спеціалізованих агентів: гіпотеза, експеримент, дані, нова гіпотеза. І людина яка визначає мету та перевіряє чи рухається система у правильному напрямку.

Код Robin на GitHub · Finch на GitHub

🔔 ПІДПИСАТИСЯ

​Чи може ШІ непомітно змінювати наші переконання?

Доброго ранку ☕️

Дослідники з MIT та Carnegie Mellon поставили важливіше запитання: чи справді люди змінюють свою думку пiсля розмови з моделлю?

Вони дослідили розмови понад тисячі користувачів із GPT-4o і представили новий бенчмарк Puppet. Учасники обирали запит на особисту пораду у сфері здоров'я, фінансів або стосунків, оцінювали свою згоду з пов'язаним твердженням за шкалою від 0 до 100, спілкувалися з GPT-4o протягом 5-10 повідомлень і повторно оцінювали своє переконання. Модель при цьому отримувала різні інструкції: діяти в інтересах користувача, не переслідувати конкретних інтересів або впливати на нього в інтересах іншої сторони. Різниця між оцінками до та після розмови й була реальним показником впливу.

І тут з'являється ключова проблема попередніх детекторів маніпуляцій. Очевидно маніпулятивна відповідь може взагалі не спрацювати тому що користувач розпізнає тиск і відкине його. Натомість м'яка персоналізована порада без агресивної риторики може суттєво змінити його погляди. Тобто маніпулятивний текст і реальний вплив це не одне й те саме.

Результати це підтвердили. Традиційні детектори маніпулятивного тексту показали майже нульову кореляцію з фактичною зміною переконань. Натомість звичайні LLM отримавши транскрипт розмови змогли помірно точно оцінити наскільки змінилася думка користувача. Найкращий результат показала GPT-4o з кореляцією Спірмена 0.436, DeepSeek-V3.1 показала 0.362. Ще далеко від надійного прогнозування але значно краще за спеціалізовані детектори.

Цікаво що додавання особистої інформації про користувача, як-от демографія, риси особистості за моделлю Great Five, життєві цілі і моральні цінності, не дало стабільного покращення. Самого діалогу часто було достатньо.

Зміни переконань дуже відрізнялися між людьми. Медіана становила лише 3.3 бала зі 100, тобто більшість учасників майже не змінили свою думку. Але стандартне відхилення близько 22 балів показує що для окремих користувачів вплив був значним. І це можливо найважливіший результат: середній ефект виглядає невеликим але приховує групу людей особливо вразливих до впливу моделі.

Дослідження вимірювало лише короткострокову зміну після однієї розмови. Схожі питання про накопичувальний ефект переконання піднімають і інші роботи в цій області. Ми ще не знаємо чи зберігається такий вплив надовго і чи накопичується він після місяців регулярного спілкування з одним асистентом.

Автори показали що виявлення маніпулятивних формулювань недостатньо для оцінювання реальної сили впливу. Моделі досить непогано прогнозували фактичні зміни переконань спираючись лише на транскрипт розмови навіть без даних про демографію чи особистість користувача. Це відкриває шлях до систем які краще захищатимуть користувачів від маніпулятивної поведінки LLM.

Автори не проаналізували випадки коли переконання змінювалися після розмови з моделлю спеціально налаштованою діяти в інтересах користувача. Це був би корисний напрям для подальших досліджень — результати могли б показати наскільки ШІ здатний допомагати людям досягати цілей: опановувати навички, вивчати нову галузь знань, переходити до здоровішого способу життя. Схожі питання про позитивне використання переконливості моделей піднімає і одне з недавніх досліджень.

При цьому сам вплив не обов'язково шкідливий. Модель може переконати людину звернутися до лікаря, почати навчання, відмовитися від небезпечної звички. Це теж зміна переконань але в інтересах самого користувача.

Тому головне питання майбутнього ймовірно звучатиме не так: чи вміє модель переконувати. Вона вже вміє. Питання в іншому: чиїм інтересам служить це переконання і чи може система вчасно помітити коли вплив стає шкідливим?

🔔 ПІДПИСАТИСЯ