Network Selector

The Network Selector is a powerful tool that allows you to define and manage the routing of requests based on various criteria.

The network selector in ecosystem.ai uses a 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.

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:

The network_config should have a type of model_selector and include a selector object which contains the details of the runtime to call to get the ordering of external runtimes to call to generate the final result set.

Example:

{
  "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 offers returned by the selector specified in the 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",
  "in_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 default and no logging routers uses a switch_key to determine the network configuration and call an external service based on this configuration. The switch key is the name of a feature in the parameter access configured for the network runtime. The lookup_passthrough type will pass the exact response received by the network runtime, default will standardise the formatting of the responses and no_logging_router will not log the network runtime interactions.

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.