Эмбеддинги превращают тексты, изображения или продукты в списки чисел, которые отражают смысл, а векторные базы данных хранят их, чтобы система могла находить элементы, похожие по смыслу, а не по точным словам. Их стоит внедрять для семантического поиска, рекомендаций и ИИ-помощников, которые отвечают на основе вашего контента. Для точной фильтрации, отчетности и транзакций традиционные базы данных остаются правильным инструментом.
Многие команды слышат о векторных базах данных через ИИ-чат-боты и предполагают, что они обязательны. Часто поисковая система или существующая база данных уже предлагает векторные функции, и новая система не нужна.
Как работают эмбеддинги?
Модель эмбеддингов, например, от OpenAI, Google, Cohere или открытые модели, такие как на Hugging Face, считывает фрагмент контента и выдает вектор из сотен или тысяч чисел. Тексты с похожим смыслом оказываются близко друг к другу в этом пространстве. Запрос встраивается таким же образом, и система находит ближайшие сохраненные векторы.
Вот почему поиск по запросу “водонепроницаемая куртка для походов” может найти продукт, описанный как “дождевик для горных троп”, даже если слова отличаются. Поиск по ключевым словам пропустил бы его, если бы синонимы не были настроены вручную.
Каковы основные варианты векторных баз данных?
- Специализированные векторные базы данных: Pinecone, Weaviate, Qdrant, Milvus и Chroma.
- Расширения для существующих баз данных: pgvector для PostgreSQL, векторная поддержка в MongoDB Atlas и Redis.
- Поисковые системы с векторными функциями: Elasticsearch, OpenSearch и ИИ-поиск Algolia.
- Облачные сервисы: векторный поиск в Google Vertex AI, Azure AI Search и Amazon OpenSearch Service.
Для многих компаний добавление pgvector в существующую базу данных PostgreSQL или включение векторного поиска в уже используемый поисковый сервис — самый простой путь.
Как это соотносится с традиционными инструментами?
Поиск по ключевым словам
Поиск по ключевым словам, такой как классический Elasticsearch или встроенный поиск на сайте, сопоставляет слова. Он быстрый, предсказуемый и хорош для точных терминов, таких как коды продуктов, названия брендов и номера моделей. Он с трудом справляется с синонимами, вопросами на естественном языке и опечатками, выходящими за рамки простого нечеткого сопоставления.
Реляционные базы данных и SQL
SQL-базы данных обрабатывают точные запросы: все заказы выше определенной суммы, все клиенты в городе, продажи по месяцам. Векторный поиск не может делать это надежно; он находит похожие элементы, а не точные совпадения.
Гибридный поиск
Большинство сильных производственных систем сочетают оба подхода. Гибридный поиск запускает поиск по ключевым словам и векторный поиск вместе и объединяет результаты, часто с моделью переранжирования поверх. Это сохраняет точные совпадения для кодов и имен, добавляя при этом сопоставление на основе смысла для естественных запросов.
Когда маркетинговой или контент-команде стоит переходить?
- Поиск по сайту выдает плохие результаты для запросов на естественном языке, а аналитика показывает много поисков без кликов.
- Чат-бот или помощник должен отвечать на основе большого набора справочных статей, данных о продуктах или документов (RAG).
- Рекомендации продуктов должны отражать сходство по смыслу, а не только теги категорий.
- Контент-командам нужно находить связанные или дублирующиеся статьи среди тысяч страниц.
- Отзывы клиентов должны группироваться по темам на многих языках.
Когда не стоит переходить?
- Каталог или библиотека контента небольшие, и хороший поиск по ключевым словам с синонимами работает.
- Запросы в основном точные: SKU, артикулы, ID заказов.
- Команда не может поддерживать конвейер эмбеддингов, который обновляется при изменении контента.
- Настоящая проблема — плохой контент или отсутствующие данные о продуктах, которые не исправит ни один метод поиска.
Последний пункт заслуживает внимания. Если описания продуктов скудные, семантический поиск будет сопоставлять скудные описания более хитро, и результаты все равно будут разочаровывать.
Что нужно для работы на практике?
Рабочая система нуждается в конвейере: разбить контент на разумные части, встроить каждую часть, сохранить ее с метаданными, такими как язык, категория и дата обновления, и перевстраивать при изменении контента. Запросы нуждаются в фильтрах, например, чтобы возвращать только товары в наличии или статьи на языке пользователя. Оценка требует тестового набора реальных запросов с известными хорошими ответами, проверяемого при каждом изменении модели или разбиения.
Расходы включают вызовы эмбеддингов, хранение и объем запросов. Они обычно скромные для контентных сайтов, но растут с большими каталогами и частыми обновлениями.
Как Alien Road применяет эмбеддинги для клиентов
В типичном проекте исследование начинается с логов поиска по сайту и вопросов поддержки, чтобы увидеть, где не срабатывает сопоставление по ключевым словам. Если сбои в основном связаны с синонимами и естественными формулировками, эмбеддинги — сильный кандидат; если они связаны с отсутствующим контентом, сначала исправляется контент.
Настройка обычно добавляет векторный поиск в существующий стек, такой как pgvector или поисковый сервис клиента, с гибридным ранжированием, чтобы точные термины продолжали работать. Для контентных проектов эмбеддинги также используются внутри компании для поиска почти дублирующихся статей и планирования внутренних ссылок. Измерение сравнивает коэффициент успеха поиска, коэффициент нулевых результатов и конверсии из поиска до и после, используя фиксированный набор тестовых запросов. Отчетность перечисляет запросы, которые улучшились, и те, которые все еще не работают.
Эмбеддинги для контент-операций
Помимо поиска и чат-ботов, эмбеддинги помогают в повседневной работе с контентом. Контент-команда, управляющая тысячами статей, может встроить каждую страницу и найти кластеры почти дубликатов, которые часто конкурируют друг с другом в поиске. Те же векторы могут предлагать внутренние ссылки между связанными статьями и выявлять темы без охвата.
Такой вид внутреннего использования менее рискован, чем поиск для клиентов, потому что ошибки проверяются редакторами до того, как что-то изменится. Это часто лучший первый проект для команды, которая хочет узнать, как эмбеддинги ведут себя на собственном контенте, прежде чем строить что-то, чем будут пользоваться посетители.
Выбор модели эмбеддингов
Протестируйте две или три модели эмбеддингов на своих запросах, прежде чем принимать решение. Многоязычный контент требует модели, обученной на этих языках; некоторые модели справляются с турецким или арабским намного лучше других. Смена модели позже означает перевстраивание всего, поэтому короткое сравнение в начале экономит работу.
Записывайте имя модели и версию с каждым сохраненным вектором, чтобы смешанные эмбеддинги никогда не оказались в одном индексе.
С чего начать на этой неделе
Экспортируйте запросы поиска по вашему сайту за последние три месяца и отсортируйте по поискам без кликов. Прочитайте топ-50.
Отметьте каждый как проблему с синонимами, проблему с отсутствующим контентом или проблему с кодом или именем. Если доминируют проблемы с синонимами, протестируйте семантический поиск на небольшой выборке, прежде чем что-то покупать; ваш существующий поисковый провайдер, возможно, уже поддерживает его.
Продолжайте читать: ИИ-оптимизация · ИИ-оптимизация