[Search] Зміна логіки роботи повнотекстового пошуку
Логіка має бути наступна:
- Шукаємо точне співпадіння введеної фрази (можливо використати "type": "phrase"(фразовий пошук, де запит повинен точно відповідати вказаній фразі. Тобто, в полі пошуку вказана фраза повинна з'явитися як цілісна одиниця, а не як окремі слова)) хоч в одному із полів:
- hunam_id
- id
- lot_id
- cadastral_numbers
- classificators
- identifiers
якщо точне співпадіння є, то boost: 300
При цьому мають ігноруватися символи, такі як " , . ! та інші (мають ігноруватися те, що не літера і не цифра)
На прикладі: Якщо введено "хрещатик 27", то має шукатися саме "хрещатик 27" а не слова "хрещатик" і "27" окремо.
"slop": 0 (зазвичай це дефолт)
"auto_generate_synonyms_phrase_query": false (не генерувати автоматично синоніми для фразових запитів.)
"zero_terms_query": "none" (не генерувати запит, якщо він не містить термінів (слів))
"lenient": true (намагатися обробити запит, навіть якщо він містить помилки). Це якась дефолтна штука.
ДАЛІ ЧЕРЕЗ "АБО" (ці всі налаштування у should, який у bool)
- Шукаємо співпадіння з допуском slop:3 у полі full_text_search
якщо співпадіння знайдені, то boost: 280
На прикладі "хрещатик 27" це означає, що маємо шукати співпадіння у полі full_text_search з можливими "вставками" між "хрещатик" і "27" до трьох термінів. Тобто, якщо у full_text_search присутні слова у такій послідовності "хрещатик у Києві 27", то це валідний для нашого пошуку випадок, т.я. "у" і "Києві" є трмінами, а у нас допуск "до трьох включно термінів між словами фрази "хрещатик _ _ _ 27". - Шукаємо можливі, з найбільшим збігом співпадіння ("type": "most_fields") у полях:
- "title.*",
- "description.*"
- "text_address"
- "phones",
- "emails",
- "owners",
для знайдених boost: 200
4. Шукаємо "хоч якесь" співпадіння у полі full_text_search (вважаю тут використати "match" з оператором "or")
"minimum_should_match": "3<-25% 9<-75%" (Цей параметр вказує мінімальну кількість термінів, які повинні відповідати для збігу. У цьому випадку, якщо є 9 термінів, тоді для збігу потрібно, щоб відповідали принаймні 75% (7 термінів), і якщо є 3 терміни, тоді потрібно, щоб відповідали принаймні 25% (1 термін).)
Ці бустимо boost: 10
Всі інші логіки поки прибрати.
P.S.: Питання, яке вирішуємо: якщо зараз пошукати повнотекстом по "хрещатик 27" і використати сортування по Релевантності, то першою буде процедура, у якої lot_id == 27.
Ось її explanation
бо, наскільки я розумію, умова "multi_match" з "type": "most_fields" знайшла і визначила, що ids є релевантним і бустанула його значно вверх ("boost": 280).
Якщо б з більшим бустом був пошук по full_text_search, то Процедури з lot_id == 27 не піднялися б у рейтингу релевантності.
Треба по полям:
- hunam_id
- id
- lot_id
- cadastral_numbers
- classificators
- identifiers
шукати строге співпадіння.
P.P.S.: Хотілося б мати окреме оточення (чи використати існуючий dev) де можу очистити весь Індекс і фільтром по фіктивному напрямку затягнути 10-20 Процедур (щоб Індекс був малий). І до цього мати можливість налаштовувати вищевказані логіки: змінювати boost, поля, типи та оператори. Бо зараз є лише здогадки, як відпрацює вищеописана логіка.