Почему ваш RAG не найдёт нужные документы: математический потолок embedding-моделей

Вы внедрили RAG в продакшен. Embedding-модель занимает топовые позиции на MTEB, векторная база настроена, chunking оптимизирован. Всё работает. Пока пользователи не начинают жаловаться: "Система не находит очевидные документы". Вы проверяете — документы есть, запросы адекватные. В чём дело?

Исследователи из Google DeepMind нашли ответ в статье "On the Theoretical Limitations of Embedding-Based Retrieval", и он неприятный. Оказывается, embedding-модели имеют фундаментальный математический потолок — и никакие данные, никакое обучение, никакой размер модели его не пробьют. Это не баг. Это геометрия.

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

Как работает dense retrieval

В современных RAG-системах ключевой компонент — embedding-модель. Принцип простой: документы превращаются в векторы фиксированной размерности d (обычно 768, 1024 или 4096), запросы проходят через ту же модель, а система находит документы с наибольшим скалярным произведением (или косинусным сходством) с запросом.

Подход быстрый, масштабируемый и работает "из коробки" на большинстве задач. Поэтому он стал стандартом индустрии. Но есть нюанс.

Все эти годы сообщество исходило из неявного предположения: если модель плохо работает на сложных запросах, значит нужно больше данных, лучше архитектура или больше параметров. Исследование Google DeepMind показало, что это не так. Проблема не в данных и не в архитектуре — она в самой математике подхода.

Формализация проблемы: матрица релевантности и её ранг

Чтобы понять суть ограничения, начнём с формализации. Представьте матрицу релевантности A размером m на n, где m — количество запросов, n — количество документов. Единица в ячейке (i, j) означает, что документ j релевантен запросу i.

Док1 Док2 Док3 Док4 Запрос1 1 1 0 0 Запрос2 1 0 1 0 Запрос3 0 1 1 0 Запрос4 1 0 0 1

Embedding-модель представляет каждый запрос как вектор u размерности d, а каждый документ — как вектор v той же размерности. Релевантность определяется скалярным произведением этих векторов. Если собрать все векторы запросов в матрицу U, а все векторы документов в матрицу V, то матрица скоров будет равна произведению транспонированной U на V.

Здесь возникает ключевой вопрос: какова минимальная размерность d, при которой модель может корректно упорядочить все документы для всех запросов согласно матрице релевантности A?

Авторы вводят понятие row-wise order-preserving rank — минимальный ранг матрицы скоров B, которая сохраняет относительный порядок документов для каждого запроса. Для бинарной матрицы релевантности это эквивалентно row-wise thresholdable rank — минимальному рангу матрицы, которую можно разделить пороговым значением для каждой строки.

Связь с sign-rank: теоретическая основа ограничения

Оказывается, эти понятия тесно связаны с концепцией sign-rank из теории сложности коммуникаций. Sign-rank матрицы M со значениями в {-1, 1} — это минимальный ранг матрицы B, элементы которой имеют тот же знак, что и соответствующие элементы M.

Авторы доказывают фундаментальное соотношение. Для любой бинарной матрицы релевантности A выполняется неравенство:

sign-rank(2A - 1) - 1 <= rankrop(A) = rankrt(A) <= rankgt(A) <= sign-rank(2A - 1)

Практический вывод из этой теоремы прост: для любой фиксированной размерности d существуют матрицы релевантности, которые невозможно представить d-мерными embedding'ами. Это не вопрос качества обучения или объёма данных — это математическое ограничение самого подхода.

Более того, чем сложнее структура связей между запросами и документами (чем больше уникальных комбинаций релевантных документов нужно обслужить), тем выше должна быть размерность embedding'а. И в какой-то момент вы упрётесь в потолок, который никакими средствами не преодолеть в рамках single-vector парадигмы.

Эмпирическое доказательство: эксперимент с "идеальной" оптимизацией

Теория — это хорошо, но работает ли это на практике? Исследователи провели эксперимент, который исключает все возможные "отмазки".

