← Back to Subjects ororo.world

Chapter 11: AI Concepts and AI Project Framework

The school bus is late. Ravi waits at the gate with his phone, and in about three minutes that phone does four clever things for him. He holds it up and it unlocks after looking at his face. He says, “Set an alarm for four o’clock,” and an alarm appears. He points the camera at a signboard in a language he cannot read, and English words show up on the screen. Then he opens a music app, and it offers him a song he has never heard, picked from what he played last week.

Four smart-looking actions, one after another. It is easy to think of the phone as one intelligent machine. It is not. Each action comes from a separate program, built for one job and trained on one kind of information. The program that unlocks the phone cannot suggest a song. The one that suggests songs cannot read a signboard.

See Fig. 11.0-1 for those four moments at the bus stop.

Diagram

Fig. 11.0-1 – a school bus stop scene, with a student holding a phone in the centre and four small labelled call-out panels around him: (1) phone unlocking after looking at his face, (2) a spoken sentence becoming a set alarm, (3) camera pointed at a signboard with translated words on the screen, (4) a music app showing a suggested song. Each panel labelled with the job it does, and a caption strip below reading “four separate programs, one phone”

NoteCuriosity Corner

Q1. A voice assistant can answer thousands of different questions. Why is it still called a narrow kind of AI? Q2. Has anyone ever built a machine that can handle any task a person can, across every subject? Q3. How can a program give expert advice when it has no experience of its own? Q4. A camera stores a photo as nothing but numbers. How can a program then tell a cow from a car in that photo? Q5. When a team sets out to build an AI system, what steps do they follow, and in what order?

This chapter will answer each of these five questions.

11.1 Broad AI and Narrow AI

A mixer in your kitchen grinds. That is the whole of it. Give it a heap of soaked dal and it will do the job faster and more evenly than any hand can, but ask it to wash the vessel afterwards and nothing happens. It is very good at one job and useless at every other job.

Most of the clever software around you today works in exactly that way. This is worth saying clearly, because the words we use can be misleading. When a news report says “AI”, it may mean a program that reads number plates at a toll gate, or it may mean the far bigger idea of a machine that could handle anything a person can handle. Those two are not close to each other, so we give them different names.

Artificial intelligence (AI) is the branch of computer science that builds systems able to do jobs that normally need human intelligence, such as recognising a face, understanding a spoken sentence, or picking the best move in a game. Within AI, one useful way to sort systems is by how wide a range of jobs they can handle.

Narrow AI

A toll gate camera reads number plates. It has been built for that one job and trained on many pictures of number plates. Point it at a mango tree and it will not tell you the tree is a mango tree — it has no way to produce that kind of answer at all. Software like this is called narrow AI.

NoteDefinition

(Narrow AI is an AI system built and trained for a single task, or a small set of closely related tasks, and it cannot work outside that task.)

“Narrow” describes the range of the job, not the quality of the work. Within its own narrow job, such a system is often faster and steadier than a person. A toll gate reads plates all night without getting tired. That is exactly why narrow AI is so widely used: pick one well-defined job, collect a lot of examples of it, and build a system that does only that.

Nearly every AI system you meet in daily life is narrow AI — a voice assistant, a spam filter, a face unlock, a song recommendation, a bank’s fraud alert.

a spam filter, as an example of narrow AI What it is: A program that sorts incoming email into “inbox” and “spam”. How it works: It is trained on a large collection of past emails that people have already marked as spam or not spam. From these it works out which words, senders and patterns tend to go with spam, and then applies the same test to each new email. Used for: The spam folder in an ordinary email account. Watch out: It only knows the kinds of spam it was trained on. A new trick that looks nothing like the old examples can slip straight through, and a genuine email can be pushed into spam by mistake.

Q. A voice assistant can play music, set alarms and answer general knowledge questions. Isn’t that more than one task?

A. They are separate narrow programs sitting behind one microphone. Each request is matched to the one program that handles it. Nothing in the assistant carries ability from one of those jobs across to another.

Q1. A voice assistant can answer thousands of different questions. Why is it still called a narrow kind of AI?

A. Because the number of questions is large but the kind of work is not. The assistant turns speech into text, matches that text to one of a fixed set of actions, and returns a result. Every one of those actions was designed and trained in advance. Ask it to do something outside that set — plan your week around your mood, or explain why a friend is upset — and it has nothing to fall back on, because it holds no general ability, only many separate narrow ones.

Broad AI

Now imagine the opposite. A single system that could read a signboard, follow a conversation about it, notice that the road is blocked, and work out another way to school — all without being separately built and trained for each of those jobs. This is broad AI, also called general AI.

NoteDefinition

(Broad AI is the idea of an AI system that can handle a wide range of different tasks, including ones it was not specially built for, by carrying what it has learnt from one situation across to another.)

Fig. 11.1-1 shows the difference as a picture: many small separate boxes on one side, one wide box on the other.

Diagram

Fig. 11.1-1 – two panels side by side. Left panel labelled “Narrow AI”: five small separate boxes, each with its own label (read number plates, filter spam, unlock by face, suggest songs, translate a signboard), with no connections between them. Right panel labelled “Broad AI”: one large box covering all five of the same labels, with arrows showing ability passing from one task to another. Caption strip: “many one-job systems, or one many-job system”

Broad AI does not exist today. It is a goal that researchers work towards, not a product anyone can buy, and no one can say when or whether it will be built. Everything you will study in this chapter — expert systems, computer vision, language processing, neural networks — belongs to the narrow side of that picture.

Table 11.1 – Narrow AI vs broad AI | Feature | Narrow AI | Broad AI | |—|—|—| | Range of tasks | One task, or a few closely related ones | A wide range of different tasks | | New, unfamiliar task | Cannot attempt it | Expected to attempt it | | Carrying ability across tasks | No | Yes | | Training | Trained separately for each task | Not tied to one set of tasks | | Available today | Yes, in wide everyday use | No, still only an aim |

treating an app that does many things as broad AI What goes wrong: A phone unlocks by face, translates a signboard and suggests songs, so it looks like one system with wide ability. The fix: Count the programs, not the phone. Each of those is a separate narrow system, trained on its own data, running on the same device. A shop that sells shoes, sweets and stationery is still three counters under one roof.

11.2 Strong AI versus Weak AI

In 11.1 we sorted AI systems by how many kinds of job they can take on. There is a second question worth asking about the same systems, and it is a deeper one: when a machine gives a sensible answer, is anything going on inside it that resembles understanding?

Think of a calculator. Type 47 × 36 and it returns 1692, correctly, every single time. It has no notion of what 47 mangoes look like, what a mango is, or why anyone would want 36 heaps of them. It matches the pattern of the sum and produces a number. Right answer, no understanding.

This is the distinction between weak AI and strong AI.

Weak AI

Weak AI is the name given to systems that produce intelligent-looking results by following rules and patterns learnt from data, without any understanding of what those results mean. Narrow AI systems are weak AI — the two names describe the same systems from two angles, one looking at the range of the task and the other at what is happening inside.

NoteDefinition

(Weak AI is an AI system that performs a task by applying rules and patterns learnt from data, without understanding the meaning of what it is doing.)

A face unlock program is a good example. It compares numbers taken from the camera image against numbers stored when you first set up the phone, and if the two are close enough, it unlocks. It does not know that the thing in front of it is a face, or that the face belongs to you, or what a phone is for. It computes a similarity and compares it against a limit.

Once again, “weak” is not an insult about performance. A weak AI system can beat every human on earth at its own job. The word only says that the ability stops at the edge of the task.

Q. A chatbot writes a reply that sounds thoughtful. Doesn’t that show some understanding?

A. No. It calculates, word by word, which word is most likely to come next given everything typed so far. The reply reads well because it was built from a huge quantity of well-written text, not because anything inside the program grasps what the words refer to.

Strong AI

Strong AI, also called general AI, is the idea of a machine with the full range of human mental abilities. Such a system would reason its way through an unfamiliar problem, learn from its own experience, come up with something new, apply what it picked up in one situation to a completely different one, and follow what a situation means rather than only what it looks like.

NoteDefinition

(Strong AI is the idea of an AI system with human-level ability to reason, learn from experience and understand meaning, across a wide range of tasks and subjects.)

Fig. 11.2-1 lays the two side by side.

Diagram

Fig. 11.2-1 – two stacked bands. Upper band labelled “Weak AI – exists today”: a box with an arrow in (camera image, typed text, recorded sound) and an arrow out (a label, a reply, an alarm set), and inside the box the words “rules and patterns learnt from data”. Lower band labelled “Strong AI – an idea, not yet built”: a wider box with the same arrows in and out, and inside it four items — reasons about new problems, learns from its own experience, carries knowledge across subjects, understands meaning. A dotted border around the lower band to show it does not yet exist

