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

Це стається тому, що великі мовні моделі не міркують про числа так, як це роблять люди. Вони передбачають токени. Токен може бути цілим словом, частиною слова або окремою цифрою. Коли модель бачить «strawberry», вона не бачить вісім окремих літер, вишикуваних у ряд. Вона бачить кілька фрагментів. Її ніколи не вчили рахувати символи, лише передбачати, який фрагмент тексту буде наступним. Те саме стосується арифметики. Модель не має внутрішнього калькулятора. У неї немає логіки переносу розряду. Вона не має справжнього розуміння розрядної системи. Коли вона множить 148 на 279, вона не виконує множення. Вона зіставляє патерни зі схожими виразами, які бачила під час навчання, вгадуючи, яка послідовність цифр має йти далі. Для зовсім маленьких сум патерн достатньо сильний, щоб спрацювати. Але для всього, що потребує справжньої точності, вгадування зрештою дає збій.

Два завдання, один бот

Стандартні методи промптингу просять одну систему робити дві дуже різні речі одночасно. По-перше, зрозуміти логіку задачі. По-друге, виконати точні математичні обчислення. Модель справді вражає при виконанні першого завдання. Вона може прочитати текстову задачу, виділити змінні, встановити зв'язки та спланувати шлях розв'язання. Але потім вона має слугувати власним калькулятором. Саме тут ланцюг розривається. Одна помилкова цифра на третьому кроці заражає всі наступні кроки. Сама логіка може бути ідеальною, проте кінцева відповідь буде сміттям, бо модель помилилася при додаванні.

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

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

Виконуване міркування на практиці

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

Розглянемо конкретний приклад. Вам потрібно розрахувати суму до погашення фіксованого депозиту в розмірі ₹50,000 під 8,5% річних із щоквартальним нарахуванням відсотків протягом семи років. Запитайте мовну модель напряму, і вона може виписати формулу, підставити значення та обчислити результат у ланцюжку думок. Проте прискіпливий погляд може виявити, що вона неправильно обробила щоквартальне нарахування, неправильно поділивши ставку, або округлила проміжний етап і перенесла помилку далі. Відповідь виглядає розумною, але відхиляється на сотні рупій.

З PAL взаємодія змінюється. Ви даєте моделі вказівку згенерувати код Python, який визначає principal = 50000, rate = 0.085, time = 7 та n = 4, а потім обчислює amount = principal * (1 + rate/n) ** (n * time). Модель видає код. Середовище виконання Python виконує його. Ви отримуєте точну цифру, аж до останнього десяткового знака, щоразу. У множенні немає вгадування, немає галюцинованого залишку, немає впевненого округлення з помилкою.

Цей самий підхід застосовується і до математики з датами. Запитайте модель, яка дата настане рівно через 120 робочих днів від сьогодні, не враховуючи вихідні. Текстова модель може рахувати вперед і помилитися на суботі. Підхід PAL змушує модель написати скрипт, використовуючи логіку datetime та calendar, а потім дозволяє інтерпретатору ітерувати точно. Маніпуляції з даними працюють так само. Якщо вам потрібно розпарсити заплутаний CSV, відфільтрувати вкладений JSON або виконати швидку статистичну трансформацію, модель має розробити логіку, тоді як інтерпретатор оброблятиме ітерації.

Чому це насправді важливо

Перехід від текстових відповідей до виконуваного коду дає три практичні переваги.

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

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

Надійність. Модель дотримується своєї ролі. Вона робить те, для чого була створена: міркує про структуру, семантику та декомпозицію задач. Машина робить те, для чого була створена: точно обчислює. Саме такий розподіл відповідальності (separation of concerns) є основою архітектури надійного програмного забезпечення. Композиція краща за монолітний дизайн.

Запускайте це як недовірений код

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

Де PAL проявляє себе найкраще, а де має межі

PAL чудово працює з математикою, датами та маніпуляціями зі структурованими даними. Він усуває механічні помилки, які притаманні міркуванням лише у текстовому форматі.

Однак він не виправляє погану логіку. Якщо модель обере неправильну формулу,