ReviewRadar AI: Ensemble Sentiment That Actually Moves the Metric
An end-to-end Yelp review intelligence pipeline — from PostgreSQL ETL and VADER features to an enhanced sentiment ensemble that lifts accuracy from ~0.84 to 0.91 on published evaluation artefacts.
Reviews are a warehouse problem first
Sentiment models get the attention; the unglamorous work that makes them usable is getting millions of review rows into a queryable warehouse with honest features. ReviewRadar AI is built around the Yelp Open Dataset: load raw JSON into PostgreSQL, map categories and geo, run EDA, then materialise review-, user-, and business-level feature tables.
Only after that pipeline exists does training a classifier make sense. Skipping the warehouse step produces notebooks that cannot be re-run when the next dump arrives.
Feature construction that models can use
The feature stage combines lexical sentiment (VADER), TF-IDF terms, time features, geo clusters, rolling user rating averages, and one-hot category signals. That mix matters: a pure bag-of-words model misses reviewer habits; a pure rating model misses what the text actually said.
Persisting a StandardScaler artefact alongside the feature tables keeps training and inference on the same numeric footing — a small detail that prevents silent train/serve skew.
If your sentiment model cannot be retrained from a clean checkout of the warehouse scripts, you do not have a pipeline — you have a souvenir notebook.
What the published metrics actually say
The evaluation artefact at evaluation_results/model_metrics.json compares three trained pipelines on the same evaluation surface. The v3.4 and v3.5 pipelines land near 0.84 accuracy and 0.88 F1. The enhanced ensemble v4 jumps to 0.9106 accuracy, 0.9341 F1, and 0.9687 ROC-AUC.
That gap is the entire justification for the ensemble work. Incremental tweaks between v3.4 and v3.5 barely move the needle; the ensemble architecture is where the lift lives.
Published sentiment metrics by pipeline
v3.4 and v3.5 are nearly identical. The ensemble is a different regime — roughly seven points of accuracy and five points of F1 over the prior pipelines.
Source — Thanuka9/reviewradar_ai evaluation_results/model_metrics.json
Full metric table from model_metrics.json
| Model | Accuracy | Precision | Recall | F1 | ROC-AUC |
|---|---|---|---|---|---|
| sentiment_pipeline_v3.4 | 0.8416 | 0.8653 | 0.9044 | 0.8844 | 0.8886 |
| sentiment_pipeline_v3.5 | 0.8413 | 0.8652 | 0.9040 | 0.8842 | 0.8883 |
| enhanced_sentiment_ensemble_v4 | 0.9106 | 0.9235 | 0.9449 | 0.9341 | 0.9687 |
Why ensembles beat another single-model tweak
v3.4 to v3.5 shows what happens when you keep iterating inside one modelling frame: metrics stall. Ensembles help when different inductive biases disagree on hard reviews — short sarcasm, mixed sentiment, or sparse text — and a vote or stacked meta-learner can recover cases any single model systematically misses.
The ROC-AUC jump to 0.9687 is especially useful for product ranking and triage: even when a hard threshold is tuned later, the ordering quality of positive vs negative intent is already strong.
"If two successive pipelines produce the same F1, stop polishing hyperparameters and change the hypothesis."
What I would ship next
The public README already points at the natural extensions: topic models over the feature store, a Streamlit dashboard on the warehouse, and grounded summarisation over retrieved reviews rather than free-form generation.
The metric story is already strong enough to support those layers. The constraint is productisation — making the warehouse refresh and the ensemble inference a single operable path — not inventing another model family.