Po czterech miesiącach przenoszenia potoku RAG (Retrieval-Augmented Generation) z notatnika Jupyter do działającej usługi, autor wskazał pięć konkretnych wyborów, które zmieniły efektowne demo w system, na którym użytkownicy mogą polegać. Różnica jest widoczna w liczbach: prosta zmiana sposobu dzielenia tekstu podniosła wskaźnik trafień (hit rate) z 61% do 83%, a skromny zestaw ewaluacyjny składający się z 200 rzeczywistych zapytań wyłapuje większość regresji, zanim dotrą one do klientów.

Dlaczego to ma znaczenie

Demo RAG robią wrażenie – w kilka sekund pobierają fragment tekstu i generują prawdopodobną odpowiedź. W środowisku produkcyjnym ten sam sposób często zwraca nieaktualne fakty, pomija kody błędów lub generuje urwane zdania, co podważa zaufanie użytkowników. Wąskim gardłem rzadko jest model językowy; problemem jest sposób pobierania, indeksowania i serwowania treści. Prawidłowe skonfigurowanie potoku może decydować o tym, czy produkt wnosi wartość, czy staje się obciążeniem.

1. Przestań używać fragmentów o stałej wielkości

Wiele prototypów dzieli każdy dokument na bloki po 512 tokenów. Działa to przy krótkich tekstach, ale niszczy instrukcje techniczne, wątki wsparcia i fragmenty kodu. Zdania są dzielone, nagłówki znikają, a silnik wyszukiwania nie może dopasować kontekstu, którego oczekuje użytkownik.

Przejdź na dzielenie uwzględniające strukturę (structure-aware chunking) – dziel na poziomie nagłówków, granic konwersacji lub bloków kodu – aby zachować jednostki semantyczne. W systemie autora samo to zwiększyło odsetek zapytań znajdujących istotny fragment z 61% do 83%. Poprawa wynika ze zmiany formatu danych; sam model pozostaje ten sam.

2. Stosuj wyszukiwanie hybrydowe

Czyste wyszukiwanie wektorowe (oparte na podobieństwie embeddingów) świetnie radzi sobie z znajdowaniem fragmentów o tym samym znaczeniu, ale zawodzi przy dokładnych identyfikatorach, takich jak kody błędów, numery wersji czy terminologia specjalistyczna. Użytkownik szukający kodu błędu typu „ERR-XXXX” może otrzymać semantycznie podobny akapit, który w ogóle nie zawiera tego kodu.

Wyszukiwanie hybrydowe łączy gęsty indeks wektorowy z tradycyjnym indeksem BM25 (opartym na częstotliwości występowania słów). Poprzez ważenie obu wyników, system odnajduje elementy, które są zarówno semantycznie bliskie, jak i zawierają dokładne terminy wpisane przez użytkownika. W produkcji wyszukiwanie hybrydowe to wymóg podstawowy, a nie opcjonalny dodatek.

3. Zarządzaj nieaktualnymi danymi

Nieaktualne tabele cenowe, dokumenty polityki czy notatki o wydaniach oprogramowania szybko niszczą wiarygodność. Trzy praktyczne kroki pozwolą utrzymać świeżość indeksu:

  • Oznacz każdy dokument znacznikiem wersji lub datą.
  • Zastosuj wzmocnienie na podstawie aktualności (recency boost) podczas punktacji, aby nowsze elementy wyprzedzały starsze kopie.
  • Przeprowadzaj nocne, przyrostowe reindeksowanie, aby pobierać zmiany z systemów źródłowych.

Te zabezpieczenia zapobiegają serwowaniu przez system ceny, która obowiązywała w zeszłym kwartale, lub polityki, która została już zastąpiona nową.

4. Stosuj reranking zamiast ulepszania modeli

Aktualizacja modelu embeddingów daje jedynie niewielki wzrost jakości, podczas gdy dodanie rerankera typu cross-encoder zapewnia znacznie większy skok przy niższym koszcie.

Przepływ produkcyjny pobiera 20 tanich kandydatów za pomocą wyszukiwania hybrydowego, a następnie przepuszcza ich przez reranker, aby wybrać pięć najlepszych. To dwuetapowe podejście daje większy skok jakościowy za ułamek kosztów pełnej aktualizacji modelu.

5. Zbuduj rzeczywisty zestaw ewaluacyjny

Nie można ulepszyć tego, czego się nie mierzy. Autor przygotował zestaw testowy składający się z 200 autentycznych zapytań użytkowników, z których każde zostało sparowane z odpowiedzią przygotowaną przez eksperta. Każda zmiana w kodzie jest sprawdzana pod kątem tego zestawu; wszelkie regresje są wykrywane przed wdrożeniem.

Gdy użytkownik zgłosi błędną odpowiedź, natychmiast dodaj to zapytanie do zestawu ewaluacyjnego, zamieniając błędy z rzeczywistego świata w przyszłe zabezpieczenia. Ciągłe logowanie każdej wygenerowanej odpowiedzi zasila pętlę ewaluacji, utrzymując system w zgodzie z faktycznym sposobem użytkowania.

Potok produkcyjny w praktyce

  • Ingest: Dzielenie uwzględniające strukturę zachowuje nagłówki, bloki kodu i zwroty w konwersacji.
  • Index: Przechowuje zarówno gęste embeddingi, jak i statystyki terminów BM25.
  • Retrieve: Wyszukiwanie hybrydowe zwraca 20 kandydatów, balansując podobieństwo semantyczne i dopasowanie dokładnych terminów.
  • Rerank: Cross-encoder zawęża listę do pięciu najbardziej obiecujących fragmentów.
  • Generate: LLM otrzymuje te najlepsze fragmenty wraz z ich metadanymi, aby przygotować ostateczną odpowiedź.
  • Evaluate: Każda odpowiedź jest logowana; błędy trafiają z powrotem do zestawu testowego 200 zapytań.

Stawka i kompromisy

Dobrze dostrojony pipeline redukuje halucynacje, poprawia trafność odpowiedzi i obniża koszty korzystania z modeli o zbyt dużych zasobach. Korzyścią jest wyższa satysfakcja użytkowników oraz mniejsze obciążenie działu wsparcia. Ignorowanie tych kroków prowadzi do powstania niestabilnej usługi, która podważa zaufanie do marki i wymusza kosztowne „gaszenie pożarów”.

Na co warto zwrócić uwagę w przyszłości

W miarę jak embeddingi open-source i bazy danych wektorowych dojrzewają, granica między wyszukiwaniem „gęstym” (dense) a „rzadkim” (sparse) będzie się zacierać, ale zasada łączenia dopasowania semantycznego z dokładnym pozostaje niezmienna.

Wniosek: W systemie RAG model językowy rzadko stanowi wąskie gardło. Prawdziwa praca polega na tym, jak dzielisz, indeksujesz i prezentujesz źródłowe treści. Podejmowanie właściwych decyzji w tych obszarach zmienia efektowne demo w niezawodny produkt.