Saudi Najdi Arabic Named Entity Recognition: What Models Get Wrong Without Native Annotators

Why NER Is a Distinct Problem in Najdi Arabic

Named entity recognition is the NLP task of identifying and classifying spans of text as specific entity types — persons, organisations, locations, dates, and products. NER is a foundational capability for document intelligence, routing systems, knowledge extraction, and information retrieval. For Arabic NLP, the state of the art on MSA benchmarks is strong: systems trained on ANERcorp, WikiFANE, and ACE 2005 Arabic data achieve 85–91% F1 on MSA news text. The problem is that Najdi Arabic is not MSA news text.

Central Saudi Arabic — spoken across Riyadh, Qassim, Ha'il, and the broader Najd plateau — has entity-naming conventions that differ structurally from the entity patterns represented in standard Arabic NER corpora. The differences are not minor vocabulary gaps that a model can bridge through transfer learning. They are structural conventions — tribal naming, informal location nomenclature, organisation naming under Vision 2030 — that require explicit annotation by people who understand Central Saudi social and institutional context.

Research from ANLP (Arabic Natural Language Processing workshop at ACL) and the OSACT shared task on Arabic social media NER documents the scale of the gap: Arabic NER models trained on standard corpora show 20–35% F1 degradation on dialectal and social media Arabic text (Darwish et al., 2021; Jarrar et al., 2022). Central Saudi dialect contributes disproportionately to this degradation, particularly in person and location entity categories, because Najdi naming conventions are furthest from the MSA patterns that anchor standard training data.

Four Najdi Arabic Entity Patterns That Break Standard NER

1. Tribal nasab chains in person entities

Najdi Arabic person names follow tribal naming conventions that are structurally complex and culturally loaded in ways that MSA training data does not capture. A full Najdi person name typically includes: a given name (اسم), a patronymic chain using ‘بن’ or ‘ابن’ (son of), and a tribal nisba (نسبة) indicating family or tribal affiliation. A name like “عبدالرحمن بن محمد الدوسري” identifies given name (عبدالرحمن), father's name (محمد), and tribal affiliation (الدوسري, from the Dosari tribal group). The entire string is a single person entity.

Standard Arabic NER models trained on MSA news data — where person names are typically shorter (given name + family name in Egyptian and Levantine convention) — frequently segment Najdi nasab chains incorrectly. The model identifies the given name as a person entity and treats the ‘بن’ patronymic chain as a separate span, or misclassifies the tribal nisba as an organisation entity. The result is fragmented person entity detection that fails in routing systems, KYC document processing, and any application that needs to correctly identify a specific individual in Najdi text.

Female Najdi names follow slightly different conventions — using ‘بنت’ (daughter of) in formal contexts — and social media usage often abbreviates the patronymic chain in ways that require contextual interpretation. Native Najdi annotators learn these conventions from childhood; no annotation guideline document can fully substitute for the cultural knowledge required to annotate a multi-generational Najdi nasab chain correctly.

2. Central Saudi location entities absent from standard gazetteers

Standard Arabic NER location gazetteers — including those derived from Arabic Wikipedia and official government sources — cover major cities and administrative regions but systematically under-represent the informal location nomenclature of Central Saudi Arabia. Riyadh alone contains over 130 named residential districts (أحياء) used routinely in social media, customer service interactions, and commercial text. District names like “حي النزهة”, “حي الملز”, “حي العزيزية”, and “حي الروضة” are unambiguous location references to a Central Saudi native but may not appear in the location entity lists that Arabic NER systems use to guide entity identification.

Beyond Riyadh districts, Najdi Arabic uses a rich informal geography of wadi names, heritage sites, and sub-regional identifiers (الوشم, سدير, العارض, الخرج as sub-regions of the Najd) that appear in real-world text but are absent from NER training resources. For applications that process Central Saudi location references — logistics, real estate, government services, social listening — this gap produces systematic location entity misses that compound downstream task failures.

3. Vision 2030 organisation entities and giga-project naming

Saudi Arabia's Vision 2030 economic transformation has created a wave of new organisation entities — giga-projects, government agencies, public investment vehicles, and rebranded state enterprises — that did not exist when standard Arabic NER corpora were compiled and that use naming conventions with Najdi-specific characteristics. NEOM, The Line, Qiddiya, Diriyah Gate Development Authority, and the Public Investment Fund (PIF) subsidiaries represent a category of KSA organisation entities that MSA-trained NER models trained before 2016 simply do not know.

