Магия, которая перестала работать
Вы загружаете документы в векторную базу, запускаете запрос — и получаете идеально релевантные фрагменты. Так обещает маркетинг. Так показывают демки. Так не работает в продакшене.
Проблема в том, что мы переоценили эмбеддинги. Представили их как волшебную палочку, которая превращает любой текст в идеальный числовой отпечаток смысла. А на деле получили инструмент с фундаментальными ограничениями, которые бьют по точности поиска там, где это больнее всего.
Если ваш RAG иногда возвращает странные результаты — это не баг системы. Это системная ошибка подхода, основанного исключительно на эмбеддингах.
Что на самом деле делает эмбеддинг-модель
Возьмем предложение "Собака бежит за мячом". Современная модель типа BGE-M3 или OpenAI embeddings превращает его в вектор из 1536 чисел. Каждое число — не "смысл слова", а статистическая закономерность, выученная на миллиардах текстов.
Модель не понимает собак, мячей или бега. Она знает, что слова "собака", "кошка", "животное" часто встречаются вместе. Что "бежит", "идет", "двигается" образуют другой кластер. Что эти кластеры в многомерном пространстве имеют определенные расстояния.
Пять смертных грехов векторного поиска
1. Проклятие многозначности
Слово "банк" — финансовое учреждение или берег реки? В эмбеддинге это один вектор, усредненный между всеми значениями. Запрос "открыть счет в банке" может найти документы про рыбалку на берегу.
Проблема обостряется с профессиональной лексикой. "Кран" в строительстве и "кран" в сантехнике. "Ядро" в программировании и "ядро" в физике. Модели, обученные на общих данных, не различают контексты.
2. Синтаксис против семантики
"Как установить Python?" и "Установка Python: руководство" — семантически идентичные запросы. Но их эмбеддинги могут быть дальше, чем "Как установить Python?" и "Как удалить Python?".
Потому что модели чувствительны к формулировкам. Вопросительная форма против утвердительной. Наличие двоеточия. Порядок слов. Все это влияет на вектор сильнее, чем должно.
| Запрос | Косинусное сходство | Проблема |
|---|---|---|
| "Как установить Python на Windows?" | 0.92 | С тем же документом |
| "Установка Python для Windows" | 0.78 | С тем же документом! |
| "Python инсталляция Windows" | 0.65 | Пропущено в топ-10 |
3. Длина имеет значение (к сожалению)
Короткий запрос "ошибка 404" и длинный документ про HTTP статус-коды могут иметь низкое косинусное сходство. Потому что эмбеддинг усредняет все слова документа. Детальное описание "разбавляется" техническими деталями.
Обратная проблема: длинный запрос "Как исправить ошибку 404 на сайте WordPress при загрузке изображений?" может не найти краткую инструкцию "404 ошибка — проверьте права файлов", потому что в запросе слишком много специфичных слов.
4. Нулевая чувствительность к числам и датам
Запрос "Python 3.11" и документ про "Python 3.10" будут иметь почти идентичные эмбеддинги. Модели не умеют различать версии, даты, суммы, проценты. Числа для них — шум.
Это убийственно для финансовых, технических, научных систем. Документ про "рост на 5%" и "падение на 5%" получат схожие векторы. Потому что "5%" доминирует над семантикой роста/падения.
5. Культурные и языковые слепые зоны
Модели, обученные преимущественно на английских данных, плохо работают с другими языками. Русские идиомы, профессиональный сленг, местные реалии — все это теряется при переводе в вектор.
"Битый пиксель" и "мертвый пиксель" в русском — синонимы. Для англоязычной модели это разные концепции. Результат? Пропущенные релевантные документы.
Как это ломает ваш RAG
Каждая из этих проблем по отдельности снижает точность на 5-10%. Вместе они создают эффект "накопленной погрешности". Система вроде работает, но постоянно ошибается в критичных местах.
1 Проблема: ложные срабатывания
RAG находит документы, которые кажутся релевантными по векторной близости, но не отвечают на вопрос. LLM получает мусор на вход и генерирует мусор на выходе.
Классический пример из статьи про деградацию поиска: база с 10 документами работает идеально. С 10 000 — начинает "врать". Потому что статистические шумы накапливаются.
2 Проблема: пропуски
Самый важный документ не попадает в топ-k результатов. LLM не видит критической информации и вынуждена "выдумывать" ответ. Или, что хуже, дает уверенный неправильный ответ.
В медицинских, юридических, финансовых системах это не просто неточность. Это опасность.
Худшее в этой ситуации: вы не знаете, что пропустили. Система уверенно возвращает результат, а вы не видите, какой документ мог бы дать правильный ответ.
Что делать? Стратегии выживания
Смириться? Ни в коем случае. Есть рабочие стратегии, которые снижают риски.
Гибридный поиск — не модное слово, а необходимость
Векторный поиск плюс полнотекстовый (BM25, SPLADE, ColBERT). Как в гибридном поиске для RAG.
Почему это работает:
- BM25 ловит точные совпадения терминов, дат, версий
- Векторный поиск ловит семантические связи
- Их комбинация покрывает слепые зоны друг друга
Реализация проще, чем кажется. Веса можно подбирать автоматически на валидационной выборке.
Переобучение эмбеддингов на своих данных
Берете готовую модель типа BGE-M3 и дообучаете на вашей предметной области. Как в Self-Supervised Learning на практике.
Что это дает:
- Модель учит вашу терминологию
- Улучшает различение многозначных слов в вашем контексте
- Повышает чувствительность к важным для вас сущностям
Не нужно размеченных данных. Контрастивное обучение на парах "похожих" документов, которые система находит сама.
Рерайт запросов — дешево и эффективно
Пользователь спрашивает "Как починить кран?". Система переписывает запрос в "Ремонт сантехнического крана инструкция" и "Ремонт строительного крана руководство". Ищет оба варианта.
Маленькая LLM (Qwen2.5-1.5B) справляется с этой задачей. Стоимость — копейки. Эффект — значительный.
Мультивекторные стратегии
Вместо одного эмбеддинга на документ — несколько:
- По заголовкам
- По ключевым предложениям
- По извлеченным сущностям (даты, имена, версии)
- По суммаризации разной длины
Запрос ищется по всем этим представлениям. Дорого по хранению, но точно.
Ручная настройка весов для важных терминов
Знаете, что в вашей предметной области версии ПО критичны? Добавьте правило: если в запросе есть "Python 3.11", бустите документы с этой версией.
Это хардкод. Это не масштабируется. Но это работает прямо сейчас, пока вы не обучили лучшую модель.
Выбор модели: иллюзия выбора
BGE-M3, EmbeddingGemma, Qwen3, OpenAI — все они страдают одними проблемами. Разница в степени, не в сути.
Как выбрать? Смотрите сравнение эмбеддинг-моделей. Но помните: даже лучшая модель не решит фундаментальных проблем.
| Модель | Размерность | Сильная сторона | Проблема с многозначностью |
|---|---|---|---|
| BGE-M3 | 1024 | Мультиязычность | Средняя |
| EmbeddingGemma | 1024 | Английский текст | Высокая |
| Qwen3-Embedding | 1536 | Контекстное понимание | Низкая |
| OpenAI text-embedding-3 | 1536 | Общее качество | Средняя |
Что будет дальше? Будущее после эмбеддингов
Эмбеддинги — это промежуточная технология. Как поиск по ключевым словам в 90-х. Работает, но ограниченно.
На горизонте:
- Прямое ранжирование LLM: вместо векторов — большая модель оценивает релевантность напрямую. Дорого, но точно
- Нейросетевые индексы: эмбеддинг + внимание к конкретным частям документа
- Мультимодальные представления: текст + структура + граф связей
- Агентный поиск: как в агентных RAG системах — несколько специализированных поисковых агентов вместо одного универсального
Самая опасная позиция — считать, что текущие эмбеддинги "достаточно хороши". Они не являются. И пока вы читаете эту статью, кто-то уже строит систему, которая обойдет вашу благодаря лучшему поиску.
Практический чеклист на сегодня
Что можно сделать прямо сейчас, без переписывания архитектуры:
- Добавьте BM25 или другой полнотекстовый поиск рядом с векторным
- Настройте взвешенное объединение результатов (start с 50/50)
- Создайте тестовый набор из 100 сложных запросов с известными правильными ответами
- Измерьте точность только векторного поиска, только полнотекстового и их комбинации
- Для критичных терминов (версии, даты, суммы) добавьте правила ручного бустинга
- Рассмотрите рерайт запросов через маленькую LLM для многозначных терминов
- Протестируйте разные эмбеддинг-модели на ваших данных, а не на стандартных бенчмарках
И главное — перестаньте верить в магию эмбеддингов. Это инструмент со своими ограничениями. Как молоток: гвозди забивает отлично, шурупы — плохо.
Эмбеддинги не идеальны. Они никогда не будут идеальными. Но понимая их ограничения, можно строить системы, которые работают несмотря на эти ограничения. Или даже благодаря им — потому что знаешь, где подстелить соломку.
Следующий шаг? Посмотрите роадмап RAG на 2026. Там есть ответы на вопросы, которые вы еще не успели задать.
