Bestu starfsvenjur við samhæfingu gervigreindarfulltrúa: meðhöndlun bilana, samþykkis og endurtilrauna

Að hafa marga gervigreindarfulltrúa að vinna að sama verkefninu hljómar afar skilvirkt. Einn skipuleggur vinnuna, annar sér um hönnunina og sá þriðji skrifar kóðann. Það virkar – þangað til það hættir að virka. Og bilanir verða oftar en þú myndir vilja.

Til að koma í veg fyrir þessar bilanir þarf vandaða hönnun verkflæðis. Skoðum því hvað gerir samhæfð verkflæði óáreiðanleg og förum yfir bestu starfsvenjur við samhæfingu sem tryggja áreiðanleika í raunrekstri.

Hvað er samhæfing gervigreindarfulltrúa?

Samhæfing gervigreindarfulltrúa samræmir marga gervigreindarfulltrúa, líkön og verkfæri til að ljúka verki í mörgum skrefum. En einhver – eða eitthvað – þarf samt að ákveða hvaða gervigreindarfulltrúi keyrir fyrst, hvaða upplýsingar hann fær og hvað gerist eftir að hann lýkur sér af. Þetta er hlutverk samhæfingaraðilans – gervigreindarfulltrúa sem gegnir hlutverki stjórnanda eða keyrslulags sem stýrt er af hugbúnaði.

Í einföldu máli brýtur samhæfingarlag markmið niður í smærri verk, heldur utan um innbyrðis tengsl þeirra, felur réttum gervigreindarfulltrúum keyrsluna, stýrir sameiginlegu samhengi og tekur saman útkomuna.

Hvernig samhæfing gervigreindarfulltrúa virkar: Inni í keyrsluvélinni

Stækka

Skoðum hvað gerist eftir að þú felur samhæfingaraðila verk.

Tökum dæmi úr vinnustofu Perplexity um Computer: smíði mælaborðs með upplýsingum um viðskiptavini sem byggir á gögnum úr Salesforce, Snowflake, tölvupósti, dagatali og nýlegum fréttum.

1. Skilja markmiðið og skipuleggja vinnuna. Samhæfingaraðilinn byrjar á umbeðinni útkomu og brýtur hana niður í verk með skýrum innbyrðis tengslum. Í mælaborðsdæminu okkar felst það í því að safna upplýsingum úr ólíkum heimildum og breyta þeim í fullbúna afurð. Skipuleggjandinn ákvarðar hvaða skref eru háð öðrum og hver geta keyrt óháð öðrum.
2. Beina verkum til viðeigandi gervigreindarfulltrúa. Samhæfingaraðilinn finnur verk þar sem allar forsendur eru uppfylltar og felur sérhæfðum gervigreindarfulltrúum eða líkönum vinnuna. Verk sem eru háð öðrum bíða eftir forsendum sínum. Perplexity Computer notar mörg framsæknustu líkönin og beinir ólíkum hlutum verkflæðisins til kerfa sem henta þeim verkum. Þetta gerir einnig kleift að keyra óháða vinnu samhliða.
3. Keyra verkfæraköll í stýrðu umhverfi. Gervigreindarfulltrúar eiga samskipti við umhverfi sitt í gegnum verkfæri á borð við vefleit, forritaskil, tengd forrit, skráaaðgerðir eða keyrslu kóða. Keyrslulagið framkvæmir þessar aðgerðir og skilar niðurstöðum til gervigreindarfulltrúanna.
4. Miðla niðurstöðum og samhengi á milli gervigreindarfulltrúa. Þegar gervigreindarfulltrúi lýkur verki sínu þarf næsti gervigreindarfulltrúi í ferlinu viðeigandi úttak til að halda áfram. Afhendingarfærsla gæti innihaldið auðkenni verks, tilvísun í úttak, útgáfu skemu og lýsigögn um uppruna. Samhæfingaraðilinn samræmir þessar afhendingar og viðheldur um leið því samhengi sem þarf fyrir næstu skref. Það sem skiptir máli er að gervigreindarfulltrúar þurfa ekki að bera alla sögu vinnu allra hinna gervigreindarfulltrúanna í eigin samhengisgluggum.
5. Skrá keyrslustöðu aðskilda frá samhengi gervigreindarfulltrúa. Þegar gervigreindarfulltrúar hefja verk, ljúka þeim eða tekst ekki að ljúka þeim uppfærir keyrsluvélin varanlega færslu verkflæðisins með stöðu verka, keyrslutilraunum, tilvísunum í úttak og þeirri vinnu sem eftir er. Þessi færsla gerir samhæfingaraðilanum kleift að fylgjast með framvindu og halda áfram eftir truflanir án þess að treysta á stórt mállíkan (LLM) til að endurgera verkflæðið út frá samtalssögu.
6. Staðfesta niðurstöður og ákveða næstu skref. Þegar verk skilar sér athugar samhæfingarlagið hvort úttak þess uppfylli væntan samning og hvort forsendur næsta verks séu uppfylltar. Ef vandamál finnst getur verkflæðið snúið aftur í fyrra skref til leiðréttingar eða verið sett í bið. Annars heldur það áfram þar til því er lokið.

