Operatiivinen huippuosaaminen agenttiyritykselle

Agenttien järjestelmien toiminnallinen huippuosaaminen laajentaa perinteisiä DevOps-käytäntöjä vastaamaan tekoälyagenttien ainutlaatuisia ominaisuuksia: ei-deterministinen toimintatapa, asiayhteydestä riippuva päättely ja muisti, tavoitteen monimutkaisuus ja muuttujien päätelmäkustannukset. Tavalliset sovellukset noudattavat ennustettavia koodipolkuja, mutta agentit luovat uusia vastauksia asiayhteyden perusteella. Perinteinen valvonta seuraa tunnettuja tilastoja, kun taas agenttien havaittavuus vaatii kielimallien perusteluiden ja päätöksenteon ymmärrystä. Vakiotestaus vahvistaa deterministisiä tuloksia, mutta agenttien vahvistus arvioi vastauksen laadun useissa ulottuvuuksissa, mukaan lukien tarkkuus, relevanttius, turvallisuus ja oikeudenmukaisuus.

Tuotteet ja järjestelmät muuttuvat ajan myötä, joten käytä näitä viittä suunnitteluperiaatetta upottaaksesi toimintatavan huippuosaamisen niiden suorittamiseen: kehittyä havaittavuudella, standardoida toimintaohjeita, omaksua DevOps-kulttuuria, automatisoida tehokkuutta ja oppia kaikista toimintatapahtumista. Ydintoimintojen huippuosaamisen periaate "Evolve with observability" on kriittinen agenttien järjestelmille, koska agenttien toimintatapa syntyy kehotteiden, haetun kontekstin, mallin toimintatavan ja keskusteluhistorian monimutkaisista vuorovaikutuksista deterministisen koodin suorituksen sijaan. Arkkitehtit eivät voi ennustaa kaikkia agenttien vastauksia suunnittelun aikana, koska vastaukset on muotoiltu mallin, kehotteen ja live-kontekstin perusteella, joten suunnittele ne havaittavuutta ja vartiointia varten. Kattava havaittavuus paljastaa, miten agentit käyttäytyvät todellisissa olosuhteissa. Tämä näkyvyys sallii datan perustuvien parannusten ja nopean ongelmien diagnosoinnin, kun agentit tuottavat odottamattomia tuloksia.

"Operaatiot koodina" ottaa uusia ulottuvuuksia agenteille. Perinteinen infrastruktuuri koodina -ominaisuus ulottuu kehotteiden versiointiin, mallin kokoonpanon hallintaan ja agenttien käyttöönoton automatisointiin. Agenttien toimenpiteet käsittelevät mallin versioiden muutoksia, kehotteiden evoluutiota ja Knowledge päivityksiä sekä tavallisia käyttöönotto- ja periytymistoimintoja.

"Opi kaikista toimintatapahtumista" on entistä arvokkaampi agenttien järjestelmissä. Agenttien vahinkotapahtumat paljastavat usein hienovaraisia kehotteiden teknisiä ongelmia, komentosarjojen ja orkestroinnin virheitä, Knowledge aukkoja tai odottamattomia käyttäjien vuorovaikutuskuvioita. Postmortems yhdistettynä agenttien telemetrian järjestelmälliseen analyysiin muuttaa toimintokokemuksen organisaatiokyvyksi, joka yhdistyy ajan myötä.

Keskusteluiden täydellinen kirjaaminen muodostaa perustan agenttien havaittavuudelle. Sieppaa kaikki keskustelut, mukaan lukien käyttäjien syöttämät tiedot, agenttien vastaukset, päättelyvaiheet, kutsutut toiminnot, haetut tiedot ja lopulliset lopputulokset. Tämä telemetria toimii useissa tarkoituksissa: tiettyjen vahinkotapahtumien virheenkorjaus, useiden vuorovaikutusten laatuanalyysi, vaatimustenmukaisuuden auditointi, mallin parantaminen ja käyttökuvion analyysi.

Käytä natiivista istuntojen jäljitysmallia mukautetun sisäänrakennetun lokin sijaan. Agentforcen istuntojen jäljittäminen kaappaa agenttien vuorovaikutustiedot yhtenäistetyssä datamallissa Data 360:ssa sen sijaan, että sinun täytyisi laatia rinnakkainen telemetrian järjestelmä. Istunnon jäljitystietojen malli (STDM) tallentaa keskustelun seurantahierarkiana. Jokainen istunto sisältää vuorovaikutukset (kierrokset), jokainen vuorovaikutus sisältää vaiheet (UserInputStep, LLMExecutionStep, FunctionStep) ja vaiheet sisältävät viestejä (käyttäjien ja agenttien viestintä). STDM käyttää vakiomuotoisia Data 360 -objekteja, kuten AIAgentSession, AIAgentSessionParticipant, AIAgentInteraction, AIAgentInteractionStep ja AIAgentInteractionMessage. Vuorovaikutukset sisältävät jaetun seurannan tunnisteet (TelemetryTraceId ja TelemetryTraceSpanId) ja vaiheet sisältävät span-tunnisteen (TelemetryTraceSpanId), joka vastaa OpenTelemetry-tyyppistä span-mallia.

Agenttien keskusteluiden mallinnus seuranta- ja laajennusvaiheina on toimialan standarditonta lähestymistapaa agenttien havaittavuudelle, ja natiivimallin uudelleenkäyttö välttää skaalautumisongelmat, joihin manuaaliset objektit kohdistuvat: usean vuoron keskusteluiden, suurten JSON-arvojen tallentaminen ja datan nopea kasvu. Mukautettujen transaktio-objektien luominen keskusteluiden kirjaamiseksi lokiin on tarkoituksellinen poikkeus — esimerkiksi kevyt mukautettu objekti, joka korreloi agenttien toimintatavan liiketoiminnan lopputuloksiin, eikä ensisijaista lokitason alustaa.

Istuntojen ja keskusteluiden metadata kaappaa kriittisen asiayhteyden, mukaan lukien istunnon ja vuorovaikutuksen tunnisteet, käyttäjän identiteetti, agentin identiteetti, alkamis- ja päättymisaika. STDMalso linkittää vuorovaikutusvaiheet sen big language -mallin (LLM) puhelutietueisiin (GenerationId- ja GenAiGatewayRequest/Response-viitteiden kautta). Valtuuksien käyttö, mallin ja kehotteiden lisätiedot ovat käytettävissä näiden liitosten kautta, eikä niitä tallenneta istuntokenttinä. Metadata sallii keskusteluiden suodattamisen ja aggregoinnin kuvioanalyysiä varten.

Vuorovaikutusten ja vaiheiden lisätiedot sieppaavat jokaisen vuoron, mukaan lukien käyttäjän syöttämät tiedot, agentin vastaus, perustelun selitys (kun käytettävissä), luottamuspisteet, haetut asiayhteydet, yritetyt toiminnot ja havaitut virheet. Vaihetason seuranta mahdollistaa yksityiskohtaisen vahinkotapahtumien tutkimisen, joka rakentaa tarkalleen sen, mitä tapahtui perusteluketjun jokaisessa vaiheessa.

Toiminnon vaiheet tallentavat kaikki agentin suorittamat toiminnot, mukaan lukien API-kutsut, datan muokkaukset, ulkoisen järjestelmän vuorovaikutukset ja kutsutut integraatiot. Toimintatietueet vastaavat kysymyksiin, kuten "Mitä tämä agentti muutti?" ja "Mitä järjestelmiä tämä agentti käytti?" Nämä vastaukset tukevat tietoturvatutkimuksia ja vaatimustenmukaisuutta. STDM kaappaa toiminnot oletusarvoisesti vuorovaikutusvaiheina.

Atlas Reasoning Engine -järjestelmän perusteluiden jäljet paljastavat agenttien päätöksentekoprosessit, jotka auttavat diagnosoimaan, miksi agentit valitsevat tiettyjä toimintoja tai luovat tiettyjä vastauksia. Istunnon jäljittäminen tallentaa suunnittelijan vaiheet osana kutakin vuorovaikutusta. Näiden perusteluiden syvyys riippuu mallista ja suunnittelijasta, mutta kun niitä on saatavilla, ne parantavat virheenkorjausta merkittävästi.

Einstein Trust Layer -luonnollisen tekoälyn auditointipolku kaappaa kunkin generoivan tekoälyn vuorovaikutuksen, kehotteen ja vastauksen tekstin – mukaan lukien henkilötietojen peitettyjen versioiden (PII) – haetut periytymistiedot, vastausten turvallisuuden ja toksisuuden pisteytykset sekä LLM-mallin lisätiedot – jotka kaikki on viety Data 360:iin ja tallennettu Data 360:iin. Ota Einsteinin luonnollisen tekoälyn ja palautteen datan kerääminen ja tallentaminen käyttöön, jotta datan ja palautteen tiedot tallennetaan Data 360:iin – josta voit kysellä ja analysoida niitä Data 360 -raportoinnin avulla pitkäaikaista säilyttämistä varten.

Esimerkki:

