Module 1: Foundations of AI Engineering › LLM Mental Models
GitHub Login Glossary

LLM Mental Models

This lesson replaces magic with mechanics: a practical mental model for how LLMs actually behave.

Once tokens, context windows, messages, and the difference between weights and runtime context are clear, everything we build later will be much easier to reason about and debug. Most "why did the model do that?" moments trace back to one of the ideas in this lesson.

By the end, you'll have the internal vocabulary you need before writing your first prompt contract or making your first API call.

What you'll learn

  • Explain what tokens are and why they determine cost, latency, and context limits
  • Describe the difference between model weights (what the model learned during training) and runtime context (what you give it at inference time)
  • Explain why model outputs vary between runs and what controls that variation
  • Identify whether a problem is a prompt issue, a context issue, or a model limitation
  • Explain the difference between training and inference

Concepts

Token: the basic unit a language model reads and produces. A token is roughly 3-4 characters of English text, but varies by language and model. Tokens determine three things you care about:

  • Cost: you pay per token, and input tokens are priced separately from output tokens. Output tokens are typically 3-5x more expensive. The formula: cost = (input_tokens × input_price) + (output_tokens × output_price). For example, at $3/million input tokens and $15/million output tokens, a request with 10K input tokens and 1K output tokens costs $0.03 + $0.015 = $0.045.

  • Latency: more tokens means slower responses, but input and output affect latency differently. Time to first token (TTFT) scales with input token count (the model processes your entire input before generating anything). Generation time scales linearly with output token count (the model generates one token at a time). So: total_latency ≈ TTFT(input_tokens) + (output_tokens × time_per_token).

  • Context limits: every model has a hard ceiling: input_tokens + output_tokens ≤ context_window. If your system prompt is 2K tokens, your conversation history is 5K, and your retrieved evidence is 10K, you have used 17K tokens of input, and whatever remains is available for the model's response. This is why context budgeting matters from day one.

Most providers offer a tokenizer or token-counting path you can use before sending a request (tiktoken for OpenAI models; Gemini exposes count_tokens; Anthropic exposes token counts in the response usage object and a count-tokens endpoint). Build the habit of checking token counts early. It prevents budget surprises and context overflow.

Context window: the maximum number of tokens a model can process in a single request. This includes everything: your system prompt, the conversation history, retrieved evidence, tool results, and the model's own response. When your input exceeds the context window, the model either truncates or refuses. Bigger context windows do not mean you should fill them. More context is not the same as better context.

Training vs inference: training is the process that creates the model's weights (its learned knowledge and behaviors). Inference is what happens when you send a request to the model and get a response. Training changes the model. Inference uses the model as-is. Most AI engineering work is inference-time work: choosing what context to provide, how to structure prompts, which tools to expose, and how to evaluate outputs. We won't train a model until Modules 7 and 8 of this curriculum.

Weights: the model's learned parameters, fixed at training time. Weights encode general knowledge, language patterns, and reasoning capabilities. You cannot change weights at inference time. When you send a prompt, you are not teaching the model; you are steering it within its existing capabilities.

Runtime context: everything you provide in a single request: system prompt, user message, conversation history, retrieved documents, tool results. This is the only thing you control at inference time. The quality of your system's output depends heavily on what context you select and how you structure it.

Temperature: a parameter that controls randomness in the model's output. Temperature 0 gives the most deterministic output (always picks the highest-probability token). Higher temperatures introduce more variation. Temperature does not make the model "more creative" in a reliable way; it makes it more random.

Top-p (nucleus sampling): an alternative to temperature for controlling output randomness. Instead of scaling all token probabilities, top-p truncates the distribution to the smallest set of tokens whose cumulative probability exceeds the threshold p. In practice, most applications set temperature or top-p, not both.

Message roles: LLM APIs structure conversations as sequences of messages, each with a role:

  • System: instructions that frame the model's behavior for the entire conversation
  • User: the human's input
  • Assistant: the model's previous responses
  • Tool: results returned from tool calls

The order, structure, and content of these messages are your primary levers for controlling model behavior.

Model families you'll encounter

The term "LLM" (large language model) is the umbrella for most models you'll work with, but not all models are the same kind of tool. You'll encounter three categories:

Workhorse models (standard LLMs): general-purpose models optimized for speed and broad capability. GPT-4o-mini, Claude Haiku, and Gemini Flash are examples. They handle most tasks well: summarization, extraction, classification, generation. This is what you'll use for most of your work and what the exercises in this lesson use. When someone says "LLM" without qualification, they usually mean this.

