Zbuduj model osadzania specjalistyczny w mniej niż dzień

Gdy budujemy system RAG (Retrieval-Augmented Generation), zawsze dochodzimy do tego samego punktu krytycznego: ogólne modele embeddingów, trenowane na miliardach stron internetowych, okazują się bezradne wobec naszych danych. Nie rozumieją specjalistycznej terminologii w umowach, logach produkcyjnych czy wewnętrznych taksonomii. Mogą wychwyć ogólne podobieństwo semantyczne, ale nie potrafią dostrzec subtelnych różnic, które w danej dziedzinie stanowią wszystko. Problem polega na tym, że dostrajanie modelu embeddingów — proces, który powinien być standardem w każdej poważnej implementacji RAG — pozostaje zaskakująco fragmentaryczny, wymagający wyspecjalizowanych umiejętności i zajmuje nieprzepartą ilość czasu.

NVIDIA właśnie zmienia tę rzeczywistość. Zespół inżynierów z firmy opracował metodę, która pozwala przekształcić ogólnodostępny model embeddingów w narzędzie głęboko rozumiejące Twoją domenę — wszystko to na jednym GPU, w mniej niż 24 godziny, bez potrzeby ręcznego etykietowania danych. To nie jest kolejna obietnica startupowa. Atlassian testował ten przepis na swoim zbiorze danych JIRA i uzyskał wzrost Recall@60 z 0.751 do 0.951 — poprawę o 26 procent. Na jednym GPU.

To zmienia grę dla każdego, kto poważnie zajmuje się retrieval-augmented generation. Nie chodzi tu o marginalną optymalizację, lecz o skok jakościowy, który sprawia, że system przestaje zwracać przypadkowe wyniki i zaczyna rzeczywiście rozumieć kontekst Twojej branży.

Dlaczego ogólne modele embeddingów zawodzą w specjalistycznych domenach

Zanim przejdziemy do techniki, musimy zrozumieć, gdzie dokładnie zawodzą istniejące rozwiązania. Modele embeddingów takie jak OpenAI text-embedding-3 czy Cohere embed są trenowane na ogromnych, różnorodnych zbiorach danych z internetu. Są fantastyczne w tym, co robią — potrafią znaleźć podobieństwo między "samochód" a "pojazd" czy między artykułem o polityce a artykułem o wyborach. To semantyka ogólnego języka angielskiego.

Ale kiedy przychodzisz z dokumentacją API, raportami technicznymi z Twojej firmy czy specjalistyczną literaturą medyczną, te modele trafiają na ścianę. Weź pytanie: "Jaka jest maksymalna temperatura złącza dla GPU H100 w konfiguracji SXM?". Ogólny model embeddingów może znaleźć dokumenty o temperaturze, o GPU, o H100 — ale nie rozumie, że "temperatura złącza" (junction temperature) to coś fundamentalnie innego niż "temperatura otoczenia" (ambient temperature). W medycynie ta sama problem: pytanie o "metforminę w cukrzycy typu 2" może zwrócić artykuły o "insulinie w cukrzycy typu 1" — oba mówią o cukrzycy i lekach, ale odpowiedź byłaby katastrofalna.

Ogólne modele embeddingów rozumieją szerokie kategorie, ale nie dostrzegają drobnych distinkcji, które w Twojej domenie stanowią różnicę między dobrą a złą odpowiedzią. To jest dokładnie punkt, w którym dostrajanie (fine-tuning) zmienia wszystko.

Syntetyczne dane treningowe: jak uniknąć piekła ręcznego etykietowania

Tradycyjne podejście do dostrajania embeddingów wymagało czegoś okropnego: tysięcy ręcznie etykietowanych par (pytanie, dokument). Dla każdego pytania trzeba było wskazać, które dokumenty są "relevant", a które nie. To jest droga do szaleństwa — droga, czasochłonna, podatna na błędy oceny poszczególnych osób.

NVIDIA rozwiązała ten problem za pomocą syntetycznej generacji danych (SDG) napędzanej przez LLM. Zamiast ludzi, to model neuronowy czyta Twoje dokumenty i automatycznie generuje wysokiej jakości pary pytań i odpowiedzi. Proces działa w czterech etapach:

• Chunking dokumentów — dzielenie Twoich plików na logiczne fragmenty (zwykle 200–500 słów)
• Generacja pytań — LLM czyta każdy fragment i tworzy pytania, na które ten fragment odpowiada
• Generacja multi-hop pytań — model syntetyzuje pytania, które wymagają połączenia informacji z wielu fragmentów
• Ocena jakości — każda para jest oceniana pod kątem trafności, dokładności, jasności i wsparcia kontekstowego

