Остерегайтесь туннельного зрения при поиске данных с помощью ИИ

2024-10-07 11:47

машинное обучение python, компьютерная лингвистика, поисковые системы

Векторный поиск не всегда является правильным инструментом. Так почему же венчурные капиталисты притворяются, что это так?

Введение

Генеративным большим языковым моделям (LLM) необходимо извлекать информацию, чтобы обеспечить большую часть своей ценности — их запомненные знания ненадежны и не поддаются обновлению, но они эффективны в рассуждениях на основе контекста, предоставленного во время вывода. Этот факт общеизвестен в сообществе LLM. Однако в течение первой половины 2023 года возникло сильное предубеждение: что извлечение информации для LLM должно осуществляться с помощью векторного поиска. Это неверно, и замена одного типа решения (векторные базы данных) на возможность (поиск информации) в авторитетном контенте, таком как технологические стеки от венчурных капиталистов, препятствует способности сообщества выбирать правильный инструмент для работы.

Чтобы быть уверенным: векторный поиск — это отличное решение для многих проблем поиска, связанных с LLM, и я использую его в производстве уже почти два года! Но он испытывает трудности в определенных условиях и преуспевает в других, и предположение, что это «то самое» решение поиска для LLM, — просто дезинформация. В вашем приложении оптимальным решением может быть полнотекстовый поиск по ключевым словам, векторный поиск, реляционная база данных, графовая база данных или их смесь. Позже мы рассмотрим реальный ландшафт поиска информации.

Спасибо, что читаете Colin's Substack! Подпишитесь бесплатно, чтобы получать новые посты и поддерживать мою работу.

Примечание для аудитории: Это написано для тех, кто понимает, что такое векторный поиск.

Терминологические примечания:

Векторный поиск, семантический поиск и поиск по сходству можно считать синонимами, но здесь мы будем использовать векторный поиск.
База данных векторов и поиск векторов будут использоваться взаимозаменяемо.
Термины «извлечение информации», «поиск» и «извлечение» будут использоваться взаимозаменяемо.
Вложения и векторы будут использоваться взаимозаменяемо.

Кто сказал, что обязательно нужно использовать векторный поиск?

Представьте, что вы разрабатываете новый продукт или функцию с использованием LLM. Время выбрать систему поиска! Если вы не знакомы с этой областью, вот несколько безопасных вариантов, которые помогут вам принять решение:

Инфраструктурные стеки от суперумных венчурных капиталистов
Учебники по популярным фреймворкам приложений LLM

Если вы это читаете, есть большая вероятность, что у вас уже открыто несколько таких ресурсов в других вкладках. Давайте рассмотрим несколько примечательных примеров.

Андреесен Горовиц: Новые архитектуры для приложений LLM

Последний и самый яркий из представленных здесь примеров, a16z, представляет собой весьма подробный и содержательный фрагмент контента, один из немногих, который действительно содержит реальную схему архитектуры:

Попробуйте найти раздел поиска информации, и вы окажетесь пустыми. На его месте находятся блоки модели встраивания и векторной базы данных. Это полезно, потому что они фактически разделяют два компонента векторного поиска, тогда как другие этого не делают, но крайне бесполезно, потому что они совершают смертный грех подмены векторным поиском поиска информации в целом. Знают ли они, что половина из их перечисленных поставщиков векторных баз данных (Pinecone, Weaviate) также предлагают поиск на основе ключевых слов/BM25, и, следовательно, являются не просто векторными базами данных? Возможно, они решили предложить эту функциональность не просто так.

Список поставщиков инструментов a16z

Sequoia Capital: новый стек языковых моделей

Уважаемый венчурный капиталист, авторитетный тон, полный вперед! Они опросили 33 компании в своей сети на предмет их текущего или ожидаемого использования ИИ:

88% считают, что механизм поиска, такой как векторная база данных, останется ключевой частью их стека. Извлечение соответствующего контекста для модели, о которой можно рассуждать, помогает повысить качество результатов, уменьшить «галлюцинации» (неточности) и решить проблемы со свежестью данных. Некоторые используют специально созданные векторные базы данных (Pinecone, Weaviate, Chroma, Qdrant, Milvus и многие другие), в то время как другие используют предложения pgvector или AWS.

