Przebudowa wyszukiwarki kandydatów, rozstrzygnięta benchmarkiem

02Benchmark z realnego ruchu, anotowany ręcznie

Z zebranych logów powstał profil realnych zapytań: jakie role, miasta, progi stażu i wymagania językowe rzeczywiście stawiają rekruterzy. Benchmark to 50 wzorcowych ogłoszeń odwzorowujących ten rozkład — nie wymyślone przypadki, tylko lustro ruchu przy bazie kilku tysięcy CV.

Oczekiwania każdego ogłoszenia są spisane ręcznie: czego wymaga, czego nie wymaga, które warunki są twarde. Ręcznie, bo benchmark, którego oczekiwania pochodzą z testowanego kodu, sprawdza tylko zgodność kodu z samym sobą. Osobna grupa ogłoszeń pomiarowych różni się od bazowego dokładnie jednym warunkiem — progiem stażu, widełkami, branżą — więc różnica w wyniku jest ceną tego jednego warunku, a nie mieszanką pięciu przyczyn naraz.

03Sędzia AI, skalibrowany jak przyrząd

Miarą jakości jest pełny raport AI — niezależna druga opinia, która nie widzi punktacji systemu, bo sędzia znający cudzy wynik przestaje być niezależną miarą. Zanim zaufałem jego werdyktom, zmierzyłem sam przyrząd: powtarzalność ocen przy deterministycznym tasowaniu kolejności podania kandydatów (modele faworyzują to, co przeczytały wcześniej) i praktyczny sufit zgodności około 80% — tyle daje ten sam sędzia uruchomiony dwa razy na tej samej liście. Stuprocentowa zgodność nie istnieje dla żadnego podejścia.

Kalibracja dała dwa wnioski ogólniejsze niż ten projekt. Po pierwsze: ogólna zasada w prompcie — „czego ogłoszenie nie postawiło, tego nie punktuj” — była łamana w co trzecim przypadku, a ta sama zasada podana jako wyliczona lista konkretów była respektowana w stu procentach. Apelowanie nie działa, wyliczanie działa. Po drugie: warianty promptu, w tym wzbogacenie sędziego o pełny przebieg zatrudnienia, też zostały zmierzone — i odrzucone, z zapisanymi liczbami i powodem, żeby nikt nie odkrywał tego samego drugi raz.

04Druga wersja silnika — w izolacji, w trzech fazach

Nowy potok powstał obok produkcyjnego, rozdzielony na poziomie plików, nie flag konfiguracyjnych — użytkownicy przez cały czas pracowali na starej wersji, a ścieżka produkcyjna pozostała nietknięta co do bajta.

Faza pierwsza zawęża pulę twardymi warunkami ogłoszenia już przy pobieraniu z bazy wektorowej. Faza druga to bramki redukcji, z których każda odpowiada na jedno pytanie; staż liczony jest kalendarzowo i w zakresie zapytania — dwadzieścia lat w handlu i dwa w księgowości to przy szukaniu księgowej dwa lata — a lejek zapisuje komplet powodów odrzutu, z licznikiem „ilu kandydatów wróci po rozluźnieniu tego warunku”. Faza trzecia punktuje wyłącznie wymiary, które ogłoszenie faktycznie stawia i których nie rozstrzygnęły już filtry: udział ocen 97+, które niczego nie różnicowały, spadł z połowy zapisanych wyników do zera.

Na końcu potoku stoi lekki reranker LLM — realizacja wniosku z odrzuconego cross-encodera. Porządkuje gotową shortlistę, ale nie ma prawa nikogo odrzucić ani dodać, a każde odstępstwo odpowiedzi od pełnej permutacji oznacza powrót do kolejności punktacji, ze śladem w logu. Ten krok też wszedł po pomiarze, nie z wiary: w pilotażu jego kolejność zgadzała się z werdyktem mocniejszego modelu w 66%, sama punktacja w 39% — i to głównie on odpowiada za zgodność kolejności z raportem AI w wynikach poniżej.

05Wagi z pomiaru, nie z wyczucia

Które składowe naprawdę przewidują werdykt sędziego? Korelacje policzyłem wewnątrz pojedynczego ogłoszenia — tam, gdzie ranking powstaje; liczone w poprzek wyszukiwań dawały wnioski odwrotne i to był wcześniejszy błąd metodyczny. Wynik: dopasowanie umiejętności okazało się sygnałem losowym — znak korelacji skakał z ogłoszenia na ogłoszenie — a niosło około dwóch trzecich wyniku. Jedynym konsekwentnym predyktorem było podobieństwo wektorowe.

