Команды Laravel продолжают искать встраивания в тот момент, когда менеджер по продукту говорит: «Поиск с помощью ИИ». Обычно это неправильный первый шаг. Большинству приложений Laravel следует начинать с тщательного поиска по SQL, добавлять векторы только тогда, когда языковое несоответствие становится реальной проблемой.
Команды Laravel продолжают искать встраивания в тот момент, когда менеджер по продукту говорит: «Поиск с помощью ИИ». Обычно это неправильный первый шаг. Большинству приложений Laravel следует начинать с надежного поиска SQL, добавлять векторы только тогда, когда несоответствие языков становится реальной проблемой, и использовать гибридный поиск, когда ставки оправдывают сложность.
Эта рекомендация звучит консервативно, но она экономит время, деньги и значительную часть времени на отладку. Качество поиска не определяется тем, какой метод поиска кажется более разумным. Все зависит от того, соответствует ли ваш индекс намерениям пользователя, доступен ли ваш рейтинг и может ли ваша команда фактически поддерживать систему в рабочем состоянии.
Если вы сегодня создаете поиск в приложении Laravel, реальный вопрос не в том, «Следует ли нам использовать встраивания?» Это: какой режим отказа мы решаем?
SQL по-прежнему выигрывает больше, чем признают люди
Для многих продуктов Laravel в поиске по-прежнему доминируют точные термины, вес полей, фильтры, актуальность и бизнес-правила. Это классическая территория отношений.
Если пользователь ищет номер счета, адрес электронной почты клиента, номер SKU, должность, название плана или флаг функции, векторный поиск мало что добавляет. На самом деле, это часто усугубляет эти случаи, потому что