Kontext och åtgärder
Viktigt!
Från och med den 20 september 2023 kommer du inte att kunna skapa nya personaliseringsresurser. Personanpassningstjänsten dras tillbaka den 1 oktober 2026.
Personanpassning fungerar genom att lära sig vad ditt program ska visa för användare i en viss kontext. Kontext och åtgärder är de två viktigaste uppgifterna som du skickar till Personanpassning. Kontexten representerar den information du har om den aktuella användaren eller systemets tillstånd, och åtgärderna är de alternativ som ska väljas från.
Kontext
Information för kontexten beror på varje program och användningsfall, men den kan vanligtvis innehålla information som:
- Demografisk information och profilinformation om din användare.
- Information som extraheras från HTTP-huvuden, till exempel användaragent eller härledd från HTTP-information, till exempel omvända geografiska sökningar baserat på IP-adresser.
- Information om aktuell tid, till exempel veckodag, helg eller inte, morgon eller eftermiddag, semesterperiod eller inte, osv.
- Information som extraheras från mobila program, till exempel plats, rörelse eller batterinivå.
- Historiska aggregeringar av användarnas beteende , till exempel vilka filmgenrer som användaren har sett mest.
- Information om systemets tillstånd.
Ditt program ansvarar för att läsa in information om kontexten från relevanta databaser, sensorer och system som du kan ha. Om kontextinformationen inte ändras kan du lägga till logik i ditt program för att cachelagras den här informationen innan du skickar den till ranknings-API:et.
Åtgärder
Åtgärder representerar en lista med alternativ.
Skicka inte in fler än 50 åtgärder när du rangordnar åtgärder. De kan vara samma 50 åtgärder varje gång, eller så kan de ändras. Om du till exempel har en produktkatalog med 10 000 artiklar för ett e-handelsprogram kan du använda en rekommendations- eller filtreringsmotor för att fastställa de 40 främsta som en kund kan gilla och använda Personanpassning för att hitta den som genererar mest belöning för den aktuella kontexten.
Exempel på åtgärder
Vilka åtgärder du skickar till ranknings-API:et beror på vad du försöker anpassa.
Nedan följer några exempel:
Syfte | Åtgärd |
---|---|
Anpassa vilken artikel som är markerad på en nyhetswebbplats. | Varje åtgärd är en potentiell nyhetsartikel. |
Optimera annonsplacering på en webbplats. | Varje åtgärd är en layout eller regler för att skapa en layout för annonserna (till exempel längst upp, till höger, små bilder, stora bilder). |
Visa anpassad rangordning av rekommenderade objekt på en shoppingwebbplats. | Varje åtgärd är en specifik produkt. |
Föreslå användargränssnittselement, till exempel filter som ska tillämpas på ett visst foto. | Varje åtgärd kan vara ett annat filter. |
Välj en chattrobots svar för att förtydliga användarens avsikt eller föreslå en åtgärd. | Varje åtgärd är ett alternativ för hur du tolkar svaret. |
Välj vad som ska visas överst i en lista med sökresultat | Varje åtgärd är ett av de få sökresultaten. |
Läs in åtgärder från klientprogrammet
Funktioner från åtgärder kan vanligtvis komma från innehållshanteringssystem, kataloger och rekommenderade system. Ditt program ansvarar för att läsa in information om åtgärderna från relevanta databaser och system som du har. Om dina åtgärder inte ändras eller om de läses in varje gång har en onödig inverkan på prestanda kan du lägga till logik i ditt program för att cachelagras den här informationen.
Förhindra att åtgärder rangordnas
I vissa fall finns det åtgärder som du inte vill visa för användarna. Det bästa sättet att förhindra att en åtgärd rangordnas är genom att lägga till den i listan Exkluderade åtgärder eller inte skicka den till rankningsbegäran.
I vissa fall kanske du inte vill att händelser ska tränas på som standard. Med andra ord vill du bara träna händelser när ett visst villkor uppfylls. Den anpassade delen av webbsidan ligger till exempel under viken (användarna måste bläddra innan de interagerar med det anpassade innehållet). I det här fallet renderar du hela sidan, men vill bara att en händelse ska tränas på när användaren rullar och har möjlighet att interagera med det anpassade innehållet. I dessa fall bör du skjuta upp händelseaktivering för att undvika att tilldela standardbelöningshändelser (och träningshändelser) som slutanvändaren inte hade möjlighet att interagera med.
Funktioner
Både kontexten och möjliga åtgärder beskrivs med hjälp av funktioner. Funktionerna representerar all information som du tror är viktig för beslutsprocessen för att maximera belöningarna. En bra utgångspunkt är att anta att du har till uppgift att välja den bästa åtgärden vid varje tidsstämpel och fråga dig själv: "Vilken information behöver jag för att fatta ett välgrundat beslut? Vilken information har jag tillgänglig för att beskriva kontexten och varje möjlig åtgärd?" Funktioner kan vara generiska eller specifika för ett objekt.
Personanpassning föreskriver inte, begränsar eller åtgärdar inte vilka funktioner du kan skicka för åtgärder och kontext:
- Med tiden kan du lägga till och ta bort funktioner om kontext och åtgärder. Personalizer fortsätter att lära sig av tillgänglig information.
- För kategoriska funktioner behöver du inte fördefiniera möjliga värden.
- För numeriska funktioner behöver du inte fördefiniera intervall.
- Funktionsnamn som börjar med ett understreck
_
ignoreras. - Listan över funktioner kan vara stor (hundratals), men vi rekommenderar att du börjar med en koncis funktionsuppsättning och expanderar efter behov.
- åtgärdsfunktioner kanske eller kanske inte har någon korrelation med kontextfunktioner .
- Funktioner som inte är tillgängliga bör utelämnas från begäran. Om värdet för en specifik funktion inte är tillgängligt för en viss begäran utelämnar du funktionen för den här begäran.
- Undvik att skicka funktioner med ett null-värde. Ett null-värde bearbetas som en sträng med värdet "null" som inte är markerat.
Det är ok och naturligt för funktioner att ändras över tid. Tänk dock på att Personanpassningens maskininlärningsmodell anpassas baserat på de funktioner den ser. Om du skickar en begäran som innehåller alla nya funktioner kan personanpassningsmodellen inte använda tidigare händelser för att välja den bästa åtgärden för den aktuella händelsen. Om du har en "stabil" funktionsuppsättning (med återkommande funktioner) kan du få hjälp med prestanda för Personanpassningsmaskininlärningsalgoritmer.
Kontextfunktioner
- Vissa kontextfunktioner kanske bara är tillgängliga en del av tiden. Om en användare till exempel är inloggad på webbplatsen för onlinebutiken innehåller kontexten funktioner som beskriver inköpshistoriken. De här funktionerna är inte tillgängliga för en gästanvändare.
- Det måste finnas minst en kontextfunktion. Personanpassning stöder inte en tom kontext.
- Om kontextfunktionerna är identiska för varje begäran väljer Personalizer den globalt bästa åtgärden.
Åtgärdsfunktioner
- Alla åtgärder behöver inte innehålla samma funktioner. Till exempel, i onlinebutiksscenariot kommer mikrowavable popcorn att ha en "tillagningstid" -funktion, medan en gurka inte kommer att göra det.
- Funktioner för ett visst åtgärds-ID kan vara tillgängliga en dag, men senare blir otillgängliga.
Exempel:
Följande är bra exempel på åtgärdsfunktioner. Dessa beror mycket på varje program.
- Funktioner med egenskaper för åtgärderna. Till exempel, är det en film eller en TV-serie?
- Funktioner om hur användare kan ha interagerat med den här åtgärden tidigare. Den här filmen ses till exempel mest av personer i demografi A eller B, den spelas vanligtvis inte mer än en gång.
- Funktioner om egenskaperna för hur användaren ser åtgärderna. Innehåller affischen för filmen som visas i miniatyrbilden till exempel ansikten, bilar eller landskap?
Funktionstyper som stöds
Personanpassning stöder funktioner i sträng-, numeriska och booleska typer. Det är troligt att ditt program främst använder strängfunktioner, med några få undantag.
Hur funktionstyper påverkar maskininlärning i Personalizer
- Strängar: För strängtyper behandlas varje kombination av nyckelvärde (funktionsnamn, funktionsvärde) som en one-hot-funktion (till exempel kategori:"Producera" och kategori:"Kött" skulle internt representeras som olika funktioner i maskininlärningsmodellen).
- Numeriskt: Använd endast numeriska värden när talet är en storlek som bör påverka anpassningsresultatet proportionellt. Detta är mycket scenarioberoende. Funktioner som baseras på numeriska enheter men där innebörden inte är linjär – till exempel Ålder, Temperatur eller Personhöjd – kodas bäst som kategoriska strängar. Ålder kan till exempel kodas som "Ålder":"0-5", "Ålder":"6-10" osv. Höjden kan vara bucketed som "Height": "<5'0", "Height": "5'0-5'4", "Height": "5'5-5'11", "Height":"6'0-6-4", "Height":">6'4".
- Boolesk
- Matriser Endast numeriska matriser stöds.
Funktionsframställning
- Använd kategoriska typer och strängtyper för funktioner som inte är stora.
- Kontrollera att det finns tillräckligt med funktioner för att underlätta anpassningen. Ju mer exakt innehållet måste vara, desto fler funktioner behövs.
- Det finns funktioner i olika densiteter. En funktion är tät om många objekt grupperas i några bucketar. Till exempel kan tusentals videor klassificeras som "Long" (över 5 min långa) och "Short" (under 5 min långa). Det här är en mycket tät funktion. Å andra sidan kan samma tusentals objekt ha ett attribut som heter "Title", som nästan aldrig kommer att ha samma värde från ett objekt till ett annat. Detta är en mycket icke-tät eller gles funktion.
Att ha funktioner med hög densitet hjälper Personalizer att extrapolera inlärning från ett objekt till ett annat. Men om det bara finns några få funktioner och de är för kompakta, kommer Personalizer att försöka att exakt rikta innehåll med bara några bucketar att välja mellan.
Vanliga problem med funktionsdesign och formatering
- Skickar funktioner med hög kardinalitet. Funktioner som har unika värden som sannolikt inte upprepas över många händelser. PiI som är specifikt för en enskild person (till exempel namn, telefonnummer, kreditkortsnummer, IP-adress) bör till exempel inte användas med Personanpassning.
- Skicka användar-ID: t Med ett stort antal användare är det osannolikt att den här informationen är relevant för personaliserarens inlärning för att maximera den genomsnittliga belöningspoängen. Att skicka användar-ID :er (även om de inte är PII) kommer sannolikt att lägga till mer brus i modellen och rekommenderas inte.
- Skicka unika värden som sällan inträffar mer än några gånger. Vi rekommenderar att du bucketar dina funktioner till en högre detaljnivå. Till exempel kan det vara användbart att ha funktioner som
"Context.TimeStamp.Day":"Monday"
eller"Context.TimeStamp.Hour":13
eftersom det bara finns 7 respektive 24 unika värden. Men är"Context.TimeStamp":"1985-04-12T23:20:50.52Z"
mycket exakt och har ett extremt stort antal unika värden, vilket gör det mycket svårt för Personanpassning att lära sig av det.
Förbättra funktionsuppsättningar
Analysera användarbeteendet genom att köra ett funktionsutvärderingsjobb. På så sätt kan du titta på tidigare data för att se vilka funktioner som i hög grad bidrar till positiva belöningar jämfört med de som bidrar mindre. Du kan se vilka funktioner som hjälper, och det är upp till dig och ditt program att hitta bättre funktioner att skicka till Personalizer för att förbättra resultaten ytterligare.
Utöka funktionsuppsättningar med artificiell intelligens och Azure AI-tjänster
Artificiell intelligens och färdiga Azure AI-tjänster kan vara ett mycket kraftfullt tillägg till Personanpassning.
Genom att förbearbeta dina objekt med hjälp av tjänster för artificiell intelligens kan du automatiskt extrahera information som sannolikt är relevant för anpassning.
Till exempel:
- Du kan köra en filmfil via Video Indexer för att extrahera scenelement, text, attityd och många andra attribut. Dessa attribut kan sedan göras mer kompakta för att återspegla egenskaper som de ursprungliga objektmetadata inte hade.
- Bilder kan köras genom objektidentifiering, ansikten genom sentiment osv.
- Information i text kan utökas genom att extrahera entiteter, sentiment och expandera entiteter med Bing-kunskapsdiagram.
Du kan använda flera andra Azure AI-tjänster, till exempel
Använda inbäddningar som funktioner
Inbäddningar från olika Machine Learning-modeller har visat sig vara affektiva funktioner för Personanpassning
- Inbäddningar från stora språkmodeller
- Inbäddningar från Azure AI Vision-modeller
Namnrymder
Du kan också ordna funktioner med hjälp av namnområden (relevanta för både kontext- och åtgärdsfunktioner). Namnområden kan användas för att gruppera funktioner efter ämne, källa eller någon annan gruppering som passar i ditt program. Du avgör om namnområden används och vad de ska vara. Namnrymder organiserar funktioner i distinkta uppsättningar och tvetydiga funktioner med liknande namn. Du kan se namnrymder som ett prefix som läggs till i funktionsnamn. Namnområden bör inte kapslas.
Följande är exempel på funktionsnamnområden som används av program:
- User_Profile_from_CRM
- Tid
- Mobile_Device_Info
- http_user_agent
- VideoResolution
- DeviceInfo
- Vädret
- Product_Recommendation_Ratings
- current_time
- NewsArticle_TextAnalytics
Namngivningskonventioner och riktlinjer för namnområde
- Namnområden bör inte kapslas.
- Namnområden måste börja med unika ASCII-tecken (vi rekommenderar att du använder namnområden som är UTF-8-baserade). För närvarande kan namnrymder med samma första tecken leda till kollisioner. Därför rekommenderar vi starkt att namnrymderna börjar med tecken som skiljer sig från varandra.
- Namnrymder är skiftlägeskänsliga. Till exempel
user
ochUser
kommer att betraktas som olika namnområden. - Funktionsnamn kan upprepas mellan namnområden och behandlas som separata funktioner
- Följande tecken kan inte användas: koderna < 32 (kan inte skrivas ut), 32 (blanksteg), 58 (kolon), 124 (rör) och 126–140.
- Alla namnområden som börjar med ett understreck
_
ignoreras.
JSON-exempel
Åtgärder
När du anropar Rank skickar du flera åtgärder att välja mellan:
JSON-objekt kan innehålla kapslade JSON-objekt och enkla egenskaper/värden. En matris kan endast inkluderas om matrisobjekten är tal.
{
"actions": [
{
"id": "pasta",
"features": [
{
"taste": "salty",
"spiceLevel": "medium",
"grams": [400,800]
},
{
"nutritionLevel": 5,
"cuisine": "italian"
}
]
},
{
"id": "ice cream",
"features": [
{
"taste": "sweet",
"spiceLevel": "none",
"grams": [150, 300, 450]
},
{
"nutritionalLevel": 2
}
]
},
{
"id": "juice",
"features": [
{
"taste": "sweet",
"spiceLevel": "none",
"grams": [300, 600, 900]
},
{
"nutritionLevel": 5
},
{
"drink": true
}
]
},
{
"id": "salad",
"features": [
{
"taste": "salty",
"spiceLevel": "low",
"grams": [300, 600]
},
{
"nutritionLevel": 8
}
]
}
]
}
Kontext
Kontexten uttrycks som ett JSON-objekt som skickas till ranknings-API:et:
JSON-objekt kan innehålla kapslade JSON-objekt och enkla egenskaper/värden. En matris kan endast inkluderas om matrisobjekten är tal.
{
"contextFeatures": [
{
"state": {
"timeOfDay": "noon",
"weather": "sunny"
}
},
{
"device": {
"mobile":true,
"Windows":true,
"screensize": [1680,1050]
}
}
]
}
Namnrymder
I följande JSON, user
, environment
, device
och activity
är namnområden.
Kommentar
Vi rekommenderar starkt att du använder namn för funktionsnamnområden som är UTF-8-baserade och börjar med olika bokstäver. Till exempel , , , och activity
börja med u
, e
, d
och a
. device
environment
user
För närvarande kan namnrymder med samma första tecken leda till kollisioner.
{
"contextFeatures": [
{
"user": {
"profileType":"AnonymousUser",
"Location": "New York, USA"
}
},
{
"environment": {
"monthOfYear": "8",
"timeOfDay": "Afternoon",
"weather": "Sunny"
}
},
{
"device": {
"mobile":true,
"Windows":true
}
},
{
"activity" : {
"itemsInCart": "3-5",
"cartValue": "250-300",
"appliedCoupon": true
}
}
]
}