Джефф Дін про наступний етап ШІ: від TPU до саморозвиваючихся агентів

На Startup School YC 2026 року голос Джеффа Дина був хриплуватим.

На початку інтерв’ю він пояснив, що втратив голос, і сьогодні його голос звучить інакше, ніж звичайно. Але це не вплинуло на увагу глядачів у залі. Diana Hu, партнер YC, сидячи перед ним, одним диханням назвала довгий список імен, які варто внести до історії комп’ютерних наук: MapReduce, BigTable, TensorFlow, TPU, Gemini.

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

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

Відповідь не в більших моделях.

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

Це також означає, що конкуренція в галузі ШІ зміщується з «хто має більші моделі» на «хто краще організовує інтелект».

У травні 2025 року Джефф Дін зробив твердження, яке викликало широке обговорення: здібності ШІ вже наближаються до рівня молодшого інженера.

Через рік Діана запитала його, як виконалася ця прогнозна оцінка?

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

«Здатність моделі виконувати все більш складні завдання зростає швидше, ніж я очікував», — сказав він.

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

Порівняння ШІ з молодшим інженером може змусити людей зосередитися на заміні людських ресурсів. Але Джефф Дін більше зацікавлений іншим аспектом: що зміниться у способах організації виробництва, коли один «молодший інженер» можна розмножити на десятки, сотні і заставити їх працювати паралельно протягом кількох днів або тижнів?

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

Це призвело до нового розподілу обов’язків у галузі AI-інженерії.

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

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

Де існує вимірювана мета, існує можливість досягти великих успіхів.

Це ключ до всього інтерв’ю.

Першими сферами, у яких автоматизація на основі ШІ вдалося досягти прориву, не обов’язково є ті, що вимагають найбільших знань, а ті, де зворотний зв’язок найбільш чіткий. Чи проходять коди тести? Чи зменшує розміщення чіпа площу? Чи підвищує структура моделі точність? Чи відповідають властивості матеріалів вимогам? У цих питаннях існують відносно чіткі критерії оцінки. Якщо оцінювач достатньо надійний, машина може проводити експерименти з дуже високою частотою.

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

Багато визначних робіт Джеффа Діна виникли з дуже простого початку: спочатку розрахувати порядки величин.

У 2001 році пошук Google все ще сильно залежав від жорстких дисків. Жорсткі диски мали велику ємність, але повільний час доступу. Джефф Дін і Санjay Гемават зробили оцінку і виявили, що повний індекс пошуку Google на той момент уже можна було розмістити у пам’яті всіх серверів.

Сьогодні це звучить як просто оновлення носія даних. Але тоді це означало зовсім інше проектування системи.

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

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

Багато галузевих інновацій відбуваються саме в такі моменти.

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

Джeff Дін вміє перетворювати звичайну логіку знову на припущення.

Він запитає: чому обов’язково саме так? Чи кількісний рівень сьогодні такий самий, як вчора? Якщо замінити найдорожчий крок, чи отримає вся система зовсім іншу форму?

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

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

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

У 2013 році глибинне навчання Google для розпізнавання мови почало значно перевершувати старі системи. Похибка зменшилася наполовину, що еквівалентно концентрації всіх досягнень у розпізнаванні мови за останні двадцять років у кілька місяців.

Команда продукту, звичайно, була захоплена. Але Джефф Дин спочатку провів розрахунки.

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

Результати не є оптимістичними. Згідно з ефективністю CPU того часу, Google, можливо, мав би подвоїти масштаб своїх серверів.

Це початок TPU.

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

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

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

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

Перше покоління TPU принесло прибуток у кілька разів. За словами Джеффа Діна, воно було в 30–80 разів ефективнішим за CPU та GPU того часу, а затримка була в 20–30 разів нижчою.

Тут ще один легко знехтуваний розмір дизайну.

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

Це дуже важко зберегти баланс. Якщо не використовувати достатньо — прибуток буде мінімальним. Якщо ж вкласти занадто багато — зміна алгоритму зробить обладнання застарілим.

Оцінка Джеффа Діна щодо сьогоднішнього обладнання для висновків явно відгукується з тим, що було з TPU. Він вважає, що наступна важлива можливість залишається у спеціалізації, але акцент зміститься ще далі на низькі затримки та низьке споживання енергії для висновків.

Уявіть, що ви зможете зробити, якщо затримка зменшиться в 50 разів.

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

Очікування — це не мала проблема з досвідом. Очікування змінює форму продукту.

Якщо було б оновлено версію «Числа затримок, які повинен знати кожен інженер-розробник штучного інтелекту 2026 року», ДжEFF Дін вважає, що акцент слід змістити з пошуку на жорсткому диску, пропусків кешу та міжконтинентальної мережевої затримки на потоки даних всередині чіпа.

