Trained models (Classic ML)

In one line. Three Studio pages — AI Models, AI Pipeline and Prediction Report — that let you train and improve the platform’s own extraction models from the corrections your reviewers make. You’ll be able to. Recognise when to train an AI Model instead of leaning on a language model agent, trigger a training run from corrected documents, read an accuracy report to decide if a model is good enough, and chain models into a pipeline. Where this lives. Studio > Agents > Classic ML — three entries: AI Models, AI Pipeline, Prediction Report.

The menu lists them in that order. This page covers them in learning order instead — AI Models (train one), then Prediction Report (judge it), then AI Pipeline (the advanced one you may never need).

Why it matters

There are two kinds of “model” on this platform, and Classic ML is about the one people forget. A language model (A2 · LLMs & services) is general-purpose: you prompt it, it reasons from instructions, and it never learns from you. An AI Model is the platform’s own trainable extractor: it starts knowing nothing about your documents and gets better every time a reviewer corrects a field. The language model is hired talent; the AI Model is an apprentice you train on the job.

Watch out — the word “model” is overloaded. Throughout this page, AI Model means the trainable extraction model (a training job owned by a Learner). It is not the language model that powers a chat agent. When in doubt: a language model is chosen on an agent’s Model tab; an AI Model is trained here, under Classic ML.

The learning loop

You have met every piece of this loop in S2 · Core concepts, E3 · Document detail, and D1 · Collections & schema. Classic ML is where it closes:

   Documents             Reviewer corrects            Learner
   extracted by   --->   fields on the        --->   (owns the Labels
   an agent              Document Detail             and the AI Model)
                         Training pane                     |  train
                                                           v
   Accuracy goes up  <---  re-predict  <---   AI MODEL (V1 -> V2 -> V3)
   (Prediction Report)     future docs        a trained extractor

Read it clockwise: an agent extracts fields against the schema (the Learner and its Labels/Fields). A reviewer reads the document and corrects the wrong values in the Training pane — and every correction saves back to the label. Those corrected documents are the labelled examples an AI Model trains on. After training, the model predicts future documents more accurately, and a Prediction Report tells you by how much.

Each correction is saved against its field. Training uses those corrected documents as examples and produces a new version of the model (V1 → V2 → V3). The language model behind your agents is untouched by any of this.

When to train an AI Model vs. just use the agent

Reach for…	When…
An agent alone (A3)	You’re starting out, volumes are low, document layouts vary wildly, or the field needs reasoning/judgement. The agent is good out-of-the-box and needs no training data.
A trained AI Model	You have a repeating, high-volume document type (the same invoice layouts, the same form), you’ve already corrected dozens of them, and you want faster, cheaper, more consistent extraction that improves measurably over time.

In practice you use both: the agent gets you running on day one and generates the first corrections; once you have a corpus of corrected documents, you train an AI Model to specialise. You do not have to choose up front.

AI Models

Browse, inspect, and train the platform’s extractors — organised by Learner, with full version history. The page uses the standard Studio list + detail split: a left rail of models (grouped by the Taxonomy / Learner you filter to) and a right detail panel of read-only rows for the selected model. Each list row shows the model name, a version chip (V1/V2…), a relative time, and a status icon whose tooltip tells you the last training result — succeeded, failed, or still running. When training succeeded, the detail panel shows a Metrics row; a failed run surfaces the failure reason in the tooltip.

What every control does

Control	What it does	Notes
Taxonomy filter (header dropdown)	Scopes the list to one Learner (or “All Taxonomy”).	Every model belongs to a Learner.
Refresh	Re-fetches the list.	Use after a training run finishes.
Model row	One trained extractor: name + version chip + relative time + status icon.
N Past Versions (expander)	Lists prior versions of a multi-version model; each is selectable to inspect.	Versioning is how the learning loop is recorded over time.
+ Model	Opens the training form — start a new training run from your corrected documents.	The main way to train. If the button isn’t there, your access doesn’t allow it.
Upload	Imports a model trained elsewhere instead of training one here.	For offline / externally-trained models.
Load more	Pages in more models.
⋮ menu	Create Taxonomy out of this model (when training succeeded) · Push model to children (when the model is exported).	Version/manage actions live here.

