# Human-in-the-Loop Feedback

Designed points where a person reviews, corrects or approves system output, feeding judgement back into the system.

**Rests on:** Production Feedback Loops

*MLOps and Platform · MLOps*


## Why learn this

This concept is the bridge between a model that makes predictions and a system that improves because of them. Understanding human-in-the-loop feedback unlocks the later topics of Production Feedback Loops (turning corrections and ratings into training data) and Drift Detection (knowing when the model’s world has changed). It also prepares you for MLOps practices like canary releases, where a small human-reviewed slice of traffic tells you whether a new model is safe to roll out. Without this, every AI system you build will eventually make a wrong call with no one watching, and you won’t know how to fix it.


## The intuition

Imagine you run a small online clothing store. You have a model that suggests whether a returned item should be restocked or marked as damaged. The model is right most of the time, but sometimes it says 'restock' when the item is actually stained, or 'damaged' when it’s perfectly fine. Now, instead of letting the model’s decision go straight to the warehouse, you add a human reviewer — a person who looks at the model’s suggestion and either approves it, corrects it, or rejects it. That person’s judgement is not a one-time fix; it is a designed part of the system. Every correction they make is a signal that the model can learn from. If the model suggested 'restock' but the human says 'damaged', that is a piece of truth that should inform the next version of the model. The human is not an afterthought or a safety net; they are a component, like a sensor or a filter, that feeds judgement back into the system. The key is that this human review is not everywhere and always — it is placed at specific points where the cost of a mistake is high, or where the model is least certain. And because humans cannot review every single prediction, the system must decide which ones to show them, based on a sampling strategy. That strategy determines whether the review actually catches the mistakes that matter.


## An analogy

Think of a restaurant kitchen with a head chef and a trainee cook. The trainee prepares dishes, but before anything leaves the kitchen, the head chef tastes it and either lets it go or sends it back. The head chef is the human-in-the-loop. The trainee is the model — it gets better because the chef’s corrections teach it what 'too salty' means, what 'undercooked' looks like, and what the regular customer prefers. But here’s the catch: the chef cannot taste every single dish. There are hundreds of orders a night, and the chef has only two hands. So the kitchen decides: the chef will taste only the dishes that are new, or the ones where the trainee is most uncertain, or those from a random sample of orders. That sampling strategy is crucial. If the chef only tastes the dishes the trainee is confident about, the trainee will never learn from its mistakes. If the chef tastes everything, the kitchen slows down and the chef burns out. The chef’s capacity is the real constraint — it must be budgeted like any other resource. The analogy breaks down when you realise that the trainee cook, unlike a machine learning model, does not change its recipe instantly based on one correction. A model’s weights are updated after many corrections, usually during a training run, not in real time. Also, the head chef has intuition and common sense — the human reviewer does too, but the model only sees what the reviewer’s actions reveal, such as 'approved' or 'rejected'. The model never understands why, unless that reason is also captured.


## Definition

Human-in-the-loop feedback is the deliberate placement of points in an AI system where a person reviews, corrects, or approves the system’s output, so that their judgement is fed back as signal to improve the system.


## How it connects

You already understand the basic idea of a model making predictions. This concept extends that by adding a human reviewer into the flow. It connects directly to Production Feedback Loops, which are the broader channel that carries corrections and ratings back into training data. It also relates to Canary Releases, where a small slice of traffic is routed to a new model and human reviewers or automated metrics decide if it is safe to expand. In your library, this topic sits under MLOps, because operating a model in production is where human review matters most — during development you have all the time in the world, but in production the model’s output has consequences. You have not yet studied Drift Detection, but human review is one way to notice drift: if the human reviewer starts correcting the model far more often, that is a signal that the input distribution or the underlying relationship has changed.


## The mathematics

