Сингулярності не сталося: де два AI-агенти все ще потребують людину

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Кілька місяців тому я поставив двом AI-моделям навмисно надмірну задачу: спробувати створити систему, здатну покращувати власний спосіб навчання.

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

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

У результаті ми не створили сингулярність. Натомість отримали невеликий working proof of concept локального навчання без backpropagation і значно цікавіший для мене висновок про самих AI-агентів.

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

З чого все почалося

Перша версія експерименту називалася Observatory.

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

Початково це були Claude Code з Claude Opus 4.6 і MiniMax 2.5. Claude формулював архітектурні кроки та перевірки, MiniMax реалізовував їх і запускав експерименти. Я залишався в контурі як людина, що могла змінити питання або зупинити напрям.

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

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

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

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

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

Чому я перейшов на OpenCode

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

Тому пізніше я переніс роботу в OpenCode і зібрав іншу пару: GPT 5.4 та MiniMax 2.5. За обережного використання звичайний Plus-план давав приблизно п’ять-шість годин такої роботи на день.

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

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

Але разом із цим проявилася інша межа.

Нескінченна оптимізація неважливого

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

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

Кожна наступна дія мала переконливе обґрунтування.

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

Їм бракувало не пам’яті, а zoom out.

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

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

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

Що таке continuity в дослідженні

Раніше я думав про continuity переважно як про пам’ять: модель повинна знати попередні рішення, спростовані гіпотези, результати тестів і причини змін архітектури.

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

Але експеримент показав, що цього недостатньо.

Жива continuity дослідження містить не лише факти, а й їхню вагу:

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

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

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

Що все-таки вдалося створити

Дослідження не залишилося лише історією про обмеження AI. З нього виріс cap-flow — невеликий експериментальний механізм локального навчання на основі знакових переходів стану.

Код і результати доступні в публічному репозиторії cap-flow.

Система не використовує backpropagation або dense hidden MLP. Вона складається з малих event cells із локальним станом, розрідженими знаковими вагами, traces та оцінками подій переходу.

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

У зафіксованому десяти-seed запуску на sklearn digits цей режим показав середню фінальну accuracy близько 0.9469 проти 0.9144 у контрольного режиму. Водночас покращилися repair і retention прикладів біля межі рішення.

Це не state of the art, не заміна нейромереж і не доказ нового загального learning paradigm. Це вузький proof of concept на малому dataset. Подальші ablation-тести також показали, що на digits більшу частину приросту поки несе шлях локального оновлення ваг, а не задумана event dynamics.

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

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

І це нормально.

Дві моделі ще не утворюють дослідника

Multi-agent система легко створює враження автономного дослідження. Одна модель генерує гіпотезу, інша критикує, перша переписує код, друга запускає тести. Зовні це схоже на маленьку лабораторію.

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

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

Тому agentic systems потрібна не тільки пам’ять і не тільки журнал подій. Їм потрібен окремий механізм роботи зі значущістю:

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

Поки що найнадійнішим носієм цієї функції в моєму експерименті залишалася людина.

Замість сингулярності

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

Відповідь виявилася складнішою за «так» або «ні».

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

Але швидкість усередині підзадачі не дорівнює швидкості дослідження. Без здатності змінювати масштаб вона може лише швидше вести в локальний максимум.

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

Сингулярності ми не створили.

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