Reasoning models: models optimized for complex multi-step planning, math, and logic. OpenAI's o3 and o4-mini are examples. They spend more time "thinking" before answering, which makes them slower and more expensive but significantly better on hard problems. You will hear some people call these "LRMs" (large reasoning models), but "reasoning models" is the more consistent term across provider documentation. The key tradeoff: use reasoning models when the task genuinely requires multi-step planning or complex logic, not as a default for every call.

Small language models (SLMs): compact models (typically 1-7B parameters) that run on consumer hardware with lower cost, lower latency, and better privacy. Microsoft's Phi models, Meta's smaller Llama variants, and Google's Gemma models are examples. SLMs are weaker on broad tasks than frontier models, but they are the right choice when privacy, offline operation, predictable cost, or low latency matter more than peak capability. You will encounter SLMs in Module 8 (distillation and fine-tuning) when you compress a capable model's behavior into a smaller one.

A note on vLLM: You may see "vLLM" mentioned in AI engineering discussions. It's not a model, but an inference serving engine that lets you host open-weight models behind an OpenAI-compatible HTTP endpoint. It belongs to the infrastructure layer, not the model layer. You don't need it now. It becomes relevant if you move from calling hosted APIs to self-hosting models, which is an advanced topic covered in the Hardware and Model Size Guide.

For this curriculum, you'll primarily use workhorse models through hosted APIs. The concepts you learn (tokens, context windows, prompt contracts, tool calling, retrieval) apply identically to reasoning models, SLMs, and self-hosted models. The only things that change are cost, latency, capability boundaries, and where the model runs.

If you want the concrete version of this question, not just the theoretical abstract, read the Model-Provider Matrix. That page tracks which exact model/provider combinations actually held the lesson contracts when I smoke-tested the guide.

Walkthrough

Before you start, read Choosing a Provider. In this path, OpenAI Platform, Gemini API, Anthropic's developer platform, Hugging Face, GitHub Models, Ollama Local, and Ollama Cloud are all valid starting paths. You can keep more than one configured. The critical distinction: consumer chat apps (chatgpt.com, gemini.google.com, claude.ai, huggingface.co/chat) are not the same thing as the developer platforms used in these lessons. If you are starting with OpenAI, go to https://platform.openai.com/. If you are starting with Gemini, go to https://aistudio.google.com/ for keys and https://ai.google.dev/ for the API docs. If you are starting with Anthropic, go to https://platform.claude.com/. If you are starting with Hugging Face, go to https://huggingface.co/settings/tokens for HF_TOKEN and https://huggingface.co/docs/inference-providers/index for the API path. If you are starting with GitHub Models, use the GitHub Models inference API docs and a GitHub token. If you are starting with local Ollama, install it from https://ollama.com/download. If you are starting with Ollama Cloud, go to https://ollama.com/api.

Setup: your first model call

Before you can experiment with tokens, temperature, and prompts, you need to be able to make a model call. This is a minimal quickstart, just enough to run the exercises in this lesson. The full API lesson comes next.

The lesson concept is the same across all supported paths; only the SDK surface, auth variable, and response shape differ. Pick your provider tab and use that version all the way through this lesson.

mkdir llm-experiments && cd llm-experiments
python -m venv .venv && source .venv/bin/activate
pip install openai

export OPENAI_API_KEY="sk-..."
# first_call.py
from openai import OpenAI

client = OpenAI()  # reads OPENAI_API_KEY from environment

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "What is a token in the context of LLMs?"}
    ],
    temperature=0
)

print(response.choices[0].message.content)
print(f"\nTokens used: {response.usage.total_tokens}")
print(f"  Input: {response.usage.prompt_tokens}")
print(f"  Output: {response.usage.completion_tokens}")
python first_call.py

If you see a response and token counts, you are ready. If you get an authentication error, check your API key. If you get a rate limit error, wait a moment and retry.

You'll use this setup throughout the exercises below. The Build with APIs lesson covers structured outputs, multi-turn conversations, tool calling, and error handling in depth.

Tokens are not words

