Parsing Nigerian Pidgin and Code-Switching in WhatsApp AI Agents: Building a Low-Latency ONNX Intent Classifier

A Lagos-based last-mile delivery startup came to us with a recurring problem. Their WhatsApp customer support bot, hooked directly up to an OpenAI API pipeline, was bleeding money and dropping customer conversations. The monthly API bill had crossed $580 for barely 30,000 active conversations, and response latencies routinely spiked past 5 seconds over MTN and Airtel 4G networks.

When we audited the raw log traces, the underlying defect became immediately obvious. The team was forwarding raw customer text straight to GPT-4o-mini with a 1,200-token system prompt packed with instruction rules on how to parse Nigerian Pidgin and Yoruba code-switching. Every simple message—whether it was "Abeg where my order dey?", "I wan change my delivery address to Lekki Phase 1", or "Wallet balance check e jo"—triggered a full LLM completion cycle.

Out of those 30,000 monthly interactions, 68% were deterministic tasks: checking order status, checking account balances, or requesting address updates. Throwing general-intelligence models at deterministic SQL queries wrapped in localized slang is architectural waste. Worse, cloud LLMs routinely stumble over structural Pidgin variations like "never" vs "neva" or localized context markers like "abi" and "sha", mistaking them for typos and returning overly formal, hallucinated responses.

We solved this by pulling LLMs out of the hot path for transactional intents. By deploying a small, domain-tuned embedding transformer quantized with ONNX Runtime, we built a 14ms local intent router that runs on a standard CPU droplet. Here is how we engineered it, tuned it for Nigerian multi-lingual patterns, and integrated it with the Meta WhatsApp Cloud API.

The Fallacy of Zero-Shot Pidgin Parsing via Cloud LLMs

Most teams building conversational tools in West Africa start with a simple setup: a Meta WhatsApp Cloud API webhook receiver, a LangChain or LlamaIndex wrapper, and an OpenAI or Anthropic API call. It works in early testing when you type perfect English into a staging dashboard. It falls apart in production when real customers type real conversation streams.

Nigerian Pidgin (West African Pidgin English) is not broken English; it has its own grammar, tense markers, and syntax. Consider these three user inputs:

1. "My money never drop." (Past negative: The bank transfer has not yet reflected).
2. "No drop the package for gate." (Imperative negative: Do not leave the parcel at the gate).
3. "I dey drop now." (Present continuous: I am arriving/disembarking right now).

When off-the-shelf models process these without fine-tuning, they frequently confuse the grammatical particle "drop" across financial transactions, physical delivery drops, and passenger transit. To force an off-the-shelf model to reliably distinguish these, engineering teams pad their system prompts with massive contextual dictionaries.

This approach breaks under three operational realities:

• Token Costs: Padding every request with 1,000+ system prompt tokens means paying for context tokens repeatedly across short 5-word user messages.
• Network Latency: Round-trips to North American or European cloud API endpoints add 300ms to 800ms of base network overhead before model generation even begins. As we previously analyzed in our piece on Coolify on Hetzner vs. Render vs. AWS ECS Fargate: Production Deployments Under West African Cloud Budget Constraints, cloud operational costs must be aggressively optimized for African operations.
• Determinism: An LLM can hallucinate a tracking link or format an address incorrectly. SQL queries do not.

Instead of making the LLM read every message, we build a local intent classification router. If the confidence score for a deterministic intent exceeds 0.85, the request routes directly to a PostgreSQL query or an internal API. If the query is complex or unstructured, it falls through to a fine-tuned small model like our approach in Quantizing Llama-3.2-3B with vLLM and AWQ: Cutting LLM Inference Costs and Latency for Nigerian Support Agents.

Architecture: The Two-Tier Intent Router

Our intent pipeline relies on three main components sitting inside a high-throughput Python engine built on FastAPI:

1. Text Normalizer: A lightweight string preprocessor that standardizes high-frequency Pidgin variants ("neva" $\rightarrow$ "never", "abeg" $\rightarrow$ particle strip, "dey" preservation) without destroying semantic structure.
2. ONNX Quantized Transformer: A sentence-transformer (BAAI/bge-small-en-v1.5 or all-MiniLM-L6-v2) fine-tuned on localized support logs, converted to Open Neural Network Exchange (ONNX) format, and quantized to 8-bit integers (INT8).
3. Classification & Route Engine: A vector similarity matcher running against canonical reference vectors with cosine distance scoring.

[ WhatsApp Webhook ] 
         │
         ▼
[ Text Normalizer ]
         │
         ▼
[ ONNX Embedding Engine (14ms) ]
         │
   ┌─────┴────────────────────────┐
   │ Similarity >= 0.85           │ Similarity < 0.85
   ▼                              ▼
[ SQL / Internal API ]     [ LLM Fallback Service ]
   (68% of Traffic)           (32% of Traffic)

Step 1: Exporting and Quantizing the Model to ONNX

We start by taking a sentence-transformer fine-tuned on a dataset of ~2,000 localized Nigerian e-commerce query pairs. We export it to ONNX format using the Hugging Face Optimum library, then apply INT8 quantization to reduce memory usage and enable fast execution on modest CPU hardware.

