Чи зменшать розумніші моделі значення інструментарію агента чи зроблять його ще важливішим?

Кілька років тому покращення функцій ШІ здебільшого означало покращення самої моделі: вибір потужнішої моделі, її доробка, надання їй чистіших даних та доступ до неї через API. Сьогодні продуктивна система, заснована на моделі, може включати механізми пошуку інформації, пам’яті, інструментів, планування, оцінки, контролю стану системи, захисних механізмів, повторних спроб, керування контекстом та кілька взаємодіючих агентів. Загальна назва цього оточуючого шару — harness. Це ставить практичне запитання для кожного, хто вирішує, де приділити час на розробку: якщо моделі продовжуватимуть вдосконалюватися, чи стане цей шар менш значущим, чи навпаки — найважливішою частиною системи? У цій статті розглядаються обидві точки зору, а наприкінці наводиться спосіб визначити, які частини вашого harness, ймовірно, скоротяться, а які — зростуть.

Що таке harness та що це не є

Харнес – це програмне забезпечення навколо моделі, яке дозволяє їй надійно виконувати завдання. Модель забезпечує логіку; харнес створює умови, за яких ця логіка призводить до корисних результатів. На практиці він об’єднує кілька аспектів: доступ до інструментів та API; отримання даних, контекст та пам’ять; розбиття роботи на заплановані кроки та відстеження стану; перевірка результатів, повернення помилок та спроби їх усунення; забезпечення дозволів та обмежень; а також вимірювання та спостереження за тим, що відбувається.

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

Щоб детальніше дізнатися про те, як розподіляються обов’язки між моделлю та інструментарієм у єдиному агенті, перегляньте джерело надійної поведінки ШІ. Тут увага зосереджена на тому, як цей розподіл змінюється з часом.

Аргументи на користь простішого інструментарію

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

• Дотримується складних інструкцій.
• Зберігає те, що є релевантним.
• Вибирає правильний інструмент.
• Планує завдання з багатьма кроками.
• Відновлює роботу після збою.
• Перевіряє власний результат.
• Визначає моменти своєї невпевненості.
• Веде облік стану під час тривалих операцій.

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

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

Зростання можливостей розширює сферу застосування

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

• Модель, яка може узагальнити один документ, незабаром буде залучена до аналізу сотні документів.
• Модель, яка може написати один SQL-запит, буде змушена досліджувати бізнес-питання, що стосуються кількох систем.
• Модель, яка може викликати один API, отримає на обробку ціле програмне середовище.

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

Здатні агенти ставлять системні запитання

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

• Які дії може виконувати агент?
• Яку інформацію він може читати?
• Коли йому необхідно просити схвалення?
• Що відбувається, коли інструмент не працює?
• Як запобігти циклам та повторним діям?
• Як хтось може відновити причину прийнятого ним рішення?
• Як оцінити робочий процес, який триває 30 хвилин, замість однієї відповіді?
• Що відбувається, коли модель помиляється, але є впевненою у своїх рішеннях?

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

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

• Інструменти: з чим може взаємодіяти агент.
• Контекст: яку інформацію йому показують.
• Стан: що він пам’ятає між кроками.
• Дозволи: що йому дозволено змінювати.

Зворотний зв’язок: як модель дізнається, що щось пішло не так.

Оцінка: як вимірюється успіх.

Межі: коли модель повинна зупинитися або передати керування людині.

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

Складність схильна до зміни, а не до зникнення

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

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

У деяких аспектах менш важливий, у інших — більше

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

Приблизний розвиток виглядає так:

• Раніше: модель підключалася майже безпосередньо до додатку.
• Зараз: модель знаходиться після промптів, технологій RAG, інструментів, агентів та процедур оцінки перед тим, як потрапити до додатку.
• У майбутньому: модель та фреймворк разом утворюють автономну систему.

Останній крок є найважливішим. Як тільки ШІ починає не просто генерувати відповіді, а й виконувати дії, ключовим питанням стає вже не лише рівень інтелекту моделі, а й те, наскільки добре спроектоване оточення навколо неї.

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

Щоб вирішити, де інвестувати, розподіліть кожен компонент комплекту на одну з двох груп:

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

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

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

Основні висновки

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