From MOT Notes to Insights with MiniLM: A Practical Guide to Text Embeddings

Every year, millions of vehicles undergo MOT testing in the UK, generating a massive amount of free-text defect notes that could revolutionize how we understand vehicle maintenance patterns.

But there’s a catch – these notes are messy, inconsistent, and nearly impossible to analyze at scale using traditional methods.

Consider these real examples from MOT records:

“Nearside rear brake pipe corroded”
“Brake hose deteriorated”
“Brakes imbalanced across an axle”
“Headlamp aim too high”
“Exhaust leaking gases”

While these notes are invaluable for mechanics, they create a nightmare for data analysis. Every tester phrases things slightly differently, and traditional keyword searches miss the bigger picture. How do you find all brake-related issues when they’re described in dozens of different ways?

The answer lies in embeddings – a powerful technique that transforms unstructured text into structured, analyzable data.

Embeddings convert text into numeric vectors, placing similar meanings close together in high-dimensional space. With embeddings, “brake hose deteriorated” and “brake pipe corroded” become neighbors – even though the wording differs significantly. This opens up entirely new possibilities for analyzing text data at scale.

This post demonstrates a practical, hands-on approach using MiniLM to:

• – Transform messy MOT defect notes into structured embeddings
• – Cluster similar defects automatically using machine learning
• – Run semantic search to find related issues by meaning, not just keywords
• – Visualize the results to understand patterns in vehicle defects

Try the Interactive Demo

The demonstration is a Jupyter notebook that you can open directly in Google Colab – no setup required on your local machine.

Open the demo in Google Colab

Or if you’d rather you can view the repository and run it locally:

github.com/DonaldSimpson/mot_embeddings_demo

How It Works: From Text to Insights

 
The demo is comprised of three key steps, each building on the previous one:
 

Step 1: Text to Numbers

The MiniLM model (specifically “all-MiniLM-L6-v2”) converts each defect note into a 384-dimensional vector. Think of this as creating a unique “fingerprint” for each piece of text that captures its semantic meaning. Notes about similar issues will have similar fingerprints.

Step 2: Finding Patterns

K-means clustering automatically groups these fingerprints together. The algorithm discovers that “brake pipe corroded” and “brake hose deteriorated” belong in the same cluster, while “headlamp aim too high” forms its own group. You’ll see this visualized in a 2D scatter plot using PCA (Principal Component Analysis).
 

Step 3: Intelligent Search

Semantic search uses cosine similarity to find the most relevant notes for any query. When you search for “brake failure,” it doesn’t just look for those exact words – it finds notes that are semantically similar, even if they use completely different terminology.
 

The notebook demonstrates this with a carefully curated set of real MOT defect notes, including:

• Brake-related issues (pipes, hoses, imbalance)
• Lighting problems (headlamp aim, functionality)
• Steering and suspension defects
• Exhaust system issues
• Tyre wear problems

Each example is designed to show how embeddings capture meaning beyond literal word matching.

Hands-On Experimentation: Make It Your Own

This isn’t just a static demonstration – it’s a tool for discovery. The notebook is designed for active exploration, and the best way to understand embeddings is to experiment with them yourself.

Here’s a roadmap for turning this demo into a more personal learning experience:

1. 1. Start with your own data  
      The most rewarding experiment is using your own MOT notes. Have you had an MOT recently? Try adding those defect notes to see how they cluster with the sample data. You might be surprised by the patterns that emerge.

      notes = [
          "Engine oil leak",
          "Headlight not working", 
          "Nearside front tyre bald",
          "Steering pulling to the left",
          "Brake discs worn and pitted",
          # Add your own notes here...
          "Your defect notes here",
          "More of your defect notes"
      ]

      Suggestion: Try adding notes from different vehicle types (cars, vans, motorcycles) to see if the clustering adapts to different contexts.

1. 1. Play with clustering granularity 
      This is where things can get really interesting. Change the number of clusters and watch how the groupings shift:

      # Try different values: 2, 3, 4, 5, 6...
      kmeans = KMeans(n_clusters=3, random_state=42)

      This uses scikit-learn’s KMeans implementation.

      Start with 3 clusters and gradually increase. You’ll see how the algorithm balances between creating too many small groups versus too few large ones. The visualization will show you exactly how your notes are being grouped – some results might surprise you!

    

   2. Make your own queries 
      The semantic search feature is incredibly powerful. Try queries that test the model’s understanding:

      # Test the model's semantic understanding
      query = "tyre wear"           # Should find tyre-related issues
      query = "steering problem"    # Should find steering defects  
      query = "engine issue"        # Should find engine problems
      query = "safety concern"      # Should find safety-related defects

      Try abstract concepts like “safety concern” or “performance issue” to see how well the model understands context beyond literal word matching.

