Ai Terminology Every It Professional Must Know
Hook
You're in a vendor meeting. They're pitching a solution with "fine-tuned transformer models using retrieval augmented generation with vector embeddings and low-rank adaptation." You nod along, but you're thinking: "Is this actually different from what we have, or are they stringing together buzzwords?" You don't want to look uninformed, but you also don't want to commit budget to something you don't understand.
Here's the truth: AI vendors use jargon intentionally. Sometimes it describes real technical differences that matter. Sometimes it's just complexity for its own sake. Either way, as an IT professional responsible for infrastructure, security, and operations, you need to understand what these terms actually mean and why they matter to your job.
This lesson is your Rosetta stone. Not a dry glossary, but a practical guide to the terms you'll actually encounter in vendor pitches, architecture decisions, and technical discussions.
Purpose
This lesson defines essential AI terminology in plain language, tied directly to IT operations contexts. Each term includes why an IT professional needs to understand it and what it means in practice for infrastructure, cost, security, and performance.
Core Terminology
Inference
What it means: Running a trained AI model on new input to get an output. The opposite of training (where the model learns patterns). When you send a question to an LLM and get a response, that's inference.
Why IT professionals need to know this: Inference is what happens in production. Training is expensive and happens once (before you deploy). Inference happens continuously and directly drives your infrastructure costs and performance requirements. When a vendor says "our inference latency is 200ms," they mean how long it takes to process one request in production. This directly affects user experience and infrastructure load.
IT scenario: Your help desk chatbot runs inference every time a user submits a question. If you get 1,000 questions per hour and inference takes 500ms per question, you need infrastructure capable of handling that throughput. If a vendor claims they can reduce inference latency by 50%, that's real value, your infrastructure can handle 2,000 questions per hour instead of 1,000.
Training
What it means: The process where an AI model learns from historical data. You feed the model examples and it adjusts its internal parameters to better predict outcomes or generate relevant outputs.
Why IT professionals need to know this: Understanding training vs. inference prevents a critical misconception: your deployed models don't learn on the job. They're frozen. Training happened before deployment. If your environment changes significantly, you need to retrain (which is expensive). When a vendor claims their system "learns from your data," understand whether they mean: (a) learns during initial training phase, (b) fine-tuned on some of your data, or (c) actually learns continuously in production (rare and requires careful infrastructure design).
IT scenario: You deploy an anomaly detection system. It learns from six months of your historical infrastructure metrics. The model is frozen. Six months later, you migrate a critical system to a new platform with different load patterns. Your anomaly detection accuracy drops because the model never learned the new patterns. You need to retrain on recent data, which requires collecting examples, running training jobs, and validating the new model before deployment.
Fine-tuning
What it means: Taking an already-trained model and doing a smaller round of training on specialized data. Cheaper and faster than training from scratch, but still training.
Why IT professionals need to know this: This is how you adapt general-purpose models to your specific domain without the cost and complexity of training from scratch. If you use a general LLM for your help desk but want it to be smarter about your specific systems, you fine-tune it on examples of your help desk tickets and responses. This is an investment, but orders of magnitude cheaper than training your own LLM.
IT scenario: You're evaluating LLMs for technical documentation Q&A. Generic LLMs work but aren't great at your specific infrastructure terminology and tools. You can fine-tune on your documentation (weeks of work, moderate cost) or train your own LLM (months of work, millions of dollars). Fine-tuning wins.
Retrieval Augmented Generation (RAG)
What it means: A technique where you combine an LLM with a search engine. Instead of the LLM trying to answer from its training data, it retrieves relevant documents from your systems first, then generates answers based on those documents.
Why IT professionals need to know this: This solves a core LLM problem: hallucination. You can't rely on an LLM's memory of training data. But you can rely on it to synthesize information from documents you provide. RAG lets you build systems that answer questions based on your current documentation (which stays in sync with reality) rather than hoping the LLM remembers.
IT scenario: Your compliance team wants an AI system that answers questions about your security policies. With RAG: the system retrieves your actual policy documents, feeds them to the LLM, and generates answers based on those real documents. Without RAG: you're hoping the LLM somehow learned your specific policies during training (it didn't) and won't hallucinate incorrect policies (it might). RAG is mandatory for high-stakes domains like compliance, security, and operational procedures.
Embeddings
What it means: A way to convert text (or images, or any data) into numbers that capture meaning. Words with similar meanings get similar numbers. "Database" and "data storage" get close numbers; "database" and "purple" get far numbers.
Why IT professionals need to know this: Embeddings are the foundation of RAG and semantic search. Instead of searching for exact text matches ("does the document contain the word 'database'?"), you can search for meaning ("what documents are about databases?"). This powers the retrieval part of RAG.
IT scenario: Your knowledge base has 10,000 articles about infrastructure, troubleshooting, policies, and procedures. A user asks: "How do I set up a new database server?" With keyword search, you'd find articles containing "database" and "server." With embeddings and semantic search, you'd find articles about "setting up databases," "server configuration," "data storage systems", even if they don't use those exact words. The system understands meaning, not just keywords.
Vector Database
What it means: A database optimized for storing and searching embeddings. Instead of traditional databases (which find rows matching exact criteria), vector databases find embeddings that are "close" to your query embedding (meaning similar in meaning).
Why IT professionals need to know this: RAG requires semantic search, which requires vector databases. Understanding what these are helps you architect systems correctly and evaluate infrastructure requirements. You need vector database infrastructure (managed cloud service or self-hosted) when you implement RAG.
IT scenario: You're implementing RAG for help desk documentation. Your 10,000 documentation articles get converted to embeddings (stored in a vector database). When a question comes in, it's converted to an embedding, and you search the vector database for similar embeddings. This requires infrastructure: either a managed service (like Pinecone, Weaviate) or self-hosted (like Elasticsearch with vector support, or Milvus). Understanding the term helps you make infrastructure decisions.
Parameters
What it means: The numbers inside an AI model. A 7-billion-parameter model has 7 billion numbers that were optimized during training. Parameters are what give the model its knowledge and behavior.
Why IT professionals need to know this: Parameter count directly determines infrastructure requirements. Each parameter needs memory to store. A 7B parameter model needs roughly 14-28GB of memory. A 70B model needs 140-280GB. You need to understand this when evaluating which models can run in your infrastructure.
IT scenario: You want to deploy an open-source LLM in your data center. You have one server with 80GB of available GPU memory. You can run a 7B model easily (uses ~28GB). You can run a 13B model (uses ~52GB). You cannot run a 70B model (needs ~280GB). Knowing parameter counts tells you which models fit your infrastructure before you try to deploy and fail.
GPU/TPU
What it means: Graphics Processing Unit (GPU) and Tensor Processing Unit (TPU). Specialized processors that are much faster than CPUs for AI workloads. GPUs are common and available from multiple vendors. TPUs are Google's specialized chips.
Why IT professionals need to know this: AI inference (especially deep learning and LLMs) requires specialized processors. CPUs are too slow. You need GPUs for inference, and you need to understand GPU types, memory sizes, and availability when planning infrastructure.
IT scenario: You deploy an LLM system. Using only CPUs, inference takes 30 seconds per request. Unacceptable. With one GPU, inference takes 500ms. With four GPUs (running in parallel), you can handle 4x more concurrent requests. Understanding GPU architecture and availability is essential for scaling AI workloads.
Tokens
What it means: Small pieces of text that an LLM processes. A word might be one or multiple tokens. Punctuation is tokens. Whitespace is tokens. Important is that LLMs don't process words. They process tokens.
Why IT professionals need to know this: Tokens determine cost, latency, and context window. Most LLM services charge per token. If you don't understand tokenization, you can't predict costs. A 1,000-word document might be 1,200 tokens or 1,800 tokens depending on content and what tokenizer is used.
IT scenario: You're budgeting for LLM costs. A vendor quotes $0.01 per 1,000 tokens. You estimate you'll process 1,000 tickets per month, average 500 words each. That's 500,000 words. You estimate 500,000 * 1.33 = 665,000 tokens (using typical tokenization ratios). Cost: $6.65/month. Seems cheap. But after a few months, you're paying $50/month because your actual tickets tokenize much longer (lots of technical jargon, code snippets, log excerpts). Understanding tokenization prevents budget surprises.
Hallucination
What it means: When an LLM generates false information with confidence. Not making an error it recognizes, confidently stating something that isn't true as if it were truth.
Why IT professionals need to know this: This is the core reliability issue with LLMs. You can't trust an LLM to generate factual information without verification. It will sound confident even when wrong. This is a fundamental limitation, not a bug to be fixed.
IT scenario: An LLM suggests a security mitigation: "Update the OpenSSL configuration file to add the line 'SSLProtocol all -SSLv2'." This sounds authoritative and specific. But you verify it and discover that setting is from 2013 and deprecated in current OpenSSL versions. The LLM hallucinated a plausible-sounding but outdated answer. Never deploy an LLM suggestion without verification, especially in security contexts.
Prompt
What it means: The text you send to an LLM to get it to do something. Your question, instruction, or context.
Why IT professionals need to know this: "Prompt engineering", crafting prompts to get better results, is a real skill and directly affects LLM output quality. Some prompts get better, more accurate responses. This matters for reliability and consistency of LLM systems.
IT scenario: Bad prompt: "Why is my server slow?" Good prompt: "My Apache web server on Linux Ubuntu 20.04 is responding slowly. It has 32GB RAM, 8 vCPUs, and serves 500 requests/minute. Recent logs show memory usage stable at 18GB, CPU usage 30% average, but response times increased from 50ms to 500ms in the last 2 hours. What could be causing this?" The second prompt gives the LLM more context, which leads to better suggestions.
Model
What it means: An AI system trained on data. "Model" is the umbrella term for any trained AI (ML model, neural network, LLM). Think of it like the compiled executable of an AI system.
Why IT professionals need to know this: This is basic vocabulary. When someone says "we're deploying a model," they mean a trained AI system ready for production use. Different models (different training, different architectures, different parameters) have different capabilities and requirements.
IT scenario: You evaluate three models for anomaly detection: Model A (Random Forest ML model), Model B (LSTM DL model), Model C (Pre-trained transformer fine-tuned for your use case). Each model has different accuracy, speed, infrastructure requirements, and interpretability. Choosing the right model drives infrastructure and operational decisions.
Temperature
What it means: A parameter that controls randomness in model output. Low temperature (0.1-0.3) makes outputs more predictable and consistent. High temperature (0.7-1.0+) makes outputs more creative and random.
Why IT professionals need to know this: Temperature affects output consistency, which affects whether you can trust the model's decisions. For automation, low temperature. For brainstorming, higher temperature. This is a tuning knob you might adjust.
IT scenario: Help desk ticket classifier with low temperature (0.1): the same ticket gets classified the same way every time. Consistent, reliable. LLM brainstorming tool for architecture ideas with high temperature (0.9): each run generates different ideas, exploring the design space. Different use cases need different temperatures.
Context Window
What it means: The maximum amount of text an LLM can consider in a single request. Measured in tokens. Current models range from 4K to 200K tokens.
Why IT professionals need to know this: Context window is a hard constraint on what you can feed the LLM. If your documentation is 50K tokens and your context window is 8K, you can't load all documentation at once. This drives architecture decisions (RAG vs. loading all data).
IT scenario: You want to use an LLM to answer questions about your infrastructure documentation (10,000 pages, ~2M tokens). A model with 8K context window can't handle it. You use RAG: retrieve relevant sections (maybe 2,000 tokens) and feed those to the LLM. Or you use a model with larger context window (more expensive, slower, but simpler architecture).
Latency
What it means: The time it takes to get a response. End-to-end, from when you send a request to when you receive output.
Why IT professionals need to know this: Latency directly affects user experience. An LLM with 100ms inference time feels responsive. One with 5-second inference time feels slow. Understanding latency helps you set realistic expectations and design systems appropriately.
IT scenario: Your help desk chatbot should respond quickly. With a 70B parameter LLM, generating a 200-token response at 20 tokens/second takes 10 seconds. Users expect sub-second responses from a chatbot. You either: (a) use a smaller, faster model, (b) accept slower responses, or (c) use streaming (send tokens as they're generated instead of waiting for the full response). Understanding latency makes these tradeoffs explicit.
Throughput
What it means: How much you can process per unit time. For LLMs, often measured in tokens per second or requests per second.
Why IT professionals need to know this: Throughput determines whether your infrastructure can handle your load. If you get 1,000 concurrent users and your system can handle 100 requests per second throughput, you'll have queuing and delays.
IT scenario: You deploy an LLM help desk system. Your peak load is 500 simultaneous users. If each request takes 2 seconds (tokens needed / tokens per second), you need to handle 250 requests per second. If your infrastructure handles 100 requests per second, users will wait in queue. You need to either increase throughput (better hardware, more instances) or reduce latency per request (smaller model, faster inference).
Transformer
What it means: A specific neural network architecture designed for sequences (like text). Transformers use "attention" to focus on relevant parts of input. The foundation of modern LLMs.
Why IT professionals need to know this: "Transformer" is the architecture behind every major LLM (GPT, Claude, Llama, etc.). Understanding that they're transformer-based tells you they share similar characteristics: good at text, require significant compute, benefit from large training datasets.
IT scenario: Someone mentions a "transformer model." You immediately know it's designed for sequential data, likely an LLM or language-based system. You know it's not designed for, say, pure numerical prediction or image recognition (different architectures exist for those).
Weight
What it means: An individual parameter in an AI model. Specifically, a number that multiplies input values in a neural network.
Why IT professionals need to know this: "Weights" and "parameters" are often used interchangeably. Weights are adjusted during training. Understanding that models are composed of weights helps you understand that training is the process of optimizing billions of numbers to predict patterns.
IT scenario: When you fine-tune a model, you're adjusting weights on a small subset of the model (using new data) rather than re-optimizing all weights from scratch. This is why fine-tuning is cheaper than training.
Bias
What it means: In neural networks, bias is a number added to computation. In datasets, bias refers to systematic skew (e.g., biased training data). Context matters.
Why IT professionals need to know this: Both meanings matter for AI reliability. Neural network bias is technical. Dataset bias is operational. If your training data for IT ticket severity classification has a bias toward marking security team tickets as critical (because the security team submits critical issues more often), your model learns that bias. Tickets from other teams get underestimated severity.
IT scenario: Your historical help desk data shows that tickets from the finance department get classified Critical 40% of the time, while tickets from HR get classified Critical 10%. This might be because finance deals with more critical issues. Or it might be bias in how finance tickets are initially categorized. If it's bias, your model learns it and perpetuates it. Data cleaning (addressing bias) becomes part of model development.
Epoch
What it means: One complete pass through all training data. If you train for 3 epochs, you process all training data 3 times.
Why IT professionals need to know this: Understanding epochs helps you understand training time and overtraining risk. More epochs = more time, potentially better accuracy, but risk of overfitting (memorizing training data instead of learning general patterns).
IT scenario: You're fine-tuning an LLM on 1,000 examples of your help desk tickets. Each epoch processes those 1,000 examples. Training for 3 epochs means you process 3,000 examples total. This takes hours or days. More epochs might improve accuracy but increase risk of overfitting where the model memorizes your specific examples instead of learning general patterns.
Overfitting
What it means: When a model learns training data too well and doesn't generalize to new, unseen data. It memorizes specific patterns instead of learning general ones.
Why IT professionals need to know this: Overfitting is the enemy of ML reliability. A model that overfits looks great on your test data (because it's from the same distribution as training data) but fails on real-world data. This is a fundamental tradeoff in ML: memorization vs. generalization.
IT scenario: You train an anomaly detection system on your historical data. Performance on test data: 98% accuracy. Real-world performance after deployment: 65% accuracy. Why the gap? Overfitting. The model memorized patterns specific to your training data distribution (patterns like "on the third Tuesday of each month, server load spikes to 75%" because it did in your training data). In production, those specific patterns aren't always true, and the model fails.
Edge AI
What it means: Running AI models on edge devices (phones, IoT sensors, small servers) instead of sending data to a central cloud.
Why IT professionals need to know this: Edge AI changes infrastructure and data privacy implications. Instead of sending all telemetry to a cloud AI system, you run smaller models locally. Faster response, lower latency, less data transmission.
IT scenario: Your company has thousands of IoT sensors on infrastructure (temperature, vibration, power). Sending all sensor data to a cloud LLM for analysis would be expensive (huge data pipes) and slow (latency). Instead, run lightweight ML models on the sensors themselves, locally detecting anomalies, and send alerts (not raw data) to the cloud. Edge AI reduces bandwidth and latency.
Multimodal
What it means: Models that can input and output multiple types of data (text, images, audio, video).
Why IT professionals need to know this: Newer models are multimodal. They can analyze both text and images, or generate both. This matters for IT scenarios involving dashboards, screenshots, server logs, and architecture diagrams.
IT scenario: You're troubleshooting a server issue. With text-only models, you describe the problem in words. With multimodal models, you can include a screenshot of the monitoring dashboard, a screenshot of the error message, and a log excerpt. The model can see all of them and provide better diagnosis.
Low-Rank Adaptation (LoRA)
What it means: A technique for fine-tuning large models efficiently. Instead of adjusting all parameters, you add small "adapter" layers that adjust a subset of parameters.
Why IT professionals need to know this: LoRA makes fine-tuning large models cheap and fast. Instead of fine-tuning a 70B parameter model (requires massive compute), you fine-tune a small LoRA adapter (fraction of the parameters). This matters for deployment: LoRA lets you have specialized models without building specialized model infrastructure.
IT scenario: You want multiple specialized LLMs: one for help desk, one for security, one for infrastructure. Training three separate models is expensive. With LoRA, you train one base model and create three small LoRA adapters. The main model is loaded once, and different adapters are loaded based on which system is being used. Saves infrastructure and cost.
Quantization
What it means: Reducing the numerical precision of model parameters. Instead of storing numbers with full precision (32-bit floats), store them with lower precision (8-bit or 4-bit integers).
Why IT professionals need to know this: Quantization reduces model size by 4-8x with only 1-5% accuracy loss. This is huge for infrastructure, smaller models run faster, use less memory, consume less bandwidth.
IT scenario: A 70B parameter LLM in full precision uses 280GB of memory. Quantized to 8-bit, it uses 70GB. 4-bit quantized, it uses 35GB. This difference determines whether the model fits in your infrastructure. Most IT operations tasks tolerate the 1-5% accuracy loss from quantization, making it a no-brainer optimization.
Key Takeaways
Know the distinction between training and inference. Training happens once; inference happens in production and drives your costs and infrastructure decisions.
Understand parameter count, context window, and latency. These three numbers determine whether a model fits in your infrastructure, what it can handle, and how fast it responds.
Hallucination is built-in, not a bug. LLMs generate plausible-sounding false information. Never trust LLM output without verification, especially for technical or security guidance.
RAG is how you make LLMs reliable for domain-specific knowledge. Instead of hoping the model learned your policies or documentation, feed it your actual documents and have it synthesize answers from those.
Quantization is often the highest-ROI optimization. Before scaling infrastructure, try quantizing your models. 4-8x efficiency gains with 1-5% accuracy loss is usually worth it.
Skill.re