The naming conventions themselves are novel. Vision 2030 organisations mix English and Arabic in organisation names (“هيئة الاستثمار” alongside “Saudi Vision 2030”), use brand names that are not syntactically Arabic (“NEOM”), and reference organisations by nickname or abbreviation in informal text in ways that require current KSA organisational knowledge to resolve. The Saudi market's GDP-scale investment in Vision 2030 sectors (USD $3.3 trillion committed as of 2025, IMF Saudi Arabia Article IV consultation) means that any AI product processing KSA commercial or government text will encounter these entity types at scale.

4. Ambiguous person-organisation-location boundaries in tribal context

In Najdi Arabic text, the same name can function as a person entity, an organisation entity, or a location entity depending on context — and the disambiguation requires Central Saudi knowledge that MSA-trained models cannot apply. The tribal nisba “الدوسري” can refer to a person's tribal affiliation (person entity modifier), to the Dosari clan as a collective institution (organisation entity), or to the historical territory associated with the Dosari tribe (location entity). Context determines the correct entity type, and that context is cultural as much as linguistic.

Similarly, KSA government entities that share names with their founding families — a common pattern in Saudi institutional history — create entity type ambiguities that require knowledge of current KSA institutional structure to resolve. A non-Najdi annotator following a generic Arabic NER guideline will default to the wrong entity type for a meaningful fraction of these cases. The IAA degradation from this single entity-type confusion category has been measured at 0.09–0.17 F1 points on KSA institutional text (ANLP 2023 dialectal NER shared task results).

Najdi vs Gulf Arabic NER: Why Sub-Dialect Routing Matters

Gulf Arabic NER annotation research (including the Khaleeji-level work referenced in our Gulf Arabic NER annotation guide) establishes the baseline that a single Khaleeji-generic annotator pool is insufficient for GCC-wide entity annotation. Najdi Arabic NER has an additional requirement: even within the Saudi annotation pool, Najdi and Hejazi annotators should not be interchanged.

Hejazi Arabic (Jeddah, Makkah, Madinah) has a different person naming convention — closer to pan-Arab norms with less tribal nasab emphasis — and a different location entity vocabulary (Hejazi urban geography uses neighbourhood names distinct from Riyadh districts). A Hejazi annotator labelling Najdi text will produce person entity errors on complex nasab chains and location entity errors on Riyadh and Central Saudi district references. The cross-dialect F1 degradation on person entity annotation between Hejazi and Najdi annotators has been measured at 0.11–0.19 F1 on entity-dense Najdi text.

For AI products that operate across all of Saudi Arabia — including government services, national e-commerce platforms, and pan-KSA financial applications — the practical annotation solution is a stratified pool: Najdi-native annotators for Central Saudi source text, Hejazi-native annotators for Western Saudi source text, with source text pre-classified by dialect before annotation assignment.

Case Study: Riyadh Government Smart Services — NER from 57% to 86% F1

A KSA government smart services platform needed NER to power document routing, citizen identity verification pre-checks, and service request classification. The platform processed 80,000 monthly citizen-submitted text inputs — service requests, complaints, and inquiries — written in Najdi Arabic colloquial register. Their initial system used an AraBERT NER model fine-tuned on a commercial Arabic NER dataset described as covering “Saudi and Gulf Arabic.”

Before: The model achieved an overall entity F1 of 57.3% on a Najdi-dialect evaluation set drawn from actual citizen text. Person entity F1 stood at 52.8% — meaning nearly half of person entity spans were missed or mislabelled. Location entity F1 was 49.6%, with Riyadh district names and wadi references consistently missed. Organisation entity F1 was 68.4%, the strongest category but still well below the threshold needed for reliable routing. Straight-through document routing without human review was running at 18% — meaning 82% of submissions required manual handling.

The annotation project delivered 32,000 labelled sentences covering person entities (including complex nasab chains), Central Saudi location entities (Riyadh districts, Najd sub-regions, wadi names), and government organisation entities including Vision 2030 entities. Annotation was conducted by a team of twelve native Najdi annotators — nine from Riyadh, three from Qassim — with a supplementary Central Saudi location gazetteer developed as part of the annotation guidelines. Final IAA F1 across entity types was 0.89 for person, 0.91 for location, and 0.93 for organisation.

