Выклік інструментаў: як мадэлі просяць праграмы дзейнічаць і дзе гэта ламаецца
Практычны агляд function calling і выкарыстання інструментаў: цыкл запыту, схемы, інструменты чытання супраць інструментаў дзеяння, агенты, MCP, ін’екцыі ў промпт, трасіроўка і тыповыя збоі.
Крыніцы: Function Calling and Tool Use: How AI Agents Automate Workflows
Першыя чат-боты былі прыстроямі для адказаў на запытанні. Чалавек пісаў што-небудзь, прыходзіў адказ, і на тым абменак завершаліся. Гэта было корыстна, але жорсткая структура. Мадэль могла опісаць, як забронюваць рэлігію, не магчымая вырахаваць цены на сёння. Яна могла поясніць, што ўключае ся ў рахунок-фактуру, але ніколі не могла стварыць яго ў сістэме білінгу. Яна могла запропанаваць час зустрэчы, але не мела можлівасці пераглядаць календар каго-небудзь, не кажучы ужо пра тое, каб дадаць заход у яго.
Выклік функцыі знімае гэты бар’ер. Мадэль мовы паводзіцца можлівасць прагучаць дапамогі у суседнім програмнаму забезпечэнні, і весь рэст сістэмы развіваецца на адной гэтай можлівасці.
Мадэль, якая можа прасіць пра ўсё
Без інструментаў мадэль адпавядае на пытанні на адваге таго, што ўсваяла пад час навчання. З інструментамі яна можа вывесты, што пытанню патрэбна зусільна дапамога, і сказаць, які інструмент трэба вікорыстаць: служба паветарных даных, індэкс пошуку, запыт да базы дадзеных, калькулятор, календар, працэс платэжа, запыт у CRM, інтэрпрэтар коду чыясьць внутраняя бізнес-функцыя. Уместа таго, каб здагадвалася, мадэль выдае структураваны запыт, прыкладнэць яго выпалняе, а мадэль продовжае працаваць, маючы ў руках свежыя і болей тачныя даны. Вялікія прадаўцы, такія як OpenAI, Anthropic і Google, а таксама фрэймворкі на кшталт LangChain, апісваюць вікорыстоўванне інструментаў адной і той жа шырокай манерай: модэлі прысвойваюцца чытка апісаныя інструменты, яна выбірае, калі іх вікорыстаць, перадае структураваныя аргументы і адлучае рэзультаты, якія ўзяты, да свайго адпаведзення чыясьць дзеяння.
Прыткая вярбальная адпрацоўка: модэль — гэта «мозг» для дыялогу, а інструменты — рукі, вочы, памяць, калькулятар, шафа для дакументаў і фургон для доставкі. «Мозг» вырашае, чаго хоча ўжоць. Інструменты выкананяюць тыя задачы, якія не можа безпечна чы рэліябельна выконаць простае стварэнне тэксту.
Выклік функцыі проты выкліку інструмента
Этыя два выразы часта вжываюцца як заменныя, але другі ёсць болей точным, каліткі ідэя выходзіць за межы класычных функцый програмавання. Інструмент можа быць настолькі простым, як get_weather(location). Ён таксама можа быць пошукам у базе дадзенаў, сесіяй браузера, выкарыстоўваннем дакументаў, калькулятаром, камандай шэлу, працэсам дызайну чы лінкам да зовнішньяго сервісу. У слоўніку OpenAI інструмент — гэта можлівасць, якая ўпускаецца ў вядомасць модэлі, а выклік інструмента — гэта спецыяльны тып адпаведзі модэлі, якая прасіць выкарыстаць адну з гэтых можлівасцей.
Чыгуннае значэнне — модэль зазвычай сама нічога не выкананяе. У стандартной канфігурацыі на баке кліента яна вяртае структураваны запіт, падобны вызову get_customer_profile з параметрам customer_id = 12345. Аплікацыя яго прыме, аналізуе, выкананяе рэальную функцыю, сабірае рэзультат і вяртае яго модэлі, якая пасля пішае свой заканчыцковы адказ. Дакументаваная последовасць: падаюць у наявнасці інструменты, прыходзіць вызов інструмента, выкананяе коду ў вашай сабе аплікацыі, прымыкаецца рэзультат, і прыходзіць або заканчыцковая адказ, або дадатковыя вызовы інструментаў.
Існуюць аднаковасці. Дзеяныя прадаўцы таксама размешчаюць інструменты на баке сервера, якія выкананяюцца на ўсіх іх інфраструктурах. Anthropic чыста раздзеляе гэтыя два варыянты: інструменты кліента выкананяюцца вашай аплікацыяй і праказуюцца як структураваныя блакі выкарыстоўвання інструментаў, тады як інструменты сервера, такія як пошук у інтэрнэце чы рэалізацыя коду, можаць выкананяцца на баке Anthropic.
Эта разліка мае важлівэе значэнне. Фраза «мадэль вызвала API» можа означаць, што мадэль створыла запіт, які трэба адкрыць у вашам програмнаму забезпечэнні, а можа таксама означаць, што платформа запусціла вбудованы інструмент зарады мадэлі. У рэальных умовах адзінэ гэта вплывае на рэгламенты безпекі, логаванне, вітраты, спосаб працы з данымі, тых, хто затверджае рашэнні, і тых, хто несе адпаведнае адпаведнасць, калі ўтвараюцца проблэмы.
Цыкл у пяць крокаў
Большасць сістэм вызову функцый перарабатвае адзін цыкл.
- Адакруцьце інструментаў. Кожны інструмент мае назву, апісанне і спіс апэкаваных вхідных дадзеных. Інструмент для паведамлення па пагодзе можа патрабаваць назву горада і краіны. Інструмент для вярнення грошаў можа патрабаваць ID замовлення, прычыну і максымальную суму. Інструмент для планавання можа патрабаваць імені учаснікаў, дату, час і тэму. Прыклады ад OpenAI опісваюць параметры у стылі JSON Schema з обав’язковымі полямі і абмежэннямі, такімі як additionalProperties, заданым як false, а дакументацыя Google Gemini паказвае заявленні функцый, створаныя на адваротах назв, апісанняў і структураў вхідных дадзеных.
- Пользоватэль прасіць пра ўтварэнне чаго-небудзь. Мадэль чытае запіт і выявляе, чы можа яна адразу даўаць адпаведзь. Запіт „Паспяшыце, што такое вызов функцыі“ верагатна не патрабуе інструмента. Запіт „Які статус замовлення 8472?“ практычна напэўна патрабуе інструмента.
Цыкл можа выконвацца аднае раз і ўтвараць многа петлі. Агент можа шукаць, парабяляць рэзультаты, вызываць іншы інструмент, ставіць дапаможныя запытанні, апдэйтаваць запісы, а пасля падсумавляць тое, што ён зрабіў.
Язык як інтэрфейс
Праўая прыемнасць вікорыстоўвання інструментаў заключаецца у тым, што повсякдзенны язык стае гнучкым фронт-эндам для програмнага забезпечэння.
Традыцыйна кожная функцыя патрабуе своіх кнопак, форм, меню і алгорытмав. За дапамогою вызову функцый корыстувач можа прымусова выразіць сваю мету: знайсці найняўлеглейшы рахунок-фактуру компаніі Acme, пераканацца, чыга прыйшлы платэжы, а як гэта не так — напісаць ввічлівы е-паштовы ліст-нагадванне. Адна рэчэнцыя маскіруе кальколькі інструментоў: пошук у CRM, запрашэнне рахунку-фактуры, перакананне статусу платэжа, праект е-пашты, а можа і запыт пра затверджэнне перш чым ўсё будзе апраўлена.
Хорашыя дызайны продуктов не ўтвараюцца неабяжнымі. Зменяецца толькі тое, дзе пачынаецца інтэрфейс. Уместо таго, каб людзі выучалі структуру програмнага забэгчыка, сам забэгчык павінен адпрацоўваць спосаб, якім людзі ужо размовляюць пра свою работу.
Гэта надае вялікага значэння апісацыям інструментаў. Неясная апісацыя не дапамагае модэлю зрозумець, як выкорыстоўваць інструмент. Чытальная апісацыя паказвае, калі яго трэба выкарыстоўваць, што ён робіць, што значыць кожны вхідны параметр і чаго не трэба прыпускаць. Дасягненні LangChain апісуюць інструменты як функціі з чытка вказанымі вхіднымі і выходнымі данымі, і зазначаюць, што падсказкі пра тыпы дадзеных і кароткія апісацыі дапамагаюць модэлю правільна іх выкарыстоўваць.
Хорашы інструмент — гэта не проста функцыя. Гэта контракт.
Чатыры тэрміны, якія перасягаюцься
Людзі плутаюць гэтыя словы, хоць яны належаць да разных рэвэў.
- Выклік функцыі — гэты механізм: мадэль просіць пра структураваны выклік функцыі або інструмента.
- Іспытанне інструментаў — гэта шырэйшая можлівасць. Яна включае выклік функцый, вбудованыя інструменты, пошук у інтэрнэце, пошук файлоў, выконанне коду, кантроль камп’ютара, даўневыя серверы і будзь-які іншы спосаб, пры якому мадэль можа зв’язвацца з зовнішнімі сістэмамі.
- Агент — гэта сістэма, якая выкарыстоўвае інструменты на кількох кроках для досягнення меты. OpenAI апісвае агенты як прыклады прыкладнікаў, якія плануюць, выкарыстоўваюць інструменты, работаюць з спецыялістамі і сочыць за прыбыллю паэтапных заданняў, а ў ўсяго SDK для агентаў агент апісваецца як LLM, настроены ўзмацненнямі, інструментамі і неабавязковымі элементамі, такімі як перадачы, правіла кантролю і структураваныя выходы.
Іншымі словамі: вызыв функцыі — гэта роз’ем, інструменты — гэта прылады, падключаныя да яго, агенты вяршаюць рашэнні пра тое, як і калі іх выкарыстоўваць, а автаматызацыя робіць так, юбы весь гэты працэс працаваў як частка жывога сістэмы.
Чаму гэта важліва?
Мадэлі мова добрая ў розумеўцы, спаўненні і перэдачы інфармацыі. Аднак яны не падходзяць як замена калькуляторам, базам дадзеных чы аператыўным манітарам. Яны можаць пісаць пра пагоду, але не можаць знайсці прогноз на сёньдзень, калі толькі не будуць падключаныя да відпаведных дадзеных. Яны можаць обсудзіць рахунок-фактуру, але не можаць з’ясавіць статус вашай сістэмы білінгу, калі тая не будзе падключаная. Яны можаць адказаць на запытанні пра код, але не можаць сказаць, чы працюе ваша служба, без дадзеных з монітарынгу.
Інструменты заполняюцыя гэтыя прыёмкі. Калькулятор забезпечвае надзею на правільныя арыфметычныя вычысленні. Апараты пошуку даюць актуальныя факты. Інструменты для выкарыстоўвання дадзеных апіраюцца на прыватныя дакументы для адказаў. Інструменты баз дадзеных адказваюць на запытанні пра дакументы компаніі. Інструменты для керавання рабочымі працэсамі ствараюць заявкі, адправляюць паведамленні, апдэйтуе ардэры чы бронююць кансэляцыі. У дасяглівых документах Google Gemini перакладаюць перадзеянні гэтых інструментоў у тры пункты: адбавленне знанняў, пашырэнне можлівасцей і дзеянне праз стороннія сістэмы.
Этам момант, калі такі відносіны перастаюць нагадваць простую перапіску і стаюць сэрцам супрацоўкі з програмнамі засобамі. Мадэль больш не толькі генеруе словы; яна таксама дапамагае коордынавацыі працы.
Даследжэнні, якія ляглі в основу гэй ідэі
Агенты, якія вікорыстоўваюць інструменты, не з’явіліся з нізкі. Чатыры ранейшыя даследжэнні паўтарылі і развілі гэтую галоўку.
- MRKL Systems (2022) запропанавалі модульную структуру, якая спаўнае мовныя мадэлі з зовнішнімі модулямі знанняў і логічных расчынанняў. Основная ідэя была простая: не прасіце адной мадэлі робіць усё; прадаўжыце кожную задачу спецыялізаванаму компоненту.
- ReAct (2022) даследаваў, як модэлі можаюць спалучваць разумаванне з дзеянням. У протыяўставаўцы да простага разумавання або простага дзеяння, падход ReAct паўзяе на тым, што модэль разумее, дзеяе, спазірае на рэзультат і корэгуе свой план. Такі цыкл павышае эфектыўнасць у задачах на адпаведзення на запытанні і прымэнне рашэнняў, а таксама спрыяе лёгкаму разуменню ўзору ўпрабаванняў модэлі.
- Toolformer (2023) пераканваліся, чы модэль можа сама научыцца выкарыстоўваць інструменты за дапамогою простых API. Яна выучылася, калі потрэбны інструменты, што падаць і як выкарыстоўваць рэзультаты, на прыкладах калькулятараў, пошуковых сістэм, перакладачаў і календараў.
- Gorilla (2023) спрамованы на масштабныя запыткі да API і на раштунак практычных проблем: усёлякія інструменты, якія існуюць, інодзе выклікаюць неабяжлівыя запыткі або задаюць некарэктныя параметры. Gorilla спалохвае навчанне з выкарыстоўванням готовых рашэнняў, тады сістэма можа сочыць за змянамі ў дакументацыі API і робіць меншае лічба памылак.
Усё гэта сведваецца да адной ідэі: найлепшыя сістэмы AI — гэта не адзінолькія мадэлі. Яны ўскладневаюць часткі большых сістэм, якія з’яўляюцца ў сувязі з інструментамі, памяцю, правіламі, програмнамі засобамі і людскім наглядам.
Як выглядае хорашы інструмент
Моцныя інструменты ёсць спецыялізаванымі, зрозумелымі і безпечнымі.
Інструменты спецыялізаваныя лёгкія для выбору мадэллю і для кантролю з боку распрацоўшчыкаў. Інструмент пад назвай update_everything ёсць нечыясным і небяспечным. create_refund_request ёсць болей ясным. approve_refund выклікае ўсё большую абераганосць, адколі ён вплывае на рэальны свет.
Зрозумелыя інструменты маюць простыя назвы і апісанні. Мадэль не павінна здагадватыся, чы роўна fetch_record означае запрашэнне профіля кліента, завантажэнне файлу чы выявленне медычнай карткі. У апісанні павінна быць указана яго мэта, сітуацыі, калі ён неабходны, значэнне кожнага аргумента і форма значэння, якое вяртаецца.
Безпечныя інструменты маюць вбудованыя ліміты. Яны пераканальваюць правыя на доступ, пераверачаюць вхідныя даны і утрымваюцца ад надання непатрэбнага доступу. Яны фіксуюць чыстыя паказанні праблем, ведуць журналы і запрашаюць пацверджэння ад чалавека перад выкананнем чутлівых дзеянняў. Яны ніколі не надаюць модэлі большых прав, чыяя нея нея неабходна для выпання задачы.
OpenAI рэкамендуе строгіяя схемы, каб аргументы прыходзілі надзеянна, а яго SDK для агентаў напамінае распрацоўшчыкаў пра неабходнасць наявнасці правілаў, перагляду з боку людзей, чыстых рэзультатаў, кантролю стану і можлівасці адзірвання пад час росту рабочых процэсаў. У практыцы найлепшыя інструменты ўсё часта ўсё простыя: кожны з іх добра выкананае адна задача і не стварае ніякіх неспакою ні распрацоўшчыку, ні модэлю, ні корыстніку.
Схемы як граматыка
Схема — гэта граматыка выкарыстоўвання інструментаў. Калі модэль вызывае функцыю, ён павінен падаць аргументы у фармаце, які розумее прыкладнэе програма. Схема вказывае, якія поля існуюць, якія ў іх тыпы, якія з іх ўскладненыя, а інодзе і якія значэнні дазволеныя. Інструмент для працы з парадкамі можа выказваць патрэбу ў строковым пазначэнні месца і полі з пазначэнням елементаў меры, якія можа быць толькі у градусах Цельсія або Фарэнгейта.
Строгія схемы зменшаюць неяснасці і спрошчуюць перакананне даных. У даследаванні OpenAI пояснюецца, што рэжым строгасці прымушвае запыткі дотрымвацца заявленай схемы, і ён выкалікае такія абмежэнні, як настройка additionalProperties на false для кожнага поля, пазначанага як неабяжнае, а таксама вікорыстоўванне тыпаў, якія дазволяюць значэнні без значэння.
Аднак схема сама па сабе не робіць сістэму безпечной. Запытка з ідэальным фарматам усё рава можа быць некальканая. Запытка send_email, надсыланая на all_customers@example.com, можа ідэальна падтрымліваць схему, але ўсё рава быць жахлівай ідэяй. Таму перакананне даных па схеме павінна супараджвацца з бізнес-правіламі, автарызацыяй, лімітамі колькасці запыткаў, этапамі перагляду і манітарынгам.
Чытанне проты дзеяння
Адна з важлівых рашэнняў у дызайне — чы хтоць з інструментаў толькі чытае, чы і дзеяе.
Інструменты з рэжымам чытання толькі запоўнююць інформацыю: шукаюць дакументы, вышукаюць запісы, перакантролююць запасы, аблекаюць даны пра парадгодзіны, вырахоўваюць сумы, аналізуюць лог-файлы. Яны ўсё ж можу павярнуць чутлівыя даны, таму іх трэба кантролюваць, але зазвычай яны нічога не зміняюць.
Інструменты для выканання дзеянняў рэалізуюць задачы. Яны аправляюць электранявісы, ставяць замовленні, анулююць падпіску, выдаюць вярненні, апдэйтуе базы дадзэнняў, ствараюць заявкі, размешчаюць код або плануе зустрэчы. Адныя прыклады ўпэўненняў у ўжыцці такіх інструментаў маюць рэальныя наследкі.
Якісна створаны агент разлічна ставіцца да гэтых двух тыпаў. Інструменты з рэжымам чытання толькі можна вільней вжываць, пры чым яны ўсё раване падлягаюць перакантролюванню па правамах. Інструменты для выканання дзеянняў зазвычай трэбуе строгей кантролі: экраны па падтверджэнні, этапы затверджэння, ліміты транзакцый, лог-файлы для аўдыту, можлівасці вярнення да пачатковага стану і чыстыя паведамленні для корыстніка.
У гэтым момэнцы аўтаматызацыя стае пытаннем управління, а не толькі тэхнічным. Ключовым ня ў тым, чы можа мадэль вызваць функцыю, а ў тым, за якіх умов сістэме павінна быць дазволена выконваць дзеяння за аднаго чалавека.
Ад адзіных вызоў да агентаў
Адзіны вызов інструмента можа даць адпаведзенне на простае запытанне. Агенты выкорыстоўваюцца для болей дзейнаўых і складных задач. Калі агента прасяць падготавіць ўзаемны выкладку продажаў за тыдзень і пазначыць рахункі, якія трэба адзірваць, яму можа знадобіцца збіраць даныя пра продажы, паўставляць іх з паканальнымі тыднямі, выявляць нестандартныя тэндэнцыі, чытаць запісы з CRM, напісаць выкладку і апрацаваць яе керавальніку. Гэта ланцуг рашэнняў, а не адзіны вызов.
Фрэймворкі агентаў карыстаюццася ланцоўкай задач. Яны зберагаюць стан, запускаюць інструменты, прабуюць зноў выконаць неудачныя крокі, перадаюць працу між спецыялізаванымі агентамі, ствараюць структураваны выхід, дазволяюць пэўныя правілы і ведуць логі задач. У дасягліх документах SDK OpenAI для агентаў опісваюцца два распашчастыя падходы: патэрн керавання, пры яком цэнтральны агент вызывае спецыялізаваныя агенты, як якія-то інструменты, і працэс перадачы контролу, пры яком адні агент перадае кераванне спецыялісту.
Агенты ўпэўненыя, так, але іх не трэба ідэалізаваць. Агент — гэта не маленькі працавальнік, які жыве ў вашам програмнаму забезпечэнні. Гэта верагатычная сістэма, створаная з коду, і яй патрэбны чыста вялікія адпаведнасці, обмежаныя правы, тэстовыя кейсы, монітарынг, шляхі для падняцьня проблемы і планы на случай неудачы. Чым больш свабоды мае агент, тым адказвальней павінна быць інжынерная праца навакол яго.
Дзе автаматызацыя зустрочаецца з рэальной працэю
Автаматызацыя — гэта стадыя, калі вікорыстоўванне інструментаў ператвараецца на аперацыі.
- Команда падтрымкі можа выкорыстоўваць агента для класыфікацыі заявак, запошуку актуальных дакументаў з правіл, падготавкі адпаведзей і прыдумвання наступных крокаў.
- Фінансавая команда можа супрацаваць з рахункамі-фактурамі, знаходзіць відсутнія замовленні на пакупку і готаваць адчыненія пра адхыленні.
- Інжынерная команда можа аналізаваць неудачныя тэсты, шукаць лог-файлы, прыдумваць способы выправлення і ствараць запросы на з’еднанне коду.
- Команда прыметкавання можа падрыхтаваць інформацыю пра потэнцыяльных кліентаў, готаваць нотаткі пасля каласоў і апдэйтаваць CRM.
Найэфектывнейшая аўтаматызацыя не выходзіць з таго, што можа зрабіць модэль. Яна выходзіць з існуючага рабочага працэсу. Дзе пачынаецца работа? Какую інформацыю яна патрэбуе? Калкія рашэнні ўжо ёсць стандартнымі, а калкія — чутлівымі? Дзе людзі зараз пераглядаюць, затвараюць або выправляюць? Калкія памылкі будуць раздражаючымі, а калкія — дорогімі?
Калі ёсць гэтыя адказы, інструменты дапамагаюць працэсу працаваць болей павольна. Агент збірае факты, запоўняе формы, прабывае тэксты паведамленняў, парабягае запісы і даёт рэкамендацыі, а людзі застаюцца учаснікамі там, дзе важлівыя суджэння, адпаведнасць і доверлівасць.
Стандартызаваныя з’яўленні
Першыя інтэграцыі былі індывідуальнымі. Кожны прыстаўкі меў свой спосаб выклікання інструментаў, рэсурсаў, запытанняў і автанацыі. Гэта працавала для малых праектаў, але ставала некантрольным, калі арганізацыі паў’язвалі больш модэляў з большымі сістэмамі.
Протакол кантэксту Модэля (MCP) — адна з спроб стандартызаваць гэты слой. Яго спецыфікацыя опісвае, як прыкладнія можаць дзеліцца кантэкстам, адкрываць інструменты і функцыі, а таксама ствараць гнучкія інтэграцыі за дапамою распараду хоста, кліента і сервера. Серверы MCP можаць запрошваць рэсурсы, запыты і інструменты. Протакол адмаўляеся за дапамою паведамленняў JSON-RPC 2.0 і абходзі тэмы перагавораў пра можлівасці, назірання за прагрэсам, анулювання, логавання і адчытання пра аблыкі.
Позытывныя аспекты ясны: спяльны слой інструментаў дазволяе прыкладненням на базе AI стабільна з’яўляцца ў зв’язку з джэрамі даных і рабочымі практыкамі, таму кожная компанія не павінна перзаснаваць кожную інтэграцыю. Негатывныя аспекты — новыя рызыкі. Сервер інструментаў, які прымае моцныя дзеянні, павінен быць прыкладненнем-хостам розглядзаны як справжняя межа безпекі, а не як ўсё толькі ўтварэнне-плагін. Самыя спецыфікацыі MCP акцэнююць на схваленні корыстувальніка, прыватнасці даных, безпеці інструментаў, а таксама на адпаведальнасці ў паводзе з несанкціонаваным доступам да даных і выкананнем коду.
Безпека — гэта прыорытэт
Агенты, якія вікорыстоўваюць інструменты, ўжоць ценныя, таму што яны выконваюць дзеянні, а гэтая ж здатнасць прыносіць рызыкі.
Введэнне запроса — гэта найвядомейшая аб’язка: ворагоўскія інструкцыі, спрывучаныя ў даныях ад корыстніка або з зовнішніх кантэнтав, якія змушаюць мадэль дзеяць так, як яе не трэба. OWASP уключае яе сярод галоўных рызыкаў для прыкладнасцей на аднойчынных нейронных мерэжах, а ў яе матэрыялах за 2025 год таксама адзначаеся надмерная самастоятэльнасць, калі сістэма, базаваная на LLM, мае большую можлівасць дзеяць, чым гэта розумна, таму нечаканы, неясны або маніпульаваны выхад можа прывесты да шкодзячых дзеянняў.
Непрамое введэнне больш заўсёды выклікае абавясці ў чызе з агентамі. Падазроўваючы, што агент чытае электранявісі і можа адправляць адпаведзі, зловольны адправальнік можа сховаць у паведамленні рэч, якая паведамляе яму ігнараваць сваія правілы і перадаць контакты корыстніка. Корыстнік можа ніколі не пабачыць гэтую рэч, але мадэль яе такі ж обрабоўвае. Калі сістэма занадта даверліва і мае занадта шырокія правыя, паведамленне, якое выглядае невінаватым, стае рэальным дзеяннем.
Команды з абяраннема безпекі пераходзяць да думкі, што LLM-ы ўможлівы ўвесты ў глухы кут толькі за дапамогою формуліравання, а не толькі за допамогою бягаў у кодзе. Нацыянальны цэнтр кібербезпекі Велікобрытаніі адзначае, што ін’екцыя запытанняяў разлічыцца ад ін’екцыі SQL, таму што LLM не выступае як строгі бар’ер межы між інструкцыямі і недоверлівымі дадзеннямі.
Эфектыўныя заходы абярання — цэлая сістэма захоўнага роўна:
- Як магчыма больш скрасіць правыя на вядомства інструментаў.
- Раздзеляць інструменты для чытання і інструменты для запісу.
- Абавесці згоду пры выкананні чутлівых дзеянняў.
- Вважаць усе, што атрымліваецца — будзь то веб-сторанкі, пісьмы, дакументы чы поля базы дадзеных — недоверлівым.
- Пераканаць кожны аргумент інструмента і працэсаваць выходныя даны, перш чым перадаць іх іншым сістэмам.
- Іспользаваць спіскі дазволенага, фіксаваць кожны вызов інструмента і сочыць за незвычайной дзеяльнасцю.
- Тэставаць інструменты з адварсальнымі прыкладамі і ствараць способы для анулювання дзеянняяў, калі гэта можліва.
Даюце агенту толькі тую колькасць праваў, якой насправды трэбуе рабочы працэс.
Адзірванне дзеянняў агента
Програмнае забезпечэнне з агентамі патрабуе ўсё багатшых справаздач, чым звычайнае програмнае забезпечэнне, адтолькі ў аднай працы можа быць уключана логіка модэля, вызовы інструментаў, перадача задач, перакананні ў сарабітнасці, пракаты і фінальны рэзультат. Адзірванне дапамагае распрацоўшчыкам стэп-зіроўна следзіць за всім шляхам ад запіту да рэзультата. За дакументацыяю да адзірвання для SDK Agents ад OpenAI, адзірванні можа фіксаваць генераванне LLM, вызовы інструментаў, перадачу задач, правіла сарабітнасці і спецыяльныя запісы, чым дапамагае командам дыбагаваць, візуалізаваць і сочыць за рабочымі працэсамі ў працэсе разработкі і эксплуатацыі.
Гэта мае значэнне для якосці і безпекі. Калі агент дае некарэктны адказ, трэба знайсці прычыну. Чы можа ён выбраў неправы інструмент? Чы інструмент вернуў застарэлыя даны? Чы мадэль неправа прачытала апісанне? Чы не працаваў захоўнік? Чы у карыстальніка не было прав? Чы агент зупініўся занадта рана? Без следаў каманды толькі здагадваюцца. З хорашай можлівасцю назірання стварэнне агентоў стае справжнейім інжынерным працэсам.
Як зазвычай выклікаюцца абыяківыя сістэмы
Абыяківыя сітуацыі ўможлівыя для прыкладзення. З боку мадэлі ёна можа выбраць неправы інструмент, калі назвы чы апісанні незрозумелыя, апрацаваць непূরныя чы некарэктныя аргументы, вызваць інструмент, калі трэба было задаць уточнюючыя пытанні, чы прыпусціць вызов, калі патрэбны свежыя даны. Яна таксама можа вызываць інструменты часта, што падвышае вартасць чы час адпаведзення, застрагнуць у цікле з паўтаральнымі вызамі без прыгоджэння, чы перасцягваты довер'е да рэзультатаў інструмента больш, чым гэта дапускаецца.
Програма таксама можа злучыцца. Яна можа прыняць аргументы, заданыя модэллю, без ўпэўнення ў ўсуненні памылак, адкрыць занадта многія інструменты адразу, вернуць вельмі вялікія і хаотычныя рэзультаты, якія плутаюць модэль, пракрыць корыстныя паведамленні пра памылкі, неправаць рэзультаты да тых вызоваў, якія іх створылі, або не мець журналав аўдыту, лімітаў на частоту вызоў і процедураў затверджэння.
Змены у запітах рэдка калі вырашаюць гэтыя проблемы. Рашэннем являецца крашчая разработка інструментаў, яснейшыя схемы, строгейшыя правыя на доступ, адпаведальнае кераванне станам, большыя тэсты і лепшы манітарынг.
Калі адмовіцца ад інструментаў
Выклік функцыі не завжды ўскладненне, якое неабходна. Калі для віканання задачы патрэбна толькі адпаведная адпаведнае поясненне, вікорыстанне інструмента толькі паўзіце працэс. Калі неабходная інфармацыя ужо ў запіце і не змінюецца, нема чаго запрашваць. Для дзеянняў з высокым рызыкам, якія не можна безпечна пераканаць чы анулюваць, абсалютная автаматызацыя можа быць неправым выборам. А калі выход інструмента ненадзеяны, не задокументаваны чы небезпечны, яго падключэнне да агента толькі паўзіце проблемы.
Корыстувачаўскі досвяд таксама мае свою цену. Выклікі інструментаў ствараюць затрымкі, запыты пра правыя адбіваюцца на прагэсе, а складныя агенты можу быць непераканальнымі. Інодзе простая форма лепшая за чат-робочы працэс, особліва калі корыстувачы ведаюць, чаго хочуць, і патрэбна якасць, адносна стабільнасць чы састаноўчаснасць.
Мета не ў тым, каб усё ператворыць у агенты. Выкорыстоўваце інструмент толькі там, дзе мова, кантэкст і дзеянне справжнім чынам супакоююцца.
Звычкі для эфектывнага будавання
Пачаткавайце з калькі незаплутаных інструментоў і толькі паступова расшырайце доступ да модэлі. Выбірайце спецыялізаваныя функцыі з простымі назвамі. Пішыце апісанні для модэлі, не толькі для інжынераў. Дзе толькі можна, выкорыстоўвайце строгіяя схемы і завжды перакананайце вхідныя даны у своем кодзе. Робіце выходныя даны короткімі і пасылайце модэлі толькі тое, што ёй насправды трэба.
Настаўляйце правыя на кожны інструмент окрэма. Агент з падтрымкі, які можа пераканацца ў статусе замовлення, не павінен автаматычна выдаваць вярненні грошаў. Памочнік з планавання можа патрабаваць інформацыю пра доступнасць календара, але не прыватныя нотаткі пра заходы. Памочнік з кодавання павінен магчымаць чытанне рэпазітарыю задоўга да таго, як ён зможа падаць запросы на з’еднанне коду.
Трэба, каб адпаведальная асоба падпісала ўсё чутлівае, дорогае, публічнае, прававая адносна обавязковае, фінансавае або такое, што важка абануць, і задавайце конкрэтныя запросы, каб пераглядач точна бачыў, што будзе рабіцца.
Супаўзяныя матэрыялы
- Іспытанне інструментаў у працэсе вырабаткі для агентаў: паходжанне параметраў, практыка павторных спроб і можлівасці абзірнасці — Агент банку здзейсніў занадто многія вызывы до платнага API і створыў вымышлены номер тэлефона. Дакладная інфармацыя пра мінімальныя наборы інструментаў, паходжанне параметраў, трыя рэжымы павторных спроб і показнікі для кожнага інструмента.
- Знімкі памяці агента, навыкі, працэс занікання даных і абмежэння памяці па галузях — Чатыры дапамогі для распрацоўкі агентаў на аснове вектарнай БД: перэносныя знімкі памяці з можлівасцю з’еднання, актывацыя навыкаў, контроль занікання даных у разы суперсчэплення і абмежэння памяці па конкрэтныя галузі.