Qwen3 Embedding — это семейство моделей, которые превращают фрагменты текста в числовые векторы, чтобы поиск находил документы по смыслу, а совпадение слов играло вторую роль. Для корпоративной базы это основа поиска по регламентам, договорам и переписке: сотрудник задаёт вопрос обычными словами и получает нужные абзацы. Выбирать модель для этой задачи надо по результату на собственном тестовом корпусе, собранном из реальных вопросов сотрудников, ведь рейтинги на открытых наборах о ваших документах молчат.
Что делает модель
Qwen3 Embedding кодирует вопросы и фрагменты документов в векторы одного пространства, а близость векторов подсказывает, какие фрагменты отвечают на вопрос; ответы пишет другая, языковая модель.
По описанию разработчиков Qwen, семейство включает модели для эмбеддингов и отдельные модели для переранжирования, выпускается в нескольких размерах и принимает инструкции под конкретную задачу. По карточке модели на Hugging Face, семейство идёт под лицензией Apache-2.0 в трёх размерах (0.6B, 4B и 8B параметров), поддерживает более ста языков и длину входа до 32 тысяч токенов. Вендор отмечает, что инструкция на стороне запроса в большинстве сценариев поиска повышает качество, поэтому её задают. Размер вектора и остальные характеристики сверяйте в карточке на момент внедрения. Общий обзор поколения есть в статье Qwen3: какую модель выбрать, здесь разбирается только поиск.
Чтобы роли остались различимыми, посмотрите, как делится работа между тремя типами моделей в системе поиска по документам.
| Компонент | Что делает | Что отдаёт |
|---|---|---|
| Модель эмбеддингов | Переводит вопрос и фрагменты в векторы | Список ближайших фрагментов |
| Модель переранжирования | Перечитывает пары «вопрос — фрагмент» и оценивает их точнее | Тот же список в новом порядке |
| Языковая модель | Читает лучшие фрагменты и формулирует ответ | Текст со ссылками на источники |
Поэтому тема статьи — только первая строка таблицы. На практике ошибка почти всегда начинается именно здесь: команда тратит недели на выбор языковой модели, а потом выясняется, что в неё поступают чужие фрагменты. Если эмбеддинги подобрали плохо, лучшая языковая модель отвечает по случайным фрагментам и выдаёт уверенную чушь. Подробнее о механике говорит разбор поиска по базе знаний на LangChain.
Тестовый корпус
Тестовый корпус — небольшая выборка ваших документов с вопросами, на которые ответы известны заранее, причём вопросы лучше брать у людей, а за столом их сочинять незачем: живые формулировки намного разнообразнее выдуманных. Он заменяет споры о том, какая модель лучше, и позволяет сравнивать варианты по одной шкале.
- Выберите пару сотен документов разных типов: регламенты, письма, таблицы, договоры.
- Разрежьте их на фрагменты одинаковым способом и сохраните соответствие фрагмента и файла.
- Попросите сотрудников записать реальные вопросы, которые они задают коллегам, и отметить, где лежит ответ.
- Добавьте каверзные вопросы: с синонимами, сокращениями, опечатками и вопросы без ответа в базе.
- Зафиксируйте эталон: для каждого вопроса список фрагментов, которые считаются правильными.
- Проиндексируйте корпус моделью и измерьте, какая доля вопросов находит правильный фрагмент в первых результатах.
Вопросы без ответа в базе важны особенно: хороший поиск должен показывать слабые совпадения как слабые, а плохой выдаёт уверенный мусор. Храните корпус в общей папке под контролем версий и закрепите за ним ответственного: набор живёт долго и должен оставаться достоверным. Этот набор вы будете использовать при каждом изменении: новой модели, нового способа нарезки, нового формата документов. Приёмы нарезки на фрагменты описаны в разборе LlamaIndex: документы и поиск для RAG.
Проверка релевантности
Для начала достаточно простой метрики без сложной математики. Релевантность измеряют долей вопросов, для которых правильный фрагмент оказался в первых результатах. Выберите порог заранее: например, правильный фрагмент должен попадать в первую пятёрку для большинства вопросов. Какое число считать достаточным, определяет цена ошибки в вашем процессе.
- Русский язык: проверьте отдельно, потому что многоязычная модель на русских юридических текстах ведёт себя иначе, чем на общем наборе.
- Сокращения и внутренний жаргон: «ДС», «КП», «акт сверки» должны находить нужные документы.
- Таблицы и перечни: эмбеддинг слабее работает на таблицах, поэтому проверяйте их вручную.
- Длинные фрагменты: слишком большие куски размывают смысл, слишком короткие теряют контекст.
Если правильный фрагмент часто находится в первых двадцати результатах, но редко в первых пяти, подключайте модель переранжирования. Если его нет и среди двадцати, чините нарезку и данные.
Отдельно ведите журнал неудачных запросов: вопросы, оставшиеся у сотрудника без ответа, превращаются в новые строки тестового корпуса, и качество растёт по мере использования. Проверку полезно повторять после каждого изменения конфигурации и записывать результаты в таблицу с датой: так видно, какое решение улучшило поиск, а какое ухудшило.
Какие документы вы хотели бы сделать доступными для поиска?
Обновление индекса
Документы меняются, и индекс устаревает тихо, без сообщений об ошибках: поиск продолжает находить прежнюю редакцию регламента, а сотрудник узнаёт об этом по ошибке в работе. Поэтому обновление индекса проектируют вместе с самим поиском.
- Для каждого фрагмента хранится идентификатор файла, версия и дата загрузки.
- Изменённый документ переиндексируется целиком, а старые фрагменты удаляются, чтобы редакции оставались раздельными.
- Удалённые документы исчезают из индекса в тот же день.
- Права доступа хранятся вместе с фрагментом, чтобы сотрудник получал только то, что ему разрешено.
Отдельно решите, кто отвечает за актуальность: у каждого набора документов нужен владелец, который сообщает об изменениях, иначе индекс обновляется по случайному графику. Смена модели эмбеддингов означает полную переиндексацию: векторы разных моделей несовместимы, и смешивать их в одном индексе нельзя. Планируйте это заранее и держите тестовый корпус под рукой, чтобы после переезда сравнить результаты. Раз в квартал полезно пересматривать вопросы корпуса: реальные запросы сотрудников меняются вместе с бизнесом.
Где запускать
Вопрос о месте запуска решают после тестового корпуса, когда известно, какая модель нужна. Для корпоративных документов чаще всего выбирают запуск на собственном сервере: модели эмбеддингов компактны по меркам языковых моделей, и документы остаются внутри контура. Открытые веса позволяют сделать это без отправки данных вендору. Альтернатива — сервис вендора напрямую, если характер документов допускает передачу и оплата доступна компании. Доступ к зарубежным сервисам напрямую российскими картами недоступен, поэтому открытые веса часто становятся основным вариантом.
Заложите и измерение скорости: время индексации корпуса и время ответа на запрос показывают, выдержит ли сервер реальную нагрузку отдела, и вовремя подсказывают, когда нужен более мощный сервер. Начинайте с самой маленькой модели из семейства и сравнивайте с более крупной на тестовом корпусе: выигрыш в качестве бывает меньше, чем рост нагрузки на сервер. Если сервер ограничен по памяти, это решает вопрос сразу, а если ресурсов достаточно, сравнение показывает, окупается ли переход на крупную модель. Выбор размера делайте по таблице результатов вместо обещаний рейтингов.
Для небольшого отдела хватает одного сервера и ночного обновления индекса, а рост числа пользователей решается отдельно, когда измерения покажут реальную нагрузку. Если вам нужен готовый контур с индексом, правами и проверкой ответов, его собирают в рамках работы с нейросетями для документов. Тестовый корпус при этом остаётся вашим активом: на нём проверяются и модели, и обновления, и новые версии индекса.