ZenML

Query rewriting is really under-rated for RAG systems I've seen firsthand how query rewriting can dramatically improve retrieval quality - yet most teams skip proper evaluation of this critical step. Implementing fancy query rewriting without rigorous evaluation is like driving blindfolded. You think you're heading in the right direction, but you're likely headed for trouble. Real-world example from our RAG bot: A query about "monitoring my pipeline" gets rewritten to "visualizing data in MLflow" - completely missing that the user wanted ZenML pipeline monitoring. These subtle misalignments destroy user trust. Common Pitfalls: • Ambiguity introducing inaccuracy • Missing domain-specific nuances • Over/under-specificity tradeoffs • Temporal drift in terminology What actually works is building systematic evaluation pipelines, tracking original queries alongside rewrites, implement automated scoring functions, and comparing performance across rewriting models. You can subsequently set up regression alerts when quality drops. The most impressive RAG pattern is worthless without evidence it's actually working. Continuous evaluation isn't optional - it's the foundation of trustworthy systems. Jayesh wrote a great guide on this on our recent blog - Give it a read if you're optimizing your RAG systems: https://lnkd.in/dGGrM3wU

Model Context Protocol is one of two things I've been following closely since December 2024, and I'm pleased that it seems to have gone viral last week. The Model Context Protocol (MCP) is an emerging standard, developed initially by Anthropic, designed to enhance how AI models, particularly large language models (LLMs), interact with external data sources and tools. It aims to simplify context management, making it easier for AI applications to access and utilize relevant information, which can improve response quality and scalability. I think it's instinct for many to say "Oh this is just an API", but you need to zoom out a bit to "get it". Yes, of course its just a typical client/server API, but if everyone starts adopting "This particular way of writing an API", *then* it has the potential to be disruptive. Case in point: At ZenML we just released our own MCP server to the world. We encoded all the tools that the LLM needs to interact with a ZenML deployment (fetching pipelines, logs, stacks etc). And now, users can plug it into Claude or Cursor or whatever, and boom they have a natural language interface to ZenML. We didn't need to build a chatbot, or integrate into our dashboard, or whatever else. It's just available now to our community. This GIF walks through how easy it is to generate a report using it: It's basically "Chat to your MLOps pipeline" baked right into Claude. Play with our new MCP server now (there's an easter egg for the eagle eyed ;-) ) now! In order to do that, you'll need to follow instructions which I'll link below. What do you think of the MCP standard? Comment below!

"I have 47 nearly identical Airflow DAGs, each serving a different ML model variant." If that made you wince, you're not alone. Let's talk about the real mess of ML workflows in Airflow. Common failure patterns I keep seeing: 1. Massive monolithic DAGs that try to handle every edge case   (Good luck debugging that 4000-line pipeline.py) 2. Task dependencies that look like spaghetti   (Because someone had to handle "just one more feature flag") 3. Hardcoded paths and config scattered across tasks   (The classic "it works on my branch" syndrome) 4. Running preprocessing in notebooks, then wondering why prod is broken (Those magic .transform() calls need version control too) What actually works: • Dynamic DAG generation from config • Modular tasks with clear contracts • Version EVERYTHING (yes, even those sklearn transformers) • Standardized failure handling patterns • Parameterized model artifacts Real talk: Your Airflow DAGs should be boring. All the ML complexity should live in versioned packages, not task definitions. Your data scientists will never read your Airflow docs. But they will use your templates if you make them easier than notebooks. The best ML pipelines are the ones you can explain to a new team member in 10 minutes. #MLOps #DataEngineering #MachineLearning #Airflow

Let's talk RAG in Enterprise! 🫸We now know prototyping a Hello World RAG app vs getting it reliably into production are two distinct problems (surprise surprise) 🫸Problems in production include inconsistent thinking, hallucinations, incompleteness, performance degradation etc 🫸A good framing is that RAG systems are data pipelines at heart (ingestion, reranking, evaluation, PII detection, etc) 🫸It's clear that building a data flywheel for your LLMOps (as for MLOps before that) is going to be a key competitive differentiation moving forward 🫸Start simple but frame this as a data problem! A solid ML platform foundation is worth the investment to enable GenAI use-cases reliably across the enterprise Picture: Me speaking about how to architect a RAG system for the enterprise at ElasticON last week in Munich

A candid note to ML platform leads: Building that internal ML platform was the easy part, wasn't it? The real gut punch came when: ➡️ Your data scientists kept using their notebooks instead of your carefully crafted workflows. ➡️ Your ML engineers still copied model files manually rather than use your artifact store. ➡️ Your expensive GPU scheduler sat unused while teams spun up their own instances. ➡️ Your documentation went unread while Slack filled with the same basic questions. You did everything "right": ✓ Kubernetes-native architecture  ✓ Full model versioning ✓ Automated CI/CD ✓ Standardized environments ✓ Role-based access But you built what you thought they needed, not what they actually needed. I learned this the hard way: A half-implemented solution that teams actually use beats a perfect platform that they don't. Start with one team's actual workflow. Make it 10% better. Repeat. #MLOps #ML #SoftwareEngineering #PlatformEngineering