A tokenizer is the tool that splits text into the tokens a specific model actually uses. Different models use different tokenizers, so the same sentence may produce different token counts depending on the model. Try these:

  • OpenAI Tokenizer — a web-based tool where you paste text and see exactly how it splits into tokens, color-coded. The fastest way to build intuition. Supports GPT-4o and GPT-3.5 tokenization.
  • tiktoken — OpenAI's Python library for counting tokens programmatically. Install with pip install tiktoken. Use this when you need token counts in your code (e.g., budgeting context before sending a request).
  • Hugging Face Tokenizers docs — a good reference for how modern tokenizers work across open models, especially if you are learning with Hugging Face or self-hosted models.
  • Anthropic token counts — Anthropic does not publish a standalone tokenizer, but every API response includes usage.input_tokens and usage.output_tokens in the response body. You can also use the /v1/messages/count_tokens endpoint to count tokens before sending a request.
  • Ollama usage counters — Ollama responses report token-like usage counters such as prompt_eval_count and eval_count. If you are using Ollama Cloud or local Ollama, those fields are your first place to build token intuition.

Paste a few sentences into the OpenAI Tokenizer and observe: tokens do not align with word boundaries. "Unbelievable" might be 2-3 tokens. A code snippet with unusual variable names might tokenize into many small pieces. This matters because:

  • You pay per token, not per word
  • Your context window is measured in tokens
  • Long variable names, formatting, and whitespace consume tokens

Build intuition for token counts early. You'll need it when budgeting context in retrieval and prompt design.

Weights vs context: the most important distinction

The model's weights are fixed. When you send a prompt, you are not "teaching" the model anything; you are selecting which capabilities to activate by providing context. This distinction matters for every decision you'll make:

  • If the model does not know something, adding it to the prompt (context) can help. Training the model (weights) is a different, much heavier intervention.
  • If the model "forgets" instructions, it is because the context is too long, not because it lost knowledge. The weights have not changed.
  • If the model generates something that sounds confident but isn't supported by evidence, that's a hallucination. We'll cover this in more detail below.

Why outputs vary

Even at temperature 0, models are not perfectly deterministic across API calls (batching, infrastructure changes, and floating-point precision can cause minor variation). At higher temperatures, variation is by design. This means:

  • You cannot rely on exact string matching for evaluation
  • You need structured output schemas (covered in Build with APIs) to get predictable shapes
  • Evaluation must account for acceptable variation

Hallucination: what it is and what it isn't

You'll hear "hallucination" constantly in AI discussions, often used loosely to mean "the model said something wrong." It's worth being more precise, because the cause determines the fix.

Hallucination means the model generates content that sounds confident and plausible but isn't supported by the evidence it was given, or fabricates details that don't exist. A model that invents a function name that isn't in the codebase, cites a paper that was never written, or states a configuration value that doesn't match the actual config is hallucinating.

What hallucination is not:

  • It's not "any wrong answer." A model that misinterprets ambiguous instructions gave a bad answer, but it didn't hallucinate; it followed the prompt poorly. That's a prompt issue.
  • It's not "the model is lying." The model has no concept of truth. It generates the most probable continuation of its input. When the input doesn't contain enough grounding evidence, the model fills gaps from its weights, and its weights don't always reflect reality.

Common causes:

  • Weak or vague prompt: the model wasn't told to stick to provided evidence, so it generated freely
  • Missing or insufficient context: the answer required information that wasn't in the context window
  • Stale or conflicting context: the model had evidence, but it was outdated or contradictory (this is context rot showing up as hallucination)
  • Model limitation: the task requires knowledge or reasoning the model genuinely can't do
  • Retrieval failure: the system retrieved the wrong evidence, and the model faithfully grounded its answer in that wrong evidence. This is especially tricky because the answer looks grounded but is still wrong.

The last cause is important: retrieval doesn't "solve" hallucination. Bad retrieval can produce confident, well-cited, wrong answers. We'll revisit this in Retrieval Fundamentals, and the full engineering treatment (grounding, citation, abstention, faithfulness evaluation) will be discussed in Modules 5 and 6.

For now, the key takeaway is: when the model says something wrong, don't just say "it hallucinated." Use the diagnostic below to figure out why it said something wrong, because the fix depends on the cause.

The four-way diagnostic

When the model gives a bad answer, the cause is one of:

  1. Prompt issue: the instructions are ambiguous, incomplete, or conflicting
  2. Context issue: the model has the wrong evidence, too much evidence, or stale evidence
  3. Model limitation: the task exceeds the model's capabilities (e.g., complex math, very long reasoning chains)
  4. Evaluation issue: the answer is actually fine but your grading criteria are wrong

