Advanced options for running experiments via code

Setup asynchronous experiments

Experiments can be run as either Synchronous or Asynchronous.

We recommend:

  • Synchronous: Slower but easier to debug. When you are building your tests these are inherently easier to debug. Start with synchronous and then make them asynchronous.

  • Asynchronous: Faster. When timing and speed of the tests matter. Make the tasks and/or Evals asynchronous and you can 10x the speed of your runs.

Code errors for synchronous tasks break at the line of the error in the code. They are easier to debug and we recommend using these to develop your tasks and evals.

The synchronous running of an experiment runs one after another. The asynchronous running of an experiment runs in parallel.

Synchronous vs Asynchronous Task and Eval

Here are some code differences between the two. You just need to add the async keyword before your functions def and add async_ at the front of the name, and then run nest_asyncio.apply(). This will rely on the concurrency parameter in run_experiment, so if you'd like to run them faster, set it to a higher number.

Sampling a dataset for an experiment

Running a test on dataset sometimes requires running on random or stratified samples of the dataset. Arize supports running on samples by allowing teams to download a dataframe. That dataframe can be sampled prior to running the experiment.

An experiment will only matched up with the data that was run against it. You can run experiments with different samples of the same dataset. The platform will take care of tracking and visualization.

Any complex sampling method that can be applied to a dataframe can be used for sampling.

Tracing your experiment

When running experiments, arize_client.run_experiment() will produce a task span attached to the experiment. If you want to add more traces on the experimental run, you can actually instrument any part of that experiment and they will get attached below the task span

Example of Tracing LangGraph Experiments, with LangGraph spans under task span

Arize tracers instrumented on experiment code will automatically trace the experiments into the platform.

Tracing Using Explicit Spans

Tracing Using Auto-Instrumentor

Experiments SDK differences in Arize AX vs Phoenix OSS

There are subtle differences between the experiments SDK using Arize AX vs. Phoenix, but the base concepts are the same.

You can check out a full notebook example of each. The example below runs an experiment to write a haiku, and evaluate its tone using an LLM eval.

Dataset upload

Arize uses the ArizeDatasetsClient . arize_client.create_dataset returns a dataset_id, instead of a dataset object. So if you want to print or manipulate the dataset, you will need to get the dataset using arize_client.get_dataset.

Phoenix uses px.Client().upload_dataset

Task definition

In Arize, we use data from the dataset_row as prompt template variables. The possible variables to pass in are:

  • input, expected, dataset_row, metadata .

In Phoenix, you can do this using example . The possible variables to pass in are:

  • input, expected, reference, example, metadata

Evaluator definition

For both Arize and Phoenix, you can often use the exact same function as your evaluator. Phoenix does have slightly different way of accessing metadata from your dataset.

Arize uses input, output, dataset_row, metadata as the optional input variables to pass into the function.

Phoenix uses input, expected, reference, example, metadata as the input variables to pass into the function.

Run the experiment

Arize and Phoenix use slightly different functions to run an experiment due to the permissioning available in Arize.

  • In Arize, you must pass in the dataset_id and space_id.

  • In Phoenix, you must pass in the dataset object itself.

Last updated

Was this helpful?