Rozmiar osadzania: wymiary 768, 1536 czy 3072?

Jasne jest, że wybór pomiędzy osadzaniem tekstu-3-małego a osadzaniem tekstu-3-dużego sprowadza się najpierw do wyboru pomiędzy 1536 a 3072 wymiarami natywnymi, zanim w ogóle zaczniemy mówić o obcinaniu. Poniższa tabela podsumowuje możliwe do sprawdzenia fakty na trzech poziomach, które pgvector natywnie rozpoznaje po stronie indeksowania, oraz na trasie Aurabase.

Źródła: OpenAI, oficjalny blog „Nowe modele osadzania i aktualizacje API”, 25 stycznia 2024 (wyniki MTEB i ceny uruchomienia, przed użyciem sprawdź aktualny cennik); aura-ai/src/embeddings/mod.rs, Aurabase (obsługa kolumn i indeksów, zweryfikowana 24 sierpnia 2026 r.).

Osadzanie jest przechowywane w postaci tablicy liczb zmiennoprzecinkowych. W pgvector klasyczny typ vector koduje każdy wymiar na 4 bajtach (float32): zatem 768 wymiarów waży około 3 KB surowych danych na wektor, 1536 wymiarów około 6 KB, a 3072 wymiary około 12 KB, nawet przed obliczeniem nagłówka pgvector i obciążenia strony Postgres.

W tym miejscu pojawia się typ halfvec pgvector, który koduje każdy wymiar w 2 bajtach (float16) zamiast 4. 3072-wymiarowy wektor przechowywany w halfvec waży około 6 KB: dokładnie tyle samo, co 1536-wymiarowy wektor przechowywany w klasycznym vector.

Bezpośrednia i nieintuicyjna konsekwencja: w Aurabase przejście z 1536 do 3072 wymiarów nie podwaja rzeczywistej ilości miejsca na dysku, ponieważ zapytanie do kolumny embedding_3072 jest wykonywane poprzez rzutowanie halfvec. Prawdziwym dodatkowym kosztem wymiarów 3072 nie jest zatem przede wszystkim dysk: jest to cena powiązanego modelu OpenAI i wynik natywnej obsługi indeksów typu vector, szczegółowo opisane w następnej sekcji.

Typ vector pgvector nie pozwala na budowanie indeksu HNSW lub IVFFlat przekraczającego 2000 wymiarów. Zatem 3072 wymiary przekraczają ten limit: żadne zapytanie wyszukiwania wektorowego w kolumnie vector(3072) nie może opierać się na przybliżonym indeksie, opiera się na pełnym skanowaniu sekwencyjnym, bezużytecznym w skali korpusu RAG w produkcji.

Kod Aurabase obsługuje ten przypadek jawnie: kolumna embedding_3072 jest rzutowana na halfvec(3072) przy każdym zapytaniu wstawiania i wyszukiwania, a typ ten pgvector może indeksować do 4000 wymiarów. Kolumny 768 i 1536 pozostają natywne vector, nieobsługiwane, ponieważ nie zbliżają się do limitu.

// Dla 3072 (>2000) HNSW nie indeksuje typu `vector` → cast 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(...), // nieobsługiwany wymiar
    }
}

Ten szczegół wyjaśnia również, dlaczego wymiar osadzania, który nie jest wymieniony w [768, 1536, 3072], wyraźnie zawodzi po stronie Aurabase, zamiast zostać zaakceptowany, a następnie słabo zindeksowany: nazwa kolumny zawsze pochodzi ze stałej listy dozwolonych, nigdy z darmowej wartości przesłanej przez klienta. Aby głębiej zagłębić się w budowanie indeksu HNSW w Postgres poza tym konkretnym przypadkiem, zobacz nasz artykuł Indeks HNSW i wyszukiwanie wektorów Postgres.

Od stycznia 2024 r. interfejs API Embeddings OpenAI akceptuje parametr dimensions, który skraca zwracany wektor bez ponownego wywoływania innego modelu. Technika ta nazywa się uczeniem reprezentacji Matrioszki: model jest szkolony tak, aby koncentrował przydatne informacje w pierwszych wymiarach wektora, tak że obcięcie traci precyzję stopniowo, a nie gwałtownie.

