Чаму прадакшн-агентам патрэбна больш, чым добры промпт
Прадакшн-агентам патрэбны не толькі добры промпт: кантэкст, інструменты, памяць, апрацоўка збояў, назіральнасць, тэсціраванне і ўзровень аўтаноміі, адпаведны рэальнай рызыцы.
Крыніцы: AI Agents Are Easy to Demo. Production Is the Hard Part.
У дэмантным прыкладах агент на базе ШЫ выглядае практычна занадта проста. Дасты ШЫ-модэлю мету, падключыш ціх некалькі інструментаў, дадзеш яго памяць і загорнуш у цыкл — і раптам ён прыме рашэнні, вызывае API-я, шукае дакументы і выканана задачы; першы прыклад стварэння такога агента здаецца чымсь на кшталт магіі. Самае справжняя інжынерная праця пачынаецца тады, калі агенты вікорыстоўваюцца у рэальных умовах.
Як толькі вы пасвятаваеце достатнько часу сістэмам агентаў, цэнтральная проблема зменяецца. Зробліць модэль дастатнька розумной больш не ёсць складным задачэм. Складнейшыя пытанні — гэта як загорнуць хутры, але недэтэрміністычны компонент у сістэму, чыя загальная працэздатнасць застаецца прыгадным. Практычна кожны архітэктурны выбор вынікае з гэтага.
Больш, чым проста ШЫ-модэль з інструментамі
Звычайна стэншора гаворыць, што агент — гэта LLM плюс інструменты плюс памяць. Гэта падходзіць для адказа на запытанне пра сутнасць, але недастаткова для практычнага выкарыстоўвання, дзе патрэбна болей шырока формула: разумаванне, кантэкст, інструменты, стан, рабочы працэс, правіла керавання, можлівасць абзярнага спостэрэння і вяснавання проблем. LLM мае значэнне, але ён — толькі адна з складовых.
Возьмем прыклад агента для аналізу дакументаў. Пользоватэль завантажывае файл і прасіць аб аналізе. За гэтым адным запытам сістэма можа быць змушаная:
- Пераканацца, што запыт ў правільным фармаце.
- Выявіць інформацыю з дакумента.
- З’явіць неабходны кантэкст.
- Склаць правільны запрос для мадэлі.
- Змусіць мадэль разумаваць на аднойчынных дапамогах.
- Пераканацца, што мадэль вернула правільныя рэзультаты.
- Застосавіць дадатковыя інструменты.
- Расчысляць рэзультаты, якія павінны быць точнымі.
- Зберагчы вынік аналізу.
- Падаць інформацыю пра прагрэс на інтэрфейс.
- Прабавіць знову тое, што не выйшла адрабатыць.
На гэтым етапі праца ужо не ёсць простым праектуванням. Гэта праектування розподыленоі сістэмі, якая віпадково містыць LLM. Чытке розподылення обов’язків допомагае.
Вхідні даныя і кантэкст
Кантэкст включае все, што агент знае про поточне задачы: інструкціі корыстувача, документы, запісі базі даных, стан робочого працэсу з поперэдніх кроків, отрымані знання і метадані застосунку. Основній урок полягае у тому, што надмірній кантэкст за замовчуванням не допомагае. Надання мадэлі усяго можа створыты шум, підвішчыты вітраты і ускладніты прогнозування іі міркувань. Метою мае буты найменшый кантэкст, які все шчэ дозволяе прыйняты рышэння.
Рывень міркувань
Хто такі LLM — гэта тыя, якія здолваюць свае завадзі. Яны можуць адначытаць неясную інфармацыю, чытаць дакументы, парабяляваць доказы, выбіраць інструменты, пісаць адказы, класіфікацыяваць рэчы і планаваць наступны крок. Аднай правілу трэба падкрэсліць: не давайце модэлю ніякіх рашэнняў, якія звычайны код можа надзеянна прыняць.
Сказаўм, правілу бізнесу ёсць variance <= 5% → PASS. Нікому не трэба LLM, каб выявіць, чы 3,8% меньш за 5%. Проста вылічыце гэта. Вывядзіце модэль там, дзе патрэбны разумовыя выводы, а код — там, дзе можліва дэтэрміністычнасць. Такое раздзеленне значна спрыяе тэставанню сістэм агентаў.
Інструменты робяць агентаў корыстнымі
LLM без інструментаў пераважна опісвае дзеянні. Калі ён ужо оснашчаны інструментамі, ён іх выконвае. Тыповыя інструменты – цэе пошук, базы дадзеных, API, адзыскванне дакументаў, выконанне коду, внутрашнія службы і сістэмы рабочых практык. Звычны ляміт працы – ад запіту корыстніка да агента, які выбірае інструмент, выконвае яго, стараецца за тым, што вернулася, і продовжае працу.
Гэта сутнасьц ReAct-шаблона: разумеў, дзействаваў, стараўся за рэзультатамі, а потым зноў разумеў. Ён ўзлёгкі, таму што агенту не трэба знайсці всі факты з самага пачатку – ён можа знайсці тое, што яму трэба, падчас выканання задачы.
Кожны ўстатку таксама можа стаць прычыной неудачы. API можа выйсці з ладу, кантэнты абмові можу выйсці за тэрмін дзейнасці, база дадзеных можа перастаць працаваць, ўстатку можа вернуць некарэктныя даны, а мадэль — неправільныя аргументы. Выкліканне ўстатку ніколі не должна значыць адправкі запіту LLM да API і спадзявання на найкрашчае. Для працы ў працэсах віробніцтва неабходны перакананне даных, таймауты, павторныя спробы, апрацоўка адзінакоў, правыя належнасці і чыста апісаныя станы неудачы.
Памяць — гэта не спосаб прыкопвання дадзеных
Памяць ўваходзіць у чысло найбольш неправільна разумеваемых аспектаў праектавання агентаў. Інтуіцыя паводзіцца з думкай, што агент, які памятае больш, становіцься розумнейшым. Але часта так не ёсць. Калі зберагаць кожную взаімадзею назаўсёды і включыць яе ў пасляўскія запіты, агент будзе отрымляць шум, а не памяць.
Дапамагае думаць па шарах:
- Рабочая памэць зберагае тое, што неабяжна для тэкушчага заведамення, такіе як стан рабочага прыему, рэзультаты няўжоўных інструментаў і проміжныя вылічэння.
- Даўгавечная памэць зберагае тое, што ўжыткова для разных заведаменняў, такіе як прыярытэты, факты, падтвердзеныя раней, і історычныя рэзультаты.
- Зовнішняя інформацыя — гэта даны, якія вучоўся ў іншым месцы і запрашваюцца толькі за патрэбай, такіе як дакументы, правілы, запісы базы дадзенаў і рэзультаты вектарнага пошуку.
Неабяжны вопыт — не гэта, сколькі агент можа запамятаць, а гэта, што яму неабяжна ведаць зараз. Гэты невелікі перакід можа значна спростыць архітэктуру.
Будзьце аберажны з многамі агентамі
Мульты-агентныя схемы ўражаюць. Коордынатор можа распадзіцца на агента для обработкі дакументаў, агента для даследжэння, агента для парадактывання і агента для стварэння звятынаў, пры чым кожны з яных адпавядае за спецыялізаваную частку задачы. На дыяграме гэта выглядае прывабліва, але гэта не павінна быць стандартным пачатковым пунктом.
Кожны дапамоглівы агент прыносіць новыя вопыты, новыя пераходы станоў, новыя формы абэкцэі, новыя межы кантакту, большу затрымку і ўсё больш пунктав для дыбаггіну. Адны агент з тромя хорашымі інструментамі часта працюе лепшая, чым чатаро агентаў, якія спілкуюцца межы сабою.
Практычныя правіла — пачынаць з самай простой схемы, якая рашае задачу, і дадаваць агента толькі тады, калі можна чыста сформулюваць патрэбу ў незалежным разумаванні чыя-небудзь адпаведальнасці. Дызайн мульты-агентных сістэм павінен рашаць архітэктурную задачу, а не проста робіць візуальны фартат прываблівым.
Планаванне на случай абэкцэі
Уявіце сабэрбот, які завантажуе дакумент, выкарыстоўвае яго для выдзялкі контэнту, збірае неабходную інфармацыю, аналізуе ёё, запускае відпаведны інструмент і стварае атлас. Аднойчы пасля аналізу сабэрбот зупіняецца. Чы усё пачынаецца занова? Чы ў базе дадзенаў ужо былі запісаны якія-небудзь даны? Чы можна без апасцерагання запускаць гэтую операцыю два разы? Чы інтэрфейс яшчэ паказвае, што заданне выпаловаецца? Чы іншы сабэрбот можа яго перэйняць?
У такім случыку традыцыйная інжынерыя бэкенду становіцца неабходнаю. Сабэрботы, якія працуюць у рэжыме продакшну, патрабуюць:
- Павторныя спробы, каб тымчасовыя неудачы не зіпсавалі весь сабэрбот.
- Ідэмпатэнтнасць, каб павторныя спробы не стваралі дублікатных наследкіў.
- Тачкі перагляду, каб длігі сабэрбот ведаў, якія крокі ўжо завершыліся.
- Таймауты, каб сабэрбот не працаваў безканечна.
QUEUED → RUNNING → COMPLETED або QUEUED → RUNNING → FAILED → RETRYING.Нічга з гэтага не здаецца настолькі захоплюючым, як інжынерыя запітоў, пры тым самэ гэта і ёсць тое, што робіць агентаў надзеянымі.
Пагляд на тое, што зрабіў агент
Звычныя прыкладнікі ужо патрабуюць логаў і метрык. Агентам патрабуецца больш. Калі агент даў паслабы рэзультат, інформацыя пра тое, што HTTP-запіт вернуў 200 OK, майжэ нічога не гаворыць. Важлівы ўсі працэс: запіт, атрыбуты кантэксту, стварэнне запіта, вызов мадэлі, выбор інструмента, адработка інструмента, ацэнка рэзультата і заканчоўны адпаведзь.
Для кожнай адработкі команда павінна магчымаць вярнуць наступнае:
- Кантэкст, які быў даны агенту
- Мадэль, якая была запушчана
- Інструменты, які былі выкарыстаны, і ў какой спраўе
- Час, прабачаны на кожны крок
- Спраўліванне токенав
- Прычына неудачы, чы гэта інфраструктура чы логіка
- Рэшчэнне на кроцы ацэнкі
Гэта адна з прычын, чаму трасуванне і ацэнка сталі такімі важлівымі элементамі экасістэмы агентаў. Тое, што не можна спазірваць, нельга паспрабаваць падбіць.
Тэставанне недэтэрміністычнага паведання
Класычныя програмы праставляюць з сабою простая правіла: вхідны даны А дае выходны рэзультат Б. LLM-ы не прымушваюць да гэтага, адколі два правыдныя адказы можу быць сформульаваны абсалютна разна. Таму тэставанне патрабуе калькі слоёў.
Дэтэрміністычныя часткі тэстуюцца звычным спосабам: API-я, выліканні, схемы, пераходы станоў і операцыі з базай дадзеных. Часткі, якія керуюцца модэлем, ацэнююцца па фактычной правільнасці, полнасці, рэлевантнасці, якосці аргументаў, выбору інструментоў і выпэлненні інструкцый. Рэалістычныя робочыя практыкі з початку до канца должны працаваць на рэпрэзентатыўных дадзеных, таму што яны выявляюць проблэмы, якіх не бачаюць ізольаваныя запіты. Нават моцны набор не можа пакрыць кожны рэальны вхід, таму цыкл ацэнкі продовжваецца пасля развяртання.
Аўтонамія должна сочыць за рызыкам
Дзеякія прыпускаюць, што „рэальны“ агент павінен быць цалкам аўтонамным. Такой падход ігнаруе ролю рызыка. Пораўняйце тры дзеянні: падсумаванне дакумента, рэкамендацыя змены фінансавай запісі і автаматычны выконанне транзакцыі з вялікім уплывам. Яны не должны выкарыстоўваць адной і той жа модэлі затверджэння. Практычны падход выглядае так:
- Нізкі рызыкі: выконваецца аўтаматычна.
- Серэднія рызыкі: выконваецца, пасля чаго фіксуецца ў журнале або пераглядаецца.
- Высокія рызыкі: патрэбна згода чалавека пры выконанні.
Мета — не максымальная автонамія. Гэта корыстная автонамія з контролюемымі рызыкамі.
Усё гэта дае чыстае адображэнне сітуацыі, і LLM выступае як стосунна невялікая частка ў ёй. Гэта свядома.
Пытанні пры выборэ фрэймворку
Перыяду пры выборэ фрэймворку або напісанні складзенага запіту варта задаць наступныя пытанні:
- Какое рашэнне практычна патрэбуе AI? Адзін крок аргументацыі не робіць усю рабочую практыку інтэлектуальной.
- Што можа застацца дэтэрміністычным? Расчытанні, паўтарэнне перакананняў, правы на выканання задач і крытычныя бізнес-правілы патрабуюць рэалізаціі ў кодзе.
Інжыніерыя запросаў, выбір модэляў і тэхналогія RAG застаюцца важлівымі. Аднак у практычным прыменэнні трэбаецца шырэйшая дысцыпліна: архітэктура працоўнага праграмнага забезпечэння, створаная на адной з прыметаў правалібістскай інтэлігенцыі. Найлепшыя рашэння — не тые, у яых больш агентаў, большы модэль чы самая сучасная сістэма керування. Гэта тые рашэння, у яых можна чытка адзначыць, што ведае агент, што ён можа і не можа робіць, як адметрабаваецца правільнасць, што выходзіць з-пад контролю і як сістэма восстанавляецца. Толькі тады AI-агент перэстаён быць простам дэманстрацыйным прыкладам і стаён праграмнай продукцыяй, якой можна даваць доверлівасць.