Что нужно понять про эмбеддинги до запуска векторного поиска
Почему выбор модели эмбеддингов - это не технический вопрос на потом, а архитектурное решение с долгосрочными последствиями.
Когда компания решает строить систему поиска по внутренним документам на основе языковых моделей, разговор быстро переходит к векторной базе данных: Pinecone, Weaviate, Chroma, что-то ещё. Это понятно - векторная БД видима, её выбирают, на неё смотрят. Но есть более фундаментальный выбор, который делается раньше и с которым потом приходится жить дольше. Это выбор модели эмбеддингов.
Эмбеддинги - это числовые представления текста, с которыми работает векторный поиск. От того, как они генерируются, зависит качество всей системы поиска. И поменять их потом - значит переиндексировать весь корпус документов заново.
Почему это решение не стоит откладывать
Процесс прост: текст → модель эмбеддингов → вектор → хранение в векторной БД. Когда пользователь ищет - его запрос проходит через ту же модель эмбеддингов, получается вектор запроса, и система ищет ближайшие векторы в базе.
Ключевой момент: запрос и документы должны проходить через одну и ту же модель. Если сегодня вы используете одну модель для индексации, а завтра хотите попробовать лучшую - нужно переиндексировать всё. Для корпуса в несколько тысяч документов это терпимо. Для сотен тысяч - уже операция.
Поэтому выбор модели эмбеддингов - это архитектурное решение, а не деталь реализации.
Основные оси выбора
Размерность вектора. Чем больше - тем больше информации в векторе, но и выше требования к памяти и скорости поиска. Современные модели обычно дают 768 или 1536 измерений. Для большинства задач это рабочий диапазон.
Языковая поддержка. Если документы на русском, нужна модель, обученная на русском. Многоязычные модели есть, но их качество по отдельным языкам обычно ниже, чем у специализированных. Для корпуса смешанных документов (русский + английский) - отдельный вопрос.
Специализация на домене. Общие модели обучены на интернете. Если ваши документы - юридические, медицинские, технические - общая модель может плохо понимать специфическую терминологию. Дообученные на домене модели дают лучшее качество, но их меньше и они дороже в поддержке.
Локальная модель или API. Некоторые модели эмбеддингов доступны через API (OpenAI text-embedding-ada-002, например). Другие запускаются локально. Это вернёт нас к вопросу о конфиденциальности данных: если документы нельзя отправлять наружу, нужна локальная модель.
Что часто упускают
Оценка качества эмбеддингов - задача, которую нельзя пропустить. Модель может хорошо выглядеть на стандартных бенчмарках и плохо работать на вашем конкретном корпусе и ваших типичных запросах. Правильный путь - взять несколько моделей, построить небольшой тестовый индекс и прогнать реальные запросы. Это занимает время, но экономит от разочарований позже.
Стоимость генерации эмбеддингов. Если используется API, каждый документ при каждом переиндексировании стоит денег. Для больших корпусов с частыми изменениями это может складываться в существенные суммы.
Практический подход
Прежде чем выбирать инструмент:
- Каков объём корпуса - сейчас и через год?
- На каких языках документы?
- Есть ли ограничения на передачу данных наружу?
- Как часто корпус будет обновляться?
- Есть ли специфическая терминология, которую модель должна понимать?
Ответы на эти вопросы сузят выбор до нескольких реальных вариантов. Тогда уже можно экспериментировать с конкретными моделями на конкретных данных - а не выбирать по популярности в интернете.