The detail panel has many conditional rows — only those relevant to the selected model show. The ones you’ll read most often:

Detail row	Tells you
Model Name (+ version)	Which model and which version you’re inspecting.
Type (chips)	What it does: Classification, Extraction, Numerical, plus modifiers like Rich Text Included, Dataset only, Imported Model.
Labels Included / Mapped Label Names	Which Fields this model predicts, and how they map to its internal names.
Predicted Segments / Stages	Where in the document and lifecycle it operates.
Neutrals / Keywords for Neutrals	Negative/neutral examples used to sharpen the model.
Children Included	Child bots rolled into this model (accordion).
Metrics	Accuracy figures — shown only when the last training succeeded.

The panel shows extra rows only when the selected model actually uses them — those belong to advanced, rule-based models and you can ignore them while learning.

Walkthrough — train a model from corrected documents

This ties straight back to the review-and-correct loop in E3 · Document detail.

First, produce training data. Leave Studio (Exit Studio), open several documents, and use the Training Mode toggle on the document page to correct the extracted fields. Each correction saves back to its Label — that’s a labelled example. Do at least a handful; more corrected documents make a better model.
Back in Studio, go to Studio > Agents > Classic ML > AI Models.
Set the Taxonomy dropdown to the Learner whose Fields you’ve been correcting (the same Learner your collection’s schema uses).
Click + Model. The training form opens.
Give the run a name and confirm the Labels to include and the model Type (Extraction for field-pulling; Classification for routing; Numerical for numbers).
Start the run. The new model appears in the list with a “training…” status icon; the tooltip reports progress, then success or failure. Hit Refresh to update.
When it succeeds, select it — the detail panel now shows a Metrics row. To judge whether it’s actually good enough, go to the Prediction Report page (next section).

Behaviours to know

Empty state. With no models yet you see “You haven’t created any AI Model to preview” plus + Model and Upload. Training data must exist first — a model with nothing to learn from won’t help.
Versions are immutable history. Re-training doesn’t overwrite V1; it creates V2. You can always inspect or roll back to an earlier version via N Past Versions.
Access-gated. + Model and the ⋮ actions only appear if your access allows them. If they’re missing, ask your administrator.

Prediction Report

A model’s Metrics row gives you a quick read, but a Prediction Report is the real verdict: it compares a prediction project (documents the model predicted) against a reference project (documents with known-correct answers) and scores them field by field. Selecting a report in the left list renders it on the right: an overall accuracy figure, then a table of accuracy and precision per Field/Label — so you can see which fields the model nails and which it struggles with. A due_date lagging at 71% tells you exactly where to send more corrected examples.

The Add Report form

Click + Report to open the form. If the button isn’t there, your access doesn’t allow creating reports — ask your administrator. Alongside a Name, a Report Type dropdown, and Save, cover these:

Field	What it does
Prediction Project URL	The project whose predicted documents you’re scoring.
Reference Project URL	The project holding the known-correct (“ground truth”) answers to compare against.
Comparison Type (dropdown)	How values are matched (the classification-type comparison mode).
Case Sensitive (toggle)	Whether `Acme` and `acme` count as a match. Off for most text fields.
Ignore special characters (toggle)	Strips punctuation/symbols before comparing — useful for IDs and amounts.
Label selection	Pick exactly which Fields to score; selected fields show as chips. Leave broad to score everything, or narrow to the few fields you care about.

How to read it — is the model good enough?