Run this script during your build pipeline to prepare the model artifact:

import os
from pathlib import Path
from optimum.onnxruntime import ORTModelForFeatureExtraction
from transformers import AutoTokenizer
from optimum.onnxruntime.configuration import AutoQuantizationConfig
from optimum.onnxruntime import ORTQuantizer

MODEL_ID = "sentence-transformers/all-MiniLM-L6-v2"
EXPORT_DIR = Path("./model_onnx")
QUANT_DIR = Path("./model_onnx_quantized")

print("--> Exporting PyTorch model to ONNX format...")
model = ORTModelForFeatureExtraction.from_pretrained(MODEL_ID, export=True)
tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)

model.save_pretrained(EXPORT_DIR)
tokenizer.save_pretrained(EXPORT_DIR)

print("--> Applying INT8 Dynamic Quantization...")
quantizer = ORTQuantizer.from_pretrained(EXPORT_DIR)
qconfig = AutoQuantizationConfig.arm64(is_static=False, per_channel=False)

quantizer.quantize(
    save_dir=QUANT_DIR,
    quantization_config=qconfig,
)
print(f"--> Quantized model successfully saved to {QUANT_DIR}")

This step drops model file size from ~90MB down to ~23MB while keeping loss in embedding accuracy under 0.6%. More importantly, CPU inference latency drops from 68ms to 14ms per input sequence on standard x86 and ARM server instances.

Step 2: Nigerian Pidgin Preprocessor

Do not strip all local punctuation or markers blindly. Words like "dey" carry heavy tense information in Pidgin. However, removing polite conversational markers like "abeg", "e jo", or "pls" helps reduce vector drift for deterministic intents.

Create normalizer.py:

import re

PIDGIN_DICTIONARY = {
    r"\bneva\b": "never",
    r"\bwan\b": "want to",
    r"\bgo dey\b": "will be",
    r"\bdon\b": "has",
    r"\bwea\b": "where",
    r"\bwetin\b": "what",
}

POLITE_MARKERS = [
    r"\babeg\b",
    r"\be jo\b",
    r"\bejoo\b",
    r"\bpls\b",
    r"\bplease\b",
    r"\bsir\b",
    r"\bma\b",
]

def normalize_pidgin_text(text: str) -> str:
    cleaned = text.lower().strip()
    
    # Strip filler conversational markers that shift intent embeddings
    for pattern in POLITE_MARKERS:
        cleaned = re.sub(pattern, "", cleaned)
    
    # Standardize frequent morphological spellings
    for pattern, replacement in PIDGIN_DICTIONARY.items():
        cleaned = re.sub(pattern, replacement, cleaned)
        
    # Remove double spaces left over by replacements
    cleaned = re.sub(r"\s+", " ", cleaned).strip()
    return cleaned

Step 3: Fast Intent Inference Engine

Now we construct the high-speed classification engine using ONNX Runtime Python APIs. We pre-compute canonical embeddings for our reference target intents on engine startup, then calculate cosine similarity vectors for incoming payloads.

import numpy as np
from typing import Dict, Tuple, List
import onnxruntime as ort
from transformers import AutoTokenizer
from normalizer import normalize_pidgin_text

class LocalIntentRouter:
    def __init__(self, model_dir: str):
        self.tokenizer = AutoTokenizer.from_pretrained(model_dir)
        self.session = ort.InferenceSession(
            f"{model_dir}/model_quantized.onnx",
            providers=["CPUExecutionProvider"]
        )
        
        # Pre-defined intent canonical seed examples
        self.intent_targets: Dict[str, List[str]] = {
            "CHECK_ORDER_STATUS": [
                "where my package dey",
                "where is my order",
                "item never arrive",
                "track my delivery parcel",
                "delivery guy never reach"
            ],
            "CHECK_WALLET_BALANCE": [
                "wetin be my account balance",
                "how much dey my wallet",
                "show me my balance",
                "money inside my wallet"
            ],
            "UPDATE_ADDRESS": [
                "i wan change my delivery address",
                "update my location to lekki",
                "change where you go drop the package"
            ]
        }
        
        # Precompute target matrix
        self.target_vectors: Dict[str, np.ndarray] = {}
        self._precompute_targets()

    def _get_embedding(self, text: str) -> np.ndarray:
        inputs = self.tokenizer(
            text,
            padding=True,
            truncation=True,
            max_length=128,
            return_tensors="np"
        )
        
        onnx_inputs = {
            "input_ids": inputs["input_ids"].astype(np.int64),
            "attention_mask": inputs["attention_mask"].astype(np.int64)
        }
        
        # Handle token_type_ids if required by model architecture
        if "token_type_ids" in [x.name for x in self.session.get_inputs()]:
            onnx_inputs["token_type_ids"] = inputs["token_type_ids"].astype(np.int64)

        outputs = self.session.run(None, onnx_inputs)
        # Mean pooling over token embeddings with attention mask
        token_embeddings = outputs[0]
        input_mask_expanded = np.expand_dims(inputs["attention_mask"], -1)
        sum_embeddings = np.sum(token_embeddings * input_mask_expanded, axis=1)
        sum_mask = np.clip(input_mask_expanded.sum(axis=1), a_min=1e-9, a_max=None)
        embedding = sum_embeddings / sum_mask
        
        # L2 normalize
        norm = np.linalg.norm(embedding, axis=1, keepdims=True)
        return (embedding / norm).squeeze()

    def _precompute_targets(self):
        for intent, phrases in self.intent_targets.items():
            phrase_vectors = [self._get_embedding(p) for p in phrases]
            # Average canonical phrase vectors for single class centroid
            centroid = np.mean(phrase_vectors, axis=0)
            centroid = centroid / np.linalg.norm(centroid)
            self.target_vectors[intent] = centroid

    def classify(self, raw_user_message: str, threshold: float = 0.78) -> Tuple[str, float]:
        normalized_text = normalize_pidgin_text(raw_user_message)
        query_vector = self._get_embedding(normalized_text)
        
        best_intent = "UNKNOWN_FALLBACK_TO_LLM"
        max_sim = -1.0
        
        for intent, target_vector in self.target_vectors.items():
            # Cosine similarity for normalized vectors is a dot product
            sim = float(np.dot(query_vector, target_vector))
            if sim > max_sim:
                max_sim = sim
                best_intent = intent
                
        if max_sim < threshold:
            return "UNKNOWN_FALLBACK_TO_LLM", max_sim
            
        return best_intent, max_sim

