1 - ATRIA components default configuration
ATRIA components default configuration
Description of the default configuration (internal configuration) for ATRIA components
Introduction
The default configuration of ATRIA corresponds to the server configuration, that is, the internal configuration for ATRIA components.
Within a specific configuration type, parameters are organized by component:
- Fields for atria-model-gateway configuration
- Fields for atria-rag-server
- Common fields for both components
1. Server configuration
Fields related to the internal configuration of ATRIA components
Target users: ATRIA development and installation teams
The default server configuration fields are non-modifiable by ATRIA constructors (excepting prompts)
1.1. Logging configuration
Configuration field shared between atria-model-gateway and atria-rag-server that enables the configuration of logs in a customizable and independent way
The logging configuration is done through a json configuration file that is set by default, as shown below.
{
"version": 1,
"disable_existing_loggers": false,
"logging": {
"handlers": {
"hdl2": {
"class": "logging.StreamHandler",
"formatter": "json",
"level": <AUTOCOMPLETED>
}
},
"loggers": {
"atria_model_gw": {
"level": <AUTOCOMPLETED>,
"handlers":[
"hdl2"
],
"filters":[],
"propagate": false
}
},
"root": {
"level": <AUTOCOMPLETED>,
"handlers": []
}
}
}
Fields
The main fields are explained below. However, for more details, developers are kindly requested to read the General Python logging documentation
| Parameter |
Subparameters |
Definition |
Type/Default values |
version |
|
Version of the logging configuration |
number |
disable_existing_loggers |
|
Boolean value to indicate whether or not the already existing loggers when this call is made are disabled or not |
boolean |
handlers |
|
Dictionary with different logging handlers. Each key is the name of a handler |
|
|
class |
It is configured with Python logging handlers (See Python documentation) |
|
|
formatter |
It configures the format of logs. |
json, string, console, simple |
|
level |
Level of the logging event. It must be filled with the labels |
INFO, ERROR, WARN or DEBUG |
loggers |
|
Python dictionary in which each key is a logger name and each value is a dictionary describing how to configure the corresponding logger instance |
|
|
level |
(Optional) Level of the logger. |
|
|
handlers |
(Optional) List with the IDs of the handlers for this logger |
|
|
filters |
(Optional) List with the IDs of the filters for this logger |
|
root |
|
Configuration for the root logger. |
|
|
level |
(Optional) Level of the logger. |
|
|
handlers |
(Optional) List with the IDs of the handlers for this logger |
|
1.2. atria-model-gateway default configuration
This section includes the parameters configured by default in atria-model-gateway:
Defaults
General-purpose field with parameters to define the behavior of atria-model-gateway
Defaults fields
| Parameter |
Subparameters |
Definition |
Type/Default values |
session_params |
|
(Optional) Default values for a session |
object |
|
window |
(Optional) Session window |
number |
|
timeout |
(Optional) Session expiration time |
number |
service_params |
|
(Optional) Default values for the server |
object |
|
preflight_max_age |
(Optional) Preflight max age |
number |
messages |
|
(Optional) Message options |
object |
|
types |
(Optional) Types of messages. |
list[string] |
openai_proxy |
|
Activate OpenAI proxy |
boolean |
trimmer |
|
(Optional) Expression to trim the response |
string |
If the timeout is 0, the last conversation in the session will not be saved, but the session history will be used.
Defaults by default
The default configuration is described as follows:
defaults:
# Default values for a session
session_params:
window: 2
timeout: 3600
# Default values for the server
service_params:
preflight_max_age: 86400
# Message options
messages:
types:
- feedback
# Activate openai proxy
openai_proxy: false
Redis
This section includes the Redis connection configuration for atria-model-gateway.
Redis fields
| Parameter |
Definition |
Type/Default values |
|
connection_mode |
(Mandatory) Connection mode |
single, sentinel, cluster |
|
pool_size |
(Mandatory) Pool size |
number |
|
database |
(Mandatory) Database |
number |
|
password |
(Mandatory) Password |
string |
|
uri |
(Mandatory) URI name |
string |
|
prefix |
(Mandatory) Prefix |
string |
|
sleep_time |
(Optional) Sleep time |
number |
|
max_retries |
(Optional) Maximum number of retries |
number |
|
Redis by default
The default configuration for Redis is described as follows:
redis:
connection_mode: <AUTOCOMPLETED>
pool_size: 100
database: <AUTOCOMPLETED>
password: <AUTOCOMPLETED>
uri: <AUTOCOMPLETED>
prefix: <AUTOCOMPLETED>
Redis Subscriber
This section includes the Redis event subscriber connection configuration for atria-model-gateway.
Redis subscriber fields
| Parameter |
Definition |
Type/Default values |
|
connection_mode |
(Mandatory) Connection mode |
single, sentinel, cluster |
|
pool_size |
(Mandatory) Pool size |
number |
|
database |
(Mandatory) Database |
number |
|
password |
(Mandatory) Password |
string |
|
uri |
(Mandatory) URI name |
string |
|
prefix |
(Mandatory) Prefix |
string |
|
sleep_time |
(Optional) Sleep time |
number |
|
max_retries |
(Optional) Maximum number of retries |
number |
|
channels |
List of channels to subscribe to |
list[string] |
|
Redis subscriber by default
The default configuration for Redis is described as follows:
redis_subscriber:
connection_mode: <AUTOCOMPLETED>
pool_size: 100
database: <AUTOCOMPLETED>
password: <AUTOCOMPLETED>
uri: <AUTOCOMPLETED>
prefix: <AUTOCOMPLETED>
channels:
- "ApplicationConfiguration"
- "PresetConfiguration"
Config API
Field with parameters for the API configuration for atria-model-gateway
Config API fields
| Parameter |
Definition |
Type/Default values |
|
base_url |
(Mandatory) API config URL |
string |
|
api_key |
(Mandatory) APIKey |
string |
|
Config API by default
The default configuration is described as follows:
aura_config_api:
base_url: <AUTOCOMPLETED>
api_key: <AUTOCOMPLETED>
Allow logging prompts with INFO level
Field to allow logging prompt with INFO level for atria-model-gateway.
It should only be used for debugging errors in environments where there are no debug logs. Due to the size of the prompts, this variable should be set to false once it is not needed.
Allow logging prompts
| Parameter |
Definition |
Type/Default values |
|
allow_log_prompts |
Allow logging prompts |
boolean |
|
Allow logging prompts by default
The default configuration is described as follows:
Models
Predefined AI models included in atria-model-gateway by default.
The model(s) to be used must be selected when configuring an application.
Model fields
| Parameter |
Subparameters |
Definition |
Type/Default values |
type |
|
(Mandatory) Identifier type of model |
rag, openai, mock, perplexity |
name |
|
(Optional) Model name. If this value does not exist, id is used |
string |
class_params |
|
(Mandatory) Preset description |
object |
|
endpoint |
(Mandatory) Endpoint of the model |
string |
|
type |
(Mandatory for RAG) Type of the model |
langchain |
|
path |
(Mandatory for RAG) Path of endpoint model |
string |
|
azure_name |
(Mandatory for OpenAI) Azure name of the model |
string |
|
model_name |
(Mandatory for OpenAI) Model name |
string |
|
api_key |
(Mandatory for OpenAI) APIkey to be used in the model call |
string |
|
api_version |
(Mandatory for OpenAI) API version to be used in the model call |
string |
|
output |
(Mandatory for mocks) Response to be used in the model call |
string |
description_params |
|
(Optional) Description of the model params |
object |
|
context_window |
(Optional) Context window of model |
number |
tokenizer |
|
(Optional) Tokenizer of model |
string |
Models by default
atria-rag model
Model for using the atria-rag-server.
The default configuration is described as follows:
atria-rag:
type: rag
name: Rag server model
class_params:
type: langchain
endpoint: <AUTOCOMPLETED>
path: <AUTOCOMPLETED>
gpt-4
Model for using Azure OpenAI GPT-4 model.
The default configuration is described as follows:
gpt-4:
type: openai
local: false
class_params:
azure_name: deployment_gpt-4
model_name: gpt-4
api_key: <AUTOCOMPLETED>
endpoint: <AUTOCOMPLETED>
api_version: <AUTOCOMPLETED>
timeout:
timeout: 60
read: 60
description_params:
context_window: 300
gpt-4o
Model for using Azure OpenAI GPT-4o model.
The default configuration is described as follows:
gpt-4o:
type: openai
local: false
class_params:
azure_name: deployment_gpt-4o
model_name: gpt-4o
api_key: <AUTOCOMPLETED>
endpoint: <AUTOCOMPLETED>
api_version: <AUTOCOMPLETED>
timeout:
timeout: 60
read: 60
description_params:
context_window: 128000
gpt-4o-mini
Model for using Azure OpenAI GPT-4o-mini model.
The default configuration is described as follows:
gpt-4o-mini:
type: openai
local: false
class_params:
azure_name: deployment_gpt-4o-mini
model_name: gpt-4o-mini
api_key: <AUTOCOMPLETED>
endpoint: <AUTOCOMPLETED>
api_version: <AUTOCOMPLETED>
timeout:
timeout: 60
read: 60
description_params:
context_window: 128000
o3-mini
Model for using Azure OpenAI o3-mini model.
The default configuration is described as follows:
o3-mini:
type: openai
local: false
class_params:
azure_name: deployment_o3-mini
model_name: o3-mini
api_key: <AUTOCOMPLETED>
endpoint: <AUTOCOMPLETED>
api_version: <AUTOCOMPLETED>
timeout:
timeout: 60
read: 60
description_params:
context_window: 128000
gpt-4.1-nano
Model for using Azure OpenAI gpt-4.1-nano model.
gpt-4.1-nano:
type: openai
local: false
class_params:
azure_name: deployment_gpt-4.1-nano
model_name: gpt-4.1-nano
api_key: <AUTOCOMPLETED>
endpoint: <AUTOCOMPLETED>
api_version: <AUTOCOMPLETED>
timeout:
timeout: 60
read: 60
description_params:
context_window: 128000
perplexity-sonar
This model will be available in ATRIA in upcoming releases.
Model for using Perplexity sonar model.
The default configuration is described as follows:
perplexity-sonar:
type: perplexity
local: false
class_params:
model_name: sonar
api_key: <AUTOCOMPLETED>
endpoint: <AUTOCOMPLETED>
timeout:
timeout: 20
read: 45
http_raise_when_retry_limit_exceeded_recognizer: false
description_params:
context_window: 300
Important: This model does not support the same parameters as the previous ones. Check Microsoft document API & feature support.
The following parameters are not supported by the model: temperature, top_p, presence_penalty, frequency_penalty, logprobs, top_logprobs, logit_bias, max_tokens.
1.3. atria-rag-server default configuration
This section includes the parameters configured by default in atria-rag-server:
LLMs
Predefined parameter to define the Large Language Models (LLMs) that call from atria-model-gateway to atria-rag-server.
Currently, only one LLM with the necessary configuration to connect atria-model-gateway to atria-rag-server is defined. It cannot be modified.
LLMs fields
| Parameter |
Subparameters |
Definition |
Type/Default values |
name |
|
(Optional) LLM name. If this value does not exist, id is used |
string |
model_type |
|
(Mandatory) Model type |
string |
endpoint |
|
(Mandatory) Endpoint of the model |
string |
LLm by default
atria-model-gateway:
atria_model_gateway:
name: Local Model Gateway
model_type: llm_manager
endpoint: http://atria-model-gw:6391/aura-services/v1/atria-model-gw
Embeddings
Parameters to define the embeddings, vector representations to find text blocks that contain the information to resolve the input request.
Two types of Embeddings are available for use:
- Local Embeddings: Generated by the atria-rag-server in local mode.
- Embeddings OpenAI: Generated by OpenAI.
Embeddings fields
| Parameter |
Subparameters |
Definition |
Type/Default values |
name |
|
(Mandatory) Embedding name |
string |
type |
|
(Mandatory) LLM name. Type of the model |
sentence_transformer, azure_openai |
model |
|
(Mandatory) Used model |
string |
openai_api_version |
|
(Mandatory to call Azure OpenAI) OpenAI API version |
string |
openai_api_type |
|
(Mandatory to call Azure OpenAI) OpenAI API type |
string |
openai_api_key |
|
(Mandatory to call Azure OpenAI) OpenAI APIKey |
string |
azure_endpoint |
|
(Mandatory to call Azure OpenAI) Azure endpoint |
string |
Embeddings by default
The predefined embeddings in atria-rag-server are shown below:
Local Sentence Transformer from HuggingFace:
This is an open-source model that appears in sentence-transformers library.
It maps sentences & paragraphs to a 384 dimensional dense vector space and can be used for several tasks like:
- Clustering
- Multilingual similarity searches
- Retrieval-based tasks
- Classification
A brief characterization of this embedding regarding different parameters is included below:
- Cost: Free to use once downloaded (local execution). No API call costs.
- Latency: Low, since it runs locally without external API calls.
- Performance: Satisfactory for general-purpose sentence embeddings, supporting multiple languages.
- Vector Length: 384 dimensions (smaller than OpenAI’s ADA model).
- Hardware Requirements: Needs a GPU for faster inference; otherwise, it can be slow on a CPU.
- Model Size: Requires local storage (~120MB).
- Quality: Slightly lower accuracy than larger models, especially for complex NLP tasks.
This embedding can be configured with a yaml file:
local_st:
name: Local Sentence Transformer from HuggingFace
type: sentence_transformer
model: paraphrase-multilingual-MiniLM-L12-v2
Distilbert-based Local Sentence Transformer from HuggingFace
This is an open-source model that appears in sentence-transformers library.
It has been trained on 215M (question, answer) pairs from diverse sources.
It maps sentences & paragraphs to a 768 dimensional dense vector space and was designed for several tasks like:
- Semantic search
- Question answering
- Passage retrieval
A brief characterization of this embedding regarding different parameters is included below:
- Cost: Free (local execution). No API call costs.
- Latency: Fast, optimized for question-answer retrieval tasks.
- Performance: Outperforms MiniLM in retrieval-based tasks due to DistilBERT’s training on QA data.
- Vector Length: 768 dimensions (higher than MiniLM, better at capturing semantics).
- Hardware Requirements: Similar to MiniLM, requires a GPU for optimal performance.
- Model Size: Larger than MiniLM (~250MB).
- Quality: Primarily trained for English, not as strong for multilingual applications.
This embedding can be configured with a yaml file:
test_distilbert:
name: Distilbert-based Local Sentence Transformer from HF
type: sentence_transformer
model: multi-qa-distilbert-cos-v1
OpenAI Embeddings ADA
This is one of OpenAI’s latest models for generating embeddings and has quickly become a top choice for tasks:
- Recommendation systems
- Chatbots
- Semantic search
- Large-scale applications
A brief characterization of this embedding regarding different parameters is included below:
- Cost: Paid API model (depends on token usage, $0.0001/1k Tokens). It can be expensive for high-volume applications.
- Latency: API calls introduce certain delay, specially in large-scale real-time applications.
- Performance: State-of-the-art embeddings with high accuracy for a wide range of NLP tasks.
- Hardware Requirements: No local hardware requirements, it works via API.
- Vector Length: 1536 dimensions (rich semantic representation).
- Quality: Strong performance across multiple languages.
This embedding can be configured with a yaml file:
text-embedding-ada-002:
name: text-embedding-ada-002 model from Azure OpenAI API
type: azure_openai
model: deployment_text-embedding-ada-002
openai_api_version: <AUTOCOMPLETED>
openai_api_type: azure
openai_api_key: <AUTOCOMPLETED>
azure_endpoint: <AUTOCOMPLETED>
Redis Subscriber
This section includes the Redis event subscriber connection configuration for the atria-rag-server.
Redis subscriber fields
| Parameter |
Definition |
Type/Default values |
|
connection_mode |
(Mandatory) Connection mode |
single, sentinel, cluster |
|
pool_size |
(Mandatory) Pool size |
number |
|
database |
(Mandatory) Database |
number |
|
password |
(Mandatory) Password |
string |
|
uri |
(Mandatory) URI name |
string |
|
prefix |
(Mandatory) Prefix |
string |
|
sleep_time |
(Optional) Sleep time |
number |
|
max_retries |
(Optional) Maximum number of retries |
number |
|
channels |
List of channels to subscribe to |
list[string] |
|
Redis subscriber by default
The default configuration for Redis is described as follows:
redis_subscriber:
connection_mode: <AUTOCOMPLETED>
pool_size: 100
database: <AUTOCOMPLETED>
password: <AUTOCOMPLETED>
uri: <AUTOCOMPLETED>
prefix: <AUTOCOMPLETED>
channels:
- "PresetConfiguration"
Prompts
A prompt is defined as an input instruction given to an AI model to generate a response. It guides the AI in the required kind of output.
A prompt by default is defined in ATRIA for different RAG stages. This can be used when a specific prompt is not defined in the preset.
Prompts structure for RAG
The hierarchy of default prompts in RAG stages is shown below:
prompts
|___ <stage>
|___ default
| |___ text
| |___ args
|___ <language>
|___ text
|___ args
-
The first level in the prompts configuration are the stages of the RAG process. Each stage has its own configuration and purpose.
-
Prompts configuration works at language level, so it is possible to have different prompts for different languages, indicated by the language code:
<language>: Any language prompt configuration (ISO 639-1 Code)
default: Default prompt configuration (in a specific language)
-
For each language, the prompts structure must include the fields text and args:
- text: This field contains the text of the prompt that will be sent to the language model. It includes placeholders (e.g., {query}, {target_language}) that are mandatory for the prompt to work. These placeholders will be dynamically replaced with the specific values when the prompt is executed.
- args: Optional field that contains a dictionary of arguments that will be used to replace the placeholders in the
text field.
Default prompts in RAG stages
The following stages are currently defined in RAG:
cleanStg
This stage is responsible for cleaning the user query. It ensures that the query is in a proper format before further processing.
See how to include this stage in the default prompt code here
translationStg
This stage handles the translation of the user query into the target language, if necessary.
See how to include this stage in the default prompt code here
contextStg
This stage determines the context of the user query, ensuring it is aligned with the previous conversation or context.
Default prompts in this stage:
sameContext: Configuration to check if the query is in the same context.
recreatedQuestion: Configuration to rewrite the original question. It is composed of following prompts:
default: Configuration for rewriting the original question.
system: System prompt configuration.
human: Human prompt configuration.
system: System prompt configuration.
human: Human prompt configuration.
order: Array of strings with prompts names sorted.
See how to include this stage in the default prompt code here
postFilteringStg
This stage filters the retrieved documents or data to ensure relevance to the user query.
Default prompts in this stage:
relevantDocument: Configuration to check if the document is relevant.
relevantSql: Configuration to check if the SQL data is relevant.
See how to include this stage in the default prompt code here
generativeStg
This stage generates the final response using the retrieved and filtered data.
Default prompts in this stage:
stuff: Configuration for the “stuff” strategy. It is composed of the following sub-stages:
default: Configuration for the “stuff” strategy.
system: System prompt configuration.
human: Human prompt configuration.
notAnswerResponse: Configuration for responses when the question cannot be answered.
informationExtraction: Configuration for extracting information. It is composed of following prompts:
human1: Human prompt configuration.
ia: IA prompt configuration.
human: Human prompt configuration.
responseConsolidation: Configuration for consolidating the response.
sqlPrompt: Configuration for generating SQL query statements.
See how to include this stage in the default prompt code here
RAG default prompt
The current section includes the prompt defined by default for ATRIA RAG capability.
You can also access the yaml file in the Github repository.
In case of any discrepancy between the content of this document and that on GitHub, the GitHub version shall always be considered the most up-to-date
RAG default prompt
prompts:
cleanStg:
es:
text: |
A continuación hay una consulta del usuario.
Por favor, limpie la consulta y responda solo con la pregunta del usuario o alguna charla informal.
-------
{query}
default:
text:
A user query follows.
Please clean the query and respond with just the user question or small talk. The query must be written in English.
-------
{query}
translationStg:
default:
text: |
Translate the following question to {target_language}: {question}
Instructions:
1. Maintain the formal tone of the original text.
2. Do not translate proper names and specific terms (e.g., company names, product names, countries).
3. Provide the translation in the same format and structure as the original text.
Translated Text:
Finally, return the result as a unique JSON object, with the following structure:
```
{{
"source_languge": The original question language,
"target_language": The target language,
"translation": The translation of the question to the target_language. ,
"possible": true|false,
"reason": The reason why it is possible or not possible to translate the question.
}}
```
contextStg:
sameContext:
default:
text: |
Below is a conversation followed by a question. You must determine if the question corresponds to the same context as the conversation or if it is from a different context.
Respond only with: [SAME CONTEXT] o [DIFFERENT CONTEXT]
Conversation:
{memory}
Question:
{query}
es:
text: |
A continuación hay una conversación y seguidamente una pregunta. Debes responder si la pregunta corresponde al mismo contexto de la conversación o es una pregunta de un contexto diferente.
Responde únicamente con: [MISMO CONTEXTO] o [DIFERENTE CONTEXTO]
Conversación:
{memory}
Pregunta:
{query}
recreatedQuestion:
default:
default:
text: |
Answer with just a new question or the original question.
Rewrite the original question only if it follows the conversation. Always rewritten question in the same language as the user's question.
Conversation:
{memory}
Original question:
{query}
Rewritten question:
es:
text: |
Responde sólamente con una nueva pregunta.
Reescribe la pregunta original si es una continuación de la conversación. Utiliza el idioma de la peticion del usuario para rescribir la pregunta.
Conversación:
{memory}
Pregunta original:
{query}
Pregunta reescrita:
system:
default:
text: |
The user text contains a query, plus the previous conversation turn.
- If the previous conversation is relevant for the current query, incorporate it into the query and produce a rewritten query
- else just repeat the current query.
Always rewrite the question in the same language as the user's question.
es:
text: |
El texto del usuario contiene una consulta, además del turno anterior de la conversación.
- Si la conversación anterior es relevante para la consulta actual, incorpórala en la consulta y produce una consulta reescrita.
- Si no es relevante, simplemente repite la consulta actual.
Reescribe siempre la consulta en el mismo idioma en que está formulada la consulta del usuario.
human:
default:
text: |
Previous conversation:
{memory}
Current query:
{query}
Rewritten query:
es:
text: |
Conversación anterior:
{memory}
Consulta actual:
{query}
Consulta reescrita:
order: ["system", "human"]
postFilteringStg:
relevantDocument:
default:
text: |
Below is an excerpt of text followed by a question. You must determine if the excerpt is relevant or irrelevant for answering the question.
Respond only with: [RELEVANT] o [IGNORABLE]
Excerpt:
{extract}
Question:
{query}
es:
text: |
A continuación hay un extracto de texto y seguidamente una pregunta. Debes responder si el extracto es relevante o ignorable para responder la pregunta.
Responde únicamente con: [RELEVANTE] o [IGNORABLE]
Extracto:
{extract}
Pregunta:
{query}
relevantSql:
default:
text: |
Given the following question:
`{question}`
Is it possible to answer, using the data contain in the following table?:
```sql
{sql_table_definition}
```
**Explain briefly, all your decisions**.
First, identify which tables are necessary to answer the question. Justify why you selected each of these tables.
Use the following format:
```
I need the following tables to answer the question:
- <table_name>: <reasoning>
- <table_name>: <reasoning>
...
```
Then, identify which columns are necessary to answer the question. Justify why you selected each of these columns.
Write the list of columns you identified, and the reasoning after each column, using the following format:
```
I need the following columns to answer the question:
- <table name>:
- <column_name>: <reasoning>
- <column_name>: <reasoning>
...
- <table_name>:
- <column_name>: <reasoning>
- <column_name>: <reasoning>
...
...
```
Then, tell if the tables and columns you identified are enough to answer the question.
Write the answer using the following format:
```
Possible to answer the question using the former columns:
- <reasoning>
- Result: <Yes|No>
```
Then, explain, step by step, how you would write the SQL query to answer the question, using the columns you identified.
**Use the full qualified names of the columns**. **DO NOT USE THE `JSON_OBJECT` FUNCTION IN THE QUERY**.
Finally, tell if the question can be answered using this format:
```
{{
"possible": true|false,
"reason": The reason why it is possible or not possible to answer the question.
}}
```
generativeStg:
stuff:
default:
default:
text: |
Use the following context extractions to answer the question at the end.
Contexto:
{context}
If the extracted context do not contain the answer avoid coming up with an answer, and response you do not have information for answering and kindly invite the user to make a new question.
Question:
{question}
Never include information by your own using your own knowledge.
{extra_prompt}
es:
text: |
Utilice el siguiente contexto que ha sido extraido para responder la pregunta del final.
Contexto:
{context}
Usando esta información, responde a la pregunta del usuario.
Si la información no contiene la respuesta evita firmemente responder, di que desconoces la respuesta e invita educadamente al usuario a que formule una nueva pregunta.
Pregunta:
{question}
Nunca incluyas información utilizando tus propios conocimientos.
{extra_prompt}
system:
default:
text: |
Respond in language {user_query_language}.
Question:
{question}
args:
user_query_language: "#.auto.language.user_query"
es:
text: |
Responde en el idioma {user_query_language}.
Pregunta:
{question}
args:
user_query_language: "#.auto.language.user_query"
human:
default:
text: |
You are going to generate an answer for a user question or query.
To generate the answer, take always into account all the information available in the context provided.
Context:
{context}
Question:
{question}
Never include information by your own using your own knowledge.
{extra_prompt}
es:
text: |
Vas a generar una respuesta para una pregunta o consulta del usuario.
Para generar la respuesta, ten siempre en cuenta toda la información disponible en el contexto proporcionado.
Pregunta:
{question}
Contexto:
{context}
Nunca incluyas información utilizando tus propios conocimientos.
{extra_prompt}
order: ["system", "human"]
notAnswerResponse:
default:
text: |
You are a question answering agent. You have tried to answer this question: {query}
However you do not have information to answer this.
Please, tell the user that you are not able to answer, apologize and invite the user to make other question.
Avoid any harmful answer, such as sexual, rude, sexist or racist.
Respond in language {user_query_language}.
User question:
{query}
args:
user_query_language: "#.auto.language.user_query"
es:
text: |
Eres un agente de respuesta a preguntas. Has intentado responder a esta pregunta: {query}
Sin embargo, no tienes información para responder a esto.
Por favor, dile al usuario que no puedes responder, discúlpate e invita al usuario a hacer otra pregunta.
Evita cualquier respuesta dañina, como sexual, grosera, sexista o racista.
Responde en el idioma {user_query_language}.
Pregunta del usuario:
{query}
args:
user_query_language: "#.auto.language.user_query"
informationExtraction:
default:
default:
text: |
The original question is this: {question}
We have provided a previous answer: {existing_answer}
Only if necessary, refine the answer exclusively with the context below.
------------
{context_str}
------------
Given the new context, refine the original answer to improve the quality of the response.
If the context is useless, respond with the exact words of the original answer.
{extra_prompt}
es:
text: |
La pregunta original es esta: {question}
Hemos proporcionado una respuesta previa: {existing_answer}
Sólo si es necesario refina la respuesta exclusivamente con el contexto a continuación.
------------
{context_str}
------------
Dado el nuevo contexto, refina la respuesta original para mejorar la calidad de la respuesta.
Si el contexto es inútil responde con las mismas palabras de la respuesta original.
{extra_prompt}
human1:
default:
text: "{question}"
es:
text: "{question}"
ia:
default:
text: "{existing_answer}"
es:
text: "{existing_answer}"
human:
default:
text: |
Refine the existing answer only if necessary, exclusively with the context below.
------------
{context_str}
------------
Given the new context, refine the original answer to improve the quality of the response.
If the context is useless, respond with the exact words of the original answer.
{extra_prompt}
es:
text: |
Refina la respuesta existente, sólo si es necesario, exclusivamente con el contexto a continuación.
------------
{context_str}
------------
Dado el nuevo contexto, refina la respuesta original para mejorar la calidad de la respuesta.
Si el contexto es inútil responde con las mismas palabras de la respuesta original.
{extra_prompt}
order: ["human1", "ia", "human"]
responseConsolidation:
default:
default:
text: |
Below I provide you a context.
---------------------
{context_str}
---------------------
Given exclusively the context, and without using any prior knowledge, respond with a single sentence to the question:
{question}
{extra_prompt}
es:
text: |
A continuación te doy un contexto.
---------------------
{context_str}
---------------------
Dado exclusivamente el contexto, y sin usar ningún conocimiento previo responde con una única frase a la pregunta:
{question}
{extra_prompt}
system:
default:
text: |
Below I provide you a context.
---------------------
{context_str}
---------------------
Given exclusively the context, and without using any prior knowledge, respond with a single sentence to the question:
{question}
{extra_prompt}
es:
text: |
A continuación te doy un contexto.
---------------------
{ context_str }
---------------------
Dado exclusivamente el contexto y sin usar ningún conocimiento previo responde con una única frase a cualquier pregunta.
{ extra_prompt }
human:
default:
text: "{question}"
es:
text: "{question}"
order: ["system", "human"]
sqlPrompt:
default:
text: |
Generate a SQL query statement to answer the following question:
`{question}`
Use the data contained in the following table, as defined in SQL:
```sql
{sql_table_definition}
```
The following tables, containing auxiliary information, are also available:
```sql
CREATE TABLE D_CBD_Static_Geo_Area_v6 (GEO_AREA_ID VARCHAR, CBD_GEO_AREA_LEVEL1_ID VARCHAR, CBD_GEO_AREA_LEVEL2_ID VARCHAR, CBD_GEO_AREA_LEVEL3_ID VARCHAR, CBD_GEO_AREA_LEVEL4_ID VARCHAR, OB_ALPHA_ID VARCHAR, EXTRACTION_TM VARCHAR);
COMMENT ON TABLE D_CBD_Static_Geo_Area IS 'Geographical areas. This table contains foreign keys to the different levels of geographical areas. In particular, it contains the foreign keys to these tables: CBD_Static_Geo_Area_Level1, CBD_Static_Geo_Area_Level2, CBD_Static_Geo_Area_Level3, CBD_Static_Geo_Area_Level4. Therefore, this tables is used, via JOIN, to query the geographical information contained in the different levels of geographical areas. For instance, if you have a table T with a field GEO_AREA_ID and you need to check whether this location corresponds to the region of Asturias you will need to look for GEO_AREA_ID in this table, then extract the CBD_GEO_AREA_LEVEL4_ID and query the table CBD_Static_Geo_Area_Level4 to get the name of the region.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area.GEO_AREA_ID IS 'Identifier of the geographical area considered. FORMAT: string containing a numerical code. This field does not contain location names.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area.CBD_GEO_AREA_LEVEL1_ID IS 'Identifier of the geographical area Level 1 (max level of detail: CP or similar). FORMAT: string containing a numerical code. This field does not contain location names.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area.CBD_GEO_AREA_LEVEL2_ID IS 'Identifier of the geographical area Level 2 (City/Town). FORMAT: string containing a numerical code. This field does not contain location names.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area.CBD_GEO_AREA_LEVEL3_ID IS 'Identifier of the geographical area Level 3 (Province). FORMAT: string containing a numerical code. This field does not contain location names.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area.CBD_GEO_AREA_LEVEL4_ID IS 'Identifier of the geographical area Level 4 (State/Region). FORMAT: string containing a numerical code. This field does not contain location names.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area.OB_ALPHA_ID IS 'Alphanumeric Organizational Business ID';
COMMENT ON COLUMN D_CBD_Static_Geo_Area.EXTRACTION_TM IS 'Date-time of the record';
CREATE TABLE D_CBD_Static_Geo_Area_Level2_v6 (CBD_GEO_AREA_LEVEL2_ID VARCHAR, GEO_AREA_LEVEL_DES VARCHAR, CBD_GEO_AREA_LEVEL3_ID VARCHAR, LONGITUDE_LON_CO DOUBLE, LATITUDE_LAT_CO DOUBLE, GEO_AREA_ID VARCHAR, GEO_STD_AREA_CD VARCHAR, OB_ALPHA_ID VARCHAR, EXTRACTION_TM VARCHAR);
COMMENT ON TABLE D_CBD_Static_Geo_Area_Level2 IS 'Geographical area level 2 (State)';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level2.CBD_GEO_AREA_LEVEL2_ID IS 'Identifier of the geographical area Level 2 (City/Town). FORMAT: string containing a numerical code.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level2.GEO_AREA_LEVEL_DES IS 'Description associated to the identifier level 2. FORMAT: alphanumeric string containing the name of the city/town.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level2.CBD_GEO_AREA_LEVEL3_ID IS 'Identifier of the geographical area Level 3 (Province)';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level2.LONGITUDE_LON_CO IS 'Longitude coordinates (in WGS84) associated with level 2';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level2.LATITUDE_LAT_CO IS 'Latitude coordinates (in WGS84) associated with level 2';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level2.GEO_AREA_ID IS 'Identifier of the geographical area considered. FORMAT: string containing a numerical code.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level2.GEO_STD_AREA_CD IS 'Standard code of the geo area';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level2.OB_ALPHA_ID IS 'Alphanumeric Organizational Business ID';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level2.EXTRACTION_TM IS 'Date-time of the record';
CREATE TABLE D_CBD_Static_Geo_Area_Level3_v6 (CBD_GEO_AREA_LEVEL3_ID VARCHAR, GEO_AREA_LEVEL_DES VARCHAR, CBD_GEO_AREA_LEVEL4_ID VARCHAR, LONGITUDE_LON_CO DOUBLE, LATITUDE_LAT_CO DOUBLE, ISO_3166_2_CD VARCHAR, GEO_AREA_ID VARCHAR, GEO_STD_AREA_CD VARCHAR, OB_ALPHA_ID VARCHAR, EXTRACTION_TM VARCHAR);
COMMENT ON TABLE D_CBD_Static_Geo_Area_Level3 IS 'Geographical area level 3 (Region)';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level3.CBD_GEO_AREA_LEVEL3_ID IS 'Identifier of the geographical area Level 3 (Province). FORMAT: string containing a numerical code.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level3.GEO_AREA_LEVEL_DES IS 'Description associated to the identifier level 3. FORMAT: alphanumeric string containing the name of the province.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level3.CBD_GEO_AREA_LEVEL4_ID IS 'Identifier of the geographical area Level 4 (State/Region). FORMAT: string containing a numerical code.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level3.LONGITUDE_LON_CO IS 'Longitude coordinates (in WGS84) associated with level 3';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level3.LATITUDE_LAT_CO IS 'Latitude coordinates (in WGS84) associated with level 3';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level3.ISO_3166_2_CD IS 'ISO 3166-2 associated';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level3.GEO_AREA_ID IS 'Identifier of the geographical area considered. FORMAT: string containing a numerical code.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level3.GEO_STD_AREA_CD IS 'Standard code of the geo area';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level3.OB_ALPHA_ID IS 'Alphanumeric Organizational Business ID';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level3.EXTRACTION_TM IS 'Date-time of the record';
CREATE TABLE D_CBD_Static_Geo_Area_Level4_v6 (CBD_GEO_AREA_LEVEL4_ID VARCHAR, GEO_AREA_LEVEL_DES VARCHAR, LONGITUDE_LON_CO DOUBLE, LATITUDE_LAT_CO DOUBLE, HASC_1_CD VARCHAR, GEO_AREA_ID VARCHAR, GEO_STD_AREA_CD VARCHAR, OB_ALPHA_ID VARCHAR, EXTRACTION_TM VARCHAR);
COMMENT ON TABLE D_CBD_Static_Geo_Area_Level4 IS 'Geographical area level 4 (min. Detail)';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level4.CBD_GEO_AREA_LEVEL4_ID IS 'Identifier of the geographical area Level 4 (State/Region). FORMAT: string containing a numerical code.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level4.GEO_AREA_LEVEL_DES IS 'Description associated to the identifier level 4. FORMAT: alphanumerical string containing the name of the state/region. EXAMPLE VALUES: ''Asturias'', ''Andaluc\u00eda'', etc.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level4.LONGITUDE_LON_CO IS 'Longitude coordinates (in WGS84) associated with level 4';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level4.LATITUDE_LAT_CO IS 'Latitude coordinates (in WGS84) associated with level 4';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level4.HASC_1_CD IS 'Hierarchical administrative subdivision codes ';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level4.GEO_AREA_ID IS 'Identifier of the geographical area considered. FORMAT: string containing a numerical code.';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level4.GEO_STD_AREA_CD IS 'Standard code of the geo area';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level4.OB_ALPHA_ID IS 'Alphanumeric Organizational Business ID';
COMMENT ON COLUMN D_CBD_Static_Geo_Area_Level4.EXTRACTION_TM IS 'Date-time of the record';
CREATE TABLE D_CBD_Static_Station_Type_v6 (STATION_TYPE_CD VARCHAR, TECH_LEVEL_WEIGHT_QT FLOAT, STATION_TYPE_L2_DES VARCHAR, STATION_TYPE_L1_DES VARCHAR, STATION_TYPE_L2_ORDER_NUM INT, STATION_TYPE_L1_ORDER_NUM INT, STATION_TYPE_ORDER_NUM INT, CONSCIOUS_IND BOOLEAN, EXTRACTION_TM VARCHAR);
COMMENT ON TABLE D_CBD_Static_Station_Type IS 'Station types';
COMMENT ON COLUMN D_CBD_Static_Station_Type.STATION_TYPE_CD IS 'Device type';
COMMENT ON COLUMN D_CBD_Static_Station_Type.TECH_LEVEL_WEIGHT_QT IS 'Associated weight for the technologic level of the home';
COMMENT ON COLUMN D_CBD_Static_Station_Type.STATION_TYPE_L2_DES IS 'Station type level 2';
COMMENT ON COLUMN D_CBD_Static_Station_Type.STATION_TYPE_L1_DES IS 'Station type level 1';
COMMENT ON COLUMN D_CBD_Static_Station_Type.STATION_TYPE_L2_ORDER_NUM IS 'Station type order level 2';
COMMENT ON COLUMN D_CBD_Static_Station_Type.STATION_TYPE_L1_ORDER_NUM IS 'Station type order level 1';
COMMENT ON COLUMN D_CBD_Static_Station_Type.STATION_TYPE_ORDER_NUM IS 'Station type order';
COMMENT ON COLUMN D_CBD_Static_Station_Type.CONSCIOUS_IND IS 'Indicates if the related device type has energy efficiency';
COMMENT ON COLUMN D_CBD_Static_Station_Type.EXTRACTION_TM IS 'Date-time of the record';
CREATE TABLE D_Segment_v8 (OPERATOR_ID VARCHAR, SEGMENT_ID VARCHAR, SEGMENT_DES VARCHAR, GBL_SEGMENT_ID VARCHAR, SEGMENT_GROUP_ID VARCHAR, SEGMENT_GROUP_DES VARCHAR, EXTRACTION_TM VARCHAR);
COMMENT ON TABLE D_Segment IS 'Classifications of the customers, attending to different segmentation criteria, for marketing and management issues, according to OB criteria and its correspondence with the global segment classification';
COMMENT ON COLUMN D_Segment.OPERATOR_ID IS 'Global Operator Identifier (Operator acting as owner of the information present in the current entity)';
COMMENT ON COLUMN D_Segment.SEGMENT_ID IS 'Organisational segment of the client, in the OB. FORMAT: Numerical code.';
COMMENT ON COLUMN D_Segment.SEGMENT_DES IS 'Segment description. This is the actual name of the segment. POSSIBLE VALUES: ''NTT'', ''Residencial'', ''Pymes'', ''Residencial/SC'', ''Autonomos'', ''Operadores'', ''Grandes Clientes'', ''Residencial Prepago'', ''Telefonica'', ''Sin Clasificar'', ''Empresas''';
COMMENT ON COLUMN D_Segment.GBL_SEGMENT_ID IS 'ID of the global segment classification';
COMMENT ON COLUMN D_Segment.SEGMENT_GROUP_ID IS 'ID code of the segmentation group';
COMMENT ON COLUMN D_Segment.SEGMENT_GROUP_DES IS 'Description of the segmentation group. POSSIBLE VALUES: ''0.- OPERADORES'', ''1.- U.N. Empresas'', ''2.-U.N. Gran Público'', ''3.- TELEFONICA'', ''4.- SIN CLASIFICAR''';
COMMENT ON COLUMN D_Segment.EXTRACTION_TM IS 'Date-time of the record';
```
Some of the former tables contains columns in full-qualified format. For instance, these are some examples of full-qualified columns:
```
record_name.field_name
TEC_PLAT_REC.DEVICE_ID
record_name.subrecord_name.field_name
TEC_PLAT_REC.TEC_PLAT_SUBCOMP_REC.DEVICE_ID
...
```
Always use the full-qualified format when referring to columns in the tables. For instance, if you need to use the column 'TEC_PLAT_REC.DEVICE_ID', you should not refer to it as 'DEVICE_ID', but as 'TEC_PLAT_REC.DEVICE_ID'.
**Explain in detail, step by step, all your decisions**.
If you need to filter by a higher level geographical such as a region (Comunidad Autónoma) you will need to:
- join the `GEO_AREA_ID` field of the data table (such as `CBD_HGU_Detail_Daily`) with the `GEO_AREA_ID` field in `D_CBD_Static_Geo_Area` table
- then join the `CBD_GEO_AREA_LEVEL4_ID` field in the `D_CBD_Static_Geo_Area` with the `CBD_GEO_AREA_LEVEL4_ID` field in the `D_CBD_Static_Geo_Area_Level4` table
- then compare the `GEO_AREA_LEVEL_DES` field in the `D_CBD_Static_Geo_Area_Level4` table with the name of the region (e.g., 'Cantabria'), since the DESCRIPTION field does contain the actual name of the geographical area.
**Only perform these joins if explicit filtering or grouping by geographical location is necessary**.
First, identify which tables are necessary to answer the question. Justify why you selected each of these tables.
Use the following format:
```
I need the following tables to answer the question:
- <table_name>: <reasoning>
- <table_name>: <reasoning>
...
```
Then, identify which columns are necessary to answer the question. Justify why you selected each of these columns.
Write the list of columns you identified, and the reasoning after each column, using the following format:
```
I need the following columns to answer the question:
- <table name>:
- <column_name>: <reasoning>
- <column_name>: <reasoning>
...
- <table_name>:
- <column_name>: <reasoning>
- <column_name>: <reasoning>
...
...
```
Then, tell if the tables and columns you identified are enough to answer the question.
Write the answer using the following format:
```
Possible to answer the question using the former columns:
- <reasoning>
- Result: <Yes|No>
```
Then, explain, step by step, how you would write the SQL query to answer the question, using the columns you identified. **Use the full qualified names of the columns**. **DO NOT USE THE `JSON_OBJECT` FUNCTION IN THE QUERY**.
Finally, write the SQL query to answer the question, using the columns you identified. **DO NOT USE THE `JSON_OBJECT` FUNCTION IN THE QUERY**.
Return the result as a unique JSON object, with the following structure:
{{
"result": <Write the SQL query here. **MAKE SURE THAT THE STATEMENT `SELECT JSON_OBJECT` is not used in the query and Use the full qualified names of the columns. Generate a valid SQL sentence in a single line without new line characters.**>,
"status": "OK",
"reason": <a reasoning explaining the query>
}}
If the former table does not contain the necessary data to answer the question, return the following JSON object:
{{
"result": null,
"status": "ERROR",
"reason": <a reasoning explaining the query>
}}
Make sure that the JSON object is correctly formatted, and can be parsed by a JSON parser.
Injection
Default injection configuration for atria-rag-server. It is used to avoid prompt injection.
Injection fields
| Parameter |
Definition |
Type/Default values |
heuristics |
Heuristic sentences. Object, where the key is the language and the value is a list of phrases. Now, by default, the heuristics sentences are defined in the config, the file path is no indicated. It is important to note that the phrases added here will be also added to those defined in the security stage securityStg of the preset configuration. |
object |
| max_length | (Mandatory) Maximum length |number |
Injection by default
The default configuration is described as follows:
injection:
heuristics:
es:
- responde como
- responda como
- respondeme como
- respondame como
en:
- answer like
- forget everything
- forget your
max_length: 200
Service
Defaults service configuration for atria-rag-server.
Service fields
| Parameter |
Definition |
Type/Default values |
host |
(Mandatory) Host name |
string |
port |
(Mandatory) Port id |
number |
Service by default
The default configuration is described as follows:
service:
host: 0.0.0.0
port: <AUTOCOMPLETED>
log_level: <AUTOCOMPLETED>
Local Storage
Defaults fields related to the configuration of the local storage for documents
Local Storage fields
| Parameter |
Definition |
Type/Default values |
atria_resources_data_folder |
(Mandatory) Folder name for data resources |
string |
atria_shared_data_folder |
(Mandatory) Shared data folder name |
string |
Local Storage by default
The default configuration is described as follows:
local_storage_manager:
atria_resources_data_folder: "/opt/atria-rag/data"
atria_shared_data_folder: "/var/atria-rag-data"
Config API
Field with parameters for atria-rag-server API configuration
Config API fields
| Parameter |
Definition |
Type/Default values |
base_url |
(Mandatory) API Config URL |
string |
api_key |
(Mandatory) APIKey |
string |
Config API by default
The default configuration is described as follows:
aura_config_api:
base_url: <AUTOCOMPLETED>
api_key: <AUTOCOMPLETED>
Retrievers
Retriever are responsible for storing the information that have been generated in the documents. Each retriever is associated with a database in order to feed or retrieve information from it.
Currently, there are three different retrievers defined in ATRIA:
-qdrant
-tfidf
-elasticsearch
Retriever fields
Each retriever type has defined specific fields, as shown below:
| Parameter |
Subparameters |
Definition |
Type/Default values |
qdrant |
host |
(Mandatory) Host service Qdrant |
string |
|
port |
(Mandatory) Port service Qdrant |
number |
|
prefix |
(Mandatory) Prefix to collection |
string |
tfidf |
dump_name |
(Mandatory) Dump name of service Tfidf |
string |
elasticsearch |
host |
(Mandatory) Host service Elasticsearch |
string |
|
ca_crt |
(Mandatory) Path certificate Elasticsearch |
string |
|
username |
(Mandatory) Username service Elasticsearch |
string |
|
password |
(Mandatory) Password service Elasticsearch |
string |
|
index_name |
(Mandatory) Index service Elasticsearch |
string |
Retrievers by default
The default configuration is described as follows:
retrievers:
qdrant:
host: <AUTOCOMPLETED>
port: 6333
prefix: <AUTOCOMPLETED>
tfidf:
dump_name: /var/atria-rag-data/tfidf/dump/
Parameter related to the configuration of metadata in atria-rag-server
It is used to setup how metadata is used when providing responses. The retrieving operation produces a list of candidates, each of which may provide a dictionary of metadata. The metadata is used to filter the candidates and provide additional information in the response.
| Parameter |
Subparameters |
Definition |
Type/Default values |
map |
filetype |
(Optional) Type of file, typically used to specify the format |
string |
|
page_number |
(Optional) Page number. It could be used to identify particular pages |
string |
group-by |
|
(Optional) Group by field names. |
string |
aggregate |
|
(Optional) Determines how the values of duplicated fields are consolidated during grouping |
string |
output_filter |
|
(Optional) List of fields to be displayed in the metadata |
List of string |
root |
|
(Optional) Primary fields that will structure the final output of the metadata processing |
List of string |
The default configuration for metadata is described as follows:
metadata:
map:
filetype: content-type
page_number: page-number
group-by: url
aggregate: page-number
output_filter:
- title
- url
- content-type
- page-number
- _zxcv
root:
- title
- url
- content-type
Language identification
Parameter related to the configuration of Language Identification in atria-rag-server
It is used to identify the language of the user’s question. The result is a dictionary containing the detected language in ISO 639-3 format and its corresponding conversion.
In addition to language identification, the user’s question is preprocessed at this stage, and special characters that may cause recognition errors are removed. For example, line breaks. In case of error, the default language is returned.
This language identification is calculated through fasttext library.
Language identification fields
| Parameter |
Subparameters |
Definition |
Type/Default values |
language_default |
|
(Optional) Language in ISO 639-3 format (two letters). For example: es |
string |
score_threshold |
|
(Optional) Score threshold used to respond in the identified language or in the default language. For example: 0.85 |
float |
model_path |
|
(Mandatory) Model path. For example: /opt/atria-fasttext/fasttext_model.bin |
string |
chars_to_clean |
|
(Optional) Characters to be cleaned. By default is ['/n'] |
list of string |
Language Identification by default
The default configuration for language identification is described as follows:
language_identification:
score_threshold: <AUTOCOMPLETED>
language_default: <AUTOCOMPLETED>
model_path: "/opt/atria-fasttext/fasttext_model.bin"
2 - Create and configure a preset
Guidelines for the configuration of ATRIA by use cases constructors when developing an experience by means of a preset
This guidelines correspond to a specific stage in the processes for building experiences using Generative AI or RAG, which are fully explained in:
Introduction
A preset is a configurable entity that defines the instructions to work with the AI model for the resolution of a use case.
These instructions include, apart from other parameters, the prompt with text to guide the AI model with the generation of the response. For example:
- “Maintain the formal tone of the original text”
- “If the previous conversation is relevant for the current query, incorporate it into the query and produce a rewritten query”
When developing an experience in ATRIA, use cases constructors must configure a preset for the specific ATRIA application to be used.
ATRIA use cases constructors can use the currently available default presets or they can modify them or create new ones via API.
In both scenarios, a further step is required to include the preset in the application.
1. Create a new preset
-
Build the preset for your use case (json file), using the available preset fields.
-
Do you get lost with all the preset configuration parameters? In best practices for ATRIA configuration, you can find the most commonly used parameters by experiences constructors grouped by their purpose (“I want to increase security”, “I want to activate the multi-language feature”, etc.)
-
When the preset json file is generated, execute this command to include it:
curl --location --request POST 'https://svc-<env>.auracognitive.com/aura-services/v2/configuration/presets/' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: APIKEY XXX' \
--data-raw '<NEW PRESET JSON>'
1.1. Modify/update a preset
If once created, certain modifications are required, follow these instructions:
-
Make the required changes in the preset json file using the available preset fields.
-
When the preset is modified, execute this command to include it:
curl --location --request PUT 'https://svc-<env>.auracognitive.com/aura-services/v2/configuration/presets/<presetID>' \
--header 'Content-Type: application/json' \
--header 'Authorization: APIKEY XXX' \
--data '<PRESET JSON WITH MODIFICATIONS>'
1.2. Delete a preset
2. Include the preset in the application
An application is defined as an entity that allows the connection of a channel, service or skill with with ATRIA.
If the application for your use case does not exist, firstly it is required to create it following the guidelines for the configuration of an application.
Once the application is created, assign the created preset. Two scenarios arise here:
2.1. If an existing preset is modified
-
Get the list of presets assigned to the application to be used from aura-configuration-api:
curl --location 'https://svc-<env>.auracognitive.com/aura-services/v2/configuration/applications/<applicationID>' \
--header 'Authorization: APIKEY '
-
Check if your preset is already included in the list and, consequently, associated to your application.
-
If not, declare the created preset in the application following the guidelines for the configuration of an application: Use Generative AI/RAG, within the field presets.
2.2. If a new preset is created
-
Update aura-configuration-api to indicate to the application the complete list of presets to be used.
It is necessary to include the entire list of presets associated to the application (the existing presets and the created/modified ones)
curl --location --request PATCH 'https://svc-<env>.auracognitive.com/aura-services/v1/applications/:applicationId' \
--header 'Accept: application/json' \
--header 'Authorization: APIKEY XXX' \
--data '{
"id": "<applicationId>",
"models": {
"level": <levelType>,
"presets": [
<complete-new-list-of-presets>
]
}
}'
- The
level field, that indicates the different levels of access to the application, can only be changed By the Global Team.
This command is a specific scenario in the process of modifying API configuration, described in the document Hot swapping of Aura applications configuration.
-
Declare the created preset in the application following the guidelines for the configuration of an application: Use Generative AI/RAG, within the field presets.
Preset fields
The fields for the characterization of a preset are summarized below, which are defined in the API swagger Aura Configuration API Preset.
If there is any discrepancy between the parameters definitions included in this document and those in the API swagger, definitions established in the API shall prevail.
-
id: Mandatory. Preset identifier. The type is string.
-
name: Mandatory. Preset name. If this value does not exist, id is used. The type is string.
-
description: Optional. Preset description. If this value does not exist, id is used. The type is string.
-
group: Mandatory. This parameter is used to group requests regarding the AI technologies used to generate KPIs. The type is string. Feasible values: simple_ai (Generative AI preset) and enriched_ai (RAG preset).
-
session: Optional. Parameters for session configuration.
window: Optional. The size of the session window, in queries. The type is number.
timeout: Optional. The time in seconds after which the session will be closed if no queries are received. If it is 0, the session history will be used, but the current interaction will not be saved. The type is number.
-
generative: Mandatory if Generative AI is used. It indicates the use of Generative AI in the use case. If this field exists, the rag field must not exist.
-
model: Mandatory. Model configuration.
id: Mandatory. Unique identifier of the model
parameters. Optional. Dictionary with all possible parameters for the model. For generative, check them here.
-
injectionMaxLength. Optional. Maximum length of the input user. The type is number.
-
prompts: Optional. Parameters to define the prompts with instructions used as input by the AI model to automatically generate responses.
. The object may include properties such as text, additional parameters, and specific configurations to control the behavior of the generative model.
. If no prompt is defined, the resolution of the use case is entirely delegated to the LLM model.
template: Optional. Template that includes the user’s input. It must include {MSG} for the user’s utterance. This will override (or add, if not defined) the template for the user message, as defined in the preset (Note: templates allow framing the user message to mitigate prompt injection attacks). The type is string.
preamble: Optional. List of phrases to be included in the model prompt.
examples: Optional. Examples to enrich the prompt. The type is string.
promptMaxLength: Optional. Maximum length of the completed prompt. Used to avoid calling LLMS with wrong prompts.
promptRegexClean: Optional. Regex pattern to clean the query before sending it to the model. This is useful to remove unwanted characters or patterns from the query. The type is number.
-
rag: Mandatory if RAG technology is used. It indicates the RAG configuration. If this field exists, the generative field must not exist.
-
ragType: Optional. RAG type. Values: questions-answers (by default) or sql
-
model: Mandatory. Parameters for the configuration of the RAG model.
id: Mandatory. Unique identifier of the model to be used. The type is string.
parameters: Optional. Dictionary with all the possible parameters for the model.
-
references: Optional. Configuration for managing references in the system. It control de number of references the system relies on to generate a response.
maximum: Optional. Maximum number of returned references. The type is number.
baseUrl: Optional. Base URL of references that will be shown to the user as part of the response. For the types of data unstructured, csvand text (defined in the field loaderType), it is required to add here the path to the public URL to be shown in the response as a clickable reference.
-
stages: Mandatory. Stages of the RAG model.
-
promptSystemLanguage: Optional. Parameter to select a specific language from the ones defined in the prompt. Type: string in ISO 639-3 format. For example: es.
-
defaultUserLanguage: Optional. Parameter used in multi-language feature. It indicates the default response language to be used if the system is not able to automatically recognize the language. Type: string in ISO 639-3 format. For example: es.
-
securityStg: Stage with parameters related to security used to avoid prompt injection.
injectionMaxLength: Mandatory. Maximum length of the input user. If length is greater, an error is sent. The type is number.
heuristics: Optional. Heuristics configuration.
es: List of heuristic sentences in Spanish. The type is list.
en: List of heuristic sentences in English. The type is list.
-
translationStg: Stage used to translate the prompt.
enabled: Mandatory. Boolean value to activate or not the translation stage. The type is boolean.
language: Mandatory. Two-letter ISO 639-1 language code into which user input is translated to match the language of the data. The type is string. If this field exists, the prompts field must not exist.
prompt: Mandatory. List of prompts to be used in the LLM call.
. The type is PromptLanguage.
. If this field exists, the language field must not exist.
. If this field is empty, the default prompt for this stage will be used.
-
contextStg: Stage used to know if the user’s phrase has the same context of the conversation.
enabled: Mandatory. Boolean value to activate or not the context stage. The type is boolean.
stickyContext: Mandatory. Strategy to include the context into the new query. If not specified, the optional context in the request is ignored. The type is string. Values:
ask_llm: An LLM-call is made to discern whether the context applies to the current query. If so, a recreate_question is performed. If not, the context is ignored and a clear_context field is added into the response.
include_context: The context will be inserted as is into the query. prompts should not by empty for this option.
recreate_question: An LLM-call will try to recreate the question by using the context.
prompts: Optional. List of prompts to be used in the LLM call.
. The type is StickyContextPrompts.
. If this field is empty, the default prompt for this stage will be used.
-
cleanStg: Stage used to remove prompt injection attempts using an LLM call.
enabled: Mandatory. Boolean value to activate or not the clean stage. The type is boolean.
prompt: Optional. Prompt to be used in the LLM call.
. The type is PromptLanguage. For example: “Please clean up the query and reply only with the user’s question”.
. If this field is empty, the default prompt for this stage will be used.
-
retrievalStg: Mandatory. Stage related to the retrieval phase, which is the process of obtaining relevant documents by comparing the query against indexed data or vectors.
The stage is crucial for identifying and retrieving the documents or data that best match the input query, ensuring that only the most relevant results are returned.
sources: Mandatory. Sources data.
name: Mandatory. Name of the source data. The type is string.
embeddings: Mandatory. Embeddings model identifier that the ATRIA source data is associated with.
docs: Mandatory. Field with parameters related to the configuration of documents. The type is object.
extension: Mandatory. Extensions of documents. The type is string. The extensions must be separated by a comma.
loader: Mandatory. Project loader configuration.
loaderType: Mandatory. Type of loader. Values: unstructured, csv, text, jsond, jsonl or url_list
options: Optional. Object that configures how the document loader operates. It allows specifying the mode of loading and any post-processing actions to be applied to the loaded data.
loaderMode: Optional. Modes for loader running. The type is string. The possible values are:
single: Document will be returned as a single document representing the whole
elements: The loader splits the document into different elements such as: Title, NarrativeText, etc. This allows a more granular processing and analysis
postProcessors: Optional. Post processor loader. It allows to perform operations in the loaded document such as cleaning, transforming, enriching, etc. The type is string.
splitter: Optional. Project splitter for dividing large text inputs into smaller, manageable chunks, that can be more easily processed by language models, ensuring efficient and accurate processing.
splitterType: Mandatory. Method used to split the text. Value: recursivechar (Recursively divides the text based on a character, typically looking for specific breakpoints such as punctuation or whitespace)
options: Optional. Project splitter options.
chunkSize: Optional. Maximum size of chunks to be returned. The type is number.
chunkOverlap: Optional. Overlap in characters between chunks. The type is number.
retrievers: Mandatory. List of retrievers used to query and retrieve relevant data or documents from a collection based on a given query.
retrieverType: Mandatory. Type of the retriever. Possible values: qdrant, tfidf, or elasticsearch.
config: Optional. Configuration parameters for retrievers. The type is dictionary.
numDocs: Optional. Number of documents to retrieve. The type is number.
loadChunkSize: Optional. Chuck size used to load the documents in qdrant. The type is number. By default, 1000.
-
postFilteringStg: Stage in charge of processing candidates before they enter the RAG chain.
. It prompts the project LLM for each candidate, using the query and the candidate text. The LLM determines whether the candidate text is related to the query, and if not, the candidate will be filtered out.
. If this option is not enabled, no post-processing or filtering will take place.
enabled: Mandatory. Boolean value to activate or not the post-filtering stage. The type is boolean.
candidatesPostFiltering: Mandatory. Post-retrieval filtering applied to the candidates. It must be llm_filter (for each candidate, a very short request is made to the LLM to identify whether the candidate is relevant to answer the query. If ’no’ is decided, the candidate is filtered out)
prompt: Optional. Prompt to be used in the LLM call.
. The type is PromptLanguage.
. If this field is empty, the default prompt for this stage will be used.
-
generativeStg: Stage for handling the question and answer process.
. It defines the strategy to solve the question, the prompts used in different stages of the process and the templates for generating responses
-
ragStrategy: Optional. Strategy to combine documents to generate a response. By default, stuff:
stuff: Mandatory. If stuff prompt is used, ragStrategy must be set to stuff.
refine: Mandatory. If informationExtraction or responseConsolidation prompts are used, ragStrategy must be set to refine.
-
prompts Optional. List of prompts to be used in the LLM call.
. The type is GenerationPrompts.
. If this field is empty, the default prompt for this stage will be used.
-
outputRefine: Optional. It is used to set up how to provide responses. The retrieving operation produces a list of candidates, each of which may provide a dictionary of metadata.
candidates: Optional. It indicates whether to return the candidates in raw (useful for evaluation purposes) or not. The type is boolean, by default, false.
filterOutputMetadata: Optional. It is used to set up how metadata is used when providing responses. The retrieving operation produces a list of candidates, each of which may provide a dictionary of metadata.
map: Optional. Maps attribute names in the original data to standard or more user-friendly names for later use.
fileType: Optional. String representing the type of file, typically used to specify the format or content type of the file being referenced. By default, content-type
pageNumber: Optional. String representing a page number. It could be used to identify particular pages within a document or resource. By default, page-number
groupBy: Optional. groupBy and aggregate are expressed in post-map field names. By default, url
aggregate: Optional. It determines how the values of duplicated fields are consolidated during grouping, specifying the handling of aggregated field information. By default, page-number
outputFilter: Optional. List of fields to be displayed in the metadata. Type is list.
root: Optional. Defines the primary fields that will structure the final output of the metadata processing. Fields listed under root will remain at the top level of the response entries, while all other metadata fields will be nested under a metadata. Type is list.
Example of preset for Generative AI capability
{
"id": "e27ca464-488a-435d-a508-da8a262d905f",
"name": "openai",
"description": "openai model",
"brand": "",
"contact": "",
"group": "simple_ai",
"session": {
"window": 0
},
"generative": {
"model": {
"id": "openai",
"parameters": {
"top_p": 0.9
}
},
"prompts": {
"preamble": {
"text": "Habla como si fueras {name}",
"args": {
"name": "Napoleon"
}
},
"examples":[
"Naciste en galicia",
"Di que tu padre era gallego"
],
"promptRegexClean": "[#\\n\"]+"
}
}
}
Example of preset for RAG capability
{
"id": "1cafcb5c-7951-4645-86d4-055d3b46fe79",
"name": "atria-rag-gpt-35-turbo",
"group": "enriched_ai",
"description": "Atria rag GPT 3.5",
"session": {
"window": 3
},
"rag": {
"ragType": "questions-answers",
"model": {
"id": "gpt-35-turbo",
"parameters": {
"max_tokens": 4000,
"temperature": 1,
"top_p": 1
}
},
"references": {
"maximum": 3,
"baseUrl": "project-gpt-35-turbo/pdfs"
},
"stages": {
"language": "en",
"translationStg": {
"enabled": true,
"language": "en"
},
"contextStg": {
"enabled": true,
"stickyContext": "ask_llm"
},
"cleanStg": {
"enabled": true
},
"retrievalStg": {
"sources": {
"name": "project-gpt-35-turbo",
"embeddings": "text-embedding-ada-002",
"docs": [
{
"extension": "pdf",
"loader": {
"loaderType": "unstructured",
"options": {
"loaderMode": "single"
}
}
},
{
"extension": "txt",
"loader": {
"loaderType": "url_list"
}
}
],
"splitter": {
"splitterType": "recursivechar",
"options": {
"chunkSize": 60,
"chunkOverlap": 20
}
},
"retrievers": [
{
"retrieverType": "qdrant",
"config": {
"loadChunkSize": 10000
}
},
{
"retrieverType": "tfidf"
}
]
}
},
"postFilteringStg": {
"enabled": true
},
"generativeStg": {
"ragStrategy": "stuff"
}
},
"outputRefine": {
"candidates": false
}
}
}
3 - Import documents into ATRIA
Import documents into ATRIA
Guidelines for importing documents and new data into ATRIA environment
Introduction
As described in General RAG: functional overview, when using RAG capability, different databases are used for lexical and semantic search.
The documents that feed these knowledge bases must be uploaded into the environment to be used in the RAG chain and updated when required. In this framework, two processes must be considered:
-
a. Curate data (recommended): Firstly, it is important to curate the data to be uploaded afterwards, to optimize the recognition process.
-
b. Import documents: Once the data is curated, the documents must be uploaded into the system. For that purpose, apart from the general method, a hot swapping process can be executed.
a. Data curation
Data curation is the process of organizing, managing, cleaning up and maintaining data to ensure it stays relevant and valuable. Good practices in this task leads to an efficient recognition by the AI model.
For this purpose, we recommend following these tips, based on research and internal analysis:
1. Data selection and cleaning
- Include only data relevant to the purpose of the RAG. Redundant, irrelevant or outdated information should be removed to clean up noise that does not add value.
2. Clarity and consistency in content
- Be concrete and specific: Keep the information to the point. Avoid unnecessary words or complex explanations.
- Avoid ambiguous messages: Avoid vague or unclear terms that could lead to confusion. Make sure the meaning is easy to interpret.
- Reinforce the message: Make the message clearer by using specific terms related to the category being discussed. Use keywords strategically to reinforce the message.
- Make sure procedures are clear and include all the necessary steps: Make sure each step in tutorials is fully described, logically structured and easy to follow. Avoid fragmented or disjointed instructions.
- Remove unnecessary reference information: Minimize excessive details between steps that could distract or confuse the LLM. Keep the flow simple and clear.
3. Improvements in information
- Add missing content: If the product includes features similar to others but with slight variations, add a sentence explaining what is and is not supported to make the LLM more accurate.
- Add similar terminology: Although you cannot control what terminology people use, mentioning common alternative terms in your content can help the LLM provide more informative answers.
4. Structure and formatting
- Maintain consistent formatting: Ensure all steps follow a parallel structure (similar sentence formats and style) to improve coherence.
- Simplify complex tables: Avoid blank cells and ensure every cell has a complete value. Replace symbols (e.g., checkmarks) with clear text (“Yes”, “Supported”) to improve interpretation. Rewrite footnote text to add context. Move complex information in table cells out of the table.
- Avoid nested content: LLMs can have difficulty with multiple levels of nesting (e.g., steps within steps). Keep content linear and simple for better understanding.
- Add summaries to tutorials or long procedures: LLMs can get “lost” with long tutorials or procedures due to context window limitations. Including a summary is a simple way to enhance results.
5. Clarification and Explanation of Concepts
- Easy writing: Resolve writing issues such as wordiness, passive voice, and unclear pronouns (with ambiguous references) to make text more understandable.
- Explain graphics/images in text: Clearly explain conceptual graphics through text to resolve ambiguities and avoid relying on an image-to-text model
b. Import documents
Once the data is curated, the documents must be uploaded into the system. For that purpose, the following guidelines must be followed.
Note: The RAG does not support files with whitespaces.
1. Upload documents in the Azure container atria-resources
-
Insert these documents in the <preset_name>/<retrievalStg.sources.name>/<retrievalStg.sources.docs[i].extension>/ folder.
-
Keep in mind the allowed formats for documents, set in the preset’s variable loader.loaderType.
For these documents to be used in your use case, they must be included in the preset, following these instructions.
- Fill in the parameters in the
docs key of your preset, which is related to the configuration of documents.
Here is an example of documents configuration. In this example, documents in the preset are separated into two folders, as we are going to load two different types of data (jsonl and pdf) into this preset.
```json
{
"retrievalStg":{
"sources":{
"name":"project-de-faqs",
"embeddings":"text-embedding-ada-002",
"docs":[
{
"extension":"jsonl",
"loader":{
"loaderType":"jsonl"
}
},
{
"extension":"pdf",
"loader":{
"loaderType":"unstructured",
"options":{
"loaderMode":"single"
}
}
}
],
"splitter":{
"splitterType":"recursivechar",
"options":{
"chunkSize":512,
"chunkOverlap":160
}
},
"retrievers":[
{
"retrieverType":"qdrant"
},
{
"retrieverType":"tfidf"
}
]
}
}
}
```
3. Upload list of URLs
-
If you use URLs as documents ("loaderType": "url_list"), you also need to upload a file with the list of URLs in the preset folder.
-
Separate each URL with a line break. The file must have the extension .txt.
http://www.url1.com
http://www.url2.com
4. Upload jsonl or jsond files
-
If you use jsonl or jsond files as documents ("loaderType": "jsonl" or "loaderType": "jsond"), you also need to upload the file content in the same folder with the extension .jsonl or .jsond.
-
To do so, each desired document content must be provided in the page_content key.
{"page_content": "test1", "metadata": {"source": "https://www.dummy1.es/"}, "type": "Document"}
{"page_content": "test2", "metadata": {"source": "https://www.dummy2.es/"}, "type": "Document"}
Scenario 1: Unstructured, csv or text data
If the loaderType is url_list, unstructured or csv, you can optionally add a file called project.metadata with relevant information about each file. This metadata will be stored in the database and is very helpful when we want to modify the source URL.
It is important that the file is correctly tabulated and does not contain any invalid characters.
The file is composed of:
- Key
__global__, which contains global data that affects all the files.
- Names of the specific files to which we want to include this extra data.
It is not necessary to define metadata for all the files in the folder.
Example:
__global__:
url: https://www.google.com
field1: test
field2: test
file1.txt:
url: https://www.dummy-url.com
title: file1 title
file2.txt:
url: https://www.dummy-url.com
title: file1 title
source: test
NOTE: From all the information added to the project.metadata when creating your use case, you can select the specific sources that will be shown to the user as part of the response, adding them to the field baseURL of the preset configuration.
Scenario 2: URL or json documents
In this case, there is no need to add the project.metadata file:
-
"loaderType": "url_list" —> Metadata information is included in the URLs themselves, uploaded in step 3
-
"loaderType": "jsonl", "loaderType": "jsond" —> Metadata information is already included in the files uploaded in step 4
6. Update data into the environment
Finally, execute the atria-rag-generate-db job to update the data into the environment.
4 - Create and configure an agent
Guidelines for the configuration of ATRIA by use cases constructors when developing an experience by means of an agent
Introduction
An agent is a configuration entity in ATRIA that represents an integration point for external channels, services, or platforms.
Each agent defines how ATRIA communicates with and manages sessions for a specific external system, specifying connection details, session parameters, and operational metadata.
Agents are referenced by applications to enable channel or service connectivity within the platform.
1. Create a new agent
-
Build the agent for your use case (json file), using the available agent fields.
-
When the agent json file is generated, execute this command to include it:
curl --location --request POST 'https://svc-<env>.auracognitive.com/aura-services/v2/configuration/agents/' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: APIKEY XXX' \
--data-raw '<NEW AGENT JSON>'
1.1. Modify/update an agent
If once created, certain modifications are required, follow these instructions:
-
Make the required changes in the agent json file using the available agent fields.
-
When the agent is modified, execute this command to update it:
curl --location --request PUT 'https://svc-<env>.auracognitive.com/aura-services/v2/configuration/agents/<agentID>' \
--header 'Content-Type: application/json' \
--header 'Authorization: APIKEY XXX' \
--data '<AGENT JSON WITH MODIFICATIONS>'
1.2. Delete an agent
2. Include the agent in the application
If the application for your use case does not exist, first create it following the guidelines for the configuration of an application.
Once the application is created, assign the created agent in the field agents.
If you update or delete an agent, ensure that any application referencing it is also updated accordingly.
Remember that agents must exist to be inserted in an application.
Example to update the list of agents in an application:
curl --location --request PATCH 'https://svc-<env>.auracognitive.com/aura-services/v1/applications/<applicationId>' \
--header 'Accept: application/json' \
--header 'Authorization: APIKEY XXX' \
--data '{
"id": "<applicationId>",
"agents": [
"<agentId1>",
"<agentId2>"
]
}'
Agent fields
The fields for the characterization of an agent are summarized below, as defined in the API swagger Aura Configuration ATRIA Agents:
| Field |
Type |
Mandatory |
Description |
id |
string |
Yes |
Unique identifier (UUID) for the agent. |
name |
string |
Yes |
Name that uniquely identifies the agent in Aura. |
description |
string |
No |
Description of the agent. |
communication |
object |
Yes |
Parameters for the configuration of the communication flow. See communication configuration. |
flowConfig |
object |
No |
Configuration of the agent flow. |
deploymentName |
string |
No |
Name of the deployment where the agent is running. If the endpoint field is not present in communication, this field will be used to route requests to the agent. |
metadata |
object |
No |
Document metadata (version, createdAt, updatedAt, etc). See metadata. |
Communication configuration (communication)
| Field |
Type |
Mandatory |
Description |
communicationType |
string |
Yes |
Type of communication. Only http is currently supported. |
endpoint |
string |
No |
HTTP endpoint where the agent listens. |
headers |
object |
No |
HTTP headers associated with the agent. |
timeout |
number |
No |
Timeout for agent communication. |
retries |
number |
No |
Number of retries for communication. |
| Field |
Type |
Mandatory |
Description |
version |
string |
No |
Configuration version when the document was created. |
createdAt |
string |
No |
Creation date (ISO 8601). |
updatedAt |
string |
No |
Last update date (ISO 8601). |
Example: Minimal agent configuration
{
"id": "b1e2c3d4-5678-1234-9abc-def012345678",
"name": "example-agent",
"communication": {
"communicationType": "http",
"endpoint": "https://agent.example.com/webhook"
}
}
Example: Full agent configuration
{
"id": "b1e2c3d4-5678-1234-9abc-def012345678",
"name": "example-agent",
"description": "Agent for integration with Example Service",
"communication": {
"communicationType": "http",
"endpoint": "https://agent.example.com/webhook",
"headers": {
"Authorization": "Bearer <token>"
},
"timeout": 30,
"retries": 3
},
"flowConfig": {},
"deploymentName": "example-deployment",
"metadata": {
"version": "1.0.0",
"createdAt": "2024-05-30T10:00:00Z",
"updatedAt": "2024-05-30T12:00:00Z"
}
}
Note:
- The
id, name, and communication fields are mandatory.
- The
communicationType must be http.
- If an agent is deleted, applications referencing it will be updated.