Sprachen und Datenkategorien

Erfahren Sie, was ShinrAI 1.3 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.

de

Deutsch

Verfügbar

94,4% Strict-Span-F1

en

Englisch

Verfügbar

97,7% Strict-Span-F1

ja

Japanisch

Verfügbar

98,1% Strict-Span-F1

fr

Französisch

Verfügbar

96,0% Strict-Span-F1

es

Spanisch

Verfügbar

96,9% Strict-Span-F1

it

Italienisch

Verfügbar

95,0% Strict-Span-F1

pl

Polnisch

Verfügbar

90,9% Strict-Span-F1

pt-PT

Portugiesisch · Portugal

Verfügbar

94,2% Strict-Span-F1

pt-BR

Portugiesisch · Brasilien

Verfügbar

97,3% Strict-Span-F1

ru

Russisch

Verfügbar

96,4% Strict-Span-F1

uk

Ukrainisch

Verfügbar

86,7% Strict-Span-F1

tr

Türkisch

Verfügbar

90,1% Strict-Span-F1

ar

Arabisch

Verfügbar

87,9% Strict-Span-F1

ko

Koreanisch

Verfügbar

95,5% Strict-Span-F1

he

Hebräisch

Beta

59,5% Strict-Span-F1

Geschäfts- und klinische Briefe; 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 →

19 Datenkategorien

Die Beispiele dienen der Veranschaulichung. Die Erkennung hängt vom Kontext und der Konfiguration ab.

Personen und Organisationen

Personen

Emma WeberPERSON

Organisationen

Example GmbHORG

Kontakt und Standort

Städte

BerlinCITY

Straßenadressen

Musterstraße 12STREET

E-Mail-Adressen

emma@example.comEMAIL

Telefonnummern

+49 30 000000PHONE

Postleitzahlen

10115POSTAL_CODE

Finanzen

Bankkonten

DE89 3704 0044 0532 0130 00ACCOUNT

Krypto-Wallets

0x…WALLET

Zahlungskarten

4242 4242 4242 4242CARD

Persönliche Kennungen

Geburtsdaten

14.03.1985DOB

Staatliche Kennungen

Tax / identity / social-security IDNATIONAL_ID

Kfz-Kennzeichen

B AB 1234PLATE

Kunden- und Vorgangsnummern

CUSTOMER-0042CUSTOMER_ID

Digitale und vertrauliche Informationen

Benutzernamen

example\emmaUSERNAME

Webadressen

https://example.comURL

Netzwerkadressen

192.0.2.1NETADDR

Geheimnisse und Zugriffstoken

API_KEY_EXAMPLESECRET

Projektcodenamen

Project AuroraCODENAME

Warum 19 Kategorien und 27 Klassen?

Das Modell hat 19 Erkennungsköpfe. Personen, Städte, Straßen und Organisationen haben je drei Untertypen; die anderen 15 Kategorien jeweils einen. Das ergibt 27 Klassen, nicht 27 unabhängige Datenkategorien.

PERSON: common, uncommon, rare
CITY: major, medium, small
STREET: generic, specific, local
ORG: international, 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 →