Швидкі обіцянки про «кінець професії розробника до кінця року» стали майже щорічною традицією для керівників великих AI‑компаній. На цьому тлі корисно подивитися на штучний інтелект тверезо — не лише як на потужний інструмент, а й як на технологію з фундаментальними обмеженнями. Канал Philipp Lackner пропонує розібратися з трьома теоретичними межами нинішніх великих мовних моделей (LLM), які не можна усунути без радикальної зміни самої архітектури.
1. Проблема навчання: стеля колективних знань
LLM не «знають» і не «розуміють» світ у людському сенсі. Їхня робота зводиться до статистичного аналізу величезних масивів тексту й передбачення наступних токенів (слів або їхніх частин) на основі виявлених закономірностей.
Джерела цих даних — блоги, Reddit, книжки, новини та інший контент, створений людьми. Чим більше такого тексту модель бачить, тим краще імітує стилі та структури мови. Але зі зростанням масштабів AI зростає й обсяг тексту, який уже згенерований іншими моделями. Виникає замкнене коло:
- моделі починають навчатися на контенті, створеному іншими моделями;
- щоб стати «розумнішими», їм потрібно вчитися на чомусь, чого вони ще не бачили;
- але власний згенерований текст не містить нових знань — це лише перетасування вже наявних патернів.
Аналогія проста: вам дають підручник з базової фізики й просять вивести з нього нову, ще невідому фізику, не звертаючись до інших джерел. Людина, яка справді мислить, може щось придумати, але навіть їй буде важко. LLM, які не мають механізму розуміння, обмежені ще жорсткіше.
Ключовий висновок: модель не може перевищити «колективну стелю» знань, закладених у тренувальні дані. Вона може синтезувати, комбінувати, узагальнювати — іноді дуже ефективно — але не виходити за межі того, що вже в тій чи іншій формі існує в корпусі текстів. Це ставить під сумнів ідею, що в нинішньому вигляді LLM зможуть радикально перевершити людський інтелект.
2. Галюцинації: побічний ефект тієї ж творчості
«Галюцинацією» називають ситуацію, коли модель упевнено видає неправдиву інформацію. Інтуїтивно це сприймається як баг, який можна виправити. Але в рамках поточної архітектури це радше невід’ємна властивість.
LLM не мають внутрішньої бази істин, де можна перевірити факт. Вони просто обирають найбільш ймовірний наступний токен, спираючись на статистику з навчальних даних. Якщо запит стосується добре відомого факту — наприклад, «найбільше місто Японії» — модель майже завжди відповість «Токіо», бо цей зв’язок масово присутній у текстах.
Проблеми починаються там, де:
- факт маловідомий або новий;
- даних мало або вони суперечливі;
- запит стосується вузьких, свіжих чи експериментальних технологій (типовий кейс — нові бібліотеки в програмуванні).
У моделі немає механізму «я цього не знаю», бо немає місця, де вона могла б перевірити наявність факту. Вона змушена щось згенерувати — тобто вибрати найімовірнішу продовжувальну послідовність токенів. Звідси й упевнені, але хибні відповіді.
Важливий нюанс: творчість і галюцинації — це дві сторони одного процесу. Коли модель:
- вигадує вірш — ми називаємо це креативністю;
- «вигадує» API неіснуючої бібліотеки — це вже галюцинація.
Механізм один і той самий: генерація нового тексту на основі статистичних патернів. Тому:
- якщо ми хочемо більшої креативності — неминуче зростає ризик галюцинацій;
- якщо жорстко пригнічуємо галюцинації — втрачаємо частину творчого потенціалу.
У задачах, де критична фактологічна точність (наприклад, у програмуванні чи технічній документації), це фундаментальне обмеження. Його не можна «вимкнути», не змінивши сам принцип роботи моделей.
3. Проблема фрейму: модель не виходить за межі поставленого питання
Ще одна глибинна межа — так звана frame problem, проблема фрейму. Вона проявляється в тому, що модель жорстко обмежена рамками запиту, який отримує.
Приклад із розробки: застосунок падає, ви даєте LLM стек трейс і просите «знайти причину та виправити». Модель:
- аналізує стек;
- знаходить, скажімо,
NullPointerException; - пропонує додати перевірку на
nullабо обробити крайовий випадок.
Формально завдання виконано. Але:
- справжня проблема може бути в хибній архітектурі;
- дані можуть передаватися через шість шарів колбеків там, де логічніше застосувати реактивний підхід;
- об’єкти можуть «гуляти» між потоками без чіткої моделі володіння.
Досвідчений сеньйор, побачивши такий код, може взагалі проігнорувати стек трейс і поставити інше, більш фундаментальне запитання: «Що тут загалом відбувається і чому це так спроєктовано?». Тобто він змінює сам фрейм задачі.
LLM же:
- працює в межах того фрейму, який задав користувач;
- не має «пташиного погляду» за замовчуванням;
- не вміє самостійно переосмислити постановку задачі.
Можна частково пом’якшити це кращим промптингом: просити «оцінити архітектуру в цілому», «запропонувати альтернативний дизайн» тощо. Але тут виникає інша пастка: якщо людина, яка ставить задачу, сама не усвідомлює, що перебуває в хибному фреймі, вона не зможе правильно його розширити. Модель залишиться замкненою в тих же межах.
У підсумку LLM у розробці часто поводиться як дуже вправний джуніор:
- добре виконує чітко сформульовані інструкції;
- не замінює стратегічне мислення й архітектурне бачення.
Як працювати з AI, знаючи про ці межі
Фундаментальні обмеження не означають, що LLM варто ігнорувати. Навпаки, у розробці вони вже дають відчутний приріст продуктивності — за умови, що їх використовують не як «магічну кнопку», а як інструмент у руках фахівця, який:
- розуміє базові принципи роботи моделей;
- вміє формулювати промпти й керувати контекстом;
- має власну технічну експертизу, щоб перевіряти й коригувати відповіді;
- мислить на рівні системного дизайну й архітектури, а не лише окремих фрагментів коду.
Реалістичний підхід до AI лежить між двома крайнощами:
- повна відмова від інструментів через недовіру;
- віра в те, що «моделі скоро замінять усіх».
Знання про теоретичні межі — це не аргумент «проти» AI, а радше інструкція з безпечного й ефективного використання.
Джерело
3 Theoretical Limits of AI – These Things Can’t Be Fixed — Philipp Lackner