Perplexity dzieli wyszukiwanie na dwa modele. Indeks buduje większy, zapytania obsługuje mniejszy

Perplexity opublikowało dwa multimodalne modele wyszukiwawcze z rodziny pplx-embed-v2-late. Zostały zaprojektowane do pracy z tekstem, obrazami oraz stronami dokumentów PDF traktowanymi jak grafika — bez konieczności stosowania osobnego etapu OCR. Wagi obu wariantów, liczących 0,6 mld oraz 9 mld parametrów, trafiły do serwisu Hugging Face na otwartej licencji MIT.

Głównym założeniem architektury jest podział zadań. Wariant 9B powstał z myślą o jednorazowym, dokładniejszym przygotowaniu indeksu dokumentów. Z kolei lekki model 0,6B służy przede wszystkim do szybkiego kodowania zapytań użytkowników. Ponieważ oba modele współdzielą tę samą przestrzeń osadzeń, zapytanie przetworzone przez mniejszy wariant może bezpośrednio przeszukiwać bazę zaindeksowaną przez wariant 9B.

Jeden wektor na token zamiast na dokument

Tradycyjne modele wyszukiwawcze często kompresują całą treść dokumentu do pojedynczego wektora. W modelach typu late interaction, takich jak pplx-embed-v2-late, zapisywany jest osobny wektor dla każdego tokenu. Podczas wyszukiwania tokeny zapytania są dopasowywane do najbardziej zbliżonych tokenów w dokumencie.

Podejście to pozwala zachować więcej szczegółów semantycznych, ale wiąże się z kompromisem: rozmiar indeksu rośnie proporcjonalnie do długości dokumentów. Choć pojedynczy wektor w modelach Perplexity ma stosunkowo niewielką szerokość (128 wymiarów), konieczność przechowywania wektora dla każdego tokenu sprawia, że całkowity rozmiar bazy danych pozostaje wyzwaniem infrastrukturalnym.

Wspólna przestrzeń osadzeń pozwala na łączenie tekstu i obrazów w obrębie tego samego indeksu, ale pojedyncze wejście do modelu nie może zawierać jednocześnie obu tych formatów.

Przykład konfiguracji mieszanej i brak niezależnych testów

W materiałach udostępnionych przez Perplexity możliwość łączenia obu modeli zilustrowano testem wyszukiwania obrazów ViDoRe v3 image. Układ, w którym indeks zbudowano modelem 9B, a zapytania kodowano wariantem 0,6B, uzyskał wynik 63,5 proc., podczas gdy zastosowanie modelu 0,6B po obu stronach dało 62,3 proc. Perplexity deklaruje przy tym, że koszt obsługi zapytania w konfiguracji z indeksem 9B i zapytaniami kodowanymi przez model 0,6B pozostaje taki sam jak przy użyciu modelu 0,6B po obu stronach.

Liczby te oraz zapewnienia o kosztach należy traktować wyłącznie jako deklaracje producenta, a nie wynik niezależnego pomiaru w warunkach produkcyjnych. Perplexity nie opublikowało dotąd pełnego raportu technicznego, a podane rezultaty nie zostały zweryfikowane przez niezależne źródła. Nie przedstawiono również szczegółowych pomiarów rzeczywistego czasu odpowiedzi, zużycia pamięci ani kosztu indeksowania w warunkach produkcyjnych.

Oba modele wymagają środowiska z obsługą technologii CUDA. Choć zapowiedziano uruchomienie hostowanego API Perplexity, obecnie jedynym sposobem na przetestowanie pplx-embed-v2-late jest samodzielne wdrożenie udostępnionych wag.