Margir hreyfanlegir hlutar eru að baki því sem virðist vera einföld samhæfing gervigreindarfulltrúa. Hvernig þú skipuleggur samræmingu gervigreindarfulltrúa ræður því hversu mikla stjórn þú hefur á keyrslunni. Og auðvitað fylgir allri þessari samræmingu aukaálag. Hún borgar sig því ekki alltaf.

Hvenær ættir þú að nota samhæfingu gervigreindarfulltrúa?

Íhugaðu samhæfingu margra gervigreindarfulltrúa þegar ólíkir hlutar verksins krefjast ólíkrar sérþekkingar, óháð vinna getur keyrt samhliða eða ekki er hægt að ákvarða næsta skref fyrir fram.

Samhæfing kemur því að gagni í þremur tilvikum:

• Verk krefjast ólíkrar sérhæfingar. Forritunarverkefni gæti til dæmis notið góðs af aðskildum gervigreindarfulltrúum fyrir skipulagningu, hönnun, þróun og yfirferð.
• Óháð verk geta keyrt samhliða. Í stað þess að einn gervigreindarfulltrúi ljúki öllu í röð geta margir gervigreindarfulltrúar unnið samtímis og skilað niðurstöðum sínum til samhæfingaraðila.
• Vandamálið er opið. Gervigreindarfulltrúar gætu þurft að kanna ólíkar nálganir, taka ákvarðanir og vinna saman í stað þess að fylgja fyrir fram skilgreindri röð.

Fyrir utan það er samhæfing bara kostnaðarsöm tískubylgja. Fleiri gervigreindarfulltrúar þýða líka meiri samræmingu og hugsanlega hærri tókakostnað.

„Ég byrja yfirleitt á einföldustu leiðinni og byggi ofan á hana. Ef við þekkjum skrefin og þau eru endurtekin er það líklega verkflæði. Ég sé aðeins ástæðu til að bæta við mörgum gervigreindarfulltrúum þegar þeir hafa ólík hlutverk, heimildir eða notendur,“ segir Josh Spilker, yfirmaður leitarmarkaðssetningar hjá AirOps.

Jafnvel þá skaltu vega ávinninginn á móti fleiri köllum í líkön, afhendingum, biðtíma og bilunarpunktum.

Högun samhæfingar gervigreindarfulltrúa: kostir og gallar

Þrjár algengar leiðir til að skipuleggja samræmingu gervigreindarfulltrúa eru miðstýrð, dreifstýrð og stigveldisbundin samhæfing. Val á réttri högun snýst um eina spurningu: Hver stýrir vinnunni og hvernig samræma gervigreindarfulltrúar sig hver við annan?

Miðstýrð samhæfing

Í miðstýrðri samhæfingu stýrir einn samhæfingaraðili ferlinu. Hann brýtur verkið niður, felur sérhæfðum gervigreindarfulltrúum vinnuna, fylgist með framvindu þeirra og tekur saman niðurstöður þeirra.

Stækka

Kostir og gallar: Miðstýrð samræming auðveldar að fylgjast með keyrslu og beita sameiginlegum reglum á einum stjórnpunkti. Samhæfingaraðilinn getur þó orðið flöskuháls og bilun í honum getur stöðvað allt verkflæðið nema kerfið styðji endurheimt.

Dreifstýrð samhæfing

Í dreifstýrðri samhæfingu samræma gervigreindarfulltrúar sig með beinni hætti í stað þess að treysta á einn stjórnanda til að taka allar ákvarðanir. Þeir geta skipst á skilaboðum, lesið sameiginlega stöðu og ákvarðað næstu skref sín sjálfstætt.

Stækka

Kostir og gallar: Gervigreindarfulltrúar geta starfað án þess að bíða eftir miðlægum skipuleggjanda, sem gerir þessa nálgun gagnlega fyrir könnunarvinnu og sjálfstæð framlög. En samræming verður erfiðari þegar gervigreindarfulltrúar eru ósammála, uppfæra sameiginlegar upplýsingar eða þurfa að komast að samræmdri niðurstöðu.

Stigveldisbundin samhæfing

Stigveldisbundin samhæfing víkkar stjórnandanálgunina út yfir mörg stig. Samhæfingaraðili á efsta stigi felur undirsettum samhæfingaraðilum ábyrgð og þeir samræma sína eigin hópa sérhæfðra gervigreindarfulltrúa.

