Векторные базы данных и эмбеддинги несут четыре основных риска для маркетинговой команды: личные данные, которые становятся доступными для поиска не теми людьми; поиск, который возвращает правдоподобные, но неверные отрывки; эмбеддинги, которые устаревают при изменении контента; и расходы, которые незаметно растут по мере роста индекса. Управление означает решение о том, что можно встраивать, кто может это запрашивать, как часто это обновляется и как проверяются ответы.
Эмбеддинг — это список чисел, представляющий смысл фрагмента текста, изображения или записи о продукте. Векторная база данных, такая как Pinecone, Weaviate, Qdrant, Milvus или расширение pgvector для PostgreSQL, хранит эти списки и находит ближайшие к запросу. Этот поиск ближайших соседей лежит в основе большинства чат-ботов с генерацией, дополненной поиском (RAG), семантического поиска по сайту и виджетов «похожие продукты».
Технология полезна и довольно зрелая. Проблема в том, что она выглядит как окно поиска, поэтому команды относятся к ней соответствующим образом. Она ведет себя иначе, и правила должны это отражать.
Что отличает векторный поиск от поиска по ключевым словам?
Поиск по ключевым словам терпит неудачу громко. Если слова нет в документе, ничего не возвращается, и кто-то это замечает. Векторный поиск почти никогда не возвращает «ничего». Он всегда находит ближайшее совпадение, даже если оно слабое, и ранжирует это слабое совпадение с той же уверенностью, что и сильное.
Для чат-бота, построенного на RAG, это корень большинства плохих ответов. Языковая модель получает три отрывка, которые «ближе всего» к вопросу, и пишет на их основе связный ответ. Если ни один из отрывков на самом деле не отвечает на вопрос, модель все равно склонна выдать что-то, что звучит правильно.
Второе отличие: смысл размыт. Модель эмбеддингов может поместить «отменить мою подписку» близко к «приостановить мою подписку», что хорошо для обнаружения, но неверно для ответа по политике. Точные термины, такие как коды продуктов, цены и юридические пункты, — это то, где чистый векторный поиск наиболее слаб.
К каким рискам следует подготовиться до запуска?
Раскрытие данных через поиск
Самый серьезный риск — это доступ. Когда команда встраивает общий диск, векторный индекс обычно не наследует никаких исходных разрешений папок. Вопрос стажера к внутреннему помощнику может извлечь отрывок из ведомости зарплаты или неопубликованного прайс-листа, потому что индекс знает только то, что отрывок семантически близок.
Сами эмбеддинги также не являются безопасной формой анонимизации. Исследования инверсии эмбеддингов показали, что значительная часть исходного текста может быть восстановлена из векторов в некоторых условиях. Относитесь к сохраненным векторам так же чувствительно, как к исходному тексту.
Устаревший и дублирующийся контент
Страница о прошлогодней политике доставки остается в индексе, пока кто-то не удалит ее векторы. Если новая страница политики также встроена, извлекаются обе, и модель может их смешать. Маркетинговые сайты часто меняются: страницы кампаний, сезонные предложения и выведенные из эксплуатации услуги, поэтому устаревание — это состояние по умолчанию, если нет задания на обновление.
Тихий дрейф качества
Изменение модели эмбеддингов, размера фрагмента или метрики сходства меняет то, какие отрывки возвращаются. Смешивание векторов из двух разных моделей эмбеддингов в одном индексе создает бессмысленные рейтинги, потому что две модели не разделяют координатное пространство. Ничто из этого не вызывает ошибку.
Рост затрат
Управляемые векторные сервисы обычно взимают плату за сохраненные векторы, измерения, единицы чтения и записи или их комбинацию. Повторное встраивание всего сайта после смены модели имеет свою стоимость API. Небольшой пилот — это дешево; индекс каждого PDF, который когда-либо создавала компания, — нет.
Какие технические ограничения стоит знать?
Большинство векторных баз данных используют индексы приближенных ближайших соседей (ANN), такие как HNSW или IVF. «Приближенный» — это буквально: ради скорости индекс может пропустить истинное ближайшее совпадение. Параметры настройки, такие как ef_search в HNSW, жертвуют полнотой ради задержки.
- Разбиение на фрагменты (чанкинг) определяет качество больше, чем бренд базы данных. Страница из 2000 слов, встроенная как один вектор, теряет детали; разбитая на части по 300 слов с небольшим перекрытием, она обычно извлекается лучше.
- Фильтрация метаданных (по языку, дате, линейке продуктов, уровню доступа) поддерживается большинством движков, но фильтрованный поиск может быть медленнее или менее точным на некоторых типах индексов.
- Многоязычный контент требует многоязычной модели эмбеддингов, иначе вопрос на турецком языке может не найти английскую страницу, которая на него отвечает.
- Гибридный поиск, сочетающий оценку по ключевым словам BM25 с векторами, является обычным решением для кодов, имен и точных фраз. Weaviate, Qdrant, Elasticsearch и OpenSearch предлагают ту или иную его форму.
Правила управления, которые нужно установить в первую очередь
Запишите их до того, как будет встроен первый документ. Они короткие и предотвращают большинство инцидентов, описанных выше.
- Список источников: укажите папки, типы записей CMS или базы данных, которые можно встраивать. Все остальное исключается по умолчанию.
- Зеркалирование доступа: сохраняйте метку доступа с каждым фрагментом и фильтруйте по ней во время запроса, чтобы пользователь извлекал только то, что он уже мог открыть.
- Правила исключения: никаких личных данных, контрактов, ведомостей зарплаты или учетных данных в индексе. Сканируйте на наличие адресов электронной почты и идентификационных номеров перед встраиванием.
- Одна модель на индекс: записывайте имя и версию модели эмбеддингов в метаданных индекса. Смена модели означает новый индекс, а не частичное обновление.
- График обновления: повторно встраивайте измененный контент при публикации и запускайте еженедельное задание, которое удаляет векторы для неопубликованных или удаленных страниц.
- Требование цитирования: каждый ответ чат-бота показывает использованные исходные отрывки, чтобы пользователи и рецензенты могли их проверить.
- Владелец: назначенное лицо утверждает новые источники и ежемесячно просматривает результаты оценки.
Как проверить качество поиска?
Создайте небольшой набор для оценки перед запуском. Тридцать-пятьдесят реальных вопросов, каждый в паре со страницей, которая должна на него отвечать, достаточно для маркетингового сайта. Запускайте их после каждого изменения настроек чанкинга, модели или индекса и записывайте, как часто правильная страница появляется в первой тройке результатов.
Добавьте порог сходства. Если лучшее совпадение оценивается ниже порога, который вы установили на основе набора для оценки, помощник должен сказать, что не знает, и предложить способ связи, вместо того чтобы импровизировать. Это единственное правило устраняет большую часть уверенных неверных ответов.
Наконец, читайте логи. Еженедельно делайте выборку из двадцати реальных запросов и их извлеченных фрагментов. Паттерны появляются быстро: страница, которая постоянно всплывает для несвязанных вопросов, или тема без хорошего источника, что является пробелом в контенте, а не проблемой базы данных.
Как Alien Road применяет векторные базы данных и эмбеддинги
В типичном проекте работа начинается с инвентаризации контента, а не с выбора базы данных. Мы перечисляем, что публикует клиент, на каких языках и какие страницы могут отвечать на вопросы клиентов. Страницы с ценами, юридические и рекламные страницы получают отдельную метку, потому что они меняются чаще всего и несут наибольший риск.
Настройка обычно означает pgvector внутри существующего экземпляра PostgreSQL для небольших сайтов или управляемый сервис, когда индекс большой или многопользовательский. Фрагменты несут метаданные о языке, типе записи, дате публикации и уровне доступа, а хук публикации повторно встраивает страницу при каждом ее изменении. Гибридный поиск включен с первого дня для названий продуктов и сервисных кодов.
Измерение использует описанный выше набор для оценки плюс два живых сигнала: доля сессий чат-бота, которые заканчиваются ответом «не знаю», и доля тех, кто кликает на процитированный источник. Ежемесячные отчеты показывают и то, и другое, перечисляют вопросы без хорошего источника и рекомендуют контент для написания в следующий раз. Этот последний список часто является самым полезным результатом для маркетинговой команды.
С чего начать на этой неделе
Выберите один узкий сценарий использования, например, ответы на вопросы о доставке и возврате, и встройте только те страницы, которые их охватывают. Запишите семь правил управления выше в документ на одну страницу и назначьте владельца. Затем соберите тридцать реальных вопросов клиентов из тикетов поддержки или логов чата и используйте их в качестве первого тестового набора.
Как только этот небольшой индекс начнет отвечать надежно, с отображением источников и четким путем «я не знаю», расширяйте по одному источнику за раз. Медленный рост — это то, что делает векторную базу данных службой поддержки, а не обузой.
Продолжайте читать: ИИ-оптимизация · ИИ-оптимизация