Пользователь ищет точный код ошибки, а система показывает красивую статью про похожую проблему. Другой пользователь пишет вопрос своими словами и не находит документ, где использованы профессиональные термины. Эти два промаха требуют разных инструментов.
Полнотекстовый поиск PostgreSQL преобразует текст и запрос с помощью выбранной конфигурации и позволяет ранжировать совпадения. Векторы добавляют поиск по близости представлений; pgvector поддерживает точный поиск, а приближённые индексы меняют компромисс между скоростью и полнотой результата. PostgreSQL: text search, pgvector
Начать с набора вопросов
Возьмём учебную базу из инструкций по работе с сервисом. Вместо выбора модного индекса составим три группы запросов: точные идентификаторы, привычные слова пользователя и вопросы, для которых ответа нет.
«Ошибка DEMO-17» должна находить документ с этим кодом. «Не могу завершить запись» может требовать инструкции, где написано «подтверждение бронирования». А вопрос о несуществующей возможности не должен получать уверенный ответ из случайно похожего документа.
Для каждого запроса заранее отмечают полезные документы. Это небольшой проверочный набор, который позволяет сравнить варианты на одной задаче. Измерять лишь скорость SQL недостаточно: очень быстрый нерелевантный результат всё равно не решает проблему.
Сначала проверить простой поиск
Небольшой учебный пример показывает работу конфигурации русского языка:
SELECT to_tsvector('russian', 'Проверка записи и подтверждения')
@@ websearch_to_tsquery('russian', 'подтверждение');В рабочем запросе учитывают поля документа, конфигурацию и индекс. websearch_to_tsquery принимает поисковую строку по своим правилам, поэтому не стоит приписывать ей синтаксис произвольной поисковой системы. PostgreSQL: управление текстовым поиском
Идентификаторы, артикулы и коды полезно рассматривать отдельно. Для них может быть нужен обычный точный поиск по структурированному полю. Попытка заставить языковой анализатор одинаково хорошо обрабатывать прозу и технические коды иногда скрывает более простое решение.
Когда добавлять векторы
Векторный вариант имеет смысл проверить там, где пользователи и авторы выражают одну мысль разными словами. Но близость представлений не является доказательством правильности документа. Она зависит от модели, способа разбиения текста и свойств коллекции.
Если меняется модель представлений, это изменение поискового контракта. Старые и новые векторы нельзя без проверки считать сопоставимыми. Нужно понимать, какие документы уже переиндексированы и как работает переходный период.
Приближённый индекс полезно оценивать относительно точного поиска на том же наборе. Ускорение может сопровождаться потерей подходящих результатов. Особенно важно посмотреть сочетание индекса и фильтров: пользователь должен получать достаточно результатов внутри разрешённой ему части коллекции.
Смешивать результаты осознанно
Гибридный подход объединяет кандидатов из нескольких методов. Например, отдельные ранжированные списки можно свести через rank fusion, а затем удалить дубли и применить выбранное правило порядка. pgvector приводит гибридный поиск с полнотекстовым как возможный сценарий. pgvector: hybrid search
Складывать сырые оценки двух разных алгоритмов без калибровки опасно: их шкалы могут означать совершенно разное. Иногда достаточно явно повысить приоритет точного совпадения кода, вместо того чтобы усложнять всю формулу.
Доступность и качество проверяются вместе
В учебном наборе должны быть документы двух условных аккаунтов. Запрос одного не должен раскрывать заголовок, фрагмент или само существование закрытого документа другого. Проверяется весь путь: от отбора кандидатов до подсказок и итоговой выдачи.
После этого сравнивают качество первых результатов, отсутствие ответа, задержку и стоимость обновления индекса. Лучший вариант определяется конкретной коллекцией и запросами. Для одной базы достаточно слов и хорошей структуры, для другой полезны векторы, для третьей — аккуратно проверенное сочетание.