The N+1 approach to education

What should the next educational product be able to do?

First, personalised, one-to-one education. The familiar “two sigma problem” comes from the claim that individual tutoring can improve performance by two standard deviations compared with classroom teaching. We should be careful about treating that as a general effect. Even a much smaller gain — say, 0.7 standard deviations — would be substantial.

Second, an objective, measurable definition of success. We want to measure whether students learn more. Later, this becomes a necessary part of how we train the system, rather than just a way of checking the result.

Third, the ambition to teach beyond the level of a human tutor. Personalisation is the starting point; we want to explore how much better teaching can become. That is our goal, not a result we have already demonstrated.

And fourth, use all the forms of communication available to a tutor: text, pictures, video and real-time voice interaction. That is what I mean by multimodality.

The approach we are developing has a deliberately small name: N+1. We have something called N, and each time we take one more step.

How do we reach a goal one small step at a time?

Imagine a pathfinder: a robot on another planet, or an autonomous car trying to reach a destination in London. It has a global goal, but each action is small. Turn the steering wheel a little. Press the brake. Move forward.

The environment is too complicated to calculate the entire journey in advance. The agent has to work with what it can observe around it and choose the next action.

There is a similar intuition in gradient descent, a method for improving a mathematical objective. We have a complicated landscape and want to find a lower point. At each step, we use the local slope to decide which way to move.

Small steps, a larger goal. That is the intuition behind N+1. To turn it into a learning system, we need to explain reinforcement learning.

What is reinforcement learning?

Reinforcement learning is learning by trial and error. An agent takes an action in an environment, observes what happened and uses the result to improve its decisions.

A reward gives the agent feedback about how well things went. The goal is to maximise the reward accumulated over time. We care about the longer-term result, rather than only the immediate consequence of the next action.

The agent’s decision-making strategy is its policy. Learning means improving that policy: given what we know now, which action should we take?

There is also a balance between exploration and exploitation. Sometimes we try something unfamiliar to discover whether it works. Sometimes we choose the option that already looks best.

Of course, we cannot explore arbitrarily in every environment. We do not want a self-driving car trying random movements on a real street. Some experiments belong in a simulation.

Why think this could lead to a better tutor?

We have examples of reinforcement learning helping solve problems where the number of possible decisions is far too large to calculate exhaustively.

In 2016, AlphaGo defeated Lee Sedol at Go. In 2019, OpenAI Five reached championship-level performance in Dota 2, a game with a much more complicated, changing environment.

These systems improved through large amounts of training and simulated experience. That is why we think learning a decision-making policy is worth pursuing in education too.

It does not make education the same as Go or Dota. It gives us a reason to ask how a similar learning process might work for teaching.

What does a good one-to-one tutor do?

Now come back to education. A student visits a maths tutor because they want to do well in a university exam. The tutor knows mathematics and knows how to teach it. But they do not yet know this student.

What happens first? Probably a few questions. The student answers, and the tutor starts to work out what they understand and where the gaps are.

It makes little sense to teach everything from the beginning. The tutor needs a model of the student’s knowledge. They also keep some record of what happened: what the student did last time, what they struggled with, what went well.

Then the tutor chooses the next concept to teach and a task for that concept. The student attempts it. Their answer gives the tutor more information.

Choose a concept, give a task, observe the answer. Repeat until the student reaches the goal.

That gives us a useful starting point for the automated version.

What does the learning orchestrator do?

We start with a student and their learning history. That history includes anything from their previous learning that gives us information about their abilities.

Our first model is the learning orchestrator, which we can think of as a virtual tutor. Its job is simple to state: given the student’s history, generate the next best task.

The student tries the task. We record what happened — they succeeded, failed or showed a particular difficulty — and add that event to the history. Then the orchestrator chooses again.

Best according to what? Our global goal is to optimise the student’s subject knowledge at the end of the course.

For mathematics, that means mathematical knowledge. For language learning, it means knowledge of the language. We want the models to work across subjects, but our first product is an English-learning app, so that is where most of these examples come from.

How do we measure that knowledge?

For English, we already have established assessments such as IELTS, TOEFL, TOEIC and Cambridge exams. But they take a substantial amount of time — several hours for some of the tests shown here.

Can we expect someone using a mobile app to sit a serious, hours-long test every month? Probably not.

So we are developing a quick general-English test that takes around fifteen minutes. The purpose is to get a repeated measure of the learner’s progress, something we can use to see whether our teaching is helping.

There is a trade-off. A short test gives us less information and a noisier estimate. N+1 does not magically make a fifteen-minute test equivalent to a full exam.

We need a measurement that is useful for tracking progress and improving the teaching policy. Repeated results also give us data for training the other models in the system.

What exactly is the next task?

The next task has two parts: an activity and a concept.

The activity comes from an activity bank, a finite collection of task types we support in the product. We design those types using product and teaching expertise.