Strong AI has not been achieved. Nobody has built a system with these abilities, and there is honest disagreement among researchers about whether it can be built at all. Everything working in the world today — every assistant, every recommendation system, every self-driving prototype — sits in the upper band of that figure.

Q2. Has anyone ever built a machine that can handle any task a person can, across every subject?

A. No. Strong AI remains a theoretical idea. Every AI system in use today is weak AI: it was built and trained for a particular job, it applies patterns learnt from data for that job, and it has nothing to offer outside it. Research aims at systems that come closer to human-level ability, but no such system exists.

Table 11.2 – Weak AI vs strong AI | Feature | Weak AI | Strong AI | |—|—|—| | What it does inside | Applies rules and patterns learnt from data | Would reason about meaning | | Understanding of the task | None | Human-level understanding | | Learning from its own experience | No, it is retrained by people on fresh data | Yes, on its own | | Handling a situation it was never trained for | Fails, or returns a wrong answer confidently | Would work it out | | Present status | In wide use across the world | A theoretical idea, not achieved |

Because weak AI systems answer smoothly, people tend to trust them as if they understood the question. That becomes serious when the answer is about a person — a loan, an admission, a medical alert. Any such decision should be checked by a responsible human being before it is acted on, and the person affected should be able to ask why the answer came out that way.

reading “weak” and “strong” as poor and good What goes wrong: Students assume weak AI means an AI system that works badly and strong AI means one that works well. The fix: The pair describes the kind of ability, not the quality of the output. A weak AI system can be extremely accurate at its own job. It is called weak because it holds no understanding beyond that job.

11.3 Expert Systems in AI

A water pump in a village stops working at six in the morning. The mechanic who has repaired that model for twenty years lives fifteen kilometres away and is asleep. His knowledge is real and valuable, but it sits inside one head, in one place, at one time.

That is the problem this part of AI set out to solve. Long before computers could learn patterns from large amounts of data, people asked a simpler question: if an expert can explain what she checks, in what order, and what each finding means, could all of that be written down as facts and rules and handed to a program?

A system built that way is called an expert system.

NoteDefinition

(An expert system is an AI system that stores the knowledge of human experts in one particular field as facts and rules, and applies them to a user’s problem to give advice or a solution.)

The field matters. An expert system for diagnosing pump faults holds nothing at all about crop diseases. Like the systems in 11.1, it is narrow — the knowledge inside it was collected for one subject and works only there.

Knowledge written as rules

Most of what an expert knows can be put in the form “if this is true, then that follows”. Table 11.3 shows a few such rules for a school computer lab printer.

Table 11.3 – sample rules for a printer helpdesk, each with a condition and the action it leads to | Rule | If | Then | |—|—|—| | R1 | No light glows on the printer | Check the power cable and the switch | | R2 | A light glows but nothing prints | Check whether the printer is the selected one on the computer | | R3 | The correct printer is selected and nothing prints | Check the paper tray and the cable to the computer | | R4 | Pages print but come out blank | Check the ink or toner level | | R5 | Pages print with streaks down the page | Clean the print head, then print a test page |

Notice that no rule mentions any particular printer brand or any particular day. Each one is a small piece of general advice, in a form a program can test.

giving advice from stored rules Input: the user’s description of the problem, given as answers to questions Output: a recommended action, or a message that no rule fits Steps:

1. Ask the user the first question about the problem.
2. Store the answer as a known fact.
3. Look through the stored rules for one whose "if" part
   is satisfied by the known facts.
4. If a rule is found, and its "then" part is an action,
   report that action to the user and stop.
5. If a rule is found, and its "then" part is a new fact,
   add that fact to the known facts and go back to step 3.
6. If no rule fits, ask the next question and go back to step 2.
7. If the questions run out and no rule fits, report that
   the system has no advice for this case.

Why it works: every step either adds a fact or uses one, so each pass through the rules brings the system closer to an action or to running out of options.

Step 7 matters more than it looks. A good expert system is willing to say it does not know. The alternative — producing an answer anyway — is worse than silence, because the user cannot tell a confident guess from real advice.

Q. Is an expert system just a search of the internet, then?

A. No. A search returns pages that mention your words and leaves you to work out which one fits. An expert system takes your particular answers, applies its rules to them, and returns the one action those answers lead to.

Q3. How can a program give expert advice when it has no experience of its own?

A. It does not need experience of its own, because it is using someone else’s. People interview experts in one field, write down what they check and what each finding means, and store that as facts and rules. The program then applies those rules to your particular case. The expertise is genuine but borrowed, and it is only as good as the rules that were collected — which is why an expert system must be updated whenever the knowledge in its field changes.

11.3.1 The Parts of an Expert System

The rules in Table 11.3 have to live somewhere, something has to apply them, and a user has to be able to talk to the system. So an expert system is built from four parts, each with a clear job. Fig. 11.3-1 shows how they fit together.

Diagram

Fig. 11.3-1 – block diagram of an expert system. A person icon on the left connected by a two-headed arrow to a box labelled “user interface”. The user interface connects to a central box labelled “inference engine”. The inference engine connects by a two-headed arrow to a box labelled “knowledge base” containing two stacked layers marked “facts” and “rules”. A fourth box labelled “explanation facility” sits below the inference engine, drawing an arrow from it and sending an arrow back to the user interface. Arrows from the user interface to the inference engine labelled “the user’s answers”, and back the other way labelled “advice”

The knowledge base

The knowledge base is the store of everything the system knows about its field. It holds two kinds of item: facts, which are things known to be true (“this printer is connected by cable, not over wi-fi”), and rules, which link a condition to a conclusion, as in Table 11.3.

This store is built by sitting with human experts and writing down what they know in a form the program can test. That work is slow, and it is the reason expert systems are expensive to build.

treating the knowledge base as an ordinary database What goes wrong: Students describe the knowledge base as “where the data is kept”, as if it were a school’s list of student names and marks. The fix: A database holds facts only. A knowledge base holds facts and the rules that connect them, and it is the rules that let the system reach a conclusion the facts do not state directly.

The inference engine

Facts and rules by themselves do nothing. The inference engine is the part that puts them to work: it takes what the user has said, searches the knowledge base for rules whose condition is now satisfied, applies them, and repeats until it reaches an action or runs out. The algorithm in 11.3 is exactly what an inference engine carries out.

the inference engine What it is: The reasoning part of an expert system. How it works: It matches the known facts against the conditions of the stored rules. Each rule that fires either produces an action or adds a new fact, and the new fact may allow another rule to fire. This chaining continues until an action is reached. Used for: Working from “a light glows but nothing prints” to “check the paper tray and the cable”. Watch out: It can only reach conclusions its rules allow. A fault nobody wrote a rule for will leave the engine with no answer, however obvious that fault might be to a technician standing in the room.

Q. Why keep the rules and the engine as separate parts?

A. So that either can be changed without touching the other. When a new model of printer brings a new fault, someone adds a rule to the knowledge base. The engine, which only matches conditions to facts, needs no change at all.

The user interface

The user interface is the part the person actually sees. It asks the questions, takes the answers, and shows the advice, in ordinary language rather than in the system’s internal form.

Its design matters more than it might seem. The person using a pump-repair system may be standing in a field with a phone in one hand. Questions have to be short, in a language he reads comfortably, and answerable without special training — otherwise correct advice inside the system never reaches the person who needs it.

The explanation facility

Suppose the system tells you to replace a part that costs two thousand rupees. You would reasonably want to know why. The explanation facility answers that question: it reports which facts were used and which rules fired to reach the recommendation.

This does two useful things. It lets the user judge whether the advice makes sense for the situation in front of him, and it lets the expert who wrote the rules find the faulty one when the advice comes out wrong. A system that gives an answer and no reason cannot be checked by anybody.

Q. What happens if two rules fit the same set of facts and suggest different actions?

A. The engine follows a fixed order — for example, the rule listed first wins, or the more specific rule wins. Whichever order is chosen, the explanation facility reports which rule was used, so the clash can be found and the rules corrected.

11.3.2 What Expert Systems Do Well, and Where They Struggle

An expert system is worth its cost only when the job suits it. That job usually has three features: the field is narrow, the expert can put her reasoning into words, and the same kind of question comes up again and again.

What they do well

  1. They keep expertise from being lost. When an experienced engineer retires, the rules written down from her work stay behind and remain usable.

  2. They answer the same way every time. Two people describing the same fault get the same advice, whether it is Monday morning or two in the night.

  3. They free the expert for hard cases. Routine questions are handled by the system, so the human expert spends her time on the unusual ones.

  4. They spread scarce knowledge. One carefully built system can advise thousands of users in places where no expert is available.

  5. They can show their reasoning. Because of the explanation facility, a user can see which rules led to the advice — something a busy human expert rarely has time to set out in full.

Table 11.4 lists fields where expert systems have been put to work, with a typical use in each.

