Cohere Embed, wektory z obrazów i tekstu

Cohere Embed, czyli obraz i tekst w jednej przestrzeni

Embed to rodzina modeli osadzeń firmy Cohere, a cała ta rodzina od trzeciej wersji robi rzecz, której większość konkurencji nie oferuje: obrazy i tekst trafiają do tej samej przestrzeni wektorowej. Czwarta odsłona pozwala dodatkowo podać jedno i drugie w jednym wejściu.

To brzmi jak szczegół techniczny, a otwiera konkretne zastosowanie. Zapytanie napisane słowami może odnaleźć wykres, zrzut ekranu albo skan faktury, bez opisywania obrazów tekstem i bez utrzymywania dwóch osobnych indeksów.

Ten tekst dotyczy samego modelu osadzeń: parametrów, kompresji i pułapek. Szerszy opis oferty producenta, razem ze zmianą kolejności wyników i wdrożeniem we własnej infrastrukturze, znajdziesz w osobnym opracowaniu.

Typ wejścia, czyli parametr, który trzeba podać

To najczęstsze źródło słabych wyników przy pierwszym użyciu i rzecz odróżniająca tę rodzinę modeli od konkurencji.

Przy każdym wywołaniu podajesz, do czego wektor ma służyć. Dokument trafiający do indeksu oznaczasz inaczej niż zapytanie użytkownika, a jeszcze inaczej tekst przeznaczony do klasyfikacji albo grupowania.

import cohere

klient = cohere.ClientV2()

dokumenty = klient.embed(
    texts=fragmenty,
    model="embed-v4.0",
    input_type="search_document",
    embedding_types=["float"],
)

pytanie = klient.embed(
    texts=["Jaki jest okres wypowiedzenia?"],
    model="embed-v4.0",
    input_type="search_query",
    embedding_types=["float"],
)

Model traktuje oba przypadki inaczej, bo zapytanie i dokument mają odmienną naturę. Zapytanie jest krótkie i pytające, dokument długi i twierdzący, więc osadzanie ich w ten sam sposób pogarsza dopasowanie.

Najczęstszy błąd polega na zaindeksowaniu zbioru jako zapytań albo odpytywaniu wektorem dokumentu. Wyszukiwanie wtedy działa, zwraca wyniki i jest po prostu wyraźnie gorsze, więc problem bywa niezauważony przez miesiące.

Obrazy i dokumenty złożone

Druga część oferty dotyczy treści innych niż tekst i tu leży główna przewaga tej rodziny.

Model przyjmuje obraz i zwraca wektor w tej samej przestrzeni co wektory tekstowe. To znaczy, że jeden indeks obsługuje jedno i drugie, a zapytanie tekstowe porównuje się bezpośrednio z obrazami.

Przyjmowane są też wejścia mieszane, czyli tekst przeplatany obrazami w ramach jednego fragmentu. To odpowiada temu, jak wyglądają prawdziwe dokumenty: strona raportu z akapitem, wykresem i podpisem pod nim.

Zastosowanie, w którym różnica jest największa, to dokumenty, których treść siedzi w układzie graficznym. Prezentacja ze slajdami, formularz, faktura, schemat techniczny. Klasyczna droga wymaga tu rozpoznania tekstu z obrazu, odtworzenia struktury i osadzenia wyniku, a każdy z tych kroków gubi część informacji. Osadzenie strony jako obrazu pomija cały ten łańcuch.

Zastrzeżenie praktyczne: obrazy są rozliczane osobno, po stawce blisko czterokrotnie wyższej niż tekst w przeliczeniu na token, a strona wysłana jako obraz zużywa ich więcej niż sam jej tekst. Przy archiwum, w którym większość dokumentów to zwykły tekst, warto kierować do wariantu obrazowego wyłącznie te strony, których tekst nie oddaje.

Skracanie wymiarów i kwantyzacja

Tu model daje więcej możliwości niż większość konkurencji, a przy dużych zbiorach to właśnie te ustawienia decydują o rachunku za bazę wektorową.

Pierwsza oś to liczba wymiarów. Domyślnie wektor ma tysiąc pięćset trzydzieści sześć wartości, a można zażądać krótszego, aż do dwustu pięćdziesięciu sześciu. Model uczono tak, żeby najważniejsza informacja siedziała na początku listy, więc skrócenie nie niszczy wyniku.

Druga oś to format liczb, i ta bywa pomijana mimo większego wpływu na koszt. Zamiast liczb zmiennoprzecinkowych można poprosić o wartości całkowite jednobajtowe albo o postać binarną, gdzie każdy wymiar zajmuje jeden bit.

odpowiedz = klient.embed(
    texts=fragmenty,
    model="embed-v4.0",
    input_type="search_document",
    embedding_types=["int8"],
    output_dimension=1024,
)

Rachunek jest tu przekonujący. Wektor tysiącwymiarowy w postaci zmiennoprzecinkowej zajmuje cztery kilobajty, ten sam w postaci jednobajtowej kilobajt, a w postaci binarnej sto dwadzieścia osiem bajtów. Przy dziesięciu milionach fragmentów to różnica między czterdziestoma gigabajtami a nieco ponad gigabajtem.

Strata trafności jest wyraźnie mniejsza, niż sugerowałaby ta proporcja, przy czym postać binarna wymaga zwykle drugiego przejścia: najpierw szybkie wyszukiwanie w postaci skompresowanej, potem doprecyzowanie wyników na pełnych wektorach. Bazy wektorowe takie jak Qdrant i Weaviate obsługują ten układ wprost.

Wybór ustawień sprawdź na własnych danych, a nie z tabeli. Pięćdziesiąt realnych pytań z oczekiwanymi odpowiedziami, ten sam zbiór zaindeksowany trzema wariantami i porównanie, ile razy właściwy dokument trafił do pierwszej piątki.

Długi kontekst i cięcie fragmentów

Model przyjmuje bardzo długie wejścia, rzędu stu tysięcy tokenów w jednym wywołaniu. To kusi, żeby osadzać całe dokumenty zamiast dzielić je na fragmenty, i zwykle jest to zły pomysł.

Powód jest prosty: wektor jest uśrednieniem całej treści. Dokument obejmujący dwanaście tematów daje wektor, który nie leży blisko żadnego z nich, więc wyszukiwanie przestaje trafiać.

Długie wejście przydaje się do czegoś innego: do osadzania fragmentów, które naturalnie są długie, na przykład całego rozdziału umowy albo strony raportu razem z wykresem. Wtedy nie musisz dzielić czegoś, co stanowi całość, tylko dlatego, że model ma krótki limit.

Reguła praktyczna pozostaje taka sama niezależnie od dostawcy. Fragment ma odpowiadać jednostce, w której mieści się odpowiedź na pytanie. Przy dokumentacji to sekcja, przy umowie paragraf, przy raporcie strona. Sam limit modelu jest tu ograniczeniem górnym, a nie wskazówką.

Warto też pamiętać o rozliczeniu. Wysłanie dokumentu na sto tysięcy tokenów kosztuje dokładnie tyle, ile wysłanie stu fragmentów po tysiąc tokenów, bo płacisz za tokeny, a nie za wywołania. Nie ma więc oszczędności w osadzaniu całości, jest tylko gorsza trafność, a to czyni ten wybór przegranym po obu stronach.

Jest natomiast jeden przypadek, w którym długie wejście oszczędza pracę: dokumenty, których nie da się sensownie podzielić automatycznie. Tabela rozciągnięta na trzy strony albo formularz z powiązanymi polami tracą sens po przecięciu, więc lepiej osadzić je w całości i przyjąć gorszą trafność niż podzielić w miejscu, które niszczy znaczenie. Zanim uznasz dokument za niepodzielny, sprawdź jednak narzędzia czytające układ strony, jak Unstructured: rozpoznają one tabelę, nagłówek i listę jako osobne elementy i tną po ich granicach, a nie po liczbie znaków, więc część takich przypadków przestaje być problemem.

Wyszukiwanie po obrazach w praktyce

Skoro to główna przewaga tego modelu, warto pokazać, jak wygląda cały przepływ i gdzie kryją się decyzje.

Pierwsza dotyczy tego, co właściwie osadzasz. Przy prezentacji naturalną jednostką jest slajd, przy raporcie strona, przy katalogu produktów pojedyncze zdjęcie razem z opisem. Wybór jednostki jest tu ważniejszy niż przy tekście, bo obrazu nie da się podzielić tak łatwo jak akapitu.

Druga dotyczy rozdzielczości. Obraz o zbyt małej rozdzielczości gubi drobny tekst na wykresie, a zbyt duży kosztuje więcej, nie dając nic w zamian. Warto sprawdzić na kilku realnych stronach, przy jakiej rozdzielczości model zaczyna poprawnie odpowiadać na pytania o zawartość wykresu, i przyjąć ją jako standard.

Trzecia dotyczy tego, co robić z wynikiem. Wyszukiwanie zwraca stronę albo slajd, a użytkownik chce zobaczyć, gdzie dokładnie leży odpowiedź. Zachowanie razem z wektorem numeru strony, nazwy pliku i miniatury pozwala pokazać źródło, a to decyduje o zaufaniu do systemu bardziej niż sama trafność.

Czwarta, najczęściej pomijana, dotyczy zbioru mieszanego. Archiwum z tysiącem dokumentów tekstowych i stoma prezentacjami warto przetworzyć dwutorowo: tekst tanią ścieżką tekstową, prezentacje ścieżką obrazową. Wektory trafiają do jednego indeksu, bo leżą w tej samej przestrzeni, a rachunek jest kilkukrotnie niższy niż przy potraktowaniu wszystkiego jako obrazów.

Pomiar jakości wyszukiwania

Bez zestawu przypadków każda zmiana ustawień jest zgadywanką, a przy tym modelu ustawień jest sporo, więc warto ten zestaw zbudować od razu.

Zacznij od pięćdziesięciu realnych pytań, najlepiej takich, które ludzie faktycznie zadają, a nie wymyślonych do testu. Do każdego przypisz dokument albo fragment zawierający odpowiedź. Ta praca zajmuje dwie godziny i zwraca się przy pierwszej zmianie parametru.

Mierz dwie rzeczy. Pierwsza to udział pytań, dla których właściwy dokument znalazł się w pierwszej piątce wyników, bo tyle zwykle trafia do kontekstu modelu generującego odpowiedź. Druga to średnia pozycja właściwego dokumentu, bo ona pokazuje kierunek zmiany nawet wtedy, gdy pierwsza miara stoi w miejscu.

Ten sam zestaw pozwala odpowiedzieć na cztery pytania naraz: czy skrócenie wymiarów szkodzi, czy kwantyzacja szkodzi, czy inny sposób cięcia fragmentów pomaga i czy warto dopłacać za ścieżkę obrazową. Bez niego każde z tych pytań kończy się dyskusją opartą na wrażeniach.

Warto też zapisać wynik początkowy przed jakąkolwiek optymalizacją. Bez punktu odniesienia trudno stwierdzić, czy trzy tygodnie strojenia dały cokolwiek poza zmęczeniem.

Cohere Embed kontra alternatywy

Rozstrzygnięcie sprowadza się do jednego pytania: czy w Twoim zbiorze jest treść, której tekst nie oddaje. Jeśli archiwum to notatki, dokumentacja i korespondencja, tańsza opcja tekstowa wystarczy i różnicy nie zauważysz. Jeśli to prezentacje, formularze i skany, obsługa obrazów zmienia jakość wyszukiwania na tyle, że uzasadnia wyższą cenę.

Ostatni wiersz warto rozważyć świadomie, bo bywa wybierany z rozpędu. Dwa osobne modele oznaczają dwa indeksy, dwie skale podobieństwa i konieczność łączenia wyników z obu, co jest zadaniem trudniejszym, niż wygląda, bo wartości z różnych przestrzeni nie są porównywalne wprost.

Typowe błędy

Pierwszy to pominięcie typu wejścia albo użycie tego samego dla dokumentów i zapytań. Wyszukiwanie działa, zwraca wyniki i jest wyraźnie gorsze, więc problem długo pozostaje niezauważony.

Drugi to osadzanie całych dokumentów, bo model przyjmuje długie wejście. Wektor uśrednia treść, więc dokument o wielu tematach przestaje trafiać w cokolwiek.

Trzeci to kierowanie wszystkich stron do wariantu obrazowego. Obrazy kosztują blisko czterokrotnie więcej za token, a przy zwykłym tekście nie dają nic ponad wersję tekstową.

Czwarty to pominięcie kwantyzacji przy dużym zbiorze. Różnica w zajętości bazy sięga rzędów wielkości przy stracie trafności rzędu procentów.

Piąty to mieszanie wektorów z różnych modeli albo z różnych ustawień w jednym indeksie. Są nieporównywalne, więc wyniki stają się losowe.

Szósty to dobieranie ustawień z tabeli zamiast z pomiaru. Zbiór pięćdziesięciu realnych pytań z oczekiwanymi odpowiedziami rozstrzyga to w popołudnie i służy potem przy każdej kolejnej zmianie.

Siódmy to indeksowanie zbioru bez zapisania, jakimi ustawieniami powstał. Po pół roku nikt nie pamięta, czy wektory policzono przy tysiącu wymiarów czy przy pełnych, a bez tej informacji dołożenie nowych dokumentów do istniejącego indeksu daje wpisy nieporównywalne z resztą.

FAQ

Czym Embed v4 różni się od poprzedniej wersji?

Wejściami mieszanymi, długością kontekstu i wyborem liczby wymiarów. Poprzednia wersja też przyjmowała obrazy, ale każde wejście musiało być jednorodne, limit wynosił pięćset dwanaście tokenów, a wektor miał na stałe tysiąc dwadzieścia cztery wartości. Czwarta przyjmuje tekst, obrazy oraz tekst przeplatany obrazami w jednym wejściu, mieści sto dwadzieścia osiem tysięcy tokenów i pozwala wybrać długość wektora.

Co ustawić w parametrze typu wejścia?

Dla dokumentów trafiających do indeksu wartość przeznaczoną dla dokumentów, dla zapytań użytkownika wartość przeznaczoną dla zapytań. Osobne wartości istnieją też dla klasyfikacji i grupowania. Ten parametr jest wymagany i jego pominięcie albo pomylenie wyraźnie pogarsza trafność.

Czy kwantyzacja psuje wyniki?

Mniej, niż sugeruje proporcja oszczędności. Postać jednobajtowa daje czterokrotnie mniejszy indeks przy stracie rzędu procentów, a postać binarna kilkudziesięciokrotnie mniejszy, przy czym ta ostatnia wymaga zwykle doprecyzowania wyników na pełnych wektorach w drugim przejściu.

Ile to kosztuje wobec tańszych opcji?

Tekst kosztuje tu sześciokrotnie więcej niż u najtańszych dostawców, a obrazy blisko czterokrotnie więcej niż tekst. Przy zwykłym archiwum tekstowym różnica bywa nieuzasadniona, przy dokumentach z układem graficznym uzasadnia ją jakość wyszukiwania.

Gdzie trzymać gotowe wektory?

W dowolnej bazie wektorowej obsługującej wybrany format liczb. Przy kwantyzacji sprawdź to przed decyzją, bo nie wszystkie bazy obsługują postać binarną z doprecyzowaniem, a dołożenie tego później oznacza przebudowę indeksu. Przy małym zbiorze wystarczy rozwiązanie opisane w tekście o pgvectorze.

Dokumentacja modeli stoi na stronie producenta, a szczegóły czwartej wersji opisuje wpis o jej wydaniu.