Это очень интересный обзор, и я рекомендую его прочитать! Но они начинают рассказывать, вставляя векторные базы данных как единственный именованный вариант для возможностей поиска. Это становится еще хуже в их «стековой» диаграмме.

Теперь категория «поиск» полностью исчезла, ее заменили векторные базы данных. Вас простят за выбор поставщика из каждого ящика и прекращение работы, но вы многое упустите. И, конечно, это «не исчерпывающий», но это не оправдание для показа одной категории баз данных.

Мадрона: Стек генеративного ИИ

Опять же, этот стек содержит категорию, описывающую технологию (векторную базу данных), а не возможность (поиск информации).

Векторные базы данных: при создании приложений LLM — особенно систем семантического поиска и диалоговых интерфейсов — разработчики часто хотят векторизовать различные неструктурированные данные с помощью вложений LLM и хранить эти векторы, чтобы их можно было эффективно запрашивать. Знакомьтесь с векторными базами данных. Векторные хранилища различаются по закрытому или открытому исходному коду, поддерживаемым модальностям, производительности и опыту разработчиков. Существует несколько автономных предложений векторных баз данных и другие, созданные на основе существующих систем баз данных.

Cowboy Ventures: новый генеративный ИИ-инфраструктурный стек

Cowboy по крайней мере назвал категорию в честь ее возможности (поиск), но не смог привести ни одного примера, который не был бы ориентирован на векторные поисковые системы (Pinecone, Baseplate, Zilliz, Qdrant, Weaviate, LanceDB, Activeloop, Chroma).

Необычные начинания: ландшафт инфраструктуры ИИ

Эта карта ориентирована на открытый исходный код и содержит целый раздел для векторного поиска, но не упоминает об использовании невекторного поиска для извлечения.

Векторные базы данных
Почти каждая широко распространенная современная база данных начиналась как база данных с открытым исходным кодом, и мы ожидаем, что эта тенденция продолжится и с векторными базами данных. Векторные базы данных будут играть важную роль в собственном стеке ИИ — шаблон обеспечения быстрого извлечения вложений, созданных из LLM для обслуживания различных вариантов использования приложений, будет продолжать расти. В прошлом году наблюдалось распространение векторных баз данных с открытым исходным кодом для удовлетворения этой потребности.

Другие примеры

Это сообщение - В поиске векторный поиск не только по умолчанию, но и обязателен - похоже, скорее правило, чем исключение. К сожалению, оно повторяется часто, с шокирующе малым количеством нюансов:

Поставщики фреймворков

Но что, если вы используете фреймворки для создания приложений, чтобы помочь вам принять решение, для более практической перспективы? Многие играли с LangChain как с набором инструментов интерфейса, в этом случае вы могли оказаться на странице документации Data Connection :

Многие приложения LLM требуют пользовательских данных, которые не являются частью обучающего набора модели. LangChain предоставляет вам строительные блоки для загрузки, преобразования и запроса ваших данных через:
Загрузчики документов : загрузка документов из множества различных источников.
Трансформаторы документов : разделение документов, удаление ненужных документов и многое другое.
Модели внедрения текста : возьмите неструктурированный текст и превратите его в список чисел с плавающей точкой.
Векторные хранилища : хранение и поиск по встроенным данным
Ретриверы : Запрос ваших данных

Согласно этому, если вы хотите подключиться к данным, у вас есть только один вариант: вложения (векторы). Однако проект LangChain управляется сообществом и довольно хаотичен, и большие части проекта меняются каждую неделю. Даже во время написания этой статьи мне пришлось изменить этот раздел, так как страница, на которую я ссылался, исчезла. Ну и что, если вы предпочитаете что-то более стабильное? Для этого я рекомендовал семантическое ядро Microsoft в качестве проверенной на предприятии альтернативы. Но, что удивительно, мы видим нечто похожее в семантическом ядре: что такое воспоминания?

Мы получаем доступ к воспоминаниям, которые необходимо загрузить в семантическое ядро, одним из трех способов, причем третий способ наиболее интересен:
Обычные пары ключ-значение: Точно так же, как вы устанавливаете переменную окружения в своей оболочке, то же самое можно сделать при использовании Semantic Kernel. Поиск является «обычным», поскольку это соответствие один к одному между ключом и вашим запросом.
Обычное локальное хранилище: когда вы сохраняете информацию в файл, ее можно извлечь по имени файла. Когда у вас много информации для хранения в паре ключ-значение, лучше всего хранить ее на диске.
Поиск в семантической памяти: Вы также можете представить текстовую информацию в виде длинного вектора чисел, известного как «встраивание». Это позволяет вам выполнять «семантический» поиск, который сравнивает смысл со смыслом вашего запроса.

