Подсказки и поиск

[audetv]

select HIGHLIGHT({limit_words=3, before_match='', after_match='', limit_snippets=1, html_strip_mode='strip', force_snippets=1},'text') from questions where match('Денежная реформа 1961*');

call keywords('денежная реф*', 'questions', 1 as stats, 10 as expansion_limit);

[audetv]

«Поиграл» локально. Добавил в настройки таблицы questions индекса svodd параметр bigram_index = all
Это позволяет при вызове функции call keywords выводить биграммы фраз, которые существуют в БД.
Например: денежная реформа, Но так же при более распространённых словах вылезают биграммы с предлогами и иные не особо значащие сочетания, которые по сути своей как будто бы ничего полезного не предоставляют.

Основной момент, что биграммы это реально существующие сочетания в индексе. Далее, если мы возьмем второе слово из биграммы — реформа, то получим биграммы с этим словом. Показалось, что хорошо, но по факту эти 2 сформированных биграммы, например: «денежная реформа» и «реформа в» могут быть вообще не связанны, и никогда рядом в тексте корпуса не встречаться. и соответственно если показать пользователь подсказку сложенную из 2х биграмм, может получиться так, что ничего в корпусе в итоге не будет найдено. (Надо добавить пример с 2мя биграммами без предлога, чтобы сформировался такой запрос, по которому ничего не найдено). Т.е. мы получаем запрос «денежная реформа в», или что-то подобная как сложение 2х биграмм, но это могут быть совершенно не связанные сочетания слов.

Попытался обойти это момент с использованием функции HIGHLIGHT. Когда мы выбираем биграмму из предложенного списка, далее передаем именно эту биграмму в поиск, для отображения частей (снипетов) реальных строк корпуса с помощью функции HIGHLIGHT и MATCH. Здесь уже получается, что-то что реально существует в корпусе, но при этом сформированные подсказки могут быть разбиты разорваны по словам, (предложения разорваны) (надо приложить примеры) и если такой текст HIGHLIGHT попадет, как поисковый запрос в поле запроса, то тоже ничего не будет найдено. Т.е. такую подсказку нельзя использовать как поисковый запрос во всех случаях. В этом направлении надо еще подумать и потестировать в корпусе разные связки запросов. Но в целом можно добиться более менее приемлемых результатов если ограничить запрос параметрами, например, как в первом посте: {limit_words=3, before_match='', after_match='', limit_snippets=1, html_strip_mode='strip', force_snippets=1} Добавить ограничение ко-ва слов в подсветке, удалить тэги, которые подсвечивают слова из запроса, обычно это тэг strong, удалить иные html тэги из подсказки,

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

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

Пока в очередной раз после нового этапа тестирования, кажется, что подсказки не нужны.

Но есть интересный момент, который можно реализовать в виде подсказки в поиске, например, когда пользователь начинает набирать слово и это совпадает с именем пользователя/автора/жанра книги/наименования книги, то можно пользователю предложить выбрать пользователя из списка и тогда сформировать запрос вида @username user @text денежная реформа, @author МИД @text …, @genre публицистика @ text …, @title Сад растет сам @text … и т.д.
Т.е. использовать диалоговую строку запроса как дополнительный инструмент управления, подсказывать какие-то фильтры при наборе и для визуального закрепления снабжать в поисковой подсказке это еще и с соответствующей иконкой: пользователя, жанра, сайта КОБ или иное.

Надо развить и расписать эту мысль подробнее, по поводу подсказок фильтров в поиске.

[audetv]

#370

Кажется после наших тестов с fuzzy поиском я cформировал для себя смысл подсказок.
Вот пример тестового кода, для библиотеки военно-исторической, что выдает следующая функция по запросу «замволт»:

$result = $this->client->autocomplete(
	[
		'body' => [
			'table' => 'common_library',
			'query' => $queryString,
			'options' => [
	            'fuzziness' => 1,
	            'append' => true,
	            'prepend' => false,
	            'expansion_len' => 4,
	            'layouts' => ['ru', 'ua'],
	        ],
		],
	]
);

var_dump($result);

array(1) {
  [0]=>
  array(5) {
    ["total"]=>
    int(7)
    ["error"]=>
    string(0) ""
    ["warning"]=>
    string(0) ""
    ["columns"]=>
    array(1) {
      [0]=>
      array(1) {
        ["query"]=>
        array(1) {
          ["type"]=>
          string(6) "string"
        }
      }
    }
    ["data"]=>
    array(7) {
      [0]=>
      array(1) {
        ["query"]=>
        string(14) "замволт"
      }
      [1]=>
      array(1) {
        ["query"]=>
        string(16) "замволту"
      }
      [2]=>
      array(1) {
        ["query"]=>
        string(16) "замволта"
      }
      [3]=>
      array(1) {
        ["query"]=>
        string(14) "замуолт"
      }
      [4]=>
      array(1) {
        ["query"]=>
        string(14) "зумволт"
      }
      [5]=>
      array(1) {
        ["query"]=>
        string(16) "замуолта"
      }
      [6]=>
      array(1) {
        ["query"]=>
        string(16) "зумволта"
      }
    }
  }
}

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

Т.е. в нашем случае польза подсказок в том, что подсказка должна подсказать возможные варианты написания введенных слов в запросе, эта информация поможет пользователю принять решение о включении нечёткого поиска по запросу или интересующим словам, или же сформировать такие запросы, которые будут покрывать необходимые варианты. Вот например «эсминец замволт»:

 array(10) {
      [0]=>
      array(1) {
        ["query"]=>
        string(29) "эсминец замволт"
      }
      [1]=>
      array(1) {
        ["query"]=>
        string(31) "эсминец замволту"
      }
      [2]=>
      array(1) {
        ["query"]=>
        string(29) "эсминец замуолт"
      }
      [3]=>
      array(1) {
        ["query"]=>
        string(29) "эсминец зумволт"
      }
      [4]=>
      array(1) {
        ["query"]=>
        string(29) "зсминец замволт"
      }
      [5]=>
      array(1) {
        ["query"]=>
        string(29) "зсминец замуолт"
      }
      [6]=>
      array(1) {
        ["query"]=>
        string(29) "зсминец зумволт"
      }
      [7]=>
      array(1) {
        ["query"]=>
        string(29) "эсминеи замволт"
      }
      [8]=>
      array(1) {
        ["query"]=>
        string(29) "эсминеи замуолт"
      }
      [9]=>
      array(1) {
        ["query"]=>
        string(29) "эсминеи зумволт"
      }
    }

Ощущение, что все это должно было быть понятно и ранее, но вы в процессе тестирования сформировали целевое использование нечеткого поиска на примере «замволт».

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

[iprst]

Пример с эсминцем прямо клинический случай получился. Десять вариантов, вот это гжель и хохлома, вот это я понимаю

[iprst]

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

Для накопления некоторой статистики, предлагаю пока оставить нечёткий поиск на сайте, может будет полезен в использовании, и покажет впоследствии что-то, что пока не осознано.