Transparensanteckning för namngiven entitetsigenkänning inklusive personligt identifierbar information (PII)

Vad är en transparensanteckning?

Ett AI-system omfattar inte bara tekniken, utan även de personer som ska använda den, de personer som påverkas av den och miljön där den distribueras. Att skapa ett system som är lämpligt för sitt avsedda syfte kräver en förståelse för hur tekniken fungerar, dess funktioner och begränsningar och hur du uppnår bästa prestanda. Microsofts transparensanteckningar är avsedda att hjälpa dig att förstå hur vår AI-teknik fungerar, vilka val systemägare kan göra som påverkar systemets prestanda och beteende samt vikten av att tänka på hela systemet, inklusive teknik, människor och miljö. Du kan använda Transparensanteckningar när du utvecklar eller distribuerar ditt eget system eller delar dem med de personer som kommer att använda eller påverkas av systemet.

Microsofts transparensanteckningar är en del av ett bredare arbete hos Microsoft för att omsätta våra AI-principer i praktiken. Mer information finns i Ansvarsfulla AI-principer från Microsoft.

Introduktion till namngiven entitetsigenkänning och personligt identifierbar information (PII)

Azure AI Language stöder namngiven entitetsigenkänning för att identifiera och kategorisera information i din text. Dessa omfattar allmänna entiteter som produkt- och händelse- och PII-entiteter (Personligt identifierbar information). En mängd olika personliga entiteter , till exempel namn, organisationer, adresser, telefonnummer, ekonomiska kontonummer eller koder samt myndighets- och lands- eller regionsspecifika identifieringsnummer kan identifieras. En delmängd av dessa personliga entiteter är skyddad hälsoinformation (PHI). Om du anger domain=phi i din begäran får du bara de PHI-entiteter som returneras. Den fullständiga listan över PII- och PHI-entitetskategorier finns i tabellen här. Dessutom stöder PII-igenkänning möjligheten att ange specifika entitetskategorier som du vill använda i svaret och redigera PII-entiteter i svaret. PII-entiteterna ersätts av asterisker i redactedText -egenskapen för svaret.

Läs exempel på NER-begäran och exempelsvar för att se hur du skickar text till tjänsten och vad du kan förvänta dig tillbaka.

Exempel på användningsfall

Kunder kanske vill känna igen olika kategorier av namngivna entiteter två huvudsakliga orsaker:

• Förbättra sökfunktionerna – Kunder kan skapa kunskapsdiagram baserat på entiteter som identifierats i dokument för att förbättra dokumentsökningen.
• Förbättra eller automatisera affärsprocesser – När du till exempel granskar försäkringsanspråk kan identifierade entiteter som namn och plats markeras för att underlätta granskningen. Eller så kan ett supportärende genereras med kundens namn och företag automatiskt från ett e-postmeddelande.

Kunder kanske vill identifiera olika kategorier av PII-entiteter specifikt av flera skäl:

• Använd känslighetsetiketter – Baserat på resultatet från PII-tjänsten kan till exempel en offentlig känslighetsetikett tillämpas på dokument där inga PII-entiteter identifieras. För dokument där amerikanska adresser och telefonnummer identifieras kan en konfidentiell etikett tillämpas. En högst konfidentiell märkning bör användas för dokument där bankgiro-nummer identifieras.
• Redigera vissa kategorier av personlig information från dokument för att skydda sekretessen – Om kundkontaktposter till exempel är tillgängliga för supportrepresentanter på första raden kanske företaget vill redigera onödig kundinformation från kundens historik för att bevara kundens integritet.
• Ta bort personlig information för att minska omedveten bias – Till exempel kan de under företagets återupptagningsprocess blockera namn, adress och telefonnummer för att minska omedveten köns- eller andra bias.
• Ersätt personlig information i källdata för maskininlärning för att minska orättvisorna – Om du till exempel vill ta bort namn som kan avslöja kön när du tränar en maskininlärningsmodell kan du använda tjänsten för att identifiera dem och du kan ersätta dem med allmänna platshållare för modellträning.

Att tänka på när du väljer ett användningsfall

Använd inte

