Skip to main content
This guide is a runnable companion to the Prompts concepts section. You’ll work through three sections that mirror the iteration cycle the concept docs describe.

What you’ll build

A trip-planner prompt that takes a destination, duration, and travel style and produces a day-by-day itinerary. You’ll:
  1. Create a Prompt Object and save it to Prompt Hub.
  2. Test the prompt against a dataset with an evaluator, as an Arize experiment.
  3. Iterate — tighten the prompt, save a new version, and compare runs side by side.
By the end you’ll have:
  • A versioned trip-planner prompt in your Prompt Hub.
  • Two experiment runs against the same dataset.
  • A measurable improvement between v1 and v2. In reference runs v2 scored 1.00 on every row, while v1 landed around 0.60-0.67 and moved between runs, because a vague prompt produces inconsistent structure.

What you’ll need

  • An Arize account with an API key and space ID.
  • An OpenAI API key. Total cost is a few cents.
  • Python 3.10 or later.

Setup

The Arize client is the entry point to every AX resource: prompts, datasets, experiments, and evaluators all hang off it as namespaces.

1. Create the prompt

A Prompt Object bundles the messages, the model, and the invocation parameters into one versioned artifact. See The Prompt Object for the concepts behind it. The v1 system message is deliberately vague: no format constraints, no examples, no rules about what to include. That is the first attempt most teams ship, and it gives the iteration cycle something to improve on.

2. Test the prompt

Build a small dataset, define a task that runs the prompt, attach an evaluator, then run it as an experiment. See Experiments for prompts. The dataset column names must match the {placeholders} in the prompt’s user message, because the experiment substitutes each row’s value when it renders the prompt.
The task is what the experiment runs per row. Building it with a factory lets v1 and v2 share the rendering and LLM-call logic, so the only thing that differs between the two runs is the system message.
The evaluator scores how closely the output follows the strict Day N: HH:MM - Activity - $cost shape, using three signals worth a third each. It is deterministic, so the comparison between versions is not itself subject to model variance.
Now run the experiment.

3. Iterate and compare

Tighten the system prompt, save it as a new immutable version, tag it, and run the same experiment again. See Versioning and tags.
Tags are mutable pointers at immutable versions, which is what makes moving a tag the deployment step.
Because both runs used the same dataset rows in the same order, you can compare them element-wise.
A positive delta means v2 improved on that row. In a real iteration cycle you want most rows positive and no row strongly negative, since regressing on a single edge case is how prompt edits ship silent bugs.

Where to go next

  • Open the prompt in Prompt Hub in the UI to see both versions side by side and diff the templates.
  • Open the experiments tab to compare the two runs row by row.
  • Add an LLM-as-a-judge evaluator for subjective dimensions the deterministic eval can’t catch. See Evaluators.
  • Wire the experiment into CI/CD so prompt edits become PR checks. See Prompts in CI/CD.
  • Try Prompt Learning for automated optimization once you have a golden dataset. See Optimizing prompts.