Skip to lesson content

BUILD / UNDERSTAND / VERIFY · LESSON 01 OF 20

Your GenAI engineering roadmap: build something worth using

A support assistant gives a beautiful answer about returns. Unfortunately, it quotes last year's policy. That small failure explains why GenAI engineering involves much more than choosing a model. You need a reliable path from a person's question to the right evidence, a useful answer, and a safe next action. Over these twenty lessons, you will design that path for a fictional company called Northstar Supplies.

3 min reading20–40 min suggested practiceStart here · no prerequisites

What you will learn

  • Separate model capabilities from application responsibilities.
  • Plan one project that grows through the whole series.
  • Define evidence of success before choosing tools.
From question to dependable answer
  1. 01QuestionA specific user need
  2. 02ApplicationIdentity, rules and orchestration
  3. 03Evidence + modelRetrieve, then compose
  4. 04Checked answerSources, limits and next steps

Start with a question someone actually asks

Our project is a support knowledge assistant. Northstar sells office supplies and has three short policy documents: returns, delivery, and damaged items. Customers need plain answers and links to the relevant policy. Staff also need to look up an order after signing in. The assistant must never invent a refund, reveal another customer's order, or pretend it completed an action that failed.

Write those boundaries on the first page of your project notebook. They are more useful than a list of fashionable libraries. A successful first version answers a small set of policy questions correctly and admits when the documents do not cover a question. Sending refunds belongs outside this first version.

Understand the pieces you are assembling

The user interface collects a question. Your application checks identity and limits, retrieves permitted information, builds the model request, and validates the result. The language model produces candidate text or requests a tool. A database stores documents and application state. Monitoring tells you which part failed.

These responsibilities remain separate even if a framework wraps them in one convenient function. A model does not become an authorization service because you tell it to respect privacy. Likewise, a vector database cannot decide whether a paragraph actually supports an answer. You will implement those checks around the model.

Follow the sequence, then revisit it

Lessons 2–6 establish the vocabulary: Python, learning, transformers, and language models. Lessons 7–10 turn that knowledge into prompts, API contracts, embeddings, and retrieval. Lessons 11–13 build and measure a grounded assistant. Lessons 14–18 add bounded agents, tools, memory, security, and an informed decision about fine-tuning. Lessons 19–20 assemble a release plan and a portfolio demonstration.

Security and evaluation appear later as dedicated lessons, but begin their checklists now. Every new feature should add at least one ordinary example and one failure case to your notebook. Read in order on the first pass; afterward, use the course directory to revisit the layer that needs work.

Choose a modest first stack

Use Python for the exercises, JSON files for the first documents, and a command-line interface before building a web screen. Start retrieval with a transparent local baseline; add vector search when you can explain what it improves. Hosted model access is optional for the early exercises and requires your own account for the API lesson. A local model is another option, with its own hardware and operational requirements.

Your first deliverable is a design brief, not a cloud deployment. Record the intended users, approved documents, excluded actions, sample questions, and how you will recognize an unsupported answer. Keep model names and prices out of the architecture itself so that providers can change without rewriting the product.

PUT IT TO WORK

Your practice task

Create a one-page Northstar project brief. Include five answerable questions, two questions absent from the documents, and one attempt to read somebody else's order. For each, write the expected behavior. Choose one measurable target for answer quality and one for response time; label both as project targets, not industry benchmarks.

Checkpoint: compare your reasoning

A useful brief distinguishes “What is the return window?” from “Has my refund arrived?” The first needs policy evidence; the second needs authenticated account data. If your design uses the same unrestricted document search for both, revise the boundary before coding.

References and further reading

Use these primary references for deeper study and current API details. Examples in this lesson use fictional Northstar data.