OpenAI ilustruje skuteczność tej techniki konkretnym przykładem w swoim ogłoszeniu: text-embedding-3-large, obcięty do zaledwie 256 wymiarów, nadal przewyższa wynik MTEB starego tekstu-embedding-ada-002 użytego w pełnym rozmiarze 1536 wymiarów (źródło: OpenAI, oficjalny blog, 25 stycznia 2024). Wektor 12 razy mniejszy, który w tym konkretnym teście porównawczym działa lepiej niż pełny wektor.

let body = json!({
    "model": self.embed_model,       // np. „osadzanie tekstu-3-dużego”
    "input": text,
    "dimensions": self.embed_dimensions, // obcina 3072 → skonfigurowaną wartość
});

Ważna uwaga, ale często źle rozumiana: obcięcie nie powoduje obniżenia ceny. Opłaty OpenAI opierają się na zapytanym modelu, a nie na rozmiarze zwróconego wektora, ponieważ rzeczywisty koszt jest obliczeniem wykonanym na podstawie tekstu wejściowego. Zażądanie 1536 wymiarów z Text-embedding-3-large kosztuje zatem tę samą cenę, co 3072 natywne wymiary (źródło: OpenAI, oficjalny blog, 25 stycznia 2024 r.); zmienia się tylko szybkość przechowywania i wyszukiwania.

Jest to dokładnie domyślny wybór Aurabase, zweryfikowany w config/mod.rs: model skonfigurowany domyślnie to text-embedding-3-large, ale wymiar wyjściowy skonfigurowany domyślnie to 1536, a nie 3072. Dlatego usługa płaci za reprezentację szerokiego modelu, obciętego tak, aby pozostał w indeksowalnej kolumnie vector w natywnym HNSW, bez rzutowania halfvec wymaganego dla 3072.

Wymiary 1536 pozostają rozsądnym punktem wyjścia dla większości projektów RAG lub wyszukiwania semantycznego: wynik MTEB dla tekstu-embedding-3-small (62,3%) pozostaje bliski wynikowi dużego modelu, pamięć pozostaje niewielka, a klasyczny typ vector indeksów pgvector w HNSW bez żadnej szczególnej konfiguracji.

Wymiary 3072 mają uzasadnienie w przypadku, gdy korpus jest niejednoznaczny lub techniczny, gdzie różnica w jakości pomiędzy 62,3% a 64,6% przekłada się na wyraźnie lepsze wyniki wyszukiwania na podstawie własnych zapytań, a nie ogólnego benchmarku OpenAI. Kilka opinii zespołów zarejestrowanych w dyskusjach społeczności programistów OpenAI wskazuje na ten kierunek: wzmocnienie 3072 wymiarów jest mierzone indywidualnie dla każdego przypadku i nie można tego zakładać.

Wymiary 768 są szczególnie przydatne, gdy objętość ma pierwszeństwo przed niuansami: duży korpus, w którym prawdziwym ograniczeniem jest budżet na przechowywanie lub obliczenia, lub użycie starszego modelu osadzania już w natywnych wymiarach 768.

Ten wybór wymiaru jest częścią większego stosu RAG, osadzania, indeksu HNSW, wyszukiwania hybrydowego, które dokumentuje nasza strona Natywna sztuczna inteligencja.

Wymiary 768, 1536 i 3072 nie są podzielone na jednej osi. 3072 zyskuje w wyniku MTEB opublikowanym przez OpenAI, ale pozostawia natywną obsługę HNSW pgvector i płaci cenę dużego modelu, niezależnie od ostatecznie żądanego wymiaru. 1536 pozostaje najczęstszym saldem domyślnym, w tym w Aurabase. 768 służy do przypadków, w których objętość ma pierwszeństwo przed niuansami.

Parametr dimensions OpenAI zmienia pytanie: nie jest to już „który model wybrać”, ale „które obcięcie zaakceptować, jaki zysk zmierzono na moim korpusie”. Przed sfinalizowaniem wyboru w produkcji przetestuj jakość wyszukiwania na prawdziwej próbce, a nie tylko na ogólnym benchmarku. Nasz przewodnik Potok RAG z pgvector szczegółowo opisuje całą konfigurację, od pozyskiwania po wyszukiwanie hybrydowe.