Почему пакет textreuse в R делает корзины LSH намного больше, чем исходные минхэши?

Насколько я понимаю, одной из основных функций метода LSH является сокращение данных даже за пределами базовых хэшей (часто минхэшей). Я использую пакет textreuse в R, и меня удивляет размер генерируемых им данных. textreuse — это проверенный экспертами пакет ROpenSci, поэтому я предполагаю, что он выполняет свою работу правильно, но мой вопрос остается.

Допустим, я использую 256 перестановок и 64 канала для функций minhash и LSH соответственно — реалистичные значения, которые часто используются для обнаружения с относительной достоверностью (~98%) сходства до 50%.

Если я хеширую случайный текстовый файл, используя TextReuseTextDocument (256 разрешений), и назначаю его trtd, у меня будет:

object.size(trtd$minhashes)
> 1072 bytes

Теперь давайте создадим LSH-бакеты для этого объекта (64 бэнда) и назначим его на l, у меня будет:

object.size(l$buckets)
> 6704 bytes

Таким образом, сохраненные хэши в корзинах LSH в шесть раз больше, чем исходные минхэши. Насколько я понимаю, это происходит потому, что textreuse использует дайджест md5 для создания хэшей ведра.

Но не слишком ли это расточительно/излишне, и нельзя ли это улучшить? Нормально ли, что наша техника сокращения данных раздувается до такой степени? И не эффективнее ли сопоставлять документы на основе исходных хэшей (аналогично perms = 256 и bands = 256), а затем использовать порог для отсеивания ложных срабатываний?

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


person retrography    schedule 15.08.2020    source источник


Ответы (1)


Автор пакета здесь. Да, было бы расточительно использовать больше хэшей/бэндов, чем вам нужно. (Хотя имейте в виду, что здесь речь идет о килобайтах, которые могут быть намного меньше, чем исходные документы.)

Вопрос в том, что вам нужно? Если вам нужно найти только совпадения, близкие к идентичным (т. е. с оценкой Жаккара, близкой к 1,0), вам не нужен особо чувствительный поиск. Однако, если вам необходимо надежно обнаруживать потенциальные совпадения, которые имеют лишь частичное перекрытие (т. е. с показателем Жаккара, близким к 0), вам потребуется больше хэшей/полос.

Поскольку вы читали MMD, вы можете посмотреть уравнение там. Но в пакете есть две функции, задокументированы здесь, которые могут вам помочь подсчитайте, сколько хэшей/бэндов вам нужно. lsh_threshold() рассчитает пороговую оценку Жаккара, которая будет обнаружена; в то время как lsh_probability() сообщит вам, насколько вероятно, что будет обнаружена пара документов с заданной оценкой Жаккара. Поэкспериментируйте с этими двумя функциями, пока не получите количество хэшей/полос, оптимальное для вашей задачи поиска.

person Lincoln Mullen    schedule 16.08.2020
comment
Приятно познакомиться, Линкольн! Я хорошо настроен на эти функции. Я имею в виду: почему 64 полосы занимают гораздо больше места, чем исходные 256 хэшей? Это одна полоса на каждые 4 минхэша, и все равно занимает в 6 раз больше места. Я думал, что мы использовали бэндинг как средство сокращения данных. Почему бы тогда не использовать исходные минхэши (а не полосы md5-хеширования) для целей сопоставления, когда требуется высокая точность при низких уровнях сходства? - person retrography; 17.08.2020
comment
Потому что полосы — это строки, а минхэши — целые числа. Мы не используем бэндинг как средство сокращения данных; мы делаем это для выявления потенциальных совпадений. В качестве детали реализации я решил сделать это, дополнительно хэшируя минхэши в полосах, чтобы упростить сравнение. Возможно, есть другой способ сделать реализацию, которая была бы более эффективной с точки зрения пространства. На практике я обнаружил, что размер текста намного больше, чем любой из производных объектов, созданных этим пакетом. - person Lincoln Mullen; 17.08.2020
comment
Это дополнительное криптографическое хеширование — именно то, к чему относится мой вопрос — деталь реализации, которую я не уверен, как еще можно решить. Я рассмотрю другие реализации, чтобы увидеть, что они сделали. Например, мне интересно, не приведет ли простое использование минхэшей в качестве индекса (размер полосы 1) к нежелательным коллизиям ключей помимо ожидаемых ложных срабатываний. И точно, я согласен, что хэшей часто меньше, чем текста. Но при 6 КБ на корзину у вас довольно быстро заканчивается память всего с несколькими миллионами документов. - person retrography; 17.08.2020
comment
Пакет в целом может быть переработан. Он в основном предназначен для корпусов памяти, и он был записан обратно с объектами из пакета tm, которые были стандартом де-факто для интеллектуального анализа текста в R. Я хотел бы переписать его так, чтобы он с самого начала использовал подход tidyverse, и поэтому что он может использовать базу данных или другой бэкенд для обработки данных произвольного размера. Я, вероятно, не смогу справиться с этим, пока мне не понадобится самому использовать пакет для чего-то интенсивного. Но вы можете открыть проблему на GitHub, обсудить ее и внести запрос на извлечение. - person Lincoln Mullen; 17.08.2020