Look at overall accuracy first for a gut check, then ignore it — averages hide problems.
Scan the per-field rows. A model can be 92% overall yet useless on the one field that matters. Sort your attention by business importance, not by the average.
Accuracy vs. precision. Accuracy = how often the field is right overall. Precision = when the model does answer, how often it’s correct. A field with high precision but low accuracy is cautious (misses some, but trustworthy when it speaks); low precision means it guesses wrong — more dangerous, because a reviewer must catch it.
Decide the threshold per field. For a field that auto-advances a document, you want it high. For a field a human always eyeballs anyway, lower is fine.
If a field is weak, feed it more corrected examples, re-train (a new version), and run the report again. That iteration is the job.

Tip. Keep a small, stable reference project of correctly-answered documents as your “exam”. Re-pointing each new model version’s report at the same reference makes versions directly comparable — you can see V3 beat V2 on the exact same documents.

Watch out. A high score on documents the model trained on means nothing — that’s just memorising. Always score against a reference set the model has not seen to get an honest number.

AI Pipeline

Sometimes one model isn’t enough: you might classify a document first (which form is this?), then run the extraction model that matches that class, then a numerical model on the amounts. An AI Pipeline chains models into that ordered sequence so the platform runs them as one unit. The left rail lists your pipelines; selecting one shows the ordered list of chained models on the left half and the details of whichever chained model you click on the right. An action menu at the top-right manages the selected pipeline.

Control	What it does
Add models to AI Pipeline	The primary action on an empty pipeline — opens the dialog to add the first model.
Add a model	Adds an existing AI Model as the next step in the chain.
Add a pipeline	Adds an entire pipeline as a step — i.e. chain pipelines inside pipelines for reuse.
Update version	Bumps a chained model to a newer trained version without rebuilding the chain.
View Chainer JSON (toggle)	Swaps the right pane for the raw chain definition — the advanced, exact view of the chain order and config.

By design. Treat AI Pipeline as the advanced option. Most solutions get all the accuracy they need from a single well-trained model. Reach for chaining only when a real classify-then-extract problem demands it; don’t build a pipeline just because you can.

How this connects to an agent’s Output tab

This closes the circle back to A3 · Your first agent. An agent extracts data by pointing its Output tab (the Structured output mode) at a Taxonomy / Learner — the schema whose Fields to fill. That same Learner is what owns the AI Model you train here. The two pages are two ends of one pipe:

The agent’s Output tab decides which Fields get extracted and routes low-confidence ones to human review.
Classic ML improves how accurately those Fields get filled, by training on the corrections reviewers make.

You don’t re-wire the agent when you train a model — the agent already targets the Learner, and a better-trained Learner simply produces better extractions on the next document. The agent stays the same; its apprentice just gets smarter.

Try it yourself

Review the accuracy of a model after correcting a few documents — the whole loop in miniature:

Pick a Processing collection you’ve used before (e.g. the Invoice Extractor from A3). Exit Studio, open 5–10 documents and use Training Mode to correct the extracted fields. Aim to fix at least a couple of due_date or total values.
Go to Studio > Agents > Classic ML > AI Models. Set the Taxonomy filter to that collection’s Learner.
Click + Model, name the run, confirm the Labels and Type: Extraction, and start it. Refresh until the status icon shows success.
Switch to Prediction Report. Click + Report, name it, set the Prediction and Reference Project URLs, pick your Fields in Label selection, and Save.
Read the per-field table. Which field is weakest? That’s your next batch of corrections. Correct a few more documents, train a V2, and run the same report again — watch the number move.

If the weak field improved after more corrections, you’ve felt the learning loop work end-to-end. That’s the entire point of these three pages.

Where to go next

A11 · Teams & mesh — wire several runnables into durable multi-stage automations.
E3 · Document detail — master the Training-Mode corrections that feed everything here.
A10 · XFlows & pipelines — the other kind of pipeline: a canvas of operators that processes documents step by step.
Glossary — AI Model, Learner, Taxonomy, Label/Field.