Skip to main content
Fiddler allows you to update specific fields in previously published events. While your model feature values can’t be updated, you can update:
  • Target column values (ground truth labels)
  • Metadata columns
Input, Output, and Custom Feature column types cannot be updated once published. If values for these columns are included with your update (update=True), they will be ignored.

Updating Ground Truth Labels

Updating ground truth labels is the most common use case for post-publish updates. You can update events when:
  • Actual values become available for events initially published without labels
  • You discover that initially uploaded labels are incorrect
Things to keep in mind about ground truth labels (target values):
  • Use null values when initially publishing inferences that don’t yet have labels
  • Fiddler automatically keeps aggregated performance metrics current as labels are updated
  • Labels can be updated multiple times if necessary

Updating Metadata Columns

Fiddler supports updating metadata columns with new values. This is particularly useful for supporting alternate labels that can be used with Custom Metrics to calculate alternative performance metrics. Things to keep in mind regarding metadata updates:
  • Updated values are visible in Feature Analytics and Root Cause Analysis views
  • Pre-calculated aggregated metrics will not reflect the updated values
  • Custom Metrics, used in charts and alerts, will always use the current values since they’re calculated at runtime
  • Updating metadata columns requires additional processing time, so only send updates when necessary

Update Rate Limits

To protect ingestion and downstream metric computation from unbounded load, the update path (update=True, PATCH /v3/events) is rate-limited per API token. These are the default limits—your administrator can tune them per environment, so your deployment may be configured differently. If you need higher throughput for a large recurring batch of label or metadata updates, contact Fiddler support to discuss raising the limits for your environment.
Request and volume limits
  • Up to 100 update requests per hour and 1,000 update requests per day.
  • Up to 1,000,000 events per hour and 10,000,000 events per day.
  • Batch/file updates (Model.publish_batch()) are additionally capped at 100,000 events per request. Stream updates (Model.publish_stream()) are chunked by the client into requests of 1,000 events each, so streaming’s effective ceiling is governed by the request-rate limit (about 100,000 events/hour) rather than the higher event-volume limit above.
If a single request exceeds the 100,000-events-per-request cap, the API returns 413 Request Entity Too Large—this is not retryable as-is; split the payload into smaller requests. If a request-rate or event-volume window limit is exceeded instead, the API returns 429 Too Many Requests along with rate-limiting headers:
  • X-RateLimit-Limit – The maximum number of allowed requests/events in the current window.
  • X-RateLimit-Remaining – The number remaining in the current window.
  • Retry-After – The number of seconds to wait before retrying.
  • X-RateLimit-Reset – The UTC epoch time (seconds) when the current rate-limiting window resets.

Label Update Examples

Stream Label Updates

As with inference publishing, label updates can be sent as streams or batches. Stream Update Data Formats
  • List of Python dictionaries
Stream Update One or More Events Integrate Fiddler directly into your production system to publish label updates as they occur. The event ID, the column chosen for Model.event_id_col, is required.
Stream Update Label and Metadata Metadata column(s) can also be updated.

Batch Update Data Formats

  • pandas DataFrame
  • CSV file (.csv),
  • Parquet file (.parquet)
Batch Update Events Publish larger sets of label updates using batch publishing. The event ID, the column chosen for Model.event_id_col, is required.
Refer to Model.publish_stream() and Model.publish_batch() documentation for more details on different sources and parameters.
📘 There are a few points to be aware of:
  • Performance metrics (available in monitoring charts and alert rules) will be computed as ground truth labels are inserted and recomputed when later updated.
    • For example, if the ground truth values are originally missing from events in a given time range, there will be no performance metrics available for that time range. Once the events are updated, performance metrics will be computed and will populate the monitoring charts.
    • Events that do not originally have ground truth labels should be uploaded with empty values—not dummy values. If dummy values are used, you will have improper performance metrics, and once the new values come in, the old, incorrect values will still be present.
    • Metrics based on Metadata columns won’t reflect updates.
  • In order to update existing events, you will need access to the event IDs used at the time of upload.
  • Updating the event timestamp, Model.event_ts_col, is not supported.