MLOps Vocabulary for People Who Already Do It

Here's a common trap for strong operations-minded engineers: you already do disciplined deployment, monitoring, and rollback — but a posting says "MLOps, model deployment/monitoring workflows," and in the interview you describe your excellent practices in ops language while the panel's rubric says MLOps words. Same substance, zero points. This lesson is a relabeling exercise: the MLOps term, what it means, and the ordinary engineering it corresponds to.

The translation table

Model registry — a versioned inventory of models: which model/version is deployed where, with what configuration, approved by whom. If you've kept a config-driven record of "which model serves which feature" — that's a lightweight registry. The enterprise versions (Azure Machine Learning's registry, MLflow) add lineage and approvals, but the concept is versioned deployment metadata.

Prompt/configuration versioning — for LLM systems, the prompt, retrieval settings, and model choice are the behavior. Treating them as versioned, diffable artifacts with review before change — exactly like schema migrations — is modern LLMOps. If you version prompts in git or a config store with rollback: say "we version and review prompts like code."

Evaluation pipeline / golden set — an automated test suite for model behavior: a curated set of inputs with known-correct outputs, run before any model/prompt change ships. It's regression testing, applied to AI. "No eval, no deploy" is the MLOps version of "no tests, no merge."

LLM-as-judge — using a second model to grade the first's outputs at scale (with human spot-checks calibrating the judge). Useful phrase when asked how you'd evaluate free-text outputs where exact-match scoring fails.

Drift — the world changing out from under a deployed model. Data drift: inputs stop resembling what you built against (new transcript formats, new course-naming fashions). Concept drift: the right answer changes (requirements updated, policy amended). The monitoring you'd build for either — distribution stats on inputs, alerts when accuracy on sampled reviews declines, corpus version checks — is health monitoring pointed at a model.

Canary / shadow deployment — release patterns you likely already know from services: canary = new version serves a small slice first, promoted on good metrics; shadow = new version runs on real traffic but its outputs aren't shown, only compared. Shadow mode is especially valuable for AI in government: run the AI silently against cases humans are already deciding, measure agreement, and build the accuracy case before the AI ever touches a member of the public. If you've ever run old and new logic side by side to compare — you've done shadow deployment.

Observability for AI — logs/metrics/traces, plus AI-specifics: token usage and cost per request, latency, retrieval hit quality, refusal rates, override rates. Saying "we tracked cost and quality per request the way we track latency SLOs" marks you as someone who has operated AI, not just called it.

Rollback for AI systems — because behavior lives in (model, prompt, corpus, thresholds), rollback means restoring a known-good combination of all four. Feature toggles that disable the AI path entirely are the emergency brake above rollback.

The one-paragraph MLOps answer

When the panel asks "what's your experience with MLOps?", do not apologize for lacking a Kubeflow certification. Answer with the discipline:

"I treat AI systems like any production system, with the AI-specific additions: model and prompt versions are tracked and reviewed like code; changes pass an evaluation set built from historical expert decisions before deploying; new behavior ships shadow-first or behind a toggle; and in production we monitor cost, latency, override rates, and drift — with a kill switch that needs no deployment. I've run this discipline on [your systems]; the tooling names change — the practices don't."

That answer scores on every MLOps rubric line without naming a single product — and then, if the panel wants tools, you can add that in an Azure shop this maps to Azure Machine Learning / Azure AI Foundry for registries and evaluations, Application Insights for telemetry, and DevOps pipelines for the gates.

Classical ML: the two-sentence hedge

AI-architect postings sometimes say "machine-learning components" meaning anything from LLMs to a regression model. Have a two-sentence classical-ML position ready: "For structured-data problems — predicting processing times, flagging anomalous batches — classical models (regression, gradient-boosted trees) are cheaper, more explainable, and easier to govern than LLMs, and I'd reach for them first. LLMs earn their cost on language: unstructured documents, equivalence judgments, drafting." Knowing when not to use an LLM is an architect signal.