Update model card: Indian Compliance Classifier Router

README.md

@@ -4,13 +4,14 @@ language:
 - en
 - hi
 tags:
-- bert
+- encoder
 - classifier
 - compliance
 - pii-detection
 - fsi
 - query-routing
 - financial-services
+- india
 library_name: pytorch
 pipeline_tag: text-classification
 model-index:
@@ -24,15 +25,15 @@ model-index:
       value: 99.2
 ---
 
-# BERT Compliance Classifier Router
+# Indian Compliance Classifier Router
 
-A 134M parameter BERT encoder model built entirely from scratch — from pre-training through fine-tuning — designed specifically for regulated industries such as Financial Services, Healthcare, and Legal. The model serves as an intelligent query router that classifies incoming prompts based on two critical dimensions: query complexity and the presence of Personally Identifiable Information (PII). This enables cost-optimized, compliance-aware LLM serving where sensitive data never leaves local infrastructure.
+A ~140M parameter encoder model built entirely from scratch - from pre-training through fine-tuning - designed specifically for regulated industries such as Financial Services, Healthcare, and Legal. The model serves as an intelligent query router that classifies incoming prompts based on two critical dimensions: query complexity and the presence of Personally Identifiable Information (PII). This enables cost-optimized, compliance-aware LLM serving where sensitive data never leaves local infrastructure.
 
 Unlike traditional keyword-based or regex-based PII detection, this model learns contextual patterns from training data, enabling it to detect PII in both structured formats (like PAN: ABCDE1234F) and unstructured human-typed input (like "my pan is abcde1234f" or "Mera PAN number batao"). The model supports English and Hinglish (Hindi-English code-mixed) queries commonly seen in Indian financial services.
 
 ## Model Description
 
-The core purpose of this model is to sit at the entry point of a multi-tier LLM serving architecture. When a user query arrives, this classifier makes a routing decision in under 10 milliseconds — determining whether the query should go to a small or large language model, and whether the data must stay on local infrastructure or can be processed cross-region. This architectural pattern delivers 65-73% cost savings compared to routing all queries to a single large model, while simultaneously enforcing data residency compliance that is architecturally impossible with Mixture-of-Experts (MoE) approaches.
+The core purpose of this model is to sit at the entry point of a multi-tier LLM serving architecture. When a user query arrives, this classifier makes a routing decision in under 10 milliseconds - determining whether the query should go to a small or large language model, and whether the data must stay on local infrastructure or can be processed cross-region. This architectural pattern delivers 65-73% cost savings compared to routing all queries to a single large model, while simultaneously enforcing data residency compliance that is architecturally impossible with Mixture-of-Experts (MoE) approaches.
 
 The model outputs one of four labels, each mapping directly to a routing action:
 
@@ -48,15 +49,15 @@ The model outputs one of four labels, each mapping directly to a routing action:
 The model achieves production-ready performance across all metrics. The 99.2% accuracy on a held-out test set demonstrates strong generalization, while the sub-10ms latency ensures the routing decision adds negligible overhead to the overall request lifecycle. The throughput of 130+ queries per second on a single GPU means a single instance can serve millions of classification requests per day.
 
 - **Accuracy:** 99.2%
-- **PII Recall:** ~100% (conservative — prefers false positive over missed PII)
+- **PII Recall:** ~100% (conservative - prefers false positive over missed PII)
 - **Latency:** ~7ms (GPU) / ~72ms (CPU)
 - **Throughput:** ~130 queries/sec per GPU instance
-- **Model Size:** 134M parameters / ~530 MB on disk
+- **Model Size:** ~140M parameters / ~530 MB on disk
 - **Inference Memory:** ~530 MB VRAM (fits on any GPU including T4 16GB)
 
 ## Files
 
-The repository contains two files required for inference. The model weights file contains the trained parameters of the BERT encoder plus the classification head. The tokenizer file contains the BPE vocabulary and merge rules trained on English Wikipedia, including special tokens required for the model.
+The repository contains two files required for inference. The model weights file contains the trained parameters of the encoder plus the classification head. The tokenizer file contains the BPE vocabulary and merge rules trained on English Wikipedia, including special tokens required for the model.
 
 | File | Size | Description |
 |------|------|-------------|
