Упрощение поиска с ИИ с помощью гибридного поиска AlloyDB и RRF

Для современных приложений с ИИ и RAG достижение высокой релевантности поиска требует объединения как минимум двух методов: векторного поиска для семантического контекста и полнотекстового поиска (FTS) для точности по ключевым словам. Хотя AlloyDB for PostgreSQL поддерживает обе эти возможности, их управление традиционно требовало более активного операционного подхода для обеспечения максимальной производительности.

Сложность заключается не в выполнении поиска, а в последующем объединении наборов результатов. Объединение результатов векторного запроса (оценки расстояния) и запроса FTS (оценки релевантности) требует сложных SQL-запросов или написания пользовательского кода на уровне приложения. Это часто означает необходимость поддержки отдельной системы для слияния, нормализации оценок и повторного ранжирования.

В этой статье подробно описывается, как гибридный поиск AlloyDB AI устраняет эту сложность. Мы рассмотрим, как недавние обновления позволяют вам:

• Упростить гибридный поиск: объединить сложные SQL-запросы или многоэтапные рабочие процессы приложения в одну высокопроизводительную SQL-функцию на основе Reciprocal Rank Fusion (RRF).

Упростить гибридный поиск: объединить сложные SQL-запросы или многоэтапные рабочие процессы приложения в одну высокопроизводительную SQL-функцию на основе Reciprocal Rank Fusion (RRF).

• Оптимизировать производительность FTS: использовать новое расширение RUM для достижения ранжирования релевантности с низкой задержкой и эффективного сопоставления фраз путем сохранения позиций слов непосредственно в индексе.

Оптимизировать производительность FTS: использовать новое расширение RUM для достижения ранжирования релевантности с низкой задержкой и эффективного сопоставления фраз путем сохранения позиций слов непосредственно в индексе.

• Использовать стандартное для отрасли ранжирование: применять новый нативно поддерживаемый индекс BM25 для превосходной оценки по ключевым словам «из коробки».

Использовать стандартное для отрасли ранжирование: применять новый нативно поддерживаемый индекс BM25 для превосходной оценки по ключевым словам «из коробки».

• Расширить универсальность поиска: выполнять запросы к специализированным внешним кластерам, включая Elasticsearch, OpenSearch и Solr, используя новый Foreign Data Wrapper (FDW) для внешнего поиска, не покидая среду AlloyDB.

Расширить универсальность поиска: выполнять запросы к специализированным внешним кластерам, включая Elasticsearch, OpenSearch и Solr, используя новый Foreign Data Wrapper (FDW) для внешнего поиска, не покидая среду AlloyDB.

Проблема многоэтапного рабочего процесса

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

• Выполнение векторного поиска: запуск запроса с использованием векторного столбца или векторного индекса (для AlloyDB это может быть индекс ScaNN) для поиска топ-k результатов с генерацией векторных оценок.

Выполнение векторного поиска: запуск запроса с использованием векторного столбца или векторного индекса (для AlloyDB это может быть индекс ScaNN) для поиска топ-k результатов с генерацией векторных оценок.

• Выполнение запроса FTS: запуск запроса FTS, например, с использованием обобщенного инвертированного индекса (GIN) для поиска топ-k результатов.

Выполнение запроса FTS: запуск запроса FTS, например, с использованием обобщенного инвертированного индекса (GIN) для поиска топ-k результатов.

• Нормализация оценок (самый хрупкий этап): написание сложной SQL-логики или пользовательского кода приложения для приведения обоих наборов результатов к общей шкале. Эта логика склонна к сбоям при изменении распределения данных.

Нормализация оценок (самый хрупкий этап): написание сложной SQL-логики или пользовательского кода приложения для приведения обоих наборов результатов к общей шкале. Эта логика склонна к сбоям при изменении распределения данных.

• Выполнение кросс-сервисных соединений и повторного ранжирования: использование памяти приложения для выполнения сложного FULL OUTER JOIN по идентификаторам документов, применение взвешенного суммирования нормализованных оценок и, наконец, сортировка объединенных результатов в случаях, когда поиск FTS выполнялся в системе, отличной от той, что использовалась для векторного поиска.

Выполнение кросс-сервисных соединений и повторного ранжирования: использование памяти приложения для выполнения сложного FULL OUTER JOIN по идентификаторам документов, применение взвешенного суммирования нормализованных оценок и, наконец, сортировка объединенных результатов в случаях, когда поиск FTS выполнялся в системе, отличной от той, что использовалась для векторного поиска.

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

Упрощение архитектур гибридного поиска с помощью AlloyDB

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

