Intelligence creation
is the act of producing the programs, lookup tables, and models that map contexts to predictions. An effective intelligence-creation process will do all of the following:
- Produce intelligence that is accurate enough to achieve the system’s objectives. The meaning of “accurate enough” will vary from system to system. For example, if the intelligent experience is extremely forceful (automating actions that are hard to undo), the intelligence will need to be extremely accurate. On the other hand, if the experience is passive, a less accurate intelligence can succeed.
- Produce intelligence quickly enough to be meaningful. That is, if the underlying problem is changing rapidly, the intelligence-creation process will need to keep pace.
- Produce intelligence efficiently and reliably. That is, cost of growing the intelligence and maintaining it over the life-cycle of the Intelligent System should be reasonable. And the process for producing the intelligence should be robust to changes in staffing and to human error.
- Produce an intelligence that works with the implementation. It must not use too much CPU or RAM. It must be small enough to distribute to the places it needs to be distributed to. It must use inputs that are available at runtime—exactly as the user will use the system.
Intelligence creation is intrinsically iterative. Some of the main phases
that an intelligence creator will encounter are these:
- 1.Understanding the problem and environment
- 2.Defining success
- 3.Getting data
- 4.Getting ready to evaluate the intelligence
- 5.Building a simple baseline
- 6.Using machine learning
- 7.Assessing and iterating
This chapter will discuss these phases and explore an example of the intelligence-creation process.
An Example of Intelligence Creation: Blinker
Let’s walk through an example of intelligence creation: a blink detector.
Imagine you need to build
an Intelligent System that determines whether an eye is open or closed. Maybe your application is authenticating users by recognizing their irises, so you want to filter out closed eyes and let the iris intelligence focus on irises. Or maybe you are building a new dating app where users wink at the profiles of the users they’d like to meet. Or maybe you’re building a horror game and want to penalize users when they close their eyes.
Understanding the Environment
The first step in every applied intelligence-creation project is to understand what you are trying to do.
Detect a blink, right? I mean, what part of “detect a blink” is confusing?
Well, nothing. But there are some additional things you’ll need to know to succeed. These should be familiar if you’ve read the rest of the book up to this point (and didn’t just jump to the “intelligence creation” chapter because you were looking for the “good stuff”). But, no matter how you got here, it’s worth walking through these questions in the context of an example.
Important questions
about the environment where the intelligence must operate include:
- Where will the input will come from? What kind of sensor will the eye images come from? Will the image source be standardized or will different users have different cameras? Does the camera exist now or is it something new (such as something embedded in a new phone that is under development)?
- What form will the input take? Will it be a single image? A short video clip? An ongoing live feed of video? How will the input (image or clip) that the intelligence must act on be selected among all possible images or clips that the sensor is capturing?
- Where will the product be used? Will it be used on desktop computers? Laptops? Indoors? Outdoors? Will there be some calibration to help users get their devices set up correctly or will you have to work with the data however it comes in (for example, if the user has their camera upside down, or a very strong back light, or some kind of smear on the lens)?
- How will the input be modified? Will the images get any pre-processing? For example, maybe there is some “low light” sensor-mode that kicks in sometimes and changes the way the camera works. Maybe there is some automatic contrast or color correction in the firmware. Maybe frames with no human faces are dropped out, or maybe the locations of eyes are marked ahead of time by some other system component.
- How will the system use the blink output? Should the output of the intelligence be a classification (that is, a flag that is true if the eye is closed and false if it is opened)? Should the output be a probability (1.0 if the eye is closed, and 0.0 if the eye is opened)? Should the output be a regression that indicates the degree of openness of the eye (1 if the eye is fully open, 0.5 if the eye is half open)? Or should the output be something else?
- What type of resources can the blink detector use? How much RAM is available for the model? How much CPU can it consume per invocation? What are the latency requirements from receiving the input to producing the output?
That’s a lot of questions before even getting started, and the answers are important. It should be possible to make a blink detector no matter how these questions are answered, but the work you’ll need to do will be very different.
In fact, the problem will be much harder for some combinations of answers than other. Consider: building a blink detector that works in a carefully controlled kiosk in a store with essentially unlimited computation; compared to building a blink detector that has to work indoors and outdoors on a sensor that doesn’t exist yet (so you can only get data off a buggy prototype) and you have 4MB of RAM for the model and must give answers in 2ms or less on a low-powered CPU.
Both of these settings require blink detectors—one will be much harder to build intelligence for than the other.
Sometimes there is flexibility in how these questions are answered, and having discussions with other team members can help. Maybe a few things are set in stone (like where the product will be used) but others are open for negotiation (like how many resources the intelligence can use). Your job as intelligence creator will be to identify how these answers impact the potential intelligence quality and influence the team to set the overall project up for success.
Define Success
To succeed, the blink detector will need to be accurate. But how accurate? This depends on what the intelligence will be used for. At this point you’ll need to consider the intelligent experience and how various levels of accuracy will change the way users perceive the overall system. Questions include:
- How many mistakes will a user see per day?
- How many successful interactions will they have per unsuccessful interaction?
- How costly are the mistakes to the user?
This will probably involve discussions with the people creating the intelligent experience (and if you are responsible for both the intelligence and the experience you might have to talk to yourself, no matter how silly it makes you feel). Come up with some options for how accuracy and experience will interact, how users will perceive the mistakes, and how will they be able to work around them.
And remember: intelligence can make all types of mistakes. It is important to know which types of mistakes are right for the blink-detector, and get consensus on what tradeoffs are right for the project.
For example, an intelligence might say the eye is open when it isn’t, or it might say the eye is closed when it isn’t. Which types of mistakes will work for your system?
For the iris-login system, the blink detector is trying to find clean frames for the iris detector
. This system needs to weed out as many closed-eyed images as possible—whenever it says the eye is open, that eye better be open!
For the horror-game system
, the blink detector is trying to add some tension when the player closes their eyes. It doesn’t want to add tension at the wrong times—whenever it says the eye is closed, that eye better be closed!
During the intelligence-creation process there will be decisions that tend to make the resulting model better at one type of mistake or the other—knowing where you are going ahead of time can really help. And it’s good to get everyone’s expectations set correctly—you don’t want the experience designers to have a different idea about the types of mistakes the intelligence will make than the intelligence creators.
Get Data
Data is critical to creating
intelligence. At a minimum, you need enough data to understand the problem and to evaluate some simple bootstrap intelligence to make sure it is effective. If you want to do machine learning right out of the gate, you’ll need lots of training data too. There are two distinct ways
to think about the problem of getting data:
- 1.How to get data to bootstrap the intelligence.
- 2.How to get data from users as they use the system.
And recall from our chapters on getting data from experience and on telemetry—the data needs to be unbiased, and it needs to be a good sample of what users will encounter as they interact with your Intelligent System.
Bootstrap Data
There are many ways to get data to bootstrap your intelligence creation; here are a couple that would work for blink-detection
:
- Find data on the web: Search the web and download images of people’s faces that are a good match for the sensor the blink-detector will be using (resolution, distance to the eye, and so on). Then pay people to separate the images into ones where the eye is opened and ones where it is closed.
- Collect your own data: Take a camera (that is a good match to the one the system will need to run on) to a few hundred people, have them look into the camera and close and open their eyes according to some script that gets you the data you need.
- Find or buy a nice data set: Lots of people do computer vision. Someone has probably built a data set of images of eyes before. Maybe you can find a public dataset or a company willing to sell a nicely curated data set.
The amount of data needed for bootstrapping will depend on the difficulty of the problem. In the case of computer vision
, my intuition is that you could:
- Attempt a blink detector with thousands of images, but it wouldn’t be very good.
- Create a usable blink detector with tens of thousands of images, probably.
- Get increasing accuracy as you scale to hundreds of thousands or millions of images, but you will start to hit diminishing returns.
One good practice is to create intelligence on successively larger sets of data to get a sense of the return on investment in gathering data. This is called a
learning curve
. Build a model on 100 images, and evaluate it. Then build on 500 images and evaluate. Then on 1000… You can see how much it helps to add data, and use that information to make a decision about how much to spend on gathering bootstrap data.
Data from Usage
A well-functioning Intelligent System will produce its own training data as users use it. But this isn’t always easy to get right. At this point it’s a good idea to work with the experience designers to come up with a strategy. In the blink-detector case some options
include:
- Tie data collection to the performance task: For example, in the iris-login system, when the user successfully logs in with the iris system, that is an example of a frame that works well for iris login. When the user is unable to log in with their iris (and has to type their password instead), that is a good example of a frame that should be weeded out by the intelligence.
- Creating a data collection experience: For example, maybe a setup experience that has users register with the system, get their device set up correctly, and open and close their eyes so the system can calibrate (and capture training data in the process). Or maybe there is a tutorial in the game that makes users open and close their eyes at specific times and verify their eyes are in the right state with a mouse-click (and capture training data).
Again, an ideal data-creation
experience will be transparent to users, or will have user incentive aligned with your data requirements. The data creation will happen often enough that the amount of data collected will be meaningful to the intelligence. And it shouldn’t be creepy or invade user’s privacy.
Get Ready to Evaluate
With data in hand, you are almost ready to begin creating intelligence. But you won’t get very far without being able to evaluate the intelligence you create. When doing intelligence creation you should repeat this mantra: evaluation is creation. And you should repeat it often. Here are some steps for evaluating intelligence
:
- 1.Set aside data for evaluation: Make sure there is enough set aside, and the data you set aside is reasonably independent of the data you’ll use to create the intelligence. In the blink-detector case you might like to partition by user (all the images from the same person are either used to create intelligence or to evaluate it), and you might like to create sub-population evaluation sets for: users with glasses, ethnicity, gender, and age.
- 2.Create framework to run the evaluation: That is, a framework to take an “intelligence” and execute it on the test data exactly as it will be executed in the Intelligent System’s runtime. Exactly. The. Same. And you should verify that it is the same, carefully.
- 3.Generate reports on intelligence quality automatically: that can be used to know:
- How accurate the intelligence is.
- If it is making the right types of mistakes or the wrong ones.
- If there is any subpopulation the accuracy is significantly worse on.
- Some of the worst mistakes it is making.
- How the intelligence is progressing over time (the rate of improvement).
The easier the evaluation is to run, the better. Leaving everything to manual labor can work, but a little investment up front in tools to help evaluate intelligence can really pay off in quality (and in sanity).
Simple Heuristics
Creating a very simple heuristic intelligence
can help in a number of ways:
- 1.It can help you make sure the problem is actually hard (because if your heuristic intelligence solves the problem you can stop right away, saving time and money).
- 2.It can get you thinking about the types of challenges inherent in the problem, to understand the data, and to start thinking about the types of features, data, and telemetry that will help make intelligence successful.
- 3.It can create a baseline to compare with more advanced techniques—if your intelligence is complex, expensive, and barely improves over a simple heuristic, you might not be on the right track.
This step is somewhat optional, but it can be very useful to get oriented and debug the rest of the tools and data before letting more complex (and harder-to-understand) intelligences into the mix.
In the case of blink-detection you might try:
- 1.Measuring gradients in the image in horizontal and vertical directions, because the shape of the eye changes when eyes are opened and closed.
- 2.Measuring the color of the pixels and comparing them to common “eye” and “skin” colors, because if you see a lot of “eye” color the eye is probably open, and if you see a lot of “skin color” the eye probably closed.
- 3.Fitting an ellipse in the middle of the image, because if there is a good fit of an irises shape gradient in your image the eye is probably open, if not, the eye might be closed.
Then you might set thresholds on these measurements and make a simple combination of these detectors, like letting each of them vote “open” or “closed” and going with the majority decision.
Would it work well enough to ship to users? No way. But it’s a start.
Also note that computer vision
is a big field with lots of techniques. If you have computer vision experience your heuristics will be more sophisticated. If you don’t have computer vision experience your heuristics might be as bad as mine. Don’t be afraid. Come up with some ideas, give them a try, and get that intelligence train rolling.
Machine Learning
Now it’s time to go big on creating the intelligence. And this almost certainly means machine
learning. There are a lot of things you could try. But sometimes it’s best to start simple. Find whatever the simplest “standard” approach
is for the type of problem you’re working with. And keep in mind that standards change. For example, roughly:
- About ten years before this book was written a very reasonable approach for blink-detection would have been this: searching for specific patterns in the image, finding where they match the image well, and then building a model where all the patterns that are detected get to vote (with some weight) on the answer.About five years before this book was written a very reasonable approach for blink-detection might have been: using huge collections of decision trees that compare very simple properties of the images (like the differences in pixel intensities at pre-determined spots).
- And at the time of this writing a very reasonable approach for blink-detection (if you have a lot of training data) would be to: use complex artificial neural networks that process raw pixel values with no (or very little) pre-processing.
And five years after this book? Who knows. To the Intelligent System (and to the rest of the approach described in this book) it doesn’t matter what machine learning technique you use, as long as the resulting model can execute appropriately in the runtime. Find a modern machine-learning toolkit
. Read a few web pages. Try the easiest thing to try with the current tools (or maybe the easiest few things). Don’t spend a ton of time, not yet. Just get something that works.
Understanding the Tradeoffs
At this point you might want to do some investigation to help design the right implementation. This is a process of exploring constraints and tradeoffs
. Answering questions like these:
- How does the intelligence quality scale with computation in the runtime?
- How far can the intelligence get with a specific RAM limit?
- How many times will we need to plan to update the intelligence per week?
- How much gain does the system get from adding particular items to the context, especially the ones that are most expensive to implement?
- What is the end-to-end latency of executing the intelligence on a specific hardware setup?
- What are the categories of worst customer-impacting mistakes the intelligence will probably make?
The answers to these questions will help decide where the intelligence should live, what support systems to build, how to tune the experiences, and more.
Flexibility
is key. For example, the implementation can have extra code to hide latency. It can have alternate experiences for mitigating mistakes. It can be set up to push new intelligence all over the world every 15 minutes. But these things can be quite expensive. Sometimes a small change to the intelligence—which model to use, what features to consider, how aggressive to be—can solve problems more elegantly, resulting in a better overall system.
Assess and Iterate
Now it’s time to take a deep breath. Look at where you are, the quality of the intelligence, how much you’ve improved from your heuristic intelligence (or from the previous iteration), and think about what to do.
There will be plenty of ways to improve. You could try more or different data. You could try more sophisticated contexts (and features that you extract from them). You could try more complex machine learning. You could improve your evaluation framework. You could try to change people’s minds about the viability of the system’s objectives. You could try influencing the experience to work better with the types of mistakes you are making.
And then you iterate
and iterate and iterate. This part of the process could be done quickly, if conditions are right, or it could go on for months or years (or decades) for a very hard, very important problem.
Maturity in Intelligence Creation
An Intelligent System may live over many years. It may be improved many times. It may be maintained by people other than you, by people you don’t even know yet. Here are some stages of maturity
that your intelligence creation might go through:
- You did it once: You produced a useful intelligence that can ship to customers, but in the process you did a lot of exploring, produced a lot of scripts, edited them, made a bit of a mess. Recreating the intelligence would require some work.
- You can redo it if you have to: You produced the intelligence and have a reasonable record of what you did. You could retrace your steps and reproduce the same intelligence in a reasonable amount of time. Or better yet, someone else could pick up your documentation, trace your steps, and produce the exact same intelligence you did.
- You can redo it easily: You produced the intelligence and have some nice tools and scripts that can do all the steps of producing the intelligence again. Maybe the scripts get new telemetry, process it, move it to a computation environment, build the model, and produce charts that show how well the new intelligence will perform — all with the touch of a button.
- It redoes itself: You built a system that automatically reproduces the intelligence on a regular basis and drops the new intelligence in a known place, with quality reports emailed to the right people.
- It redoes itself and deploys if appropriate: Your system that automates intelligence production also automates deployment. It has tests that sanity-check everything. It knows how to send out new intelligence, roll it out to more and more customers, and will back out and alert orchestrators if anything goes wrong.
In building an Intelligent System you will probably start at the low-end of this maturity spectrum
and you will probably end near the higher end. Full automation isn’t always worth implementing, but for open-ended or time-changing problems it might be. Overall, the goal is to develop the lowest-cost way of maintaining intelligence at the quality required to enable the Intelligent System to achieve its objectives.
Being Excellent at Intelligence Creation
As with most human endeavors — the people who are best at intelligence creation are way, way better than the people who are average at it.
In addition to basic programming skills and data science skills, good intelligence creators
have several skills:
- Data debugging
- Verification-based approach
- Intuition with the toolbox
- Math (?)
This section looks at all of these requirements.
Data Debugging
Intelligence creation requires a mentality to look at data and figure out what is going on. What is the data trying to say? What stories are hidden in it?
This can be very tedious work. Kind of like being a detective, piecing together clues to figure out what happened.
Sometimes tracking a small discrepancy (for example, that some number seems to be coming up 0 more often than you expected) can lead to a big improvement. Maybe it’s a sign of an important bug. Maybe it’s an indication that someone made incorrect assumptions somewhere in the implementation. Maybe it’s a hint that the model is confused in a particular way, and a different approach would work better.
Not everyone has a data debugging mentality. Most people want to shrug and say, “that just happens 1% of the time, how big a deal could it be?” Having a bias for tracking unexpected/interesting things in data, and the experience to know when to stop, are critical for excellence in intelligence creation.
Verification-Based Approach
At its core, intelligence creation is about exploring many different possibilities and picking the one that is best. So it’s kind of important to be able to tell which is actually best.
One part of this is figuring out which tests you can run to tell if an intelligence will actually meet the system’s goals. This requires some basic statistical understanding (or intuition) and some customer empathy to connect numbers to customer experiences.
Another aspect of a verification-based approach
is to make it as easy as possible to compare candidate intelligences with one another. In fact one of the longest chapters in this book is titled “Evaluating Intelligence” and it is coming up soon. If the thought of reading a long, long chapter on evaluating intelligence makes you a little bit sad inside… intelligence creation might not be for you.
Intuition with the Toolbox
You also need a deep understanding of some of the intelligence-creation tools
, including machine-learning models and feature-generation approaches.
Intelligence-creation tools can be temperamental. They won’t tell you what’s wrong, and every approach is different. Techniques that work well with one machine-learning algorithm may not work with another. It’s important to develop the intuition to be able to look at an intelligence-creation tool, the output, and the situation, and know what to change to make progress.
This skill is a little like EQ (Emotional IQ) but for machine learning (MQ?). It’s like having someone sitting in the room with you, and you need to read their body language, read between the lines of what they are saying, and figure out if they are mad, and why, and what you could do to make it better.
Sometimes, that’s what intelligence creation is like.
Math (?)
And then there is math. Much of machine learning was created by math-first thinkers. Because of this, much of machine learning training is done in a math-first way. But I think advanced math is optional for excellent applied machine learning.
Really?
Yeah, I think so.
Machine learning is like most human tools—our cars, our cell phones, our computers, our jet fighters—the person operating them doesn’t need to understand everything it took to build them. I’m sure the world’s best jet fighter pilots can’t work all the math it takes to design a modern fighter jet. But put an engineer who could work that math into a jet, and let them dogfight with an ace fighter pilot…
Who do you think is going to win?
A bit of knowledge of the inner workings of machine learning algorithms might help you develop intuition, or it might not. Follow your strengths. Don’t sweat what you can’t control.
You might end up being the next machine learning ace.
Summary
Applied intelligence creation is an iterative process. The main steps are:
- 1.Understanding the environment
- 2.Defining success
- 3.Getting data
- 4.Getting ready to evaluate
- 5.Trying simple heuristics
- 6.Trying simple machine learning
- 7.Assessing and iterating until you succeed
The specific intelligence building techniques (especially the machine learning based ones) can vary over time, and from problem-domain to problem-domain. But the basic workflow outlined here should remain fairly stable over time.
Spending time automating these steps can be very useful, especially as you find yourself carrying out more and more iteration.
And remember—verify, verify, verify.
For Thought…
After reading this chapter, you should:
- Be able to create intelligence end-to-end.
- Understand the types of questions, challenges, and activities that will occupy the intelligence-creator’s time.
Youshould be able to answer questions like these:
- Choose your favorite Intelligent System and walk through the seven steps of the intelligence creation process described in this chapter. What questions would be relevant to your Intelligent System? How would you define success? How would you find data? How would you evaluate? What heuristic intelligence would you try? And what would some standard, simple machine learning approaches be?