Де саме експеримент чіпляє
Я люблю такі тести не за хайп, а за неприємну чесність. Беруть близько 80 задач з програмування, дають їх моделям у двох обгортках: звичайний Python та тьюринг-повні езотеричні мови. На Python виходить щось на кшталт 85-95% успіху, а на езотеричних мовах — жалюгідні 0-11%.
І ось тут у мене не сталося шоку. Радше навпаки: цифри просто підсвітили те, що я й так бачу в прикладній роботі з кодогенерацією. Модель часто не «розуміє задачу» в абстрактному вигляді — вона впевнено їде знайомими рейками синтаксису, патернів і поширених рішень.
Якщо коротко, теза така: тьюринг-повнота сама по собі не рятує. Формально мова може вміти все, що й Python, але для моделі це взагалі не означає, що вона перенесе навичку. Ось це і є неприємна частина історії про sample-efficient transfer — перенесення знань у трансформерів досі є доволі крихким.
Джерело тут не академічне, а радше дослідницько-інтернетний розбір навколо ідеї The Illusion of Thinking. Це важливо проговорити чесно: я б не подавав це як остаточний вирок усій архітектурі. Але як стрес-тест на абстракцію — дуже показово.
Чому Python обманює нас краще, ніж хочеться
Я багато разів бачив, як команда дивиться на високий відсоток у Python-бенчмарках і робить надто сміливий висновок: «ну все, модель вміє програмувати». Ні, вона чудово статистично орієнтується у звичній екосистемі. Це корисно, але не тотожно мисленню.
Python — ідеальна теплиця для LLM. Величезний корпус коду, передбачувані ідіоми, безліч однотипних завдань, море документації та обговорень. Модель там не просто сильна — вона там удома.
А ось коли я висмикую її з комфортного середовища і прошу зробити щось на незвичному DSL, старій внутрішній мові правил або кривому конфіг-форматі, магія різко тьмяніє. Не тому що задача фундаментально складніша, а тому що зникає опора на знайомі шаблони. Для мене це набагато ближче до реального життя, ніж чергове красиве Python demo.
Що це змінює в бізнесі та автоматизації
Для бізнесу висновок дуже практичний: не можна плутати успішний copilot у знайомому стеці з універсальним reasoning-рушієм. Якщо у вас впровадження ШІ зав'язане на нестандартні процеси, внутрішні DSL, легасі-системи або рідкісні формати даних, ризик недооцінити крихкість моделі є досить високим.
Я б сформулював правило так: що далі ваш контур від масового інтернету, то менше варто вірити «середній температурі по бенчмарках». Потрібні свої eval-набори, свої тести перенесення, свої обмеження на автономність агента. Інакше ШІ автоматизація виглядатиме красиво в пілоті й неприємно в продакшені.
Хто виграє? Команди, які будують AI-архітектуру з перевірками, проміжними представленнями, компіляцією в контрольовані кроки та жорсткою валідацією результату. Хто програє? Ті, хто намагається просто прикрутити модель до рідкісної доменної мови й сподівається, що вона «сама розбереться».
Ми в Nahornyi AI Lab з таким стикаємося регулярно, коли йде розробка ШІ рішень для внутрішніх процесів, а не для красивих демо. Якщо домен вузький, я майже завжди закладаю шар нормалізації: спочатку переведення задачі в більш стійке представлення, потім генерація, потім автоматична перевірка. Це не так романтично, зате працює.
Мій висновок без зайвої драми
Я б не кричав, що «моделі не вміють думати взагалі». Це надто дешева формула. Але я точно сказав би інакше: їхня здатність до перенесення знань сильно переоцінена, особливо коли ми дивимося на звичні мови та зручні бенчмарки.
Якщо ви плануєте впровадження штучного інтелекту в код, ops або внутрішні інструменти, тримайте в голові просте питання: модель вирішує мою задачу чи вгадує знайому форму задачі? Різниця між цими двома сценаріями потім перетворюється або на економію місяців, або на дуже дорогу ілюзію.
Цей розбір написав я, Вадим Нагорний, у Nahornyi AI Lab. Я власноруч збираю ШІ інтеграції, агентні пайплайни та автоматизацію за допомогою ШІ там, де є легасі, нестандартні дані та вимоги до якості. Якщо хочете, я допоможу тверезо перевірити ваш кейс і разом зрозуміти, де в моделі реальна сила, а де лише впевнений фасад.