Hyvä: Mukautetuissa Salesforce-objekteissa säilytetyt keskustelulokit, joissa on kenttiä käyttäjän syöttämille tiedoille, agentin vastauksille, suoritetuille toiminnoille, valtuuksien kulutuksille ja keskustelun lopputuloksille. Mittaristo näyttää keskustelun onnistumissuhteet agentin ja käyttötarkoituksen mukaan. Parempi: Kattava loki sisältää perusteluja, jotka näyttävät agentin päätöksentekoprosessin, haetut asiayhteydet, jotka näyttävät vastausten perustana olevat tiedot, ja epävarmuutta osoittavat luottamuspisteet. Paras: Keskustelu-analyysi korreloi agenttien toimintatavan liiketoiminnan lopputuloksiin, tunnistaa parannusmahdollisuuksia kuvion analyysin avulla ja syöttää jatkuvaa oppimista koskevia myyntiputkia laadukkaiksi merkittyjen esimerkkien avulla.

Valvo toiminnallista suorituskykyä varmistaaksesi, että agentit täyttävät palvelutasot ja toimivat odotettujen parametrien mukaisesti.

Vastauksen viive seuraa käyttäjän syöttämien tietojen päättymisaikaa agentin vastaukseen. Viive vaikuttaa suoraan käyttäjäkokemukseen. Mittaa viiveitä prosenttilukuissa (p50, p95, p99), jotka paljastavat tyypillisiä suorituskyky- ja pahimpien tapausten käyttökokemuksia. Hälytys, kun p95-lähtö ylittää kynnysarvot, jotka osoittavat suorituskyvyn heikentymistä.

Agenttien viiveen osatekijöihin sisältyy mallin päättelyaika, datan ja asiayhteyden haun kesto, ulkoisten työkalujen ja toimintojen suoritus ja verkkoviive. Instrumentoi jokainen vaihe erikseen ottaaksesi kohdennetun optimoinnin käyttöön, kun kokonaisviive ylittää tavoitteet.

Token-kulutus mittaa keskustelua, agenttia ja käyttötarkoitusta kohti käytettyjä tokeneita. Valtuuksien kulutus aiheuttaa johtokustannuksia ja vaikuttaa vastausaikaan (useammat valtuudet vaativat enemmän johtoslaskentaa). Seuraa valtuuksien jakaumaa, joka paljastaa, vastaako todellinen käyttö ennusteita. Havaitse poikkeavia keskusteluita, jotka kuluttavat liikaa valtuuksia, jotka ehdottavat kehotteiden ongelmia tai väärinkäyttöä.

Valtuuksien tilastoihin sisältyvät kehotteiden valtuudet (mallin syöttö), suoritusvaltuudet (mallin tulos) ja valtuuksien kokonaismäärä (kehotteiden ja suorittamisen summa). Kehotteiden valtuuksia voi hallita paremmin kuin suoritusvaltuuksia. Optimoi kehotteet ja haetut asiayhteydet vähentämällä kehotteiden valtuuksien kulutusta samalla kun säilytät laatua.

Lähetyksen valvonta seuraa samanaikaisia keskusteluita, pyyntöjä per sekunti ja keskustelun määrän trendejä, ja se voi auttaa projektin kapasiteettia ja skaalautumisen vaatimuksia. Vertaa tämänhetkistä läpimenoa tunnettuihin nopeusrajoituksiin tai kapasiteetin perushälytyksiin, kun kynnysarvoja lähestytään.

Virhesuhteen seuranta seuraa virheitä tyypeittäin, mukaan lukien mallikohtaiset virheet, aikakatkaisuvirheet, käyttöoikeuksien evätyt virheet ja ulkoisen integraation virheet. Virhemallit paljastavat järjestelmällisiä ongelmia, jotka täytyy korjata. Laske virhesuhteet pyyntöjen kokonaismäärän prosenttiosuutena salliaksesi agenttien ja ajanjaksojen välisen vertailun.

Erota eri vastauksia vaativat virhekategoriat toisistaan. Mallikohtaiset virheet saattavat vaatia kehotteiden säätöjä tai siirtymistä parempaan malliin. Käyttöoikeusvirheet vaativat suojauskokoonpanojen muutoksia. Integrointivirheet vaativat ulkoisen järjestelmän tutkimisen tai katkaisijan aktivoinnin.

Saatavuuden valvonta mittaa agenttien toiminta-aikoja ja onnistuneita toiminta-aikoja. Laske saatavuus prosentteina, jonka ajan agentit vastaavat pyyntöihin onnistuneesti. Seuraa saatavuutta palvelutasotavoitteiden (SLO) perusteella ja ota käyttöön ennakoiva vastaus, kun saatavuus laskee tavoitteiden alle.

Proactive Monitoring arvioi organisaatiosi sovellusalustan poikkeavuuksien ja resurssien käyttöongelmien varalta, jotka voivat vaikuttaa agenttien infrastruktuurin kuntoon. Se näyttää signaalit ennen kuin ne eskaloituvat käyttäjille näkyviksi ongelmaksi. Käytä sitä pysyäksesi edellä infrastruktuuritason ehtoja — kuten epätavallinen API-aktiivisuus tai resurssien kulutuksen trendi kohti sovellusalustan rajoituksia — jotka saattavat heikentää agenttien suorituskykyä. Tarkasta sen signaalit agenttiesi normaalin toiminta-alustan perusteella, jotta voit erottaa toiminnalliset poikkeamat odotetusta variaatiosta.

Valvo vastausten laatua jatkuvasti ja havaitse heikentyminen ennen kuin se vaikuttaa liiketoiminnan lopputuloksiin. Kun sovellusalusta tarjoaa sisäänrakennettuja arviointityökaluja, käytä niitä mukautettujen tai manuaalisten prosessien sijaan. Aloita natiivisilla testaus- ja arviointityökaluilla. Agentforce-testauskeskus sallii sinun ylläpitää uudelleenkäytettäviä testitapausten joukkoja ja suorittaa agentteja niitä vastaan erissä, tarkastamalla, valitsiko agentti odotetun aiheen ja toiminnon ja tuottiko hän hyväksyttävän vastauksen sen sijaan, että hän rakentaisi ja suorittaisi oman testilaitteesi. Se tukee myös natiivisia arvioijia, mukaan lukien käyttövalmiita laatuulottuvuuksia ja LLM-arvoa arvioivaa lähestymistapaa keskusteluiden laadun pisteyttämiseen, ja se sallii mukautettujen arvioijien kirjoittamisen organisaatiokohtaisia ehtoja varten. Käytä testijoukoissasi edustavia keskusteluita, jotta arviointi vastaa todellista käyttöä.

Vastausten tarkkuus mittaa, sisältävätkö agenttien vastaukset oikeat tiedot. Tarkka arviointi vaatii tunnettujen vastausten vahvistukset tai ihmisen tarkastuksen. Jos kyseessä on tosiasiallinen kysymys, jolla on tunnettuja vastauksia, automatisoitu arviointi vertaa agenttien vastauksia oikeisiin vastauksiin ja ylläpitää niitä testitapauksina testauskeskuksessa toistettavaa arviointia varten. Avoimien kysymysten arvioijat arvioivat näytettyjen keskusteluiden tarkkuuden. Seuraa tarkkuuden trendejä pitkältä aikaväliltä paljastamalla, parantavatko kehotteiden muutokset, mallin päivitykset vai Knowledge muutokset suorituskykyä vai heikentävät sitä.

Vastausten relevanttius mittaa, käsittelevätkö agenttien vastaukset käyttäjien kysymyksiä oikein, vaikka ne eivät olisikaan täysin paikkansapitäviä. Asiaankuuluvat vastaukset ymmärtävät käyttäjän tarkoituksen ja tarjoavat hyödyllisiä tietoja, vaikka täydellinen vastaus ei olisi mahdollista. Arvioi relevanttius käyttämällä paikallisia arvioijia, jos niitä on saatavilla, otettujen keskusteluiden henkilökohtaista tarkastelua ja käyttäjän signaaleja. Knowledge perustuvien agenttien natiivi haku-laatua koskeva analyysi voi arvioida vastausten asiayhteydestä, vastausten relevanttiudesta ja uskollisuudesta (perustelusta).

Guardrails havaitsee epäsuojatut, sopimattomat tai haitalliset vastaukset, mukaan lukien vinouma, loukkaava sisältö, vaaralliset neuvot ja vaikutusalueen ulkopuoliset vastaukset. Einstein Trust Layer soveltaa toksisuuksien havaitsemista LLM-vuorovaikutuksiin suorituksen aikana, mikä on ensimmäinen puolustuslinjasi. Paranna turvallisuutta sisällön suodattamalla, manuaalisesti tarkastamalla näytteitä, käyttäjien raportointimekanismeilla ja oikeudenmukaisuustarkastuksilla, jotka arvioivat lopputulosten jakauman väestöryhmissä.

Käyttäjien tyytyväisyystilastot sieppaavat käyttökokemuksen subjektiivisen laadun. Agentforcen palaute kulkee Einsteinin generoiviin tekoälyn auditointi- ja palautemallien datamalleihin (GenAIFeedback/GenAIFeedbackDetail Data 360:ssa). Nämä mallit keräävät käyttäjiltä selkeitä signaaleja — peukalo ylös/alas, hyväksyminen/ hylkääminen, muokkaaminen ja sanalliset kommentit — ihmisestä tai järjestelmästä sekä yhdyskäytävän pyynnöstä ja datan luomisesta. Kerää selkeä palaute (pyyntö ennen eskalointia, keskustelun jälkeen ja jatkokyselyiden kautta) tarvittaessa ja yhdistä selkeitä ja epäsuoria signaaleja kattavan laadun näkökulmasta.

