Bruke hensikter i agentoptimalisering
Arbeid med hensikter i Agentoptimalisering for å forstå brukerforespørsler, analysere interaksjonsmønstre og forbedre agentens ytelse.
Nødvendige utgaver
| Tilgjengelig i Enterprise, Performance og Ubegrenset Edition med et Einstein for Sales, Einstein for Platform, Einstein for Service, Einstein 1 Service eller Einstein GPT Service-tillegg. Hvis du vil kjøpe tillegg, kontakter du din Salesforce-kundeansvarlige. |
| Få tilgang til og vise agentoptimalisering | Tildele tillatelsessettene Tilgang til agentoptimalisering og Data Cloud-bruker |
Hensikter representerer sett interaksjoner i en økt som håndterer en bestemt brukerforespørsel. Bruk hensikter til å forstå hva brukere spør og hvordan agenten svarer. Hvis du støter på problemer med generering av hensikter eller klynger, kan du se Feilsøke agentoptimalisering.
Hensiktsanalyse og -klynger
Agentoptimalisering bruker hensiktsgenerering og klynger under behandling til å analysere øktdata. Hensiktsledningen analyserer økter for å identifisere og generere hensikter. Clustering pipeline grupperer hensikter etter delte brukermål og tildeler klyngekoder til hensikter som oppfyller semantiske og størrelsesterskler.
Hensikten er å utlede hensikter fra avsluttede økter. Pipeline grupperer deretter hensikter som uttrykker lignende brukermål, slik at du kan analysere mønstre på et kodenivå i stedet for bare per rå hensikt.
Minste klyngestørrelse: Pipelinen danner en klynge bare når minst 10 hensikter er tilstrekkelig like i betydning. Mindre grupper med lignende hensikter blir ikke til en klynge og mottar ikke en klyngekode.
Hensikter som ikke er gruppert: Alle hensikter som ikke er plassert i en klynge med minst 10 semantiske samsvar, får ikke en kode. Klynger evaluerer hensikter fra omtrent den siste måneden med data. Jobben kjører omtrent én gang i uken, så hvis en hensikt ikke er kodet i en gitt kjøring, kan den evalueres på nytt i påfølgende kjøringer (vanligvis noen flere ukentlige overføringer). Hvis den fremdeles ikke slutter seg til en kvalifiseringsklynge etter at disse har blitt overført, beholdes den uten en klyngekode.
Session trace og untagged intentions: Øktsporing viser bare kodede hensiktsforekomster (de som sluttet seg til en klynge). En ikke-kodet hensiktsforekomst vises ikke i øktsporingen, selv om økten har en hensikt. Hvis det mangler en hensikt i øktsporingen, kan det være en ikke-kodet forekomst. Se Feilsøke agentoptimalisering.
Viktige punkter om tid og forsinkelse
Se gjennom tidsegenskaper for å forstå når hensikter og klynger blir tilgjengelig i analyser.
| Tidsplanleggingskomponent | Varighet | Notater |
|---|---|---|
| Avslutningsdeteksjon av økt | Umiddelbart til 3 timer | Eksplisitt avslutning eller antatt avslutning etter inaktivitet |
| Hensiktsplanleggingssyklus | Hver tredje time | Maksimal ventetid før første evaluering |
| Varighet for hensikt under arbeid | 4–24 timer | Typisk: 4–5 timer. Maksimum: 24 timer |
| Clustering Pipeline Duration (Varighet for klynge under arbeid) | Opptil 24 timer | Varierer etter datavolum og kompleksitet |
Livssyklus for hensiktsanalyse
Når du aktiverer Agentoptimalisering, registrerer systemet nye økter, behandler dem gjennom planlagte pipelines og genererer innsikt.
Vurderinger om Pipeline Run:
- Hvis du tidligere har aktivert STDM i Oppsett, vil den første pipelinekjøringen generere innsikt for hensikter de siste 30 dagene. Påfølgende pipelinekjøringer bruker data fra de siste sju dagene.
- Hvis du ikke har aktivert STDM ennå, analyseres innsikter bare fra det øyeblikket du aktiverer den og videre.
Optimization Pipeline (Optimalisering under arbeid)
Hensiktsanalyseprocessen har forskellige faser, der administrerer sessionbehandling, pipelineudførelse og datavalidering. Hver fase har spesifikke utløsere, betingelser og tidskrav.
Analysen starter når en økt avsluttes eller når systemet antar at den avsluttes etter inaktivitet. Analyseklokken sporer øktaktivitet og bestemmer når behandling under behandling skal starte. Når en økt vurderes som "avsluttet" (på grunn av avslutning eller etter 3 timer med inaktivitet), starter pipelinen.
| Utløsertype | Beskrivelse | Tidsplan |
|---|---|---|
| Eksplisitt avslutning | Bruker eller system avslutter økten eksplisitt | Umiddelbart |
| Forutsagt avslutning (Inaktivitetstidsavbrudd) | Økt antas å være avsluttet etter 3 timer med inaktivitet | Etter 3 timer |
Hensiktsplanlegging og Pipeline-utførelse
Hensiktsplanlegger kjører hver tredje time for å evaluere betingelser for utførelse av pågående arbeid. Planleggeren bestemmer om en enkelt økt skal behandles ved første kjøring eller flere økter i en gruppe ved påfølgende kjøringer.
Hensikt Pipeline behandler økter for å generere hensikter. Typisk varighet er 4-5 timer, men kan ta opptil 24 timer.
| Parameter | Verdi |
|---|---|
| Scheduler Frequency (Planlagt frekvens) | Hver tredje time |
| Typisk varighet | 4-5 timer |
| Maksimal varighet | 24 timer |
Utløser for hensiktsklynger
Når hensiktspipelinen har generert hensikter, venter systemet 12 timer før klyngepipelinen utløses. Denne forsinkelsen tillater at tilstrekkelige økter med genererte hensikter akkumuleres for meningsfylt klyngeanalyse. Klynger krever minst 10 semantisk like hensikter. Hensikter som aldri slutter seg til en slik klynge, mottar ikke en kode.
| Utløserbetingelse | Beskrivelse |
|---|---|
| Første vellykkede hensiktskjøring under arbeid | Hensikt under arbeid fullfører sin første kjøring og genererer hensikter |
Klyngen under behandling grupperer hensikter etter delt brukermål på tvers av flere økter. Pipelinevarighet kan ta opptil 24 timer. Systemet evaluerer datatilstrekkeligheten ved å telle økter med genererte hensikter. Hvis det generelle samtalevolumet er lite, er det ikke sikkert at det er nok data ennå for at klyngepipelinen skal kjøre effektivt – dette er ofte den begrensende faktoren før regler per klynge brukes.
I en klyngekjøring eksisterer en klynge (og dens kode) bare når modellen finner minst ti hensikter som er semantisk like. Grupper med færre enn 10 samsvarende hensikter danner ikke en klynge. Disse hensiktene forblir ikke kodet for det utfallet og vises ikke i øktsporingen. Et stort totalt antall hensikter garanterer ikke klynger hvis de ikke grupperes i sett med lignende betydning.
Klynger tar generelt hensyn til hensikter fra omtrent den siste måneden med data. Klyngejobben kjører omtrent én gang i uken, så hensikter som ikke er kodet i én kjøring, kan vurderes på nytt i de neste flere ukentlige kjøringer. Hvis en hensikt fremdeles ikke havner i en kvalifiseringsklynge etter at de har blitt overført, mottar den ikke en klyngekode.
Når det ikke er tilstrekkelige data tilgjengelig på øktnivå, venter systemet på at flere økter skal akkumulere hensikter før klyngen forsøker på nytt.
| Parameter | Verdi |
|---|---|
| Maksimal varighet | Opptil 24 timer |
| Typiske økter for generering av hensikter | 5–7 økter |
| Datatilstrekkelighetsmål for klynger | 50 økter med hensikter |
| Minste antall hensikter per klynge (for en kode) | 10 semantisk lignende hensikter |
| Vinduet for evaluering av klynger | Omtrent den siste måneden med hensikter |
| Klyngekadens | Omtrent én gang per uke |
| Hensikter utenfor en kvalifiserende klynge | Ingen klyngekode, vises ikke i øktsporingen før den er kodet, kan vurderes på nytt ved senere ukentlige kjøringer, og forblir deretter ikke kodet hvis den aldri klynger |
| Handling med ikke tilstrekkelige data | System venter på flere økthensikter |