• ENDAST PII – Använd inte för automatiska redigerings- eller informationsklassificeringsscenarier – Alla scenarier där fel med att redigera personlig information kan utsätta människor för risken för identitetsstöld och fysiska eller psykiska skador bör omfatta noggrann mänsklig tillsyn.
• NER och PII – Använd inte för scenarier som använder personlig information för ett syfte som det inte har getts samtycke till – Till exempel har ett företag CV:n från tidigare jobbsökande. De sökande gav inte sitt samtycke till att bli kontaktade för kampanjevenemang när de lämnade in sina meritförteckningar. På grundval av detta scenario bör både NER- och PII-tjänster inte användas för att identifiera kontaktinformation i syfte att bjuda in tidigare sökande till en mässa.
• NER och PII – Kunder är förbjudna att använda den här tjänsten för att samla in personlig information från offentligt tillgängligt innehåll utan medgivande från personer som omfattas av den personliga informationen.
• NER och PII – Använd inte för scenarier som ersätter personlig information i text med avsikten att vilseleda personer.

Juridiska och regelmässiga överväganden: Organisationer måste utvärdera potentiella specifika juridiska och regelmässiga skyldigheter när de använder AI-tjänster och lösningar, vilket kanske inte är lämpligt för användning i alla branscher eller scenarion. Dessutom är AI-tjänster eller lösningar inte utformade för och får inte användas på sätt som är förbjudna i tillämpliga användningsvillkor och relevanta uppförandekoder.

Egenskaper och begränsningar

Beroende på ditt scenario, indata och de entiteter som du vill extrahera kan du uppleva olika prestandanivåer. Följande avsnitt är utformade för att hjälpa dig att förstå viktiga begrepp om prestanda när de gäller för användning av Azure AI Language NER- och PII-tjänsterna.

Förstå och mäta prestanda för NER

Eftersom både falska positiva och falska negativa fel kan inträffa är det viktigt att förstå hur båda typerna av fel kan påverka ditt övergripande system. Med Namngiven entitetsigenkänning (NER) inträffar en falsk positiv identifiering när en entitet inte finns i texten, men identifieras och returneras av systemet. Ett falskt negativt är när en entitet finns i texten, men inte identifieras och returneras av systemet.

Förstå prestanda för PII

I redigeringsscenarier kan, till exempel, falska negativa leda till läckage av personlig information. För redigeringsscenarier bör du överväga en process för mänsklig granskning för att ta hänsyn till den här typen av fel. För scenarier med känslighetsetiketter kan både falska positiva och falska negativa identifieringar leda till felklassificering av dokument. Målgruppen kan i onödan begränsas för dokument som är märkta som konfidentiella, om ett felaktigt positivt resultat inträffat. PII kunde läckas där ett falskt negativt inträffade och en offentlig etikett tillämpades.

Du kan justera tröskelvärdet för konfidenspoäng som systemet använder för att finjustera systemet. Om det är viktigare att identifiera alla potentiella instanser av PII kan du använda ett lägre tröskelvärde. Det innebär att du kan få fler falska positiva identifieringar (icke-PII-data identifieras som PII-entiteter), men färre falska negativa (PII-entiteter som inte identifieras som PII). Om det är viktigare för systemet att bara identifiera sanna PII-data kan du använda ett högre tröskelvärde. Tröskelvärden kanske inte har konsekvent beteende i enskilda kategorier av PII-entiteter. Därför är det viktigt att du testar systemet med verkliga data som det kommer att bearbeta i produktion.

Systembegränsningar och metodtips för att förbättra prestanda

• Se till att du förstår alla entitetskategorier för NER och PII som kan identifieras av systemet. Beroende på ditt scenario kan dina data innehålla annan information som kan betraktas som personlig men som inte omfattas av de kategorier som tjänsten stöder för närvarande.

• Kontext är viktigt för att alla entitetskategorier ska kännas igen korrekt av systemet, eftersom det ofta är upp till människor att känna igen en entitet. Utan kontext är till exempel ett tiosiffrigt tal bara ett tal. Men med tanke på kontext som "Du kan nå mig på mitt kontorstelefonnummer 2345678901", kan både systemet och en människa känna igen det tiosiffriga numret som ett telefonnummer. Inkludera alltid kontext när du skickar text till systemet för att få bästa möjliga prestanda.

