deDeutsch
Verfügbar95,5% Strict-Span-F1
Dokumentation
Sprachen und Datenkategorien
Erfahren Sie, was ShinrAI 1.5 erkennt, wie die Abdeckung gemessen wird und welche API Sie nutzen können.
15 Modell-Sprachvarianten
Ein mehrsprachiges Modell mit regionalen Portugiesisch-Varianten und Hebräisch-Beta. Website-Sprachen und API-Sprachcodes sind davon getrennt.
Keine passenden Sprachen oder Kategorien.
enEnglisch
Verfügbar97,3% Strict-Span-F1
jaJapanisch
Verfügbar98,5% Strict-Span-F1
frFranzösisch
Verfügbar96,4% Strict-Span-F1
esSpanisch
Verfügbar97,6% Strict-Span-F1
itItalienisch
Verfügbar96,1% Strict-Span-F1
plPolnisch
Verfügbar93,5% Strict-Span-F1
pt-PTPortugiesisch · Portugal
Verfügbar94,6% Strict-Span-F1
pt-BRPortugiesisch · Brasilien
Verfügbar98,2% Strict-Span-F1
ruRussisch
Verfügbar96,9% Strict-Span-F1
ukUkrainisch
Verfügbar95,0% Strict-Span-F1
trTürkisch
Verfügbar93,2% Strict-Span-F1
arArabisch
Verfügbar90,1% Strict-Span-F1
koKoreanisch
Verfügbar95,2% Strict-Span-F1
heHebräisch
Beta71,2% Strict-Span-F1
Geschäfts-, medizinische und administrative Dokumente; 200 Texte je Sprachvariante. Exakte Entitätsgrenzen. Hebräisch-Beta enthalten. Innovius-Auswertung des Modells, keine allgemeine Genauigkeitsgarantie für den Dienst.
Methodik und Ergebnisse ansehen →Modell-Sprachvarianten, API-Codes und Website-Sprachen
Die Website ist auf Englisch, Deutsch, Japanisch, Französisch und Spanisch verfügbar. Das Modell ist nicht auf diese fünf Sprachen beschränkt.
Der dokumentierte Azure-Textadapter akzeptiert diese Sprachcodes:
de en fr es it pl pt ru uk tr ar he ja ko
Portugiesisch nutzt einen API-Sprachcode, hat aber zwei ausgewertete regionale Modellvarianten. Ein akzeptierter Code garantiert weder alle Entitätskategorien noch gleiche Qualität.
Adapter-Grenzen nachlesen →21 Datenkategorien
Die Beispiele dienen der Veranschaulichung. Die Erkennung hängt vom Kontext und der Konfiguration ab.
Personen und Organisationen
Personen
Emma WeberPERSONOrganisationen
Example GmbHCOMPANYKontakt und Standort
Städte
BerlinCITYStraßenadressen
Musterstraße 12STREET_ADDRESSE-Mail-Adressen
emma@example.comEMAILTelefonnummern
+49 30 000000PHONEPostleitzahlen
10115POSTAL_CODEFinanzen
Bankkonten
DE89 3704 0044 0532 0130 00BANK_ACCOUNTKrypto-Wallets
0x…CRYPTO_WALLETZahlungskarten
4242 4242 4242 4242CREDIT_CARDPersönliche Kennungen
Geburtsdaten
14.03.1985DATE_OF_BIRTHStaatliche Kennungen
Tax / identity / social-security IDNATIONAL_IDKfz-Kennzeichen
B AB 1234LICENSE_PLATEKunden- und Vorgangsnummern
CUSTOMER-0042CUSTOMER_IDDatums- und Altersangaben
Datumsangaben
12 March 2026DATEAltersangaben
42 yearsAGEDigitale und vertrauliche Informationen
Benutzernamen
example\emmaUSERNAMEWebadressen
https://example.comURLNetzwerkadressen
192.0.2.1IP_ADDRESSGeheimnisse und Zugriffstoken
API_KEY_EXAMPLESECRETProjektcodenamen
Project AuroraPROJECT_CODENAMEWarum 21 Kategorien und 29 Klassen?
Das Modell hat 21 Erkennungsköpfe. Personen, Städte, Straßen und Organisationen haben je drei Untertypen; die anderen 17 Kategorien jeweils einen. Das ergibt 29 Klassen, nicht 29 unabhängige Datenkategorien.
PERSONcommon, uncommon, rareCITYmajor, medium, smallSTREET_ADDRESSgeneric, specific, localCOMPANYinternational, national, regional
Herkunft, Namensform und weitere Attribute helfen bei passenden Ersetzungen. Es sind Zusatzattribute, keine zusätzlichen Sprachen oder garantierten Erkennungen.
Enterprise-Detektoren und API-Abdeckung
Enterprise ergänzt deterministische Regeln und Validierung für unterstützte Kennungen. Diese sind in den obigen reinen Modellergebnissen nicht enthalten.
Beispiele in den Adaptern sind US-Sozialversicherungsnummern, Bankleitzahlen, SWIFT-Codes und Fahrzeugidentifikationsnummern. Umfang und erforderlicher Kontext unterscheiden sich je nach API.
Kompatibilitätsadapter stellen ihre dokumentierten Kategorien und Vorgänge bereit. Nicht unterstützte Optionen werden abgelehnt; nicht zugeordnete Treffer können Warnungen erzeugen. Nutzen Sie die native API für Treffer außerhalb einer Adapterzuordnung.
Native API und Kompatibilitätsdokumentation →