Главная / Статьи / За пределами Top-K: пороги релевантности, гибридный поиск и переранжирование в RAG

RAGLLMRetrievalRerankingHybrid SearchAI Engineering

За пределами Top-K: пороги релевантности, гибридный поиск и переранжирование в RAG

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

1628 слов

Метод генерации с усилением на основе поиска обычно описывается как трехэтапный процесс: поиск документов, связанных с вопросом, передача их языковой модели и запуск процесса написания ответа. Сама схема кажется простой, но сделать её надежной — сложно. Пайплайн, соединяющий поиск с использованием эмбеддингов непосредственно с ЯЗЫКОВОЙ МОДЕЛЬЮ, будет уверенно отвечать даже при слабом контексте, пропускать точные идентификаторы и выдумывать ответы, когда в базе знаний нет соответствующей информации. Именно здесь ломается такой наивный дизайн, и какие этапы — от разбиения текста с учётом структуры до объективной оценки — превращают его в надёжную архитектуру поиска.

Наивный пайплайн и его скрытые предположения

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

Разделение по структуре документа

Возьмем руководство для сотрудников. Слабый подход предполагает его разделение на произвольные фрагменты по 1000 символов, что приводит к тому, что правила могут быть разделены пополам, а конец одной темы прикрепляется к началу другой. Более эффективный подход учитывает собственную структуру документа, формируя такие фрагменты, как «Работа из дома», «Безопасность», «Отпуск и расходы».

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

Метод Top-K возвращает самые близкие результаты, а не наиболее релевантные

Лучшие фрагменты текста могут привести к новым заблуждениям. Установка параметра top_k = 5 часто интерпретируется как «дайте мне пять релевантных результатов». На самом деле этот параметр запрашивает пять самых близких по значению результатов, независимо от того, являются ли они релевантными или нет. Типичное распределение баллов для вопроса о удаленной работе может выглядеть следующим образом:

Remote Work       0.62
Paid Time Off     0.36
Security          0.30
Expenses          0.28
Other Policy      0.24

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

Вопросы, на которые невозможно ответить, требуют особого подхода

Особенно важным случаем является вопрос, на который база знаний просто не может ответить, например: «Каков лимит оплаты из собственных средств по страховке здоровья компании?», если в руководстве об этом нигде не упоминается. Метод Top-K всё равно вернёт пять результатов, и примитивная система обработки будет рассматривать наиболее близкий к ответу вариант как доказательство и делать предположение.

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

No sufficiently relevant context was found.

Добавление фильтра релевантности между поиском и моделью

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

Vector Search
   ↓
Top-K
   ↓
LLM

Улучшенный алгоритм рассматривает список Top-K как кандидатов и вставляет фильтр перед моделью:

Vector Search
   ↓
Top-K candidates
   ↓
Relevance Filter
   ↓
LLM

Самым простым фильтром является порог сходства. Кандидаты, соответствующие этому порогу или превосходящие его, сохраняются:

score >= threshold
    → keep

А все, что ниже этого порога, отбрасывается:

score < threshold
    → discard

Если никто не остается, система возвращает ответ «нет релевантного контекста» вместо того, чтобы запускать модель с шумными данными.

Выбор порога на основе измерений

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

| Threshold | Known-query recall | Unknown-query rejection |
| --------: | -----------------: | ----------------------: |
|      0.20 |               100% |                      0% |
|      0.25 |               100% |                      0% |
|      0.30 |               100% |                     50% |
|      0.35 |               100% |                     50% |
|      0.40 |               100% |                     50% |
|  **0.45** |           **100%** |                **100%** |
|      0.50 |               100% |                    100% |
|      0.55 |               100% |                    100% |

