Реалізація пошуку з виправленням помилок для веб-застосунку
Користувач вводить «наушниик» — порожній результат. 70% таких відвідувачів ідуть до конкурентів. Нечіткий пошук (fuzzy search) виправляє помилки та повертає релевантні товари. За час роботи ми реалізували понад 30 проектів з fuzzy-пошуком для e-commerce та каталогів. Обираємо двигун під ваш стек та навантаження: pg_trgm, Meilisearch або Elasticsearch. При правильному налаштуванні конверсія зростає на 15–25%, а витрати на підтримку знижуються — це підтверджують наші кейси.
Наприклад, для інтернет-магазину побутової техніки ми знизили відсоток порожніх результатів з 25% до 3% за рахунок впровадження Meilisearch. Конверсія зросла на 22%. Час відповіді скоротився з 200 мс до 4 мс. Замовте пілотний проект — ми безкоштовно протестуємо на ваших даних.
Які алгоритми відстаней використовуються?
Відстань Левенштейна — мінімальна кількість вставок, видалень, замін для перетворення одного рядка в інший, описано в Wikipedia. Відстань Дамерау-Левенштейна додає транспозицію (перестановку сусідніх символів). Для української мови він кращий: «наушники» → «наушинки» — це одна транспозиція, а не дві операції. На практиці використовуємо Damerau-Levenshtein. Вибір алгоритму впливає на якість: Damerau-Levenshtein дає на 10% менше пропусків для україномовних запитів.
PostgreSQL: pg_trgm
Розширення pg_trgm працює на основі триграм і не потребує зовнішніх сервісів. Це найпростіше рішення, якщо ваш стек вже включає PostgreSQL.
CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE INDEX idx_products_title_trgm ON products USING GIN (title gin_trgm_ops); CREATE INDEX idx_products_description_trgm ON products USING GIN (description gin_trgm_ops); SET pg_trgm.similarity_threshold = 0.3; SELECT id, title, similarity(title, 'наушниик') AS sim FROM products WHERE title % 'наушниик' ORDER BY sim DESC LIMIT 10; -- Комбінуємо fuzzy з повнотекстовим пошуком SELECT p.id, p.title, p.price, greatest(similarity(p.title, 'беспродные наушники'), ts_rank(p.search_vector, plainto_tsquery('russian', 'беспродные наушники'))) AS relevance FROM products p WHERE p.title % 'беспродные наушники' OR p.search_vector @@ plainto_tsquery('russian', 'беспродные') ORDER BY relevance DESC LIMIT 20; Оператор % використовує GIN-індекс. Поріг similarity_threshold 0.3 — ліберальний, 0.5 — строгий. Для коротких запитів обирайте нижню межу. На практиці ми рекомендуємо починати з 0.3 та коригувати за A/B-тестами: збільшення порогу до 0.5 знижує кількість хибних спрацьовувань, але може пропустити частину релевантних результатів. Економія на інфраструктурі при використанні pg_trgm становить до 40% порівняно із зовнішніми двигунами.
Meilisearch — виділений fuzzy-двигун
Meilisearch написаний на Rust, підтримує typo tolerance з коробки. Він спеціально спроектований для швидкого нечіткого пошуку і не потребує складного налаштування.
import meilisearch client = meilisearch.Client('http://localhost:7700', 'your-master-key') index = client.index('products') # Налаштування індексу index.update_settings({ 'searchableAttributes': ['title', 'brand', 'description', 'tags'], 'filterableAttributes': ['category_id', 'status', 'price', 'brand'], 'sortableAttributes': ['price', 'created_at', 'popularity'], 'rankingRules': ['words', 'typo', 'proximity', 'attribute', 'sort', 'exactness'], 'typoTolerance': { 'enabled': True, 'minWordSizeForTypos': { 'oneTypo': 5, 'twoTypos': 9 }, 'disableOnWords': ['iPhone', 'iPad'], 'disableOnAttributes': ['sku', 'barcode'], }, 'pagination': { 'maxTotalHits': 10000 }, }) # Батчева індексація batch_size = 1000 for i in range(0, len(documents), batch_size): batch = documents[i:i + batch_size] task = index.add_documents(batch) index.wait_for_task(task.task_uid) Приклад відповіді Meilisearch
{ "hits": [ { "id": 1234, "title": "Sony WH-1000XM5 бездротові навушники", "_formatted": { "title": "Sony WH-1000XM5 бездротові <mark>навушники</mark>" } } ], "query": "наушниик sony", "processingTimeMs": 4, "totalHits": 38, "page": 1, "hitsPerPage": 20 } Meilisearch дає середній час відповіді менше 10 мс для каталогів до 10 млн записів, що в 10 разів швидше за pg_trgm на великих обсягах.
Elasticsearch: fuzzy-запит
Якщо Elasticsearch вже використовується, додайте fuzzy в мультиматч:
{ "query": { "bool": { "should": [ { "multi_match": { "query": "наушниик", "fields": ["title^3", "brand^2", "description"], "fuzziness": "AUTO", "prefix_length": 2, "max_expansions": 50 } }, { "match_phrase": { "title": { "query": "наушниик", "slop": 2 } } } ] } } } prefix_length: 2 — точне співпадіння перших двох символів знижує хибні спрацьовування. Elasticsearch підходить для великих обсягів (10M+) та інтеграції з аналітикою, але потребує складнішої інфраструктури.
Який двигун обрати?
| Критерій | pg_trgm | Meilisearch | Elasticsearch |
|---|---|---|---|
| Навантаження | до 100k записів | до 10M записів | 10M+ записів |
| Швидкість | ~100ms | <10ms | <50ms |
| Складність | низька | середня | висока |
| Фільтри/фасети | тільки SQL | вбудовані | потужні |
| Вимоги до інфра | тільки PostgreSQL | окремий сервер | кластер |
Для стартапів оптимальний pg_trgm — мінімальна вартість розгортання. Якщо очікуєте зростання, закладайте міграцію на Meilisearch. Для корпоративних проектів з аналітикою — Elasticsearch.
Чому налаштування порогу помилок критичне?
Кожен параметр впливає на якість: занадто ліберальний поріг дає шум, занадто строгий — пропускає помилки. На практиці ми використовуємо:
| Тип запиту | Рекомендований допуск |
|---|---|
| 1–2 слова | 1 помилка (minWordSizeForTypos: 5) |
| 3–4 слова | 2 помилки (minWordSizeForTypos: 9) |
| Довгі запити (5+) | 2–3 помилки |
Точне налаштування дає зростання конверсії на 15–25% за нашими вимірами на 30+ проектах. Економія на доробках після запуску становить до 30% часу команди.
Процес роботи
Аналітика — аудит поточного пошуку, збір статистики помилок. Вибір двигуна — pg_trgm, Meilisearch або Elasticsearch під ваш стек. Інтеграція — налаштування індексів, конфігурацій, API. Тестування — A/B-тест з реальними запитами, коригування порогів. Деплой — моніторинг та підтримка.
Терміни
pg_trgm (розширення, індекси, запити, tuning threshold): 1 день. Meilisearch (деплой, налаштування, синхронізація, API): 2–3 дні. Fuzzy в існуючому Elasticsearch: 1 день.
Що входить в роботу
Конфігурація індексів та типів помилок. Інтеграція через REST API або SDK. Документація з експлуатації. Гарантія — виправимо баги протягом 2 тижнів.
Оцінимо реалізацію fuzzy search під ваші задачі. Отримайте консультацію — зв'яжіться з нами. Ми допоможемо підібрати оптимальне рішення та налаштувати його під ваш стек.







