Building a Multi-Tier Review Classifier

Taken from: https://developers.tiktok.com/blog/tiktok-techjam-2025-highlights

Preface

This project was part of TikTok’s TechJam Hackathon 2025, where our team placed 5th out of 300 teams. The hackathon featured seven problem statements, and over 40% of teams chose the same problem statement as us.

While many teams at TikTok TechJam 2025 relied on heavy, complex models to tackle the problem, our solution took a simpler approach. We intentionally focused on basic, well-understood models like TF‑IDF + Logistic Regression and FastText. What set our team apart was not the complexity of the models themselves, but the thoughtful design choices that guided how we applied them.

In this article, we aim to highlight those design decisions — the staged pipeline, uncertainty thresholds, and efficiency-driven architecture.

Introduction

Problem Statement & Dataset

ML for Trustworthy Location Reviews — Leverage Machine Learning and Natural Language Processing to automatically assess the quality and relevancy of online location reviews

The dataset provided consisted of millions of unlabeled Google reviews. These reviews could be labeled as spam, unsafe, advertisements, irrelevant or accepted.

Initial Findings and Design Choices

As we began exploring the dataset, a few key observations immediately shaped our approach. First, the majority of reviews were benign, meaning most content did not require heavy analysis. Second, reviews were generally short in length, often just a few sentences, which meant that simple models could capture most of the important signals. Finally, the sheer volume of data — millions of unlabelled Google reviews — made it clear that running a heavy model on every review would be computationally infeasible.

These initial findings led us to define the core requirements for our pipeline:

1. Speed: The solution has to be fast enough to handle millions of data points.

2. Accuracy: Since reviews are important for businesses, the pipeline must maintain good accuracy.

These core requirements then led to our solution: use lightweight models to filter the easy cases, and reserve heavier models for difficult or ambiguous reviews. This approach allows us to process massive volumes of data efficiently while maintaining high accuracy for toxic content detection.

Pipeline Design Overview

Taken from: https://github.com/frznprograms/ARC

The pipeline consists of three stages:

1. Lightweight detection using classical machine learning -> tf-idf + logistic regression
2. Intermediate semantic understanding using embeddings -> fastText
3. Heavy encoder models for edge cases -> BERT model

By structuring the pipeline this way, we reduce unnecessary computation, handle class imbalance, and ensure that only the most uncertain cases consume heavier resources.

Stage 1: Safety Filtering

The first stage of our pipeline uses TF‑IDF features combined with Logistic Regression, trained on the **ToxicGen dataset**, using the Scikit learn library. This stage was to remove reviews that were unsafe.

Why use the ToxicGen dataset?

Most of the reviews were safe which made the dataset highly imbalanced ~ 99% of the dataset was appropriate. As a way to rebalance the dataset, it was necessary to use another dataset for the opposite label.

Examples from the ToxicGen dataset:

“african-american people spend their time fine-tuning the science of being a brutish thug”

Why TF-IDF + logistic regression?

• TF‑IDF converts text into a sparse numeric vector, where each feature corresponds to a word or bigram, weighted by its importance in the document relative to the corpus. Rare but significant words are emphasized, while common words like “the” or “and” are down-weighted.
• Logistic Regression is a simple linear classifier that predicts the probability of a review being toxic. It is fast, interpretable, and effective for short text.
• The time complexity during inference for a logistic classifier is linear, which meets our efficiency requirements for our pipeline.

If the prediction probabilities by the classifier is below a threshold (0.3), we reject the data point and classify it as unsafe. The rest of the pipeline will not be run for this data point. This would have been a quick way to filter out unsafe data.

However, most of the data is safe and will proceed to the next stage.

Stage 2: Intermediate Detection with FastText

Reviews that fall into an uncertain prediction range in the first stage are escalated to the second stage, which uses FastText, a Word2Vec-inspired embedding model.

Why use FastText?

• FastText builds upon the Word2Vec model, but segments each word into subwords, allowing it to capture more nuances.
• It strikes a balance between speed and accuracy, being faster than a full transformer but more nuanced than TF‑IDF.

This intermediate step ensures that ambiguous reviews are properly classified without immediately resorting to computationally heavy encoders.

Stage 3: Final Detection with DistilBERT

The final stage of ARC is designed for the hardest cases: reviews that are not clearly acceptable, but not clearly rejectable either.

For this layer, we used a LoRA-tuned DistilBERT encoder. Unlike earlier stages that rely on lightweight lexical or statistical signals, the transformer is able to interpret the review more holistically. It looks at how words relate to one another in context, which makes it better suited for detecting nuanced moderation categories.

This matters because many problematic reviews are subtle. A review can be emotionally charged without being toxic, promotional without using obvious advertising phrases, or negative without actually describing a real customer experience. These are cases where keyword-driven systems often struggle.

DistilBERT gave us a strong middle ground between performance and efficiency. It retains much of the contextual reasoning ability of larger transformer models, while remaining lightweight enough to fit a staged moderation pipeline. We further adapted it with LoRA fine-tuning, which allowed us to specialize the model for review classification without the overhead of full-parameter retraining.

Results

Architecturally, the pipeline is designed so that most reviews should never reach Stage 3. Most of the reviews should be classified by stage 2. This is validated by the results where only ~30% of reviews reach the last transformer stage.

This propagation pattern is important for both technical and product reasons:

1. Lower average latency: most reviews finish before the transformer
2. Lower inference cost: expensive semantic analysis is reserved for hard cases
3. Better throughput: more reviews can be processed with the same infrastructure
4. Clearer system behavior: each stage has a narrow job and a more interpretable failure mode

In other words, the pipeline is not just trying to classify reviews accurately. It is trying to do so with efficient routing.

Why did ARC work?

What made ARC work — and what helped it stand out against heavier LLM-based solutions — was that we designed it around the AI inference iron triangle of speed, cost, and accuracy.

Iron Triangle for ML, generated by ChatGPT

In moderation systems, pushing too hard on any one of those dimensions usually creates pressure on the other two: a large model can improve quality on nuanced edge cases, but often at the expense of latency and compute, while lightweight models are fast and cheap but can miss subtle semantic signals. ARC addressed that tradeoff directly through a staged architecture. Instead of treating every review as equally complex, we used lightweight filters for obvious cases and reserved the transformer layer for the smaller set of ambiguous reviews that actually required deeper language understanding. That gave us a system that was not only technically effective, but also operationally credible — responsive enough for a live product experience, efficient enough to scale more realistically, and accurate enough where nuance mattered most.

In the end, ARC was compelling not because it used the biggest model, but because it used the right level of intelligence at the right point in the pipeline.

Conclusion

More than anything, this hackathon reminded us that building good AI systems is not just about maximizing model performance in isolation. In school, it is easy to focus on benchmarks, accuracy scores, or the sophistication of a model, while overlooking the practical constraints that matter in real products — cost, latency, scalability, and user experience. This hackathon pushed us to think more like engineers building for industry, where the best solution is rarely the heaviest or most impressive on paper, but the one that balances performance with operational constraints in a way that can actually be deployed.

Disclaimer

All opinions and interpretations are that of the writer, and not of MITB. I declare that I have full rights to use the contents published here, and nothing is plagiarized. I declare that this article is written by me and not with any generative AI tool such as ChatGPT. I declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of my knowledge. I agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.