Salesforce tarjoaa useita mallien pintoja. Generointitaso tarjoaa selkokielisen päättelyn agentit, jotka suoritetaan: Agentforce isännöimät mallit tarjoavat käyttövalmiita perusteluja Salesforcen Trust rajoissa ja tuovat omia LLM (BYOLLM) -linkkejä ulkoisiin LLM-ohjelmiin tai tarjoajiin. Ennustetaso tarjoaa rakenteelliset pisteet, joiden perusteella agentit voivat tehdä päätöksensä: BYOM noutaa ulkoisesti isännöityjen sovellusalustojen ennusteiden nollan kopiointipisteet, ja natiiviset Einstein tuottavat automatisoitua pisteytystä ja luokittelua CRM-objekteille. Yhdessä nämä pinnat sallivat itsenäisen agentin perustella asioita luonnollisella kielellä, samalla kun se perustaa työnkulunsa rakenteelliseen tilastolliseen dataan.

Valvo mallin heilahdetta, joka osoittaa heikentyneen suorituskyvyn ajan myötä tai muuttuvia ehtoja, jotka vaativat mukautumista. Tarkasta julkaisuhuomautukset ja testaa kriittisiä käyttötapoja sandboxissa ennen kuin jokainen suuri julkaisu siirretään tuotantoympäristöön. Käytä julkaisumatriisia ja sandboxin esikatseluikkunaa havaitaksesi yhteensopivuusongelmat ajoissa.

Suorituskykymittari tapahtuu, kun agenttien tarkkuus, relevanttius tai turvallisuus heikkenee ajan myötä. Seuraa laatutilastoja pitkältä aikaväliltä ja havaitse tilastollisesti merkittäviä laskuja. Suorituskyvyn heikentyminen voi johtua mallin heikentymisestä, Knowledge vanhentumisesta, kehotteiden virheellisestä yhteensovituksesta muuttuvien käyttökuvioiden kanssa tai käsitteiden heikentymisestä, jossa syötettyjen ja haluttujen tulosten väliset suhteet kehittyvät.

Määritä perustoiminnot välittömästi agentin ensimmäisen käyttöönoton jälkeen mittaamalla tarkkuutta, relevanttiutta, turvallisuutta ja tyytyväisyyttä edustavissa testitapauksissa. Arvioi samat testitapaukset säännöllisesti uudelleen, jotka paljastavat suorituskyvyn muutokset käyttökuvion työvuoroista riippumatta.

Hälytys, kun laatutilastot eivät ylitä hyväksyttyjä kynnysarvoja. Määritä kynnysarvot liiketoiminnan vaikutusten toleranssin perusteella. Jotkin käyttötarkoitukset kestävät kohtuullisen laadun heikentymisen, kun taas toiset vaativat välittömästi vastauksia.

Jakauma tapahtuu, kun käyttäjien syöttökuviot muuttuvat merkittävästi koulutus- tai säätödatan jakaumista. Jakauma heikentää suorituskykyä, kun agentit kohtaavat syöttötyyppejä, joita he eivät ole suunniteltu käsittelemään. Valvo syötettyjä ominaisuuksia, mukaan lukien kysymysten pituus, aiheiden jakauma, kielen monimutkaisuus ja toimialueen termistö, joka havaitsee merkittäviä työvuoroja.

Vertaa nykyisiä syötettyjä tietoja historiallisiin perustasoksiin. Suuret jaon työvuorot voivat osoittaa uusia käyttötarkoituksia, käyttäjien käyttäytymisen muutoksia tai liiketoimintaprosessien kehittymistä. Jakelutyöt voivat vaatia kehotteiden päivityksiä, Knowledge laajentamista tai agenttien kykyjen parantamista.

Käyttäytymisen hajonta tapahtuu, kun agenttien vastauskuviot muuttuvat odottamattomasti. Valvo vastausten ominaisuuksia, mukaan lukien vastauksen keskiarvoinen pituus, toimintojen kutsujen yleisyydet, eskalointien yleisyydet ja virhekuvion. Merkittävät toimintatavan muutokset voivat osoittaa kehotteiden ongelmia, mallin ongelmia tai sen perustana olevia järjestelmämuutoksia.

Laadi toimintatavan perustasot tuotantoympäristössä alkuvaiheessa, sieppaamalla normaaleja toimintaominaisuuksia, kuten säännölliset suorituskykykuviot, työkalujen käyttö ja päätöspolut. Näistä perustasosta tulee vertailuarvo, jota myöhemmin poikkeavuuksien havaitseminen mittaa. Vertaa jatkuvaa toimintatapaa perustasoksi, joka ilmoittaa, kun poikkeamat ylittävät odotetun vaihtelun.

Automaattinen hälytys sallii ennakoivan drift-vastauksen. Määritä hälytykset käynnistymään, kun drift-tilastot ylittävät kynnysarvot, jotka käynnistävät tutkimuksen ja mahdollisen korjauksen, mukaan lukien kehotteiden tarkentaminen, Knowledge päivitykset, testijoukon laajentaminen tai BYOM-mallin uudelleenkoulutus.

Havaitse automaattisesti epätavallinen agenttien toimintatapa, joka vaatii tutkimista.

Kustannuspoikkeamat, mukaan lukien valtuuksien kulutuksen kiihtyvyys, johtosuhteen kasvu tai kokonaiskustannusten kiihtyvyys. Kustannusten nousut voivat osoittaa ongelmia, jotka aiheuttavat liiallisen valtuuden luomisen, väärinkäytön tai väärinkäytön, joka aiheuttaa odottamattoman käytön, tai infrastruktuuriongelmia, jotka aiheuttavat tarpeettomia puheluita.

Valvo valtuuksien kulutuksen jakaumia, jotka havaitsevat poikkeavia keskusteluita. Tutki keskusteluita, jotka kuluttavat 10 kertaa tavallista valtuuksien määrää, ymmärtääksesi, edustavatko ne oikeutettuja reunojen tapauksia vai ongelmia, jotka vaativat korjausta.

Virhesuhteiden kiihtymiset, mukaan lukien epäonnistumisasteiden äkillinen nousu, uusien virhetyyppien näyttäminen, joita ei ollut olemassa perustason perusteella, tai paikalliset virhekeskittymät, jotka vaikuttavat tiettyihin käyttäjiin, agenteihin tai käyttötarkoituksiin. Virheiden pisteet edeltävät usein asiakkaiden näkemiä huonolaatuisia ongelmia. Ennakoiva havaitseminen mahdollistaa korjauksen ennen laajalle levinnyttä vaikutusta.

Vastauskuvio muuttuu, mukaan lukien vastauksen pituuden äkilliset muutokset, toimintojen kutsujen yleisyyden tai eskalointisuhteen muutokset. Kuvioiden muutokset saattavat osoittaa kehotteiden ongelmia, mallin toimintatavan muutoksia tai kehittyviä käyttökuvioita.

Keskusteluiden hylkääminen lisääntyy, kun käyttäjät hylkäävät keskusteluita korkeammalla tasolla, mikä viittaa laadun heikentymiseen, lisääntyneeseen viiveeseen tai toimintojen puutteisiin. Seuraa hylkäämistä keskustelun vaiheesta, joka tunnistaa, hylkäävätkö käyttäjät alustavan vuorovaikutuksen aikana, keskustelun aikana vai tehtävän suorittamisen jälkeen. Hylkäysten kuviot paljastavat tiettyjä parannusmahdollisuuksia.

Suunnittele hälytysarkkitehtuuri, joka tasapainottaa nopean ilmoituksen hälytyksen väsymyksen kanssa. Reititä kriittiset agentin virheet välittömästi puhelunaikaisille insinööreille. Reititä laadun heikentymisen varoitukset tuotetiimeille tutkimista varten toimistoaikojen aikana. Aggregoi pienet poikkeamat päivittäisiin tiivistelmään trendausta varten.

Versioiden hallintaohjelmat, kokoonpanot ja mallin metadata sallivat periytymisen, A/B-testauksen ja seurantatietojen ylläpidon.

Kehotteiden mallit ovat Kehotteiden rakentajassa luotuja uudelleenkäytettäviä kehotteita, jotka määrittävät agentin tavoitteen, rajoitukset ja brändin ohjeet sekä dynaamisten perustetietojen paikanpitäjät, kuten asiakkaan tai tuotteen lisätiedot. Tallenna kehotteiden mallit Gitiin sovelluksen koodin kanssa ja käsittele kehotteita kriittisinä sovelluslogiikoina, jotka ansaitsevat saman tarkkuuden kuin koodi. Kehotteiden muutokset läpäisevät koodin tarkastuksen, testauksen ja hallitun käyttöönoton.

Käytä Kehotteiden rakentajaa kehotteiden iteratiiviseen kehitystyöhön versiohistorian ja testausominaisuuksien avulla. Kun käytät kehotteiden malleja agenttitoimintoina, esikatsele mallia Kehotteiden rakentajassa varmistaaksesi, että yhdistämiskentät ratkaistaan oikein. Käytä sitten testauskeskusta suorittaaksesi kokonaisvaltaisia testejä, jotka vahvistavat, että agentti valitsee toiminnon ja luo oikeat tulokset.

Vie tuotanto-valmiita kehotteita versioiden hallintaan synkronoinnin luomiseksi Kehotteiden rakentajan kehityksen ja lähdekoodin hallitsemien käyttöönottoputkien välillä.

