Comments 12
Очень интересный подход, с поиском нечетких дубликатов впервые столкнулся в 1997-м ещё. Тоже пробовалось вычислять некое "расстояние", но к сожалению смысловая нагрузка слова может быть далекой от его буквенной похожести: "река" - "рука". Всего одна буква, а какой разный смысл! Самая первая задача поиска аналогов - прайс-листы поставщиков товаров, особенно в ситуациях нескольких дублирующих поставщиков. Вот тогда и столкнулся: перефразировка наименования, с целью "отстроиться от конкурента".
Насчет "векторизации", да тоже была идея применять к словам преобразование Фурье или вельветные преобразования, но не помню чтобы "зашло"..
мы обычно явно отделяем неточный поиск от семантического поиска. На удивление, много задач именно неточный поиск требуют. например, данные вводились с клавиатуры разными людьми, надо найти опечатки, ошибки. Обычно строчки состоят из 2-5 слов, т.е. ngram довольно хорошо позволяют найти то, что нужно
если возникает семантика, тогда применяем нейросети, тоже перевод в вектора. классика на русском языке - intfloat/multilingual-e5-large. Иногда с дообучением. Иногда кросс-энкодерный подход, вместо би-энкодерного.
а вообще тема поиска близких объектов действительно обширная и глубокая)
мы обычно явно отделяем неточный поиск от семантического поиска. На удивление, много задач именно неточный поиск требуют. например, данные вводились с клавиатуры разными людьми, надо найти опечатки, ошибки. Обычно строчки состоят из 2-5 слов, т.е. ngram довольно хорошо позволяют найти то, что нужно
Это слабо интересная задача, т.к. опечатка, как нравило это соседняя кнопка на клавиатуре - их 7шт примерно. Или чужой регистр, что тоже исправимо на лету и уже давным давно. Или пропускнажатия (часто пробела) или ддвойноое, в т.ч. по причине старости бабушки Клавы. )
Интересен именно семантический поиск и без нейросетей, где "расстояния Левенштейна" не работают от слова "совсем". Нам, помнится удавалось добиться 82-90% авто распознавания, но на 5млн строк это все равно дает ошибку от 500 тыс не распознанного, что очень много.
На память, как пример строки прайс листа: "куп. раздел. верх 2 черепа".. что это? :)
А почему нейросети не рассматриваете для семантического поиска?
я как раз наоборот, не знаю других способов семантики, кроме bertов. вообще они дают неплохой результат. Иногда так делаем: берем список -> для каждого элемента LLM делает описание -> векторизация -> далее уже кластеризация для или k-NN и графовый анализ
куп. раздел. верх 2 черепа - купе раздельное верхняя полка 2 места, Череповец))
потому, что их в конце 90-х, начале 00-х ещё не было как инструмента. Я про свой опыт поиска семантических дублей в товарных строках, с учетом принципиального желания Поставщика отстроить свой дубликат от соседа.
Ну и ещё: исключать из сравнения стоит не только точные дубликаты, но и заведомо отличные друг от друга предложения. Так можно из 5млн строк оставить 50-100тыс. "вроде бы похоже". Далее, канонизация товарной строки (существительное - прилагательное - прочее: "шапка зимняя, мех исскуственный" а не "зимняя шапка на исск. меху" - Зализняк в помощь), расшифровка типовых сокращений, "любимых сокращений бухгалтера", типа куп. = "купальник" раздел = "раздельный", 2 черепа = "рисунок" .. :) Замена синонимов на "каноничное слово".
Как правило, уже на этом этапе многие дубликаты обнаруживаются достаточно достоверно.
вообще интересно, что такие методы (алгоритмические/эврестические/классическое NLP) довольно хорошо решают реальные проблемы, даже во время нейросетей всяких. Хотя у них есть граница применимости и времени они требуют больше на настройку
аббревиатуры и сокращения - вечная тема) постоянно их пытаемся расшифровать. Приведение к каноническому виде - идея интересная, но боюсь сложно реализуется, в общем случае...
ну да питон к сожалению медленный, на (хотябы 24)java всё ищется без этих изысков легко c помощью относительной длинны(с помощью да - алгоритма Кнута-Морриса-Пратта)(разбиваем документ на строки или фразы предварительно и вот оно разбитое пространство ) и даже сами слова можно искать например в 20 миллионах символах в текстовом редакторе, да придётся подождать но эта плата оправдана, по моим наблюдениям лучше подождать чем решать коллизии мультипотоков, хотя можно просто решать 1 поток в разных потоках частями последовательно
проблема векторов в том что появляется новая система кодировки типо, а слова уже есть, тоесть с документами до 2 мегабайт мы на самом деле можем взаимодействовать легко при опр реализациях в самих текстовых документах, всё что больше 2 мегабайт, ну хорошо не 2 мегабайта текста порог, а допустим 10 мегабайт текста, текстового документа должно быть переработано во что-то другое поидее (тоесть страницы например)(тоесть содержание номера страниц, страницы, строки)
например есть txt файл он весит 100 мегабайт - как им пользоваться
ну python тут даже не рассматривается, он очень медленный
но ощущение, что Java тоже не спасет...
например, у нас 5 млн. текстовых строк (короткие разнообразные названия, товары)
надо выделить группы похожий между собой
в моем понимании Java это не сделает без оптимизаций и векторов... или как это можно сделать?
делал в качестве пет-проекта from scratch на python неточный поиск с помощью tf idf и косинусного сходства. часть кода переписал на rust, но на больших данных не проверял
Статус: в неточном поиске (fuzzy match)