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

Именно за эту сложную задачу взялась команда Департамента управления данными (SberData) в рамках эффективной интеграции ИИ‑агентов в Корпоративную аналитическую платформу Сбера (КАП), которая объединяет современные инструменты для работы с данными: хранение, интеграция, аналитика, моделирование и контроль качества данных. Наличие таких технологий, как продвинутые LLM (например, GigaChat), и большие объёмы данных делают исследование подобных задач актуальным для рынка больших данных.

В статье мы сравним эффективность векторного поиска, гибридных методов и подхода Retrieval‑Augmented Generation (RAG), оценим их влияние на точность результатов и обсудим практические ограничения.

Постановка задачи

Прежде чем анализировать данные, их нужно найти. А если речь идёт о банке, где сущностей и атрибутов больше миллиона, задача усложняется. Передача только релевантных данных ИИ‑агенту поможет не только увеличить точность ответа, но и снизить затраты.

Мы сосредоточились на конкретном сценарии — поиске релевантных столбцов в большой таблице по запросу на естественном языке. Эти столбцы затем используются в качестве контекста для генерации SQL‑запросов (Text2SQL).

Рассмотрим две таблицы:

• первая таблица содержит 1000 столбцов и соответствующие им описания на естественном языке (далее ЕЯ);

• вторая таблица содержит SQL‑запросы и соответствующие им вопросы на ЕЯ.

Задача сводится к выделению из 1000 столбцов топ-100, достаточных для формирования корректного SQL‑запроса. Хотя возможно передать все 1000 столбцов, сокращение размера ввода улучшает точность модели и снижает затраты на токены. Подробнее о влиянии длины ввода на качество ответов можно узнать здесь.

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

Резюме

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

Таблица 1. Пример данных (сгенерирован):

Вторая таблица содержит SQL-запросы и соответствующие им вопросы на ЕЯ.

Таблица 2. Пример взят из бенчмарка BIRD:

Цель: выбрать 10 % наиболее релевантных столбцов (то есть топ-100) для конкретного пользовательского запроса.

Зачем это нужно?

1. Уменьшить объём контекста для Text2SQL‑моделей, что, в свою очередь, позволит снизить затраты на токены и увеличить точность;

2. Ускорить обработку запросов.

Бенчмарк

В следующих главах обсудим способы поиска релевантных данных, а также получаемую прибавку к точности. Но прежде, чем перейти к сравнению, важно определиться, что считать точностью и чем её измерять. Поскольку наш бенчмарк содержит пары «вопрос» и «правильный SQL‑запрос», мы можем:

• для каждого вопроса выявить релевантные колонки, таблицы и схемы;

• измерять точность системы стандартными формулами (пример 1, пример 2).

В фокусе нашего исследования — метрика ContextRecall@K (в дальнейшем Recall@K). Главной задачей стало в среднем максимизировать метрику Recall@K, чтобы все колонки, таблицы и схемы были включены в контекст.

Вторичной метрикой стала AveragePrecision@K, которая позволяет оценить, насколько правильно расположены релевантные колонки, таблицы и схемы в этой K-выборке (релевантные должны быть выше нерелевантных):

Первые подходы к решению, или Поговорим про RAG

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

Разработаем модели преобразования естественного языка в SQL‑запросы. В нашем случае оптимальным решением оказался метод RAG, подразумевающий поэтапный подход к решению задачи.

RAG (Retrieval Augmented Generation) — это интересный и мощный подход в области обработки естественного языка, который объединяет два основных направления: поиск релевантной информации и генерацию текста на основе найденных данных.

По сути, RAG — это метод, позволяющий использовать внешние источники данных для повышения точности и полноты создаваемого текста. Процесс состоит из дух этапов: извлечения релевантной информации из больших баз данных и последующего генерирования точных SQL‑запросов. Такой подход позволяет минимизировать контекст и повысить точность.

Как работает RAG?

Обычно языковые модели, например, GPT или GigaChat, работают с фиксированным набором данных, полученным во время обучения. Но когда речь идёт о предметно-ориентированных запросах (Domain Knowledge), которые не были заложены в обучающую выборку, этих данных оказывается недостаточно. Вот тут-то и вступает в дело RAG.

