ML inference ingest processor

The ml_inference ingest processor calls a registered machine learning model during ingest, maps document fields into the model's input, and writes the model's output back into new document fields.

It is the general-purpose escape hatch of the ingest pipeline. Where embed exists specifically to produce vectors and image_tiling specifically to slice imagery, ml_inference runs whatever model you registered and puts the result wherever you say.

info

ml_inference is one processor name used at three different points in a pipeline: here at ingest, and as a search request and search response processor. They share a configuration vocabulary — model_id, input_map, output_map — so learning it once carries across all three.

How the mapping works

Two settings do the work:

• input_map takes document fields and presents them to the model under the names the model expects.
• output_map takes fields out of the model's response and writes them onto the document.

Both understand dot-path notation, including nested objects and arrays — the processor rewrites the JSON path accordingly, so items.0.text or extracted.blocks.text resolve as you would expect.

Request fields

Field	Type	Description	Required
model_id	String	The registered model to call.	Yes
input_map	List	Maps document fields to model input fields. One entry per prediction.	No
output_map	List	Maps model output fields back onto the document.	No
model_config	Object	Extra model configuration merged into the request.	No
model_input	String	Template for the model input payload, for models whose input is not a simple map.	No
function_name	String	The model's function name, for locally hosted models.	No
full_response_path	Boolean	Read outputs from the full model response path rather than the simplified one.	No
max_prediction_tasks	Integer	Ceiling on the prediction tasks a single document may trigger.	No
ignore_missing	Boolean	Skip quietly when a mapped source field is absent. Defaults to false.	No
override	Boolean	Overwrite the target field when it already exists. Defaults to false.	No
ignore_failure	Boolean	Standard processor setting — continue the pipeline if this processor fails.	No

Example

Call a registered model on each document's text field and store the result under ml_output:

PUT /_ingest/pipeline/classify
{
  "description": "Classify incoming documents with a registered model",
  "processors": [
    {
      "ml_inference": {
        "model_id": "NWR9YIsBUysqmzBdifVJ",
        "input_map": [
          { "input_text": "text" }
        ],
        "output_map": [
          { "ml_output": "response" }
        ],
        "ignore_missing": true
      }
    }
  ]
}

POST /articles/_doc?pipeline=classify
{
  "text": "Quarterly results exceeded expectations across all regions."
}

The indexed document then carries both the original text and the model's ml_output.

Choosing between ml_inference and a purpose-built processor

Use	When
embed	You want vectors. It knows about providers, dimensions, and content types.
image_tiling	You want imagery sliced into spatially indexed tiles.
chunk	You want text split for retrieval.
ml_inference	Anything else a registered model can do — classification, extraction, scoring, enrichment.

A purpose-built processor carries the surrounding behaviour (coordinate handling, provider config, content-type awareness) that you would otherwise have to reproduce in input_map and output_map. Reach for ml_inference when no purpose-built processor fits.

Related

• ML inference search processor — the same processor at query time
• Embed processor
• Register a model