Qwen3 Embedding: выбрать 0.6B, 4B или 8B для локального поиска

Что такое Qwen3 Embedding и когда он нужен?

Qwen3 Embedding кодирует текст в вектор для поиска похожих фрагментов: это звено retrieval в RAG, а не чат-модель, которая сама отвечает по документу. Авторы выпустили три отдельных репозитория — Qwen/Qwen3-Embedding-0.6B, Qwen/Qwen3-Embedding-4B и Qwen/Qwen3-Embedding-8B s1 s2 s3. В прикладном сценарии вопрос и фрагменты документов превращаются в векторы, после чего поиск отбирает фрагменты; отдельная генеративная модель может формулировать ответ с проверяемыми ссылками на исходный документ. Для задачи с артикулами и номерами одного смыслового поиска часто недостаточно: сопоставьте его с гибридным поиском.

Qwen заявляет поддержку более 100 языков и публикует оценки мультиязычных тестов s6. Это заявления автора, не результат проверки русского языка в вашем каталоге, договорах или внутренней базе знаний. Размер модели и положение в авторском рейтинге не назначают победителя на конкретной задаче.

Как выбрать между 0.6B, 4B и 8B?

• 0.6B — удобный кандидат для первого измерения, а не гарантированно достаточный размер. По карточке максимум 1024 измерения вектора; опубликованы основные веса и отдельный официальный GGUF-репозиторий с форматами f16 и Q8_0 s1 s5. Для GGUF автор приводит путь через llama.cpp с режимом --embedding --pooling last s5. Поддержку конкретной версии runtime и фактическое потребление памяти проверяйте на своей машине: вес файла на диске не равен RAM/VRAM.
• 4B — вектор до 2560 измерений; самостоятельный репозиторий и отдельный индекс с одной размерностью на все документы s2. Этот вариант имеет смысл испытывать, если baseline 0.6B упускает нужные фрагменты и ваше оборудование выдерживает выбранный формат, длину контекста и параллельную нагрузку. Обещать фиксированный прирост на русском нельзя.
• 8B — вектор до 4096 измерений; проверяйте лишь при подтверждённой потребности и доступном ресурсе, сопоставляя качество, задержку и расход памяти на тех же вопросах s3. Результаты авторских MTEB-таблиц — не замена этой проверке s6.

Карточки трёх моделей заявляют контекст 32K s1 s2 s3. При этом config.json 4B содержит max_position_embeddings=40960 s8: конфигурационное число не разрешает автоматически обещать рабочие 40K токенов или хорошее качество длинного русского документа. Разбивайте документ на осмысленные фрагменты и измеряйте качество поиска на реальной длине текста. Укороченная размерность вектора поддерживается по заявлению автора s6, но при смене размерности, модели, нормализации или инструкции перестраивайте индекс и фиксируйте настройки, иначе сравнение будет некорректным.

Как подготовить запрос и документы для retrieval?

В примере авторов на SentenceTransformers вопрос кодируется с prompt_name="query", а документы — обычным encode без этого prompt s1 s6. Альтернативный авторский пример формирует строку Instruct: ... и новую строку Query: ... для вопроса; не добавляйте эту инструкцию к документам при обычном асимметричном поиске s6. Сохраняйте конкретную формулировку инструкции рядом с SHA весов и параметрами индекса; изменение инструкции может менять порядок выдачи. Автор рекомендует формулировать инструкции на английском, ссылаясь на собственные эксперименты, но это не независимый вывод для русской выборки s6.

Модуль 1_Pooling/config.json у 0.6B включает last-token pooling и выключает mean/CLS; те же поля доступны в снимках модулей 4B/8B. Карточка GGUF прямо указывает --pooling last s4 s5. Не переносите настройки mean pooling от другой embedding-модели: вектор может иметь правильную длину, но не соответствовать авторскому способу получения. Для сравнений придерживайтесь нормализации и метода близости из выбранного рабочего пути s1 s6. Сам факт, что API выдал вектор нужной длины, ещё не означает правильный retrieval.

Как запустить и проверить результат без подмены теста?

Для начальной проверки есть два документированных автором пути: модельные карточки показывают загрузку через Sentence Transformers, а карточка официального 0.6B GGUF показывает llama.cpp в режиме embeddings s1 s5. Это документация автора, не запуск Modelium. Не предполагайте, что любой чат-сервер автоматически применяет query-instruction, last-token pooling и нужную нормализацию. Гайд по vLLM Embeddings API объясняет структуру запроса и ответа, но совместимость выбранного Qwen3-репозитория в вашей версии vLLM проверяется отдельно.

1. Подготовьте небольшой обезличенный набор русских документов с несколькими похожими, но неверными фрагментами. Запишите для каждого вопроса корректный document_id, идентификатор фрагмента и допустимые альтернативы до сравнения моделей. Не переносите закрытые тексты во внешний сервис ради теста.
2. Для каждого размера отдельно постройте индекс: сохраните SHA репозитория, формат весов, runtime и версию, параметры разбиения, размерность, pooling и query-instruction. Кодируйте запрос и документ по соответствующему авторскому примеру s1 s2 s3. Выход 1024-, 2560- и 4096-мерных конфигураций не смешивайте в одном векторном поле s1 s2 s3.
3. Сверьте долю размеченных фрагментов в первых результатах, ложные находки, задержку и реальный расход памяти на своём железе. Документация Sentence Transformers описывает InformationRetrievalEvaluator и метрики поиска; условия набора, топ-k и метод близости фиксируйте одинаковыми для всех вариантов s7. Затем отдельно проверьте, цитирует ли генеративная модель именно найденный источник: retrieval и качество ответа — разные проверки.

Все три карточки размечены Apache-2.0 s1 s2 s3. Это метки опубликованных артефактов, а не юридическое заключение по вашим данным, коду runtime и зависимостям; проверьте условия фактически скачанного файла и вашей интеграции. Open weights не означают бесплатный сервер, разрешение на чужие документы или готовую изоляцию от сети.

Следующий шаг: составьте протокол оценки RAG и сравните 0.6B с 4B/8B на одних и тех же русских вопросах. Если больший вариант не улучшает нужные находки при приемлемой задержке и расходе памяти, не выбирайте его из-за числа параметров.