На этом этапе, когда официальный партнер OpenAI продает векторный поиск как единственное решение для текстового поиска, вы можете подумать: «Что ж, может быть, это ВЫ ошибаетесь». Но, пожалуйста, продолжайте читать и решайте сами.

Вектор не всегда лучший

Горькая правда в том, что для приложений корпоративного уровня простой векторный поиск часто является неправильным решением. Многие специалисты понимают это и часто используют векторный поиск как часть своей системы поиска информации. Ниже приведено несколько ресурсов, показывающих, где релевантность векторного поиска уступает традиционным альтернативам на основе ключевых слов.

Эти примеры подробно описывают приложения поиска, ориентированные на пользователя. На первый взгляд, вы можете склоняться к тому, чтобы различать эти приложения и приложения извлечения и генерации, но при более близком рассмотрении различие размывается. Реальность такова, что огромная часть корпоративных приложений LLM по сути являются поисковыми системами с генеративным пользовательским интерфейсом и целевой единицей извлечения «куска» или короткой записи, а не длинной записи. Если только нет существенного отклонения в вашем шаблоне использования, критерии релевантности для поиска и извлечения LLM фактически взаимозаменяемы.

Мое намерение здесь не в том, чтобы осудить векторный поиск, а в том, чтобы предоставить более сбалансированный взгляд на его место в ландшафте поиска информации. Эти контрпримеры должны развеять представление о том, что векторный поиск является окончательным решением для всех сценариев, но не подрывать его важность и потенциальную полезность.

Haystack US 2023 — Эрика Лесишин и Макс Ирвин: поиск векторов для клинических решений

Превосходное исследование случая, представленное на Haystack US 2023 (где я также выступил с докладом о генеративном поиске ), изучающее весь процесс внедрения и оценки поисковой системы в медицинской области. При замене действующей системы на основе ключевых слов на векторный поиск количество ответов «Не удовлетворен» в опросе почти удвоилось, даже при использовании модели векторизатора, специфичной для домена.

Не удовлетворены: 27% — обычный поиск, 51% — векторный поиск

Команда все еще работает над улучшением системы векторного поиска, и я верю, что она будет отлично работать, когда будет завершена, но огромное спасибо Эрике и Максу за то, что они нашли в себе смелость поделиться актуальным примером из реальной жизни из своего опыта, который противоречит некоторому технооптимизму вокруг векторного поиска.

Как сравнить векторный поиск с традиционным поиском для электронной коммерции

Это простая, но информативная статья, подкрепленная показателями производительности. В этом примере оба подхода работают сопоставимо, и, взятые вместе с приведенным выше примером клинических решений, это хорошая иллюстрация того, как целевые данные и домен могут сместить баланс.

«Предварительно обученная модель» здесь относится к векторному поиску, тогда как «BM25» относится к традиционному поиску по ключевым словам. nDCG — это метрика релевантности.

Как это произошло?

Многие тонкие течения в сообществе LLM способствовали возникновению обратной связи «векторный поиск — это то, что вы используете с ИИ», что привело к эхо-камере, которая привела к однобокому содержанию из более раннего периода. Давайте рассмотрим все факторы и рассмотрим их вклад.

Предполагая, что поиск для ИИ отличается от текстового поиска

В чем именно заключаются различия между извлечением для генеративных вариантов использования и извлечением, существовавшим ранее, для поиска?

Ограниченный размер извлеченного объекта
Различные формы запроса

Нужен ли для этого новый тип поиска? Давайте рассмотрим каждый из них и посмотрим.

Ограниченный размер извлеченного объекта