This concept’s mathematics is about counting and ratios, not about calculus or matrices. The branch is arithmetic — simple counting, percentages, and rates. The reason is that human-in-the-loop feedback is a resource allocation problem: you have a limited number of human reviews per hour or per day, and you must decide how to spend them. The core operation is the sampling rate. If you have 1000 predictions a day and you want to review 10% of them, you review 100. But it is not just about how many — it is about which ones. You decide based on a rule, such as 'review all predictions where the model’s confidence is below 0.6' or 'review a random 5% plus all rejected ones'. The mathematics of this is about proportions and how much signal you get from each review. Let us define that clearly. A sampling rate is simply a fraction: number of predictions reviewed divided by total predictions. If you review 100 out of 1000, the rate is 0.1, or 10%. That number tells you how many human hours you need. The other key calculation is the defect yield: the proportion of reviewed cases where the human disagrees with the model. If, out of 100 reviewed, the human corrects 20, the defect yield is 20%. That number tells you how often the model is wrong in the population you sampled. If your sampling is biased towards uncertain predictions, the defect yield will be higher than the true rate across all predictions, but it is a useful signal for where to focus training.

Let:
- T = total number of predictions per period
- r = sampling rate (a number between 0 and 1)
- R = number of predictions reviewed = T × r
- C = number of reviewed predictions the human corrects

The correction rate (sometimes called the human disagreement rate) is:

correction_rate = C / R

If you want to know how many human hours are needed, multiply R by the average time per review. For example, if each review takes 3 minutes and R = 200, then you need 600 minutes, or 10 hours, of human time per day.


## A worked example

```
A support chatbot handles 10,000 queries a day. The system is designed to show a human reviewer 2% of the conversations, but only those where the model’s confidence is below 0.7. You want to know how many reviews are needed per day and what the human correction rate is.

Step 1: Total predictions = 10,000   # This is the daily volume.
Step 2: Sampling rate = 2% = 0.02   # The designed fraction of total predictions to review.
Step 3: Number reviewed = 10,000 × 0.02 = 200   # Multiply total by the rate to get the count.
Step 4: Out of 200 reviewed, the human corrects 30, so correction rate = 30 / 200 = 0.15 = 15%   # The proportion of reviewed cases where the human disagreed with the model.

Result: You need 200 human reviews per day. The model’s accuracy on the reviewed subset is 85% (170 approved) — but remember this is a biased sample because you chose low-confidence cases, so this 85% is likely lower than the true accuracy across all 10,000.
```


## From scratch, in Python

We will write plain Python to simulate the sampling and review process. First, we need a few Python building blocks.

A **list** is an ordered collection that can be changed. For example, `predictions = [0.9, 0.4, 0.6]` is a list of three numbers.

A **dictionary** looks things up by name rather than by position. For example, `item = {'id': 123, 'confidence': 0.8, 'label': 'restock'}` stores three values under three names.

A **loop** repeats an action for each item in a list. `for p in predictions:` would run the following block for each element.

Now, here is the simulation:

```python
# Step 1: Create a list of predictions with confidence scores and labels
predictions = [
    {'id': 1, 'confidence': 0.9, 'label': 'restock'},
    {'id': 2, 'confidence': 0.5, 'label': 'restock'},
    {'id': 3, 'confidence': 0.3, 'label': 'damaged'},
    {'id': 4, 'confidence': 0.8, 'label': 'restock'},
    {'id': 5, 'confidence': 0.6, 'label': 'restock'},
]

# Step 2: Decide the sampling threshold. Review if confidence < 0.7
def should_review(pred):
    return pred['confidence'] < 0.7

# Step 3: Loop through all predictions and collect the ones to review
review_queue = []
for p in predictions:
    if should_review(p):
        review_queue.append(p)

# Step 4: Simulate the human review. Assume the human corrects any label that is 'restock' when the confidence is below 0.4
corrected = []
for p in review_queue:
    if p['confidence'] < 0.4:
        p['label'] = 'damaged'  # human corrects
        corrected.append(p)

# Step 5: Calculate the correction rate
review_count = len(review_queue)
correction_count = len(corrected)
if review_count > 0:
    correction_rate = correction_count / review_count
else:
    correction_rate = 0

print('Reviewed', review_count, 'out of', len(predictions))
print('Correction rate', correction_rate)
```

