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. The most simple prompt is a plain text message which does not require any parameter. In that case we are speaking about a static prompt which cannot be parametrized. Each parametrized prompt defines a schema which describes the parameters required to render the prompt.

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 implicitely 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. 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 defaukt 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).

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 reesults 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.