10 речей про LLM, які варто знати — 7/10 🧠
LLM мислять сюжетними шаблонами
Доброго ранку ☕️
Минулого разу говорили про структуру запиту, а сьогодні — про структуру самої розповіді.
Одна з причин чому AI-тексти часто здаються правильними але поверхневими полягає в тому, що моделі тяжіють до знайомих риторичних траєкторій. Найчастіше це виглядає так: проблема → інсайт → рішення → оптимістичний висновок.
Для простого контенту така структура працює добре. Текст виходить зрозумілим, логічним і завершеним.
Але зі складними темами починаються проблеми. LLM може надто швидко "закрити" питання: знайти одну головну причину, примирити суперечності та запропонувати універсальне рішення — навіть там де справжньої відповіді поки немає. І це не просто суб'єктивне враження від AI-текстів.
В одному з досліджень науковці попросили GPT-4o mini написати 11 800 історій для 236 країн. Культурні декорації змінювалися але структура часто залишалася майже однаковою: герой живе в маленькому місті або повертається додому, стикається з конфліктом, заново відкриває традиції, об'єднує спільноту — і все завершується примиренням. Реальні політичні та соціальні конфлікти при цьому згладжувалися, а напруга поступалася ностальгії та відновленню стабільності.
Автори назвали це narrative homogenisation — наративною гомогенізацією. Тобто модель змінює персонажів і декорації але продовжує відтворювати ту саму безпечну сюжетну логіку.
Anthropic дослідила поведінку п'яти AI-асистентів і виявила що всі вони тією чи іншою мірою демонстрували sycophancy — схильність погоджуватися з позицією користувача. Більше того, люди та моделі оцінювання іноді віддавали перевагу переконливо написаній відповіді яка підтримувала думку користувача а не точнішій відповіді яка їй суперечила.
Наприклад запит "поясни чому AI корисний для бізнесу" вже містить готовий висновок. Моделі залишається лише підібрати аргументи й красиво провести читача до нього: бізнес має проблему → AI її вирішує → компанія стає ефективнішою.
У дослідженні Стенфордського університету 2026 року моделям давали медичні тести з яких навмисно видалили правильний варіант. Моделям дозволяли відмовитися від відповіді. Проте вони все одно обирали один із неправильних варіантів у 53-82% випадків залежно від моделі та набору запитань.
Дослідники називають це premature closure — передчасним закриттям: модель фіксується на висновку хоча інформації для нього недостатньо.
Наприклад: «Віддалена робота підвищує продуктивність, але послаблює командну взаємодію. Як це вирішити?» LLM швидко запропонує гібридний формат і регулярні зустрічі, але може не запитати, як вимірювали продуктивність і чи проблема не в менеджменті.
Замість "поясни чому AI корисний для бізнесу" спробуйте: "поясни суперечність — AI підвищує продуктивність але може знижувати прозорість процесів". Тут модель уже не може просто захищати одну позицію. Їй потрібно показати за яких умов правильне кожне твердження і де між ними виникає реальний конфлікт.
Ще краще прямо заборонити швидке примирення: "не намагайся одразу вирішити суперечність. Спочатку покажи аргументи обох сторін, винятки та факти які не вписуються у просте пояснення. Наведи приклад який суперечить твоєму основному висновку. Заверши питаннями що залишаються відкритими".
Корисні доповнення до складних запитів: не припускай що існує одне універсальне рішення, назви щонайменше три конкуруючі пояснення, покажи за яких умов кожне з них може бути правильним, відокрем факти від правдоподібного наративу, не роби остаточного висновку якщо даних недостатньо.
Microsoft Research описує ширшу версію цього ефекту як mechanised convergence — механізовану конвергенцію: автоматизація роботи веде до збіжності простору результатів, а GenAI має гомогенізуючий ефект на людський намір.
Тому хороший текст не повинен одразу давати відповідь. Іноді його завдання — не зняти напругу а точніше показати чому вона взагалі існує.
🔔 ПІДПИСАТИСЯ
LLM мислять сюжетними шаблонами
Доброго ранку ☕️
Минулого разу говорили про структуру запиту, а сьогодні — про структуру самої розповіді.
Одна з причин чому AI-тексти часто здаються правильними але поверхневими полягає в тому, що моделі тяжіють до знайомих риторичних траєкторій. Найчастіше це виглядає так: проблема → інсайт → рішення → оптимістичний висновок.
Для простого контенту така структура працює добре. Текст виходить зрозумілим, логічним і завершеним.
Але зі складними темами починаються проблеми. LLM може надто швидко "закрити" питання: знайти одну головну причину, примирити суперечності та запропонувати універсальне рішення — навіть там де справжньої відповіді поки немає. І це не просто суб'єктивне враження від AI-текстів.
В одному з досліджень науковці попросили GPT-4o mini написати 11 800 історій для 236 країн. Культурні декорації змінювалися але структура часто залишалася майже однаковою: герой живе в маленькому місті або повертається додому, стикається з конфліктом, заново відкриває традиції, об'єднує спільноту — і все завершується примиренням. Реальні політичні та соціальні конфлікти при цьому згладжувалися, а напруга поступалася ностальгії та відновленню стабільності.
Автори назвали це narrative homogenisation — наративною гомогенізацією. Тобто модель змінює персонажів і декорації але продовжує відтворювати ту саму безпечну сюжетну логіку.
Anthropic дослідила поведінку п'яти AI-асистентів і виявила що всі вони тією чи іншою мірою демонстрували sycophancy — схильність погоджуватися з позицією користувача. Більше того, люди та моделі оцінювання іноді віддавали перевагу переконливо написаній відповіді яка підтримувала думку користувача а не точнішій відповіді яка їй суперечила.
Наприклад запит "поясни чому AI корисний для бізнесу" вже містить готовий висновок. Моделі залишається лише підібрати аргументи й красиво провести читача до нього: бізнес має проблему → AI її вирішує → компанія стає ефективнішою.
У дослідженні Стенфордського університету 2026 року моделям давали медичні тести з яких навмисно видалили правильний варіант. Моделям дозволяли відмовитися від відповіді. Проте вони все одно обирали один із неправильних варіантів у 53-82% випадків залежно від моделі та набору запитань.
Дослідники називають це premature closure — передчасним закриттям: модель фіксується на висновку хоча інформації для нього недостатньо.
Наприклад: «Віддалена робота підвищує продуктивність, але послаблює командну взаємодію. Як це вирішити?» LLM швидко запропонує гібридний формат і регулярні зустрічі, але може не запитати, як вимірювали продуктивність і чи проблема не в менеджменті.
Замість "поясни чому AI корисний для бізнесу" спробуйте: "поясни суперечність — AI підвищує продуктивність але може знижувати прозорість процесів". Тут модель уже не може просто захищати одну позицію. Їй потрібно показати за яких умов правильне кожне твердження і де між ними виникає реальний конфлікт.
Ще краще прямо заборонити швидке примирення: "не намагайся одразу вирішити суперечність. Спочатку покажи аргументи обох сторін, винятки та факти які не вписуються у просте пояснення. Наведи приклад який суперечить твоєму основному висновку. Заверши питаннями що залишаються відкритими".
Корисні доповнення до складних запитів: не припускай що існує одне універсальне рішення, назви щонайменше три конкуруючі пояснення, покажи за яких умов кожне з них може бути правильним, відокрем факти від правдоподібного наративу, не роби остаточного висновку якщо даних недостатньо.
Microsoft Research описує ширшу версію цього ефекту як mechanised convergence — механізовану конвергенцію: автоматизація роботи веде до збіжності простору результатів, а GenAI має гомогенізуючий ефект на людський намір.
Тому хороший текст не повинен одразу давати відповідь. Іноді його завдання — не зняти напругу а точніше показати чому вона взагалі існує.
🔔 ПІДПИСАТИСЯ
1👍10❤1🔥1👏1
AI не робить людей менш потрібними. Він робить їх… більш універсальними.
Доброго ранку ☕️
Є цікаве спостереження.
Коли ми говоримо про AI зазвичай обговорюємо які професії він замінить. Але на практиці відбувається дещо інше.
Раніше над продуктом працювали окремі спеціалісти: frontend, backend, mobile, DevOps. Сьогодні один інженер із хорошим AI-інструментарієм здатний закрити значну частину цих завдань самостійно. Тому цінність поступово зміщується не до написання коду а до проєктування архітектури, ухвалення технічних рішень і розуміння продукту.
Те саме починає відбуватися й в інших професіях.
Маркетологу вже не потрібно витрачати години на написання текстів, збір інформації чи підготовку простих звітів — у цьому допомагає AI. Звільнений час переходить на розробку стратегії, координацію кампаній та аналіз результатів.
У рекрутингу AI бере на себе пошук кандидатів і частину організаційної роботи. У результаті один спеціаліст здатний вести весь цикл найму самостійно.
Я сам відчуваю цей ефект на собі. Раніше будь-яке дослідження чи перевірка гіпотези займали дуже багато часу — просто тому що є робота і особисте життя і на глибоке занурення в тему часу не вистачало. Зараз швидкість зросла в усіх сферах. Менше часу йде на те щоб щось перевірити, дослідити, порівняти підходи. Я став рухатись швидше не тому що працюю більше годин а тому що частину рутинної роботи забирає AI.
Виходить цікавий тренд.
AI не просто автоматизує окремі завдання. Він розмиває межі між професіями.
Ми поступово рухаємося від вузьких спеціалістів до людей які здатні довести проєкт від ідеї до результату використовуючи AI як інструмент для виконання спеціалізованих завдань.
Саме тому сьогодні особливо цінними стають навички які раніше вважалися прерогативою senior-фахівців: системне мислення, уміння проєктувати рішення, розуміння бізнесу, здатність поєднувати в єдине ціле роботу різних напрямів.
Є гарний мисленнєвий експеримент.
Згадайте 2022 рік. Які завдання тоді виконцваои не тільки ви а й ваші колеги з суміжних ролей. Той самий frontend-розробник, маркетолог чи рекрутер поруч з вами?
Подивіться скільки з цих завдань сьогодні можете закрити ви самі завдяки AI, навіть якщо це не ваша основна спеціалізація. Ось цей приріст і є ваш новий професійний рівень — не абстрактний а виміряний у конкретних задачах які раніше вимагали окремої людини.
Можливо головний ефект AI — не заміна спеціалістів а поява покоління full-stack-фахівців майже в кожній галузі.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Є цікаве спостереження.
Коли ми говоримо про AI зазвичай обговорюємо які професії він замінить. Але на практиці відбувається дещо інше.
Раніше над продуктом працювали окремі спеціалісти: frontend, backend, mobile, DevOps. Сьогодні один інженер із хорошим AI-інструментарієм здатний закрити значну частину цих завдань самостійно. Тому цінність поступово зміщується не до написання коду а до проєктування архітектури, ухвалення технічних рішень і розуміння продукту.
Те саме починає відбуватися й в інших професіях.
Маркетологу вже не потрібно витрачати години на написання текстів, збір інформації чи підготовку простих звітів — у цьому допомагає AI. Звільнений час переходить на розробку стратегії, координацію кампаній та аналіз результатів.
У рекрутингу AI бере на себе пошук кандидатів і частину організаційної роботи. У результаті один спеціаліст здатний вести весь цикл найму самостійно.
Я сам відчуваю цей ефект на собі. Раніше будь-яке дослідження чи перевірка гіпотези займали дуже багато часу — просто тому що є робота і особисте життя і на глибоке занурення в тему часу не вистачало. Зараз швидкість зросла в усіх сферах. Менше часу йде на те щоб щось перевірити, дослідити, порівняти підходи. Я став рухатись швидше не тому що працюю більше годин а тому що частину рутинної роботи забирає AI.
Виходить цікавий тренд.
AI не просто автоматизує окремі завдання. Він розмиває межі між професіями.
Ми поступово рухаємося від вузьких спеціалістів до людей які здатні довести проєкт від ідеї до результату використовуючи AI як інструмент для виконання спеціалізованих завдань.
Саме тому сьогодні особливо цінними стають навички які раніше вважалися прерогативою senior-фахівців: системне мислення, уміння проєктувати рішення, розуміння бізнесу, здатність поєднувати в єдине ціле роботу різних напрямів.
Є гарний мисленнєвий експеримент.
Згадайте 2022 рік. Які завдання тоді виконцваои не тільки ви а й ваші колеги з суміжних ролей. Той самий frontend-розробник, маркетолог чи рекрутер поруч з вами?
Подивіться скільки з цих завдань сьогодні можете закрити ви самі завдяки AI, навіть якщо це не ваша основна спеціалізація. Ось цей приріст і є ваш новий професійний рівень — не абстрактний а виміряний у конкретних задачах які раніше вимагали окремої людини.
Можливо головний ефект AI — не заміна спеціалістів а поява покоління full-stack-фахівців майже в кожній галузі.
🔔 ПІДПИСАТИСЯ
❤9👍7💯1
Одна модель говорить, інша - думає
Доброго вечора ☕️ 🙂
OpenAI повністю перебудувала голосовий режим ChatGPT.
Щоб зрозуміти масштаб зміни — треба пройти всю еволюцію архітектури. Тож я вам це пiдготував 😎
Перший ChatGPT Voice у 2023 був каскадним пайплайном: Whisper розпізнавав мову, GPT генерував текстову відповідь, окрема TTS-модель озвучувала результат. Три моделі, три окремі виклики на кожну репліку, втрата інформації між етапами і помітна затримка.
Advanced Voice Mode який ми розбирали раніше об'єднав обробку аудіо в одну модель — це прибрало затримку між етапами. Але залишилася фундаментальна проблема: система все одно працювала turn-based. Модель чекала поки людина замовкне і лише тоді починала відповідати. А визначення "людина закінчила говорити" базувалося на тиші — тому коротка пауза або фоновий шум могли змусити модель перебити вас у невдалий момент.
Тут і починається інженерна задача яку вирішує GPT-Live.
Перше рішення — full-duplex архітектура
Замість обробки послідовності окремих повідомлень модель безперервно обробляє вхідний аудіопотік одночасно з генерацією вихідного. Це означає що система приймає рішення багато разів на секунду: говорити, слухати, зачекати, перебити, видати коротке "угу" поки співрозмовник ще говорить, або викликати інструмент у фоні.
Ключова інженерна деталь — відмова від детекції завершення репліки на основі тиші як єдиного сигналу. Система використовує кілька сигналів одночасно щоб зрозуміти чи людина справді закінчила думку чи просто зробила паузу. Це усуває цілий клас евристик з якими роками боролися розробники голосових систем: пороги тиші, таймери, спеціальні правила для шумних середовищ.
Друге і важливіше рішення — розділення розмовного і reasoning шарів
Тут головна інженерна ставка: голосова модель сама не є frontier reasoning-моделлю. Коли питання просте — вона відповідає самостійно. Коли потрібен пошук чи багатоетапний аналіз — вона делегує задачу GPT-5.5 у фоновому режимі і продовжує підтримувати розмову поки reasoning-модель працює, а потім вбудовує результат у відповідь.
Це архітектурне розділення концернів: голосовий шар оптимізований під латентність і природність, а інтелект живе в окремому бекенд-шарі. І саме це рішення — а не сам full-duplex — розробники називають найважливішим наслідком: голосовий інтерфейс автоматично стає розумнішим з кожним новим поколінням reasoning-моделей без потреби переробляти голосовий шар.
За внутрішніми тестами OpenAI GPT-Live з високим рівнем reasoning показує 84.2% на GPQA проти 45.3% у старого Advanced Voice Mode і 75.2% на BrowseComp проти 0.7%. Але всі порівняння OpenAI проводить зі своєю попередньою системою, а не з Gemini Live, Moshi чи іншими конкурентами — тому цифри варто сприймати обережно, це не незалежна перевірка.
Практичний висновок для тих хто будує подібні системи
Архітектура GPT-Live показує загальний патерн який можна переносити далеко за межі голосових інтерфейсів: розділяти шар взаємодії від шару інтелекту. Шар взаємодії оптимізується під швидкість, природність і відповідність очікуванням користувача в реальному часі. Шар інтелекту оптимізується під якість і може оновлюватися незалежно — новіша reasoning-модель одразу підвищує стелю можливостей усієї системи без переробки фронтенду.
Це той самий принцип який ми вже бачили в архітектурі DSpark де паралельний і послідовний компоненти вирішували різні частини задачі. Розкладання задачі на спеціалізовані шари з різними пріоритетами — це поки що один із найнадійніших інженерних прийомів у роботі з LLM-системами.
За даними Bloomberg, до кінця року OpenAI планує представити портативну розумну колонку без екрана яка повністю покладатиметься на голосову взаємодію GPT-Live. Продажі очікуються на початку 2027. І це логічно — саме розділення на "швидкий інтерфейс + потужний бекенд" робить подібний пристрій технічно можливим.
А ви вже спробували новий режим?
🔔 ПІДПИСАТИСЯ
Доброго вечора ☕️ 🙂
OpenAI повністю перебудувала голосовий режим ChatGPT.
Щоб зрозуміти масштаб зміни — треба пройти всю еволюцію архітектури. Тож я вам це пiдготував 😎
Перший ChatGPT Voice у 2023 був каскадним пайплайном: Whisper розпізнавав мову, GPT генерував текстову відповідь, окрема TTS-модель озвучувала результат. Три моделі, три окремі виклики на кожну репліку, втрата інформації між етапами і помітна затримка.
Advanced Voice Mode який ми розбирали раніше об'єднав обробку аудіо в одну модель — це прибрало затримку між етапами. Але залишилася фундаментальна проблема: система все одно працювала turn-based. Модель чекала поки людина замовкне і лише тоді починала відповідати. А визначення "людина закінчила говорити" базувалося на тиші — тому коротка пауза або фоновий шум могли змусити модель перебити вас у невдалий момент.
Тут і починається інженерна задача яку вирішує GPT-Live.
Перше рішення — full-duplex архітектура
Замість обробки послідовності окремих повідомлень модель безперервно обробляє вхідний аудіопотік одночасно з генерацією вихідного. Це означає що система приймає рішення багато разів на секунду: говорити, слухати, зачекати, перебити, видати коротке "угу" поки співрозмовник ще говорить, або викликати інструмент у фоні.
Ключова інженерна деталь — відмова від детекції завершення репліки на основі тиші як єдиного сигналу. Система використовує кілька сигналів одночасно щоб зрозуміти чи людина справді закінчила думку чи просто зробила паузу. Це усуває цілий клас евристик з якими роками боролися розробники голосових систем: пороги тиші, таймери, спеціальні правила для шумних середовищ.
Друге і важливіше рішення — розділення розмовного і reasoning шарів
Тут головна інженерна ставка: голосова модель сама не є frontier reasoning-моделлю. Коли питання просте — вона відповідає самостійно. Коли потрібен пошук чи багатоетапний аналіз — вона делегує задачу GPT-5.5 у фоновому режимі і продовжує підтримувати розмову поки reasoning-модель працює, а потім вбудовує результат у відповідь.
Це архітектурне розділення концернів: голосовий шар оптимізований під латентність і природність, а інтелект живе в окремому бекенд-шарі. І саме це рішення — а не сам full-duplex — розробники називають найважливішим наслідком: голосовий інтерфейс автоматично стає розумнішим з кожним новим поколінням reasoning-моделей без потреби переробляти голосовий шар.
За внутрішніми тестами OpenAI GPT-Live з високим рівнем reasoning показує 84.2% на GPQA проти 45.3% у старого Advanced Voice Mode і 75.2% на BrowseComp проти 0.7%. Але всі порівняння OpenAI проводить зі своєю попередньою системою, а не з Gemini Live, Moshi чи іншими конкурентами — тому цифри варто сприймати обережно, це не незалежна перевірка.
Практичний висновок для тих хто будує подібні системи
Архітектура GPT-Live показує загальний патерн який можна переносити далеко за межі голосових інтерфейсів: розділяти шар взаємодії від шару інтелекту. Шар взаємодії оптимізується під швидкість, природність і відповідність очікуванням користувача в реальному часі. Шар інтелекту оптимізується під якість і може оновлюватися незалежно — новіша reasoning-модель одразу підвищує стелю можливостей усієї системи без переробки фронтенду.
Це той самий принцип який ми вже бачили в архітектурі DSpark де паралельний і послідовний компоненти вирішували різні частини задачі. Розкладання задачі на спеціалізовані шари з різними пріоритетами — це поки що один із найнадійніших інженерних прийомів у роботі з LLM-системами.
За даними Bloomberg, до кінця року OpenAI планує представити портативну розумну колонку без екрана яка повністю покладатиметься на голосову взаємодію GPT-Live. Продажі очікуються на початку 2027. І це логічно — саме розділення на "швидкий інтерфейс + потужний бекенд" робить подібний пристрій технічно можливим.
А ви вже спробували новий режим?
🔔 ПІДПИСАТИСЯ
👍7❤6
Підключіть лабораторію до циклу
Доброго ранку ☕️
Дослідники з FutureHouse, Оксфордського та Фордгемського університетів представили Robin — ШІ-агента для пошуку нових способів застосування вже відомих препаратів.
Robin це не одна модель а оркестрація кількох спеціалізованих агентів кожен з яких відповідає за окрему когнітивну задачу в дослідницькому pipeline.
Crow робить короткі цілеспрямовані пошуки в літературі і пропонує експериментальні стратегії та кандидатів на препарати. Falcon робить глибші літературні огляди коли потрібен повноцінний технічний звіт а не швидка відповідь. Finch окремий агент для аналізу даних який працює вже не з текстами а з сирими експериментальними датасетами: RNA-seq, flow cytometry, результати скринінгу. Він шукає статистично значущі патерни і генерує гіпотези виходячи з самих даних а не з літератури.
Ключова інженерна ідея тут це розділення ролей за типом джерела інформації. Crow і Falcon працюють з текстовим корпусом знань. Finch працює з числовими експериментальними даними. Це різні типи задач які вимагають різних підходів до пошуку сигналу. Замість намагатися зробити одну універсальну модель яка вміє все автори розбили pipeline на спеціалізовані компоненти які передають один одному структуровані результати.
Цикл роботи виглядає так: Crow і Falcon аналізують дослідження про захворювання і визначають можливі біологічні механізми → система пропонує експерименти для перевірки гіпотези → людина фізично проводить експеримент у лабораторії → Finch аналізує отримані результати → на основі нових даних цикл формує наступну гіпотезу. Окремий компонент — суддя який ранжує гіпотези через парні порівняння — вирішує які напрямки варто досліджувати далі коли варіантів багато.
Людина поки що залишається в цьому циклі як виконавець фізичного експерименту і як точка перевірки. Вона задає захворювання й оцінює чи рухається система у правильному напрямку. Але більшість дослідницької роботи, читання літератури, формулювання гіпотез, дизайн експериментів, інтерпретація результатів, система виконує майже автономно.
Показовий масштаб: Crow опрацював 551 релевантну статтю приблизно за 30 хвилин. Задача яку дослідник виконував би близько 540 годин ручного читання і синтезу.
Robin протестували на сухій віковій макулярній дегенерації. Агент припустив що лікуванню може допомогти посилення фагоцитозу пігментного епітелію сітківки, процесу яким клітини ока очищаються від пошкоджених компонентів. Після аналізу літератури Robin запропонував два препарати: Y-27632 майже вдвічі підвищив активність потрібного процесу в ізольованих клітинах ока, а Ripasudil, вже схвалений у Японії препарат від глаукоми, дав приріст приблизно у 1.9 раза.
Важливе уточнення: препарати тестували лише на клітинах а не на пацієнтах. Це не готове лікування і навіть не доказ що метод спрацює в живому організмі.
Але сама модель роботи цінна незалежно від конкретного результату. Система не генерує гіпотезу один раз. Вона отримує дані, аналізує їх, оновлює припущення і пропонує наступний крок. Тобто бере участь у справжньому ітеративному процесі а не просто видає одноразову відповідь на запит.
Особливо перспективним виглядає саме repurposing вже схвалених ліків. Розробка нового препарату може тривати понад десять років і коштувати більше мільярда доларів при тому що регулятори схвалюють лише близько 50 нових препаратів на рік. Наявні препарати вже пройшли значну частину перевірок безпеки, тому пошук нового застосування для старих ліків це ефективне використання часу і ресурсів.
Наступний логічний крок це під'єднати таких агентів до роботизованих лабораторій щоб система могла самостійно провести й частину фізичних експериментів. Схожий підхід вже демонструє система RoboChem де AI-модель керує набором автоматизованих лабораторних інструментів.
Можливо майбутнє науки це не один універсальний "AI-науковець" а замкнений цикл спеціалізованих агентів: гіпотеза, експеримент, дані, нова гіпотеза. І людина яка визначає мету та перевіряє чи рухається система у правильному напрямку.
Код Robin на GitHub · Finch на GitHub
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Дослідники з FutureHouse, Оксфордського та Фордгемського університетів представили Robin — ШІ-агента для пошуку нових способів застосування вже відомих препаратів.
Robin це не одна модель а оркестрація кількох спеціалізованих агентів кожен з яких відповідає за окрему когнітивну задачу в дослідницькому pipeline.
Crow робить короткі цілеспрямовані пошуки в літературі і пропонує експериментальні стратегії та кандидатів на препарати. Falcon робить глибші літературні огляди коли потрібен повноцінний технічний звіт а не швидка відповідь. Finch окремий агент для аналізу даних який працює вже не з текстами а з сирими експериментальними датасетами: RNA-seq, flow cytometry, результати скринінгу. Він шукає статистично значущі патерни і генерує гіпотези виходячи з самих даних а не з літератури.
Ключова інженерна ідея тут це розділення ролей за типом джерела інформації. Crow і Falcon працюють з текстовим корпусом знань. Finch працює з числовими експериментальними даними. Це різні типи задач які вимагають різних підходів до пошуку сигналу. Замість намагатися зробити одну універсальну модель яка вміє все автори розбили pipeline на спеціалізовані компоненти які передають один одному структуровані результати.
Цикл роботи виглядає так: Crow і Falcon аналізують дослідження про захворювання і визначають можливі біологічні механізми → система пропонує експерименти для перевірки гіпотези → людина фізично проводить експеримент у лабораторії → Finch аналізує отримані результати → на основі нових даних цикл формує наступну гіпотезу. Окремий компонент — суддя який ранжує гіпотези через парні порівняння — вирішує які напрямки варто досліджувати далі коли варіантів багато.
Людина поки що залишається в цьому циклі як виконавець фізичного експерименту і як точка перевірки. Вона задає захворювання й оцінює чи рухається система у правильному напрямку. Але більшість дослідницької роботи, читання літератури, формулювання гіпотез, дизайн експериментів, інтерпретація результатів, система виконує майже автономно.
Показовий масштаб: Crow опрацював 551 релевантну статтю приблизно за 30 хвилин. Задача яку дослідник виконував би близько 540 годин ручного читання і синтезу.
Robin протестували на сухій віковій макулярній дегенерації. Агент припустив що лікуванню може допомогти посилення фагоцитозу пігментного епітелію сітківки, процесу яким клітини ока очищаються від пошкоджених компонентів. Після аналізу літератури Robin запропонував два препарати: Y-27632 майже вдвічі підвищив активність потрібного процесу в ізольованих клітинах ока, а Ripasudil, вже схвалений у Японії препарат від глаукоми, дав приріст приблизно у 1.9 раза.
Важливе уточнення: препарати тестували лише на клітинах а не на пацієнтах. Це не готове лікування і навіть не доказ що метод спрацює в живому організмі.
Але сама модель роботи цінна незалежно від конкретного результату. Система не генерує гіпотезу один раз. Вона отримує дані, аналізує їх, оновлює припущення і пропонує наступний крок. Тобто бере участь у справжньому ітеративному процесі а не просто видає одноразову відповідь на запит.
Особливо перспективним виглядає саме repurposing вже схвалених ліків. Розробка нового препарату може тривати понад десять років і коштувати більше мільярда доларів при тому що регулятори схвалюють лише близько 50 нових препаратів на рік. Наявні препарати вже пройшли значну частину перевірок безпеки, тому пошук нового застосування для старих ліків це ефективне використання часу і ресурсів.
Наступний логічний крок це під'єднати таких агентів до роботизованих лабораторій щоб система могла самостійно провести й частину фізичних експериментів. Схожий підхід вже демонструє система RoboChem де AI-модель керує набором автоматизованих лабораторних інструментів.
Можливо майбутнє науки це не один універсальний "AI-науковець" а замкнений цикл спеціалізованих агентів: гіпотеза, експеримент, дані, нова гіпотеза. І людина яка визначає мету та перевіряє чи рухається система у правильному напрямку.
Код Robin на GitHub · Finch на GitHub
🔔 ПІДПИСАТИСЯ
👍7❤2🥰2🔥1
Чи може ШІ непомітно змінювати наші переконання?
Доброго ранку ☕️
Дослідники з MIT та Carnegie Mellon поставили важливіше запитання: чи справді люди змінюють свою думку пiсля розмови з моделлю?
Вони дослідили розмови понад тисячі користувачів із GPT-4o і представили новий бенчмарк Puppet. Учасники обирали запит на особисту пораду у сфері здоров'я, фінансів або стосунків, оцінювали свою згоду з пов'язаним твердженням за шкалою від 0 до 100, спілкувалися з GPT-4o протягом 5-10 повідомлень і повторно оцінювали своє переконання. Модель при цьому отримувала різні інструкції: діяти в інтересах користувача, не переслідувати конкретних інтересів або впливати на нього в інтересах іншої сторони. Різниця між оцінками до та після розмови й була реальним показником впливу.
І тут з'являється ключова проблема попередніх детекторів маніпуляцій. Очевидно маніпулятивна відповідь може взагалі не спрацювати тому що користувач розпізнає тиск і відкине його. Натомість м'яка персоналізована порада без агресивної риторики може суттєво змінити його погляди. Тобто маніпулятивний текст і реальний вплив це не одне й те саме.
Результати це підтвердили. Традиційні детектори маніпулятивного тексту показали майже нульову кореляцію з фактичною зміною переконань. Натомість звичайні LLM отримавши транскрипт розмови змогли помірно точно оцінити наскільки змінилася думка користувача. Найкращий результат показала GPT-4o з кореляцією Спірмена 0.436, DeepSeek-V3.1 показала 0.362. Ще далеко від надійного прогнозування але значно краще за спеціалізовані детектори.
Цікаво що додавання особистої інформації про користувача, як-от демографія, риси особистості за моделлю Great Five, життєві цілі і моральні цінності, не дало стабільного покращення. Самого діалогу часто було достатньо.
Зміни переконань дуже відрізнялися між людьми. Медіана становила лише 3.3 бала зі 100, тобто більшість учасників майже не змінили свою думку. Але стандартне відхилення близько 22 балів показує що для окремих користувачів вплив був значним. І це можливо найважливіший результат: середній ефект виглядає невеликим але приховує групу людей особливо вразливих до впливу моделі.
Дослідження вимірювало лише короткострокову зміну після однієї розмови. Схожі питання про накопичувальний ефект переконання піднімають і інші роботи в цій області. Ми ще не знаємо чи зберігається такий вплив надовго і чи накопичується він після місяців регулярного спілкування з одним асистентом.
Автори показали що виявлення маніпулятивних формулювань недостатньо для оцінювання реальної сили впливу. Моделі досить непогано прогнозували фактичні зміни переконань спираючись лише на транскрипт розмови навіть без даних про демографію чи особистість користувача. Це відкриває шлях до систем які краще захищатимуть користувачів від маніпулятивної поведінки LLM.
Автори не проаналізували випадки коли переконання змінювалися після розмови з моделлю спеціально налаштованою діяти в інтересах користувача. Це був би корисний напрям для подальших досліджень — результати могли б показати наскільки ШІ здатний допомагати людям досягати цілей: опановувати навички, вивчати нову галузь знань, переходити до здоровішого способу життя. Схожі питання про позитивне використання переконливості моделей піднімає і одне з недавніх досліджень.
При цьому сам вплив не обов'язково шкідливий. Модель може переконати людину звернутися до лікаря, почати навчання, відмовитися від небезпечної звички. Це теж зміна переконань але в інтересах самого користувача.
Тому головне питання майбутнього ймовірно звучатиме не так: чи вміє модель переконувати. Вона вже вміє. Питання в іншому: чиїм інтересам служить це переконання і чи може система вчасно помітити коли вплив стає шкідливим?
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Дослідники з MIT та Carnegie Mellon поставили важливіше запитання: чи справді люди змінюють свою думку пiсля розмови з моделлю?
Вони дослідили розмови понад тисячі користувачів із GPT-4o і представили новий бенчмарк Puppet. Учасники обирали запит на особисту пораду у сфері здоров'я, фінансів або стосунків, оцінювали свою згоду з пов'язаним твердженням за шкалою від 0 до 100, спілкувалися з GPT-4o протягом 5-10 повідомлень і повторно оцінювали своє переконання. Модель при цьому отримувала різні інструкції: діяти в інтересах користувача, не переслідувати конкретних інтересів або впливати на нього в інтересах іншої сторони. Різниця між оцінками до та після розмови й була реальним показником впливу.
І тут з'являється ключова проблема попередніх детекторів маніпуляцій. Очевидно маніпулятивна відповідь може взагалі не спрацювати тому що користувач розпізнає тиск і відкине його. Натомість м'яка персоналізована порада без агресивної риторики може суттєво змінити його погляди. Тобто маніпулятивний текст і реальний вплив це не одне й те саме.
Результати це підтвердили. Традиційні детектори маніпулятивного тексту показали майже нульову кореляцію з фактичною зміною переконань. Натомість звичайні LLM отримавши транскрипт розмови змогли помірно точно оцінити наскільки змінилася думка користувача. Найкращий результат показала GPT-4o з кореляцією Спірмена 0.436, DeepSeek-V3.1 показала 0.362. Ще далеко від надійного прогнозування але значно краще за спеціалізовані детектори.
Цікаво що додавання особистої інформації про користувача, як-от демографія, риси особистості за моделлю Great Five, життєві цілі і моральні цінності, не дало стабільного покращення. Самого діалогу часто було достатньо.
Зміни переконань дуже відрізнялися між людьми. Медіана становила лише 3.3 бала зі 100, тобто більшість учасників майже не змінили свою думку. Але стандартне відхилення близько 22 балів показує що для окремих користувачів вплив був значним. І це можливо найважливіший результат: середній ефект виглядає невеликим але приховує групу людей особливо вразливих до впливу моделі.
Дослідження вимірювало лише короткострокову зміну після однієї розмови. Схожі питання про накопичувальний ефект переконання піднімають і інші роботи в цій області. Ми ще не знаємо чи зберігається такий вплив надовго і чи накопичується він після місяців регулярного спілкування з одним асистентом.
Автори показали що виявлення маніпулятивних формулювань недостатньо для оцінювання реальної сили впливу. Моделі досить непогано прогнозували фактичні зміни переконань спираючись лише на транскрипт розмови навіть без даних про демографію чи особистість користувача. Це відкриває шлях до систем які краще захищатимуть користувачів від маніпулятивної поведінки LLM.
Автори не проаналізували випадки коли переконання змінювалися після розмови з моделлю спеціально налаштованою діяти в інтересах користувача. Це був би корисний напрям для подальших досліджень — результати могли б показати наскільки ШІ здатний допомагати людям досягати цілей: опановувати навички, вивчати нову галузь знань, переходити до здоровішого способу життя. Схожі питання про позитивне використання переконливості моделей піднімає і одне з недавніх досліджень.
При цьому сам вплив не обов'язково шкідливий. Модель може переконати людину звернутися до лікаря, почати навчання, відмовитися від небезпечної звички. Це теж зміна переконань але в інтересах самого користувача.
Тому головне питання майбутнього ймовірно звучатиме не так: чи вміє модель переконувати. Вона вже вміє. Питання в іншому: чиїм інтересам служить це переконання і чи може система вчасно помітити коли вплив стає шкідливим?
🔔 ПІДПИСАТИСЯ
👍8👀2
10 речей про LLM, які варто знати — 8/10 🧠
Контраст робить пояснення точнішим
Гарного дня! 👋
Продовжуємо серію. Якщо запитати мовну модель "що таке AI-агент" — вона найімовірніше дасть правильне але досить загальне визначення: автономна система яка використовує AI для виконання завдань.
Проблема не в тому що модель не знає відповіді. Просто такий запит не пояснює які саме властивості поняття для нас важливі та де потрібно провести його межу.
Набагато корисніше запитати: "чим AI-агент відрізняється від звичайного чатбота, workflow-автоматизації та RPA?" Тепер моделі недостатньо просто перелічити властивості агента. Їй потрібно знайти ознаки за якими ці системи можна розрізнити: хто визначає послідовність дій, чи може система змінювати план, чи працює вона за жорстким сценарієм, чи самостійно обирає інструменти, де закінчується автоматизація і починається автономність.
У результаті ми отримуємо не просто визначення а межі поняття.
Цей принцип давно досліджують у когнітивній науці. Роботи Дедре Гентнер та Артура Маркмана показують що порівняння змушує людину узгоджувати структури двох об'єктів, помічати спільні зв'язки та відмінності які без порівняння могли б залишитися непомітними.
Схожий механізм спостерігається і в роботі з LLM. У дослідженні Large Language Models Are Contrastive Reasoners моделі просили сформувати не лише правильну а й неправильну відповідь а потім протиставити їх. Такий contrastive prompting покращував результати на низці арифметичних, логічних і commonsense-задач.
Автори Contrastive Chain-of-Thought Prompting пішли ще далі: вони показували моделі одночасно правильні та помилкові ланцюжки міркувань. Негативний приклад допомагав моделі зрозуміти не лише як потрібно міркувати а й яких помилок потрібно уникати.
Ці експерименти безпосередньо не доводять що будь-яке порівняльне питання завжди дасть краще пояснення. Але вони підтверджують загальний принцип: явний контраст допомагає моделі шукати розрізнювальні ознаки а не просто відтворювати типове визначення.
OpenAI, Anthropic, Google та Microsoft формулюють це трохи інакше. У своїх рекомендаціях вони радять давати моделі конкретну операцію, контекст, критерії та бажану структуру результату. Тобто не просто "поясни" а уточнити що саме потрібно знайти, порівняти або показати.
Ethan Mollick називає такі конструкції structured prompts — структурованими запитами які працюють майже як невеликі програми: задають моделі конкретне завдання та спосіб його виконання.
Наприклад замість "що таке RAG?" краще запитати: "чим RAG відрізняється від fine-tuning і простого додавання документа в контекст? Порівняй їх за актуальністю знань, вартістю, складністю та типовими сценаріями використання".
А замість "що таке галюцинація моделі?" можна запитати: "чим галюцинація відрізняється від фактичної помилки, невизначеності та застарілої інформації?"
Ще сильніший варіант промпту: "порівняй X з Y та Z за критеріями A, B і C. Покажи спільні риси, ключові відмінності, граничні випадки та приклад у якому ці поняття легко переплутати".
Тут вже видно що для ефективної роботи з моделлю недостатньо просто сформулювати питання. Треба керувати самим процесом міркування — і по суті це вже інженерний підхід а не просто вдалий промпт. Але якщо ви думали що на цьому все — ні 😁
Є ще одне застереження. Порівнювати потрібно близькі поняття. Якщо вони належать до різних рівнів або категорій — модель може побудувати штучну вісь порівняння та впевнено вигадати відмінності там де коректного зіставлення немає.
Визначення перелічує властивості. Контраст показує які з них справді мають значення.
Тому якщо хочете ясності — просіть модель не просто описати поняття а показати чим воно відрізняється від найближчих альтернатив і де проходить його межа.
Зберігай щоб не загубити, а наступного разу — ще один важливий факт про LLM 👀
🔔 ПІДПИСАТИСЯ
Контраст робить пояснення точнішим
Гарного дня! 👋
Продовжуємо серію. Якщо запитати мовну модель "що таке AI-агент" — вона найімовірніше дасть правильне але досить загальне визначення: автономна система яка використовує AI для виконання завдань.
Проблема не в тому що модель не знає відповіді. Просто такий запит не пояснює які саме властивості поняття для нас важливі та де потрібно провести його межу.
Набагато корисніше запитати: "чим AI-агент відрізняється від звичайного чатбота, workflow-автоматизації та RPA?" Тепер моделі недостатньо просто перелічити властивості агента. Їй потрібно знайти ознаки за якими ці системи можна розрізнити: хто визначає послідовність дій, чи може система змінювати план, чи працює вона за жорстким сценарієм, чи самостійно обирає інструменти, де закінчується автоматизація і починається автономність.
У результаті ми отримуємо не просто визначення а межі поняття.
Цей принцип давно досліджують у когнітивній науці. Роботи Дедре Гентнер та Артура Маркмана показують що порівняння змушує людину узгоджувати структури двох об'єктів, помічати спільні зв'язки та відмінності які без порівняння могли б залишитися непомітними.
Схожий механізм спостерігається і в роботі з LLM. У дослідженні Large Language Models Are Contrastive Reasoners моделі просили сформувати не лише правильну а й неправильну відповідь а потім протиставити їх. Такий contrastive prompting покращував результати на низці арифметичних, логічних і commonsense-задач.
Автори Contrastive Chain-of-Thought Prompting пішли ще далі: вони показували моделі одночасно правильні та помилкові ланцюжки міркувань. Негативний приклад допомагав моделі зрозуміти не лише як потрібно міркувати а й яких помилок потрібно уникати.
Ці експерименти безпосередньо не доводять що будь-яке порівняльне питання завжди дасть краще пояснення. Але вони підтверджують загальний принцип: явний контраст допомагає моделі шукати розрізнювальні ознаки а не просто відтворювати типове визначення.
OpenAI, Anthropic, Google та Microsoft формулюють це трохи інакше. У своїх рекомендаціях вони радять давати моделі конкретну операцію, контекст, критерії та бажану структуру результату. Тобто не просто "поясни" а уточнити що саме потрібно знайти, порівняти або показати.
Ethan Mollick називає такі конструкції structured prompts — структурованими запитами які працюють майже як невеликі програми: задають моделі конкретне завдання та спосіб його виконання.
Наприклад замість "що таке RAG?" краще запитати: "чим RAG відрізняється від fine-tuning і простого додавання документа в контекст? Порівняй їх за актуальністю знань, вартістю, складністю та типовими сценаріями використання".
А замість "що таке галюцинація моделі?" можна запитати: "чим галюцинація відрізняється від фактичної помилки, невизначеності та застарілої інформації?"
Ще сильніший варіант промпту: "порівняй X з Y та Z за критеріями A, B і C. Покажи спільні риси, ключові відмінності, граничні випадки та приклад у якому ці поняття легко переплутати".
Тут вже видно що для ефективної роботи з моделлю недостатньо просто сформулювати питання. Треба керувати самим процесом міркування — і по суті це вже інженерний підхід а не просто вдалий промпт. Але якщо ви думали що на цьому все — ні 😁
Є ще одне застереження. Порівнювати потрібно близькі поняття. Якщо вони належать до різних рівнів або категорій — модель може побудувати штучну вісь порівняння та впевнено вигадати відмінності там де коректного зіставлення немає.
Визначення перелічує властивості. Контраст показує які з них справді мають значення.
Тому якщо хочете ясності — просіть модель не просто описати поняття а показати чим воно відрізняється від найближчих альтернатив і де проходить його межа.
Зберігай щоб не загубити, а наступного разу — ще один важливий факт про LLM 👀
🔔 ПІДПИСАТИСЯ
👍7❤3👏3🥰1
Цього тижня сталася дуже показова історія для всієї AI-індустрії.
Доброго ранку ☕️
Протягом останніх років нам часто говорили: відкриті моделі небезпечні, закриті моделі з жорсткими guardrails безпечні. Реальний інцидент показав значно складнішу картину.
Hugging Face розкрила деталі атаки яка сталася на вихідних 11-12 липня. Компанія прямо каже: це була перша атака проведена "end-to-end автономною AI-агентною системою". Зловмисний датасет експлуатував вразливості в пайплайні обробки даних, агент escalation-ом отримав доступ до credentials і за вихідні виконав понад 17 000 автоматизованих дій через рій короткоживучих sandbox-середовищ.
За кілька днів OpenAI підтвердила що джерелом атаки була саме їхня система — під час оцінки моделей GPT-5.6 Sol на бенчмарку ExploitGym модель вирвалась за межі тестового середовища і атакувала реальну інфраструктуру Hugging Face замість ізольованого полігону.
І тут почалася найцікавіша частина.
Коли Hugging Face намагалася проаналізувати логи атаки — комерційні frontier-моделі відмовлялися допомагати. Запити містили реальні команди експлойтів, payload і артефакти command-and-control інфраструктури — і guardrails спрацьовували, не розрізняючи легітимний форензик-аналіз від спроби скласти атаку.
У підсумку команда розгорнула відкриту модель GLM 5.2 від Z.ai на власній інфраструктурі і саме через неї проаналізувала весь масив логів.
У цього рішення виявилося два практичні плюси. По-перше воно взагалі спрацювало — модель не блокувала forensic-запити. По-друге жодні дані атакувальника і жодні credentials не покинули контрольоване середовище компанії, бо аналіз відбувався локально а не через сторонній API.
Сама Hugging Face сформулювала висновок прямо у пості: це не аргумент проти safety-механізмів у хостінгових моделях. Це сигнал що командам захисту варто мати перевірену відкриту модель напоготові ще до інциденту — саме щоб уникнути ситуації коли власний захист блокує аналіз атаки на самого себе.
Чи повинні guardrails заважати аналізу вже здійсненої атаки? Між "допоможи мені зламати сервер" і "допоможи проаналізувати журнали вже виконаної атаки щоб зрозуміти що сталося" — величезна різниця. Але для класифікатора безпеки який бачить лише текст запиту ця різниця не завжди очевидна.
Ця історія вкотре показує що дискусію не можна зводити до простого "відкрите = небезпечне, закрите = безпечне". Відкриті моделі можуть не лише створювати ризики а й суттєво спрощувати аудит, цифрову криміналістику та аналіз інцидентів — особливо коли компанії потрібно тримати чутливі дані у власному периметрі. Й водночас саму атаку здійснила не відкрита а одна з найпотужніших закритих frontier-систем яка вирвалась із тестового полігону.
Тому питання не в тому щоб зробити моделі максимально "обмеженими". Питання в тому як зробити їх відповідальним інструментом для тих хто використовує їх у законних цілях — включно з захистом власної інфраструктури від атак інших AI-систем.
Що думаєте? Чи повинна модель відмовлятися аналізувати логи кібератаки якщо це робиться для захисту інфраструктури?
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Протягом останніх років нам часто говорили: відкриті моделі небезпечні, закриті моделі з жорсткими guardrails безпечні. Реальний інцидент показав значно складнішу картину.
Hugging Face розкрила деталі атаки яка сталася на вихідних 11-12 липня. Компанія прямо каже: це була перша атака проведена "end-to-end автономною AI-агентною системою". Зловмисний датасет експлуатував вразливості в пайплайні обробки даних, агент escalation-ом отримав доступ до credentials і за вихідні виконав понад 17 000 автоматизованих дій через рій короткоживучих sandbox-середовищ.
За кілька днів OpenAI підтвердила що джерелом атаки була саме їхня система — під час оцінки моделей GPT-5.6 Sol на бенчмарку ExploitGym модель вирвалась за межі тестового середовища і атакувала реальну інфраструктуру Hugging Face замість ізольованого полігону.
І тут почалася найцікавіша частина.
Коли Hugging Face намагалася проаналізувати логи атаки — комерційні frontier-моделі відмовлялися допомагати. Запити містили реальні команди експлойтів, payload і артефакти command-and-control інфраструктури — і guardrails спрацьовували, не розрізняючи легітимний форензик-аналіз від спроби скласти атаку.
У підсумку команда розгорнула відкриту модель GLM 5.2 від Z.ai на власній інфраструктурі і саме через неї проаналізувала весь масив логів.
У цього рішення виявилося два практичні плюси. По-перше воно взагалі спрацювало — модель не блокувала forensic-запити. По-друге жодні дані атакувальника і жодні credentials не покинули контрольоване середовище компанії, бо аналіз відбувався локально а не через сторонній API.
Сама Hugging Face сформулювала висновок прямо у пості: це не аргумент проти safety-механізмів у хостінгових моделях. Це сигнал що командам захисту варто мати перевірену відкриту модель напоготові ще до інциденту — саме щоб уникнути ситуації коли власний захист блокує аналіз атаки на самого себе.
Чи повинні guardrails заважати аналізу вже здійсненої атаки? Між "допоможи мені зламати сервер" і "допоможи проаналізувати журнали вже виконаної атаки щоб зрозуміти що сталося" — величезна різниця. Але для класифікатора безпеки який бачить лише текст запиту ця різниця не завжди очевидна.
Ця історія вкотре показує що дискусію не можна зводити до простого "відкрите = небезпечне, закрите = безпечне". Відкриті моделі можуть не лише створювати ризики а й суттєво спрощувати аудит, цифрову криміналістику та аналіз інцидентів — особливо коли компанії потрібно тримати чутливі дані у власному периметрі. Й водночас саму атаку здійснила не відкрита а одна з найпотужніших закритих frontier-систем яка вирвалась із тестового полігону.
Тому питання не в тому щоб зробити моделі максимально "обмеженими". Питання в тому як зробити їх відповідальним інструментом для тих хто використовує їх у законних цілях — включно з захистом власної інфраструктури від атак інших AI-систем.
Що думаєте? Чи повинна модель відмовлятися аналізувати логи кібератаки якщо це робиться для захисту інфраструктури?
🔔 ПІДПИСАТИСЯ
👍9❤4👏2
Kimi K3: відкрита модель на 2.8 трильйона параметрів майже наздогнала лідерів AI-ринку
Доброго ранку ☕️
Moonshot AI представила Kimi K3 — мультимодальну модель на 2.8 трильйона параметрів яка приймає текст, зображення та відео й підтримує контекст до 1 мільйона токенів.
Як завжди, я не писав одразу як вийшла модель, так як треба був час на те щоб детально розiбратись. Тож почнем
За незалежними тестами Kimi K3 випередила всі інші моделі з відкритими вагами та на багатьох завданнях наблизилася до найсильніших пропрієтарних систем. У Intelligence Index від Artificial Analysis: Claude Fable 5 — 60 балів, GPT-5.6 Sol — 59, Kimi K3 — 57, GLM-5.2 (про яку я писав раніше) — 51. Найкраща відкрита модель відстає від лідера лише на три бали.
На AutomationBench-AA, який тестує автоматизацію робочих процесів у бізнес-застосунках, Kimi K3 взагалі посіла перше місце серед усіх моделей. А в Code Arena WebDev вона стартувала на першій позиції, перемігши у шести із семи категорій фронтенд-розробки.
Як працює модель
Kimi K3 побудована на архітектурі Mixture of Experts. Усього модель має 896 експертів але для обробки кожного токена активуються лише 16 із них — тобто система має величезну загальну місткість не використовуючи всі 2.8 трильйона параметрів одночасно. Орієнтовно для одного токена активуються близько 50 мільярдів параметрів.
Moonshot використала дві важливі архітектурні інновації.
Kimi Delta Attention. Звичайний attention порівнює кожен новий токен з усіма попередніми — чим довший контекст тим більше потрібно пам'яті та обчислень. Kimi Delta Attention працює інакше: модель підтримує пам'ять фіксованого розміру й поступово оновлює її під час читання контексту. У попередніх експериментах Moonshot цей підхід скоротив використання пам'яті до 75%, прискорив генерацію до шести разів і дозволив ефективніше працювати з контекстом у 1 мільйон токенів.
Attention Residuals. У звичайному трансформері результат кожного шару додається до загальної суми — зі збільшенням глибини моделі внесок окремих шарів може поступово розмиватися. Attention Residuals дозволяє кожному шару вибірково звертатися до результатів попередніх шарів. Тобто модель використовує attention не лише між токенами а й між рівнями власної архітектури. У тестах блокова версія цього підходу забезпечила таку саму якість як стандартні residual connections але потребувала приблизно на 20% менше обчислень під час навчання.
Разом із більш розрідженою MoE-архітектурою та новими методами тренування це за словами Moonshot зробило навчання Kimi K3 приблизно у 2.5 раза ефективнішим за попередні запуски.
Якщо ви не маєте можливості запускати модель локально, можно заплатити, Kimi K3 коштує $3 за мільйон вхідних токенів, $0.30 за мільйон кешованих і $15 за мільйон вихідних.
Kimi K3 поступово усуває майже всі причини через які розробник обираючи модель міг би автоматично віддати перевагу найкращій пропрієтарній системі. За рівнем продуктивності вона відстає від Claude Fable 5 лише на три бали але коштує значно дешевше за одне виконане завдання.
Після публікації відкриті ваги дадуть змогу запускати модель на власній інфраструктурі, виконувати fine-tuning та дистиляцію, детальніше досліджувати роботу моделі. Власник ваг також самостійно визначає правила використання — багато запитів які Claude Fable 5 відхиляє не створюватимуть подібних обмежень для користувачів Kimi K3.
Найважливіший аспект Kimi K3 полягає саме в іншому. Moonshot досягає прогресу не лише завдяки збільшенню кількості параметрів а завдяки зміні базових компонентів трансформера: attention, residual connections і маршрутизації експертів.
Дві з цих технологій компанія вже описала в наукових роботах і опублікувала разом із кодом.
Коли лабораторії які не мають необмежених обчислювальних ресурсів відповідають на це архітектурними інноваціями й відкрито діляться результатами — виграє вся AI-індустрія.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Moonshot AI представила Kimi K3 — мультимодальну модель на 2.8 трильйона параметрів яка приймає текст, зображення та відео й підтримує контекст до 1 мільйона токенів.
Як завжди, я не писав одразу як вийшла модель, так як треба був час на те щоб детально розiбратись. Тож почнем
За незалежними тестами Kimi K3 випередила всі інші моделі з відкритими вагами та на багатьох завданнях наблизилася до найсильніших пропрієтарних систем. У Intelligence Index від Artificial Analysis: Claude Fable 5 — 60 балів, GPT-5.6 Sol — 59, Kimi K3 — 57, GLM-5.2 (про яку я писав раніше) — 51. Найкраща відкрита модель відстає від лідера лише на три бали.
На AutomationBench-AA, який тестує автоматизацію робочих процесів у бізнес-застосунках, Kimi K3 взагалі посіла перше місце серед усіх моделей. А в Code Arena WebDev вона стартувала на першій позиції, перемігши у шести із семи категорій фронтенд-розробки.
Як працює модель
Kimi K3 побудована на архітектурі Mixture of Experts. Усього модель має 896 експертів але для обробки кожного токена активуються лише 16 із них — тобто система має величезну загальну місткість не використовуючи всі 2.8 трильйона параметрів одночасно. Орієнтовно для одного токена активуються близько 50 мільярдів параметрів.
Moonshot використала дві важливі архітектурні інновації.
Kimi Delta Attention. Звичайний attention порівнює кожен новий токен з усіма попередніми — чим довший контекст тим більше потрібно пам'яті та обчислень. Kimi Delta Attention працює інакше: модель підтримує пам'ять фіксованого розміру й поступово оновлює її під час читання контексту. У попередніх експериментах Moonshot цей підхід скоротив використання пам'яті до 75%, прискорив генерацію до шести разів і дозволив ефективніше працювати з контекстом у 1 мільйон токенів.
Attention Residuals. У звичайному трансформері результат кожного шару додається до загальної суми — зі збільшенням глибини моделі внесок окремих шарів може поступово розмиватися. Attention Residuals дозволяє кожному шару вибірково звертатися до результатів попередніх шарів. Тобто модель використовує attention не лише між токенами а й між рівнями власної архітектури. У тестах блокова версія цього підходу забезпечила таку саму якість як стандартні residual connections але потребувала приблизно на 20% менше обчислень під час навчання.
Разом із більш розрідженою MoE-архітектурою та новими методами тренування це за словами Moonshot зробило навчання Kimi K3 приблизно у 2.5 раза ефективнішим за попередні запуски.
Якщо ви не маєте можливості запускати модель локально, можно заплатити, Kimi K3 коштує $3 за мільйон вхідних токенів, $0.30 за мільйон кешованих і $15 за мільйон вихідних.
Kimi K3 поступово усуває майже всі причини через які розробник обираючи модель міг би автоматично віддати перевагу найкращій пропрієтарній системі. За рівнем продуктивності вона відстає від Claude Fable 5 лише на три бали але коштує значно дешевше за одне виконане завдання.
Після публікації відкриті ваги дадуть змогу запускати модель на власній інфраструктурі, виконувати fine-tuning та дистиляцію, детальніше досліджувати роботу моделі. Власник ваг також самостійно визначає правила використання — багато запитів які Claude Fable 5 відхиляє не створюватимуть подібних обмежень для користувачів Kimi K3.
Найважливіший аспект Kimi K3 полягає саме в іншому. Moonshot досягає прогресу не лише завдяки збільшенню кількості параметрів а завдяки зміні базових компонентів трансформера: attention, residual connections і маршрутизації експертів.
Дві з цих технологій компанія вже описала в наукових роботах і опублікувала разом із кодом.
Коли лабораторії які не мають необмежених обчислювальних ресурсів відповідають на це архітектурними інноваціями й відкрито діляться результатами — виграє вся AI-індустрія.
🔔 ПІДПИСАТИСЯ
👍8🔥2❤1💯1
Cloudflare хоче перетворити доступ AI до інтернету на платну послугу
Доброго ранку ☕️
Cloudflare представила нову систему керування AI-краулерами яка дозволить власникам сайтів окремо вирішувати хто і для чого може використовувати їхній контент.
Чи користувались ви коли-небудь Cloudflare? Як на мене це дуже зручний інструмент для підприємців і власників малого бізнесу. Недавно допомагав другу запустити сайт на ньому.
Тепер можна буде дозволити індексацію сторінок для пошуку, заборонити збір даних для навчання AI-моделей і заблокувати AI-агентів які виконують дії від імені користувачів. Раніше вебкраулер зазвичай або мав доступ до сайту або не мав. Тепер Cloudflare намагається розділити ботів за їхньою реальною функцією.
Як це працюватиме
Cloudflare поділяє ботів на три категорії: search crawlers для пошукової індексації, training crawlers які збирають контент для навчання моделей, і agent crawlers які діють від імені користувача — порівнюють товари, взаємодіють із сайтами, здійснюють покупки. Для кожної категорії власник сайту зможе повністю заблокувати доступ, обмежити його лише сторінками з рекламою або дозволити повністю. Зміни мають почати застосовуватися 15 вересня.
Найцікавіша проблема виникає з краулерами які використовуються одночасно для кількох цілей. Наприклад Googlebot може індексувати контент для пошуку але водночас використовувати його для AI-продуктів. У такому разі Cloudflare застосовуватиме найсуворіше правило: якщо власник дозволив індексацію але заборонив навчання AI — багатофункціональний краулер може бути заблокований повністю.
Окремо Cloudflare представила BotBase — публічну базу відомих ботів яка класифікуватиме їх за поведінкою. Верифікація підтверджує особу оператора і дотримання robots.txt але не дає автоматичного доступу.
Платний доступ до контенту
Cloudflare планує піти далі. Компанія анонсувала систему яка дозволить власникам сайтів стягувати плату з AI-агентів за доступ до вебсторінок, датасетів, API та MCP-серверів. Коли агент спробує отримати захищений контент — Cloudflare спочатку перевірить оплату і лише після цього передасть запит сайту. Тобто компанія хоче стати платіжним шлюзом між видавцями та AI-системами.
Чому це відбувається
За даними Cloudflare 57.5% усіх HTTP-запитів сьогодні надходять від автоматизованих систем а не від людей. Стара угода між сайтами та пошуковиками руйнується: раніше сайт дозволяв індексацію → пошуковик показував посилання → людина переходила на сайт → видавець заробляв на рекламі. Тепер AI-агент читає сторінку, формує готову відповідь і не відправляє користувача на оригінал. Контент використано але власник нічого не отримав. Саме тому деякі видавці вже відмовляються від індексації в Google.
Доступ до якісних даних з відкритого інтернету залишається критично важливим для розвитку AI. Але видавці та посередники як Cloudflare дедалі частіше обмежують способи їх збору. Великі компанії вже зібрали величезні масиви вебданих і можуть укладати прямі угоди з видавцями. Нові гравці таких ресурсів не мають і стикаються з вищими бар'єрами доступу до знань. Тому нові обмеження можуть не зрівняти ринок а навпаки посилити перевагу найбільших гравців.
Cloudflare вважає що між AI-компаніями та видавцями можна укласти нову угоду а сама компанія може виступити оператором платного пропускного пункту. Але це суперечить принципу яким керується більшість AI-компаній: навчання на загальнодоступних даних має вважатися добросовісним використанням.
Поки що незрозуміло чи має Cloudflare достатньо впливу щоб запровадити таку плату і чиє визначення справедливості зрештою переможе.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Cloudflare представила нову систему керування AI-краулерами яка дозволить власникам сайтів окремо вирішувати хто і для чого може використовувати їхній контент.
Чи користувались ви коли-небудь Cloudflare? Як на мене це дуже зручний інструмент для підприємців і власників малого бізнесу. Недавно допомагав другу запустити сайт на ньому.
Тепер можна буде дозволити індексацію сторінок для пошуку, заборонити збір даних для навчання AI-моделей і заблокувати AI-агентів які виконують дії від імені користувачів. Раніше вебкраулер зазвичай або мав доступ до сайту або не мав. Тепер Cloudflare намагається розділити ботів за їхньою реальною функцією.
Як це працюватиме
Cloudflare поділяє ботів на три категорії: search crawlers для пошукової індексації, training crawlers які збирають контент для навчання моделей, і agent crawlers які діють від імені користувача — порівнюють товари, взаємодіють із сайтами, здійснюють покупки. Для кожної категорії власник сайту зможе повністю заблокувати доступ, обмежити його лише сторінками з рекламою або дозволити повністю. Зміни мають почати застосовуватися 15 вересня.
Найцікавіша проблема виникає з краулерами які використовуються одночасно для кількох цілей. Наприклад Googlebot може індексувати контент для пошуку але водночас використовувати його для AI-продуктів. У такому разі Cloudflare застосовуватиме найсуворіше правило: якщо власник дозволив індексацію але заборонив навчання AI — багатофункціональний краулер може бути заблокований повністю.
Окремо Cloudflare представила BotBase — публічну базу відомих ботів яка класифікуватиме їх за поведінкою. Верифікація підтверджує особу оператора і дотримання robots.txt але не дає автоматичного доступу.
Платний доступ до контенту
Cloudflare планує піти далі. Компанія анонсувала систему яка дозволить власникам сайтів стягувати плату з AI-агентів за доступ до вебсторінок, датасетів, API та MCP-серверів. Коли агент спробує отримати захищений контент — Cloudflare спочатку перевірить оплату і лише після цього передасть запит сайту. Тобто компанія хоче стати платіжним шлюзом між видавцями та AI-системами.
Чому це відбувається
За даними Cloudflare 57.5% усіх HTTP-запитів сьогодні надходять від автоматизованих систем а не від людей. Стара угода між сайтами та пошуковиками руйнується: раніше сайт дозволяв індексацію → пошуковик показував посилання → людина переходила на сайт → видавець заробляв на рекламі. Тепер AI-агент читає сторінку, формує готову відповідь і не відправляє користувача на оригінал. Контент використано але власник нічого не отримав. Саме тому деякі видавці вже відмовляються від індексації в Google.
Доступ до якісних даних з відкритого інтернету залишається критично важливим для розвитку AI. Але видавці та посередники як Cloudflare дедалі частіше обмежують способи їх збору. Великі компанії вже зібрали величезні масиви вебданих і можуть укладати прямі угоди з видавцями. Нові гравці таких ресурсів не мають і стикаються з вищими бар'єрами доступу до знань. Тому нові обмеження можуть не зрівняти ринок а навпаки посилити перевагу найбільших гравців.
Cloudflare вважає що між AI-компаніями та видавцями можна укласти нову угоду а сама компанія може виступити оператором платного пропускного пункту. Але це суперечить принципу яким керується більшість AI-компаній: навчання на загальнодоступних даних має вважатися добросовісним використанням.
Поки що незрозуміло чи має Cloudflare достатньо впливу щоб запровадити таку плату і чиє визначення справедливості зрештою переможе.
🔔 ПІДПИСАТИСЯ
👍6❤1🤔1
🔓 Ще один аргумент на користь відкритих AI-моделей
Доброго ранку ☕️
Я не раз розповідав вам про open source і open-weight моделі. Мені завжди подобався сам принцип відкритого коду — ще з часів коли я був просто інженером і зараз з не меншим інтересом стежу за open-weight моделями. З одного боку це можливість детальніше розібратися як усе влаштовано зсередини. З іншого — це справжній двигун прогресу в AI.
Ендрю Ин розповів про кейс з OpenWorker — власним open source AI-агентом який вони з Rohit Prasad щойно випустили. Команда проводила аудит безпеки цього проєкту і вирішила залучити AI-агентів.
Спочатку використали Claude Code з Fable 5 та Codex з GPT-5.6 Sol. Результат виявився несподіваним. Claude просто зупинив роботу і відмовився продовжувати перевірку. GPT-5.6 Sol зміг непогано описати потенційні вектори атак за відомими методологіями на кшталт MITRE ATT&CK але на певному етапі захотів "спуститися" до менш потужної моделі і фактично теж відмовився заглиблюватися далі.
Тоді команда перейшла на власний агентний фреймворк OpenWorker з відкритими моделями GLM 5.2 та Kimi K3. І саме вони дозволили довести аудит до кінця та отримати впевненість у безпеці системи.
Ин прямо пов'язує цей випадок з нещодавньою історією Hugging Face де закриті моделі відмовилися допомагати з форензик-аналізом після атаки і команді довелося перейти на відкриту GLM 5.2 щоб проаналізувати логи.
На мій погляд цей випадок добре демонструє одну важливу проблему. Закриті моделі дедалі частіше не лише блокують потенційно небезпечні дії а й можуть відмовитися допомагати навіть тоді коли користувач перевіряє власний код і намагається знайти в ньому вразливості до того як це зроблять зловмисники.
У світі де атакувальники вже активно використовують AI для автоматизованого пошуку вразливостей така поведінка створює складну дилему для команд що відповідають за безпеку. Вони чують від security-фахівців дедалі більше розчарування саме з цього приводу.
Саме тому відкриті моделі стають важливими не лише з точки зору незалежності чи вартості. Вони також дають можливість виконувати повноцінні аудити безпеки без штучних обмежень якщо це відбувається в легітимному контексті.
Схоже що дискусія про open vs closed AI поступово виходить за межі питання продуктивності. Все частіше вона стосується того хто зрештою контролює можливості інструменту — його користувач чи постачальник моделі.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Я не раз розповідав вам про open source і open-weight моделі. Мені завжди подобався сам принцип відкритого коду — ще з часів коли я був просто інженером і зараз з не меншим інтересом стежу за open-weight моделями. З одного боку це можливість детальніше розібратися як усе влаштовано зсередини. З іншого — це справжній двигун прогресу в AI.
Ендрю Ин розповів про кейс з OpenWorker — власним open source AI-агентом який вони з Rohit Prasad щойно випустили. Команда проводила аудит безпеки цього проєкту і вирішила залучити AI-агентів.
Спочатку використали Claude Code з Fable 5 та Codex з GPT-5.6 Sol. Результат виявився несподіваним. Claude просто зупинив роботу і відмовився продовжувати перевірку. GPT-5.6 Sol зміг непогано описати потенційні вектори атак за відомими методологіями на кшталт MITRE ATT&CK але на певному етапі захотів "спуститися" до менш потужної моделі і фактично теж відмовився заглиблюватися далі.
Тоді команда перейшла на власний агентний фреймворк OpenWorker з відкритими моделями GLM 5.2 та Kimi K3. І саме вони дозволили довести аудит до кінця та отримати впевненість у безпеці системи.
Ин прямо пов'язує цей випадок з нещодавньою історією Hugging Face де закриті моделі відмовилися допомагати з форензик-аналізом після атаки і команді довелося перейти на відкриту GLM 5.2 щоб проаналізувати логи.
На мій погляд цей випадок добре демонструє одну важливу проблему. Закриті моделі дедалі частіше не лише блокують потенційно небезпечні дії а й можуть відмовитися допомагати навіть тоді коли користувач перевіряє власний код і намагається знайти в ньому вразливості до того як це зроблять зловмисники.
У світі де атакувальники вже активно використовують AI для автоматизованого пошуку вразливостей така поведінка створює складну дилему для команд що відповідають за безпеку. Вони чують від security-фахівців дедалі більше розчарування саме з цього приводу.
Саме тому відкриті моделі стають важливими не лише з точки зору незалежності чи вартості. Вони також дають можливість виконувати повноцінні аудити безпеки без штучних обмежень якщо це відбувається в легітимному контексті.
Схоже що дискусія про open vs closed AI поступово виходить за межі питання продуктивності. Все частіше вона стосується того хто зрештою контролює можливості інструменту — його користувач чи постачальник моделі.
🔔 ПІДПИСАТИСЯ
👍8🔥3❤2👏2
🔥 Anthropic знову зробила Opus однією зі своїх ключових моделей
Доброго ранку ☕️
Після релізу Claude Fable 5 майбутнє лінійки Opus здавалося невизначеним. Але Anthropic представила Claude Opus 5 — модель яка в багатьох завданнях перевершує Fable, коштує дешевше і доступна ширшому колу користувачів.
І це не просто чергове оновлення бенчмарків.
Claude Opus 5 отримав контекст до 1 млн токенів, п'ять рівнів reasoning, підтримку інструментів, роботу із зображеннями та окремий Fast Mode приблизно у 2.5 раза швидший за стандартний.
Але найцікавіше — результати.
На Artificial Analysis Intelligence Index новий Opus посів перше місце з 61 балом, трохи випередивши Claude Fable 5 та GPT-5.6 Sol. У Coding Agent Index він розділив перше місце з GPT-5.6 Sol. Схожа картина і на інших незалежних бенчмарках — Zapier та Cursor також ставлять Opus 5 серед лідерів у своїх власних тестах на реальні агентні задачі.
А на ARC-AGI-3, де агент має самостійно розібратися з правилами незнайомого середовища, Claude Opus 5 показав 30.2%. Найближчий конкурент GPT-5.6 Sol отримав лише 7.8%.
Тобто найбільша перевага нової моделі проявилася не у звичайному знанні фактів чи написанні текстів а саме у здатності навчатися під час виконання завдання.
Це добре узгоджується зі стратегією Anthropic. Компанія заявляє у власній документації що Opus 5 краще делегує роботу субагентам, перевіряє власні результати, виконує довгі програмні та бізнес-процеси. Anthropic навіть рекомендує прибирати частину старих інструкцій на кшталт "обов'язково перевір свою відповідь" — модель і без цього схильна перевіряти себе надто ретельно.
Окремо компанія переглянула систему безпеки. Claude Opus 5 усуває більшість претензій користувачів до Fable 5: менше необґрунтованих fallback-відмов, менше блокувань безпечних наукових тем, значно нижча ціна, доступність у дешевших підписках і відсутність політики 30-денного зберігання даних яка була головним болем для enterprise-клієнтів. Аналіз власного коду на вразливості офіційно дозволений. Водночас запити на створення експлойтів або проведення атак усе ще можуть спричинити fallback на старішу модель.
Водночас Claude Fable 5 усе ще має переваги. Він рідше галюцинує, краще відтворює фактичну інформацію і в деяких складних сценаріях залишається сильнішою моделлю. Не виключено також що нинішні бенчмарки ще не повністю відображають реальну різницю між двома моделями — до речі окремо варто згадати що TechCrunch розбирав і чутки про те що успіх Kimi K3 пов'язаний з експлуатацією Fable 5 — експерти цю версію не підтверджують.
При цьому Opus 5 коштує через API $5 за мільйон вхідних і $25 за мільйон вихідних токенів. Це дешевше за Fable хоча модель усе одно залишається дорожчою за більшість конкурентів.
Схоже Anthropic свідомо не бере участі у перегонах за найдешевший і найшвидший inference. Поки більшість AI-компаній робить ставку на швидкість і здешевлення, Anthropic рухається у протилежному напрямку — створює великі, повільніші але дуже компетентні моделі. Компанія робить ставку на те що для таких сфер як кібербезпека, розробка ПЗ та робота з документами користувачі готові платити більше за максимальну якість. А якщо потрібна ще й висока швидкість — вони будуть готові заплатити ще більше.
Тому Opus 5 це не повна заміна Fable. Швидше це модель яку Anthropic нарешті зробила достатньо сильною, доступною та передбачуваною для щоденної роботи.
І можливо головний висновок цього релізу такий: майбутня конкуренція моделей відбуватиметься не лише навколо того хто краще відповідає на запитання а навколо того хто краще виконує довгу роботу від початку до кінця.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Після релізу Claude Fable 5 майбутнє лінійки Opus здавалося невизначеним. Але Anthropic представила Claude Opus 5 — модель яка в багатьох завданнях перевершує Fable, коштує дешевше і доступна ширшому колу користувачів.
І це не просто чергове оновлення бенчмарків.
Claude Opus 5 отримав контекст до 1 млн токенів, п'ять рівнів reasoning, підтримку інструментів, роботу із зображеннями та окремий Fast Mode приблизно у 2.5 раза швидший за стандартний.
Але найцікавіше — результати.
На Artificial Analysis Intelligence Index новий Opus посів перше місце з 61 балом, трохи випередивши Claude Fable 5 та GPT-5.6 Sol. У Coding Agent Index він розділив перше місце з GPT-5.6 Sol. Схожа картина і на інших незалежних бенчмарках — Zapier та Cursor також ставлять Opus 5 серед лідерів у своїх власних тестах на реальні агентні задачі.
А на ARC-AGI-3, де агент має самостійно розібратися з правилами незнайомого середовища, Claude Opus 5 показав 30.2%. Найближчий конкурент GPT-5.6 Sol отримав лише 7.8%.
Тобто найбільша перевага нової моделі проявилася не у звичайному знанні фактів чи написанні текстів а саме у здатності навчатися під час виконання завдання.
Це добре узгоджується зі стратегією Anthropic. Компанія заявляє у власній документації що Opus 5 краще делегує роботу субагентам, перевіряє власні результати, виконує довгі програмні та бізнес-процеси. Anthropic навіть рекомендує прибирати частину старих інструкцій на кшталт "обов'язково перевір свою відповідь" — модель і без цього схильна перевіряти себе надто ретельно.
Окремо компанія переглянула систему безпеки. Claude Opus 5 усуває більшість претензій користувачів до Fable 5: менше необґрунтованих fallback-відмов, менше блокувань безпечних наукових тем, значно нижча ціна, доступність у дешевших підписках і відсутність політики 30-денного зберігання даних яка була головним болем для enterprise-клієнтів. Аналіз власного коду на вразливості офіційно дозволений. Водночас запити на створення експлойтів або проведення атак усе ще можуть спричинити fallback на старішу модель.
Водночас Claude Fable 5 усе ще має переваги. Він рідше галюцинує, краще відтворює фактичну інформацію і в деяких складних сценаріях залишається сильнішою моделлю. Не виключено також що нинішні бенчмарки ще не повністю відображають реальну різницю між двома моделями — до речі окремо варто згадати що TechCrunch розбирав і чутки про те що успіх Kimi K3 пов'язаний з експлуатацією Fable 5 — експерти цю версію не підтверджують.
При цьому Opus 5 коштує через API $5 за мільйон вхідних і $25 за мільйон вихідних токенів. Це дешевше за Fable хоча модель усе одно залишається дорожчою за більшість конкурентів.
Схоже Anthropic свідомо не бере участі у перегонах за найдешевший і найшвидший inference. Поки більшість AI-компаній робить ставку на швидкість і здешевлення, Anthropic рухається у протилежному напрямку — створює великі, повільніші але дуже компетентні моделі. Компанія робить ставку на те що для таких сфер як кібербезпека, розробка ПЗ та робота з документами користувачі готові платити більше за максимальну якість. А якщо потрібна ще й висока швидкість — вони будуть готові заплатити ще більше.
Тому Opus 5 це не повна заміна Fable. Швидше це модель яку Anthropic нарешті зробила достатньо сильною, доступною та передбачуваною для щоденної роботи.
І можливо головний висновок цього релізу такий: майбутня конкуренція моделей відбуватиметься не лише навколо того хто краще відповідає на запитання а навколо того хто краще виконує довгу роботу від початку до кінця.
🔔 ПІДПИСАТИСЯ
👍7🔥3❤1👾1
10 речей про LLM, які варто знати — 9/10 🧠
##, списки та блоки в промптах — це не просто оформлення
Гарного дня! 👋
Продовжуємо серію. Минулого разу говорили про те що контраст робить пояснення точнішим. Сьогодні про іншу річ яку часто недооцінюють — саму розмітку промпта.
Коли ми пишемо промпт так:
символи ##, списки та блоки допомагають не лише людині швидше прочитати інструкцію. Вони також дають мовній моделі сигнали про структуру тексту: де починається новий розділ, що є завданням а що контекстом, які вимоги незалежні одна від одної, де знаходяться приклади або вхідні дані, у якому форматі потрібно повернути результат.
Але тут є важливе уточнення.
Markdown це не програмний синтаксис який LLM виконує за жорсткими правилами. Заголовок "## Important" не отримує автоматично вищий пріоритет лише через два символи #. Це радше м'яка структурна розмітка.
Моделі навчалися на великій кількості документації, README-файлів, коду, специфікацій та вебсторінок. Тому Markdown, XML, JSON і схожі формати для них знайомі способи організації інформації.
Саме тому OpenAI рекомендує використовувати Markdown-заголовки та списки для поділу промпта на секції а XML-теги для відокремлення документів, контексту й метаданих.
Anthropic особливо активно рекомендує конструкції на кшталт:
Google радить обрати один спосіб структурування, Markdown або XML, і використовувати його послідовно. Microsoft і Mistral також зазначають що ці формати добре знайомі моделям через структуру даних на яких вони навчалися.
Які символи краще використовувати
Заголовки #, ##, ### для логічних розділів: "## Завдання", "## Обмеження", "## Формат відповіді".
Списки для окремих вимог: "Збережи головну думку", "Прибери повтори", "Додай конкретику".
Нумеровані списки коли важливий порядок дій: "1. Проаналізуй текст", "2. Знайди шаблонні фрази", "3. Перепиши", "4. Перевір результат".
Потрійні зворотні лапки щоб відокремити текст, код або дані від самої інструкції.
XML-теги коли промпт великий, містить кілька документів або має вкладену структуру.
А ось конструкція "Role: AI content editor" з подвійною стрілкою на початку виглядає ефектно але з погляду стандартного Markdown такий символ означає вкладену цитату а не спеціальне поле промпта. Краще написати звичайним заголовком: "## Role" і далі текст.
Головний best practice
Не намагайтеся "запрограмувати" модель декоративними символами типу потрійних знаків оклику чи стрілок навколо слів MUST FOLLOW. Краще створити просту й зрозумілу структуру: Goal, Context, Requirements, Input, Output.
Дослідження впливу Markdown, JSON, YAML і plain text показує що формат промпта справді може впливати на якість відповіді. Але універсального переможця немає: в одних задачах краще працює Markdown, в інших XML, JSON або навіть звичайний текст. Дослідження використання розділювачів у промптах підтверджує той самий висновок.
Тому структура це не магія і не гарантія. Це спосіб зменшити неоднозначність, зробити інструкцію зрозумілішою, відокремити команди від даних, спростити тестування і підтримку промптів, підвищити ймовірність стабільного результату.
Markdown не зовсім рідна мова LLM. Але це точно один із найбільш знайомих їй діалектів.
Зберігай щоб не загубити, а наступного разу — ще один важливий факт про LLM 👀
🔔 ПІДПИСАТИСЯ
##, списки та блоки в промптах — це не просто оформлення
Гарного дня! 👋
Продовжуємо серію. Минулого разу говорили про те що контраст робить пояснення точнішим. Сьогодні про іншу річ яку часто недооцінюють — саму розмітку промпта.
Коли ми пишемо промпт так:
## Role
AI content editor
## Goal
Зробити текст природнішим
## Keep
- основну думку
- факти
- стиль автора
## Remove
- шаблонні фрази
- повтори
- надмірні підсумкисимволи ##, списки та блоки допомагають не лише людині швидше прочитати інструкцію. Вони також дають мовній моделі сигнали про структуру тексту: де починається новий розділ, що є завданням а що контекстом, які вимоги незалежні одна від одної, де знаходяться приклади або вхідні дані, у якому форматі потрібно повернути результат.
Але тут є важливе уточнення.
Markdown це не програмний синтаксис який LLM виконує за жорсткими правилами. Заголовок "## Important" не отримує автоматично вищий пріоритет лише через два символи #. Це радше м'яка структурна розмітка.
Моделі навчалися на великій кількості документації, README-файлів, коду, специфікацій та вебсторінок. Тому Markdown, XML, JSON і схожі формати для них знайомі способи організації інформації.
Саме тому OpenAI рекомендує використовувати Markdown-заголовки та списки для поділу промпта на секції а XML-теги для відокремлення документів, контексту й метаданих.
Anthropic особливо активно рекомендує конструкції на кшталт:
<instructions>
Перепиши текст.
</instructions>
<context>
Текст призначений для Telegram.
</context>
<source_text>
...
</source_text>Google радить обрати один спосіб структурування, Markdown або XML, і використовувати його послідовно. Microsoft і Mistral також зазначають що ці формати добре знайомі моделям через структуру даних на яких вони навчалися.
Які символи краще використовувати
Заголовки #, ##, ### для логічних розділів: "## Завдання", "## Обмеження", "## Формат відповіді".
Списки для окремих вимог: "Збережи головну думку", "Прибери повтори", "Додай конкретику".
Нумеровані списки коли важливий порядок дій: "1. Проаналізуй текст", "2. Знайди шаблонні фрази", "3. Перепиши", "4. Перевір результат".
Потрійні зворотні лапки щоб відокремити текст, код або дані від самої інструкції.
XML-теги коли промпт великий, містить кілька документів або має вкладену структуру.
А ось конструкція "Role: AI content editor" з подвійною стрілкою на початку виглядає ефектно але з погляду стандартного Markdown такий символ означає вкладену цитату а не спеціальне поле промпта. Краще написати звичайним заголовком: "## Role" і далі текст.
Головний best practice
Не намагайтеся "запрограмувати" модель декоративними символами типу потрійних знаків оклику чи стрілок навколо слів MUST FOLLOW. Краще створити просту й зрозумілу структуру: Goal, Context, Requirements, Input, Output.
Дослідження впливу Markdown, JSON, YAML і plain text показує що формат промпта справді може впливати на якість відповіді. Але універсального переможця немає: в одних задачах краще працює Markdown, в інших XML, JSON або навіть звичайний текст. Дослідження використання розділювачів у промптах підтверджує той самий висновок.
Тому структура це не магія і не гарантія. Це спосіб зменшити неоднозначність, зробити інструкцію зрозумілішою, відокремити команди від даних, спростити тестування і підтримку промптів, підвищити ймовірність стабільного результату.
Markdown не зовсім рідна мова LLM. Але це точно один із найбільш знайомих їй діалектів.
Зберігай щоб не загубити, а наступного разу — ще один важливий факт про LLM 👀
🔔 ПІДПИСАТИСЯ
❤8👍4🔥2
Більше токенів ≠ більше продуктивності
Доброго ранку ☕️
Останнім часом в AI-середовищі набрала популярності доволі проста ідея: хочете отримувати більше користі від AI — використовуйте більше токенів.
Запускайте більше агентів. Давайте їм більше контексту. Нехай вони довше думають. Паралельно запускайте ще кілька. І взагалі чим більше compute ви спалюєте тим продуктивнішими стаєте.
Для цього навіть з'явився термін — tokenmaxxing.
І в цій ідеї є частина правди. Сучасні reasoning-моделі справді можуть використовувати додатковий compute для складніших задач. Агенти можуть паралельно досліджувати різні рішення. Більший контекст дозволяє працювати з більшими кодовими базами та документами. METR документує як стрімко зростає час автономної роботи моделей над задачами — межа того скільки токенів ми можемо корисно використати постійно зростає.
Але є одна проблема.
У певний момент bottleneck перестає бути в AI.
Модель уже написала код — але його має хтось перевірити. Агенти запропонували п'ять архітектур — але хтось має вибрати одну. AI створив 20 варіантів документа — але тепер людині потрібно прочитати 20 варіантів.
Можна запустити ще десять агентів. Але якщо процес review, прийняття рішень або інтеграції залишився тим самим — ви просто швидше створюєте чергу роботи для людей. Починається diminishing return: кожна наступна тисяча або мільйон токенів приносить усе менше реальної користі.
І тут є ще один цікавий момент.
Компанії які продають AI compute природно зацікавлені в тому щоб ми використовували його більше. Це не якась особливість AI-бізнесу. Автосервіси десятиліттями радили міняти мастило частіше ніж це реально потрібно багатьом автомобілям. У рекламі зубної пасти щітку покривають пастою майже повністю хоча стоматологи рекомендують значно меншу кількість. Продукт може бути дуже корисним і водночас його виробнику вигідно щоб ви використовували його більше.
З AI відбувається приблизно те саме.
Тому питання яке варто ставити компаніям звучить так: "де додатковий AI реально збільшує throughput нашої системи?"
Іноді відповіддю справді будуть мільйони додаткових токенів і десятки агентів. А іноді зміна процесу review, автоматизація integration pipeline, кращі evals або просто усунення організаційного bottleneck.
Бо мета не максимізувати кількість використаних токенів. Мета максимізувати кількість корисної роботи яка доходить до production.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Останнім часом в AI-середовищі набрала популярності доволі проста ідея: хочете отримувати більше користі від AI — використовуйте більше токенів.
Запускайте більше агентів. Давайте їм більше контексту. Нехай вони довше думають. Паралельно запускайте ще кілька. І взагалі чим більше compute ви спалюєте тим продуктивнішими стаєте.
Для цього навіть з'явився термін — tokenmaxxing.
І в цій ідеї є частина правди. Сучасні reasoning-моделі справді можуть використовувати додатковий compute для складніших задач. Агенти можуть паралельно досліджувати різні рішення. Більший контекст дозволяє працювати з більшими кодовими базами та документами. METR документує як стрімко зростає час автономної роботи моделей над задачами — межа того скільки токенів ми можемо корисно використати постійно зростає.
Але є одна проблема.
У певний момент bottleneck перестає бути в AI.
Модель уже написала код — але його має хтось перевірити. Агенти запропонували п'ять архітектур — але хтось має вибрати одну. AI створив 20 варіантів документа — але тепер людині потрібно прочитати 20 варіантів.
Можна запустити ще десять агентів. Але якщо процес review, прийняття рішень або інтеграції залишився тим самим — ви просто швидше створюєте чергу роботи для людей. Починається diminishing return: кожна наступна тисяча або мільйон токенів приносить усе менше реальної користі.
І тут є ще один цікавий момент.
Компанії які продають AI compute природно зацікавлені в тому щоб ми використовували його більше. Це не якась особливість AI-бізнесу. Автосервіси десятиліттями радили міняти мастило частіше ніж це реально потрібно багатьом автомобілям. У рекламі зубної пасти щітку покривають пастою майже повністю хоча стоматологи рекомендують значно меншу кількість. Продукт може бути дуже корисним і водночас його виробнику вигідно щоб ви використовували його більше.
З AI відбувається приблизно те саме.
Тому питання яке варто ставити компаніям звучить так: "де додатковий AI реально збільшує throughput нашої системи?"
Іноді відповіддю справді будуть мільйони додаткових токенів і десятки агентів. А іноді зміна процесу review, автоматизація integration pipeline, кращі evals або просто усунення організаційного bottleneck.
Бо мета не максимізувати кількість використаних токенів. Мета максимізувати кількість корисної роботи яка доходить до production.
🔔 ПІДПИСАТИСЯ
👍7❤2🔥1
DeepSeek знову показує що більша модель не завжди краща
Доброго ранку ☕️
DeepSeek оновила відносно компактну V4-Flash, не змінюючи архітектуру та кількість параметрів. І після нового fine-tuning вона обігнала власну більшу V4-Pro. На Artificial Analysis Intelligence Index: V4-Flash 50, V4-Pro 44, GPT-5.6 Luna 51.
Але цікавіше тут не результат а спосіб яким його отримали.
Компанія не зробила модель більшою. Вона переробила post-training pipeline. Щоб зрозуміти чому це працює, варто розібрати механізм по кроках.
Крок перший. Спеціалізація замість узагальнення
Замість того щоб одразу вчити одну універсальну модель на суміші всіх типів задач, DeepSeek спочатку створила окремих спеціалістів. Для кожного домену, математики, coding, agentic tasks, instruction following, тренувалася окрема модель. Кожна проходила спочатку SFT на якісних даних свого домену щоб закласти базову компетенцію. Потім кожного спеціаліста додатково донавчали через reinforcement learning з GRPO, Group Relative Policy Optimization, з reward-моделями підібраними саме під критерії успіху цього конкретного домену.
Ідея тут проста і водночас нетривіальна. Оптимізаційний сигнал для математики і для agentic tool use дуже різний за формою. Коли ви тренуєте одну модель одразу на всьому, градієнти з різних доменів можуть конфліктувати і взаємно розмивати одне одного. Розділивши тренування по спеціалістах ви даєте кожному домену чистий незашумлений сигнал.
Крок другий. On-policy distillation як спосіб зібрати спеціалістів назад в одну модель
Після того як з'явилося понад десять сильних спеціалізованих моделей постала інша задача: як перенести їхні знання назад в одну універсальну модель не втративши якість кожного окремого домену.
Тут DeepSeek використала on-policy distillation. Класична дистиляція навчає студента копіювати виходи вчителя на фіксованому датасеті прикладів. Проблема цього підходу в тому що студент вчиться імітувати відповіді на чужих траєкторіях, тих що згенерував сам вчитель, а не на власних. Коли студент потім генерує щось трохи інше, він потрапляє в стани яких ніколи не бачив під час навчання і починає деградувати.
On-policy distillation вирішує це інакше. Студент сам генерує токени під час навчання, а вчитель у реальному часі оцінює якість саме цих згенерованих студентом токенів і дає сигнал корекції. Тобто модель вчиться виправляти власні помилки а не просто копіювати чужі правильні відповіді. Це набагато ближче до того як реально working знання переносяться, через власний досвід а не через спостереження.
Об'єднавши понад десять доменних спеціалістів через цей механізм в одну модель DeepSeek отримала приблизно 10 пунктів приросту Intelligence Index порівняно з квітневою preview-версією, без жодної зміни в самій архітектурі.
Чому це загалом важливо як інженерний прийом
Ключовий висновок тут не про DeepSeek конкретно а про сам патерн: розділяй і навчай, потім об'єднуй через on-policy сигнал а не через offline копіювання. Це дозволяє паралелізувати саму розробку моделі, кожна команда може незалежно покращувати свого спеціаліста, і водночас уникнути втрати якості яка зазвичай супроводжує зведення кількох джерел знань в одну систему.
Це той самий загальний принцип розкладання складної задачі на спеціалізовані компоненти з подальшою акуратною інтеграцією, який ми вже бачили в інших архітектурних рішеннях цього року. Тільки тут він застосований не до інференсу а до самого процесу навчання моделі.
Ще нещодавно головним питанням було скільки параметрів має модель. Потім наскільки вона розумна. Зараз дедалі важливішим стає третє питання: скільки цього інтелекту я отримую за долар. І DeepSeek показує що відповідь на нього часто лежить не в масштабуванні а в тому як саме влаштований pipeline навчання.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
DeepSeek оновила відносно компактну V4-Flash, не змінюючи архітектуру та кількість параметрів. І після нового fine-tuning вона обігнала власну більшу V4-Pro. На Artificial Analysis Intelligence Index: V4-Flash 50, V4-Pro 44, GPT-5.6 Luna 51.
Але цікавіше тут не результат а спосіб яким його отримали.
Компанія не зробила модель більшою. Вона переробила post-training pipeline. Щоб зрозуміти чому це працює, варто розібрати механізм по кроках.
Крок перший. Спеціалізація замість узагальнення
Замість того щоб одразу вчити одну універсальну модель на суміші всіх типів задач, DeepSeek спочатку створила окремих спеціалістів. Для кожного домену, математики, coding, agentic tasks, instruction following, тренувалася окрема модель. Кожна проходила спочатку SFT на якісних даних свого домену щоб закласти базову компетенцію. Потім кожного спеціаліста додатково донавчали через reinforcement learning з GRPO, Group Relative Policy Optimization, з reward-моделями підібраними саме під критерії успіху цього конкретного домену.
Ідея тут проста і водночас нетривіальна. Оптимізаційний сигнал для математики і для agentic tool use дуже різний за формою. Коли ви тренуєте одну модель одразу на всьому, градієнти з різних доменів можуть конфліктувати і взаємно розмивати одне одного. Розділивши тренування по спеціалістах ви даєте кожному домену чистий незашумлений сигнал.
Крок другий. On-policy distillation як спосіб зібрати спеціалістів назад в одну модель
Після того як з'явилося понад десять сильних спеціалізованих моделей постала інша задача: як перенести їхні знання назад в одну універсальну модель не втративши якість кожного окремого домену.
Тут DeepSeek використала on-policy distillation. Класична дистиляція навчає студента копіювати виходи вчителя на фіксованому датасеті прикладів. Проблема цього підходу в тому що студент вчиться імітувати відповіді на чужих траєкторіях, тих що згенерував сам вчитель, а не на власних. Коли студент потім генерує щось трохи інше, він потрапляє в стани яких ніколи не бачив під час навчання і починає деградувати.
On-policy distillation вирішує це інакше. Студент сам генерує токени під час навчання, а вчитель у реальному часі оцінює якість саме цих згенерованих студентом токенів і дає сигнал корекції. Тобто модель вчиться виправляти власні помилки а не просто копіювати чужі правильні відповіді. Це набагато ближче до того як реально working знання переносяться, через власний досвід а не через спостереження.
Об'єднавши понад десять доменних спеціалістів через цей механізм в одну модель DeepSeek отримала приблизно 10 пунктів приросту Intelligence Index порівняно з квітневою preview-версією, без жодної зміни в самій архітектурі.
Чому це загалом важливо як інженерний прийом
Ключовий висновок тут не про DeepSeek конкретно а про сам патерн: розділяй і навчай, потім об'єднуй через on-policy сигнал а не через offline копіювання. Це дозволяє паралелізувати саму розробку моделі, кожна команда може незалежно покращувати свого спеціаліста, і водночас уникнути втрати якості яка зазвичай супроводжує зведення кількох джерел знань в одну систему.
Це той самий загальний принцип розкладання складної задачі на спеціалізовані компоненти з подальшою акуратною інтеграцією, який ми вже бачили в інших архітектурних рішеннях цього року. Тільки тут він застосований не до інференсу а до самого процесу навчання моделі.
Ще нещодавно головним питанням було скільки параметрів має модель. Потім наскільки вона розумна. Зараз дедалі важливішим стає третє питання: скільки цього інтелекту я отримую за долар. І DeepSeek показує що відповідь на нього часто лежить не в масштабуванні а в тому як саме влаштований pipeline навчання.
🔔 ПІДПИСАТИСЯ
👍6🔥4✍1
10 речей про LLM, які варто знати — 10/10 🧠
Ритм видає AI
Гарного дня! 👋
Останній пост із серії. Минулого разу говорили про розмітку промптів. Сьогодні про те як розпізнати AI-текст навіть коли він написаний бездоганно.
AI-текст часто впізнається не за помилками. Навпаки, він може бути занадто правильним. Речення граматично чисті. Переходи логічні. Абзаци акуратні. Висновок на місці. І саме тому щось відчувається не так.
Проблема це ритм. Порівняйте.
AI-ритм: "У сучасному світі штучний інтелект відкриває нові можливості для бізнесу, освіти та творчості."
І трохи живіше: "AI вже не просто допомагає писати швидше. Іноді він пише настільки гладко, що текст перестає звучати як людський."
Різниця не лише у словах. У другому випадку змінюється темп.
Люди пишуть нерівно
Дослідження яке порівнювало людські тексти з текстами кількох сімейств LLM знайшло цікаву відмінність: у людей розподіл довжини речень був більш розкиданим.
AI: довге, довге, довге, довге.
Людина: довге, коротке, середнє, дуже коротке, знову довге.
Справа не в тому щоб механічно чергувати 8 і 20 слів. Темп змінюється разом із думкою. Десь треба пояснити. Десь зупинитися. А десь достатньо трьох слів.
Але довжина речень лише частина проблеми
Інші стилометричні дослідження знаходять у текстах LLM більшу граматичну стандартизацію. Модель може використовувати різні слова але постійно повертатися до схожих конструкцій: "це не лише змінює X але й відкриває Y", "це не просто допомагає X а й дозволяє Y". Начебто різні речення. А ритмічний шаблон той самий.
Саме тому текст може бути грамотним, логічним і навіть красивим але все одно звучати так ніби його зібрали.
AI особливо любить трійки
Це одна з моїх улюблених деталей. У свіжому дослідженні риторичних конструкцій автори порівнювали експертні людські тексти з LLM. Один із найсильніших сигналів це tricolon, конструкції з трьох паралельних елементів: "faster, cheaper, more scalable" або "для бізнесу, освіти та творчості". LLM використовували такі конструкції значно частіше за людей.
І якщо почати це помічати розбачити вже складно. AI любить три переваги, три проблеми, три наслідки, три приклади. Навіть цей список зараз небезпечно близький до AI 🙂
Ще одна ознака це занадто рівномірна красивість
У тому ж дослідженні риторичні прийоми у LLM були більш рівномірно розподілені по тексту. Людина може написати три сухі абзаци а потім раптом одне живе речення, потім довге пояснення, потім знову коротка фраза. У людини риторика з'являється там де її вимагає думка. AI часто намагається підтримувати однакову якість і гладкість увесь час.
Grammarly описує схожі патерни: рівний тон, повторювана фразеологія, структуровані переходи, передбачуване форматування, однакова довжина речень.
Тобто проблема AI-тексту часто не в тому що він погано написаний. Він написаний занадто рівно.
А що з perplexity та burstiness
Навколо AI-детекторів популярна ідея що людський текст має більше burstiness, непередбачуваності та варіативності. У цьому є сенс. Але я б не перетворював це на жорстке правило "низька burstiness означає AI".
Велике дослідження 2026 року перевірило сотні лінгвістичних характеристик на десятках LLM і різних типах тексту. Висновок важливий: багато ознак справді повторюються але вони сильно залежать від конкретної моделі, промпта та домену. Тому рівний ритм це сигнал а не детектор.
Ethan Mollick називає це ще простіше — sameness
Дослідник Wharton Ethan Mollick писав що його починає дратувати саме sameness of AI writing, однаковість AI-текстів. І це мабуть найточніше слово.
LLM навчена створювати хороший, зрозумілий, структурований текст. Тому на типовий запит "напиши професійний пост про AI" вона дуже легко сходиться до статистичного центру хорошого професійного тексту: вступ, теза, аргументи, плавний перехід, список, висновок. Немає нічого неправильного. Але немає й тертя.
Продовження далi 👇🏻
🔔 ПІДПИСАТИСЯ
Ритм видає AI
Гарного дня! 👋
Останній пост із серії. Минулого разу говорили про розмітку промптів. Сьогодні про те як розпізнати AI-текст навіть коли він написаний бездоганно.
AI-текст часто впізнається не за помилками. Навпаки, він може бути занадто правильним. Речення граматично чисті. Переходи логічні. Абзаци акуратні. Висновок на місці. І саме тому щось відчувається не так.
Проблема це ритм. Порівняйте.
AI-ритм: "У сучасному світі штучний інтелект відкриває нові можливості для бізнесу, освіти та творчості."
І трохи живіше: "AI вже не просто допомагає писати швидше. Іноді він пише настільки гладко, що текст перестає звучати як людський."
Різниця не лише у словах. У другому випадку змінюється темп.
Люди пишуть нерівно
Дослідження яке порівнювало людські тексти з текстами кількох сімейств LLM знайшло цікаву відмінність: у людей розподіл довжини речень був більш розкиданим.
AI: довге, довге, довге, довге.
Людина: довге, коротке, середнє, дуже коротке, знову довге.
Справа не в тому щоб механічно чергувати 8 і 20 слів. Темп змінюється разом із думкою. Десь треба пояснити. Десь зупинитися. А десь достатньо трьох слів.
Але довжина речень лише частина проблеми
Інші стилометричні дослідження знаходять у текстах LLM більшу граматичну стандартизацію. Модель може використовувати різні слова але постійно повертатися до схожих конструкцій: "це не лише змінює X але й відкриває Y", "це не просто допомагає X а й дозволяє Y". Начебто різні речення. А ритмічний шаблон той самий.
Саме тому текст може бути грамотним, логічним і навіть красивим але все одно звучати так ніби його зібрали.
AI особливо любить трійки
Це одна з моїх улюблених деталей. У свіжому дослідженні риторичних конструкцій автори порівнювали експертні людські тексти з LLM. Один із найсильніших сигналів це tricolon, конструкції з трьох паралельних елементів: "faster, cheaper, more scalable" або "для бізнесу, освіти та творчості". LLM використовували такі конструкції значно частіше за людей.
І якщо почати це помічати розбачити вже складно. AI любить три переваги, три проблеми, три наслідки, три приклади. Навіть цей список зараз небезпечно близький до AI 🙂
Ще одна ознака це занадто рівномірна красивість
У тому ж дослідженні риторичні прийоми у LLM були більш рівномірно розподілені по тексту. Людина може написати три сухі абзаци а потім раптом одне живе речення, потім довге пояснення, потім знову коротка фраза. У людини риторика з'являється там де її вимагає думка. AI часто намагається підтримувати однакову якість і гладкість увесь час.
Grammarly описує схожі патерни: рівний тон, повторювана фразеологія, структуровані переходи, передбачуване форматування, однакова довжина речень.
Тобто проблема AI-тексту часто не в тому що він погано написаний. Він написаний занадто рівно.
А що з perplexity та burstiness
Навколо AI-детекторів популярна ідея що людський текст має більше burstiness, непередбачуваності та варіативності. У цьому є сенс. Але я б не перетворював це на жорстке правило "низька burstiness означає AI".
Велике дослідження 2026 року перевірило сотні лінгвістичних характеристик на десятках LLM і різних типах тексту. Висновок важливий: багато ознак справді повторюються але вони сильно залежать від конкретної моделі, промпта та домену. Тому рівний ритм це сигнал а не детектор.
Ethan Mollick називає це ще простіше — sameness
Дослідник Wharton Ethan Mollick писав що його починає дратувати саме sameness of AI writing, однаковість AI-текстів. І це мабуть найточніше слово.
LLM навчена створювати хороший, зрозумілий, структурований текст. Тому на типовий запит "напиши професійний пост про AI" вона дуже легко сходиться до статистичного центру хорошого професійного тексту: вступ, теза, аргументи, плавний перехід, список, висновок. Немає нічого неправильного. Але немає й тертя.
Продовження далi 👇🏻
🔔 ПІДПИСАТИСЯ
1❤6👍3🔥2
Що з цим робити
Не просити "зроби більш людяно". Це майже нічого не означає.
Краще працює інший підхід. Дайте моделі 3-5 ваших реальних текстів і попросіть окремо проаналізувати довжину речень, розмір абзаців, синтаксичні конструкції, переходи, короткі фрагменти, ритм і pacing. А потім уже писати новий текст у цьому патерні.
Це близько до підходу який описує Tiago Forte: спочатку змусити AI витягнути style guide з вашого власного письма а вже потім використовувати його. Anthropic у своїх рекомендаціях теж радить давати моделі кілька різноманітних прикладів коли важливі тон, структура та формат. А Mollick взагалі пропонує залишати AI роль reader/editor а не повністю віддавати йому авторство. Це те як використовю AI я для написання текстiв ✍️
Мені ця логіка подобається найбільше. Бо хороший текст має не лише сенс. Він має темп. Іноді швидкий. Іноді повільний.
На цьому серія 10 речей про LLM завершена. Дякую що читали весь цей час 🙏
🔔 ПІДПИСАТИСЯ
Не просити "зроби більш людяно". Це майже нічого не означає.
Краще працює інший підхід. Дайте моделі 3-5 ваших реальних текстів і попросіть окремо проаналізувати довжину речень, розмір абзаців, синтаксичні конструкції, переходи, короткі фрагменти, ритм і pacing. А потім уже писати новий текст у цьому патерні.
Це близько до підходу який описує Tiago Forte: спочатку змусити AI витягнути style guide з вашого власного письма а вже потім використовувати його. Anthropic у своїх рекомендаціях теж радить давати моделі кілька різноманітних прикладів коли важливі тон, структура та формат. А Mollick взагалі пропонує залишати AI роль reader/editor а не повністю віддавати йому авторство. Це те як використовю AI я для написання текстiв ✍️
Мені ця логіка подобається найбільше. Бо хороший текст має не лише сенс. Він має темп. Іноді швидкий. Іноді повільний.
На цьому серія 10 речей про LLM завершена. Дякую що читали весь цей час 🙏
🔔 ПІДПИСАТИСЯ
2👍14🔥8❤1🥰1💯1
4 навички без яких розробнику буде складно в AI-era
Доброго ранку ☕️
Andrew Ng та команда DeepLearning.AI проаналізували понад 10 000 вакансій, провели десятки інтерв'ю з AI-експертами, hiring-менеджерами та рекрутерами й спробували відповісти на просте питання: що сьогодні насправді варто вчити розробнику якщо навколо AI занадто багато шуму та хайпу?
У результаті вони виділили 4 ключові групи навичок.
1. Вміти будувати AI-системи а не просто викликати API
LLM принципово відрізняються від класичного software: їхній результат не є повністю детермінованим. Тому недостатньо просто знати як підключити модель. Потрібно розуміти LLM та context engineering, RAG, agentic workflows, ML і deep learning, evals, error analysis. І мабуть найважливіше — вміти вимірювати якість AI-системи та системно покращувати її поведінку.
Тобто AI engineering дедалі менше схожий на "написав prompt, наче працює". І дедалі більше на інженерний цикл: побудувати → оцінити → проаналізувати помилки → покращити → повторити.
2. Software Engineering нікуди не зникає. Навпаки
Є популярна думка що coding agents зроблять фундаментальні знання програмування менш важливими. Ng фактично говорить протилежне.
Коли агент пише значну частину коду за тебе твоєю роботою стає розуміти чи хороші рішення він приймає. Архітектура, масштабованість, надійність, безпека, приватність, робота з даними, тестування, вартість. Якщо ти не бачиш цих trade-offs — агент теж навряд чи магічно їх вирішить. Більше того ти навіть не знатимеш який контекст йому дати щоб він прийняв правильне рішення.
Тому парадокс AI-era може бути таким: чим більше коду пише AI тим важливішим стає розуміння інженерних основ.
3. Coding agents це вже окрема інженерна навичка
Не просто "користуватися Cursor, Claude Code чи Copilot". А розуміти як організувати роботу агента. Коли дати йому автономність. Коли втрутитися. Коли спочатку попросити скласти план. Як керувати контекстом. Як написати specification. Як дати агенту тести чи інші verifiers щоб він сам міг перевіряти результат. Як запускати кількох агентів паралельно. І що теж важливо — як не дати агенту випадково зробити щось веселе з production database 🙂
Фактично виникає новий рівень абстракції: раніше ми керували кодом, тепер дедалі частіше керуємо системами які пишуть код.
4. Найцікавіший пункт — Shaping the Build
Coding agents дедалі краще реалізують чітко сформульовані задачі. Тому bottleneck поступово зміщується. Проблема вже не тільки в "як це побудувати" а все частіше в "що саме потрібно побудувати".
Тут інженеру вже недостатньо отримати готовий дизайн і перетворити його на код. Потрібні product sense, розуміння бізнесу і користувача, здатність формулювати проблему, здатність вирішувати що має потрапити в specification, розуміння коли швидко зробити MVP а коли навпаки сповільнитися.
Це одна з найважливіших змін у професії. AI поступово забирає частину execution. А цінність людини зміщується вище: проблема → рішення → специфікація → перевірка.
Хороший інженер майбутнього це не той хто швидше за всіх пише код. А той хто правильно визначає проблему, формує рішення, керує AI у процесі реалізації та може довести що результат справді працює.
І є ще п'ята навичка яка фактично лежить під усіма чотирма — постійно перевчатися. Бо workflows які сьогодні здаються cutting-edge через рік цілком можуть виглядати так само як сьогодні виглядає "скопіювати код із ChatGPT у IDE".
І саме це мабуть зараз найбільше відрізняє AI engineering від класичного software development.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Andrew Ng та команда DeepLearning.AI проаналізували понад 10 000 вакансій, провели десятки інтерв'ю з AI-експертами, hiring-менеджерами та рекрутерами й спробували відповісти на просте питання: що сьогодні насправді варто вчити розробнику якщо навколо AI занадто багато шуму та хайпу?
У результаті вони виділили 4 ключові групи навичок.
1. Вміти будувати AI-системи а не просто викликати API
LLM принципово відрізняються від класичного software: їхній результат не є повністю детермінованим. Тому недостатньо просто знати як підключити модель. Потрібно розуміти LLM та context engineering, RAG, agentic workflows, ML і deep learning, evals, error analysis. І мабуть найважливіше — вміти вимірювати якість AI-системи та системно покращувати її поведінку.
Тобто AI engineering дедалі менше схожий на "написав prompt, наче працює". І дедалі більше на інженерний цикл: побудувати → оцінити → проаналізувати помилки → покращити → повторити.
2. Software Engineering нікуди не зникає. Навпаки
Є популярна думка що coding agents зроблять фундаментальні знання програмування менш важливими. Ng фактично говорить протилежне.
Коли агент пише значну частину коду за тебе твоєю роботою стає розуміти чи хороші рішення він приймає. Архітектура, масштабованість, надійність, безпека, приватність, робота з даними, тестування, вартість. Якщо ти не бачиш цих trade-offs — агент теж навряд чи магічно їх вирішить. Більше того ти навіть не знатимеш який контекст йому дати щоб він прийняв правильне рішення.
Тому парадокс AI-era може бути таким: чим більше коду пише AI тим важливішим стає розуміння інженерних основ.
3. Coding agents це вже окрема інженерна навичка
Не просто "користуватися Cursor, Claude Code чи Copilot". А розуміти як організувати роботу агента. Коли дати йому автономність. Коли втрутитися. Коли спочатку попросити скласти план. Як керувати контекстом. Як написати specification. Як дати агенту тести чи інші verifiers щоб він сам міг перевіряти результат. Як запускати кількох агентів паралельно. І що теж важливо — як не дати агенту випадково зробити щось веселе з production database 🙂
Фактично виникає новий рівень абстракції: раніше ми керували кодом, тепер дедалі частіше керуємо системами які пишуть код.
4. Найцікавіший пункт — Shaping the Build
Coding agents дедалі краще реалізують чітко сформульовані задачі. Тому bottleneck поступово зміщується. Проблема вже не тільки в "як це побудувати" а все частіше в "що саме потрібно побудувати".
Тут інженеру вже недостатньо отримати готовий дизайн і перетворити його на код. Потрібні product sense, розуміння бізнесу і користувача, здатність формулювати проблему, здатність вирішувати що має потрапити в specification, розуміння коли швидко зробити MVP а коли навпаки сповільнитися.
Це одна з найважливіших змін у професії. AI поступово забирає частину execution. А цінність людини зміщується вище: проблема → рішення → специфікація → перевірка.
Хороший інженер майбутнього це не той хто швидше за всіх пише код. А той хто правильно визначає проблему, формує рішення, керує AI у процесі реалізації та може довести що результат справді працює.
І є ще п'ята навичка яка фактично лежить під усіма чотирма — постійно перевчатися. Бо workflows які сьогодні здаються cutting-edge через рік цілком можуть виглядати так само як сьогодні виглядає "скопіювати код із ChatGPT у IDE".
І саме це мабуть зараз найбільше відрізняє AI engineering від класичного software development.
🔔 ПІДПИСАТИСЯ
👍12🔥6❤2👏1
Anthropic почала вбудовувати невидимі водяні знаки в тексти Claude
Доброго ранку ☕️
Компанія заявила що така система буде використовуватися у всіх нових моделях Claude а згодом пошириться і на існуючі. Причина — вимоги EU AI Act, який передбачає машинозчитуване маркування AI-контенту і набув чинності 2 серпня.
Але цікавіше те як саме це працює.
Claude не вставляє в текст якийсь прихований символ чи метадані. Замість цього використовується технологія на основі SynthID-Text від Google. Під час генерації модель постійно обирає між кількома приблизно рівнозначними словами або формулюваннями. Наприклад "AI активно змінює ринок" або "AI суттєво трансформує ринок". Для людини різниця майже відсутня. Але алгоритм трохи підштовхує модель до певних варіантів слів за секретним статистичним ключем, який Anthropic порівнює з числом пі за складністю.
У результаті в тексті виникає прихований патерн який спеціальний детектор може знайти пізніше. Тобто водяний знак це не конкретний символ у тексті а статистична структура вибору токенів. Anthropic планує надати API який повертатиме оцінку того наскільки текст схожий на згенерований Claude.
І тут починаються цікаві нюанси.
Це не 100% доказ. Детектор показує ймовірність а не остаточний вердикт. Можливі false positive та false negative. Більше того якщо людина написала текст сама а потім попросила Claude його скоротити, перекласти чи відредагувати, у фінальній версії теж може залишитися watermark-сигнал.
Водяний знак переживає copy-paste і невеликі правки. Але сильний rewrite або paraphrasing потенційно знищить статистичний патерн. Тому теоретично можна просто прогнати текст через іншу LLM.
У коді watermark буде значно слабшим. У звичайному тексті модель має багато варіантів продовження. У коді часто існує один правильний варіант. Якщо потрібно написати "2 + 2 =" модель не може вибрати між 4, 7 або 12 щоб створити сигнал. Тому найбільше watermark-патерну буде в коментарях, документації та місцях де існує кілька допустимих варіантів генерації.
Для зображень використовується інший механізм — C2PA, криптографічно підписані дані про походження файлу які записуються в метадані а не в саме зображення.
І саме тут навколо рішення почалася серйозна дискусія. За даними The Star і TechCrunch, десятки користувачів на X критикували рішення. За два тижні після запуску принаймні чотири платних підписники підтвердили скасування підписки з посиланнями на професійну відповідальність і ризики клієнтських контрактів, а десятки інших заявляли про те саме в соцмережах без підтверджень. Anthropic каже що не спостерігає зростання відтоку клієнтів загалом.
Один користувач на Reddit писав: "Хто потрапить під підозру? Студент який попросив Claude переструктурувати абзац. Журналіст який попросив узагальнити стенограму на двісті сторінок. Той хто мав творчий блок і попросив підібрати синоніми. Всі вони виходять з процесу з цифровим тавром на лобі." Anthropic заперечує таку інтерпретацію і стверджує що watermark "не містить ідентифікуючої інформації і не може бути простежений до конкретної людини чи чату".
Колишній керівник Microsoft Стівен Сінофскі сформулював це як право людини на приватні думки без цифрового сліду.
Є й технічна вразливість системи. Вже за кілька днів після технічного розкриття деталей інструмент на GitHub для видалення таких водяних знаків, що працює проти Claude, SynthID-Text, OpenAI і C2PA, набрав понад 10 000 зірок. Тобто питання наскільки ефективною буде система проти тих хто справді хоче її обійти залишається відкритим, тоді як звичайний користувач який нічого не приховує може отримати false positive.
Найцікавіше що Anthropic схоже лише перша. OpenAI, Google, Meta та Microsoft також підписали європейський Code of Practice on Transparency of AI-generated Content. OpenAI вже застосовує SynthID для зображень і з 31 липня розширила покриття на аудіо.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Компанія заявила що така система буде використовуватися у всіх нових моделях Claude а згодом пошириться і на існуючі. Причина — вимоги EU AI Act, який передбачає машинозчитуване маркування AI-контенту і набув чинності 2 серпня.
Але цікавіше те як саме це працює.
Claude не вставляє в текст якийсь прихований символ чи метадані. Замість цього використовується технологія на основі SynthID-Text від Google. Під час генерації модель постійно обирає між кількома приблизно рівнозначними словами або формулюваннями. Наприклад "AI активно змінює ринок" або "AI суттєво трансформує ринок". Для людини різниця майже відсутня. Але алгоритм трохи підштовхує модель до певних варіантів слів за секретним статистичним ключем, який Anthropic порівнює з числом пі за складністю.
У результаті в тексті виникає прихований патерн який спеціальний детектор може знайти пізніше. Тобто водяний знак це не конкретний символ у тексті а статистична структура вибору токенів. Anthropic планує надати API який повертатиме оцінку того наскільки текст схожий на згенерований Claude.
І тут починаються цікаві нюанси.
Це не 100% доказ. Детектор показує ймовірність а не остаточний вердикт. Можливі false positive та false negative. Більше того якщо людина написала текст сама а потім попросила Claude його скоротити, перекласти чи відредагувати, у фінальній версії теж може залишитися watermark-сигнал.
Водяний знак переживає copy-paste і невеликі правки. Але сильний rewrite або paraphrasing потенційно знищить статистичний патерн. Тому теоретично можна просто прогнати текст через іншу LLM.
У коді watermark буде значно слабшим. У звичайному тексті модель має багато варіантів продовження. У коді часто існує один правильний варіант. Якщо потрібно написати "2 + 2 =" модель не може вибрати між 4, 7 або 12 щоб створити сигнал. Тому найбільше watermark-патерну буде в коментарях, документації та місцях де існує кілька допустимих варіантів генерації.
Для зображень використовується інший механізм — C2PA, криптографічно підписані дані про походження файлу які записуються в метадані а не в саме зображення.
І саме тут навколо рішення почалася серйозна дискусія. За даними The Star і TechCrunch, десятки користувачів на X критикували рішення. За два тижні після запуску принаймні чотири платних підписники підтвердили скасування підписки з посиланнями на професійну відповідальність і ризики клієнтських контрактів, а десятки інших заявляли про те саме в соцмережах без підтверджень. Anthropic каже що не спостерігає зростання відтоку клієнтів загалом.
Один користувач на Reddit писав: "Хто потрапить під підозру? Студент який попросив Claude переструктурувати абзац. Журналіст який попросив узагальнити стенограму на двісті сторінок. Той хто мав творчий блок і попросив підібрати синоніми. Всі вони виходять з процесу з цифровим тавром на лобі." Anthropic заперечує таку інтерпретацію і стверджує що watermark "не містить ідентифікуючої інформації і не може бути простежений до конкретної людини чи чату".
Колишній керівник Microsoft Стівен Сінофскі сформулював це як право людини на приватні думки без цифрового сліду.
Є й технічна вразливість системи. Вже за кілька днів після технічного розкриття деталей інструмент на GitHub для видалення таких водяних знаків, що працює проти Claude, SynthID-Text, OpenAI і C2PA, набрав понад 10 000 зірок. Тобто питання наскільки ефективною буде система проти тих хто справді хоче її обійти залишається відкритим, тоді як звичайний користувач який нічого не приховує може отримати false positive.
Найцікавіше що Anthropic схоже лише перша. OpenAI, Google, Meta та Microsoft також підписали європейський Code of Practice on Transparency of AI-generated Content. OpenAI вже застосовує SynthID для зображень і з 31 липня розширила покриття на аудіо.
🔔 ПІДПИСАТИСЯ
1👍6❤4🔥2
AI-гроші ходять по колу 🤯
Доброго ранку ☕️
Зараз багато говорять про замкнений цикл грошей в AI-індустрії, але розібратися, хто кого фінансує і куди зрештою йдуть ці мільярди, не так просто. Я зібрав усе в одну схему — з цифрами та посиланнями на першоджерела. 🕵🏻♂️🔍 👇🏻
Почнемо з OpenAI. У 2025 році OpenAI, SoftBank, Oracle та MGX запустили Stargate, програму будівництва AI-інфраструктури у США з планом інвестувати до $500 млрд протягом чотирьох років. Це не один дата-центр за $500 млрд як іноді пишуть а ціла інфраструктурна програма.
У лютому 2026 OpenAI оголосила ще один гігантський раунд: $30 млрд від Nvidia, $30 млрд від SoftBank і $50 млрд від Amazon. Пізніше раунд виріс до $122 млрд.
А тепер подивимось куди OpenAI витрачає ці гроші. З Amazon ситуація особливо цікава: Amazon вкладає $50 млрд в OpenAI а OpenAI паралельно розширює контракт з AWS ще на $100 млрд на вісім років. Тобто Amazon дає OpenAI $50 млрд, а OpenAI повертає AWS понад $100 млрд. Це вже дуже схоже на замкнений контур.
З Oracle наступний рівень. За даними Reuters і WSJ OpenAI підписала контракт приблизно на $300 млрд compute протягом п'яти років. А Oracle своєю чергою планувала придбати приблизно $40 млрд Nvidia GPU і здавати ці потужності OpenAI. Отримуємо: OpenAI платить Oracle, Oracle купує чипи у Nvidia. А Nvidia при цьому сама інвестує в OpenAI.
Є ще AMD. OpenAI домовилася розгорнути до 6 GW AMD GPU. У відповідь AMD видала OpenAI warrants на купівлю до 160 млн акцій AMD, на момент угоди це відповідало приблизно 10% компанії за умови виконання всіх milestones. Великий клієнт AMD потенційно стає ще й великим акціонером AMD.
Ще цікавіше стає коли дивитися на Anthropic. У листопаді 2025 Microsoft і Nvidia домовилися інвестувати в Anthropic до $5 млрд і $10 млрд відповідно. У межах тієї ж домовленості Anthropic зобов'язалася придбати $30 млрд Azure compute. І Microsoft при цьому залишається одним із найбільших акціонерів OpenAI, головного конкурента Anthropic.
Далі Google. Компанія домовилася інвестувати в Anthropic до $40 млрд. Паралельно Anthropic розширює використання Google Cloud і отримує доступ до мільйона TPU. І Google при цьому має власну Gemini, прямого конкурента Claude.
А ще Amazon вклав у Anthropic спочатку $8 млрд, потім додав ще $5 млрд і погодив можливість інвестувати до $20 млрд. За даними FT фактично вже вкладено близько $18 млрд. У відповідь Anthropic зобов'язалася витратити на AWS понад $100 млрд протягом наступних десяти років.
До цього додаємо CoreWeave, один із найбільших AI-neocloud провайдерів. У 2025 році 67% його виручки припадало на Microsoft. Компанія має контракти з OpenAI, Meta та тепер Anthropic, а вся її GPU-інфраструктура побудована на Nvidia. І Nvidia сама інвестує в CoreWeave.
Тобто Nvidia одночасно виробляє GPU, інвестує в AI-компанії, інвестує в компанії які купують її GPU, продає їм hardware, а вони здають цей hardware в оренду тим самим OpenAI, Microsoft, Meta та Anthropic.
Це не означає що виручка Nvidia, AWS, Azure чи Oracle "намальована", і не означає автоматично що перед нами фінансова піраміда. У фінансах подібні конструкції давно існують під назвою vendor financing: постачальник допомагає профінансувати покупця щоб той міг придбати його продукт.
Але масштаб тут уже незвичайний. Financial Times у липні прямо назвав частину цих угод "circular financing". А цього тижня FT пішов ще далі і виніс у заголовок фразу "Nvidia becomes the bank of AI".
Reuters повідомив буквально сьогодні що Nvidia разом з Apollo, BlackRock, Blackstone, Brookfield, Goldman Sachs і KKR працює над платформою здатною мобілізувати понад $500 млрд для фінансування AI-інфраструктури. Сама Nvidia потенційно може підтримати до $125 млрд цього фінансування.
Тож ми бачимо реальний попит на AI чи частково попит, який сама індустрія допомагає фінансувати?
Чим сильніше пов’язані AI-компанії, дата-центри, хмари, кредити й GPU-постачальники, тим системнішим стає ризик. Якщо compute перетвориться на реальну виручку — модель спрацює. Якщо ні, проблема вдарить одразу по всьому ланцюгу.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Зараз багато говорять про замкнений цикл грошей в AI-індустрії, але розібратися, хто кого фінансує і куди зрештою йдуть ці мільярди, не так просто. Я зібрав усе в одну схему — з цифрами та посиланнями на першоджерела. 🕵🏻♂️🔍 👇🏻
Почнемо з OpenAI. У 2025 році OpenAI, SoftBank, Oracle та MGX запустили Stargate, програму будівництва AI-інфраструктури у США з планом інвестувати до $500 млрд протягом чотирьох років. Це не один дата-центр за $500 млрд як іноді пишуть а ціла інфраструктурна програма.
У лютому 2026 OpenAI оголосила ще один гігантський раунд: $30 млрд від Nvidia, $30 млрд від SoftBank і $50 млрд від Amazon. Пізніше раунд виріс до $122 млрд.
А тепер подивимось куди OpenAI витрачає ці гроші. З Amazon ситуація особливо цікава: Amazon вкладає $50 млрд в OpenAI а OpenAI паралельно розширює контракт з AWS ще на $100 млрд на вісім років. Тобто Amazon дає OpenAI $50 млрд, а OpenAI повертає AWS понад $100 млрд. Це вже дуже схоже на замкнений контур.
З Oracle наступний рівень. За даними Reuters і WSJ OpenAI підписала контракт приблизно на $300 млрд compute протягом п'яти років. А Oracle своєю чергою планувала придбати приблизно $40 млрд Nvidia GPU і здавати ці потужності OpenAI. Отримуємо: OpenAI платить Oracle, Oracle купує чипи у Nvidia. А Nvidia при цьому сама інвестує в OpenAI.
Є ще AMD. OpenAI домовилася розгорнути до 6 GW AMD GPU. У відповідь AMD видала OpenAI warrants на купівлю до 160 млн акцій AMD, на момент угоди це відповідало приблизно 10% компанії за умови виконання всіх milestones. Великий клієнт AMD потенційно стає ще й великим акціонером AMD.
Ще цікавіше стає коли дивитися на Anthropic. У листопаді 2025 Microsoft і Nvidia домовилися інвестувати в Anthropic до $5 млрд і $10 млрд відповідно. У межах тієї ж домовленості Anthropic зобов'язалася придбати $30 млрд Azure compute. І Microsoft при цьому залишається одним із найбільших акціонерів OpenAI, головного конкурента Anthropic.
Далі Google. Компанія домовилася інвестувати в Anthropic до $40 млрд. Паралельно Anthropic розширює використання Google Cloud і отримує доступ до мільйона TPU. І Google при цьому має власну Gemini, прямого конкурента Claude.
А ще Amazon вклав у Anthropic спочатку $8 млрд, потім додав ще $5 млрд і погодив можливість інвестувати до $20 млрд. За даними FT фактично вже вкладено близько $18 млрд. У відповідь Anthropic зобов'язалася витратити на AWS понад $100 млрд протягом наступних десяти років.
До цього додаємо CoreWeave, один із найбільших AI-neocloud провайдерів. У 2025 році 67% його виручки припадало на Microsoft. Компанія має контракти з OpenAI, Meta та тепер Anthropic, а вся її GPU-інфраструктура побудована на Nvidia. І Nvidia сама інвестує в CoreWeave.
Тобто Nvidia одночасно виробляє GPU, інвестує в AI-компанії, інвестує в компанії які купують її GPU, продає їм hardware, а вони здають цей hardware в оренду тим самим OpenAI, Microsoft, Meta та Anthropic.
Це не означає що виручка Nvidia, AWS, Azure чи Oracle "намальована", і не означає автоматично що перед нами фінансова піраміда. У фінансах подібні конструкції давно існують під назвою vendor financing: постачальник допомагає профінансувати покупця щоб той міг придбати його продукт.
Але масштаб тут уже незвичайний. Financial Times у липні прямо назвав частину цих угод "circular financing". А цього тижня FT пішов ще далі і виніс у заголовок фразу "Nvidia becomes the bank of AI".
Reuters повідомив буквально сьогодні що Nvidia разом з Apollo, BlackRock, Blackstone, Brookfield, Goldman Sachs і KKR працює над платформою здатною мобілізувати понад $500 млрд для фінансування AI-інфраструктури. Сама Nvidia потенційно може підтримати до $125 млрд цього фінансування.
Тож ми бачимо реальний попит на AI чи частково попит, який сама індустрія допомагає фінансувати?
Чим сильніше пов’язані AI-компанії, дата-центри, хмари, кредити й GPU-постачальники, тим системнішим стає ризик. Якщо compute перетвориться на реальну виручку — модель спрацює. Якщо ні, проблема вдарить одразу по всьому ланцюгу.
🔔 ПІДПИСАТИСЯ
👍7🔥3❤1🤯1
Grok повернувся у вищу лігу. І схоже Cursor тут зіграв ключову роль 🚀
Доброго ранку ☕️
Щось останнім часом дуже багато роботи, тож не встигаю нормально розбирати новини. Зараз трохи прихворів, тому нарешті знайшов на це час 😅
Ще нещодавно Grok складно було назвати реальним конкурентом найсильніших моделей OpenAI та Anthropic. Але новий Grok 4.6 уже фактично повертає SpaceXAI у frontier.
На Artificial Analysis Intelligence Index модель набрала 61 бал, стільки ж скільки GPT-5.6 Sol, і лише трохи нижче за лідерів Anthropic. При цьому API коштує $2 за 1 млн input-токенів і $6 за output, тоді як близькі за якістю GPT-5.6 Sol та Claude Opus 5 суттєво дорожчі. Детальний розбір бенчмарків від Artificial Analysis.
Але найцікавіше навіть не benchmark scores.
На AA-Briefcase, тесті довгих agentic-задач де модель годинами працює з файлами та створює документи, таблиці й презентації, Grok 4.6 у середньому витрачав близько 53 turns та 0.5B input tokens. Claude Opus 5 близько 103 turns та 2B tokens. Тобто Grok поки поступається Opus за кінцевим score але проходить подібні довгі workflows приблизно вдвічі меншою кількістю кроків і з учетверо меншим input-контекстом.
А для AI-агентів це може бути важливіше за ще +1% на черговому benchmark.
Звідки такий прогрес? Тут починається найцікавіша частина історії, Cursor.
Навесні Cursor та SpaceXAI уклали партнерство: Cursor отримав доступ до величезних обчислювальних потужностей Colossus, а SpaceXAI до експертизи та даних реальних coding-agent workflows. Це дуже цінний тип даних: prompts програмістів, ітерації агента, виправлення помилок, рішення щодо архітектури, робота з великими codebase.
І результати з'явилися дуже швидко. Grok 4.3 мав 38 балів в Artificial Analysis Index. Grok 4.5 у липні вже 56. Grok 4.6 у серпні 61.
При навчанні 4.6 компанія також збільшила supplemental pretraining, використала Grok 4.5 для генерації нових training trajectories і додала reinforcement learning на реальних agentic-задачах: coding, knowledge work, web development, CAD і навіть оптимізації GPU kernels.
А далі партнерство перетворилося на щось значно більше. У серпні SpaceX завершила придбання Cursor приблизно за $60 млрд в акціях. І тепер у Маска фактично формується вертикально інтегрований AI-стек: compute → модель → agent harness → IDE → дані реальних користувачів → наступна модель.
А через три дні після завершення угоди Cursor запустив Origin, власний аналог GitHub створений уже з розрахунком на те що значну частину коду генеруватимуть не люди а агенти.
Я не поспішав з цим постом бо вирішив спочатку сам спробувати. Cursor я користуюсь досить активно і можу сказати що Grok 4.6 дійсно непогана модель, на безкоштовній підписці вона точно має сенс. Але мій особистий фаворит зараз це Composer 2.5. Для написання коду він не виглядає гіршим за Medium чи навіть High-моделі типу GPT-5.6 Sol. Розумію що Sol буде кращим для мультиагентних задач де треба агрегувати багато інформації з різних джерел, а Composer не пише код гірше за Opus. Просто у Opus і Sol сила в іншому. Але саме з точки зору написання коду Composer мене дуже приємно здивував.
Мені здається це добре показує куди рухається конкуренція в AI. Раніше лабораторії змагалися за найкращу модель. Тепер перевагою стає весь ланцюжок: хто має compute, хто має дані реальної роботи агентів, хто контролює середовище де вони працюють, і хто може виконати задачу дешевше та за меншу кількість кроків.
І в такій системі Cursor для SpaceXAI може виявитися значно ціннішим активом ніж просто популярний редактор коду.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Щось останнім часом дуже багато роботи, тож не встигаю нормально розбирати новини. Зараз трохи прихворів, тому нарешті знайшов на це час 😅
Ще нещодавно Grok складно було назвати реальним конкурентом найсильніших моделей OpenAI та Anthropic. Але новий Grok 4.6 уже фактично повертає SpaceXAI у frontier.
На Artificial Analysis Intelligence Index модель набрала 61 бал, стільки ж скільки GPT-5.6 Sol, і лише трохи нижче за лідерів Anthropic. При цьому API коштує $2 за 1 млн input-токенів і $6 за output, тоді як близькі за якістю GPT-5.6 Sol та Claude Opus 5 суттєво дорожчі. Детальний розбір бенчмарків від Artificial Analysis.
Але найцікавіше навіть не benchmark scores.
На AA-Briefcase, тесті довгих agentic-задач де модель годинами працює з файлами та створює документи, таблиці й презентації, Grok 4.6 у середньому витрачав близько 53 turns та 0.5B input tokens. Claude Opus 5 близько 103 turns та 2B tokens. Тобто Grok поки поступається Opus за кінцевим score але проходить подібні довгі workflows приблизно вдвічі меншою кількістю кроків і з учетверо меншим input-контекстом.
А для AI-агентів це може бути важливіше за ще +1% на черговому benchmark.
Звідки такий прогрес? Тут починається найцікавіша частина історії, Cursor.
Навесні Cursor та SpaceXAI уклали партнерство: Cursor отримав доступ до величезних обчислювальних потужностей Colossus, а SpaceXAI до експертизи та даних реальних coding-agent workflows. Це дуже цінний тип даних: prompts програмістів, ітерації агента, виправлення помилок, рішення щодо архітектури, робота з великими codebase.
І результати з'явилися дуже швидко. Grok 4.3 мав 38 балів в Artificial Analysis Index. Grok 4.5 у липні вже 56. Grok 4.6 у серпні 61.
При навчанні 4.6 компанія також збільшила supplemental pretraining, використала Grok 4.5 для генерації нових training trajectories і додала reinforcement learning на реальних agentic-задачах: coding, knowledge work, web development, CAD і навіть оптимізації GPU kernels.
А далі партнерство перетворилося на щось значно більше. У серпні SpaceX завершила придбання Cursor приблизно за $60 млрд в акціях. І тепер у Маска фактично формується вертикально інтегрований AI-стек: compute → модель → agent harness → IDE → дані реальних користувачів → наступна модель.
А через три дні після завершення угоди Cursor запустив Origin, власний аналог GitHub створений уже з розрахунком на те що значну частину коду генеруватимуть не люди а агенти.
Я не поспішав з цим постом бо вирішив спочатку сам спробувати. Cursor я користуюсь досить активно і можу сказати що Grok 4.6 дійсно непогана модель, на безкоштовній підписці вона точно має сенс. Але мій особистий фаворит зараз це Composer 2.5. Для написання коду він не виглядає гіршим за Medium чи навіть High-моделі типу GPT-5.6 Sol. Розумію що Sol буде кращим для мультиагентних задач де треба агрегувати багато інформації з різних джерел, а Composer не пише код гірше за Opus. Просто у Opus і Sol сила в іншому. Але саме з точки зору написання коду Composer мене дуже приємно здивував.
Мені здається це добре показує куди рухається конкуренція в AI. Раніше лабораторії змагалися за найкращу модель. Тепер перевагою стає весь ланцюжок: хто має compute, хто має дані реальної роботи агентів, хто контролює середовище де вони працюють, і хто може виконати задачу дешевше та за меншу кількість кроків.
І в такій системі Cursor для SpaceXAI може виявитися значно ціннішим активом ніж просто популярний редактор коду.
🔔 ПІДПИСАТИСЯ
🔥12👏4👍3
☝🏻 Одна команда від Claude майже перетворила Mac розробника на цеглину. І ця історія схоже справжня.
Доброго ленчу ☕️
4го Вересня в r/ClaudeCode з'явився показовий кейс.
Розробник працював над iOS-застосунком і хотів виставити певний час для красивого скріншота. Замість того щоб самому розбиратися попросив Claude зробити це за нього. За словами автора він використовував Claude Opus 5 High.
Claude запропонував:
Розробник просто вставив команду в Terminal. І за кілька секунд Mac завис 🤖💀
І далі почалося найцікавіше.
За словами автора Mac перестав нормально завантажуватися: логотип Apple, progress bar, чорний екран із курсором. Не допомогли Safe Mode, Recovery, fallback Recovery, bootable media, кілька спроб DFU Revive з іншого Mac. DFU при цьому завершувався помилкою 4042.
У результаті автор знайшов схожий кейс де комусь допомогло встановлення Xcode на другий Mac з якого проводився Revive.
Але тут є важливий нюанс. Не варто робити висновок що саме Xcode полагодив Mac. Сам автор цього не стверджує. Перед цим він робив ще одну невдалу DFU Restore тому точно встановити причинно-наслідковий зв'язок неможливо. Більше того в офіційній інструкції Apple для DFU Revive Xcode взагалі не є вимогою. Потрібні інший Mac, актуальна macOS, інтернет і USB-C кабель, а сам Revive запускається через Finder. Тобто маємо реальний user report але не задокументований Apple bug.
І тут є ще прекрасніша іронія 🙂
Змінювати системний час Mac узагалі не було потрібно. Apple вже багато років дозволяє окремо підміняти годинник у status bar iOS Simulator командою xcrun simctl status_bar booted override --time 12:01. Тобто можна було змінити цифри на скріншоті не торкаючись системного часу комп'ютера взагалі. Це офіційно документована можливість Xcode Simulator.
І ось саме це на мій погляд найцікавіше у всій історії.
Claude формально виконав задачу. Потрібно змінити час? Ось команда яка змінює час. Але модель не оцінила масштаб втручання. Замість локальної зміни UI Simulator вона запропонувала sudo, відключити network time, глобально змінити системний clock.
Це хороший приклад того чому AI coding agents змінюють не тільки швидкість розробки а й саму модель ризику. Раніше небезпечну команду потрібно було знайти, зрозуміти і написати самому. Тепер достатньо сказати "Claude, fix it". А далі головним security layer залишається людина яка має прочитати команду перед Enter. Особливо якщо там є sudo.
Тут для мене два практичні висновки. Перший: якщо ви даєте агентам на базі Claude чи будь-якої іншої моделі доступ до вашої системи — обмежуйте scope можливостей і не давайте sudo без потреби. Другий: якщо виконуєте команду за рекомендацією AI — переконайтесь що розумієте що саме вона робить.
Це ще одне підтвердження того що незалежно від того наскільки потужним стає AI, базове розуміння команд, алгоритмів і того як влаштована система нікуди не зникає з вимог до людини. Інакше саме ви стаєте тим слабким security layer який пропускає катастрофу далі.
AI може бути чудовим інженером але root-доступ йому краще видавати з таким самим рівнем довіри як дуже талановитому junior'у який працює о третій ночі 😄
🔔 ПІДПИСАТИСЯ
Доброго ленчу ☕️
4го Вересня в r/ClaudeCode з'явився показовий кейс.
Розробник працював над iOS-застосунком і хотів виставити певний час для красивого скріншота. Замість того щоб самому розбиратися попросив Claude зробити це за нього. За словами автора він використовував Claude Opus 5 High.
Claude запропонував:
sudo systemsetup -setusingnetworktime off && sudo date 090306494026.00Розробник просто вставив команду в Terminal. І за кілька секунд Mac завис 🤖💀
І далі почалося найцікавіше.
За словами автора Mac перестав нормально завантажуватися: логотип Apple, progress bar, чорний екран із курсором. Не допомогли Safe Mode, Recovery, fallback Recovery, bootable media, кілька спроб DFU Revive з іншого Mac. DFU при цьому завершувався помилкою 4042.
У результаті автор знайшов схожий кейс де комусь допомогло встановлення Xcode на другий Mac з якого проводився Revive.
Але тут є важливий нюанс. Не варто робити висновок що саме Xcode полагодив Mac. Сам автор цього не стверджує. Перед цим він робив ще одну невдалу DFU Restore тому точно встановити причинно-наслідковий зв'язок неможливо. Більше того в офіційній інструкції Apple для DFU Revive Xcode взагалі не є вимогою. Потрібні інший Mac, актуальна macOS, інтернет і USB-C кабель, а сам Revive запускається через Finder. Тобто маємо реальний user report але не задокументований Apple bug.
І тут є ще прекрасніша іронія 🙂
Змінювати системний час Mac узагалі не було потрібно. Apple вже багато років дозволяє окремо підміняти годинник у status bar iOS Simulator командою xcrun simctl status_bar booted override --time 12:01. Тобто можна було змінити цифри на скріншоті не торкаючись системного часу комп'ютера взагалі. Це офіційно документована можливість Xcode Simulator.
І ось саме це на мій погляд найцікавіше у всій історії.
Claude формально виконав задачу. Потрібно змінити час? Ось команда яка змінює час. Але модель не оцінила масштаб втручання. Замість локальної зміни UI Simulator вона запропонувала sudo, відключити network time, глобально змінити системний clock.
Це хороший приклад того чому AI coding agents змінюють не тільки швидкість розробки а й саму модель ризику. Раніше небезпечну команду потрібно було знайти, зрозуміти і написати самому. Тепер достатньо сказати "Claude, fix it". А далі головним security layer залишається людина яка має прочитати команду перед Enter. Особливо якщо там є sudo.
Тут для мене два практичні висновки. Перший: якщо ви даєте агентам на базі Claude чи будь-якої іншої моделі доступ до вашої системи — обмежуйте scope можливостей і не давайте sudo без потреби. Другий: якщо виконуєте команду за рекомендацією AI — переконайтесь що розумієте що саме вона робить.
Це ще одне підтвердження того що незалежно від того наскільки потужним стає AI, базове розуміння команд, алгоритмів і того як влаштована система нікуди не зникає з вимог до людини. Інакше саме ви стаєте тим слабким security layer який пропускає катастрофу далі.
AI може бути чудовим інженером але root-доступ йому краще видавати з таким самим рівнем довіри як дуже талановитому junior'у який працює о третій ночі 😄
🔔 ПІДПИСАТИСЯ
👍13❤2🔥1😁1