Skip to content
Notifications
Clear all

TIL: You can use Arize to track shadow deployments without a full rollout

3 Posts
3 Users
0 Reactions
1 Views
(@ci_cd_crusader)
Reputable Member
Joined: 1 month ago
Posts: 139
Topic starter   [#20410]

While reviewing Arize's documentation for a production monitoring project, I discovered a particularly elegant pattern for shadow deployments. Many teams assume Arize is solely for post-hoc analysis of fully deployed models, but its data collection and comparison features are flexible enough for low-risk validation of new models against live traffic.

The core concept involves sending inference data from both your primary and shadow models to Arize, using tags or inference IDs to differentiate the sources. This allows you to compare performance in the Arize UI without exposing end-users to the new model's predictions. Here's a simplified pattern for a Python service using the Arize client:

```python
# Pseudocode highlighting the shadow deployment pattern
from arize.api import Client

arize_client = Client(api_key=..., space_key=...)

def process_inference(input_data, model_primary, model_shadow):
# Primary model inference for user
primary_prediction = model_primary.predict(input_data)
primary_features = {...}

# Shadow model inference (not returned to user)
shadow_prediction = model_shadow.predict(input_data)
shadow_features = {...}

# Log both to Arize with a 'deployment_type' tag
arize_client.log(
prediction_id=str(uuid.uuid4()),
features=primary_features,
prediction_label=primary_prediction,
tags={"deployment_type": "production", "model_version": "v2.1"}
)

arize_client.log(
prediction_id=str(uuid.uuid4()),
features=shadow_features,
prediction_label=shadow_prediction,
tags={"deployment_type": "shadow", "model_version": "v3.0-rc"}
)

return primary_prediction
```

Key considerations for this workflow:
* **Cost:** You will incur double the logging cost for the shadowed traffic.
* **Latency:** The shadow call should be asynchronous or non-blocking to avoid impacting user-facing latency.
* **Comparison:** In Arize, you can create segments or boards filtering by the `deployment_type` tag to directly compare accuracy, drift, or performance metrics between the two model versions.

This method provides a robust safety net, allowing data-driven go/no-go decisions for a full rollout based on real-world inference data. It integrates well into existing CI/CD pipelines where a new model candidate can be deployed in shadow mode behind a feature flag for a specified evaluation period.

--crusader


Commit early, deploy often, but always rollback-ready.


   
Quote
(@cloud_ops_amy_2)
Estimable Member
Joined: 5 months ago
Posts: 96
 

Nice find. We've been running a similar pattern for a few months now with a recommendation model and it's saved us from at least one bad rollout. The key thing I'd add is that you need to be careful about the data volume when you're logging *both* models at full traffic. If your primary model already logs everything to Arize, doubling that for the shadow can hit your ingest limits or cost pretty quick.

We ended up sampling the shadow model logs to 10% and only logging the full set when we saw an anomaly in the comparison dashboard. That gave us enough signal without blowing up the bill.

Also worth noting - if your shadow model is significantly slower than the primary, you'll want to add a timeout or async path so the user's request doesn't get blocked. The pattern in the pseudocode has both running synchronously which could cause latency issues in production.

Have you run into any gotchas with the inference ID tagging? We had to be careful to keep the IDs consistent across both models for the comparison views to work cleanly.


terraform and chill


   
ReplyQuote
(@consultant_mark_2)
Estimable Member
Joined: 4 months ago
Posts: 82
 

That's a clever application of their platform. I often see teams default to building custom tracking systems for shadow deployments, which adds unnecessary overhead. Arize's comparison features are indeed a good fit here, turning an ops tool into a validation one.

The main caveat I'd add is on the TCO side. Logging two full inference streams, as you mentioned, can double costs. More critically, it can complicate your data contracts. If you're later comparing models, you need to ensure the logged features are identical in schema and meaning, otherwise your performance analysis isn't apples-to-apples. It's easy for a feature drift in the shadow model's preprocessing to go unnoticed.


independent eye


   
ReplyQuote