Resurssien ja kustannusten optimointi agenttiyritykselle
Itsenäiset agentit kuluttavat Salesforce-resursseja eri tavalla kuin deterministinen automatisointi. Agenttien työkuormat ovat odottamattomia ja jatkuvia, eikä kiinteitä ja transaktioihin perustuvia. Resurssien ja kustannusten optimoinnin pilarin arvon kustannusten mukaan -arvosana siirtyy suoraan agenttiyritykseen. Resurssien tehokkuus tarkoittaa, että käytät kapasiteettia, josta jo maksat, ja kustannusten optimointi tarkoittaa, että kulut ohjataan tarkoituksella itsenäisiin ominaisuuksiin, jotka ansaitsevat tuottoa. Agentit muuttavat molempien muotoa. Tehokas agenttien suunnittelu pitää kulutuksen ajan tasalla ja hinnoittelumallin valinta, kokonaisomistuksen kustannusten (TCO) mallinnus ja taloushallinta pitävät kulut tasalla arvon kanssa. Tämä asiakirja käsittelee resurssien tehokkuutta ja kustannusten optimointia yhtenä päätöksenä, koska agenteille he ovat kaksi näkymää samasta tavoitteesta.
Agentit muuttavat kulutuksen ennustettavuutta. Perinteinen Apex toimii tunnetulle tietuejoukolle, jolla on tunnetut resurssin kustannukset. Agentti toimii selkokielisesti, ja yksi keskustelu voi suorittaa kymmeniä toimintoja, jotka edistävät agentin tehtävää. Jokainen toiminto kuluttaa hallintarajoituksia omassa transaktiossaan sen sijaan, että se keräisi niitä koko keskustelussa. Kontekstiin valmistautuminen yhdelle kierrokselle saattaa kysellä 200 tietuetta tai 20 000, riippuen käyttäjän kysymyksistä. API-kulutus nopeutuu, koska agentit voivat toimia itsenäisesti ja ennakoivat, lähtevät ja ajoitetut agentit toimivat jatkuvasti, eivätkä vain käyttäjätapahtuman aikana. Tämä ei-ennustettavuus on syy, miksi agenttien resurssien hallinnan täytyy olla puolustavaa suunnittelussa sen sijaan, että sitä säädettäisiin kulutuksen nousun jälkeen.
Kustannusten puoli muuttuu yhtä paljon. Autonomiset agentit ottavat käyttöön kulutukseen perustuvan hinnoittelun, joka toimii eri tavalla kuin perinteinen per istunto -lisenssi. Agentforce tarjoaa kaksi kulutukseen perustuvaa hinnoittelumallia, Flex Credits ja Per-Conversation. Jokainen agenttien käyttöönotto valitsee yhden seuraavista malleista. Organisaatio käyttää yhtä kulutusmallia kerralla. , mutta käyttäjäkohtainen lisäosa, joka on tarjolla käyttäjäkohtaisesti kuukaudessa mittaamattomaan käyttöön, voi olla kerros kulutusmallin vieressä, jotta asiakaskohtaiset agentit käyttävät Flex-hyvityksiä tai Keskustelua kohti -toimintoa, kun työntekijät käyttävät mittaamattomia lisenssejä. Data 360 tukee agenttien maadoitusta vektorihaun ja -haun avulla ja kuluttaa datan käsittelykapasiteettia, kun taas MuleSoft ottaa käyttöön API-kapasiteettia kuluttavia agenttien integraatioita. Nämä muuttujien kustannukset skaalautuvat agenttien käytön mukaan, mikä luo sijoituskuvion, joka vaatii taloushallintaa, joka on rakennettu vaihtelevuudelle kiinteän vuositilauksen sijaan.
Ratkaisut, jotka on suunniteltu liiketoiminta-arvolle ja joilla on optimoidut kustannukset Agent Enterprise -organisaatiossa, pitävät agenttien kulutuksen tehokkaana joukkotoimintojen, kurinalaisten kontekstiikkunoiden ja välimuistiin tallentamisen avulla. He ohjaavat kulut myös tarkoituksella oikean hinnoittelumallin, täydellisen TCO-mallinnuksen ja jatkuvan kustannusvalvonnan liiketoiminnan lopputulosten perusteella. Ilman tätä kohdistusta agenttien käyttöönotot kertovat kustannuksia näyttämättä suhteellista arvoa, ja agentti, jonka syyt ovat rajoittamattomassa silmukassa, voivat polttaa krediittejä nopeammin kuin ihmisen valvonta voi puuttua. Sama tehostustyö, joka pitää agentin hallintarajoitustensa sisällä, pitää sen sen luotto-budjetin sisällä, joka on agenteilla ilmaistu pilariarviointi.
Tämä asiakirja kattaa muutokset, kun agentit ovat kuvassa. Kaikkiin Salesforce-ratkaisuihin liittyvät perusresurssien ja kustannusten optimoinnin kuviot, mukaan lukien suorituskyvyn optimointi, hallintarajoitukset, TCO-analyysi ja lisenssitiede, löytyvät kohdasta Resurssien ja kustannusten optimoinnin pilari. Agenttien hallinta ja henkilökohtainen valvonta liittyvät Trust- ja fairness -pylväisiin, jotka kattavat ohjelmakomponentit, jotka pitävät itsenäisen toimintatavan turvallisena ja vastuullisena.
Agenttien resurssien kulutus noudattaa samoja sovellusalustan mekanismeja kuin Kulku tai Apex, mutta sen ennustamaton, keskusteluun perustuva kutsu tekee kulutuksesta vaikeampaa ennustaa ja vaatii puolustusmallia. Optimointitehtäväsi kattavat hallintorajoitetun budjetoinnin toimintojen ketjuille, API-kulutukselle, vastausten viiveelle, Data 360 -pohjaisen tehokkuudelle, kontekstien ajanjaksojen hallinnalle ja yhdistettävälle rakenteelle, jonka avulla agentit voivat skaalaa ilman identtisiä tietueita. Jokainen vastuu on hintakohtainen päätös ennen teknistä, koska agentit toistavat tehottomuuksia jokaisessa keskustelussa.
Agentit kutsuvat toimintoja, jotka käynnistävät Apex, kulkujen ja integraatioiden. Yksi keskustelu voi suorittaa kymmeniä toimintoja monimutkaisessa tehtävässä. Peruspolku on sama kuin muillekin Salesforce-ratkaisuille, mutta ennustamaton kutsukuvio nostaa panoksia. Suunnittele toimintoja hyväksymään kokoelmia siten, että agentti, joka päivittää 50 tapausta, kutsuu yhtä toimintoa 50 erillisen puhelun sijaan. Yksittäinen toiminto, joka toimii tietueiden kokoelmassa, kuluttaa paljon vähemmän Salesforce Object Query Language (SOQL) -kyselyitä ja Datan manipulointikieli (DML) -operaatioita samalle työlle. Hallitse SOQL-budjettia toimintoketjujen välillä harkiten, koska 10–15 toimintoa kutsuva työnkulku voi lähestyä tai ylittää 100 kyselyn synkronointirajoituksen, kun jokainen toiminto suorittaa useita omia kyselyitään. Käytä suhdekyselyitä noutaaksesi päätiedot ja alitason tiedot yhdessä lausekkeessa ja viitataksesi sovellusalustan välimuistissa säilytettyyn dataan samassa keskustelussa oleville toiminnoille. Nämä kaksi käytäntöä pitävät monitoimintojen ketjun budjetissaan.
Siirrä synkronointirajoituksia ylittävät agenttitoiminnot jonoon tai erä Apexiin, jossa ei-synkronoitu konteksti on noin kaksinkertainen työhön käytettävissä olevan SOQL- ja CPU-päätilassa. Suuret analyysioperaatiot, kuten 1 000 liidin pisteytys tai sentimentin analysointi historiallisista tapauksista, kuuluvat ei-synkronoituun käsittelyyn sen sijaan, että ne estäisivät keskustelun. Suuren kielen mallin johtopäätökset tapahtuvat Salesforcen ulkopuolella ja kuluttavat Flex-hyvityksiä Apexin CPU-ajan sijaan, joten profiilissasi määritetyn CPU-budjetin kuluttavat toimintologiikka, datan transformaatiot ja agenttien käynnistämät integraatiot. Tietojen vääristymiskenaariot, joissa ylätason tietueet on liitetty tuhansille alitason tietueille, ansaitsevat erityistä puolustusta agenttien kanssa. Tämä haavoittuvuus johtuu siitä, että agentti voi pyytää "kaikkia historiatietoja" tilille, jossa on kymmeniä tuhansia asiaan liittyviä tietueita tavalla, jota deterministinen kysely ei koskaan tekisi. Suunnittele toimintoja, joilla on vahvoja alitason tietueiden rajoituksia ja sivutusta, ja käytä näytettä, kun määrät ylittävät datan lyhennyksen kynnysarvon. Nämä rajoitukset estävät ennustamatonta pyyntöä muuttumasta rajoittamattomaksi kyselyksi. Agentforce istuntojen jäljittäminen -ominaisuus tunnistaa toiminnot, jotka kuluttavat liikaa kyselyitä istuntotasolla, ja Scale Center valvoo Apex suorituskykyä ja organisaation kuntoa.
Agenttien arkkitehtuurit kuluttavat API-rajapintoja nopeammin kuin käyttäjiin perustuvat työnkulut, koska agentit toimivat itsenäisesti ja ennakoivasti tai ajoitetuille agenteille jatkuvasti. Agentin esitystapa määrittää, miten se vähentää API-kapasiteettia. REST API:n kautta kutsutut agentit kuluttavat yhden puhelun per keskustelun kierros. Vakiokomponenttien kautta Lightning upotetut agentit eivät kuluta API-kutsuja per vuorovaikutus, vaikka heidän kustannuksensa mitataan silti valitun hinnoittelumallin hyvityksissä tai keskusteluissa. Mukautetut Lightning, jotka aiheuttavat suoria REST-kutsuja, kuluttavat API-kapasiteettia. Lightning Data Service -sovittimille laadittuja komponentteja ei käytetä, koska Lightning Data Service toimii asiakassivun jaetusta välimuistista API-kutsun tekemisen sijaan. Valvo kulutusta tapahtumien valvonta -ominaisuudessa pilottiprosessin aikana, jotta ymmärrät todellisen käytön ennen täyttä käyttöönottoa.
Tapahtumiin perustuvat kuviot ovat suurimpia vaivaa agenttien kuluttamalle API:lle. Sovellusalustan tapahtuman julkaiseminen, kun ehto vaatii agentin interventiota, välttää ajoitetun kyselyn, joka kuluttaa API-kutsuja riippumatta siitä, onko töitä tehtävissä, ja Muuta datan taltiointi -tapahtumia tilaava agentti säilyttää ajankohtaisen asiayhteyden ilman päivittäisiä kyselykutsuja, joita ulkoinen orkestroija muutoin tekisi. Arvo per kustannus -logiikka on suora: Kysely, joka ei löydä työtä, on kapasiteettia, jota käytetään tyhjäksi, ja tapahtuma, joka käynnistyy vain todellisen muutoksen perusteella, on kapasiteettia, jota käytetään vain todelliseen työhön. Haun augmentoima generointi lisää omaa kulutustaan, koska jokainen Data 360 -kentän vektorihaku kuluttaa laskentaa, joten määritä haun rajoitukset palauttaaksesi vain tulokset, joita agentti todella käyttää.
Agentin siirron viive on LLM:n päättelyajan, toiminnon suoritusajan, Data 360 -kyselyn ajan ja integraatioajan summa, kun vaiheet suoritetaan järjestyksessä. Jos ei, se on pisin rinnakkainen haara sekä kaikki peräkkäiset vaiheet. Latency on kustannushuolestuttava sekä kokemusten huolenaihe, koska hidas toiminto pitää resurssit auki kauemmin ja turhautunut käyttäjä aloittaa enemmän keskusteluita kuin ratkaistu. Lyhyemmät kehotteet luovat nopeampia vastauksia, joten poista tarpeettomat ohjeet, tarpeettomat esimerkit ja tarpeeton konteksti. Selektiivinen konteksti parantaa sekä viiveitä että vastausten laatua, jossa kattava kontekstien roskaposti lisää vain melua. Pidä indeksoitujen kenttien, bulkkauksen ja välimuistiin tallennetun viitetietojen toiminnot nopeana valikoivan SOQL:n avulla, koska 3 sekunnin toiminto muuttuu pullonkaulaksi riippumatta siitä, kuinka nopeasti päätelmä tehdään. Vahvista toimintokyselyt Query Plan -työkalulla tunnistaaksesi täyden taulukon skannaukset, jotka kasvattavat toimintojen viiveitä.
Agent Builderin orkestrointi voi suorittaa toimintoja rinnakkain, kun niiden välillä ei ole sidonnaisuuksia, esimerkiksi tilin lisätietojen ja siihen liittyvien mahdollisuuksien hakeminen samanaikaisesti kestää niin kauan kuin ne ovat hitaampia kuin niiden summa. Jos puhelu lähetetään useisiin alempaan järjestelmään, yhdistä Agentforce integrointialustaan, kuten MuleSoft: agentti kutsuu yhtä toimintoa, MuleSoft vastaanottaa pyynnön ja lähettää rinnakkaisia puheluita taustajärjestelmiin, ja palauttaa sitten yhden aggregoidun vastauksen. Sovellusalustan välimuisti poistaa toistuvien pyyntöjen johtopäätöksen ja kyselyn viiveen, ja muiden kuin kiireellisten töiden, kuten pitkän asiakirjan analyysin, käsitteleminen ei-synkronoidusti sallii agentin hyväksyä pyynnön välittömästi ja palauttaa tuloksen, kun se on valmis sen sijaan, että keskustelu pysyisi avoinna.
Data 360 tarjoaa vektorihakun, joka perustelee agenttien vastaukset nykyiseen dataan mallin koulutusdatan sijaan, ja sen tehokkuus määrittää sekä perustamisen laadun että sen saavuttamiseen tarvittavan laskutoimen. Pilkkominen, upottaminen, metadatan suodattaminen ja tulosten rajoitukset ovat arvokkaimpia päätöksiä. Ryhmitä Knowledge semanttisesti merkityksellisiin segmentteihin, koska liian pienet lohkot pakottavat useita palautuksia yhdelle kysymykselle, kun taas liian suuret lohkot laimentavat relevanttiuden asiayhteydettömällä asiayhteydellä ja täyttävät valtuuksien budjetin johtopäätökseksi. Valitse upotusmalli, joka vastaa agenttiesi todellista kyselytapaa, koska kysymysten ja vastausten samankaltaisuus toimii eri tavalla kuin asiakirjojen luokittelu, ja vahvista valinta edustavien kyselyiden kanssa. Yhdistä semanttinen samankaltaisuus metadata-suodattimien kanssa siten, että liiketoimintarajoitukset säilyvät samankaltaisuudesta riippumatta, esimerkiksi jättämällä lopetetut tuotteet pois suosituksesta riippumatta siitä, kuinka lähellä vastaavuus on. Määritä top-k-rajoitukset palauttaaksesi vain agentin käyttämät tulokset. Jos esimerkiksi 5 tulosta tarjoavat vastauksen, 50 tuloksen noutaminen lisää 45 käyttämättömää tulosta maadoituksen tietosisältöön ja valtuuksien budjettiin.
Yhtenäistettyjä profiileja käytetään resurssitehokkaasti, koska yksi yhtenäistetty Data 360 -profiili kyselee agenttia hakeakseen asiakkaan koko asiayhteyden yhdessä operaatiossa sen sijaan, että se orkestroisi erilliset kyselyt Tili-, Yhteyshenkilö-, Mahdollisuus-, Tapaus- ja Kampanja-objekteihin jokaiselle kierrokselle. Määritä Data 360 -esiintymät alueisiin, joita lakisääteiset vaatimukset vaativat, jotta tietyn lainkäyttöalueen tietojen käsittelijät voivat kysellä henkilötietoja sisältävää instanssia.
Suuren kielen sisältävät kontekstiikkunat sisältävät rajallisen määrän valtuuksia, ja budjetin hallinta pitää pitkän keskustelun johdonmukaisena ilman, että kapasiteetti loppuu tai jokaisen päätelmäkutsun kustannukset kasvavat. Priorisoi tarkoituksella sen sijaan, että lyhennettäisiin satunnaisesti: viimeaikainen keskusteluhistoria on tärkein prioriteetti, kriittinen liiketoimintatieto, kuten tietueen tämänhetkinen tila ja käyttöoikeudet, tulee toiseksi, ja vanha historia sisällytetään mukaan vain, kun tila sallii. Ensimmäisten useiden vuorojen jälkeen voit tehdä yhteenvedon aiemmasta keskustelusta ytimekkääksi yleiskatsaukseksi, joka säilyttää tärkeimmät faktat ilman täyttä kirjaimellista historiaa. Tämä yhteenveto säilyttää jatkuvuuden kasvattamatta valtuuksien budjettia . Tallenna laajennettu konteksti Data 360 -tietueeseen tai mukautettuihin objekteihin ulkoisena muistina kyseltynä tarvittaessa sen sijaan, että toistaisit koko historian jokaisessa puhelussa, ja palauta vain kunkin toiminnon olennaiset kentät, koska vastaus, joka siirtää tietueen kaikki 50 kenttää, kun tehtävä tarvitsee 8, käyttää kontekstibudjettia paremmin keskusteluun tai perustamiseen.
Agenttien rakentaminen uudelleenkäytettävistä komponenteista vähentää kehitys- ja ylläpitokustannuksia. Kerran luotu ja uudelleenkäytetty ominaisuus on huomattavasti halvempi sen elinkaaren aikana kuin sama uudelleen käyttöönotettu ja erikseen ylläpidetty ominaisuus jokaiselle agentille. Tietueiden toimintoja, hyväksyntöjä, ilmoituksia ja vahvistuksia kattavat keskitettyjen toimintojen kirjastot sallivat sovellusalustan tiimien ylläpitää yhdenmukaista toimintatapaa, tietoturvaa ja suorituskykyä kaikille kuluttaville agenteille, ja ne sallivat uuden agentin kokoonpanon todennetuista rakennuspalikoista päivinä sen sijaan, että ne rakennettaisiin mukautetuista toiminnoista viikkoja. Keskitetyt asiantuntijaagentit, joilla on selkeät toimialueen rajat, ylläpitävät kapeampaa asiayhteyttä ja selkeämpiä toimintatapoja kuin yksi universaali agentti, joka yrittää kaikissa tilanteissa, ja Agent Builderin orkestrointi koordinoi asiantuntijoita, kun tehtävä ylittää toimialueet. Kehotteiden rakentaja vahvistetut kehotteiden mallit sieppaavat todennettuja kuvioita pohjautumiselle, perustelulle ja vastausten muotoilulle, jotta laatu pysyy yhdenmukaisena kehityksen nopeuttamisen myötä, ja datan 360-yhteinen Knowledge perustaa useita agentteja yhdestä lähteestä, joten päivitys saavuttaa kaikki kuluttajat kerralla eikä vaadi muutoksia jokaiselle agentille.
Yritystiimit tekevät yhä useammin useita agentteja yhdessä yksittäisten agenttien luomisen sijaan, kun orkestrointiagentti pilkkoo pyynnön ja delegoi sen erikoistuneille alaagenteille tai erikoistuneille agenteille, jotka välittävät sen toisilleen, kun keskustelu siirtyy toimialueiden välillä. Tämä koostumus nostaa esiin resurssin ja kustannusten kysymyksiä, jotka ylittävät yksittäisen agentin tarpeet, koska orkestroinnin ylimääräiset kustannukset, agenttien välinen Trust ja osavaltion myöntäminen yhdistyvät ketjuun sen sijaan, että ne jäävät yhteen toimintoon. Pidä orkestrointikehotteet kapeina, rajoittuen tarkoituksen luokitteluun ja reititykseen sen sijaan, että pyydettäisiin orkestrointia pohtimaan myös sen perustana olevaa tehtävää, koska tämä perustelu kuuluu alitason agentille, jolla on asiaankuuluva konteksti, ja rajoita ketjun syvyys, ellei käyttötarkoitus vaadi selvästi syvempää sisäkkäisyyden kuin orkestroija alitason agentille. Käsittele jokaista alitason agentin vastausta epäluotettavana input-arvona samalla tavalla kuin ulkoista API-vastausta. Vahvista sen odotettu muoto ja liiketoimintasääntöjen noudattaminen ennen sen käyttämistä. Käytä kenttätason suojausta ja jakotapaa erillään kullekin agenttitoiminnolle.
Välitä vain tila, jonka vastaanottava agentti tarvitsee, käyttämällä tietuetunnusten, tehtävien yhteenvedon ja asiaankuuluvien kenttien rakenteellista siirron hyötykuormaa sen sijaan, että välittäisit raaka-keskusteluhistoriaa, joten koko ketjun valtuuksien budjetti pysyy hallittuna ja säilyy agenttien välisen istunnon tilana Data 360:ssa tai mukautetussa objektissa, kun siirron täytyy säilyä eri transaktioissa. Hallintarajoituksia sovelletaan per agentti, ei kerran per keskustelu, joten jokainen ketjun agentti saa oman SOQL-, DML- ja CPU-budjettinsa. Orkestraattorin ja kolmen alitason agentin ketju kuluttaa kukin näistä rajoituksista neljä kertaa enemmän, ja syvemmät ketjut kertovat kulutuksen entisestään. Sama kerroin edistää kustannuksia, mikä tekee rajoittamattomasta ketjun syvyydestä kustannusriskin enemmän kuin hallintorajoituksen.
Määritä, mitä orkestroija tekee, kun alitason agentti epäonnistuu, aikakatkaistaan tai palauttaa epäluotettavan tuloksen, olipa kyseessä rajoitettu uudelleenyritys, varausvaste tai eskalointi ihmiselle, jotta yksittäinen alitason agentin aikakatkaisu ei johda koko ketjun epäonnistumiseen. Korjaa pyyntö jokaisesta agentista, johon se koskee, ja jaetun seurantatunnuksen, joka lisätään siirron tietosisällön kautta, koska ketjun agenttien diagnosointi aiheutti viiveen nousun tai kustannusten nousun muutoin vaatii manuaalisen korreloinnin lokeista eri agentti-istuntojen välillä.
Epäonnistuneet toiminnot ja epäonnistuneet alitason agenttikutsut vaikuttavat luotettavuuteen, koska jokainen uudelleenyritys saattaa suorittaa uudelleen epäonnistuneelle yritykselle jo käytetyt SOQL-, DML- ja CPU-työt, ja usean agentin ketjussa tämä kustannus yhdistetään epäonnistuneiden alaisten agenttien määrään. Kulutukseen perustuvassa hinnoittelussa samat virheyhdisteet kuluvat sekä lasketaan: uudelleenkäytetty toiminto kuluttaa krediittejä uudelleen Flex-hyvitykset-osiossa. Suunnittele uudelleenyrityslogiikka ottaaksesi huomioon sekä luotettavuuden että kustannukset. Erota väliaikaiset epäonnistumiset, kuten callout-aikakatkaisu tai lukon ristiriita, loogisista epäonnistumisista, kuten vahvistusvirhe tai väärin muotoiltu syöte, ennen kuin päätät, miten vastata, koska väliaikainen epäonnistuminen voi olla yhden rajoitetun uudelleenyrityksen arvoinen, kun taas looginen epäonnistuminen epäonnistuu identtisesti toistumisen yhteydessä ja polttaa vain budjetin takuulle toistuvalle epäonnistumiselle, joka pitäisi eskaloida välittömästi sen sijaan.
Ylläpidä uudelleenyrityksiä per toiminto kahdella tai kolmella yrityksellä ja sovella niiden välille eksponenttista rästityötä välittömän uudelleenkutsun sijaan, koska SOQL- tai DML-raskaan toiminnon rajoittamaton tai tiukka silmukkainen uudelleenyritys voi tyhjentää synkronoituja rajoituksia yhden transaktion sisällä tai polttaa kumulatiivisen ketjubudjetin ja kumulatiiviset luottojen kulut usean agentin keskustelussa. Suunnittele toiminnot siten, että uudelleenkäynnistetty puhelu tuottaa saman lopputilan kuin yksittäinen onnistunut puhelu, käyttämällä idempotency-avainta, kuten pyynnön tunnusta tai ulkoista tunnusta, jossa on upsert-logiikkaa lisäämisen sijaan, jotta uudelleenkäynnistys päivittää saman tietueen identtisten tietueiden luomisen sijaan. Toiminto, jolla ei ole idempotency-arvoa, pakottaa uudelleenkäynnistyksen joko kaksinkertaistamaan resurssin kulutuksen alempien tietueiden kaksoiskappaleilla tai kaksinkertaistamaan laskutettujen toimintojen tai keskusteluiden määrän jo kerran tapahtuneille töille.
Seuraa suorituksen tilaa per agentti ketjussa, koska yhden agentin toiminto voi sitouttaa DML:n onnistuneesti ennen kuin alempi agentti epäonnistuu, ja epäonnistumisen käsittelijä, joka tietää, mitä on jo onnistunut, voi korvata tai jatkaa epäonnistumista sen sijaan, että se käynnistäisi ja laskuttaisi koko ketjun uudelleen. Näytä uudelleenyritykset tai keskeneräiset tilat loppukäyttäjälle, kun rajoitettu uudelleenyritys on lennossa, koska käyttäjä, joka näkee hiljaisuuden ja toistaa pyyntönsä, käynnistää kokonaan uuden keskustelun ja uuden toimintojen joukon, mikä lisää alkuperäisen yrityksen resurssit ja laskutuskustannukset identtiseen.
Tässä asiakirjassa kuvatut resurssin optimointikuvioet auttavat vain, jos arkkitehti voi nähdä, missä agentti käyttää SOQL-kyselyitä, CPU-aikaa, DML-rivejä ja valtuuksia todellisuudessa tuotantoympäristössä. Ilman toimintokohtaista ja istuntokohtaista näkyvyyttä rajoitushäiriö tai viiveen regressio näytetään oireena, eikä sitä voi jäljittää takaisin sen aiheuttaneeseen toimintoon tai ketjun agenttiin. Tämä huolenaihe ei ole sama kuin Digital Walletin kustannusten valvonta- ja taloushallinta-osiossa tarjoama kulutusten näkyvyys. Digital Wallet näyttää, kuinka monta krediittiä tai keskustelua agentti kulutti, ja työkalu näyttää, miksi niitä kulutettiin yksittäisen kyselyn, DML-rivin tai toiminnon tasolla, joka aiheutti kyseisen kulutuksen. Oikea työkalu riippuu siitä, mitä tietyn asiakkaan organisaatio ja tukisopimus todellisuudessa myöntävät, eikä siitä, mikä työkalu on teoriassa paras, joten täsmää suositus lisenssisi ja käyttöoikeustason perusteella sen sijaan, että käytät oletusarvoisesti tehokkainta työkalua.
Mikä tahansa arkkitehti voi luoda mukautettuja sovellusalustan tapahtumia, jotka käynnistyvät kunkin toiminnon ja alitason agenttien kutsujen alussa ja lopussa. Nämä tapahtumat seuraavat koko keskustelun suoritusta käyttämällä vain sovellusalustan vakiotoimintoja ja toimintojen tason kirjaamista mukautettuun objektiin, joka kaappaa SOQL-kyselyiden määrän, CPU-ajan, DML-rivien määrän ja kunkin toiminnon suorituskerran kopion käytön. Molemmat tapahtumat ovat kyseltavissa raporteilla tai SOQL:n kautta ja tarjoavat jokaiselle organisaatiolle perusarvoisen diagnostisen ominaisuuden riippumatta Edition-versiosta tai lisäosalisensseistä. Tapahtumien valvonta -ominaisuus, joka otettiin käyttöön aiemmin API-kulutuksen seuraamiseksi pilottien aikana, esittää myös agenteille, joiden organisaatiossa on kyseinen lisäosa, agenteille organisaationlaajuisesti koottuja resurssien käyttömalleja, jolloin arkkitehti voi tunnistaa, mitkä työnkulut ovat suuntautuneet hallintarajoituksiin useissa keskusteluissa, eikä diagnosoida yhtä kerrallaan. Skaalikeskus tarjoaa syvällistä seurantaa hallintarajoituksiin lähestyvistä transaktioista, joita käytetään tavallisesti tukitoimintojen kautta tai jotka ovat käytettävissä suoraan tilitasoilla, jotka myöntävät sen.
Agenttien itsenäinen versiointi mahdollistaa hallitun julkaisun, periytymisen ja vertailun, ja se suojaa sijoituksen työstävään agenttiin, kun parannat sitä. Suorita toimintatapa kokoonpanon avulla aina, kun se on mahdollista, käyttämällä mukautettuja metadatatyyppejä ja Kehotteiden rakentajaa, jotta pääkäyttäjät voivat säätää kehotteiden malleja ja toimintojen valintoja ilman kehityssykliä. Käytä pilotti-A/B-testauksen kykyä reitittääksesi pienen määrän käyttäjiä kokeiluversioon. Vertaa laatua, tyytyväisyyttä ja tehtävien suorituskykyä ennen täyttä julkaisua. Tämä vertailu vahvistaa parannukset todellisessa käytössä ja havaitsee regressiot, kun altistusta on rajoitettu. Määritä komponenttien välille selkeät käyttöliittymäsopimukset, määrittämällä syötteet, tulokset, virheet ja suorituskykyennusteet, jotta toteutusta voidaan korvata muokkaamatta siihen kuuluvia agentteja.
Agentin taloustiedot alkavat omistajuuden kokonaiskustannuksista, mitattuna liiketoiminta-arvon perusteella, mutta itsenäisten agenttien kulutuspohjainen hinnoittelu saa kustannuspuolen käyttäytymään tavallisten lisenssien tapaan. Valitsemasi hinnoittelumalli on perustavanlaatuinen arkkitehtoninen päätös, koska se määrittää, mitä optimoit koko agentin elinkaarelle. Tässä osiossa luodaan hinnoittelumallit, agenttien toteutusten kokonaiskuva ja agenttien ominaisuuksien rakentamisen vs. ostamisen päätös.
Agentforce tarjoaa kaksi kulutukseen perustuvaa hinnoittelumallia, ja organisaatio valitsee niistä yhden agentin käyttöönotolle. Flex Credits -hinta per agenttitoiminto, mikä tekee toiminnon tehokkuudesta kustannusten hallinnan kannustimena. Keskustelukohtainen hinnoittelu veloittaa kiinteän maksun per keskustelu riippumatta sen pituudesta tai monimutkaisuudesta, mikä tekee keskustelun rajoittamisesta vaivaa. Käyttäjäkohtaiset tilaukset tarjoavat agenttien mittaamattoman käytön työntekijöille tarkoitetuksi lisäosaksi kolmanteen kulutuksen mallin sijaan, ja ne siirtävät optimoinnin keskityksen kulutuksen tehokkuudesta omaksumiseen, koska arvo saadaan lisensoiduista käyttäjistä, jotka osallistuvat agenttiin aktiivisesti, eikä jokaisen vuorovaikutuksen minimoinnista. Kaksi kulutusmallia ei ole yhdistetty samalle organisaatiolle, mutta Käyttäjäkohtainen-lisäosa, joka on tarjolla käyttäjäkohtaisesti kuukaudessa mittaamattomaan käyttöön, voi olla kerros kulutusmallin vieressä, jolloin asiakaskohtaiset agentit käyttävät Flex-hyvityksiä tai Keskustelua kohti -toimintoa, kun työntekijät käyttävät mittaamattomia lisenssejä.
Flex-hyvitykset-osiossa toiminnon kustannukset ovat kiinteitä per toiminto, enintään määritetty valtuuksien enimmäismäärä. Toisin kuin valtuuksiin perustuva päättelyhinnoittelu, hyvityskustannukset eivät vaihtele kehotteen pituuden tai mallin monimutkaisuuden mukaan, joten yhden lauseen vastaus ja usean kappaleen vastaus maksavat yhtä paljon. Monitoimintojen vuorovaikutus kuluttaa jokaiselle toiminnolle krediittejä, joten vuorovaikutus, joka noutaa dataa, syitä ja päivittää tietueen, kuluttaa kolmen toiminnon krediittejä, ja haun augmentoitu generointi lisää muita toimintoja vektorihaun ja asiakirjan noutamisen kautta ennen perusteluita. Toimintojen keskiarvoisen määrän ymmärtäminen per liiketoimintatransaktio on siis edellytys kustannusten mallinnukselle Flex-hyvityksissä.
Keskustelukohtainen hinnoittelu -osiossa käytetään tasaista maksua per keskustelu ja useita istunnon sisällä tapahtuvia vuorot lasketaan yhteen keskusteluun, joten kustannusten hallinta tapahtuu ratkaisemalla ongelma yhdessä keskustelussa ja määrittämällä selkeät istunnon rajat yksittäisten toimintojen vähentämisen sijaan. Data 360 -perustaminen ja MuleSoft-integraatio kuluttavat omat kapasiteettinsa valitun mallin kanssa, koska generoinnin ja samankaltaisuuksien haun upottaminen vähentää datan käsittelykapasiteettia jokaiselle maadoitetulle kyselylle ja jokainen ulkoinen toiminto kuluttaa API-kapasiteettia sekä lähde- että kohdejärjestelmissä.
Agenttien toteutuksen kokonaisomistuskustannukset (TCO) kattavat kuusi kategoriaa, ja kaikkien kuuden kategorian mallinnus muuntaa luottoarvioinnin tietoiseksi sijoituspäätökseksi. Kehityskustannukset kattavat agenttien suunnittelun, kehotteiden suunnittelun, integraation kehittämisen ja testauksen, ja ne vaihtelevat laajalti yksinkertaisesta yksittäisestä agentista monien agenttien järjestelmään, jossa on monimutkainen orkestrointi. Inferenssin kustannukset riippuvat valitusta hinnoittelumallista ja vaativat toiminnon odotettujen määrien mallinnuksen Flex-hyvityksiä, Keskustelua kohti -osiossa olevia keskusteluiden määriä tai lisensoitujen käyttäjien määriä Per käyttäjä -osiossa. Suurissa Knowledge oleville agenteille Data 360 -infrastruktuuri, joka tukee perustamista, voi vastata tai ylittää päätelmäkustannukset. Infrastruktuurikustannukset kattavat Data 360- ja MuleSoft-lisenssit, lisäsandboxit ja valvontainfrastruktuurin, ja ne ovat pääosin kiinteitä tai vaiheittaisia kapasiteettitasojen perusteella. Toimintakustannukset kattavat valvontatoiminnot, kehotteiden hienosäätämisen, vahinkotapahtumien vastauksen ja käyttäjien tuen, ja kypsille agenttien ohjelmille ne vastaavat tavallisesti merkittävää osaa kehityskustannuksista vuosittain, mikä on yhdenmukaista tekoälyagenttien yleisten toimialan vertailuarvojen kanssa Salesforce-kohtaisen luvun sijaan. Hallintakustannukset kattavat turvallisuustarkastuksen, henkilökohtaisen valvonnan, kirjauslokien ja vaatimustenmukaisuuden vahvistuksen, jotka kasvavat agenttien itsenäisyyden ja riskien myötä, ja Fairness-pilari kattaa tärkeimmät ohjelmakomponentit. Muutosten kustannukset kattavat käyttäjien koulutuksen, liiketoimintaprosessien mukauttamisen ja organisaation muutosten hallinnan, ja ne ovat luokkaryhmät, jotka aliarvioivat useimmin.
Laadi laskentataulukon TCO-malleja, jotka ennustavat 3–5 vuoden kulut. Asiakirjojen oletukset vuorovaikutusten määrälle, toimintojen määrälle ja kasvulle. Suorita luottamuksellisuusanalyysi tunnistaaksesi oletukset, jotka vaikuttavat eniten kokonaissummaa, ja keskitä vahvistus sitten kyseisiin oletuksiin. Malli kaikki kolme kustannusrakennetta, Flex Credits, Per-Conversation ja Per-User, ennustetun käytön perusteella ennen sitouttamista, koska optimaalinen rakenne riippuu käyttökuvasta ja väärän valinnan vapauttaminen on kallista, kun agentti on tuotantoympäristössä.
Agenttien build-versus-buy-päätös noudattaa samaa logiikkaa kuin mikä tahansa muu Salesforce-ominaisuus, ja se vertaa valmiin ratkaisun välitöntä arvoa ja mukautetun rakenteen tarkkaa sovitusta 3–5 vuoden TCO-horisontissa. Tuotteiden työnkulut suosivat ostamista, kun taas omistettujen ominaisuuksien erottamisen edistävät ydintoiminnot oikeuttavat rakentamisen. Agentic Enterprise tarjoaa useita vaihtoehtoja binäärivaihtoehdon sijaan. Valmiit Agentforce, kuten palveluagentti tai myyntikehitysedustaja, tarjoavat todennettuja ominaisuuksia nopealla käyttöönotolla ja sovellusalustan ylläpitämillä päivityksillä. He kuluttavat luottoja valitun hinnoittelumallin perusteella. AgentExchangen kautta tarjotaan kaupallisesti saatavilla olevia agentteja Salesforce Independent Software Vendor (ISV) -yhteisöstä, josta löydät ratkaisun, joka täyttää jo vaatimuksen sen rakentamisen sijaan. Agent Builderilla luodut mukautetut agentit tarjoavat tarkkaa sovitusta ja kilpailukykyä edeltävän kehityksen sekä jatkuvan kehotteiden hienosäätämisen ja ylläpidon kustannuksella. Käyttövalmiiden agenttien mukauttaminen Kehotteiden rakentajan ja toimintojen kokoonpanon avulla tarjoaa keskipisteen, joka maksaa vähemmän kuin täydellinen mukautettu kehitys, mutta joka mukauttaa agenttia organisaatiosi mukaisesti. Harkitse kustannusten lisäksi aika-arvoa koskevia vaatimuksia, sisäistä kehityskykyä, strategista eriytymistä ja toimittajien riippuvuuksien toleranssia ja tallenna päätös arkkitehtuurin päätöstyötietueeseen, jotta se voidaan arvioida uudelleen, kun vaatimukset muuttuvat.
Toteuttavat agentit, joilla on selkeä ymmärrys niiden perustana olevasta kustannusrakenteesta, tekevät kykyjen itsenäisestä skaalattamisesta kestävää sen sijaan, että ne heikentäisivät budjettiä. Optimoinnin vipuvaikutus riippuu hinnoittelumallista, koska se, mitä määrität hallitaksesi kustannuksia, eroaa maksuja per toiminto, maksuja per keskustelu ja maksuja per käyttäjä. Periaate on vakio kaikissa kolmessa: säädä kulutusta todellisen toimitetun arvon mukaan, jotta kelvollinen agentti ei polta budjettiaan hiljaa nopeammin kuin se palauttaa liiketoimintatuloksen.
Flex-hyvitykset-osiossa optimointi tarkoittaa toimintojen minimoimista liiketoiminnan lopputuloksen mukaan ja laatua säilyttämistä. Ratkaise yksinkertaisia pyyntöjä yhdellä toiminnolla monivaiheisen työnkulun sijaan, jotta yleisimpiin kysymyksiin vastaaminen tai rutiinihaku ei kuluta kolmen toiminnon ketjun hyvityksiä. Yhdistä operaatiot yhteen toimintoon, kun se on järkevää, yhdistämällä haku, analyysi ja vastaus sen sijaan, että maksaisit jokaisesta erikseen, kun yksi toiminto toimisi. Tallenna toistuvien pyyntöjen vastaukset välimuistiin siten, että usein kysytyt kysymykset toimivat välimuistissa sen sijaan, että kuluttaisit tuoreita toimintoja jokaiselle identtiselle kyselylle, mikä on tämän mallin suurin tehokkuusvoitelu, kun merkittävä osa kyselyistä toistuu.
Keskustelukohtainen hinnoittelu -osiossa optimointi tarkoittaa ongelmien ratkaisemista yhdessä keskustelussa useiden ongelmien sijaan. Suunnittele istunnon rajat ja aikakatkaisut siten, että keskustelu jatkuu oikein ilman, että se lopetetaan ennenaikaisesti ja että uusi laskutettava keskustelu pakotetaan. Keskitä agentin kykyjä ensimmäisen keskustelun ratkaisuun, jotta tehtävä suoritetaan loppuun ensimmäisen keskustelun aikana eikä se vaadi jatkotoimia. Seuraa ensimmäisen keskustelun ratkaisun suhdetta kustannustehokkuustilastoina ja estä vaikutusalueen laajentamista, kun käyttäjä avaa erilliset keskustelut siihen liittyvistä ongelmista, joita olemassa oleva keskustelun konteksti olisi voinut käsitellä.
Käyttäjäkohtaiset tilaukset -osiossa optimointi tarkoittaa jokaisen lisensoidun käyttäjän palauttaman arvon maksimointia, koska kulutusta ei mitata ja kustannus on kiinteä per istunto. Keskity sopeutumiseen, jotta lisensoidut käyttäjät voivat ottaa agentin aktiivisesti mukaan, seurata käyttöasteita tunnistaakseen vähäiset käyttäjät kohdennettua koulutusta tai lisenssien uudelleenallokointia varten, ja yhdistää agenttien vuorovaikutukset liiketoiminnan lopputuloksiin käyttäjäjoukon mukaan, jotta arvokkaat käyttötarkoitukset oikeuttavat investoinnin, kun taas vähäisen arvon käyttö osoittaa optimoinnin tai toisen hinnoittelumallin tarpeen. Tarkasta käyttäjäjoukot vaiheittain, jotta lisenssit pysyvät tasalla todellisen käytön kanssa.
Riippumatta hinnoittelumallista, arkkitehtuuri vaikuttaa kustannuksiin. Toteuta lajitteluagentteja, jotka käsittelevät alustavan reitityksen yksinkertaisella logiikalla ja ohjaavat käyttäjät erikoistuneelle agentille vain, kun monimutkaisuus vaatii sitä, jotta kalliit monimutkaiset kutsut tapahtuvat vain, kun ne on varmistettu. Palaa perinteiseen automatisointiin deterministisille skenaarioille, joissa riittää sääntöihin perustuva logiikka, jolloin kulut voivat käsitellä deterministisiä polkuja halvemmalla hinnalla, kun taas agentit käsittelevät epäselviä tilanteita, jotka todella tarvitsevat perusteluja. Nouda periytymistietoja valikoidusti, käynnistämällä vektorihaun ja asiakirjojen noutamisen vain, kun agentin päättely edellyttää sitä, eikä jokaisessa vuorovaikutuksessa, jotta Data 360 -kulutus seuraa todellista tarvetta. Nämä kuviot pitävät arkkitehtuurin päättely- ja kulutuskustannukset suhteessa työn vaikeuteen.
Itsenäisten agenttien kustannusten seuranta on vaikeampaa kuin perinteisten työkuormien, koska agentit eivät noudata ennustettavissa olevaa pyyntöjen ja vastausten kuviota. Agentti voi iteroida monivaiheisen päättelyn kautta, kutsua mukautettuja työkaluja suorituksen aikaisten ehtojen perusteella ja koordinoida muita agentteja, mikä tuottaa erittäin vaihtelevaa luotonkulutusta, jota on vaikea ennustaa. Ilman valvontaa syvällisiä iteratiivisia töitä suorittava agentti voi kuluttaa suuria määriä krediittejä ennen kuin kukaan puuttuu asiaan, ja tehottomat kehotteiden suunnittelu tai tarpeettomat perustelukulut voivat tyhjentää budjetteja hiljaa koko agenttien joukosta. Tehokas hallinta edellyttää siis reaaliaikaista näkyvyyttä kulutukseen per agentti ja per operaatio, automatisoituja hälytyksiä ja ohjaimia, jotka estävät kustannusten häviämisen ja säilyttävät agenttien hyödyllisyydestä riippumattomuuden. Myös agenttien taloushallinta vaatii selkeää omistajuutta ja tasoitettua hyväksyntää, joka on laadittu muuttujien kulutukselle staattisten laskentakustannusten sijaan.
Salesforce Digital Wallet on sisäänrakennettu työkalu kulutuspohjaisten tuotteiden, kuten Agentforce Flex Credits -tuotteiden, valvomiseksi, ja Flex Credits -tuotteita käyttävien organisaatioiden tulisi ottaa se käyttöön ensisijaisena kustannusvalvontamekanismina sen sijaan, että ne rakentaisivat mukautettuja mittaristoja, jotka vastaavat sen tarjoamia tietoja. Digital Wallet tarjoaa lähes reaaliaikaista kulutustietoa toiminnon tason käytön havainnoilla, agenttikohtaisen erittelyn, joka näyttää eniten kuluttavat agentit, ennakoivat kulutushälytykset ja historialliset trendit kuvioanalyysejä ja ennusteita varten. Täsmää valvonta hinnoittelumalliin. Seuraa Flex Credits -osiossa kulutusta agentin, käyttäjäjoukon, ajanjakson ja toiminnon tyypin mukaan ja täydennä Digital Walletia mukautetuilla mittaristoilla, jotka yhdistävät luotonkulutuksen liiketoimintatransaktioihin. Tarkasta Keskustelukohtainen hinnoittelu -osiosta keskusteluiden määrät, keskiarvoinen pituus ja suoritussuhteet. Valvo Käyttäjäkohtaiset tilaukset -osiossa käyttöasteen sijaan kulutusta seuraamalla aktiivisia käyttäjiä ja liiketoiminta-arvoa per käyttäjä, jotta lisenssin sijoittaminen näytetään tuottavan suhteellista arvoa.
Vuorovaikutuskohtainen kustannusmääritys yhdistää kulutuksen liiketoimintatransaktioihin ja paljastaa kustannukset per ratkaistu tapaus, per hyväksytty liidi tai per käsitelty tilaus, mikä mahdollistaa ROI-laskennan ja käyttötapausten välisen vertailun. Budjettihälytys käynnistää ilmoituksen, kun kulutus lähestyy määritettyjä kynnysarvoja, kuten 70 % ja 85 % budjetista, jotta optimointi tapahtuu ennen rajoituksen saavuttamista. Määritä hälytyksiä per agentti ja käyttötapa, äläkä vain organisaationlaajuisesti lokalisoidaksesi ongelman lähteeseen. Poikkeavuuksien havaitseminen paljastaa kulutuksen äkillisen nousun, joka osoittaa odottamattoman käyttökuvion tai tutkimista vaativan perustelukulun. Jaa kustannusmittaristoja liiketoiminnan sidosryhmille ja teknisille tiimeille, jotta avoimuus edistää kustannustietoista agenttien käyttöä.
Käytä taloushallintaa ennen kuin sitoutat kulut agenttien arkkitehtuuriin. Vaadi agentin sijoitukselle liiketoimintatapaus, joka kattaa valitun hinnoittelumallin ennustetun kokonaissumman 3–5 vuoden aikana, odotetut liiketoimintatulokset mittaustavalla, vertailun vaihtoehtoihin, mukaan lukien manuaaliset prosessit ja perinteinen automatisointi, sekä riskinarvioinnin, joka kattaa laadun, turvallisuuden ja toiminnan riskit. Määritä hyväksymisen kynnysarvot, jotka erottavat osasto voi valtuuttaa sijoituksia ja jotka vaativat johdon hyväksynnän, jotta korkean sijoituksen tai riskin agentti saa oikeasuhteisen tarkastuksen. Mandate pilottikäyttöönotot, jotka vahvistavat oletukset ennen täyttä tuotantoa, koska pilotti paljastaa todellisen kulutuksen, laadun ja sopeutumisen, jotka kertovat sekä tuotanto-investointien päätöksestä että hinnoittelumallin valinnasta.
Hallitse agentin kiinteistöä portfoliona eikä agentin perusteella, koska portfolionäkymä paljastaa optimointimahdollisuudet, joita yksittäinen agentin tarkastus ei näe. Tarkasta kaikki agentit yhdessä vertaamalla kustannuksia, käyttöä, liiketoiminta-arvoa ja strategista kohdistusta ja määrittämällä sunsetting-ehtoja, jotka poistavat agentit, joilla on alhainen sopeutuminen, heikko ROI, korvatut toiminnot tai liialliset kustannukset, jotta vähäarvoiset agentit eivät keräänny ja kuluta budjettia loputtomiin aikoihin. Kohdista sijoitukset alhaisen suorituskyvyn agenteilta korkean arvon mahdollisuuksiin jatkuvana käytännönä, joka sovittaa kulut uudelleen kehittyviin prioriteetteihin kertaluonteisen siivouksen sijaan.
Kustannusten allokointi luo vastuullisuuden agenttien kulutuksesta, ja organisaatiot toteuttavat sen kahden mallin kautta, jotka koskevat muuta alustaa. Showback-raportit raportoivat agenttien kustannukset liiketoimintayksiköiden mukaan ilman sisäistä maksua, mikä parantaa kustannusten tietoisuutta ja optimointikeskustelua ilman sisäistä laskutusta. Chargeback jakaa todelliset agenttien kustannukset kuluttaville liiketoimintayksiköille, mikä parantaa optimointitapaa, koska kustannukset vaikuttavat suoraan osaston budjettiin, mutta se vaatii tarkan allokointimenetelmän riitojen välttämiseksi. Hybridimenetelmä soveltaa täydennystä raskaan tuotantoympäristön agenteille, mutta käyttää sitä myös kokeilu- tai vähäisen volyymin agenteille, mikä tasapainottaa suurten investointien vastuullisuuden ja innovaatioiden joustavuuden.
Agenttien arkkitehtuurit ottavat käyttöön omat kestävään kehitykseen liittyvät näkökohdat, koska suurikielisten mallien johtopäätös on laskutoimittain intensiivinen ja jotkin agentit suoritetaan jatkuvasti, eikä vain käyttäjien käynnistämissä erillisissä transaktioissa. Proaktiiviset, lähtevät ja ajoitetut agentit toimivat ilman käyttäjää silmukassa, selkokieliset agentit keräävät kulutusta useista kierroksista, ja vektorihaku, asiayhteyden valmistelu ja toimintojen suoritus lisäävät infrastruktuurin latausta. Kestävän kehityksen agenttien rakenne minimoi laskutoimiin liittyvät jätteet ja pitää käyttökokemuksen reagoivana. Kuten Resurssien ja kustannusten optimoinnin pilarissa, yhden ratkaisun ja datakeskuksen päästöjen välinen suhde on epäsuora. Yksittäisen vuokralaisen tehokkuus ei vähennä päästöjä suoraan. Kaikkien vuokralaisten tehokkuuden parantaminen auttaa kuitenkin Salesforcea käyttämään infrastruktuuriaan tehokkaammin ja lykkäämään kapasiteetin laajentumista. ja Resurssien ja kustannusten optimoinnin pilarin perustavat kestävän kehityksen käytännöt koskevat agentteja, ja seuraavat tehostusstrategiat käsittelevät suurten kielten malliin perustuvia keskustelujärjestelmiä. Jokainen vähentää myös kustannuksia, minkä vuoksi kestävyys ja arvo kustannukselle ovat samaa kuria eri lopputulosten perusteella.
Havainto on agenttien arkkitehtuurin resurssiintensiteettisin komponentti, joten tehokkuus hyödyttää kehotteiden pituutta, kontekstien käyttöä ja välimuistiin tallentamista. Optimoi kehotteita välittämään tarkoitus vähemmässä määrässä valtuuksia poistamalla tyhjiä ohjeita ja tarpeettomia esimerkkejä, koska lyhyempi kehote vähentää esitäytettyä laskentaa suhteellisesti, vaikka se ei muuta vastauksen luomisen laskentaa. Hallitse kontekstiikkunaa tekemällä yhteenvedon keskusteluhistoriasta ensimmäisten useiden vuorojen jälkeen ja palauttamalla jokaisesta toiminnosta vain välttämättömiä kenttiä, jotta jokaiseen johtopäätökseen lisätty valtuusbudjetti pysyy rajallisena eikä kasva keskustelun myötä.
Vektorihaku ja yhtenäistettyjen profiilien kyselyt kuluttavat laskentaresursseja, joten sama tulosrajoitus- ja suodatustiede, joka hallitsee maadoituskustannuksia, vähentää myös maadoituksen infrastruktuurin kuormitusta. Määritä top-k-rajoitukset palauttaaksesi vain agentin käyttämät tulokset, koska 50:n hakeminen, kun 5 ilmoittaa vastauksesta, johtaa 45 käyttämättömään tulokseen, jotka kuluttavat maadoitusvaltuuksien budjettia ilman hyötyä, ja käytä metadatasuodattimia rajoittaaksesi hakua ennen samankaltaisuuksien järjestystä. Kysele yhtenäistettyjä profiileja kokoamaan koko konteksti yhteen operaatioon sen sijaan, että lähettäisit erillisiä kyselyitä useille objekteille joka kerta, ja tallenna välimuistiin profiileja agenteille, joilla on suuri käyttäjäkohtaisuus, kuten myyntiagentille, joka työskentelee kiinteän tilien joukossa, jotta toistuva kontekstijoukko ei toista kyselyä.
Agenttien toiminnot kuluttavat SOQL-kyselyitä, DML-toimintoja ja CPU-aikaa, joten Resurssien ja kustannusten optimoinnin pilarin bulkkaus-, välimuisti- ja asynkroninen tieteenala koskee suoraan agenttien toimintoja. Suunnittele toimintoja hyväksyäksesi kokoelmia siten, että useiden tietueiden päivittäminen on yksi toiminto useiden sijaan, käytä suhdekyselyitä noutaaksesi ylätason ja alitason tietoja yhdestä lausekkeesta, tallentaaksesi viitetiedot välimuistiin sovellusalustan välimuistiin ja erä DML kokoelmassa tietueen sijaan. Siirrä synkronointirajoituksia ylittävät operaatiot jonoon tai erä Apexiin, käsittele ei-painuvia töitä, kuten joukkopisteytys tai historiallinen rikastus, ei-synkronoidusti, ja ajoita agenttien käynnistämiä erätöitä ruuhka-aikojen ulkopuolelle, kun se on mahdollista, jotta kuorma leviää ajan myötä eikä keskittyä toimistoaikojen aikana. Valvo ei-synkronoitua suoritusta siten, että jonon rästityöt osoittavat, että kapasiteetin suunnittelu on tarpeen ennen kuin siitä tulee virhe.
Agentin kulutuskuvio kehittyy, kun käyttö kasvaa, joten kestävän kehityksen toteuttaminen vaatii jatkuvaa valvontaa kertaluonteisen käytön sijaan. Seuraa keskiarvoisia tokeneja per johtopäätös käytettävissä olevan käytön telemetrian avulla, jotta kehotteen kasvava koko näkyy optimointimahdollisuudessa, valvo keskustelun pituuden jakaumaa siten, että rajoittamattomat keskustelut paljastavat tehtävärajan ongelman, ja analysoi toimintojen suorituskykyä tapahtumien valvonnassa siten, että korkean yleisyyden toiminnosta tulee optimoinnin prioriteetti. Tutustu Data 360 -kyselyiden kuvioihin löytääksesi yleisiä kyselyitä, jotka kannattaa tallentaa välimuistiin tai laskea valmiiksi, seuraa semanttisia välimuistiin tallennettuja tapaamisia siten, että alhainen nopeus käynnistää kynnysarvon säädön, ja mittaa viiveen prosenttiosuuksia siten, että jälkeinen viive paljastaa mahdolliset pullonkaulakohdat. Tarkasta agenttien käyttö säännöllisesti vaikutusalueen heikkenemisestä. Tutki esimerkiksi agenttia, jonka keskiarvoinen keskustelun pituus kasvaa muutamasta vuorosta useampaan kuukauden aikana. Tarkenna agentin rajoja siten, että kulutus palauttaa suunnitelman. Jotkin näistä valvontapinta-alueista paljastavat käytön aggregaattimittaristoissa erillisen laskentalokin sijaan, joten tarkasta kokoonpanollesi saatavilla oleva tarkka telemetria, kun suunnittelet valvontaa.
Resurssien optimointi määrittää, skaalataanko agenttien arkkitehtuurit väestöryhmien ja käyttötapausten kasvaessa, ja kustannusten optimointi määrittää, palauttaako skaala suhteellisen liiketoiminta-arvon. Nämä kaksi päätöstä muodostavat yhden valtuuden:
- Arkkitehtuurinen tehokkuus: suunnittele toimintoja bulkkauksella, budjetoi SOQL-kyselyitä toimintojen ketjuille, siirrä raskaan käsittelyn asynkronointiin, optimoi API-kulutus yhdistelmä- ja tapahtumiin perustuvien kuvioiden avulla, hallitse konteksti-ikkunoita priorisoinnin ja yhteenvetojen avulla sekä rakenna yhdistettäviä arkkitehtuuria uudelleenkäytettävistä komponenteista.
- Taloudellinen ohje: Valitse hinnoittelumalli tarkoituksellisesti, malli täyttää TCO-kertoimet ennen sitouttamista, valvo kulutusta liiketoiminnan lopputulosten perusteella ja hallitse sijoituksia tasoitetulla hyväksynnällä ja portfolion tarkastuksella.
Organisaatiot, jotka hallitsevat näitä kuvioita, tarjoavat agenteille interaktiivisia käyttökokemuksia sovellusalustan rajoituksien mukaisesti, mutta pitävät kuluttamisen tasalla agenttien palauttaman arvon kanssa.
Perusresurssien ja kustannusten optimoinnin ohjeet kaikille Salesforce-ratkaisuille, mukaan lukien suorituskyvyn optimointi, hallintarajoitukset, TCO-analyysi, lisenssisuunnitelma ja kustannusten hallinta, perustuvat Resurssien ja kustannusten optimoinnin pilariin. Agenttien hallinta-, henkilökohtainen valvonta- ja turvallisuusohjelmakomponentit liittyvät Trust- ja Fairness-pilarit. Tämän asiakirjan yksityiskohtaiset agenttien toteutusohjeet, jotka kattavat resurssien tehokkuuden, taloustiedon, toimintojen optimoinnin, hallinnan ja kestävän kehityksen, on kerätty agenttien kuvioiden kirjastossa.