Для того чтобы LLM мог сгенерировать извлеченный объект, он должен легко помещаться в контекстное окно LLM, оставляя при этом некоторое пространство для генерации. Например, на момент написания базовая модель gpt-3.5-turbo (стандартная модель ChatGPT) имела контекстное окно в 4 тыс. токенов, а отдельная версия предлагала 16 тыс. Грубая эвристика преобразования составляет 3 слова на 4 токена, что означает, что эти модели поддерживают комбинированный ввод/вывод 3 тыс. и 12 тыс. слов соответственно. Для некоторых данных целые записи будут удобно помещаться в этот предел. Другие данные с более длинными записями должны быть разбиты на «фрагменты», чтобы в контекст LLM можно было вставить только соответствующую часть длинной записи. Это требование, как оказалось, является общим для векторного поиска (который обычно использует фрагменты в качестве цели извлечения, модели векторизатора имеют ограничения, аналогичные ограничениям LLM, описанным выше), но фрагментированный текст по-прежнему остается просто текстом и может быть проиндексирован и извлечен как таковой. Вывод: любой метод извлечения может работать.

Различные формы запроса

Другим возможным возражением может быть то, что векторный поиск необходим для обработки различных типов запросов, с которыми могут столкнуться системы LLM, тогда как традиционным методам поиска требуются только ключевые слова. Некоторые из этих возможных типов запросов:

Вопросы
Чат-диалог
Целые записи (например, поиск по файлу)

В каждом случае ключевые слова можно извлечь с помощью удаления стоп-слов или явного извлечения ключевых слов. А в некоторых случаях весь диалог или запись могут быть слишком большими для векторного поиска в любом случае, что делает версию этого шага необходимой в любом случае. Конечно, векторный поиск может дать некоторые преимущества для систем вопросов-ответов и перефразирования, но это вряд ли единственный вариант. Более того, некоторые системы будут запускать этап повторного ранжирования или фильтрации на основе LLM перед окончательной генерацией, сводя к минимуму некоторые из этих преимуществ. Вывод: любой метод извлечения может работать.

Объединяя вышеизложенные пункты, мы видим, что извлечение информации для генерации LLM может выглядеть немного по-разному в зависимости от того, используете ли вы векторы или нет, но все методы применимы.

Очевидно, что это предположение (поиск для LLM — это отдельная категория, и его следует рассматривать с помощью векторного поиска) неверно, но оно так редко подвергалось сомнению, что сохранилось.

Влияние: высокое

Знакомство сообщества с LLM и векторным поиском

И генеративные LLM, и векторный поиск основаны на одной и той же технологии: языковых моделях на основе трансформаторов. В период с 2020 по 2022 год LLM и векторный поиск были просто двумя сторонами одной медали. Затем, после взрыва фреймворков и контента после выпуска ChatGPT, разработчики, создатели фреймворков и производители контента естественным образом отдали приоритет векторному поиску в своих демонстрациях и фреймворках, потому что они уже были с ним знакомы. Я отношу себя к этой группе. Даже в 2021 году моим ответом на текстовый поиск был векторный поиск просто потому, что это была техника, с которой я был знаком, а поиск по ключевым словам — нет. Эта предвзятость знакомства, вероятно, подтолкнула многих ранних практиков к выбору векторного поиска в неоптимальных ситуациях.

Влияние: высокое

Смешивание расширенной генерации FAIR с тем, что мы делаем сейчас

В 2020 году исследователи из FAIR опубликовали сообщение в блоге и статью под названием Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (RAG). В этой статье описывается система, в которой они одновременно настраивают векторизатор запросов и генератор ответов на закрытой задаче типа вопрос-ответ. Это был инновационный подход к повышению производительности на аналогичных задачах в то время, но с тех пор он устарел, поскольку генеративные модели стали намного больше и мощнее, что сделало одновременную тонкую настройку вместе с векторизатором неважной и неосуществимой.

Сейчас очень немногие практикуют FAIR RAG, но термин «Retrieval-Augmented Generation» был, к сожалению, возрожден в конце 2022 года и применен к простому шаблону заземления извлечения и генерации, который теперь повсеместно используется в использовании LLM. Я сильно подозреваю, что некоторые люди предполагают, что векторы должны использоваться для этого базового шаблона извлечения и генерации, потому что они были необходимы для системы FAIR RAG, но ограничения, требующего использования векторов (возможность обратного распространения как через генератор, так и через векторизатор), больше не существует. Если бы это зависело от меня, мы бы перестали говорить Retrieval-Augmented Generation и сказали бы retrieve-and-generate , generative search , или retrieval для заземления LLM . Но этого, вероятно, не произойдет, поэтому просто убедитесь, что ВЫ не совершаете ошибку, предполагая, что поиск векторов требуется для извлечения контекста для генерации LLM.