Рабочий процесс RAG делится на три этапа:

1. Поиск релевантных данных. На входе — запрос на естественном языке (например, «Найти клиентов с высокой кредитной нагрузкой»). Система ищет и извлекает только те столбцы и метаданные, которые соответствуют запросу (например, credit_score, loan_amount, income).

2. Контекстное обогащение. Важнейшая особенность RAG — это способность гибко объединять знания, полученные из внешней среды, с собственными знаниями. Модель комбинирует имеющиеся данные, что повышает точность генерации.

3. Генерация текста. Обогащённая информация передаётся языковой модели (в нашем случае — GigaChat), которая формирует SQL‑запрос, например, вот такой:
   SELECT client_id FROM clients WHERE loan_amount / income > 0.5 ORDER BY credit_score DESC.

Преимущества RAG

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

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

3. Широкий охват: благодаря возможности обращаться к большим корпусам данных, RAG может обрабатывать гораздо более разнообразные и сложные запросы.

4. Гибкость: подход легко адаптируется к различным задачам — от вопросов‑ответов до создания длинных текстов, переводов и многих других.

Современные SOTA RAG‑системы давно вышли за пределы примитивного векторного поиска. Чтобы добиться максимальной эффективности, может потребоваться многоэтапный поиск или генерация. Разберём ключевые компоненты такой системы, которые подходили под специфику нашей задачи и доказали свою эффективность. Однако перед тем, как углубляться в продвинутые техники RAG, давайте подробнее остановимся на его основных элементах.

Для глубокого погружения рекомендуем серию ноутбуков про современный RAG с нуля.

Способы векторизации и поиска данных

Рассмотрим способы векторного представления текста (как представить набор предложений в виде набора чисел), а затем поиска.

Первоначально методы в NLP делятся на:

• Семантические методы. Используют предобученные на больших объёмах данных (например, сводки новостей) модели, учитывающие контекст и упаковывающие его в сжатые (dense) векторы. Такие модели называют эмбеддинг-моделями (Word2Vec, GloVE, BERT и т. д.).

• Частотные методы. Учитывают только частоту слов в тексте (BoW, TF‑IDF и т. д.), не нуждаются в предобучении, учатся на имеющихся данных и в результате работы создают так называемые разреженные (sparse) векторы.

Рассмотрим эти методы подробнее.

Семантический поиск

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

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

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

Преимущества семантического поиска:

• Работа со смыслом текста и связью слов.

• Эффективная работа с большими объёмами данных (размер векторов ограничен до определённого размера).

Недостатки:

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

• Ограниченное контекстное окно (как следствие, необходимость делить на чанки, желательно схожего размера).

Выбирать эмбеддинги можно при помощи бенчмарков под релевантную задачу. Например, для русского языка есть Encodechka, а также ruMTEB, который является частью большого проекта Multilingual Text Embedding Benchmark (MTEB). На ICLR 2025 анонсировали MMTEB. Мы выбрали несколько подходящих эмбеддинг-моделей и сравнили на нашей задаче.

Таблица 3. Выбор эмбеддингов:

Применение семантического поиска на задаче 1 дало следующие результаты (Таблица 4. Результаты применения семантического поиска):

Частотный поиск (BM25)

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

Он оптимален для точного поиска по ключевым словам.

Таблица 5. Результаты применения частотного поиска:

Гибридный поиск

Гибридный поиск стал «золотой серединой» и позволил объединить в себе достоинства семантического и частотного поиска. Основной идеей является проведение нескольких запросов по каждому из векторов. Далее полученные ответы сливают в итоговый с помощью одного из видов алгоритмического реранжирования: RRF (Rank Reciprocal Fusion), который ранжирует новый список, основываясь на рангах элементов в предыдущих списках, либо WeightedRanker, который основывается на заранее выбранных весах для каждого из запросов.

Гибридный метод улучшил результаты поиска релевантных колонок (задача 1).

Таблица 6. Результаты поиска:

Векторные базы данных

Перейдём к хранению и эффективному поиску векторов.

