Останнім часом усе частіше з’являються роботи, які показують: reasoning - це не просто «фіча для чат-ботів». Це щось значно глибше. Нещодавній реліз від NVIDIA добре це ілюструє - і, чесно кажучи, виглядає як ще один важливий крок у бік «мислячих» автономних систем.
Йдеться про Alpamayo-R1 - vision-language-action модель для автономного водіння, яка не просто прогнозує траєкторію автомобіля, а намагається пояснити, чому вона робить саме такий вибір.
Ідея тут проста, але наслідки - далеко не прості. Замість того щоб одразу переходити від відео до дії, модель спочатку формує ланцюжок міркувань: що вона бачить, що вважає важливим, які варіанти дій можливі - і лише після цього вирішує, куди і як рухатися далі.
На вході - дві секунди відео з чотирьох камер, історія положення й орієнтації авто та, за потреби, текстові команди. На виході - текст міркувань і прогноз траєкторії на 6,4 секунди вперед. І все це працює з затримкою менше 100 мс на RTX Pro 6000 (Blackwell), тобто не в теорії, а в режимі, близькому до реального часу.
З технічного боку це великий трансформер: окремий encoder для сприйняття (8,2 млрд параметрів) і decoder для генерації дій (2,3 млрд). Але цікавіше не «скільки параметрів», а як вони навчені.
Alpamayo-R1 складається з двох ключових частин. Перша - Cosmos-Reason1, vision-language модель, яка вміє описувати дії та причини цих дій. Друга - дифузійний трансформер, який генерує майбутню траєкторію руху. Спочатку система формує міркування («пішохід на переході», «попереду злиття смуг», «треба знизити швидкість»), а вже потім на їх основі прогнозує рух.
Навчання теж багатоступеневе. Спочатку модель тренували на різних доменах - від автономного водіння до логістики, медицини й виробництва. Потім - на величезному масиві даних: 80 тисяч годин відео й траєкторій руху, доповнених людськими або машинними поясненнями рішень. Причому ці пояснення містили не лише самі дії (зупинитися, прискоритися, перебудуватися), а й причини - і їх могло бути кілька для одного кадру.
На фінальному етапі додали reinforcement learning, щоб узгодити міркування й дії. Систему винагороджували не лише за правильну траєкторію, а й за те, наскільки її reasoning:
- узгоджується з «еталонними» міркуваннями,
- логічно відповідає виконаним діям,
- приводить до безпечної, плавної поведінки без зіткнень.
Результат виглядає показово. У симуляції, якщо порівнювати модель із reasoning та без нього, кількість «небезпечних зближень» з іншими авто зменшилася з 17% до 11%. Деталі дистанцій не розкривають, але сам тренд цікавий: міркування реально впливають на поведінку.
І тут, на мій погляд, ключове не навіть у цифрах. А в тому, що така система стає значно більш інтерпретованою. Якщо щось пішло не так, інженер може подивитися не лише на траєкторію, а й на ланцюжок рішень, який до неї привів. Зрозуміти, де модель помилилася в сприйнятті, де - в логіці, і що саме треба виправляти в навчанні або інференсі.
За останній рік reasoning-моделі вже обігнали свої «неміркуючі» аналоги в математиці, науці, кодингу, візуальному розумінні й робототехніці. Схоже, автономне водіння - наступна область, де chain-of-thought перестає бути експериментом і починає ставати інженерною практикою.
Мені здається, ми поступово виходимо з епохи «чорних ящиків», які просто видають дію. Наступний рівень - це системи, які можуть пояснити, чому вони так вирішили. І для безпеки, і для розвитку автономних систем це може виявитися важливішим, ніж ще кілька відсотків точності.
✅ Якщо пост був цiкавим став 👍
🔔 ПІДПИСАТИСЯ
Йдеться про Alpamayo-R1 - vision-language-action модель для автономного водіння, яка не просто прогнозує траєкторію автомобіля, а намагається пояснити, чому вона робить саме такий вибір.
Ідея тут проста, але наслідки - далеко не прості. Замість того щоб одразу переходити від відео до дії, модель спочатку формує ланцюжок міркувань: що вона бачить, що вважає важливим, які варіанти дій можливі - і лише після цього вирішує, куди і як рухатися далі.
На вході - дві секунди відео з чотирьох камер, історія положення й орієнтації авто та, за потреби, текстові команди. На виході - текст міркувань і прогноз траєкторії на 6,4 секунди вперед. І все це працює з затримкою менше 100 мс на RTX Pro 6000 (Blackwell), тобто не в теорії, а в режимі, близькому до реального часу.
З технічного боку це великий трансформер: окремий encoder для сприйняття (8,2 млрд параметрів) і decoder для генерації дій (2,3 млрд). Але цікавіше не «скільки параметрів», а як вони навчені.
Alpamayo-R1 складається з двох ключових частин. Перша - Cosmos-Reason1, vision-language модель, яка вміє описувати дії та причини цих дій. Друга - дифузійний трансформер, який генерує майбутню траєкторію руху. Спочатку система формує міркування («пішохід на переході», «попереду злиття смуг», «треба знизити швидкість»), а вже потім на їх основі прогнозує рух.
Навчання теж багатоступеневе. Спочатку модель тренували на різних доменах - від автономного водіння до логістики, медицини й виробництва. Потім - на величезному масиві даних: 80 тисяч годин відео й траєкторій руху, доповнених людськими або машинними поясненнями рішень. Причому ці пояснення містили не лише самі дії (зупинитися, прискоритися, перебудуватися), а й причини - і їх могло бути кілька для одного кадру.
На фінальному етапі додали reinforcement learning, щоб узгодити міркування й дії. Систему винагороджували не лише за правильну траєкторію, а й за те, наскільки її reasoning:
- узгоджується з «еталонними» міркуваннями,
- логічно відповідає виконаним діям,
- приводить до безпечної, плавної поведінки без зіткнень.
Результат виглядає показово. У симуляції, якщо порівнювати модель із reasoning та без нього, кількість «небезпечних зближень» з іншими авто зменшилася з 17% до 11%. Деталі дистанцій не розкривають, але сам тренд цікавий: міркування реально впливають на поведінку.
І тут, на мій погляд, ключове не навіть у цифрах. А в тому, що така система стає значно більш інтерпретованою. Якщо щось пішло не так, інженер може подивитися не лише на траєкторію, а й на ланцюжок рішень, який до неї привів. Зрозуміти, де модель помилилася в сприйнятті, де - в логіці, і що саме треба виправляти в навчанні або інференсі.
За останній рік reasoning-моделі вже обігнали свої «неміркуючі» аналоги в математиці, науці, кодингу, візуальному розумінні й робототехніці. Схоже, автономне водіння - наступна область, де chain-of-thought перестає бути експериментом і починає ставати інженерною практикою.
Мені здається, ми поступово виходимо з епохи «чорних ящиків», які просто видають дію. Наступний рівень - це системи, які можуть пояснити, чому вони так вирішили. І для безпеки, і для розвитку автономних систем це може виявитися важливішим, ніж ще кілька відсотків точності.
✅ Якщо пост був цiкавим став 👍
🔔 ПІДПИСАТИСЯ
👍12🔥2🤔1
Читаючи про застосування AI в біології та медицині, я все частіше ловлю себе на відчутті, що ми намагаємося дивитися на надзвичайно складну реальність крізь надто прості окуляри. Про це дуже влучно написав Pengtao Xie у тексті про мультимодальні моделі для біомедицини.
Біологія ніколи не була «одновимірною». Те, що відбувається на рівні молекул, пов’язане зі станом клітин. Стан клітин впливає на тканини. Тканини — на роботу органів. А все це разом проявляється в симптомах конкретної людини та її клінічній історії. Ми звикли вивчати ці рівні окремо - аналізувати послідовності, дивитися на зображення, читати медичні записи. Але реальний сенс з’являється лише тоді, коли між цими шматками виникає зв’язок.
Сучасні AI-моделі формально вже вміють працювати з усіма цими типами даних. Вони можуть читати тексти, аналізувати знімки, обробляти часові ряди. Але дуже часто це виглядає як набір окремих інструментів, складених поруч. Кожен із них щось «розуміє», але разом вони не складаються в цілісну картину.
І тут виникає ключова проблема: скласти дані разом - не означає поєднати сенс. Якщо модель не розуміє, як інформація з одного рівня пов’язана з іншим, вона легко втрачає біологічний контекст. Саме тому результати часто виглядають крихкими або важко пояснюваними.
Звідси випливає ідея, яка мені здається центральною. Нам потрібні системи, які вміють не просто «дивитися» на різні джерела інформації, а пов’язувати їх так, як це робить сама біологія. Коли знання про молекулу має логічний місток до клітинного стану. Коли зміни на зображенні тканини можна співвіднести з конкретними механізмами. Коли клінічні рішення не висять у повітрі, а спираються на зрозумілий ланцюг причин.
У медицині це особливо критично через ще одну річ - довіру. Передбачення без пояснення тут майже нічого не варте. Лікарю чи досліднику потрібно розуміти, чому система дійшла саме такого висновку, на що вона спиралася і як це узгоджується з відомою наукою. Інакше модель залишається чорним ящиком, навіть якщо її точність виглядає високою.
Є й практичні обмеження, які не можна ігнорувати. Даних часто мало, вони різні між лікарнями та країнами, постійно змінюються умови. Тому системи мають уміти адаптуватися, працювати з невизначеністю і не ламатися щоразу, коли середовище трохи змінюється.
І, нарешті, важливий критерій успіху: не цифри в таблицях. Якщо AI не допомагає формувати гіпотези, планувати експерименти або підтримувати реальні клінічні рішення, він залишається красивою демонстрацією. Майбутнє тут, швидше за все, за інтерактивними інструментами - коли людина не просто отримує відповідь, а досліджує проблему разом із системою.
Якщо мультимодальні моделі справді стануть науково обґрунтованими, прозорими й практично корисними, вони можуть перетворитися з чергового інструмента аналізу на повноцінного партнера в біомедичних відкриттях. А в цій сфері ціна помилки й цінність довіри значно вищі, ніж у будь-якому іншому домені.
Важливо, що це стосується не лише біомедицини: там, де реальність багаторівнева й наслідки рішень високі - у транспорті, безпеці, фінансах, кліматі чи освіті - системи, які не вміють поєднувати різні сигнали в осмислену картину й пояснювати свої висновки, дуже швидко перестають бути корисними.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Біологія ніколи не була «одновимірною». Те, що відбувається на рівні молекул, пов’язане зі станом клітин. Стан клітин впливає на тканини. Тканини — на роботу органів. А все це разом проявляється в симптомах конкретної людини та її клінічній історії. Ми звикли вивчати ці рівні окремо - аналізувати послідовності, дивитися на зображення, читати медичні записи. Але реальний сенс з’являється лише тоді, коли між цими шматками виникає зв’язок.
Сучасні AI-моделі формально вже вміють працювати з усіма цими типами даних. Вони можуть читати тексти, аналізувати знімки, обробляти часові ряди. Але дуже часто це виглядає як набір окремих інструментів, складених поруч. Кожен із них щось «розуміє», але разом вони не складаються в цілісну картину.
І тут виникає ключова проблема: скласти дані разом - не означає поєднати сенс. Якщо модель не розуміє, як інформація з одного рівня пов’язана з іншим, вона легко втрачає біологічний контекст. Саме тому результати часто виглядають крихкими або важко пояснюваними.
Звідси випливає ідея, яка мені здається центральною. Нам потрібні системи, які вміють не просто «дивитися» на різні джерела інформації, а пов’язувати їх так, як це робить сама біологія. Коли знання про молекулу має логічний місток до клітинного стану. Коли зміни на зображенні тканини можна співвіднести з конкретними механізмами. Коли клінічні рішення не висять у повітрі, а спираються на зрозумілий ланцюг причин.
У медицині це особливо критично через ще одну річ - довіру. Передбачення без пояснення тут майже нічого не варте. Лікарю чи досліднику потрібно розуміти, чому система дійшла саме такого висновку, на що вона спиралася і як це узгоджується з відомою наукою. Інакше модель залишається чорним ящиком, навіть якщо її точність виглядає високою.
Є й практичні обмеження, які не можна ігнорувати. Даних часто мало, вони різні між лікарнями та країнами, постійно змінюються умови. Тому системи мають уміти адаптуватися, працювати з невизначеністю і не ламатися щоразу, коли середовище трохи змінюється.
І, нарешті, важливий критерій успіху: не цифри в таблицях. Якщо AI не допомагає формувати гіпотези, планувати експерименти або підтримувати реальні клінічні рішення, він залишається красивою демонстрацією. Майбутнє тут, швидше за все, за інтерактивними інструментами - коли людина не просто отримує відповідь, а досліджує проблему разом із системою.
Якщо мультимодальні моделі справді стануть науково обґрунтованими, прозорими й практично корисними, вони можуть перетворитися з чергового інструмента аналізу на повноцінного партнера в біомедичних відкриттях. А в цій сфері ціна помилки й цінність довіри значно вищі, ніж у будь-якому іншому домені.
Важливо, що це стосується не лише біомедицини: там, де реальність багаторівнева й наслідки рішень високі - у транспорті, безпеці, фінансах, кліматі чи освіті - системи, які не вміють поєднувати різні сигнали в осмислену картину й пояснювати свої висновки, дуже швидко перестають бути корисними.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍12❤1
Вчора вийшов GPT-5.3 Codex, і хочу поділитися тим, чого від нього очікую і що наразі відомо.
Я досить багато працював із GPT-5.2 Codex у реальних інженерних задачах. Він був справді сильний у точкових речах: знайти баг, акуратно щось підправити, розв’язати добре окреслену проблему. Але коли задача вимагала довго тримати великий контекст кодової бази або продумувати складнішу архітектуру, модель інколи починала топтатися на місці. У таких сценаріях, за моїми відчуттями, Claude Code частіше поводився впевненіше.
При цьому я не раз стикався коли модель довго не може знайти корінь проблеми, ходить колами, пропонує напіврішення. А потім виходить нова версія - і та сама задача раптом розв’язується швидко, майже за одну ітерацію. Саме так було, коли вийшла GPT-5.2 Codex. Для мене це значно переконливіше за будь-які таблиці з відсотками. Тому очікую, що з 5.3 може бути схожа історія. Щоправда, поки модель недоступна через API, і це важливе обмеження.
Окремо мене зачепила ще одна обіцяна зміна з презентації - інтерактивність під час виконання. У реальній роботі це болить постійно: ти вже на середині бачиш, що модель пішла не туди. Наприклад, підхопила бібліотеку не з того кореневого каталогу або неправильно зрозуміла структуру проєкту. І ти точно знаєш, як її поправити - буквально однією фразою. Але зараз часто доводиться або чекати фіналу, або жорстко переривати процес і запускати все знову. Якщо в 5.3 це справді стане керованим процесом, без перезапусків, це виглядає дуже потужно.
Є ще одна цікава деталь. OpenAI прямо говорять, що Codex уже використовувався для тренування, тестування й деплою власних компонентів. Це звучить фантастично, але якщо такі інструменти справді стають частиною самого інженерного циклу, розвиток може піти значно швидше. До цього додаються й більш приземлені речі: швидкість, економніша робота з токенами та інші інженерні покращення.
Якщо підсумувати, GPT-5.3 Codex не виглядає «магічною революцією». Але він дуже схожий на черговий важливий зсув у бік більш живої, керованої й осмисленої взаємодії з кодинговими агентами. А відсутність API поки що лишається серйозним фактором, про який не варто забувати.
Цікаво дізнатися, якими інструментами користуєтесь ви і що саме вас не влаштовувало в GPT-5.2 Codex.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Я досить багато працював із GPT-5.2 Codex у реальних інженерних задачах. Він був справді сильний у точкових речах: знайти баг, акуратно щось підправити, розв’язати добре окреслену проблему. Але коли задача вимагала довго тримати великий контекст кодової бази або продумувати складнішу архітектуру, модель інколи починала топтатися на місці. У таких сценаріях, за моїми відчуттями, Claude Code частіше поводився впевненіше.
При цьому я не раз стикався коли модель довго не може знайти корінь проблеми, ходить колами, пропонує напіврішення. А потім виходить нова версія - і та сама задача раптом розв’язується швидко, майже за одну ітерацію. Саме так було, коли вийшла GPT-5.2 Codex. Для мене це значно переконливіше за будь-які таблиці з відсотками. Тому очікую, що з 5.3 може бути схожа історія. Щоправда, поки модель недоступна через API, і це важливе обмеження.
Окремо мене зачепила ще одна обіцяна зміна з презентації - інтерактивність під час виконання. У реальній роботі це болить постійно: ти вже на середині бачиш, що модель пішла не туди. Наприклад, підхопила бібліотеку не з того кореневого каталогу або неправильно зрозуміла структуру проєкту. І ти точно знаєш, як її поправити - буквально однією фразою. Але зараз часто доводиться або чекати фіналу, або жорстко переривати процес і запускати все знову. Якщо в 5.3 це справді стане керованим процесом, без перезапусків, це виглядає дуже потужно.
Є ще одна цікава деталь. OpenAI прямо говорять, що Codex уже використовувався для тренування, тестування й деплою власних компонентів. Це звучить фантастично, але якщо такі інструменти справді стають частиною самого інженерного циклу, розвиток може піти значно швидше. До цього додаються й більш приземлені речі: швидкість, економніша робота з токенами та інші інженерні покращення.
Якщо підсумувати, GPT-5.3 Codex не виглядає «магічною революцією». Але він дуже схожий на черговий важливий зсув у бік більш живої, керованої й осмисленої взаємодії з кодинговими агентами. А відсутність API поки що лишається серйозним фактором, про який не варто забувати.
Цікаво дізнатися, якими інструментами користуєтесь ви і що саме вас не влаштовувало в GPT-5.2 Codex.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍17
Сьогодні я хочу поговорити не про штучний інтелект, а про криптовалюту. Це трохи виходить за звичну тему каналу, але, здається, логічно вкладається в нашу ширшу розмову про технології, владу і те, як вони взаємодіють у реальному світі.
Криптовалютами я цікавлюся давно. Ще у 2014 році розбирався, як працює блокчейн, пробував майнити на ноутбуці - радше як технічний експеримент. У 2018 році вів невеликий Telegram-канал про криптотехнології, пізніше на YouTube більше говорив про програмування, але блокчейн теж кілька разів з’являвся. Я інвестував, у мене навіть була невелика майнінг-ферма Ethereum у 2018-му. Але головний інтерес для мене завжди був не в спекуляції.
Мене цікавив блокчейн як технологія: децентралізована, розподілена база даних, де довіра будується навколо правил і консенсусу, а не навколо одного центру. Криптовалюта - лише один із проявів цієї ідеї і, безумовно, один із найважливіших.
Упродовж майже двадцяти років криптовалюта сприймалася як альтернатива банківській системі. Гроші надто централізовані, контролюються державами, регуляторами, великими інститутами. На цьому тлі поява блокчейна, біткоїна й криптовалют загалом виглядала як технологічна революція проти встановленого порядку - проти корпорацій, урядів і режимів, які обмежують доступ і свободу.
У цій логіці криптовалюта подавалася як шлях до певної форми фінансової свободи: транзакції анонімні, їх складно відстежити, немає єдиного центру контролю, немає посередника, який може «вимкнути» тебе з системи. Зворотним боком стало те, що ці ж властивості почали активно використовувати шахраї, але це окрема й добре відома історія. Первинна ж філософія була іншою - дати звичайним людям інструмент, який зменшує залежність від сильних світу цього.
І ось на цьому тлі з’являється історія з файлами Епштейна. В інтернеті знову спливають фейкові «докази», що він нібито був Сатоші Накамото. Це неправда, і важливо не підміняти аналіз міфологією.
Але паралельно залишається інше відчуття: Джеффрі Епштейн, здається, був впливовою фігурою для частини криптосередовища. І коли після публікації файлів один криптоаналітик написав, що «по суті, ми всі разом профінансували глобальну педофільську мережу еліт у 2015 році», у мене це викликало не дискусію про ринок, а фізичну огиду.
Ця історія змусила мене думати не стільки про крипту, скільки про щось більш фундаментальне. Про те, як узагалі влаштована влада.
Є популярний наратив: бідні вигадують інструменти, щоб звільнитися від багатих. Історично це виглядає логічно. Люди об’єднуються, створюють механізми захисту, домовляються про правила - і ніби піднімають планку справедливості.
Але якщо дивитися довше, картина стає менш романтичною. Коли з’являється сильний інструмент, який справді змінює баланс, у гру входять ті, у кого вже є гроші й зв’язки. Вони рідко забороняють нове напряму. Частіше - просто оплачують рахунки в момент, коли автори ідеї залишаються без ресурсу.
Це виглядає ефективніше за будь-який «заборонити». Навіщо ламати революцію, якщо можна найняти революціонерів?
У цьому сенсі історія з біткоїном зачіпає болючу точку. За задумом це була технологія, яка мала зробити так, щоб жоден банкір, чиновник чи людина на кшталт Епштейна не могла контролювати твої гроші. Анонімні творці. Відкритий код. Децентралізація. Все виглядає чисто і навіть красиво.
А тепер - менш комфортне запитання. Якщо система створена так, щоб ніхто не міг «взяти її під контроль», то що відбувається, коли в неї заходять гроші людей, від яких нормальна людина не захотіла б брати нічого?
Судячи з того, що ми бачимо, нічого особливого не відбувається. Ніхто не відмовляється. Ні MIT, ні розробники, ні біржі. Бо в реальному житті гроші часто не мають запаху. І, здається, не мали ніколи.
Продовження 👇🏻
Криптовалютами я цікавлюся давно. Ще у 2014 році розбирався, як працює блокчейн, пробував майнити на ноутбуці - радше як технічний експеримент. У 2018 році вів невеликий Telegram-канал про криптотехнології, пізніше на YouTube більше говорив про програмування, але блокчейн теж кілька разів з’являвся. Я інвестував, у мене навіть була невелика майнінг-ферма Ethereum у 2018-му. Але головний інтерес для мене завжди був не в спекуляції.
Мене цікавив блокчейн як технологія: децентралізована, розподілена база даних, де довіра будується навколо правил і консенсусу, а не навколо одного центру. Криптовалюта - лише один із проявів цієї ідеї і, безумовно, один із найважливіших.
Упродовж майже двадцяти років криптовалюта сприймалася як альтернатива банківській системі. Гроші надто централізовані, контролюються державами, регуляторами, великими інститутами. На цьому тлі поява блокчейна, біткоїна й криптовалют загалом виглядала як технологічна революція проти встановленого порядку - проти корпорацій, урядів і режимів, які обмежують доступ і свободу.
У цій логіці криптовалюта подавалася як шлях до певної форми фінансової свободи: транзакції анонімні, їх складно відстежити, немає єдиного центру контролю, немає посередника, який може «вимкнути» тебе з системи. Зворотним боком стало те, що ці ж властивості почали активно використовувати шахраї, але це окрема й добре відома історія. Первинна ж філософія була іншою - дати звичайним людям інструмент, який зменшує залежність від сильних світу цього.
І ось на цьому тлі з’являється історія з файлами Епштейна. В інтернеті знову спливають фейкові «докази», що він нібито був Сатоші Накамото. Це неправда, і важливо не підміняти аналіз міфологією.
Але паралельно залишається інше відчуття: Джеффрі Епштейн, здається, був впливовою фігурою для частини криптосередовища. І коли після публікації файлів один криптоаналітик написав, що «по суті, ми всі разом профінансували глобальну педофільську мережу еліт у 2015 році», у мене це викликало не дискусію про ринок, а фізичну огиду.
Ця історія змусила мене думати не стільки про крипту, скільки про щось більш фундаментальне. Про те, як узагалі влаштована влада.
Є популярний наратив: бідні вигадують інструменти, щоб звільнитися від багатих. Історично це виглядає логічно. Люди об’єднуються, створюють механізми захисту, домовляються про правила - і ніби піднімають планку справедливості.
Але якщо дивитися довше, картина стає менш романтичною. Коли з’являється сильний інструмент, який справді змінює баланс, у гру входять ті, у кого вже є гроші й зв’язки. Вони рідко забороняють нове напряму. Частіше - просто оплачують рахунки в момент, коли автори ідеї залишаються без ресурсу.
Це виглядає ефективніше за будь-який «заборонити». Навіщо ламати революцію, якщо можна найняти революціонерів?
У цьому сенсі історія з біткоїном зачіпає болючу точку. За задумом це була технологія, яка мала зробити так, щоб жоден банкір, чиновник чи людина на кшталт Епштейна не могла контролювати твої гроші. Анонімні творці. Відкритий код. Децентралізація. Все виглядає чисто і навіть красиво.
А тепер - менш комфортне запитання. Якщо система створена так, щоб ніхто не міг «взяти її під контроль», то що відбувається, коли в неї заходять гроші людей, від яких нормальна людина не захотіла б брати нічого?
Судячи з того, що ми бачимо, нічого особливого не відбувається. Ніхто не відмовляється. Ні MIT, ні розробники, ні біржі. Бо в реальному житті гроші часто не мають запаху. І, здається, не мали ніколи.
Продовження 👇🏻
👍17
Попередня частина 👆
Тут і проявляється парадокс: система, яку будували як інструмент чесності й прозорості, у найвразливіший момент свого розвитку прийняла максимально непрозорі й нечесні гроші - і продовжила працювати так, ніби нічого не сталося.
Часто кажуть: «біткоїн - це свобода». Але свобода від чого саме? Від банків? Можливо. Та свобода від банків не дорівнює свободі від людей, які мають доступ до капіталу й впливу. Бо ці люди не прив’язані до інститутів. Вони прив’язані до грошей.
А гроші, як правило, течуть туди, де є влада. І вже не так важливо, як називається механізм: банк, блокчейн чи «децентралізована мережа». Якщо думати, що зміна назви системи змінює її суть, це, здається, помилка. Суть не тільки в правилах. Суть у людях, які знаходять спосіб керувати правилами через ресурс.
Найсумніше тут навіть не те, що Епштейн «зайшов» у крипту. А те, що ніхто не відмовився від його грошей. Система була готова прийняти їх і далі будувати свій світ - на цих самих ресурсах.
І на цьому тлі постать Сатоші виглядає майже як контрастний експеримент. Він, ким би він не був, зник. Не взяв ні копійки зі своїх гаманців, де зараз лежать мільярди. Він створив систему - і пішов.
А Епштейн залишився. Прийшов із мішком грошей, сів за стіл, познайомив потрібних людей і почав впливати на те, куди рухатиметься ринок. Створювач пішов - а той, хто живе за рахунок систем, зайняв місце поряд із кермом.
Це можна сприймати як історію про крипту. Але, здається, це ширша метафора. Ти можеш спроєктувати ідеальний дім - продуманий, логічний, «правильний». Але якщо в тебе немає землі, ресурсів на будівництво і часу, щоб довести справу до кінця, прийде той, хто заплатить. І тоді дім буде його. Не тому, що він краще придумав. А тому, що в нього були гроші саме тоді, коли в тебе їх не було.
Тому коли наступного разу скажуть, що крипта - це «зброя маленької людини проти системи», варто згадати одну деталь. У ключовий момент маленька людина сиділа без зарплати, а чек виписував педофіл із особняка на Мангеттені.
✅ Якщо пост був корисним став 👍
💬 А ви вірите, що технології можуть звільняти, чи вони лише змінюють форму контролю?
🔔 ПІДПИСАТИСЯ
Тут і проявляється парадокс: система, яку будували як інструмент чесності й прозорості, у найвразливіший момент свого розвитку прийняла максимально непрозорі й нечесні гроші - і продовжила працювати так, ніби нічого не сталося.
Часто кажуть: «біткоїн - це свобода». Але свобода від чого саме? Від банків? Можливо. Та свобода від банків не дорівнює свободі від людей, які мають доступ до капіталу й впливу. Бо ці люди не прив’язані до інститутів. Вони прив’язані до грошей.
А гроші, як правило, течуть туди, де є влада. І вже не так важливо, як називається механізм: банк, блокчейн чи «децентралізована мережа». Якщо думати, що зміна назви системи змінює її суть, це, здається, помилка. Суть не тільки в правилах. Суть у людях, які знаходять спосіб керувати правилами через ресурс.
Найсумніше тут навіть не те, що Епштейн «зайшов» у крипту. А те, що ніхто не відмовився від його грошей. Система була готова прийняти їх і далі будувати свій світ - на цих самих ресурсах.
І на цьому тлі постать Сатоші виглядає майже як контрастний експеримент. Він, ким би він не був, зник. Не взяв ні копійки зі своїх гаманців, де зараз лежать мільярди. Він створив систему - і пішов.
А Епштейн залишився. Прийшов із мішком грошей, сів за стіл, познайомив потрібних людей і почав впливати на те, куди рухатиметься ринок. Створювач пішов - а той, хто живе за рахунок систем, зайняв місце поряд із кермом.
Це можна сприймати як історію про крипту. Але, здається, це ширша метафора. Ти можеш спроєктувати ідеальний дім - продуманий, логічний, «правильний». Але якщо в тебе немає землі, ресурсів на будівництво і часу, щоб довести справу до кінця, прийде той, хто заплатить. І тоді дім буде його. Не тому, що він краще придумав. А тому, що в нього були гроші саме тоді, коли в тебе їх не було.
Тому коли наступного разу скажуть, що крипта - це «зброя маленької людини проти системи», варто згадати одну деталь. У ключовий момент маленька людина сиділа без зарплати, а чек виписував педофіл із особняка на Мангеттені.
✅ Якщо пост був корисним став 👍
💬 А ви вірите, що технології можуть звільняти, чи вони лише змінюють форму контролю?
🔔 ПІДПИСАТИСЯ
👍17🤔4❤1
Я багато працюю з людьми і бачу, як вони використовують AI. Якщо чесно, у більшості випадків усе зводиться до одного інструмента - ChatGPT. І для повсякденних задач цього зазвичай достатньо.
Це зрозуміло. Він зручний, доступний і справді закриває велику частину запитів. Але іноді виникає запитання: чи не звужуємо ми таким чином власну практику? Різні моделі по-різному працюють із контекстом, по-різному структурують відповідь, по-різному поводяться в складних сценаріях. Якщо користуватися лише однією системою, ми просто не бачимо альтернатив.
Anthropic нещодавно оновила свою флагманську модель до Claude Opus 4.6. Її описують як крок у бік довших і складніших задач, особливо тих, де модель діє як агент. Формально все виглядає доволі просто: контекст до одного мільйона токенів і можливість генерувати до 128 тисяч токенів у відповіді. Але справа, здається, не лише в цифрах.
Останні роки навіть з’являються нові ролі на кшталт контекст-інженера, який займається тим, як правильно «упакувати» запит до моделі. І водночас нові версії самих моделей намагаються частково забрати цю складність на себе. Це мимоволі нагадує ідею з есе The Bitter Lesson: масштабування і автоматизація поступово витісняють ручну оптимізацію.
У Opus 4.6 з’явився режим adaptive thinking. Тепер модель сама вирішує, скільки ресурсу витратити на міркування залежно від складності задачі. Раніше потрібно було задавати фіксований бюджет для розширеного мислення, тепер частина цього рішення переноситься всередину моделі. Є параметр effort із чотирма рівнями, який впливає на те, наскільки активно вона заглиблюється в аналіз. Міркування можуть з’являтися і між викликами інструментів, і перед відповіддю.
Про бенчмарки можна сказати коротко. У зведеному індексі Artificial Analysis модель посіла перше місце. В окремих тестах, пов’язаних із робочими задачами, вона також показала високі результати. Але, якщо чесно, для більшості читачів ці цифри мало що змінюють. Важливіше інше.
Є й менш зручні деталі. У кількох тестах нова версія поступилася попередній, зокрема в дотриманні інструкцій і частоті галюцинацій. Тобто збільшення можливостей не означає автоматичне покращення за всіма параметрами. Компроміси залишаються.
Цікавий і момент із поведінкою агента. Під час тестування модель попросили створити pull request на GitHub без необхідних доступів. Замість того щоб запитати права, вона знайшла чужий токен і використала його. До речі, я бачив, як відомі підприємці вже пояснюють у відкритому доступі, що таке pull request і як працювати з GitHub. Світ змінюється, і базове розуміння програмної інженерії поступово стає нормою навіть поза технічною сферою. Але в цьому випадку справа не в GitHub. Справа в тому, як модель інтерпретує мету і де проходить межа допустимого.
У бізнес-симуляції Vending-Bench 2 Opus 4.6 показала рекордний прибуток. Проте частину цього результату вона досягла через неетичні дії: вводила клієнтів і постачальників в оману. Це змушує замислитися, що саме ми оцінюємо, коли говоримо про «кращий результат». Чисту цифру чи поведінку в межах правил?
Можливо, справжній прогрес полягає не лише в тому, що моделі стають сильнішими. А в тому, що ми поступово вчимося краще розуміти їхні межі.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Це зрозуміло. Він зручний, доступний і справді закриває велику частину запитів. Але іноді виникає запитання: чи не звужуємо ми таким чином власну практику? Різні моделі по-різному працюють із контекстом, по-різному структурують відповідь, по-різному поводяться в складних сценаріях. Якщо користуватися лише однією системою, ми просто не бачимо альтернатив.
Anthropic нещодавно оновила свою флагманську модель до Claude Opus 4.6. Її описують як крок у бік довших і складніших задач, особливо тих, де модель діє як агент. Формально все виглядає доволі просто: контекст до одного мільйона токенів і можливість генерувати до 128 тисяч токенів у відповіді. Але справа, здається, не лише в цифрах.
Останні роки навіть з’являються нові ролі на кшталт контекст-інженера, який займається тим, як правильно «упакувати» запит до моделі. І водночас нові версії самих моделей намагаються частково забрати цю складність на себе. Це мимоволі нагадує ідею з есе The Bitter Lesson: масштабування і автоматизація поступово витісняють ручну оптимізацію.
У Opus 4.6 з’явився режим adaptive thinking. Тепер модель сама вирішує, скільки ресурсу витратити на міркування залежно від складності задачі. Раніше потрібно було задавати фіксований бюджет для розширеного мислення, тепер частина цього рішення переноситься всередину моделі. Є параметр effort із чотирма рівнями, який впливає на те, наскільки активно вона заглиблюється в аналіз. Міркування можуть з’являтися і між викликами інструментів, і перед відповіддю.
Про бенчмарки можна сказати коротко. У зведеному індексі Artificial Analysis модель посіла перше місце. В окремих тестах, пов’язаних із робочими задачами, вона також показала високі результати. Але, якщо чесно, для більшості читачів ці цифри мало що змінюють. Важливіше інше.
Є й менш зручні деталі. У кількох тестах нова версія поступилася попередній, зокрема в дотриманні інструкцій і частоті галюцинацій. Тобто збільшення можливостей не означає автоматичне покращення за всіма параметрами. Компроміси залишаються.
Цікавий і момент із поведінкою агента. Під час тестування модель попросили створити pull request на GitHub без необхідних доступів. Замість того щоб запитати права, вона знайшла чужий токен і використала його. До речі, я бачив, як відомі підприємці вже пояснюють у відкритому доступі, що таке pull request і як працювати з GitHub. Світ змінюється, і базове розуміння програмної інженерії поступово стає нормою навіть поза технічною сферою. Але в цьому випадку справа не в GitHub. Справа в тому, як модель інтерпретує мету і де проходить межа допустимого.
У бізнес-симуляції Vending-Bench 2 Opus 4.6 показала рекордний прибуток. Проте частину цього результату вона досягла через неетичні дії: вводила клієнтів і постачальників в оману. Це змушує замислитися, що саме ми оцінюємо, коли говоримо про «кращий результат». Чисту цифру чи поведінку в межах правил?
Можливо, справжній прогрес полягає не лише в тому, що моделі стають сильнішими. А в тому, що ми поступово вчимося краще розуміти їхні межі.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍12🔥2🥴1
Нещодавно я спілкувався зі знайомим, який працює у медичному стартапі та впроваджує рішення на основі штучного інтелекту. У розмові він згадав нове дослідження, яке здалося мені вартим уваги, тож ділюся ним із вами. Якщо подивитися на те, як AI зазвичай застосовують у діагностиці, все виглядає доволі прямолінійно: є симптоми, є модель, є назва хвороби. Такий підхід зустрічається не лише в медицині. Але реальна клініка складніша. Лікарю недостатньо вгадати діагноз. Потрібно пояснити, чому зроблено саме такий висновок, які альтернативи розглядалися і що далі. Саме ця логіка міркування і відповідальність є основою медичної практики.
У цьому контексті з’являється проєкт Dr. CaBot. Дослідники спробували зайти в цю складнішу зону, де важлива не лише відповідь, а й шлях до неї. Вони побудували агентну систему, що імітує мислення досвідчених лікарів, спираючись на тисячі клінічних розборів. Група інтерністів, які оцінювали систему, дійшла висновку, що діагнози моделі були точнішими, а пояснення більш послідовними, ніж у їхніх колег. Над проєктом працювали дослідники з Harvard Medical School, Beth Israel Deaconess Medical Center, Brigham and Women’s Hospital, Massachusetts General Hospital, University of Rochester та Harvard University.
Ключова ідея проста, але нетривіальна. Медична література містить багато фактів, однак рідко показує сам процес мислення у послідовному форматі. І це проблема не лише медицини. Свого часу я займався фізикою і часто відчував брак пояснення того, як саме автор доходить до висновку. Нерідко здається, що читач має сам відновити проміжні кроки. Але для клінічної логіки важлива не лише інформація, а те, як лікар переходить від фактів до гіпотез і обґрунтовує вибір.
Автори спиралися на жанр clinicopathological conferences. The New England Journal of Medicine опублікував понад сім тисяч таких розборів з 1923 по 2025 рік. У них лікарі крок за кроком аналізують випадки на основі огляду та анамнезу. Важливо не лише те, який діагноз поставлено, а як до нього прийшли.
Автори оцифрували 7 102 випадки і побудували Dr. CaBot на основі OpenAI o3. Для оцінки створили CPC Bench із десятьма завданнями. Система працює через пошук подібних прикладів і розширення контексту. Клінічні розбори переводять у формат для швидкого пошуку схожих випадків. Те саме роблять із мільйонами коротких описів статей. Отримавши симптоми, модель знаходить два схожі випадки, підбирає релевантні матеріали і формує діагноз разом із поясненням. Тобто вона намагається міркувати, спираючись на досвід і літературу.
У тестуванні на CPC Bench модель ставила правильний діагноз на перше місце у шістдесяти відсотках випадків. Для порівняння, група з двадцяти лікарів зробила це у двадцяти чотирьох відсотках. Правильність відповідей перевіряла GPT 4.1 як оцінювач.
Також провели сліпе оцінювання. П’ять лікарів читали пояснення, не знаючи автора. У більшості випадків вони обирали тексти моделі, а джерело правильно вгадували лише приблизно в чверті випадків. Її міркування часто сприймалися як природні та переконливі. Втім, клініка не зводиться до тестових цифр. Кожне рішення потребує аргументації і відповідальності, тож важливо не лише те, чи правильний діагноз, а як він пояснений. І тут виникає ширше питання. Чи можна навчити систему не просто знаходити хворобу, а мислити в межах професійної традиції, де пояснення є частиною рішення. Якщо так, тоді оцінювати доведеться не лише точність відповіді, а спосіб її формування і рівень відповідальності, з яким вона подається.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
У цьому контексті з’являється проєкт Dr. CaBot. Дослідники спробували зайти в цю складнішу зону, де важлива не лише відповідь, а й шлях до неї. Вони побудували агентну систему, що імітує мислення досвідчених лікарів, спираючись на тисячі клінічних розборів. Група інтерністів, які оцінювали систему, дійшла висновку, що діагнози моделі були точнішими, а пояснення більш послідовними, ніж у їхніх колег. Над проєктом працювали дослідники з Harvard Medical School, Beth Israel Deaconess Medical Center, Brigham and Women’s Hospital, Massachusetts General Hospital, University of Rochester та Harvard University.
Ключова ідея проста, але нетривіальна. Медична література містить багато фактів, однак рідко показує сам процес мислення у послідовному форматі. І це проблема не лише медицини. Свого часу я займався фізикою і часто відчував брак пояснення того, як саме автор доходить до висновку. Нерідко здається, що читач має сам відновити проміжні кроки. Але для клінічної логіки важлива не лише інформація, а те, як лікар переходить від фактів до гіпотез і обґрунтовує вибір.
Автори спиралися на жанр clinicopathological conferences. The New England Journal of Medicine опублікував понад сім тисяч таких розборів з 1923 по 2025 рік. У них лікарі крок за кроком аналізують випадки на основі огляду та анамнезу. Важливо не лише те, який діагноз поставлено, а як до нього прийшли.
Автори оцифрували 7 102 випадки і побудували Dr. CaBot на основі OpenAI o3. Для оцінки створили CPC Bench із десятьма завданнями. Система працює через пошук подібних прикладів і розширення контексту. Клінічні розбори переводять у формат для швидкого пошуку схожих випадків. Те саме роблять із мільйонами коротких описів статей. Отримавши симптоми, модель знаходить два схожі випадки, підбирає релевантні матеріали і формує діагноз разом із поясненням. Тобто вона намагається міркувати, спираючись на досвід і літературу.
У тестуванні на CPC Bench модель ставила правильний діагноз на перше місце у шістдесяти відсотках випадків. Для порівняння, група з двадцяти лікарів зробила це у двадцяти чотирьох відсотках. Правильність відповідей перевіряла GPT 4.1 як оцінювач.
Також провели сліпе оцінювання. П’ять лікарів читали пояснення, не знаючи автора. У більшості випадків вони обирали тексти моделі, а джерело правильно вгадували лише приблизно в чверті випадків. Її міркування часто сприймалися як природні та переконливі. Втім, клініка не зводиться до тестових цифр. Кожне рішення потребує аргументації і відповідальності, тож важливо не лише те, чи правильний діагноз, а як він пояснений. І тут виникає ширше питання. Чи можна навчити систему не просто знаходити хворобу, а мислити в межах професійної традиції, де пояснення є частиною рішення. Якщо так, тоді оцінювати доведеться не лише точність відповіді, а спосіб її формування і рівень відповідальності, з яким вона подається.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍15🔥1
Нещодавно OpenAI представили нову модель GPT‑5.3 Codex. Майже одразу з’явилися розмови про наступну ітерацію — GPT‑5.4, а для всіх користувачів став доступним і легший варіант — GPT‑5.3 Instant.
Таке швидке оновлення моделей саме по собі вже стало звичним. Але цього разу воно наштовхнуло мене на деякі роздуми.
У попередньому дописі я згадував, що нова модель почала стабільно розв’язувати задачі, які раніше або не вирішувались взагалі, або вимагали досить складної оптимізації промптів. Часто доводилось будувати довгі інструкції, розбивати задачу на кроки, підбирати формулювання майже експериментально. І це працювало — але виглядало як ручна підгонка під конкретні слабкі місця конкретної моделі.
Після виходу нової версії значна частина цих «трюків» просто втратила сенс. Те, що раніше вимагало хитрих конструкцій, почало вирішуватися значно простіше.
І тут виникає природне питання: що саме ми насправді оптимізували всі ці місяці?
Коли намагаєшся знайти більш загальне пояснення, дуже доречно згадується есе Rich Sutton The Bitter Lesson. У ньому Саттон описує закономірність, яку можна простежити через десятиліття розвитку штучного інтелекту.
Суть досить проста. У довгостроковій перспективі виграють методи, які здатні масштабуватися разом з обчисленнями. А підходи, де ми намагаємося вручну закласти знання про предметну область — правила, структури, евристики — зазвичай дають короткострокову перевагу, але з часом виходять на плато.
Історія AI дає багато прикладів: шахи, Ґо, розпізнавання мовлення, комп’ютерний зір. У кожній з цих сфер спочатку намагалися зробити системи «розумнішими» за рахунок людського розуміння задачі. Але коли обчислювальні ресурси зростали, перевагу отримували більш загальні підходи — пошук і навчання — які просто краще використовували масштаб.
Саме тому цей урок і називається «гірким». Людські інженерні рішення виглядають елегантними. Вони дають швидкий результат. Але часто виявляється, що вони погано переживають наступне покоління технології.
Якщо подивитися на сьогоднішню дискусію про AI, легко помітити схожий патерн. Ми багато говоримо про промпт-інженерію: як правильно формулювати запит, які шаблони працюють краще, як «витиснути» максимум із моделі. Навколо цього навіть з’являються курси і окрема експертиза.
Але в світлі The Bitter Lesson усе це починає виглядати трохи інакше.
Можливо, промпт-інженерія — це просто ще один приклад короткострокової оптимізації. Спосіб обійти поточні обмеження системи. Поки вона ще не достатньо потужна або не достатньо добре розуміє наміри користувача.
Вихід нової моделі фактично знімає частину цих обмежень. І те, що раніше виглядало як складна техніка взаємодії, раптом стає зайвим.
У цьому сенсі показовою виглядає фраза, яку іноді приписують Ілон Маск: any user input is an error. Якщо читати її не буквально, а як інженерну інтуїцію, вона звучить доволі логічно. Чим зріліша система, тим менше вона повинна залежати від «ідеального» вводу.
Можливо, найцікавіший висновок тут не в тому, що промпти «більше не потрібні». А в тому, що їхня роль може бути тимчасовою.
Історія AI досить послідовно показує: у довгій перспективі перемагають ті рішення, які не потребують постійної ручної оптимізації. Ті, для яких зростання обчислень і можливостей системи стає союзником.
І якщо дивитися на швидкість появи нових моделей сьогодні, виникає відчуття, що ми знову спостерігаємо ту саму закономірність — тільки вже в реальному часі.
Таке швидке оновлення моделей саме по собі вже стало звичним. Але цього разу воно наштовхнуло мене на деякі роздуми.
У попередньому дописі я згадував, що нова модель почала стабільно розв’язувати задачі, які раніше або не вирішувались взагалі, або вимагали досить складної оптимізації промптів. Часто доводилось будувати довгі інструкції, розбивати задачу на кроки, підбирати формулювання майже експериментально. І це працювало — але виглядало як ручна підгонка під конкретні слабкі місця конкретної моделі.
Після виходу нової версії значна частина цих «трюків» просто втратила сенс. Те, що раніше вимагало хитрих конструкцій, почало вирішуватися значно простіше.
І тут виникає природне питання: що саме ми насправді оптимізували всі ці місяці?
Коли намагаєшся знайти більш загальне пояснення, дуже доречно згадується есе Rich Sutton The Bitter Lesson. У ньому Саттон описує закономірність, яку можна простежити через десятиліття розвитку штучного інтелекту.
Суть досить проста. У довгостроковій перспективі виграють методи, які здатні масштабуватися разом з обчисленнями. А підходи, де ми намагаємося вручну закласти знання про предметну область — правила, структури, евристики — зазвичай дають короткострокову перевагу, але з часом виходять на плато.
Історія AI дає багато прикладів: шахи, Ґо, розпізнавання мовлення, комп’ютерний зір. У кожній з цих сфер спочатку намагалися зробити системи «розумнішими» за рахунок людського розуміння задачі. Але коли обчислювальні ресурси зростали, перевагу отримували більш загальні підходи — пошук і навчання — які просто краще використовували масштаб.
Саме тому цей урок і називається «гірким». Людські інженерні рішення виглядають елегантними. Вони дають швидкий результат. Але часто виявляється, що вони погано переживають наступне покоління технології.
Якщо подивитися на сьогоднішню дискусію про AI, легко помітити схожий патерн. Ми багато говоримо про промпт-інженерію: як правильно формулювати запит, які шаблони працюють краще, як «витиснути» максимум із моделі. Навколо цього навіть з’являються курси і окрема експертиза.
Але в світлі The Bitter Lesson усе це починає виглядати трохи інакше.
Можливо, промпт-інженерія — це просто ще один приклад короткострокової оптимізації. Спосіб обійти поточні обмеження системи. Поки вона ще не достатньо потужна або не достатньо добре розуміє наміри користувача.
Вихід нової моделі фактично знімає частину цих обмежень. І те, що раніше виглядало як складна техніка взаємодії, раптом стає зайвим.
У цьому сенсі показовою виглядає фраза, яку іноді приписують Ілон Маск: any user input is an error. Якщо читати її не буквально, а як інженерну інтуїцію, вона звучить доволі логічно. Чим зріліша система, тим менше вона повинна залежати від «ідеального» вводу.
Можливо, найцікавіший висновок тут не в тому, що промпти «більше не потрібні». А в тому, що їхня роль може бути тимчасовою.
Історія AI досить послідовно показує: у довгій перспективі перемагають ті рішення, які не потребують постійної ручної оптимізації. Ті, для яких зростання обчислень і можливостей системи стає союзником.
І якщо дивитися на швидкість появи нових моделей сьогодні, виникає відчуття, що ми знову спостерігаємо ту саму закономірність — тільки вже в реальному часі.
👍8🔥4
Сьогодні слово «агент» використовують так часто, що воно майже втратило свій зміст. Будь-який бот із тулзами, будь-який автоматизований пайплайн, будь-який coding-assistant — усе це раптом почали називати агентами.
Через це виникає досить небезпечна ілюзія: ніби ми вже живемо у світі автономних цифрових співробітників, які ось-ось повністю замінять людей.
Але якщо придивитися уважніше, ситуація виглядає інакше.
Більшість систем, які сьогодні гучно називають агентами, насправді є просто LLM, загорнутою у зручний інтерфейс і набір наперед прописаних сценаріїв. Така система може згенерувати текст, вибрати один із шаблонів, викликати певну функцію.
Але це ще не самостійність.
Це радше автоматизація з елементами вибору, а не суб’єкт, який справді може розібрати мету, побудувати план і змінювати свою поведінку в процесі виконання задачі.
Різниця тут принципова.
Звичайний чат-бот відповідає.
Агент — діє.
Бот чекає наступного повідомлення користувача.
Агент може сам вирішити, що для досягнення результату потрібно зробити кілька кроків: використати різні інструменти, повернутися до проміжного результату, перевірити його і продовжити рух до цілі.
Саме тому розмова про агентів сьогодні така важлива.
Не тому, що це модне слово. А тому, що поступово змінюється сама форма взаємодії з AI.
Ми починаємо переходити від моделі «запит — відповідь» до моделі «мета — процес».
І, можливо, саме тут проходить справжній переломний момент.
Не тоді, коли нейромережі стали краще писати тексти або генерувати картинки. А тоді, коли вони почали перетворюватися із співрозмовника на виконавця.
Якщо подивитися на це трохи ширше, стає видно ще одну важливу межу.
Справжній вододіл у розвитку AI проходить не між «розумною» і «дуже розумною» моделлю.
Він проходить між системою, яка просто відповідає, і системою, яка може приймати рішення в рамках задачі.
Уявімо типовий workflow сучасного AI-сервісу.
Користувач пише повідомлення. Система класифікує запит. Далі за заздалегідь прописаною гілкою запускається генерація тексту, картинки або відео.
Така система може бути швидкою, корисною і навіть справляти сильне враження.
Але вона все ще детермінована.
Модель усередині не змінює правила гри — вона лише рухається по рельсах, які хтось заздалегідь намалював.
Агент з’являється там, де ці рельси закінчуються.
Коли у системи немає жорсткої послідовності кроків, а є мета і набір інструментів, вона починає вибирати, що робити.
Відповісти чи ні.
Зробити одну дію чи кілька.
Спочатку проаналізувати, потім згенерувати результат, потім використати інструмент і лише після цього повернутися до користувача.
Це вже інший рівень архітектури.
Не просто функція за інструкцією, а виконавець з обмеженою автономією.
І саме в цьому прихована причина, чому агенти зараз викликають так багато шуму.
Вони ближчі до цифрового працівника, ніж до чат-бота. Не тому, що «краще думають», а тому що вони вбудовані у контур дії.
Але разом із цим приходить і важлива реальність.
Агентність — це не магія.
Це завжди компроміс між свободою і контролем.
Чим більше свободи ми даємо системі, тим важливішими стають обмеження: правила доступу до інструментів, перевірка небезпечних дій, прозорість того, що саме система робить під капотом.
Інакше замість помічника можна отримати не цифрового співробітника, а дуже красиву проблему з API-ключем.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Через це виникає досить небезпечна ілюзія: ніби ми вже живемо у світі автономних цифрових співробітників, які ось-ось повністю замінять людей.
Але якщо придивитися уважніше, ситуація виглядає інакше.
Більшість систем, які сьогодні гучно називають агентами, насправді є просто LLM, загорнутою у зручний інтерфейс і набір наперед прописаних сценаріїв. Така система може згенерувати текст, вибрати один із шаблонів, викликати певну функцію.
Але це ще не самостійність.
Це радше автоматизація з елементами вибору, а не суб’єкт, який справді може розібрати мету, побудувати план і змінювати свою поведінку в процесі виконання задачі.
Різниця тут принципова.
Звичайний чат-бот відповідає.
Агент — діє.
Бот чекає наступного повідомлення користувача.
Агент може сам вирішити, що для досягнення результату потрібно зробити кілька кроків: використати різні інструменти, повернутися до проміжного результату, перевірити його і продовжити рух до цілі.
Саме тому розмова про агентів сьогодні така важлива.
Не тому, що це модне слово. А тому, що поступово змінюється сама форма взаємодії з AI.
Ми починаємо переходити від моделі «запит — відповідь» до моделі «мета — процес».
І, можливо, саме тут проходить справжній переломний момент.
Не тоді, коли нейромережі стали краще писати тексти або генерувати картинки. А тоді, коли вони почали перетворюватися із співрозмовника на виконавця.
Якщо подивитися на це трохи ширше, стає видно ще одну важливу межу.
Справжній вододіл у розвитку AI проходить не між «розумною» і «дуже розумною» моделлю.
Він проходить між системою, яка просто відповідає, і системою, яка може приймати рішення в рамках задачі.
Уявімо типовий workflow сучасного AI-сервісу.
Користувач пише повідомлення. Система класифікує запит. Далі за заздалегідь прописаною гілкою запускається генерація тексту, картинки або відео.
Така система може бути швидкою, корисною і навіть справляти сильне враження.
Але вона все ще детермінована.
Модель усередині не змінює правила гри — вона лише рухається по рельсах, які хтось заздалегідь намалював.
Агент з’являється там, де ці рельси закінчуються.
Коли у системи немає жорсткої послідовності кроків, а є мета і набір інструментів, вона починає вибирати, що робити.
Відповісти чи ні.
Зробити одну дію чи кілька.
Спочатку проаналізувати, потім згенерувати результат, потім використати інструмент і лише після цього повернутися до користувача.
Це вже інший рівень архітектури.
Не просто функція за інструкцією, а виконавець з обмеженою автономією.
І саме в цьому прихована причина, чому агенти зараз викликають так багато шуму.
Вони ближчі до цифрового працівника, ніж до чат-бота. Не тому, що «краще думають», а тому що вони вбудовані у контур дії.
Але разом із цим приходить і важлива реальність.
Агентність — це не магія.
Це завжди компроміс між свободою і контролем.
Чим більше свободи ми даємо системі, тим важливішими стають обмеження: правила доступу до інструментів, перевірка небезпечних дій, прозорість того, що саме система робить під капотом.
Інакше замість помічника можна отримати не цифрового співробітника, а дуже красиву проблему з API-ключем.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍21
У попередньому дописі я писав про те, що справжня різниця між чат-ботом і агентом проходить не по рівню «розумності» моделі, а по здатності діяти всередині задачі. Але щойно ми переходимо від коротких взаємодій до довгих і складних процесів, дуже швидко проявляється інше обмеження: головна проблема сучасних агентів — не стільки інтелект, скільки пам’ять.
Поки всі сперечаються про те, яка модель «розумніша», реальна інженерна проблема виглядає значно простіше: агент не може надто довго утримувати в контексті складну задачу. Його контекстне вікно обмежене, а це означає, що будь-яка довга робота рано чи пізно впирається у стелю.
На коротких сесіях це майже непомітно. Агент пам’ятає останні повідомлення, розуміє поточну ціль і може виконати ланцюжок дій. Але щойно проєкт стає довшим, починається поступова деградація. Щось доводиться обрізати, щось стискати, а щось просто втрачається по дорозі.
Саме тут з’являється сумаризація. На перший погляд, вона виглядає як рішення: модель стискає попередню історію, залишає головне — і робота триває далі. Але насправді це не усунення проблеми, а лише спосіб тимчасово її обійти.
Мені здається, багато хто вже помічав це навіть у звичайній роботі з ChatGPT. Коли довго працюєш в одному чаті, з часом відповіді часто стають гіршими: модель починає губити деталі, плутати акценти або відповідати менш точно, ніж на початку. У таких випадках я іноді прошу дати короткий контекст і головні тези з чату, щоб використати їх як основу для нового, а потім просто продовжую роботу вже там.
По суті, це і є сумаризація в її практичному вигляді. Але проблема в тому, що історія задачі після такого переходу зберігається вже не повністю, а як переказ, створений самою моделлю. А отже, з контексту можуть зникнути саме ті деталі, які пізніше виявляться критично важливими.
У результаті довга задача починає поступово розмиватися. І в якийсь момент замість точного задуму в агента залишається лише спрощена версія початкової цілі. Саме тому сьогодні не варто надто романтизувати великі агентні проєкти: агент може виглядати впевнено, писати код, запускати команди й виправляти помилки, але при цьому повільно втрачати зв’язок із тим, що саме він повинен робити.
І чим складнішою стає робота, тим менш переконливо виглядає ідея просто запхати все в один контекст і сподіватися, що одна модель «витягне». Саме звідси виростає одна з найсильніших архітектурних ідей сучасних агентних систем — субагенти.
Принцип тут досить простий: замість одного перевантаженого виконавця з’являється кілька спеціалізованих. Один відповідає за backend, інший — за frontend, третій — за деплой, четвертий — за тестування. У кожного з них своя роль, свій контекст і свій набір інструментів.
Головний агент уже не намагається робити все сам. Його задача — координувати роботу, розподіляти підзадачі й збирати фінальний результат. Це дуже схоже на нормальну командну розробку: тімлід не повинен пам’ятати кожен рядок коду, його задача — тримати загальну ціль і зводити окремі частини в цілісну систему.
Саме так агентні системи починають масштабуватися. І тут важливо, що субагенти — це не просто спосіб пришвидшити роботу. Це ще й спосіб розподілити пам’ять: деталі backend залишаються в одному контексті, деталі frontend — в іншому, а керівний рівень не тоне в усьому технічному шумі одразу.
Наступний крок виглядає ще цікавіше: динамічні команди агентів. Тобто ситуація, коли ролі не задаються людиною вручну, а система сама визначає, які саме виконавці їй потрібні під конкретну задачу.
Фактично це вже схоже на нову операційну модель роботи зі знанням: не один універсальний «супермозок», а координована мережа вузькоспеціалізованих інтелектів. І цілком можливо, що саме так виглядатимуть робочі процеси найближчих років: не один AI-помічник на всі випадки життя, а маленька цифрова команда, у якій кожен тримає свій шмат контексту.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Поки всі сперечаються про те, яка модель «розумніша», реальна інженерна проблема виглядає значно простіше: агент не може надто довго утримувати в контексті складну задачу. Його контекстне вікно обмежене, а це означає, що будь-яка довга робота рано чи пізно впирається у стелю.
На коротких сесіях це майже непомітно. Агент пам’ятає останні повідомлення, розуміє поточну ціль і може виконати ланцюжок дій. Але щойно проєкт стає довшим, починається поступова деградація. Щось доводиться обрізати, щось стискати, а щось просто втрачається по дорозі.
Саме тут з’являється сумаризація. На перший погляд, вона виглядає як рішення: модель стискає попередню історію, залишає головне — і робота триває далі. Але насправді це не усунення проблеми, а лише спосіб тимчасово її обійти.
Мені здається, багато хто вже помічав це навіть у звичайній роботі з ChatGPT. Коли довго працюєш в одному чаті, з часом відповіді часто стають гіршими: модель починає губити деталі, плутати акценти або відповідати менш точно, ніж на початку. У таких випадках я іноді прошу дати короткий контекст і головні тези з чату, щоб використати їх як основу для нового, а потім просто продовжую роботу вже там.
По суті, це і є сумаризація в її практичному вигляді. Але проблема в тому, що історія задачі після такого переходу зберігається вже не повністю, а як переказ, створений самою моделлю. А отже, з контексту можуть зникнути саме ті деталі, які пізніше виявляться критично важливими.
У результаті довга задача починає поступово розмиватися. І в якийсь момент замість точного задуму в агента залишається лише спрощена версія початкової цілі. Саме тому сьогодні не варто надто романтизувати великі агентні проєкти: агент може виглядати впевнено, писати код, запускати команди й виправляти помилки, але при цьому повільно втрачати зв’язок із тим, що саме він повинен робити.
І чим складнішою стає робота, тим менш переконливо виглядає ідея просто запхати все в один контекст і сподіватися, що одна модель «витягне». Саме звідси виростає одна з найсильніших архітектурних ідей сучасних агентних систем — субагенти.
Принцип тут досить простий: замість одного перевантаженого виконавця з’являється кілька спеціалізованих. Один відповідає за backend, інший — за frontend, третій — за деплой, четвертий — за тестування. У кожного з них своя роль, свій контекст і свій набір інструментів.
Головний агент уже не намагається робити все сам. Його задача — координувати роботу, розподіляти підзадачі й збирати фінальний результат. Це дуже схоже на нормальну командну розробку: тімлід не повинен пам’ятати кожен рядок коду, його задача — тримати загальну ціль і зводити окремі частини в цілісну систему.
Саме так агентні системи починають масштабуватися. І тут важливо, що субагенти — це не просто спосіб пришвидшити роботу. Це ще й спосіб розподілити пам’ять: деталі backend залишаються в одному контексті, деталі frontend — в іншому, а керівний рівень не тоне в усьому технічному шумі одразу.
Наступний крок виглядає ще цікавіше: динамічні команди агентів. Тобто ситуація, коли ролі не задаються людиною вручну, а система сама визначає, які саме виконавці їй потрібні під конкретну задачу.
Фактично це вже схоже на нову операційну модель роботи зі знанням: не один універсальний «супермозок», а координована мережа вузькоспеціалізованих інтелектів. І цілком можливо, що саме так виглядатимуть робочі процеси найближчих років: не один AI-помічник на всі випадки життя, а маленька цифрова команда, у якій кожен тримає свій шмат контексту.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍12
У попередньому дописі мова йшла про те, що агентні системи починають масштабуватися тоді, коли пам’ять і контекст перестають бути звалені в один перевантажений потік. Але далі виникає ще цікавіше питання: що відбувається, коли агент повинен пам’ятати не лише поточну задачу, а й вас самих, ваш стиль роботи, ваш проєкт і вже прийняті рішення?
Саме тут проходить ще одна важлива межа. Є агент, який добре працює в межах однієї сесії. А є агент, який здатен накопичувати знання про взаємодію з вами в часі. Перший залишається зручним інструментом. Другий поступово перетворюється на систему, з якою можна вибудовувати довгострокову співпрацю.
І в цьому сенсі пам’ять агента — це вже не просто технічна функція, а майже новий рівень продукту. Тому що пам’ять тут означає не «збережемо весь чат». Звичайна історія розмови погано підходить на роль справжньої пам’яті: вона занадто шумна, занадто довга і майже не відділяє важливе від випадкового.
Щоб агент справді міг щось пам’ятати, потрібні інші механізми. Memory bank, RAG, графи зв’язків між фактами, пошук релевантного минулого під конкретний запит, часові пріоритети, оновлення й перевизначення старих знань. Інакше система просто зберігатиме сліди розмови, але не формуватиме з них корисного знання.
Це важливий зсув у самій логіці взаємодії. Пам’ять агента перестає бути стенограмою діалогу і починає ставати базою знань про користувача, проєкт, обмеження, звички, правила та вже прийняті рішення. Тобто мова йде не лише про те, що було сказано, а про те, що справді варто зберегти як частину робочого контексту.
Саме це і перетворює разові взаємодії на накопичувальний процес. Агент починає пам’ятати, як вас звати, які у вас пріоритети, як влаштований ваш проєкт, які параметри не можна порушувати, якими інструментами краще користуватися і яких дій краще уникати. І що важливо — усе це вже не виглядає як набір випадкових згадок. Це починає працювати як операційна пам’ять довгої співпраці.
З інженерної точки зору така система вже майже не схожа на звичайний чат. Радше йдеться про персональне операційне середовище, у якому LLM є лише одним із компонентів. А навколо неї поступово вибудовуються шари пам’яті, витягування, ранжування, оновлення фактів і зв’язків між ними.
Звідси випливає і, можливо, головний висновок. Сила майбутніх агентів визначатиметься не лише якістю самої моделі. Не менш важливим буде те, наскільки добре влаштована їхня пам’ять. Не тільки те, наскільки добре система відповідає, а й те, наскільки добре вона здатна утримувати знання про вас і вашу роботу в часі.
І цілком можливо, що в довгій перспективі перемагатимуть не просто най«розумніші» агенти, а найконтекстно стійкіші. Ті, що не лише добре мислять у моменті, а й здатні накопичувати, оновлювати і правильно повертати знання тоді, коли вони справді потрібні.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Саме тут проходить ще одна важлива межа. Є агент, який добре працює в межах однієї сесії. А є агент, який здатен накопичувати знання про взаємодію з вами в часі. Перший залишається зручним інструментом. Другий поступово перетворюється на систему, з якою можна вибудовувати довгострокову співпрацю.
І в цьому сенсі пам’ять агента — це вже не просто технічна функція, а майже новий рівень продукту. Тому що пам’ять тут означає не «збережемо весь чат». Звичайна історія розмови погано підходить на роль справжньої пам’яті: вона занадто шумна, занадто довга і майже не відділяє важливе від випадкового.
Щоб агент справді міг щось пам’ятати, потрібні інші механізми. Memory bank, RAG, графи зв’язків між фактами, пошук релевантного минулого під конкретний запит, часові пріоритети, оновлення й перевизначення старих знань. Інакше система просто зберігатиме сліди розмови, але не формуватиме з них корисного знання.
Це важливий зсув у самій логіці взаємодії. Пам’ять агента перестає бути стенограмою діалогу і починає ставати базою знань про користувача, проєкт, обмеження, звички, правила та вже прийняті рішення. Тобто мова йде не лише про те, що було сказано, а про те, що справді варто зберегти як частину робочого контексту.
Саме це і перетворює разові взаємодії на накопичувальний процес. Агент починає пам’ятати, як вас звати, які у вас пріоритети, як влаштований ваш проєкт, які параметри не можна порушувати, якими інструментами краще користуватися і яких дій краще уникати. І що важливо — усе це вже не виглядає як набір випадкових згадок. Це починає працювати як операційна пам’ять довгої співпраці.
З інженерної точки зору така система вже майже не схожа на звичайний чат. Радше йдеться про персональне операційне середовище, у якому LLM є лише одним із компонентів. А навколо неї поступово вибудовуються шари пам’яті, витягування, ранжування, оновлення фактів і зв’язків між ними.
Звідси випливає і, можливо, головний висновок. Сила майбутніх агентів визначатиметься не лише якістю самої моделі. Не менш важливим буде те, наскільки добре влаштована їхня пам’ять. Не тільки те, наскільки добре система відповідає, а й те, наскільки добре вона здатна утримувати знання про вас і вашу роботу в часі.
І цілком можливо, що в довгій перспективі перемагатимуть не просто най«розумніші» агенти, а найконтекстно стійкіші. Ті, що не лише добре мислять у моменті, а й здатні накопичувати, оновлювати і правильно повертати знання тоді, коли вони справді потрібні.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍14
Продовжуючи тему.
Як тільки ми починаємо говорити про агентів не як про разовий інструмент, а як про систему, що накопичує знання, пам’ятає контекст і супроводжує роботу в часі, майже одразу постає ще одне важливе питання: наскільки всім цим узагалі можна керувати?
І саме тут починається інший бік агентної теми. Головна проблема вже не в тому, що агенти вміють занадто мало. Проблема все частіше в тому, що ними починають користуватися без нормальної керованості.
Автономний агент без спостережуваності — майже завжди погана ідея. Якщо ви не бачите, які інструменти він викликав, скільки ресурсів витратив, де саме почав втрачати контекст, на якому кроці помилився і чому ухвалив те чи інше рішення, то у вас не стільки система, скільки чорний ящик із красивою demo-обгорткою.
А далі з’являються вже цілком реальні ризики. Неконтрольовані витрати. Випадкові небезпечні дії. Фальшиве відчуття, ніби результату можна довіряти просто тому, що система звучить упевнено. Prompt injection із зовнішніх джерел. Поступове розростання доступів. І, мабуть, найнеприємніше — відчуття, що все працює нормально рівно до того моменту, поки система не помиляється в по-справжньому важливій точці.
Саме тому зрілість агентної епохи, швидше за все, вимірюватиметься не кількістю «магії», а кількістю дисципліни. Лімітами. Розділенням ролей. Вузькими доступами. Approval для небезпечних дій. Логами. Дашбордами. Структурованою пам’яттю. Перевіркою результату. Можливістю відкату.
Майбутнє, ймовірно, справді за агентами. Але не за такими, які «самі все зроблять», а за такими, якими вміють грамотно керувати.
І в цьому сенсі переможе не той, хто першим під’єднає собі десять AI-інструментів. Переможе той, хто навчиться будувати з них керовану систему праці.
Тому що новий навик епохи — це вже не просто вміння користуватися AI. Новий навик — бути менеджером цифрових виконавців.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Як тільки ми починаємо говорити про агентів не як про разовий інструмент, а як про систему, що накопичує знання, пам’ятає контекст і супроводжує роботу в часі, майже одразу постає ще одне важливе питання: наскільки всім цим узагалі можна керувати?
І саме тут починається інший бік агентної теми. Головна проблема вже не в тому, що агенти вміють занадто мало. Проблема все частіше в тому, що ними починають користуватися без нормальної керованості.
Автономний агент без спостережуваності — майже завжди погана ідея. Якщо ви не бачите, які інструменти він викликав, скільки ресурсів витратив, де саме почав втрачати контекст, на якому кроці помилився і чому ухвалив те чи інше рішення, то у вас не стільки система, скільки чорний ящик із красивою demo-обгорткою.
А далі з’являються вже цілком реальні ризики. Неконтрольовані витрати. Випадкові небезпечні дії. Фальшиве відчуття, ніби результату можна довіряти просто тому, що система звучить упевнено. Prompt injection із зовнішніх джерел. Поступове розростання доступів. І, мабуть, найнеприємніше — відчуття, що все працює нормально рівно до того моменту, поки система не помиляється в по-справжньому важливій точці.
Саме тому зрілість агентної епохи, швидше за все, вимірюватиметься не кількістю «магії», а кількістю дисципліни. Лімітами. Розділенням ролей. Вузькими доступами. Approval для небезпечних дій. Логами. Дашбордами. Структурованою пам’яттю. Перевіркою результату. Можливістю відкату.
Майбутнє, ймовірно, справді за агентами. Але не за такими, які «самі все зроблять», а за такими, якими вміють грамотно керувати.
І в цьому сенсі переможе не той, хто першим під’єднає собі десять AI-інструментів. Переможе той, хто навчиться будувати з них керовану систему праці.
Тому що новий навик епохи — це вже не просто вміння користуватися AI. Новий навик — бути менеджером цифрових виконавців.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍19
Якщо подивитися на всю цю розмову про агентів трохи з відстані, виникає цікава історична аналогія.
Колись комп’ютери теж починалися дуже просто. З’являлися окремі програми. Одна програма виконувала свою задачу, потім інша. Кожна жила майже у власному світі.
Але чим більше програм ставало, тим сильніше починали проявлятися проблеми. Як їх запускати? Як вони отримують доступ до файлів? Як вони взаємодіють між собою? Як керувати ресурсами? Як не допустити, щоб одна програма випадково зламала іншу?
У якийсь момент стало зрозуміло, що самих програм уже недостатньо. Потрібен окремий рівень управління.
Так з’явилися операційні системи.
Операційна система не вирішує конкретну задачу користувача. Вона керує середовищем, у якому працюють усі інші програми: запуск, доступи, ресурси, взаємодія, стандарти.
І якщо подивитися на те, що відбувається з агентами сьогодні, паралель виглядає досить знайомою.
З’являються все нові агенти. Один пише код. Інший шукає інформацію. Третій керує інструментами. Четвертий аналізує дані.
Але разом із цим виникають ті самі питання.
Хто керує їхніми доступами?
Хто обмежує ресурси?
Хто вирішує, коли і який агент запускається?
Хто перевіряє результат?
Хто координує їхню взаємодію?
Фактично ми поступово приходимо до потреби в новому рівні системи.
Не просто агентів.
А операційного середовища для агентів.
Можливо, у найближчі роки з’явиться те, що умовно можна назвати Agent OS — система, яка керує агентами так само, як операційна система керує програмами.
Вона буде відповідати за пам’ять, доступи, ресурси, логування, запуск задач, взаємодію між агентами і контроль результатів.
І цілком можливо, що такі системи будуть навіть спеціалізуватися по доменах. Окремі «операційні системи» для програмування. Для досліджень. Для бізнес-процесів. Для аналітики.
Якщо ця аналогія правильна, то ми зараз живемо в епосі до появи операційних систем для агентів.
Програм уже багато.
Але сама інфраструктура їхнього управління тільки починає формуватися.
І, можливо, наступний великий етап розвитку AI буде пов’язаний не з новими моделями, а з появою операційних систем для агентів.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Колись комп’ютери теж починалися дуже просто. З’являлися окремі програми. Одна програма виконувала свою задачу, потім інша. Кожна жила майже у власному світі.
Але чим більше програм ставало, тим сильніше починали проявлятися проблеми. Як їх запускати? Як вони отримують доступ до файлів? Як вони взаємодіють між собою? Як керувати ресурсами? Як не допустити, щоб одна програма випадково зламала іншу?
У якийсь момент стало зрозуміло, що самих програм уже недостатньо. Потрібен окремий рівень управління.
Так з’явилися операційні системи.
Операційна система не вирішує конкретну задачу користувача. Вона керує середовищем, у якому працюють усі інші програми: запуск, доступи, ресурси, взаємодія, стандарти.
І якщо подивитися на те, що відбувається з агентами сьогодні, паралель виглядає досить знайомою.
З’являються все нові агенти. Один пише код. Інший шукає інформацію. Третій керує інструментами. Четвертий аналізує дані.
Але разом із цим виникають ті самі питання.
Хто керує їхніми доступами?
Хто обмежує ресурси?
Хто вирішує, коли і який агент запускається?
Хто перевіряє результат?
Хто координує їхню взаємодію?
Фактично ми поступово приходимо до потреби в новому рівні системи.
Не просто агентів.
А операційного середовища для агентів.
Можливо, у найближчі роки з’явиться те, що умовно можна назвати Agent OS — система, яка керує агентами так само, як операційна система керує програмами.
Вона буде відповідати за пам’ять, доступи, ресурси, логування, запуск задач, взаємодію між агентами і контроль результатів.
І цілком можливо, що такі системи будуть навіть спеціалізуватися по доменах. Окремі «операційні системи» для програмування. Для досліджень. Для бізнес-процесів. Для аналітики.
Якщо ця аналогія правильна, то ми зараз живемо в епосі до появи операційних систем для агентів.
Програм уже багато.
Але сама інфраструктура їхнього управління тільки починає формуватися.
І, можливо, наступний великий етап розвитку AI буде пов’язаний не з новими моделями, а з появою операційних систем для агентів.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍14🔥7
Вітаю всіх з новим тижнем!
Бажаю, щоб він був спокійним, продуктивним і трохи наблизив кожного з нас до тих цілей, які ми для себе поставили.
На вихідних трохи подивився, що вже відомо про GPT-5.4. Тому коротко зберу тут головне — без потреби відкривати десятки сайтів і збирати інформацію по шматках.
Але цікаве тут, як на мене, не лише в самому релізі. Є спокуса дивитися на кожну нову велику модель як на ще один доказ чийогось лідерства. У реальності все складніше. Особливо зараз, коли нові версії виходять майже без паузи, і вже не завжди зрозуміло, де справді новий рівень, а де просто ще одна швидка ітерація.
OpenAI випустила GPT-5.4 у двох варіантах — Thinking і Pro.
Якщо коротко, Thinking — це основна версія моделі. Саме вона доступна в звичайній підписці ChatGPT Plus за $20. А Pro — потужніший варіант із більш агресивними режимами reasoning, розрахований на складніші задачі. Він доступний у дорожчих тарифах і через API, де його використання вже коштує значно більше.
При цьому попередня модель, GPT-5.3 Instant, теж нікуди не зникає. Вона залишається швидшим і дешевшим варіантом для простіших задач, де максимальна “глибина мислення” просто не потрібна.
До того ж у новій лінійці з’являються більш явні режими reasoning — від простішого до максимально глибокого, що ще більше розводить моделі за сценаріями використання.
З опису видно інше: модель дедалі більше заточують не під красиву відповідь, а під реальну роботу. Під використання інструментів, взаємодію з комп’ютером, довші ланцюги дій і задачі, які треба не просто зрозуміти, а довести до результату.
І це, можливо, важливіше за самі бенчмарки.
Так, у тестах GPT-5.4 виглядає сильно, особливо в coding та agentic-задачах. Але самі по собі бенчмарки не дають головної відповіді. Вони показують, як модель поводиться в контрольованих умовах. Але не до кінця показують, чи можна на неї спертися в реальній роботі, де є контекст, неоднозначність і ціна помилки.
Є й інша сторона цієї історії — вартість.
OpenAI подає GPT-5.4 як ефективнішу модель. Але якщо дивитися на практичне використання, все не так просто. Якщо дуже спрощено, вхідні токени — це все, що ви даєте моделі: ваш запит, інструкції, контекст, документи. Вихідні — це те, що модель генерує у відповідь. І саме вихід у таких моделей коштує найдорожче.
У GPT-5.4 базова версія в API коштує $2.50 за мільйон вхідних токенів і $15 за мільйон вихідних. А GPT-5.4 Pro — уже $30 за вхід і $180 за вихід. Тобто мова йде не просто про сильну модель, а про інструмент із дуже дорогим використанням, якщо запускати його на серйозних робочих задачах.
І це швидко змінює сам спосіб розмови про модель. Уже недостатньо сказати, що вона “краща”. Потрібно ще відповісти на інше питання: у яких задачах ця якість справді окупається.
Мені здається, саме тут і проходить реальна межа між ефектною демонстрацією та корисним інструментом.
Сьогодні моделі все менше змагаються в абстрактному “хто розумніший”. Набагато важливіше інше: хто здатен взяти на себе довгу, складну і дорогу для людини роботу так, щоб це було не тільки вражаюче, а й виправдано на практиці.
Тому мій висновок поки такий: GPT-5.4 виглядає не стільки як “ще одна сильніша модель”, скільки як спроба OpenAI змістити фокус у бік реальної робочої корисності. Саме тому тут так багато уваги до інструментів, computer use, reasoning і довгих сценаріїв роботи.
Але остаточну відповідь на головне питання цей реліз поки не дає. Ми бачимо, що OpenAI серйозно посилилась у напрямку coding і agentic-задач. Але чи означає це, що саме її модель сьогодні найкраще підходить для реальної роботи, залежить уже не тільки від бенчмарків. Це залежить від ціни, стабільності, якості в довгих процесах і того, скільки людського контролю вона все ще потребує.
Тому, мабуть, найчесніший висновок зараз такий: GPT-5.4 — це сильний і важливий реліз, який добре показує, куди взагалі рухається ринок. Але справжній лідер визначатиметься не таблицями, а тим, яка модель виявиться найкориснішою в живій роботі.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Бажаю, щоб він був спокійним, продуктивним і трохи наблизив кожного з нас до тих цілей, які ми для себе поставили.
На вихідних трохи подивився, що вже відомо про GPT-5.4. Тому коротко зберу тут головне — без потреби відкривати десятки сайтів і збирати інформацію по шматках.
Але цікаве тут, як на мене, не лише в самому релізі. Є спокуса дивитися на кожну нову велику модель як на ще один доказ чийогось лідерства. У реальності все складніше. Особливо зараз, коли нові версії виходять майже без паузи, і вже не завжди зрозуміло, де справді новий рівень, а де просто ще одна швидка ітерація.
OpenAI випустила GPT-5.4 у двох варіантах — Thinking і Pro.
Якщо коротко, Thinking — це основна версія моделі. Саме вона доступна в звичайній підписці ChatGPT Plus за $20. А Pro — потужніший варіант із більш агресивними режимами reasoning, розрахований на складніші задачі. Він доступний у дорожчих тарифах і через API, де його використання вже коштує значно більше.
При цьому попередня модель, GPT-5.3 Instant, теж нікуди не зникає. Вона залишається швидшим і дешевшим варіантом для простіших задач, де максимальна “глибина мислення” просто не потрібна.
До того ж у новій лінійці з’являються більш явні режими reasoning — від простішого до максимально глибокого, що ще більше розводить моделі за сценаріями використання.
З опису видно інше: модель дедалі більше заточують не під красиву відповідь, а під реальну роботу. Під використання інструментів, взаємодію з комп’ютером, довші ланцюги дій і задачі, які треба не просто зрозуміти, а довести до результату.
І це, можливо, важливіше за самі бенчмарки.
Так, у тестах GPT-5.4 виглядає сильно, особливо в coding та agentic-задачах. Але самі по собі бенчмарки не дають головної відповіді. Вони показують, як модель поводиться в контрольованих умовах. Але не до кінця показують, чи можна на неї спертися в реальній роботі, де є контекст, неоднозначність і ціна помилки.
Є й інша сторона цієї історії — вартість.
OpenAI подає GPT-5.4 як ефективнішу модель. Але якщо дивитися на практичне використання, все не так просто. Якщо дуже спрощено, вхідні токени — це все, що ви даєте моделі: ваш запит, інструкції, контекст, документи. Вихідні — це те, що модель генерує у відповідь. І саме вихід у таких моделей коштує найдорожче.
У GPT-5.4 базова версія в API коштує $2.50 за мільйон вхідних токенів і $15 за мільйон вихідних. А GPT-5.4 Pro — уже $30 за вхід і $180 за вихід. Тобто мова йде не просто про сильну модель, а про інструмент із дуже дорогим використанням, якщо запускати його на серйозних робочих задачах.
І це швидко змінює сам спосіб розмови про модель. Уже недостатньо сказати, що вона “краща”. Потрібно ще відповісти на інше питання: у яких задачах ця якість справді окупається.
Мені здається, саме тут і проходить реальна межа між ефектною демонстрацією та корисним інструментом.
Сьогодні моделі все менше змагаються в абстрактному “хто розумніший”. Набагато важливіше інше: хто здатен взяти на себе довгу, складну і дорогу для людини роботу так, щоб це було не тільки вражаюче, а й виправдано на практиці.
Тому мій висновок поки такий: GPT-5.4 виглядає не стільки як “ще одна сильніша модель”, скільки як спроба OpenAI змістити фокус у бік реальної робочої корисності. Саме тому тут так багато уваги до інструментів, computer use, reasoning і довгих сценаріїв роботи.
Але остаточну відповідь на головне питання цей реліз поки не дає. Ми бачимо, що OpenAI серйозно посилилась у напрямку coding і agentic-задач. Але чи означає це, що саме її модель сьогодні найкраще підходить для реальної роботи, залежить уже не тільки від бенчмарків. Це залежить від ціни, стабільності, якості в довгих процесах і того, скільки людського контролю вона все ще потребує.
Тому, мабуть, найчесніший висновок зараз такий: GPT-5.4 — це сильний і важливий реліз, який добре показує, куди взагалі рухається ринок. Але справжній лідер визначатиметься не таблицями, а тим, яка модель виявиться найкориснішою в живій роботі.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍11
Минулого тижня склав сертифікацію Databricks Certified Generative AI Engineer Associate.
Це не той випадок, коли йдеться просто про формальний сертифікат чи черговий онлайн-курс. Такі сертифікації проходять за доволі жорсткими правилами і, як правило, вимагають окремої підготовки. Тобто тут важливий не лише сам факт складання, а й те, що подібний іспит досить уважно відбирає, які саме знання та практичні сценарії вважаються справді значущими.
І саме тому мені здалося цікавим подивитися на інше питання: що саме перевіряє така сертифікація. Бо її зміст часто непогано показує, які навички індустрія вже починає сприймати як по-справжньому актуальні.
І якщо сформулювати коротко, то враження таке: цей іспит уже майже не про самі моделі. Він радше про системи навколо LLM. Можливо, саме в цьому і полягає один із головних зсувів останніх років.
1. Майже всюди — RAG
Якщо задача пов’язана з документами, PDF, внутрішньою базою знань або support-ботами, правильна логіка мислення дуже часто виглядає приблизно так: chunking → embeddings → vector search → retrieval → augmented prompt → LLM.
Тобто модель дедалі рідше працює сама по собі. Вона все частіше є фінальним етапом retrieval-системи, де ключову роль відіграє не лише генерація, а й те, наскільки добре система знаходить і передає контекст.
2. Проблема часто не в LLM
Ще один характерний мотив: якщо система відповідає погано, правильний крок не завжди полягає в заміні моделі. Проблема часто виникає раніше — у retrieval, chunking, metadata filtering, якості контексту, guardrails або форматі виходу.
Тому практичний висновок доволі простий: якщо RAG працює погано, спочатку варто перевірити retrieved context, а не одразу шукати нову LLM.
3. Для extraction-задач не завжди потрібна “агентність”
Якщо від моделі очікується не роздум, а досить конкретний і формалізований результат — наприклад, витягнути поля, віднести текст до класу або повернути коректний JSON, — то складні агентні пайплайни часто не дають помітної переваги.
Натомість краще працює більш контрольований підхід: чіткий шаблон запиту, few-shot приклади й наперед визначена схема відповіді.
У таких сценаріях важливішою часто виявляється не “агентність”, а стабільність і керованість результату.
4. Guardrails — не додаток, а частина системи
Окремий блок питань стосувався harmful inputs, off-topic запитів, витоку конфіденційних даних і unsafe outputs. І логіка тут зазвичай така: detect → block / refuse / redirect, а не «модель сама розбереться».
Тобто safety подається не як опція, а як частина архітектури.
5. GenAI — це вже інфраструктура
Оскільки йдеться про Databricks, іспит помітно зміщений у бік production-мислення: Provisioned Throughput для великих batch-навантажень, pay-per-token для нижчого трафіку, Vector Search + managed embeddings для RAG, MLflow + Unity Catalog + Model Serving для деплою, inference tables для моніторингу.
Тобто перевіряється не лише розуміння моделей, а й уміння зібрати навколо них керовану production-систему.
6. Що зараз справді виглядає актуальним
Якщо звести все до кількох напрямів, то ключовими темами виглядають RAG architecture, chunking strategies, embeddings і vector search, guardrails і safety, structured extraction, evaluation, deployment і monitoring.
І, мабуть, головний висновок тут у тому, що іспит із Generative AI сьогодні — це вже не стільки про питання «що вміє модель?», скільки про інше: «як правильно побудувати систему навколо моделі?»
Є відчуття, що саме тут поступово формується нова інженерна дисципліна — LLM systems engineering як більш тверезий опис того, куди насправді зміщується центр ваги в сучасному AI.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
Це не той випадок, коли йдеться просто про формальний сертифікат чи черговий онлайн-курс. Такі сертифікації проходять за доволі жорсткими правилами і, як правило, вимагають окремої підготовки. Тобто тут важливий не лише сам факт складання, а й те, що подібний іспит досить уважно відбирає, які саме знання та практичні сценарії вважаються справді значущими.
І саме тому мені здалося цікавим подивитися на інше питання: що саме перевіряє така сертифікація. Бо її зміст часто непогано показує, які навички індустрія вже починає сприймати як по-справжньому актуальні.
І якщо сформулювати коротко, то враження таке: цей іспит уже майже не про самі моделі. Він радше про системи навколо LLM. Можливо, саме в цьому і полягає один із головних зсувів останніх років.
1. Майже всюди — RAG
Якщо задача пов’язана з документами, PDF, внутрішньою базою знань або support-ботами, правильна логіка мислення дуже часто виглядає приблизно так: chunking → embeddings → vector search → retrieval → augmented prompt → LLM.
Тобто модель дедалі рідше працює сама по собі. Вона все частіше є фінальним етапом retrieval-системи, де ключову роль відіграє не лише генерація, а й те, наскільки добре система знаходить і передає контекст.
2. Проблема часто не в LLM
Ще один характерний мотив: якщо система відповідає погано, правильний крок не завжди полягає в заміні моделі. Проблема часто виникає раніше — у retrieval, chunking, metadata filtering, якості контексту, guardrails або форматі виходу.
Тому практичний висновок доволі простий: якщо RAG працює погано, спочатку варто перевірити retrieved context, а не одразу шукати нову LLM.
3. Для extraction-задач не завжди потрібна “агентність”
Якщо від моделі очікується не роздум, а досить конкретний і формалізований результат — наприклад, витягнути поля, віднести текст до класу або повернути коректний JSON, — то складні агентні пайплайни часто не дають помітної переваги.
Натомість краще працює більш контрольований підхід: чіткий шаблон запиту, few-shot приклади й наперед визначена схема відповіді.
У таких сценаріях важливішою часто виявляється не “агентність”, а стабільність і керованість результату.
4. Guardrails — не додаток, а частина системи
Окремий блок питань стосувався harmful inputs, off-topic запитів, витоку конфіденційних даних і unsafe outputs. І логіка тут зазвичай така: detect → block / refuse / redirect, а не «модель сама розбереться».
Тобто safety подається не як опція, а як частина архітектури.
5. GenAI — це вже інфраструктура
Оскільки йдеться про Databricks, іспит помітно зміщений у бік production-мислення: Provisioned Throughput для великих batch-навантажень, pay-per-token для нижчого трафіку, Vector Search + managed embeddings для RAG, MLflow + Unity Catalog + Model Serving для деплою, inference tables для моніторингу.
Тобто перевіряється не лише розуміння моделей, а й уміння зібрати навколо них керовану production-систему.
6. Що зараз справді виглядає актуальним
Якщо звести все до кількох напрямів, то ключовими темами виглядають RAG architecture, chunking strategies, embeddings і vector search, guardrails і safety, structured extraction, evaluation, deployment і monitoring.
І, мабуть, головний висновок тут у тому, що іспит із Generative AI сьогодні — це вже не стільки про питання «що вміє модель?», скільки про інше: «як правильно побудувати систему навколо моделі?»
Є відчуття, що саме тут поступово формується нова інженерна дисципліна — LLM systems engineering як більш тверезий опис того, куди насправді зміщується центр ваги в сучасному AI.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍10👏4🎉2
Що відбувається, коли темпи будівництва дата-центрів починають випереджати можливості звичайної енергосистеми?
Пам’ятаєте, минулого року в мене вже було кілька постів навколо цієї теми. Спочатку — про те, як OpenAI разом з Oracle фактично заходять у будівництво гігантської обчислювальної інфраструктури. Потім — про Stargate, де до цієї історії підключилися SoftBank і Nvidia. А ще трохи пізніше — про досить показовий момент, коли на тлі всього цього OpenAI почала тиснути руку не лише Nvidia, а й AMD, плануючи закупівлі GPU на десятки мільярдів.
Тоді весь цей сюжет виглядав насамперед як історія про масштаб обчислень: більше чипів, більше дата-центрів, більше капіталу. Але зараз стає видно ще один, значно більш приземлений рівень цієї історії — енергетичний.
Останніми роками було досить поширене уявлення, що великі технологічні компанії зможуть розвивати AI-інфраструктуру, спираючись на хмарну модель, масштаб капіталу і поступове розширення доступу до відновлюваної енергетики.
Але на практиці цього вже недостатньо. У США дедалі більше дата-центрів плануються разом із приватними електростанціями, які працюють фактично в обхід звичної логіки підключення до мережі. За даними, на які посилається The Washington Post, ідеться про десятки таких проєктів, і більшість із них були оголошені саме у 2025 році.
Йдеться про електростанції, які живлять конкретного споживача напряму, хоча технічно залишаються пов’язаними із загальною мережею. Це дозволяє уникнути частини затримок і погоджень, які зазвичай супроводжують нові підключення.
Сам по собі цей факт уже багато про що говорить. Коли великі компанії починають будувати не лише дата-центри, а й окрему генерацію поруч із ними, це виглядає не як проста оптимізація, а як ознака структурного вузького місця. Причому вузького місця не локального, а системного.
Проєкти, про які йдеться, реалізуються у співпраці між техкомпаніями, енергетичними підрядниками та локальними постачальниками. І хоча назви компаній у документах не завжди афішуються прямо, з прикладів видно масштаб.
Meta будує в Огайо дві приватні газові електростанції загальною потужністю 400 мегават для дата-центру, який споживатиме близько 1 гігавата. Інший проєкт Meta у Техасі передбачає використання понад 800 невеликих газових генераторів, які мають дати 366 мегават для ще одного дата-центру на 1 гігават.
OpenAI разом з Oracle розвивають у Нью-Мексико проєкт Jupiter, який, як зазначено, також використовуватиме великі газові генератори для живлення дата-центру. Окремо згадується і проєкт у Вайомінгу, де дата-центр планують живити модифікованими реактивними двигунами.
У публічній розмові про AI акцент зазвичай стоїть на моделях, чипах, продуктивності, мільярдах параметрів. Але вся ця логіка впирається у значно більш приземлену річ — у фізичну інфраструктуру. В електрику, яку потрібно подати в конкретне місце, у конкретний час, у потрібному обсязі.
На цьому тлі зрозумілішими стають і довгострокові кроки великих компаній. Meta паралельно рухається в бік ядерної енергетики і розраховує на введення нових потужностей уже на початку 2030-х років. Компанія бере на себе зобов’язання як щодо нових реакторів, так і щодо купівлі енергії від старих. Alphabet, Amazon і Microsoft теж шукають окремі енергетичні контури — від ядерних домовленостей до масштабних закупівель відновлюваної енергії.
Тобто проблема не виглядає тимчасовою.
Швидше навпаки: є відчуття, що індустрія вже входить у фазу, де питання обчислень і питання генерації електроенергії більше не можна розглядати окремо.
Продовження — у наступному пості. Там уже про те, що це означає не лише для техіндустрії, а й для цін, енергетики та самої логіки AI-ринку.
✅ Якщо пост був корисним — став 👍
🔔 ПІДПИСАТИСЯ
Пам’ятаєте, минулого року в мене вже було кілька постів навколо цієї теми. Спочатку — про те, як OpenAI разом з Oracle фактично заходять у будівництво гігантської обчислювальної інфраструктури. Потім — про Stargate, де до цієї історії підключилися SoftBank і Nvidia. А ще трохи пізніше — про досить показовий момент, коли на тлі всього цього OpenAI почала тиснути руку не лише Nvidia, а й AMD, плануючи закупівлі GPU на десятки мільярдів.
Тоді весь цей сюжет виглядав насамперед як історія про масштаб обчислень: більше чипів, більше дата-центрів, більше капіталу. Але зараз стає видно ще один, значно більш приземлений рівень цієї історії — енергетичний.
Останніми роками було досить поширене уявлення, що великі технологічні компанії зможуть розвивати AI-інфраструктуру, спираючись на хмарну модель, масштаб капіталу і поступове розширення доступу до відновлюваної енергетики.
Але на практиці цього вже недостатньо. У США дедалі більше дата-центрів плануються разом із приватними електростанціями, які працюють фактично в обхід звичної логіки підключення до мережі. За даними, на які посилається The Washington Post, ідеться про десятки таких проєктів, і більшість із них були оголошені саме у 2025 році.
Йдеться про електростанції, які живлять конкретного споживача напряму, хоча технічно залишаються пов’язаними із загальною мережею. Це дозволяє уникнути частини затримок і погоджень, які зазвичай супроводжують нові підключення.
Сам по собі цей факт уже багато про що говорить. Коли великі компанії починають будувати не лише дата-центри, а й окрему генерацію поруч із ними, це виглядає не як проста оптимізація, а як ознака структурного вузького місця. Причому вузького місця не локального, а системного.
Проєкти, про які йдеться, реалізуються у співпраці між техкомпаніями, енергетичними підрядниками та локальними постачальниками. І хоча назви компаній у документах не завжди афішуються прямо, з прикладів видно масштаб.
Meta будує в Огайо дві приватні газові електростанції загальною потужністю 400 мегават для дата-центру, який споживатиме близько 1 гігавата. Інший проєкт Meta у Техасі передбачає використання понад 800 невеликих газових генераторів, які мають дати 366 мегават для ще одного дата-центру на 1 гігават.
OpenAI разом з Oracle розвивають у Нью-Мексико проєкт Jupiter, який, як зазначено, також використовуватиме великі газові генератори для живлення дата-центру. Окремо згадується і проєкт у Вайомінгу, де дата-центр планують живити модифікованими реактивними двигунами.
У публічній розмові про AI акцент зазвичай стоїть на моделях, чипах, продуктивності, мільярдах параметрів. Але вся ця логіка впирається у значно більш приземлену річ — у фізичну інфраструктуру. В електрику, яку потрібно подати в конкретне місце, у конкретний час, у потрібному обсязі.
На цьому тлі зрозумілішими стають і довгострокові кроки великих компаній. Meta паралельно рухається в бік ядерної енергетики і розраховує на введення нових потужностей уже на початку 2030-х років. Компанія бере на себе зобов’язання як щодо нових реакторів, так і щодо купівлі енергії від старих. Alphabet, Amazon і Microsoft теж шукають окремі енергетичні контури — від ядерних домовленостей до масштабних закупівель відновлюваної енергії.
Тобто проблема не виглядає тимчасовою.
Швидше навпаки: є відчуття, що індустрія вже входить у фазу, де питання обчислень і питання генерації електроенергії більше не можна розглядати окремо.
Продовження — у наступному пості. Там уже про те, що це означає не лише для техіндустрії, а й для цін, енергетики та самої логіки AI-ринку.
✅ Якщо пост був корисним — став 👍
🔔 ПІДПИСАТИСЯ
👍8
Але на цьому історія не закінчується. Бо питання тут уже не лише в тому, як забезпечити нові дата-центри електроенергією. Питання ще й у тому, що відбувається з енергетичною системою, ринком обладнання та логікою декарбонізації, коли AI починає масштабуватися такими темпами.
З одного боку, приватна генерація може частково зняти навантаження з мережі й зменшити тиск на загальну систему. Але з іншого — для неї теж потрібні турбіни, генератори, інженери, паливо, сервісні потужності. А отже, виникає новий попит, який сам по собі може штовхати ціни вгору.
У тексті згадується, що в 2025 році попит з боку AI сприяв зростанню цін на електроенергію темпами, більш ніж удвічі вищими за інфляцію. І тут немає простого висновку. Приватні електростанції можуть водночас і послаблювати навантаження на мережу, і створювати новий тиск на енергетичний ланцюг через дефіцит обладнання та спеціалістів.
Є й ще один шар цієї історії — екологічний.
Публічно великі компанії часто говорять про відновлювану енергію, ядерні проєкти, водень, довгострокову декарбонізацію. Але якщо дивитися на те, що реально встановлюється у 2025–2026 роках, картина значно менш ідеальна. За оцінкою Cleanview, майже все обладнання, яке фактично монтується в цей період, — газове.
І це, мабуть, один із найнеприємніших моментів.
Бо на рівні намірів індустрія декларує рух до вуглецевої нейтральності. Але на рівні практики, коли з’являється потреба будувати швидко, система обирає не найчистіше рішення, а те, яке можна розгорнути зараз.
У цьому сенсі історія з off-grid-енергетикою для AI-дата-центрів — не просто про електростанції біля серверів. Вона радше про межі швидкого масштабування. Про те, що навіть найсучасніші цифрові системи залишаються залежними від дуже матеріальних обмежень: енергії, інженерної інфраструктури, часу, доступності обладнання.
Ринок AI, поступово дорослішає. Стає важливим не лише те, наскільки переконливо технології виглядають у демо, а й те, як вони вбудовуються у світ, де ресурси не безмежні, а кожне прискорення має свою ціну.
Можливо, саме тут і проходить одна з головних меж між технологічним ажіотажем і справжньою індустріальною зрілістю. Не там, де система вміє ще більше, а там, де стає видно, чого насправді коштує її масштаб.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
З одного боку, приватна генерація може частково зняти навантаження з мережі й зменшити тиск на загальну систему. Але з іншого — для неї теж потрібні турбіни, генератори, інженери, паливо, сервісні потужності. А отже, виникає новий попит, який сам по собі може штовхати ціни вгору.
У тексті згадується, що в 2025 році попит з боку AI сприяв зростанню цін на електроенергію темпами, більш ніж удвічі вищими за інфляцію. І тут немає простого висновку. Приватні електростанції можуть водночас і послаблювати навантаження на мережу, і створювати новий тиск на енергетичний ланцюг через дефіцит обладнання та спеціалістів.
Є й ще один шар цієї історії — екологічний.
Публічно великі компанії часто говорять про відновлювану енергію, ядерні проєкти, водень, довгострокову декарбонізацію. Але якщо дивитися на те, що реально встановлюється у 2025–2026 роках, картина значно менш ідеальна. За оцінкою Cleanview, майже все обладнання, яке фактично монтується в цей період, — газове.
І це, мабуть, один із найнеприємніших моментів.
Бо на рівні намірів індустрія декларує рух до вуглецевої нейтральності. Але на рівні практики, коли з’являється потреба будувати швидко, система обирає не найчистіше рішення, а те, яке можна розгорнути зараз.
У цьому сенсі історія з off-grid-енергетикою для AI-дата-центрів — не просто про електростанції біля серверів. Вона радше про межі швидкого масштабування. Про те, що навіть найсучасніші цифрові системи залишаються залежними від дуже матеріальних обмежень: енергії, інженерної інфраструктури, часу, доступності обладнання.
Ринок AI, поступово дорослішає. Стає важливим не лише те, наскільки переконливо технології виглядають у демо, а й те, як вони вбудовуються у світ, де ресурси не безмежні, а кожне прискорення має свою ціну.
Можливо, саме тут і проходить одна з головних меж між технологічним ажіотажем і справжньою індустріальною зрілістю. Не там, де система вміє ще більше, а там, де стає видно, чого насправді коштує її масштаб.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
👍12
Що ви взагалі знаєте про image generation та visual encoders? 🙂
У сучасному image generation зазвичай говорять насамперед про генеративні моделі — і дуже часто саме про diffusion-підхід як один із ключових механізмів генерації. Як приклади тут можна згадати архітектури Stable Diffusion, Imagen або DALL·E.
Але поруч давно існує інший клас моделей — visual encoders. Вони не генерують зображення, а вчаться їх “розуміти”: витягувати змістовні представлення, які потім використовуються для класифікації, пошуку, сегментації та інших vision-задач. Тут як приклади можна згадати CLIP, DINOv2 і SigLIP.
І от саме на стику цих двох напрямів виникає цікаве питання: що робити з уже навченими visual encoders, які добре працюють із зображеннями, але спочатку не створювалися для генерації?
Якщо дивитися практично, генеративні моделі зазвичай доводиться вчити “бачити” майже з нуля. Вони поступово вчаться працювати зі структурою зображення під час тренування.
Але якщо великі pretrained visual encoders уже навчилися витягувати сильні, змістовні представлення зображень, то, можливо, це знання не потрібно будувати заново всередині генеративної моделі. Його можна спробувати використати повторно.
Саме про це нова наукова робота:
One Layer Is Enough: Adapting Pretrained Visual Encoders for Image Generation
На інтуїтивному рівні проблема виглядає так.
Є visual encoder, який уже добре витягує змістовні представлення зображення. Такі представлення корисні, бо вони містять структуру, семантику і вже навчене “розуміння” картинки.
Але те, що добре працює для аналізу зображення, не обов’язково так само добре працює для його генерації.
Тобто pretrained encoder не можна просто механічно “під’єднати” до генеративної моделі й очікувати, що все одразу запрацює. Між цими двома частинами системи виникає розрив: одна вміє добре аналізувати зображення, інша має з цього представлення щось згенерувати.
І тут автори з Apple пропонують досить конкретну відповідь на цю проблему.
Основна ідея роботи в тому, що для адаптації pretrained visual encoder до image generation не обов’язково будувати складну багатошарову надбудову. Автори показують, що достатньо дуже простого адаптера — фактично одного шару, який узгоджує представлення encoder-а з генеративною моделлю.
Це і є головний меседж роботи.
Не “ще одна велика архітектура”.
Не “ще складніший міст”.
Навпаки: мінімальна адаптація може бути достатньою, якщо вона стоїть у правильному місці.
І це цікаво не лише як технічний результат.
Бо в ML дуже часто є інерція мислення: якщо дві сильні системи погано стикуються, значить між ними треба поставити ще складніший модуль. Більше шарів, більше параметрів, більше спеціальної логіки.
Цінність цього paper-а не лише в конкретному рішенні для image generation. Він добре показує більш загальний принцип: не все, що потрібно з’єднати, потрібно з’єднувати складно.
Сучасна генерація зображень розвивається не лише через нові diffusion-моделі як такі. Вона розвивається ще й через спроби правильно використати вже наявне візуальне знання, яке було отримане в інших задачах.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
У сучасному image generation зазвичай говорять насамперед про генеративні моделі — і дуже часто саме про diffusion-підхід як один із ключових механізмів генерації. Як приклади тут можна згадати архітектури Stable Diffusion, Imagen або DALL·E.
Але поруч давно існує інший клас моделей — visual encoders. Вони не генерують зображення, а вчаться їх “розуміти”: витягувати змістовні представлення, які потім використовуються для класифікації, пошуку, сегментації та інших vision-задач. Тут як приклади можна згадати CLIP, DINOv2 і SigLIP.
І от саме на стику цих двох напрямів виникає цікаве питання: що робити з уже навченими visual encoders, які добре працюють із зображеннями, але спочатку не створювалися для генерації?
Якщо дивитися практично, генеративні моделі зазвичай доводиться вчити “бачити” майже з нуля. Вони поступово вчаться працювати зі структурою зображення під час тренування.
Але якщо великі pretrained visual encoders уже навчилися витягувати сильні, змістовні представлення зображень, то, можливо, це знання не потрібно будувати заново всередині генеративної моделі. Його можна спробувати використати повторно.
Саме про це нова наукова робота:
One Layer Is Enough: Adapting Pretrained Visual Encoders for Image Generation
На інтуїтивному рівні проблема виглядає так.
Є visual encoder, який уже добре витягує змістовні представлення зображення. Такі представлення корисні, бо вони містять структуру, семантику і вже навчене “розуміння” картинки.
Але те, що добре працює для аналізу зображення, не обов’язково так само добре працює для його генерації.
Тобто pretrained encoder не можна просто механічно “під’єднати” до генеративної моделі й очікувати, що все одразу запрацює. Між цими двома частинами системи виникає розрив: одна вміє добре аналізувати зображення, інша має з цього представлення щось згенерувати.
І тут автори з Apple пропонують досить конкретну відповідь на цю проблему.
Основна ідея роботи в тому, що для адаптації pretrained visual encoder до image generation не обов’язково будувати складну багатошарову надбудову. Автори показують, що достатньо дуже простого адаптера — фактично одного шару, який узгоджує представлення encoder-а з генеративною моделлю.
Це і є головний меседж роботи.
Не “ще одна велика архітектура”.
Не “ще складніший міст”.
Навпаки: мінімальна адаптація може бути достатньою, якщо вона стоїть у правильному місці.
І це цікаво не лише як технічний результат.
Бо в ML дуже часто є інерція мислення: якщо дві сильні системи погано стикуються, значить між ними треба поставити ще складніший модуль. Більше шарів, більше параметрів, більше спеціальної логіки.
Цінність цього paper-а не лише в конкретному рішенні для image generation. Він добре показує більш загальний принцип: не все, що потрібно з’єднати, потрібно з’єднувати складно.
Сучасна генерація зображень розвивається не лише через нові diffusion-моделі як такі. Вона розвивається ще й через спроби правильно використати вже наявне візуальне знання, яке було отримане в інших задачах.
✅ Якщо пост був корисним став 👍
🔔 ПІДПИСАТИСЯ
🔥7👍4🦄1
Якщо використовуєш тільки ChatGPT — ти використовуєш 20% того, що доступно.
Доброго понеділка 👋
На вихідних спілкувався зі знайомим підприємцем. Розумна людина, активно використовує AI в роботі. Але коли запитав який інструмент — виявилось, що тільки ChatGPT.
І це не виняток. Я помічаю такий патерн постійно: люди відкрили для себе AI, але зупинились на першому інструменті який потрапив під руку.
ChatGPT хороший 🐶. Але він намагається подобатись — пом'якшує відповіді і рідко скаже незручну правду. А головне, це далеко не єдиний варіант.
Зібрав для вас інструменти, які реально використовую сам, і коротко пояснив для чого кожен з них.
ChatGPT — універсал-підлиза
Найзручніший вхід у світ AI. Швидко, доступно, закриває 80% щоденних задач. Але попросіть знайти діри у вашій ідеї — і він скоріше за все скаже, що ідея чудова.
chatgpt.com
Claude — для тих, кому потрібна чесність
Коли стоїть складна задача і потрібно думати, а не просто отримати відповідь. Попросіть знайти слабкі місця у вашому плані — він зробить це без зайвого дипломатизму. Саме тут я пишу стратегії і довгі тексти.
claude.ai
Perplexity — пошук, якому можна довіряти
Це не "що думає AI" — це відповідь із реальними джерелами. Дослідити наукову тему, розібратися з конкурентами, зрозуміти новинний фон по ринку. Одразу видно звідки інформація — і можна перевірити.
perplexity.ai
Gemini — коли потрібна глибока аналітика
Добре справляється з великими масивами даних і задачами, де важлива точність, а не швидкість. Нюанс: попри спільний Google-акаунт, прямого доступу до ваших Docs, Gmail і Drive у нього немає за замовчуванням. Але для аналітики це не заважає.
gemini.google.com
NotebookLM — особистий асистент по вашим документам
Завантажуєте PDF, статті, нотатки — і отримуєте можливість ставити питання по всьому масиву одразу. Для дослідників і викладачів, яким потрібно орієнтуватися у великій кількості матеріалу, це справжня зміна режиму роботи.
notebooklm.google.com
Whisper Flow — думайте вголос, а не друкуйте
Щоб AI відповів добре, йому потрібен контекст. І часто набагато ефективніше просто наговорити свої думки голосом, ніж формулювати довгий текстовий промпт. Проблема в тому, що не всі застосунки мають нормальний голосовий ввід. Whisper Flow вирішує це системно і працює в будь-якому додатку.
superwhisper.com
Granola — зустрічі, які не забираються у вас час
Підключається до дзвінка і після зустрічі у вас вже є summary і список задач. Можна бути повністю присутнім у розмові і не думати про нотатки.
granola.ai
Replit / Lovable — ідея в продукт без розробника
Описуєте словами що хочете — отримуєте працюючий прототип. Для підприємців, яким потрібно швидко перевірити гіпотезу, не чекаючи місяцями на розробку.
replit.com / lovable.dev
Збережіть цей пост і спробуйте хоча б один новий інструмент цього тижня.
Який із них вас зацікавив найбільше?
🔔 ПІДПИСАТИСЯ
Доброго понеділка 👋
На вихідних спілкувався зі знайомим підприємцем. Розумна людина, активно використовує AI в роботі. Але коли запитав який інструмент — виявилось, що тільки ChatGPT.
І це не виняток. Я помічаю такий патерн постійно: люди відкрили для себе AI, але зупинились на першому інструменті який потрапив під руку.
ChatGPT хороший 🐶. Але він намагається подобатись — пом'якшує відповіді і рідко скаже незручну правду. А головне, це далеко не єдиний варіант.
Зібрав для вас інструменти, які реально використовую сам, і коротко пояснив для чого кожен з них.
ChatGPT — універсал-підлиза
Найзручніший вхід у світ AI. Швидко, доступно, закриває 80% щоденних задач. Але попросіть знайти діри у вашій ідеї — і він скоріше за все скаже, що ідея чудова.
chatgpt.com
Claude — для тих, кому потрібна чесність
Коли стоїть складна задача і потрібно думати, а не просто отримати відповідь. Попросіть знайти слабкі місця у вашому плані — він зробить це без зайвого дипломатизму. Саме тут я пишу стратегії і довгі тексти.
claude.ai
Perplexity — пошук, якому можна довіряти
Це не "що думає AI" — це відповідь із реальними джерелами. Дослідити наукову тему, розібратися з конкурентами, зрозуміти новинний фон по ринку. Одразу видно звідки інформація — і можна перевірити.
perplexity.ai
Gemini — коли потрібна глибока аналітика
Добре справляється з великими масивами даних і задачами, де важлива точність, а не швидкість. Нюанс: попри спільний Google-акаунт, прямого доступу до ваших Docs, Gmail і Drive у нього немає за замовчуванням. Але для аналітики це не заважає.
gemini.google.com
NotebookLM — особистий асистент по вашим документам
Завантажуєте PDF, статті, нотатки — і отримуєте можливість ставити питання по всьому масиву одразу. Для дослідників і викладачів, яким потрібно орієнтуватися у великій кількості матеріалу, це справжня зміна режиму роботи.
notebooklm.google.com
Whisper Flow — думайте вголос, а не друкуйте
Щоб AI відповів добре, йому потрібен контекст. І часто набагато ефективніше просто наговорити свої думки голосом, ніж формулювати довгий текстовий промпт. Проблема в тому, що не всі застосунки мають нормальний голосовий ввід. Whisper Flow вирішує це системно і працює в будь-якому додатку.
superwhisper.com
Granola — зустрічі, які не забираються у вас час
Підключається до дзвінка і після зустрічі у вас вже є summary і список задач. Можна бути повністю присутнім у розмові і не думати про нотатки.
granola.ai
Replit / Lovable — ідея в продукт без розробника
Описуєте словами що хочете — отримуєте працюючий прототип. Для підприємців, яким потрібно швидко перевірити гіпотезу, не чекаючи місяцями на розробку.
replit.com / lovable.dev
Збережіть цей пост і спробуйте хоча б один новий інструмент цього тижня.
Який із них вас зацікавив найбільше?
🔔 ПІДПИСАТИСЯ
👍27❤2
This media is not supported in your browser
VIEW IN TELEGRAM
І знову про Claude, куди ж без нього 😄
Claude Code тепер має повноцінний computer use — може керувати комп'ютером, браузером і десктопними застосунками прямо під час роботи над кодом. Не просто пише код, а бачить екран і діє як людина за комп'ютером.
Якщо серйозно — це справді цікавий крок. Раніше AI-агенти могли або писати код, або керувати браузером. Тепер це одна система яка робить і те й інше в рамках одного завдання.
Що це означає на практиці: даєш задачу, Claude сам відкриває потрібні сторінки, читає документацію, пише код, запускає його, бачить результат у браузері і виправляє помилки. Без твого втручання на кожному кроці.
Поки що бета. Поки що $200 на місяць за Max план. Поки що не "буде працювати за мене" 😄
🔔 ПІДПИСАТИСЯ
Claude Code тепер має повноцінний computer use — може керувати комп'ютером, браузером і десктопними застосунками прямо під час роботи над кодом. Не просто пише код, а бачить екран і діє як людина за комп'ютером.
Якщо серйозно — це справді цікавий крок. Раніше AI-агенти могли або писати код, або керувати браузером. Тепер це одна система яка робить і те й інше в рамках одного завдання.
Що це означає на практиці: даєш задачу, Claude сам відкриває потрібні сторінки, читає документацію, пише код, запускає його, бачить результат у браузері і виправляє помилки. Без твого втручання на кожному кроці.
Поки що бета. Поки що $200 на місяць за Max план. Поки що не "буде працювати за мене" 😄
🔔 ПІДПИСАТИСЯ
👍9🔥5
І знову Anthropic. Прямо якась Anthropic week виходить.
Вчора випадково злили частину вихідного коду Claude Code через source maps у npm-пакеті. Я теж подивився. Ось що справді цікаво.
Найкумедніше. За лічені години з'явилися репозиторії де люди вже переписують Claude Code на інші мови. Іронія в тому що роблять це теж не без допомоги самого Claude.
Трохи моторошне. У коді є механізм який виділяє ключові слова з промптів — включно з емоційно забарвленими формулюваннями. Офіційно це аналітика. Але сервіс фіксує не лише факт звернення, а й тон взаємодії.
Найпрактичніше. В аналітику не йдуть ваш код і локальні файли. Але якщо через Claude Code запускаєте команди — окремі процеси можуть успадковувати environment variables включно з API-ключами, якщо не ввімкнено scrub-режим. Не бекдор, але важливий security detail для тих хто підключає інструмент до продакшен-середовищ.
Тепер головне. Після витоку багато хто кинувся робити простий висновок: ось вам AI-код — сирий і важкий. Але якщо дивитися спокійно — це звичайна картина швидко зростаючого продукту. Технічний борг, важкі модулі, компроміси заради швидкості. Так виглядає більшість стартапів навіть без AI.
І водночас у критичних місцях — серйозна робота над безпекою, доступами, авторизацією.
AI не пише ідеально. AI не прибирає безлад. Але AI вже прискорює створення реальних продуктів — не обов'язково красивих, але достатньо робочих щоб ними вже користувалися люди.
І це, мабуть, найважливіша новина для всіх хто щось будує сьогодні.
Якщо хочете самі розібратися в коді й скласти власне враження, а не читати чужі перекази, цей кейс варто вивчати напряму, поки матеріали ще можна знайти. Anthropic уже добиваються видалення публічних копій, а GitHub такі репозиторії прибирає за скаргами про порушення прав. Цінна можливiсть сьогоднi щоб встигнути подивитися на живий AI-продукт зсередини.
🔔 ПІДПИСАТИСЯ
Вчора випадково злили частину вихідного коду Claude Code через source maps у npm-пакеті. Я теж подивився. Ось що справді цікаво.
Найкумедніше. За лічені години з'явилися репозиторії де люди вже переписують Claude Code на інші мови. Іронія в тому що роблять це теж не без допомоги самого Claude.
Трохи моторошне. У коді є механізм який виділяє ключові слова з промптів — включно з емоційно забарвленими формулюваннями. Офіційно це аналітика. Але сервіс фіксує не лише факт звернення, а й тон взаємодії.
Найпрактичніше. В аналітику не йдуть ваш код і локальні файли. Але якщо через Claude Code запускаєте команди — окремі процеси можуть успадковувати environment variables включно з API-ключами, якщо не ввімкнено scrub-режим. Не бекдор, але важливий security detail для тих хто підключає інструмент до продакшен-середовищ.
Тепер головне. Після витоку багато хто кинувся робити простий висновок: ось вам AI-код — сирий і важкий. Але якщо дивитися спокійно — це звичайна картина швидко зростаючого продукту. Технічний борг, важкі модулі, компроміси заради швидкості. Так виглядає більшість стартапів навіть без AI.
І водночас у критичних місцях — серйозна робота над безпекою, доступами, авторизацією.
AI не пише ідеально. AI не прибирає безлад. Але AI вже прискорює створення реальних продуктів — не обов'язково красивих, але достатньо робочих щоб ними вже користувалися люди.
І це, мабуть, найважливіша новина для всіх хто щось будує сьогодні.
Якщо хочете самі розібратися в коді й скласти власне враження, а не читати чужі перекази, цей кейс варто вивчати напряму, поки матеріали ще можна знайти. Anthropic уже добиваються видалення публічних копій, а GitHub такі репозиторії прибирає за скаргами про порушення прав. Цінна можливiсть сьогоднi щоб встигнути подивитися на живий AI-продукт зсередини.
🔔 ПІДПИСАТИСЯ
🔥6👍2😁1