Почему encode_query и encode_document различаются в Sentence Transformers

1. Откройте карточку выбранной embedding-модели и изучите её инструкции для запросов.
2. Закодируйте короткий вопрос через encode_query, фрагменты корпуса через encode_document.
3. Проверьте одинаковую размерность двух полученных массивов и выбранную метрику.
4. Сверьте top-k с вручную отмеченным документом.
5. При смене модели или prompt пересчитайте и индекс, и контрольные запросы.

Подготовьте изолированное окружение и установите зафиксированный пакет: pip install "sentence-transformers==6.1.0". Библиотека потребует подходящих зависимостей и свободной памяти под выбранные веса; установка пакета не скачивает заранее любую модель. Перед тестом напечатайте установленную версию и зафиксируйте имя checkpoint. Не отправляйте в примеры клиентские имена, закрытые документы или ключи доступа.

Готовый шаблон

from sentence_transformers import SentenceTransformer, util

model = SentenceTransformer("BAAI/bge-small-en-v1.5")
query = "How long can I return an item?"
docs = ["An item may be returned within 14 days.",
        "Delivery is available from Monday to Friday."]
q_vec = model.encode_query(query)
d_vec = model.encode_document(docs)
print(q_vec.shape, d_vec.shape)
print(util.semantic_search(q_vec.reshape(1, -1), d_vec, top_k=2))

Запускайте первый раз на очень маленьком обезличенном наборе. Для каждой строки и документа сохраняйте стабильный ID: иначе невозможно выяснить, почему нейросеть выбрала конкретную запись. Если вывод отличается от ожидаемой формы, сначала проверьте состав входа, затем конфигурацию модели и только после этого настройки ранжирования. Не маскируйте ошибки ручной подстановкой заранее «правильного» ответа.

Конкретный вход и ожидаемый результат

Вопрос про срок возврата и два фрагмента: 14 дней и дни доставки. Ожидается одна строка вектора вопроса, две строки документов одинаковой размерности и первый hit по документу о 14 днях при успешном тесте. Печатайте позиции и score фактического запуска: конкретные цифры не объявляются универсальными.

Проверяйте структуру отдельно от смысла. Массив верного размера не означает хорошего поиска, а высокий score не удостоверяет факт в документе. Сохраните реальные выводы программы и сопоставьте их с заранее размеченными эталонными ID. При переносе на другой корпус обновите проверочные данные; простая замена входного предложения в коде не доказывает обобщения метода.

Разбор метода и ограничений

В информационном поиске короткий вопрос и длинный документ играют разные роли. Некоторые модели используют отдельные инструкционные префиксы и задачи для двух сторон. Поэтому «encode для всего» может тихо отключить то, на что рассчитывали авторы конкретной модели. Однако нельзя говорить, что все модели обязательно преобразуют стороны по-разному: официальное руководство прямо допускает эквивалентное поведение при отсутствии специализированного prompt. Карточка checkpoint важна не меньше API библиотеки. В рабочем индексе записывайте идентификатор модели, её ревизию, схему подготовки документа и режим кодирования. Изменить только метод для новых вопросов и оставить старые документы без проверки — значит сравнивать потенциально разные представления.

Дополнительный сценарий проверки

Сначала измерьте на одном корпусе baseline: encode/encode и encode_query/encode_document. Для каждого из десяти вопросов вручную отметьте правильный документ и сравните hit@1; если модель не использует асимметричные prompts, улучшения может не быть. Особенно опасно вносить prefix в пользовательский текст вручную и одновременно дать методу добавить встроенный prompt: получится двойная инструкция. Для индекса со смешанными русскими и английскими документами BGE-small-en не является проверенной русскоязычной моделью, поэтому языковую поддержку проверяйте отдельно. Отличайте размерность от совместимости: совпадающая длина вектора разных моделей не означает сравнимость смысловых пространств. Если сменили prompt для corpus, пересчёт документов должен происходить в новом индексе до переключения.

Критерии принятия