Kokoonpanon hallinta seuraa mallin valintaa, lämpötilan asetuksia, noutokokoonpanoja ja ominaisuusmerkintöjä. Tallenna kokoonpanoja koodina, jotta voit käyttää ympäristökohtaisia arvoja, automatisoida käyttöönottoja ja havaita kokoonpanovirtoja.

Semanttista versiointia sovelletaan agenttien julkaisuihin. Tärkeimmät versiot osoittavat rikkoutuvat muutokset, kuten muokatut syöttö-/lähtö-sopimukset tai merkittävästi muutettu toimintatapa. Pienet versiot tarkoittavat ominaisuuksien lisäyksiä tai parannuksia, jotka ylläpitävät yhteensopivuutta. Korjausversiot tarkoittavat virheenkorjauksia. Version numerointi ilmoittaa muutosten vaikutuksista toiminta-tiimeille ja käyttäjille.

Ota semanttinen versiointi käyttöön agenttien komponenteille, mukaan lukien kehotteiden malleille, agenttikokoonpanoille ja Knowledge. Lokien versioiden numerot sallivat vahinkotapahtumien korrelaation tiettyjen käyttöönottojen kanssa.

Muutosdokumentaatio sieppaa kehotteiden muutosten, kokoonpanojen muutosten ja mallien päivitysten perusteet. Dokumentoi muutokset, miksi ne muuttuivat, mitkä testit vahvistivat muutoksen ja mitkä peruutusmenetelmät ovat käytössä. Muutosdokumentaatio nopeuttaa vahinkotapahtumien tutkimista ja Knowledge.

Ylläpidä kattavaa rekisteriä mallin versioista, kehotteista, kokoonpanoista ja käyttöönottohistoriasta.

Mallin rekisteri tallentaa käyttöönotetut malliversiot, mukaan lukien mallin perheen, tietyn version, hienosäätöjen tilan, käyttöönottoympäristön (tuotanto, vaiheistaminen ja kehitys), käyttöönoton päivämäärän ja vastuullisen tiimin. Rekisteri tarjoaa yhden totuuden lähteen agenttien infrastruktuurin tilalle.

Käyttöönoton seuranta kirjaa lokiin jokaisen agentin käyttöönoton, mukaan lukien käyttöönotetun version, ympäristön, käyttöönoton aikaleiman, käyttöönottokäyttäjän, saatujen hyväksyntöjen ja käyttöönoton lopputuloksen. Käytä käyttöönottohistoriaa arvioidaksesi vaikutuksia, kun ongelmia ilmenee (esimerkiksi "mitä agentteja otettiin käyttöön ennen tämän vahinkotapahtuman alkamista?") ja tukeaksesi vaatimustenmukaisuuden raportointia.

Riippuvuuksien seuranta kartoittaa agenttien, kehotteiden, Knowledge-tietokantojen, toimintojen ja integraatioiden väliset suhteet. Kun jaettu Knowledge päivitetään, sidonnaisuuksien seuranta paljastaa, ketkä agenteista vaikuttavat siihen. Kun ulkoinen integraatio muuttuu, sidonnaisuuksien seuranta tunnistaa asiaankuuluvat agentit.

Asiakirjojen sidonnaisuudet selkeästi, äläkä havaitse niitä vahinkotapahtumien aikana. Luo riippuvuuskarttoja, joita ylläpidetään kehitys- ja käyttöönottoprosessien kautta.

Vanhentumiskäytännöt määrittävät malliversioiden elinkaaret, mukaan lukien tuen keston, vanhentumisen aikajanan ja siirron vaatimukset. Selkeät vanhentumiskäytännöt hallitsevat teknistä velkaa estämällä vanhojen malliversioiden määrittämättömän tuen. Laadi vanhentumisaikataulu, joka ilmoittaa aikajanoista riittävän etukäteen, jotta voit ottaa käyttöön suunniteltuja siirtoja pakotettujen vanhentumisten hätätilanteiden sijaan. Hyvin ilmoitettu ja käytäntöön perustuva vähimmäisilmoitusjakso tarjoaa riittävän siirtymisaikaa kriittisille muutoksille.

Rollback-toimenpiteet sallivat tiimien palautua nopeasti ongelmallisista käyttöönotoista. Asiakirjojen periytymistoimenpiteet kullekin agentille, mukaan lukien:

• Ehdot, jotka käynnistävät periytymisen
• Mihin versioon palautetaan
• Miten periytyminen suoritetaan
• Kuka valtuuttaa ja suorittaa periytymisen
• Mitkä testit vahvistavat, että periytyminen onnistui ja mitkä tiimit ilmoittavat.

Testaa periytymistoimenpiteitä säännöllisesti muissa kuin tuotantoympäristöissä varmistaaksesi, että ne toimivat ennen kuin luotat niihin tuotantotapahtumien aikana. Harjoittele esimerkkitoteutuksilla, jotta tiimisi tietää tarkalleen mitä tehdä. Todentamattomat periytymismenetelmät epäonnistuvat usein, kun niitä tarvitaan eniten.

Ylläpidä agenttien laatua jatkuvalla koulutuksella, hienosäätämisellä ja hienosäätämisellä.

Palautekokoelma kerää järjestelmällisesti käyttäjien palautetta, ihmisten tarkastusten korjauksia, laatuarviointeja ja lopputulosten mittoja. Palaute tarjoaa parannettavaa raaka-ainetta. Ilman järjestelmällistä keruuta parannuksista tulee arvailuja. Kerää selkeää palautetta kysymyksistä esittämällä kysymyksiä ennen eskalointia, keskustelun jälkeen tai jatkokyselyiden kautta. Kerää epäsuoraa palautetta suoritussuhteiden, eskalointien yleisyyksien ja uudelleenyrityskuvioiden avulla. Yhdistä selkeitä ja epäsuoria signaaleja tarjotaksesi kattavan laadun perspektiivin.

Datan kuratointi ylläpitää korkealaatuisia koulutusdatajoukkoja kuratoinnin, laadun tarkastuksen ja vinoumien tarkastuksen kautta. Koulutusdatan laatu määrittää suoraan mallin laadun. Huono data tuottaa epäluotettavia malleja. Erinomainen data mahdollistaa poikkeuksellisen suorituskyvyn.

Kerää keskustelulokeja koulutusdatajoukkoihin seuraavin tavoin:

• Suodattaminen laadun perusteella – mukaan lukien korkean arvosanan saaneet keskustelut ja onnistuneet lopputulokset
• Ongelmallisten esimerkkien poistaminen – mukaan lukien turvallisuusrikkomukset ja virheet
• Edustavuuden varmistaminen – mukaan lukien erilaiset skenaariot ja reunojen tapaukset
• Identtisten esimerkkien poistaminen – lähes identtisten esimerkkien poistaminen

Voit sovittaa agentteja toimialueeseesi — erikoistuneita sanastoja, ainutlaatuisia liiketoimintaprosesseja, organisaatiokohtaista Knowledgea — ensisijaisesti datan 360:een perustuvan haun parannetun generoinnin (RAG) ja Salesforcen luoman kehotteiden säädön avulla.

Salesforcessa ei ole hienosäätetty generointimallia. Valitset ja määrität malleja tekoälymallien ja Kehotteiden rakentajan avulla. Kun maadoitus ei riitä, hienosäädä ulkoisesti ja yhdistä BYOLLM:n kautta.

Kehotteiden hienosäätö parantaa kehotteita iteratiivisesti suorituskykytietojen perusteella Kehotteiden rakentajan avulla. Kehotteiden suunnittelu on jatkuvaa harjoitusta, eikä kertaluonteista harjoitusta. Kun käyttömallit muuttuvat, liiketoimintaprosessit muuttuvat ja käyttäjien odotukset muuttuvat, kehotteet vaativat säätöjä optimaalisen suorituskyvyn ylläpitämiseksi.

Luo säännöllinen kehotteiden tarkastusvaihe, joka tutkii viimeaikaisia keskusteluita, laatutilastoja ja käyttäjien palautetta ja tunnistaa parannusmahdollisuuksia. Toteuta kehotteiden muutokset asteittain A/B-testauksella, joka vahvistaa parannukset ennen täyttä julkaisua.

Arvioinnin automatisointi suorittaa laadun arvioinnin varattujen testijoukkojen osalta, mikä mahdollistaa parannuksen ehdokkaiden nopean arvioinnin. Automatisoitu arviointi tarjoaa objektiivisen mittauksen, joka täydentää subjektiivista ihmisarviointia.

Ylläpidä testisarjoja, jotka kattavat onnelliset polut, reunojen tapaukset, vastustajien syöttämät tiedot ja historialliset ongelmakenaariot. Määritä testien automatisointi suorittaaksesi testiskenaariosi säännöllisesti. Sisällytä automatisoitu tulosten valvonta, kynnysarvot ja ilmoitukset, jotka varoittavat pääkäyttäjiä poikkeavuuksista. Tämä automatisoitu testaus on ratkaisevan tärkeää ulkoisten tekijöiden haitallisten vaikutusten havaitsemiseksi, kuten mallin kaatumisesta.

Laajenna testisarjoja jatkuvasti, kun uusia reunasta esiintyy tuotantoympäristössä. Testien automatisointi on tärkeää, mutta suorita myös säännöllisiä manuaalisia tarkastuksia, kertakäyttöisiä testejä ja gorillatestejä varmistaaksesi, että agenttien käyttöönottosi kestää edistyneitä tapauksia.

