By · Last updated 2026-02-26

Tillbaka till BloggenTeknisk

Flerspråkig NER: engelska modeller misslyckas med arabiska

Engelska NER-modeller når 85–92% noggrannhet. Arabiska och kinesiska? Ofta 50–70%. Lär dig om de tekniska utmaningarna och hur du bygger verkligt.

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

Flerspråkig NER: Utmaningar vid PII-detektering

Uppdaterad för 2026

Noggrannhetsgapet

NER-modeller tränade på engelska når 85–92% F1 på standardtester. Applicera samma modeller på arabisk eller kinesisk text. Noggrannheten sjunker till 50–70%.

För PII-arbete är det gapet ett problem. En träffrate på 70% innebär att 30% av känslig data förblir oupptäckt.

Orsakerna är inte buggar. De kommer från hur skriftsystem skiljer sig åt.

Fyra grundorsaker

1. Ordgränser

Engelska delar ord med mellanslag. Tokenisering är enkel.

Kinesiska har inga mellanslag alls.

``` "张伟住在北京" → Dela först: ["张伟", "住在", "北京"] ```

En modell kan inte märka vad den inte kan hitta. Uppdelning måste komma före NER.

Arabiska binder ihop bokstäver inom ett ord. Korta vokaler utelämnas. Text löper från höger till vänster.

``` "محمد يعيش في دبي" → Inga korta vokaler, höger till vänster, bundna bokstäver ```

2. Morfologi

Engelska verb förändras på några få sätt. Arabiska använder ett rotsystem. En rot skapar dussintals ord.

``` كتب (k-t-b, "skriva") → كاتب (författare), كتاب (bok), مكتبة (bibliotek) ```

NER måste tolka rötter för att hitta namn i härledda ordformer.

3. Namnkonventioner

Latinska namn placerar förnamnet före efternamnet. Namn i RTL-språk kedjar familjeband.

``` محمد بن عبد الله (Muhammad son till Abdullah) ```

Kinesiska namn sätter familjenamnet först. De flesta namn är två eller tre tecken långa.

``` 张伟 (Zhang Wei) — 2 tecken 欧阳修 (Ouyang Xiu) — 3 tecken ```

En modell byggd på västerländska namnmönster missar dessa strukturer.

4. Textriktning

En del språk löper från höger till vänster. När RTL-text innehåller ett engelskt namn splittras visuell ordning och logisk ordning. Detta kallas BiDi-text. Det kräver noggrann tolkning.

F1-poäng per skriftsystem

SpråkSkriftsystemF1-intervallNivå
EngelskaLatinskt85–92%Låg
TyskaLatinskt82–88%Låg
FranskaLatinskt80–87%Låg
SpanskaLatinskt81–86%Låg
RyskaKyrilliskt75–83%Medel
ArabiskaAbjad55–75%Hög
KinesiskaHanzi60–78%Hög
JapanskaBlandat65–80%Hög
ThailändskaThailändskt50–70%Mycket hög
HindiDevanagari60–75%Hög

Icke-latinska system och saknade ordmellanslag sänker poängen generellt.

Trelagers lösning

Vi använder tre lager för att täcka 48 språk och skriftsystem.

Lager 1: spaCy — 25 språk

För språk med starka, testade modeller. Det täcker engelska, tyska, franska, spanska, italienska, portugisiska, holländska, polska, ryska och grekiska.

Lager 2: Stanza — Komplexa språk

Stanford Stanza hanterar arabiska, kinesiska, japanska och koreanska. Det utför orduppdelning och rotanalys före NER.

Lager 3: XLM-RoBERTa — Lågresursspråk

För språk utan dedikerade modeller. Thailändska, vietnamesiska, hindi, bengali, hebreiska, turkiska och persiska placeras här. Det hanterar blandspråkig text utan explicita flaggor.

RTL och BiDi

Höger-till-vänster-text kräver extra steg utöver uppdelning.

Vår pipeline:

  1. Normaliserar text till logisk ordning.
  2. Kör NER på den ordningen.
  3. Mappar entiteternas positioner tillbaka till visuell ordning.

Vi tar bort bundna prefix före NER och lägger till dem igen efteråt.

``` "محمد" — namn enbart "لمحمد" — "till Muhammad" (prefix på) ```

Kodväxling

Verkliga dokument blandar ofta språk på en enda rad.

``` "El meeting con John es at 3pm" "我今天跟John去shopping" ```

Vår pipeline delar upp efter språk. Den kör rätt modell på varje del. Sedan sammanfogar den resultat med positionsmappning.

Interna benchmarks

Resultat från interna tester på flerspråkig data:

ScenarioF1
Endast engelska91%
Endast tyska88%
Endast arabiska79%
Endast kinesiska81%
Engelska-arabiska mix83%
Engelska-kinesiska mix84%
Engelska-tyska mix89%

Installationsanmärkningar

Skrivbordsappen identifierar automatiskt språk per dokument. För filer med blandade språk bearbetar den varje segment med rätt modell. Inget manuellt steg krävs.

Ange språket i API:t när du vet det:

```json { "text": "محمد بن عبد الله", "language": "ar" } ```

Använd auto-detektering när du inte vet:

```json { "text": "محمد بن عبد الله", "language": "auto" } ```

Anpassade mönster bör täcka lokala siffror:

```

Latinskt medarbetar-ID

EMP-[0-9]{6}

Arabiskt medarbetar-ID (inkluderar arabisk-indiska siffror)

موظف-[٠-٩0-9]{6} ```

Se den fullständiga entitetslistan. För API-installation, besök API-funktionssidan. Vår GDPR-efterlevnadsguide täcker hur detekteringsluckor påverkar dataskyddslagstiftningen.


anonym.legal använder en trelagers NER-stack — spaCy, Stanza och XLM-RoBERTa — för att täcka 48 språk med konsekvent PII-detektering.

Källor

Redo att skydda din data?

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

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.