Как проверить documentTemplate Meilisearch до запуска переиндексации

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

1. Выберите три записи: полную, с пропущенным описанием и с длинным/чувствительным полем.
2. Сформулируйте шаблон только из тех полей, которые помогают находить документ; уберите токены, внутренние ID и персональные комментарии.
3. Отправьте /render-template для существующего ID и проверьте полученный rendered буквально.
4. Проверьте новый объект через documentTemplate плюс inlineDocument, чтобы выявить отсутствующие ключи до индексации.
5. Сравните результаты для двух вариантов на контрольных вопросах, только затем меняйте embedders setting.

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

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

POST /render-template
{"template":{"kind":"inlineDocumentTemplate",
             "inline":"Тема: {{doc.title}}. Суть: {{doc.body|truncatewords:40}}"},
 "input":{"kind":"indexDocument","indexUid":"kb","id":"refund:1"}}

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

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

Вход: refund:1 с заголовком «Возврат оплаты», телом с условиями и служебным полем private_note. Ожидаемое rendered начинается с «Тема: Возврат оплаты. Суть: ...», не содержит private_note и не остаётся пустым. Отрицательный вход — документ без body: проверка должна показать, что векторный текст потерял существенное содержание.

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

Разные ошибки имеют разные последствия. Утечка приватного поля отправляет лишние данные embedding-провайдеру; слишком длинный текст увеличивает нагрузку или обрезается провайдером; отсутствие оговорки превращает похожий документ в неверный ответ. Тестируйте не только синтаксис, но и смысл полученного текста: если важна фраза «кроме цифровых товаров», она должна пережить сокращение. Не удаляйте source_id из самого документа: он нужен генератору для проверки цитат, даже если не нужен для embedding. Изменение шаблона может переобработать документы, поэтому планируйте миграцию и следите за task status и ограничениями провайдера. Снимайте снимок прежнего template и выборку rendered-строк, чтобы объяснить изменение качества после релиза. У userProvided этот параметр запрещён: если vectors вычисляются вручную, формируйте текст на своей стороне.

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

• Ответ rendered проверен для заполненного и неполного документа.
• Чувствительные поля и технический мусор исключены.
• Условия и отрицания сохраняются после обрезки.
• После применения настроек task дошла до успешного состояния.

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