Function Types

Nyckel supports four function types. They share the same underlying concept — a live, self-improving endpoint with samples, a review queue, and a managed model — but they solve different kinds of problems and have different setup steps.

Classification

The decision: assign each input to one of a fixed set of labels.

Use it when the answer is “which of these N categories does this input belong to?”

Inputs: text, image, or tabular data. Output: a label name and a confidence score.

A classification function returns exactly one label per input (or top-N labels with scores for multi-label setups). You define the labels; Nyckel learns to assign them from your examples.

Tabular is worth calling out, because it’s the one people miss. A tabular classification function takes a row of named fields rather than a single input — and a field can be text, a number, or an image. That makes one function able to weigh a product photo, a price, and a description together. It’s also how you build a scorer: the confidence on a positive label is a calibrated probability you can rank by. See Structured data & multimodal functions.

Create a classification function →

Detection

The decision: find where specific objects appear in an image, and what each one is.

Use it when you need both what and where — not just “is there a defect?” but “where is the defect, and how big is it?”

Inputs: image only. Output: a list of detected objects, each with a class name, a bounding box, and a confidence score.

You teach a detection function by drawing boxes around examples of each object class on training images. Detection is fundamentally different from classification — instead of one answer per input, you get zero, one, or many answers per input.

Create a detection function →

The decision: given a query, return the items from your reference data that are most similar in meaning. Powered by semantic search — see the Search guide for a fuller explanation.

Use it when the answer isn’t a fixed label but a ranked list — and similarity is about meaning, not just keyword overlap.

Inputs: text or image, depending on what you populate the reference data with. Output: a ranked list of reference items, each with a similarity score.

Unlike classification and Box Detect, Search doesn’t have “right” or “wrong” answers — it has more relevant and less relevant answers. You don’t define labels; you upload reference data, and the function answers queries against it.

Create a Search function →

OCR

The decision: read the text that appears inside an image.

Use it when the information you need is present in a picture but not yet available as text.

Inputs: image only. Output: the text found in the image.

OCR is often the first step in a chain rather than the end of one — read the text, then classify or route on what it says. There is no step-by-step walkthrough for OCR yet; create one from the console the same way you’d create any other function, choosing OCR as the output.

Picking the right type

If you want to… Use
Put each input into one of your categories Classification
Weigh several fields — text, numbers, images — together Classification (tabular input)
Find and locate objects in images Detection
Find the closest match from a reference set Search
Extract the text inside an image OCR

If you’re not sure, start with classification — it’s the most common case and the easiest to prototype. You can always create another function later. Nothing about your account or data is locked to one function type.

Input and output modality are fixed once a function is created, so this choice is worth a minute of thought — but creating a second function is cheap, and nothing stops you running two.

Why separate pages?

These types share the same concept of “a function,” but they involve different setup steps, different review workflows, and different output shapes. Splitting the docs by type means you only have to learn the parts that apply to your use case, without wading through irrelevant terminology.

Next