Table 11.4 – fields that use expert systems, and a typical use in each | Field | Typical use | |—|—| | Medicine | Suggesting likely causes of a set of symptoms for a doctor to consider | | Finance | Checking a loan application against a bank’s lending rules | | Engineering | Diagnosing a fault in a machine from the symptoms an operator reports | | Customer support | Guiding a caller step by step through a common problem with a product | | Agriculture | Advising on a crop problem from what the farmer describes and photographs |

Where they struggle

The same design that makes an expert system dependable also sets its limits.

Uncertain or incomplete information is the first difficulty. The rules are written as though every condition is either true or false. A farmer who says “some leaves have small brown spots, but I am not sure how many” has given the system nothing it can test cleanly, while a human expert would happily work with the doubt.

The second difficulty is that knowledge goes stale. A rule that was correct when it was written stays in the knowledge base long after the field has moved on. Nothing inside the system notices this — someone has to go back and update the rules by hand.

The third is that some expertise cannot be written down at all. A mechanic who says “it just sounded wrong” is using judgement built from thousands of engines heard over many years. He cannot state the rule, so nobody can store it.

And there is a fourth, which follows from 11.2: an expert system does not learn from its own use. Give it the same case a hundred times and it gives the same answer a hundred times, even if the first ninety-nine turned out to be wrong. Improvement comes only when a person changes the rules.

Q. If the knowledge base can be wrong, how would anyone find out?

A. By comparing the advice against what actually happened. If the system repeatedly recommends replacing a part and replacing it does not fix the fault, the rule that fired is the one to examine — and the explanation facility says which rule that was.

An expert system whose rules have not been updated can go on giving confident, outdated advice about a person’s health, money or crop. The people it advises usually cannot tell. Any system used for decisions like these needs a named person responsible for reviewing its rules on a fixed schedule, and its advice should be presented as a recommendation for a human being to check, not as a verdict.

Pick a device in your classroom that sometimes stops working — a fan, a light, a projector. Write three rules for it in “if … then …” form, in the style of Table 11.3. Then ask a classmate to describe a fault and see whether your rules reach useful advice, or run out.

11.3.3 Eliza: An Early Example

The systems in 11.3.1 hold real knowledge about a field. One famous early program showed something almost opposite, and it is worth studying for exactly that reason: how convincing a conversation can seem when the program behind it holds almost no knowledge at all.

Eliza was written in the mid-1960s by Joseph Weizenbaum, a computer scientist at the Massachusetts Institute of Technology (MIT) in the United States. You typed a sentence, and Eliza typed a sentence back. Its best-known version replied in the manner of a therapist, turning most of what you said into a question and handing it back to you. Fig. 11.3-2 shows what such a session looked like on the screens of the time.

Diagram

Fig. 11.3-2 – screenshot of an Eliza session running in a plain text terminal, showing the program’s greeting and a few alternating lines of typed conversation in a monospaced font

Eliza is generally counted as the first chatbot — a program that holds a conversation with a person in ordinary language, through typed text or speech.

How the replies were produced

Eliza worked by pattern matching. Its rules looked for particular words or shapes of sentence in what you typed, and each rule carried a template for the reply, with part of your own sentence dropped into it. Table 11.5 shows the kind of rule involved.

Table 11.5 – the kind of pattern rule Eliza used, with a sample input and the reply the template produces | Pattern looked for | Reply template | Example input | Reply produced | |—|—|—|—| | “I am …” | “How long have you been …?” | I am tired of waiting for the bus | How long have you been tired of waiting for the bus? | | “… my mother …” | “Tell me more about your family.” | My mother packs my lunch | Tell me more about your family. | | “I need …” | “Why do you need …?” | I need a new cycle | Why do you need a new cycle? | | no pattern matches | a stock reply | The window is open | Please go on. |

Eliza What it is: An early text conversation program built on pattern matching rules. How it works: It scans the typed sentence for a keyword or sentence shape it recognises, picks the matching rule, and fills the rest of your own words into that rule’s reply template. If nothing matches, it falls back on a stock phrase such as one inviting you to continue. Used for: Demonstrating, in the 1960s, that a computer could carry on a text conversation in ordinary language. Watch out: It keeps no record of meaning. It does not know what a bus is, or a cycle, and it cannot connect one reply to the next, so a long conversation with it becomes repetitive and finally absurd.

Why Eliza still matters

Weizenbaum built the program partly to show how shallow the trick was. What happened instead surprised him: people who used Eliza often behaved as though it understood them, and some wanted to be left alone with it. The program had no understanding whatever — this is weak AI in its plainest form, from 11.2 — and yet the impression of understanding was strong.

That lesson has not aged. Modern chatbots produce far better sentences than Eliza did, and the pull to treat a fluent reply as a thoughtful one is far stronger now.

Eliza’s second contribution was technical. It was an early demonstration that stored rules could be applied to ordinary human language, and the work that grew out of it led towards natural language processing, which you will meet in 11.5.

Q. Is Eliza a true expert system?

A. It is rule-based in the same way — stored rules applied to what the user types. But it has no knowledge base about any subject, and no explanation facility, so it can give no advice and no reasons. It is best treated as an early relative of the expert system rather than a full one.

The tendency to credit a machine with understanding because its replies sound human has a name: the Eliza effect. It was named after this program, and it is the reason a fluent answer should never by itself be taken as a correct one.

11.4 Computer Vision (CV)

In a fruit packing shed, mangoes roll down a belt and two workers pick out the bruised ones by eye. They are good at it, but the belt runs eight hours a day and eyes get tired. Could a camera above the belt do the same job?

The camera part is easy. The hard part is everything after it, because a camera does not hand over a picture of a mango. It hands over a grid of numbers.

What a picture is, to a computer

An image is stored as a grid of tiny squares called pixels. Each pixel holds a number for how bright that square is — in a common format, 0 stands for black, 255 for white, and the values in between for shades of grey. A colour image keeps three numbers per pixel, one each for red, green and blue.

So the picture in Fig. 11.4-1 is, inside the machine, nothing but a very long list of numbers.

Diagram

Fig. 11.4-1 – on the left, a small simple drawing of a mango on a plain background; on the right, the same image shown as a coarse grid of about 12 by 12 squares with a two- or three-digit number written inside each square, higher numbers in the bright areas and lower numbers in the dark areas. A magnifier line joins one square on the left to one numbered cell on the right, labelled “one pixel = one number (grey) or three numbers (colour)”

That list gets long quickly.

how many numbers make up one photograph

Given: a colour photo 640 pixels wide and 480 pixels tall, storing 3 numbers per pixel

Find: the total count of numbers in the photo

Working:

number of pixels = 640 × 480 = 307200 pixels

numbers stored = 307200 × 3 = 921600

921600 numbers

Nothing in that list says “mango”. There is no square marked fruit and no square marked bruise. Finding a mango in nine lakh numbers is the whole problem, and the branch of AI that works on it is computer vision.

NoteDefinition

(Computer vision (CV) is the branch of AI that takes images or video as input and extracts useful information from them, such as what objects are present and where they are.)

The steps in a computer vision system

Most computer vision systems move through the same stages, shown in Fig. 11.4-2.

Diagram

Fig. 11.4-2 – a left-to-right pipeline of four labelled blocks joined by arrows: “image acquisition” (small camera icon), “pre-processing” (icon of an image being straightened and brightened), “feature extraction” (icon of an image with edges and corners marked), “the task” (icon branching into three small labels: classification, detection, segmentation). Below the pipeline, a caption strip reading “numbers in, information out”

Image acquisition is the first step: a camera or other sensor captures the picture or the video. Everything later depends on this, so the camera position, the lens and the lighting are part of the design, not details to be settled afterwards.

Pre-processing then cleans up what arrived. The image may be resized so that every picture reaching the next stage is the same size, brightened or darkened so that a cloudy morning and a bright afternoon look comparable, and smoothed to reduce speckle. The aim is to remove differences that have nothing to do with the question being asked.

Feature extraction is the step that turns raw pixels into measurements worth comparing. Instead of nine lakh separate numbers, the system works out a much shorter list describing the picture — where the edges and corners lie, which colours occur in which patches, how rough or smooth a region is. These measurements are called features.

Q. Why not compare the pixel numbers directly against a stored photo of a mango?

A. Because almost nothing would match. Move the mango two centimetres, turn it, or let a cloud pass over the shed, and every one of those numbers changes, though the fruit is the same. Features are chosen to survive such changes.

What the system is asked to produce

Once features are available, the system is trained on many pictures that people have already labelled, and it works out which patterns of features go with which label. What comes out depends on the task.

Image classification gives one label for the whole picture: this photo shows a mango, or this photo shows a bruised mango.

Object detection and localisation goes further and reports where: it draws a box around each object it finds and labels each box, so one picture may yield six mangoes at six positions.

Image segmentation is finer still. It assigns a label to every single pixel, marking exactly which pixels belong to the fruit and which to the belt, so the bruised area can be measured rather than merely noticed.