Они взяли набор документов и запросов, где каждая возможная комбинация top-2 документов должна быть возвращена каким-то запросом. Затем напрямую оптимизировали векторы градиентным спуском — без ограничений естественного языка, без архитектуры модели, без проблем с данными. Это так называемая free embedding оптимизация: векторы свободны и могут принимать любые значения.

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

Результат оказался показательным: при увеличении числа документов в какой-то момент оптимизация перестаёт находить решение, достигающее 100% точности. Исследователи назвали эту точку critical-n — максимальное число документов, для которых данная размерность может представить все комбинации top-2.

Зависимость critical-n от размерности d оказалась полиномиальной третьей степени с формулой y = -10.53 + 4.03d + 0.052d^2 + 0.0037d^3 и коэффициентом детерминации 0.999. Экстраполируя эту зависимость, получаем критические значения для типичных размерностей embedding'ов: при 512 измерениях модель может обслужить примерно 500 тысяч документов, при 768 — около 1.7 миллиона, при 1024 — порядка 4 миллионов, при 3072 — около 107 миллионов, а при 4096 — примерно 250 миллионов.

Звучит много? Давайте посчитаем. Если у вас корпус из миллиона документов и вы хотите, чтобы система могла вернуть любую пару документов как top-2 результат, вам понадобится более 768 измерений. Но это при идеальной оптимизации. Реальные модели работают в разы хуже из-за ограничений, связанных с необходимостью работать с естественным языком.

А если у вас веб-поиск с миллиардами документов? Даже 4096-мерные embedding'и (самые большие на рынке) теоретически могут обслужить только 250 миллионов комбинаций в идеальном случае. Это капля в море.

Датасет LIMIT: простейшая задача, которую не решить

Чтобы перевести теорию в практику, исследователи создали датасет LIMIT — Limitations of Instruction-following Models In retrieval Tasks. Задача максимально простая.

Документы выглядят так:

Jon Durben likes Quokkas and Apples. Ovid Rahm likes Quokkas and Rabbits. Leslie Laham likes Apples and Candy. ...

Запросы элементарны:

Who likes Quokkas?

Ответ очевиден: Jon и Ovid.

Это не reasoning, не многошаговый вывод, не сложная логика. Буквально поиск по ключевому слову. Любой первокурсник справится. Grep справится.

Но фокус в том, как устроен датасет. В нём 50 тысяч документов, 1000 запросов, причём каждый запрос имеет ровно 2 релевантных документа. Ключевая особенность: датасет покрывает все 1035 возможных комбинаций из 46 ключевых документов (это C(46,2) = 1035).

Почему именно 46? Потому что исследователи хотели создать датасет с максимальным числом документов, при котором все комбинации top-2 укладываются примерно в 1000 запросов. Датасет специально спроектирован так, чтобы заставить модель представить максимальное число комбинаций.

Стандартные бенчмарки вроде BEIR и MTEB тестируют только выборку возможных комбинаций — поэтому модели на них "переобучаются" и выглядят хорошо. LIMIT же тестирует способность модели представлять все комбинации, что вскрывает фундаментальные ограничения.

Результаты SOTA-моделей на LIMIT

Результаты тестирования современных embedding-моделей на LIMIT оказались катастрофическими. На полном датасете (50k документов) лучшая single-vector модель Promptriever Llama3 8B с размерностью 4096 показала всего 3.0% recall@2. Это означает, что в 97% случаев модель не может найти оба релевантных документа в топ-2 результатов.

Для сравнения: GritLM 7B при той же размерности достиг 2.4%, Gemini Embed с размерностью 3072 показал 1.6%, E5-Mistral 7B — 1.3%, а Qwen3 Embed — и вовсе 0.8%.

Multi-vector модель GTE-ModernColBERT, использующая несколько векторов на документ и механизм MaxSim, справилась значительно лучше — 23.1% recall@2. Это в 7-8 раз лучше лучшей single-vector модели, но всё ещё далеко от идеала.