Nowe wagi leżą na środku szerokiego płaskowyżu, nie na szpilce dopasowanej do szumu, a walidacja na odłożonym ogłoszeniu potwierdziła kierunek: zgodność z sędzią wzrosła z 15% do 41%, pokrycie pierwszej piątki z 58% do 78%.

06Testy bez wołania modelu

Odpowiedź modelu zamienia się w tym potoku w twarde filtry, więc przypadków brzegowych nie da się badać na żywym API: kosztuje, jest niedeterministyczne i nie zostaje w repozytorium. Atrapa modelu zwraca surowy tekst, nie gotowy obiekt — bo połowa realnych usterek mieszka w tekście: płotki markdownu przed JSON-em, zdanie wstępu, odpowiedź ucięta na limicie.

Testy pisane z wymagań biznesowych przed kodem znalazły realne błędy — deklarację poziomu B2 czytaną jako biegłość, bo ogólniejszy wzorzec był sprawdzany pierwszy, i miasto znikające z warunków przez pomyłkę typu w odpowiedzi modelu, po której pula szła na całą Polskę, a wynik wyglądał normalnie, tylko odpowiadał na inne pytanie. Zestaw urósł do ponad 440 testów offline; kontrakt promptu stoi osobno, bo jako jedyny kosztuje.

07Wynik: 50 ogłoszeń, oba podejścia, ten sam sędzia

Każde z 50 ogłoszeń benchmarku poszło do obu wersji, a każdą listę ocenił pełny raport AI — z uczciwie opisanym lejkiem danego podejścia, żeby żadnemu nie punktować kryteriów rozstrzygniętych już przez jego filtry. Koszt całego testu: około 4 USD.

Cena tej jakości jest policzona, nie przemilczana: średni czas wyszukiwania 22,6 s wobec 11,5 s — różnica to głównie krok układania kolejności przez model — a koszt samego zapytania ok. 0,008 USD wobec 0,003 USD.

08Wdrożenie: nowa wersja przejmuje ruch

Jak wyglądało samo przepięcie

Benchmark rozstrzyga spór, ale wdraża się kod, nie benchmark. Między testem a przepięciem weszła jeszcze ręczna kontrola sześciu ogłoszeń przez testera, człowieka. Najostrzejszy przypadek: na ogłoszeniu o kontrolera finansowego stara wersja ułożyła listę odwrotnie do ocen człowieka, a nowa zgodnie z nimi.

Samo przepięcie zrobiłem odwrotnie, niż podpowiada wygoda: do modułu produkcyjnego pojechał kod nowego silnika, zamiast przepiąć ruch klientów na moduł badawczy. Przepięcie ruchu dałoby potok, którego nigdy nie zmierzyłem w całości — nową listę ocenianą starym promptem. Cała obudowa produkcyjna została nietknięta: logowanie, anonimizacja danych osobowych, kontrakt odpowiedzi. Zmienia się silnik, nie funkcjonalność.

Przed wdrożeniem, nie po: dowód, że kopia jest wierna (różnice wobec wersji badawczej to wyłącznie zmiany zamierzone), test równoważności wyników na ośmiu ogłoszeniach, kontrola anonimizacji na ścieżce klienckiej i opisana z góry ścieżka odwrotu — bez migracji bazy, więc powrót nie wymaga przeliczania niczego. Do każdego zapisanego wyszukiwania dopisywany jest znacznik wersji silnika, żeby za rok dało się w danych odróżnić wiersze sprzed przepięcia od tych po nim.

Cztery klasy defektów, które zeszły z produkcji

Kolejność da się zmierzyć bez szumu, średniej oceny nie — dlatego drugim dowodem nie są punkty, tylko cztery klasy defektów, które zniknęły z listy klienta. Skalę każdej policzyłem w logach realnych wyszukiwań, zanim poprawka weszła.

Powtarzalność, której nie zamawiał żaden benchmark

Regresja jest jedna i też jest policzona: mediana wyszukiwania rośnie z 8,4 s do 27,9 s, z czego 13,3 s to samo układanie kolejności przez model, przy koszcie około czterech groszy za wyszukiwanie. Rachunek ma nieoczywistą strukturę — przy kilkudziesięciu tokenach odpowiedzi model zużywa około 2800 tokenów „myślenia” rozliczanych jak wyjście, czyli 85% ceny wywołania.