MLOps.community

Demetrios

Relaxed Conversations around getting AI into production, whatever shape that may come in (agentic, traditional ML, LLMs, Vibes, etc)

Episodes

Mentioned books

Oct 27, 2020 • 57min

Operationalize Open Source Models with SAS Open Model Manager // Ivan Nardini // Customer Engineer at SAS // MLOps Meetup #39

Oct 26, 2020 • 57min

Machine in Production = Data Engineering + ML + Software Engineering // Satish Chandra Gupta // MLOps Coffee Sessions #16

Oct 20, 2020 • 1h 2min

MLOps + Machine Learning // James Sutton // MLOps Coffee Sessions #15

Oct 19, 2020 • 57min

Scalable Python for Everyone, Everywhere // Matthew Rocklin // MLOps Meetup #38

Oct 18, 2020 • 1h 1min

MLOps Coffee Sessions #13 How to Choose the Right Machine Learning Tool: A Conversation // Jose Navarro and Mariya Davydova

4 snips

Oct 12, 2020 • 57min

MLOps Coffee Sessions #14 Conversation with the Creators of Dask // Hugo Bowne-Anderson and Matthew Rocklin

Hugo Bowne-Anderson and Matthew Rocklin, co-founders of Coiled, are reshaping the data science landscape. They dive into Dask, the open-source library that optimizes parallel computing for Python, making it easier to handle large datasets. The duo discusses the challenges of scaling data science, navigating cloud complexities, and the vital role of data literacy in organizations. They also share insights on community engagement in open source, the evolution of OSS, and the advantages of Dask over tools like Spark, emphasizing its future in distributed computing.

Oct 10, 2020 • 1h 5min

MLOps Coffee Sessions #12: Journey of Flyte at Lyft and Through Open-source // Ketan Umare

Ketan Umare, a Senior Staff Software Engineer at Lyft, discusses his pivotal role in the development of Flyte, a pivotal open-source project for machine learning infrastructure. He explains why Flyte was created, highlighting its capacity to handle tens of thousands of workflows and millions of tasks. The conversation delves into the complexities of mapping technology and the algorithmic challenges in ride-sharing. Ketan also shares insights on open-source community engagement and the transition to using Go for backend development.

Oct 4, 2020 • 1h 6min

MLOps Coffee Sessions #11: Analyzing “Continuous Delivery and Automation Pipelines in ML" // Part 3

Oct 4, 2020 • 56min

MLOps Meetup #36: Moving Deep Learning from Research to Prod Using DeterminedAI and Kubeflow // David Hershey, DeterminedAI

MLOps community meetup #36! This week, we talk to David Hershey, Solutions Engineer at Determined AI, about Moving Deep Learning from Research to Production with Determined and Kubeflow. // Key takeaways:What components are needed to do inference in MLHow to structure models for ML inferenceHow a model registry helps organize your models for easy consumptionHow you can set up reusable and easy-to-upgrade inference pipelines// Abstract:Translating the research that goes into creating a great deep learning model into a production application is a mess without the right tools. ML models have a lot of moving pieces, and on top of that, models are constantly evolving as new data arrives or the model is tweaked. In this talk, we'll show how you can find order in that chaos by using the Determined Model Registry along with Kubeflow Pipelines.// Bio:David Hershey is a solutions engineer for Determined AI. David has a passion for machine learning infrastructure, in particular systems that enable data scientists to spend more time innovating and changing the world with ML. Previously, David worked at Ford Motor Company as an ML Engineer, where he led the development of Ford's ML platform. He received his MS in Computer Science from Stanford University, where he focused on Artificial Intelligence and Machine Learning.// Relevant Linkswww.determined.aihttps://github.com/determined-ai/determinedhttps://determined.ai/blog/production-training-pipelines-with-determined-and-kubeflow/ Join our Slack community: https://go.mlops.community/slackFollow us on Twitter: @mlopscommunitySign up for the next meetup: https://go.mlops.community/registerConnect with Demetrios on LinkedIn: https://www.linkedin.com/in/dpbrinkm/Connect with David on LinkedIn: https://www.linkedin.com/in/david-hershey-458ab081/Timestamps:0:00 - Intros4:15 - The structure of the chat5:20 - What is DeterminedAI?7:20 - How is DeterminedAI different than other, more standard artifact storage solutions?9:25 - Where are the boundaries between what your tool determined AI does really well, and where it works smoothly with other things around it?11:48 - Is Kubeflow dying?13:54 - How do you see DeterminedAI and Kubeflow becoming more solidified?15:55 - How does DeterminedAI interact with Kubeflow at the moment?18:01 - What type of models are they? Is the Kubeflow metadata?19:18 - What is a model registry, and why is it so important to have that?23:16 - Can you give us the quick demo real fast?30:52 - Which orchestration tool to use?32:04 - When using Kubeflow are determined how can you deploy the model through CD tools like Jenkins?33:40 - How is it determined to be connected to Kubeflow?36:09 - What components do you feel are needed to do inference in machine learning? And how can we structure different models for that machine learning inference?40:04 - Are they the same ones when we talk about ML researchers?42:14 - How can we better be ready for when we do want to get into production?44:59 - In this pipeline, where do you normally see people getting stopped?47:05 - What are things that you've seen pop up that you're not necessarily thinking about in those first phases?50:17 - What are the most underrated topics regarding deploying machine learning models in production? 52:44 - How do you see the adoption of tools such as Determined and Kubeflow by Data scientists?54:40 - Can you explain the Determined open source components?

