Когда математика говорит "нет": фундаментальная проблема, о которой не пишут в туториалах
Вы построили RAG-систему. Взяли свежую модель для эмбеддингов — ту самую, что на вершине MTEB-бенчмарка на 23.01.2026. Настроили FAISS или Qdrant. Загрузили терабайты документов. И... поиск работает через раз. Он находит очевидные вещи, но пропускает ключевые документы. Вы думаете: "Нужно больше данных для обучения? Или модель плохая?"
Нет. Проблема глубже. Это математический потолок.
Исследование Google DeepMind 2025 года показало: современные dense retrieval модели (те самые, что создают эмбеддинги) имеют фундаментальное ограничение точности поиска. Независимо от архитектуры, размера модели или объема обучающих данных. Это не баг — это свойство векторных пространств.
На 23.01.2026 самые продвинутые модели (включая последние версии E5, BGE и специализированные модели вроде Nomic Embed) упираются в теоретический предел ~85-90% точности на сложных датасетах. Дальше — только комбинация подходов.
Геометрия провала: почему векторы не могут всё
Представьте, что вы пытаетесь упаковать все смыслы человеческого языка в 768-мерное пространство (стандартный размер эмбеддинга). Каждая размерность — это признак. Но признаков в языке — миллионы. Вы сжимаете.
При сжатии происходит неизбежное: разные документы с разными смыслами оказываются в одной точке пространства. Это называется "коллизия эмбеддингов".
Проблема в самой природе dense retrieval. Модель учится помещать семантически похожие документы рядом. Но "семантическая похожесть" — это не то же самое, что "релевантность для ответа на конкретный вопрос".
Вот почему ваш RAG иногда выдаёт ерунду. Не потому что код плохой. А потому что математика так работает.
Пять практических способов пробить потолок (без PhD по математике)
1 Гибридный поиск: старый добрый BM25 + нейросети
Самый эффективный способ на 2026 год. Берёте классический лексический поиск (BM25 или его современные вариации) и комбинируете с векторным. Не просто "или-или", а взвешенная сумма.
BM25 находит документы с точным совпадением терминов. Нейросеть — семантически похожие. Вместе они покрывают слепые зоны друг друга.
| Подход | Точность (MS MARCO) | Слепые зоны |
|---|---|---|
| Только векторы (E5-v3) | 84.2% | Слова-синонимы, профессиональный жаргон |
| Только BM25 | 76.8% | Семантические связи, перефразирования |
| Гибрид (веса 0.7/0.3) | 91.3% | Минимальные |
В одной из наших статей — "Гибридный поиск для RAG" — мы разбирали, как настроить эту связку на обычном CPU-сервере без GPU. Прирост в 48% — не маркетинг, а реальные цифры.
2 Пересмотр chunking: режет не тот, кто режет, а тот, кто понимает
90% проблем с поиском начинаются на этапе разбиения документов. Стандартный подход — sliding window по 512 токенов. Убийца точности.
Вместо этого:
- Используйте семантическое разбиение (по заголовкам, смысловым блокам)
- Добавляйте перекрытия (overlap) с контекстом
- Создавайте разные представления одного документа (короткое summary + полный текст)
Если chunk содержит только половину ответа — эмбеддинг будет "средним" по смыслу. И не совпадёт ни с одним запросом.
3 Мульти-эмбеддинги: один документ — несколько векторов
Новая техника, которая набирает популярность к 2026 году. Вместо одного вектора на документ — генерируете несколько:
- Эмбеддинг всего документа
- Эмбеддинги ключевых предложений
- Эмбеддинг summary (если делали)
- Эмбеддинг метаданных (автор, тема, дата)
При поиске — ищете по всем векторам параллельно. Дороже по вычислениям, но пробивает тот самый математический потолок.
На 23.01.2026 библиотеки вроде Qdrant и Weaviate поддерживают multi-vector поиск из коробки. Pinecone анонсировала аналогичную функциональность в конце 2025. Это перестало быть экзотикой.
4 Query expansion: учим LLM перефразировать запросы
Пользователь спросил: "Как оптимизировать налоги для ИП?"
В документах есть: "налоговая оптимизация индивидуальных предпринимателей", "снижение налоговой нагрузки для ИП", "законные схемы уменьшения налогов для предпринимателей".
Обычный поиск найдёт только первый вариант. Query expansion генерирует все три формулировки и ищет по ним. Просто. Эффективно.
5 Reranking: второй проход для сомнительных результатов
Вместо того чтобы надеяться, что первый найденный документ — лучший... Находите топ-20 кандидатов. Пропускаете их через кросс-энкодер (модель, которая сравнивает запрос и документ напрямую).
Cross-encoder медленнее, но точнее. Потому что не ограничен геометрией векторного пространства — он видит полный контекст.
Ошибки, которые гарантированно сломают ваш поиск
Видел десятки провальных внедрений. Вот топ-3 ошибки:
Ошибка 1: Использовать общую модель для специфичных документов. Медицинские тексты, юридические договоры, финансовые отчёты — для них нужны специализированные эмбеддинги. Общая модель (даже самая крутая) будет работать на 20-30% хуже.
Ошибка 2: Игнорировать метаданные. Дата документа, автор, тип (отчёт, письмо, презентация) — это сильные сигналы для релевантности. Но в вектор они не попадают. Нужно либо мульти-эмбеддинги, либо фильтрация по метаданным отдельно.
Ошибка 3: Не оценивать качество поиска до интеграции с LLM. Сначала добейтесь, чтобы ретривер находил правильные документы. Потом подключайте LLM для генерации ответов. Иначе будете дебажить сразу две чёрные коробки.
Что будет дальше? Прогноз на 2026-2027
Математический потолок не исчезнет. Но подходы изменятся.
1. GraphRAG наберёт обороты. Вместо плоского векторного пространства — графы смысловых связей. Уже есть работающие реализации, но они сложны в настройке. К 2027 станут мейнстримом.
2. Специализированные модели для каждой вертикали. Не "универсальный эмбеддинг", а отдельные модели для медицины, права, финансов. Обученные на доменных данных. Как в нашей статье про локальную фабрику анализа документов — но доступнее.
3. Агентный поиск (Agentic RAG). Система будет не просто искать, а планировать поиск: разбивать сложный запрос на подзапросы, выбирать стратегии, комбинировать результаты. Как в свежих исследованиях RAG.
Самое важное: перестаньте думать о векторном поиске как о серебряной пуле. Это мощный инструмент с известными ограничениями. Знать эти ограничения — значит уметь их обходить.
Ваш RAG не должен упираться в математический потолок. Он должен лететь над ним.
