AI seria pytań rekrutacyjnych 11: Jak optymalizować RAG?

Optymalizacja RAG nie polega na dostosowaniu pojedynczego elementu, ale na procesie optymalizacji pełnego łańcucha. Poniżej przedstawiam systematyczne strategie optymalizacji z czterech wymiarów: strona indeksowania danych, strona wyszukiwania, strona generowania i strona oceny, wraz z praktycznymi doświadczeniami, które można przytoczyć podczas rozmowy rekrutacyjnej.

1. Optymalizacja strony indeksowania danych (poprawa jakości „bazy wiedzy”)

To jest najczęściej pomijany, ale najbardziej skuteczny obszar.

Punkt optymalizacji	Objaw problemu	Konkretne działanie	Wskaźnik efektu
Parsowanie dokumentów	Tabele, diagramy w PDF są pomijane, tekst jest zniekształcony lub w złej kolejności.	Użyj lepszych bibliotek parsujących (np. `unstructured`, tryb zachowania układu `pypdf`); dla tabel użyj `pandas` do ekstrakcji i konwersji na Markdown.	Współczynnik odzysku (Recall) +5~15%
Rozmiar fragmentów tekstu	Zbyt mały chunk traci kontekst (np. „jego przychody w tym roku wzrosły” – zaimek „jego” traci odniesienie); zbyt duży chunk powoduje szum w wyszukiwaniu.	Eksperymentuj z różnymi rozmiarami chunków (256/512/768 tokenów), nakładanie overlap 10~20%; dla długich dokumentów dziel według granic semantycznych (akapity/nagłówki), a nie stałej długości.	Współczynnik trafień / Wierność
Dodawanie metadanych	Znaleziono odpowiedni fragment, ale nie można określić źródła ani czasu, lub potrzebne jest filtrowanie według dziedziny.	Dodaj do każdego chunka metadane: `source` (nazwa pliku/URL), `timestamp`, `page_num`, `doc_type`. Podczas wyszukiwania używaj filtrów (np. `doc_type == 'legal'`).	Dokładność filtrowania
Wybór modelu osadzania (embedding)	Ogólne embeddingi słabo działają w specjalistycznych dziedzinach (medycyna, kod, prawo).	Użyj modeli dostrojonych do dziedziny (BGE-large-zh, GTE-Qwen2-7B-instruct); lub dostrój własny model embeddingu (z triplet loss).	MRR@10 wyszukiwania +10~20%

2. Optymalizacja strony wyszukiwania (bardziej precyzyjne „przeglądanie”)

Wyszukiwanie decyduje o jakości „materiałów referencyjnych” podawanych LLM.

Punkt optymalizacji	Objaw problemu	Konkretne działanie	Efekt
Wyszukiwanie hybrydowe	Wyszukiwanie wektorowe nie radzi sobie z precyzyjnymi terminami (np. model produktu `ABC-123`), wyszukiwanie słów kluczowych nie rozumie synonimów.	Użyj jednocześnie wyszukiwania wektorowego (semantycznego) i BM25 (słów kluczowych), połącz przez ważenie (np. 0.7wektor + 0.3BM25) lub rerank.	Współczynnik odzysku +10~25%
Ponowne szeregowanie (Rerank)	Pierwsze wyniki wyszukiwania wektorowego nie zawsze są najbardziej trafne; dopiero 10. jest najlepsze.	Użyj modelu cross-encoder (np. `BGE-reranker-v2`, Cohere Rerank) do ponownej oceny zbioru kandydatów (np. pierwszych 20) i wybrania top-K.	Znaczny wzrost współczynnika trafień (szczególnie top-1)
Przepisywanie zapytania	Pytanie użytkownika jest niejasne lub ma niejednoznaczne odniesienia w konwersacji („A jaka jest jego cena?”).	Użyj LLM do przekształcenia oryginalnego pytania w formę bardziej odpowiednią do wyszukiwania (np. „Jaka jest cena iPhone 15?”); lub uzupełnij kontekstem z historii rozmowy.	Współczynnik odzysku +5~15%
HyDE	Pytanie użytkownika jest zbyt krótkie lub abstrakcyjne (np. „Opowiedz o fotosyntezie”), bezpośrednie wyszukiwanie jest nieskuteczne.	Najpierw pozwól LLM wygenerować hipotetyczną odpowiedź, a następnie użyj tej odpowiedzi do wyszukania dokumentów.	Odpowiednie dla domen otwartych, ale nie dla precyzyjnych pytań faktograficznych
Dostosowanie liczby Top-K	Zbyt małe K może pominąć kluczowe informacje; zbyt duże K zwiększa zużycie tokenów i szum.	Eksperymentuj z K=3/5/10, obserwując równowagę między współczynnikiem odzysku a wiernością odpowiedzi.	Kompromis między wydajnością a efektem

3. Optymalizacja strony generowania (sprawienie, by LLM dobrze wykorzystywał materiały referencyjne)