Влияние: высокое

Участие в стартап-сообществе и стимулы

Естественно, сообщество LLM ранних последователей и технических энтузиастов, скорее всего, будет заинтересовано и будет следить за контентом векторного поиска, чем за традиционным контентом поиска. В конце концов, поставщики векторных баз данных являются одними из самых активных участников контента в сообществе, движимые венчурным финансированием и стремящиеся к принятию через захват быстро множащихся создателей LLM. Партнерства с фреймворками, сообщения в блогах, демонстрации, видеоуроки — весь этот контент, несомненно, принес пользу сообществу. Но вместе со всей помощью приходит перспектива, иногда громкая, а иногда тихая, что векторный поиск — это серебряная пуля.

Некоторые из них были просто вопиющими — самым вопиющим нарушением является брендинг Pinecone :

Пример мирового класса агрессивного антропоморфизма

Но эта показная игра, вероятно, та же причина, по которой они были так смехотворно успешны с привлечением средств от венчурных капиталистов . И финансирование, вероятно, действительно является мотиватором здесь, потому что если векторный поиск — это все, что вам нужно, зачем им интегрировать поиск по ключевым словам в свой продукт ?

Другие добились большего успеха — Weaviate и Qdrant избежали некоторых из самых грубых излишеств брендинга и по-прежнему делились массой полезного контента. Но при любом совете знайте, откуда он исходит. Контент от поставщика технологий, скорее всего, будет продвигать эту технологию, неявно или явно.

Влияние: Среднее

Позорное пренебрежение со стороны действующих лиц

По другую сторону пропасти поисковых провайдеров действующие игроки совершили свои собственные ошибки. Их главной ошибкой было игнорирование векторного поиска как важной функции целостной текстовой поисковой системы до тех пор, пока стартапы не укрепили свое влияние на сообщество пользователей LLM. Мир LLM мог бы выглядеть совсем иначе, если бы Elasticsearch или даже MongoDB наняли 10 инженеров для интеграции векторного поиска в свои предложения в 2020 или 2021 году и оседлали волну LLM с активным участием сообщества. Вместо этого они тянули время, относились к векторному поиску как к второсортной функции и в значительной степени игнорировали растущее сообщество.

Elastic выпустили свою полную функциональность поиска векторов на основе ANN (приблизительных ближайших соседей) в феврале 2022 года . Это было смехотворно поздно, и сообщество уже больше года использовало плагины с открытым исходным кодом, которые они создали для достижения того же результата . Как будто этого было недостаточно, они поместили интерфейс с моделями Hugging Face в клиент Eland , что является функцией «машинного обучения», ограниченной для клиентов Platinum+ . Вы можете реализовать свой собственный интерфейс, если у вас есть время, но они по сути взимают с вас плату за доступ к моделям Hugging Face с открытым исходным кодом. Их документация столь же непонятна, как и любая другая, которую я нашел, и мне потребовались часы, чтобы понять, что я не могу развернуть модель векторизатора, потому что я не купил лицензию. Я не могу винить никого за игнорирование их предложения.

OpenSearch был настроен гораздо серьезнее, по-видимому, предлагая поиск векторов ANN с 2019 года . Но, похоже, они не добились большого прогресса в сообществе, за исключением рекомендаций от давних практиков поиска, которые я нашел в некоторых каналах Discord фреймворков LLM или подобных. А MongoDB только что присоединился к группе полнотекстового поиска со своим поиском Atlas , но, похоже, пока не поддерживает векторы ANN.

Влияние: Среднее

Отсутствие отзывов от реальных пользователей

На сегодняшний день большая часть контента о поиске для LLM была подготовлена:

Поставщики фреймворков
Поставщики векторных баз данных
Венчурные капиталисты

Ни одна из этих групп не решает проблемы в производстве, все они находятся выше по течению на разном расстоянии. Работа поставщиков технологий обычно проявляется в демонстрациях на общедоступных данных, таких как Википедия или транскрипты видео/подкастов. Забавно, что эти два варианта использования являются двумя из лучших возможных приложений для векторного поиска, поскольку они являются открытыми и, в случае транскриптов, разговорными! Они также не подвергаются такому пристальному вниманию, как результаты генеративного поиска на предприятии. Поэтому имейте в виду, что вы получаете предвзятое представление как о возможностях технологии, так и о приложениях, где она используется.

