Artificial intelligence has many branches, but in real projects the most important question is simple: what tool solves the problem with the least complexity and the highest reliability.
This article walks through that question using my GitHub project, Vancouver Traffic Accident Risk Predictor, as a real example. Along the way, it explains when to use machine learning (ML) instead of large language models, how an ML pipeline works, what MLOps means, and how a model becomes a production ready service.
The Modern Habit of Using LLMs for Everything
There is a new pattern in the industry. Whenever a team faces a data problem, someone eventually says, “Why not just use an LLM for this?”
It sounds modern. It sounds powerful. It feels like a universal solution.
But this instinct hides a deeper issue.
LLMs are not designed for structured data prediction.
They can reason across messy text, generate explanations, and handle unstructured inputs. They are excellent at language. But when the task is numerical, statistical, or based on clean tabular data, an LLM behaves like a very smart person guessing instead of a model trained precisely for the job.
This is where the Vancouver project becomes a perfect example.
The goal is to predict accident risk based on weather and traffic conditions.
This is not a language problem.
This is a structured prediction problem.
This is exactly where classical ML shines.
Why Business Users Often Think LLMs Can Solve Everything
This misconception is extremely common, and it is not the fault of business users.
It comes from the experience of interacting with LLMs, not from their underlying capabilities.
LLMs feel magical
A business user types a question.
Claude answers instantly.
It sounds smart.
It sounds confident.
It sounds like it understands the business context.
From their perspective, this feels like general intelligence.
So the natural conclusion becomes:
“If it can talk about anything, it can probably do anything.”
Industry messaging reinforces the illusion
Marketing language often says things like:
- “Analyze your data with AI”
- “AI that understands your business”
- “AI that learns from your documents”
Business users interpret this literally.
They imagine the LLM training on their data.
In reality, the LLM is only summarizing or sampling it.
LLMs hide complexity
A classical ML pipeline exposes its steps:
- Data cleaning
- Feature engineering
- Model training
- Evaluation
- Deployment
LLMs hide all of this behind a single prompt.
So business users assume the complexity is gone.
But the complexity is still there — just invisible.
The professional explanation
The most effective way to explain this to business stakeholders is simple:
“Claude is excellent at understanding and generating language.
But price prediction, risk scoring, and forecasting are mathematical problems, not language problems.”
This keeps the conversation respectful, clear, and aligned with business outcomes.
The Reality Check: Is “LLM Everything” Acceptable in Terms of Results and Costs
The short answer is no.
But the reasons matter.
The results problem
LLMs can approximate patterns in structured data, but they cannot match the precision of a model trained directly on the dataset.
Classical ML consistently delivers:
- Higher accuracy
- Better calibration
- More stable predictions
- Clearer evaluation metrics
LLMs, by contrast, introduce variability and guesswork.
The cost problem
Even small LLMs are expensive compared to classical ML.
They require more compute, more memory, and often GPU acceleration.
A simple logistic regression or random forest runs on a tiny CPU with millisecond latency and almost zero cost.
An LLM introduces unnecessary overhead.
The engineering problem
LLMs are harder to test, harder to monitor, and harder to guarantee deterministic behavior.
For structured prediction, this is unnecessary complexity.
So is “LLM everything” acceptable?
Only if you do not care about accuracy, cost, latency, interpretability, or operational simplicity.
Real projects always care about these things.
Comparison of ML vs LLM for Structured Prediction
| Dimension | Classical Machine Learning | Large Language Models |
|---|---|---|
| Accuracy on structured data | High accuracy with stable, well calibrated predictions | Lower accuracy, pattern guessing rather than statistical learning |
| Latency | Milliseconds on CPU | Tens to hundreds of milliseconds, often requires GPU |
| Cost per prediction | Extremely low | Significantly higher, especially at scale |
| Scalability | Scales cheaply on commodity hardware | Scaling requires more compute and higher operational cost |
| Interpretability | Clear metrics, feature importance, reproducible behavior | Hard to interpret, non deterministic, difficult to validate |
| Operational complexity | Simple to test, monitor, and deploy | Harder to test, monitor, and guarantee consistent outputs |
| Best suited for | Risk scoring, forecasting, classification, anomaly detection | Text reasoning, summarization, multi modal understanding |
| Overall fit for structured prediction | Excellent | Acceptable only with compromises in cost and accuracy |
Real World Comparison
Scikit Learn ML vs Claude 4.7 LLM for a 10 GB Price Prediction Dataset
In real enterprise environments, teams often ask whether an LLM can replace a classical ML model for large scale prediction tasks.
So let us take a concrete scenario:
A 10 GB Excel dataset for price prediction.
Which tool performs better?
A well defined scikit learn pipeline wins every time.
Claude 4.7 is slower, less accurate, and dramatically more expensive.
Why ML Wins
When the task is structured prediction on a large dataset, classical ML does not just win — it wins decisively. And the reasons become even clearer when you look at the actual tools used in real projects.
ML can train on the full dataset
A scikit learn pipeline can load and process the entire 10 GB dataset using the Python data stack that enterprises rely on every day:
-
pandas for ingestion and cleaning
-
pandas.read_csvto load large files in chunks -
DataFrame.mergeto join datasets -
DataFrame.fillnato handle missing values
-
- numpy for vectorized numerical operations
-
scikit learn for modeling
RandomForestRegressorGradientBoostingRegressortrain_test_splitPipelineStandardScaler
These libraries are built for structured data at scale.
They learn real statistical relationships instead of guessing patterns.
ML produces stable, reproducible predictions
With scikit learn, you can:
- Set
random_statefor deterministic behavior - Evaluate models with
cross_val_score - Inspect feature importance
- Tune hyperparameters with
GridSearchCVorRandomizedSearchCV
This gives you a model that behaves the same way every time.
ML runs cheaply and efficiently
A trained scikit learn model:
- Runs on CPU
- Responds in milliseconds
- Costs almost nothing per prediction
- Scales horizontally with minimal infrastructure
This is why ML is used in production systems where cost and latency matter.
ML integrates cleanly into production
With Python’s ecosystem, you can deploy the model using:
- FastAPI for serving predictions
- Docker for packaging the environment
This gives you a clean, maintainable architecture that fits naturally into modern DevOps and MLOps workflows.
Why Claude 4.7 Loses
Claude 4.7 is powerful, but it is not built for this category of problem.
It cannot train on 10 GB of structured data
Claude can only sample or summarize chunks of the dataset.
It cannot compute gradients, optimize a loss function, or learn the full distribution.
It guesses patterns instead of learning them
LLMs are language models, not regression engines.
They infer trends from text, not from numerical relationships.
It is slower and more expensive
- Higher latency
- Higher compute cost
- Requires chunking and repeated calls
- Cannot be cached effectively
It introduces non deterministic behavior
Even with the same prompt, outputs can vary.
This is unacceptable for financial, operational, or regulatory workloads.
When Claude 4.7 Is Still Useful
LLMs are excellent assistants for:
- Exploratory analysis
- Explaining trends
- Suggesting features
- Cleaning messy text columns
- Generating documentation
But not for the core predictive model.
For large structured datasets and numerical prediction tasks:
Use ML for the model.
Use LLMs for support.
This is the architecture that delivers accuracy, cost efficiency, and operational stability.
Machine Learning as Part of AI
Machine learning is one of the foundational pillars of AI. It learns patterns from structured data and uses those patterns to make predictions.
When ML is the right tool
Use ML when the problem involves:
- Numerical prediction
- Classification on structured data
- Statistical relationships
- Low latency inference
- Clear evaluation metrics
- Reproducible behavior
When LLMs are the right tool
Use LLMs when the problem involves:
- Understanding or generating text
- Summarizing documents
- Reasoning across unstructured information
- Conversational interfaces
- Multi modal inputs
A simple rule of thumb:
- If the question is “Given these numbers, what is the probability of X?” , use ML.
- If the question is “Given this text, what does it mean?” , use an LLM.
What an ML Pipeline Really Is
An ML pipeline is the journey from raw data to a working model.
It is not a single script. It is a repeatable, structured process.
A complete ML pipeline includes:
- Data ingestion
- Data cleaning and preparation
- Exploratory data analysis
- Feature engineering
- Model training and evaluation
- Model packaging
- Deployment and monitoring
This pipeline ensures that the work is reproducible, traceable, and ready for automation.
What MLOps Means
MLOps is the operational discipline that keeps machine learning systems healthy in production.
It brings together DevOps, data engineering, and model lifecycle management.
MLOps focuses on:
- Versioning of data, code, and models
- Automated training and retraining
- Continuous integration and delivery
- Monitoring model drift and performance
- Scalable deployment patterns
If ML is the engine, MLOps is the system that keeps the engine running safely at scale.
Example: The Vancouver Traffic Accident Risk Predictor
This project analyzes weather and traffic accident data in Vancouver and builds a predictive model to estimate accident risk under different conditions.
It follows a complete ML pipeline from exploration to deployment.
Introduction to Weather and Traffic Accident Analysis in Vancouver
The project begins with a simple question:
How does weather influence accident risk in the city?
Data Sources and Analytical Tools
The project uses:
- Traffic accident records: Traffic accident data is sourced from the City of Vancouver’s Strategic Plan Dashboard for reliability and accuracy. The dashboard provides detailed and regularly updated records essential for comprehensive traffic analysis.
- Historical weather data: Weatherstats.ca aggregates data from Environment and Climate Change Canada for accurate meteorological information. The data encompasses a wide range of weather variables ensuring thorough climate analysis.
Tools include Python, Pandas, Matplotlib, Boken, Scikit Learn, FastAPI, and Docker.
Data Cleaning and Preparation
This stage merges datasets, handles missing values, and prepares the final analytical table.
Exploratory Data Analysis
EDA reveals patterns such as:
- Higher accident frequency during snow
- Seasonal variations
- Time of day risk levels
Visualizing Key Trends
Charts help identify correlations and guide feature selection.
Predictive Modeling
The dataset is split into training and testing sets.
Models such as random forest are trained to predict accident risk.
Evaluation metrics confirm generalization.
Accuracy Metric: Accuracy measures the overall correctness of the predictive model by comparing true results to total predictions.
Precision Metric: Precision indicates how many of the positive predictions made by the model are actually correct.
Recall Metric: Recall assesses the model’s ability to identify all relevant positive cases in the dataset.
To increase the accuracy of Our ML module, we can tune the hyperparameters:
Insights and Conclusions
The analysis shows how weather patterns influence accident probability and demonstrates the value of structured ML for public safety insights.
5. Productionalization and Deployment
A model becomes valuable only when it can be used by real applications.
FastAPI Model Server
The trained model is wrapped in a FastAPI application that exposes a prediction endpoint.
An in memory prediction cache provides low latency responses.
Dockerized Environment
The entire environment is packaged in Docker, ensuring:
- Consistent runtime
- Easy local testing
- Seamless deployment to any container platform
This closes the loop from exploration to production.
Why This Matters to Your Business
Every organization today is under pressure to adopt AI, but the real advantage comes from choosing the right tool for the right problem.
This article highlights a simple but often overlooked truth:
Not every AI problem needs an LLM. Many business problems are solved faster, cheaper, and more reliably with classical ML.
For business leaders, this means:
- Lower operational cost
- Faster time to value
- More predictable performance
- Easier compliance and governance
- Clearer ROI
The Vancouver project is not just a technical exercise. It is a demonstration of how disciplined ML engineering can deliver practical, measurable outcomes without unnecessary complexity.
Conclusion
Machine learning is not a relic from the pre LLM era.
It is a precise, efficient, and reliable discipline that solves structured prediction problems better than anything else.
The Vancouver Traffic Accident Risk Predictor demonstrates how ML pipelines, MLOps practices, and lightweight deployment patterns come together in a real project.
If your team is exploring AI adoption, modernizing analytics, or evaluating where ML and LLMs fit into your roadmap, I am always open to meaningful conversations.
Whether you are building your first predictive model or scaling AI across the organization, the right architecture and the right tool choice make all the difference. Feel free to connect.
About the Author
Jonathan Wong is an IT and AI consultant with 20+ years of experience leading engineering teams across Vancouver and Hong Kong. He specializes in modernizing legacy platforms, cloud security, and building AI-ready systems for startups and large enterprises while advising leadership on using strategic technology to drive business growth.
Connect with me on LinkedIn
The post From Machine Learning to Production: A Practical Walkthrough Using My Vancouver Traffic Accident Risk Predictor appeared first on Behind the Build.
Top comments (0)