01 — LLM Fundamentals (from zero)¶

The JD literally lists these as required: "tokenization, temperature and sampling, context windows, grounding, hallucination mechanics, and fine-tuning." This file teaches each one assuming no prior knowledge, then gives you the QA angle — because in the interview, the follow-up is always "…and how does that affect your testing?"

0. What an LLM actually is (the one-minute version)¶

A Large Language Model (LLM) like GPT-4, Gemini, or Claude is, at its core, a next-token predictor. You give it text; it predicts the most likely next chunk of text, one chunk at a time, feeding each guess back in to produce the next one. That's it. Everything else — answering questions, writing code, "reasoning" — comes from doing that one trick really well after training on a huge amount of text.

Remember: it's autocomplete on steroids. It guesses the next bit of text, again and again.

Two consequences that matter for a tester: - It is probabilistic, not a database lookup. The same prompt can yield different outputs. This is the reason classic assert actual == expected testing breaks. - It has no built-in notion of truth. It predicts plausible text, not correct text. That's the root of hallucination.

1. Tokenization¶

What it is. Models don't see words or characters — they see tokens, which are sub-word chunks. "Testing" might be one token; "Tokenization" might split into Token + ization. A rough rule of thumb for English: 1 token ≈ 4 characters ≈ ¾ of a word.

Why it exists. A fixed vocabulary of ~50k–200k tokens lets the model represent any text (including typos and new words) by combining pieces.

Why a tester cares: - Cost & limits are billed/measured in tokens, not words. Your eval harness budgets must be token-aware. - Truncation happens at token boundaries. If a prompt + context exceeds the limit, content gets silently cut — a real failure mode to test for. - Multilingual inflation. This role is bilingual (English/French). Non-English text often uses more tokens per word, so French prompts can hit context limits or cost more sooner. A great point to raise: "I'd test that our French test cases don't get truncated differently than English ones." - Glitch tokens. Rare tokens can cause weird/unstable behavior (garak has a glitch probe for this).

2. Temperature and sampling (top-p, top-k)¶

When the model has predicted the probability of every possible next token, sampling decides which one to actually pick. Three knobs:

Temperature (typically 0.0–2.0). Controls randomness.
Low (→0): always pick the highest-probability token → deterministic, focused, repetitive. Use for factual/extraction tasks.
High (→1+): evens out the odds so less-likely tokens get a chance → creative, diverse, riskier.
In plain words: low temperature makes the model "play it safe" and pick its top choice; high temperature lets it take chances.

Remember: low temperature = boring but repeatable; high temperature = creative but unpredictable. - top-p (nucleus sampling): only consider the smallest set of tokens whose probabilities add up to p (e.g., 0.9), then sample among those. Cuts off the long tail of unlikely tokens. - top-k: only consider the k most likely tokens. top_k=1 = greedy = always the top token.

