5 ms·

FWIW, as an example, Google developers don't have direct access to production PII data. The best they get are aggregations (sufficiently large enough that you

by nevir 8y ago

FWIW, as an example, Google developers don't have direct access to production PII data. The best they get are aggregations (sufficiently large enough that you can't identity a person). Specific user information is only available if the user explicitly opts in to share it, and is scoped to the specific case for analysis. It makes training/diagnosing ML models a challenge, to be sure

kuzehanka 8y ago
Let's be really clear here. It doesn't just make ML solutions a challenge. It makes them impossible. Even with all the compute power and automation of google, you can't blindly create an ML model and say yes it works without a data scientist actually looking at the guts with row-wise access to the training/validation data. You can't do analytics without giving engineers access to prod data. Not at even at Google.
- nevir 8y ago
  And yet, they do. Source: worked there, on a ML focused team.
  - kuzehanka 8y ago
    Go on, tell us how it works so we can all start doing the same and save millions of dollars in risk/compliance crossing enablement.
    - nevir 8y ago
      https://cloud.google.com/solutions/sensitive-data-and-ml-datasets https://cloud.google.com/solutions/sensitive-data-and-ml-dat... has some high level guidance on different techniques that can be applied, depending on the type of data you're working with.
      - kuzehanka 8y ago
        I actually know this article, so I'll summarise it for the readers. It covers de-risking data if it isn't required for ML models or is of low impact. Through removal of it, masking of it, or entropy injection to it. Every single one of these approaches is detrimental to an ML model and just make it useless unless the fields being controlled are't correlated to the outcome in the first place. This article is an acknowledgement of the issue and the fact that solutions don't exist. Only risk management strategies which disable potential solutions. Their ultimate answer is 'protect the data and give it to only a small restricted set of people'. Right back where we started.
        Fireflite 8y ago
        Injecting entropy into your data in order to generate differentially private access actually typically improves model performance, rather than degrades it. This behaviour is counterintuitive, but effectively you're enforcing a degree of regularization in a way similar to how data augmentation works. You'll get reduced training set performance and improved test set performance, as with other forms of regularization until you make it too strong.

by nevir 8y ago

kuzehanka 8y ago

Let's be really clear here. It doesn't just make ML solutions a challenge. It makes them impossible. Even with all the compute power and automation of google, you can't blindly create an ML model and say yes it works without a data scientist actually looking at the guts with row-wise access to the training/validation data. You can't do analytics without giving engineers access to prod data. Not at even at Google.

nevir 8y ago
And yet, they do. Source: worked there, on a ML focused team.
- kuzehanka 8y ago
  Go on, tell us how it works so we can all start doing the same and save millions of dollars in risk/compliance crossing enablement.
  - nevir 8y ago
    https://cloud.google.com/solutions/sensitive-data-and-ml-datasets https://cloud.google.com/solutions/sensitive-data-and-ml-dat... has some high level guidance on different techniques that can be applied, depending on the type of data you're working with.
    - kuzehanka 8y ago
      I actually know this article, so I'll summarise it for the readers. It covers de-risking data if it isn't required for ML models or is of low impact. Through removal of it, masking of it, or entropy injection to it. Every single one of these approaches is detrimental to an ML model and just make it useless unless the fields being controlled are't correlated to the outcome in the first place. This article is an acknowledgement of the issue and the fact that solutions don't exist. Only risk management strategies which disable potential solutions. Their ultimate answer is 'protect the data and give it to only a small restricted set of people'. Right back where we started.
      - Fireflite 8y ago
        Injecting entropy into your data in order to generate differentially private access actually typically improves model performance, rather than degrades it. This behaviour is counterintuitive, but effectively you're enforcing a degree of regularization in a way similar to how data augmentation works. You'll get reduced training set performance and improved test set performance, as with other forms of regularization until you make it too strong.