Інженерам потрібно знати: яка пропускна здатність між основною пам’яттю та начіповою пам’яттю, яка пропускна здатність між начіповою пам’яттю та множильними блоками, скільки енергії витрачається на одну операцію множення, як чіпи взаємопід’єднані між собою, і як знизиться ефективність мережі при масштабуванні з 500 чіпів до 10 000.

Ці цифри здаються віддаленими від продукту, але насправді вони визначають, який продукт може вдалося.

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

Іншими словами, сьогодні дорогими діями в системах ШІ часто є не самі «обчислення», а «переміщення даних, які треба обчислити».

Це також пояснює, чому пакетна обробка така важлива.

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

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

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

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

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

Тому «енергетична проблема» ШІ — це не віддалена екологічна тема. Вона безпосередньо визначає, чи можуть моделі ефективно обслуговувати більше людей, чи можуть агенти працювати постійно, а також чи є валова прибутковість стартапів здоровими.

Протягом останніх кількох років індустрія ШІ звикла вимірювати прогрес за кількістю параметрів, даними для навчання та бенчмарками. У 2026 році Джефф Дін більше акцентує увагу на все, що оточує модель.

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

Ось чому «інженерія контексту» починає виходити на центральну сцену.

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

Це створює важливу можливість для невеликих команд.

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

Джефф Дін навів свій власний приклад.

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

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

Ми просто подали йому методи, які використовують люди, у формі, зрозумілій для моделі.

Це речення майже можна вважати простою визначеною контекстної інженерії.

Це не таємні трюки з промптами, ні додавання більше контексту. Це відповідь на три питання: які кроки виконують експерти, які надійні інструменти має система та як слід перевіряти результати.

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

Саме тому «навички (skill)» стають ключовим активом у екосистемі агентів. Добре створений файл навички може містити роки прихованого досвіду команди. Він вказує моделі, що робити першим при зустрічі з певним типом проблеми, які помилки найпоширеніші, які інструменти варто вважати надійними та що вважати завершеним результатом.

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

Майже всі команди, які справді працювали з Agent, бачили одну й ту саму сцену.

Перші кроки йшли добре. Модель могла читати вимоги, використовувати інструменти та писати код. Але на 30-му або 50-му кроці вона почала забувати про мету, неправильно розуміти стан, повторювати дії або все більше віддалятися в неправильному напрямку.

Джефф Дін приписує одну з причин проблемам поза розподілом.

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

Один із способів вирішення — надати навички та підказки, щоб обмежити модель на її знайомих шляхах. Інший спосіб — використання багатоагентної системи.

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

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

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

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

Це саме місце, де контекст Джеффа Діна знову стає ключовим.

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

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

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

У контексті Startup School найбільш обговорюваною темою, звичайно, є підприємницькі можливості.

Google може спільно розробляти чіпи, центри обробки даних, моделі та продукти. Такі універсальні моделі, як Gemini, швидко розширюють межі своїх можливостей. На чому базується перемога команди з двох-трьох осіб?

Відповідь Джеффа Діна не романтична.

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

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

Тому підприємцям потрібно визначити, чи є їхні переваги стійкими.

Джефф Дін висунув дуже конкретний критерій відбору: шукайте завдання, у яких успішність сучасних моделей близька до 0% або 1%, а не ті, у яких вже досягнуто 20%.

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

Причина проста: 20% означає, що здатності вже почали виникати. Більше даних, більші моделі та довші міркування, ймовірно, швидко зроблять їх придатними для використання. 0% або 1% свідчать про те, що завданню, ймовірно, не вистачає ключових даних, спеціальних інструментів, відгуків з галузі або здатності, яку загальна модель важко отримати в короткостроковій перспективі.

Це можна назвати «правилом 1%» Джеффа Дина.

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

Ці сліді в цілому поділяються на три категорії.

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

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

Третій тип — вузькі та глибокі моделі. AlphaFold не є універсальною чат-моделлю; вона розроблена для вирішення проблем структури білків і має високоспеціалізовані здібності. Подібні можливості можуть з’явитися в матеріалознавстві, проектуванні чіпів та інших спеціалізованих галузях.

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

Справжні можливості знаходяться на межі обох.

Діана висуває гіпотезу: якщо в майбутньому кожен засновник зможе одночасно керувати 50, 100 агентами, а весь код буде писатися агентами, які здібності стануть рідкісними?

Відповідь Джеффа Дина — «смак».

Точніше — визначити, що повинен робити агент.

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

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

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

Специфікації також стануть важливішими.

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

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

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

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

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

Щодо того, як навчати «смаку», ДжEFF ДЕАН запропонував дуже практичний підхід.

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

Смак не завжди є талантом. Його також можна розвивати через аналіз.

