Why teachers need to understand LLMs, not just use them

Short answer: you do not need to be able to repair an engine to drive a car, but you do need to know which warning light means pull over now. This course teaches you the AI dashboard.

It starts with a circular that was wrong

At the end of last term a discipline master used AI to draft a letter to parents. The prose was fluent, the formatting tidy, the register professional, and he very nearly sent it as it stood. On a final read he caught two problems: the school's founding year was twelve years too early, and the letter cited an Education Bureau guideline reference number that does not exist. Both errors were stated with complete confidence, with no hint of hedging anywhere.

Afterwards he asked a very good question: "It uses punctuation better than I do. How can it be so badly wrong on exactly the things that matter?"

Being able to answer that question is half of this course. And the answer is not that the AI is not clever enough. It is that the AI is not doing the thing you assume it is doing.

Knowing how to use it, and knowing how to judge it

Most teacher training stops at the first: which prompt to type, which button to press, how to paste the output back into Word. That is useful, but it is not enough, because professional judgement needs a second layer.

Picture a newly arrived student teacher. He reads widely, writes well and is extremely eager, but he has three traits. He will never say "I don't know". He knows nothing about your school. And the last time he read a newspaper was several months ago. Once you know those three things you naturally work out how to use him: draft a worksheet, yes; verify student records on his own, no; tidy up the minutes, yes, but you will read them yourself before they go out.

Knowing how to judge means understanding where those three traits come from. They are not defects to be patched. They follow directly from the way the technology works.

An example from the classroom

A Secondary 3 English teacher had forty argumentative essays to mark in a fortnight, and also had to prepare a writing performance analysis for her panel head. She pasted each essay in and asked for a mark on Content, Language and Organisation, plus comments.

The result was instructive. The comments were genuinely good, especially on grammar and loose paragraph structure, and considerably more patient than she is at eleven at night. But three essays came back clearly over-marked, and those three had something in common: they were long and used showy vocabulary while saying very little. Separately, when she asked the AI to tabulate "the three most common grammatical errors in the class", the percentages looked precise, but a spot check showed they had been estimated rather than counted.

Her final workflow was to keep the AI comments as a first draft, set the marks herself, and do the statistics in Excel. That is exactly the right judgement, and she reached it because she had a rough sense of what the AI was actually doing: imitating what a good comment looks like, rather than assessing whether an argument holds up.

Why does that happen? The lesson on alignment explains that models are trained to produce answers human raters prefer, and human raters tend to like writing that looks rich. Why the statistics were wrong is handled in detail in the lesson on hallucination.

What this course covers

The course runs across seven modules, from the inside of a model to what is coming next.

Module 1 (lessons 1 to 5): how a model works inside. Starting with the Transformer architecture in plain language, then tokenisation and why Chinese costs more, what parameters actually store, and embeddings, positional encoding and self-attention.

Module 2 (lessons 6 to 10): how a model is made. Pre-training and data cleaning, fine-tuning and instruction following, alignment with RLHF and DPO, where hallucination and bias come from, and knowledge cutoffs and model versioning.

Module 3: ecosystem and getting models. Hugging Face, the GitHub of AI, model cards and model file formats, and small language models.

Module 4: core application concepts. Prompt engineering, knowledge bases and RAG, chunking and reranking, context caching and cost control, agents, tool calling and MCP, and development frameworks.

Module 5: local deployment and efficient fine-tuning. LoRA and QLoRA, quantisation, Ollama and LM Studio, and on-device AI and privacy.

Module 6: safety, evaluation and hard limits. AI guardrails, prompt injection defence, privacy, bias and copyright ethics, and evaluation and leaderboards.

Module 7: what comes next. Multimodality, reasoning models and embodied AI.

If you only have an hour, read lessons 1, 3, 9 and 10, then jump to knowledge bases and RAG. Those five cover most of what comes up in a staffroom.

Try it yourself first

Open any AI tool and paste the following, substituting your own school's name. The demonstration is worth more than another paragraph of explanation:

Tell me the founding year of "(your school's full name)", the name of the current principal, the school's sponsoring body, and the year of its most recent external school review.
For each item, state in brackets how confident you are, and say clearly which items you are not actually sure about.

You will usually see two things. First, the AI answers with great confidence. Second, at least one item is wrong, unless your school has an unusually large online footprint. That is the core problem lesson 9 deals with, and the problem we solve inside the platform with a school knowledge base.

What this means for your classroom

1. Anything that leaves the classroom gets checked. Letters to parents, student comments, external reports, alumni details — AI can draft these, but your name goes on them. Treat the output as a first draft from a hard-working student teacher who does not know the school.
2. Anything involving school-specific facts needs the documents supplied. Teaching schedules, rubrics, school rules, circular formats: the model knows none of them. Rather than hoping it guesses, give it the files. That is what a school knowledge base with RAG is for.
3. Anything students touch directly needs gating. Students will not check answers the way you do. Student use needs hint levels, teacher monitoring and an audit trail, not an open chat window.
4. Procurement decisions should not rest on parameter counts and benchmark scores. Lesson 4 covers what a parameter count really means and lesson 27 covers the limits of leaderboards. For a school, whether data can stay inside the campus network usually matters more than which model tops a chart.

Next

In the next lesson we open up the model itself and follow a sentence through it. No maths — just a row of teachers marking a worksheet.

Continue with the Transformer architecture in plain language.

If you would rather see what these techniques look like inside a working platform, look at features and security. If you are preparing a funding application, the Smart Learning funding page sets out the key points.