Object tracking applies to video. It follows the same object from frame to frame, which lets a system count how many mangoes passed and notice when one is missing, even as they move.

Table 11.6 – image classification vs object detection | Feature | Image classification | Object detection | |—|—|—| | What it returns | One label for the whole image | A label and a box for each object found | | Number of objects handled | Assumes the image is about one thing | Several in the same image | | Position information | None | Yes, the position of each object | | Suits the question | “Is this a bruised mango?” | “How many mangoes on this belt, and which are bruised?” |

Q4. A camera stores a photo as nothing but numbers. How can a program then tell a cow from a car in that photo?

A. It never looks for a cow directly. The numbers are first cleaned up, then reduced to features — edges, corners, colours, textures and their arrangement. During training, the system is shown a large number of pictures already labelled by people as cow or car, and it works out which feature patterns go with which label. For a new picture it measures the same features and reports the label whose pattern they match most closely. No step in this involves knowing what a cow is; it is measurement and comparison from start to finish.

Where computer vision is used, and where it fails

Computer vision is at work in driver-assistance systems that spot lane markings, in medical imaging that highlights regions for a radiologist to examine, in farming systems that check crops from drone photographs, in factories that inspect parts, and in the face unlock on a phone.

Every one of these depends on the pictures it meets resembling the pictures it was trained on. A system trained on daytime photographs performs poorly at dusk. One trained on clean mangoes on a bright belt will struggle when the belt is dusty. Change the camera, the lighting or the background, and accuracy can fall sharply, with nothing in the system to announce that this has happened.

A camera that identifies people is not the same as one that counts mangoes. Face recognition can track where a person goes and who they meet, often without their knowing. Systems like these should be used only where there is a clear, stated purpose, the people involved are told, the images are kept no longer than needed, and a human being reviews any decision made about a person from them.

11.5 Natural Language Processing (NLP)

A small bookshop lets customers type a short review after every order. In a good month that comes to eight hundred reviews. The owner would like to know two things: how many customers are unhappy, and what they are unhappy about. Reading all eight hundred takes a full day, so it never gets done.

The reviews are already inside a computer, as text. Yet a computer cannot answer either question, because to it a review is a string of characters, no different from a car number or a password.

Human language is difficult for a machine for reasons that never trouble us. The same word carries different meanings — “the book was a steal” is praise, “the book was stolen” is a complaint. Word order changes everything. People misspell, shorten, and mix languages in one sentence. Nothing here is regular enough to handle with a plain search for keywords.

Natural language processing (NLP) is the branch of AI that works on this.

NoteDefinition

(Natural language processing (NLP) is the branch of AI that lets a computer take in human language as text or speech, extract information from it, and produce language in return.)

Cleaning the text first

Raw text has to be tidied before anything can be measured, in much the same way that an image is pre-processed in 11.4. Table 11.7 follows one short review through the usual steps.

Table 11.7 – one review after each text-processing step | Step | The text after this step | |—|—| | Original review | The delivery was very late, and the book was damaged! | | Punctuation removed | The delivery was very late and the book was damaged | | Converted to lower case | the delivery was very late and the book was damaged | | Split into tokens | the / delivery / was / very / late / and / the / book / was / damaged | | Stop words removed | delivery / late / book / damaged |

Splitting a piece of text into separate words or pieces is called tokenisation, and each piece is a token. Common words such as “the”, “was” and “and” are called stop words; they appear in almost every sentence, so they help very little in telling one review from another, and are often dropped.

Look at the last row. Four words — delivery, late, book, damaged — and the complaint is still perfectly clear, from a quarter of the original text.

Q. Is it always safe to remove stop words?

A. No. “The book was not damaged” becomes “book damaged” if “not” is treated as a stop word, which reverses the meaning. Which words are safe to drop depends on the task, and negation words usually have to be kept.

What the system is then asked to do

Once the text is in tokens, several different jobs become possible.

Part-of-speech tagging labels each token with its grammatical class — noun, verb, adjective and so on. This helps later steps tell apart the two senses of a word like “book”, which can be a thing or an action.

Parsing works out the grammatical structure of a sentence: which word is the subject, which the verb, what belongs to what. “The dog chased the boy” and “The boy chased the dog” contain the same tokens, and only structure separates them.

Named entity recognition picks out the tokens that name particular things — people, organisations, places, dates, amounts. In the bookshop’s reviews it would pull out city names and delivery dates, which is what the owner needs to see whether the delays are worse in one city.

Sentiment analysis decides whether a piece of text is positive, negative or neutral. This is the one that answers the owner’s first question: run it over eight hundred reviews and it reports how many are unhappy in a few seconds.

Machine translation converts text from one language to another. Natural language generation goes the other way, producing sentences from data or from a request — the reply a chatbot types, or a one-line summary of a long report.

Speech, and a whole command

A voice assistant strings several of these together, with one extra step at the front. Fig. 11.5-1 traces what happens between speaking and the alarm being set.

Diagram

Fig. 11.5-1 – a five-step horizontal flow, each step a labelled box with an arrow to the next: (1) person speaks a command, (2) microphone records the sound as a signal, (3) speech-to-text converts the recording into a sentence of text, (4) the text is tokenised and parsed to find the action and its details, (5) the matching action is carried out and a spoken reply is generated. Under step 4 a small call-out showing the sentence “set an alarm for four o’clock” split into action = set alarm, time = 4 o’clock

Notice step 4. What the system produces is not meaning in any human sense — it is a small set of filled-in slots: an action and the details that action needs. That is all a command has to become for a program to act on it.

expecting translation to work word by word What goes wrong: Students assume a translation system swaps each word for the matching word in the other language. The fix: Word-by-word swapping fails, because word order, grammar and idiom all differ between languages. Translation systems work on whole sentences, trained on very large collections of the same text in both languages.

Where NLP struggles

Sarcasm defeats most sentiment analysis: “wonderful, the book arrived in only three weeks” scores as positive on its words alone. Long conversations lose their thread, because the system must carry earlier sentences forward and often does not. Sentences that mix two languages, as people do naturally in India, fit poorly with a system trained on one. And any system is weakest on the kinds of writing it saw least of during training.

Take a two-line review of anything — a shop, a film, a bus service — and carry out the steps of Table 11.7 on paper. Then look at your final list of words and decide whether it still shows clearly what the writer felt.

11.6 Neural Networks (NN)

The printer rules in 11.3 could be written down because an expert could state them. Now go back to the mangoes in 11.4 and try the same thing. Write a rule that separates a bruise from a shadow, using only the numbers in the pixels. Nobody can. The difference is real and any child can see it, but no one can put it into words precise enough for a program.

So a different approach is needed: instead of a person supplying the rule, the system is given many examples that people have already labelled, and it sets its own numbers so that its answers match those labels. A neural network (NN) is the most widely used design of this kind.

NoteDefinition

(A neural network is an AI system made of many small computing units arranged in layers, where each connection carries a number called a weight, and the weights are adjusted from labelled examples until the network’s outputs match the labels.)

The name comes from a loose comparison with the brain, where nerve cells pass signals to one another. The comparison is a picture, not a claim — an artificial network is arithmetic on numbers, and it is far simpler than any living brain.

One unit

The small computing unit is called a neuron. It does three things, in order.

It receives one number on each of its input connections. It multiplies each input by the weight stored on that connection and adds the products together. It then passes that total through an activation function, which decides what the neuron sends onward — in the simplest case, whether it sends a 1 or a 0.

what one neuron computes

Given: a neuron with two inputs taken from a mango photograph — share of the surface that is dark patches, x₁ = 0.6, and smoothness of the surface, x₂ = 0.2. The weights on these connections are w₁ = 0.9 and w₂ = 0.4. The activation function sends 1 if the total is 0.5 or more, and 0 otherwise. An output of 1 means “bruised”.

Find: what this neuron sends onward

Working:

first product = x₁ × w₁ = 0.6 × 0.9 = 0.54

second product = x₂ × w₂ = 0.2 × 0.4 = 0.08

total = 0.54 + 0.08 = 0.62

0.62 is not less than 0.5, so the activation function sends 1

the neuron sends 1, marking this mango as bruised

Read the weights again. The dark-patch input carries 0.9 and the smoothness input only 0.4, so dark patches count for more than twice as much in this decision. That is what a weight means: how much one input matters. Nobody typed 0.9 and 0.4 by hand — those numbers came out of training, which is described below.

Layers

One neuron can only draw a very simple line between two answers. Real problems need many, arranged in layers, as in Fig. 11.6-1.

Diagram

Fig. 11.6-1 – a small feed-forward neural network drawn left to right. An input layer of three circles labelled with features (dark-patch share, smoothness, colour), a hidden layer of four circles, and an output layer of two circles labelled “bruised” and “good”. Every circle in one layer joined by a line to every circle in the next. A few lines labelled w to show that each connection carries a weight. Arrows along the bottom pointing left to right, labelled “feed-forward: numbers flow this way”