Ota agenttien muutokset käyttöön vaiheittain ja valvo laatua ennen täyttä käyttöönottoa rajoittaaksesi ongelmien rästitehoa. Kun muutos kattaa useita alueita — kehotteet, mallin kokoonpano, toiminnot, maadoitus, integraatiot — se voi heikentää toimintatapaa tavalla, jota testaus ei onnistunut havaitsemaan. Kun näin tapahtuu, tuloksena oleva laadun regressio osoittaa harvoin yhteen selkeään juurisyyn. Lähetä pienet muutokset yksi kerrallaan, jotta regressio voidaan jäljittää sen lähteeseen, ja vapauta jokainen rajatulle liikenteen osalle ensin sisällyttääksesi vaikutuksen diagnoosin aikana.

Ominaisuusmerkinnät irrottavat käyttöönoton julkaisusta ottamalla agentit käyttöön, joiden ominaisuudet eivät ole käytössä kokoonpanon jälkeen. Toteuta ominaisuusmerkintöjä käyttämällä logiikkaa tai mukautettuja metadatatyyppejä tai mukautettuja asetuksia. Ominaisuusmerkinnät sallivat testien tuotantoympäristössä paljastamatta ominaisuuksia käyttäjille, vaiheittaiset julkaisut tietyille käyttäjäsegmenteille, A/B-testauksen vertaamalla toteutuksia ja välittömän periytymisen poistamalla merkinnät käytöstä ilman uudelleenkäyttöönottoa.

Käytä ominaisuusmerkintöjä merkittäville agenttien muutoksille, joissa epäonnistumisen räjähdyssä voi olla vakava, kuten Liiketoiminta-kriittisiin agenteihin vaikuttavat muutokset, Uudet järkeilykuviot, joilla on epävarma tuotantoympäristö Integrointi ulkoisiin järjestelmiin, joissa vuorovaikutuskuviot saattavat poiketa testauksesta.

Canary-käyttöönotot vapauttavat agenttien muutokset pieniin käyttäjäjoukkoihin ensimmäiseksi valvoen virhesuhteita, laatutilastoja ja suorituskykyä ennen laajempaa julkaisua. Käytä käyttöoikeusjoukkoja hallitaksesi kanavien käyttöönottoja — rajoita agenttien käyttöoikeuksia tietyille käyttäjille tai suodata orkestrointilogiikkaa käyttäjäattribuuttien perusteella.

Valvo ja mittaa onnistumissuhteita, vastauksen laatua ja käyttäjien palautetta. Vertaa kanavien tilastoja ohjausryhmiin käyttämällä aiempaa agentin versiota. Laajenna käyttöönottoa vain, kun Canary näyttää vastaavaa tai parannettua suorituskykyä.

A/B-testaus vertaa agenttien variaatioita, jotka mittaavat laatua, kustannuksia ja käyttäjien tyytyväisyyttä. A/B-testaus tarjoaa empiirisiä tietoja parannuspäätöksistä. Ota variaatiot käyttöön satunnaisesti valituille käyttäjäalajoukoille varmistaaksesi tilastollisen voimassaolon. Mittaa lopputuloksia useista ulottuvuuksista (tarkkuus, tyytyväisyys, kustannus ja viive) tarjotaksesi kattavan vertailun.

Määritä onnistumisen ehdot ja oletus ennen A/B-testien aloittamista. Selkeät ehdot estävät epäselvät tulokset, kun jotkin tilastot parantuvat ja toiset heikkenevät. Onnistumisen ehtojen tulisi vastata liiketoimintatavoitteita (esimerkiksi "Variantti B:n täytyy vastata muuttujan A tarkkuutta 2 %:n sisällä ja vähentää kustannuksia 15 %:lla").

Champion-challenger-testaus ottaa parannetut agenttien versiot käyttöön liikenteen osajoukoille verrattuna nykyisiin versioihin. Champion-Challenger-kuvio hallitsee parannusriskiä pitämällä todennettua versiota varaosana. Jos haastaja toimii heikosti, palaa sankariksi ilman, että käyttäjällä olisi vaikutusta. Jos haastaja suoriutuu paremmin, ylennä se uudelle sankarille.

Määritä tavoitteelliset tarjousehdot, mukaan lukien näytteen vähimmäiskoko tilastollista kelpoisuutta varten, laatukynnysarvot, jotka haastajien täytyy ylittää, ja arvioinnin kesto ennen tarjouspäätösten tekemistä. Asiakirjojen tarjouskampanjan päätökset, jotka luovat seurannan, miksi agenttien versioita muutettiin.

Laadi vahinkotapahtumien havaitseminen, joka tunnistaa agenttien toimintaongelmat nopeasti kattavan valvonnan avulla.

Agentin virhetilat eroavat tavallisista sovellusten virheistä. Yleisiin virhetiloihin sisältyy:

• Hallusinaatiot – luovat todennäköisiä mutta virheellisiä tietoja
• Aiheen ulkopuoliset vastaukset - käyttäjän tarkoituksen väärinkäsitys
• Liiallinen kustannusten kulutus - poissa olevan valtuuden generointi
• Aikakatkaisuvirheet - johtopäätös kestää liian kauan
• Käyttöoikeusvirheet – valtuuttamattomien toimintojen yritys
• Integraation virheet - ulkoisen järjestelmän käytettävyys
• Turvallisuusrikkomukset – epäasiallisen sisällön luominen

Havaitse virheitä valvomalla virhesuhteita, laatutilastojen heikentymistä, kustannuspoikkeavuuksia, viiveiden kasvua ja käyttäjien eskalointeja koskevia automaattisia hälytyksiä. Täydennä käyttäjien itseraporttimekanismeja, mukaan lukien palautepyynnöt ja selkeät ohjeet palautteen antamiseen ja antamiseen, jotta voit korjata automaatiossa esiintyvät aukot.

Vahinkotapahtumien vakavuusluokitus reitittää vahinkotapahtumat asiaankuuluville vastaajille asiaankuuluvalla kiireellisyydellä. Kriittiset vahinkotapahtumat osoittavat, että tuotantoympäristö ei ole käytettävissä, joka vaikuttaa useisiin käyttäjiin, agenttien toiminnoista johtuva datan korruptioriski, tietoturvariskit tai turvallisuusrikkomukset, jotka vaativat välittömän vastauksen. Korkea vakavuus osoittaa heikentyneen laadun, joka vaikuttaa liiketoimintaan kriittisiin agenteihin tai merkittäviin kustannuskorvauksiin. Keskiarvoinen vakavuus osoittaa yksittäisiä ongelmia tai lähestyvät kynnysarvoja, jotka vaativat tutkimista toimistoaikojen aikana. Matala vakavuus osoittaa, että vahinkotapahtumien hallintaprosessin ulkopuolella on havaittu pieniä ongelmia.

Määritä vakavuusehdot objektiivisesti käyttäjien vaikutusten, räjähdyksen säteen, datan eheyden riskin ja palautuksen kiireellisyyden perusteella. Tavoiteehdot estävät todellisten ongelmien liiallisen eskaloinnin ja pienien ongelmien liiallisen eskaloinnin. Ylläpidä vahinkotapahtumien ratkaisemisen havaintojen dokumentaatiota parantaaksesi prosessia jatkuvasti.

Alkuperäiset vastausmenetelmät ohjaavat välittömiä toimenpiteitä tilanteen vakauttamiseksi. Toimenpiteisiin sisältyy:

• Poista virheellinen agentti - katkaisijan aktivointi käytöstä
• Reititä käyttäjät varavaihtoehtoihin - henkilökohtainen viestintä, yksinkertaisempi agentti, staattiset vastaukset
• Kerää diagnostisia tietoja - viimeaikaiset keskustelut, virhelokit, resurssitilastot
• Ilmoita sidosryhmille - puhelunaikaisille insinööreille, tuotteiden omistajille ja asiaankuuluville käyttäjille
• Aloita vahinkotapahtumien viestintä - tilojen sivujen päivitykset, sisäiset koordinointikanavat
• Dokumentoi alustavat vastausmenetelmät suorituskertoina, jotka mahdollistavat nopean suorituksen ilman vahinkotapahtumakohtaista tutkimista.
• Suorituskirjojen täytyy voida suorittaa puhelimitse toimiville insinööreille, joilla ei ole asiantuntemusta agenteille.

Estä epäonnistumiset ja ylläpidä toimintoja agenttien vahinkotapahtumien aikana.

Sulkeutumiskuvio poistaa epäonnistuneet agentit automaattisesti käytöstä estääkseen toistuvia virheitä ja käyttäjien vaikutuksia ongelmien ratkaisemisen aikana. Ota käyttöön katkaisimet, jotka valvovat virhesuhteita ja avaavat (poistavat agentin käytöstä), kun virhesuhde ylittää kestävän ajanjakson kynnysarvon.

Määritä katkaisijat virheiden kynnysarvolla, keston ajanjaksolla ja palautustestauksella. Esimerkiksi 50 %:n virhesuhde, jossa on viiden minuutin jakso, ja säännöllinen kokeilujakso, joka pyytää testaamaan, onko agentti toipunut. Kun piiri avautuu, reititä pyynnöt varavaihtoehtoihin. Aikakatkaisun jälkeen piiri siirtyy puolivaiheiseen tilaan, joka sallii kokeilupyyntöjen suorittamisen. Kun kokeilupyynnöt onnistuvat yhdenmukaisesti, sulje piiri ja jatka normaalia toimintaa.

