Как настроить distribution в Meilisearch для слишком высоких semantic scores

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

1. Подготовьте не менее трёх классов пар запрос–документ: точно отвечает, частично относится, нерелевантен.
2. Получите сырые наблюдаемые scores с showRankingScore:true на замороженных данных.
3. Определите по медианам умеренной группы mean, а по разнице групп — проверяемую исходную оценку sigma.
4. Обновите только distribution для конкретного named embedder; зафиксируйте прежние значения для отката.
5. Повторите запросы и проверьте доли ложных допусков и ложных отказов при выбранном пороге приложения.

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

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

POST /indexes/kb/search
{"q":"как отменить заказ", "hybrid":{"embedder":"ru-kb-v1",
 "semanticRatio":1.0},"showRankingScore":true,"limit":10}

PATCH /indexes/kb/settings/embedders
{"ru-kb-v1":{"distribution":{"mean":0.7,"sigma":0.3}}}

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

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

Вход: три отмеченных hit имеют оценки 0.91 (полный ответ), 0.70 (тематически похож), 0.48 (не отвечает). В учебном шаблоне mean=0.7 отражает среднюю группу, sigma=0.3 служит стартовым предположением, которое нужно проверить на всех кейсах. Ожидаемый выход — отчёт с изменёнными score и фактическими false positives/negatives, не обещание определённых итоговых чисел.

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

Выбранный порог должен оцениваться на отложенных отрицательных вопросах, включая документы с похожими словами, но противоположным условием. Если документ говорит «не подлежит возврату», простой высокий score по запросу о возврате не даёт права ответить «можно вернуть». Результат LLM проверяйте отдельно по тексту и источнику. Не подгоняйте distribution под одну красивую выдачу: score calibration может изменить порядок фильтрации downstream и привести к отказу на действительно полезных документах. Храните до/после число принятых hits, средний размер контекста, p95 и качество цитат. Если проблема — плохой embedding, шаблон или язык модели, калибровка не исправит ranking IDs. Для гибридной ветви отдельно оцените semanticRatio: это другой механизм, не подмена mean/sigma.

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

• Сырые scores собраны с showRankingScore:true.
• Порог оценён на положительных и отрицательных парах.
• Model ID, documents и ratio не менялись в том же эксперименте.
• Новый score не трактуется как вероятность истинности.

Сделайте повторный запуск тех же запросов после изменения модели, схемы, API поставщика или состава корпуса. Фиксируйте source IDs, текст-основание ответа, долю верных top-k и задержку на одинаковых данных. Для RAG найденный hit — свидетельство релевантности, не разрешение придумывать содержание: генератору передавайте только допустимые фрагменты, а утверждения проверяйте по первоисточнику.