A Brief Overview Of The New Oracle Digital Assistant
And Where Does The Oracle Chatbot Fit Into The Conversational AI Landscape
Introduction
Exactly two years ago I wrote two articles on the Oracle Digital Assistant (ODA). One of the criticisms raised was that of intents and entities not being closely coupled.
Much has changed with regard to ODA in terms of functionality and aligning with what is currently maintained as best practice in chatbot frameworks.
In its simplest form, an Oracle Digital Assistant is constituted by five elements. Intents and Entities, Components which can be built-in or custom. A dialog flow which can be developed graphically or via a markdown language. And lastly channel integration.
Two areas ODA could have focussed on is entity annotation within intent utterance examples. And making the Visual Flow Designer more interactive in terms of direct interaction with the design canvas.
Being able to select a Visual Flow Designer tool to build dialog flows as opposed to only having the YAML option to write dialog states in OBotML is a significant step forward. But some improvement is required; more on that later.
Skip to the end for general critique & considerations…
Accessing Oracle Digital Assistant
Ease of access is definitely not one of the Oracle Digital Assistant’s (ODA) advantages. Especially compared to the free and full access of Cognigy, Kore AI, Nuance Mix and others. Even when compare to enterprise cloud solutions like AWS, IBM Watson Assistant and others.
Registering an initial account is quite fast. The number of free services on this no-pay tier are limited and does not include any AI or Analytics tools.
Upgrading my account to a paid version was a 24 hour process. This pales in comparison to the speed of other enterprise cloud solutions like Azure, AWS, IBM Cloud, etc.
Creating an instance for a digital assistant takes a while (fortunately minutes not hours), this really emphasises the exceptional efficiency, speed and orchestrated onboarding process of other platforms.
What’s New?
- The biggest change is the addition of a Visual Designer as part of Digital Assistant Release 22.04 about a month ago. As seen below, when creating a skill, the option exists to choose between a YAML or Visual Dialog Mode.
- This new Visual Designer aids in designing dialog flows visually with a no-code to low-code approach.
- Create separate flows for each intent, create sub-flows and reusable utility flows to simplify design and maintenance of dialog flows. The idea of separate flows per intent reminds quite a bit of Cognigy.
- The new Knowledge feature enables you to quickly create answer intents from PDF/HTML sources that contain text in a Q&A format. Ingest Q&A pairs from PDF/HTML sources and generate answer intents automatically.
- Structure is added to intents with quick replies within the intent. Intents can be switched on or off. Intents can be multi-lingual with quick replies within the intent.
- These quick replies which can evolve into a QnA service. Quick replies can also contain the conversation without any flow involvement.
- Autocomplete allows for utterances to be used for auto complete suggestions. This is an implementation of Large Language Models, where complete the sentence options are available. Autocomplete minimises user error by providing effective phrases that can be used as both direct input and as suggestions.
- The help feature on the ODA is very unobtrusive, and does not force the user down a certain path or sequence of events. But as your development process unfolds, different messages show up to guide the user to a probably next step.
Languages
- An astounding amount of languages are supported. This is done via both Native support and translation services.
- The translation service include languages like Afrikaans, Zulu and Xhosa,
- venda, Tswana, Tsonga, Swati, Shona, Sesotho, Lingala, etc.
- Native Language support supports a smaller number of languages directly in a linguistic model without any translation layer.
- The use of a translation service requires you to configure a translation service key from Google or Microsoft with your digital assistant instance. Incoming user messages are translated to the base language configured for a skill. The base language is the language you use to train the model, which for translation services most often is English. The benefit of using translation services at the moment is that it supports more languages than native language support does. Scaling and management are key considerations here. The translation layer introduces an additional layer of potential unpredictability.
Training
ODA also focusses on training time, and finding solutions to shorten training time, especially during development testing.
Trainer Ht is good to use early during development when you don’t have a well-designed and balanced set of training utterances as it trains faster and requires fewer utterances.
Use Trainer Tm as soon as you have collected between 20 and 30 high quality utterances for each intent in a skill. It is also the model you should be using for serious conversation testing and when deploying your digital assistant to production.
ODA has a validate option which can be executed to check basic logic within the application.
Entities
Entities are closely associated with intents, this is a common trait within conversational AI frameworks now. Again Cognigy comes to mind where intents and entities are closely linked to portions of the flow.
ODA also supports different types of entities.
Simple Entities are numbers, email and yes/no.
Complex Entities include address, time, date, duration, currency.
Ambiguity Resolution Rules for Times and Dates are available.
Custom entities include:
- Composite Bag
- ML Entities
- Value List Entities
- Dynamic Entities
- Regular Expression
- Entity List
- Derived
Most notable are Derived Entities, a derived entity is the child of a built-in entity or another entity that you define.
An ML (machine learning) entity uses a model to identify the entity values in a user message.
A composite bag is a grouping of related entities that can be treated as a whole within a conversation. Using composite bags enables a skill to extract values for multiple entities in one user utterance, which allows a conversation to flow more naturally.
Knowledge Documents
You can upload documents that contain a series of questions and answers to generate answer intents for each question. Knowledge documents can be HTML or PDF.
The Q&A feature enables your skill to answer general interest questions by returning one or more question and answer pairs. It’s a way for you to use a skill to surface FAQs or other knowledge-base documents.
Adding a Q&A module to your skill enables it to evaluate whether the user input is intended for a transaction (“What’s my balance?”) or to answer a question (“What’s the bank’s address?”) and then respond appropriately.
Conclusion & General Considerations
The Good
- Functionality is being added to intents, richer management and tweaking of intents.
- Functionality is also being added to entities, blurring the lines between intents, entities, dialog flow and messages.
- Intents & Entities seem to be coupled, which leads to improved accuracy.
- Intents are linked to sections of flow, also aligning with Gartner leaders best practice.
- A visual design tool is available for dialog flow state design and management.
- Focus on no-code and low-code.
- Based on the conversational design challenge, the visual or YAML dialog development tool can be selected.
- Rich entity functionality in the form of ML entities, nested or sub entities. Derived and child entities.
- Different model training options supporting quick iterative testing.
- Two approaches to question and answer bots, and knowledge bases.
- Auto completion hints at ODA leveraging Large Language Models for user assistance.
- Vast number of supported languages, although quality is a consideration here when considering translation.
- ODA has gone the route of adding much functionality to entities; fuzzy matching, disambiguation, prompts, validation rules, etc.
The Not-So Good
- The large number of language options can be misleading, as most are language translation. This introduces another layer of translation where intent, meaning and general semantics can be lost or misinterpreted. Scaling and managing of a conversational agent becomes a problem here.
- The graphic design canvas (Visual Designer) is not fully interactive. The ODA canvas reminds of how Nuance Mix implemented their dialog design canvas. With the nodes not being fully interactive in the sense of dragging and dropping elements. Add to this list AWS Lex.
- Entities cannot be annotated within intent utterance examples. This approach is common place with Conversational AI frameworks.
- Access and onboarding is a challenge and could be an impediment to new users.
- The mediums available for deployment are substantial, but pales in comparison to other frameworks like Microsoft, Cognigy, Kore AI and more.
- YAML (mark down language) and Visual Designer cannot be combined in one skill.
