Чы розумнейшыя моделі зменшыць значэнне агента чы ж зробяць яго ўсё важлівейшым?

Каля калькі гадоў, павышэнне якосці функцыйяў AI значна часта абыходзілася павышэнням якосці самага моделю: выбір сильнейшага модэлю, його налаштаванне, задаванне чыстэйых дадзеных і ўпрынцованне яго через API. Сэгодня ж система для прыменення моделю можа включаць функціі пошуку, памяці, інструментаў, планавання, адзыначэння якосці, стварэння можлівасцяў для спостерэння, захоўнікаў правіл, павторных спроб, кантролю контэксту і калькі саўместна працюючых агентаў, а загальны тэрмін для гэтага паверхневага шару — « Harness ». Гэта паднімае практычны вопыт для кожнага, хто выбірае, дзе пасвятіць час на розрабоцу: якшы моделі будуць продаваляцца, чы гэты шар стане менш значным, чы ён стане найважлівейшай часткой системы? У этам артыкуле рассматраюцца оба баку спору, і ён заканчываецца спосабам вярнага выбору тых частак вашага « Harness », якія, верагодна, зменшыцца, а якія — расліжуцца.

Што такое Harness і чаго ён не ўключае

Харнес — это програмна частка, якая абсалютваецца навакола модэлю і дапамагае яму адконанаць задачу надзейна. Модэль забезпечвае логіку; харнес стварае умовы, пад якімі гэтая логіка дае корисныя рынкі. У практыцы ён аб’еднвае кальколька аспектаў: доступ да інструментоў і API; запрашэнне, контекст і памяць; разбіўка работы на запланаваныя крокі і стежэнне за станам; перакананне выходных дадзеных, вярнэнне памылак і прабавы зноў; апэльнаванне праваў і захоўнікаў; а таксама вимераванне і спагляданне таго, што выкананаць.

Важным моментам ёсць тое, што кастоўванне спецыяльных інструментаў не мае на мету зробіць модель болей розумнай. Їё цэль — стварыць систему, якая ў цаласці будзе болей спроможная, надзеяная і безпечная. Возьмімо прыклад перакладу тексту ў SQL. Модель можа вясці, як пісаць запит. Інструменты даюць ёй схему, дазваляюць аналізаваць метаданы табелей, запускаюць запит, фіксуюць адныя, вяртаюць рэзультат або паведамленне пра адныя, запускаюць пракату ў разы потрэбы і дапамагаюць адначасова выявіць, чы рэшчанне є достатнім. Модель выконвае логічныя расыланні; інструменты забезпечваюць цикл, які ўскладнюе гэтыя расыланні. Гэты цикл стае найважлівейшым, калі модель виконвае больш, чым проста стварае текст.

Ёсць можласць дакладнейшае розглядзенне таго, як распадаюцца абавянні межы модэлі і канструкцыі ў адным агенте; для гэтага перайдзіце за адрэсай, дзе паказана прычына надзейнага паведання ШІ. Увага тут сконцэнтравана на тым, як гэты распад зменшваецца з часам.

Аргументы за простэйшую канструкцыю

Працоўна ўявіць, што кращыя модэлі патрабуюць меншай канструкцыйнай падтрымкі. Уявіце сабе модэлю, якая надзейна выканае всі наступныя задачы:

• Выпалняе складныя інструкцыі.
• Зберагае тое, што ўжо не патрэбна.
• Выбірае правы інструмент.
• Плануе задачы, якія складаюцца з многа крокаў.
• Вярна прыступае да работы пасля неудачы.
• Пераканальвае ся ў своіх рэзультатах.
• Видвае моменты, калі ёй неясна правільная адпаведь.
• Следзіце за станам працы працоўнага процэсу.

З такім моделюванням значная частка сучасных методаў організаціі працы выглядае зайвай. Болей сильныя алгорытмы спрощуюць патрабавання да явных роўнэў планування. Кращая аднародная работа з інструментамі зменшуе неабходнасць ручнага выбору інструментаў. Кращая обработка дзялёных контэкстаў зменшуе патрабавання да складных систем памяці. Надзеяна самаоцэнка зменшуе патрабавання да зовнішніх процэсаў па верыфікацыі.

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

Здольнасці расширяюць межы

Калі модэль становіцца значна здольней, команды рэдка выкорыстоўваюць гэтыя здольнасці проста для таго, каб выконваць тую ж работу дышча. Яны нарабатываюць іх для рашэння сложнейшых задач.

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

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

Спроможныя агенты ставяць запыткі системам

Падзірцем, якшо агенту з растучымі можлівасцямі будуць даўнае прыстрою для перегляду веб-сторонак, база дадзеных, внутршнія API, файлы, можлівасць выканання коду, інструменты для перадачы паведамленняў і дзейнае запамятованне, то інтэлект больш не будзе факторам, які лімітуе ўжо. Тады трэба адпавядаць на такія запитанні:

