Концепция нечеткого поиска в базе данных

13

Я думал об этом и пытался найти решения о том, как нечеткий поиск в базе данных, если, например, пользователь вводит орфографическую ошибку. Есть какие-то явные проблемы с логикой этого? Будет ли это работать и было ли это сделано раньше?

Наш стол мы хотим найти:

**tblArticles**
Body - Soundex_Body - CharacterCoded_Body

Поэтому мы храним необработанное текстовое тело для физического отображения. Другие 2 столбца используются для поиска, который рассчитывается следующим образом:

Саундэкс

Тело разделено на слова и переведено в версию soundex. IE, получающееся тело могло бы быть чем-то вроде:

H252 B54 C23 E33... etc

Таким образом, кто-то может войти в «динозавр», а текст статьи гласит «динозавр», оба они оценивают как B26. Затем мы запускаем LIKE для значения soundex поискового термина.

Кодировка персонажа

Учитывая отображение символов, которое отображает символы в простые числа, IE:

h = 2
e = 3
l = 5
o = 7
p = 11
c = 13

help = 2*3*5*11     =   330
hello = 2*3*5*5*7   =   1050
hell = 2*3*5*5      =   150
hlep = 2*5*3*11     =   330
cello = 13*3*5*5*7  =   6825

Если пользователь хотел напечатать «привет», но он переключил два или более символов, например, «hlelo», он оценил бы одно и то же число. Разделите необработанное тело на слова, просто закодируйте каждое слово и сохраните в базе данных, получив поле, которое выглядит следующим образом:

330 6825 330 1050... etc

Затем мы можем подобрать поиск по этому значению, чтобы он соответствовал опечаткам.

Преимущества

Опечатки защищены от
Фонетическое неверное написание защищено от
Больше не родной английский говорящий дружелюбный
Будет работать на любом языке (где работает soundex)

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

algorithms concepts search

— Том
источник

Было бы интересно увидеть, как это сравнивается с Trigram Search.

— Рич

Я хотел бы иметь что-то вроде этого для WordPress ...

— Кит Менке

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

— Glenatron

1

@Glen Afaik умножая простые числа всегда генерирует уникальное число. Однако анаграммы будут сталкиваться, но я не знаю, какая это большая проблема, в этом и заключается смысл быстрого поиска анаграмм.

— Том

@Glen: см. Теорему об уникальной факторизации для уникальности.

— Стивен Эверс

2

Есть ряд других алгоритмов поиска. Смит-Уотерман - один из лучших для человеческого текста, в то время как BLAST (пока) - лучший для поиска последовательностей ДНК. Когда вам представлен текст с различными орфографическими ошибками, такими как hlepвместо help, то вы ищете минимальное расстояние редактирования .

Для библиотеки для реализации ряда этих функций в CLR в SQL Server 2005 (и более поздних версиях) посмотрите исходный проект forge подделки SimMetrics . Сообщение в блоге о SimMetrics .
http://staffwww.dcs.shef.ac.uk/people/S.Chapman/simmetrics.html

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

— Tangurena
источник

2

Apache Solr, поддерживает синонимы и исправления орфографии - хотя это все еще немного грубо по краям.

Нечеткие поиски могут быть реализованы с помощью Ngrams,

Портер Стеммер: http://tartarus.org/~martin/PorterStemmer/

и языковая база данных, такая как http://wordnet.princeton.edu/

... но такие проекты, как Xapian и Solr, справятся с этим.

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

— Бен ДеМотт
источник

1

Некоторое время назад я делал что-то подобное для адресов, которые проверяли бы, сколько изменений потребуется, чтобы преобразовать одну строку в другую, и возвращали числовое значение в диапазоне от 0 до 1, чтобы определить, насколько близко они совпадают.

Это сработало замечательно, поскольку возвращало большое значение для таких элементов, как N / North, St / Street, EastMain / MainEast и т. Д. Идея пришла из этой ссылки CodeProject.

— Рейчел
источник

Является ли код, который вы написали для сопоставления адресов с открытым исходным кодом?

— Thismatters

@ Thismatters У меня нет доступа к коду, но ссылка в моем ответе должна предоставить логику для этого. По сути, вы просто хотите увидеть, сколько изменений потребуется, чтобы превратить одну строку в другую, и чем меньше изменений, тем ближе они будут

— Рэйчел

0

Если вы сопоставляете имена, людей или места, список синонимов может работать намного лучше.

Soundex не будет соответствовать "Дик == Ричард", "Кит == Кристофер" или "Мисс. == Миссис".

— Мартин Беккет
источник