AI, ML & GenAI Demystified Series: Good Data Beats Clever Models

Introduction

Welcome back to the kitchen. If Part 1 was the pantry tour and Part 2 was choosing the right recipe, then Part 3 is all about ingredients. Because before a machine can learn, it needs something to learn from. That means data. Not just any data, though. The quality, structure, and flavor of your data can shape everything that comes after.

This is the third post in the AI, ML & GenAI Demystified series. In Part 1, we unpacked how we got to today's AI landscape by tracing the evolution from old-school logic to modern generative models. Part 2 tackled the big question most teams skip: should AI even be used for this task? Now we're rolling up our sleeves and getting hands-on with what AI actually needs to cook something useful.

Here's the kicker: most AI projects don't fail because the model was bad. They fail because the data was. Maybe it was messy, biased, too small, too stale, or just not the right match for the job. That's why this post focuses entirely on getting your data house in order before you ever open up a model notebook.

More data beats clever algorithms, but better data beats more data.

Peter Norvig

We'll break down the kinds of data you'll run into, how to collect and label it, how to prep it for modeling, and what to watch out for when it comes to bias, quality, and silent errors that can poison the whole dish.

You're not just feeding a machine. You're shaping how it sees the world.

Understanding the Data Landscape

Data is the new oil. It's valuable but if unrefined it cannot really be used.

Clive Humby

Before you can train a model, you need to know what you're feeding it. In machine learning, "data" isn't just a blob of numbers or text—it's a complex, dynamic ingredient that comes in all shapes, speeds, and storage formats. And like any great recipe, the outcome depends heavily on the quality, variety, and preparation of what you start with.

This section will help you recognize the ingredients at your disposal—what they are, where they come from, and how they're stored—so you can work with them deliberately instead of hoping for the best.

Types of Data

Some data comes neatly diced and labeled. Other data shows up like a mystery crate of raw produce.

Structured data is the tidy kind—organized into rows and columns like spreadsheets or database tables. It's ideal for classic ML tasks like forecasting or classification. Unstructured data is the wild stuff—images, audio, video, free-form text. Most of the fuel behind generative AI lives here. In between, you've got semi-structured data: things like JSON files or XML that have some format but still need effort to prepare.

Structured data is easy to use but not always available. Unstructured data is messy but powerful. Most real-world AI systems deal with all three.

But knowing what kind of data you have is just the beginning. Next, you need to know how it's arriving—and how quickly it's moving.

Where Data Comes From

Just like a kitchen deals with different delivery schedules (weekly produce, daily bread, real-time online orders), machine learning systems handle data that arrives in different modes.

• Batch data comes in bulk. Think daily CSV exports or ETL jobs that run overnight.
• Streaming data is real-time and continuous—like sensor readings or click logs sent through Kafka or Kinesis.
• APIs let you fetch data on-demand or in chunks, often from third-party services or internal microservices.

Each mode has trade-offs. Batch is easier to manage and test but lacks immediacy. Streams require specialized infrastructure but keep your models fresh. APIs give flexibility, but latency and rate limits can bottleneck performance.

ML systems often combine all three. Your model might train on batch history, monitor updates from a stream, and enrich predictions using API calls on the fly.

Most conversations about data start with the three Vs: volume, variety, and velocity. These describe how much data you have, what form it comes in, and how quickly it arrives. But in real projects, a few more Vs creep in — veracity (is it trustworthy?), value (does it actually help?), and volatility (how often does it change?).

Let's translate that into something practical:

This isn't just plumbing. How fast data arrives, and how often it changes, shapes what kind of structure your data needs. Before we decide where to store it, we need to understand how it's organized — because the way your data is modeled and formatted can make or break everything that comes next.

Data Models and Formats

Before we talk about where your data lives, we need to talk about how it's structured. Data modeling is like deciding how you organize your kitchen—whether you label every spice jar, dump everything into one big drawer, or keep specialized storage for unique ingredients. The choices you make here affect how easy it is to cook later.