А теперь главный удар: BM25 — лексический поиск из 90-х годов — показал 85.7% recall@2. Алгоритм без единой нейронной сети побеждает современные 7-миллиардные модели в ~29 раз по этой метрике.

При увеличении k до 100 картина несколько сглаживается: Promptriever достигает 18.9% recall@100, GTE-ModernColBERT — 54.8%, а BM25 — 93.6%. Но разрыв между нейросетевыми embedding-моделями и простым лексическим поиском остаётся колоссальным.

На малом наборе из 46 документов (только те, что релевантны хотя бы одному запросу) результаты лучше, но всё равно далеки от идеала. Лучший single-vector результат — 54.3% recall@2 у Promptriever с размерностью 4096. GTE-ModernColBERT достигает 83.5%. А BM25 снова доминирует с 97.8% recall@2 и идеальными 100% на recall@10 и recall@20.

Интересно, что cross-encoder Gemini-2.5-Pro, получив все 46 документов и все 1000 запросов за один проход, решает задачу на 100%. Это подтверждает, что проблема именно в single-vector архитектуре, а не в сложности самой задачи.

Почему BM25 побеждает нейросети

Ответ прост: размерность.

BM25 работает в пространстве размерности словаря — десятки тысяч измерений. Каждое уникальное слово — отдельное измерение. Благодаря этому BM25 может представить экспоненциально больше комбинаций, чем dense retrieval.

Dense retrieval сжимает всю семантику в 768-4096 измерений. Это отлично для обобщения и работы с синонимами, но создаёт жёсткий потолок на число комбинаций, которые модель способна различить.

Парадокс: сообщество потратило годы, оптимизируя embedding-модели для "понимания смысла", и в процессе потеряло способность находить очевидные совпадения.

Это не проблема данных: доказательство

Резонный вопрос: "Может, модели просто не видели таких примеров при обучении?"

Исследователи проверили эту гипотезу. Они взяли модель lightonai/modernbert-embed-large и дообучили её на тренировочном наборе LIMIT — примеры того же формата, те же типы запросов, просто другие атрибуты. Результат после дообучения на train: около 1% recall@2. Практически без изменений по сравнению с zero-shot результатом.

Для сравнения, когда ту же модель дообучили на тестовом наборе (то есть буквально заставили запомнить ответы), результат составил 96.5% recall@2.

Этот эксперимент доказывает две вещи. Во-первых, проблема не в domain shift. In-domain обучение не помогает, потому что ограничение фундаментальное. Во-вторых, модель физически способна выдать правильные ответы — но только если зазубрит их напрямую, что невозможно в реальных сценариях с новыми запросами.

Интересно, что даже при переобучении на тестовом наборе модели с малой размерностью (32-64) не достигали 100%, что соответствует теоретическим предсказаниям о критических точках.

Влияние паттернов матрицы релевантности

Авторы также исследовали, как структура матрицы релевантности влияет на сложность задачи. Они создали четыре версии LIMIT с разными паттернами qrel-матрицы: random (случайная выборка комбинаций), cycle (циклический паттерн, где каждый следующий запрос делит один документ с предыдущим), disjoint (каждый запрос релевантен уникальной паре документов) и dense (все возможные комбинации, стандартный LIMIT).

Результаты показали разительную разницу. На random, cycle и disjoint паттернах модели показывают сопоставимые результаты: E5-Mistral достигает около 40% recall@100. Но на dense паттерне результаты падают до 4.8% recall@100 — почти в 10 раз хуже.

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

Отсутствие корреляции с BEIR

Авторы сравнили результаты моделей на LIMIT с их результатами на BEIR — популярном бенчмарке из MTEB. Корреляция оказалась практически нулевой.

Qwen3 Embed с лучшим результатом 62.76 на BEIR показывает худший результат 4.8% на LIMIT. Promptriever с более скромным 56.40 на BEIR лидирует на LIMIT с 18.9%. Snowflake Arctic имеет низкие результаты на обоих бенчмарках, вероятно, из-за меньшей размерности embedding'а и объёма предобученной модели.

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

