Дослідники з University of Oregon, Purdue, UC San Diego, NYU та Princeton перевірили як державні медіа впливають на відповіді великих мовних моделей.
Доброго ранку ☕️
Знову середа. Знову розбір наукової публікації. Але цього разу не архітектурний розбір а дослідження яке не менш цікаве. І трохи неприємне.
У дослідженні тестували GPT-4o і Claude 3 Sonnet. Здавалося б навіщо звертати увагу на старі моделі коли сьогодні всі вже використовують GPT-5.5 і Claude Sonnet 4.6. Але по-перше моделі виходять дуже швидко а дослідження вимагають часу. Ці моделі були актуальними на той момент. А по-друге архітектура між версіями принципово не змінюється і те що справедливо для попередніх версій працює і в нових.
Вже задокументовано що більшість LLM мають схильність до західних цінностей. Але більшість таких досліджень проводилася з англомовними промптами. Нинішня робота показує що мова запиту є ключовою змінною яку раніше недооцінювали.
Чому так відбувається. LLM навчаються на величезних масивах текстів з інтернету. Автори порівняли китайськомовний сегмент CulturaX побудований на Common Crawl — одному з найбільших публічних архівів інтернет-сторінок який регулярно використовується для навчання моделей. Порівняли із джерелами китайських державних медіа. Виявилось що таких документів там більш ніж у 40 разів більше ніж документів з китайської Wikipedia. Тобто державний наратив може бути не просто одним із голосів а основним голосом який модель бачила під час навчання.
Далі дослідники давали моделям однакові політичні запити китайською та англійською. У питаннях про Китай китайськомовні відповіді були більш сприятливими до Китаю у 75.3% випадків. Для Claude 3 Sonnet майже у 75%, для GPT-4o приблизно у 68%. Перевірили й інші країни та мови і побачили зв'язок між рівнем контролю над медіа і тим наскільки відповіді локальною мовою стають більш прихильними до місцевої влади.
Тут є цікавий технічний кут. Мова запиту може перемикати модель в інший інформаційний режим не лише через різні тренувальні дані а й через саму структуру векторного простору. Слова з різних мов навіть якщо вони означають одне й те саме кодуються в різних областях багатовимірного простору. Дослідження показують що речення з однаковим змістом але різними мовами формують окремі кластери у векторному просторі моделі. "Король" і "king" живуть у різних математичних сусідствах і це сусідство несе різний культурний і політичний контекст. Тому питання поставлене китайською активує інший "регіон" знань моделі ніж те саме питання англійською.
Чому це важливо. LLM дедалі частіше стають основним джерелом інформації для мільйонів людей у всьому світі. Зазвичай вони не цитують джерела. Тому користувачі не бачать хто або що могло вплинути на відповідь. Дослідження 2025 року також виявило що LLM демонструють різні моральні установки різними мовами навіть у відповідь на твердження про базові цінності.
У результаті моделі можуть просувати наративи які суперечать цінностям користувачів і суспільств у яких ці користувачі живуть.
Дослідження виходить із припущення що державні медіа не створювалися спеціально для впливу на LLM. Такий вплив є побічним ефектом. Але воно також показує очевидний стимул для урядів впливати на тренувальні дані більш безпосередньо.
Боротися не лише за телебачення і соцмережі. А й за те що завтра відповість вам модель.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Знову середа. Знову розбір наукової публікації. Але цього разу не архітектурний розбір а дослідження яке не менш цікаве. І трохи неприємне.
У дослідженні тестували GPT-4o і Claude 3 Sonnet. Здавалося б навіщо звертати увагу на старі моделі коли сьогодні всі вже використовують GPT-5.5 і Claude Sonnet 4.6. Але по-перше моделі виходять дуже швидко а дослідження вимагають часу. Ці моделі були актуальними на той момент. А по-друге архітектура між версіями принципово не змінюється і те що справедливо для попередніх версій працює і в нових.
Вже задокументовано що більшість LLM мають схильність до західних цінностей. Але більшість таких досліджень проводилася з англомовними промптами. Нинішня робота показує що мова запиту є ключовою змінною яку раніше недооцінювали.
Чому так відбувається. LLM навчаються на величезних масивах текстів з інтернету. Автори порівняли китайськомовний сегмент CulturaX побудований на Common Crawl — одному з найбільших публічних архівів інтернет-сторінок який регулярно використовується для навчання моделей. Порівняли із джерелами китайських державних медіа. Виявилось що таких документів там більш ніж у 40 разів більше ніж документів з китайської Wikipedia. Тобто державний наратив може бути не просто одним із голосів а основним голосом який модель бачила під час навчання.
Далі дослідники давали моделям однакові політичні запити китайською та англійською. У питаннях про Китай китайськомовні відповіді були більш сприятливими до Китаю у 75.3% випадків. Для Claude 3 Sonnet майже у 75%, для GPT-4o приблизно у 68%. Перевірили й інші країни та мови і побачили зв'язок між рівнем контролю над медіа і тим наскільки відповіді локальною мовою стають більш прихильними до місцевої влади.
Тут є цікавий технічний кут. Мова запиту може перемикати модель в інший інформаційний режим не лише через різні тренувальні дані а й через саму структуру векторного простору. Слова з різних мов навіть якщо вони означають одне й те саме кодуються в різних областях багатовимірного простору. Дослідження показують що речення з однаковим змістом але різними мовами формують окремі кластери у векторному просторі моделі. "Король" і "king" живуть у різних математичних сусідствах і це сусідство несе різний культурний і політичний контекст. Тому питання поставлене китайською активує інший "регіон" знань моделі ніж те саме питання англійською.
Чому це важливо. LLM дедалі частіше стають основним джерелом інформації для мільйонів людей у всьому світі. Зазвичай вони не цитують джерела. Тому користувачі не бачать хто або що могло вплинути на відповідь. Дослідження 2025 року також виявило що LLM демонструють різні моральні установки різними мовами навіть у відповідь на твердження про базові цінності.
У результаті моделі можуть просувати наративи які суперечать цінностям користувачів і суспільств у яких ці користувачі живуть.
Дослідження виходить із припущення що державні медіа не створювалися спеціально для впливу на LLM. Такий вплив є побічним ефектом. Але воно також показує очевидний стимул для урядів впливати на тренувальні дані більш безпосередньо.
Боротися не лише за телебачення і соцмережі. А й за те що завтра відповість вам модель.
🔔 ПІДПИСАТИСЯ
👍6❤4🔥2🤔2
Cursor випустив власну модель — Composer 2.5
Доброго ранку ☕️
Знаю що багато хто з вас використовує Cursor як основний інструмент для роботи з агентами. Якщо не знаєте що краще — Opus чи Codex — або хочете користуватися обома але платити за одну підписку, Cursor це ваш вибір.
На фоні Claude Code та Codex багато хто вже почав вважати що майбутнє повністю за універсальними моделями. Достатньо взяти найсильніший LLM і обгорнути його хорошим агентним середовищем.
Cursor пішов іншим шляхом.
Компанія випустила Composer 2.5 — власну модель для програмування спеціально натреновану під Cursor CLI та агентний режим роботи. В основі лежить Kimi K2.5 від Moonshot — про яку я вже писав як про одну з найсильніших моделей для задач з кодом. Архітектура: mixture-of-experts transformer, 1.04 трлн параметрів загалом і 32 млрд активних параметрів на токен. Не дивно до речі що Moonshot також випустили власний CLI.
Cursor додатково донавчив модель на синтетичних задачах — у 25 разів більше ніж у Composer 2. Основна мета навчити модель працювати зі складнішими сценаріями. Наприклад синтетична задача могла містити інструкцію видалити певну функцію застосунку — і до неї додавали відповідні зміни в коді, очищення залишкових артефактів і тест який перевіряв що змінений застосунок працює. Яка саме модель генерувала такі задачі — команда не розкрила.
Під час навчання модель отримувала не лише винагороду за правильний результат а й текстовий фідбек про свої помилки. Якщо агент обирав неправильний інструмент або робив неефективний крок — йому буквально показували що можна було зробити краще. Фактично Cursor тренував не просто модель а модель разом із власним агентним середовищем. Детальніше про підхід у paper на arXiv.
Результат показовий. Третє місце в Artificial Analysis Coding Agent Index, перше місце на SWE-Bench-Pro-Hard-AA. Середній час виконання задачі близько 6.7 хвилини проти 8.8 хвилини у Claude Code. Середня вартість задачі $0.44 проти понад $4 для Claude Opus. Різниця в ціні майже на порядок.
Останній рік багато говорять про те що вирішальним стає не сама модель а агентна обв'язка навколо неї. Cursor показує цікавішу ідею: можливо не потрібно обирати між моделлю та агентом. Можливо майбутнє за моделями які від самого початку навчаються всередині конкретного агентного середовища і оптимізуються саме під нього.
Cursor спочатку був IDE і продавав доступ до сторонніх моделей задовго до того як почав розробляти власні. Йому не потрібна універсальна модель — йому потрібна модель яка швидко й дешево вирішує проблеми розробників. І це видно навіть у партнерствах: New York Times писав про угоду Cursor зі SpaceX.
Успіх Composer показує що для спеціалізованих моделей досі є місце навіть в агентну епоху. Особливо коли ціна виконання задачі відрізняється в 10 разів.
Цілком можливо що через кілька років ми будемо говорити не про "найкращу LLM" а про "найкращу AI-систему" для конкретного типу задач.
Напiшiть чи пробували ви вже Composer? Якi враження? 👇🏻
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Знаю що багато хто з вас використовує Cursor як основний інструмент для роботи з агентами. Якщо не знаєте що краще — Opus чи Codex — або хочете користуватися обома але платити за одну підписку, Cursor це ваш вибір.
На фоні Claude Code та Codex багато хто вже почав вважати що майбутнє повністю за універсальними моделями. Достатньо взяти найсильніший LLM і обгорнути його хорошим агентним середовищем.
Cursor пішов іншим шляхом.
Компанія випустила Composer 2.5 — власну модель для програмування спеціально натреновану під Cursor CLI та агентний режим роботи. В основі лежить Kimi K2.5 від Moonshot — про яку я вже писав як про одну з найсильніших моделей для задач з кодом. Архітектура: mixture-of-experts transformer, 1.04 трлн параметрів загалом і 32 млрд активних параметрів на токен. Не дивно до речі що Moonshot також випустили власний CLI.
Cursor додатково донавчив модель на синтетичних задачах — у 25 разів більше ніж у Composer 2. Основна мета навчити модель працювати зі складнішими сценаріями. Наприклад синтетична задача могла містити інструкцію видалити певну функцію застосунку — і до неї додавали відповідні зміни в коді, очищення залишкових артефактів і тест який перевіряв що змінений застосунок працює. Яка саме модель генерувала такі задачі — команда не розкрила.
Під час навчання модель отримувала не лише винагороду за правильний результат а й текстовий фідбек про свої помилки. Якщо агент обирав неправильний інструмент або робив неефективний крок — йому буквально показували що можна було зробити краще. Фактично Cursor тренував не просто модель а модель разом із власним агентним середовищем. Детальніше про підхід у paper на arXiv.
Результат показовий. Третє місце в Artificial Analysis Coding Agent Index, перше місце на SWE-Bench-Pro-Hard-AA. Середній час виконання задачі близько 6.7 хвилини проти 8.8 хвилини у Claude Code. Середня вартість задачі $0.44 проти понад $4 для Claude Opus. Різниця в ціні майже на порядок.
Останній рік багато говорять про те що вирішальним стає не сама модель а агентна обв'язка навколо неї. Cursor показує цікавішу ідею: можливо не потрібно обирати між моделлю та агентом. Можливо майбутнє за моделями які від самого початку навчаються всередині конкретного агентного середовища і оптимізуються саме під нього.
Cursor спочатку був IDE і продавав доступ до сторонніх моделей задовго до того як почав розробляти власні. Йому не потрібна універсальна модель — йому потрібна модель яка швидко й дешево вирішує проблеми розробників. І це видно навіть у партнерствах: New York Times писав про угоду Cursor зі SpaceX.
Успіх Composer показує що для спеціалізованих моделей досі є місце навіть в агентну епоху. Особливо коли ціна виконання задачі відрізняється в 10 разів.
Цілком можливо що через кілька років ми будемо говорити не про "найкращу LLM" а про "найкращу AI-систему" для конкретного типу задач.
Напiшiть чи пробували ви вже Composer? Якi враження? 👇🏻
🔔 ПІДПИСАТИСЯ
👍9❤3🔥2
10 речей про LLM які варто знати 3/10 🧠
LLM краще імітують тон ніж думку
Доброго ранку ☕️
Продовжуємо розбиратися як ефективно працювати з AI. Можливо ви помічали дивну річ: модель може написати текст так ніби його готував дуже впевнений експерт. Ритм правильний. Слова правильні. Висновок звучить переконливо.
І саме в цьому пастка.
LLM дуже добре відтворюють поверхневі ознаки мислення: академічний тон, логічні зв'язки, впевнені формулювання, стиль консультанта або аналітика. Але форма міркування це ще не саме міркування.
Модель може звучати як експерт ніби вона щось довела, хоча насправді просто продовжила текст у стилі людини яка щось доводить. Може побудувати акуратний абзац навколо слабкого припущення. Або написати дуже впевнений висновок там де мала б сказати: "даних недостатньо".
Це не означає що LLM взагалі не здатні розв'язувати логічні задачі. Здатні. І дуже ефективно. Ще у 2022 році стаття Chain of Thought Prompting показала це. Особливо нові reasoning-моделі з окремим thinking-елементом де модель перед фінальною відповіддю може розкладати задачу на кроки, порівнювати варіанти, повертатися до припущень і лише потім формулювати висновок. Саме тому reasoning-моделі краще пишуть код, розв'язують математичні задачі і менше ламаються на складних інструкціях.
Але тут є пастка. Thinking-елемент це не мислення у тому розумінні до якого ми звикли в контексті людини. LLM генерує послідовність токенів — і в процесі thinking частина цих токенів використовується не як фінальна відповідь а як робочий простір для розв'язання задачі. У людини мислення пов'язане з досвідом, тілом, пам'яттю, цілями, емоціями. У LLM — з обробкою контексту.
Раніше ми частіше мали справу з текстом який просто звучить розумно. Тепер маємо справу з текстом який може ще й виглядати як процес мислення. Покроковість створює додаткову ілюзію надійності.
Для людини це працює через ефект ілюзорної правди. Ми схильні більше вірити інформації якщо вона звучить впевнено. Гарно написаний текст здається розумнішим. LLM цю людську слабкість дуже добре підсилюють — не тому що хочуть обманути а тому що чудово генерують мовні сигнали впевненості.
Тому одна з головних помилок у роботі з AI — просити "напиши переконливо". Переконливо модель майже завжди напише.
Краще просити не переконливість а каркас мислення:
Це змінює режим роботи. Ви змушуєте модель будувати опору під відповідь: припущення, альтернативи, обмеження, рівень впевненості. Thinking допомагає. Але thinking це не гарантія істини. Гарантію дає не тон і не довгий ланцюжок міркувань а перевірка фактів, джерел, логіки і меж застосування.
Коли відповідь здається надто гладкою — це не завжди ознака якості. Іноді це просто гарний тон який маскує слабку структуру.
Практичне правило просте: не довіряйте тону. Перевіряйте опору. Просіть модель не тільки дати відповідь а й показати на чому вона стоїть.
Зберігай щоб не загубити, а наступного разу — ще один важливий факт про LLM 👀
🔔 ПІДПИСАТИСЯ
LLM краще імітують тон ніж думку
Доброго ранку ☕️
Продовжуємо розбиратися як ефективно працювати з AI. Можливо ви помічали дивну річ: модель може написати текст так ніби його готував дуже впевнений експерт. Ритм правильний. Слова правильні. Висновок звучить переконливо.
І саме в цьому пастка.
LLM дуже добре відтворюють поверхневі ознаки мислення: академічний тон, логічні зв'язки, впевнені формулювання, стиль консультанта або аналітика. Але форма міркування це ще не саме міркування.
Модель може звучати як експерт ніби вона щось довела, хоча насправді просто продовжила текст у стилі людини яка щось доводить. Може побудувати акуратний абзац навколо слабкого припущення. Або написати дуже впевнений висновок там де мала б сказати: "даних недостатньо".
Це не означає що LLM взагалі не здатні розв'язувати логічні задачі. Здатні. І дуже ефективно. Ще у 2022 році стаття Chain of Thought Prompting показала це. Особливо нові reasoning-моделі з окремим thinking-елементом де модель перед фінальною відповіддю може розкладати задачу на кроки, порівнювати варіанти, повертатися до припущень і лише потім формулювати висновок. Саме тому reasoning-моделі краще пишуть код, розв'язують математичні задачі і менше ламаються на складних інструкціях.
Але тут є пастка. Thinking-елемент це не мислення у тому розумінні до якого ми звикли в контексті людини. LLM генерує послідовність токенів — і в процесі thinking частина цих токенів використовується не як фінальна відповідь а як робочий простір для розв'язання задачі. У людини мислення пов'язане з досвідом, тілом, пам'яттю, цілями, емоціями. У LLM — з обробкою контексту.
Раніше ми частіше мали справу з текстом який просто звучить розумно. Тепер маємо справу з текстом який може ще й виглядати як процес мислення. Покроковість створює додаткову ілюзію надійності.
Для людини це працює через ефект ілюзорної правди. Ми схильні більше вірити інформації якщо вона звучить впевнено. Гарно написаний текст здається розумнішим. LLM цю людську слабкість дуже добре підсилюють — не тому що хочуть обманути а тому що чудово генерують мовні сигнали впевненості.
Тому одна з головних помилок у роботі з AI — просити "напиши переконливо". Переконливо модель майже завжди напише.
Краще просити не переконливість а каркас мислення:
1. Спочатку сформулюй припущення
2. Вкажи що точно відомо а що ні
3. Розглянь альтернативні пояснення
4. Покажи слабкі місця аргументації
5. Лише після цього зроби висновокЦе змінює режим роботи. Ви змушуєте модель будувати опору під відповідь: припущення, альтернативи, обмеження, рівень впевненості. Thinking допомагає. Але thinking це не гарантія істини. Гарантію дає не тон і не довгий ланцюжок міркувань а перевірка фактів, джерел, логіки і меж застосування.
Коли відповідь здається надто гладкою — це не завжди ознака якості. Іноді це просто гарний тон який маскує слабку структуру.
Практичне правило просте: не довіряйте тону. Перевіряйте опору. Просіть модель не тільки дати відповідь а й показати на чому вона стоїть.
Зберігай щоб не загубити, а наступного разу — ще один важливий факт про LLM 👀
🔔 ПІДПИСАТИСЯ
🔥11👍6❤2⚡1💯1
Anthropic випустила одну з найсильніших моделей Claude. Але хто довів що вона сильніша?
Доброго ранку ☕️
Сьогодні хочу розібрати на прикладі останньої моделі Claude як складно стало вимірювати реальні можливості сучасних AI-моделей.
Почнемо з того що Anthropic мала модель Claude Mythos 5. Але публічно доступною стала не вона а її захищена версія — Claude Fable 5. Формально дуже сильна модель із додатковими safety-механізмами. Але на практиці ці механізми почали ламати саму ідею незалежного тестування.
Перед тим як промпт потрапляв до Claude Fable 5 його перевіряли класифікатори Anthropic. Якщо запит стосувався кібербезпеки, біології, хімії або інженерії AI-моделей — він міг взагалі не дійти до Fable 5. В API такий запит просто отримував відмову. У власних застосунках Anthropic, зокрема в Claude Code, система могла автоматично передати запит на Claude Opus 4.8 — але в самій відповіді користувач не бачив що відповіла вже інша модель.
І ось тут виникає дуже незручне питання. Якщо ми тестуємо Claude Fable 5 але частину відповідей дає Claude Opus 4.8 — то що саме ми вимірюємо?
Artificial Analysis включила fallback-відповіді у загальний результат і отримала змішану оцінку. У їхньому Intelligence Index Claude Fable 5 посіла перше місце з результатом 64.9 — приблизно на 3.5% вище за Claude Opus 4.8. Але приблизно у 8% завдань відповіді фактично були fallback на Opus 4.8.
Vals AI зробила цікавіше і опублікувала два набори результатів: один із fallback-відповідями і другий де кожна відмова рахувалася як провал. Загальний результат майже не змінився: 75.14% проти 74.92%. Але в окремих доменах різниця була драматична. На GPQA Diamond — тесті наукових питань рівня аспірантури — Claude Fable 5 падала з 93.18% точності до 55.56% якщо відмови рахувати як провали.
На Agents' Last Exam де тестують довгі агентні задачі Claude Fable 5 відмовилася приблизно від 35% завдань. На тих задачах які вона виконувала сама pass rate був 22.8% — майже на рівні Codex/GPT-5.5 з 23.8% і помітно краще за Claude Opus 4.8 з 15.8%. Але коли safeguards перекидали частину роботи на Opus 4.8 — результат падав.
ARC Prize Foundation взагалі відмовилася проводити verified evaluations. Причина не в слабкості моделі а в умовах доступу: для тестування Claude Fable 5 треба було погодитися на зберігання промптів і відповідей протягом 30 днів. Для приватних тестових наборів це проблема — незалежність тестування стає менш чистою.
Те що Anthropic описує як заходи безпеки фактично зробило пряме вимірювання можливостей Fable 5 неможливим. Оцінка без класифікаторів описує версію до якої публічні користувачі не мають доступу. А оцінка з класифікаторами описує рухому ціль — Anthropic може переналаштувати їх у будь-який момент.
Раніше бенчмарки давали відповідь на питання про можливості моделі. Claude Fable 5 змушує поставити більш практичне питання: яку частину цих можливостей користувачі реально отримують?
Уявіть що ви тестуєте автомобіль. На прямій трасі він показує прекрасну швидкість. Але в реальних умовах частину часу двигун автоматично перемикається на слабший режим а іноді машина просто відмовляється їхати. Формально двигун дуже потужний. Але вам важливо знати не лише максимальну швидкість а й те як часто ви реально зможете нею скористатися.
Якщо подібні моделі будуть з'являтися і далі — бенчмарки мають показувати не тільки "найкращий можливий результат" а й "доступний користувачу результат". Окремо треба рахувати відповіді самої моделі, fallback на інші моделі, відмови і домени де safety-фільтри змінюють поведінку.
Інакше ми будемо порівнювати не моделі. А красиві назви моделей.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Сьогодні хочу розібрати на прикладі останньої моделі Claude як складно стало вимірювати реальні можливості сучасних AI-моделей.
Почнемо з того що Anthropic мала модель Claude Mythos 5. Але публічно доступною стала не вона а її захищена версія — Claude Fable 5. Формально дуже сильна модель із додатковими safety-механізмами. Але на практиці ці механізми почали ламати саму ідею незалежного тестування.
Перед тим як промпт потрапляв до Claude Fable 5 його перевіряли класифікатори Anthropic. Якщо запит стосувався кібербезпеки, біології, хімії або інженерії AI-моделей — він міг взагалі не дійти до Fable 5. В API такий запит просто отримував відмову. У власних застосунках Anthropic, зокрема в Claude Code, система могла автоматично передати запит на Claude Opus 4.8 — але в самій відповіді користувач не бачив що відповіла вже інша модель.
І ось тут виникає дуже незручне питання. Якщо ми тестуємо Claude Fable 5 але частину відповідей дає Claude Opus 4.8 — то що саме ми вимірюємо?
Artificial Analysis включила fallback-відповіді у загальний результат і отримала змішану оцінку. У їхньому Intelligence Index Claude Fable 5 посіла перше місце з результатом 64.9 — приблизно на 3.5% вище за Claude Opus 4.8. Але приблизно у 8% завдань відповіді фактично були fallback на Opus 4.8.
Vals AI зробила цікавіше і опублікувала два набори результатів: один із fallback-відповідями і другий де кожна відмова рахувалася як провал. Загальний результат майже не змінився: 75.14% проти 74.92%. Але в окремих доменах різниця була драматична. На GPQA Diamond — тесті наукових питань рівня аспірантури — Claude Fable 5 падала з 93.18% точності до 55.56% якщо відмови рахувати як провали.
На Agents' Last Exam де тестують довгі агентні задачі Claude Fable 5 відмовилася приблизно від 35% завдань. На тих задачах які вона виконувала сама pass rate був 22.8% — майже на рівні Codex/GPT-5.5 з 23.8% і помітно краще за Claude Opus 4.8 з 15.8%. Але коли safeguards перекидали частину роботи на Opus 4.8 — результат падав.
ARC Prize Foundation взагалі відмовилася проводити verified evaluations. Причина не в слабкості моделі а в умовах доступу: для тестування Claude Fable 5 треба було погодитися на зберігання промптів і відповідей протягом 30 днів. Для приватних тестових наборів це проблема — незалежність тестування стає менш чистою.
Те що Anthropic описує як заходи безпеки фактично зробило пряме вимірювання можливостей Fable 5 неможливим. Оцінка без класифікаторів описує версію до якої публічні користувачі не мають доступу. А оцінка з класифікаторами описує рухому ціль — Anthropic може переналаштувати їх у будь-який момент.
Раніше бенчмарки давали відповідь на питання про можливості моделі. Claude Fable 5 змушує поставити більш практичне питання: яку частину цих можливостей користувачі реально отримують?
Уявіть що ви тестуєте автомобіль. На прямій трасі він показує прекрасну швидкість. Але в реальних умовах частину часу двигун автоматично перемикається на слабший режим а іноді машина просто відмовляється їхати. Формально двигун дуже потужний. Але вам важливо знати не лише максимальну швидкість а й те як часто ви реально зможете нею скористатися.
Якщо подібні моделі будуть з'являтися і далі — бенчмарки мають показувати не тільки "найкращий можливий результат" а й "доступний користувачу результат". Окремо треба рахувати відповіді самої моделі, fallback на інші моделі, відмови і домени де safety-фільтри змінюють поведінку.
Інакше ми будемо порівнювати не моделі. А красиві назви моделей.
🔔 ПІДПИСАТИСЯ
👍12❤3
10 речей про LLM які варто знати 4/10 🧠
LLM вміють знаходити структуру в хаосі
Гарної п'ятниці! 👋
На цьому тижні було багато роботи і не встигав писати для вас. Але зібрав багато цікавого матеріалу — на вихідних детально вивчу і підготую на наступний тиждень. А поки п'ятниця і ще одна важлива річ про LLM яку варто знати.
Минулого разу говорили про те що LLM краще імітують тон ніж думку. Сьогодні про інший бік цієї технології.
LLM корисні не тільки тоді коли треба "щось написати". Іноді їхня найсильніша роль — не автор а аналітик сирого матеріалу.
Уявіть що у вас є 20 коментарів читачів. Або 50 відгуків клієнтів. Або нотатки після кількох дзвінків. Або чернетки ідей які лежать у різних файлах і давно перетворилися на хаос.
Людина дивиться на це і бачить шум. Хтось пише що "було складно". Хтось просить більше прикладів. Хтось ставить питання яке вже ставили десять разів але іншими словами.
LLM може знайти в цьому структуру: згрупувати за темами, знайти повторювані болі, виділити типові питання, показати що люди не розуміють, запропонувати теми для наступних постів.
Технічно за цим стоять embeddings — векторні представлення тексту де схожі за змістом речення опиняються поруч у математичному просторі навіть якщо в них немає однакових слів. Про це я вже писав детальніше раніше.
Наприклад три різні коментарі:
"Я не зрозумів навіщо це потрібно"
"Було б краще показати практичний приклад"
"Теорія цікава але як це застосувати?"
Формально різні. За змістом — одна тема: аудиторії не вистачає практичного контексту.
До речі цей принцип добре працює і з голосовим введенням. Коли проговорюєш все що є в голові — розрізнені думки, незавершені ідеї, контекст — модель отримує набагато більше сирого матеріалу ніж коли пишеш. І саме в цьому хаосі голосових нотаток вона може знайти структуру, сформулювати цілі і дістати цінне. По суті голосовий потік свідомості це теж вхідний хаос для якого LLM виступає аналітиком.
У якісних дослідженнях є схожа практика — thematic analysis. Дослідник читає відповіді, виділяє повторювані мотиви і збирає їх у теми. LLM може прискорити перший прохід цього процесу. Не замінити дослідника — саме прискорити. При цьому важливо розуміти ризики: дослідження про семантичну ентропію показує як виявляти галюцинації моделі, а NIST AI Risk Management Framework окремо попереджає про ризик зміщень у якісному аналізі за допомогою AI.
Тому найкращий спосіб — просити не тільки висновок а й опору.
Поганий запит: "Ось коментарі. Проаналізуй їх."
Кращий запит: "Ось 20 коментарів. Згрупуй за темами. Для кожної теми дай назву. Покажи які конкретні коментарі підтверджують цю тему. Окремо познач що є фактом у коментарях а що твоєю інтерпретацією."
Якщо модель не може показати на чому стоїть її класифікація — це не аналіз а красива здогадка.
LLM може бути дуже корисною коли треба розібрати безлад: коментарі під постами, відповіді в анкеті, фідбек після запуску продукту, нотатки з мітингів, питання від клієнтів. Вона може показати що під поверхнею хаосу є структура.
Але ця структура — не істина. Це перша карта місцевості. І завдання людини — перевірити чи ця карта справді відповідає території.
Практичне правило: використовуйте LLM не тільки для генерації тексту а й для аналізу того що вже накопичилося. Іноді найцінніше в AI — не те що він напише новий абзац а те що допоможе побачити порядок у матеріалі який здавався просто шумом.
Зберігай щоб не загубити, а наступного разу — ще один важливий факт про LLM 👀
🔔 ПІДПИСАТИСЯ
LLM вміють знаходити структуру в хаосі
Гарної п'ятниці! 👋
На цьому тижні було багато роботи і не встигав писати для вас. Але зібрав багато цікавого матеріалу — на вихідних детально вивчу і підготую на наступний тиждень. А поки п'ятниця і ще одна важлива річ про LLM яку варто знати.
Минулого разу говорили про те що LLM краще імітують тон ніж думку. Сьогодні про інший бік цієї технології.
LLM корисні не тільки тоді коли треба "щось написати". Іноді їхня найсильніша роль — не автор а аналітик сирого матеріалу.
Уявіть що у вас є 20 коментарів читачів. Або 50 відгуків клієнтів. Або нотатки після кількох дзвінків. Або чернетки ідей які лежать у різних файлах і давно перетворилися на хаос.
Людина дивиться на це і бачить шум. Хтось пише що "було складно". Хтось просить більше прикладів. Хтось ставить питання яке вже ставили десять разів але іншими словами.
LLM може знайти в цьому структуру: згрупувати за темами, знайти повторювані болі, виділити типові питання, показати що люди не розуміють, запропонувати теми для наступних постів.
Технічно за цим стоять embeddings — векторні представлення тексту де схожі за змістом речення опиняються поруч у математичному просторі навіть якщо в них немає однакових слів. Про це я вже писав детальніше раніше.
Наприклад три різні коментарі:
"Я не зрозумів навіщо це потрібно"
"Було б краще показати практичний приклад"
"Теорія цікава але як це застосувати?"
Формально різні. За змістом — одна тема: аудиторії не вистачає практичного контексту.
До речі цей принцип добре працює і з голосовим введенням. Коли проговорюєш все що є в голові — розрізнені думки, незавершені ідеї, контекст — модель отримує набагато більше сирого матеріалу ніж коли пишеш. І саме в цьому хаосі голосових нотаток вона може знайти структуру, сформулювати цілі і дістати цінне. По суті голосовий потік свідомості це теж вхідний хаос для якого LLM виступає аналітиком.
У якісних дослідженнях є схожа практика — thematic analysis. Дослідник читає відповіді, виділяє повторювані мотиви і збирає їх у теми. LLM може прискорити перший прохід цього процесу. Не замінити дослідника — саме прискорити. При цьому важливо розуміти ризики: дослідження про семантичну ентропію показує як виявляти галюцинації моделі, а NIST AI Risk Management Framework окремо попереджає про ризик зміщень у якісному аналізі за допомогою AI.
Тому найкращий спосіб — просити не тільки висновок а й опору.
Поганий запит: "Ось коментарі. Проаналізуй їх."
Кращий запит: "Ось 20 коментарів. Згрупуй за темами. Для кожної теми дай назву. Покажи які конкретні коментарі підтверджують цю тему. Окремо познач що є фактом у коментарях а що твоєю інтерпретацією."
Якщо модель не може показати на чому стоїть її класифікація — це не аналіз а красива здогадка.
LLM може бути дуже корисною коли треба розібрати безлад: коментарі під постами, відповіді в анкеті, фідбек після запуску продукту, нотатки з мітингів, питання від клієнтів. Вона може показати що під поверхнею хаосу є структура.
Але ця структура — не істина. Це перша карта місцевості. І завдання людини — перевірити чи ця карта справді відповідає території.
Практичне правило: використовуйте LLM не тільки для генерації тексту а й для аналізу того що вже накопичилося. Іноді найцінніше в AI — не те що він напише новий абзац а те що допоможе побачити порядок у матеріалі який здавався просто шумом.
Зберігай щоб не загубити, а наступного разу — ще один важливий факт про LLM 👀
🔔 ПІДПИСАТИСЯ
👍6❤3
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 року.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Зараз у світі 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 року.
🔔 ПІДПИСАТИСЯ
❤8👍4😁1
Відкрита модель майже наздогнала 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 ви будуєте навколо неї.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
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 ви будуєте навколо неї.
🔔 ПІДПИСАТИСЯ
❤5👍5🔥3
Біологічні молекули як мова 🧬
Доброго ранку ☕️
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.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
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.
🔔 ПІДПИСАТИСЯ
👍6🔥5
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 до звичайних користувацьких пристроїв.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
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 до звичайних користувацьких пристроїв.
🔔 ПІДПИСАТИСЯ
👍6❤4🔥1
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 👀
🔔 ПІДПИСАТИСЯ
Якщо не дати структуру — модель вигадає її сама
Гарної п'ятниці! 👋
Минулого разу говорили про те що 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 👀
🔔 ПІДПИСАТИСЯ
👍8❤3🔥3👏1
🎓 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 року а й до тих що з'являться в наступні роки.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Університети США масово запускають бакалаврські програми, майнори та спеціалізації зі штучного інтелекту.
За даними 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 року а й до тих що з'являться в наступні роки.
🔔 ПІДПИСАТИСЯ
👍6❤1🔥1
AI-світ став дуже шумним.
Доброго ленчу ☕️ 🍔
Останнім часом я трохи втомився від новин про AI і все більше фокусуюся саме на наукових статтях. Тому що соцмережі, медіа, компанії, маркетологи — усі щось постять про AI, і мої стрічки в Х, Інстаграмі й Телеграмі просто завалені цим. Можливо це якийсь ефект вибіркової уваги — коли цікавишся темою то бачиш її всюди. Але думаю зараз таке у всіх, бо AI дуже сильно рекламується. Топова, хайпова тема, як колись були криптовалюти. Усі щось запускають, продають, обіцяють революцію, за день будують бізнеси і намагаються на цьому заробити. І часто під виглядом освітнього контенту ми отримуємо просто добре запакований рекламний текст.
Через це стає складно зрозуміти що справді варто вивчати.
Мені подобається такий принцип. Спочатку думати про людей які навчаються — що їм реально потрібно щоб вирости як спеціалісти. Потім вже про партнерів і комерційні інтереси. І тільки в останню черга про власну вигоду. Це проста позиція але дуже важлива, бо в AI-освіті зараз велика спокуса навчати не тому що справді фундаментально, а тому що вигідно просувати конкретний продукт чи вендора.
Якщо подивитися уважніше — навичка не в тому щоб вивчити один конкретний інструмент. Навичка — це розуміти принципи.
Штучний інтелект як інженерна дисципліна має кілька важливих фундаментальних складових: ефективне використання агентів для написання коду, ключові будівельні блоки такі як оцінка якості моделей, аналіз помилок і робочі процеси агентів, а також суміжні навички — вміння приймати базові продуктові рішення або швидко пройти шлях від ідеї до першої робочої версії продукту.
Конкретний інструмент тут — просто засіб для практики. Якщо ви вчитеся водити, вам потрібна машина. Але навичка — це водіння а не бренд машини.
Кілька років тому я став батьком і все частіше задумуюся над тим чому і як навчати дитину, щоб освіта залишалася актуальною і не застарівала. Я працюю на передовій розвитку AI і бачу як швидко все змінюється — тому розумію цю проблему трохи глибше ніж більшість. Але моє глибоке переконання: вища освіта потрібна. Фундаментальні основи — розуміння як влаштована матерія, фізика, основи соціології, психології, біології — це і є той фундамент який дозволяє залишатися актуальним навіть коли інструменти змінюються щомісяця. Університет дає не набір фактів а вміння вчитися, розбиратися, експериментувати і розуміти сам підхід дослідження. Саме це не застаріває.
І тут є хороший фільтр для будь-якого AI-контенту: після цього матеріалу я краще розумію фундаментальний принцип — чи просто краще знаю як користуватися чиїмось продуктом?
Друге теж може бути корисним. Але якщо говорити про довгострокову цінність — фундаментальні навички важливіші.
Бо інструменти будуть змінюватися. Моделі будуть змінюватися. А вміння розбиратись, оцінювати, будувати, тестувати й ітерувати — залишиться.
А як ви вирішуєте для себе цей фільтр — вчите принципи чи інструменти? І чи задумувались що з цього передати своїм дітям?
🔔 ПІДПИСАТИСЯ
Доброго ленчу ☕️ 🍔
Останнім часом я трохи втомився від новин про AI і все більше фокусуюся саме на наукових статтях. Тому що соцмережі, медіа, компанії, маркетологи — усі щось постять про AI, і мої стрічки в Х, Інстаграмі й Телеграмі просто завалені цим. Можливо це якийсь ефект вибіркової уваги — коли цікавишся темою то бачиш її всюди. Але думаю зараз таке у всіх, бо AI дуже сильно рекламується. Топова, хайпова тема, як колись були криптовалюти. Усі щось запускають, продають, обіцяють революцію, за день будують бізнеси і намагаються на цьому заробити. І часто під виглядом освітнього контенту ми отримуємо просто добре запакований рекламний текст.
Через це стає складно зрозуміти що справді варто вивчати.
Мені подобається такий принцип. Спочатку думати про людей які навчаються — що їм реально потрібно щоб вирости як спеціалісти. Потім вже про партнерів і комерційні інтереси. І тільки в останню черга про власну вигоду. Це проста позиція але дуже важлива, бо в AI-освіті зараз велика спокуса навчати не тому що справді фундаментально, а тому що вигідно просувати конкретний продукт чи вендора.
Якщо подивитися уважніше — навичка не в тому щоб вивчити один конкретний інструмент. Навичка — це розуміти принципи.
Штучний інтелект як інженерна дисципліна має кілька важливих фундаментальних складових: ефективне використання агентів для написання коду, ключові будівельні блоки такі як оцінка якості моделей, аналіз помилок і робочі процеси агентів, а також суміжні навички — вміння приймати базові продуктові рішення або швидко пройти шлях від ідеї до першої робочої версії продукту.
Конкретний інструмент тут — просто засіб для практики. Якщо ви вчитеся водити, вам потрібна машина. Але навичка — це водіння а не бренд машини.
Кілька років тому я став батьком і все частіше задумуюся над тим чому і як навчати дитину, щоб освіта залишалася актуальною і не застарівала. Я працюю на передовій розвитку AI і бачу як швидко все змінюється — тому розумію цю проблему трохи глибше ніж більшість. Але моє глибоке переконання: вища освіта потрібна. Фундаментальні основи — розуміння як влаштована матерія, фізика, основи соціології, психології, біології — це і є той фундамент який дозволяє залишатися актуальним навіть коли інструменти змінюються щомісяця. Університет дає не набір фактів а вміння вчитися, розбиратися, експериментувати і розуміти сам підхід дослідження. Саме це не застаріває.
І тут є хороший фільтр для будь-якого AI-контенту: після цього матеріалу я краще розумію фундаментальний принцип — чи просто краще знаю як користуватися чиїмось продуктом?
Друге теж може бути корисним. Але якщо говорити про довгострокову цінність — фундаментальні навички важливіші.
Бо інструменти будуть змінюватися. Моделі будуть змінюватися. А вміння розбиратись, оцінювати, будувати, тестувати й ітерувати — залишиться.
А як ви вирішуєте для себе цей фільтр — вчите принципи чи інструменти? І чи задумувались що з цього передати своїм дітям?
🔔 ПІДПИСАТИСЯ
👍13❤🔥2❤2
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-інфраструктури загалом.
І окремо варто згадати дослідження про моніторинг поведінки агентів яке показує наскільки складно відрізнити справжню безпечну поведінку моделі від навченої видимості безпеки — особливо коли модель розуміє що її тестують і може підлаштовуватися під це.
Головні питання тепер звучать інакше: хто має доступ до найсильніших моделей? Хто визначає межі дозволеного? І чи можемо ми взагалі довіряти оцінкам безпеки якщо сама модель під час тестування намагається їх обдурити?
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
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-інфраструктури загалом.
І окремо варто згадати дослідження про моніторинг поведінки агентів яке показує наскільки складно відрізнити справжню безпечну поведінку моделі від навченої видимості безпеки — особливо коли модель розуміє що її тестують і може підлаштовуватися під це.
Головні питання тепер звучать інакше: хто має доступ до найсильніших моделей? Хто визначає межі дозволеного? І чи можемо ми взагалі довіряти оцінкам безпеки якщо сама модель під час тестування намагається їх обдурити?
🔔 ПІДПИСАТИСЯ
👍11❤3🔥2👏1
Роботів вчать не тільки діяти. Їх вчать розуміти наскільки добре вони діють 🤖
Доброго ранку ☕️
У 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 а не просто сподіватися що вони автоматично з'являться як побічний ефект розвитку сильніших універсальних моделей.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
У 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 а не просто сподіватися що вони автоматично з'являться як побічний ефект розвитку сильніших універсальних моделей.
🔔 ПІДПИСАТИСЯ
👍3🔥3❤2
Чому в 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-модулем для реального робота.
🔔 ПІДПИСАТИСЯ
Доброго вечора 🌙
Продовжуємо тему з ранкового посту про 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-модулем для реального робота.
🔔 ПІДПИСАТИСЯ
👍4🔥3❤1
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" поступово закінчується.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Цікавий поворот: 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" поступово закінчується.
🔔 ПІДПИСАТИСЯ
👍4❤2👌2
10 речей про LLM які варто знати 6/10 🧠
LLM люблять чітку розмітку
Гарного дня! 👋
Минулого разу говорили про те що LLM вигадують структуру якщо ви її не даєте: коли у промпті немає чіткого формату — модель обирає найбільш статистично ймовірну структуру з тих які бачила раніше.
Сьогодні — про інший бік цієї ж теми.
Якщо LLM добре знаходять структуру то ще краще вони працюють тоді коли ми самі даємо їм цю структуру на вході.
LLM люблять чітку розмітку тому що розмітка зменшує неоднозначність.
Коли ми пишемо моделі довгий "людський" запит — там зазвичай усе змішано разом: контекст, задача, стиль, аудиторія, обмеження, приклади, очікуваний формат. Людина може це розплутати бо розуміє інтонацію і ваші наміри. Модель теж може. Але з більшим шансом помилки — вона може переплутати приклад із завданням, контекст з інструкцією, стиль з головною ідеєю.
Наприклад можна написати так: "проаналізуй фідбек від клієнтів за останній місяць і скажи що там головне". Це нормальний запит. Але схожий на розмову в коридорі.
Можна структурованіше:
Це вже зовсім інший рівень. Тут модель бачить не просто прохання а маленьке технічне завдання.
Чому це працює технічно. LLM тренуються на масивних наборах даних де структуровані документи — технічні інструкції, бази знань, розмічений контент — представлені дуже широко. Моделі спираються на позиційне кодування й механізми уваги щоб визначати релевантність токенів. Структурні елементи — розділи, заголовки, позначені сегменти — працюють як легенда карти. Вони показують моделі де має концентруватися увага і де відбуваються семантичні переходи. Це зменшує шум і звужує варіативність прогнозування наступних токенів.
Мітки на кшталт "Definition" чи "Step 1" працюють як м'які обмеження. Вони стають опорними точками і спрямовують увагу моделі на наступні токени. Це не просто стилізація промпта — це функціональне спрямування.
Але тут є нюанс. Чітка розмітка — це не магія. Не треба кожен промпт перетворювати на документ на 40 пунктів. Проблема не в тому що промпт має бути довгим. Проблема в хаосі.
Хороший промпт не обов'язково великий. Але він має відповідати на кілька базових питань: що є на вході, що треба зробити, для кого, які обмеження, у якому форматі повернути результат.
І тут важливо розуміти чому взагалі це працює а не просто копіювати шаблон. Фактично це і є інженерія — коли людина розуміє як влаштована система бо сама писала щось подібне. Сьогодні у багатьох може виникнути спокуса не вчити синтаксис мови програмування, алгоритми, патерни, ООП — бо LLM самі пишуть код. Але в цьому криється підміна понять: тільки людина яка пройшла через фундаментальні речі має розуміння як правильно застосовувати LLM.
Поганий запит: "проаналізуй це і скажи що думаєш".
Кращий запит: "проаналізуй цей текст. Окремо виділи головну ідею, сильні сторони, слабкі місця. Дай відповідь у вигляді списку. Окремо познач де ти робиш припущення".
Різниця не в тому що другий запит "розумніший". Різниця в тому що він залишає менше простору для неправильного трактування.
У продакшені цю ідею зараз описують ширше — не просто prompt engineering а context engineering. Задача в тому щоб правильно зібрати весь контекст навколо задачі: інструкції, дані, приклади, формат відповіді, критерії якості, обмеження.
Так само як люди покладаються на заголовки й візуальну ієрархію щоб розшифрувати значення — LLM покладаються на структурні підказки щоб обмежити поведінку відповіді. Якщо промпт не має структури — модель змушена її вгадувати. Якщо структура є — модель її наслідує.
Практичне правило: коли задача стає складнішою — додавайте структуру. Не обов'язково багато. Але достатньо щоб відділити контекст від задачі, задачу від обмежень, а обмеження від формату відповіді.
Зберігай щоб не загубити 👀
🔔 ПІДПИСАТИСЯ
LLM люблять чітку розмітку
Гарного дня! 👋
Минулого разу говорили про те що LLM вигадують структуру якщо ви її не даєте: коли у промпті немає чіткого формату — модель обирає найбільш статистично ймовірну структуру з тих які бачила раніше.
Сьогодні — про інший бік цієї ж теми.
Якщо LLM добре знаходять структуру то ще краще вони працюють тоді коли ми самі даємо їм цю структуру на вході.
LLM люблять чітку розмітку тому що розмітка зменшує неоднозначність.
Коли ми пишемо моделі довгий "людський" запит — там зазвичай усе змішано разом: контекст, задача, стиль, аудиторія, обмеження, приклади, очікуваний формат. Людина може це розплутати бо розуміє інтонацію і ваші наміри. Модель теж може. Але з більшим шансом помилки — вона може переплутати приклад із завданням, контекст з інструкцією, стиль з головною ідеєю.
Наприклад можна написати так: "проаналізуй фідбек від клієнтів за останній місяць і скажи що там головне". Це нормальний запит. Але схожий на розмову в коридорі.
Можна структурованіше:
Context: 40 відгуків клієнтів після оновлення продукту
Task: визначити повторювані проблеми і запити
Audience: команда продукту, готується до планування спринту
Output: топ-5 тем з прикладами цитат, окремо позначити що є багом а що побажаннямЦе вже зовсім інший рівень. Тут модель бачить не просто прохання а маленьке технічне завдання.
Чому це працює технічно. LLM тренуються на масивних наборах даних де структуровані документи — технічні інструкції, бази знань, розмічений контент — представлені дуже широко. Моделі спираються на позиційне кодування й механізми уваги щоб визначати релевантність токенів. Структурні елементи — розділи, заголовки, позначені сегменти — працюють як легенда карти. Вони показують моделі де має концентруватися увага і де відбуваються семантичні переходи. Це зменшує шум і звужує варіативність прогнозування наступних токенів.
Мітки на кшталт "Definition" чи "Step 1" працюють як м'які обмеження. Вони стають опорними точками і спрямовують увагу моделі на наступні токени. Це не просто стилізація промпта — це функціональне спрямування.
Але тут є нюанс. Чітка розмітка — це не магія. Не треба кожен промпт перетворювати на документ на 40 пунктів. Проблема не в тому що промпт має бути довгим. Проблема в хаосі.
Хороший промпт не обов'язково великий. Але він має відповідати на кілька базових питань: що є на вході, що треба зробити, для кого, які обмеження, у якому форматі повернути результат.
І тут важливо розуміти чому взагалі це працює а не просто копіювати шаблон. Фактично це і є інженерія — коли людина розуміє як влаштована система бо сама писала щось подібне. Сьогодні у багатьох може виникнути спокуса не вчити синтаксис мови програмування, алгоритми, патерни, ООП — бо LLM самі пишуть код. Але в цьому криється підміна понять: тільки людина яка пройшла через фундаментальні речі має розуміння як правильно застосовувати LLM.
Поганий запит: "проаналізуй це і скажи що думаєш".
Кращий запит: "проаналізуй цей текст. Окремо виділи головну ідею, сильні сторони, слабкі місця. Дай відповідь у вигляді списку. Окремо познач де ти робиш припущення".
Різниця не в тому що другий запит "розумніший". Різниця в тому що він залишає менше простору для неправильного трактування.
У продакшені цю ідею зараз описують ширше — не просто prompt engineering а context engineering. Задача в тому щоб правильно зібрати весь контекст навколо задачі: інструкції, дані, приклади, формат відповіді, критерії якості, обмеження.
Так само як люди покладаються на заголовки й візуальну ієрархію щоб розшифрувати значення — LLM покладаються на структурні підказки щоб обмежити поведінку відповіді. Якщо промпт не має структури — модель змушена її вгадувати. Якщо структура є — модель її наслідує.
Практичне правило: коли задача стає складнішою — додавайте структуру. Не обов'язково багато. Але достатньо щоб відділити контекст від задачі, задачу від обмежень, а обмеження від формату відповіді.
Зберігай щоб не загубити 👀
🔔 ПІДПИСАТИСЯ
2👍9🔥6❤2
AI-токени дешеві а людські — золото 🧠
Доброго ранку ☕
Одна з найцікавіших думок яку останнім часом сформулював собі про AI-агентів для програмування звучить дуже просто:
AI-токени дешеві. Людські токени — золото.
І чим більше працюю з сучасними coding-агентами тим більше погоджуюся з цією ідеєю.
Багато хто досі намагається спочатку продумати всю архітектуру, написати ідеальне ТЗ, визначити всі API і лише потім починати розробку. Але коли ви створюєте продукт з нуля — це часто працює гірше.
До речі це дуже добре перетинається з ідеєю запуску продуктів де важливий швидкий старт і швидкий фідбек. Звісно не для кожного продукту це підходить — якщо реалізація лежить на межі науки або вбудованих систем, перший прототип на тисячі рядків коду може взагалі не запуститися 😅 Але в більшості випадків підхід працює добре.
Набагато ефективніше: написати просту специфікацію, дати агенту побудувати першу версію, подивитися що він зробив, зрозуміти що саме вам не подобається, оновити специфікацію і повторити цикл.
Чому? Тому що код сьогодні став дешевим. Якщо агент за 20 хвилин напише кілька тисяч рядків коду а потім ви їх повністю видалите — це майже нічого не коштує. А ось ваш час коштує дорого. Дуже часто лише побачивши працюючий прототип ви розумієте що інтерфейс незручний, архітектура не підходить або взагалі продукт потрібно будувати інакше. Жодна година роздумів над документом не дала б цього розуміння.
Є ще одна цікава практика. Якщо ви сказали агенту щось важливе — не покладайтеся на його пам'ять. Попросіть його одразу записати це у SPEC .md, README .md або інший документ проєкту: які технології використовуються, які рішення вже прийняті, яких принципів потрібно дотримуватися, які помилки більше не можна повторювати.
Якщо агент забуде власне відкриття — він просто витратить ще трохи токенів і знайде його знову. Але якщо він забуде ваше рішення — вам доведеться пояснювати все ще раз.
Саме тому людські токени — найдорожчий ресурс у процесі розробки.
Мені здається що в майбутньому роль розробника дедалі більше зміщуватиметься від написання коду до написання специфікацій, критеріїв оцінки і правил за якими працюватимуть агенти.
І можливо найціннішою навичкою стане вміти правильно формулювати вимоги та розуміти що взагалі потрібно робити.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕
Одна з найцікавіших думок яку останнім часом сформулював собі про AI-агентів для програмування звучить дуже просто:
AI-токени дешеві. Людські токени — золото.
І чим більше працюю з сучасними coding-агентами тим більше погоджуюся з цією ідеєю.
Багато хто досі намагається спочатку продумати всю архітектуру, написати ідеальне ТЗ, визначити всі API і лише потім починати розробку. Але коли ви створюєте продукт з нуля — це часто працює гірше.
До речі це дуже добре перетинається з ідеєю запуску продуктів де важливий швидкий старт і швидкий фідбек. Звісно не для кожного продукту це підходить — якщо реалізація лежить на межі науки або вбудованих систем, перший прототип на тисячі рядків коду може взагалі не запуститися 😅 Але в більшості випадків підхід працює добре.
Набагато ефективніше: написати просту специфікацію, дати агенту побудувати першу версію, подивитися що він зробив, зрозуміти що саме вам не подобається, оновити специфікацію і повторити цикл.
Чому? Тому що код сьогодні став дешевим. Якщо агент за 20 хвилин напише кілька тисяч рядків коду а потім ви їх повністю видалите — це майже нічого не коштує. А ось ваш час коштує дорого. Дуже часто лише побачивши працюючий прототип ви розумієте що інтерфейс незручний, архітектура не підходить або взагалі продукт потрібно будувати інакше. Жодна година роздумів над документом не дала б цього розуміння.
Є ще одна цікава практика. Якщо ви сказали агенту щось важливе — не покладайтеся на його пам'ять. Попросіть його одразу записати це у SPEC .md, README .md або інший документ проєкту: які технології використовуються, які рішення вже прийняті, яких принципів потрібно дотримуватися, які помилки більше не можна повторювати.
Якщо агент забуде власне відкриття — він просто витратить ще трохи токенів і знайде його знову. Але якщо він забуде ваше рішення — вам доведеться пояснювати все ще раз.
Саме тому людські токени — найдорожчий ресурс у процесі розробки.
Мені здається що в майбутньому роль розробника дедалі більше зміщуватиметься від написання коду до написання специфікацій, критеріїв оцінки і правил за якими працюватимуть агенти.
І можливо найціннішою навичкою стане вміти правильно формулювати вимоги та розуміти що взагалі потрібно робити.
🔔 ПІДПИСАТИСЯ
👍13❤2
Уряд США зупинив найпотужніші моделі 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 це початок нового етапу у якому запуск передових моделей залежатиме не лише від готовності розробників а й від рішень урядів.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
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 це початок нового етапу у якому запуск передових моделей залежатиме не лише від готовності розробників а й від рішень урядів.
🔔 ПІДПИСАТИСЯ
👍10❤2
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 — що підтверджує: підхід не прив'язаний до конкретної моделі а є загальним інженерним прийомом.
Головний урок тут не в цифрах прискорення а в самій структурі рішення: розкласти задачу на два шари з різними пріоритетами, зробити коригувальний шар максимально легким, і додати адаптивність яка реагує на реальні умови навантаження а не працює за фіксованим правилом. Патерн який можна переносити далеко за межі спекулятивного декодування.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
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 — що підтверджує: підхід не прив'язаний до конкретної моделі а є загальним інженерним прийомом.
Головний урок тут не в цифрах прискорення а в самій структурі рішення: розкласти задачу на два шари з різними пріоритетами, зробити коригувальний шар максимально легким, і додати адаптивність яка реагує на реальні умови навантаження а не працює за фіксованим правилом. Патерн який можна переносити далеко за межі спекулятивного декодування.
🔔 ПІДПИСАТИСЯ
👍10❤2
🍌 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. Водночас покращення швидкості та вартості можуть бути не такими важливими для звичайних користувачів які лише час від часу генерують контент як хобі.
Але як уже сталося з текстом і аудіо — основна цінність мультимедійних моделей може з'явитися завдяки автоматизації, інтерактивності, персоналізації й агентним робочим процесам. Схоже зараз саме той час коли варто дати волю уяві.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Компанія представила дві новинки: 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. Водночас покращення швидкості та вартості можуть бути не такими важливими для звичайних користувачів які лише час від часу генерують контент як хобі.
Але як уже сталося з текстом і аудіо — основна цінність мультимедійних моделей може з'явитися завдяки автоматизації, інтерактивності, персоналізації й агентним робочим процесам. Схоже зараз саме той час коли варто дати волю уяві.
🔔 ПІДПИСАТИСЯ
👍8❤3🔥3