@@ -65,31 +66,31 @@ The repository contains two files required for inference. The model weights file
 
 ## Architecture
 
-The model uses a standard BERT encoder architecture — a bidirectional transformer that attends to all tokens simultaneously (no causal mask). This is fundamentally different from decoder-only models like GPT which can only see past tokens. The bidirectional attention is critical for classification tasks because the model needs to understand the full context of a query before making a routing decision. The classification is performed on the first token's hidden state, which aggregates information from the entire input sequence through self-attention.
+The model uses a bidirectional transformer encoder architecture that attends to all tokens simultaneously (no causal mask). This is fundamentally different from decoder-only models like GPT which can only see past tokens. The bidirectional attention is critical for classification tasks because the model needs to understand the full context of a query before making a routing decision. The classification is performed on the first token's hidden state, which aggregates information from the entire input sequence through self-attention.
 
-- **Type:** BERT Encoder (bidirectional transformer, no causal mask)
+- **Type:** Bidirectional Transformer Encoder (no causal mask)
 - **Dimensions:** 768
 - **Layers:** 12
 - **Attention Heads:** 12
 - **FFN Dimension:** 3072
 - **Max Sequence Length:** 128 tokens (inference) / 512 tokens (pre-training)
-- **Vocabulary:** 32,000 (BPE, includes `<mask>` token at ID=4)
-- **Activation:** GELU (standard for BERT-family models)
+- **Vocabulary:** 32,000 (BPE, includes special tokens)
+- **Activation:** GELU
 - **Normalization:** LayerNorm (pre-norm variant)
-- **Classification Head:** Linear(768→768) → Tanh → Dropout → Linear(768→4)
+- **Classification Head:** Linear(768-768) - Tanh - Dropout - Linear(768-4)
 
 ## Training
 
-The model was trained in two phases following the standard pre-train then fine-tune paradigm. Pre-training teaches the model general English language understanding through the Masked Language Model (MLM) objective — predicting randomly masked tokens from context. Fine-tuning then specializes this general understanding into the specific 4-class classification task using labeled FSI examples.
+The model was trained in two phases following the standard pre-train then fine-tune paradigm. Pre-training teaches the model general English language understanding through the Masked Language Model (MLM) objective - predicting randomly masked tokens from context. Fine-tuning then specializes this general understanding into the specific 4-class classification task using labeled FSI examples.
 
 ### Pre-training
 
-Pre-training was conducted on English Wikipedia (2B tokens) using the Masked Language Model objective. During each training step, 15% of input tokens are randomly masked (80% replaced with [MASK], 10% replaced with random token, 10% kept unchanged), and the model learns to predict the original tokens. This teaches deep contextual understanding of English language patterns, grammar, and world knowledge — providing a strong foundation for downstream classification.
+Pre-training was conducted on English Wikipedia (2B tokens) using the Masked Language Model objective. During each training step, 15% of input tokens are randomly masked (80% replaced with mask token, 10% replaced with random token, 10% kept unchanged), and the model learns to predict the original tokens. This teaches deep contextual understanding of English language patterns, grammar, and world knowledge - providing a strong foundation for downstream classification.
 
 - **Objective:** Masked Language Model (MLM), 15% masking (80/10/10)
 - **Data:** English Wikipedia (2B tokens processed over 500K steps)
 - **Batch size:** 8, sequence length: 512
-- **Learning Rate:** 1e-4 → 1e-5 (cosine schedule, warmup 2000 steps)
+- **Learning Rate:** 1e-4 to 1e-5 (cosine schedule, warmup 2000 steps)
 - **Optimizer:** AdamW (betas=0.9/0.999, weight_decay=0.01)
 - **Hardware:** NVIDIA L4 (24 GB), ~48 hours
 - **Precision:** BF16 mixed precision with gradient checkpointing
@@ -104,13 +105,13 @@ Fine-tuning was performed on 50,000 synthetic FSI examples carefully designed to
 - **Input Formats:** Structured + unstructured (human-typed messy input)
 - **Languages:** English + Hinglish (15% code-mixed)
 - **Steps:** 8,000, batch=32, sequence length=128