Связь с существующими датасетами

Почему эта проблема не проявлялась раньше? Авторы проанализировали структуру существующих IR-датасетов через метрики плотности графа qrel-матрицы.

Они ввели две метрики: Graph Density (плотность графа, где узлы — документы, а рёбра соединяют документы, релевантные одному запросу) и Average Query Strength (средняя сила связи между запросами через общие релевантные документы).

Natural Questions имеет нулевую плотность графа — каждый запрос релевантен уникальным документам. HotPotQA показывает плотность 0.000037 и среднюю силу запроса 0.11. SciFact немного выше: 0.001449 и 0.42. FollowIR Core17 — instruction-following датасет — показывает 0.026 и 0.59.

LIMIT же имеет плотность 0.085 и среднюю силу запроса 28.47 — на два порядка выше, чем у ближайшего конкурента. Именно эта высокая связность делает LIMIT сложным для embedding-моделей.

Датасеты вроде QUEST с его 325k документами и логическими операторами в запросах теоретически содержат астрономическое число возможных комбинаций (C(325k, 20) = 7.1e91 — больше, чем оценка числа атомов в наблюдаемой Вселенной). Но на практике тестируется лишь 3357 запросов — бесконечно малая доля пространства.

Когда это ваша проблема

Ограничение становится критичным в определённых сценариях. Если вы используете только bi-encoder без reranking, если ваши запросы содержат редкие или специфичные термины (точные имена, коды, идентификаторы), если критичен recall в первых 1-2 результатах, если запросы содержат логические операторы или требуют объединения несвязанных документов — будьте готовы к проблемам.

Типичные примеры критичного использования: поиск в медицинских базах по редким диагнозам или кодам МКБ, юридический поиск по статьям законов и номерам дел, поиск в коде по конкретным функциям и переменным, финансовые системы с номерами счётов и точными суммами.

Ограничение менее критично при гибридном подходе (BM25 + neural), при корпусе до 100k документов, когда достаточен recall@10-100, и при описательных запросах без требования точного соответствия.

Ограничение практически не влияет на стандартный поиск типа "найди информацию про X", когда dense retrieval служит первой стадией перед reranking, когда запросы семантически похожи на текст документов, и когда допустима неполнота результатов.

Альтернативы: как обойти ограничение

Cross-encoders

Cross-encoder сравнивает пару "запрос + документ" напрямую, без промежуточного представления в виде отдельных векторов. Модель видит оба текста одновременно и принимает решение о релевантности напрямую, что полностью обходит ограничение размерности embedding'а.

На LIMIT small cross-encoder Gemini-2.5-Pro решает задачу на 100%, обрабатывая все 46 документов и 1000 запросов за один проход. Это доказывает, что задача тривиальна для архитектур без ограничения размерности.

Главный недостаток cross-encoder'ов — вычислительная сложность. Нужно прогнать каждую пару запрос-документ через модель, что делает их непригодными для первичного поиска по миллионам документов. Но как вторая стадия после dense retrieval они незаменимы.

Multi-vector модели (ColBERT)

Multi-vector модели используют несколько векторов на документ (обычно по вектору на токен) вместо одного. Сравнение происходит через механизм MaxSim — сумму максимумов попарных сходств между токенами запроса и документа.

На LIMIT GTE-ModernColBERT показывает 54.8% recall@100 — в 3 раза лучше лучшей single-vector модели. Это значительный прогресс, хотя и далеко от идеала.

Преимущества multi-vector моделей: они быстрее cross-encoder'ов, но выразительнее single-vector. Недостатки: требуют больше памяти (нужно хранить N векторов вместо одного на документ), медленнее dense retrieval, и пока менее исследованы для instruction-following и reasoning задач.

Sparse и лексические методы

BM25 и нейронные sparse модели работают в пространстве высокой размерности (размер словаря — десятки тысяч измерений). Это позволяет им представлять экспоненциально больше комбинаций.

