AI Foundations + Shared Vocabulary

Where we are going today

Day 1 builds the shared vocabulary every later day depends on. By lunch you can name the moving parts of a modern AI system; by the end of the lab you have stood up a local model and built a working RAG pipeline on your own machine. Everything runs locally on CPU with Ollama — no data leaves the laptop, which is also the security posture we care about all week.

Types of AI, and where LLMs sit

“AI” is an umbrella. It helps to place today’s tools on the map:

• Rule-based / symbolic AI — explicit human-written logic. Deterministic, auditable, brittle.
• Classical machine learning — models that learn patterns from labeled data (spam filters, fraud scoring).
• Deep learning — neural networks with many layers; the basis for modern language and vision models.
• Generative AI — models that produce new content (text, code, images). Large language models are the generative-text branch and the focus of this course.

A useful cut for security work is discriminative vs. generative: a discriminative model answers “which class is this?” (the DeBERTa prompt-injection classifier you meet on Day 2), while a generative model answers “what comes next?” (the LLM itself).

LLM vs. SLM

Same idea, different scale. Large language models (frontier, hundreds of billions of parameters) reason and recall broadly but need serious hardware. Small language models (1-3B parameters, like qwen2.5:1.5b) fit in laptop RAM and run on CPU — perfect for a classroom — at the cost of some capability. Choosing the smallest model that reliably does the job is a recurring theme (it returns on Day 4, where tool-calling forces us up to a 3B model).

How a language model actually works

Modern LLMs are transformers. Three ideas are enough to reason about them securely:

Every token can weigh every other token

• Tokens — text is chopped into sub-word tokens; the model reads and writes tokens, not characters. The context window is the maximum number of tokens it can attend to at once.
• Embeddings — every token (and, separately, every chunk of a document) is mapped to a vector of numbers that captures meaning. Similar meanings sit close together in vector space. This is what makes RAG’s similarity search possible.
• Attention + autoregressive generation — the transformer’s self-attention lets each token weigh every other token in context; the model then generates one token at a time, feeding its own output back in. That autoregressive loop is why prompt content — including injected content — so strongly steers the output.

Prompt engineering

Prompting is how you program these models without training them.

• Zero-shot — an instruction with no examples (“Classify this ticket’s urgency”).
• One-shot / multi-shot (few-shot) — include one or several labeled examples; output format and accuracy improve markedly.
• Chain-of-thought — ask the model to reason step by step before answering; helps on multi-step problems.
• System vs. user roles — the system message sets durable behavior and guardrails; the user message carries the request. Placing instructions in the system role is stronger, but — as the lab demonstrates — it is not an airtight boundary a determined user cannot cross.

The Day 1 lab’s three experiments (shot prompting, role placement, chain-of-thought) let you feel each of these effects on the same local model.

RAG and vector stores

Retrieval-Augmented Generation grounds a model in your documents:

Ingest-time path vs. query-time path

1. Ingest — split documents into chunks.
2. Embed — turn each chunk into a vector with an embedding model (nomic-embed-text in the lab).
3. Store — keep the vectors in a vector database (Chroma) with a similarity index.
4. Retrieve — embed the user’s query, fetch the most similar chunks.
5. Generate — inject those chunks into the prompt so the model answers from real context.

RAG adds knowledge and cuts hallucination without retraining, which is why it is the default way to put private or fresh data in front of a model. Its weak point is retrieval quality: if the wrong chunk (or a poisoned one) is fetched, the model faithfully uses it — a preview of the Day 2 discussion on vector and embedding weaknesses.

The AI lifecycle and human-in-the-loop

An AI system is more than a model call. Data is collected and curated, a model is selected or trained, the system is evaluated, deployed, monitored, and eventually retired. Security and governance attach at every stage (we formalize this with NIST AI RMF on Day 3).

A closed lifecycle with a human approval gate

Human-in-the-loop means a person reviews or approves consequential outputs before they take effect. For AI-assisted security work this is non-negotiable: a generated detection rule, a CVE triage recommendation, or a redaction decision is a draft for a human to confirm — a principle you will apply directly in the Day 4 SecOps lab.

Shared vocabulary: AI meets security

Watch for terms that mean different things in each field — “model,” “inference,” “poisoning,” “signature,” “agent.” Building a common glossary now prevents miscommunication when we start threat-modeling AI systems tomorrow.