BGE, otwarte osadzenia wielojęzyczne

BGE, czyli otwarte osadzenia z trzema trybami naraz

BGE to rodzina otwartych modeli osadzeń rozwijana przez chiński instytut badawczy, wydawana na licencji swobodnej pozwalającej na użycie komercyjne. Modele uruchamiasz u siebie, więc nie ma kosztu za token ani wysyłania danych na zewnątrz.

Wyróżnikiem najbardziej znanego modelu z tej rodziny jest coś, czego u konkurencji zwykle nie ma: jeden model zwraca trzy różne reprezentacje tego samego tekstu w jednym przejściu. Zwykły wektor gęsty, wektor rzadki odpowiadający słowom oraz zestaw wektorów opisujących poszczególne fragmenty tekstu.

To rozwiązuje problem, który przy innych modelach wymaga utrzymywania dwóch osobnych systemów wyszukiwania. Poniżej opisuję, co z tego wynika w praktyce i kiedy warto z tego skorzystać.

Trzy tryby w jednym modelu

Warto zrozumieć, czym te reprezentacje się różnią, bo od tego zależy, którą wykorzystasz.

Wektor gęsty to klasyczne osadzenie: kilkaset liczb, gdzie bliskość oznacza podobieństwo znaczeń. Świetnie radzi sobie z pytaniem sformułowanym inaczej niż odpowiedź, i gubi dokładne dopasowania.

Wektor rzadki ma ogromną liczbę wymiarów odpowiadających słowom, z których niemal wszystkie są zerami. Działa jak wyszukiwanie po słowach kluczowych, przy czym model sam ocenia, które słowa są istotne, i uwzględnia formy pokrewne. Trafia tam, gdzie liczy się konkretny numer, kod albo nazwa własna.

Trzeci tryb zwraca osobny wektor dla każdego fragmentu tekstu i porównuje je z fragmentami zapytania. Daje najwyższą trafność i kosztuje najwięcej miejsca oraz czasu, więc stosuje się go zwykle jako ostatni krok, do doprecyzowania kilkudziesięciu kandydatów.

from FlagEmbedding import BGEM3FlagModel

model = BGEM3FlagModel("BAAI/bge-m3", use_fp16=True)

wynik = model.encode(
    fragmenty,
    return_dense=True,
    return_sparse=True,
    return_colbert_vecs=False,
)

Kluczowe jest to, że wszystkie trzy powstają w jednym przebiegu. Przy innych rozwiązaniach wyszukiwanie hybrydowe wymaga dwóch modeli, dwóch indeksów i dwóch przejść przez archiwum. Tutaj płacisz raz i decydujesz, czego użyjesz.

Wielojęzyczność, która działa

To drugi wyróżnik i przy polskich dokumentach ważniejszy niż pierwszy.

Model obsługuje ponad sto języków i, co istotniejsze, radzi sobie z wyszukiwaniem między nimi. Pytanie po polsku może odnaleźć dokument po angielsku, bo teksty o tym samym znaczeniu w różnych językach leżą blisko siebie w tej samej przestrzeni.

Przy archiwum firmowym to bywa rozstrzygające. Dokumentacja techniczna po angielsku, korespondencja po polsku, umowy w obu wersjach: jeden indeks obsługuje wszystko, bez tłumaczenia czegokolwiek i bez osobnych zbiorów na język.

Warto natomiast sprawdzić to na własnych danych, bo jakość różni się między językami. Model uczono na zbiorze, w którym niektóre języki są reprezentowane lepiej niż inne, więc deklarowana obsługa stu języków nie oznacza jednakowej trafności we wszystkich.

Test zajmuje popołudnie: pięćdziesiąt realnych pytań po polsku z oczekiwanymi odpowiedziami, porównanie z modelem komercyjnym na tym samym zbiorze i sprawdzenie, ile razy właściwy dokument trafił do pierwszej piątki.

Model przyjmuje też wyjątkowo długie wejście, rzędu ośmiu tysięcy tokenów, czyli mniej więcej dwudziestu stron tekstu. To wygodne przy dokumentach, których nie da się sensownie podzielić, na przykład tabeli rozciągniętej na kilka stron. Nie jest natomiast zachętą do osadzania całych dokumentów, bo wektor uśrednia treść, więc dokument obejmujący dwanaście tematów przestaje trafiać w cokolwiek. Limit modelu traktuj jako ograniczenie górne, a nie jako wskazówkę.

Modele oceniające kandydatów

Osobną częścią rodziny są modele porównujące parę zapytanie i dokument, widzące oba naraz.

Różnica wobec osadzeń jest zasadnicza. Model osadzeń liczy wektor dokumentu raz, bez znajomości pytania, więc porównanie sprowadza się do odległości dwóch punktów. Model oceniający widzi jedno i drugie razem, przez co ocenia dopasowanie znacznie dokładniej, kosztem czasu, bo musi wykonać się dla każdej pary osobno.