• Якія дзеянні можа выконваць агент?
• Яю інфармацыю ён можа чытаць?
• Калі яму трэба прасіць апраўды?
• Што выходзіць, калі інструмент не працуе?
• Як запобегчы ціклам і павтарэнню дзеянняў?
• Як хтось можа пераканацца, чаму агент прыняў певную рашэнне?
• Як ацэніць рабочы процес, які трывае 30 хвілін, а не дае аднае рашэнне?
• Што выходзіць, калі модель неправая, але впэўнена ў сабе?

Ніякую з эйх проблем не можна рашыць за дапамою болей разумнага модэлю. Болей супэльны модэль можа пагародзіць апошню задачу, таму што бяспераблівыя, адказныя памылкі важкае ўпазнаваць. Это проблэмы самай системы, і самэль тут становіцца важлівым інструмент «harness», а не трапляецца непатрэбным.

Ад оркестрацыі да дизайна средавішча

Большасць сучасных фрэймворкаў для агентаў сфокусаваныя на оркестрацыі: выборы таго, што будзе далей, які інструмент запускаць і што перадаць назад модэлю. Калі модэлі становяцца кращымі у самастойнам планаванні, гэтая логіка абараноў найбольш верагатна зменшыцца. Тое, што застаецца і расте, ближэй да дизайна средавішча. Інструмент «harness» вядомае:

• Інструменты: з чым можа взаімацца агент.
• Кантэкст: яя інфармацыя ў яго распаўсюджэнні.
• Стан: што ён памятае между крокамі.
• Правыя: што ёму дазволенае зменіць.

Адказ: як модель выявляе, што ўтыкнула.

Ацэнка: як вимеряецца успех.

Межы: калі яна должна зупніцца або перадаць кантроль чалавеку.

У такім падходзе модель атрымляе автаномію, а «упрэг» стае межай для гэтай автаноміі. Вы перестаеце пісаць шлях, які прыменяе агент, і пачынаеце формаваць прастор, праз які ён рухаецца.

Складнасць зазвычай перасілляецца, а не зникае

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

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

У дзеярых аспектах менш важлівы, у іншых — болей

Чыстая адказва — не адна і не другая. Конструкцыя для керавання становіцца менш важлівай як месца для ручнага компенсавання слабых модэляў. Яна становіцца важлівай як аднакоўшчык, який дазволяе здольным модэлям працаваць у рэальным свете, не становячыся небезпечнымі, ненадзеяннымі чырай марнатрацкімі. Будучыя конструкцыі для керавання можаць мець менш жорсткую оркестрацыю і значна болей суперфінансаваную ацэнку, правыя на выкорыстоўванне, стан, адзывы, можлівасць спостэрэння і кантроль апошней сяродавы.

Прыбліжны працэс развіцця выглядае так:

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

Пасёлковым крокам і ўсё завісіць. Калі ШІ перейдзе з стварэння адказоў да выканання дзеянь, ключовым пытаннем будзе не толькі ступень інтэлекту моделі, але і тое, насколькі добра спроектавана атмосфера навакола яе.

Практычны тэст для вашага прыладу

Ёжчы вырашыце, дзе інвеставаць, раздзеліце кожны элемент прыладу на адну з двух груп:

• Компенсацыйныя элементы існуюць таму, што нынешняя модель слаба ў чымсь: жорсткія планавальнікі крок за крокам, складная логіка аналізу та рэмонту выходных даных, направленне інструментоў на адповідныя ключавыя словы, способы адмахненняся ад патронавання. Храніце іх простымі та лёгкімі да адчынення, і ператеставаце іх ўсё час, калі апдэйтаваеце моделі, таму што саме воны часта станавяцца непрыдатнымі.

Існуюць стойкі элементы таму, што задача мае наследкі ў рэальным свете: правы прыступу і ізоляцыя, контрольныя пункты затверджэння, журналы аудыту і відстежэння, ліміты костаў і цыклаў, наборы для ацэнкі, стойкасць стану. Неабходна правильна інвеставацыя ў гэтыя элементы, адколькі болей спроможны модэль толькі падвышае ўжо існуючую цэннасць.

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

Ключовыя выводы

• Системны комплекс не робіць модэль умней; ён робіць цэлую систему болей спроможной, надзеянай і безпечной.
• Болей супернасныя модэлі, верагатывацельна, будуць спрыяць скарочэнню логікі керавання і альтернатыўных рашэнняў, і гэта варта узяць пад расчыт.
• Вышэйшыя можлівасці ведуць да шырэйшага масштабу, што паднімае пытанні пра правы на выконанне задач, адарожэнне нявыхода, ацэнку і адказнасць, на якія жадныя паследнія прабавы не даюць адказу.
• Система пераходзіць ад напісвання кожнага крока праз складанне среды: інструментаў, контэксту, стану, прав, адзывоў, ацэнкі і меж.
• Можна спакою чакаць, што сложнасць перайдзе ў інфраструктуру, а не знікне, таму будуйце тыя элементы вашай системы, якія маюць застацца стойкімі, з гэтым у ўвазе.