Foundation / Module 05

Understand the application wrapped around the LLM

Follow a request through instructions, retrieval, tools, memory, output parsing, and the final business action.

50 minutes Beginner Practical lab
01

Tokens, attention, and embeddings are building blocks

Language models process tokens rather than whole ideas. Transformer attention lets each token weigh relationships to other tokens in the available context, while positional information preserves order. Training adjusts many parameters so the model becomes better at predicting likely continuations.

Embeddings represent text or other content as vectors for similarity search. They are useful for retrieval and clustering, but a nearby vector is not proof that two items are equivalent, authorized, current, or true. Context length controls how much material can be supplied; it does not decide which material is trustworthy.

  • Tokenization affects cost, truncation, and how unusual strings are represented.
  • Attention describes learned relationships, not a human-readable chain of justification.
  • Embeddings support similarity search but can reproduce bias and stale context.
  • Fine-tuning changes model behavior; retrieval changes the supplied evidence.
  • Model version and configuration belong in every evaluation record.
02

The model predicts; the application decides

A language model receives tokens and predicts a useful continuation. The application decides which instructions, retrieved documents, conversation history, tool descriptions, and user content enter the context. It also decides whether model output is displayed, parsed, executed, or sent elsewhere.

That wrapper creates most of the controllable security surface: authorization, input provenance, output validation, tool permissions, rate limits, logging, and human approval.

03

Retrieval changes the trust problem

Retrieval-augmented generation can ground answers in selected sources, but it also imports untrusted content into a privileged instruction-processing environment. A poisoned document, misleading metadata, or over-broad search result can steer the model.

Treat retrieved text as data, attach provenance, enforce document-level authorization before retrieval, and keep citations connected to the exact source passages used.

  • Embedding similarity is not truth or authorization.
  • Chunking can remove qualifying context.
  • Index freshness can create silent stale answers.
  • Retrieved instructions should not outrank developer policy.
  • A citation is useful only when the linked passage supports the claim.
04

Tools turn language into consequences

Tool calling moves risk from an incorrect sentence to a real action. Every tool needs a narrow schema, server-side authorization, explicit side-effect classification, bounded input, timeout, logging, and a safe failure mode.

Do not give the model a generic shell, database administrator role, or broad browser session because it is convenient. Build task-specific tools that expose only the action and data needed.

A system prompt describes a boundary. Identity, authorization, and tool design enforce it.

Practice

Trace one request end to end

Safety boundary: Use a fictional HR policy assistant with read-only documents.

  1. 01

    Write a sample user request and the system policy that applies.

  2. 02

    List the retrieved documents and the authorization decision before retrieval.

  3. 03

    Describe the model context in source order.

  4. 04

    Define the expected structured output and validation rules.

  5. 05

    Mark where logging, refusal, citation, and human review occur.

Checkpoint

Ready to move on?

Go deeper

Primary sources for this module

All resources
Previous module04 · Measure the security decision, not just model accuracy Next module06 · Threat-model AI across data, model, application, and action
Share this module LinkedIn Email Permanent link