Hugsaðu þér verkflæði í stórfyrirtæki sem nær til sölu-, fjármála- og lögfræðiteyma. Samhæfingaraðili á efsta stigi gæti falið hvern verkþátt samræmingaraðila á viðkomandi sviði. Þeir samræmingaraðilar myndu síðan stýra sínum eigin sérhæfðu gervigreindarfulltrúum og skila samantekinni niðurstöðu.

Þessi uppbygging getur hjálpað þegar verkflæði eru of umfangsmikil til að einn samhæfingaraðili geti stýrt þeim með góðum árangri.

Stækka

Kostir og gallar: Stigveldi gera teymum kleift að skipta með sér ábyrgð á samræmingu og hugsanlega meðhöndla bilanir innan einstakra greina. Þau fela þó í sér fleiri afhendingar, flóknari stöðustjórnun og meira rekstrarálag. Staðbundin endurheimt veltur líka á því hvernig vistunarpunktar og keyrslustaða eru útfærð.

Samanburður á þessum gerðum högunar:

Raðbundin keyrsla, samhliða keyrsla og keyrsla byggð á afhendingum

Það er einn greinarmunur til viðbótar sem vert er að skilja. Arkitektúrinn ræður því hver samhæfir gervigreindarfulltrúana. Keyrslumynstrið ræður því hvernig verkum þeirra miðar áfram.

Þetta eru þrjú keyrslumynstur:

• Raðbundin verkflæði: Gervigreindarfulltrúar vinna í fyrir fram ákveðinni röð og niðurstaða eins gervigreindarfulltrúa verður inntak þess næsta.
• Samhliða keyrsla: Sjálfstæðir gervigreindarfulltrúar vinna samtímis.
• Keyrsla byggð á afhendingum: Stjórnin færist á milli sérhæfðra gervigreindarfulltrúa eftir því sem verkinu miðar. Þetta nýtist þegar annar gervigreindarfulltrúi er betur í stakk búinn til að sjá um næsta skref, en hver afhending þarf þó að varðveita þær upplýsingar sem þarf til að halda áfram.

Mynstrin útiloka ekki hvert annað og þau samsvara ekki samhæfingararkitektúrum einn á móti einum. Markmiðið er að velja einföldustu uppbygginguna sem styður við hæði verkflæðisins, kröfur um samhæfingu og ásættanlega rekstrarbyrði.

Algeng mistök í samhæfingu gervigreindarfulltrúa

Allt getur farið úrskeiðis í samhæfingu, allt frá einföldum yfirsjónum til flókinna hindrana. Stundum getur gervigreindarfulltrúi jafnvel virst sinna starfi sínu rétt á meðan verkflæðið í heild bregst. Út frá reynslu fagfólks höfum við tekið saman nokkur algeng mistök sem liggja að baki óáreiðanlegum samhæfðum verkflæðum – hafðu augun opin fyrir þeim:

• Gloppóttar afhendingar milli gervigreindarfulltrúa. Stjórnandi sendir samantekna áætlun til sérhæfðs gervigreindarfulltrúa en í samantektina vantar takmarkanir, hæði eða útfærsluatriði.
• Ótímabær samantekt niðurstaðna (fan-in). Gervigreindarfulltrúi neðar í ferlinu byrjar að safna saman niðurstöðum áður en öllum verkum ofar í ferlinu er lokið.
• Óákvæðnar uppfærslur á sameiginlegri stöðu. Samhliða gervigreindarfulltrúar skrifa í sömu stöðulykla án vel skilgreindra sameiningarreglna. Eftir því hvernig rammaverkið meðhöndlar uppfærslur getur þetta leitt til glataðra skrifa, tvítekinna gagna, úttaks sem er háð röð eða misvísandi breytinga.
• Misræmi milli vistunarpunkta og hliðarverkana. Verk framkvæmir ytri aðgerð en vel heppnuð framkvæmd hennar er ekki skráð með varanlegum hætti áður en vinnslueiningin bilar. Við endurheimt sér stjórnandinn ólokið verk og keyrir það aftur.
• Kapphlaupsvillur þegar haldið er áfram eftir samþykki manneskju. Þegar keyrsla er sett í bið og henni síðan haldið áfram skapast sérstök samstillingarvandamál.
• Framsalslykkjur og margföldun endurtilrauna. Gervigreindarfulltrúar færa verk ítrekað hver til annars vegna þess að ábyrgðarsvið þeirra skarast, hæði eru hringlaga eða skilyrði fyrir verklokum eru óljós.
• Stýringum á fyrirmælastigi ruglað saman við öryggi í keyrslu. Stjórnandi getur sagt gervigreindarfulltrúum að nálgast ekki tiltekin tilföng eða framkvæma ekki viðkvæmar aðgerðir, en fyrirmæli til líkans framfylgja ekki heimildum stýrikerfis, takmörkunum á netkerfi eða heimildamörkum. Rannsóknir Perplexity á öryggisverkfræði varpa ljósi á hvers vegna gervigreindarfulltrúar geta farið yfir öryggismörk þegar þeir vinna að lögmætum markmiðum, jafnvel án illgjarnra fyrirmæla