Data in machine learning isn't just about raw values—it's about how those values are modeled and formatted. Whether you're dealing with classic relational rows, nested JSON objects, or high-dimensional embeddings, your model needs to understand the shape and structure of the data it ingests.

Each model has trade-offs. Relational models are precise and structured—great for cleanly diced data. Document and graph models offer flexibility for messier or relational data. Vector databases are a newer addition—perfect for storing the abstract representations created by modern ML systems like embeddings.

Data is only useful if you act on it. Don't just collect data. Interpret it. Experiment with it. Use it to inform better decisions.

Cassie Kozyrkov, former Chief Decision Scientist at Google

Choosing a file format is like choosing packaging for your ingredients. Some formats (like CSV or JSON) are great for human inspection and quick debugging. Others (like Parquet, TFRecord, or Protobuf) are built for scale, performance, and compatibility with big ML pipelines.

Once you understand how your data is modeled and formatted, you can make smarter decisions about how and where to store it—and what tooling you'll need to access it later.

Storage Models

Once the data is in the door, where does it go? Just like a kitchen needs fridges, pantries, and prep stations, your AI system needs proper data storage—and not all storage is created equal.

• Warehouses are like precision-prepped mise en place—fast, structured, but limited in variety.
• Lakes are your bulk freezer: cheap, versatile, but a little chaotic.
• Lakehouses are the walk-in fridge with zones for everything—giving you structure when you need it and flexibility when you don’t.

These storage choices affect not just speed and cost, but how accessible your data is to data scientists, analysts, and ML pipelines. Want to reduce ETL pain? Choose a format that supports schema evolution and columnar storage. Want to scale labeling or retraining? Make sure your storage supports versioning and metadata tracking.

In short, how you store data shapes how you'll use it.

From Raw to Ready

Once you understand what data looks like and where it lives, it's time to get your hands dirty. This is the messy middle of the machine learning kitchen — the prep work that turns raw ingredients into something your model can actually learn from.

Data doesn't show up clean, labeled, and ready to use. It arrives noisy, incomplete, imbalanced, or just plain weird. The job here is to gather it, make sense of it, clean it up, and shape it for learning. That includes tagging it with the right labels, engineering the right features, and handling the messy real-world issues like missing values, outliers, and bias.

Done well, this part lays the foundation for everything that comes next. Done poorly, it sets your model up for failure — no matter how clever the architecture is.

Let's walk through how we go from raw to ready.

Collecting and Preparing Data

Before a machine can learn, it needs something to learn from. That means collecting data that's relevant, timely, and representative of the problem you're solving. Whether it comes from batch jobs, streaming pipelines, or third-party APIs, the point isn't just to collect a lot of data — it's to collect the right data.

Just like you wouldn't cook with spoiled produce or expired ingredients, you don't want to train a model on data that's missing context or skewed beyond recognition.

Once data is in hand, the next step is data wrangling — cleaning, transforming, and labeling it into something useful. If you're training a supervised model, you need clear input-output pairs.

• Features are your inputs — things like temperature, image pixels, or credit scores.
• Labels are the targets — the category, number, or signal you want the model to predict.

Labeling can be:

• Manual — humans tag each example (e.g., marking spam emails).
• Automated — rules or heuristics apply labels programmatically.
• Hybrid — automation first, then human-in-the-loop review for quality.

After labeling, you split the data into:

• Training set — usually 70 to 80 percent. The model learns here.
• Validation set — used to tune hyperparameters and compare models.
• Test set — a clean set for final performance evaluation.

To avoid overfitting, you might also use cross-validation, where different slices of the data rotate through the validation role.

A few best practices at this stage:

• Split before you scale — apply any normalization or transformation after splitting, to prevent data leakage.
• Use only training stats — compute scaling parameters like mean or standard deviation from the training set alone.
• Track where your data comes from — lineage matters, especially in regulated or dynamic environments.