Sep 22, 2020 • 1h 8min

MLOps Coffee Sessions #10 Analyzing the Article “Continuous Delivery and Automation Pipelines in Machine Learning" // Part 2

Second installation, David and Demetrios are reviewing the Google paper about Continuous training and automated pipelines. They dive deep into machine learning monitoring and also what exactly continuous training actually entails. Some key highlights are:Automatically retraining and serving the models: When to do it?Outlier detectionDrift detectionOutlier detection:What is it?How you deal with itDrift detectionIndividual features may start to drift. This could be a bug, or it could be perfectly normal behavior that indicates that the world has changed, requiring the model to be retrained.Example changes:shifts in people’s preferencesmarketing campaignscompetitor movesthe weatherthe news cycleLocationsTimeDevices (clients)If the world you're working with is changing over time, model deployment should be treated as a continuous process. What this tells me is that you should keep the data scientists and engineers working on the model instead of immediately moving to another project.Deeper dive into concept driftFeature/target distributions changeAn overview of concept drift applications: “.. data analysis applications, data evolve over time and must be analyzed in near real time. Patterns and relations in such data often evolve over time; thus, models built for analyzing such data quickly become obsolete over time. In machine learning and data mining, this phenomenon is referred to as concept drift.”https://www.win.tue.nl/~mpechen/publications/pubs/CD_applications15.pdfhttps://www-ai.cs.tu-dortmund.de/LEHRE/FACHPROJEKT/SS12/paper/concept-drift/tsymbal2004.pdfTypes of concept drift:SuddenGradualGoogle, in some way, is trying to address this concern - the world is changing, and you want your ML system to change as well, so it can avoid decreased performance but also improve over time and adapt to its environment. This sort of robustness is necessary for certain domains.Continuous delivery and automation of pipelines (data, training, prediction service) was built with this in mind. Minimizing the commit-to-deploy interval and maximizing the velocity of software delivery and its components: maintainability, extensibility, and testabilityThen the pipeline is ready, you can now run it. So you can do this continuously. After the pipeline is deployed to the production environment, it will be executed automatically and repetitively to produce a trained model that is stored in a central model registry.This pipeline should be able to be run on a schedule or based on triggers: certain events that you have configured for your business domain - new data or drop in performance from the prod model.The link between the model artifact and the pipeline is never severed. What pipeline trained them? What data was extracted, validated, and how was it prepared? What was the training configuration, and how was it evaluated? Etc. metrics are key here! Lineage tracking!!!Keeping a close tie between the dev/experiment pipeline and the continuous production pipeline helps avoid inconsistencies between model artifacts produced by the pipeline and models being served - hard to debugJoin our Slack community: https://go.mlops.community/slackFollow us on Twitter: @mlopscommunitySign up for the next meetup: https://go.mlops.community/registerConnect with Demetrios on LinkedIn: https://www.linkedin.com/in/dpbrinkm/Connect with David on LinkedIn: https://www.linkedin.com/in/aponteanalytics/Connect with Cris Sterry on LinkedIn: https://www.linkedin.com/in/chrissterry/

The AI-powered Podcast Player

Save insights by tapping your headphones, chat with episodes, discover the best highlights - and more!

Get the app