Taktu eftir hversu ólík þessi mistök eru. Ótímabær stöðubreyting í verkraðara eða óljós skrif í ytra kerfi geta bæði leitt til rangrar niðurstöðu, en þau eiga upptök sín í ólíkum hlutum keyrsluferlisins. Þess vegna krefst áreiðanleg samhæfing meira en betri kvaðninga eða fleiri endurtilrauna.

7 bestu starfsvenjur í samhæfingu gervigreindarfulltrúa fyrir áreiðanleika í raunkeyrslu

1. Skilgreindu skýra verksamninga, viðtökuskilyrði og stöðvunarskilyrði

Óljós markmið og óskýr skilgreining á verklokum leiða oft til vonbrigða með niðurstöður gervigreindarfulltrúa. Lausnin er kvaðningarsamningur (verklýsing fyrir gervigreindarfulltrúa): komið ykkur saman um markmiðið, takmarkanir, úttakssnið og bilunarskilyrði áður en keyrsla hefst.

Hér er til dæmis hvernig þú gætir skilgreint samning fyrir gervigreindarfulltrúa sem á að laga samþættingarpróf sem bregst af og til:

• Markmið: Finna og laga orsök óstöðugs samþættingarprófs fyrir API greiðsluferlisins.
• Inntak: Frumkóði prófsins, villuannálar úr CI, nýlegar commit-færslur og viðeigandi forritskóði.
• Takmarkanir: Ekki gera próf óvirk, slaka á fullyrðingum eða breyta ótengdri hegðun forritsins.
• Væntanlegt úttak: Kóðaplástur, útskýring á rót vandans og niðurstöður prófakeyrslu.
• Viðtökuskilyrði: Prófið sem áður brást stenst í 10 keyrslum í röð og viðeigandi aðhvarfsprófasafn stenst.
• Bilunarskilyrði: Ekki er hægt að finna rót vandans, lagfæringin veldur aðhvarfsvillum eða nauðsynlegt prófunarumhverfi er ekki tiltækt.

En það er annar mikilvægur þáttur: hvenær á gervigreindarfulltrúinn að hætta?

Gervigreindarfulltrúi ætti ekki að halda endalaust áfram að ítra bara vegna þess að hann hefur ekki skilað fullnægjandi niðurstöðu. Skilgreindu hvað telst vel heppnuð verklok, hvenær skila á verki sem er aðeins lokið að hluta og hvenær á að hætta vegna þess að ekki er hægt að uppfylla kröfu. Settu hámark á framsalsdýpt og ítrunarmörk eða keyrslukvóta svo að óleyst verk verði ekki að endalausum lykkjum.

Aftur að CI-dæminu okkar. Þú gætir skilgreint eftirfarandi stöðvunarskilyrði:

• Árangur: Lagfæringin stenst 10 prófakeyrslur í röð og viðeigandi aðhvarfsprófasafn.
• Ítrunarmörk: Gervigreindarfulltrúinn má ekki reyna fleiri en tvær mögulegar lagfæringar.
• Keyrslukvóti: Gervigreindarfulltrúinn verður að hætta eftir 60 mínútur, jafnvel þótt vandamálið sé enn óleyst.
• Framsalsmörk: Gervigreindarfulltrúinn má framselja verk til eins sérhæfðs gervigreindarfulltrúa, án frekara framsals til undirfulltrúa.
• Verki lokið að hluta: Ef báðar tilraunir mistakast eða tímamörkin renna út skilar gervigreindarfulltrúinn niðurstöðum sínum, breytingunum sem reyndar voru og prófaniðurstöðum.
• Hindruð keyrsla: Ef prófunarumhverfið er ekki tiltækt hættir gervigreindarfulltrúinn og tilkynnir um hindrunina í stað þess að halda fram árangri.

2. Haltu stjórnendum einföldum og framfylgdu skipulögðum afhendingum

Stundum fela forritarar stjórnanda of mörg verkefni og í stað þess að samhæfa sérhæfða gervigreindarfulltrúa fer hann sjálfur að skrifa kóða, kemba eða framkvæma ítarlegar yfirferðir. Þetta skapar flöskuháls: stjórnandinn eyðir samhengiskvóta sínum í útfærsluatriði, tefur framsal og gerir ábyrgð á niðurstöðunum óljósa.

Leyfðu því stjórnendum að sinna sínu hlutverki og framfylgdu afhendingum með vísunum í áþreifanlegar afurðir: upprunalega verkið, viðeigandi inntak, úttaksafurðir, keyrslustöðu og öll óleyst mál.

