Every technical term in the program, in plain language. Terms are grouped by theme and ordered for reading; within each group, earlier terms build on later ones' prerequisites. Each entry ends with where the program teaches it in depth.
How to use this file: don't read it cover to cover. When a week uses a word you don't know, jump to it (your editor's search is your friend), read the one-paragraph definition, and get back to work.
Part of AI Engineering Lab · Developed by Zorost Intelligence AI Lab · zorost.com
API (Application Programming Interface): A way for one program to ask another program to do something and get an answer back, over a fixed contract. When you "call a model," your code is making an API request. Week 1; KB-01.
CLI (Command-Line Interface): A program you drive by typing commands into a terminal instead of clicking buttons. Most AI engineering tools (git, Ollama, Claude Code) are CLIs. Week 1.
Git / GitHub: Git is version control: it records every change to your files so you can undo, compare, and collaborate. GitHub is a website that hosts git repositories so others can see and copy them. This program lives on GitHub. Week 1.
IDE (Integrated Development Environment): A code editor with extras: file browser, terminal, debugger, and extensions in one window. The program uses VS Code; Cursor is an AI-native IDE. Week 1; skills/cursor.
Jupyter / notebook: An interactive document that mixes code cells, their output,
and written explanation. The program's hands-on work all happens in notebooks (.ipynb
files) so you can run one cell at a time and see what happened. Week 1.
Library / package: Pre-written code you import instead of writing from scratch.
pandas is a data library; torch is a deep-learning library. Week 1.
Python: The programming language of AI engineering, chosen for its readable syntax and unmatched ecosystem of AI/data libraries. Taught from zero in Week 1.
Repository ("repo"): A folder of code tracked by git. This program is a repository. Week 1.
SQL (Structured Query Language): The language for asking questions of tabular
databases: SELECT column FROM table WHERE condition. AI engineering runs on data,
and data still speaks SQL. Week 2; KB-02.
Terminal / shell: The text window where you type commands directly to the operating system (Terminal on macOS, PowerShell/Windows Terminal on Windows). Week 1.
Virtual environment: An isolated folder of Python packages for one project, so one project's library versions can't break another's. You make one in Week 1 and never think about it again. Week 1.
Model: A file of learned numbers (parameters) plus the code shape that uses them. Given input, it produces output: an ETA, a category, or the next token. Week 3.
Training: The process where a model's parameters are automatically adjusted to reduce its error on example data. Training is expensive; using a trained model (inference) is cheap. Week 3 to 4; KB-02.
Inference: Using a trained model to make predictions on new input. Most of AI engineering is inference-side: prompting, serving, evaluating. Week 3; KB-02.
Feature: An input variable you hand to a model: distance, carrier, day of week. Feature engineering is crafting inputs the model can actually learn from. Week 3; Week 23.
Label / target: The answer column in training data: the actual ETA, the true on-time flag. Models learn by comparing predictions to labels. Week 3.
Regression vs. classification: Regression predicts a number (ETA in hours); classification predicts a category (on-time vs. delayed). Week 3 builds one of each.
Train/test split: Holding out data the model never saw during training, to measure how it performs on new cases, the only performance that matters. Week 3.
Overfitting: When a model memorizes the training data's noise and performs worse on new data. The central failure mode of ML; the test split is how you detect it. Week 3 to 4; KB-02.
Neural network: A model made of layers of simple units that multiply inputs by learned weights and pass them through a non-linearity. Depth (many layers) lets it learn complex patterns. Week 4.
PyTorch: The dominant open-source deep-learning framework. Week 4 builds a small neural network in it so the "deep learning" in every LLM stops being magic. Week 4.
Autograd / gradient descent: The math that makes training work: compute how each parameter contributed to the error (gradients), then nudge every parameter downhill. PyTorch's autograd does the calculus for you. Week 4; KB-02.
Embedding: A dense vector of numbers representing meaning, so similar things land near each other in vector space. Used inside LLMs and, separately, to power semantic search. Week 5; KB-03.
LLM (Large Language Model): A very large neural network trained to predict the next token in text. That single capability, scaled, produces summarization, extraction, reasoning, and dialogue. Week 5; KB-03.
Token: The chunk of text a model actually reads, roughly ¾ of an English word. Costs, context limits, and speed are all measured in tokens. Week 5; KB-03.
Tokenizer: The component that cuts text into tokens and maps each to an integer ID. Different models tokenize differently, so always measure with the actual model's tokenizer. Week 5.
Transformer: The neural architecture behind every modern LLM: a stack of blocks, each mixing self-attention (tokens gathering information from each other) with a small feed-forward network. Week 5; KB-03.
Attention / self-attention: The mechanism that lets each token weigh which other tokens matter to it ("it" in a sentence attending back to its noun). The Q·K·V projection dance is explained visually in Week 5. Week 5; KB-03.
Context window: The maximum number of tokens a model can consider at once: your instructions, the conversation, retrieved documents, and the model's own output all compete for it. Managing it is context engineering. Week 6; KB-04.
KV cache: A serving optimization that stores each token's key/value vectors so the model doesn't recompute attention for the whole prompt on every generated token. Why the first token is slow and the rest stream fast. Week 5; KB-03.
Temperature: A sampling dial: low temperature makes output more predictable (pick the most likely token); high temperature makes it more varied. Extraction tasks run near zero. Week 5 to 6.
Hallucination: When a model states something false with full confidence, because its job is producing plausible text, not verified fact. The engineering answers are retrieval (give it the facts), structured output, and evals. Week 6 to 7; KB-03.
Prompt: Everything you put in front of the model: system instructions, examples, the user's request, retrieved evidence. Week 6.
System prompt: The standing instructions sent with every request: role, policy, output format, guardrails. It is a policy layer, not a security layer. Week 6; KB-04.
Few-shot prompting: Including 1 to 3 worked input→output examples in the prompt so the model copies the pattern. One good example beats three mediocre ones. Week 6.
Chain-of-thought: Asking the model to reason step by step before answering. Helps multi-step problems; costs tokens on every call. Week 6; KB-04.
Structured output: Constraining the model's answer to a schema (usually JSON) so code, not a human, can consume it. Remember: a schema constrains shape, never truth. Week 6; KB-04.
Prompt injection: An attack where instructions hidden in content the system reads (a web page, a document field) hijack the model. OWASP's #1 LLM risk; defenses live outside the prompt. Week 6; KB-04.
Prompt caching: A provider feature that reuses the processed prefix of repeated requests, cutting cost and latency when your system prompt and context are stable. Week 6; KB-04.
RAG (Retrieval-Augmented Generation): Retrieve relevant documents, put them in the context window, and ask the model to answer from them, with citations. The default cure for hallucination and stale knowledge. Week 7; KB-05.
Vector database: A database that stores embedding vectors and finds the nearest neighbors to a query vector fast. The retrieval half of RAG. Week 7; KB-05.
Chunking: Splitting documents into pieces small enough to embed and retrieve usefully. Chunk size and overlap are among the highest-leverage RAG decisions. Week 7.
Reranking: A second-pass model that re-orders the vector search's top candidates by true relevance. Cheap accuracy for RAG pipelines. Week 7; KB-05.
Knowledge graph: Data stored as entities and relationships (shipment, carried_by→ carrier), enabling multi-hop questions vector search can't answer. Week 7 builds one.
Open-weight model: A model whose parameter files you can download and run yourself (Llama, Qwen, Mistral, DeepSeek…). "Open source" in common speech, though licenses vary. Week 8; KB-06.
Foundation model: A large model trained on broad data that you adapt to tasks, by prompting, RAG, or fine-tuning, rather than training from scratch. Week 8; KB-06.
Ollama / llama.cpp / MLX: The three local-inference stacks the program uses: Ollama for convenience, llama.cpp for control and GGUF, MLX for Apple Silicon. Week 8; skills/ollama-llamacpp; KB-08.
GGUF: The file format llama.cpp uses for quantized models, one file you can download and run anywhere. Week 8 to 9.
Quantization: Storing model weights at lower precision (16-bit → 8/6/5/4-bit) to shrink memory and speed up inference, at a small quality cost. Q4_K_M is the classic sweet spot. Week 9; KB-06.
VRAM: GPU memory. The hard wall for local models: the model's weights, the KV cache, and the runtime must all fit. Week 8 to 9 teach you to size it before downloading.
vLLM: A high-throughput open-source serving engine for LLMs (paged attention, continuous batching). What you graduate to when one user becomes fifty. Week 9; KB-08.
Fine-tuning: Continuing a model's training on your data to change its behavior: tone, format, domain vocabulary. Week 10; KB-06.
SFT (Supervised Fine-Tuning): Fine-tuning on input→ideal-output examples. The first rung of behavior change. Week 10.
LoRA (Low-Rank Adaptation): Fine-tuning a small set of added matrices instead of all parameters: cheap, fast, and the resulting "adapter" file is tiny. Week 10; KB-06.
DPO (Direct Preference Optimization): Training on pairs of "better vs. worse" answers to align behavior with preferences, without a separate reward model. Week 10.
Distillation: Training a small model to imitate a big model's outputs, trading capability for speed and cost. KB-06.
Eval (evaluation): A repeatable measurement of a model or system's quality on a fixed set of cases, producing a score. The discipline that separates AI engineers from demo builders. Week 11; KB-07.
Golden set: The curated set of inputs with known-good answers that an eval scores against. Fix the golden set before touching the prompt. Week 6, 11.
LLM-as-judge: Using a strong model to grade another system's outputs against a rubric, when correctness is fuzzy (summaries, answers). Cheap and scalable, but must be calibrated against human grades. Week 11; KB-07.
Error analysis: Reading real failures by hand, clustering them into categories, and fixing the largest category first. The highest-ROI habit in the program. Week 11; KB-07.
Harness (coding-agent harness): The software wrapper that lets an LLM act on your computer: read files, run commands, edit code, with permissions, rules files, and context management around it. Claude Code, Cursor, OpenCode, and the DeepSeek Harness are the four the program compares. Week 12; KB-09; reference/skills
Rules file: The persistent instruction file a harness reads every session
(CLAUDE.md, AGENTS.md, .cursor/rules): project conventions, commands, and
boundaries. Week 12; reference/skills
Subagent: A spawned helper agent with its own context window, given a narrow job (research, review) so the main agent's window stays clean. Week 12; KB-09.
Verifier: Anything that checks the agent's work automatically: tests, linters, type checks, evals. Closing the loop means the agent runs its verifier itself. Week 13.
Spec-driven development: Writing the specification first and steering the agent to it, so quality is judged against an explicit contract instead of vibes. Week 13; KB-01.
Agent: A model in a loop with tools: observe → think → act → observe…, until done or stopped. Agents handle tasks where the steps aren't known in advance. Week 14; KB-10.
ReAct: The foundational agent pattern: interleave reasoning ("what should I do next?") with actions (tool calls) in one loop. Week 14 builds one from scratch.
Tool (function calling): A function the model can ask the harness to run:
track_shipment(id). The model emits structured intent; your code executes it and
returns the result. Week 14; KB-10.
Guardrails: The hard limits around an agent: max steps, cost caps, refusal rules, human approval for irreversible actions. Week 14; KB-10.
Trace / observability: A recorded log of every step an agent took, prompts, tool calls, outputs, costs, so failures are debuggable and evaluable. Week 17; KB-07, KB-10.
LangGraph: A framework that models agents as explicit state graphs: nodes (steps), edges (transitions), checkpoints (resumability). Week 15; KB-10.
Multi-agent system: Splitting work across specialized agents (router, tracker, refunds) coordinated by an orchestrator. A measured trade, not a default. Week 16; KB-10.
MCP (Model Context Protocol): An open standard for exposing tools and data to AI agents: one server, many compatible clients. Week 16 builds an MCP server for ZoroLogistics. Week 16; KB-11.
A2A (Agent-to-Agent): Google's protocol for agents delegating tasks to other agents across boundaries; complements MCP's agent-to-tools focus. KB-11.
OpenClaw: An open-source personal-agent framework the program uses in Week 17 to run a 24/7 assistant wired into the Week-16 MCP server. Week 17; agents/openclaw.
Router / OpenRouter: A service that fronts hundreds of models behind one API key,
so you can swap models, compare cost/quality, and use :free variants. Week 12;
skills/openrouter.
Azure AI Foundry: Microsoft's platform for building, evaluating, and deploying AI apps and agents, with a model catalog and enterprise governance. Week 18; KB-12.
Google Vertex AI: Google Cloud's ML/GenAI platform: Gemini models, Agent Builder, evaluation services, and MLOps. Week 19; KB-12.
AWS Bedrock: Amazon's managed service offering foundation models (Claude, Llama, Nova…) via one API, plus Knowledge Bases, Agents, and Guardrails. Week 20; KB-12.
Serverless endpoint: Model hosting where you pay per request and never manage servers; the opposite of provisioning a GPU instance yourself. Week 18 to 20.
Lakehouse: A data platform combining a data lake's cheap open storage with a data warehouse's reliability and SQL performance. Databricks' core idea. Week 21; KB-13.
Delta Lake: The open storage layer (tables on object storage with ACID transactions, time travel, schema enforcement) under the lakehouse. Week 21.
Unity Catalog: Databricks' governance layer: one place for data, model, and permission management with lineage. Week 21; platforms/databricks/01.
Medallion architecture: Organizing data in bronze (raw) → silver (cleaned) → gold (business-ready) tables. Week 21 to 22.
PySpark: The Python API for Apache Spark, the distributed compute engine that processes data across a cluster. Week 22.
Lakeflow (DLT & Jobs): Databricks' declarative pipeline and orchestration tooling: declare the tables; it handles dependencies, retries, and monitoring. Week 22.
MLflow: The open-source experiment-tracking and model-registry system: every training run logged with parameters, metrics, and artifacts. Week 23.
Feature store: A governed home for computed features so training and serving use identical definitions. Week 23.
Model serving: Putting a model behind an endpoint that applications call. Databricks Model Serving, Foundry endpoints, and Vertex endpoints are the managed versions. Week 23; KB-12.
Vector Search / AI Search: Databricks' managed vector database for RAG, governed by Unity Catalog. Week 23.
Genie: Databricks' natural-language interface over governed data: ask in English, get a governed SQL answer. Week 23.
Agent Bricks: Databricks' tooling for building and evaluating agents on platform data. Week 23 to 24.
DABs (Databricks Asset Bundles): Infrastructure-as-code for Databricks: the whole project, jobs, pipelines, endpoints, declared in YAML and deployed with one command. Week 24.
CI/CD (Continuous Integration / Continuous Deployment): Automatically testing and deploying code on every change, so production is never a manual leap of faith. Week 24.
FinOps: The discipline of measuring and controlling cloud/AI spend: budgets, alerts, cost-per-query dashboards. Week 24; platforms/databricks/17.
Governance: The controls that make data and AI usable safely at scale: permissions, lineage, audit, quality rules. The thread that runs through Week 21 to 24.
Missing a term? That's a bug, open an issue or add it (see
.github/CONTRIBUTING.md).
© 2026 Zorost Intelligence LLC · zorost.com