Представление неструктурированных данных в виде векторов встраивания и поиск на основе встраивания (EBR) с использованием векторного поиска популярнее, чем когда-либо. Что вообще такое вложения? Рой Киз хорошо объясняет это в Самое короткое определение вложений?

Встраивания — это заученные преобразования, которые делают данные более полезными.

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

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

Итак, что нового? Почему всплеск интереса? Ответ заключается в лучшей архитектуре моделей (например, в архитектуре Transformer) и обучении представлений с самоконтролем. Добавьте немного путаницы вокруг больших языковых моделей (LLM), таких как chatGPT, и вот мы здесь.

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

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

Чтобы сократить этот пост, давайте сосредоточимся на текстовых моделях и моделях BERT. Как мы можем преобразовать данные в полезное представление для встраивания, используя модели на основе Transformer?

BERT — это модель глубокой нейронной сети с весами, слоями и прочим, сложностью, которую мы прячем внутри коробки. Если мы вытянем модель из Huggingface, веса модели будут назначены путем предварительного обучения с использованием цели маскированная языковая модель.

Мы можем взять некоторый текст и разбить этот текст на фиксированный словарь, чтобы получить набор числовых идентификаторов. Сопоставление между свободным текстом и жестко запрограммированными идентификаторами. Размер словарного запаса зависит от языка, но для ванильной модели BERT для английского языка это около 30 тысяч слов. Неизвестным словам (вне словарного запаса) присваивается значение UNK, и им присваивается специально зарезервированный идентификатор. Все неизвестные слова присваиваются этому идентификатору, и модель не может различать «foo» и «bar», если их нет в словаре.

Модель BERT может принимать максимум 512 слов (ограничение длины входного контекста), а выход сети — 512 векторов размерностью N, в зависимости от типа модели bert-base. Ванильная модель BERT использует 768 измерений. Для ввода 512 слов мы получаем матрицу 512 x 768 чисел с плавающей запятой, один 768-мерный вектор на входное слово. В отличие от предыдущих архитектур моделей NLP, таких как Word2vec, каждое представление вектора слова на выходе контекстуализируется механизмом внимания в архитектуре Transformer. Векторное представление одного слова зависит от всех остальных слов во входных данных.

Теперь у нас есть несколько векторов, представляющих один текст; что нам делать, если мы хотим представить фрагмент текста, текстовый отрывок или абзац текста в одном векторном представлении? Один из подходов состоит в том, чтобы выбрать один выходной вектор в качестве представления и игнорировать остальные. Другой подход — объединение. Например, усреднение пула усреднит 512 выходных векторов в одно векторное представление.

Теперь у нас есть встроенное представление фрагмента текста, что приводит к ошибке номер 1.

Ошибка № 1: Использование предварительно обученных моделей без тонкой настройки под конкретную задачу

Использование прямых векторных представлений из модели, которая была только предварительно обучена, не даст полезного представления встраивания для любой задачи. Ранжирование в поиске — пример такой задачи; подробности см. в разделе Как не использовать BERT для ранжирования в поиске.

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

Ошибка № 2. Использование тонко настроенных одновекторных моделей встраивания вне предметной области

Чтобы получить полезное представление встраивания (лучше, чем случайное) для поискового ранжирования, нам нужно настроить веса модели. Мы можем сделать это, используя другую цель при обучении модели. Мы можем обучать (обновлять веса), используя помеченные примеры, такие как релевантные и нерелевантные документы, для большой выборки запросов. MS MARCO — это большая коллекция релевантности веб-поиска с помеченными запросами и парами документов, которую можно использовать для обучения модели ранжирования.

Эта тонкая настройка создает полезные представления для встраивания на основе BERT и значительно превосходит традиционные методы поиска по ключевым словам без обучаемых параметров, такие как BM25, в наборе данных MS MARCO с очень большим отрывом.

Проблема в том, что когда мы берем единую модель векторного представления, настроенную на метки MS MARCO, она не превосходит BM25 в другой области с немного другими типами документов и вопросов.

BEIR Benchmark — это отличная основа для оценки качества моделей, обученных на MS Marco, и того, насколько хорошо они переносятся в разные области и задачи.

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

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

Ошибка 3: Непонимание компромиссов векторного поиска

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

