Що таке виклик інструментів? Як моделі ШІ перетворюють рішення на дії

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

Виклик інструментів — основа сучасних ШІ-агентів. Модель може міркувати про те, що слід зробити, але саме застосунок визначає, чи є запитана дія допустимою та дозволеною, чи буде її виконано і чи повернуть результат моделі для ухвалення наступного рішення.

Навіщо моделям потрібні інструменти

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

Інструменти надають моделі такі можливості, як:

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

Інструмент сам по собі не робить модель обізнанішою. Він надає застосунку контрольований спосіб отримати докази або виконати операцію.

Будова опису інструмента

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

Застосунки описують кожен доступний інструмент у структурованому форматі. Зазвичай визначення містить:

• Назва: стабільний ідентифікатор, наприклад get_weather або create_support_ticket.
• Опис: точне пояснення того, що робить інструмент і коли його слід використовувати.
• Схема вхідних даних: обов’язкові й необов’язкові аргументи, їхні типи даних і дозволені значення.
• Контракт вихідних даних: документація щодо результату або станів помилки, які поверне застосунок.

У багатьох інтерфейсах інструментів використовують JSON Schema або споріднений типізований формат. Вузька й однозначна схема зменшує ймовірність того, що модель вигадає параметри або поєднає несумісні варіанти.

Як працює цикл виклику інструмента

Уявімо, що користувач запитує: «Чи є в мене зустрічі в Манчестері наступного вівторка і чи буде дощ?»

1. Застосунок надає контекст. Він надсилає моделі запит користувача, системні інструкції та визначення вибраних інструментів.
2. Модель вибирає інструмент. Вона може запросити пошук у календарі, вказавши діапазон дат і фільтр за місцем.
3. Застосунок перевіряє запит. Він перевіряє назву інструмента, обов’язкові аргументи, обсяг дозволів і бізнес-правила.
4. Середовище виконання запускає інструмент. Воно звертається до календарної системи й повертає відповідні події або чітке повідомлення про помилку.
5. Модель отримує результат. Вона бачить, що в Манчестері запланована зустріч, і запитує дані про погоду в цьому місті на відповідну дату.
6. Застосунок повторює перевірки й виконання.
7. Модель формулює остаточну відповідь. Вона поєднує перевірені результати й наводить відповідні подробиці.

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

Вибір інструментів може бути автоматичним або обмеженим

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

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

Виклик інструментів і структурований вивід

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

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

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

Виклик інструментів і API

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

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

Яким має бути хороший інструмент ШІ?

Чітке призначення. Назва й опис мають відрізняти інструмент від подібних функцій. Інструменти зі схожими можливостями призводять до непослідовного вибору.

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

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

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

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

Поширені помилки під час виклику інструментів

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

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

Дозволи та схвалення людиною

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

Схвалення має бути усвідомленим. Інтерфейс підтвердження повинен показувати точну дію, ціль, важливі параметри та ймовірні наслідки. Запитання «Дозволити використання інструмента?» недостатньо, якщо інструмент надішле електронний лист 5 000 адресатам або видалить виробничий ресурс.

В огляді OpenAI щодо інструментів для створення агентів наголошується, що використання інструментів має бути частиною агентної платформи з трасуванням і спостережуваністю. Супутні засоби контролю — не факультативні доповнення; саме вони дають змогу належно керувати діями, які вибирає модель.

Як оцінювати використання інструментів

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

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

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

Як читати діаграми виклику інструментів

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

У матеріалі «Що таке виклик інструментів? Як моделі ШІ перетворюють рішення на дії» схема — це карта, а не гарантія. У реальній реалізації кілька етапів можуть об’єднуватися, окремий крок може повторюватися, а також може бути передбачено межу, на якій потрібне схвалення людини. Важливо, чи може команда визначити ті самі функції в розгорнутій системі, призначити відповідального за кожну межу та перевірити перехід між ними. Якщо етап неможливо спостерігати або виміряти, несправності на ньому буде складно діагностувати.

Що варто пам’ятати про виклик інструментів

Виклик інструментів — це міст між судженнями моделі та діями програмного забезпечення. Модель визначає потрібну функцію та пропонує структуровані вхідні дані; застосунок перевіряє їх, надає дозвіл, виконує дію та повертає результат.

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