• I synnerhet personnamn kräver språklig kontext. Skicka så mycket kontext som möjligt för bättre identifiering av personnamn.

• För konversationsdata bör du överväga att skicka mer än en enda tur i konversationen för att säkerställa högre sannolikhet att den nödvändiga kontexten ingår i de faktiska entiteterna.
  I följande konversation, om du skickar en rad i taget, kommer passnumret inte att ha någon kontext associerad med det och EU Passport Number PII-kategorin kommer inte att identifieras.

  Hej, hur kan jag hjälpa dig idag?
  Jag vill förnya mitt pass
  Visst, vad är ditt nuvarande passnummer?
  Dess 123456789, tack.

  Men om du skickar hela konversationen identifieras den eftersom kontexten ingår.

• Ibland kan flera entitetskategorier identifieras för samma entitet. Om vi tar föregående exempel:

  Hej, hur kan jag hjälpa dig idag?
  Jag vill förnya mitt pass
  Visst, vad är ditt nuvarande passnummer?
  Dess 123456789, tack.
  

  Flera olika länder har samma format för passnummer, så flera olika specifika entitetskategorier kan identifieras. I vissa fall räcker det kanske inte att använda den högsta konfidenspoängen för att välja rätt entitetsklass. Om ditt scenario är beroende av att den specifika entitetskategorin identifieras kan du behöva skilja resultatet någon annanstans i systemet antingen genom en mänsklig granskning eller ytterligare valideringskod. Noggrann testning av verkliga data kan hjälpa dig att identifiera om du sannolikt kommer att se flera entitetskategorier i ditt scenario.
  

• Alla entitetskategorier stöds inte på alla språk för både NER och PII. Kontrollera artikeln om entitetstypen för entiteterna på det språk som du vill identifiera.

• Många internationella PII-entiteter stöds. Som standard är de entitetskategorier som returneras de som matchar språkkoden som skickas med API-anropet. Om du förväntar dig entiteter från andra nationella inställningar än den som angetts måste du ange dem med parametern piiCategories . Läs mer om hur du anger vad ditt svar ska innehålla i API-referensen. Läs mer om de kategorier som stöds för varje språk i dokumentationen för namngivna entitetstyper.

• Om du använder den version av API:et som innehåller den valfria parametern piiCategoriesi PII-redigeringsscenarier är det viktigt att du överväger alla PII-kategorier som kan finnas i texten. Om du bara redigerar specifika entitetskategorier eller standardentitetskategorierna för ett visst språk, kommer andra PII-entitetskategorier som oväntat visas i texten att läckas. Till exempel, om du har skickat EN-US som lokal inställning och inte har angett några valfria PII-kategorier och ett tyskt körkortsnummer finns i texten, kommer det att läcka. För att förhindra detta måste du ange kategorin Tyskt körkortsnummer i parametern piiCategories . Om du har angett en eller flera kategorier med parametern piiCategories för det angivna nationella språket bör du dessutom vara medveten om att det är de enda kategorier som skulle redigeras. Om du till exempel har skickat EN-US lokalinställning och har angett amerikanskt Social Security Number (SSN) som PII-kategori för maskering, skulle alla andra EN-US kategorier som amerikanskt körkortsnummer eller amerikanskt passnummer läcka om de visas i indatatexten.

• Eftersom PII-tjänsten returnerar PII-kategorier som matchar språkkoden i anropet, bör du kontrollera språket för indatatetexten om du inte är säker på vilket språk eller lokalisering det kommer att vara. Du kan använda funktionen Språkidentifiering för att göra detta.

• PII-tjänsten tar endast text som indata. Om du redigerar information från dokument i andra format bör du noggrant testa redigeringskoden för att säkerställa att identifierade entiteter inte läcker ut av misstag.

Se även

• Transparensanteckning för Azure AI Language
• Transparensanteckning för hälsofunktionen
• Transparensanteckning för extrahering av nyckelfraser
• Transparensanteckning för språkidentifiering
• Transparensanteckning för svar på frågor
• Transparensanteckning för sammanfattning
• Transparensanteckning för attitydanalys
• Datasekretess och säkerhet för Azure AI Language
• Vägledning för integrering och ansvarsfull användning med Azure AI Language