7 października 2026 r. Perplexity ogłosiło rodzinę modeli wyszukiwawczych pplx-embed-v2-late w wariantach oznaczonych 0.6B i 9B. Firma poinformowała, że oba modele są publicznie dostępne na Hugging Face. Mają wyszukiwać informacje w tekście i obrazach, a ich wyróżnikiem jest porównywanie reprezentacji poszczególnych tokenów zamiast sprowadzania całej treści do jednego wektora.
Jak działa późna interakcja i MaxSim?
Embedding przekształca dane wejściowe w wektory liczbowe, które można porównywać podczas wyszukiwania. W modelach pplx-embed-v2-late każdy token otrzymuje własny wektor o 128 wymiarach. Mechanizm późnej interakcji (late interaction) zestawia tokeny zapytania z tokenami dokumentu: dla każdego tokenu zapytania wybiera najlepsze dopasowanie, a następnie sumuje wyniki za pomocą MaxSim.
To inne podejście niż wyszukiwanie gęste (dense), w którym treść reprezentuje pojedynczy wektor. Perplexity opisuje też embeddingi kontekstowe, które uwzględniają kontekst dokumentu przy tworzeniu reprezentacji jego fragmentów. W modelach późnej interakcji dopasowania na poziomie tokenów pozostają dostępne podczas porównywania zapytania z dokumentem.
Mniejszy model może odpytywać indeks utworzony przez większy
Warianty 0.6B i 9B korzystają ze wspólnej przestrzeni wektorowej. Dzięki temu większy model może utworzyć indeks dokumentów, a mniejszy kodować zapytania do jego przeszukiwania. Perplexity wskazuje, że taki podział może ograniczyć obliczenia potrzebne przy zapytaniach. Późna interakcja przechowuje jednak wiele wektorów dla dokumentu i wymaga porównywania dopasowań między tokenami, więc zwiększa zapotrzebowanie na pamięć i pracę przy ocenie kandydatów. Skala tego kosztu zależy od długości dokumentów i sposobu wdrożenia.
W osobnym teście obrazowym ViDoRe v3 Perplexity podało wynik 63,5% nDCG@10 dla indeksu utworzonego przez model 9B i zapytań kodowanych przez model 0.6B. Dla konfiguracji, w której model 0.6B tworzył indeks i kodował zapytania, wynik wyniósł 62,3%.
Co pokazują wyniki ViDoRe v3?
nDCG@10 mierzy jakość uporządkowania pierwszych dziesięciu wyników wyszukiwania. W tabeli zestawiono wyniki opublikowane przez Perplexity dla dwóch wariantów i dwóch zadań: wyszukiwania na podstawie obrazów oraz dokumentów w formacie Markdown.
| Wariant modelu | ViDoRe v3: obrazy, nDCG@10 | ViDoRe v3: Markdown, nDCG@10 |
| 0.6B | 62,3% | 61,2% |
| 9B | 65,2% | 64,7% |
W tych zadaniach wariant 9B uzyskał wyższe wyniki od 0.6B. Są to rezultaty dla konkretnych testów opublikowane przez Perplexity; opisują ranking wyników w tych zadaniach, a nie jakość wyszukiwania w każdym możliwym zastosowaniu.
Wyszukiwanie stron dokumentów i wymagania wejściowe
Perplexity opisuje wyszukiwanie stron dokumentów wizualnych, w tym stron PDF wyrenderowanych jako obrazy, bez OCR i bez wyodrębniania tekstu. W udokumentowanym przepływie strony są przekazywane jako obrazy. Tekst i obrazy trzeba kodować w osobnych partiach — nie można łączyć obu typów danych w jednej partii.
Karta modelu podaje wymagania programowe: sentence-transformers >= 6.0.0 oraz transformers >= 5.4.0. Perplexity zapowiedziało także stopniowe wdrażanie obsługi embeddingów późnej interakcji, gęstych i kontekstowych na swojej platformie API.
