У серпні 2026 року на arXiv з'явилася робота (arXiv:2608.28447), яка показує, як reinforcement learning навчає математичних AI-агентів самостійно вирішувати, коли варто викликати зовнішній інструмент — калькулятор, код-інтерпретатор чи символьну бібліотеку — а коли достатньо власного текстового міркування. За даними arXiv, це напрям, який напряму впливає на точність агентів у задачах, де ціна арифметичної помилки моделі висока.

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

Саме тут з'являється reinforcement learning: замість того, щоб просто показати моделі приклади правильних викликів інструментів (класичний supervised fine-tuning), агента навчають через нагороду за правильну кінцеву відповідь — і модель сама відкриває, коли виклик інструменту підвищує точність, а коли лише сповільнює міркування.

Що саме показало дослідження?

Головний результат — reinforcement learning підвищує здатність моделі коректно інтегрувати виклики зовнішніх інструментів у ланцюжок математичних міркувань, а не просто «приклеювати» їх до тексту відповіді. Це відрізняється від традиційного fine-tuning на розмічених прикладах: RL оцінює не формат виклику інструменту, а те, чи привів цей виклик до правильного фінального результату.

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

Чому RL, а не просто навчання на прикладах?

Supervised fine-tuning вчить модель наслідувати конкретні приклади викликів інструментів, підготовані людиною чи іншою моделлю. Проблема в тому, що такі приклади рідко покривають усі варіанти математичних задач, і модель погано узагальнює на нові типи обчислень поза тренувальним набором.

• SFT: модель копіює патерн виклику інструменту з розмічених прикладів, тому крихко реагує на незнайомі формати задач.
• RL: модель отримує нагороду за правильну відповідь незалежно від того, як саме вона туди дійшла, тому вчиться приймати рішення «інструмент чи ні» адаптивно.

Це узгоджується із загальним трендом у тренуванні reasoning-моделей: нагорода за кінцевий результат замість нагороди за формат кроку дає моделі свободу вибудувати власну стратегію розв'язання задачі.

Кому це знадобиться на практиці?

Найпряміший бенефіціар — команди, що будують агентів для розв'язання математичних чи інженерних задач із доступом до калькулятора, Python-інтерпретатора або символьних бібліотек на кшталт SymPy. Якщо агент постійно або занадто рідко викликає інструмент, кінцева точність падає, а вартість інференсу зростає через зайві виклики.

• Розробники математичних тьюторів та освітніх агентів, де кожна арифметична помилка підриває довіру користувача.
• Команди, що будують агентів для фінансових розрахунків чи наукових обчислень із виконанням коду.
• Дослідники, що тренують reasoning-моделі через RL і шукають, як розширити reward-сигнал на рішення про виклик інструментів, а не лише на текст відповіді.

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

Висновок AiiN: що це означає для AI-білдерів?

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

Для команд, що вже інвестують у RL-інфраструктуру для тренування агентів — і тут доречно згадати, як OpenAI та Anthropic нарощують обчислювальні потужності саме під reinforcement learning — вбудовування tool-calling у reward-функцію виглядає логічним наступним кроком, а не окремим експериментом.

Чи можна застосувати цей підхід поза математикою?

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

Чи означає це, що SFT для tool-calling більше не потрібен?

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