Fallback-hierarkiat tarjoavat hienovaraisen laskennan, kun ensisijaiset agentit epäonnistuvat. Suunnittele varasekvenssejä, jotka yrittävät yhä yksinkertaisempia vaihtoehtoja, kunnes hyväksyttävä vastaus saavutetaan. Esimerkki varahierarkiasta: Ensisijainen hienostunut agentti → Yksinkertaisempi varmuuskopioagentti → Staattiset FAQ-vastaukset → Henkilökohtainen lähetys.

Toteuta varalogiikkaa orkestrointikerroksessa, äläkä agenteissa, mikä mahdollistaa yhdenmukaisen toimintatavan agenttien ekosysteemissä. Testaa varapolkuja säännöllisesti vahvistaaksesi, että ne toimivat tarvittaessa.

Human handoff eskaloituu ihmisagenteille, kun tekoälyn agentit eivät voi käsitellä pyyntöjä. Suunnittele siirron työnkulut, jotka säilyttävät keskustelun asiayhteyden, ilmoittavat siirron syyn, reitittävät asiaankuuluvan ammattitaidon omaaville agenteille ja seuraavat siirron yleisyyksiä, jotka paljastavat parannusmahdollisuuksia.

Valvo eskalointisuhteita aiheen, agentin ja epäonnistumisen syyn perusteella. Korkeammat suhdemäärät osoittavat, että agenttien kykyissä on aukkoja, jotka vaativat kehotteiden parantamista, Knowledge laajentamista tai käyttötapausten hienosäätämistä.

Graceful Degradation säilyttää osittaisen toiminnon heikentyneen toiminnon aikana. Kun hienostunut päättely epäonnistuu, palaa yksinkertaisempaan logiikkaan. Kun reaaliaikaista dataa ei ole saatavilla, käytä välimuistiin tallennettua dataa. Kun ulkoiset integraatiot epäonnistuvat, toimi Vain luku -tilassa. Selkeä heikentyminen sallii järjestelmän toimia pienellä kapasiteetilla, eikä se epäonnistu kokonaan.

Suorita syyttömät vahinkotapahtumien jälkeiset tarkastukset, jotka keskittyvät järjestelmän parannuksiin yksittäisten vikojen sijaan ja jotka luovat psykologista turvallisuutta rehellistä arviointia varten.

Aikajanan uudelleenrakentaminen luo yksityiskohtaisen järjestyksen alustavista ehdoista ensimmäisen signaalin, havaitsemisen, hyväksynnän, tutkimisen, vastaustoimintojen, palautuksen ja vahvistuksen kautta. Aikaleima jokaiselle tapahtumalle, joka sallii kunkin vaiheen keston analyysin, joka paljastaa, missä vahinkotapahtuman vastaus viivästyi.

Lisää aikajanallesi seuraavat tiedot:

• Mitä otettiin äskettäin käyttöön (kehotteet, kokoonpanot, mallit, integraatiot)?
• Mitä muutoksia käyttäjäkuvioissa (kiireinen liikenteen kasvu, uudet keskustelutyypit) havaittiin?
• Mitkä ulkoiset tekijät vaikuttavat siihen (kolmansien osapuolten palvelun heikentyminen, sovellusalustan päivitykset)?
• Mikä tekee havainnosta hitaampaa kuin ihanteellinen?

** Juurisyyn tunnistaminen** määrittää suoran teknisen syyn. Erota välitön syy (mallin aikakatkaisu) vaikuttavista tekijöistä (kehotteiden suunnittelu ylittää valtuuksien rajoitukset tietyissä keskustelukuvioissa). Juurisyyn analyysi estää yksinkertaiset johtopäätökset ("agentilla oli virhe") tiettyjen havaintojen puolesta, jotka johtavat tehokkaaseen korjaukseen.

Käytä "Five Why"-tekniikkaa, joka tarkentaa oireita perussyihin.

Pintaesimerkki: "Agentti tuotti virheellisiä tietoja" → "Miksi? Noudettu konteksti sisälsi vanhentuneita tietoja" → "Miksi? Knowledge ei päivitetty viimeaikaisilla tuotemuutoksilla" → "Miksi? Tuotetiimillä ei ole prosessia, joka käynnistäisi Knowledge päivityksiä" → Juurisyöte: Puuttuva työnkulku, joka yhdistää tuotejulkaisut Knowledge ylläpitoon.

Lisäävät tekijät paljastavat organisaatio-, prosessi- tai arkkitehtuurisehdot, jotka sallivat tai vahvistavat vahinkotapahtumien vaikutuksia. Yleisimpiin tekijöihin sisältyvät aukot, jotka sallivat ongelmien säilymisen havaittua pidempään, testin aukot, jotka jättävät epäonnistumisskenaariot löytämättömiksi, dokumentaation aukot, jotka hidastavat nopeaa diagnoosia, automaation aukot, jotka pakottavat manuaaliset palautusvaiheet, ja arkkitehtoniset aukot, kuten yksittäiset epäonnistumispisteet tai tarpeettomuus.

Osatekijöiden analyysi paljastaa parannusmahdollisuuksia välittömän juurisyyn korjaamisen lisäksi. Useimmilla vahinkotapahtumilla on useita osatekijöitä, joista jokaisella on vahvistava vaikutus.

Havainto-analyysi tutkii, miten vahinkotapahtuma havaittiin ja olisiko havainto voinut olla nopeampaa. Monet agenttien vahinkotapahtumat ilmoitetaan ensin käyttäjiltä automaattisen valvonnan sijaan, mikä osoittaa, että valvonta on aukossa. Määritä: Minkä signaalin olisi pitänyt havaita ongelma aiemmin? Mikä valvonta mahdollistaa nopeamman havaitsemisen? Mitä hälytysehtoja olisi käynnistetty asianmukaisesti?

Havaintoanalyysien parannuksiin sisältyy: Valvonnan puuttuvan kattavuuden lisääminen, hälytysten kynnysarvojen säätäminen virheellisten negatiivien poistamiseksi, hälytyksen kontekstin rikastaminen lajittelun nopeuttamiseksi ja mittaristojen parantaminen ongelmien ennakoivaksi tunnistamiseksi.

Vastausten arviointi arvioi, mikä meni hyvin ja mikä oli hitaampaa tai vaikeampaa kuin tarvittaessa. Vastausten arviointikysymykset: Ovatko suorituskirjat hyödyllisiä ja tarkkoja? Ovatko eskalointipolut selkeitä ja tehokkaita? Ovatko periytymistoimenpiteet testattuja ja valmiita? Tarjoavatko työkalut tarvittavat diagnostiset tiedot? Oliko viestintä oikea-aikaista ja tehokasta?

Vastausten arvioinnin parannuksiin sisältyy: suorituskirjojen päivittäminen saaduilla oppitunteilla, eskalointiehtojen selventäminen, peruutustoimenpiteiden testaaminen säännöllisesti, diagnostisten työkalujen lisääminen ja vahinkotapahtumien viestintämallien parantaminen.

Toimintojen kohteet määrittävät konkreettisia, kohdistettuja ja ajoitettuja parannuksia, jotka estävät toistumisen tai parantavat tulevia vastauksia. Vältä epätarkkoja toimintokohteita, kuten "paranna valvontaa", ja suosittele tiettyjä tehtäviä, kuten "lisää hälytys, jos agenttien virhesuhde on yli 5 % 10 minuutin ajanjakson aikana", kohdistettu: Alex, eräpäivä: 2 viikkoa."

Seuraa toiminnon kohteen valmistumista myöhemmissä tarkastuksissa varmistaaksesi, että jatkuvaa parantamista tapahtuu. Tarkasta aiempien vahinkotapahtumien avoimet toimintokohteet jokaisen vahinkotapahtuman jälkeisen tarkastuksen aikana. Pienet suoritussuhteet osoittavat, että jatkuva parantamisprosessi epäonnistuu ja vaatii huomiota.

Knowledge-jakaminen dokumentoi vahinkotapahtumien jälkeiset tarkastukset jaetussa wiki:ssä, Knowledge-tietokannassa tai yhteistyötilassa käyttämällä merkintöjä, jotka mahdollistavat kuvioanalyysin useissa vahinkotapahtumissa. Vahinkotapahtumien jälkikatseluiden tulisi olla haettavissa epäonnistumistilan, asiaankuuluvien komponenttien ja ajanjakson perusteella, jotta tulevat vastaajat voivat oppia historiallisista vahinkotapahtumista.

Jaa vahinkotapahtuman jälkeisiä tarkastuksia laajemmin kuin välittömiä vahinkotapahtuman vastaajia. Organisaation oppiminen vaatii tietojen levittämistä. Harkitse suurten vahinkotapahtumien oppimisen esittämistä tiimin kokouksissa tai lounasta- ja oppimisistunnoissa, jotka levittävät Knowledgea ja rakentavat kollektiivisia kykyjä.

Vaadi hyväksyntä ennen kuin otat tuotanto-agentteja käyttöön varmistaaksesi tarkastuksen, riskien arvioinnin ja sidosryhmien tasauksen.

Käyttöönottoa edeltävä tarkistuslista vahvistaa valmiuden, mukaan lukien:

