Нечеткое сопоставление структурированных данных - PullRequest
1 голос
/ 12 марта 2010

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

Записи имеют ширину около 12000 байт, а общее количество записей - около 150 000. В схеме таблицы 110 столбцов, и 95% поисковых запросов будут в верхних 5% наиболее часто используемых столбцов.

Данные такие вещи, как имена, адреса, номера телефонов и другие отраслевые номера. Как в корпусе, так и в протоколе испытаний он вводится вручную и является полуструктурированным в пределах отдельного поля. На первый взгляд вы можете сказать «взвесить столбцы вручную и сопоставить жетоны слов внутри них», но это не так просто. Я тоже так думал: если я получу номер телефона, я думаю, что это будет означать идеальное совпадение. Проблема в том, что в форме нет ни одного поля, частота токена которого не меняется на порядки. Номер телефона может появляться 100 раз в корпусе или 1 раз в корпусе. То же самое касается любой другой области. Это делает взвешивание на уровне поля нецелесообразным. Мне нужен более детальный подход для получения достойного соответствия.

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

Я бы использовал частоту в качестве веса: чем выше частота токена в эталонном корпусе, тем меньше вес, который я добавляю к этому токену, если он найден в протоколе испытаний.

Мой первый вопрос к статистикам в комнате: как бы я использовал частоту в качестве веса? Существует ли точное математическое соотношение между n, количеством записей, f (t), частотой, с которой токен t появился в корпусе, вероятностью o того, что запись является оригиналом, а не дубликатом, и вероятностью p, что тестовая запись - это действительно запись x с данным тестом и x содержат одинаковые t в одном и том же поле? Как насчет связи для нескольких совпадений токенов в нескольких полях?

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

Кроме этого, у кого-нибудь есть способ сделать это?

Я особенно заинтересован в других предложениях, которые не включают ведение другой таблицы в базе данных, таких как таблица поиска частоты токенов.

1 Ответ

0 голосов
/ 12 марта 2010

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

Более конкретно к проблеме, вот несколько мыслей и идей:

Во-первых, признавая очень искаженное использование (только от 6 до 10 атрибутов покрывают 95% использования), вы можете / должны применять асимметричное усилие к атрибутам, то есть вкладывать больше средств как во время программирования, так и в выделение ЦП во время выполнения для работы с этими несколькими атрибутами, а не со 100 с лишним дополнительных атрибутов.

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

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

  • Нормализация данных
    Если вам не разрешено изменять исходные значения полей, возможно, продублируйте соответствующие столбцы в столбце «norm_xxx», где xxx - исходное имя.
    Что, Как нормализовать, может варьироваться в зависимости от каждого атрибута; для данных, подобных «свободному тексту», убедитесь, что нет ни начальных, ни конечных пробелов, только один пробел между словами, табуляции и непечатных символов. Используйте все заглавные или строчные буквы (если исходный текст / текст для отображения может включать в себя микс, ваша обработка будет идти быстрее, если принять одинаковый регистр). В частности, для адресов и / или названий компаний вы можете преобразовать общие термины в стандартную форму (ST для STREET, ST и ST и т. Д.) (Обязательно сохраните этот список, поскольку он будет применяться и к критериям поиска пользователей). ). Частью нормализации также может быть полное удаление некоторых шумовых слов (как, например, CO, INC, GMBH в конце названий компаний)
  • Создать несколько вычисляемых столбцов
    Например, с обратным текстом для атрибутов, в которых можно искать с помощью подстановочного символа
  • Рассмотрите возможность использования Soundex-подобного преобразования для некоторых атрибутов.
  • Полный текстовый индекс, индивидуально, все текстоподобные столбцы
  • Создание простых (SQL) индексов для всех 6-10 часто используемых столбцов

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

  • Нормализуйте критерии поиска, которые оправдывают это
  • Запустить несколько поисков ...
    Это немного сложно; Есть несколько частично противоречивых целей для выполнения этого поиска. Мы хотим значительно сократить количество «потенциальных совпадений»: практически нецелесообразно проводить полное сравнение один на один всех 150 000 записей с предоставленными пользователем критериями; например, некоторая логика сопоставления может подразумевать вычисление расстояния редактирования между полем данной записи базы данных и критериями поиска. Мы также хотим убедиться, что мы не исключаем записи из списка «потенциальных совпадений» из-за опечатки в названии компании ... Наконец, мы хотим предоставить список возможных совпадений в ранжированной форме.
    Способ выполнения этих поисков следует некоторой предварительно определенной эвристике (я нашел, что шаблон проектирования стратегии хорошо работает для этого, обеспечивая гибкость в способе поиска, в зависимости от введенных пользователем данных). Короче говоря, мы ищем самые селективные слова в наиболее селективных / релевантных атрибутах, и на основе количества найденных «обращений» мы либо «ИЛИ» (объединение), либо «И» с другими результатами поиска, пока у нас не получится несколько сто рекорд.
  • Вычислить значение сходства между каждым атрибутом записей «потенциальных совпадений» и соответствующими критериями поиска. Возможно применить коэффициент к этому значению (позволяя придать больший вес, чтобы сказать, что название компании [частичное] совпадает с названием города)
  • Подсчет общего значения сходства для полной записи (в сравнении с критериями полного поиска)
  • Показать записи, превышающие определенный порог значения сходства с конечным пользователем, для просмотра

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...