Первое, что вы должны спросить себя, нужно ли нам вводить приближенный поиск ближайшего соседа (ANNS) вместо точного поиска ближайшего соседа? Как и во многих аспектах жизни, это вопрос компромиссов.

На стороне обслуживания запросов. Даже без учета сложности обработки на стороне документа, такой как потребность в CRUD, в реальном времени по сравнению с пакетной обработкой и т. д.

  • Соглашение об уровне обслуживания с задержкой (SLA) — насколько быстро оно нам нужно? 0,001 мс, 1 мс, 10 мс, 100 мс, секунда? Может 3 секунды нормально?
  • Пропускная способность. Что мы ожидаем от пропускной способности запросов и какова максимальная скорость, которую мы можем ожидать? 1 QPS, может 1M QPS или даже миллиарды?
  • Влияние на точность, которое мы можем допустить для нашего варианта использования. Когда мы вводим приблизительный поиск, происходит потеря точности по сравнению с полным поиском. В зависимости от нашего выбора алгоритма это может быть существенным. Мы можем оценить это влияние, выполняя запросы с использованием точного поиска, сравнивая приблизительные результаты и вычисляя перекрытие между ними. Например, используя k=10, мы можем измерить перекрытие@10, или k=1, измерить перекрытие@1.

Учитывая вышеизложенное, все сводится к стоимости развертывания производства; сколько серверов нам нужно, и нужны ли они вообще?

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

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

Возможно, все, что вам нужно, это исчерпывающий поиск

Точный поиск соседей будет методом грубой силы вычислять расстояние между запросом и всеми подходящими документами, а возвращенные k документов будут истинными ближайшими соседями. Поиск может быть распараллелен, многопоточен и во многих случаях может использовать оптимизированные аппаратные инструкции; векторы - это язык машины. Поиск также можно эффективно ограничить подмножеством, если мы сохраним векторы в механизме с возможностями фильтрации механизма запросов.

Например, поиск методом грубой силы 1 млн векторов со 128 измерениями занимает около 100 мс в однопоточном режиме. Мы можем распараллелить поиск; например, используя четыре потока, мы можем сократить время до 25 мс, пока не достигнет пропускной способности памяти. Если мы выгружаем векторные данные с диска случайным образом, это будет медленнее, но все же будет распараллеливаться. Если у нас есть 10 миллиардов векторов и у нас нет способа эффективно выбрать подмножество документов, по которым мы выполняем поиск ближайшего соседа, у нас возникает проблема стоимости. Мы все еще можем получить приличную задержку, распределяя поиск по нескольким узлам параллельно, как это может сделать Vespa. Но аренда серверов для контроля задержек может стать дорогостоящей из-за миллиардов встраиваний. Добавьте к этому высокую пропускную способность запросов, и мы получим реальную проблему затрат.

Введение приближений

Идя по пути приближенного векторного поиска, нам нужен алгоритм, который может индексировать векторные данные, чтобы поиск был менее затратным, чем исчерпывающий поиск за счет использования ресурсов и обработки индексации. Здесь также есть много компромиссов, таких как использование диска и использование памяти. Насколько хорошо алгоритм можно использовать с операциями CRUD в реальном времени. Одним из источников понимания алгоритмов ИНС является https://github.com/erikbern/ann-benchmarks, где различные алгоритмы и реализации сравниваются на различных наборах векторных данных.

Приведенный выше график относится к набору данных SIFT с 1 млн 128-мерных векторов. График отображает отзыв@10 (то же, что и перекрытие@10) в зависимости от количества запросов в секунду. Бенчмарк является однопоточным, а это означает, что если алгоритм работает со скоростью 10² QPS, у нас есть задержка 10 мс. 10³ QPS означает задержку в 1 мс и так далее. Эти алгоритмы чертовски быстры.

Если мы развернем эти алгоритмы на сервере с несколькими ядрами ЦП, мы сможем получить еще больше QPS. Ожидается, что 2 ядра дадут 2x QPS, если нет проблем с конфликтами или блокировкой масштабирования. Но не все алгоритмы ANN дают нам одинаково хорошую память. Алгоритмы, ориентированные вверх и вправо, обеспечивают наилучший компромисс между производительностью и точностью, а нижний левый квадрант хуже. Как видно выше, некоторые алгоритмы борются с отзывом более 50%.

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

Краткое содержание

Если вам не понравился этот пост, вы можете написать мне в Твиттере https://twitter.com/jobergum.