1. Единый источник истины

Вместо многоэтапного процесса выборки и объединения вы просто вызываете одну SQL-функцию, предоставляя компоненты поиска в виде декларативного JSON-массива:

SQL

(Примечание: унифицированный API ai.hybrid_search не ограничивается только двумя компонентами. Он также нативно поддерживает внешние источники поиска через новый FDW).

2. Оркестрация на уровне базы данных

Функция hybrid_search() выполняет весь рабочий процесс в рамках одного плана запроса, минимизируя накладные расходы и помогая обеспечить согласованность транзакций. Она использует:

• Динамическая генерация CTE: функция конструирует динамический SQL, создавая обобщенные табличные выражения (CTE) для каждого компонента. Каждый CTE отвечает за вычисление позиционного ранга (ROW_NUMBER()) своих результатов.

Динамическая генерация CTE: функция конструирует динамический SQL, создавая обобщенные табличные выражения (CTE) для каждого компонента. Каждый CTE отвечает за вычисление позиционного ранга (ROW_NUMBER()) своих результатов.

• Слияние на уровне ядра: все ранжированные результаты компонентов немедленно объединяются с использованием FULL OUTER JOIN на основе идентификатора документа.

Слияние на уровне ядра: все ранжированные результаты компонентов немедленно объединяются с использованием FULL OUTER JOIN на основе идентификатора документа.

• Итоговая оценка RRF: объединенные ранги используются для вычисления итоговой унифицированной оценки с использованием формулы RRF:

Итоговая оценка RRF: объединенные ранги используются для вычисления итоговой унифицированной оценки с использованием формулы RRF:

Благодаря такому подходу сложные вычисления оценок и объединения на стороне приложения становятся ненужными. Хотя Reciprocal Rank Fusion (RRF) является нашим текущим алгоритмом ранжирования, в будущем мы планируем внедрить дополнительные варианты слияния и ранжирования.

Результат: производительность и операционная простота

Переход от сложных внешних рабочих процессов к нативным SQL-функциям дает немедленные и измеримые преимущества:

Метрика

Многоэтапный рабочий процесс приложения (симулированный ручным SQL)

UDF hybrid_search() в AlloyDB AI

Сложность кода

Сложные функции нормализации оценок, вызовы сервисов и объединения в приложении.

Отсутствие внешней логики; один декларативный SQL-вызов.

Обслуживание

Постоянная настройка формул нормализации.

Настройка не требуется; RRF основан на рангах и не зависит от распределения.

Повышение производительности FTS: расширение RUM

Функция hybrid_search() в AlloyDB AI разработана для обеспечения высокой релевантности поиска за счет объединения высокопроизводительного векторного поиска с полнотекстовым поиском (FTS). Хотя встроенные возможности FTS в AlloyDB весьма мощны, зависимость от стандартного индекса PostgreSQL GIN для текстовых компонентов может стать «узким местом» при выполнении сложных операций.

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

• Ранжирование по релевантности: расчет оценок результатов поиска на основе близости и частоты слов.

Ранжирование по релевантности: расчет оценок результатов поиска на основе близости и частоты слов.

• Поиск фраз: поиск точного порядка слов, что требует наличия информации о позициях.

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

Представляем расширение RUM для FTS с низкой задержкой

Расширение RUM — это мощный метод доступа к индексам на основе GIN, который напрямую решает эти проблемы производительности.

• Основное преимущество RUM: в отличие от индекса GIN (который сопоставляет слово -> [docID]), индекс RUM хранит информацию о позиции каждого слова непосредственно внутри индекса (например, слово -> [(docID1, [pos])], ...).

Основное преимущество RUM: в отличие от индекса GIN (который сопоставляет слово -> [docID]), индекс RUM хранит информацию о позиции каждого слова непосредственно внутри индекса (например, слово -> [(docID1, [pos])], ...).

• Преимущества в производительности: это позволяет RUM выполнять сложные операции, такие как ранжирование и сопоставление фраз, преимущественно внутри самого индекса, избегая дорогостоящего сканирования кучи (heap scans). RUM обеспечивает значительно более быстрое ранжирование по релевантности, а также эффективный поиск фраз и поиск по близости слов.

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

• Отлично подходит для гибридного поиска: RUM является критически важным дополнением к векторному поиску (например, ScaNN) в рамках гибридного поиска, поскольку потенциальная задержка GIN делает его менее подходящим для гибридного подхода в реальном времени.