The input layer receives the features — the measurements taken from the picture, as in 11.4. Each hidden layer combines what the layer before it produced, so later layers work with combinations that no single input carries on its own. The output layer produces the final answer: a label, or a score for each possible label.

Passing numbers forward through the layers in this way, from input to output, is called feed-forward propagation.

Q. What is actually hidden about a hidden layer?

A. Only that you never see its values. The input layer holds numbers you supplied and the output layer holds the answer you read, but the hidden layers hold intermediate numbers that have no name and no meaning you can state. They are simply useful combinations found during training.

Training

An untrained network has weights set to small arbitrary values, so its first answers are close to guesses. Training corrects them, using examples whose correct labels are already known.

training a neural network Input: many examples, each with its features and its correct label Output: a set of weights that makes the network’s answers match the labels closely Steps:

1. Start with small arbitrary weights on every connection.
2. Take one example and pass its features forward through
   the layers to get the network's output.
3. Compare that output with the correct label and calculate
   the loss, a number measuring how far apart they are.
4. Work backwards through the layers, finding for each weight
   whether raising or lowering it would reduce the loss.
5. Change every weight slightly in that direction.
6. Repeat steps 2 to 5 for the next example, and keep going
   through the whole set of examples many times.
7. Stop when the loss stops falling.

Why it works: each pass leaves every weight a little better than it was for that example, and repeating over many examples settles the weights at values that suit the whole set.

Two of those steps have names. The loss function in step 3 is the calculation that turns “how wrong was this answer” into a single number. Back-propagation is steps 4 and 5 — working backwards from the loss to decide how each weight should change. Fig. 11.6-2 shows the loop.

Diagram

Fig. 11.6-2 – a closed loop. Along the top, a left-to-right arrow labelled “feed-forward” from a block “example” through a block “network” to a block “output”. To the right, “output” and “correct label” both feed into a block labelled “loss function”, which produces “loss”. Along the bottom, a right-to-left arrow labelled “back-propagation” running from “loss” back into “network”, ending at a small block labelled “weights updated”. A circular arrow around the whole figure labelled “repeat over many examples”

saying the network learns to recognise mangoes the way a person does What goes wrong: Because training is described as learning, students picture the network forming an idea of a mango. The fix: Training changes numbers. Each pass adjusts weights so that the calculated output sits closer to the label supplied by a person. Nothing in the network holds an idea of fruit, which is why a network trained on mangoes returns confident nonsense if you show it a cricket ball.

Strengths, limits, and where they are used

Neural networks handle exactly the problems expert systems cannot: those where the pattern is real but nobody can state it. That advantage comes at a price, as Table 11.8 sets out.

Table 11.8 – expert system vs neural network | Feature | Expert system | Neural network | |—|—|—| | Where its knowledge comes from | Rules written down by human experts | Weights set during training on labelled examples | | What it needs to be built | Access to experts, and time to interview them | A large number of correctly labelled examples | | Suits problems where | The expert can state the rule | The pattern is real but cannot be stated | | Explaining an answer | Can report the rules it used | Can report only the answer, not a reason a person can follow | | Updating it | Someone edits a rule | The network is retrained on fresh data |

The need for labelled data is the practical limit. Thousands of examples must be collected and labelled by people, and if those examples are unrepresentative, the trained network carries the same gaps. The difficulty of explaining an answer is the deeper limit — a network that rejects a loan application cannot say which rule it applied, because it has none.

Neural networks are behind most of the systems in 11.4 and 11.5: image classification, object detection, speech-to-text, machine translation and the reply a modern chatbot produces. They are also used for forecasting demand, spotting unusual transactions and recommending what to watch next.

11.7 The AI Project Framework

A school notices that a great deal of food is thrown away from its canteen every afternoon. Someone suggests using AI to work out how much to cook. It is a fair suggestion, and it is also where most such projects go wrong — not because the idea is bad, but because the next step taken is usually the wrong one.

The tempting next step is to start building. A team that does this often discovers, weeks later, that nobody wrote down what “too much food” means, that no record exists of how many students ate on any given day, and that even a working system would have no way to reach the cook before he starts at nine in the morning.

All three problems could have been found in the first week. That is what a framework is for.

NoteDefinition

(An AI project framework is the ordered set of stages a team works through to build an AI system, from stating the problem to checking how well the finished system performs.)

It is also called the AI project cycle, and both names appear in use. The stages are these:

  1. Problem Scoping — deciding exactly what problem is being solved, and for whom.

  2. Data Acquisition — gathering the data the problem needs.

  3. Data Exploration — examining that data to see what it actually contains.

  4. Modelling — building the system that produces the answers.

  5. Evaluation — testing how well it performs on data it has never seen.

Table 11.9 puts the same five stages next to the question each one answers, which is often the quickest way to tell them apart.

Table 11.9 – the five stages and the question each answers | Stage | The question it answers | |—|—| | Problem Scoping | What exactly are we solving, for whom, and how will we know it worked? | | Data Acquisition | What data do we need, and where will it come from? | | Data Exploration | What is actually in this data, and what is wrong with it? | | Modelling | How do we turn this data into answers? | | Evaluation | How well does it perform on data it has not seen before? |

Why it is drawn as a cycle

The stages are worked through in order, but the order is not a one-way street. Fig. 11.7-1 shows why it is usually drawn as a ring.

Diagram

Fig. 11.7-1 – five labelled blocks arranged clockwise in a ring, joined by solid arrows in this order: Problem Scoping, Data Acquisition, Data Exploration, Modelling, Evaluation, with a final arrow from Evaluation back round to Problem Scoping. Three dashed arrows drawn across the ring show the common return paths: Data Exploration back to Data Acquisition, Modelling back to Data Exploration, and Evaluation back to Modelling. A label in the centre reads “AI project cycle”

Suppose exploration shows that attendance was recorded for only two months of the year. There is no point going forward with that; the team returns to acquisition and looks for more. Suppose evaluation shows the system predicts well on weekdays and badly on the days of school functions. The team goes back to modelling, or further back to ask whether function days should have been part of the problem at all.

Going back is not failure. Finding the flaw at exploration costs a week. Finding the same flaw after the system is running in the canteen costs the whole project.

Q. What if the first stage shows that AI is not needed at all?

A. Then the project stops there, and that is a good outcome. If the canteen wastes food because the cook is never told the number of students on trips, the fix is a message from the school office, not a trained model. AI is worth using when the pattern is real, the data exists, and no simple rule will do.

Q5. When a team sets out to build an AI system, what steps do they follow, and in what order?

A. They follow five stages in order: Problem Scoping, Data Acquisition, Data Exploration, Modelling and Evaluation. First the problem is stated precisely along with a test of success, then the data is gathered, then examined for what it really contains, then used to build a system that produces answers, and finally that system is checked on data it has never seen. The order matters because each stage depends on the one before it, and teams routinely go back a stage when a later one reveals a problem — which is why it is drawn as a cycle rather than a straight line.

The five stages are taken up one by one in 11.7.1 to 11.7.5, following the canteen project throughout.

11.7.1 Problem Scoping

“The canteen wastes too much food.” Everyone in the school would agree with that sentence, and nobody could build anything from it. How much is too much? Wasted on which days? Noticed by whom? And if a system were built, what would count as it having worked?

Problem scoping is the stage where a complaint is turned into a statement precise enough to work from. It is the shortest stage and the one that decides whether the rest of the project is worth doing.

Four questions do most of the work.

  1. Who is affected? The cook, who decides quantities each morning; the canteen manager, who pays for what is thrown away; the students, who find dishes finished by the time they reach the counter.

  2. What exactly is happening? On most days, more food is cooked than is eaten. On a few days the opposite happens and food runs out.

  3. Where and when? In the school canteen, on the lunch break, on ordinary working days.

  4. Why does it matter? Wasted food costs money and the waste is avoidable, since the number of students eating on a given day follows a pattern.

From these, the team writes a single statement that everyone signs up to.

Table 11.10 – a vague statement and a scoped statement of the same problem | Feature | Vague statement | Scoped statement | |—|—|—| | What it says | The canteen wastes too much food | Predict, by 8 a.m. each working day, how many students will eat lunch that day | | Who it is for | Not stated | The cook, before cooking begins | | When the answer is needed | Not stated | Before 8 a.m., the same day | | How success is judged | Not stated | The prediction is within 20 servings of the actual count on at least four days out of five | | Can a team start work on it | No | Yes |

Look at the last two rows. A deadline of 8 a.m. rules out any design that needs the day’s attendance register, because that is not ready until half past nine. A success criterion of twenty servings is a decision the team makes with the cook — it is not a result, and nothing has yet been measured. Its purpose is to settle in advance what “good enough” means, so that the question is not argued about later when everyone is attached to the system they built.

Q. Why fix the success criterion now, before anything exists?

A. Because once a system is running, it is easy to look at whatever it produced and call that a success. A number agreed in advance, with the person who will use the system, keeps the judgement honest.

