Interactions

The interactions are the core concept of Composable Prompts. 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 togheter 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.).

Composable Prompts 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

Executing Interactions

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

You can do this by invoking the Composable Prompts 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 JavaScript SDK.

Execution Runs

The interaction execution will create an ExecutionRun 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 event to reuse the results.

In order to easily find execution runs you can tag an interaction execution with one or more tags.

Interaction Versions

When you create an interaction the interaction 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.
You ca do this 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.