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
🔐 «Ми не тренуємося на ваших даних» і «ми взагалі не маємо ваших даних» — це дві дуже різні речі
Доброго вечора ☕️
Зараз між OpenAI та Anthropic формується доволі показова різниця саме в цьому питанні.
Для бізнесу який передає AI конфіденційні дані важливі три прості питання: де зберігаються ваші промпти та відповіді, як довго вони зберігаються, чи може провайдер AI отримати до них доступ. І тут підходи Anthropic та OpenAI починають суттєво розходитися.
Anthropic
З червня бізнес-клієнти нових моделей Anthropic мали погоджуватися на 30-денне зберігання розмов. Тобто навіть компанії які раніше мали Zero Data Retention фактично втрачали ZDR якщо хотіли використовувати нові моделі. Результат виявився передбачуваним: частина бізнес-клієнтів просто відмовилася від нових моделей. Навіть ARC Prize Foundation не захотіла запускати свої закриті benchmark-тести щоб не передавати приватні тестові питання на зберігання.
Тепер Anthropic готує систему Enterprise Frontier Safeguards. Ідея така: дані все одно потрібно буде зберігати 30 днів але вже на серверах самого клієнта або у вибраного ним cloud-провайдера, AWS, Google Cloud, Microsoft Foundry тощо. Клієнт також зможе контролювати encryption keys та audit logs. Але сама вимога зберігати дані нікуди не зникає.
OpenAI
OpenAI пішла іншим шляхом. Для схвалених бізнес-клієнтів компанія заявляє підтримку Zero Data Retention для своїх найпотужніших моделей. Тобто OpenAI стверджує що не логуватиме ані prompts ані responses. Паралельно компанія готує Private Safety Processing, систему яка має виявляти потенційні зловживання одразу в серії запитів не передаючи співробітникам сам зміст цих запитів. Детальніше про це OpenAI написала окремо.
І ось тут починається найцікавіше.
Якщо AI не бачить дані, як він їх аналізує?
Обидві компанії хочуть автоматично знаходити патерни атак у багатьох запитах. Наприклад best-of-N jailbreak: атакуючий сотні разів трохи змінює заборонений prompt поки одна з версій не пройде. Для виявлення такого патерну система має аналізувати історію запитів.
І виникає фундаментальне питання: "наші співробітники не бачать ваші дані" не дорівнює "наші системи не мають доступу до ваших даних". Як саме це буде реалізовано криптографічно й архітектурно поки що повністю не пояснила жодна з компаній. OpenAI обіцяє окремий technical paper щодо PSP.
Бізнеси вже зараз вирішують чи можна довіряти цим моделям конфіденційні дані спираючись фактично лише на пресрелізи. Для регульованих галузей, юридичних фірм, лікарень і банків, обіцянки "ми не будемо навчати моделі на ваших даних" і "у нас узагалі немає ваших даних" це зовсім різні речі.
Минулого року в межах позову The New York Times щодо авторських прав суд зобов'язав OpenAI зберігати журнали чатів які зазвичай мали бути видалені, включно з тими які самі користувачі вже стерли. OpenAI заявила що клієнтів із ZDR це не стосувалося, оскільки OpenAI взагалі не мала їхніх даних.
У 2024 році ми описали чотири рівні конфіденційності хмарного AI. Найсильніший із них, коли провайдер узагалі не може отримати доступ до ваших даних, є найважливішим для роботи з чутливою інформацією. Особливо з огляду на лазівки які дозволяють frontier-лабораторіям на власний розсуд визначати що вважати "безпечним".
Обидві компанії тепер заявляють що здатні одночасно зберегти конфіденційність користувачів і виявляти зловживання розподілені між великою кількістю запитів. Але жодна з них поки що не показала як саме це працюватиме.
🔔 ПІДПИСАТИСЯ
Доброго вечора ☕️
Зараз між OpenAI та Anthropic формується доволі показова різниця саме в цьому питанні.
Для бізнесу який передає AI конфіденційні дані важливі три прості питання: де зберігаються ваші промпти та відповіді, як довго вони зберігаються, чи може провайдер AI отримати до них доступ. І тут підходи Anthropic та OpenAI починають суттєво розходитися.
Anthropic
З червня бізнес-клієнти нових моделей Anthropic мали погоджуватися на 30-денне зберігання розмов. Тобто навіть компанії які раніше мали Zero Data Retention фактично втрачали ZDR якщо хотіли використовувати нові моделі. Результат виявився передбачуваним: частина бізнес-клієнтів просто відмовилася від нових моделей. Навіть ARC Prize Foundation не захотіла запускати свої закриті benchmark-тести щоб не передавати приватні тестові питання на зберігання.
Тепер Anthropic готує систему Enterprise Frontier Safeguards. Ідея така: дані все одно потрібно буде зберігати 30 днів але вже на серверах самого клієнта або у вибраного ним cloud-провайдера, AWS, Google Cloud, Microsoft Foundry тощо. Клієнт також зможе контролювати encryption keys та audit logs. Але сама вимога зберігати дані нікуди не зникає.
OpenAI
OpenAI пішла іншим шляхом. Для схвалених бізнес-клієнтів компанія заявляє підтримку Zero Data Retention для своїх найпотужніших моделей. Тобто OpenAI стверджує що не логуватиме ані prompts ані responses. Паралельно компанія готує Private Safety Processing, систему яка має виявляти потенційні зловживання одразу в серії запитів не передаючи співробітникам сам зміст цих запитів. Детальніше про це OpenAI написала окремо.
І ось тут починається найцікавіше.
Якщо AI не бачить дані, як він їх аналізує?
Обидві компанії хочуть автоматично знаходити патерни атак у багатьох запитах. Наприклад best-of-N jailbreak: атакуючий сотні разів трохи змінює заборонений prompt поки одна з версій не пройде. Для виявлення такого патерну система має аналізувати історію запитів.
І виникає фундаментальне питання: "наші співробітники не бачать ваші дані" не дорівнює "наші системи не мають доступу до ваших даних". Як саме це буде реалізовано криптографічно й архітектурно поки що повністю не пояснила жодна з компаній. OpenAI обіцяє окремий technical paper щодо PSP.
Бізнеси вже зараз вирішують чи можна довіряти цим моделям конфіденційні дані спираючись фактично лише на пресрелізи. Для регульованих галузей, юридичних фірм, лікарень і банків, обіцянки "ми не будемо навчати моделі на ваших даних" і "у нас узагалі немає ваших даних" це зовсім різні речі.
Минулого року в межах позову The New York Times щодо авторських прав суд зобов'язав OpenAI зберігати журнали чатів які зазвичай мали бути видалені, включно з тими які самі користувачі вже стерли. OpenAI заявила що клієнтів із ZDR це не стосувалося, оскільки OpenAI взагалі не мала їхніх даних.
У 2024 році ми описали чотири рівні конфіденційності хмарного AI. Найсильніший із них, коли провайдер узагалі не може отримати доступ до ваших даних, є найважливішим для роботи з чутливою інформацією. Особливо з огляду на лазівки які дозволяють frontier-лабораторіям на власний розсуд визначати що вважати "безпечним".
Обидві компанії тепер заявляють що здатні одночасно зберегти конфіденційність користувачів і виявляти зловживання розподілені між великою кількістю запитів. Але жодна з них поки що не показала як саме це працюватиме.
🔔 ПІДПИСАТИСЯ
👍5🔥3❤1
⚖️ Thomson Reuters запустила власну LLM. І це значно цікавіше, ніж просто ще один fine-tune
Доброго ранку ☕️
Thomson Reuters представила сімейство моделей Thomson для права, фінансів, податків, бізнесу та новин.
І тут цікавий не стільки сам факт появи domain-specific LLM, скільки те, як саме її побудували.
За основу Thomson-1.0-Large взяли Qwen3.5-397B-A17B — Mixture-of-Experts модель на 397 млрд параметрів, із яких приблизно 17 млрд активуються на кожен токен.
А далі Thomson Reuters не обмежилася LoRA або невеликим instruction fine-tuning. Компанія фактично провела повторне mid-training моделі під власний домен. Для цього разом із DatologyAI вони відібрали 200 млрд токенів із пулу в 19 трлн токенів.
Навчальний датасет приблизно порівну складався з пропрієтарних даних Thomson Reuters — судової практики, контрактів, regulatory filings, новин — synthetic data з прикладами реальних професійних задач і general-purpose даних, щоб не втратити базові можливості моделі.
Після цього модель додатково вирівнювали за допомогою DPO, а для agentic deep research використовували також GSPO, зокрема для роботи з context compaction та document caching.
На весь training pipeline Thomson Reuters, за власними даними, витратила близько $40 млн за три місяці.
І результат досить цікавий. За їхніми тестами Thomson-1.0-Large трохи випереджає GPT-5.4 та Claude Sonnet 5 за factuality і completeness у legal, tax та news задачах. На factuality для open-web контенту різниця, за їхніми вимірюваннями, сягає приблизно 15 пунктів. При цьому контекст — до 262k токенів.
Але, на мою думку, найважливіше тут навіть не benchmark.
Останні кілька років здавалося, що майбутнє виглядатиме приблизно так:
foundation model → RAG → трохи fine-tuning → готово.
Але Thomson показує інший варіант:
open-weight frontier model → великий proprietary corpus → domain mid-training → alignment → private deployment.
Тобто компанія не тренує LLM із нуля, що коштувало б сотні мільйонів доларів. Але й не обмежується поверхневим fine-tuning. Вона бере сильну базову модель і фактично продовжує її pretraining уже на власному світі даних.
І це може бути важливим трендом.
Бо в Thomson Reuters є те, чого немає у більшості AI-стартапів: десятиліттями накопичені структуровані професійні дані.
Крім того, моделі можна додатково навчати на приватних даних конкретної компанії за допомогою mid-training методів Thomson — без величезних витрат на повноцінне pretraining і без обмеженої ефективності дешевших методів fine-tuning на кшталт LoRA.
Для банків, юридичних компаній, enterprise R&D і regulated industries це може бути набагато цікавіше за класичний SaaS-доступ до зовнішньої LLM.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Thomson Reuters представила сімейство моделей Thomson для права, фінансів, податків, бізнесу та новин.
І тут цікавий не стільки сам факт появи domain-specific LLM, скільки те, як саме її побудували.
За основу Thomson-1.0-Large взяли Qwen3.5-397B-A17B — Mixture-of-Experts модель на 397 млрд параметрів, із яких приблизно 17 млрд активуються на кожен токен.
А далі Thomson Reuters не обмежилася LoRA або невеликим instruction fine-tuning. Компанія фактично провела повторне mid-training моделі під власний домен. Для цього разом із DatologyAI вони відібрали 200 млрд токенів із пулу в 19 трлн токенів.
Навчальний датасет приблизно порівну складався з пропрієтарних даних Thomson Reuters — судової практики, контрактів, regulatory filings, новин — synthetic data з прикладами реальних професійних задач і general-purpose даних, щоб не втратити базові можливості моделі.
Після цього модель додатково вирівнювали за допомогою DPO, а для agentic deep research використовували також GSPO, зокрема для роботи з context compaction та document caching.
На весь training pipeline Thomson Reuters, за власними даними, витратила близько $40 млн за три місяці.
І результат досить цікавий. За їхніми тестами Thomson-1.0-Large трохи випереджає GPT-5.4 та Claude Sonnet 5 за factuality і completeness у legal, tax та news задачах. На factuality для open-web контенту різниця, за їхніми вимірюваннями, сягає приблизно 15 пунктів. При цьому контекст — до 262k токенів.
Але, на мою думку, найважливіше тут навіть не benchmark.
Останні кілька років здавалося, що майбутнє виглядатиме приблизно так:
foundation model → RAG → трохи fine-tuning → готово.
Але Thomson показує інший варіант:
open-weight frontier model → великий proprietary corpus → domain mid-training → alignment → private deployment.
Тобто компанія не тренує LLM із нуля, що коштувало б сотні мільйонів доларів. Але й не обмежується поверхневим fine-tuning. Вона бере сильну базову модель і фактично продовжує її pretraining уже на власному світі даних.
І це може бути важливим трендом.
Бо в Thomson Reuters є те, чого немає у більшості AI-стартапів: десятиліттями накопичені структуровані професійні дані.
Крім того, моделі можна додатково навчати на приватних даних конкретної компанії за допомогою mid-training методів Thomson — без величезних витрат на повноцінне pretraining і без обмеженої ефективності дешевших методів fine-tuning на кшталт LoRA.
Для банків, юридичних компаній, enterprise R&D і regulated industries це може бути набагато цікавіше за класичний SaaS-доступ до зовнішньої LLM.
🔔 ПІДПИСАТИСЯ
🔥6❤🔥3👍3❤1
«Люди які створюють AI справді вважають що він може знищити людство»
Доброго ранку ☕️ Гарних вихідних 👋
Вже про Astra поговоримо в понеділок, а сьогодні трохи «розважального» контенту 🙂
Кілька днів тому дослідник Джейкоб Коксон звільнився з Anthropic і опублікував тред який за добу набрав понад 100 мільйонів переглядів.
Три роки він займався дослідженнями попереднього навчання моделей спочатку в OpenAI а потім в Anthropic. І написав: "Жодна з компаній не діє відповідально. Вони мчать прямо до штучного інтелекту здатного самовдосконалюватися, ставлячи на кін наші життя".
Звучить як черговий панічний пост. Але далі стало цікавіше.
Керівник напряму безпеки в Anthropic Еван Хубінгер публічно відповів Коксону: "Джейкоб має рацію, ми справді щиро вважаємо що AI може вбити всіх людей. Особисто я оцінюю це у понад 10% імовірності протягом наступних десяти років". І визнав: Anthropic поки не має готового плану вирішити цю проблему.
Його підтримав ще один дослідник компанії Семюел Маркс. За його словами побоювання серйозних сценаріїв усередині індустрії цілком реальні, причому досвідчені дослідники хвилюються сильніше ніж молодші.
А тепер найцікавіше. За два дні до цього треду головний науковець OpenAI Якуб Пахоцький опублікував текст "An Alien Mind". І там фактично підтверджується та сама проблема. Пахоцький пише що за внутрішніми результатами компанії прогрес може продовжитися аж до моменту коли AI сам активно братиме участь у створенні наступних сильніших систем. І прямо заявляє: "Наразі жодна лабораторія не вирішила питання безпеки настільки добре щоб довго відповідально масштабуватися на максимальній швидкості".
Це вже не колишній співробітник який грюкнув дверима. Це головний науковець OpenAI.
А що думають засновники сучасного AI? Джеффрі Хінтон сказав BBC що оцінка у 10% не здається йому нерозумною хоча ніхто насправді не знає як коректно порахувати таку ймовірність. Йошуа Бенджіо попереджає про небезпечну комбінацію: високий інтелект плюс автономність плюс довгострокові цілі плюс доступ до реального світу.
Консенсусу тут немає взагалі. Andrew Ng колись писав в LinkedIn: "Чесно кажучи я не розумію звідки береться цей ризик".
А CEO Nvidia Дженсен Хуанг заявив Axios ще жорсткіше: "Ідея що це стане кінцем людства це повна нісенітниця".
А ви що з цього приводу думаєте, поділіться в коментарях 👇
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️ Гарних вихідних 👋
Вже про Astra поговоримо в понеділок, а сьогодні трохи «розважального» контенту 🙂
Кілька днів тому дослідник Джейкоб Коксон звільнився з Anthropic і опублікував тред який за добу набрав понад 100 мільйонів переглядів.
Три роки він займався дослідженнями попереднього навчання моделей спочатку в OpenAI а потім в Anthropic. І написав: "Жодна з компаній не діє відповідально. Вони мчать прямо до штучного інтелекту здатного самовдосконалюватися, ставлячи на кін наші життя".
Звучить як черговий панічний пост. Але далі стало цікавіше.
Керівник напряму безпеки в Anthropic Еван Хубінгер публічно відповів Коксону: "Джейкоб має рацію, ми справді щиро вважаємо що AI може вбити всіх людей. Особисто я оцінюю це у понад 10% імовірності протягом наступних десяти років". І визнав: Anthropic поки не має готового плану вирішити цю проблему.
Його підтримав ще один дослідник компанії Семюел Маркс. За його словами побоювання серйозних сценаріїв усередині індустрії цілком реальні, причому досвідчені дослідники хвилюються сильніше ніж молодші.
А тепер найцікавіше. За два дні до цього треду головний науковець OpenAI Якуб Пахоцький опублікував текст "An Alien Mind". І там фактично підтверджується та сама проблема. Пахоцький пише що за внутрішніми результатами компанії прогрес може продовжитися аж до моменту коли AI сам активно братиме участь у створенні наступних сильніших систем. І прямо заявляє: "Наразі жодна лабораторія не вирішила питання безпеки настільки добре щоб довго відповідально масштабуватися на максимальній швидкості".
Це вже не колишній співробітник який грюкнув дверима. Це головний науковець OpenAI.
А що думають засновники сучасного AI? Джеффрі Хінтон сказав BBC що оцінка у 10% не здається йому нерозумною хоча ніхто насправді не знає як коректно порахувати таку ймовірність. Йошуа Бенджіо попереджає про небезпечну комбінацію: високий інтелект плюс автономність плюс довгострокові цілі плюс доступ до реального світу.
Консенсусу тут немає взагалі. Andrew Ng колись писав в LinkedIn: "Чесно кажучи я не розумію звідки береться цей ризик".
А CEO Nvidia Дженсен Хуанг заявив Axios ще жорсткіше: "Ідея що це стане кінцем людства це повна нісенітниця".
А ви що з цього приводу думаєте, поділіться в коментарях 👇
🔔 ПІДПИСАТИСЯ
👍6❤3🤔3😁1
Піар чи щирий страх? Продовження вчорашньої історії
Доброго ранку ☕️
Вчора розповідав про тред Джейкоба Коксона, відповідь Евана Хубінгера з Anthropic та текст головного науковця OpenAI Пахоцького де серйозні люди відкрито говорять про ризик знищення людства через AI. Сьогодні хочу розібрати питання яке напрошується саме тут: це щире занепокоєння чи частина піар-гри?
Мені здається що це хибний вибір. Швидше і те й інше одночасно, не одне замість іншого.
Аргументи на користь щирості. Хубінгер і Маркс це дослідники чия вся кар'єра побудована на безпеці AI а не на маркетингу. Коксон буквально кинув роботу і пішов з індустрії, а це дуже дорогий сигнал який складно симулювати заради піару. Хінтон пішов з Google саме через ці побоювання, йому вже нічого доводити. І всередині самого табору немає єдиної відполірованої позиції: Хубінгер прямо каже що ризик від нинішніх моделей низький, турбує його саме майбутнє самовдосконалення систем. Справжній піар зазвичай виглядає більш скоординовано.
Але є й структурна вигода. Сама ідея "ми будуємо щось настільки потужне що може вбити всіх" це водночас і попередження і грандіозна реклама можливостей продукту. І в аргументі Ендрю Ина, якого я згадував вчора, є сенс: наратив про загибель людства історично використовується як інструмент для обмеження конкуренції. Якщо переконати державу що технологія надзвичайно небезпечна — великі лабораторії з ресурсами на дотримання регуляцій виграють, а стартапи і відкриті проєкти вимирають. Це не означає що Хубінгер особисто цинічно рахує ризики. Але система стимулів навколо нього об'єктивно винагороджує саме таку позицію.
Мій особистий висновок: люди які прямо про це говорять, Хубінгер, Коксон, Пахоцький, скоріше за все щирі у своїй професійній оцінці, це їхня реальна робота і вони роками цим займаються. Але як ця щира тривога потім використовується на рівні індустріальної політики і регулювання це вже окреме питання де інтереси компаній і щирі побоювання дослідників не завжди збігаються.
І найдивніша частина цієї історії мабуть саме така: люди які створюють найпотужніші AI-системи у світі відкрито визнають що ще не знають як гарантовано контролювати системи наступного рівня. Але продовжують їх будувати.
А що думаєте ви? Це реальна загроза яку варто сприймати серйозно, чи чергова спроба виправдати обмеження ринку через страх? Пишіть у коментарях 👇
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Вчора розповідав про тред Джейкоба Коксона, відповідь Евана Хубінгера з Anthropic та текст головного науковця OpenAI Пахоцького де серйозні люди відкрито говорять про ризик знищення людства через AI. Сьогодні хочу розібрати питання яке напрошується саме тут: це щире занепокоєння чи частина піар-гри?
Мені здається що це хибний вибір. Швидше і те й інше одночасно, не одне замість іншого.
Аргументи на користь щирості. Хубінгер і Маркс це дослідники чия вся кар'єра побудована на безпеці AI а не на маркетингу. Коксон буквально кинув роботу і пішов з індустрії, а це дуже дорогий сигнал який складно симулювати заради піару. Хінтон пішов з Google саме через ці побоювання, йому вже нічого доводити. І всередині самого табору немає єдиної відполірованої позиції: Хубінгер прямо каже що ризик від нинішніх моделей низький, турбує його саме майбутнє самовдосконалення систем. Справжній піар зазвичай виглядає більш скоординовано.
Але є й структурна вигода. Сама ідея "ми будуємо щось настільки потужне що може вбити всіх" це водночас і попередження і грандіозна реклама можливостей продукту. І в аргументі Ендрю Ина, якого я згадував вчора, є сенс: наратив про загибель людства історично використовується як інструмент для обмеження конкуренції. Якщо переконати державу що технологія надзвичайно небезпечна — великі лабораторії з ресурсами на дотримання регуляцій виграють, а стартапи і відкриті проєкти вимирають. Це не означає що Хубінгер особисто цинічно рахує ризики. Але система стимулів навколо нього об'єктивно винагороджує саме таку позицію.
Мій особистий висновок: люди які прямо про це говорять, Хубінгер, Коксон, Пахоцький, скоріше за все щирі у своїй професійній оцінці, це їхня реальна робота і вони роками цим займаються. Але як ця щира тривога потім використовується на рівні індустріальної політики і регулювання це вже окреме питання де інтереси компаній і щирі побоювання дослідників не завжди збігаються.
І найдивніша частина цієї історії мабуть саме така: люди які створюють найпотужніші AI-системи у світі відкрито визнають що ще не знають як гарантовано контролювати системи наступного рівня. Але продовжують їх будувати.
А що думаєте ви? Це реальна загроза яку варто сприймати серйозно, чи чергова спроба виправдати обмеження ринку через страх? Пишіть у коментарях 👇
🔔 ПІДПИСАТИСЯ
👍7🤔3❤1👏1
GPT-6 Per aspera ad astra - справжня зірка 💫
Доброго ранку ☕️
Схоже що рахувати ціну токенів скоро стане майже безглуздо.
OpenAI випустила GPT-6 Astra, нову флагманську модель. І цього разу найцікавіше те якою ціною вона опинилася на вершині більшості тестів.
Astra має контекст до 1.05 млн токенів, вихід до 128 тисяч, п'ять рівнів глибини міркування і проєктується вже не як чатбот а як модель для довгих агентних задач: працює з браузером, комп'ютером, кодом, файлами, викликає інструменти асинхронно.
Є дві важливі технічні риси. Перша: модель може зберігати внутрішній стан міркування між окремими викликами API. Друга: довгий контекст можна стискати, залишаючи тільки потрібне для подальшої роботи, а в Codex Astra може сама вести нотатки про свою роботу і потім шукати по них.
І це вже видно в результатах. На ARC-AGI-3, інтерактивних задачах де модель має сама зрозуміти правила невідомого середовища, Astra у стандартному режимі отримала 62.7%. Попередній найкращий результат Claude Opus 5 був 30.2%. Але коли ARC Prize дозволили моделі використовувати саме її нативні механізми, збереження стану між запитами і стиснення контексту, результат зріс до 99.9%.
Тут важливо не перебільшувати: це не означає що AGI досягнуто. Сам ARC Prize прямо каже що середовища закриті й наперед визначені. Але є деталь не менш цікава за сам результат: на 96% рівнів Astra зробила менше дій ніж медіанний учасник людина, у середньому на 51.7% менше кроків. Тобто модель не просто довше думала і перебирала більше варіантів. Вона навчилася швидше будувати уявлення про нове середовище і діяти ефективніше.
На інших незалежних тестах картина схожа. У Intelligence Index від Artificial Analysis Astra ділить вершину з Claude Fable 5.1. У рейтингу веброзробки Arena вона перша.
Але тут найважливіша частина цієї історії.
API коштує 10 доларів за мільйон вхідних токенів і 50 доларів за мільйон вихідних. Це приблизно у 2.5 раза дорожче ніж GPT-5.6 Sol за токен. Здавалося б дорога модель. Але на тестах написання коду вона виконувала завдання за ту саму загальну вартість що й Sol, бо використовувала приблизно втричі менше токенів. На ARC-AGI-3 ситуація взагалі парадоксальна: вищий рівень міркування іноді коштував дешевше за нижчий, бо модель швидше знаходила правильну стратегію і робила менше дій.
Раніше ми порівнювали моделі просто за ціною токена. Потім почали додавати рівень міркування. Але й цього вже недостатньо. Для реальних агентних систем набагато важливішими стають вартість розв'язаної задачі, час до результату і кількість дій потрібних для нього. Модель може коштувати у кілька разів дорожче за токен і при цьому бути дешевшою в експлуатації якщо їй не потрібно двадцять разів ходити по колу.
Є у Astra й інша, менш комфортна сторона. OpenAI вперше класифікувала свою модель як критичну за кіберможливостями. У тестах без виробничих обмежень вона знаходила невідомі вразливості і будувала повні ланцюжки атак. Тому релізна версія відмовляється виконувати частину складних наступальних задач з кібербезпеки, а розширений доступ залишається лише для перевірених спеціалістів.
Це показує наскільки змінилася сама проблема безпеки AI. Модель яка керує комп'ютером, запускає код і використовує десятки інструментів протягом довгої сесії, може зробити дію. Тому OpenAI тепер відстежує не тільки результат а й весь хід міркувань і дій агента, і може зупинити виконання просто посеред роботи.
За словами OpenAI, Astra стала найбільшим навчальним запуском компанії, понад 100 000 GPU.
Але головний висновок релізу не в масштабі тренування і навіть не в черговому першому місці. Ми все менше купуємо токени й усе більше купуємо виконану роботу. Якщо агент за вищою ціною здатний розв'язати задачу за три кроки, а дешевший агент ходить по колу двадцять разів, дешевша модель раптом перестає бути дешевшою.
Для розробників це означає просту річ: свої AI-системи вже варто оцінювати не тільки за якістю відповіді та ціною токена. Треба рахувати вартість завершеної задачі. Схоже саме ця метрика стане однією з головних у наступному поколінні AI-продуктів.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Схоже що рахувати ціну токенів скоро стане майже безглуздо.
OpenAI випустила GPT-6 Astra, нову флагманську модель. І цього разу найцікавіше те якою ціною вона опинилася на вершині більшості тестів.
Astra має контекст до 1.05 млн токенів, вихід до 128 тисяч, п'ять рівнів глибини міркування і проєктується вже не як чатбот а як модель для довгих агентних задач: працює з браузером, комп'ютером, кодом, файлами, викликає інструменти асинхронно.
Є дві важливі технічні риси. Перша: модель може зберігати внутрішній стан міркування між окремими викликами API. Друга: довгий контекст можна стискати, залишаючи тільки потрібне для подальшої роботи, а в Codex Astra може сама вести нотатки про свою роботу і потім шукати по них.
І це вже видно в результатах. На ARC-AGI-3, інтерактивних задачах де модель має сама зрозуміти правила невідомого середовища, Astra у стандартному режимі отримала 62.7%. Попередній найкращий результат Claude Opus 5 був 30.2%. Але коли ARC Prize дозволили моделі використовувати саме її нативні механізми, збереження стану між запитами і стиснення контексту, результат зріс до 99.9%.
Тут важливо не перебільшувати: це не означає що AGI досягнуто. Сам ARC Prize прямо каже що середовища закриті й наперед визначені. Але є деталь не менш цікава за сам результат: на 96% рівнів Astra зробила менше дій ніж медіанний учасник людина, у середньому на 51.7% менше кроків. Тобто модель не просто довше думала і перебирала більше варіантів. Вона навчилася швидше будувати уявлення про нове середовище і діяти ефективніше.
На інших незалежних тестах картина схожа. У Intelligence Index від Artificial Analysis Astra ділить вершину з Claude Fable 5.1. У рейтингу веброзробки Arena вона перша.
Але тут найважливіша частина цієї історії.
API коштує 10 доларів за мільйон вхідних токенів і 50 доларів за мільйон вихідних. Це приблизно у 2.5 раза дорожче ніж GPT-5.6 Sol за токен. Здавалося б дорога модель. Але на тестах написання коду вона виконувала завдання за ту саму загальну вартість що й Sol, бо використовувала приблизно втричі менше токенів. На ARC-AGI-3 ситуація взагалі парадоксальна: вищий рівень міркування іноді коштував дешевше за нижчий, бо модель швидше знаходила правильну стратегію і робила менше дій.
Раніше ми порівнювали моделі просто за ціною токена. Потім почали додавати рівень міркування. Але й цього вже недостатньо. Для реальних агентних систем набагато важливішими стають вартість розв'язаної задачі, час до результату і кількість дій потрібних для нього. Модель може коштувати у кілька разів дорожче за токен і при цьому бути дешевшою в експлуатації якщо їй не потрібно двадцять разів ходити по колу.
Є у Astra й інша, менш комфортна сторона. OpenAI вперше класифікувала свою модель як критичну за кіберможливостями. У тестах без виробничих обмежень вона знаходила невідомі вразливості і будувала повні ланцюжки атак. Тому релізна версія відмовляється виконувати частину складних наступальних задач з кібербезпеки, а розширений доступ залишається лише для перевірених спеціалістів.
Це показує наскільки змінилася сама проблема безпеки AI. Модель яка керує комп'ютером, запускає код і використовує десятки інструментів протягом довгої сесії, може зробити дію. Тому OpenAI тепер відстежує не тільки результат а й весь хід міркувань і дій агента, і може зупинити виконання просто посеред роботи.
За словами OpenAI, Astra стала найбільшим навчальним запуском компанії, понад 100 000 GPU.
Але головний висновок релізу не в масштабі тренування і навіть не в черговому першому місці. Ми все менше купуємо токени й усе більше купуємо виконану роботу. Якщо агент за вищою ціною здатний розв'язати задачу за три кроки, а дешевший агент ходить по колу двадцять разів, дешевша модель раптом перестає бути дешевшою.
Для розробників це означає просту річ: свої AI-системи вже варто оцінювати не тільки за якістю відповіді та ціною токена. Треба рахувати вартість завершеної задачі. Схоже саме ця метрика стане однією з головних у наступному поколінні AI-продуктів.
🔔 ПІДПИСАТИСЯ
👍13👀2❤1🔥1