writing a solution where the problem should be What goes wrong: The team writes “we will build an app that uses AI to plan the canteen menu”. That is a description of what they want to build, not of what is wrong. The fix: State the problem so that it stays true even if the solution turns out to be something else entirely. If a wall chart of last year’s numbers solves the canteen’s problem, the scoped statement should still be correct — and the project should end there.

Scoping also settles what is out of scope. This project predicts how many students will eat, not what they should be served, not who ate what, and not whether the food was liked. Every one of those is a reasonable question, and each would need different data and a different system. Letting them creep in now is the surest way to finish none of them.

11.7.2 Data Acquisition

The scoped problem asks for one number by 8 a.m.: how many students will eat lunch today. Nothing can predict that number from nothing. The system needs a record of what happened on many past days, and that record has to include whatever makes one day different from another.

Data acquisition is the stage of collecting that record.

Deciding what to collect

Start from the question, not from what happens to be available. For the canteen, one column is fixed by the problem itself — the number of meals served — because that is the quantity to be predicted. A quantity a system is trained to predict is called the label, or the target.

The other columns are the features from 11.4: the measurements available before the prediction is needed. Here they might be the day of the week, the number of students present in school, whether it is raining, and whether the day carries a special event. Each one is a possible reason why one day differs from another, and each one is known before 8 a.m., which the label is not.

A collection of records organised in this way — one row per case, one column per feature, plus the label — is a dataset. Table 11.11 shows ten days from the canteen’s.

Table 11.11 – ten school days from the canteen dataset, with the features known each morning and the meals actually served | Date | Day | Students present | Raining | Special event | Meals served | |—|—|—|—|—|—| | 1 Aug | Monday | 420 | No | None | 351 | | 2 Aug | Tuesday | 415 | No | None | 349 | | 3 Aug | Wednesday | 408 | Yes | None | 372 | | 4 Aug | Thursday | 402 | No | Sports day | 268 | | 5 Aug | Friday | 418 | No | None | 351 | | 8 Aug | Monday | 425 | Yes | None | 388 | | 9 Aug | Tuesday | 410 | No | None | 344 | | 10 Aug | Wednesday | 412 | No | None | 350 | | 11 Aug | Thursday | 398 | Yes | None | 365 | | 12 Aug | Friday | 421 | No | None | 355 |

Notice what is not in the table. No student’s name, no class, no record of who ate. The problem asks for a count, and a count is all that is collected.

Where data comes from

Data for a project like this comes from a few kinds of source.

  1. Records that already exist. The canteen’s daily sale register and the school’s attendance summary between them supply most of Table 11.11.

  2. Data collected on purpose. If nobody has been noting whether it rained at lunchtime, someone starts noting it from tomorrow.

  3. Sensors. A counter at the canteen door, or a rain sensor on the roof, records a reading automatically each day.

  4. Surveys. Asking students on a sample of days whether they intended to eat in the canteen, to check whether the register is complete.

  5. Open datasets. Data published for anyone to use — a weather department’s daily rainfall record for the city, for instance — which saves collecting what someone has already collected properly.

Q. Could the team just use another school’s canteen data instead of collecting their own?

A. Only with great care. Another school has a different strength, timetable, menu and price, so its numbers describe its canteen and not this one. Borrowed data can be useful for getting started, but a system meant for this canteen has to be trained on this canteen’s record.

How much, and how representative

Ten rows are enough to look at in a book. They are nowhere near enough to build with. Two weeks of August contains no winter, no examination week, no festival, and only three rainy days. A system trained on it would meet its first cold January morning with nothing to go on.

The honest guide is coverage rather than a magic number: the data should contain examples of every kind of day the system will later be asked about. For a school canteen that means at least a full year, because the year is the cycle the school runs on.

The same applies to unusual days. Sports day appears once in Table 11.11, at 268 meals. One example of a rare case is not enough for anything to be learnt from it, which leaves the team a choice — collect several such days over a longer period, or decide during scoping that event days are handled by the cook and not by the system.

Data collected in a school is data about children. Collect only the columns the scoped problem needs, keep no names or identifying details when a count will do, tell the school and the students what is being collected and why, and store it where only the project team can reach it. Data gathered for the canteen should never be reused for a different purpose without asking again.

collecting everything available, in case it proves useful What goes wrong: The team exports every column the school’s software offers, including names, classes and fee records, reasoning that extra data cannot hurt. The fix: Extra data does hurt. It adds columns that have no bearing on lunch, it makes the dataset harder to check, and it puts personal information at risk for no gain. Collect what the scoped problem calls for, and go back for more only when exploration shows something is missing.

11.7.3 Data Exploration

A year of canteen records now sits in a file. It is tempting to move straight to building something. Almost every experienced team does the opposite, because data collected in the real world is never as tidy as the table it is stored in.

Data exploration is the stage of looking hard at the data before using it — first to find what is wrong with it, then to see what patterns it holds.

Finding what is wrong

Four problems turn up again and again. Table 11.12 shows one example of each, drawn from days that follow those in Table 11.11.

Table 11.12 – four problem rows found while exploring the canteen data | Date | Day | Students present | Raining | Special event | Meals served | What is wrong | |—|—|—|—|—|—|—| | 16 Aug | Tuesday | — | No | None | 347 | A value is missing | | 17 Aug | Wednesday | 411 | No | None | 3520 | Impossible: more meals than students, almost certainly a typing slip for 352 | | 18 Aug | Thursday | 405 | — | None | 358 | A value is missing | | 18 Aug | Thursday | 405 | No | None | 358 | The same day entered twice |

Each needs a decision, and the decision should be recorded. A missing value can be filled in from another record, or the row can be dropped. An impossible value can be corrected if the original register still exists, and dropped if it does not. A duplicate row is removed, because leaving it in makes that day count twice in everything calculated afterwards.

The test for “impossible” comes from thinking about what the column means. Meals served cannot exceed students present. Students present cannot exceed the school’s strength. Nothing can be negative. Checks like these are quick to apply and catch most typing errors.

Q. Why not simply fill every missing number with the average?

A. Because it invents a value and hides the gap. It is sometimes acceptable, but only when a few values are missing at random. If the rain column is blank for every day the office was shut early, filling it with an average buries a pattern rather than repairing one.

Looking for patterns

Once the data is clean, the useful question is which features actually relate to the label. Fig. 11.7-2 plots the ten days of Table 11.11.

Diagram

Fig. 11.7-2 – a bar chart drawn from Table 11.11. Dates 1 Aug to 12 Aug along the x-axis, meals served on the y-axis with a scale from 0 to 400. Bars for the three rainy days (3, 8 and 11 Aug) shaded darker and marked with a small rain symbol; the bar for 4 Aug marked “sports day” and clearly much shorter than the rest. A dotted horizontal line across the chart labelled “ordinary-day average”

Two things stand out immediately. The rainy bars are taller than the rest, and the sports day bar is far shorter. The first is worth measuring.

how much difference does rain make

Given: from Table 11.11, ordinary days with no rain and no event served 351, 349, 351, 344, 350 and 355 meals; rainy days served 372, 388 and 365 meals

Find: the average on each kind of day, and the difference between them

Working:

ordinary days total = 351 + 349 + 351 + 344 + 350 + 355 = 2100 meals

ordinary days average = 2100 ÷ 6 = 350 meals

rainy days total = 372 + 388 + 365 = 1125 meals

rainy days average = 1125 ÷ 3 = 375 meals

difference = 375 − 350 = 25 meals

350 meals on an ordinary day and 375 on a rainy day, a difference of 25 meals

Twenty-five meals is worth knowing. It suggests that rain belongs in the system, most likely because students who would otherwise eat outside stay in the building. Three rainy days are far too few to settle the matter, but they are enough to say the question deserves a full year of data.

The sports day figure of 268 is an outlier — a value that sits far away from the rest.

deleting every unusual value What goes wrong: The team sees 268 sitting well below every other day and removes it as a mistake. The fix: An outlier is not automatically an error. The special-event column explains this one: on sports day the timetable changed and most students left early. It is a genuine record of a real day, and removing it would hide exactly the kind of day the cook most needs warning about. Errors are removed; unusual truths are kept and explained.

Exploration also settles what the data cannot support. If the whole year contains four event days, no system can be expected to predict them well, and the honest response is to say so now — at the cost of a day’s work — rather than after the system has been installed in the canteen.

11.7.4 Modelling

Exploration has left the team with clean data and a couple of patterns worth using. What is still missing is the thing itself: something that takes this morning’s features — the day, the strength present, the rain, the event — and returns one number for the cook.

That something is a model.

NoteDefinition

(A model is the part of an AI system that takes a set of features as input and produces an answer, using a rule or a set of numbers worked out from data.)

Two ways to build one

The first way is to write the rule yourself, as in the expert system of 11.3. The second is to let the numbers be worked out from data, as the weights of a neural network are in 11.6.

