Building a Multilingual AI Backend for Part Recognition

Situation

When building AI features that analyze user-provided text, supporting multiple languages often introduces immense complexity. For an automotive maintenance application, users could enter service records in Spanish, English, or French.

The backend needed to parse these records, identify exactly which parts were serviced (e.g., “spark plugs”, “bujías”, “bougies”), and provide predictive maintenance advice. It also needed to generate precise product search queries for an affiliate program—all matched perfectly to the user’s native language.

The Challenge

Directly translating user input on the fly is slow, expensive, and often inaccurate for technical automotive terms. Conversely, maintaining entirely separate backend logic branches for each language becomes a maintenance nightmare.

The core algorithm needed to be language-agnostic while the inputs and outputs remained language-specific.

Implementation Patterns

1. Unified Multilingual Keyword Dictionaries

Instead of translating on the fly, the solution involved creating a comprehensive dictionary mapping specific entities to their translations across all supported languages.

const PART_KEYWORDS = {
  SPARK_PLUGS: {
    es: ["bujía", "bujias", "encendido"],
    en: ["spark plug", "spark plugs", "ignition"],
    fr: ["bougie", "bougies", "allumage"]
  },
  // ... other parts
};

This allows the backend to cross-match any incoming text against all known variations, identifying the canonical part ID (SPARK_PLUGS) regardless of the input language.

2. Parameter Extraction and Defaulting

The client application was updated to include the user’s locale in every request payload. The serverless functions extract this parameter, falling back to a default if missing.

// Extract language from request with 'es' as default
const { question, vehicleContext, previousMessages, records, language = 'es' } = request.data;

3. Localized Response Mapping

Once the AI logic completes its assessment using the canonical part IDs, the final step is formatting the output. A response dictionary uses the canonical ID and the extracted language parameter to return the correct string.

Service	Spanish	English	French
Spark Plugs (due)	“Cambiadas hace X km…"	"Changed X km ago…"	"Changées il y a X km…”
Timing Belt (critical)	“⚠️ CRÍTICO: Último cambio…"	"⚠️ CRITICAL: Last change…"	"⚠️ CRITIQUE: Dernier changement…“

4. Dynamic Affiliate Queries

For monetization, the app dynamically generates search queries for automotive parts. Using the same localized dictionaries, the backend constructs highly targeted queries:

• ES: "Bujías Ford Focus 2018"
• EN: "Spark plugs Ford Focus 2018"
• FR: "Bougies Ford Focus 2018"

This approach kept the core predictive logic clean and language-agnostic while delivering a fully localized experience to the end user.

Conceptual Diagram

This diagram conceptually supports Building a Multilingual AI Backend for Part Recognition. It illustrates the core architectural concept: disparate language streams (EN, ES, FR) flowing into a central, unified intelligence node, which then parses them into a single canonical standard.

Post-Specific Engineering Lens

For this post, the primary objective is: Balance model quality with deterministic runtime constraints.

Implementation decisions for this case

• Chose a staged approach centered on nodejs to avoid high-blast-radius rollouts.
• Used multilingual checkpoints to make regressions observable before full rollout.
• Treated llm documentation as part of delivery, not a post-task artifact.

Practical command path

These are representative execution checkpoints relevant to this post:

./llama-server --ctx-size <n> --cache-type-k q4_0 --cache-type-v q4_0
curl -s http://localhost:8080/health
python benchmark.py --profile edge

Validation Matrix

Validation goal	What to baseline	What confirms success
Functional stability	input quality, extraction accuracy, and processing latency	schema validation catches malformed payloads
Operational safety	rollback ownership + change window	confidence/fallback policy routes low-quality outputs safely
Production readiness	monitoring visibility and handoff notes	observability captures latency + quality per request class

Failure Modes and Mitigations

Failure mode	Why it appears in this type of work	Mitigation used in this post pattern
Over-allocated context	Memory pressure causes latency spikes or OOM	Tune ctx + cache quantization from measured baseline
Silent quality drift	Outputs degrade while latency appears fine	Track quality samples alongside perf metrics
Single-profile dependency	No graceful behavior under load	Define fallback profile and automatic failover rule

Recruiter-Readable Impact Summary

• Scope: ship AI features with guardrails and measurable quality.
• Execution quality: guarded by staged checks and explicit rollback triggers.
• Outcome signal: repeatable implementation that can be handed over without hidden steps.