Tillbaka till BloggenTeknisk

Flerspråkig NER: Varför din engelsktränade modell...

Engelska NER-modeller uppnår 85-92% noggrannhet. Arabiska och kinesiska? Ofta 50-70%.

February 26, 20268 min läsning
NERmultilingualArabic NLPChinese NLPPII detection

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åkSkriptF1-poängsintervallUtmaningsnivå
EngelskaLatin85-92%Låg
TyskaLatin82-88%Låg
FranskaLatin80-87%Låg
SpanskaLatin81-86%Låg
RyskaKyrilliska75-83%Medium
ArabiskaArabiska55-75%Hög
KinesiskaHanzi60-78%Hög
JapanskaBlandad65-80%Hög
ThailändskaThailändska50-70%Mycket Hög
HindiDevanagari60-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:

  1. Normalisera till logisk ordning
  2. Kör NER på logisk ordning
  3. Mappa enhetspositioner tillbaka till visuell ordning
  4. Å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:

  1. Segmentera texten efter språk
  2. Bearbeta varje segment med lämplig modell
  3. Sammanfoga resultaten med positionsmappning

Prestandamått

Intern testning på blandade språkdatamängder:

ScenarioF1-poäng
Endast engelska91%
Endast tyska88%
Endast arabiska79%
Endast kinesiska81%
Blandning av engelska och arabiska83%
Blandning av engelska och kinesiska84%
Blandning av engelska och tyska89%

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:

  1. Språk-specifika modeller för komplexa skript
  2. Regex-mönster för strukturerad data
  3. Rätt RTL/BiDi-hantering
  4. 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:

Redo att skydda din data?

Börja anonymisera PII med 285+ entitetstyper på 48 språk.