Размер встраивания: размеры 768, 1536 или 3072?

Очевидно, что выбор между text-embedding-3-small и text-embedding-3-large сначала означает выбор между 1536 и 3072 собственными размерами, еще до того, как говорить об усечении. В таблице ниже приведены поддающиеся проверке факты на трех уровнях, которые pgvector изначально распознает на стороне индексирования, и на этом маршруте Aurabase.

Источники: OpenAI, официальный блог «Новые модели встраивания и обновления API», 25 января 2024 г. (оценки MTEB и цены запуска, перед использованием проверьте текущую страницу цен); aura-ai/src/embeddings/mod.rs, Aurabase (поддержка столбцов и индексов, проверено 24 августа 2026 г.).

Вложение хранится как массив чисел с плавающей запятой. В pgvector классический тип vector кодирует каждое измерение в 4 байта (float32): поэтому 768 измерений весят около 3 КБ необработанных данных на вектор, 1536 измерений - около 6 КБ, а 3072 измерения - около 12 КБ, даже без учета заголовка pgvector и служебных данных страницы Postgres.

Здесь на помощь приходит тип pgvector halfvec, который кодирует каждое измерение в 2 байтах (float16) вместо 4. 3072-мерный вектор, хранящийся в halfvec, весит около 6 КБ: ровно такой же вес 1536-мерного вектора, хранящегося в классическом vector.

Прямое и неинтуитивное следствие: в Aurabase переход от измерений с 1536 до 3072 не удваивает фактическое пространство на диске, поскольку столбец embedding_3072 запрашивается посредством приведения halfvec. Таким образом, реальная дополнительная стоимость размеров 3072 связана в первую очередь не с диском: это цена соответствующей модели OpenAI и результат встроенной поддержки индексов типа vector, подробно описанный в следующем разделе.

Тип pgvector vector не позволяет строить индекс HNSW или IVFFlat размером более 2000. Таким образом, размерность 3072 превышает этот предел: ни один векторный поисковый запрос в столбце vector(3072) не может полагаться на приблизительный индекс, он опирается на полное последовательное сканирование, непригодное для использования в масштабе действующего корпуса RAG.

Код Aurabase обрабатывает этот случай явно: столбец embedding_3072 преобразуется в halfvec(3072) при каждом запросе на вставку и поиск, тип, который pgvector может индексировать до 4000 измерений. Столбцы 768 и 1536 остаются родными vector, не приведенными, поскольку они не приближаются к пределу.

// Для 3072 (>2000) HNSW не индексирует тип `vector` → приводит к halfvec
fn vec_query_parts(dims: usize) -> AuraResult<(&'static str, &'static str, &'static str)> {
    match dims {
        768  => Ok(("embedding_768",  "", "::vector")),
        1536 => Ok(("embedding_1536", "", "::vector")),
        3072 => Ok(("embedding_3072", "::halfvec(3072)", "::halfvec(3072)")),
        other => Err(...), // неподдерживаемое измерение
    }
}

Эта деталь также объясняет, почему измерение внедрения, не указанное в [768, 1536, 3072], явно терпит неудачу на стороне Aurabase, а не принимается и затем плохо индексируется: имя столбца всегда берется из фиксированного списка разрешений, а не из свободного значения, отправленного клиентом. Чтобы углубиться в создание индекса HNSW в Postgres за пределами этого конкретного случая, см. нашу статью Индекс HNSW и векторный поиск Postgres.

По состоянию на январь 2024 года API Embeddings API OpenAI принимает параметр dimensions, который сокращает возвращаемый вектор без повторного вызова другой модели. Этот метод называется «Обучение представлениям матрешки»: модель обучена концентрировать полезную информацию в первых измерениях вектора, так что усечение теряет точность постепенно, а не резко.

OpenAI иллюстрирует эффективность этого метода на конкретном примере в своем объявлении: text-embedding-3-large, усеченный всего до 256 измерений, по-прежнему превышает показатель MTEB старого text-embedding-ada-002, используемого в полном размере 1536 измерений (источник: OpenAI, официальный блог, 25 января 2024 г.). Вектор в 12 раз меньше, который работает лучше, чем полный вектор, в этом конкретном тесте.

let body = json!({
    "model": self.embed_model,       // например "встраивание текста-3-большой"
    "input": text,
    "dimensions": self.embed_dimensions, // усекает 3072 → настроенное значение
});

Важный момент, который часто неправильно понимают: сокращение не снижает взимаемую цену. OpenAI взимает плату на основе запрошенной модели, а не размера возвращаемого вектора, поскольку фактическая стоимость представляет собой расчет, выполненный на основе входного текста. Таким образом, запрос 1536 размеров из text-embedding-3-large стоит той же цены, что и его 3072 собственных измерения (источник: OpenAI, официальный блог, 25 января 2024 г.); изменяются только скорость хранения и поиска.

Это именно выбор Aurabase по умолчанию, проверенный в config/mod.rs: модель, настроенная по умолчанию, — text-embedding-3-large, но выходное измерение, настроенное по умолчанию, — 1536, а не 3072. Таким образом, служба платит за представление широкой модели, усеченной, чтобы оставаться в индексируемом столбце vector в собственном HNSW, без приведения halfvec, необходимого к 3072.

Размерность 1536 остается разумной отправной точкой для большинства проектов RAG или семантического поиска: показатель MTEB для встраивания текста-3-маленький (62,3%) остается близким к показателю большой модели, хранилище остается легким, а классический тип индексов pgvector vector в HNSW без какой-либо конкретной конфигурации.

3072 измерения оправданы, когда корпус неоднозначный или технический, где разрыв в качестве между 62,3% и 64,6% приводит к заметно лучшим результатам поиска по вашим собственным запросам, а не по общему тесту OpenAI. Несколько отзывов команд, зафиксированных в дискуссиях сообщества разработчиков OpenAI, указывают на это: выигрыш в 3072 измерения измеряется в каждом конкретном случае, его нельзя предполагать.

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

Этот выбор измерения является частью более крупного стека RAG, вложений, индекса HNSW и гибридного поиска, которые документированы на нашей странице Native AI.

Размеры 768, 1536 и 3072 не разделены по одной оси. 3072 выигрывает в рейтинге MTEB, опубликованном OpenAI, но оставляет встроенную поддержку HNSW pgvector и платит цену большой модели, независимо от того, какой размер в конечном итоге запрошен. 1536 остается наиболее распространенным балансом по умолчанию, в том числе в Aurabase. 768 служит для случаев, когда громкость имеет приоритет над нюансами.

Параметр dimensions OpenAI меняет вопрос: это больше не «какую модель выбрать», а «какое усечение принять, для какого выигрыша измерено на моем корпусе». Прежде чем окончательно определиться с выбором в производстве, протестируйте качество поиска на реальной выборке, а не только на общем эталоне. В нашем руководстве RAG-конвейер с pgvector подробно описана полная настройка, от приема до гибридного поиска.