Wydałem 500 USD na infrastrukturę RAG, zanim naprawiłem te 7 błędów

Zbudowałem potok (pipeline) RAG do przeszukiwania prywatnych dokumentów. Kosztowało mnie to 500 USD na moc obliczeniową i tygodnie debugowania. Wyniki były słabe. Użytkownicy otrzymywali błędne odpowiedzi, a zapytania były wolne.

Przeprowadziłem audyt potoku. Znalazłem 7 błędów. Ich naprawienie zmieniło wszystko.

  1. Sztywne dzielenie na fragmenty (Token Chunking) Dzieliłem dokumenty co 512 tokenów. To niszczyło kontekst. Wyjaśnienie API mogło zostać przerwane w połowie zdania. LLM otrzymywał fragmenty i generował bezużyteczne odpowiedzi. Rozwiązanie: Stosuj semantyczne dzielenie (semantic chunking).
  • Dziel na naturalne granice, takie jak akapity lub nagłówki.
  • Stosuj metodę parent-document retrieval.
  • Twórz małe fragmenty typu „child” do wyszukiwania.
  • Przekazuj pełny dokument nadrzędny (parent document) do LLM.
  • Dodaj 10-20% nakładki (overlap) między fragmentami.
  1. Złe wagi wyszukiwania hybrydowego (Hybrid Search) Używałem podziału 50/50 dla wyszukiwania wektorowego i słów kluczowych. To nie sprawdzało się w dokumentacji technicznej. Użytkownicy techniczni potrzebują dokładnych dopasowań słów kluczowych. Rozwiązanie: Stosuj dynamiczne wagi.
  • Zapytania faktograficzne: 35% wektory, 65% słowa kluczowe.
  • Zapytania semantyczne: 75% wektory, 25% słowa kluczowe.
  • Zapytania ogólne: 60% wektory, 40% słowa kluczowe.
  1. Nadmierne dostrajanie parametrów HNSW Ustawiłem ef_construction na maksimum. To spowodowało awarię serwera. Zużyło cały dostępny RAM. Rozwiązanie: Używaj odpowiednich parametrów.
  • Ustaw M w zakresie od 8 do 32.
  • Ustaw ef_construction na 200.
  • Ustaw ef_search na 50. Zużycie pamięci spadło o 70%.

  1. Ogólne modele embeddingowe Używałem modelu trenowanego na Wikipedii. Moje dokumenty były technicznymi instrukcjami inżynieryjnymi (runbooks). Model nie rozumiał mojej dziedziny. Rozwiązanie: Użyj modelu dotrenowanego (fine-tuned) pod kątem treści technicznych lub kodu.

  2. Brak przekształcania zapytań (Query Rewriting) Użytkownicy zadają pytania w języku naturalnym. Dokumentacja techniczna używa formalnych terminów. Nie pasują one do siebie. Rozwiązanie: Dodaj lekki krok z użyciem LLM, aby przekształcać zapytania.

  • Użytkownik pyta: „dlaczego mój build jest wolny”
  • System przekształca na: „optymalizacja wydajności potoku CI”
  • To poprawiło wskaźnik recall o 40%.

  1. Powtarzające się wyniki Pobieranie 10 najlepszych fragmentów (chunks) często zwracało ten sam akapit trzy razy. LLM powtarzał się. Rozwiązanie: Użyj Maximal Marginal Relevance (MMR), aby zapewnić różnorodność wyników.

  2. Testowanie niewłaściwych rzeczy Testowałem cały potok naraz. Nie wiedziałem, czy problem leży w wyszukiwaniu (retrieval), czy w LLM. Rozwiązanie: Rozdziel ewaluację wyszukiwania.

  • Monitoruj hit rate.
  • Monitoruj Mean Reciprocal Rank (MRR).
  • Stwórz zestaw testowy składający się ze 100 par zapytanie-dokument.

Wyniki po poprawkach:

  • Trafność odpowiedzi: 45% do 85%
  • Opóźnienie: 3,2 s do 1,8 s
  • Miesięczny koszt: $180 do $95

Najpierw popraw chunking. Potem wagi. Na końcu jakość embeddingów.

Źródło: https://dev.to/kollittle/i-spent-500-on-rag-infrastructure-before-realizing-these-7-mistakes-were-killing-my-results-iph