AI Builder

In one line. Three Studio surfaces — AI Models, Prediction Report, and AI Pipeline — 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 an LLM 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 ▸ AI Builder — three sub-pages: AI Models (/studio/.../ai_builder/ai_models, the default), Prediction Report (/studio/.../ai_builder/reports), and AI Pipeline (/studio/.../ai_builder/ai_pipeline).

Why it matters

There are two kinds of “model” on this platform, and AI Builder is about the one people forget. An LLM (A2 · LLMs & services) is a general-purpose large language model you rent from a provider and prompt — it reasons from instructions and 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 LLM 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 LLM that powers a chat agent. When in doubt: an LLM is configured on an agent’s Model tab; an AI Model is trained here, in AI Builder.

The learning loop

You have met every piece of this loop in S2 · Core concepts, E3 · Document detail, and D1 · Collections & schema. AI Builder 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.

Under the hood. Each correction writes a confidence-scored value into the document’s labels. A training run feeds those labelled examples to the platform’s extractor (the AIModel the Learner owns) and re-scores it; the result is a new version (V1 → V2 → V3). The LLM is never touched by any of this.

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

Reach for…	When…
An LLM agent alone (A3)	You’re starting out, volumes are low, document layouts vary wildly, or the field needs reasoning/judgement. The LLM 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 LLM 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.	Developers also see a Sherlock/debug link.
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 (`initiateTrainingForm`) — start a new training run from the corrected/labelled documents.	The main way to train. Permission-gated.
Upload	Imports an offline / externally-trained model instead of training one here.	For models trained elsewhere.
Load more	Pages in more models (server-side lazy load).
⋮ 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.

Under the hood. The remaining rows (Bulk Label Rules drive-url, Parent logs, Rule-based Model Rules, Widget Input/Primary/Output columns) are for advanced / rule-based models. You can safely ignore them while learning; they appear only when a model actually uses them.

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. In the consumer app, open several documents and use the Training Mode toggle on the Document Detail 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.
In Studio, go to Studio ▸ AI Builder ▸ 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.
Permission-gated. + Model and the ⋮ actions only appear if your role allows them.

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 (permission ai_builder/Add Report) to open the form. 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 chain-model-list on the left half and the details of whichever chained model you click on the right. An L3 action menu (top-right) manages the selected pipeline.

Control	What it does
Add models to AI Pipeline	The primary action (`addChainerModel`) on an empty pipeline — opens the dialog to add the first model.
add-chain-model dialog	Adds an existing AI Model as the next step in the chain.
add-model-pipeline dialog	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 chainer definition (`chainer-json`) — the advanced/exact view of the chain order and config.

Under the hood. A pipeline you build here is also available as the AI Pipeline stage node inside the XFlow editor — that’s how a chained extractor gets wired into a collection’s processing pipeline.

By design. Treat AI Pipeline as the advanced surface. 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 surfaces are two ends of one pipe:

The agent’s Output tab decides which Fields get extracted and routes low-confidence ones to human review.
AI Builder 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). Open 5–10 documents in the consumer app 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 ▸ AI Builder ▸ 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 AI Builder.

Where to go next

A11 · Teams & mesh — wire several runnables into durable multi-stage automations.
E3 · Document detail — master the Training-Mode correction surface that feeds everything here.
A10 · XFlows & pipelines — the AI Pipeline stage node that drops a chained model into a collection’s processing pipeline.
Glossary — AI Model, Learner, Taxonomy, Label/Field.