• Kattava testaus suoritettu - toiminnallisuus, laatu, turvallisuus, suorituskyky
• Suojaustarkastus hyväksytty - käyttöoikeuksien rajat, tietojen käyttöoikeudet, toimintojen valtuutukset
• Vaatimustenmukaisuus vahvistettu - lakisääteiset vaatimukset, käytännön noudattaminen
• Dokumentaatio on valmis - suorituskerrat, peruutustoimenpiteet, eskalointipolut
• Valvonta määritetty - laatutilastot, virhesuhteet, kustannusten seuranta
• Sidosryhmän hyväksyntä saatu - tuotteen omistaja, tietoturva, vaatimustenmukaisuus

Tarkistuslista tarjoaa yhdenmukaiset arviointiehdot agenteille. Mukauta agenttien riskiprofiilien tarkistuslistaa, jonka syvyys vaihtelee agenttien kriittisyyden, datan luottamuksellisuuden ja itsenäisyyden perusteella.

Riskien arviointi arvioi agenttien virheiden mahdolliset vaikutukset, mukaan lukien:

• Räjähdyssäde – kuinka monta käyttäjää epäonnistui
• Datan luottamuksellisuus – mitä tietoagentteja käytetään
• Toiminnon valtuus – mitä muokkauksia agentti voi tehdä
• Integroinnin sidonnaisuudet – mihin järjestelmiin agentti vaikuttaa
• Palautuksen monimutkaisuus – kuinka vaikea periytyminen on
• Vaikutukset vaatimustenmukaisuuteen – mitä säännöksiä sovelletaan

Riskien arviointi määrittää hyväksymisvaatimukset. Korkean riskin agentit tarvitsevat päällikön hyväksynnän, tietoturvatarkastuksen ja asteittaisen julkaisun, kun taas vähemmän riskin agentit saattavat vaatia vertaisarviointia ja standarditestausta.

Hyväksymistyönkulut reitittävät käyttöönottopyynnöt asiaankuuluvien tarkastajien kautta. Toteuta hyväksymistyönkulkuja käyttämällä Salesforcen hyväksymisprosesseja tai ulkoisia käyttöönottotyökaluja. Automatisoi, seuraa ja auditoi hyväksymistyönkulkuja ottaaksesi vaatimustenmukaisuuden raportoinnin ja vahinkotapahtumien tutkimisen käyttöön.

Asiakirjojen hyväksymispäätökset, tarkastusketjun luominen käyttöönottojen hyväksyjistä, hyväksyntöjä koskevista tiedoista, sovellettavista ehdoista tai rajoituksista ja sitoumuksista seurantaan.

Hätätilanteiden ohitustoimenpiteet mahdollistavat nopean käyttöönoton tuotantotapahtumien aikana, kun normaalit hyväksymisprosessit viivästyttävät kriittisiä korjauksia. Hätätilanteiden toimenpiteiden tulisi vaatia päällikön hyväksyntää, sisältää perustelujen dokumentaatiota ja käynnistää nopeutetun käyttöönoton jälkeisen tarkastuksen, joka vahvistaa hätätilanteen muutokset.

Seuraa hätätoteutuksia erillään vakiomuotoisista julkaisuista. Suuren hätätilan käyttöönoton yleisyys osoittaa prosessien ongelmia, jotka vaativat tutkimista.

Määritä laatuportaalit, jotka agenttien täytyy käydä läpi ennen tuotantoympäristön käyttöönottoa estääksesi ongelmallisia agentteja saavuttamasta käyttäjiä.

Toimintojen testaaminen vahvistaa, että agentit suorittavat suunniteltuja tehtäviä oikein edustavissa skenaarioissa. Testaa tyypillisiä vuorovaikutuksia kattavia onnellisia polkuja, harvinaisia, mutta kelvollisia skenaarioita kattavia reunastapauksia, virhepolkuja, jotka testaavat, käsittelevätkö agentit virheellisiä syötettä oikein, ja rajan ehtoja, jotka tarkastavat, onko agentti hallintarajoitusten, valtuusrajoitusten ja datamäärien rajoitusten sisällä.

Agenttien toiminnalliset testit eroavat perinteisestä testauksesta, koska ei-deterministiset tulokset estävät tarkkoja vastaavuuksia. Testaa tuloksen ominaisuuksia (sisältää vaadittuja tietoja, säilyttää asiaankuuluvan äänimerkin, sisältää tarvittavat lainausmerkit) tarkan tekstin sijaan.

Vastauksen laadun testaaminen arvioi vastauksen tarkkuuden ja relevanttiuden testiskenaarioissa. Laadun testaaminen vaatii ihmisen arvioinnin tai perustietojen datajoukkoja, joilla on odotetut tulokset. Määritä agenttien täyttämät vähimmäislaadun kynnysarvot (esimerkiksi "95-prosenttinen tarkkuus myöhässä olevien testien joukossa, nolla turvallisuusrikkomusta, oikeudenmukaisuustarkastukset eivät näytä väestötieteellisiä eroavaisuuksia yli 5 %"). Ylläpidä ja laajenna testijoukkoja jatkuvasti, kun uusia reunastapauksia havaitaan.

Turvatestaus vahvistaa, että agentit hylkäävät vaarallisia, epäeettisiä tai vaikutusalueen ulkopuolisia pyyntöjä. Turvatestit yrittävät syöttää vastakkaisia tietoja, mukaan lukien:

• Pyydä ruiskutusyrityksiä - yrittää korvata ohjeita
• Jailbreak-yritykset – turvallisuusrajoitusten ohittaminen
• Pyydä eskalointia – pyydä yhä luottamuksellisempia toimintoja
• Vaikutusalueen ulkopuoliset pyynnöt – valtuuttamattomien tehtävien yritys

Kohdista turvallisuustestejä itsenäisille tiimin jäsenille, jotka eivät olleet mukana agentin rakentamisessa. Lisää riskialttiille agenteille punaisen tiimin asiantuntijoita.

Suorituskyvyn testaaminen vahvistaa, että viive, läpimeno ja kustannukset täyttävät odotukset. Testaa realistisia latauksia, mukaan lukien samanaikaiset keskustelut, tavalliset keskustelun pituudet ja ennustettu käyttöaste. Suorituskyvyn testaaminen paljastaa hallintarajoitusten ongelmat, resurssien rajoitukset ja skaalattavuuden pullonkaulat, joita ei näytetä yhden käyttäjän testauksessa.

Mittaa testiympäristön kulutusta suorituskyvyn testauksen aikana ja käytä sitä ennustaaksesi tuotantokapasiteetin tarpeita.

Tietoturvatestit vahvistavat käyttöoikeuksien rajat, tietojen käyttöoikeuksien ohjaimet ja toimintojen valtuutuksen. Suojaustestit vahvistavat: agentit eivät voi käyttää valtuuttamattomia tietoja, agentit eivät voi suorittaa valtuuttamattomia toimintoja, kehotteiden syöttäminen ei voi eskaloida käyttöoikeuksia ja kirjausloki tallentaa kaikki agenttien toiminnot.

Integroi staattisen koodin suojauksen skannaus käyttöönottoputkeen käyttämällä Salesforce Code Analyzeria, joka skannaa Apexin, kulkujen, Lightningin ja Visualforcen tietoturvariskien varalta ja joka voidaan suorittaa jatkuvassa integroinnissa/käyttöönotossa (CI/CD) sen komentorivikäyttöliittymän (CLI) tai GitHub-toiminnon kautta. Käytä erikoistuneita tekoälyn/agenttien suojaustestejä havaitaksesi kehotteiden ruiskutuksen haavoittuvuuksia ja luottamuksellisten tietojen altistumisen riskejä, koska ne ovat suoritetun LLM-syötteen uhkia staattisen koodianalyysin ulkopuolella.

Sovella agenttien käyttöönotoille muutostenhallinnan kuria varmistaaksesi, että muutokset dokumentoidaan, tarkastetaan ja ilmoitetaan.

Muutosdokumentaatio tallentaa:

• Mitä muuttui - kehotteiden muutokset, kokoonpanon päivitykset, mallin muutokset
• Miksi muutos tehtiin – laadun parantaminen, kustannusten optimointi, virheiden korjaus
• Mitkä testit vahvistivat muutoksen - testitulokset, laatupisteet, tietoturvatarkistukset
• Mikä periytymisprosessi on olemassa

Muutosdokumentaatio sallii vahinkotapahtumien tutkimisen, vaatimustenmukaisuuden raportoinnin ja Knowledge. Asiakirjoitetut muutokset luovat oppimisorganisaation, joka perustuu aiempiin kokemuksiin oppimisen sijaan.

Viestintäsuunnitelma ilmoittaa sidosryhmille agenttien muutoksista, mukaan lukien asiaankuuluvat käyttäjät, toimintotiimit, tukitiimit ja liiketoiminnan sidosryhmät. Viestinnän tulisi kuvailla: mitä tapahtuu, milloin muutos otetaan käyttöön, mitä etuja käyttäjät näkevät, mitä riskejä on olemassa ja kenen kanssa ottaa yhteyttä ongelmien varalta.

Laadi viestintämalleja eri muutostyypeille standardoimalla viestejä ja vähentämällä käyttöönottoon valmistautumista.

