LLMOps in English: Vocabulary for Deploying and Monitoring Language Models
Expand your LLMOps vocabulary in English — prompt versioning, RAG, evaluation harnesses, hallucination monitoring, and cost-per-token language for AI engineers.
LLMOps: A New Domain, New English Vocabulary
LLMOps — the operational practice of deploying, monitoring, and maintaining Large Language Models in production — is one of the fastest-growing specialisations in software engineering. The vocabulary is evolving rapidly, and many terms have no direct equivalent in other languages. Mastering these terms in English is essential if you work in AI engineering or want to follow international research and tooling discussions.
Core LLMOps Vocabulary
Prompt Versioning
Prompts are not static — they change frequently as you tune model behaviour. Prompt versioning is the practice of tracking changes to prompts in a version control system, much like source code.
“We version all system prompts in our Git repository and use semantic versioning to track breaking changes.”
Related terms:
- Prompt template — a reusable prompt structure with placeholder variables.
- System prompt — the instructions given to the model before the user’s input.
- Prompt registry — a centralised store of versioned prompts.
Retrieval-Augmented Generation (RAG)
RAG is an architecture where the model retrieves relevant context from an external knowledge base before generating a response. This reduces hallucination and keeps the model’s knowledge current without retraining.
- Vector store — a database that stores text as numerical embeddings for semantic similarity search.
- Retrieval pipeline — the sequence of steps that fetches, ranks, and injects context into the prompt.
- Chunking — splitting documents into smaller pieces for indexing and retrieval.
Evaluation Harness
An evaluation harness is a test framework that automatically scores model outputs against a set of reference answers or criteria. This is analogous to a unit test suite for traditional software.
- Groundedness — whether the model’s answer is supported by the retrieved context.
- Faithfulness — whether the response accurately reflects the source material without adding fabricated detail.
- Latency budget — the maximum acceptable response time for a model call.
Hallucination Monitoring
Hallucination in LLMs refers to the model generating confident but factually incorrect or entirely fabricated information. In production, teams implement monitoring to detect and alert on hallucinations.
- Hallucination rate — the percentage of responses that contain factually incorrect or unsupported claims.
- Guard rail — a rule or classifier applied to model output to catch unsafe or incorrect responses before they reach users.
- Output validation — programmatic checks applied to model responses to verify format, completeness, or factual consistency.
Cost Per Token
Running LLMs at scale is expensive. Cost per token is the fundamental unit of LLM pricing — you pay for both input tokens (the prompt) and output tokens (the generated response).
- Token budget — the maximum number of tokens allocated to a single request or workflow.
- Context window — the maximum number of tokens a model can process in a single call.
- Caching — storing previous prompt-response pairs to avoid redundant API calls and reduce cost.
Operational Language
Use these phrases in standups, postmortems, and architecture discussions:
- “The evaluation harness flagged a regression in groundedness after the last prompt update.”
- “We are tracking hallucination rate as a key reliability metric in our LLM dashboard.”
- “The retrieval pipeline is the primary latency bottleneck — p99 is currently 1.8 seconds.”
- “We need to optimise the prompt template to stay within the token budget for long documents.”
Five Example Sentences
- “After deploying the new RAG pipeline, the hallucination rate dropped from 12% to 3% on our internal benchmark.”
- “We store all prompt templates in a versioned registry so that any team member can roll back to a previous version if a model update degrades quality.”
- “The evaluation harness runs automatically on every pull request, scoring each prompt variant against a curated set of golden answers.”
- “Our cost-per-token analysis showed that switching to a smaller model for classification tasks reduced monthly spend by 40%.”
- “Guard rails are applied at the output layer to ensure the model does not return responses outside the permitted topic scope.”
Staying Current
LLMOps terminology is standardising quickly. Follow the documentation of tools like LangSmith, MLflow, and Weights & Biases to encounter these terms in authentic context. Reading engineering blogs from companies running LLMs at scale — such as Anthropic, OpenAI, and Cohere — is an excellent way to see how these concepts are described in professional English.
Navigating the Nuances: A Guide for Non-Native Speakers
The world of LLMOps is becoming increasingly complex, demanding a precise command of technical vocabulary. For developers whose first language isn’t English, this can feel particularly challenging. It’s not just about understanding what something does; it’s about using the right phrases to communicate effectively within a team, document your work clearly, and contribute meaningfully to discussions. A common frustration is feeling like you understand the concept conceptually but struggle to articulate it concisely in English, leading to misunderstandings or difficulty collaborating on solutions. This section aims to bridge that gap by offering practical examples of how these terms are used in real-world scenarios, focusing specifically on the subtle differences in phrasing and tone that matter most when communicating with native English speakers.
Let’s consider a code review comment. Imagine you’ve been working on implementing Retrieval Augmented Generation (RAG) for a chatbot – you’ve successfully integrated a new knowledge base and modified your prompt to leverage it. During the code review, your colleague, Sarah, might leave this comment: “This is good work, but could you add some error handling around the retrieval step? What if the vector database returns no results? We need to ensure the LLM doesn’t throw an exception or hallucinate based on a missing context.” Notice the phrasing – it’s not just saying “add error handling”; it’s outlining why that’s important (“What if…?”) and suggesting a specific potential issue (hallucination). A less precise phrase, like “Add error handling,” might be met with confusion about the urgency or scope of the task. Similarly, when writing a Pull Request description for your changes, avoid overly literal translations. Instead of saying “I have implemented RAG,” try something like: “This PR introduces RAG functionality to improve contextual accuracy and reduce reliance on the base LLM by augmenting its knowledge with retrieved documents from the [KnowledgeBaseName] vector database.” The latter is more professional, clearly stating the purpose and highlighting key components.
Another common scenario arises in Slack discussions about monitoring for hallucinations. A senior engineer might say: “Let’s prioritize setting up a continuous evaluation harness to monitor the model’s output for factual inaccuracies – specifically focusing on instances where it contradicts our documented knowledge sources.” Again, the phrasing is layered with intention; “continuous evaluation harness” implies an automated process, and “contradicts our documented knowledge sources” specifies what we’re looking for. A simpler statement like “Monitor for hallucinations” lacks this crucial detail and could lead to wasted effort. It’s about conveying not just the action, but also the criteria for success. Understanding that these phrases are built around a specific level of technical precision is key.
Finally, consider the language used when discussing cost-per-token. Many teams struggle with optimizing LLM usage, and this often leads to discussions around minimizing token consumption. A project manager might say: “We need to investigate strategies for reducing our cost-per-token – perhaps by implementing prompt optimization techniques or exploring smaller model sizes where appropriate.” The phrase “strategies for reducing” is more sophisticated than simply stating a desire to lower the cost, and it immediately suggests actionable steps. Don’t be afraid to ask clarifying questions if you’re unsure about a term – it’s always better to seek clarification than to make assumptions that could lead to miscommunication.
Here’s an example of how to use tiktoken to estimate token counts for prompts:
pip install tiktoken
import tiktoken
encoding = tiktoken.get_encoding("cl100k_base") # Common encoding for OpenAI models
text = "This is a test prompt to calculate the number of tokens."
num_tokens = len(encoding.encode(text))
print(f"Number of tokens: {num_tokens}")