Home

Traffic Split

Suggest Edits

Modifying Traffic

To have more than one variation running in a model, you must configure an audience and attach it to the model and variations.
You will have the option to control the traffic and how it is split between the variations.

Audiences

The audience is a definition of a list of conditions we can use to divide the model's traffic by.
The audience is defined on the account level and can be reassigned to a few models.

Create an Audience

The configuration of an audience is defined via a YAML file.

api_version: v1
spec:
  audiences:
    - name: New-York
      description: users from new-york
      conditions:
        unary:
          - key: location
            operator: UNARY_OPERATOR_TYPE_EXACT_MATCH
            operand: new-york
        binary:
          - key: age
            operator: BINARY_OPERATOR_TYPE_RANGE_MATCH
            first_operand: 10
            second_operand: 30

Name: a name for the audience as it will be shown on the platform.
Description: a description for the audience.
Conditions: a list of conditions with AND operand between them.

Conditions:

There are 2 types of conditions:
Unary operators:

  1. UNARY_OPERATOR_TYPE_EXACT_MATCH - The value passed matches the saved value.
  2. UNARY_OPERATOR_TYPE_SAFE_REGEX_MATCH - The value matches the regex
  3. UNARY_OPERATOR_TYPE_PRESENT_MATCH - The key is present.
  4. UNARY_OPERATOR_TYPE_PREFIX_MATCH - The prefix matches the saved value.
  5. UNARY_OPERATOR_TYPE_SUFFIX_MATCH - The suffix matches the saved value.
  6. UNARY_OPERATOR_TYPE_CONTAINS_MATCH - Contains the saved value.
    Binary operator:
  7. BINARY_OPERATOR_TYPE_RANGE_MATCH - The value is between the saved values.

And Apply the audience to the platform with CLI command:

qwak audience create -f <file_path>

Assigning Traffic to Audience

When we are deploying a model with multiple variations we will have audiences assigned to the model and a fallback variation.
fallback variation - the variation that will receive traffic that does not match any audience.
the audience can be connected to one or more variations - the traffic between the variations in the audience will split randomly by the percentage defined.

Inference

To redirect traffic to the wanted audience, we can pass metadata to the prediction function.
The audience that matches the metadata passed will receive the request.

client.predict(feature_vector, metadata: {"location":"new-york"})

Modifying Traffic using the UI

The current variations appear under your model's overview (Traffic Control section):

To modify the existing traffic configuration:
Edit the deployment of the wanted build and change the percentage of the variation.

Get Audience

Get all saved audiences:

📘

Audience id

To get the audience id use the "list" command.

qwak audience list

returns a list of audience ids and names.

*Get a specific audience: 

qwak audience get --audience-id <audience_id>

Deploy a model with multiple variations using the CLI

in the deployment config file, we have a real-time section where we can configure the audiences and the traffic split between them.

🚧

Fallback Variation

When deploying multiple variations in the model we must specify a fallback variation.
The fallback variation will receive traffic that does not match any audience.

With a configuration file as follows:

realtime:
  variation_name: new-york
  audiences:
    - id: <audience id>
      routes:
        - variation_name: new-york
          weight: 100
          shadow: false
  fallback_variation: default

Undeploying a Real-Time Model

Once you have more than one build deployed, when you undeploy an existing build, you must specify how to split the traffic after the undeployment.

Undeploying using the UI

To undeploy a variation:

  1. In the build view, click the options icon next to a deployed build and select Undeploy.

  1. Redistribute the traffic between the remaining variations and then click Undeploy.

Undeploying using the CLI

To undeploy a model with variation from the CLI, run the following command:

qwak models undeploy \ 
    --model-id <model-id> \
    --variation-name <variation-name> \
    --from-file <config-file-path>

With a configuration file as follows:

realtime:
  variation_name: <The variation name being undeployed>
   audiences:
    - id: <remaining audience id>
      routes:
        - variation_name: <other existing variation>
          weight: 80
          shadow: false
        - variation_name: <other existing variation 2>
          weight: 20
          shadow: false
  fallback_variation: <other existing variation>

If you use --variation-name in the CLI command, you don't have to pass the variation_name in the configuration file.

When undeploying from 2 variations to one, you don't have to pass any variation-related data -all the traffic will pass to the remaining variation.

📘

Note

By default the undeploy command is executed asynchronously, which means that the command does not wait for the undeployment to complete.

To execute the command in sync, use the --sync flag.

Updated 3 days ago