В рамках нью-йоркской конференции AI Dev 25 представитель компании Tiger Data Джеки Лян выступил с докладом о скрытых проблемах поиска технической документации для ИИ-агентов. Спикер подробно разобрал, почему популярный векторный поиск часто совершает критические ошибки в контексте RAG-систем, и представил новое решение на базе СУБД Postgres — расширение pg_search. По его мнению, интеграция полнотекстового и семантического поиска внутри одной базы данных избавляет инженеров от инфраструктурного хаоса и кардинально повышает точность ответов искусственного интеллекта.
❌ Почему векторный поиск не справляется с документацией 2:33
Векторный поиск (vector search) стал негласным стандартом для систем генеративного искусственного интеллекта (RAG). Принцип его работы заключается в сравнении семантических математических представлений текста — векторов, создаваемых специальными эмбеддинг-моделями. Например, популярная модель OpenAI text embedding 3 small преобразует текст в массив из 1536 измерений. В этом многомерном пространстве похожие по смыслу понятия находятся близко друг к другу (как рок-группы Metallica и Slayer), а далекие — на значительном расстоянии.
Однако для технической документации исключительно векторный поиск, по словам Джеки Ляна, таит в себе скрытые уязвимости. Проблема заключается в том, что семантическая схожесть не означает точного совпадения на уровне конкретных слов. Модели эмбеддингов слишком снисходительны к версиям программного обеспечения и точным формулировкам. С точки зрения векторного пространства, фразы «Postgres SQL 17» и «Postgres SQL 16» или «Python 3.12» и «Python 3.11» практически идентичны.
Для ИИ-агентов и чат-ботов это оборачивается критическими ошибками:
- Ассистенты программиста рекомендуют устаревшие или несуществующие синтаксические конструкции для текущей версии фреймворка.
- Боты технической поддержки предлагают настройки конфигурации, несовместимые с версией базы данных пользователя.
- Поисковые системы выдают устаревшие (deprecated) методы API вместо актуальных.
🔍 Ограничения ключевых слов и сила гибридного поиска 6:52
Противоположностью векторного поиска является классический поиск по ключевым словам (keyword search), используемый в традиционных поисковых системах вроде Google. Он идеально справляется с точными названиями методов API, параметрами конфигурации и номерами версий, но совершенно не понимает контекст и синонимы. Например, такой алгоритм не догадается, что слова «гнев» и «ярость» близки по смыслу, или что «настройка базы данных» эквивалентна «оптимизации производительности».
Очевидным решением становится гибридный поиск (hybrid search), объединяющий преимущества обоих подходов. В такой схеме векторный поиск отвечает за понимание концептов, синонимов и контекста, а алгоритм ключевых слов (традиционно BM25) обеспечивает ювелирную точность совпадения терминов.
Для объединения результатов применяется специальный алгоритм RRF (Reciprocal Rank Fusion). Джеки Лян привел пример: при запросе «как настроить max_connections в Postgres 17» векторный поиск может вернуть руководство для Postgres 16 или данные по СУБД MySQL, поскольку они семантически близки. Гибридный поиск благодаря жесткому фильтру по ключевым словам выведет на первое место именно нужный документ для 17-й версии Postgres.
🏗️ Кошмар синхронизации инфраструктуры и альтернатива в лице Postgres 10:06
Построение гибридного поиска в классической архитектуре, как утверждает Лян, превращается для инженеров в инфраструктурный кошмар. Стандартная схема выглядит избыточно: сама документация и данные пользователей хранятся в реляционной СУБД (например, Postgres), оттуда данные через сложный конвейер (ETL) синхронизируются с векторной базой данных (Pinecone, Weaviate, Quadrant) для семантического поиска и одновременно с Elasticsearch или OpenSearch — для поиска по ключевым словам.
Спикер, развивающий собственный поисковый ИИ-стартап, признался, что лично столкнулся со всеми недостатками такой архитектуры. Среди главных рисков распределенной системы он выделил:
- Поломка конвейера синхронизации, требующая полной перезагрузки данных в случае сбоя.
- Проблема «согласованности в конечном счете» (eventual consistency), когда из-за сетевых задержек данные в векторной базе временно не соответствуют основному хранилищу.
- Необходимость переписывать схемы данных сразу в трех независимых системах при любых изменениях.
- Возражения со стороны финансовых директоров (CFO) из-за огромных счетов за использование сторонних облачных векторных баз.
🐔 Эволюция поиска в Postgres: от TS_rank к алгоритму BM25 12:32
На самом деле механизмы текстового поиска встроены в Postgres с версии 8.3, вышедшей еще в 2005 году. Инструменты TS_vector и TS_query позволяют токенизировать текст, удалять стоп-слова и выполнять стемминг (приведение слов к корню). Однако встроенный алгоритм ранжирования TS_rank, по мнению Ляна, безнадежно устарел и плохо масштабируется.
TS_rank считает только частоту слов и их позицию, игнорируя обратную частоту документов (IDF). Это делает его уязвимым к так называемому «набиванию ключевыми словами» (keyword stuffing). Спикер продемонстрировал это на комичном примере шуточного научного доклада «Chicken Chicken Chicken», где текст состоял исключительно из одного этого слова. В системе TS_rank такой документ получил бы высочайший балл релевантности, тогда как современный индустриальный стандарт BM25 штрафует за избыточное повторение одинаковых слов и учитывает редкость терминов. Кроме того, BM25 нормально обрабатывает документы разной длины, уравнивая шансы стостраничного фолианта и короткой заметки.
🚀 Три шага к гибридному поиску с расширением pg_search 16:19
Чтобы решить проблему качественного ранжирования, компания Tiger Data разработала плагин pg_search (PG text search) для Postgres. Как иронично заметил штатный инженер-разработчик компании Ти-Джей (TJ), они создали «глубоко неоригинальную архитектуру». Это огромный плюс для мира баз данных, поскольку решение заимствует надежные, проверенные временем принципы Lucene и Tantivy, используемые в Elasticsearch.
Связка pg_search и плагина для высокопроизводительного векторного поиска pg_vector_scale позволяет реализовать полноценный гибридный поиск внутри одной СУБД. Настройка системы, по словам спикера, занимает всего три шага на чистом SQL:
- Шаг 1. Активация расширений и создание таблицы для документации, содержащей уникальный ключ, текстовое содержимое и векторное поле на 1536 измерений.
- Шаг 2. Создание двух индексов: векторного на базе алгоритма DiskANN от Microsoft (с использованием косинусного сходства) и текстового индекса BM25 с указанием английского языка для правильного стемминга.
- Шаг 3. Выполнение поискового запроса SQL с оператором «глазного яблока» (eyeball operator
@@) и объединение топ-20 векторных и топ-20 текстовых результатов через алгоритм RRF.
Формула RRF (1 / (K + rank), где константа K=60) взята из классического исследования Google и Университета Ватерлоо 2009 года. Этот метод вычислительно прост, но крайне эффективен: документы, занявшие высокие позиции в обоих типах поиска, гарантированно поднимаются на самый верх итоговой выдачи.
🛠️ Преимущества единой системы и ответы на вопросы 22:43
Главными аргументами в пользу переноса гибридного поиска в Postgres Лян называет радикальное упрощение архитектуры и атомарность обновлений. Данные обновляются мгновенно во всех индексах, исключая рассинхронизацию. Инженерам становятся доступны все привычные мощные инструменты Postgres: фильтрация по метаданным, объединение таблиц (JOIN), работа с JSONB, геопространственными данными и временными рядами. Технология уже доступна в превью-режиме на платформе Tiger Cloud.
Отвечая на вопросы слушателей из зала, Лян уточнил важные детали:
- Совместимость с AWS RDS: На текущий момент
pg_searchработает только в экосистеме Tiger Data, но планируется к открытию в open-source. При этом сопутствующее расширениеpg_vector_scaleполностью совместимо с AWS RDS и другими вендорами. - Тесты производительности: Бенчмарки для
pg_searchкомпания обещает опубликовать в течение одного-двух месяцев. Для остальных продуктов сравнительные графики уже выложены в блоге; по утверждению спикера, их векторное решение превосходит Pinecone. - Зачем фильтровать данные до передачи в нейросеть? На вопрос о том, почему бы не отдать большой массив данных в LLM, позволив ей искать ключевые слова в контексте, Джеки Лян ответил, что в этом и заключается суть инженерии контекста (context engineering). Современные большие языковые модели все еще плохо справляются с выбором релевантной информации внутри зашумленного контекста. Предварительная очистка данных на уровне БД исключает путаницу и галлюцинации ИИ.
