Items marked preview in this article are currently in preview. This preview is provided without a service-level agreement, and Microsoft doesn’t recommend it for production workloads. Certain features might not be supported or might have constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.
Prerequisites
- Complete the cloud evaluation prerequisites and client setup.
- A model deployment to simulate users.
- An agent target to evaluate.
- Scenario data that describes the interactions to simulate.
Understand conversation simulation
This approach is useful for:- Pre-deployment testing: Validate agent behavior across diverse scenarios without real user traffic.
- Edge case coverage: Test scenarios that rarely occur naturally but are important to handle well.
- Regression testing: Ensure agent updates don’t degrade performance on known scenarios.
- Scale testing: Generate many conversations quickly to stress-test agent capabilities.
- You provide scenario descriptions as JSONL data or strongly typed inline test cases. Each test case describes a situation the simulated user tries to accomplish.
- The service uses a simulator model to play the role of the user, interacting with your agent based on the scenario.
- Each scenario generates one or more complete conversations.
- Conversation-level evaluators assess the generated conversations.
- Your project stores the evaluation results. You can optionally persist all generated conversations as a versioned Foundry dataset.
azure_ai_user_conversation_simulation_preview data source. Put settings that apply to every test case in default_simulation_configuration. A test case can override individual conversation settings in its simulation_configuration; settings that it doesn’t override continue to use the run defaults.
Prepare scenario data
Supply test cases by using one of these source types:file_idorfile_contentfor JSONL scenarios.inline_user_conversation_simulationfor strongly typed test cases in the run request. Include at least one test case.
test_case_description. The description can contain 1 through 2,500 characters.
data_mapping. If it uses different names, map those attributes to test_case_id, test_case_description, and simulation_configuration. Don’t use data_mapping with an inline_user_conversation_simulation source.
Each inline or JSONL test case supports these properties:
Configure the simulated user
Use themodel_configuration object to configure the model that plays the simulated user. This model is separate from the target model or agent being evaluated.
For voice simulation,
voice_model.type must be azure-standard. Set name to an Azure standard neural voice name. You can also set temperature from 0 through 1; when omitted, the underlying voice model’s default applies.
Configure conversations
Set run-wide values indefault_simulation_configuration. The conversation controls max_num_turns, conversation_repetitions, desired_num_turns, audio_effects, and user_behavior can also appear in a test case’s simulation_configuration to override the corresponding run defaults. The dataset-generation properties enable_conversation_dataset_generation and output_conversation_dataset_name are valid only in default_simulation_configuration and can’t be overridden per test case.
Configure voice conditions and interruptions
Placeaudio_effects and user_behavior inside default_simulation_configuration to apply them to every test case. To override either setting for one test case, place it inside that test case’s simulation_configuration instead.
Use audio_effects to test how the target performs under realistic listening conditions. Add one or more effects: street_traffic, crowd_chatter, background_tv, metro_station, or telephonic_voice. Set volume_percentage from 1 through 100 to control their combined volume. The default is 15. Audio effects are ignored in text-only simulations.
Use user_behavior.interruption to test how the target handles a user speaking while the target is responding. Set its type to default to enable simulated interruptions. Omit interruption when interruptions aren’t part of the test.
Define evaluators
Select evaluators designed for conversation-level assessment. The simulated conversations automatically map to the evaluators.- Python
- C#
- JavaScript/TypeScript
- cURL
Create the evaluation and run
- Python
- C#
- JavaScript/TypeScript
- cURL
Save the canonical JSONL rows from Prepare scenario data as
simulation_scenarios.jsonl.Use inline test cases
To define scenarios directly in the run request, setdata_source.source to an inline_user_conversation_simulation source. Inline sources require at least one test case and don’t use data_mapping.
Get generated conversations
Poll the run until it reaches a terminal state as described in Get cloud evaluation results. Whenenable_conversation_dataset_generation is true, a completed run includes an output_datasets entry like this one:
id, name, and version to retrieve or reuse the generated conversations. If dataset generation is disabled, output_datasets is omitted.
Next steps
- To poll for completion and interpret results, see Get cloud evaluation results.
- For a complete runnable example, see sample_multiturn_conversation_simulation.py on GitHub.
- To evaluate stored conversations, see Evaluate conversation datasets.
- To evaluate production traces, see Evaluate deployed model and agent conversations.