Как узнать процент похожести текста?

Question

[DragoN DragoN]

Стоит задача такая, чтобы определять процент похожести текста который только набрали с текстом который есть в базе MySQL. Это нужно, чтобы устранить дубли. Например, кто-то создает новость о происшествии, а о нем было написано уже два дня назад другим человеком - это будет дубль. Я знаю, что можно делать перебором, но это очень долго и будет нагружать MySQL. Возможно ли это сделать каким-то запросом или чем-то сторонним, в голову приходит только Sphinx Search... Подскажите, есть ли какие-то варианты?

Answer 1

[Stalker_RED]

Частично проблема решается алгоритмом шинглов, который неплохо находит похожие тексты. Но хороший рерайтер легкло сделает текст отличающимся на 40-60% при сохранинеии смысла. А в последнее время можно вообще сделать магию: "чатгпт, перепиши этот текст другими словами добавив тоски о былом величии римской империи", и все это за считанные секунды и бесплатно.

в качестве примера перефразированный ваш вопрос

Каким образом можно определить процент схожести между текстом, который только что был написан, и текстом, который уже хранится в базе данных MySQL? Это необходимо для того, чтобы исключить повторения текстов. Например, если кто-то создает новость о происшествии, а она была опубликована два дня назад другим человеком, то это будет считаться дублем. Я знаю, что можно сравнивать тексты посредством перебора, но это займет много времени и будет нагружать MySQL. Есть ли какие-то другие методы, кроме использования Sphinx Search, чтобы достичь этой цели?

По расчетам вот этого сервиса процент схожести менее 30%

Ну и да, Rsa97 прав, чтобы избежать ложных срабатываний придется не просто сравнивать слова, а разбирать текст на смыслы, делать фактографический разбор, а это совсем не простая работа.

Answer 2

[Rsa97]

"Вчера на площади Свердлова попал под лошадь извозчика 8974 гр. О. Бендер. Пострадавший отделался легким испугом."
"Сегодня на площади Свердлова попал под лошадь извозчика 1234 гр. О. Иванов. Пострадавший отделался легким испугом."
Схожесть по словам 81% (13/16), но новости то разные.
Вам надо выделять ключевые слова - тип происшествия, даты, фамилии, адреса, номера и модели автомобилей и т.п. и сравнивать по ним.

Answer 3

[rPman]

Похожесть - перебором.

У меня в поиске заголовков статей (40к) postgres подсчет левенштейн со всеми записями был меньше секунды, а ведь он фактически перебор делает. Но задача на самом деле сложнее.

Посмотри хорошую статья с обзором алгоритмов, статья старая но взяв из нее алгоритмы будет что гуглить дальше

p.s. рандомная ссылка из гугла, в работе есть код на питоне

Answer 4

[Александр Маджугин]

Вот вам еще вариант - добавить к статьям обязательные поля (если вы пишите о событии):
Точная дата начала события
Место события (населенный пункт)
Список ФИО участников
Тип события (выбор из фиксированного списка)

Тогда вы сможете вычислять схожесть опираясь на этот классификатор и показывать редактору похожие статьи, а он уже пусть решает.

Comments

[DragoN DragoN]

Это было бы хорошо, но ценится оперативность, т.е. на заполнение этого просто не будет времени. Да и что уж говорить, будет лень это делать журналистам

[rPman]

DragoN DragoN, мысль у Александр Маджугин, собирать больше информации о статье, в машиночитаемом виде
просто дата и приблизительное место, позволит делать поиск не по всей базе а на интервале дат

я бы сюда закинул источник, собрав какой то объем статей и откидывая в ручном режиме дубликаты, сам факт этого откидывания тоже нужно сохранять (т.е. сохранять статью с пометкой - дубликат другой статьи, с указанием какой), и на основе этой информации можно принять решение о том что такой то источник плодит исключительно дубликаты и его можно не использовать

[Александр Маджугин]

DragoN DragoN, это можно сделать оперативно. Смотрите, ведь редакторы печатают слова? Ок. Вероятно они есть в тексте. Следовательно вы можете добавить шорткаты клавиатуры, которые отправляют слово левее курсора в соответствующие поля. Да, придется учится. А например даты может не быть в тексте в явном виде. Там может быть "вчера" например, но можно сделать конвертер... ну это я уже на ходу сочиняют.

В целом, как и сказал rPman, мысль в том, чтобы предоставить структуру данных о статье в машиночитаемом виде. Это как бы та же ваша задача но разбитая на два приема, первый из которых подготовка данных под контролем человека.

Answer 5

[alexalexes]

Самое простое - натравить поисковик на собственный ресурс запросом:
"site:yousite.ru фрагмент фразы".

PS: Сайт на момент запроса должен быть проиндексирован поисковиком.

Answer 6

[Максим Франко]

Реализация match() с PHP - mySQL Full Text Search With Percentage Scoring

Answer 7

[mayton2019]

Мне кажется что для обобщения надо все таки новую статью добавить в MySQL. Чтоб API проводящий сравнение хотя-бы был единообразным.

И наверное есть много способов решать эту задачу. Но она по своей природе близка к полно-текстовому поиску хотя-бы потому что слова и их комбинации могут отличаться. Могут быть переставлены местами. Могут быть с опечатками. С переносами в середине слова.

Насчет Sphinx - ничего не скажу. Не использовал. Но в классическом текстовом поиске все слова хешируются в 18-20 битные числа. Потом гистограмма. И дальше эти векторы можно быстро сравнивать. (там еще слова чистятся. удяляются предлоги. приводятся к единой форме). Это теория. Как это реализовано в MySQL - я ХЗ. В Postgres это точно есть. Один чел выше уже написал.

Answer 8

[Максим Кореев]

Тут надо социалочку подключать, публиковать статью и пусть посетители сайта за нее голосуют. Если она уходит в минуса - скрывать.
Или, как вариант, подключать апи чатгпт и делать к ней запросы с просьбой сравнить публикации, она не дорогая.