-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Audit confident edge predictions #156
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,8 @@ | ||
# For configuring detectors on the edge endpoint. See CONFIGURING-DETECTORS.md for more information. | ||
|
||
global_config: # These settings affect the overall behavior of the edge endpoint. | ||
refresh_rate: 60 # How often to attempt to fetch updated ML models (in seconds). If not set, defaults to 60. | ||
refresh_rate: 60 # How often to attempt to fetch updated ML models (in seconds). Defaults to 60. | ||
confident_audit_rate: 0.001 # Probability that a confident prediction will be sent to cloud for auditing. Defaults to 0.001. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So, what's the standard FPS rate on an edge detector (binary)? If it's 5, then that's a human-required escalation for audit every 3.5 minutes or so, I think. Seems like too much. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Definitely a good point! It's hard to say what the standard FPS rate is since there's such a wide range of use cases, which makes it hard to pick a rate that works for all cases. Something approximating video processing (or a setup with multiple cameras going to a single detector) could definitely be 5 FPS or more. For high FPS use cases the rate could be configured to be lower (though I don't think we could expect a customer to do that without direct guidance from us). A concern with lowering it too much would be that it becomes much less useful for lower FPS cases. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We could instead audit on a timer, so our audit frequency is independent of FPS, but thats no longer random sampling. What do you think Paulina? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that's fine There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the timer would add some additional complexity with our multiple worker setup because each worker would have their own timer unless we make the timer external to the processes somehow - which is possible, just maybe more complicated than we'd want. |
||
|
||
edge_inference_configs: # These configs define detector-specific behavior and can be applied to detectors below. | ||
default: # Return the edge model's prediction if sufficiently confident; otherwise, escalate to the cloud. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the cloud audits get a lower review priority than escalations. How if at all is that handled here? When combined with the audit rate / sheer number of audited images, this is a potential area of concern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah we do want to treat edge audits in the same way as cloud audits, which will likely take some backend work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the current code, the 'audit' escalations to the cloud will be treated as normal escalations, so they won't have the reduced priority that cloud audits do. I tried to find a way for these escalations to be counted as audits, but I'm pretty sure there's no way to do it without making backend changes (and potentially SDK changes as well). Given that, I thought it could be worth introducing edge audits via this simple approach first, but we could go with the more complicated approach instead if that seems worthwhile.