Aura –

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

NLP as a Service

Discover NLP as a Service, the AI-driven functionality for seamless language recognition and integration based on Natural Language Processing technologies

Introduction to NLP technologies

Natural language processing (NLP) refers to the branch of AI concerned with giving computers the ability to process, understand and generate human language. NLP combines computational linguistics (rule-based modelling of human language) with statistical, machine learning and deep learning models to bridge the communication gap between humans and machines.

Figure 4. NLP technologies

NLP encompasses a wide spectrum of technologies designed to be integrated into diverse user experiences. It includes deterministic and probabilistic techniques, syntax and semantics methods, named entity recognition (NER), etc.

Nowadays, the use of NLP in virtual assistants is not limited to understand and respond to simple utterances but also to derive meaning and use data behind user queries, allowing them to provide relevant and precise responses resulting in more accurate and natural interactions through different NLP technologies.

Application of NLP as a Service in ATRIA

NLP as a Service enables the use of different technologies through NLP Apps (Natural Language Processing recognition stages) for understanding users’ requests and providing back accurate responses.

Currently, these technologies, both proprietary and third-party ones, are included in the Aura NLP component but, in future releases, external NLP methods will be used.

In this framework, constructors have two approaches depending on the utilized stages:

Using NLP Apps (NLP recognition stages) different from Semantic Search
Find here detailed information regarding NLP Apps capability
Using Semantic Search technology, a specific NLP App that overcomes traditional keyword-based searches through the use of embeddings.
Find here detailed information regarding Semantic search functionality

Figure 5. NLP as a Service in ATRIA

Benefits from the use of NLP as a Service

NLP as a Service offers several benefits both for constructors and end-users:

Benefits for use cases constructors

Less time and complexity of use cases development
It is possible to create and configure tailored NLP pipelines, choosing from a variety of available stages and connectors that cover different aspects of Natural Language Processing.
No need for the manual generation of training phrases (aliases) for generic questions knowledge bases.
Knowledge bases can be updated continuously in an easy and quick way.
Accessibility: any application, both internal and external to Aura Platform, can consume this service.

Benefits for Aura end users

End-users can interact with Aura in a natural and conversational way, using their own words and expressions and even informal language, slang, abbreviations, misspellings, etc.
Improved Aura’s understanding capabilities, leading to fast and reliable responses and results.
Easy update of the knowledge bases, so the users can receive reliable responses based on up-to-date data.
The NLP service can be leveraged as capabilities offered to end-users or as internal features used by other Telefonica teams in order to streamline specific internal processes.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

LLM/LMM Experiences Builder

Discover ATRIA LLM/LMM Experiences Builder, that includes LLM chains for the generation of different types of content through Generative AI or RAG technologies

Introduction

ATRIA can integrate third-party AI technologies via API through the LLM/LMM Experiences Builder to create interactive, personalized, and dynamic user interactions, while establishing control mechanisms to ensure security and data privacy.

To do that, the LLM/LMM Experiences Builder allows the creation of LLM chains, which are defined as structured workflows that involve several interconnected steps, each of them using diverse LLM technologies to process, generate, or transform text data. Each step feeds into each other, with the ultimate goal of understanding a request expressed in natural language and providing an accurate response to it.

In the current release, two predefined LLM chains are included in ATRIA, offering two key capabilities:

Simple flows that call to an LLM: Generative AI capability for understanding and generating human-like texts through LLMs.
Complex flows: General RAG capability through RAG (retrieval-augmented-generation) processing techniques that combine different AI models.

Currently, only these two predefined chains can be used. In further ATRIA versions, constructors will have the flexibility of creating customized LLM chains.

ATRIA also includes a testing UI interface to test the behavior of the LLM/LMM Experiences Builder when using both Generative and RAG capabilities, before publishing into production. In further versions, the solution will include an interface to configure different parameters easily and a mechanism to load data.

Functional components

The following diagram schematically shows the functional components into play in the LLM/LMM Experiences Builder.

Figure 9. LLM/LMM Experiences Builder

Chain builder and orchestration layer

Currently, this layer allows:

Using a predefined LLM chain for specific use cases, that corresponds to a RAG (Retrieval Augmented Generation) pipeline integrated using LangChain.
Manual configuration of parameters.
Integration of new components (vector databases, document loaders, text splitters, etc.) by Aura Global Team.
Simple fallback mechanism: flag set in configuration.
Conversation history, taking into account past interactions for the enrichment of responses.

Control layer

The components of this layer have the following roles:

Providing mechanisms for ensuring security and data protection.
- Heuristics blacklists.
- Prompt injection.
- Templates.
Including the control of tokens consumption.

Model layer

The model layer can include both internally and externally hosted models.

Models currently integrated into ATRIA

The AI models currently integrated in ATRIA are:

Azure OpenAI embeddings model: text-embedding-ada-002
Hugging face models: paraphrase-multilingual-MiniLM-L12-v2, Multi-qa-distilbert-cos-v1
Azure OpenAI GPT models: gpt-4-turbo, gpt-4o, gpt-4o-mini, o3-mini

