Метрики информационного поиска значительно снижаются на производственном корпусе (по сравнению с тестовым набором данных).

Вопрос или проблема

Я работаю над семантическим поисковым движком, основанным на предвычисленных эмбеддингах и KNN (в моем случае ANN). В качестве функции схожести используется косинусное сходство. Поиск асимметричен: запросы значительно короче документов. В качестве модели для создания эмбеддингов я использовал предварительно обученный Sentence Transformer (основанный на deBERTa) от huggingface с размерностью 768. В нем используется токенизатор на уровне байтов BPE. Я дообучил его на своем корпусе (это специализированный корпус) следующим образом:

обучающая выборка состояла из пар запрос-документ (около 27000 пар);
я выбрал MNR в качестве функции потерь;
начальная скорость обучения: 1e-5;
1 эпоха;
я использовал SentenceTrainsformerTrainer из библиотеки 🤗 sentence_transformers.

Для оценки я использовал InformationRetrievalEvaluator. Для тестовой выборки я взял около 2000 запросов с до 10 релевантными документами для каждого. В частности, метрики после дообучения были следующие:

точность: 0.98 (k=10)
полнота: 0.63 (k=10)

После вычисления эмбеддингов для всего коруса (~52 млн документов) и тестирования на другом наборе данных метрики были следующие:

точность: 0.65 (k=10)
полнота: 0.12 (k=10)

Я попробовал дальнейшее дообучение на “сложных” запросах, но это привело к значительному ухудшению метрик (до 8%) на тестовой выборке. Также я пробовал дообучение предварительно обученной модели, с которой я начал, на исходной обучающей выборке, включая “сложные” запросы, что также ухудшило результаты тестов. Единственное, что приходит на ум, это “проклятие размерности”: поэтому я рассматриваю возможность попробовать дообучить модель, которая производит меньшие эмбеддинги (размерность=384). Стоит ли оно того? Или я что-то упустил? Любые подсказки будут полезны.

Ответ или решение

Ваша проблема заключается в значительном падении метрик информационного поиска на производственном корпусе по сравнению с тестовым набором данных. Рассмотрим возможные причины и решения этой проблемы.

Теория:

Когда вы перенимаете модель из исследовательской или тестовой среды в производственную, вы сталкиваетесь с несколькими потенциальными проблемами. Во-первых, существует возможность дисбаланса данных или несоответствия между тестовым и производственным датасетами. Во-вторых, потому что запросы в вашем случае значительно короче документов, это может стать проблемой для анализа и извлечения релевантных токенов, что влияет на качество и точность получаемых эмбеддингов.

Косинусное сходство, используемое вами, хорошо себя показывает, когда векторы не слишком разрежены, но с увеличением размерности и уменьшением плотности (то есть, с уменьшением длинны запросов) проклятие размерности может действительно начать сказываться. Косинусное сходство потенциально чувствительно к шуму и не всегда оказывает ожидаемую производительность на высокоразмерных данных с незначительным набором фич.

Пример:

Проблема с падением метрик при переходе от тестового к производственному датасету может напоминать ситуацию в рекомендательных системах, где модели, отлично работающие на датасетах, собранных в контролируемых условиях, показывают совсем другие результаты при встрече с реальностью. В вашем случае, несмотря на высокую точность и точность при k=10 на тестовом наборе данных, эти метрики резко падают в продуктивных условиях.

Применение:

Анализ проблем передачи:
- Проведите анализ распределения данных в обучающем, тестовом и производственном наборах данных. Возможно, стоит рассмотреть использование статистических методов анализа, чтобы понять, как сильно отличаются эти распределения. Это может помочь определить причины ухудшения метрик, будь то из-за других типов данных, необычных запросов или нечистых данных.
Обработка данных и ремедии:
- Попробуйте внедрить методы очистки данных и более тщательную предварительную обработку текстовых данных. Возможно, ваш производственный корпус содержит больше шума или упоминаний, которые не учитываются в тестовом наборе данных.
Оптимизация модели:
- Исследуйте возможность уменьшения размерности векторов эмбеддингов (например, до 384), чтобы минимизировать влияние "проклятия размерности". Но это изменение нужно проводить осторожно, возможно, через пошаговое снижение и последующие эксперименты с метриками при изменениях.
Фина-тюнинг и обучение:
- Помимо фина-тюнинга на "трудных" запросах, рассмотрите обучение на большем разнообразии данных, включая данные, которые ближе к производственному окружению. Возможно, стоит провести перекрестную валидацию на вспомогательных выборках для определения оптимальных гиперпараметров.
Тестирование и валидация:
- Проводите регулярное тестирование модели с реальными данными. Поддержание качественной контроля качества с расширением пула атрибутов и метрик также способствует лучшему пониманию производительности в разных условиях.

Понимание, в чем заключаются различия между тестовым и производственным окружением, является ключом к решению вашей проблемы. Проводите больше экспериментов с фича-анализом, снижением размерности и проверкой качества модели для анализа и улучшения её надежности.