Ge varje AI-återkopplingsmeddelande ett beläggsläge och en ansvarig

Använd fyra synliga lägen innan du skriver välformulerad löptext. ”Stöds nu” betyder att det visade påståendet går att koppla till en namngiven aktuell indata, systempost eller slutförd händelse. ”Villkorad slutsats” anger förutsättningen som måste fortsätta gälla. ”Okänt” pekar ut saknade indata, otillgängliga källor eller olösta motsägelser utan att fylla i luckan. ”Åtgärdsstatus” anger begärd, köad, skickad, bekräftad, slutförd eller misslyckad endast när systemet kan observera den övergången. NIST:s profil för generativ AI förklarar att genererat innehåll kan vara felaktigt men ändå presenteras med självsäkerhet, så en självsäker ton är ingen statussignal. Håll enskilda påståenden åtskilda: en kalenderpost kan skapas medan en extern inbjudan fortfarande väntar på bekräftelse. Slå inte ihop båda till ”Allt är ordnat”. Varje kort bör visa vilket stöd det har och när det senast kontrollerades.

Ett löfte är giltigt endast om den ansvariga kan utföra åtgärden och observera att den slutförts. Ange vem som ansvarar för nästa steg: den här produkten, användaren, en namngiven extern tjänst eller en person utanför systemet. Visa sedan förutsättningar, en faktisk tidsfrist eller uppskattning, kontrollpunkten för nästa avstämning och möjliga slutlägen: slutfört, avböjt, utgånget, misslyckat eller väntar fortfarande. ”Jag ser till att de svarar i morgon” saknar en ansvarig som kan styra utfallet. ”Inbjudan skickad av den här appen; mottagarens svar ligger utanför appen; kontrollera igen på tisdag” skiljer mellan kontroll och beroende. Microsoft HAX rekommenderar tydliga gränser för förmåga och prestanda. Låt inte assistentens jag-formuleringar i tysthet överföra en extern parts skyldighet till modellen. Om ingen aktör ansvarar för resultatet, formulera det som ett alternativ, inte ett åtagande.

En fotnot eller allmän friskrivning kan inte rätta till en statusetikett utan villkor. Placera det avgörande villkoret intill meningen: ”Baserat på det anslutna schemat just nu”, ”om lokalens öppettider inte ändras” eller ”något kvitto har inte kommit än”. Tid har tre olika funktioner. Tidsstämpeln för belägget anger när underlaget observerades; den utlovade kontrollpunkten anger när den ansvariga agerar eller kontrollerar igen; giltighetstiden anger när påståendet inte längre får återanvändas. Externa data, behörigheter, appversioner och användarändringar kan förändras oberoende av varandra. När ett beroende löper ut eller kopplas från ska statusen nedgraderas i stället för att gårdagens självsäkra formulering står kvar. OECD:s transparensvägledning stöder meningsfull, kontextuell information om indata och begränsningar. Gränssnittet bör bevara tidigare formuleringar i en logg endast om de tydligt är daterade, inte presentera dem som aktuell sanning.

Ett användbart meddelande om osäkerhet ger fortfarande en avgränsad nästa åtgärd. Google PAIR rekommenderar att man förklarar vad som saknas och erbjuder en väg framåt; det kan innebära att försöka igen efter en kontrollpunkt, återansluta en källa, redigera indata, byta till en manuell väg, avbryta begäran eller lämna frågan olöst. Knapptexten ska beskriva åtgärden, inte utlova följden: ”Skicka begäran”, inte ”Få godkännande”; ”Kontrollera tillgänglighet”, inte ”Boka utan problem”; ”Be om ett förtydligande”, inte ”Lös det nu”. Återkopplingskontroller behöver också en ärlig beskrivning av effekten. Om en korrigering bara ändrar den aktuella visningen, säg det; om den läggs i en granskningskö för senare, ange omfattning och tidpunkt. Ett tackmeddelande får inte antyda att den underliggande modellen redan har ändrats.

Använd ofarliga testdata och granska observerbara gränssnittslägen. Koppla från en extern källa efter ett positivt svar; återkalla en nödvändig behörighet; fördröj den externa bekräftelsen förbi kontrollpunkten; ange en andra indata som strider mot den första; öppna ett gammalt resultat igen efter att det har gått ut. Kontrollera i varje fall om rubriker, märken, aviseringar, sammanfattningar och genererade uppföljningar nedgraderas samtidigt. Ett fel får inte lämna kvar ”klart”, ”säkert”, ”alltid” eller en framtidsform som produkten inte längre kan ansvara för. Kontrollera att den tillgängliga åtgärden fortfarande passar läget: återanslut, redigera, försök igen, avbryt, välj manuell hantering eller låt det förbli okänt. Undersök inte dolda skyddsmekanismer och skapa inte riskfyllt innehåll. Dokumentera indata, beroende, tidsstämpel, förväntat slutläge, observerad formulering och version så att felet går att återskapa.

Granska varje betydelsefull återkopplingskomponent i en logg med sju kolumner: beläggsläge; villkor; okänt; åtgärd som går att styra; externt beroende; ansvarig, tid och fel; giltighetstid. En release blir godkänd när varje mening motsvarar ett läge, varje löfte har en ansvarig med förmåga att genomföra det, beroenden är synliga, utgången giltighet leder till en nedgradering och alla negativa tester når ett ärligt slutläge. Den underkänns när det visuella intrycket av säkerhet överstiger beläggen, slutförande härleds från att något skickats, en uppskattning blir en tidsfrist, användaråterkoppling beskrivs som en omedelbar modelluppdatering eller inaktuellt innehåll förblir aktivt. Kombinera granskning av text med granskning av händelselägen: ändrade adjektiv kan inte åtgärda en backend som bara visar framgång. Den här grinden utvärderar produktens återkoppling. Det separata arbetsflödet för faktagranskning gäller fortfarande när en användare behöver verifiera ett visst svar.