Это также является проблемой в более широком сообществе LLM — такие демонстрационные проекты, как AutoGPT, потребляют непропорционально много внимания сообщества по сравнению с той ценностью, которую они предоставляют в корпоративном использовании (вероятно, близкой к нулю из-за надежности, наблюдаемости, конфиденциальности и других препятствий). В некотором смысле это хорошо, это поддерживает развитие технологии, но это также дает неточное представление о том, что на самом деле используется в производстве и создает ценность для бизнеса.

Влияние: высокое

Векторный поиск — это что-то новое и крутое ?

Помните, как шумиха вокруг криптовалют, технологий распределенного реестра и «децентрализации всего» привела к притоку систем, созданных с использованием блокчейна, даже когда их конкретные варианты использования не извлекали выгоду из преимуществ блокчейна? Эти инициативы были мотивированы скорее привлекательностью ярлыка блокчейна и соблазном прокатиться на волне ажиотажа и финансирования, а не расчетливым выбором, основанным на технологических потребностях. Подобно тому, как системы на основе блокчейна могут столкнуться с серьезными операционными проблемами в масштабе, если вы наивно выбираете векторный поиск, а затем обнаруживаете, что не можете позволить себе переобучение и переиндексацию через год, чтобы соответствовать требованиям релевантности, вас ждут плохие времена.

Влияние: Среднее

Смещение VC и эхо-камера

Подобно тому, как поставщики баз данных заинтересованы в продвижении своих технологий, венчурные капиталисты заинтересованы в продвижении новых технологий (поскольку они вкладывают средства в их успех). В дополнение к этому их внимание сосредоточено на новых компаниях и модных технологиях, что приводит к тому, что они не знакомы с традиционными решениями тех же проблем, которые решают новые решения. Возможно, самое главное, что «практики реального мира», на опыте которых они основываются, как правило, попадают в группы, описанные выше, а именно: энтузиасты языковых моделей, которые не взвесили тщательно преимущества векторного поиска по сравнению с обычным поиском по ключевым словам для тех же вариантов использования. Давайте взглянем на стороны, с которыми консультировался a16z:

Источники, перечисленные в статье Андресена Горовица «Развивающаяся архитектура»

15 напечатанных имен примерно попадают в следующие категории:

3 — поставщики или эксперты в области моделей глубокого обучения (Бен Фиршман, Андрей Карпати, Моин Надим)
8 — поставщики фреймворков/инструментов/платформ (Тед Бенсон, Харрисон Чейз, Джерри Лю, Али Годсил, Шрея Раджпал, Ион Стоика, Матей Захария, Джаред Зонераич)
1 — поставщик векторной базы данных (Грег Коган)
1 — инвестор (Диего Оппенгеймер)
Just 1 — поставщик приложений, ориентированных на пользователя (Деннис Сюй)

Венчурные капиталисты говорят не с теми людьми . Если вы спросите кучу поставщиков инструментов ИИ и экспертов, как должен работать поиск, они скажут вам: ИИ (векторы). Вероятно, они не оценивали никаких альтернатив. Риск здесь заключается в создании целого поколения неоптимальных приложений просто потому, что разработчики когда-либо знали только об одном типе поиска. Венчурные капиталисты могут исправить это, проконсультировавшись с опытными специалистами по поиску и теми, кто оценил несколько методов для приложений, ориентированных на пользователя.

Скорее всего, техническая осведомленность и динамика эхо-камеры составляют основную часть того, почему венчурные капиталисты в большой степени отдают предпочтение векторным базам данных как решению для поиска. Когда вы потребляете их контент, помните об этих предубеждениях и стимулах, которые они содержат.

Влияние: высокое

Так каков же реальный стек поиска?

К сожалению, советы на основе данных о том, как ориентироваться в вариантах, все еще редки. Сейчас я предоставлю несколько упрощенных категорий, интуицию и общие рекомендации.

Опросите ваши данные

Чтобы ориентироваться в доступных методах, признайте, что то, как вы должны извлекать, зависит от того, что вы хотите извлечь. Попробуйте ответить на следующие вопросы:

Для структурированных данных