Отлично подходит для гибридного поиска: RUM является критически важным дополнением к векторному поиску (например, ScaNN) в рамках гибридного поиска, поскольку потенциальная задержка GIN делает его менее подходящим для гибридного подхода в реальном времени.

Расширение RUM — отличный выбор для поисковых приложений с интенсивным ранжированием или высокой конкурентностью. Храня позиции слов непосредственно в индексе, RUM устраняет необходимость повторного сканирования страниц таблицы во время ранжирования, предоставляя быстрые и отсортированные результаты. Однако у него есть свои недостатки: более медленное создание индексов и больший объем занимаемого дискового пространства. Если ваша рабочая нагрузка отдает приоритет быстрым запросам и точному ранжированию, а не скорости записи и плотности хранения, RUM — это инвестиция, которая полностью себя оправдывает.

Измеримые результаты и интеграция

Использование RUM напрямую повышает производительность FTS в AlloyDB, демонстрируя значительный прирост как для обычных FTS-запросов, так и для гибридного поиска, включающего FTS-запросы. Ниже приведены статистические данные о производительности, показывающие ускорение при использовании RUM по сравнению с GIN на различных BEIR наборах данных.

RUM интегрируется со специализированным оператором расстояния <=> для поиска и ранжирования, который поддерживается для использования в SQL-вызовах гибридного поиска, предоставляя лучшее из обоих миров. В следующем codelab показано, как настроить и использовать индекс RUM с UDF гибридного поиска.

Представляем индекс BM25: современный стандарт ранжирования

Недавно мы представили индекс BM25 в CloudSQL и AlloyDB в предварительной версии, внедрив отраслевой стандарт ранжирования по релевантности через расширение pg_textsearch. BM25 использует TF-IDF, который учитывает насыщение частоты терминов и нормализацию длины документа, обеспечивая значительно более высокую точность и качество для поисковых запросов на основе ключевых слов. Используя встроенные индексы BM25 в AlloyDB AI, вы можете получить превосходную точность ранжирования «из коробки», благодаря чему точные совпадения терминов и ключевые слова будут иметь высокий рейтинг без необходимости внедрения внешних поисковых систем или сложной пользовательской логики оценки.

Внешний поиск: расширение универсальности с помощью оберток внешних данных (FDW)

Чтобы еще больше расширить возможности поиска, мы также представили обертку внешних данных (Foreign Data Wrapper, FDW) для внешнего поиска в AlloyDB AI. Это позволяет выполнять полнотекстовый поиск по специализированным внешним кластерам, начиная с Elasticsearch, OpenSearch и Solr, и обеспечивает несколько ключевых архитектурных преимуществ:

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

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

• Единый SQL-интерфейс: взаимодействуйте с внешними данными, выполняйте соединения (joins) и объединяйте результаты с помощью стандартного SQL PostgreSQL, не теряя выразительности расширенных FTS-запросов.

Единый SQL-интерфейс: взаимодействуйте с внешними данными, выполняйте соединения (joins) и объединяйте результаты с помощью стандартного SQL PostgreSQL, не теряя выразительности расширенных FTS-запросов.

• Высокая переносимость: сохраняйте существующую поисковую инфраструктуру, получая при этом преимущества упрощенной гибридной архитектуры, предлагаемой AlloyDB AI.

Высокая переносимость: сохраняйте существующую поисковую инфраструктуру, получая при этом преимущества упрощенной гибридной архитектуры, предлагаемой AlloyDB AI.

Следующие codelabs представляют собой комплексные руководства по коду, описывающие гибридный поиск с интеграциями Elasticsearch и Solr.

Единая архитектура для поиска на базе ИИ

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

• Упрощение гибридного поиска: функция гибридного поиска AlloyDB AI, работающая на базе RRF, превращает хрупкий многошаговый рабочий процесс приложения в один высокопроизводительный SQL-вызов. Эта встроенная реализация устраняет необходимость в сложной нормализации оценок и соединениях на стороне приложения, радикально снижая операционные и инженерные затраты и обеспечивая при этом стабильно точные и быстрые результаты гибридного поиска.

Упрощение гибридного поиска: функция гибридного поиска AlloyDB AI, работающая на базе RRF, превращает хрупкий многошаговый рабочий процесс приложения в один высокопроизводительный SQL-вызов. Эта встроенная реализация устраняет необходимость в сложной нормализации оценок и соединениях на стороне приложения, радикально снижая операционные и инженерные затраты и обеспечивая при этом стабильно точные и быстрые результаты гибридного поиска.