Skoðum þetta dæmi: status: completed vísar til verksins sem gervigreindarfulltrúanum var falið, ekki alls verkflæðisins. Þar sem prófin eru enn pending ætti stjórnandinn ekki að samþykkja lokaniðurstöðuna.

3. Vistaðu stöðu verkflæðis varanlega og haltu vexti samhengis í skefjum

Samtalsferill gervigreindarfulltrúa er ekki áreiðanleg skrá yfir framvindu verkflæðis. Þegar samhengisgluggi hans fyllist getur sjálfvirk þjöppun fellt brott mikilvæg atriði. Og ef vinnslueining hrynur þarf næsti gervigreindarfulltrúi að vita hvaða skrefum var raunverulega lokið.

Ef gervigreindarfulltrúinn sem sér um kóðun býr til dæmis til plástur og hrynur síðan ætti næsta vinnslueining að sækja vistuðu afurðina og halda áfram frá skráðri stöðu verkflæðisins. En ef gervigreindarfulltrúinn ræsti líka ytri CI-keyrslu verður stjórnandinn að stemma þá keyrslu af sérstaklega áður en aðgerðin er endurtekin

Haltu því keyrslustöðunni aðskilinni frá vinnusamhengi gervigreindarfulltrúans. Vistaðu stöðu verka, keyrslutilraunir, lokin skref og vísanir í afurðir í varanlegri geymslu. Hlaððu á sama tíma aðeins inn þeim fyrirmælum, inntaki og niðurstöðum sem skipta máli fyrir núverandi verk gervigreindarfulltrúans í stað þess að troða öllum keyrsluferlinum inn í samhengisglugga hans.

4. Hannaðu endurtilraunir sem taka mið af villum og endurheimtanlega keyrslu verkfæra

Segjum að CI-gervigreindarfulltrúinn þinn ræsi prófakeyrslu en API-beiðnin renni út á tíma. Tókst ekki að ræsa prófakeyrsluna, eða setti CI-þjónustan hana í biðröð og glataði svarinu?

Þótt tímamörk renni út þýðir það ekki endilega að aðgerð hafi mistekist. Þess vegna þarftu að greina á milli villna áður en þú ákveður hvað gerist næst:

• Tímabundnar villur (429, 503): Reyndu aftur með takmarkaðri veldisvaxandi biðtöf og slembitöf og virtu Retry-After þegar það er gefið upp.
• Staðfestingar- eða heimildavillur (400, 403): Stöðvaðu eða lagfærðu undirliggjandi vandamál í stað þess að endurtaka sömu beiðnina.
• Óljós niðurstaða (tímamörk eftir mögulega skrift): Kannaðu hvort aðgerðin hafi tekist áður en hún er reynd aftur.

Athugið: Jafnvel villur sem má reyna aftur þurfa mörk. Settu tímamörk fyrir hvert verkfærakall, takmarkaðu fjölda endurtilrauna og heildartíma þeirra og framfylgdu heildarfresti fyrir verkflæðið svo að hreiðraðir gervigreindarfulltrúar geti ekki endalaust endurræst sömu aðgerðina. Ef hæði bregst ítrekað skaltu nota rofa (circuit breaker) til að stöðva beiðnir tímabundið.

Fyrir aðgerðir með ytri hliðarverkunum skaltu úthluta föstum idempotency-lykli á hverja rökræna aðgerð og endurnýta hann í öllum endurtilraunum. Ef API-ið styður tvítekningarvörn á þjóninum getur það greint endurteknar beiðnir án þess að framkvæma aðgerðina tvisvar. Ef ekki skaltu senda fyrirspurn til ytra kerfisins með tengiauðkenni (correlation ID) eða annarri áreiðanlegri tilvísun.

Þegar þú getur ekki staðfest hvað gerðist skaltu stöðva og vísa málinu áfram.

Dæmi um rökvísina á bak við endurtilraunir CI-gervigreindarfulltrúans okkar, sett fram í sauðakóða:

Athugasemd um kóðann: Dæmið gerir ráð fyrir að CI-API-ið styðji uppflettingu keyrslna eftir beiðnaauðkenni. Gildið request_id kemur aðeins í veg fyrir tvítekningar ef veitandinn ábyrgist idempotency sérstaklega. bounded_retry() er sauðakóði til skýringar. Í raunkeyrslu ættu endurtilraunir að takmarkast bæði af endurtilraunakvóta fyrir hverja aðgerð (hámarksfjölda tilrauna eða liðnum tíma) og heildarfresti verkflæðisins.

Fyrir lengri verkflæði sem ná yfir margar þjónustur skaltu íhuga Saga-mynstrið til að samhæfa mótvægisaðgerðir þegar síðari skref mistakast. Hafðu þó í huga að mótvægisaðgerð jafngildir ekki alltaf fullri afturköllun. Þú getur afturkallað uppfærslu á gagnagrunni en þú getur ekki afturkallað tölvupóst sem hefur verið sendur.