У другій частині інтерв’ю Джефф Дін поділився досить божевільним думковим експериментом.

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

У великих розподілених системах інженери давно прийняли те, що окремі компоненти можуть вийти з ладу. Жорсткі диски можуть зламатися, сервери можуть вимкнутися, комутатори можуть вийти з ладу. Надійність системи походить не від абсолютного відсутності помилок у кожному компоненті, а від реплікації, перевірки, надлишковості та відновлення.

Тоді Джефф Дін запитав: що б сталося, якби транзистори помилялися 20 разів на день, а не раз на мільйон років?

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

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

MapReduce походить з подібного процесу.

Ранні системи паука та індексування Google містили велику кількість ручного паралельного коду, контрольних точок та логіки відновлення після відмов. Самі обчислювальні завдання були досить простими, наприклад, читання всіх веб-сторінок та визначення мови сторінки. Однак велика кількість системного коду приховувала цю просту ідею.

Джефф Дін і Саньян Гемават отримали натхнення з функціонального програмування. Вони абстрагували величезну кількість завдань у Map і Reduce, перенісши паралелізацію, планування, стійкість до помилок та повторні спроби до єдиної рамки. Розробники бізнес-логіки повинні лише визначати сам обчислювальний процес.

Цей дизайн не зробив машини безпомилковими. Він зробив помилки здатними до поглинання системою.

Сьогодні інженерія агентів також може перебувати на подібному етапі. Багато команд все ще вручну налаштовують підказки, логіку повторних спроб та виклики інструментів для кожного завдання. Чи з’явиться в майбутньому проста абстракція, подібна до MapReduce, яка зробить розкладання, перевірку, відновлення та паралельне дослідження довгострокових агентів базовими можливостями?

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

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

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

Штучний інтелект може змінити дві частини.

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

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

Після зміни швидкості перевірки форма наукового питання також змінюється.

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

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

Машинне навчання також стане об’єктом такої автоматизованої науки.

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

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

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

У 2014 році Джефф Дін, Джеффрі Хінтон та Оріол Вінальс подали статтю про дистиляцію знань. Сьогодні дистиляція знань є базовим методом у стисненні моделей та перенесенні здібностей. Великі моделі як вчителі передають свої здібності меншим, швидшим і дешевшим студентським моделям.

Цю статтю, яка пізніше мала великий вплив, тоді відхилили NeurIPS.

Один рецензент вважає, що це «малоймовірно матиме значний вплив». Цікавим читачам можна відвідати статтю «Відмова ≠ невдача! Ці високоефективні наукові роботи вже відхилялися на провідних конференціях».

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

Після відмови у публікації команда розмістила її на arXiv. Галузь все одно прочитала її і почала використовувати.

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

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

Це також важливо для підприємців.

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

Джефф Дін не закликає сліпо триматися за своїм поглядом. Він закликає: розуміти проблему, постійно перевіряти, і не вважати одну оцінку кінцевим судом над світом.

На завершення інтерв’ю Діана поставила уявну питання.

Якщо молодого Джефа Діна, який приєднався до Google у 1999 році, перенести у 2026 рік, він приєднається до передової лабораторії чи заснує компанію разом із двома-трьома друзями?

Джефф Дин не давав стандартної відповіді.

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

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

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

Якщо відповідь — просто «досить круто», то, можливо, не варто витрачати найцінніший час.

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

Ці слова мають простоту старомодного інженера.

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

У кар'єрі Джеффа Дина багато легенд, які розповідають знову і знову.

Він і Санджай Гемават за кілька днів переписали пошукову систему, щоб індекси потрапили в пам’ять. Оцінка трьоххвилинного голосового повідомлення спонукала Google створити TPU. MapReduce приховав масштабне паралелізування та стійкість до помилок у єдиній абстракції. Знання з дистиляції перетворилися з відхиленої статті на базову технологію галузі.

Ці історії легко роблять із нього уявного генія, який постійно отримує натхнення.

Але з цієї інтерв’ю видно, що його підхід насправді дуже послідовний.

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

Сьогодні галузь ШІ переживає подібний переломний момент.

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

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

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

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

Що варто робити? Які обмеження застаріли? Які зміни тільки-но перетнули критичну межу? Яка система, якщо прискорити її в 50 разів, перетвориться на зовсім інший продукт?

Джефф Дин не надав списку можливостей для 6000 підприємців. Він надав більш стійкий спосіб мислення.

Не спішіть переслідувати найпопулярніші відповіді.

Спочатку розрахуйте питання.

Посилання для довідки

https://x.com/ycombinator/status/2082938685071491219

https://www.ycrootaccess.com/p/jeff-dean-the-1-rule-for-building

Цей матеріал зі сторінки WeChat «Machine Heart» (ID: almosthuman2014), автор: Panda