Jak mierzyć jakość embeddingów: recall@k, MRR i benchmarki dziedzinowe

Regularnie widzimy ten sam scenariusz: zespół wybiera model embeddingów na podstawie pozycji w rankingu MTEB, wdraża go na produkcji i dopiero po kilku tygodniach skarg użytkowników odkrywa, że asystent nie znajduje oczywistych dokumentów. Publiczny benchmark mówi, jak model radzi sobie na cudzych danych po angielsku. Nie mówi nic o tym, jak poradzi sobie z Twoimi umowami, procedurami ISO czy zgłoszeniami serwisowymi po polsku. Jedyny wiarygodny pomiar to ewaluacja na zbiorze, który odzwierciedla rzeczywiste zapytania Twoich użytkowników.

Ewaluacja wyszukiwania semantycznego sprowadza się do jednego pytania: czy dla danego zapytania właściwe fragmenty pojawiają się wysoko na liście wyników. Mierzą to trzy uzupełniające się metryki.

Recall@k odpowiada, jaki odsetek oczekiwanych fragmentów znalazł się w top k wynikach. To metryka „czy w ogóle znaleźliśmy". Jeśli oczekujesz 3 trafnych dokumentów, a w top 5 pojawiły się 2, recall@5 wynosi 0,67. Recall@k jest kluczowy dla RAG, bo model generatywny widzi tylko to, co retrieval mu poda; brakujący fragment to brakujący kontekst i ryzyko halucynacji.

MRR (Mean Reciprocal Rank) mierzy, jak wysoko pojawia się pierwszy trafny wynik. Dla zapytania, w którym trafny dokument jest na pozycji 1, wkład wynosi 1; na pozycji 2 to 1/2; na pozycji 4 to 1/4. MRR uśrednia te odwrotności po wszystkich pytaniach. Wysoki MRR oznacza, że często trafiasz „za pierwszym razem", co pozwala podać modelowi mniej kontekstu i obniżyć koszty tokenów.

nDCG (normalized Discounted Cumulative Gain) to najbardziej wymagająca z trójki. Uwzględnia nie tylko, czy trafny wynik jest wysoko, ale też stopień trafności (możesz oznaczyć fragment jako „bardzo trafny" lub „częściowo trafny") i karze za umieszczanie słabszych wyników nad lepszymi. nDCG warto liczyć, gdy masz stopniowane oceny trafności, a nie tylko binarne „pasuje/nie pasuje".

Liczby w kolumnie „próg" to widełki obserwowane przez nas na projektach z polskimi dokumentami firmowymi, a nie uniwersalne stałe. Traktuj je jako punkt odniesienia do kalibracji, nie jako cel sam w sobie.

Bez golden setu nie masz czego mierzyć. Golden set to lista par: realistyczne pytanie + zbiór fragmentów, które powinny się pojawić w odpowiedzi. Budowa wygląda następująco.

Zacznij od zebrania 50-100 prawdziwych pytań. Najlepsze źródło to logi rzeczywistych zapytań do asystenta, zgłoszenia do supportu albo wywiady z osobami, które będą korzystać z systemu. Pytania wymyślone „przy biurku" są zbyt regularne i nie oddają języka użytkownika, który pisze z błędami, skrótami i w formach przypadkowych.

Dla każdego pytania oznacz fragmenty trafne. Tu pojawia się decyzja: oceny binarne (pasuje/nie pasuje) są szybsze, oceny stopniowane (bardzo trafny / częściowo trafny / nietrafny) dają bogatszy sygnał dla nDCG. Dla pierwszej iteracji wystarczą oceny binarne. Annotację powinna wykonać osoba znająca dziedzinę, nie model językowy, bo to model jest tu obiektem oceny.

Ważne, by korpus do ewaluacji był zindeksowany dokładnie tak samo jak produkcyjny: ta sama strategia chunkingu, ten sam rozmiar fragmentu, ten sam model. Jeśli zmienisz chunking między testem a produkcją, metryki przestają cokolwiek znaczyć. Wybór samej bazy wektorowej omawiamy osobno w artykule o tym, jak wybrać bazę wektorową.

Metryki liczone na golden secie to ewaluacja offline: kontrolowana, powtarzalna, tania. Ma jednak ograniczenia, których nie wolno ignorować.

Pierwsza pułapka to przeuczenie się do golden setu. Jeśli wielokrotnie stroisz pipeline pod ten sam zestaw 80 pytań, w końcu optymalizujesz pod te konkretne pytania, a nie pod realne zapytania. Trzymaj część par jako „set walidacyjny", którego nie używasz do strojenia. Druga pułapka to dryf danych: golden set zbudowany na korpusie sprzed pół roku przestaje odzwierciedlać dokumenty, które przybyły później.