Rezultat? Weź fragment dokumentacji o GPU H100: "Thermal design power (TDP) wynosi 700W w formie SXM. Rozwiązanie chłodzące musi utrzymywać temperaturę złącza poniżej 83°C pod stałymi obciążeniami. Chłodzenie cieczą jest zalecane dla gęstych wdrożeń przekraczających 4 GPU na węzeł, ponieważ chłodzenie powietrzem nie może rozproszyć wystarczającej ilości ciepła w standardowych obudowach 2U." Z tego fragmentu pipeline generuje zarówno proste pytania faktyczne ("Jaki jest TDP H100 SXM?"), jak i skomplikowane pytania przyczynowo-skutkowe ("Jak 700W TDP H100 SXM ogranicza wybór między chłodzeniem powietrzem a cieczą w multi-GPU?"). Każde pytanie ma przypisaną złożoność (2–5), typ rozumowania i ogólną ocenę jakości.

Tylko pary, które przejdą próg jakości, trafiają do danych treningowych. To oznacza, że zamiast tysięcy godzin ręcznego etykietowania, otrzymujesz tysięce wysokiej jakości par treningowych w kilka minut.

Hard negative mining: nauczanie modelu subtelnych różnic

Tutaj zaczyna się prawdziwa magia. Jeśli trenowałbyś embedding model tylko na parach pozytywnych (pytanie + prawidłowy dokument), model nauczyłby się rozróżniać oczywiste przypadki, ale zawaliłby się na trudnych. W prawdziwym systemie retrieval, najtrudniejsze są fragmenty, które wyglądają na relevant, ale nie są prawidłową odpowiedzią — "near-misses", które zmuszają model do myślenia.

Hard negative mining znajduje dokładnie te fragmenty. Oto jak to działa: pipeline bierze Twój bazowy model embeddingów i oblicza podobieństwo między każdym pytaniem a każdym fragmentem w Twojej kolekcji. Następnie maskuje znane pozytywne dokumenty i szuka fragmentów, które model uważa za bardzo relevant, ale które nie są prawidłową odpowiedzią. Kluczowy element: stosuje się margines bezpieczeństwa — fragmenty zbyt podobne do pozytywnych są odrzucane, ponieważ mogą być w rzeczywistości prawidłowymi odpowiedziami, które po prostu nie zostały etykietowane podczas generacji danych syntetycznych.

Rezultat: hard negatives to fragmenty, które są naprawdę mylące dla modelu — dostatecznie podobne, aby stanowiły wyzwanie, ale wystarczająco różne, aby być rzeczywiście negatywne. W medycznej kolekcji, pytanie o "metforminę w cukrzycy typu 2" może mieć hard negatives o "skutkach ubocznych metforminy" lub "insulinie w cukrzycy typu 1". Treningowanie na takich przykładach zmusza model do nauczenia się subtelnych distinkcji, które są krytyczne dla Twojej domeny.

Domyślnie pipeline wybiera 5 hard negatives na pytanie. To liczba, która — zgodnie z badaniami NVIDIA — stanowi optymalny punkt równowagi między siłą treningową a czasem obliczeniowym.

Multi-hop pytania: dlaczego pojedyncze fragmenty to za mało

Większość systemów retrieval trenuje się na prostych parach: jedno pytanie, jeden dokument. To działa dla pytań faktycznych ("Ile kosztuje?", "Kiedy się to stało?"), ale rzeczywisty świat jest bardziej skomplikowany. Użytkownicy zadają pytania, które wymagają syntezy informacji z wielu dokumentów.

Weź przykład: "Biorąc pod uwagę TDP H100, ograniczenia chłodzenia i limity gęstości stojaków, jaka jest maksymalna liczba GPU H100, które można rozmieścić w standardowym rzędzie data center?" To pytanie wymaga połączenia informacji z trzech różnych dokumentów — o TDP, o systemach chłodzenia i o ograniczeniach infrastrukturalnych.

Pipeline NVIDIA generuje pytania na 1 do 3 hopów. Każdy hop to jeden krok rozumowania. Pytania 1-hop są proste. Pytania 2-hop wymagają połączenia dwóch fragmentów. Pytania 3-hop syntetyzują trzy fragmenty. Każde pytanie ma przypisane ID segmentów, które je wspierają, więc dane treningowe zachowują pełny łańcuch rozumowania. Po rozwinięciu (unrolling), każda para (pytanie, fragment) staje się niezależnym sygnałem treningowym — model uczy się, że wszystkie te fragmenty są relevant dla multi-hop pytania. To oznacza, że dostrojony model nauczy się pobierać dokumenty, które są kontekstowo powiązane, a nie tylko leksykalnie podobne.

Proces dostrajania: od danych do wytrenowanego modelu

NVIDIA wybrała Llama-Nemotron-Embed-1B-v2 jako model bazowy do tego przepisu. To 1-miliardowy model parametrów — rozmiar, który stanowi doskonały kompromis między jakością a kosztem wnioskowania. Dostatecznie duży, aby rozumieć złożone semantykę, dostatecznie mały, aby działać na pojedynczym A100 lub H100.

Dostrajanie wykorzystuje contrastive learning z architekturą biencoder. Biencoder oznacza, że model ma dwa identyczne kodery: jeden dla pytań, jeden dla dokumentów. Oba kodery są identyczne — to ten sam model z tymi samymi wagami. Podczas treningowania, model uczy się kodować pytania i dokumenty w taki sposób, że pytania są blisko swoich pozytywnych dokumentów i daleko od hard negatives.