Есть ли текст?
- Это свободный текст или он ограничен сущностями/категориями?
- Сколько текста в записи? В одном или нескольких полях?

Для неструктурированных данных

Каков характер текста? Разговорные (звонки/подкасты/ТВ) стенограммы? Официальные (отчеты/политики)?
Сколько текста в одной записи?

В любом случае

Какую единицу вы пытаетесь получить? Целую запись или содержащийся в ней подробный ответ/сущность?
Какой у вас поисковый запрос? Вопрос, ключевые слова, диалог в чате или запись?
Является ли домен (темы, терминология, аббревиатуры) в первую очередь открытым/публичным или закрытым/частным?
Есть ли у вас надежные тезаурусы или глоссарии в данной области?
Как часто в предметной области происходят существенные изменения (появляются новые концепции и терминология)?
Обогащаете ли вы записи при индексации или пытаетесь выполнить задачи, выходящие за рамки поиска?

Эти соображения будут определять ваш выбор метода поиска. Обратите внимание, что это не исчерпывающее руководство, но оно должно обеспечить прочную основу и помочь развить интуицию. Я надеюсь написать или поделиться более подробной информацией по этой теме позднее.

Примечание: я фокусируюсь на текстовых данных (или данных, содержащих текст) и исключаю такие модальности, как изображение/видео/аудио. Для этих модальностей векторный поиск имеет некоторые существенные преимущества, но варианты использования в настоящее время более ограничены. Еще одна небольшая оговорка заключается в том, что я рассматриваю здесь только методы извлечения, а не методы переранжирования, которые иногда включают использование векторного сходства для переранжирования результатов поиска по ключевым словам (см. Azure Cognitive Search, Cohere Rerank).

Рассмотрите ваши варианты

Имея в виду свои ответы, рассмотрите различные доступные методы поиска. Вот упрощенный анализ плюсов, минусов и примеров, имея в виду, что этот обзор является упрощенным представлением гораздо более сложного ландшафта:

Поиск векторов
1. Плюсы:
  1. Подходит для «о чем-то», разговорных данных, перефразирования, вопросов-запросов
  2. Доступны многоязычные опции (в зависимости от модели векторизатора)
  3. Интуитивно понимает связанные термины/концепции в контексте обучения модели векторизатора.
2. Минусы:
  1. Проблемы с точными совпадениями, работа со многими возможными измерениями сходства
  2. Стоимость/задержка/сложность векторизатора, работающего для каждого запроса (во время запроса) и индексированной записи (во время индексации)
  3. Невосприимчивость к терминам/концепциям, находящимся вне контекста обучения модели векторизатора, если они не настроены точно
  4. Неустойчив к меняющейся терминологии и отношениям
  5. Сложно обновлять посредством тонкой настройки и дорого переиндексировать в больших масштабах
3. Примеры: Weaviate, Pinecone, Qdrant
Поиск по ключевым словам
1. Плюсы:
  1. Подходит для точных совпадений, поиска длинных записей.
  2. Можно легко обновлять с помощью синонимов, таксономий и т. д.
2. Минусы:
  1. Проблемы с перефразированием, разговорными данными
  2. Не понимает изначально взаимосвязей между терминами/понятиями.
  3. Часто требуется предварительная обработка запроса для уменьшения шума
  4. Огромное количество рычагов настройки может вызвать паралич настройки
3. Примеры: Solr, Elasticsearch, OpenSearch, MongoDB
Реляционная база данных
1. Плюсы:
  1. Если это то, что вы уже используете, это упрощает задачу.
  2. Могут иметь возможности поиска по вектору/ключевым словам/плагины, о которых вы не знаете
  3. Простой и эффективный поиск по идентификаторам
2. Минусы:
  1. Возможности поиска по ключевым словам и вектору могут быть ограничены.
3. Примеры: Постгрес
Гибридный поиск (комбинация 1 и 2)
1. Плюсы:
  1. Предоставляет доступ как к векторному поиску, так и к поиску по ключевым словам.
2. Минусы:
  1. Методы/шаблоны использования слияния пока еще не очень развиты
  2. Поставщики слабы в своем вторичном индексе (поставщики, ориентированные на векторные данные, не имеют функций ключевых слов, поставщики, ориентированные на ключевые слова, не имеют функций векторов)