Learning to quickly identify which category you are in will save you from the most common debugging trap: changing the prompt when the problem is actually the context (or vice versa).

Exercises

  1. Send the same prompt at three different temperatures (0, 0.5, 1.0) and compare outputs. Note what changes and what stays the same.

  2. Count approximate token growth as you add long chat history to a request. At what point does the context window start to matter?

  3. Create three versions of the same task with:

    • No system prompt
    • A weak, vague system prompt
    • A strict, specific system prompt

    Compare outputs and write a short note explaining what changed, what stayed stochastic, and what moved from "prompt issue" to "context issue."

  4. Find one case where the model gives a wrong answer. Diagnose it using the four-way diagnostic: is it a prompt issue, context issue, model limitation, or evaluation issue? Write one sentence explaining your diagnosis.

Completion checkpoint

You can explain:

  • Why longer context is not the same as better context
  • The difference between weights (training) and context (inference)
  • Why model outputs vary and what controls the variation
  • How to tell the difference between a prompt problem and a context problem

Connecting to the project

The experiments you ran here are standalone scripts, and that's intentional. This lesson is focused on building mental models, not building a service. But everything you learned applies directly to the FastAPI project you started in lesson 1 and will extend in lesson 4:

  • When your API endpoint calls a model, you'll construct messages with system, user, and tool roles
  • When your service slows down, you'll check token counts to find the bottleneck
  • When the model returns wrong answers, you'll use the four-way diagnostic to isolate the cause
  • When we add retrieval in Module 4, context budgeting will become a daily concern

Keep the llm-experiments/ scripts around, as they'll be useful for quick tests throughout the curriculum.

What's next

Prompt Engineering. Now that the model feels mechanical instead of mystical, the next lesson shows how to shape its inputs with contracts, examples, and decomposition.

References

Start here

Build with this

Deep dive

Your Notes
GitHub Sync