Векторные базы данных предназначены для эффективного хранения и поиска векторных представлений данных, таких как эмбеддинги текста, изображений или аудио. В отличие от традиционных баз данных, которые работают с табличными или текстовыми данными, векторные базы данных индексируют векторы и позволяют быстро находить наиболее близкие (похожие) с использованием метрик расстояния между ними. К таким базам относятся Qdrant, Chroma, Pinecone, Weaviate, Milvus и FAISS.

Поиск по сжатым векторам традиционно выполняют по близости векторов (ANN). Оценить схожесть можно различными формулами:

• Cosine Similarity (косинусная схожесть);

• Dot Product (скалярное произведение);

• Squared Euclidean (L2-норма);

• Manhattan (манхэттенское расстояние);

• Hamming (расстояние Хэмминга).

Для эффективного поиска используют оптимизированные алгоритмы, в частности, приближенный поиск ближайших соседей (ANN), который обеспечивает высокую скорость при работе с векторами. Популярны такие методы, как деревья KD‑tree, локально‑чувствительное хеширование (LSH) и графовые структуры, например, Hierarchical Navigable Small World (HNSW). Для работы с большими объёмами данных применяют метод сжатия эмбеддингов Product Quantization (PQ), когда векторы разделяют на подвекторы и кодируют компактными представлениями, что значительно уменьшает требования к памяти и ускоряет поиск.

Рассмотрим техники RAG

Продвинутые техники RAG

После проверки семантического и частотного поиска и их объедения в гибридный мы столкнулись с проблемой: всё ещё не нашлось всех необходимых данных для составления корректного SQL-запроса. Так мы приблизились к продвинутым техникам RAG. Они позволяют повысить точность поиска путём изменения начального запроса пользователя и его обогащения контекстом с помощью LLM или уже имеющихся у нас данных, например, увеличения описания к колонкам с помощью LLM. В качестве LLM мы использовали нейросеть GigaChat. Далее представляем примеры промптов к GigaChat и то, как изменяется запрос после её работы, после чего снова применили гибридный поиск к изменённому запросу.

Рерайтинг

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

Таблица 7. Результаты гибридного поиска с Query Rewriting:

Декомпозиция

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

Таблица 8. Результаты гибридного поиска с Query Decomposition:

Step Back

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

Метод состоит из двух этапов:

1. Сгенерировать общие вопросы или дополнить контекст по запросу пользователя.

2. Сгенерировать ответы и добавить их к исходному запросу.

Таблица 9. Результаты гибридного поиска с Step Back Prompting:

HYDE (Hypothetical Document Expansion)

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

Таблица 10. Результаты гибридного поиска с HYDE:

Первичные результаты

Внедрение описанных методов позволило значительно улучшить точность поиска на основе естественных языковых запросов. Ниже приведён график с точностью и способами решения задачи. Самым точным оказался гибридный поиск + Query Decomposition.

Дальнейшие шаги

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

Обогащение контекста

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

Sufficient Context: A New Lens on Retrieval Augmented Generation Systems

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

Предложен метод селективной генерации, комбинирующий уверенность модели и метку достаточности контекста — подробнее можно изучить тут.

И ещё одна из интересных работ — «InstructRAG: Instructing RAG via Self‑Synthesized Rationales».

А сейчас давайте посмотрим на применимость подхода на задачах бизнес блоков.

Практическое применение

Постановка задачи

Для построения прототипов витрин, проверки гипотез, сбора фич для моделей и др. коллеги из бизнеса, в основном, используют SQL, например, PySpark SQL в Jupyter Notebook или Hive SQL в HUE, для написания которого нужно хорошо понимать модели данных.

Для оптимизации процессов создали ИИ‑ассистента, который решал бы задачу Text2SQL, то есть по запросу на естественном языке находил необходимые метаданные и генерировал SQL‑запрос. Ниже более детальная информация про работу поиска.

Подготовка к поиску

На этапе подготовки нужно было решить две задачи: где взять метаданные и как измерять качество поиска.

