Что такое embedding в рабочей системе

Embedding - числовое представление смысла текста. По нему поиск находит близкие chunks, даже если слова не совпадают. Вектор не хранит доказательство релевантности: он лишь создаёт кандидатов, которые нужно проверять на реальных запросах.

Dense и sparse

Dense-векторы хорошо ловят перефразирование и смысл. Sparse-представления сохраняют силу точных терминов, артикулов, имён и редких слов. Для неоднородной базы часто выигрывает hybrid retrieval, а не попытка найти одну универсальную модель.

Одинаковая модель на входе и в индексе

Запрос и документ должны быть закодированы совместимым способом. Некоторые модели требуют разных префиксов для query и passage. Версия модели, нормализация и токенизация становятся частью схемы индекса; незаметная смена одного элемента ломает сопоставимость.

Cosine, dot product и Euclidean

Метрика выбирается по рекомендациям модели и способу нормализации. Для единично нормализованных векторов cosine и inner product дают эквивалентный порядок, но движки могут возвращать разные шкалы score. Порог нельзя переносить между моделями и индексами без новой калибровки.

Размерность - не синоним качества

Более длинный вектор увеличивает память, сеть и индекс. Сокращение размерности может быть выгодным, если качество на eval-наборе сохраняется. Считайте полный footprint: число chunks × байты на компонент плюс граф индекса, payload и реплики.

Multilingual и доменный язык

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

Как оценивать модель

Соберите запросы с известными релевантными chunks и hard negatives. Измеряйте Recall@k, MRR или nDCG, затем downstream answer quality. Отдельно режьте метрики по коротким запросам, кодам, русскому языку и длинным вопросам.

Безопасная миграция

Создайте новый vector field или индекс рядом со старым, выполните backfill, включите dual-write, сравните shadow queries и только затем переключайте чтение. Храните embedding_model_version у каждой записи и предусматривайте откат.

С чего начать внедрение?
С узкого сценария, измеримого baseline и набора реальных запросов. Сначала зафиксируйте качество и ограничения, затем меняйте один параметр за эксперимент.
Какие метрики считать обязательными?
Качество результата, p95 latency, ошибки, стоимость и отдельные метрики ключевого этапа. Среднее значение без сегментов и percentiles скрывает провалы.
Можно ли выбрать параметры по документации?
Документация задаёт безопасный baseline, но финальные параметры выбирают по собственному корпусу, нагрузке и eval-набору.
Как обновлять систему без риска?
Версионировать конфигурацию, запускать shadow-сравнение, затем canary и иметь заранее проверенный rollback target.
Почему нужен набор отрицательных примеров?
Он показывает, умеет ли система отказываться и не поднимать нерелевантные результаты только потому, что они ближайшие среди доступных.
Что сохранять для расследования?
Версии компонентов, trace ID, параметры запроса, IDs доказательств, решения фильтров и агрегированные метрики с соблюдением правил доступа и retention.
← Все статьи блога