For this project the first way is a good place to start, because exploration already handed the team a rule. Ordinary days averaged 350 meals and rainy days 375, so:

\[\text{predicted meals} = 350 + 25 \times r\]

Here \(r\) is 1 when rain is expected at lunchtime and 0 when it is not, and both 350 and 25 are the averages calculated in 11.7.3.

using the simple rule to predict two days

Given: the rule above, with 350 meals as the ordinary-day figure and 25 meals as the rain adjustment

Find: the prediction for an ordinary Tuesday with no event, and for a Wednesday with rain expected

Working:

ordinary Tuesday: r = 0, so predicted meals = 350 + 25 × 0 = 350 + 0 = 350 meals

rainy Wednesday: r = 1, so predicted meals = 350 + 25 × 1 = 350 + 25 = 375 meals

350 meals for the ordinary Tuesday and 375 meals for the rainy Wednesday

That is a complete model. It is crude — it ignores the day of the week, the strength present and every special event — but it can be worked out on paper, it can be explained to the cook in one sentence, and it gives the team a figure to beat. A first simple model used this way is called a baseline.

A learnt model comes next. Given a year of rows, a system of the kind described in 11.6 can set its own numbers for every feature at once, including combinations the team never thought of, such as rain mattering more on Mondays than on Fridays. This is where the extra accuracy usually comes from, and it is also where the ability to explain the answer is usually lost.

Q. If a learnt model is more accurate, why bother with the baseline at all?

A. Because “more accurate” has to be shown, not assumed. Without a baseline there is nothing to compare against, and a team can spend a month on a model that turns out to do no better than adding twenty-five for rain.

Keeping data aside

Whichever way the model is built, one decision has to be taken before building starts: not all the data may be used.

The rows are divided into two parts. The training data is what the model is built from. The test data is set aside, untouched, and shown to the model only at the end. A typical split keeps about four rows in five for training. For a school year of 200 recorded days that works out as 160 days for training and 40 days for testing, since 200 × 4 ÷ 5 = 160 and 200 − 160 = 40.

Fig. 11.7-3 shows the split.

Diagram

Fig. 11.7-3 – a long horizontal bar representing 200 rows of the dataset, divided into a large left part shaded one way and labelled “training data – 160 days – the model is built from these” and a smaller right part shaded differently and labelled “test data – 40 days – locked away until evaluation”. An arrow from the left part into a box labelled “model”, and a dotted arrow from the right part into the same box marked with a small clock icon and the words “only at the end”

The reason for locking data away is simple. A model asked about days it was built from will do well on them, in the same way that anyone can recite a passage they have just copied out. That tells you nothing about tomorrow, which is the only day the cook cares about. Judging the model needs days it has never seen, and that is the subject of 11.7.5.

reaching for the most complex model first What goes wrong: The team begins with a neural network, because that is the technique they have read most about. The fix: Start with the simplest model that could work and measure it. Complex models need far more data, take far longer to build, and cannot explain their answers. Move to one only when the measurement shows the simple model is not good enough.

11.7.5 Evaluation

The model is built. The 40 test days from 11.7.4 have been sitting untouched all this time. Evaluation is where they are finally used, to answer one question: how well does this model do on days it has never seen?

The question has to be asked this way round. A model checked on its training days is being asked about work it has already copied.

NoteDefinition

(Accuracy is the share of cases an AI system gets right when it is tested on data it has not seen before.)

The last part of that sentence is not a detail. A figure measured on training data is not accuracy in any useful sense, however impressive it looks.

Measuring the canteen model

Accuracy in its plain form suits a system that produces a label — a mango is bruised or it is not, so each answer is right or wrong and the share of right ones can be counted. The canteen model produces a number instead, and a number is rarely exactly right. So the team measures how far off it is, and uses the criterion agreed during scoping in 11.7.1: a prediction counts as good if it is within 20 meals of the actual count.

Table 11.13 shows ten of the test days.

Table 11.13 – ten test days, with the model’s prediction, the actual count, and the size of the miss | Test day | Raining | Predicted | Actual | Difference | |—|—|—|—|—| | 1 | No | 350 | 342 | 8 | | 2 | No | 350 | 361 | 11 | | 3 | Yes | 375 | 368 | 7 | | 4 | No | 350 | 349 | 1 | | 5 | No | 350 | 377 | 27 | | 6 | Yes | 375 | 391 | 16 | | 7 | No | 350 | 336 | 14 | | 8 | No | 350 | 352 | 2 | | 9 | No | 350 | 318 | 32 | | 10 | No | 350 | 358 | 8 |

The differences are written without a plus or minus sign, because for the cook a shortfall of 20 and a surplus of 20 are both misses of 20.

does the model meet the agreed criterion

Given: the ten test days of Table 11.13, and the criterion from 11.7.1 that a prediction is good if it is within 20 meals of the actual count

Find: the share of days meeting the criterion, and the average size of the miss

Working:

days within 20 meals: differences of 8, 11, 7, 1, 16, 14, 2 and 8 — that is 8 days

days over 20 meals: differences of 27 and 32 — that is 2 days

share meeting the criterion = 8 ÷ 10 = 0.8, which is 80%, or 4 days out of 5

total of all differences = 8 + 11 + 7 + 1 + 27 + 16 + 14 + 2 + 32 + 8 = 126 meals

average difference = 126 ÷ 10 = 12.6 meals

80% of test days meet the criterion, with an average miss of 12.6 meals

Fig. 11.7-4 shows the same result as a picture.

Diagram

Fig. 11.7-4 – a line and point chart. Test day 1 to 10 along the x-axis, meals on the y-axis. A line joining the predicted values (350, 350, 375, 350, 350, 375, 350, 350, 350, 350) and separate dots for the actual values from Table 11.13. A shaded band of 20 meals above and below the prediction line labelled “within the agreed 20 meals”. The dots for days 5 and 9 fall outside the band and are circled

Using the same ten days in Table 11.13, work out how many would still count as good if the criterion were tightened to within 10 meals. Then decide whether the cook would find the tighter criterion worth asking for.

Reading the result honestly

Four days out of five is exactly what was agreed, and it was agreed before anything was built, which is what makes it worth anything. But the figure alone is not the whole of evaluation.

Where the model failed matters as much as how often. Days 5 and 9 are both ordinary days, so rain does not explain them, and the team should look for what does — a class trip, perhaps, or a change in the menu. That is a finding, and it points straight back to 11.7.2, because the feature that would have caught it was never collected.

The size of the test matters too. Ten days is what a page can show; the model was evaluated on all 40, and even 40 is not many. A result on a handful of days can turn out differently on the next handful.

And the cost of each kind of miss matters. Predicting 30 too many wastes 30 meals. Predicting 30 too few sends 30 students away hungry. Those are not equally bad, and a criterion that treats them as equal — as this one does — may need rewriting with the canteen manager.

Q. The model reached the agreed figure. Is the project finished?

A. Not quite. The model still has to reach the cook by 8 a.m. in a form he will use, and it has to be checked again after some months, because a change in the timetable or the menu can make yesterday’s model wrong without anything appearing to break.

Evaluation ends with one of three decisions. Put the model into use, and keep watching it. Go back a stage — to modelling for a better model, to acquisition for the missing feature, or to scoping if the problem was stated wrongly. Or stop, and say plainly that the data does not support the system anyone hoped for. All three are proper outcomes of the cycle, and the third is far cheaper here than after the cook has been relying on it for a term.