Stąd układ dwuetapowy, który warto uznać za domyślny przy poważnym wyszukiwaniu. Tanie wyszukiwanie wektorowe zwraca pięćdziesiąt kandydatów z całego archiwum, a model oceniający wybiera z nich pięć najlepszych.

Dołożenie tego kroku to zwykle największy pojedynczy skok trafności, jaki da się osiągnąć bez zmiany modelu osadzeń ani sposobu cięcia dokumentów. Warto sprawdzić go wcześniej niż dostrajanie, bo kosztuje ułamek tej pracy.

W rodzinie znajdziesz modele oceniające w kilku rozmiarach, w tym warianty zaprojektowane pod niższy koszt obliczeniowy. Wybór między nimi to zwykły kompromis: większy jest trafniejszy i wolniejszy, a przy pięćdziesięciu kandydatach na zapytanie ta różnica przekłada się wprost na czas odpowiedzi.

Sprzęt i wydajność

Modele z tej rodziny są większe niż typowe osadzenia komercyjne, bo obsługują wiele języków i wiele trybów naraz, więc warto zaplanować sprzęt.

Do obsługi zapytań przychodzących pojedynczo procesor wystarcza, choć czas liczenia jest zauważalnie wyższy niż przy modelach mniejszych. Przy aplikacji, gdzie zapytanie i tak czeka na model językowy, ta różnica ginie w całości.

Do indeksowania karta graficzna zmienia sytuację radykalnie. Przetworzenie stu tysięcy fragmentów na procesorze to wiele godzin, na karcie kilkanaście minut. Jeśli archiwum aktualizuje się codziennie, karta zwraca się w pierwszym miesiącu.

Trzy ustawienia dają największą różnicę bez zmiany modelu. Pierwsze to zmniejszona precyzja liczb, skracająca czas mniej więcej dwukrotnie przy stracie praktycznie niezauważalnej. Drugie to przetwarzanie partiami zamiast pojedynczo. Trzecie to wyłączenie trybów, których nie używasz, bo liczenie wszystkich trzech reprezentacji kosztuje więcej niż liczenie jednej.

To ostatnie bywa pomijane, a różnica jest realna. Jeśli budujesz wyłącznie wyszukiwanie gęste, wyłącz pozostałe dwa tryby w wywołaniu i zyskasz zauważalnie na czasie oraz na miejscu w bazie.

Warto też przemyśleć, gdzie model ma działać. Wczytanie go osobno w każdym procesie aplikacji oznacza tyle kopii w pamięci, ile masz procesów, a te modele są duże. Sensowniejszy układ to osobna usługa licząca wektory, odpytywana przez resztę aplikacji, z jedną kopią modelu wczytaną raz przy starcie i jednym sztucznym zapytaniem na rozgrzewkę, żeby pierwszy prawdziwy użytkownik nie płacił za inicjalizację.

Jak połączyć wyniki z dwóch trybów

Skoro model daje wektor gęsty i rzadki naraz, trzeba jeszcze zdecydować, jak zestawić wyniki obu wyszukiwań w jedną listę. To krok, który przy wyszukiwaniu hybrydowym decyduje o wszystkim, a bywa robiony na wyczucie.

Naiwne podejście polega na dodaniu wyników do siebie. Nie działa, bo skale są nieporównywalne: podobieństwo wektorów gęstych mieści się zwykle w wąskim zakresie, a wynik wyszukiwania rzadkiego może przyjmować dowolnie duże wartości zależnie od długości zapytania.

Podejście, które sprawdza się w praktyce, ignoruje wartości i patrzy wyłącznie na pozycje. Dokument, który w jednym wyszukiwaniu wypadł trzeci, a w drugim siódmy, dostaje wynik złożony z odwrotności obu pozycji. Metoda jest prosta, nie wymaga strojenia progów i jest odporna na to, że jedno wyszukiwanie zwraca wartości w zupełnie innej skali niż drugie.

Alternatywa polega na normalizacji obu list do wspólnego zakresu i zsumowaniu z wagami. Daje większą kontrolę i wymaga dobrania wag na własnym zestawie pytań, więc warto po nią sięgnąć dopiero wtedy, gdy prostsza metoda okaże się niewystarczająca.

Warto sprawdzić na własnych danych, czy wyszukiwanie hybrydowe w ogóle poprawia wynik. Przy dokumentach opisowych, bez numerów i kodów, samo wyszukiwanie gęste bywa równie dobre, a dokładanie drugiej warstwy tylko komplikuje system.

Dostrajanie i granice tego podejścia

Modele z tej rodziny da się dostroić na własnych danych, co jest przewagą, której usługi komercyjne nie dają wcale.

Zysk pojawia się przy słownictwie specjalistycznym: skrótach używanych w jednej firmie, nazwach produktów, terminach branżowych, których model ogólny nie kojarzy ze sobą. Kilka tysięcy par pytanie i fragment z odpowiedzią wystarcza, żeby model nauczył się tych powiązań.

