Как включить binary quantization в Meilisearch и не потерять исходные vectors

Порядок действий

1. Заморозьте корпус и выборку запросов с размеченными source IDs; измерьте качество и размер хранилища до изменения.
2. Создайте отдельный тестовый embedder/индекс с той же моделью и включённым binaryQuantized, сохранив неизменную базовую конфигурацию.
3. Дождитесь выполнения tasks, затем сравните top-10 IDs, nDCG/Recall, p95 и размер фактических данных.
4. Проверьте редкие и отрицательные случаи, где потеря точности меняет первый ответ или приводит к чужому source ID.
5. Если выигрыш стоит потерь, выполните управляемое переключение; исходную конфигурацию держите до завершения контрольного периода.

После каждого шага сохраняйте ID операции или задачи, связанные с тестом версии модели, а не только HTTP-статус. Если задача окончилась ошибкой, не скрывайте её повторным запросом к поиску: сначала устраняйте причину. Применение к Meilisearch Cloud и самостоятельной установке зависит от доступности endpoint и полномочий ключа; здесь используются точные имена HTTP API из официальной документации, но не выдуманные пункты интерфейса.

Готовый запрос или шаблон

PATCH /indexes/kb/settings/embedders
{"large-bq-v2":{"source":"openAi","model":"text-embedding-3-large",
                 "apiKey":"${OPENAI_API_KEY}",
                 "documentTemplate":"{{doc.title}}: {{doc.body}}",
                 "binaryQuantized":true}}

Никогда не копируйте заглушки URL, API key, model ID или тестовые vectors в рабочую систему без замены и проверки. Векторы длины три демонстрируют контракт данных; они не представляют реальную языковую модель и не позволяют обещать заданный порядок поисковых результатов.

Пример входа и ожидаемого результата

Вход: 1000 frozen документов, 50 размеченных вопросов, два индекса с одним и тем же model ID; в B включён BQ. Ожидается отчёт: размер индекса, top-10 IDs, Recall@10, p95 по обоим вариантам. Нельзя заранее обещать, что качество B останется неизменным; публикуйте именно измеренные значения, а не теоретическое соотношение битов.

Что важно при внедрении

Теоретическое 32-битное число против одного бита полезно для понимания механизма, но общий размер Meilisearch включает документы, служебные структуры и другие данные. Поэтому проверяйте disk_usage реальной установки и стоимость полного refeed. BQ может быть особенно вредна при низкой dimension, где каждый утраченный компонент несёт большую долю информации. Сначала определите допустимую потерю качества, а не объясняйте ухудшение после выпуска. Если модель меняется одновременно с BQ, эксперимент перестаёт изолировать причину. Рассматривайте два переключателя как разные A/B сравнения. Для RAG дополнительный отрицательный тест должен показывать, что на вопрос без ответа в корпусе система не получает обманчивый высокий score от близкого, но неверного документа. Надёжный rollback — исходные полноточные vectors либо возможность заново их получить, а не попытка binaryQuantized:false на том же embedder.

Сравнение решений

Сравнивайте режимы на фиксированном наборе вопросов и ID: табличные свойства указывают механизм, а не гарантируют результат на вашем корпусе.

Критерии проверки

• Исходная полноточная копия доступна для отката.
• BQ проверена на одинаковом корпусе и модели.
• Размер и p95 измерены, а не вычислены из теории.
• Порог потери Recall@10 согласован до переключения.