Why a tester cares (this is a frequent question): - Set temperature=0 for reproducibility when you want a test to give the same answer each run. - BUT temperature=0 is not truly deterministic. Answers can still vary because of how computers round tiny numbers (floating-point math isn't perfectly consistent), your request getting bundled (batched) with other people's on the server, and the provider swapping the backend hardware/model (this is why OpenAI exposes a system_fingerprint so you can tell when it changed). Saying this in an interview is a strong signal you've actually done this work. - Test at production temperature too. If the app ships at temp=0.7, testing only at temp=0 doesn't reflect real behavior. Strategy: run the same prompt N times and assert on a pass rate (e.g., "≥9/10 must be faithful"), not a single output.

3. Context window¶

What it is. The context window is the maximum amount of text (measured in tokens) the model can "see" at once — it includes the system prompt, the conversation history, any retrieved documents (RAG), and the space reserved for the answer. Modern models range from a few thousand tokens to ~1 million (Gemini 2.5).

Failure modes to test for (this is gold in an interview): - Overflow / truncation. Exceed the window and content is dropped — usually the oldest messages or the middle of a long document. Test: does the app degrade gracefully or silently lose information? - "Lost in the middle." Models reliably use info at the start and end of a long context but often miss facts buried in the middle. Test: place a needed fact in the middle of a long document and check if the answer still finds it ("needle in a haystack" test). - Cost/latency scale with context length. Bigger context = slower, pricier. Relevant to performance testing of AI features.

4. Grounding (and how it relates to RAG)¶

Grounding means tying the model's output to a trusted, provided source of truth rather than letting it answer from its trained-in memory (which may be outdated or wrong). The dominant grounding technique is RAG (Retrieval-Augmented Generation): fetch relevant documents and put them into the prompt, then instruct the model to answer using only that context.

Ungrounded: "What's our refund policy?" → model guesses from training data → may hallucinate.
Grounded (RAG): retrieve the actual policy doc → "Answer using only the text below: " → answer is checkable against the source.

Why a tester cares: grounding is testable. You can measure faithfulness (does the answer stick to the provided source?) and context recall (did retrieval actually fetch the needed source?). Grounding is the main defense against hallucination — so testing grounding is testing hallucination risk. (Full RAG detail in 02.)

5. Hallucination mechanics¶

What it is. A hallucination is output that is fluent and confident but factually wrong or unsupported by any source. (OWASP calls the broader risk "Misinformation," LLM09.)

Why it happens (be able to explain the mechanism, not just the symptom): - The model optimizes for plausible next tokens, not truth. If the most plausible-sounding continuation is false, it'll say it anyway. - Gaps in training data — for niche or recent facts, the model fills the blank with something that "fits the pattern" (it makes up a plausible answer). - No uncertainty signal by default — it doesn't natively say "I don't know"; it produces something. - Snowballing — once it states a wrong fact, it tends to stay consistent with that mistake (garak's snowball probe tests this).

How you systematically test for it (the expected answer): 1. Faithfulness / groundedness metrics — break the answer into individual claims (small standalone statements) and check each one against the provided source. Score = supported claims ÷ total claims. 2. Reference-based factual checks — compare against known-correct golden answers (factual correctness, answer accuracy). 3. Adversarial probes — questions with no answer in the source (does it admit "I don't know" or invent one?), questions with false premises (does it correct them or play along?). 4. Numerical accuracy tests — the JD calls this out specifically: math, dates, quantities the model tends to get subtly wrong. 5. Retrieval-augmentation as a fix — and then test that the grounding actually holds.

6. Fine-tuning vs RAG vs prompt engineering (when to use which)¶

Teams will ask you to advise them, so know the trade-offs:

Approach	What it does	Best for	Testing implication
Prompt engineering	Carefully word the instruction / give examples (few-shot)	Quick behavior changes, formatting, tone	Cheapest to test; test prompt robustness to phrasing changes
RAG (grounding)	Inject external, current knowledge at query time	Fresh/proprietary facts, citations, reducing hallucination	Test retrieval quality and faithfulness separately
Fine-tuning	Further-train the model's weights on your data	Teaching a style/skill/format consistently; narrow domains	Most expensive; needs regression eval before/after each tune; risk of catastrophic forgetting

Rule of thumb to say: "RAG for knowledge, fine-tuning for behavior/skill, prompt engineering first because it's cheapest. If the problem is 'it doesn't know X,' that's RAG. If it's 'it doesn't behave like X,' that's fine-tuning."

7. The three message roles (you'll use these in red-teaming)¶

A chat LLM prompt is structured into roles: - System prompt — the hidden, developer-set instructions ("You are a Bell support agent. Never reveal internal pricing."). Defines behavior and guardrails. - User — the end-user's message. - Assistant — the model's replies (prior turns are fed back as history).

Why a tester/red-teamer cares: - System prompt leakage (OWASP LLM07) — attackers try to trick the model into revealing the system prompt. Test for it. - Prompt injection exploits the fact that the model can't reliably tell trusted system instructions apart from untrusted user/retrieved text — they're all just tokens in the same window. (See 03.) - Prefix injection / refusal suppression jailbreaks manipulate the assistant's opening tokens.

Quick self-check (answer these out loud)¶

A test passes at temperature=0 but the dev says it's flaky in prod at temp=0.8. What's your strategy? (Run N times, assert on pass rate; test at prod temp; use semantic/rubric checks not exact match.)
Why might the same prompt give different answers even at temperature=0? (Floating-point non-associativity, server-side batching, backend changes.)
The app answers a question correctly but the fact wasn't in the retrieved context. Is that a pass? (No — it's an ungrounded answer / lucky hallucination; faithfulness should flag it.)
Your French test cases behave differently from English. Name two token-level reasons. (More tokens per word → earlier truncation / higher cost; different tokenization boundaries.)
A team says "our bot doesn't know our 2026 pricing." RAG or fine-tuning? (RAG — it's a knowledge gap, not a behavior gap.)

→ Next: 02 — Evaluation, LLM-as-Judge & RAG