Вы внедрили 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 выполняется неравенство:
Практический вывод из этой теоремы прост: для любой фиксированной размерности d существуют матрицы релевантности, которые невозможно представить d-мерными embedding'ами. Это не вопрос качества обучения или объёма данных — это математическое ограничение самого подхода.
Более того, чем сложнее структура связей между запросами и документами (чем больше уникальных комбинаций релевантных документов нужно обслужить), тем выше должна быть размерность embedding'а. И в какой-то момент вы упрётесь в потолок, который никакими средствами не преодолеть в рамках single-vector парадигмы.
Эмпирическое доказательство: эксперимент с "идеальной" оптимизацией
Теория — это хорошо, но работает ли это на практике? Исследователи провели эксперимент, который исключает все возможные "отмазки".
Они взяли набор документов и запросов, где каждая возможная комбинация top-2 документов должна быть возвращена каким-то запросом. Затем напрямую оптимизировали векторы градиентным спуском — без ограничений естественного языка, без архитектуры модели, без проблем с данными. Это так называемая free embedding оптимизация: векторы свободны и могут принимать любые значения.
Это идеальный сценарий. Если даже такая оптимизация не справляется — никакая реальная модель не справится. Ведь реальные модели ограничены необходимостью работать с естественным языком, архитектурой encoder'а и качеством обучающих данных.
Результат оказался показательным: при увеличении числа документов в какой-то момент оптимизация перестаёт находить решение, достигающее 100% точности. Исследователи назвали эту точку critical-n — м��ксимальное число документов, для которых данная размерность может представить все комбинации top-2.
Зависимость critical-n от размерности d оказалась полиномиальной третьей степени с формулой 
и коэффициентом детерминации 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