Nawet przy dobrym wyszukiwaniu, jeśli prompt jest zły lub model słaby, efekt będzie marny.

Punkt optymalizacji	Objaw problemu	Konkretne działanie	Efekt
Inżynieria promptów	LLM ignoruje znalezione treści lub zmyśla.	Wyraźne polecenie: „Odpowiadaj wyłącznie na podstawie poniższych materiałów referencyjnych. Jeśli materiały są niewystarczające lub nieistotne, odpowiedz „Brak wystarczających informacji”. Dodaj przykłady few-shot pokazujące, jak cytować źródła.	Wierność +20~40%
Kompresja kontekstu	Znalezione treści są zbyt długie (przekraczają okno kontekstowe modelu) lub w większości stanowią szum.	Użyj `LLMLingua` lub `selektywnej kompresji kontekstu`, aby zachować najbardziej istotne zdania, a następnie przekaż je do LLM.	Zmniejsza ryzyko utraty informacji
Aktualizacja modelu LLM	Mały model (7B) nie radzi sobie ze złożonym wnioskowaniem lub zapamiętaniem długiego kontekstu.	Zastosuj mocniejszy model (GPT-4o, Claude 3.5 Sonnet, Qwen2.5-72B).	Znaczny wzrost dokładności wnioskowania
Streaming i cytowanie	Użytkownik nie może zweryfikować wiarygodności odpowiedzi.	Spraw, by LLM podczas generowania wypisywał `[citation:1]`, odpowiadający numerowi dokumentu w wynikach wyszukiwania. Dołącz na końcu link do oryginalnego źródła.	Zaufanie użytkownika + możliwość debugowania
Kalibracja odmowy odpowiedzi	Model zmyśla, gdy nie powinien odpowiadać, lub mówi „nie wiem”, gdy powinien.	Ustaw próg podobieństwa: jeśli cosinusowe podobieństwo top-1 chunka do pytania jest poniżej 0,7, poinstruuj LLM „Materiał nie jest odpowiedni”.	Zmniejszenie wskaźnika halucynacji

4. Strona oceny i iteracji (wiedza, gdzie kierować optymalizację)

Bez pomiaru nie ma optymalizacji.

Punkt optymalizacji	Działanie	Wskaźnik
Tworzenie zbioru ewaluacyjnego	Przygotuj 100–300 rzeczywistych pytań użytkowników + wzorcowych odpowiedzi + poprawnych identyfikatorów dokumentów do wyszukania.	Pokrywaj różne poziomy trudności i intencje.
Automatyczna ocena	Użyj RAGAS (Faithfulness, Answer Relevance, Context Recall) lub TruLens.	Trzy główne wskaźniki: wierność, trafność odpowiedzi, odzysk kontekstu.
Ocena ręczna	Co tydzień losowo testuj 20 przypadków problematycznych (bad case), analizując typ błędu (nieudane wyszukiwanie / błąd generowania / brak w bazie wiedzy).	Ustalanie priorytetów usprawnień.
Testy A/B	W środowisku produkcyjnym testuj na różnych grupach użytkowników różne strategie wyszukiwania (np. BM25 vs wyszukiwanie hybrydowe).	Wskaźniki online: zadowolenie użytkowników, odsetek braku odpowiedzi.

5. „Praktyczne doświadczenia” do przytoczenia podczas rozmowy (punkty dodatnie)

„W projekcie RAG, nad którym pracowałem, początkowy współczynnik trafień wynosił 67%. Zrobiłem trzy rzeczy:
1. Zmieniłem podział ze stałego 1024 na dynamiczny podział semantyczny (według nagłówków i akapitów), co podniosło trafność do 74%;
2. Wprowadziłem wyszukiwanie hybrydowe (wektorowe + BM25) oraz mały model rerank, co podniosło trafność do 83%;
3. Zoptymalizowałem prompt i wymusiłem odpowiedź [Nie znaleziono odpowiednich informacji], dzięki czemu wskaźnik halucynacji spadł z 22% do poniżej 5%.

Dodatkowo, zbudowaliśmy ciągły potok ewaluacyjny – przed każdą zmianą uruchamialiśmy punktację RAGAS na 200 pytaniach, aby upewnić się, że nie ma regresji.”

Podsumowanie: Pełna mapa drogowa optymalizacji RAG

Warstwa danych ─→ Czyszczenie dokumentów, optymalizacja podziału, wzbogacanie metadanych, domenowe osadzanie (embedding)
Warstwa wyszukiwania ─→ Wyszukiwanie hybrydowe, rerank, przepisywanie zapytania, HyDE, dostosowanie Top-K
Warstwa generowania ─→ Wzmocnienie promptu, wymagania co do instrukcji, kompresja, cytowanie, próg odmowy
Warstwa oceny ─→ Zbiór ewaluacyjny, RAGAS, analiza ręczna, testy A/B