Glossary
Definitions of the domain terms used across the documentation — pipeline, node, run, dataset, Training, quality control, cost, and workforce vocabulary — each linking the page that covers it in depth.
The terms used across this documentation, in the words the product uses. Each entry links the page that covers it in depth.
The built-in assistant you build pipelines with, in a chat on the project page. You describe the task in plain language. The agent assembles the pipeline, writes the instructions and the labeling screen, and sets quality control, audience, and pricing. See How the platform works.
API key
Section titled “API key”A credential you generate in the Business Console. It acts as your user for the HTTP API and the CLI. Access follows the teams you belong to. See CLI and Programmatic access (API).
Audience
Section titled “Audience”The set of experts eligible to label on a Generation or Quorum node, filtered by language, specialization, and country. It applies to expert labeling only. Synthetic labeling has no audience. See Generation node.
Audience reuse
Section titled “Audience reuse”Reusing the expert audience from a deployed Generation or Quorum node, typically one in another pipeline of the same project, so experts who passed that node’s onboarding start work without repeating it. It is unavailable under synthetic labeling. See Generation node.
Balance
Section titled “Balance”The prepaid funds on your team that a run draws down as it labels. Billing is pay-as-you-go for the items a run processes. A run cannot deploy on an empty balance, and if the balance runs out mid-run the run pauses until you top it up and resume it. A Training Run first places a hold for its maximum charge on the same team balance, then charges only the GPU seconds it used; a run that fails because of the platform is not charged at all. See Pricing and billing.
Base model
Section titled “Base model”A catalog model you can train from, identified by a stable id such as qwen3-8b. A Training names either one base model or one existing Model Version as its source. See Fine-tune a model.
The items one run processes, up to the 10,000-item per-run limit. A large or recurring workload is a cycle of batches: deploy one, clone the pipeline, point the copy at the next, deploy again. See Label a large dataset in batches.
Branch
Section titled “Branch”One of a Match node’s outgoing paths. Each condition is a branch, labeled by the condition’s name. The default branch carries every item that matches no condition. See Match node.
Business Console
Section titled “Business Console”The separate Toloka application where money enters your account: Top up and Billing history open its billing page in a new tab. The platform reads your balance from it and links to it. Adding funds, invoices, and payment details live there.
A test on one node, run before deploying. Seven kinds exist in two families: test checks that you author cases for, all but one of which the agent can run for you, and built-in lint checks that take no case and block the deploy until they finish. A check ends passed or failed and reverts to not run when the settings it covers change. See Self-check.
Checkout
Section titled “Checkout”A directory bound to one platform project by a toloka.json file. The CLI treats that file as the project root. See CLI.
A copy of a pipeline that carries the same configuration into a new pipeline in the same project. Because a deployed pipeline is locked, cloning is how you label another batch or start a new version. See Label a large dataset in batches.
Condition
Section titled “Condition”A named group of field tests on a Match node. Each test compares one input field’s value, and the condition passes when all of its tests pass, or any one, as configured. Each condition gets its own branch. An item that matches no condition follows the default branch. See Match node.
Contract
Section titled “Contract”The per-item prices for one run, frozen when you deploy and unchanged for the life of that run. Each run freezes its own contract, so a clone does not inherit the original’s prices. The run’s Contract button reopens it at any time. See Pricing and billing.
Cost breakdown
Section titled “Cost breakdown”The Cost breakdown (forecast) window shows the forecast before you deploy, with one row per billable line and an Expected and a Maximum total for the run. It lists the real per-task, per-call, and per-token prices and computes the totals. See Pricing and billing.
Cost estimate
Section titled “Cost estimate”A free check of a Training that freezes the dataset selection, validates every selected row, and returns either a list of problems or a maximum charge. It expires 24 hours after its cutoff time. See Training.
Data collection
Section titled “Data collection”A task type where experts produce new content. Uploading media is one example. Experts do not label data you already have in this task type. Its labeling interface must include a media-upload control, it is the one task type that may use the wider unverified expert pool, and synthetic labeling is not available on it. See Generation node.
Dataset
Section titled “Dataset”The collection of items a pipeline reads, loaded from a JSON or CSV file. The Start node binds to one dataset and exposes its fields as the pipeline’s inputs. A Training also reads project datasets of labeled conversations. See Fields and data and Fine-tune a model.
Deploy
Section titled “Deploy”Launching a run: you confirm the cost, the contract freezes, and the run begins labeling. Deploying locks the pipeline, so you cannot edit or rerun it and a further batch needs a clone. A deploy that failed is the exception: it frees the same pipeline to fix and deploy again. See Label a large dataset in batches.
Experts
Section titled “Experts”The people who label your data. Pages also call them expert labelers. You set the audience they are drawn from and the price each is paid. The agent writes the instructions and the labeling screen they see. See How the platform works.
Expert offboarding
Section titled “Expert offboarding”Removing an expert from a Quorum node’s task for persistently landing in the minority on a chosen single-label output field. An expert agrees on an item when their label matches more than half of all the labels submitted for it, their own included. An offboarding rule acts on experts, not items. It does not grade, reject, or change any individual label. It is available only in the node’s no-review mode, which also needs an overlap of at least three and the per-expert cap switched off; at least one rule is required there. See Quorum node.
Expert payout
Section titled “Expert payout”The per-task price you set for experts on a Generation or Quorum node is what the expert earns. Your charge adds the platform commission on top. The cost breakdown shows the combined line as Expert Service Cost. See Generation node.
Export
Section titled “Export”A downloadable JSON file of a run’s results, with one entry per item carrying its inputs and the output fields the pipeline produced. Each export is a snapshot taken when you start it, and its download link is valid for 30 minutes. See Export format for the file’s contract and Export your labeled results for the steps.
A named value on an item. Input fields are the values a node reads. Output fields are the values it writes. Each field has a name and a type. See Fields and data.
Generation model
Section titled “Generation model”The model that produces the labels under synthetic labeling, chosen per node from the platform’s catalog with a recommended default. It is separate from the review model, which checks those labels. See Label with an LLM instead of experts.
Gisting
Section titled “Gisting”A Training method that learns a compact prompt representation from example conversations plus a prompt text file. It is not supervised fine-tuning. See Training.
Human review
Section titled “Human review”A review path where expert reviewers check a sample of a node’s labeled items, 10 to 100 percent of them. It is available on the Generation node only. The Quorum node and synthetic labeling do not offer it. See Quality control.
One unit of data a run processes, carrying the fields the pipeline reads and writes. The unit is one entry from the dataset. A single run processes up to 10,000 items. See Fields and data.
Item filter
Section titled “Item filter”The Start node’s filter that narrows which dataset items a run launches. It matches by a field’s value, by the source that recorded a value, or by a field’s absence, and it evaluates as of the moment the run launches. See Start and End nodes.
Labeling interface
Section titled “Labeling interface”The screen an expert fills in for one item. The agent builds the form from your task. It shows the input fields and collects a value for each output field. On the node it is the UI for Experts card, and the User Interface check previews it. Pages also call it the labeling screen. See Generation node.
LLM review
Section titled “LLM review”A review path where an LLM checks every labeled item against your quality criteria and returns a verdict for each. It is the default review path and always covers every item, with no sampling. See Quality control.
Location
Section titled “Location”How a part of a structured value is addressed: it starts at the value’s root, written $, and steps inward one named member or list position at a time. Match node tests, item filters, repeating-field declarations, and derived fields each use one. See Fields and data.
Maximum charge
Section titled “Maximum charge”The most a Training Run can cost: the price of the estimate’s maximum GPU seconds, rounded up to the cent. The platform places a hold for this amount on the team balance when the run starts and charges only the GPU seconds used by a run that completes or that you cancel; a run that fails because of the platform is not charged. See Training.
A project-owned named container for immutable Model Versions produced by Training Runs. The first Training Run creates the Model from the Training name. See Fine-tune a model.
Model Version
Section titled “Model Version”One immutable published result of a completed Training Run, with a unique name and a server-assigned revision. See Fine-tune a model.
One unit of a pipeline. A pipeline is a connected set of nodes, each of a small, fixed set of kinds that label, transform, or route your data. See Pipeline nodes.
Onboarding
Section titled “Onboarding”A one-time course experts complete before they take paid items on a Generation or Quorum node. It needs at least three steps, one quiz (multiple-choice questions with correct answers), and exactly one hands-on part; material to read and a consent block are optional. The hands-on part can be a practice exercise or worked examples, not both. See Generation node.
Overlap
Section titled “Overlap”The number of experts who independently label each item on a Quorum node — the card calls it the number of independent annotations per task. It is a whole number from 1 to 100. Raising it raises the expert cost in step. See Quorum node.
Per-expert cap
Section titled “Per-expert cap”An optional limit on how many tasks a single expert may take on a node, a whole number from 1 to 50. It is off by default. See Generation node.
Pipeline
Section titled “Pipeline”The connected set of nodes that takes your data in and produces labeled results. The agent assembles it from your task description. You review it, launch it, and export from it. See How the platform works.
Project
Section titled “Project”The workspace unit that holds your pipelines, datasets, secrets, Trainings, and Models. You create one by describing a task to the agent, or with toloka project create. Every pipeline and Training belongs to one project. See Get your first labeled dataset, Fine-tune a model, and CLI.
Quality criterion
Section titled “Quality criterion”A named check a labeled output is judged against, with a pass condition, a fail condition, and an optional instruction for the LLM reviewer, targeting one output field. Reviewers apply the criteria and return a verdict for each. See Quality control.
Reasoning effort
Section titled “Reasoning effort”A synthetic-labeling setting for how hard the generation model reasons on each item: Low, Medium, or High on models that support it, with Medium the default. Higher effort raises the estimated tokens per item and the price. Lower effort lowers both. See Generation node.
LoRA rank
Section titled “LoRA rank”A supervised fine-tuning setting: the rank of the LoRA adapter, 8, 16, or 32, with 16 the default. A larger rank gives the adapter more capacity and needs more data. Alpha is always twice the rank. See Training.
Gist tokens
Section titled “Gist tokens”A gisting setting: the number of learned soft tokens that replace the prompt, 8, 32, or 64, with 32 the default. Fewer tokens compress harder; more tokens keep more of the prompt. It also takes a fraction of the prompt — "1/4", "1/8", "1/16", or "1/32" — which fixes the compression ratio instead of the count and is resolved to a token count when the run reads the prompt. See Training.
Repeating field
Section titled “Repeating field”An output field that can hold several values within a single item. It returns a list rather than one value. On a Quorum node, a repeating output comes back as one list per expert. See Fields and data.
Review metadata field
Section titled “Review metadata field”An extra output field a reviewed node adds alongside your own fields, named after the node and ending in _qa_metadata, with details about how the item’s labels were reviewed. See Quality control.
Review model
Section titled “Review model”The model that performs LLM review on a node. It is set per node, separately from the generation model under synthetic labeling, and each model has its own per-call price. See Quality control.
Review path
Section titled “Review path”How a node’s labels are reviewed: LLM review, human review, both, or none, depending on the node. The agent turns quality control on by default. See Quality control.
One execution of a deployed pipeline over a batch of items. A run is created at deploy and does not run again. More data means more runs. See Label a large dataset in batches.
Secret
Section titled “Secret”A credential stored in your project, such as an API key, that a Code node’s environment variable can point to, so the value stays out of your code. You create one on the project’s Secrets page. The agent can reference a secret by name but cannot create one. See Code node.
Self-check
Section titled “Self-check”The checks run before you deploy to confirm the pipeline is built correctly, while mistakes are still free to fix. It validates the configuration rather than labeling real data. Configuration errors and failed checks block the deploy. Unrun test checks are warnings you can override, while the built-in lints must have finished: two on each labeling node and one on the Start node. See Self-check.
Single-label output field
Section titled “Single-label output field”An output field where each expert picks exactly one label from a fixed set. On a Quorum node, agreement is measured on single-label output fields: agreement checks and expert offboarding each work on one. See Quorum node.
Source
Section titled “Source”Who recorded a field’s value: a person or an automated source such as an earlier pipeline run. A field can hold several recorded values over an item’s life, each with its own source, and a node reads the latest by default. See Fields and data.
Specialization
Section titled “Specialization”A skill area used to filter a node’s audience, alongside language and country. Specializations require verified experts and are not available with the unverified pool. See Generation node.
A page of an expert onboarding course. A pipeline’s units are nodes, never steps — the Current Step column on the Items tab names the node an item has reached. See Generation node.
Synthetic labeling
Section titled “Synthetic labeling”Having an LLM produce a node’s labels instead of expert labelers, with each label checked against your quality criteria by a separate LLM call. Quality control is LLM review only, and the expert audience, pricing, per-expert cap, and onboarding do not apply. See Label with an LLM instead of experts.
One unit of expert work: one item shown to one expert to label or review. Pricing is per task. On a Quorum node, one item produces as many tasks as it has experts, and the per-expert cap counts tasks. See Generation node.
The account unit that owns projects and the balance. Every run, whichever project it belongs to, draws on its team’s one balance. See Get your first labeled dataset.
toloka
Section titled “toloka”The command-line program shipped with the platform SDK. You sign in with an API key, select a project, reconcile TypeScript source with plan and apply, and run Training commands. See CLI.
Training
Section titled “Training”An editable draft that names a method (supervised fine-tuning or gisting), a source model, and dataset selections. Updating a Training does not change an existing Training Run. See Training.
Training Run
Section titled “Training Run”One billed execution of a Training from a ready cost estimate. It is immutable. A completed run publishes one Model Version. See Fine-tune a model.
Verdict
Section titled “Verdict”The result of checking one quality criterion on one labeled output: pass or fail, each with a written reason. Besides pass and fail, a verdict can have the state skipped or an error state when the check could not run for that item. A criterion on a repeating output returns a list of verdicts, one per value. See Quality control.
Verified experts
Section titled “Verified experts”Experts who have completed ID verification. Labeling tasks require verified experts, and specializations are available only with them. Only data-collection tasks may use the wider unverified pool. See Generation node.