1. Experiment with different models (for the curious) 
   If you want to see how different embedding models perform, try swapping out MiniLM:

   # Larger, potentially more accurate model 
   model = SentenceTransformer("multi-qa-mpnet-base-dot-v1")
    
   # Or try a model specifically trained for technical text
    
   model = SentenceTransformer("all-mpnet-base-v2")

   These are SentenceTransformer models from the Hugging Face model hub.

   Compare the results – do the clusters change? Are the search results more relevant? This is a great way to understand how model choice affects performance.

 

2. Scale up and discover patterns 
   Once you’re comfortable with the basics, try working with larger datasets. The DVLA MOT dataset contains millions of records, and you’ll start to see fascinating patterns emerge:
   • Which vehicle makes have the most brake-related failures?
   • Do certain types of defects cluster by geographic region?
   • How do defect patterns change over time?

   This is where embeddings really shine – they can reveal insights that would be impossible to find with traditional keyword searches.

Each of these modifications provides immediate feedback – you can see the results directly in the notebook, making it an ideal learning environment.

Real-World Applications: CarHunch

For CarHunch, I’ve been applying this same approach to millions of MOT records. Embeddings make it possible to:

• Standardize messy defect notes into consistent categories
• Compare your car’s defects with similar vehicles
• Surface patterns across the UK fleet (e.g., which makes and models fail most often on brakes)

A Surprising ‘Discovery’: The Land Rover Defender Seatbelt issue

Sometimes, the most interesting insights come from patterns you’d never expect to find. Take my own Land Rover (original) Defender 110 as an example. When I analyzed its MOT history alongside thousands of similar vehicles, I discovered something surprising:

seatbelt damage is the number 1 most common issue for Defenders – not the engine, suspension or rust problems you’d probably expect from a rugged old off-road vehicle!

This revelation only became apparent through the kind of clustering and semantic analysis we’re exploring in this notebook. Traditional keyword searches would have missed this pattern entirely, because MOT testers describe seatbelt issues in dozens of different ways:

“Seatbelt webbing frayed”
“Driver’s seatbelt damaged”
“Seatbelt retraction mechanism faulty”
“Belt webbing showing signs of wear”

But embeddings revealed the underlying pattern: all these different descriptions clustered together as the same fundamental issue.

Even more fascinating, the analysis showed this is a design quirk specific to Defenders; the front seatbelts naturally fall right in to the door jambs as there’s nowhere else for them to go (plus the tensioners are weak/slow), so when the doors are closed they get trapped, causing accelerated wear that doesn’t occur in most other vehicles.

The Bigger Picture: How This Could Transform Automotive Design

This Defender example hints at something much larger: embeddings could impact how car manufacturers identify design flaws and improve vehicle quality. Imagine if every manufacturer had access to this kind of analysis across their entire fleet:

• Early Warning System: Spot recurring issues before they become widespread problems
• Design Validation: Verify that design changes actually solve the problems they’re meant to address
• Cost-Benefit Analysis: Quantify the real-world impact of design decisions on maintenance costs
• Competitive Intelligence: Understand how your vehicles compare to competitors in terms of reliability

Traditional quality control relies on warranty claims and customer complaints – reactive data that comes too late. But MOT data is generated continuously, providing a real-time view of how vehicles perform in the wild. The challenge has always been extracting meaningful insights from the unstructured text that testers write.

This is exactly the kind of insight that would be impossible to discover without the semantic understanding that embeddings provide. You can explore this particular analysis yourself with CarHunch’s enhanced hunches feature, which uses the same techniques demonstrated in this notebook.

This example is just a small subset of what that larger platform does, showing how embeddings can transform unstructured text data into actionable insights that reveal patterns invisible to traditional analysis methods.

From Experimentation to Production

Once you’ve experimented with the notebook and understand how embeddings work, you might be wondering: “How do I turn this into a production system?” This is where the journey from data science experimentation to operational ML begins.

In my previous post, “MLOps for DevOps Engineers – MiniLM & MLflow demo”, I showed how to take these same embedding techniques and build them into a proper MLOps pipeline. That post covers:

• Containerizing the embedding pipeline with Docker
• Tracking experiments and model versions with MLflow
• Automating the entire workflow with Makefiles
• Building quality gates and reproducibility into the process

Think of it this way: this notebook is your playground for understanding embeddings, while the MLOps post shows you how to turn that playground into a production system. The same MiniLM model that powers this interactive demo is the foundation for the automated pipeline in the MLOps example.

For DevOps engineers, this represents a natural progression: start with hands-on experimentation to understand the concepts, then apply your existing automation and infrastructure skills to make it production-ready.

Key Takeaways

For DevOps and SRE engineers curious about machine learning, embeddings represent an excellent entry point:

• No GPU required for basic experimentation
• Easy to run locally or in cloud environments
• Immediately useful for messy, real-world text data
• Natural bridge to production MLOps workflows

Give the notebook a try, experiment with your own MOT notes, and discover what insights you can uncover. When you’re ready to take it further, the MLOps post will show you how to automate and scale these techniques.

Open the demo in Google Colab

Contains public sector information licensed under the Open Government Licence v3.0.