11.8 Summary

  1. Artificial intelligence covers systems built to do jobs that normally need human intelligence. AI systems can be sorted by how wide a range of jobs they handle, and by whether anything like understanding is involved.
  2. Narrow AI is built and trained for one task, or a few closely related ones, and cannot work outside that task. Almost every AI system in daily use is narrow AI.
  3. “Narrow” describes the range of the job, not the quality of the work. A narrow system is often faster and steadier than a person within its own task.
  4. Broad AI, also called general AI, is the idea of a system that handles many different tasks, including ones it was not built for. It does not exist today.
  5. Weak AI produces intelligent-looking results by applying rules and patterns learnt from data, without understanding what those results mean. Narrow AI systems are weak AI.
  6. Strong AI is the idea of a system with human-level ability to reason, learn from its own experience and understand meaning. It remains a theoretical idea and has not been achieved.
  7. An expert system stores the knowledge of human experts in one field as facts and rules, and applies them to a user’s problem to give advice.
  8. An expert system has four parts: the knowledge base holding facts and rules, the inference engine that applies them, the user interface that asks and answers, and the explanation facility that reports which rules were used.
  9. Expert systems preserve scarce expertise, answer consistently and can explain themselves. They struggle with uncertain information, go out of date unless updated by hand, cannot capture expertise nobody can put into words, and do not learn from their own use.
  10. Eliza, written in the mid-1960s by Joseph Weizenbaum at MIT, is generally counted as the first chatbot. It replied by pattern matching, holding no knowledge of any subject, yet many users behaved as though it understood them.
  11. Computer vision takes images or video as input and extracts useful information from them. An image reaches the computer only as numbers, one per pixel for grey, three per pixel for colour.
  12. A computer vision system moves through image acquisition, pre-processing, feature extraction, and then the task itself: classification gives one label for the picture, detection gives a label and a position for each object, segmentation labels every pixel, and tracking follows an object across video frames.
  13. Natural language processing lets a computer take in human language, extract information from it, and produce language in return.
  14. Text is first cleaned: punctuation removed, case made uniform, the text split into tokens by tokenisation, and common stop words dropped. Later steps include part-of-speech tagging, parsing, named entity recognition, sentiment analysis, machine translation and language generation.
  15. NLP systems are weakest with sarcasm, long conversations, mixed languages, and any writing unlike what they were trained on.
  16. A neural network is made of small units called neurons, arranged in layers. Each neuron multiplies its inputs by the weights on its connections, adds the products, and passes the total through an activation function.
  17. A network is trained by passing examples forward, measuring the error with a loss function, and using back-propagation to adjust every weight slightly in the direction that reduces the error, repeated over many examples.
  18. Neural networks suit problems where a real pattern exists but nobody can state the rule. They need large amounts of labelled data and cannot explain an answer in a way a person can follow.
  19. The AI project framework, also called the AI project cycle, has five stages: Problem Scoping, Data Acquisition, Data Exploration, Modelling and Evaluation. It is drawn as a cycle because a later stage often sends the team back to an earlier one.
  20. Problem scoping states who is affected, what is happening, where and when, and why it matters, and fixes a measurable test of success before any building starts.
  21. Data acquisition collects the features known in advance and the label to be predicted, from existing records, purposeful collection, sensors, surveys or open datasets. Only the data the problem needs should be collected, and personal details should be left out.
  22. Data exploration checks the data for missing, impossible and duplicated values, and then looks for patterns. An outlier is not automatically an error, and errors are removed while unusual truths are kept and explained.
  23. A model turns a set of features into an answer, using either rules written by people or numbers worked out from data. A simple baseline model gives the team a figure to beat.
  24. Some rows are kept aside as test data and shown to the model only at the end, so that it can be judged on cases it has never seen.
  25. Accuracy is the share of cases a system gets right when tested on data it has not seen before. Evaluation also asks where the system failed, how large the test was, and whether different kinds of mistake cost the same.
  26. Evaluation ends in one of three decisions: put the system into use and keep watching it, go back to an earlier stage, or stop the project.

11.9 Key Terms

  1. Accuracy — the share of cases an AI system gets right when tested on data it has not seen before.
  2. Activation function — the calculation inside a neuron that decides, from the total of its weighted inputs, what the neuron sends onward.
  3. AI project cycle — another name for the AI project framework, used because a later stage often sends the team back to an earlier one.
  4. AI project framework — the ordered set of stages a team works through to build an AI system: Problem Scoping, Data Acquisition, Data Exploration, Modelling and Evaluation.
  5. Artificial intelligence (AI) — the branch of computer science that builds systems able to do jobs that normally need human intelligence.
  6. Back-propagation — the training step that works backwards from the loss to decide how each weight in a neural network should change.
  7. Broad AI — the idea of an AI system that can handle a wide range of different tasks, including ones it was not specially built for; also called general AI.
  8. Chatbot — a program that holds a conversation with a person in ordinary language, through typed text or speech.
  9. Computer vision (CV) — the branch of AI that takes images or video as input and extracts useful information from them.
  10. Dataset — a collection of records organised as one row per case and one column per feature, together with the label.
  11. Expert system — an AI system that stores the knowledge of human experts in one field as facts and rules, and applies them to a user’s problem to give advice.
  12. Explanation facility — the part of an expert system that reports which facts and rules led to its advice.
  13. Inference engine — the part of an expert system that matches known facts against stored rules and applies them until it reaches an action.
  14. Label — the quantity or category an AI system is trained to predict; also called the target.
  15. Loss function — the calculation that turns the gap between a network’s output and the correct label into a single number.
  16. Model — the part of an AI system that takes a set of features as input and produces an answer, using a rule or numbers worked out from data.
  17. Narrow AI — an AI system built and trained for a single task, or a small set of closely related tasks, and unable to work outside that task.
  18. Natural language processing (NLP) — the branch of AI that lets a computer take in human language as text or speech, extract information from it, and produce language in return.
  19. Neural network (NN) — an AI system made of small computing units arranged in layers, whose connection weights are adjusted from labelled examples until its outputs match the labels.
  20. Neuron — one small computing unit in a neural network, which multiplies its inputs by their weights, adds the products, and passes the total through an activation function.
  21. Pixel — one of the tiny squares that make up a stored image, holding one number for brightness in a grey image and three for colour.
  22. Sentiment analysis — the natural language processing task of deciding whether a piece of text is positive, negative or neutral.
  23. Stop words — very common words such as “the”, “was” and “and”, which appear in almost every sentence and are often removed before text is analysed.
  24. Strong AI — the idea of an AI system with human-level ability to reason, learn from experience and understand meaning across a wide range of subjects; also called general AI.
  25. Test data — the rows kept aside from training and shown to a model only at the end, so that it can be judged on cases it has never seen.
  26. Tokenisation — splitting a piece of text into separate words or pieces, each of which is called a token.
  27. Training data — the rows an AI model is built from.
  28. User interface — the part of an expert system that asks the user questions and presents the advice in ordinary language.
  29. Weak AI — an AI system that performs a task by applying rules and patterns learnt from data, without understanding the meaning of what it is doing.
  30. Weight — the number stored on a connection in a neural network, which sets how much that input counts towards the result.

11.10 Objective Questions

  1. (Which of these is an example of narrow AI?)

    1. A spam filter that sorts email into inbox and spam
    2. A system that can take up any task a person can take up
    3. A machine that understands the meaning of what it is doing
    4. A system that improves its own design without help

  2. (Fill in the blank: Splitting a piece of text into separate words or pieces is called ________.)

  3. (State whether true or false: A weak AI system can never perform a task better than a person can.)

  4. (Match each part of an expert system in Column A with its job in Column B.)

    Column A Column B
    a. Knowledge base i. Reports which rules led to the advice
    b. Inference engine ii. Asks the user questions and shows the advice
    c. User interface iii. Stores the facts and rules of the field
    d. Explanation facility iv. Applies the rules to the known facts

  5. (In a neural network, the number stored on a connection, which sets how much that input counts, is called the)

    1. label
    2. token
    3. weight
    4. pixel

  6. (A neuron receives two inputs, 0.4 and 0.5, on connections whose weights are 0.5 and 0.2. Write the total this neuron adds up before its activation function is applied.)

  7. (Fill in the blank: The stage of the AI project cycle in which a model is tested on data it has never seen before is called ________.)

11.11 Concept Questions

  1. (Define an expert system, and name its four parts.)

  2. (A face unlock program works faster and more reliably than a person checking photographs, yet it is called narrow AI. Explain what the word “narrow” is describing here.)

  3. (Differentiate between image classification and object detection, giving one example of a question each one is suited to.)

  4. (Give a reason why some rows of a dataset are kept aside as test data instead of using every row to build the model.)

  5. (A neuron has three inputs of 0.5, 0.2 and 0.8, on connections whose weights are 0.6, 0.5 and 0.5. Its activation function sends 1 if the total is 0.7 or more, and 0 otherwise. Work out the total and state what the neuron sends onward.)

  6. (An expert system used by a repair workshop has not had its knowledge base updated for five years. What could go wrong with the advice it gives, and why is the system itself unable to notice the problem?)

11.12 Case-Based Questions

  1. (A school library wants to know each morning how many books are likely to be issued that day, so that a helper can be arranged on busy days. Five days of records are shown below.)

    Day Students present Raining Books issued
    Monday 400 No 62
    Tuesday 395 No 58
    Wednesday 402 Yes 71
    Thursday 398 No 60
    Friday 405 Yes 75
    1. Which column is the label the system should predict, and which columns are the features it can use in the morning?
    2. Work out the average number of books issued on the two rainy days and on the three days without rain, and state the difference between the two averages.
    3. A team member suggests adding each borrower’s name and class to the dataset. State whether this should be done, and give one reason for your answer.

  2. (A farmers’ co-operative plans an app in which a farmer photographs a leaf and the app reports which disease the plant has. The photographs used to build the system were all taken on clear mornings, in bright sunlight, on one farm.)

    1. Which branch of AI does this app belong to, and name the three steps a system of this kind carries out before it produces its answer.
    2. Explain what is likely to happen when a farmer uses the app on a cloudy evening, or on a farm with different soil in the background.
    3. The app is to be given to farmers who will spend money on the treatment it names. Suggest two things the team should do so that a farmer is not misled by a wrong answer.