3. Примеры: Weaviate, Pinecone, Elasticsearch, OpenSearch

Примечание 1: Графовые базы данных и text2sql также становятся все более популярными для поиска и будут включены в будущий связанный контент.

Примечание 2: Гибридный поиск часто относится к одновременному запуску векторного и ключевого поиска и объединению результатов. Я использую его для описания поисковых систем с индексами векторов и ключевых слов, чтобы эти поиски можно было запускать вместе или независимо.

Советы новым специалистам

Понимание принципов поиска как по вектору, так и по ключевым словам даст вам огромный плюс: вы сможете выбрать гораздо более простое решение, чем у конкурентов, быстрее выйти на рынок и предложить более качественные результаты в нужных ситуациях.

Чтобы получить лучший ответ, процесс оценки может оказаться бесценным, и для этого я рекомендую проверить Quepid или что-то подобное. Однако я знаю, что большинство из вас собираются реализовать решение по поиску без строгого процесса оценки, поэтому вот некоторые рекомендации, основанные на моем собственном опыте и разговорах с другими специалистами.

Во-первых, если ваши данные реляционные и уже находятся в базе данных с полнотекстовым поиском, сначала изучите потенциал вашей текущей настройки — выполните поиск по ключевым словам или вектору (см. pgvector , Redis vector similarity ), оцените их производительность и рассмотрите переход на альтернативу только в том случае, если она явно превосходит ваше существующее решение. Если ваш поиск основан в первую очередь на идентификаторах (например, учетных записях пользователей), вам, возможно, вообще не придется рисковать текстовым поиском.

Если ваши данные не находятся в реляционной базе данных:

Выберите базу данных, которая будет поддерживать как векторный поиск, так и поиск по ключевым словам.
В большинстве случаев сначала реализуйте поиск по ключевым словам.
1. Используйте удаление стоп-слов или извлечение ключевых слов для предварительной обработки вашего запроса.
2. Реализуйте наборы синонимов, если они доступны/необходимы
В других случаях сначала реализуйте векторный поиск . Некоторые практические правила:
1. Данные разговоров (например, стенограммы звонков/интервью)
2. Синонимы используются часто, но домен слишком широк для их сбора
Если возвращается много результатов, рассмотрите возможность повторного ранжирования или фильтрации для повышения точности.
Когда ваш первый поиск окажется успешным, реализуйте другой и оцените
1. Начните с использования вторичного прохода поиска, обычно «ключевое слово-затем-вектор», при этом второй проход запускается при отсутствии результатов или низком качестве ответа от первого.
2. Для более простого, но более сложного решения рассмотрите возможность использования параллельного гибридного поиска с использованием такой техники, как взаимное ранжирование (часто включено в гибридные предложения).
Только для зрелых поисковых систем: настройте свою систему поиска по ключевым словам и уточните модель векторизатора.

Причина, по которой следует начинать с поиска по ключевым словам для большинства приложений, заключается в том, что он может предложить высокую точность и легче понять сопоставление от ввода к выводу. Это очень полезно в производственных случаях использования, когда пользователи могут быть сбиты с толку результатами, которые, по-видимому, не соответствуют условиям запроса.

Причина использования поиска по ключевым словам, затем по вектору в пункте 5.a. заключается в том, что эта последовательность позволяет вам искать высокоточные результаты (с помощью поиска по ключевым словам), а если это не удается, то увеличивать полноту с помощью векторного поиска.

Использование векторного поиска в качестве нечеткого запасного варианта в случае плохих результатов по ключевым словам позволяет использовать сильные стороны обоих типов поиска.

Интересно, что это также то, что Qdrant рекомендует для гибридного поиска.

Советы венчурным капиталистам и создателям фреймворков

Замена векторного поиска на извлечение информации вводит в заблуждение и является упрощением.
Очеловечивание поиска информации до уровня «воспоминаний» бесполезно и отвлекает.
Ваш стек или документация должны содержать категорию поиска информации. В ней укажите опции и помогите разработчикам принять решение.

Для всех: сосредоточьтесь на возможностях, а не на технологиях. Думайте о векторном поиске как о функции текстового поиска, а не как о его собственной категории. Таким его запомнят.

Источник: colinharman.substack.com

Остерегайтесь туннельного зрения при поиске данных с помощью ИИ

Комментарии: