Embeddings multimodalne wykraczające poza pojedynczy wektor

Od premiery pplx-embed-v1 w lutym pracujemy nad nową generacją modeli embeddingowych. W zeszłym tygodniu przedstawiliśmy nasz nowy model kontekstowych embeddingów, pplx-embed-v2-context. Dziś rozszerzamy tę rodzinę o pplx-embed-v2-late, zestaw modeli późnej interakcji. Oprócz silniejszych możliwości wyszukiwania modele te są pierwszymi, które łączą trzy kluczowe cechy:

• Reprezentacje wielowektorowe. Zamiast kompresować każde wejście do jednego wektora, modele te zachowują wektory na poziomie tokenów, co umożliwia bardziej szczegółowe porównania zapytanie-dokument. Pozwala to różnym częściom zapytania dopasowywać się do różnych części dokumentu, zachowując szczegóły szczególnie cenne w multimodalnym wyszukiwaniu.
• Obsługa zarówno tekstu, jak i obrazu. Oprócz możliwości wyszukiwania tekst→tekst oferowanych przez nasze wcześniejsze modele, te nowe modele obsługują wyszukiwanie tekst→obraz, umożliwiając bezpośrednie przeszukiwanie wyrenderowanych stron PDF bez potrzeby OCR ani analizowania tekstu.
• Wspólna przestrzeń embeddingów. Udostępniamy dwa rozmiary modeli, 0,6B i 9B, aby obsłużyć różne wymagania dotyczące jakości, opóźnień i mocy obliczeniowej. Każdy z nich może być używany niezależnie, ale wspólna przestrzeń embeddingów pozwala również mniejszemu modelowi przeszukiwać indeks utworzony przez większy model, łącząc wyższej jakości osadzenia dokumentów z tanim i szybkim wnioskowaniem w czasie zapytania.

Nowe modele osiągają najlepsze obecnie wyniki w wielu testach porównawczych wyszukiwania wizualnego i tekstowego, a także w agentowych zadaniach polegających na odpowiadaniu na pytania. Co istotne, w ViDoRe (V3), czołowym teście porównawczym wyszukiwania dokumentów wizualnych, nasz model 0.6B dorównuje modelom o pięciokrotnie większej liczbie aktywnych parametrów. Oba modele są publicznie dostępne w serwisie Hugging Face. Więcej szczegółów na temat metodologii i wyników ewaluacji można znaleźć w naszym raporcie technicznym.

Od pojedynczych wektorów do późnej interakcji

Systemy wyszukiwania muszą znaleźć równowagę między wydajnością a głębokością interakcji między zapytaniami i dokumentami. Gęste modele embeddingowe kodują każde zapytanie i dokument niezależnie, co pozwala porównywać je tanim iloczynem wewnętrznym. Dzięki temu praktyczne staje się przybliżone wyszukiwanie najbliższych sąsiadów (ANN) w miliardach dokumentów. Na drugim biegunie cross-encodery przetwarzają zapytanie i dokument razem, umożliwiając bogatszą interakcję, ale wymagając osobnego przejścia w przód dla każdego kandydata. Zastosowanie tych obliczeń do dużego korpusu dokumentów przy każdym wyszukiwaniu jest zaporowo kosztowne, więc cross-encodery są zwykle zarezerwowane do ponownego rankingu niewielkiego zbioru pobranych kandydatów.

Ograniczenia gęstych embeddingów

Reprezentowanie całego dokumentu jednym wektorem o stałym rozmiarze tworzy wąskie gardło informacyjne. Wraz ze wzrostem długości dokumentów i liczby poruszanych tematów model musi upchnąć więcej treści w tym samym wektorze, co utrudnia zachowanie wszystkiego, co istotne dla zapytania. Dzielnie na fragmenty może zmniejszyć tę presję, ale fragmentuje dokument i może rozdzielać informacje, które mają sens tylko razem, co jest problemem, z którym mierzymy się również w naszym modelu kontekstowych embeddingów. To wąskie gardło pogarsza się w ustawieniach multimodalnych, gdzie gęstość informacji w obrazach wymaga jeszcze większej kompresji.

Pojedynczowektorowe gęste wyszukiwanie sprowadza także każde porównanie do iloczynu wewnętrznego między dwoma wektorami, ograniczając ekspresyjność funkcji punktacji. Dla ustalonego wymiaru embeddingu i dostatecznie dużego korpusu niektórych wzorców punktacji w parach zapytanie-dokument nie da się wygenerować, niezależnie od treningu. Benchmark LIMIT zamienia tę teoretyczną obawę w konkretne obciążające testy dla pojedynczowektorowego wyszukiwania.

Wyszukiwanie z późną interakcją

Modele późnej interakcji zajmują miejsce pomiędzy tańszymi modelami gęstych embeddingów a bardziej ekspresyjnymi cross-encoderami. Podobnie jak modele gęste, kodują dokumenty niezależnie od zapytania, co pozwala obliczać reprezentacje dokumentów offline. Jednak zamiast redukować każde wejście do jednego wektora, zachowują wiele wektorów i stosują bogatszą funkcję punktacji przy porównywaniu zapytania z dokumentem.

Nasze modele pplx-embed-v2-late wykorzystują architekturę w stylu ColBERT, generując osadzenia o wymiarze 128 dla każdego tokenu wejściowego. Parom zapytanie-dokument przypisujemy wynik za pomocą MaxSim; dla każdego tokenu zapytania model wybiera token dokumentu o najwyższej ocenie i sumuje maksymalne podobieństwa dla poszczególnych tokenów, aby uzyskać wynik końcowy. Dzięki temu różne części zapytania mogą dopasowywać się do różnych części dokumentu, a silniejsze dopasowania tokenów wnoszą większy wkład do wyniku.

Powiększ

Ta dodatkowa ekspresyjność wiąże się z wyższymi kosztami przechowywania i oceniania kandydatów. Gęste wyszukiwanie przechowuje jeden wektor na dokument i ocenia kandydata jednym iloczynem wewnętrznym; późna interakcja przechowuje wektory dla tokenów dokumentu i oblicza wiele podobieństw token-do-tokenu. Koszt rośnie wraz z długością dokumentu, więc późna interakcja wymaga innego kompromisu między indeksowaniem a obsługą niż wyszukiwanie ANN oparte na jednym wektorze. W zamian zapewnia bogatsze wyszukiwanie w pierwszym etapie dla korpusów wrażliwych na jakość, a także może służyć jako późniejszy etap w większym potokach wyszukiwania na skalę webową.

Jeden model, wiele modalności

Wykazano, że ta lepsza głębia interakcji jest bardzo przydatna w różnych zadaniach, w tym w wyszukiwaniu długokontekstowym, agentowym i poza domeną. Różnica ta jest szczególnie widoczna w wyszukiwaniu multimodalnym, co pokazuje duża przewaga modeli ColPali w rankingu ViDoRe(V3).

Rzeczywiste korpusy nie składają się wyłącznie z czystego tekstu. Trafiają jako pliki PDF, prezentacje, zrzuty ekranu, zeskanowane strony, wykresy i tabele. Konwencjonalny potok analizuje te dokumenty, stosuje OCR lub captioning i przeszukuje uzyskany tekst, co jest kosztowne i stratne: może wprowadzać błędy OCR i usuwa układ, strukturę tabel, rysunki oraz relacje przestrzenne. Wizualne wyszukiwanie dokumentów pomija ten krok, rzutując wyrenderowaną stronę bezpośrednio do przestrzeni reprezentacji, w której mogą jej szukać zapytania tekstowe.

Nasza nowa rodzina modeli opiera się na silnych wynikach modeli wielowektorowych w wielomodalnym wyszukiwaniu i przesuwa granicę Pareto dla małych modeli na najczęściej używanym benchmarku wyszukiwania dokumentów, ViDoRe(V3). Choć oczekujemy, że renderingi dokumentów będą najczęstszą formą wejścia wizualnego, nasze modele obsługują również semantyczne wyszukiwanie obrazów naturalnych, takich jak fotografie krajobrazowe.

Trenowanie rodziny interoperacyjnych modeli

Wyszukiwanie jest z natury asymetryczne: indeksowanie i kodowanie zapytań mają różne ograniczenia operacyjne. Indeksowanie działa offline i można je równoleglić, więc jego koszt obliczeniowy rozkłada się na wiele przyszłych wyszukiwań. Kodowanie zapytań działa online dla każdego żądania, przez co jest wrażliwe na opóźnienia i czasem podlega ograniczeniom serwowania lub urządzeń brzegowych. Nasza rodzina modeli wykorzystuje tę asymetrię, oferując rozmiary dopasowane do każdej strony potoku wyszukiwania.

Trenujemy nauczyciela 18B kontrastywnie, a następnie destylujemy go osobno do modeli uczniowskich 9B i 0,6B. Zamiast uczyć każdego ucznia wyłącznie odtwarzania rozkładu rankingu nauczyciela, stosujemy destylację reprezentacji w stylu LEAF: dla każdego tokenu wejściowego wyrównujemy embedding wyjściowy ucznia z embeddingiem nauczyciela. Choć destylacja w przestrzeni reprezentacji była wcześniej stosowana w gęstych, pojedynczowektorowych modelach, rozszerzamy ją na późną interakcję, gdzie celem dopasowania jest wektor dla każdego zachowanego tokenu.

W rezultacie oba opublikowane checkpointy współdzielą tę samą wielowektorową przestrzeń embeddingów. Umożliwia to wyszukiwanie między modelami i otwiera dodatkowe opcje wdrożenia.

• Maksymalna jakość: koduj dokumenty i zapytania modelem 9B.
• Maksymalna wydajność: koduj dokumenty i zapytania modelem 0,6B dla 100% lokalnego wnioskowania
• Wyszukiwanie o niskich opóźnieniach: zbuduj indeks korpusu modelem 9B, a następnie koduj bieżące zapytania modelem 0,6B, aby wykorzystać obliczenia wykonywane podczas indeksowania przy jednoczesnym zachowaniu szybkości zapytań.
• Lokalno-chmurowe wyszukiwanie: koduj prywatne dokumenty lokalne lub bieżące zapytania modelem 0,6B na urządzeniu, a następnie porównuj lub łącz te reprezentacje z wynikami z indeksu 9B hostowanego w chmurze.

W ustawieniach wrażliwych na opóźnienia zaprojektowaliśmy model 0,6B jako lekki enkoder zapytań, który może również działać na urządzeniach brzegowych. Wychodząc od Qwen3.5-0.8B, przycinamy jego 24-warstwową wieżę tekstową do 12 warstw, redukując tę wieżę z 498 mln do 240 mln parametrów innych niż embeddingowe. Otrzymany model ma łącznie 594 mln parametrów, ale jego nominalny rozmiar zawyża koszt obsługi: 100 mln są używane do kodowania obrazu, a 254 mln znajdują się w tabeli embeddingów tokenów, co ma niewielki wpływ na czas działania. Tylko około 240 mln parametrów jest aktywnych dla kodowania tekstu i 340 mln dla kodowania obrazu, co daje modelowi koszt obsługi znacznie mniejszego modelu przy zachowaniu zgodności z indeksem 9B.

Zastosowaliśmy ten sam proces, aby zbudować naszego nauczyciela 18B z rdzenia 27B, co znacznie obniżyło koszt jego destylacji bez osłabiania sygnału, jaki dostarcza.

Wielojęzyczne, multimodalne, niekontaminowane dane treningowe

Trenujemy oba modele na zbiorze 186 milionów par zapytanie-dokument pochodzących z 594 zbiorów danych w 46 językach. Spośród tych par 88,3% to tekst→tekst, 8,3% to tekst→obraz, a 3,4% to pary tekst→wizualny dokument. Zamiast próbkowania proporcjonalnie do wielkości zbioru danych, przypisujemy każdemu zbiorowi wagę próbkowania, co daje bardziej zrównoważoną mieszankę treningową odpowiednio 56,5%, 30,9% i 12,6%.

Przy tworzeniu danych treningowych wykluczamy wszystkie zbiory danych powiązane z benchmarkami, na których się oceniamy, aby wiernie przedstawić nasze wyniki bez zawyżania wyników benchmarków. Ta decyzja wiąże się z kompromisem: niektóre wykluczone zbiory zawierają wysokiej jakości dane, które mogłyby poprawić wydajność naszego modelu w zadaniach innych niż benchmark, z którego pochodzą. Ostatecznie zdecydowaliśmy się zaakceptować ten koszt: wiarygodne liczby są dla nas bardziej użyteczne podczas rozwoju, a dla użytkowników przy porównywaniu modeli.

Ocena

Oceniamy oba modele w zadaniach wyszukiwania tekstu, wyszukiwania dokumentów wizualnych, wyszukiwania obrazów mieszanych oraz wyszukiwania agentowego. Oba modele przewyższają oceniane benchmarki bazowe na Q2D-Web i BrowseComp+, a także osiągają mocne wyniki w wyszukiwaniu dokumentów wizualnych i MADQA.

Wyszukiwanie tekstu

Oceniamy wyszukiwanie tekst→tekst na trzech benchmarkach:

• Benchmarki specyficzne dla domen: Zbiór 72 zadań w stylu MTEB, z czego 55 w pięciu domenach (finanse, prawo, zdrowie, rozmowa, technologia), plus 17 różnorodnych zadań wielojęzycznych. Zbiór obejmuje takie zadania jak FinQA, AILACasedocs i XLSum. Żaden z tych zbiorów danych nie pojawia się w naszych danych treningowych, jak opisano powyżej.
• Q2D-Web: nasz benchmark wyszukiwania na skalę webową obejmujący około 70 000 zapytań wyszukiwawczych przeformułowanych przez agenta, pochodzących z produkcyjnego ruchu wyszukiwania, oparty na korpusie 190 mln dokumentów internetowych. Benchmark ten mierzy skuteczność wyszukiwania w środowisku znacznie bliższym rzeczywistemu wyszukiwaniu webowemu niż inne dostępne benchmarki wyszukiwania, dzięki zapytaniom podobnym do produkcyjnych i dużemu korpusowi.
• ViDoRe(V3) Markdown: ViDoRe(V3) jest zazwyczaj zadaniem wyszukiwania tekst→wizualny dokument, ale można je również oceniać jako zadanie tekstowe, używając wersji korpusu przetworzonej do Markdown, co pozwala nam oceniać wyszukiwanie dokumentów bogatych w informacje zarówno w modalności obrazu, jak i tekstu.

Wydajność mierzymy za pomocą nDCG@10, z wyjątkiem Q2D-Web, gdzie podajemy Recall@1000 ze względu na nacisk benchmarku na scenariusz wyszukiwania webowego w pierwszym etapie. W całej naszej ewaluacji porównujemy się z wiodącymi w branży modelami embeddingowymi w różnych klasach rozmiaru. W przypadku wyszukiwania tekstu nemotron-embed-8b, gemini-embedding-2, voyage-large-4 i qwen3-embed-8b reprezentują najsilniejszych i najczęściej używanych konkurentów gęstych, podczas gdy voyage-4-nano i qwen3-embed-0.6b pełnią rolę gęstych benchmarków poniżej miliarda parametrów. Dodatkowo porównujemy się z niedawno wydanymi przez TopK modelami późnej interakcji topk-embed-v1 na benchmarkach, dla których TopK opublikował wyniki. Wyniki ViDoRe(V3) pochodzą z kart modeli dla 128 wymiarów, co odpowiada szerokości naszych embeddingów tokenów; wynik Q2D-Web pochodzi z naszej tabeli wyników.

W benchmarkach specyficznych dla domen nasz model 9B i 0,6B osiągają średnio odpowiednio 81,3% i 78,0%. Nasz model 9B uzyskuje najwyższy wynik spośród wszystkich ocenianych modeli, pokonując kolejny najlepszy model o 1,6 pp. Nasz model 0,6B jest konkurencyjny wobec innych najlepiej ocenianych modeli, ustępując tylko o 0,3 pp gemini-embedding-2. Co istotne, ponieważ nie trenowaliśmy na żadnych danych dla tych zadań benchmarkowych, benchmarki specyficzne dla domen pokazują, że nasze modele embeddingowe potrafią generalizować na nowe domeny.

Powiększ

Względna siła naszego modelu 0,6B jest jeszcze większa w zadaniu ViDoRe(V3) Markdown; jego wynik 61,2% wyprzedza wszystkie inne modele poza naszym modelem 9B, który uzyskał 64,7%. Kolejny najlepszy model zewnętrzny uzyskał 60,6%, a kolejny najlepszy model poniżej 1B, topk-embed-v1-0.8b, był o 4,3 pp za naszym modelem 0,6B.

Powiększ

W Q2D-Web trafność pochodzi z trzech zestawów ocen: dokumentów, które agent zacytował (Citation), dokumentów uszeregowanych przez nasz produkcyjny system wyszukiwania (Web) oraz unii obu tych zbiorów rozszerzonej o oceny LLM dla nieoznaczonych dokumentów (Combined). Oba modele pplx-embed-v2-late prowadzą wśród wszystkich benchmarków we wszystkich trzech zestawach ocen. Skupiamy się na ocenach Combined, ponieważ zbiory Citation i Web są pochodną tego, co nasze własne systemy już wyeksponowały, a więc faworyzują modele, które porządkują wyniki podobnie jak one; oceny LLM dodane w Combined obejmują dokumenty, których żaden z systemów nie pobrał. W tym zbiorze zarówno nasz model 9B, jak i 0,6B pokonuje wszystkich konkurentów, osiągając odpowiednio 74,8% i 73,6%, wobec poprzedniego najlepszego wyniku 69,3%.

Powiększ

Wyszukiwanie wizualne

Naszym głównym wizualnym benchmarkiem wyszukiwania jest standardowy publiczny podzbiór ViDoRe(V3), w którym korpus składa się z wyrenderowanych obrazów stron, a nie z konwersji do Markdown. Porównujemy się z dwoma wiodącymi gęstymi modelami vision-language, qwen3-vl-embed-8b i gemini-embedding-2, oraz z modelami późnej interakcji topk-embed-v1. Dodatkowo modele EVIE firmy Tencent oraz modele Nemotron ColEmbed V2 firmy NVIDIA to wielowektorowe benchmarki „vision-only” trenowane specjalnie do zadań wyszukiwania obrazów.

Oba nasze modele osiągają wyniki na poziomie najlepszych dostępnych modeli w zadaniach vision-language. Nasz model 9B uzyskuje średnio 65,2%, ustępując tylko EVIE. Nasz model 0,6B osiąga wynik 62,3%, wyprzedzając topk-embed-v1-2b i ustępując jedynie znacznie większym modelom EVIE oraz nemotron-colembed-v2-8b spośród zewnętrznych benchmarków.

Powiększ

Nasz model 0,6B jest szczególnie konkurencyjny w kontekście rozmiaru modelu. Wyprzedza wszystkie porównywalne rozmiarowo modele i ustępuje modelowi nemotron-colembed-v2-8b jedynie o 1,2 pp, aktywując przy tym tylko 340 mln parametrów dla danych wejściowych obrazu. Nasze modele generują osadzenia o wymiarze 128 na token, w porównaniu z 2 048 w przypadku EVIE-4.5B oraz 4 096 w przypadku EVIE-8B i nemotron-colembed-v2-8b. Ta różnica w kosztach przechowywania może radykalnie wpłynąć na scenariusze, w których modele te są praktyczne w użyciu.

Powiększ

Oceniając wyszukiwanie wizualne na MIRACL-Vision, benchmarku, którego korpus składa się ze zrzutów ekranu artykułów w Wikipedii, oraz PPLX-Q2I, wewnętrznym benchmarku obejmującym zarówno dokumenty wizualne, jak i obrazy naturalne. PPLX-Q2I jest zbudowany na podstawie produkcyjnych logów wyszukiwania obrazów Perplexity i zaprojektowany tak, aby odzwierciedlać różnorodność zastosowań wyszukiwania obrazów. Używamy próby 10 000 zapytań, stratyfikowanej według języka i domeny, względem korpusu 100 000 obrazów; odpowiadające dokumenty dla każdego zapytania to obrazy, które zostały dla niego wyświetlone. Nie ocenialiśmy EVIE-8B ani Nemotron ColEmbed na PPLX-Q2I, ponieważ indeksowanie korpusu tej wielkości przy ich domyślnych wymiarach wyjściowych (2 560 dla Nemotron ColEmbed 4B oraz 4 096 dla Nemotron ColEmbed 8B i EVIE-8B) było niepraktyczne.

Podobnie jak w przypadku wyników na ViDoRe(V3), nasz model 0,6B jest konkurencyjny wobec znacznie większych modeli, ustępując o zaledwie 1 pp modelowi qwen3-vl-embed-8b na MIRACL-Vision. Nasz model 9B przewyższa wszystkie inne modele z wyjątkiem gemini-embedding-2.

Na PPLX-Q2I oba nasze modele pokonują qwen3-vl-embedding-8b z przewagą ponad 9 pp, a nasz model 9B ustępuje modelowi gemini-embedding-2 tylko o 2 pp. Nasze wyniki pozostają konkurencyjne na korpusach zawierających zarówno obrazy naturalne, jak i dokumenty wizualne, więc reprezentacje wielowektorowe, które przynoszą korzyści na ViDoRe(V3), nie odbywają się kosztem ogólnego wyszukiwania obrazów.

Powiększ

Wyszukiwanie między modelami

Wyniki w poprzednich sekcjach oceniają każdy model względem korpusu, który sam osadził. Wspólna przestrzeń embeddingów oznacza, że nie jest to wymagane: korpus zindeksowany modelem 9B można przeszukiwać zapytaniami osadzonymi przez model 0,6B. Taka konfiguracja jest według nas najbardziej prawdopodobna w większości wdrożeń produkcyjnych, ponieważ indeksowanie to jednorazowy koszt amortyzowany w całym okresie życia korpusu, a osadzanie zapytań działa na krytycznej dla opóźnień ścieżce każdego żądania.

Wdrożenie, które nie może uruchamiać modelu 9B w czasie zapytania, musiałoby inaczej również indeksować modelem 0,6B, więc symetryczna konfiguracja 0,6B jest tu właściwym punktem odniesienia. Ocenę prowadzimy względem 72 benchmarków specyficznych dla domen użytych powyżej oraz na wyszukiwaniu obrazów ViDoRe v3. Zapytania są osadzane przez pplx-embed-v2-late-0.6b, a zmieniamy wyłącznie to, co osadzało korpus.

Indeksowanie modelem 9B jest jednoznaczną poprawą. W benchmarkach specyficznych dla domen konfiguracja asymetryczna daje średnio wzrost o 1,6 pp. W wyszukiwaniu obrazów ViDoRe v3 uzyskuje 63,5%, w górę z 62,3% przy modelu 0,6B po obu stronach, co oznacza wzrost o 1,2 punktu procentowego. Koszt kodowania zapytań pozostaje taki sam w konfiguracjach symetrycznej 0,6B i asymetrycznej, ponieważ w obu przypadkach zapytanie koduje ten sam model 0,6B; dodatkowy koszt kodowania dokumentów ponoszony jest w czasie indeksowania.

Uruchomienie modelu 9B po obu stronach pozostaje jeszcze lepsze, dając średnio 81,3% w benchmarkach specyficznych dla domen. Konfiguracja asymetryczna odzyskuje więc około połowy różnicy jakości między tymi dwoma modelami w tekście, bez dodatkowego kosztu kodowania zapytań. Wybór konfiguracji zależy od tego, czy model 9B jest opłacalny w czasie zapytania; tam, gdzie nie jest, konfiguracja asymetryczna przechwytuje znaczną część jego korzyści.

Powiększ

Wyszukiwanie agentowe

Wyszukiwanie agentowe to kolejny obszar, w którym embeddingi wielowektorowe są szczególnie silne. W BrowseComp+ LLM (GPT-OSS-120B w naszym przypadku) używa modelu embeddingowego do przeszukiwania korpusu pod kątem informacji istotnych dla złożonego zapytania użytkownika, a drugi LLM ocenia, czy wynikowa odpowiedź odpowiada prawdzie referencyjnej. Nasz model 9B osiąga 64,0% dokładności, pokonując kolejny najlepszy model ColBERT o 4,9 pp i kolejny najlepszy model gęsty o 8,7 pp, przy jednoczesnym wykonywaniu mniejszej liczby wyszukiwań niż każdy inny model poza naszym 0,6B. Model 0,6B wyprzedza również każdy model spoza naszej rodziny.

Powiększ

MADQA testuje agentowe question answering na 800 heterogenicznych rzeczywistych plikach PDF obejmujących ponad 18 000 stron, z 500 pytaniami napisanymi przez ludzi, na które nie da się odpowiedzieć na podstawie ogólnej wiedzy. Agent (w naszym przypadku Gemini 3.5 Flash) przeszukuje zbiór z retrieverem będącym przedmiotem testu i jest oceniany pod kątem dokładności odpowiedzi oraz F1 na poziomie strony względem oznaczonych stron dowodowych. Nasz model 9B ustanawia nowy stan wiedzy wśród retrieverów z dokładnością 92,4%, o 3,5 pp przed tym samym agentem korzystającym z retrievera Mixedbread; nasz model 0,6B osiąga 90,1%. Zauważamy też, że nasz retriever osiąga konkurencyjne wyniki względem Mixedbread Agentic Search, który używa podagenta wyszukiwania w swoim systemie wyszukiwania, planującego i uruchamiającego kilka wyszukiwań na każde wywołanie głównego agenta (93,4%, w granicach naszego przedziału ufności).

Powiększ

Pierwsze kroki

Oba nasze modele 0,6B i 9B są dostępne na Hugging Face i są od razu kompatybilne z sentence-transformers >= 6.0.0 oraz transformers >= 5.4.0. Dalsze szczegóły techniczne i pełne wyniki ewaluacji zostaną opublikowane w raporcie technicznym jeszcze w tym roku.

Obecnie trenujemy kolejną generację naszych modeli gęstych osadzeń i będziemy stopniowo wprowadzać obsługę osadzeń z późną interakcją, gęstych oraz kontekstowych w Perplexity API Platform.

Cytowanie

@online{perplexity2026MultimodalEmbeddingsBeyondASingleVector,
  author = {{Perplexity} and Markus Krimmel and Louis Milliken and Antoine Chaffin and Sarah Eslami and Ekaterina Glazkova and Maximilian Schall and Bo Wang and Denis Bykov and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Multimodal embeddings beyond a single vector}},
  date = {2026-10-07},
  url = {https://www.perplexity.ai/hub/blog/multimodal-embeddings-beyond-a-single-vector}
}