ReviewScope Uses Embeddings and Graphs to Find Anomalies in 21,000 Reviews

One strange phrase in a bakery review turned into a full-fledged tool. The author of a Habr post, choosing a bakery after moving, saw a review on Yandex Maps that began with the words "here's a good option for a reply" («да вот хороший вариант ответа»). That is what text usually looks like when it is copied from a language-model chat together with a stray line of the bot's own. Instead of simply going to another bakery, he wrote ReviewScope: a system that looks for anomalies, repeated texts and unusual patterns in reviews. He tested it on 21 thousand real reviews.

What we know about ReviewScope

The announcement on Habr lists three pillars of the project: embeddings, match graphs and a weighted rating. The full write-up, quality metrics and results on the sample are hidden behind a cut, so we have no figures for accuracy or for the share of suspicious reviews. We won't guess at them.

• Goal: find anomalies, duplicates and atypical patterns in reviews
• Inspiration: a Yandex Maps review with a generation artifact
• Methods: text embeddings, match graphs, weighted rating
• Test sample: about 21,000 real reviews
• The author also promises to cover the errors he had to fix

Why use a graph for reviews

The logic of this combination is clear even without the details. Embeddings turn text into a vector, so reviews that are close in meaning end up next to each other, even if the words are reordered or swapped for synonyms. That gives them an edge over exact-match search: a review farmer can easily change a couple of words, but the semantic fingerprint stays.

The graph handles the next problem. If you treat reviews as nodes and strong similarity as edges, a coordinated campaign shows up as a dense cluster. A single boilerplate text proves almost nothing, but ten linked reviews of one business are already a reason to take a closer look. A weighted rating, judging by the name, should reduce the contribution of such reviews to the final score. How exactly the author calculates the weights is not clear from the announcement.

Where such systems break

The approach has weak spots, and the author, judging by the errors he says he fixed, ran into them. Short reviews like "Tasty, recommend" match each other quite honestly, and a naive similarity threshold will flag them as suspicious. Chain businesses produce uniform wording. Seasonal promotions cause spikes in reviews that look like manipulation but are not. Any such system needs at least part of the sample labeled by hand, otherwise it is unclear what counts as a false positive.

There is also an ethical angle. A review containing a language-model phrase is not necessarily fake: a person may have asked a chatbot to edit a real experience. An anomaly in the text says something about how it was written, not about whether the review is truthful.

What you can take from the project

For teams that work with user-generated content, the example is useful as a template. Embeddings and a similarity graph can be assembled from standard components over a weekend, and the value comes at the stage of calibrating thresholds and analyzing false positives. If you are building review moderation, start with a sample of several thousand records and manual review of disputed clusters. Evaluate groups of linked reviews rather than individual texts. It is better to lower a review's weight than to zero it out: that is reversible and reduces the cost of a mistake.

When the author publishes the full text with results, check how he measured quality and what share of the detected anomalies he confirmed manually. Without those numbers, ReviewScope remains a convincing demonstration of an idea, not a verified tool.