In further releases, the model manager will integrate other state-of-the-art models from different providers, avoiding lock-in and making easy for constructors to choose, try and select the one that fits better with their needs.

Analytics layer

The analytics layer currently includes two features:

Feedback functionality, for the estimation of the accuracy in the response, in which the user can provide feedback by clicking on a thumbs-up icon if the quality and appropriateness of the answer is correct or selecting the thumbs-down icon if the response misses the point, contains hallucinations, or is unclear.
Simple RAG monitoring to check how the RAG chain performs.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Introduction to ATRIA multibrand feature

Description of ATRIA multibrand feature, based on a multitenant architecture

Introduction

ATRIA, just like Aura Virtual Assistant, is designed as a multibrand platform, meaning that users can access ATRIA through the different Telefónica brands available in their country.

This multibrand feature is based on a multitenant architecture, with a tenant defined as the deployment associated to a specific brand.

Functional multitenant architecture in ATRIA

An overview of the functional operation of the multibrand feature in ATRIA is shown and explained below:

Overview of multitenant architecture in ATRIA

ATRIA supports different brands
Each brand is associated to several channels
Each channel allows accessing to use cases in a specific domain
When a user send a request, it passes through Kernel and is managed by a specific Kernel tenant
This Kernel tenant sends the query to a particular ATRIA tenant
ATRIA calls the required AI-driven models for its resolution

Technical documents

Multitenant configuration in Aura installer

Aura installer: Multitenant configuration: Guidelines for the configuration of different tenants when several brands are available in the OB.

Descriptive documents and guidelines

Once the user accesses through a specific Telefónica brand, the technical behavior of the corresponding Aura tenant is similar to the one before the implementation of the multitenant architecture. Therefore, there are no specific descriptive documents or guidelines for the multitenant architecture.

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Introduction to ATRIA multi-language feature

Description of ATRIA multi-language feature, offering its AI-driven capabilities in different languages

This feature is only available for ATRIA RAG stages

Introduction

ATRIA RAG now includes a multi-language feature, to deliver service to a global audience in multiple languages.

This multi-language capability allows users to make a request to ATRIA and receive back the response in their own language through a technology that automatically detects and adapts to the input language.

The multi-language feature provides multiple benefits:

The information provided by ATRIA is easier to understand, as it is generated in the user’s language.
A wide range of languages is supported, allowing ATRIA to reach a global audience.
The user experience is also optimized by reducing the need for external translation tools, making communication more seamless and natural.

From a technical point of view, the model for text identification and classification fastText is used, that supports more than 176 languages.

Functional overview

This feature is only available for RAG stages

A high-level overview on how the ATRIA multi-language feature works is included below.

A users sends a request to ATRIA in a specific language. ATRIA automatically detects the input language and sends the response back to the user in the same language.
In case the user’s request includes a mixture of languages (for example, “por favor, dame feedback”), ATRIA detects the predominant language of the query and uses it in the response.
In case ATRIA is not capable of identifying the request language, then the system generates the response in a language previously configured by default (that should be the region/country primary one).
The multi-language feature can be activated or deactivated by ATRIA constructors, as well as configured to meet their requirements and needs.

Technical guidelines

How constructors can configure ATRIA multi-language feature?

Constructors can configure this feature through different parameters of the prompt:

Best practices for ATRIA configuration: Use the multi-language feature

ATRIA server internal configuration

The ATRIA server configuration responsible for managing the multi-language feature includes these fields:

ATRIA default configuration: language identification fields

Docs:

Mon, 01 Jan 0001 00:00:00 +0000

Generative feedback functional description

Discover the feedback functionality that can be used for Generative AI and RAG capabilities

If you are interested in the detailed technical operational flow of this capability, that includes the sequence diagram of interactions between components, access here

Introduction

Within the use of the ATRIA AI-driven Generative AI or RAG capabilities, we have developed a feedback functionality.

This feedback functionality allows the estimation of the user’s satisfaction regarding the obtained response.

The user can provide feedback by clicking on a thumbs-up icon if the quality and appropriateness of the answer is correct or selecting the thumbs-down icon if the response misses the point, contains hallucinations, or is unclear.

Functional operation

The underlying process is summarized in the following lines and schematically shown in the figure below:

An application sends a request to aura-gateway-api generative with a correlator.
Firstly, it passes through Kernel (Telefónica Digital Ecosystem) for authentication and security purposes.
aura-gateway-api processes the received request and sends the request to the auto-generative content generator atria-model-gateway to obtain an appropriate response.
atria-model-gateway generates the most appropriate response and sends it back to aura-gateway-api.
aura-gateway-api sends the response back to the service that initiated the request with the same correlator and a session identifier.
An application sends a request to aura-gateway-api feedback with:
- A new header correlator
- The sessionId received in the path
- The field msg_corrid, in the body, that indicates the correlator of the message the feedback is about.
aura-gateway-api processes the received request and communicates with atria-model-gateway to send this request.
atria-model-gateway stores the feedback.
aura-gateway-api communicates a 204 to the application.