This prints: Reviewed 3 out of 5, Correction rate 0.666. The correction rate is high because the threshold selects only low-confidence cases.


## The same thing, with a framework

In production, you would not write this from scratch. You would use a workflow orchestration tool like Prefect or Airflow to schedule the sampling, send items to a human review queue, and collect the results. In Python, you might use a library like `random` for random sampling. Here is how you would randomly sample 2% of a large list:

```python
import random

all_predictions = [...]  # your full list
sample_size = int(0.02 * len(all_predictions))
review_sample = random.sample(all_predictions, sample_size)
```

Under the hood, `random.sample` does exactly what you would do by hand: it picks a fixed number of items from the list without repetition. The framework does not change the logic — it just wraps it in a reusable function.


## What the code does

Step 1 creates a list of dictionaries. Each dictionary represents one prediction: an ID, a confidence score between 0 and 1, and a label. Step 2 defines a function `should_review` that returns `True` if the confidence is below 0.7, meaning we want to review low-confidence predictions. Step 3 loops through the list and builds a new list `review_queue` of items that pass the test. Step 4 simulates the human: we assume the human corrects any item with confidence below 0.4, changing its label to 'damaged'. Step 5 calculates the correction rate by dividing the number of corrected items by the number of reviewed items. The key insight is that the correction rate depends entirely on the sampling rule. If we review only high-confidence predictions, we would see a low correction rate and think the model is perfect, but we would be missing the real errors.


## Common misconceptions

**Human review is a safety net, not a component** — We can deploy the model, and if it makes mistakes, we’ll have a human look at them later — that’s a safety net.

If the human review is not designed in from the start, there is no queue, no sampling rule, no capacity plan, and no feedback path. The human is overwhelmed, the feedback is ignored, and the model never improves. In fact: Human review is a designed component with explicit sampling, capacity, and feedback mechanisms, just like the model itself.

**Review the easy cases to save time** — We should review the predictions the model is confident about — those are the important ones because they drive decisions.

Reviewing confident predictions gives you no signal — the model is usually right there, so the human rarely corrects it. You waste reviewer effort on easy cases and miss the hard ones where the model is wrong. In fact: Sample strategically: review low-confidence predictions, random samples, or cases where the cost of error is high — this maximises the information gained per review.

**More human review is always better** — The best system reviews every single prediction — that way nothing slips through.

Reviewing everything is impossible at scale and it is also harmful: reviewer fatigue sets in, mistakes increase, and the system slows down. Capacity is a real constraint with a budget. In fact: Budget reviewer capacity like any resource. Choose a sampling rate that fits the capacity and captures enough signal to improve the model.

**The corrections are instantly absorbed into the model** — When the human corrects a prediction, the model immediately learns from it and changes its behaviour.

Models are updated in training runs, not per-correction. Corrections are collected, stored, and later used to fine-tune the model (or to create a better training set). In fact: Corrections accumulate as labelled data; they are used in a training loop, not live. The feedback loop has a delay that must be designed for.


## In short

Human-in-the-loop feedback means building specific points into an AI system where a person reviews, corrects, or approves output, and that judgement becomes data for improvement. Key points: (1) it is a designed component, not a safety net; (2) the sampling strategy decides what gets reviewed — choose low-confidence, random, or high-cost cases; (3) reviewer capacity is a real budget, so sampling rate and review time must be planned; (4) the correction rate is a key metric; (5) feedback is collected over time and used in training, not applied instantly. Without human-in-the-loop feedback, your model is flying blind in production.


## Where this is used

In **large language models (LLMs)**, human-in-the-loop feedback is central to fine-tuning. The most common method is Reinforcement Learning from Human Feedback (RLHF). Here, the model generates answers, and human reviewers rate them (e.g., on a scale of 1 to 5) or rank them against each other. These ratings are used to train a reward model — a second model that predicts what rating a human would give to any answer. The main LLM is then optimised to produce answers that score high on the reward model. In practice, the developer uses a framework like PyTorch or a platform like Anthropic’s Constitutional AI, but the core idea is the same: human judgement is turned into a numerical reward signal that guides the model’s weights. The sampling strategy in RLHF is crucial: you do not ask humans to rate every possible answer — that would be impossible. You sample a diverse set of prompts and responses, often using the model itself to generate candidate answers, and then get human rankings. A developer might use a library like `trl` (Transformers Reinforcement Learning) to implement this. If too few human reviews are collected, the reward model is noisy and the LLM learns the wrong things. If the review set is biased (e.g., only easy prompts), the model fails on hard cases.