Sometimes your training data doesn't match your production inputs. This is data mismatch — for example, if you train on clean product photos but your users upload blurry smartphone shots. One way to catch it early is by creating a train-dev split, where a slice of your training data mimics real-world noise or variation.

Once data is labeled and split, it's time to shape it — and that's where feature engineering comes in.

Feature Engineering

Coming up with features is difficult, time-consuming, and requires expert knowledge. Applied machine learning is basically feature engineering.

Andrew Ng, Machine Learning and AI via Brain Simulations, Stanford University

Feature engineering is a creative act of data wrangling that shapes the signals your model will learn from. You don't just throw raw ingredients into a pan. You prep them. Chop, measure, marinate. Machine learning is no different.

Feature engineering is the process of transforming raw inputs into signals your model can understand and learn from. It's a creative and often domain-specific process. Done well, it can boost even simple models to top-tier performance. Done poorly, it can bury useful patterns under noise.

Some feature engineering best practices:

• Split first, then engineer — never engineer features on the whole dataset if they rely on label info or summary stats.
• Use domain knowledge — what matters in healthcare isn't the same as in retail or aerospace.
• Watch for leakage — features that contain information you wouldn't have at prediction time can create false confidence.
• Feature selection matters — more features isn't always better. Prune the noisy, irrelevant, or redundant ones.
• Understand importance — use correlation matrices, SHAP values, or model-specific tools to identify what's driving decisions.

Once you've engineered your features, the next step is deciding which ones to keep. That's where feature selection comes in. It's the process of identifying which inputs are truly informative, and which are just noise. More features don't always mean better performance. In fact, irrelevant or redundant features can confuse your model and slow down training. Tools like correlation analysis, variance thresholds, model-based importance scores (like SHAP), or dimensionality reduction techniques like PCA can help you make smart cuts.

You can automate some of this with libraries or AutoML tools, but human insight remains irreplaceable — especially in regulated or high-stakes domains.

And remember: feature engineering never really ends. Even after deployment, new patterns, inputs, or use cases might require feature tweaks or expansion.

Data Quality, Imputation and Cleaning

Garbage in, garbage out.

George Fuechsel, IBM engineer (classic aphorism, 1957)

Even the best recipes fall apart with rotten ingredients. Machine learning is no different. If your data is messy, inconsistent, or biased, your model will inherit those flaws.

Here are some common pitfalls:

Cleaning isn't just about deleting rows. It's about making conscious trade-offs.

Ways to handle missing values:

• Mean, median, or mode — simple but may smooth away natural variation.
• Constant placeholder — especially for categorical fields; lets the model learn "missingness."
• Forward/backward fill — useful in time-series where continuity matters.
• Model-based imputation — use other features to predict the missing value.
• Drop it — if a field is unreliable or irrelevant, it may be better to remove it.

Tip: Always track which values were imputed. That absence might itself be a signal.

Cleaning and imputation are where your dataset earns its trustworthiness. But technical cleaning isn't enough. You also have to ask who's represented — and who's left out.

Bias, Diversity and Representation

Data isn't neutral. It reflects the systems and decisions that created it. And if those systems were biased, your model will be too.

This goes beyond technical fixes. It's about asking: who labeled this data? Who does it represent? Who might be harmed by bad predictions?

A few real-world examples:

• Facial recognition systems that underperform on darker skin tones.
• Resume screeners that learn to favor certain genders or universities.
• Loan models that penalize ZIP codes due to historical redlining.

Bias can come from many places: how data was collected, who was included, what was labeled, or what features were engineered. Fixing it takes more than filters — it takes human judgment, diverse perspectives, and ethical awareness.

To reduce risk:

• Audit your dataset — who's in it, who's not, and why?
• Measure fairness — many platforms offer tools to track equity across groups.
• Include stakeholders — especially those impacted by model decisions.
• Document assumptions — clarity helps others interpret and improve your work.

Fairness isn't an add-on. It's part of the prep. And like any good kitchen, your data process needs to serve everyone — not just the easy cases.

Data Pitfalls and Failure Modes

