AI Services
Overview
AI Services represent a versatile and impactful type of AI solution designed to execute complex tasks and reasoning via Quiq's public API.
AI Service flows are extremely flexible, allowing customizable request and response options and enabling all of the common utility provided by AI Studio without requiring any middleware. This flexibility allows AI Services to handle a wide range of scenarios empowering users to craft applications tailored to specific needs.
Getting Started
AI Services are created and managed like other AI Studio Projects, and can be created using the New Project button, or in the Services tab:
AI Services are published and versioned just like traditional assistants, and can be exported and imported as desired:
Starting an AI Service
AI services always begin flow execution from an API Definition Behavior. The behaviors configuration defines the endpoint used to begin the execution as well as the request and response payload if applicable:
Unlike Assistants, there is no session or conversation associated with a service execution, meaning that each execution is completely separate from any other.
API Definition Behaviors
The API Definition is a Behavior that is unique to AI Services and is what defines the public API used to initiate the flow:
The behavior defines several pieces of data including the Request Body as well as an optional response:
Request
Endpoint ID: The ID of your endpoint, once added a Draft
and Published
version of your endpoint will be visible in the Endpoints section at the bottom of the behavior
Method: API Definition behaviors support GET
and POST
methods.
Body:
- Encoding can be
JSON
,YAML
, orXML
Defining Properties
It's not required to define any properties in the Body, however doing so enables you to define the type:
as well as additional details, like whether or not the property is required:
Defining properties in the body of your Behavior also makes them accessible in the visual rules editor, enabling you to condition off of them or set values:
Any defined properties will be validated and your AI Services requests can fail if the contract is not satisfied.
Undefined Properties
Properties that are not defined will not be stripped out of the request context, meaning that they can be accessed via the Function Editor, but will not be accessible in the Flow panel UI.
Response
Similar to the Request, it is not required to define all properties that will be returned from the service, but using it as a form of validation is recommended.
Return Type can be JSON
, YAML
, XML
, or None
Asynchronous vs Synchronous
If Return type is set to None
a checkbox enabling the response to run Asynchronously appears:
This can be helpful in situations you're calling into a system with a short timeout.
Returning a Response Asynchronously
When
Run Asynchronously
is enabled, you can set up a Call API at the end of your flow to submit the results into your system.
Handling Undefined Properties
Under normal circumstances an error will occur when attempting to set a non-existent field from a programmatic action. In order to get around this for the response, a new code only setResponse
action is available for AI Services only:
def build_response(context):
actions = []
value = {
'successful': True,
'completion': context['prompts']['test-prompt']['completion']
}
setResponse = {
"action": "setResponse",
"endpoint": "test",
"value": value
}
actions.append(setResponse)
return {"actions": actions}
This enables you to leverage any of the properties you may get back from your API, without having to define them one by one in your API Definition Behavior.
On request
The API Definition Behavior has a rule handler where you can configure visual rules and actions , including a location change to the next Behavior in the flow:
Endpoint Dispatcher
Because AI Services do not revolve around conversations like other Projects do, the Chat Panelis not available, and instead a new Endpoint Dispatcher panel is available that enables you to test and preview your AI Service without publishing your experience.:
You can toggle between your different endpoints using the dropdown at the top of the panel:
Key Differences Between AI Services & AI Agents
While AI Services and AI Agents use much of the same components of AI Studio, there are some key differences between them.
Fields
AI Services exist outside the context of a session or conversation, which means they don't have access to botSession
field types, conversation
field types, or customer
field types. Additionally, AI Services Fields cannot be reported on in analytics currently.
Field Type | Format | AI Services | AI Agents |
---|---|---|---|
Bot Session Fields | bot.session.[fieldname] | Not Available | Available |
Custom Conversation Fields | conversation.custom.[fieldname] | Not Available | Available |
Customer Fields | conversation.customer.custom.[fieldname] | Not Available | Available |
AI Services Fields | fields.[fieldname] | Available | Not Available |
Ending an AI Service
Unlike other AI Studio projects, AI Services do not need to transition to a Close or Route Behavior to end their flow without an error. Instead, they will simply stop running once they reach the last behavior that has no further change location action configured.
Errors in AI Services
Because of their ability to end at any point, you will not receive errors when a behavior does not go anywhere or do anything, like you would with other Project types. This makes it especially important to check your work before publishing changes to ensure your AI Service is behaving as expected.
Updated about 10 hours ago