Trzeba jednak powiedzieć wprost, w jakiej kolejności to robić, bo dostrajanie kusi bardziej, niż na to zasługuje. Najpierw popraw cięcie dokumentów na fragmenty, bo to zmienia trafność najbardziej i kosztuje najmniej. Potem dołóż model oceniający kandydatów. Dopiero gdy oba kroki nie wystarczą, sięgaj po dostrajanie, bo to praca na kilka dni i wymaga zbudowania zbioru treningowego.

Granica całego podejścia leży gdzie indziej i warto ją znać. Osadzenia znajdują dokumenty podobne znaczeniowo do pytania, a nie odpowiadają na pytanie. Jeśli odpowiedź wymaga zestawienia informacji z trzech dokumentów albo policzenia czegoś, żaden model osadzeń tego nie zrobi, bo to zadanie dla warstwy generującej odpowiedź.

Drugą granicą jest aktualność. Wektory odzwierciedlają stan dokumentu z chwili indeksowania, więc dokument zmieniony albo wycofany musi zostać ponownie przetworzony lub usunięty z indeksu. Bez tego wyszukiwanie zwraca treści, których już nie ma, a to jest błąd trudniejszy do zauważenia niż brak wyników.

BGE kontra alternatywy

Drugi wiersz nie jest tu konkurencją, tylko warstwą obok. Biblioteka do pracy z modelami lokalnymi potrafi wczytać modele z tej rodziny i daje wygodniejszy interfejs, więc typowe wdrożenie używa obu naraz.

Wybór między pierwszym a trzecim wierszem sprowadza się do dwóch pytań. Czy dane mogą opuścić firmę, bo jeśli nie, to nie ma o czym dyskutować. Oraz czy wolumen jest na tyle duży, żeby koszt stały wyszedł taniej niż zmienny, co przy kilku tysiącach zapytań dziennie zwykle nie zachodzi.

Typowe błędy

Pierwszy to liczenie wszystkich trzech reprezentacji, gdy używasz jednej. Wyłączenie zbędnych trybów w wywołaniu skraca czas i zmniejsza zajętość bazy.

Drugi to zakładanie jednakowej jakości we wszystkich obsługiwanych językach. Deklarowana obsługa stu języków nie oznacza jednakowej trafności, więc sprawdź swój przypadek na własnych pytaniach.

Trzeci to pominięcie modelu oceniającego kandydatów. To zwykle największy skok trafności przy najmniejszym nakładzie pracy.

Czwarty to indeksowanie dużego archiwum na procesorze. Karta graficzna zamienia wiele godzin w kilkanaście minut i przy regularnych aktualizacjach zwraca się szybko.

Piąty to mieszanie wektorów z różnych wersji modelu w jednym indeksie. Są nieporównywalne, a objawem są gorsze wyniki bez żadnego komunikatu o błędzie.

Szósty to wybór modelu wyłącznie na podstawie pozycji w publicznym rankingu. Zestawienia mierzą zadania uśrednione po wielu dziedzinach, a Twoje dokumenty należą do jednej dziedziny i jednego języka.

FAQ

Czy BGE jest darmowe?

Tak, modele są otwarte i wydane na licencji pozwalającej na użycie komercyjne. Płacisz wyłącznie za sprzęt, na którym je uruchamiasz, oraz za czas potrzebny na wdrożenie i utrzymanie.

Na czym polega obsługa trzech trybów naraz?

Jeden model zwraca w jednym przejściu wektor gęsty, wektor rzadki odpowiadający słowom oraz zestaw wektorów opisujących fragmenty tekstu. Przy innych rozwiązaniach wyszukiwanie hybrydowe wymaga dwóch modeli i dwóch indeksów, tutaj wystarczy jeden przebieg przez archiwum.

Czy działa dobrze po polsku?

Model obsługuje ponad sto języków i radzi sobie z wyszukiwaniem między nimi, więc pytanie po polsku może znaleźć dokument po angielsku. Jakość różni się jednak między językami, więc warto sprawdzić to na własnym zestawie pytań przed decyzją.

Jaki sprzęt jest potrzebny?

Do obsługi pojedynczych zapytań wystarcza procesor. Do indeksowania większego archiwum karta graficzna skraca czas z wielu godzin do kilkunastu minut, więc przy regularnych aktualizacjach jest praktycznie konieczna.

Gdzie trzymać policzone wektory?

W bazie wektorowej obsługującej wybrane tryby, na przykład opisanej w tekście o Qdrancie. Przy wektorach rzadkich sprawdź wsparcie przed decyzją, bo nie każda baza obsługuje je równie dobrze, a dołożenie tego później oznacza przebudowę indeksu.

Modele i dokumentacja stoją na stronie projektu, a kod narzędzi w repozytorium na GitHubie.