An API client requesting their input text like "Open a savings account" can expect the following kind of response back.
500 Internal server error
(no, just joking)
200 OK
{ "text": "Open a savings account", "intents": [ { "intent": "AccountOpen", "confidence": 0.9 }, { "intent": "AccountInfo", "confidence": 0.2 } ], "annotations": [ { "name": "AccountOpen", "type": "intent", "source": "annotator:banking", "confidence": 0.9 }, { "name": "AccountInfo", "type": "intent", "source": "annotator:banking", "confidence": 0.2 } ] }
Model configurations are the payloads of the request/response bodies of the GET/POST /models
API calls.
The NLU API supports 2 model types to begin with: pipeline
and annotator
.
Pipeline models can be of mode parallel
or sequential
.
The type
of the model also corresponds to an additional object property that can store
further properties specific to that type of NLU model.
The configuration below delegates all work to a hand-made model called
banking1
that got pretrained and lives in the nlu_annot
microservice.
The configuration below defines a "pipeline" model that is a container that purely references other NLU models that must exist within the NLU service and accumulates their annotations.
The configuration below defines a model that consists of a closed-ner
model.
The configuration below defines a pipeline model that consists of annotators
and also by builtin-ner
models.
The configuration below showcases the json sample needed to create a model of type annotator
.
The configuration below showcases the json sample needed to create a model of type pipeline
.
Notice that the mode
can be either "sequential" or "parallel".
The configuration below showcases the json sample needed to create a model that is able to detect builtin entities
.
You have to create a pipeline
model and add a builtin-ner
model to it.
The builtin
model needs to have its name equal to builtin-ner
and a language
(en
and cs
are supported right now, more to come).
The configuration below showcases the json sample needed to create a model that is able to detect closed entities
.
Inside the phrase_set_ids
list, add all the phrase sets that the model should be able to detect words against.
The phrase sets must be created in the nlu-ner-closed-api
.
If you want to use a closed-ner
model alongside annotators
and builtin-ner
models, create a simple pipeline
model.
Notice that in all cases the model_id
and the owner
are not needed, as they are assigned automatically.
To update an existing model the model_id
is needed. Also, the configuration below
showcases the json sample needed to update the model, in this case the name
and the description
.
Note that the JSON configuration included in the POST request body will overwrite the existing configuration
of the model. No merging is performed with the original model configuration.
To delete an existing model only the model_id
is needed.