Concepts
Mubit groups similar calls into tasks and uses kept examples to train and test adapters.
Not every call is kept, and not every version passes. Training also depends on the task's limits and eligibility.
The diagram in words
Mubit groups recorded calls into tasks and selects kept examples. Once enough eligible examples are available and training can run, Mubit trains and tests an adapter version. A passing version can be compared in Try models. If a version is below target, review its results and provide more useful examples.
Four terms to know
- Request: One call your app sends through Mubit. Recorded calls appear in Requests.
- Task: A recurring kind of request. Calls with matching model, instructions, tools, tool choice, and output format form a task.
- Kept example: A call Mubit accepts for training or testing. Not every recorded call becomes a kept example.
- Adapter: A small model trained for one task. Each training creates a version, which Mubit tests against the provider model's answers.
Once an adapter version passes its tests, you can compare it with your provider model in Try models. Passing a test does not guarantee suitability for every input; review representative examples from your application.
Two different keys
Your app uses a Mubit key to call Mubit. Mubit uses a provider API key to call the provider, either through supported starter credit or your configured provider account.
A project holds your calls, tasks, adapters, and keys. Project administration is separate from this learning flow.
Next: Create your first adapter.
For detail: Tasks and sessions · Mubit keys · Provider keys.