---
title: "Interactions"
source: "https://docs.vertesiahq.com/studio/interactions"
markdown: "https://docs.vertesiahq.com/llms/studio/interactions.md"
---

# Interactions

//import YoutubeVideo from '../../../components/YoutubeVideo';

# Interactions

The interactions are a core concept of the Vertesia Platform.
Roughly speaking, an interaction is a composition of parametrized prompts which define the task a target LLM is requested to perform.
In addition, an interaction can define a schema to structure the response of the LLM.

To understand interactions it is important to understand first the following concepts:

1. **Parametrized Prompt**.

A parametrized prompt is a message template and a schema which defines which kind of parameters are required to render the template as a plain text message.
Templates can use **Handlebars** syntax (`{{variable}}`, recommended) or **JS Templates** (`${variable}`, for advanced composition).
The most simple prompt is a static prompt which does not require any parameter.
Each parametrized prompt defines a schema which describes the parameters required to render the prompt.

Prompts can be reused between interactions.

2. **Prompt Roles**

Each prompt has a role. The following roles are defined:

* **safety** - The safety prompt have the highest priority and are always rendered first. They are used to prevent the LLM to generate unsafe content.
* **system** - The system prompt is used to define the context of the interaction. For example, the system prompt can be used to define the persona of the LLM.
* **user** - The user prompt is used to define the user input.
* **assistant** - The assistant prompt is used to define the assistant (i.e. LLM) input.

3. **Prompt Formatters**

Parametrized prompts are rendered and assembled together to form the intermediate prompt which is describing the task the LLM should perform.
This intermediate prompt is an array of **Prompt Segments**, similar to OpenAI's prompt format: plain text messages with a role attribute.

As each LLM expect the prompt to be formatted in a certain way to understand the task, the prompt segments must be rendered into a final prompt
to fit with the LLM's prompt format (properly tag the system prompt, the user messages, the application messages, etc.).

Vertesia natively offers the following prompt format:

* **openai**: array of plain text messages with a role attribute.
* **llama2**: string with a special syntax to tag the prompt segments.
* **claude**: string with "Human:"" and "Assistant:" to tag the prompt segments.
* **GenericLLM** string with User and System tags, well suited for most other LLMs (Mistral, AI21, Cohere, etc.)

If you need a specific format, please reach out to us to review how to do it.

4. **Input Schema**

The input schema defines the structure of the data input which is required to render the prompt segments. \
This schema is implicitly defined by the concatenation of the parametrized prompt schemas.

5. **Output Schema**

An output schema can be defined if the LLM should respond using a JSON structured response. \
Both input and response schemas are defined as JSON schemas (https://json-schema.org/).
The executor will validate the output data using the defined schemas.

6. **Environment**

An **execution environment** is a configuration used to describe a target LLM. \
Interactions may specify a default environment which will be used to execute the interaction.

Apart the default environment, interactions may define default configuration properties like the model or the temperature to use.


## Creating an Interaction

### Defining an interaction's expected result

This is about defining what you expect from a functional perspective, in terms of result.


### Creating an interaction to summarize an input text

Let's see how to create a simple interaction that summarizes any input text.


### Creating an interaction to summarize an input document

As an alternative to the previous interaction, you may want to summarize a document previously stored in Vertesia's Content Store, which is by the way a very convenient way to implement RAG (Retrieval Augmented Generation).

Imagine you’re drafting a contract, preparing for litigation, or simply searching through thousands of legal documents to find the most relevant clauses and precedents. Retrieval Augmented Generation (RAG) is an advanced AI approach that can greatly streamline this process by combining two key abilities:

1. **Retrieval of Relevant Information**:
The AI system searches through vast enterprise databases, internal records, case files, and legal texts to pull out the most relevant pieces of information needed for your task. Think of it like having a super-efficient research assistant who quickly digs through your firm’s archives to find the exact document or detail you need.

2. **Generation of Tailored Content**:
Once the key pieces of information are retrieved, the AI system uses its language generation capabilities to create a draft or summary that combines this data seamlessly with its own pre-existing knowledge. This means you get a well-organized, accurately referenced piece of text that can serve as a foundation for your legal work.


### Generating an interaction from a sentence

Instead of configuring an interaction from scratch, you may ask Vertesia to generate one from a simple sentence. And then fine tune it.


### Adding comments to an interaction's result schema

An `Interaction`'s result schema is made of output parameters corresponding to what you expect to get from the interaction. It possible to comment those output parameters:
- either for documenting what they do
- or for helping the underlying LLM understanding what you expect, precisely


## Executing Interactions

Once you created an interaction you can test your interaction from the `Playground` tab of the `Interaction` page.
The reason of using Vertesia is to use the interaction you created in a real application you own.

You can do this by invoking the **REST API** to execute the interaction given the interaction ID, a data input object and optionally some specific execution environment configuration.
If your application is a JavaScript application you can use the **Vertesia SDK**.

## Execution Runs

The interaction execution will create an execution `Run` object, which is used to track the execution progress and, when completed, to store the results if successful or the error if it failed. \
Thus, you can find later an execution `Run` to analyse or even to reuse the results.

In order to easily find execution `Run` objects you can tag an `Interaction` execution with one or more tags.

## Interaction Versions

When you create an interaction it will have a `draft` status and will be at `version 1`. \
You continue working on it, testing the results with different environments and data inputs and finally you think the interaction is ready to be used in production. \
You may want then to save this version of the interaction as a read only copy of the draft interaction. This may be achieved by **publishing** the interaction.

Publishing an interaction will create a read only copy at the same version with one of the draft version (in our case at `version 1`), then it will increment the draft version at `version 2`. \
So, the draft version is always the version you are working on and the published versions are copies frozen in time of your intermediate versions of the interaction.

When publishing an interaction, all prompts referenced by the interaction are published too, by creating a read only copy of the current state of the prompts.

Also, when publishing an interaction you can choose to make the published interaction **public**. By doing so, you enable other organizations to **fork** your interaction and create their own version of it.