Performance Comparison: Local ONNX vs API-Based Pipelines

To evaluate performance under production load, we benchmarked 5,000 real customer queries processed by our local ONNX router against two alternative architectures: a zero-shot GPT-4o-mini setup and an unquantized PyTorch transformer pipeline.

| Execution Metric | Local ONNX INT8 Engine | Standard PyTorch Model | Direct OpenAI API Call | | :--- | :--- | :--- | :--- | | P95 Latency | 14.2 ms | 72.8 ms | 1,420 ms | | RAM Consumption | 140 MB | 680 MB | N/A (Cloud) | | Cost per 10k Queries| $0.00 (Local CPU) | $0.00 (Local CPU) | ~$14.50 | | Pidgin Intent Accuracy| 93.4% | 93.6% | 84.2% | | Offline Availability| Full | Full | None (Network Dependent) |

By keeping execution entirely inside your application process, you remove third-party HTTP round-trips from 68% of incoming WhatsApp messages. This architectural approach avoids unnecessary token consumption while speeding up system responses.

Common Pitfalls

1. Over-Cleaning Local Vernacular Particles

It is tempting to strip all non-English words using aggressive regex filters. Do not do this. Particles like "no", "dey", and "don" alter the grammatical aspect of Nigerian Pidgin sentences. Stripping "dey" turns "I dey drop package" into "I drop package", flipping present continuous action into simple past tense and causing intent misclassification.

2. Failing to Warm-Up ONNX Runtime Sessions

ONNX Runtime allocates memory graphs dynamically on the first execution pass. If your first real customer request triggers session initialization, that initial user will experience a 400ms to 900ms delay. Always send a dummy zero-tensor warm-up payload through your router during service boot before binding the server to its network socket.

3. Missing Structural Fallback Logic for Mixed Code-Switching

Users routinely mix three languages in one sentence: "Abeg check my balance, mi o ri notification kankan" (Yoruba + Pidgin + English). If your cosine similarity threshold is set too high (e.g., >0.92), these multi-lingual strings will fail classification unnecessarily. Keep your classification threshold between 0.75 and 0.82, and ensure the fallback path forwards the request to your LLM agent with full context preserved.

Frequently Asked Questions

Why not use fine-tuned GPT-3.5 or GPT-4o-mini endpoints instead of a local router?

Cloud fine-tuning improves accuracy, but it does not fix latency or vendor dependency. An API call to a fine-tuned cloud model still requires sending a network request across international routes, taking 400ms to 1200ms per message. Local INT8 ONNX execution takes under 15ms directly inside your primary hosting environment.

How do we handle incoming voice notes containing Nigerian Pidgin?

Voice notes must be transcribed before passing through the intent router. We recommend using an whisper model variant tuned for localized African accents or running a optimized local transcription engine like faster-whisper. Once text output is produced, pass the transcript through the exact same normalize_pidgin_text() pipeline described above.

What server specifications are required to run this model in production?

Because the INT8 model artifact is roughly 23MB, it runs comfortably on an entry-level virtual machine with 1 vCPU and 1GB RAM. It uses around 140MB of memory at runtime, leaving plenty of room for your primary application server or API framework.

How should new slang terms or emerging patterns be integrated?

Log queries that fall below your classification threshold (e.g., confidence < 0.75) into an analytics table. Review those low-confidence logs weekly. When new phrasing patterns emerge (such as new vernacular for payment transfers), add those phrases to your target vector seed dictionary and re-run the target pre-computation step without needing to retrain the underlying model.