5. Beindu verkum og keyrðu þau samhliða með skýrum tilfangakvótum

Hér þarf að vega tvennt hvort á móti öðru: hversu mikla getu líkans hvert verk þarf og hversu mörg verk þú getur keyrt samtímis. Ef annað hvort atriðið er rangt metið áttu á hættu að gervigreindarfulltrúar keppi um sameiginlega API-kvóta eða reiði sig eingöngu á dýr rökhugsunarlíkön.

Varðandi val á líkani skaltu laga getu líkansins og umfang rökhugsunar að flækjustigi verksins – einfalt en oft vanrækt. Athugaðu að þú getur annaðhvort stillt beiningarreglur og metið líkön sjálfur eða notað samhæfingarvettvang sem sér um val á líkani fyrir þig.

Til dæmis gerir Effort Mode í Perplexity Computer þér kleift að velja hversu mikla vinnu verk á skilið án þess að velja líkan handvirkt. Veldu Light, Standard, High eða Ultra og Perplexity velur sjálfkrafa stjórnlíkanið og rökhugsunarstig þess. Sá stjórnandi framselur síðan undirverk til gervigreindarfulltrúa sem aðstoða og geta notað líkön frá ólíkum veitendum.

Perplexity metur stillingar líkana með tilliti til gæða og kostnaðar og velur frekar ódýrari kosti sem skila sambærilegum niðurstöðum. Þú getur einnig notað Custom-stýringar ef þú vilt frekar velja líkanið og rökhugsunarstigið sjálfur.

Varðandi samhliða vinnslu ættu mörkin að ráðast af innviðum þínum og þeim ytri kerfum sem verkflæðið er háð. Staðfestu tíðnitakmörk beiðna og tákna hjá sameiginlegum API-þjónustum og álagsprófaðu síðan verkflæðið með sífellt meiri samhliða keyrslu. Fylgstu með hvort afköst batni eða hvort beiðnir fari að safnast í biðröð, hægja á sér eða skila 429-villum.

Til að halda tilfanganotkun fyrirsjáanlegri skaltu framfylgja tilfangamörkum og tímaáætlunarstýringum:

• Stjórnaðu samhliða vinnslu og tíðni beiðna: Takmarkaðu fjölda kalla í vinnslu á hverja þjónustu og settu umframverk í biðröð. Hafðu í huga að hámark á samhliða vinnslu eitt og sér framfylgir ekki takmörkum á beiðnum eða táknum á mínútu.
• Fylgstu með tákna- og kostnaðarkvótum: Haltu utan um notkun í öllu verkflæðinu, þar á meðal hjá undirfulltrúum, og hættu að ræsa ný verk þegar eftirstandandi kvóti dugar ekki.
• Framfylgdu keyrslufrestum: Settu tímamörk fyrir verk og verkflæði og láttu afturköllun berast til gervigreindarfulltrúa í keyrslu þar sem það er stutt.
• Taktu mið af hæðum milli verka: Ræstu verk neðar í ferlinu aðeins þegar nauðsynlegt inntak þeirra er tiltækt, í stað þess að ræsa alla gervigreindarfulltrúa samtímis.

6. Framfylgdu samþykktum og einangraðu keyrslu gervigreindarfulltrúa

Biddu líkanið aldrei um að meta hvort eigin aðgerðir þess séu öruggar. Veittu gervigreindarfulltrúum í staðinn lágmarksheimildir og framfylgdu áhættumiðuðum samþykktarreglum í forritskóðanum. Ef gervigreindarfulltrúar keyra kóða skaltu einangra þá keyrslu frá hýsilumhverfinu og takmarka aðgang að skrám, netkerfum og auðkennum. Þetta takmarkar skaðann ef gervigreindarfulltrúinn gerir mistök eða keyrir óöruggan kóða.

„Ég er efins um óþarflega flókin kerfi með mörgum gervigreindarfulltrúum, sérstaklega þegar gervigreindarfulltrúar fara yfir og samþykkja verk hver annars. Það getur endað með því að nokkrir gervigreindarfulltrúar láti sömu mistökin ganga áfram af fullu öryggi án þess að nokkur grípi þau í raun,“ varar Spilker við.

Stækka

Fyrir aðgerðir sem krefjast samþykkis manneskju skaltu gera hlé á keyrslu og vista nákvæmlega þá aðgerð sem lögð er til:

• færibreytur hennar
• marktilfang hennar
• commit-færslu hennar eða útgáfu stöðunnar
• ákvörðun yfirferðaraðilans

Skilgreindu einnig hvað gerist ef samþykki er synjað, það rennur út eða þarf að vísa því áfram. Þetta skiptir sköpum fyrir rammaverk sem hægt er að halda áfram í, þar sem kóði er keyrður aftur frá upphafi hnútsins þegar haldið er áfram með rofinn hnút. Allar hliðarverkanir sem urðu fyrir rofið geta því keyrt aftur.