Sync your lesson notes to a private GitHub Gist. If you have not entered a token yet, the sync button will open the GitHub token modal.
Glossary
API (Application Programming Interface)Foundational terms
A structured way for programs to communicate. In this context, usually an HTTP endpoint you call to interact with an LLM.
AST (Abstract Syntax Tree)Foundational terms
A tree representation of source code structure. Used by parsers like Tree-sitter to understand code as a hierarchy of functions, classes, and statements. You'll encounter this more deeply in the Code Retrieval module, but the concept appears briefly in retrieval fundamentals.
BM25 (Best Match 25)Foundational terms
A classical ranking function for keyword search. Scores documents by term frequency and inverse document frequency. Often competitive with or complementary to vector search.
ChunkingFoundational terms
Splitting a document into smaller pieces for indexing and retrieval. Chunk boundaries significantly affect retrieval quality. Split at the wrong place and your retrieval will return half a function or the end of one paragraph glued to the start of another.
Context engineeringFoundational terms
The discipline of selecting, packaging, and budgeting the information a model sees at inference time. Prompts, retrieved evidence, tool results, memory, and state are all parts of context. Context engineering is arguably the core skill of AI engineering. Bigger context windows are not a substitute for better context selection.
Context rotFoundational terms
Degradation of output quality caused by stale, noisy, or accumulated context. Symptoms include stale memory facts, conflicting retrieved evidence, bloated prompt history, and accumulated instructions that contradict each other. A form of technical debt in AI systems.
Context windowFoundational terms
The maximum number of tokens an LLM can process in a single request (input + output combined).
EmbeddingFoundational terms
A fixed-length numeric vector representing a piece of text. Used for similarity search: texts with similar meanings have nearby embeddings.
EndpointFoundational terms
A specific URL path that accepts requests and returns responses (e.g., POST /v1/chat/completions).
GGUFFoundational terms
A file format for quantized models used by llama.cpp and Ollama. When you see a model name like qwen2.5:7b-q4_K_M, the suffix indicates the quantization scheme. GGUF supports mixed quantization (different precision for different layers) and is the most common format for local inference.
HallucinationFoundational terms
When a model generates content that sounds confident but isn't supported by the evidence it was given, or fabricates details that don't exist. Not the same as "any wrong answer"; a model that misinterprets ambiguous instructions gave a bad answer but didn't hallucinate. Common causes: weak prompt, missing context, context rot, model limitation, or retrieval failure.
InferenceFoundational terms
Running a trained model to generate output from input. What happens when you call an API. Most AI engineering work is inference-time work: building systems around models, not training them. Use "inference," not "inferencing."
JSON (JavaScript Object Notation)Foundational terms
A lightweight text format for structured data. The lingua franca of API communication.
Lexical searchFoundational terms
Finding items by matching keywords or terms. Includes BM25, TF-IDF (Term Frequency–Inverse Document Frequency), and simple keyword matching. Returns exact term matches, not semantic similarity.
LLM (Large Language Model)Foundational terms
A neural network trained on large text corpora that generates text by predicting the next token. The core technology behind AI engineering; every tool, pattern, and pipeline in this curriculum runs on top of one.
MetadataFoundational terms
Structured information about a document or chunk (file path, language, author, date, symbol type). Used for filtering retrieval results.
Neural networkFoundational terms
A computing system loosely inspired by biological neurons, built from layers of mathematical functions that transform inputs into outputs. LLMs are a specific type of neural network (transformers) trained on text. You don't need to understand neural network internals to do AI engineering, but knowing the term helps when reading external resources.
Reasoning modelFoundational terms
A model optimized for complex multi-step planning, math, and logic (e.g., o3, o4-mini). Slower and more expensive but better on hard problems. Sometimes called "LRM" (large reasoning model), but "reasoning model" is the more consistent term across provider docs.
RerankingFoundational terms
A second-pass scoring step that re-orders retrieved results using a more expensive model. Improves precision after an initial broad retrieval.
SchemaFoundational terms
A formal description of the shape and types of a data structure. Used to validate inputs and outputs.
SLM (small language model)Foundational terms
A compact model (typically 1-7B parameters) that runs on consumer hardware with lower cost, latency, and better privacy (e.g., Phi, small Llama variants, Gemma). The right choice when privacy, offline operation, predictable cost, or low latency matter more than peak capability.
System promptFoundational terms
A special message that sets the model's behavior, role, and constraints for a conversation.
TemperatureFoundational terms
A parameter controlling output randomness. Lower values produce more deterministic output; higher values produce more varied output. Does not affect the model's intelligence.
TokenFoundational terms
The basic unit an LLM processes. Not a word. Tokens are sub-word fragments. "unhappiness" might be three tokens: "un", "happi", "ness". Token count determines cost and context window usage.
Top-kFoundational terms
The number of results returned from a retrieval query. "Top-5" means the five highest-scoring results.
Top-p (nucleus sampling)Foundational terms
An alternative to temperature for controlling output diversity. Selects from the smallest set of tokens whose cumulative probability exceeds p.
Vector searchFoundational terms
Finding items by proximity in embedding space (nearest neighbors). Returns "similar" results, not "exact match" results.
vLLM (virtual LLM)Foundational terms
An inference serving engine (not a model) that hosts open-weight models behind an OpenAI-compatible HTTP endpoint. Infrastructure layer, not model layer. Relevant when moving from hosted APIs to self-hosting.
WeightsFoundational terms
The learned parameters inside a model. Changed during training, fixed during inference.
Workhorse modelFoundational terms
A general-purpose LLM optimized for speed and broad capability (e.g., GPT-4o-mini, Claude Haiku, Gemini Flash). The default for most tasks. When someone says "LLM" without qualification, they usually mean this.
BaselineBenchmark and Harness terms
The first measured performance of your system on a benchmark. Everything else is compared against this. Without a baseline, you can't tell whether a change helped.
BenchmarkBenchmark and Harness terms
A fixed set of questions or tasks with known-good answers, used to measure system performance over time.
Run logBenchmark and Harness terms
A structured record (typically JSONL) of every system run: what input was given, what output was produced, what tools were called, how long it took, and what it cost. The raw data that evals, telemetry, and cost analysis are built from.
A2A (Agent-to-Agent protocol)Agent and Tool Building terms
An open protocol for peer-to-peer agent collaboration. Agents discover each other's capabilities and delegate or negotiate tasks as equals. Different from MCP (which connects agents to tools, not to other agents) and from handoffs (which transfer control within one system).
AgentAgent and Tool Building terms
A system where an LLM decides which tools to call, observes results, and iterates until a task is complete. Agent = model + tools + control loop.
Control loopAgent and Tool Building terms
The code that manages the agent's cycle: send prompt, check for tool calls, execute tools, append results, repeat or finish.
HandoffAgent and Tool Building terms
Passing control from one agent or specialist to another within an orchestrated system.
MCP (Model Context Protocol)Agent and Tool Building terms
An open protocol for exposing tools, resources, and prompts to AI applications in a standardized way. Connects agents to capabilities (tools and data), not to other agents.
Tool calling / function callingAgent and Tool Building terms
The model's ability to request execution of a specific function with structured arguments, rather than just generating text.
Context compilation / context packingCode Retrieval terms
The process of selecting and assembling the smallest useful set of evidence for a specific task. Not "dump everything retrieved into the prompt."
GroundingCode Retrieval terms
Tying model assertions to specific evidence. A grounded answer cites what it found; an ungrounded answer asserts without evidence.
Hybrid retrievalCode Retrieval terms
Combining multiple retrieval methods (e.g., vector search + keyword search + metadata filters) and merging or reranking the results.
Knowledge graphCode Retrieval terms
A data structure that stores entities and their relationships explicitly (e.g., "function A calls function B," "module X imports module Y"). Useful for traversal and dependency reasoning. One retrieval strategy among several, often overused when simpler metadata or adjacency tables would suffice.
RAG (Retrieval-Augmented Generation)Code Retrieval terms
A pattern where the model's response is grounded in retrieved external evidence rather than relying solely on its training data.
Symbol tableCode Retrieval terms
A mapping of code identifiers (functions, classes, variables) to their locations and metadata.
Tree-sitterCode Retrieval terms
An incremental parsing library that builds ASTs for source code. Used in this curriculum for code-aware chunking and symbol extraction.
Context packRAG and Grounded Answers terms
A structured bundle of evidence assembled for a specific task, with metadata about provenance, relevance, and token budget.
Evidence bundleRAG and Grounded Answers terms
A collection of retrieved items grouped for a specific sub-task, with enough metadata to evaluate whether the evidence is relevant and sufficient.
Retrieval routingRAG and Grounded Answers terms
Deciding which retrieval strategy or method to use for a given query. Different questions need different retrieval methods.
EvalObservability and Evals terms
A structured test that measures system quality. Not the same as training. Evals measure, they don't change the model.
Harness (AI harness / eval harness)Observability and Evals terms
The experiment and evaluation framework around your model or agent. It runs benchmark tasks, captures outputs, logs traces, grades results, and compares system versions. It turns ad hoc "try it and see" into repeatable, comparable experiments. Typically includes: input dataset, prompt and tool configuration, model/provider selection, execution loop, logging, grading, and artifact capture.
LLM-as-judgeObservability and Evals terms
Using a language model to evaluate or grade the output of another model or system. Useful for scaling evaluation beyond manual review, but requires rubric quality, judge consistency checks, and human spot-checking. Not a replacement for exact-match checks where they apply.
OpenTelemetry (OTel)Observability and Evals terms
An open standard for collecting and exporting telemetry data (traces, metrics, logs). Vendor-agnostic.
RAGASObservability and Evals terms
A specific eval framework for retrieval-augmented generation. Measures metrics like faithfulness, relevance, and context precision. One tool example, not a foundational concept. Learn the metrics first, then the tool.
SpanObservability and Evals terms
A single operation within a trace (e.g., one tool call, one retrieval query). Traces are made of spans.
TelemetryObservability and Evals terms
Structured data about system behavior: what happened, when, how long it took, what it cost. Includes traces, metrics, and events.
TraceObservability and Evals terms
A structured record of one complete run through the system, including all steps, tool calls, and decisions.
Long-term memoryOrchestration and Memory terms
Persistent facts that survive across conversations. Requires write policies to manage what gets stored, updated, or deleted.
OrchestrationOrchestration and Memory terms
Explicit control over how tasks are routed, delegated, and synthesized across multiple agents or specialists.
RouterOrchestration and Memory terms
A component that decides which specialist or workflow path to use for a given query.
SpecialistOrchestration and Memory terms
An agent or workflow tuned for a narrow task (e.g., "code search," "documentation lookup," "test generation"). Specialists are composed by an orchestrator.
Thread memoryOrchestration and Memory terms
Conversation state that persists within a single session or thread.
Workflow memoryOrchestration and Memory terms
Intermediate state that persists within a multi-step task but doesn't survive beyond the workflow's completion.
Catastrophic forgettingOptimization terms
When fine-tuning causes a model to lose capabilities it had before training. The model gets better at the fine-tuned task but worse at tasks it previously handled. PEFT methods like LoRA reduce this risk by freezing original weights.
DistillationOptimization terms
Training a smaller (student) model to reproduce the behavior of a larger (teacher) model on a specific task.
DPO (Direct Preference Optimization)Optimization terms
A method for preference-based model optimization that's simpler than RLHF, training the model directly on preference pairs without a separate reward model.
Fine-tuningOptimization terms
Updating a model's weights on task-specific data to change its behavior permanently. An umbrella term that includes SFT, instruction tuning, RLHF, DPO, and other techniques. See the fine-tuning landscape table in Lesson 8.3 for how these relate.
Full fine-tuningOptimization terms
Updating all of a model's parameters during training, as opposed to PEFT methods that update only a small subset. Requires significantly more GPU memory and compute. Produces the most thorough adaptation but carries higher risk of catastrophic forgetting.
Inference serverOptimization terms
Software (like vLLM or Ollama) that hosts a model and serves inference requests.
Instruction tuningOptimization terms
A specific application of SFT where the training data consists of instruction-response pairs. This is how base models become chat models: the technique is SFT, the data format is instructions. Not a separate technique from SFT.
LoRA (Low-Rank Adaptation)Optimization terms
A parameter-efficient fine-tuning method that trains small adapter matrices instead of updating all model weights. Dramatically reduces GPU memory and compute requirements.
Parameter countOptimization terms
The number of learned weights in a model, commonly expressed in billions (e.g., "7B" = 7 billion parameters). Determines memory requirements (roughly 2 bytes per parameter at FP16) and broadly correlates with capability, though training quality and architecture matter as much as size. See Model Selection and Serving for sizing guidance.
PEFT (Parameter-Efficient Fine-Tuning)Optimization terms
A family of methods (including LoRA) that fine-tune a small subset of parameters instead of the full model.
Preference optimizationOptimization terms
Training methods (RLHF, DPO) that use human or automated preference signals to improve model behavior. "This output is better than that output" rather than "this is the correct output."
QLoRA (Quantized LoRA)Optimization terms
LoRA applied to a quantized (compressed) base model. Further reduces memory requirements, enabling fine-tuning on consumer hardware.
QuantizationOptimization terms
Reducing the precision of model weights (e.g., FP16 → INT4) to shrink memory usage and increase inference speed at some quality cost. A 7B model at FP16 needs ~14 GB VRAM; quantized to 4-bit, it fits in ~4 GB. Common formats include GGUF (llama.cpp/Ollama), GPTQ and AWQ (vLLM/HuggingFace). See Model Selection and Serving for format details and tradeoffs.
OverfittingOptimization terms
When a model memorizes training examples instead of learning generalizable patterns. The model performs well on training data but poorly on new inputs. Detected by monitoring validation loss alongside training loss.
RLHF (Reinforcement Learning from Human Feedback)Optimization terms
A training method that uses human preference signals to improve model behavior through a reward model. More complex than DPO (requires training a separate reward model) but offers more control over the optimization objective.
SFT (Supervised Fine-Tuning)Optimization terms
Fine-tuning using input-output pairs where the desired output is known. The most common fine-tuning approach.
TRL (Transformer Reinforcement Learning)Optimization terms
A Hugging Face library for training language models with reinforcement learning, SFT, and other optimization methods.
Consumer chat appCross-cutting terms
The browser or desktop product meant for human conversation (ChatGPT, Claude, HuggingChat). Useful for experimentation, but not the same as API access.
Developer platformCross-cutting terms
The provider's API, billing, API-key, and developer-docs surface. This is what you need for this learning path.
Hosted APICross-cutting terms
The provider runs the model for you and you call it over HTTP.
Local inferenceCross-cutting terms
You run the model on your own machine.
ProviderCross-cutting terms
The company or service that hosts a model API you call from code.
Prompt cachingCross-cutting terms
Reusing computation from repeated prompt prefixes to reduce latency and cost on subsequent requests with the same prefix.
Rate limitingCross-cutting terms
Constraints on how many API requests you can make per unit of time. An operational concern that affects system design and cost.
Token budgetCross-cutting terms
The maximum number of tokens you allocate for a specific part of the context (e.g., "retrieval evidence gets at most 4K tokens"). A context engineering tool for preventing any single component from dominating the context window.