С метаданными нам повезло, так как модель данных ведётся централизованно: для каждой сущности и атрибута есть как короткое, так и детальное описание, включая логику получения, источники и примеры значений. На первом этапе мы ограничимся слоем только базовых витрин, который содержит примерно 1,5 тысячи таблиц или 20 тысяч бизнес‑атрибутов (исключили все технические атрибуты и бизнес-даты актуальности).

Для измерения качества поиска необходимо собрать бенчмарк, который представляет собой пару «вопрос на естественном языке» и «SQL‑запрос». На текущий момент у нас порядка 400 сценариев, которые мы собрали, продолжая работать над увеличением количества сценариев как вручную, так и автоматически.

Так как поиск является промежуточным этапом, то мы остановились на поиске по таблицам, чтобы на этапе генерации SQL уже из них отобрать нужные атрибуты. Метрикой качества мы считаем долю кейсов, для которых Recall@3 равен 1, то есть в топ-3 выдачи по таблицам должны быть все необходимые сущности для построения SQL‑запроса.

Эволюция подходов к поиску

Первые попытки решения задачи с помощью только семантического поиска по всем метаданным:

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

• Для построения эмбеддингов использовали модель E5 с длиной вектора 1024 и длиной контекста 512 токенов, для векторного поиска — FAISS.

• На подготовку одного индекса, построения эмбеддингов для всех витрин уходило около получаса.

• Результат — низкое качество поиска (~55 %), но быстрое и дешёвое решение.

Качество не удовлетворяло по следующим причинам:

• Пересечение предметных областей в витринах разных бизнес-трайбов, как, например, кредиты в розничном и корпоративном бизнесе.

• Наличие витрин агрегатов внутри одного трайба.

Для улучшения качества поиска мы разбили поиск на этапы: ищем одну релевантную витрину, а потом уже в ней топ-3 релевантные таблицы:

• Для поиска по витринам использовали классификацию через LLM. В качестве описания пробовали разные варианты: готовое описание витрин, экспертную разметку тегами, суммаризацию на основе описания таблиц с помощью LLM.

• По таблицам искали с помощью семантического поиска.

• Значительного улучшения не наблюдалось, качество ~60-65 %, при этом решение оставалось быстрым и дешёвым, так как было одно дополнительное обращение к LLM.

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

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

  

• Использовали GigaChain (fork от Langchain), экспериментально подобрали веса для всех ретриверов и перешли на GigaChat.

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

• Точность увеличилась до ~76 %.

• Увеличилось время поиска, так как ансамбли ретриверов работали последовательно, пришлось перестраивать четыре матрицы для BM25S для поиска в конкретной витрине, которая не была известна заранее.

На завершающем этапе в алгоритм поиска по витринам интегрировали декомпозицию запроса и поиск по значениям, а поиск по таблицам целиком переделали на LLM (GigaChat):

• В поиск по витринам добавили мультипоточность и ограничили количество ключевых слов до четырёх, так как использовали пять потоков LLM для отработки за один проход;

  

• Так как одна витрина в среднем содержит десятки таблиц, а контексты GigaChat постоянно растут, стоит изменить поиск по таблицам следующим образом:

  

• В поиск по таблицам передаём короткое и детальное описание таблиц, по атрибутам — короткое и детальное описание атрибутов и возможные значения атрибута, если есть.

• Такой подход позволил увеличить точность поиска ~81 %.

• При этом увеличились тайминги, стоимость решения и количество вызовов GigaChat до десяти с большим контекстом. Среднее время поиска составило ~30 секунд, а среднее обращение к LLM — ~80 000 токенов.

Выводы

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

• Важно отслеживать время и потребление токенов LLM как на этапе подготовки, так и при ответе на запрос пользователя.

• Применение продвинутых техник RAG, предложенное командой RnD SberData, позволяет значительно улучшить точность поиска на основе естественных языковых запросов.

Авторы: Максим Рябов, Виктория Позднякова, Далгат Ибрагимов (@L0ckR) и Максим Радионов (@tr1ggers) участники профессионального сообщества Сбера DWH/BigData. Профессиональное сообщество DWH/BigData отвечает за развитие компетенций в таких направлениях, как экосистема Hadoop, PostgreSQL, GreenPlum, а также BI‑инструментах Qlik, Apache SuperSet и др.