Wybór modelu embeddingów do firmowej bazy wiedzy
Każdy asystent oparty na retrieval augmented generation stoi na jednym elemencie, o którym nikt nie mówi na etapie demo: modelu embeddingów. To on decyduje, które fragmenty wrócą, gdy ktoś zada pytanie, a wszystko dalej dziedziczy tę decyzję. Traktujemy ten wybór jak problem inżynierski z mierzalnymi odpowiedziami. Nie jak sięganie po to, co w zeszłym miesiącu było na szczycie rankingu.
Co naprawdę rozstrzyga model embeddingów
Model zamienia fragmenty dokumentów i pytania użytkowników na wektory. Jakość wyszukiwania jest ograniczona tym, jak czysto rozdziela on twój materiał - i żaden model generujący, choćby najmocniejszy, nie uratuje słabego retrievera. Asystent odpowiada tylko z tekstu, który dostał. Słabe wyszukiwanie to nie tylko mgliste zdania, ale też złe źródła przy odpowiedzi, bo podane źródło to po prostu to, co wróciło z indeksu. Trzymaj trzy zadania osobno: chunking, embedding, reranking.
Zacznij od własnego korpusu, nie od rankingu
Publiczne benchmarki mierzą ogólne teksty z sieci i prace naukowe. Twoja baza wiedzy to umowy, zgłoszenia, procedury, karty katalogowe i notatki ze spotkań. Numery katalogowe, wewnętrzne nazwy produktów i firmowe skróty źle zachowują się w modelach ogólnego przeznaczenia, a materiał wielojęzyczny wymaga modelu wielojęzycznego, nawet jeśli interfejs jest tylko po angielsku. Zapisz te cechy korpusu, zanim zaczniesz układać krótką listę:
- Występujące języki, łącznie z tymi sporadycznymi
- Typy dokumentów i ich udział w całości
- Średnia długość fragmentu po zastosowaniu twoich reguł chunkingu
- Udział tabel i bloków kodu
- Częstotliwość aktualizacji i poziom wrażliwości danych
Hostowane API czy własne wagi
Hostowane API daje mocny punkt wyjścia bez GPU do pilnowania. Ceną jest to, że każdy dokument i każde zapytanie opuszcza sieć. Modele open weight działają na sprzęcie klienta i przy materiale regulowanym albo poufnym to często jedyna dopuszczalna odpowiedź. Różni się też czas odpowiedzi: wywołanie API dokłada podróż w obie strony, której rozgrzane lokalne GPU nie ma. Zmiana modelu później oznacza policzenie embeddingów dla wszystkiego od nowa, więc traktuj ten wybór jako półtrwały i wersjonuj indeks.
Wymiary, okno kontekstu i koszt indeksu
Szerokość wektora decyduje o miejscu na dysku i w pamięci bazy, a szerszy nie znaczy automatycznie lepiej wyszukujący. Modele z możliwością obcięcia wymiarów pozwalają oddać odrobinę trafności za dużo mniejszy indeks, co zaczyna mieć znaczenie, gdy korpus rośnie. Limit wejścia wyznacza twardy sufit dla wielkości fragmentu - wszystko dłuższe zostaje po cichu ucięte. Wskazówka: mierz rozmiar indeksu i czas zapytania na swojej realnej liczbie dokumentów, nigdy na kilkuset przykładowych fragmentach.
Zbuduj zestaw testowy z prawdziwych pytań
Zbierz to, o co naprawdę pytają ludzie, którzy będą korzystać z asystenta. Razem z przykładami źle sformułowanymi. Oznacz fragment, który odpowiada na każde z nich, a potem oceniaj kandydatów przez recall at k zamiast subiektywnych rzutów oka. Od pięćdziesięciu do dwustu oznaczonych pytań zwykle wystarcza, żeby oddzielić poważnych kandydatów od reszty.
- Zbierz prawdziwe pytania od przyszłych użytkowników
- Zaznacz do każdego wzorcowy fragment
- Policz embeddingi korpusu każdym kandydującym modelem
- Puść identyczne zapytania na każdym indeksie
- Porównaj trafienia at k, potem obejrzyj pudła ręcznie
Gdzie się mieści reranker
Cross encoder czyta zapytanie i fragment razem, przestawia szerszą listę kandydatów i wyłapuje to, czego samo podobieństwo wektorów nie widzi. Typowy układ: wyszukaj szeroko szybkim modelem, przestaw kolejność najlepszych kandydatów, przekaż mały zestaw do generowania. W praktyce daje to więcej trafności niż wymiana modelu embeddingów, a płacisz za to dodatkową inferencją przy każdym zapytaniu. Wskazówka: zanim wymienisz model, zwiększ k i dołóż reranker - to dużo taniej niż liczenie embeddingów całego korpusu od nowa.
Praktyczna ścieżka wyboru
Wybierz dwa albo trzy modele spełniające ograniczenie wdrożeniowe, a potem uszereguj je według zmierzonej jakości wyszukiwania na własnym zestawie. Trzymaj pipeline niezależny od modelu: zapisuj nazwę i wersję modelu przy każdym wektorze, żeby migracja była przebudową, a nie przepisywaniem. Wracaj do oceny, gdy korpus rośnie i pojawiają się nowe typy dokumentów. I miej na oku wyszukiwanie hybrydowe, bo dopasowanie po słowach kluczowych nadal wygrywa przy dokładnych identyfikatorach i kodach błędów.
FAQ
Czy musimy dotrenować model embeddingów na własnych dokumentach?
Zwykle nie. Lepszy chunking, wyszukiwanie hybrydowe i reranker dają więcej mniejszym nakładem, a dotrenowanie zostawia cię z obowiązkiem powtarzania treningu przy każdej zmianie korpusu.
Co się stanie, jeśli później zmienimy model embeddingów?
Cały korpus dostaje embeddingi od nowa, a indeks trzeba przebudować. Zapytania i zapisane wektory zawsze muszą pochodzić z tego samego modelu, więc częściowa migracja daje ciche bzdury.
Czy jeden model obsłuży dokumenty w kilku językach?
Model wielojęzyczny może, ale sprawdź wyszukiwanie między językami na własnym zestawie testowym, zamiast wierzyć etykiecie.
Podsumowanie
Kolejność, która działa: najpierw ograniczenie wdrożeniowe, potem dopasowanie do korpusu, na końcu zmierzona jakość wyszukiwania na pytaniach, które użytkownicy naprawdę zadają. Benchmarki zawężają krótką listę. Zwycięzcę wybiera oznaczony zestaw testowy. Zaprojektuj pipeline tak, żeby model dało się wymienić bez ruszania logiki aplikacji, bo prędzej czy później trzeba będzie.