In **small language models** running on devices (like a phone’s autocorrect or a smart speaker), human feedback is lighter but still present. The model might ask the user 'Was this helpful?' after a response, or the user can correct the transcription. On-device learning uses a method called on-device fine-tuning, where the corrections are stored locally and used to update a small model via gradient descent — but because devices have limited compute, the training is often done in chunks, e.g., every night when the device is charging. The developer writes code that collects the user’s corrections (e.g., a tap on a suggested word) and stores them in a local database, then runs a small training loop when the device is idle. The sampling strategy here is implicit: the system only reviews cases where the user actively corrected it, which is a form of selective sampling. The constraint is human patience — you cannot ask the user to review everything. This concept underlies the 'human-in-the-loop' features of products like Gboard and Siri.

In **retrieval-augmented generation (RAG)**, human feedback appears in the evaluation of retrieved documents. A RAG system retrieves a set of documents and then generates an answer. If the answer is wrong, a human can mark which retrieved document was misleading. That feedback is used to adjust the retrieval weights or to re-rank documents. The mechanism: the system logs the text chunks it retrieved, and the human’s correction ('this chunk is irrelevant') is fed back into a feedback loop that updates the retrieval model. A developer might use a tool like LlamaIndex, which provides callbacks for human evaluation. The sampling strategy is to review the top-k retrieved documents for a small percentage of queries, especially those where the generated answer has low confidence. If the human review is not included, the RAG system can confidently give wrong answers because it retrieved the wrong context.

In **agentic systems** — AI agents that plan, call tools, and act in loops — human-in-the-loop is a safety mechanism. An agent decides to take an action (e.g., send an email, book a flight, delete a file). A human must approve high-stakes actions before they are executed. The system is designed with 'approval gates': the agent pauses and asks the human for a yes/no. The developer implements this as a state machine: the agent’s output is checked, and if it exceeds a risk threshold (e.g., action involves money or personal data), it is routed to a human for approval. The human’s response is logged and fed back into the agent’s policy (e.g., via few-shot examples in the prompt). The constraint is latency: every approval slows the agent down, so the system must decide when to ask. A sampling strategy here is to ask only for actions with a risk score above a threshold, or for all actions in a new environment.

In **everyday applied ML** (recommendation systems, fraud detection, forecasting), human review is common for edge cases. For example, a fraud detection model flags a transaction, but a human investigator reviews it to confirm. The investigator’s decision (fraud or not) is fed back as labelled data. The sampling strategy is often to review only flagged transactions, but that creates a bias: the model never sees false negatives (missed fraud). To fix this, some systems sample a small random set of non-flagged transactions for review. The developer writes code to export flagged cases to a review queue, then imports the human decisions back into the training set. In forecasting, a human might adjust the model’s prediction (e.g., a weather forecaster tweaks the output), and that adjustment is used to recalibrate the model. The key point is that human review is not an afterthought — it is scheduled, budgeted, and tracked like any other process.

The library you have notes on: 'AI Algorithms and Their Practical Application' states that human review is a designed component, not an informal safety net. That means you plan for it, allocate resources for it, and measure its effectiveness — otherwise the feedback loop is broken. In practice, a developer uses tools like Label Studio for human labelling, or custom internal tools, and connects them to the model via APIs. What breaks when done badly: if the sampling strategy is wrong, the reviewer sees only easy cases and the model never learns from hard ones; if reviewer capacity is not budgeted, the queue backs up and feedback arrives too late to be useful; if the feedback is not versioned and logged, you cannot trace why the model improved or degraded.


---

Read this on the web: https://basavapurushottam.com/learn-ai/human-in-the-loop-feedback