На LIMIT BM25 достигает 93.6% recall@100 — с огромным отрывом от всех нейросетевых моделей.

Недостатки sparse методов хорошо известны: они не работают с семантикой (синонимы, парафразы), плохо справляются с многоязычными сценариями и требуют точного совпадения терминов. Но для задач с чёткими ключевыми словами они остаются непревзойдёнными.

Гибридный подход

На практике имеет смысл комбинировать подходы в многоэтапном pipeline. Сначала dense retrieval отсекает до 500-1000 кандидатов — это быстро и масштабируемо. Затем BM25 или sparse модель добавляет дополнительных кандидатов через объединение множеств. Наконец, cross-encoder или ColBERT переранжирует до финальных 10-20 документов.

Такой pipeline использует скорость dense retrieval для первичного отсечения, добавляет sparse для покрытия edge cases с точным соответствием терминов, и гарантирует точность через reranking.

Да, это сложнее и медленнее, чем чистый dense retrieval. Но если вам нужна надёжность на сложных запросах — альтернативы нет.

Как протестировать свою RAG-систему

Хотите понять, насколько ваша система близка к ограничениям?

Протестируйте вашу embedding-модель на LIMIT. Датасет доступен на GitHub. Если результаты близки к таблицам из статьи — ваша модель работает на уровне SOTA. Если сильно хуже — проблема в чём-то другом помимо фундаментальных ограничений.

Измерьте комбинаторную сложность вашего корпуса. Сколько уникальных пар или троек документов реально возвращаются как top-k? Если это число растёт быстрее, чем позволяет ваша размерность согласно формуле critical-n, ждите проблем.

Отслеживайте деградацию recall при изменении k. Если recall@2 значительно хуже recall@10, а recall@10 значительно хуже recall@100 — это сигнал, что модель не справляется с комбинаторикой.

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

Будущее: куда движется индустрия

Исследование показывает, что single-vector парадигма имеет фундаментальный потолок. Это не вопрос улучшения моделей — это математическое ограничение подхода.

Multi-vector модели станут важнее. Ожидайте ColBERT-подобные архитектуры не только для информационного поиска, но и для reasoning и instruction-following задач.

Гибридные системы станут стандартом. Комбинация dense + sparse + reranking превратится из опции в baseline для production-систем.

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

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

Выводы

Embedding-модели имеют математический потолок на число комбинаций релевантности, которые они могут представить. Это не баг реализации — это следствие sign-rank матрицы релевантности и фундаментальных ограничений представления информации в пространстве фиксированной размерности.

Потолок реален и достижим в практических сценариях. Датасет LIMIT показывает, что даже тривиальная задача поиска по ключевому слову становится нерешаемой для SOTA-моделей, когда требуется покрыть все комбинации релевантных документов.

Увеличение размерности помогает, но не решает проблему фундаментально. Даже 4096-мерные embedding'и недостаточны для веб-масштаба при идеальной оптимизации, а реальные модели работают в разы хуже.

Гибридные подходы — практическое решение. Dense retrieval для скорости, sparse для покрытия edge cases с точными терминами, reranking для финальной точности.

BM25 рано хоронить. В определённых сценариях лексический поиск из 90-х превосходит современные LLM-based embedding'и на порядки.

Если вы внедряете RAG — не полагайтесь на embedding-модель как единственный источник истины. Добавьте reranking. Добавьте sparse retrieval. Мониторьте комбинаторную сложность ваших запросов. И помните: иногда grep работает лучше GPT.

Об исследовании

Название: On the Theoretical Limitations of Embedding-Based Retrieval

Авторы: Orion Weller (Google DeepMind, Johns Hopkins University), Michael Boratko, Iftekhar Naim, Jinhyuk Lee (Google DeepMind)

Дата: август 2025

arXiv: 2508.21038v1 [cs.IR]

Абстракт и метаданные: Страница на arXiv

Код и датасет: github.com/google-deepmind/limit