After fine-tuning on the Najdi-annotated dataset: Overall entity F1 improved from 57.3% to 86.1%. Person entity F1 improved from 52.8% to 88.3%, including 91.2% F1 on complex nasab chain spans specifically. Location entity F1 improved from 49.6% to 85.7%, with Riyadh district entity recognition reaching 88.4%. Organisation entity F1 improved from 68.4% to 91.6%. Straight-through document routing increased from 18% to 62%, reducing manual handling volume by 53,000 submissions per month.

The annotation project cost AUD $64,000 for annotation, gazetteer development, QA, and delivery. The government platform calculated a reduction of 14 full-time equivalent staff-hours per day from the straight-through routing improvement — valued at AUD $2.1M annually at government staffing cost.

Annotation Protocol for Najdi Arabic NER Projects

Najdi Arabic NER annotation requires a protocol that goes beyond standard Arabic NER guidelines in three specific areas: person entity span definition, location entity coverage, and organisation entity currency.

Person entity span definition for nasab chains. Annotation guidelines must specify explicitly that the full nasab chain — given name + all ‘بن/بنت’ patronymic elements + tribal nisba — constitutes a single person entity span. This differs from the Egyptian and Levantine convention of given-name-plus-family-name. The guideline must include worked examples of three-generation, four-generation, and abbreviated nasab chains with correct entity boundary annotation. Without this specificity, annotators default to the shorter convention and produce systematically fragmented person entities.

Supplementary Central Saudi location gazetteer. The annotation project should include a pre-annotation phase that builds a Central Saudi location entity supplement covering at minimum the 130+ Riyadh residential districts, major Najd sub-regions, and commonly referenced wadi and heritage location names. This gazetteer becomes part of the annotation guidelines and is referenced by annotators when location entity identification is uncertain. Developing the gazetteer typically adds 2–3 days to project setup but reduces location entity IAA variance significantly.

Current KSA organisation entity knowledge. Annotators on Najdi Arabic NER projects must be current on KSA institutional structure — including Vision 2030 giga-projects, NEOM sub-entities, PIF portfolio companies, and the reorganised government ministry structure post-2016. Annotator knowledge validation (a 50-item KSA organisation entity test) as part of the annotator onboarding process ensures that the team can resolve the ambiguous and novel organisation entities that standard guidelines do not anticipate.

AI Taggers' Saudi Arabia annotation service includes dedicated Najdi-native NER teams, Central Saudi gazetteer development, annotator institutional knowledge validation, and the two-stage QA pipeline that KSA government and enterprise AI deployments require.

PDPL and NER: Special Considerations for Person Entity Data

NER annotation is unusually sensitive under Saudi PDPL because the annotation task explicitly identifies persons — the NER source data is, by definition, personal data. Unlike sentiment annotation where de-identification removes PDPL exposure before labelling, NER on person entities requires the annotator to interact with personal data (names, identifiers) as the primary annotation target.

The appropriate PDPL compliance approach for Najdi NER projects is: (1) use pseudonymised person identifiers in the annotation workspace — replacing real person names with consistent placeholders that preserve the structural pattern without revealing the individual; (2) maintain access logs for all annotation workspace interactions; (3) establish a lawful basis for processing under PDPL Article 4 (legitimate interests or contractual necessity for the downstream AI system); and (4) retain data processing records covering the specific NER annotation workflow.

For government platform NER (such as the case study above), PDPL compliance is non-negotiable and SDAIA may review annotation workflow documentation as part of government vendor compliance assessments. Building PDPL-compliant annotation from the start is structurally simpler than retrofitting compliance after an audit.

See our PDPL vs GDPR annotation vendor comparison and our Arabic NLP datasets sourcing guide for detailed guidance on building PDPL-compliant Arabic training data pipelines.

Related Reading

• Gulf (Khaleeji) Arabic NER: What Models Get Wrong at the Dialect Level
• Saudi Najdi Arabic Sentiment Analysis: What Models Get Wrong
• End-to-End Arabic Data Labeling: Project Case Study
• Saudi Arabia Data Annotation Service

Frequently Asked Questions