You can prep your ingredients with care, follow every recipe, and still end up with a dish that falls flat. Sometimes, the problem isn't the cooking. It's that the ingredients came from the wrong kitchen.

In machine learning, these kinds of mismatches creep in quietly. And they often don't show up until after deployment.

Data Mismatch and Distribution Drift

All models are wrong, but some are useful.

George Box

One of the biggest reasons models fail in the wild? The world they were trained on no longer matches the world they operate in.

This happens in two flavors:

• Data mismatch: Your training data looks different from your production data. You built a vision model using clean, studio-lit stock photos, but now it's trying to classify blurry webcam snapshots. That mismatch leads to unpredictable performance.
• Distribution drift: The real world changes over time. User behavior evolves. Market signals shift. What was true last month may no longer be true today. The model doesn't degrade overnight—it just starts making more mistakes, slowly and silently.

That's why techniques like a train-dev split—where you set aside a portion of training data that simulates your real-world inputs—can help surface mismatch before it bites you in production.

And post-deployment? You need monitoring in place to catch drift early. Model accuracy, input distributions, and even user engagement patterns can all signal when it's time to retrain or adjust.

If your ingredients change, the recipe might need to change too.

The Role of Governance and Lineage

In any kitchen, you want to know where your food came from. In machine learning, that same logic applies. You need to trace your data—where it came from, how it's changed, who touched it, and when.

That's data lineage. It's not just a technical detail. It's the foundation for trust, reproducibility, and accountability.

Governance tools help you:

• Track dataset versions and schema changes
• Log data transformations and preprocessing steps
• Annotate who labeled what, when, and how
• Maintain audit trails for compliance or debugging

Without governance, small issues compound. A mislabeled field. A corrupted file. A quiet change to a data source. These can all cascade into model failure. And if you can't trace the source, you can't fix the dish—you just keep serving it wrong.

Governance isn't glamorous, but it's what separates AI prototypes from AI products. It's how you move from hacks to habits, from one-off experiments to repeatable, reliable systems.

Because good data isn't just about what's in it. It's about how you manage it, track it, and trust it over time.

Different Ways to Model the World

When you teach a machine, you're teaching it how to make sense of the world. But there's more than one way to do that.

Some systems start with logic. Others start with data. The path you choose affects everything—how you prepare your data, how you reason about results, and how confident you can be in what comes out.

This section explores two very different philosophies in AI: manual modeling, where humans define the structure, and emergent modeling, where structure is learned from data.

Let's step into both kitchens.

Ontologies & Knowledge Graphs

Before neural networks took over, many AI systems began with a simple but powerful question: What are the things in this world, and how do they relate? Symbolic approaches to AI answer that question by explicitly modeling knowledge — and ontologies are one of the main ways they do it.

An ontology is a formal definition of concepts and relationships in a specific domain. It's like a hand-crafted map of the territory, designed by subject matter experts to reflect how things actually work — or how we want a system to understand them.

For example, in a family ontology, you might define:

• John is a Person
• Mary is a Person
• John is the FatherOf Mary
• Therefore, Mary is the DaughterOf John

These relationships aren't guessed or inferred — they're declared. That makes them highly interpretable, controllable, and often legally or operationally reliable.

Symbolic AI systems excel in environments where correctness, consistency, and traceability are paramount. They're often used in:

• Medical diagnostics
• Legal document classification
• Compliance automation
• Metadata modeling
• Cyber threat intelligence graphs

Because the rules are transparent and inspectable, inference is deterministic — the system arrives at conclusions through logic, not probability.

But there's a catch.

Creating and maintaining these systems is labor-intensive. Experts must agree on definitions, update schemas as the world changes, and account for edge cases ahead of time. That works well for stable domains, but it struggles with ambiguity, scale, or constantly shifting language.

Symbolic systems are like writing your own cookbook: clear and precise, but slow to expand. You get control and clarity — at the cost of flexibility and coverage.

Next, we'll look at a very different approach — one that starts not with predefined rules, but with mountains of data and a model that learns patterns for itself.