-- **Learning Rate:** 2e-5 → 2e-6 (cosine schedule)
+- **Learning Rate:** 2e-5 to 2e-6 (cosine schedule)
 - **Hardware:** NVIDIA L4, ~15 minutes
 - **Final Accuracy:** 99.2%
 
 ## Usage
 
-Using this model requires defining the BERT architecture (as the weights are stored as a PyTorch state_dict without the architecture). The model accepts tokenized input with an attention mask and returns logits for 4 classes. A softmax converts logits to probabilities, and the argmax gives the predicted label.
+Using this model requires defining the encoder architecture (as the weights are stored as a PyTorch state_dict without the architecture). The model accepts tokenized input with an attention mask and returns logits for 4 classes. A softmax converts logits to probabilities, and the argmax gives the predicted label.
 
 ```python
 import torch
@@ -120,7 +121,7 @@ from tokenizers import Tokenizer
 # Load tokenizer
 tokenizer = Tokenizer.from_file("deycoding.compliance-classifier-in-1-0.json")
 
-# Load model weights (requires architecture definition — see documentation)
+# Load model weights (requires architecture definition - see documentation)
 model.load_state_dict(torch.load("deycoding.compliance-classifier-in-1-0.pt", map_location="cpu"))
 model.eval()
 
@@ -168,7 +169,7 @@ This model is designed for deployment as a lightweight, low-latency routing laye
 
 - Query routing in multi-tier LLM serving architectures
 - PII detection for data residency compliance (GDPR, RBI Data Localization, India DPDP Act)
-- Cost optimization — route simple queries to cheaper/smaller models (65-73% savings)
+- Cost optimization - route simple queries to cheaper/smaller models (65-73% savings)
 - Financial services (banking, insurance, capital markets)
 - Healthcare (patient data routing)
 - Legal (privileged information detection)
@@ -177,20 +178,20 @@ This model is designed for deployment as a lightweight, low-latency routing laye
 
 While the model achieves high accuracy on the test set, there are important limitations to consider before production deployment. The training data is synthetic (template-generated with variations), which means the model may not generalize perfectly to all real-world query patterns. Production deployment should include a feedback loop where misclassified queries are collected and used to improve subsequent training iterations.
 
-- Trained on synthetic data — recommend fine-tuning on real customer queries for production
-- English + Hinglish only — other Indian languages (Tamil, Telugu, Bengali, etc.) not covered
-- Max 128 tokens — very long queries get truncated, potentially losing PII at the end
-- PII detection is learned (not regex) — may miss novel PII formats not represented in training data
-- No entity extraction — model detects presence of PII but doesn't extract or mask specific values
-- Confidence calibration not verified — high confidence doesn't guarantee correctness on out-of-distribution inputs
+- Trained on synthetic data - recommend fine-tuning on real customer queries for production
+- English + Hinglish only - other Indian languages (Tamil, Telugu, Bengali, etc.) not covered
+- Max 128 tokens - very long queries get truncated, potentially losing PII at the end
+- PII detection is learned (not regex) - may miss novel PII formats not represented in training data
+- No entity extraction - model detects presence of PII but does not extract or mask specific values
+- Confidence calibration not verified - high confidence does not guarantee correctness on out-of-distribution inputs
 
 ## Ethical Considerations
 
-This model is designed to enhance privacy and compliance, not to circumvent it. The routing decisions enforce data residency by ensuring PII-containing queries physically cannot reach cross-region infrastructure. The model makes conservative decisions — when uncertain, it defaults to the most restrictive routing (local processing), preferring false positives (unnecessary local routing) over false negatives (PII leaking to cross-region).
+This model is designed to enhance privacy and compliance, not to circumvent it. The routing decisions enforce data residency by ensuring PII-containing queries physically cannot reach cross-region infrastructure. The model makes conservative decisions - when uncertain, it defaults to the most restrictive routing (local processing), preferring false positives (unnecessary local routing) over false negatives (PII leaking to cross-region).
 
 - Model makes routing decisions, not content decisions
 - PII detection is conservative (prefers false positive over missed PII)
-- Data residency enforcement is architectural — PII queries physically cannot reach cross-region infrastructure
+- Data residency enforcement is architectural - PII queries physically cannot reach cross-region infrastructure
 - No user data is stored or logged by the model itself
 - Model should be part of a defense-in-depth strategy, not the sole PII control