Embeddings и reranker для локального RAG: как выбрать модели и не испортить поиск

Что такое embedding-модель

Embedding-модель не пишет обычный текстовый ответ. Она превращает текст в числовой вектор — набор координат, описывающий его семантическое содержание.

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

Embedding используется не только для RAG:

• semantic search;
• поиск похожих документов;
• кластеризация;
• дедупликация;
• classification;
• memory для AI-агентов;
• поиск по коду;
• translation memory.

Где embeddings находятся в RAG pipeline

Когда приходит вопрос, система строит embedding уже для запроса и ищет ближайшие vectors в базе.

Именно поэтому слабый retrieval невозможно полностью исправить хорошей LLM. Если нужный fragment вообще не попал в контекст, генеративной модели нечего анализировать.

Что делает reranker

Vector search должен быстро просмотреть тысячи или миллионы chunks. Поэтому embedding retrieval — компромисс между скоростью и точностью.

Reranker работает позже: получает один query и уже небольшой список кандидатов, после чего оценивает каждую пару query + document более дорогой моделью.

Что выбрать для локального RAG в 2026 году

Qwen3 Embedding: почему серия удобна для локального RAG

Официальная серия Qwen3 Embedding включает embedding и reranking models размером 0.6B, 4B и 8B.

Серия поддерживает Matryoshka Representation Learning (MRL): можно использовать меньшую выходную размерность вместо максимальной. Это позволяет балансировать качество, размер vector index и скорость.

Qwen также указывает поддержку 100+ языков и рекомендует task-specific instructions. По данным собственной оценки Qwen, использование инструкции в большинстве downstream tasks давало улучшение порядка 1–5%, но это результат разработчика модели, а не универсальная гарантия для любого corpus.

Запуск 0.6B через Ollama

ollama pull qwen3-embedding:0.6b

curl http://localhost:11434/api/embed -d '{
  "model": "qwen3-embedding:0.6b",
  "input": "Почему срабатывает УЗО?"
}'

EmbeddingGemma: маленькая embedding-модель Google

Google описывает EmbeddingGemma как открытую embedding-модель примерно 300M параметров, ориентированную на on-device сценарии: мобильные устройства, ноутбуки и desktops.

Она обучена для 100+ разговорных языков и предназначена для:

• semantic search;
• retrieval;
• classification;
• clustering;
• semantic similarity.

В текущей документации Ollama embeddinggemma входит в список рекомендованных embedding models наряду с qwen3-embedding и all-minilm.

ollama pull embeddinggemma
ollama run embeddinggemma "Проверка семантического поиска"

Qwen3 Reranker: второй этап поиска

В той же серии Qwen доступны rerankers 0.6B, 4B и 8B с context до 32K. Они instruction-aware и предназначены для text ranking.

Для домашнего RAG разумно начинать с 0.6B: reranker обрабатывает только несколько десятков candidates, но делает это для каждого пользовательского запроса.

Увеличивать reranker до 4B/8B стоит только после измерений: дополнительная latency должна давать реальный прирост Recall/MRR/NDCG на вашей базе.

Embeddings через Ollama: актуальный API

В текущем Ollama используется endpoint POST /api/embed. Старый /api/embeddings считается устаревшим.

Одна строка

curl http://localhost:11434/api/embed -d '{
  "model": "embeddinggemma",
  "input": "Как выбрать автоматический выключатель?"
}'

Batch embeddings

curl http://localhost:11434/api/embed -d '{
  "model": "embeddinggemma",
  "input": [
    "УЗО реагирует на ток утечки.",
    "Автомат защищает линию от перегрузки и короткого замыкания.",
    "УЗИП ограничивает импульсное перенапряжение."
  ]
}'

Текущий API также поддерживает параметр dimensions для моделей, которые допускают изменение размерности.

1024, 2560 или 4096 dimensions: больше не всегда лучше

Размерность embedding — количество чисел в векторе. Чем больше dimensions, тем больше:

• объём vector database;
• RAM для индекса;
• network/storage traffic;
• стоимость similarity search.

При миллионах chunks разница становится существенной.

Например, 1 000 000 vectors × 1024 float32 — уже примерно 3.8 ГиБ только сырого массива координат, до индекса и metadata.

Поэтому MRL интересен именно practically: если модель поддерживает сокращённую размерность, можно подобрать баланс retrieval quality ↔ index size.

Почему документы и запросы нужно кодировать одной моделью

Ollama прямо рекомендует использовать одну и ту же embedding model и для индексирования, и для пользовательских запросов.

Векторы разных моделей живут в разных representation spaces. Даже одинаковая размерность не делает их совместимыми.

Когда нужно полностью переиндексировать RAG-базу