Käyttöönottojen ajoitus ajoittaa agenttien käyttöönotot vähäisen käytön ajanjaksojen aikana, kun Event Monitoringin data näyttää todelliset käyttökuviot. Vältä käyttöönottoja huippukäytön aikana, kuukauden lopussa, vuosineljänneksen lopussa tai suurissa liiketoimintatapahtumissa. Ilmoita käyttöönottoajat, mukaan lukien odotettu kesto ja peruutuspäätösten aikajana.

Harkitse suurten muutosten ajoittamista viikon alusta keskiviikkoon ja vältä myöhäisiä käyttöönottoja, jotta ongelmia voidaan ratkaista riittävin resurssein. Priorisoi nopea periytyminen ja vahva käyttöönoton jälkeinen valvonta minkä tahansa kiinteän kalenterisäännön päälle.

Vaihda ja jäädyttää kriittisiä liiketoiminta-aikoja. Määritä muutosten jäädyttämisen ajanjaksot ennen tärkeimpiä liiketoimintatapahtumia (tilivuoden loppuun, tuotteiden julkaisuja ja suuria markkinointikampanjoita) välttyäksesi käyttöönoton aiheuttamilta ongelmilta korkean panoksen aikana.

Asiakirjojen muutosten jäädytyskalenteri, joka ilmoittaa rajoitetut ajanjaksot tarpeeksi etukäteen vuosittain salliaksesi tiimien suunnitella ne asianmukaisesti. Liiallinen jäädyttäminen hidastaa nopeutta; riittämättömät jäädytykset aiheuttavat liiketoimintariskiä.

Laadi palautussilmukoita, jotka yhdistävät toiminnallisen telemetrian agenttien parantamiseen.

Käyttäjien palautteen kerääminen kerää selkeää palautetta kysymysten tai jatkokyselyiden kautta. Kerää epäsuoraa palautetta suoritussuhteiden, ihmisagenttien eskaloinnin, uudelleenyrityskuvioiden ja tyytymättömyyden osoittamien jatkokysymysten avulla. Yhdistä selkeitä ja epäsuoria signaaleja tarjotaksesi kattavan laadun perspektiivin.

Kerää palautetta suoraan, kun se tapahtuu, äläkä myöhemmin. Viivästynyt palautteen kerääminen vähentää vastaussuhteita ja käynnistää takaisinvedon vinouman.

Käytön analyysit paljastavat todellisia keskustelukuvioita, kuten aiheita, kysymyksiä ja toistuvia trendejä. He testaavat, ansaitseeko agentin monimutkaisuus sen säilyttämisen, eivätkö kykyjä käytetä huonojen havaintojen vuoksi ja vahvistaako todellinen käyttö alkuperäiset suunnittelun oletukset.

Kysele keskustelulokeja, jotka analysoivat kysymystyyppejä, keskustelun pituuksia, onnistumissuhteita aiheittain ja käyttäjien tyytyväisyyttä keskustelun ominaisuuksien perusteella. Käyttökuvioanalyysi opastaa kehotteiden hienosäätämisessä, Knowledge laajentamisessa ja kykyjen priorisoinnissa.

Virhekuvion analyysi tunnistaa järjestelmälliset laatuongelmat, jotka vaativat korjausta. Analysoi virhelokeja, jotka on ryhmitetty virhetyypin, asiaankuuluvien käyttäjien, keskustelukuvioiden ja aikojen mukaan. Virhemallit paljastavat kehotteiden ongelmia, Knowledge aukkoja, integraatio-ongelmia tai käsittelyä vaativia reunojen tapauksia.

Priorisoi virheenkorjaus yleisyyden ja vaikutuksen perusteella. Useisiin käyttäjiin vaikuttavat yleiset virheet vaativat välittömästi huomiota. Alhaisen yleisyyden virheet voivat edustaa hyväksyttyjä edistymistapoja liiketoiminnan vaikutusten ja korjauksen kustannusten mukaan.

Laadun trendien valvonta seuraa tarkkuutta, relevanttiutta, turvallisuutta ja tyytyväisyyttä pitkältä aikaväliltä ja havaitsee heikentymisen ennen kuin se muuttuu vakavaksi. Laadi laatuperusteita agentin ensimmäisen käyttöönoton jälkeen. Valvo jatkuvaa laatua perustason hälytysten perusteella, kun trendit laskevat hyväksyttävien kynnysarvojen yläpuolelle.

Laadunvalvonta paljastaa, parantavatko kehotteiden muutokset, mallin päivitykset vai Knowledge muutokset suorituskykyä tai heikentävät sitä, mikä mahdollistaa datan perustuvat parannuspäätökset.

Seuraa kokeita, jotka opastavat parannuspäätöksiä järjestelmällisesti empiiristen tietojen avulla.

Kokeilukehys tarjoaa yhdenmukaisen rakenteen parannusten testaamiseen, mukaan lukien:

• Hypoteesi – mitä parannusta odotetaan
• Kokeellinen suunnittelu – miten variaatiot otetaan käyttöön
• Tilastot – mitkä lopputulokset mitataan
• Näytteen koko – kuinka monta vuorovaikutusta tarvitaan tilastollisen kelpoisuuden varmistamiseksi
• Onnistumisehdot – mitkä tulokset oikeuttavat ylennyksen

Asiakirjojen ennen suoritusta tehdyt kokeilut estävät tulosten epäselvän tulkinnan. Esimääritetyt onnistumisen ehdot mahdollistavat selkeät tarjouspäätökset välttyäksesi pitkiltä keskusteluilta siitä, ovatko tulokset ”riittävän hyviä”.

Varianttien seuranta kirjaa lokiin käyttäjät, jotka ovat vastaanottaneet lopputuloksen korrelaation mahdollistavia variaatioita. Seuraa variaatioiden kohdistusta keskustelun metadatassa, joka sallii laadun, kustannusten ja tyytyväisyyden analyysin variaatioittain.

Tilastollinen voimassaolo varmistaa, että kokeilut kestävät tarpeeksi kauan ja että näytteen koko on riittävä luotettavia johtopäätöksiä varten. Laske vaadittu näytteen koko ennen kokeita vaikutuksen odotetun koon, tilastollisten virran vaatimusten ja hyväksyttävien virhesuhteiden perusteella. Riittämättömät näytteet aiheuttavat meluisia tuloksia, jotka johtavat huonoihin päätöksiin.

Monikäyttöinen bandit-optimointi kohdistaa enemmän liikennettä dynaamisesti suorituskykyisimpiin variaatioihin kokeilujen aikana. Useiden aseistettujen rosvojen lähestymistavat vähentävät mahdollisuuksien kokeilukustannuksia vähentämällä altistumista heikompiin muuttujiin ja keräämällä silti tarpeeksi dataa tilastoanalyysiä varten.

Kokemusten katalogi kirjaa lokiin kunkin kokeen variaatiot, lopputulokset ja päätökset. Se estää tiimejä testaamasta epäonnistuneita lähestymistapoja uudelleen, levittää oppimista organisaatiossa ja laatii yhteisen tietueen siitä, mitä todella toimii.

Agenttien järjestelmien toiminnan huippuosaaminen edellyttää perinteisten DevOps-käytäntöjen laajentamista yksilöllisten tekoälyn ominaisuuksien ratkaisemiseksi. Kattava havaittavuus sallii uusien agenttien toimintatapojen ymmärtämisen. Järjestelmällinen elinkaaren hallinta varmistaa laadun, turvallisuuden ja kustannusten hallinnan. Vahinkotapahtumien vastausmenetelmät käsittelevät agenttikohtaisia virhetiloja. Jatkuva parantaminen muuntaa toimintokokemuksen organisaation kapasiteetiksi.

Agenttien järjestelmien toiminnan parantamisen tärkeimmät käytännöt:

• Kirjaa koko keskustelut lokiin, mukaan lukien syötetyt tiedot, tulokset, perusteluperusteet, toiminnot ja lopputulokset.
• Valvo vastausten laatua jatkuvasti tarkkuuden, relevanttiuden, turvallisuuden ja tyytyväisyyden tilastojen avulla.
• Havaitse mallin heilahdus ja toimintatavan muutokset perustason vertailun ja poikkeavuuksien havaitsemisen avulla.
• Voit hallita kehotteita, kokoonpanoja ja malleja, jotka sallivat periytymisen ja A/B-testauksen.
• Toteuta asteittainen julkaisu käyttämällä ominaisuusmerkintöjä ja kanarian käyttöönottoja, jotka rajoittavat räjähdyksen sädettä.
• Suunnittele katkaisijat ja varahierarkiat estääksesi agenttien epäonnistumisen.
• Suorita virheettömiä vahinkotapahtumien jälkeisiä tarkastuksia, jotka keskittyvät järjestelmällisiin parannuksiin.
• Laadi laatuportaaleja ja hyväksymisprosesseja estääksesi ongelmallisia agentteja pääsemästä tuotantoympäristöön.
• Laadi palautussilmukoita, jotka yhdistävät toiminnallisen telemetrian agenttien parantamiseen.
• Seuraa kokeita järjestelmällisesti käyttämällä empiiristä näyttöä parantavien päätösten opastamiseksi.

Organisaatiot, jotka investoivat agenttien toiminnan parantamiseen, saavat kestävää kilpailuetua luotettavilla, korkealaatuisilla tekoälymahdollisuuksilla, jotka kehittyvät jatkuvasti liiketoimintatarpeiden mukaan.

Jaa palautetta hyvin rakennetusta kehysjärjestelmästä.