Scale By The Bay 2019: Sophia Sanchez, Build Your Own ML Data Feedback Loop

Scale By The Bay 2019: Sophia Sanchez, Build Your Own ML Data Feedback Loop

Recording: Scale By The Bay 2019: Sophia Sanchez, Build Your Own ML Data Feedback Loop

[Music] hi everybody my name is Sofia I am a machine learning engineer at a start-up and the Bay Area called cure AI and today I'm going to be talking about building your own machine learning data feedback loop so to start cure eyes mission is to provide the world's best health care to everyone we do this by using artificial intelligence and machine learning with user centric focus to provide instant medical expertise that's accurate trustworthy relevant and actionable so you can think of this as a telehealth platform or a doctor/patient chat application that has AI integrated into the system to scale the doctors work we know that AI is particularly well suited to large-scale data processing prediction and automation and because of this AI can help scale healthcare care via this automation specifically through giving the doctors back some of their time according to dr. Eric Topol who is the author of deep medicine an excellent read I highly recommend one of the most important potential outgrowths of AI and medicine is the gift of time it'll take many years for all of this to be actualized but ultimately it should be regarded as the most expensive transformation in the history of medicine so those are pretty bold words but we have reason to believe that this is true at Qi one of the ways in which we use AI to scale the doctors time is by automating patient information gathering so in this example a patient comes in with a chief complaint let's say I have a headache there's a patient pertinent information gathering model that will ask them follow-up questions like how long have you had the headache how severe is your headache which can then be passed through for diagnosis and treatment so this machine learning task is going to be the motivating use case that I'll discuss today with regards to building a machine learning data feedback loop so as an overview we're gonna start by talking about why you should use a machine learning data feedback loop next we'll talk about how to actually build one so the nuts and bolts of it from presenting model output to logging your data data processing model retraining testing and finally integration and then and with a couple of closing thoughts on ML data feedback loops okay so why should you use a machine learning data feedback loop in the first place this is basically what a data feedback loop looks like you have your patient coming in giving the model its inputs maybe a headache and a fever you have a pertinent information gathering model that then you get feedback on these medical questions so maybe this takes the form of you present these questions to a doctor and they either say yep this is a good question send it on to the patient or nope don't use this and then you use that feedback to retrain your model but let's start at the beginning so Envy one of your information-gathering model you're using a couple of data sources to build it the main one that you're using is a knowledge base or KB so this is typically coming from a doctor painstakingly sitting down and writing down all of the symptoms and diseases in forming that into a graph so as you can imagine it's pretty time-consuming and the coverage amongst all possible symptoms and diseases is relatively low you might also use patient and provide our conversation data to provide additional context and submit that to your model but at any rate you've formed now your v1 of your information gathering model and you put it into production so in this case a doctor/patient chat application the problem is that medical models make mistakes in the wild so this is a real screenshot from first opinion a doctor-patient chat application and the patient's coming in saying I'm back baby want to go see the doctor they're kind of saucy I have a headache and a cough and a fever and then an entity extractor tries to identify this out of symptoms so it lists four of them and then the patient goes through and says yep that's right or nope that's wrong so can anybody you can just shout it out see what the mistake was I think I heard it in the back maybe yeah so infant is wrong I'm back baby does not mean that the patient is an infant it's just a turn of phrase so the models made a mistake here here's another example so the models asking that have you recently fainted or passed out and the user says yep I have syncope is just the medical term for passing out and then it asks have you almost fainted so this is a little bizarre because if you just said yes to fainting you know that it doesn't make sense to ask have you or almost fainted but a model doesn't necessarily know that that's the case so it's not learned something important about these nodes or these symptoms and how they should be connected so that's the v1 of your model and we can see here that it doesn't perform particularly well in the wild we know that under data shift ie when your training data is different from what is actually going on in production it makes a lot of mistakes and we know that it doesn't scale particularly well it takes a really long time to build these knowledge bases and that's a rate limiting factor so the main question is how do we improve the model in a way that scales one of the main ways that we can do this is through a feedback loop on medical questions so we made the choice to have a doctor in the loop initially to get high-quality medical feedback so you can imagine you can ask patients hey did you like this question or you can ask doctors hey did you like this question and because we're using this as grand she's labeling to rebuild our medical models we chose to use doctors in practice what this looks like is that in production you present the doctor with a choice they can choose to use or not use a particular suggested question to send to a patient and if they click yes you go ahead and send it and if they click no you don't send it and this is a really interesting model because the incentives are aligned the doctors are incentivized to use this tool because it saves them time with typing and you might not think that that's a big time savings but we know that doctors spend thirty five percent of their time on administrative tasks and way too much time doing things like typing or asking the same sets of questions so it's actually a really big time saver and if they select no that's really important negative feedback to our models that the models prediction was incorrect so they're using this in production and we can use their history of their usage data as ground truth labeling or in other words as feedback to retrain our models so we've learned a couple of things here about a data feedback loop one is that data collection and labeling is often the rate-limiting step of ml research it's time-consuming to collect and it often doesn't perform well under data shift so that's the status quo so again we also know that we're using these models in production and getting usage history from real doctors in real time and we can use that feedback that yes or no as ground truth labeling to retrain our models this means that the model can get better and better over time using this data and learning from its past history and its past mistakes so compared to the status quo we now have a way to scale our machine learning models and iterate much more quickly than we could before so hopefully I've convinced you at this point that you should use a machine learning data feedback loop and next I want to talk a little bit about how to build an ml data feedback loop so these are the nuts and bolts a data feedback loop in short means that health care models in our particular use case should learn from their history by harnessing doctor and patient you should usage data to retrain your models so this is the high level of what a data feedback loop looks like one really important note is how you collect your data so there are two ways you can do this there is implicit and explicit data implicit data collection would be something like you present a suggested medical question to the doctor to send to the patient and they can either click yes or they can ignore it so this is lower friction it doesn't interrupt their workflow and it's higher signal meaning that if they say yes they must have really liked that question but it's a little bit more confusing for your data labeling so maybe an ignore means that it was a negative response it was a bad question or maybe they just didn't care to use your tool and the other option is explicit data which is every single time they have to click yes use this or no don't use this so that's a lot more straightforward for your ground truth labeling but it interrupts their workflow so there's a trade-off there so in this data feedback loop you start with your model integrated into your application and then based on the usage data from your doctor or your patient you send that forward to a couple of data sinks from there it goes to a data warehouse for some amount of data analysis or post-processing so maybe this is a Python script or some sort of cron job running and then sent to an output table so something like a CSV or other data store then you retrain your machine learning model you test and deploy and you reintegrate a cure I we use a lot of different pieces of technology to build this data feedback loop in the healthcare app itself who use docker and kubernetes for data sinks we use things like stock driver on the backend mix panel on the front end we're mostly a Google cloud shop so we use bigquery for data warehouse and Google Cloud Storage for output we're training our machine learning models we use everything from PI torch to pandas to tensorflow for deploying we use helm and for testing in an online setting via future flagging we use launch directly so that's a lot of different components so I want to just focus in on a couple of key pieces and the first one is the set of data sinks so we use stock driver primarily on the backend for logging what the doctor is deciding to do so the way that you would actually set this up is you would start with a GCP project with stock driver logging API enabled there's a link down below for a great resource and documentation on exactly how to do that second for your authorized user you assign the cloud logs writer role so here on the right you can see a screenshot of how you would do that it's pretty straight forward and third you install the library so this is a pip install Google Cloud logging I should note at this point that we are a python-based shop on the back end so all these are examples are going to be focused on Python but they're very similar and other back-end languages on the Python side we've gone ahead and made a flask application to set up our shop and then we need to configure this stock driver logging so that's what this step is here the application has some configuration for stock driver and you're just grabbing the Google Cloud login client so once that's instantiate 'add the second thing you need to do is grab that client then access a particular logger in this case it's called NQ log name which isn't particularly descriptive of a title but maybe you call it something like doctor selection of model and then the last thing you need to do is call logger.log struct which is actually going to forward your data on to the stock driver service so here you need to collect everything that you would actually need to recreate the decision-making process in real time things like the user ID who actually made the selection the time stamp or when they made it importantly the model input and output so that you can recreate this environment exactly of course the user selection any information about your model version so if we're talking about many different models in production it's really important to keep track of which one you are working with and your environment so here is a screenshot of what that looks like on the sock driver side it's forwarding some sort of JSON payload so here you can see a patient came in with a fever a headache and a cough and the model said you should ask about a severe headache or maybe a high-grade fever or maybe nausea and the doctor goes ahead and says I want to ask about severe headache so that's what the Data Sync step looks like and once you've collected that data you then forward it on to your data warehouse for some amount of post-processing this involves two primary steps the first is to scrub your data set of sensitive data in our case in our vertical this is protected health information or pH I so things like your name your date of birth what your specific medical history is that ties itself to you and your identity so for example say one of the things you want to store starts off as thanks for the info miss Sanchez that's me do you also have a fever and then you transfer that to what you actually care about which was the name of the symptom so a KB item or a knowledge base node representation of your symptom named fever this is also true of other verticals a really good example is finance or banking so things like scrubbing data of a credit card number or your personal address the second thing you do is join your data sinks to form your ground truth data set so as an example here suppose you're locking the doctor's choice from your stock driver logs and you have a second data sink from Mixpanel which is more related to front-end style logging so things like clicks or an on hover which you could combine with this other data set to get a sense of what the doctor actually saw and looked at versus what they didn't even bother to take a look at once you've done your data post-processing then you output your data to some sort of table or other data store and use that ground truth data set to retrain your machine learning model so you can have an entire talk on what retraining your ml model looks like it's going to be highly dependent on exactly what sort of machine learning you're doing in our particular case you can think of it as a graphical representation of symptoms in diseases where the edges are probabilities connecting these different concepts so perhaps retraining your machine learning model means updating these edges or adding new information that you didn't know about before once you've retrained your machine learning model the last step is to test and deploy and this might be the most important step of this entire process because we know that one of the primary things are trying to solve for is that models don't tend to perform that well in production so the question is how do you actually test them and make sure that they're going to be better than what you had before so one of the ways that you do this is the traditional method so offline metrics which I imagine most people in this audience are familiar with you compute on a gold standard test set in our case we tend to use the semi grand test set which is a essentially a gold standard medical test set for diagnosed models it's really great because different labs or different folks in industry can use it to cross compare and see how they're performing and how they stack up against other people's approaches it's a set of 70 to 80 medical cases with a set of symptoms and what the ground truth label is for the diagnosis so while it's great that you can cross compare against other people's models it's not so great because as anybody who's been to the doctor or taken a kid to the doctor knows there's a lot more possibilities than just 70 or 80 cases so to account for that we also use a test set which is curated in-house by our own clinical experts so the advantage there is there's a lot more coverage in the possible domain space so those are the two approaches that we use to calculate our offline metrics and say okay in our sort of controlled environment how is our model performing the second and perhaps more interesting approach is to look at the online metrics and in this particular case by online I actually mean in production so when you're actually sending a doctor responses in real time in a real world environment how do you actually measure how your model is performing the first way you can do this is by looking at what's called top K accuracy of your diagnostic model on in the wild cases so in other words you can leverage the fact that a doctor has to fill out these forms and these patient charts with things like what their symptoms were what the diagnosis was and compare that to what your model predicted it would be the second thing you can do is look at user satisfaction in an online model so this is something like a patient thumbs up or patient thumbs down at the end of a doctor-patient chat and this turns out to be really important for measuring these in the wild cases so as a concrete example imagine that the model is asking a patient do you have red hair this is a real example and that can be a pretty jarring question to ask somebody about the color of their hair other physical features it might not make sense in the context of their symptoms so of course the patient gives a thumbs down because they don't particularly like that but turns out from a mathematical and medical sense this actually makes a lot of sense we know that in medicine having red hair might be associated with pain tolerance or anesthesia but without that additional context user satisfaction will suggest that that's not a good question to ask a third way that you can test online metrics is through what we call a B testing so instead of just plugging in your new model and totally getting rid of the old version what you want to do is run an experiment in an online setting so so you have three models an old one and two versions of your new one what you would do is setup feature flagging so the maybe 33% of patients get model one 33% get model two and 33% get model three and through this way you can test in an online way which model is actually performing the best to do this we use launched darkly ourselves there are lots of other options you can use Optimizely as a great one you could also set up your own JSON file to ingest if you want to do it in a very bootstrapped way but regardless all of these approaches are using feature flagging for a be testing so for lunch darkly the way that you would set this up on the command line is a simple pip install launch directly server SDK and then once you have that on the Python side you need to go ahead and instantiate your launch darkly client so here you can see you're setting the SDK key which is a private key that's given to you when you set up an account and then you go ahead and get that client here is just a wrapper around the launch darkly get variation method so all this is doing is it's taking in a feature flag that you're trying to query for and a hash and it's going to give you back the answer so for example say the feature flag you want to get information about is your cure i model test and then you have pass in a hash this is probably going to be a patient or a doctor user ID and then it's going to give you back an assignment so some strings saying this user should be assigned to model one or model two or model three here in the model wrapper so you can see the call to that get variation that we just talked about with a user ID and the model string name once you have that string assignment returned to you you go ahead and you get the actual instantiated model that you're going to call so it could be as simple as in this case a dictionary that you're grabbing that variation from so that would look like this here are your model arms you got model 1 model 2 and model 3 so in this way you can do testing across multiple different versions of your model in production and this is just a launch darkly side of things if you're a feature flag is called Qri model arms and you have your model 1 2 & 3 that you set up then link that to your Python logic so that's testing and deploying and at the end of all this you get the reward I suppose which is reintegrating and deploying into your healthcare application so what this might look like as a final product is suppose this is the before screenshot so the user comes in with a cough a sore throat and a fever and the model asks do you have clear nasal discharge yes no unsure and then the new model is going to ask maybe a better question do you have a high-grade fever and in that way we have a newer version of our model that's relying on usage history for retraining so that's the data feedback loop as a big picture a couple of final thoughts so one topic that's often neglected when people talk about training machine learning models or data feedback loops especially as it concerns online testing and data collection is the ethics of building these data feedback loops so we strongly believe that user trust should come before use or usage as a prerequisite what this means essentially is that the user whether it's a doctor or a patient should always understand how and why their data are being used especially because we're using it to build a machine learning model to make medical predictions that that is a really important piece this plays out in a couple of key ways on the ui/ux side it's about how you actually present this data to the user and explain what you're doing from an art guru architectural standpoint it really impacts things like where you store your logs and how you do that in a way that's ethical and compliant so as an example perhaps stackdriver as a data sink is HIPAA compliant HIPAA being a set of laws regulations and best practices surrounding how you store a sensitive health information but maybe Mixpanel is not and so you always have to be aware of where you're sending this data and what additional security measurements you need when building this data feedback loop as it pertains to sensitive health information so important ramifications both on the ui/ux side and also architectural ewwww so looking forward Cariah is working on combined forces of human practitioners with AI to provide quality care at less than 20% of the cost for best health care access we focused on mobile health mobile first care meaning that you always have access to a health provider 24/7 so doing things like applying a data feedback loop can improve the iteration of your madhuri training and ultimately help to provide better question-asking models and diagnostic models to provide high quality care and with that I'll take any questions and thank you very much [Applause] hey I really like which all are doing I did have a question how what do you tailor more towards of trying to obviously getting it perfect could be ideal but both false positives and false negatives are potentially dangerous in the medical diagnosis it's not I don't like the movie you recommended me how do you handle that I mean how do you work with that yeah thank you really insightful question so that actually depends a lot on the sub domain which is a piece that I didn't really have time to get into here so for example when you're building diagnostic models for dermatology it turns out they're only a couple of treatments for a whole range of dermatology problems so in that what you're trying to balance is the risk of different treatments and so most of the treatments are pretty low risk so if you accidentally say you have this disease when you don't and you get recommended a low risk treatment not such I mean it's not great but like it's much better than some other fields you can imagine as a sort of extreme example if you tell somebody they have cancer and they don't and then you recommend chemotherapy that's obviously a much worse use case so the short answer is it depends on the sub domain hi great talk I'm curious how much of the this application works for a history right lots of times in his patient history is very you know thorough yeah so it's a question how does this apply when you're looking at temporal data sorry is this a brand-new patient who's just never had any person medical history and then that model is trained just on their first one sentence or is it or is there more personal history involved in their predictions yeah great question so they're actually a lot of pieces of data that go into something like this you have their patient reported medical history so my parent has this form of cancer I take these medications that I have for the last two years there's also what we call episodes of care or EOC s that means every time you go to the doctor that a separate interaction and so that is also used as input to your medical model so you can imagine somebody who comes in who has a history of cancer in their family you should maybe build a model that's more likely to ask them those sorts of questions right are there any further questions [Music] what challenges does this face with HIPAA and high trust and all that sort of stuff yeah so there are a lot of regulations and best practices surrounding protected health information the the key is a couple of things first to always keep in mind that those things are there for good reason it's to protect patients and everybody in this room is a patient the second thing is you just have to be really careful about how you architect your system right so this is adding additional layers of security it's how you do your ops in deployment it's how you scrub your data so there's a really interesting field that's just about can and how can you do nonnamous data and sort of distill that into the data that you need so yeah it definitely affects a lot of the work that we do any other questions all righty I think that's it all right thank you very much [Music] [Applause] [Music]