Hoppa till innehållet

Fortsätt hantera supportärenden när AI-tjänsten fallerar

Skilj mottagningen av ett ärende från AI-steget. Planera begränsade återförsök, osäkra lagringsutfall och teamets möjlighet att fortsätta.

Lukas Schneider2 min läsning
Blå handbok med larmsymbol, personsymboler, pratbubblor och ett stoppur.

Ett supportärende ska kunna hanteras av teamet även när den automatiska sammanfattningen fallerar. Applikationen behöver ett fastställt flöde utan den funktionen. Upprepade modellanrop håller inte arbetsprocessen igång på egen hand.

Skilj mottagningen från AI-steget

I denna fiktiva portal sparas en teknisk förfrågan först i ärendelagret. Mottagningsidentifieraren är F-81. En mottagningsbekräftelse visas först efter bekräftad lagring. Därefter ska en AI-tjänst skapa en intern sammanfattning. Originalmeddelandet förblir läsbart för ansvarigt team.

Om sammanfattningen fallerar kan det sparade ärendet hanteras vidare i den avsedda arbetskön. Gränssnittet visar den väntande sammanfattningen och får inte ange ett färdigbehandlat ärende. Utformningen kräver att lagring, rättigheter och manuell hantering fungerar oberoende av AI-steget som fallerat.

Koppla feltyper till nästa steg

Microsoft skiljer i Retry-mönstret mellan tillfälliga fel och fall där upprepning inte är meningsfull. Bestäm lämpliga tids- och försöksgränser för den aktuella tjänsten. Tabellen beskriver exempelreaktioner som förväntas:

Problem

Planerad reaktion

Synligt tillstånd

AI-anropet når en tidsgräns

Försök igen begränsat och med pauser; lämna sedan till teamet

Sammanfattning väntar

Åtkomst till AI-tjänsten nekas

Stoppa automatiska försök och låt integrationen undersökas

Teamet kan fortfarande hantera ärendet

Bekräftelse på ursprunglig lagring saknas

Klarlägg först det befintliga lagringsutfallet

Mottagning ännu inte bekräftad

Vid nekad åtkomst kontrollerar ansvarig teknisk kontakt konfiguration och behörigheter. Applikationen utökar inte själv sina rättigheter som svar.

Klarlägg först ett osäkert skrivutfall

Ett förlorat svar kan betyda att lagringen redan har lyckats. Microsoft lyfter upprepade effekter när icke-idempotenta operationer utförs igen. Idempotent betyder här att upprepning av samma uppdrag inte ger någon ytterligare verksamhetseffekt.

Lagringsflödet måste hantera upprepningar av samma mottagningsidentifierare inom rätt behörighetsområde och kunna återge ett befintligt utfall. En identifierare ensam säkerställer inte detta. Ett okänt tillstånd får inte tvinga fram ett andra ärende med en ny identifierare.

Bestäm återupptagning och ansvar

NIST-profilen för generativ AI behandlar återställningsplaner, kontaktvägar och alternativa processer. Bestäm vem som tar över öppna ärenden och när automatiskt arbete får återupptas. En sent anländ AI-text får inte okontrollerat skriva över manuellt arbete som har granskats under tiden.

Testa avbrott, nekad åtkomst, okänt lagringsutfall och tjänstens återkomst efter manuell hantering. Kontrollera varje gång originalmeddelandet, synligt ärendetillstånd och nästa användbara steg. Ett gränssnitt som går att nå igen visar inte ensamt att alla öppna ärenden har fortsatt korrekt.

Källor

Skriven av

  • Lukas SchneiderTeknisk redaktörLukas Schneider skriver om molnteknik och drift av applikationer på ASES. Hans artiklar sträcker sig från val av infrastruktur till underhåll och säkerhetskopiering samt övervakning av system i drift.

Följ ASES

Läs vidare

Alla artiklar

AI & automatisering med ASES

AI-assistenter och automatiserade flöden