Utmaningen med flerspråkig NER
Modeller för Named Entity Recognition (NER) som tränats på engelska uppnår imponerande resultat—85-92% F1-poäng på standardbenchmarkar. Tillämpa dessa modeller på arabiska eller kinesiska? Noggrannheten sjunker ofta till 50-70%.
För PII-detektering är detta gap kritiskt. En detektionsgrad på 70% innebär att 30% av känslig data förblir o skyddad.
Varför engelska modeller misslyckas
1. Ordboundaries
Engelska: Ord separeras av mellanslag.
"John Smith lives in New York"
→ ["John", "Smith", "lives", "in", "New", "York"]
Kinesiska: Inga ordboundaries alls.
"张伟住在北京"
→ Behöver segmentering först: ["张伟", "住在", "北京"]
Arabiska: Ord kopplas samman, och korta vokaler skrivs inte.
"محمد يعيش في دبي"
→ Sammanhängande skrift, höger-till-vänster, vokaler utelämnas
Engelska tokeniseringsregler gäller helt enkelt inte.
2. Morfologisk komplexitet
Engelsk morfologi: Relativt enkel
run → runs, running, ran
Arabisk morfologi: Extremt komplex (rot-mönster system)
كتب (k-t-b, "skriva" rot)
→ كاتب (författare), كتاب (bok), مكتبة (bibliotek), يكتب (han skriver)
En enda arabisk rot genererar dussintals relaterade ord. NER-modeller måste förstå detta derivationssystem.
3. Namnkonventioner
Engelska namn: Första Efternamn
John Smith, Mary Johnson
Arabiska namn: Flera komponenter
محمد بن عبد الله بن عبد المطلب
(Muhammad son-of Abdullah son-of Abdul-Muttalib)
Kinesiska namn: Familjenamn först, ofta 2-3 tecken totalt
张伟 (Zhang Wei) - 2 tecken
欧阳修 (Ouyang Xiu) - 3 tecken
4. Skriptriktning
Engelska: Vänster-till-höger (LTR) Arabiska/Hebreiska: Höger-till-vänster (RTL) Blandad text: Bidirektionell (BiDi) - extremt komplex
När ett engelskt namn dyker upp i arabisk text:
التقيت بـ John Smith في المؤتمر
(Jag träffade John Smith på konferensen)
Renderingsordningen, logiska ordningen och visningsordningen skiljer sig alla åt.
Noggrannhet efter språk
Verklig NER-prestanda varierar dramatiskt:
| Språk | Skript | F1-poängsintervall | Utmaningsnivå |
|---|---|---|---|
| Engelska | Latin | 85-92% | Låg |
| Tyska | Latin | 82-88% | Låg |
| Franska | Latin | 80-87% | Låg |
| Spanska | Latin | 81-86% | Låg |
| Ryska | Kyrilliska | 75-83% | Medium |
| Arabiska | Arabiska | 55-75% | Hög |
| Kinesiska | Hanzi | 60-78% | Hög |
| Japanska | Blandad | 65-80% | Hög |
| Thailändska | Thailändska | 50-70% | Mycket Hög |
| Hindi | Devanagari | 60-75% | Hög |
Språk med komplex morfologi, icke-latinska skript, eller inga ordboundaries presterar konsekvent sämre.
anonym.legals tre nivåer av tillvägagångssätt
Vi löser flerspråkig NER genom tre specialiserade nivåer:
Nivå 1: spaCy (25 språk)
För högresursspråk med bra modeller:
- Engelska, Tyska, Franska, Spanska, Italienska, Portugisiska
- Holländska, Polska, Ryska, Grekiska
- Och 15 till med pålitlig noggrannhet
Nivå 2: Stanza (7 språk)
För språk med komplex morfologi:
- Arabiska (rot-mönster morfologi)
- Kinesiska (ordsegmentering krävs)
- Japanska (flera skript)
- Koreanska (agglutinerande)
- Och 3 till
Nivå 3: XLM-RoBERTa (16 språk)
För lågresursspråk utan dedikerade modeller:
- Thailändska, Vietnamesiska, Indonesiska
- Hindi, Bengali, Tamil
- Hebreiska, Turkiska, Farsi
- Och mer
Hur det fungerar
Inmatningstext med språkdetection
↓
[Språkrouter]
↓
┌───────┴───────┐
↓ ↓
Högresurs Komplex/Lågresurs
(spaCy) (Stanza/XLM-RoBERTa)
↓ ↓
└───────┬───────┘
↓
[Regex-overlay för strukturerad data]
↓
[Confidence merger]
↓
Slutliga enheter
Regex-overlay
Vissa mönster är språkoberoende:
- E-postadresser:
[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,} - Kreditkort:
\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4} - Telefonnummer: Olika mönster per land
Vi tillämpar regex först för strukturerad data, oavsett språk.
RTL-skripthantering
Höger-till-vänster-språk kräver särskild hantering:
Bidirektionell textalgoritm
När arabiska innehåller engelska:
Visuell: المؤتمر في John Smith بـ التقيت
Logisk: التقيت بـ John Smith في المؤتمر
Vår bearbetning:
- Normalisera till logisk ordning
- Kör NER på logisk ordning
- Mappa enhetspositioner tillbaka till visuell ordning
- Återvända konsekventa positioner för vilken rendering som helst
Enhetsgränsdetektering
Arabiska enhetsgränser är komplexa:
"محمد" - bara namnet
"لمحمد" - "till Muhammad" (bifogad preposition)
"ومحمد" - "och Muhammad" (bifogad konjunktion)
Vi tar bort affix före NER och fäster dem igen efteråt.
Kodväxling
Verklig text blandar ofta språk:
"El meeting con John es at 3pm"
(spanska-engelska blandning)
"我今天跟John去shopping"
(kinesiska-engelska blandning)
Vårt tillvägagångssätt:
- Segmentera texten efter språk
- Bearbeta varje segment med lämplig modell
- Sammanfoga resultaten med positionsmappning
Prestandamått
Intern testning på blandade språkdatamängder:
| Scenario | F1-poäng |
|---|---|
| Endast engelska | 91% |
| Endast tyska | 88% |
| Endast arabiska | 79% |
| Endast kinesiska | 81% |
| Blandning av engelska och arabiska | 83% |
| Blandning av engelska och kinesiska | 84% |
| Blandning av engelska och tyska | 89% |
Vårt hybrida tillvägagångssätt bibehåller hög noggrannhet även på utmanande språk.
Implementeringstips
För API-användare
Specificera språk när det är känt:
{
"text": "محمد بن عبد الله",
"language": "ar"
}
Låt oss auto-detektera när det är okänt:
{
"text": "محمد بن عبد الله",
"language": "auto"
}
För användare av skrivbordsapp
Appen auto-detekterar språk per dokument. För blandade språkfiler bearbetar den varje segment på lämpligt sätt.
För anpassade enhetstyper
Anpassade mönster bör ta hänsyn till skript:
# Engelsk anställd ID
EMP-[0-9]{6}
# Arabisk anställd ID (inkluderar arabiska siffror)
موظف-[٠-٩0-9]{6}
Slutsats
Engelsktränade NER-modeller misslyckas med icke-engelsk text eftersom språk skiljer sig fundamentalt i:
- Ordboundaries (eller bristen på sådana)
- Morfologisk komplexitet
- Skriptriktning
- Namnkonventioner
Effektiv flerspråkig PII-detektering kräver:
- Språk-specifika modeller för komplexa skript
- Regex-mönster för strukturerad data
- Rätt RTL/BiDi-hantering
- Stöd för kodväxling
anonym.legal stödjer 48 språk genom vårt tre-nivå tillvägagångssätt, vilket uppnår konsekvent noggrannhet överallt.
Prova själv:
Källor: