← All modules
03Intermediate

Build with LLMs

Ship production-ready code: RAG pipelines, API integrations, autonomous agents.

The demo is the easy part, and that is the trap. A weekend gets you a chatbot over your PDFs that impresses everyone in the room; six months later it is still not in production, because the demo never had to answer a question the documents do not cover, or handle a provider outage, or explain a bill. This module is about the other ninety percent. We build like the thing has to run without you watching it. That means treating the model as an unreliable network call with a variable price, not as a magic function — it will time out, it will refuse, it will return something that violates the schema you asked for, and your code decides what happens next. It means accepting that most RAG failures are retrieval failures: the model was never given the answer, so no prompt could have saved it. It means agents that are boring on purpose, with a hard step limit and a spending cap, because an autonomous loop with a budget is a product and one without is an incident. And it means fine-tuning last, after you have proven with evidence that prompting and retrieval genuinely cannot get you there — because most teams reach for it first and pay for months to learn what a test set would have told them in a day.

LevelIntermediate
Duration8 weeks
Sessions5
Price1,800 DH

Prerequisites

  • Comfortable writing Python — this module is for engineers
  • You have called a REST API and handled its errors before
  • Git, the command line, and deploying something once before
  • Module 02 or equivalent hands-on prompting experience

What you can do afterwards

  • Integrate hosted and open-source model APIs behind one interface you can swap
  • Handle timeouts, rate limits, refusals and schema violations without waking up at 3am
  • Build a RAG pipeline and debug it at the retrieval layer, where the bug usually is
  • Ship an agent with tool-use, a step limit and a spending cap you actually enforce
  • Decide with evidence whether fine-tuning is warranted — and usually conclude it is not
  • Run a cost, latency and quality budget for an AI feature in production

Sessions

Model APIs and the provider layer

You will integrate hosted providers and open-source models behind a single interface you control, because being locked to one vendor is a decision you should make on purpose, not discover during an outage. Every call is an unreliable network call with a variable price — so we build the retry, the timeout, the fallback and the cost meter on day one, not after the first incident.

Covered

One interface, several providersStreaming and why it changes your UXRetries, timeouts, rate limits and backoffHandling refusals and schema violations in codeCost accounting per requestSelf-hosted open weights vs a hosted API

RAG pipelines that survive real documents

Real documents are scanned, badly formatted, half in French and half in Arabic, and full of tables that chunking destroys. Building the pipeline takes an afternoon; making it retrieve the right passage takes the rest of the module. The key habit you leave with: when the answer is wrong, look at what was retrieved before you touch the prompt.

Covered

Embeddings and vector stores, minus the hypeChunking strategies and where they destroy meaningHybrid search: why pure vector search missesReranking and the recall/precision tradeGrounding, citations and refusing to answerRetrieval in Arabic and French documents

Agents and tool-use

An agent is a loop that decides which function to call next, and that is both the whole idea and the whole danger. You will give a model real tools, then spend most of your effort on the boring scaffolding: step limits, spend caps, idempotency and a human gate in front of anything destructive. An unbounded loop with your API keys is not autonomy, it is an incident with a countdown.

Covered

Tool definitions and why the description is the promptThe plan-act-observe loopStep limits and spending caps you enforce in codeIdempotency and safe retries on side effectsHuman approval before destructive actionsWhen a plain workflow beats an agent

Fine-tuning and model customisation

Fine-tuning is the most requested and least justified thing on this list. It teaches a model a form, not a fact — so if your problem is missing knowledge, retrieval is the answer and fine-tuning will produce a model that is confidently wrong in your house style. You will do it properly once, and mostly learn to recognise the cases where it is the wrong tool.

Covered

Prompting vs retrieval vs fine-tuning: the decisionForm vs knowledge — what tuning can and cannot teachDataset construction and why it is the whole jobParameter-efficient tuning on modest hardwareEvaluating a tuned model against the base honestlyThe maintenance cost nobody budgets for

Shipping, evaluation and living with it

The feature is not done when it works; it is done when someone can be woken up for it and know what to do. You will build the offline eval that gates a deploy, the tracing that lets you replay a bad answer months later, and the guardrails that stop a form field from rewriting your system prompt. This is the difference between a portfolio piece and a product.

Covered

Offline evals as a deployment gateTracing and replaying a single bad answerCaching: where it saves money and where it liesPrompt injection and output sanitisationCost, latency and quality as one budgetOn-call for a non-deterministic system
What you leave with

Ship a production-ready AI product: a deployed application combining retrieval and at least one tool-using agent, with an offline eval suite gating deploys, a documented cost and latency budget, tracing on every call, and an honest write-up of the failure modes you chose to live with.

Offered in

Questions

Why does this module say "engineers only"? Can a strong no-code builder follow it?

Honestly, no — and we would rather say it than take your money. This module is eight weeks of writing Python, reading stack traces and deploying services; the value is in the parts a no-code platform hides from you, which are exactly the parts that break in production. If your goal is to automate work rather than build software, the automation module is a better fit and you will finish it with something running. If your goal is to build the product itself, this is the one.

Should I fine-tune a model on my company data?

Almost certainly not, and this module will show you why with numbers rather than opinion. Fine-tuning teaches a model form — a tone, a format, a way of answering — not facts. If you want it to know your policies or your catalogue, that is retrieval: cheaper, updatable the moment the document changes, and able to cite its source. Teams tend to reach for fine-tuning first because it sounds serious, then spend months discovering that a good prompt and a working retrieval layer had already solved it. We do cover it properly, and you will do it once — mostly so you can tell when it is genuinely the answer.

My RAG chatbot works on my test PDFs but falls apart on real documents. What is this module going to change?

It will change where you look. Almost everyone in your position is tuning the prompt when the actual problem is upstream: the right passage was never retrieved, so the model was asked to answer from nothing and did what it always does — invented something plausible. Real documents are scanned, mixed-language, table-heavy and chunk badly, and pure vector search quietly misses exact terms like a reference number. You will learn to inspect what was retrieved before touching anything else, to combine keyword and vector search, to rerank, and to make the system say it does not know instead of guessing. That last one is usually what makes it deployable.

Other modules