The whole journey

FRAME

Building something with AI is a bit like planning a long trip: you do not jump straight to the destination, you move through stops in order. There are six of them — first you work out the problem, then you gather data, look closely at that data, build a model, check how good it is, and finally put it to use. You cannot do them out of order, and when you reach the end you often loop back to make the next version better. The whole trip is the work, not any one stop.

six stages, in order — and it loops
Problem scopingData acquisitionData explorationModelingEvaluationDeployment
Deployment → Problem scoping  results send you back — the loop is the work
you cannot skip ahead: each stage needs the one before it; a weak earlier stage caps every later one

↑ Back to top

Scope the problem first

CONCEPT

The very first stop is to get crystal-clear about the problem before you collect a single thing. Four small questions do the job: who is stuck, what exactly is going wrong, where it happens, and why fixing it matters. A fuzzy problem leads to a fuzzy project — a machine is very precise, so the question you hand it has to be precise too.

scope the problem with four questions
WHO — whose problem is it? (the stakeholder)
WHAT — what exactly is wrong? (the gap)
WHERE — in what context does it occur?
WHY — why does solving it matter?
answer all four before gathering data — they decide what data you even need

↑ Back to top

Get the right data

CONCEPT

Next you go and get the data — but not just any data, and not as much as possible. You want the data that actually fits your question, taken from places you can trust. A small, well-chosen set beats a giant pile gathered carelessly, because whatever the machine learns, it learns straight from this data.

from the question to the right data
Ask: what data does this problem need?Find sources that hold itCheck each source is reliableCollect only what is relevant
garbage in, garbage out — a model can only be as good as the data it learns from
CONCEPT

Before building anything, spend time really looking at what you collected. Draw charts so the numbers become a picture, hunt for patterns of what goes with what, notice anything missing, and flag the surprises that do not fit. Spotting a problem here is easy and cheap; missing it now and finding it later is a real headache.

look before you build
Chart it — make the numbers visible
Find patterns — what tends to go with what?
Find gaps — what is missing or skewed?
Find surprises — what does not fit?
a problem you see now is cheap; the same problem found after modeling is expensive

↑ Back to top

Build, judge, and use the model

KEY-TERM

Now you build the part that actually decides. The big question first: do you already know the rule? If the rule is known and stable, you can just write it down yourself. If the rule is buried in the data and too tangled to spell out, you let the machine learn it from lots of examples instead. The problem decides which path you take.

do you already know the rule?
A decision to automate

TEST — Is the rule known and stable?
Yes — rule is known
→ rule-based: write the rule directly
No — rule is hidden in the data
→ learning-based: train a model on examples
CONCEPT

Once you have a model, you have to be honest about how good it really is. One nice-looking score can fool you — a model can seem clever overall and still get the important cases wrong. So you test it on examples it has not seen before, and you look at the kind of mistakes it makes, not just the count.

one number can lie
SURFACE
Looks goodone high accuracy score on the data it learned from — flattering and unsafe
test on held-out data; read the error types
BENEATH
Judged honestlytested on unseen data, broken down by which errors it makes and what they cost
ask not only 'how often right?' but 'wrong in which way, and who does that hurt?'
CONCEPT

The last stop is letting the model do its job for real — and keeping an eye on it. The world keeps changing, so a model that worked yesterday can slip over time. That is why this is not really the end: what you learn from real use flows back to the first stop, and the trip begins again, a little better each time.

ship, watch, loop back
Put the model into real useMonitor: is it still right in the world?Watch for drift as conditions changeFeed new data + problems back to scoping
deployment is where the cycle closes and restarts — not where it ends
The AI Project Lifecycle — Grade 8 (CT & AI) · projected from the LATTICE via prism_html.py · register: school-g8

↑ Back to top