Ewaluacja online mierzy zachowanie na żywym ruchu: klikalność wyników, odsetek zapytań kończących się eskalacją do człowieka, oceny kciuk w górę/w dół, odsetek odpowiedzi oznaczonych jako nietrafne. Sygnał jest „brudniejszy" niż offline, ale to on mówi prawdę o doświadczeniu użytkownika. Najlepsza praktyka to połączenie obu: offline jako szybka bramka przy każdej zmianie modelu lub chunkingu, online jako ostateczny arbiter na produkcji. Ten sam podział offline/online stosujemy przy ewaluacji agentów AI, gdzie testy syntetyczne weryfikują regresje, a metryki produkcyjne potwierdzają realną wartość.

Trzecia pułapka jest specyficzna dla RAG: dobry retrieval to warunek konieczny, ale nie wystarczający dla dobrej odpowiedzi. Możesz mieć recall@5 na poziomie 85%, a użytkownicy i tak będą niezadowoleni, bo model generatywny źle podsumowuje znaleziony kontekst. Dlatego metryki retrieval mierz osobno od metryk jakości odpowiedzi (faithfulness, trafność). Mylenie tych dwóch warstw to najczęstszy błąd diagnostyczny, jaki widzimy.

Polska fleksja sprawia, że ewaluacja embeddingów dla polszczyzny wymaga ostrożności. Użytkownik pyta o „fakturę", a dokument zawiera „faktur", „fakturze", „fakturami". Model słaby dla polskiego potraktuje te formy jako odległe punkty, więc trafny fragment spadnie w rankingu, mimo że treściowo pasuje idealnie. W golden secie celowo umieść pytania w formach przypadkowych i z diakrytyką wpisaną niedbale („wez" zamiast „weź"), bo tak piszą realni użytkownicy.

Drugi czynnik to korpus walidacyjny mieszany językowo. Polskie dokumenty firmowe są pełne angielskich terminów: compliance, vendor, deliverable, SLA. Jeśli Twój golden set zawiera wyłącznie czyste polskie zdania, przeszacujesz jakość modelu na danych, które w rzeczywistości są dwujęzyczne. Dobierając model, warto sięgnąć po taki z bogatym korpusem wielojęzycznym, na przykład BGE-M3; szerzej piszemy o tym w artykule o embeddingach dla języka polskiego.

Trzecia kwestia: gdy czysty retrieval wektorowy nie domyka się na polskich terminach branżowych i numerach katalogowych, warto zmierzyć, ile dokłada wyszukiwanie hybrydowe. Policz recall@5 dla samych wektorów, a potem dla wektorów połączonych z BM25 na tym samym golden secie. Jeśli różnica przekracza kilka punktów procentowych, hybryda się opłaca. Wszystkie te porównania mają sens tylko wtedy, gdy zmieniasz jedną zmienną naraz i mierzysz na niezmiennym zbiorze testowym.

Dla pierwszej, orientacyjnej oceny wystarczy 50-100 starannie dobranych par. Taki zbiór wyłapie rażące różnice między modelami i pozwoli odrzucić ewidentnie słabe opcje. Do stabilnych, statystycznie wiarygodnych porównań między zbliżonymi modelami warto dążyć do 200-300 par, bo przy małej próbie kilka trudnych pytań potrafi przesunąć wynik o kilka punktów procentowych.

Recall@k mówi, jaki odsetek wszystkich trafnych fragmentów znalazł się w top k, czyli mierzy pokrycie. Precision@k mówi, jaki odsetek wyników w top k jest faktycznie trafny, czyli mierzy „czystość" listy. W RAG zwykle priorytetem jest recall, bo brakujący kontekst boli bardziej niż jeden niepotrzebny fragment, który model generatywny i tak zignoruje. Precision zyskuje na znaczeniu, gdy fałszywe trafienia są kosztowne lub mylące.

Publiczne benchmarki są przydatne jako wstępny filtr, by zawęzić listę kandydatów, ale nie zastąpią pomiaru na Twoich danych. Korpusy MTEB i BEIR są w dużej mierze angielskie i ogólnodziedzinowe, więc słabo przewidują zachowanie na polskich umowach czy zgłoszeniach serwisowych. Traktuj ranking jako punkt startowy, a decyzję podejmij na podstawie własnego golden setu.

Offline-owy golden set warto przeliczać przy każdej zmianie modelu, strategii chunkingu lub rerankera, bo to szybka bramka regresji. Niezależnie od tego, raz na kwartał odśwież sam golden set o nowe pytania z produkcji, żeby nadążał za dryfem danych i języka użytkowników. Metryki online (oceny, eskalacje) monitoruj ciągle, podobnie jak przy monitoringu jakości agenta AI.

Nie. Wysoki recall oznacza tylko, że trafne fragmenty trafiają do kontekstu, co jest warunkiem koniecznym, ale nie wystarczającym. Model generatywny może źle podsumować dobry kontekst, pominąć kluczowy szczegół albo dodać informację spoza źródła. Dlatego jakość retrieval (recall, MRR, nDCG) mierz osobno od jakości odpowiedzi (faithfulness, trafność), bo to dwie różne warstwy z różnymi przyczynami awarii.