Network Selector

The Network Selector is a powerful tool that allows you to define and manage the routing of requests based on various criteria. It provides flexibility in configuring the network and allows for easy integration with external services.

The network selector in ecosystem.ai uses an experiment’s configuration to dynamically route each prediction or interaction request to one of multiple ecosystem runtime configurations (e.g., Configuration A, B, or C). This lets you easily compare different model versions, capture feedback and logs, and adapt to evolving experiments - all managed under a single, unified API.

When setting up a project to support network routing, you will need to configure the network selector. This involves defining the network configuration and specifying the routing criteria.

The network selector uses a switch key to determine which network configuration to use for each request. The switch key is a unique identifier that is used to route requests based on specific criteria.

Network Types

Here are the different types of network selectors, that will perform different routing mechanisms based on the network configuration:

• model_selector: Calls an external model selector to get a sorted list of options based on scores. It then calls other runtimes in sequence based on the model selector’s score.

• no_logging_router: Routes requests without logging. It uses a switch key in a data lookup to determine the network configuration and calls an external service based on this configuration.

• experiment_selector: Routes requests based on an experiment setup. Customers are randomly allocated to experimental groups on first interaction with the experiment and then follow the same routing on subsequent interactions.

• lookup_passthrough: Looks up a value with result pass-through. It uses a switch key in a data lookup to determine the network configuration and calls an external service based on this configuration.

• default: The default routing mechanism. It uses a switch key in a data lookup to determine the network configuration and calls an external service based on this configuration.

Network Configuration

There are two configuration settings that need to be created for the selector to work, network and network_config. network_config specifies the type of the network and any network level settings. network is a collection of documents specifying the parameters for the network nodes. network contains one document for each node in the network.

Model Selector

The model selector is a network configuration that calls an external model selector to get a sorted list of options based on scores. It then calls other runtimes in sequence based on the model selector’s score.

network_config:

This configuration file contains settings for the network configuration. It includes a switch_key that determines which key in the feature store to use for routing, and a selector object that specifies the default values for various parameters.

Example:

{
  "switch_key": "marital",
  "name": "network_config",
  "type": "model_selector",
  "selector": {
    "subcampaign": "recommender_dynamic_bayes",
    "channel": "app",
    "campaign": "recommender_dynamic_bayes",
    "params": "{}",
    "value": "married",
    "userid": "ecosystem_network",
    "url": "http://customer.ecosystem.ai:8091",
    "customer": "281db655-d667-4671-a715-8402c29d7d11"
  }
}

network:

This configuration file contains the actual network options. Each entry corresponds to a possible value of the switch_key specified in network_config. It includes parameters such as numberoffers, subcampaign, channel, campaign, in_params, value, userid, url, and customer.

Example:

{
  "numberoffers": 4,
  "subcampaign": "recommender_dynamic_bayes",
  "channel": "app",
  "campaign": "recommender_dynamic_bayes",
  "params": "{}",
  "value": "married",
  "userid": "ecosystem_network",
  "url": "http://customer.ecosystem.ai:8091",
  "customer": "281db655-d667-4671-a715-8402c29d7d11"
}

Lookup Passthrough, Default and No Logging Router

The lookup passthrough is a network configuration that looks up a value with result pass-through. It uses a switch_key to determine the network configuration and calls an external service based on this configuration. It also checks for network validity and applies default values if necessary.

network_config:

{
   "switch_key": "cohort",
   "name": "network_config",
   "type": "lookup_passthrough"
}

network:

In this example the network configuration is set to route requests based on the cohort value. It includes parameters such as numberoffers, subcampaign, channel, campaign, in_params, value, userid, url, and customer. If those are not present, then it will pass it through from the calling service.

{
  "campaign": "dynamic-recommender",
  "value": "1",
  "url": "http://localhost:8015"
}

Experiment Selector

The experiment_selector network will randomly assign customers to experiment groups based on proportions defined in the network_config. The first time customers interact with a configuration they will be assigned to an experiment group, on subsequent interactions that assigned group will persist. This is done using the contacts logging collection. To enable this:

• The logging connection and database should be the same for all of the ecosystem.Ai runtimes in the network, including the network runtime itself
• An index {"params.value":1,"predictor":1} should be added to those already present in the logging collection

network_config:

{
  "name": "network_config",
  "selector": {
    "random_splits": [
      0.4
    ],
    "groups": [
      "experiment__group_a",
      "experiment__group_b"
    ]
  },
  "predictor": "experiment__options",
  "type": "experiment_selector",
  "version": "001"
}

network:

In this example the network configuration is set to route requests based on assigned experiment group. It includes parameters such as numberoffers, subcampaign, channel, campaign, in_params, value, userid, url, and customer. If those are not present, then it will pass it through from the calling service.

{
  "campaign": "dynamic-recommender",
  "value": "experiment__group_a",
  "url": "http://localhost:8015"
}

Logging

Besides the no_logging_router network type, both the Network Selector runtime and the node runtime will generate contact and response logs, so both the performance of the node and the network as a whole can be easily monitored. In order for this to occur the following process is followed:

1. When a response to the Network Selector /invocations API is received, it will contain the UUID of the contact logged by the node runtime
2. The contact logged by the node runtime will contain the UUID of the Network Selector contact as a field in the in_params object
3. When the /response API is called on the Network Selector with the /invocations UUID it will first log a response for the node runtime and then use the UUID in in_params of the node contact to create a response for the Network Selector.