What is Imitation Learning?

Imitation learning covers the methods that learn from demonstrations instead of from a reward signal. The simplest is behavioral cloning: treat each demonstration as a set of observation-and-action pairs and train the policy as ordinary supervised learning. It works, and it fails in one specific way. The policy only ever sees the states the demonstrator visited, so the moment it drifts slightly off that path it meets a situation it was never trained on, decides badly, drifts further, and the error compounds. A long task then fails even though every individual decision was nearly right.

The standard answers to that are worth knowing because each one changes the data you need. DAgger runs the policy, asks the expert to label the states the policy actually reached, and retrains on the combined set. It targets the drift directly, and it needs an expert available for repeated rounds rather than one recording session. Diffusion policy sidesteps a different problem: when the same scene admits several valid actions, averaging them during training yields an action valid for none of them, so instead of regressing a single action it models the distribution and samples from it. Action chunking predicts a short sequence of actions at once, which reduces how often the policy gets a fresh chance to make a mistake.

The data consequence is that coverage and consistency beat volume. Ten thousand demonstrations of the same grasp teach one grasp very thoroughly; the demonstrations carrying real information are the ones where the object sat awkwardly, the first attempt failed, or the operator had to correct. Most collection pipelines discard exactly those. If a project is being specified for imitation learning, the brief should say how failure and recovery episodes are handled (kept, labeled, or dropped), because that decision gets made by default during collection and is expensive to reverse afterwards.

Where imitation learning is applied

Manipulation is the core case: picking, placing, inserting, assembling and handling objects that deform. Wherever a task involves contact and small corrections, imitation is usually the default approach. Insertion and assembly are the standard examples, because a scripted controller cannot absorb the small variations that a human corrects without thinking about them. The data these tasks need is demonstration episodes, from teleoperation or from an operator physically guiding the arm.

Locomotion and whole-body control are the second area, mostly learned in simulation. Humanoid and quadruped gaits are commonly trained by imitating reference motion, often retargeted from motion capture, where the policy copies the style of the human movement while the physics engine handles balance. The demonstrations here are motion clips rather than task episodes.

Driving and navigation are the third. Steering and path behavior learned from human driving logs is imitation in all but name, with one structural difference: the demonstrations are long continuous recordings rather than repeated attempts, so the coverage question becomes which roads, weather and traffic conditions appear in the logs rather than how many attempts of one task were captured.

How the data spec changes

The demonstrator is part of the specification. A policy imitates whoever recorded the data, habits and mistakes included, so the skill of the operator sets the ceiling on what the policy can reach. For a task with a right and a wrong technique, the brief should name who demonstrates and require the correct technique in the guideline.

Operator consistency is the second choice to make. One operator across every episode of a task gives clean, consistent demonstrations and a narrow style; several operators give variety that the policy has to average out. Neither is wrong, but the mix should be deliberate. When it is left to whoever was free that day, the behavior of the set becomes hard to predict.

The third question is how many demonstrations, and the honest way to set the number is a pilot rather than a formula. Collect a small batch, train, and look at where the policy fails; if the failures cluster on one object or one lighting condition, the next batch should target that rather than repeat the same task. Fix the evaluation protocol, start states and success criteria, before collection begins.