One activity might ask you to match a word to a picture. Another might play a one-minute explanation. Another might ask you to type a missing word into a sentence. It could also be a conversation with an LLM, guided by a prompt chosen for the lesson.

The concept is an item from the knowledge graph: the set of things we want to be able to teach in the subject. For English vocabulary, imagine all the words, idioms and phrasal verbs, with their different meanings.

In some subjects or domains, we might organise concepts with explicit relationships — for example, you need to understand one before learning another. In others, we might use a collection of concepts without defining relationships between them. It depends on how we want to organise that particular knowledge graph.

A dictionary gives us a concrete starting point. We can extend it with grammar rules, common mistakes and pronunciation concepts — the things a learner needs to master to use English well.

And this is why the approach is N+1. One student may have a long learning history; another may be starting from zero. Whatever their N is, we choose one more task, observe the result and continue.

Why do we need simulations?

Before introducing the second model, let’s return to reinforcement learning. What happens when a real experiment is too slow or too expensive?

In education, a single learning outcome can take months or years to observe. Across many experiments and many students, the time adds up quickly. In other settings, such as autonomous driving, some trial-and-error actions are unsuitable for the real world.

Simulation lets us run those experiments in a digital environment. Here is the robot-dog example from the talk.

At first, the model makes random movements. We measure how well it walks and use that feedback to improve its policy. After thousands of trials, useful patterns emerge.

The second example uses a humanoid-like character. Again, it starts with poor movements. Actions that produce better results receive a better reward, and repeated trials eventually produce a running gait.

Can we build something comparable for learning — a virtual student against which the tutor can practise?

What does the Knowledge Predictor predict?

Our second model is the Knowledge Predictor, which we also call a virtual student.

Give it a student’s learning history, and it estimates the probability that this student knows each concept in the knowledge graph. We get a model of what the learner is likely to understand and what they are likely to be missing.

Our aim is to use the two models together in simulation: train the orchestrator to teach the virtual student. You can think of the interaction between two chess-playing models during training, except that here one model is trying to teach the other.

We already have an early Knowledge Predictor. It is still fairly simple, and we expect to improve it as we collect more learner data. For simulation to be useful, its predictions must also capture how knowledge changes with teaching.

The model has another immediate job: handling the cold start, when a new learner arrives and we know very little about them.

We give them a short test. Those answers provide an initial history, and the predictor estimates likely gaps across the concept inventory. Now we have somewhere to start instead of teaching everything from the beginning.

Could an LLM do the prediction for us?

This is a knowledge-tracing problem: use a learner’s previous behaviour to estimate what they know. How well do ordinary, prompted LLMs do it?

The studies collected here show that they often struggle compared with much smaller models designed for knowledge tracing.

Studies in this comparison: Neshaei et al. (2024), Hooshyar et al. (2025), Bhattacharyya et al. (2026) and Huang et al. (2026).

DKT means deep knowledge tracing, using a neural network. BKT is Bayesian knowledge tracing, which uses a probabilistic model. Both are designed around the learner’s history.

In several of these comparisons, simply prompting an LLM produces much worse predictions. Fine-tuning — additional training for the task — helps, but can be costly, and often only brings the model closer to the specialised alternatives.

There are exceptions. On tutoring conversations, the trained LLM approach discussed in the research roundup beats classic knowledge-tracing comparisons. So we need to compare methods for the specific task, rather than assume that all LLMs behave the same way.

What if we ask the LLM to play a student instead? “Behave like a ten-year-old learning mathematics.”

The problem is that the model knows too much. It can change how it speaks without reproducing the gaps in a child’s understanding.

In the Norwegian reading-test study, the real pupils scored about 69%, while prompted models scored around 96–99%. Random guessing was closer to the real distribution of scores than those LLM personas. That is a comparison of score distributions, not a claim that random answers are more accurate. Read the student-simulation study ↗

We need a model of the learner’s actual knowledge and mistakes. A convincing student voice is not enough.

Where does the learner meet these concepts?

Think about the material people use outside a lesson. They watch Netflix, listen to music, read books and watch videos. In a second language, they constantly meet words and meanings they do not know.

The same applies to mathematics. A professor asks a student to read a textbook, and the student opens it to find concepts they have not yet understood.

That brings us to the third model: the concept extractor. It takes learning material and identifies the learning concepts needed to understand it.

Suppose a learner chooses a book from our database. The extractor identifies its concepts. The Knowledge Predictor estimates which of those concepts the learner does not yet know. We pass those gaps to the learning orchestrator, which chooses tasks to teach them.

The three models have different jobs, but they work together around the same learner and the same goal. This is the N+1 approach we are developing and using in Glite.

How do we build the extractor itself? That is the next part of the story, in Vassili’s article on finding learning concepts in material and student answers.