Emergent Representations

The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.

Edsger Dijkstra

If ontologies are like writing out a recipe step by step, emergent models are like watching a chef improvise after years in the kitchen. There's no printed guide—just instinct, pattern recognition, and thousands of meals' worth of experience.

Models like large language models (LLMs) don't start with predefined structure. They train on oceans of data—text, images, code—and let patterns emerge organically. They don't store facts in diagrams. Instead, they build statistical representations: rich, multi-dimensional maps of what tends to co-occur, what follows what, and how concepts connect in subtle ways.

Unlike symbolic systems, where logic and relationships are carefully crafted, emergent models learn everything from the data itself. These internal structures—like attention maps and embeddings—are rarely human-readable, but incredibly powerful. They allow the model to summarize books, write software, and even perform chain-of-thought reasoning.

Here's how this bottom-up approach compares to traditional symbolic AI:

You could say symbolic systems are like assembling IKEA furniture—every part has a label, and the instructions are clear. Emergent models are more like learning carpentry by studying thousands of finished chairs and figuring out the style as you go.

This difference has real implications for how you prepare data. Symbolic systems demand clean, labeled inputs up front. Emergent models can work with messier data—but scale, diversity, and quality still matter. Garbage in still leads to garbage out—even if the garbage is elegantly predicted.

Why This Matters for Data Preparation

Whether you're hand-coding logic or training a model on petabytes of data, your approach to machine learning shapes how you prep the ingredients.

If you're working with symbolic systems, data prep is like laying out a mise en place for a cooking class. You need labeled containers, clearly defined terms, and carefully controlled portions. The relationships between ingredients—this is a spice, that's a vegetable, this belongs in a soup—are explicit and must be written down ahead of time. The model follows those rules, step by step.

But if you're building emergent models like LLMs or multimodal transformers, it's more like watching a master chef work from intuition. You don't give the model the rules—you give it examples. Lots of them. The goal isn't a recipe, but an instinct built from experience. What matters isn't just labeling a tomato, but showing the model a thousand ways tomatoes are used.

That means:

• Symbolic systems need well-defined structure: ontologies, hierarchies, and relationships between terms must be made clear upfront.
• Emergent systems need high-volume, high-variety, and high-quality data: the model finds its own structure from patterns across examples.

Here's how that difference plays out in real-world prep:

And sometimes, the smartest kitchen combines both.

The key takeaway: how you prep your data should match the kind of system you're building. Don't try to handcraft an ontology if you're training a generative model. And don't expect an LLM to follow strict rules if you've only given it vague, inconsistent examples.

Different cooks. Different kitchens. Same rule: prep matters.

Conclusion: Data Isn't Step One. It's the Backbone.

We started this post with a simple idea: good data beats clever models. But by now, it's clear that data isn't just fuel — it's the foundation, the framing, and the flavor. Everything your model learns, trusts, and repeats is shaped by the examples you give it. You're not just feeding it information. You're shaping its worldview.

Whether you're wrangling structured tables or untangling messy logs, curating diverse examples or trimming bias from labels — this work matters. It defines what your model can know, what it will ignore, and how well it will generalize when the real world comes knocking.

And just like a kitchen doesn't stop prepping after one dish, data work in machine learning is never "done." Models evolve, behaviors shift, feedback rolls in. So keep your pipeline clean, your features sharp, and your expectations grounded in reality, not hype.

Because the smartest AI systems don't start with genius. They start with good ingredients.

Up Next: Training Day

Now that we've shaped the raw ingredients, it's time to choose the recipe.

In the next post, we'll dive into model training — how to pick the right algorithm, tune it for performance, and evaluate whether it's truly ready for the real world. We'll break down learning paradigms, explore modern architectures like transformers and diffusion models, and look at what makes foundation models so powerful (and sometimes unpredictable).

Because it's not just about getting your model to learn — it's about teaching it to learn the right things, the right way.

See the associated LinkedIn post.