Ef samþykki er því synjað eða það rennur út er beiðninni lokað. Ef commit-færslan sem miðað er við, færibreytur eða heimildir breytast fyrir keyrslu skaltu ógilda samþykkið og óska eftir nýju.

Spilker styður heldur ekki þá hugmynd að fullkomlega sjálfvirkir gervigreindarfulltrúar sem sjá um allt ferlið frá upphafi til enda séu markmiðið. „Að mínu mati er betri leið að smíða nokkra afmarkaða gervigreindarfulltrúa með skýr ábyrgðarsvið, skilgreindar heimildir og yfirferð manneskju á réttum stöðum. Þannig næst samt skilvirkni án þess að gefa eftir fulla stjórn,“ segir hann að lokum.

7. Sannreyndu úttak með óháðum hætti og prófaðu hegðun við endurheimt

Hefur gervigreindarfulltrúi einhvern tímann tilkynnt Success þegar honum mistókst í raun? Það er pirrandi, ef ekki óþolandi, og lagfæringin er ekki fljótleg því lokaskilaboð gervigreindarfulltrúans segja þér ekki endilega hvar eitthvað fór úrskeiðis.

Til að rannsaka málið skaltu rekja hvað gerðist í keyrslunni og sannreyna niðurstöðurnar með óháðum hætti. Gefum okkur því tíma til að einangra og leysa vandamálið.

Rektu verkflæðið til að finna hvað fór úrskeiðis

Áður en þú kembir kvaðningar gervigreindarfulltrúa skaltu skrá alla keyrsluleiðina. Þú þarft rakningu sem tengir saman köll í gervigreindarfulltrúa, verkfærakoll, villur og endurtilraunir undir sömu keyrslu verkflæðisins.

GenAI-merkingarvenjur OpenTelemetry bjóða upp á staðlaða leið til að lýsa þessum aðgerðum. Til dæmis auðkennir invoke_workflow keyrslu verkflæðis, invoke_agent kall í gervigreindarfulltrúa og execute_tool verkfærakall. Hverja aðgerð má skrá sem span með tímasetningu, stöðu og viðeigandi lýsigögnum.

Þetta skref gefur þér rakningu á keyrsluleiðinni svo þú getir fundið hvar gervigreindarfulltrúi hnaut.

Dæmi um keyrslurakningu til skýringar.

Farðu yfir úttakið á óháðan hátt

Notaðu forritaðar athuganir hvar sem því verður við komið. Staðfestu úttak gagnvart JSON-skemum, keyrðu einingar- og samþættingarpróf, athugaðu hvort nauðsynlegar afurðir séu til staðar og sendu fyrirspurnir til ytri kerfa til að staðfesta að aðgerðir hafi raunverulega tekist.

Fyrir úttak sem krefst huglægs mats – og er því ekki hægt að meta með forrituðum athugunum – skaltu bæta við óháðum gervigreindarfulltrúa sem sér um yfirferð. Ein nálgun er lykkja útfærsluaðila, yfirferðaraðila og úrlausnaraðila, þar sem einn gervigreindarfulltrúi býr til afurð, yfirferðaraðili með ferskt samhengi greinir vandamál og úrlausnaraðili tekur á þeim áður en staðfesting er keyrð á ný.

Þú þarft samt að sannreyna niðurstöður yfirferðaraðilans þar sem það er hægt og ef þú notar matsaðila byggða á LLM fyrir endurtekið mat skaltu kvarða mat þeirra gagnvart dæmum sem fólk hefur farið yfir.

Kallaðu fram bilanir til að prófa endurheimt

Hingað til hefur þú rakið hvað gervigreindarfulltrúarnir framkvæmdu og kannað hvort úttak þeirra væri rétt. En hvað gerist þegar vinnsluferli hrynur í miðju verkefni eða API rennur út á tíma eftir að hafa tekið við beiðni? Það kann að koma á óvart að verkflæðið þitt geti virkað fullkomlega við eðlilegar aðstæður en farið úrskeiðis við endurheimt.

Til að prófa þetta skaltu framkalla bilanir vísvitandi í prófunarumhverfi:

• Hermdu eftir því að API-köll renni út á tíma
• Láttu vinnsluferli hrynja á milli skrifa í ytri kerfi og vistunarpunkta
• Skilaðu gölluðu úttaki frá verkfærum
• Láttu samþykki renna út

Eftir hverja prófun skaltu skoða keyrsluferilinn til að sjá hvaða skref voru keyrð, hvar verkflæðið hélt áfram og hvort einhverjar aðgerðir voru endurteknar eða þeim sleppt. Farðu síðan yfir raunverulegu niðurstöðurnar.