В этом наборе данных порог 0.45 стал первым значением, которое позволило сохранить все известные запросы и отклонить все неизвестные, что сделало его лучшим вариантом среди протестированных значений. Однако это число не является универсальным. Оценки сходства зависят от модели вкладки, корпуса данных, формулировок запросов и настроек поиска; разные модели дают совершенно разные диапазоны значений. Тот факт, что показатель отклонения меняется с шагом в 50%, также указывает на очень малое количество неизвестных запросов, поэтому для реального использования требуется более крупный набор меткированных данных перед тем, как можно будет доверять этому порогу. То, что может быть перенесено, — это метод: измерять поведение системы поиска для известных и неизвестных запросов и выбирать порог на основе полученных данных, а не интуиции.

Поиск и ранжирование — это разные задачи

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

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

10,000 chunks
      ↓
retrieval
      ↓
50 candidates

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

50 candidates
      ↓
reranker
      ↓
5 strongest candidates

Теперь структура работы выглядит следующим образом:

Question
   ↓
Embedding
   ↓
Vector / Hybrid Search
   ↓
Candidate Set
   ↓
Reranking
   ↓
Best Context
   ↓
LLM

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

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

INC-48271
ERR_CONNECTION_RESET
POL-104
AWS us-east-1
customer_12345

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

Гибридный способ поиска объединяет оба сигнала

Стандартным решением является гибридный поиск, при котором одновременно выполняются семантический и лексический поиск:

Semantic Search
+
Keyword / Lexical Search

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

Question
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
   Semantic Search      Keyword Search
          │                   │
          └─────────┬─────────┘
                    ↓
              Candidate Set

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

Инфраструктура, ориентированная на производство

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

Documents
    ↓
Semantic Chunking
    ↓
Embeddings
    ↓
Vector / Hybrid Retrieval
    ↓
Relevance Filtering
    ↓
Reranking
    ↓
LLM
    ↓
Answer + Sources
    ↓
Evaluation + Observability

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

Базовая версия, которую стоит создать в первую очередь

Хороший способ изучить эти компромиссы — постепенно разрабатывать решение. Простая базовая версия может включать Python, FastAPI, эмбеддинги от OpenAI и LLM, а также Pinecone в качестве хранилища векторов, плюс:

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

Порядок работы такой системы следующий:

Question
   ↓
Embedding
   ↓
Pinecone Retrieval
   ↓
Top-K Candidates
   ↓
Similarity Threshold
   ↓
Relevant Context
   ↓
LLM
   ↓
Answer + Sources

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

Оценка надежности системы

Вопрос «Работает ли чат-бот?» не является полезным. Разделим его на показатели, которые можно измерить:

  • Качество поиска: была ли вообще получена правильная информация?
  • Качество ранжирования: находится ли самый полезный контекст ближе к верху списка?
  • Обоснованность ответа: подкреплен ли ответ полученным контекстом?
  • Точность цитирования: подтверждают ли приведенные источники сделанные утверждения?
  • Обработка неизвестных запросов: способна ли система распознать, когда ответ отсутствует в базе знаний?
  • Задержка: сколько времени в сумме занимают процессы поиска и генерации?
  • Стоимость: сколько стоит каждый запрос?

    • Цель меняется с «может ли приложение отвечать на вопросы?» на «можем ли мы оценить надежность архитектуры поиска?»

    Основные выводы

    • RAG — это не просто предоставление LLM доступа к документам; ключевыми решениями являются определение того, что искать, чему доверять, что передавать и когда отклонять.
    • top_k гарантирует количество результатов, а не их релевантность, поэтому необходимо фильтровать кандидатов с использованием порога, настроенного на ваших собственных данных.
    • Гибридный поиск позволяет находить точные идентификаторы, которые смазываются при использовании эмбеддингов, а переранжирование превращает широкий набор кандидатов в точный контекст.
    • Качество ответа во многом определяется еще до того, как модель увидит контекст: лучший контекст приводит к лучшим ответам и более надежным системам.
    • Рассматривайте производственную систему RAG как архитектурную проблему с измеримыми этапами, а не как простую интеграцию одной большой языковой модели.

    Связанные статьи

    Все статьиПрислать бриф