• Оптимизация производительности FTS: Чтобы компонент FTS в Hybrid Search соответствовал разнообразным требованиям приложений, AlloyDB AI предлагает различные варианты полнотекстового поиска. Расширение RUM оптимизировано для обеспечения низкой задержки за счет хранения позиционных данных непосредственно в индексе, что позволяет ускорить ранжирование релевантности и повысить эффективность поиска фраз — это важно, когда требуется высокая скорость выполнения запросов. В качестве альтернативы индекс BM25 обеспечивает стандартное для отрасли ранжирование релевантности и является предпочтительным выбором, когда приоритетом является точность оценки ключевых слов. Вы можете выбирать между этими вариантами в зависимости от того, что для вас важнее: задержка поиска или точность ранжирования.

Оптимизация производительности FTS: Чтобы компонент FTS в Hybrid Search соответствовал разнообразным требованиям приложений, AlloyDB AI предлагает различные варианты полнотекстового поиска. Расширение RUM оптимизировано для обеспечения низкой задержки за счет хранения позиционных данных непосредственно в индексе, что позволяет ускорить ранжирование релевантности и повысить эффективность поиска фраз — это важно, когда требуется высокая скорость выполнения запросов. В качестве альтернативы индекс BM25 обеспечивает стандартное для отрасли ранжирование релевантности и является предпочтительным выбором, когда приоритетом является точность оценки ключевых слов. Вы можете выбирать между этими вариантами в зависимости от того, что для вас важнее: задержка поиска или точность ранжирования.

• Повышение универсальности за счет внешнего поиска: Добавление внешнего поиска через FDW расширяет возможности AlloyDB для работы со специализированными поисковыми бэкендами, такими как Elasticsearch. Это позволяет использовать преимущества масштабируемости и расширенные функции поиска специализированных поисковых кластеров, сохраняя при этом привычный интерфейс PostgreSQL. Интегрируя эти внешние результаты непосредственно в структуру гибридного поиска, AlloyDB AI гарантирует, что вы сможете объединить даже самые огромные текстовые репозитории с семантическими данными на основе векторов.

Повышение универсальности за счет внешнего поиска: Добавление внешнего поиска через FDW расширяет возможности AlloyDB для работы со специализированными поисковыми бэкендами, такими как Elasticsearch. Это позволяет использовать преимущества масштабируемости и расширенные функции поиска специализированных поисковых кластеров, сохраняя при этом привычный интерфейс PostgreSQL. Интегрируя эти внешние результаты непосредственно в структуру гибридного поиска, AlloyDB AI гарантирует, что вы сможете объединить даже самые огромные текстовые репозитории с семантическими данными на основе векторов.

Консолидируя сложность оценки, объединения и повторного ранжирования внутри ядра базы данных и предлагая двухпутевой подход к FTS — использование RUM для оптимизированного, низкозадержечного внутреннего FTS или внешнего поиска для специализированных масштабируемых бэкендов — AlloyDB AI предоставляет надежную и автономную поисковую основу. Это сосуществование имеет решающее значение для общей концепции гибридного поиска, обеспечивая гибкость выбора оптимального пути в зависимости от рабочей нагрузки, объема данных и существующей инфраструктуры. Теперь вы можете сосредоточиться на создании интеллектуальных функций приложений, будучи уверенными в том, что ваша поисковая архитектура обладает высокой производительностью и проста в обслуживании.

Посмотрите на это в действии

Посмотрите, как AlloyDB становится идеальным гибридным поисковым движком.

Узнайте о поддержке BM25 в AlloyDB.

Начало работы

Готовы повысить скорость и экономическую эффективность ваших рабочих нагрузок ИИ?

• Впервые в AlloyDB? Откройте для себя AlloyDB с 30-дневной бесплатной пробной версией.

Впервые в AlloyDB? Откройте для себя AlloyDB с 30-дневной бесплатной пробной версией.

• Начало работы с гибридным поиском: Настройте индекс текстового поиска и выберите индекс векторного поиска. После их создания вы сможете найти примеры выполнения различных запросов гибридного поиска.

Начало работы с гибридным поиском: Настройте индекс текстового поиска и выберите индекс векторного поиска. После их создания вы сможете найти примеры выполнения различных запросов гибридного поиска.

• Внешний поиск: Создайте обертку внешних данных (foreign data wrapper) и внешнюю таблицу в AlloyDB для запроса внешних данных из Elasticsearch, Solr или OpenSearch.

Внешний поиск: Создайте обертку внешних данных (foreign data wrapper) и внешнюю таблицу в AlloyDB для запроса внешних данных из Elasticsearch, Solr или OpenSearch.

• Базы данных