Inception: Mercury Decide

Mercury Decide är Inceptions modell för strukturerade beslut över angivet underlag. Den kombinerar ett gemensamt tillstånd med namngivna frågor och returnerar typade svar med sannolikheter. Resultatet kan vara en vald kategori, en uppskattad ja/nej-sannolikhet eller en position på en definierad skala. Profilen tjänar ett avgränsat beslut som programvara kan tolka; dess dokumenterade gränssnitt genererar inget fritt formulerat chattsvar.

Gemensamt tillstånd och meningsfulla frågenamn

Producentens begäran innehåller en modell, ett tillstånd och en icke-tom mappning av frågor. Frågenamnen bevaras i svarsmappningen. Ange den information som behövs för att bedöma varje fråga, och namnge frågorna efter de resultat som arbetsflödet använder, till exempel category, priority eller needs_follow_up. Flera frågor utvärderar samma underlag oberoende av varandra. Att de ligger i samma begäran gör inte att en senare fråga beror på ett tidigare svar.

Inceptions exempel använder ett JSON-objekt för tillståndet. Guiden tillåter också strängar, objekt eller arrayer i tillståndet, instruktionerna och kriteriebeskrivningarna, där instruktioner är valfria eller kan vara null. Bevara användbar struktur när underlaget redan består av fält, och håll ett dokument eller meddelande identifierbart när du anger text. För ett supportärende tar du med den faktiska förfrågan och relevanta fakta i stället för en uppmaning att härleda saknad kontext.

Noul: ett uppskattat positivt svar

En noul-fråga representerar ett ja/nej-villkor. Dess utdata är en sannolikhet från 0 till 1 för att det positiva svaret gäller. Valfria beskrivningar för sant och falskt kan ange vad som räknas på respektive sida av frågan. Fråga till exempel om ett meddelande uttryckligen begär en ersättningsvara och skilj det från ett allmänt klagomål på varan. Sannolikheten ger en numerisk bedömning; applikationen väljer tröskeln och den resulterande åtgärden i arbetsflödet.

Håll villkoret så snävt att underlaget kan avgöra det. Om en fråga blandar huruvida användaren vill ha hjälp, huruvida en vara är defekt och huruvida ärendet är brådskande, dela upp villkoren. Behåll den returnerade sannolikheten tillsammans med frågedefinitionen så att en senare granskare kan se vad talet faktiskt mäter.

Choice: att välja ett namngivet alternativ

En Choice-fråga använder en mappning av ett till 255 alternativnamn och beskrivningar; beskrivningarna kan vara null. Det returnerade valet är det angivna alternativ som har högst sannolikhet. Resultatet innehåller också en sannolikhet för varje alternativ samt konfidens. Definiera tydligt åtskilda betydelser för kategorierna, och ta med en reservkategori när vissa indata kommer att hamna utanför de specifika alternativen. Korta utdatanycklar kan identifiera kategorier medan utförligare beskrivningar fastställer gränserna mellan dem.

En routningsinstruktion kan skilja mellan ett åtkomstproblem, en produktfråga och ett rapporterat fel. Ange betydelsen av varje alternativ och tillhandahåll meddelandet som ska routas. Utdatan är en vald kategori med en fördelning, inte en instruktion som redan har ändrat en kö eller kontaktat ett annat system. Granska konkurrerande sannolikheter när ett fall är tvetydigt i stället för att tolka den vinnande etiketten som bevis på säkerhet.

Score: en förväntad position på en bedömningsmatris

En Score-fråga använder en ordnad array med en till tio nivåbeskrivningar, med början på nivå 0. Dess poäng är det sannolikhetsviktade medelvärdet av nivåindexen och kan hamna mellan nivåer. Svaret innehåller nivåförklaringen, sannolikheter per nivå och konfidens. Definiera ordningen och kriterierna för varje nivå, till exempel ingen omedelbar påverkan, ett problem med ett fungerande alternativ och en helt blockerad uppgift.

En förväntad decimalpoäng är användbar för prioritering eller aggregering. Den skiljer sig från att välja den enskilt mest sannolika nivån. Behåll nivåförklaringen tillsammans med talet så att en poäng inte tolkas på en orelaterad skala. Konfidens för Choice och Score rapporteras separat mellan 0 och 1; den aktuella guiden definierar den inte som identisk med den största alternativsannolikheten och anger ingen universell formel för att rekonstruera den.

Förbereda ett användbart beslutsresultat

Ett och samma underlag kan stödja oberoende frågor om kategori, brådska och villkor. En dokumentgranskningsuppgift kan fråga om ett obligatoriskt ämne finns med, välja dess kategori och betygsätta dess relevans på beskrivna nivåer. Använd bara källmaterial som finns i tillståndet, med kriterier kopplade till det beslut som arbetsflödet behöver härnäst. Om en åtgärd kräver ett tidigare resultat, gör det resultatet explicit i underlaget för nästa steg i stället för att anta att frågorna bildar en dold sekvens.

Svaret returnerar modellnamnet och en svarsmappning med de angivna frågenamnen som nycklar. Choice-sannolikheter använder alternativnamnen; Score-sannolikheter använder strängindex, där nivåförklaringen förklarar indexen. Håll ihop tillståndets identifierare, frågedefinitionerna och de typade svaren. Det ger en tolkningsbar klassificerings- eller betygsartefakt i stället för ett tal som är frikopplat från de fakta som gav upphov till det.

Gränssnittets omfång och gränser

Inception dokumenterar Mercury Decide via sitt dedikerade beslutsgränssnitt. Det stöder inte tillverkarens gränssnitt för chattkompletteringar, strömning eller verktygsanrop, så förmågor från Mercurys profiler för resonemang, röst och kodgenerering ska inte överföras till denna modell. Beslutsguiden anger antalet alternativ och nivåer men ger ingen numerisk tokengräns för tillståndet och inget tak för antalet frågor; håll det gemensamma underlaget fokuserat på de frågor som utvärderas.

Bedöm sannolikheter och kategorigränser på representativt märkt material från den avsedda uppgiften. Granska gränsfall mot tillståndet och håll saknad information synlig som saknad i stället för att ersätta den med påhittade fakta. Ett användbart resultat från Mercury Decide ger ett slutet beslut, dess sannolikheter och de definitioner som behövs för att förstå det; den omgivande applikationen avgör hur resultatet blir routning, prioritering eller ett granskningsutfall.