Переиндексация нужна, если вы меняете:

• embedding model;
• embedding dimension;
• существенно меняете preprocessing;
• chunking strategy;
• нормализацию/формат входа, если он влияет на embeddings;
• instruction scheme у instruction-aware модели.

Cosine similarity: что именно сравнивает vector DB

Cosine similarity сравнивает направление векторов, а не их абсолютную длину. Для L2-normalized embeddings cosine особенно удобен.

Чем ближе значение к максимальному similarity вашей системы, тем семантически ближе embeddings. Но не используйте один фиксированный threshold из чужой статьи: распределение scores зависит от модели, domain и corpus.

Хорошая embedding-модель не спасёт плохой chunking

Если chunk содержит три несвязанные темы или обрывает важное определение пополам, embedding честно представляет этот плохой фрагмент.

Проверяйте:

• размер chunks;
• semantic boundaries;
• заголовки;
• metadata;
• overlap;
• таблицы и списки;
• OCR-ошибки;
• дубли страниц.

Для технических документов полезно хранить вместе с chunk название документа, раздел, дату, страницу и тип материала — потом это можно использовать для filters/reranking.

Dense retrieval + BM25: зачем гибридный поиск

Embeddings хорошо находят смысл. Но точные идентификаторы, артикулы, номера нормативов и редкие обозначения иногда лучше ищутся keyword/BM25 методом.

Для технической базы hybrid retrieval часто разумнее чистого vector search. Reranker затем может объединить кандидатов и выбрать лучший контекст.

Как запустить локальный reranker

Qwen3-Reranker-0.6B поддерживается через Sentence Transformers как CrossEncoder.

pip install -U sentence-transformers

from sentence_transformers import CrossEncoder

model = CrossEncoder("Qwen/Qwen3-Reranker-0.6B")

query = "Почему отключается УЗО?"
documents = [
    "УЗО отключает цепь при обнаружении дифференциального тока.",
    "Автоматический выключатель защищает проводку от перегрузки.",
    "Wi-Fi 5 ГГц обычно быстрее, но имеет меньшую дальность."
]

ranking = model.rank(query, documents)

for item in ranking:
    print(item)

Логика production pipeline:

Какие embeddings использовать для русского языка

Не выбирайте модель по одному англоязычному MTEB score. Для русскоязычного RAG нужен собственный retrieval test.

Qwen3 Embedding официально заявляет поддержку 100+ языков и cross-lingual retrieval. EmbeddingGemma также обучена на 100+ spoken languages. Это делает обе семьи логичными кандидатами для теста на русской базе.

У Qwen3 Embedding query может получать instruction. Разработчики рекомендуют формулировать instruction по-английски даже для multilingual retrieval, потому что training instructions преимущественно были английскими.

Как проверить retrieval quality до запуска всей базы

Сделайте небольшой golden set.

Простая метрика:

Если Recall@20 низкий — проблема в embedding/chunking/index. Если Recall@20 высокий, а правильный документ часто стоит на позиции 12–18 — reranker особенно полезен.

Нужно ли embedding-модели GPU

Не обязательно. Компактные embedding models часто нормально работают на CPU. GPU становится полезной при массовой первичной индексации большого corpus или при высоком числе запросов.

Это отдельный плюс локального RAG: генеративная LLM может работать на GPU, а лёгкая embedding model — на CPU или другой машине.

Где хранить vectors

Embedding model не является vector database. Векторы нужно хранить и искать отдельно.

Популярные классы решений:

• Chroma — простой локальный старт;
• Qdrant — полноценная vector database и filters;
• PostgreSQL + pgvector — если инфраструктура уже на PostgreSQL;
• FAISS — локальная библиотека индекса, не полноценная DB.

Выбор базы — отдельная задача. При небольшом corpus разница между vector stores обычно менее важна, чем chunking и embedding quality.

Главные ошибки

1. Использовать чат-модель вместо embedding model

LLM и embedding model обучаются для разных задач. Нужен специализированный embedding endpoint/model.

2. Менять model после индексирования

Нужно пересчитать embeddings всех документов.

3. Выбирать самую большую embedding model

Индексирование, RAM и latency могут вырасти сильнее реального выигрыша retrieval.

4. Увеличивать Top K вместо reranking

Передача 30 похожих chunks в LLM может ухудшить ответ и раздуть context.

5. Не тестировать русский corpus

Общий multilingual benchmark не заменяет ваши запросы и терминологию.

6. Игнорировать exact terms

Для моделей устройств, ГОСТов и кодов ошибок добавляйте BM25/keyword или metadata filters.

7. Считать reranker генеративной LLM

Он не отвечает на вопрос — он выдаёт relevance score/ranking.

Частые вопросы