Kluczowy hiperparametr: temperatura wynosi 0.02 — celowo agresywna. Tworzy bardzo ostrą dystrybucję prawdopodobieństwa, co oznacza, że model otrzymuje silne gradienty, aby nauczył się różnicy między hard negatives a pozytywami. To działa, ponieważ hard negatives z kroku 2 są wysokiej jakości — rzeczywiście mylące fragmenty, które model musi się nauczyć rozróżniać.

Domyślne hiperparametry to: 3 epoki, learning rate 1e-5, batch size 128 (1 pozytywny + 4 hard negatives na pytanie). Dla dużych zbiorów danych możesz zmniejszyć epoki do 1–2. Dla małych zbiorów (poniżej 2000 przykładów), pipeline automatycznie skaluje batch size w dół do 16–64, aby gradienty były znaczące. To oznacza, że możesz zacząć z małą kolekcją (50–100 dokumentów) dla proof-of-concept i skalować później bez zmiany kodu.

Całe dostrajanie — od syntetycznych danych do wytrenowanego modelu — zajmuje mniej niż 24 godziny na jednym A100 lub H100. To jest punkt zwrotny dla każdego, kto pracuje z RAG w skali przedsiębiorstwa.

Ewaluacja: czy dostrajanie rzeczywiście pomogło?

Po dostrojeniu musisz wiedzieć, czy to zadziałało. NVIDIA wykorzystuje BEIR framework — standardowy benchmark dla ewaluacji information retrieval. Pipeline oblicza cztery metryki na zbiorze testowym (20% danych, odłożone na bok przed dostrajaniem):

• nDCG@k (Normalized Discounted Cumulative Gain) — jakość rankingu. Czy najlepsze dokumenty są rankowane wysoko?
• Recall@k — pokrycie. Jaki procent relevant dokumentów został pobrany w top-k wynikach?
• Precision@k — dokładność. Jaki procent pobranych dokumentów jest faktycznie relevant?
• MRR (Mean Reciprocal Rank) — na której pozycji pojawia się pierwszy relevant dokument?

Metryki są obliczane dla k = 1, 5, 10 i 100. To daje pełny obraz: jak model radzi sobie w ścisłym top-1, w rozsądnym top-10 i w szerszym top-100.

W testach NVIDIA na dokumentacji publicznej H100, dostrojony model wykazał ponad 10% poprawę zarówno w Recall@10, jak i NDCG@10 w porównaniu do modelu bazowego. Atlassian, testując ten przepis na swoim zbiorze JIRA, uzyskał wzrost Recall@60 z 0.751 do 0.951 — to jest 26% skok na jednym GPU. To nie jest marginalny wzrost. To jest skok, który zmienia użyteczność systemu.

Wdrażanie w produkcji: od modelu do serwisu

Po dostrojeniu i ewaluacji, masz wytrenowany model. Teraz trzeba go wdrożyć. NVIDIA dostarcza NeMo Export-Deploy do konwersji modelu do formatów ONNX i TensorRT — optymalizowanych dla produkcji. ONNX (Open Neural Network Exchange) to otwarty format, który pozwala modelom działać na różnych platformach. TensorRT to engine wnioskowania NVIDIA, który oferuje drastyczne przyspieszenie na GPU.

Dla serwowania w produkcji, NVIDIA rekomenduje NVIDIA NIM (NVIDIA Inference Microservices) — konteneryzowany serwis wnioskowania, który automatycznie obsługuje batching, cache'owanie i skalowanie. NIM pozwala Ci serwować model jako REST API bez pisania kodu infrastruktury — po prostu uruchamiasz kontener i wysyłasz pytania.

Cały workflow jest zintegrowany. Nie musisz łączyć narzędzi z pięciu różnych firm. To jest spójny pipeline od surowych dokumentów do produkcyjnego serwisu retrieval.

Praktyczne implikacje: kto powinien to robić teraz

Ten przepis nie jest teoretyczną ćwiczką. To jest praktyczne narzędzie dla konkretnych przypadków użycia. Jeśli budujasz system RAG dla firm, które mają: — Duże repozytoria wewnętrznych dokumentów (procedury, polityki, specjalistyczne raporty) — Specjalistyczną terminologię, która nie jest dobrze reprezentowana w ogólnych modelach — Wysokie wymagania dotyczące dokładności retrieval (błędne odpowiedzi są kosztowne) …wtedy dostrajanie embeddingów za pomocą tego przepisu jest nie do pominięcia.

Koszt jest minimalny: jedna GPU, mniej niż 24 godziny, bez ręcznego etykietowania. Zysk jest znaczący: 20–30% poprawa w recall, co oznacza, że Twój RAG system zwraca lepsze dokumenty, co oznacza, że LLM generuje lepsze odpowiedzi.

To jest punkt, w którym RAG przechodzi z "ciekawy eksperyment" na "produkcyjny system, na którym możemy polegać".