Segjum að CI-fulltrúinn þinn sendi beiðni um að hefja prófunarkeyrslu en að API-svarið renni út á tíma. Fulltrúinn reynir aftur, fær svar um að aðgerðin hafi tekist og tilkynnir Tókst. Allt virðist í lagi þar til þú skoðar CI-þjónustuna og kemst að því að tvær prófunarkeyrslur voru stofnaðar í stað einnar.

Þess vegna ættir þú að staðfesta bæði skráða stöðu verkflæðisins og raunverulegar breytingar í ytri kerfum. Endurheimtarprófun ætti aðeins að standast þegar verkflæðið nær væntanlegri stöðu án óviljandi hliðarverkana.

Bættu þeim bilunum sem þú finnur við aðhvarfsprófanirnar þínar svo að síðari breytingar valdi þeim ekki aftur.

Þegar öllu er á botninn hvolft þýðir árangur að verkflæðið hafi staðist nauðsynlegar athuganir og að ytri niðurstöður þess hafi verið staðfestar.

Algengar spurningar um samhæfingu gervigreindarfulltrúa

Hvers vegna bregðast einangraðir gervigreindarfulltrúar í rekstri stórfyrirtækja?

Einangraðir gervigreindarfulltrúar geta leyst einstök verkefni sín rétt af hendi en samt skilað ósamræmdum niðurstöðum þegar á heildina er litið. Ímyndaðu þér að gervigreindarfulltrúi í sölu sæki skilmála viðskiptavinar kl. 10:00, annar í verðlagningu reikni út tilboð með uppfærðum verðum kl. 10:05 og sá þriðji, í lögfræðimálum, yfirfari samning sem breyttist kl. 10:07. Hver þeirra vinnur með ólíka skyndimynd af rekstrinum, svo úttak þeirra getur stangast á.

Vandinn verður meira áberandi í stórfyrirtækjum vegna þess að gervigreindarfulltrúar eiga samskipti við mörg kerfi sem uppfærast óháð hvert öðru, hafa ólíkar heimildir og deila ekki endilega samhengi eða keyrslustöðu.

Hvernig kemur þú í veg fyrir endalausar endurtilraunalykkjur hjá gervigreindarfulltrúum?

Settu takmörk á mörgum stigum: hámarksfjölda endurtilrauna verkfærakalla, hámarksfjölda ítrana fulltrúa, hámarksdýpt framsals og heildarfrest fyrir verkflæðið. Flokkaðu bilanir áður en reynt er aftur. Fyrir tímabundin 429-svör skaltu virða Retry-After þegar það er gefið upp. Annars skaltu nota takmarkaða veldisvaxandi bið (exponential backoff) með slembiflökti (jitter).

Hættu að endurtaka óbreyttar beiðnir eftir villur í sannprófun eða heimildum. Ef þjónusta neðar í keðjunni bilar ítrekað getur rofi (circuit breaker) komið í veg fyrir að fulltrúarnir valdi auknu álagi.

Hvernig heldur þú verkflæði gervigreindarfulltrúa áfram eftir hrun?

Endurheimtaraðferðin fer eftir keyrsluumhverfinu þínu. Í LangGraph geymir varanlegur vistunarpunktsbúnaður (checkpointer) á borð við PostgresSaver stöðu grafsins undir thread_id, sem gerir kleift að halda keyrslu áfram frá vistaðri stöðu. Í Temporal getur annað vinnsluferli endurbyggt verkflæði með því að spila atburðasögu þess aftur. Við endurspilun eru áður skráðar niðurstöður aðgerða endurnýttar.

Ef forritið er sett upp á ný á meðan verkflæði eru enn í keyrslu er ekki víst að vistuð staða og keyrslusaga séu lengur samhæfðar. Temporal tekur á þessu með Worker Versioning og plástrun verkflæða. Í kerfum sem byggja á vistunarpunktum skaltu skipuleggja skemabreytingar og prófa endurheimt út frá fyrirliggjandi vistaðri stöðu áður en ósamhæfðar breytingar eru teknar í notkun.

Hvernig prófar þú áreiðanleika samhæfingar gervigreindarfulltrúa?

Keyrðu sömu dæmigerðu verkefnin mörgum sinnum og greindu á milli pass@k (hvort a.m.k. ein af k tilraunum tekst) og pass^k (hvort allar k tilraunirnar takast)

Mældu niðurstöður eftir verkefnaflokkum og útgáfum verkflæðis í stað þess að treysta á eitt samanlagt árangurshlutfall. Fylgstu með árangri í fyrstu tilraun, samræmi milli endurtekinna keyrslna, p95-svartíma, kostnaði á hvert lokið verkefni og hlutfalli verkefna sem krefjast mannlegrar íhlutunar. Gefðu upp úrtaksstærðir og óvissubil fyrir árangurshlutföll.