Koszt i opóźnienia w pipelinie RAG: gdzie naprawdę ucieka czas

Każde demo RAG działa błyskawicznie, dopóki nie pojawią się prawdziwe dokumenty i prawdziwi użytkownicy. Potem ktoś pyta, dlaczego odpowiedź zajęła dziewięć sekund, a szczera odpowiedź zwykle brzmi: nikt nie zmierzył poszczególnych etapów. Budujemy takich asystentów zawodowo i widzimy to samo w kółko: zespoły optymalizują etap, który widzą, zamiast tego, który realnie kosztuje. Wiedza o tym, gdzie w pipelinie znika czas i pieniądze, decyduje o tym, czy masz system, który da się stroić, czy taki, za który możesz tylko przepraszać.

Etapy, przez które przechodzi pytanie

Jedno zapytanie to nie jedna operacja. Trzeba je zamienić na embedding, przeszukać indeks wektorowy, może przepuścić kandydatów przez reranking, złożyć prompt, wygenerować odpowiedź, a na końcu powiązać cytowania z dokumentami źródłowymi. Generowanie zjada większość czasu w niemal każdym wdrożeniu, jakie widzieliśmy, bo to jedyny etap produkujący tokeny po kolei. Wyszukiwanie często sprawia wrażenie wolnego, choć prawdziwym winowajcą jest skok sieciowy albo zimny indeks. Zmierz każdy etap osobno, zanim czegokolwiek dotkniesz. Pojedyncza liczba od początku do końca ukrywa wąskie gardło, zamiast ci je pokazać.

Wyszukiwanie jest tanie, dopóki go nie ulepszysz

Zwykłe wyszukiwanie wektorowe po rozgrzanym indeksie jest naprawdę szybkie. Koszt pojawia się wraz z dodatkami. Reranker typu cross-encoder uruchamia drugi model na każdym kandydackim fragmencie. Przepisywanie zapytania zamienia jedno żądanie w dwa wywołania modelu, zanim wyszukiwanie w ogóle się zacznie.

• Wyszukiwanie hybrydowe: lepsza skuteczność przy nazwach, kodach i rzadkich terminach; kosztuje drugie odpytanie indeksu i krok scalania.
• Reranker: trafniejsza kolejność kandydatów; kosztuje pełne przejście modelu na każdy fragment.
• Przepisywanie zapytania: radzi sobie z pytaniami nieprecyzyjnymi i potocznymi; kosztuje jedną turę zanim ruszy wyszukiwanie.
• Wyszukiwanie wieloetapowe: odpowiada na pytania rozłożone na wiele dokumentów; mnoży każdy etap poniżej siebie.

Wskazówka: zmierz jakość odpowiedzi z rerankerem i bez niego na własnym zbiorze dokumentów. Przy wąskich zbiorach często nie zmienia to zupełnie nic.

Rozmiar kontekstu to dźwignia kosztów, której nikt nie pilnuje

Każdy pobrany fragment jest liczony jako wejście i odsuwa w czasie moment pojawienia się pierwszego tokena. Podanie dwudziestu fragmentów zamiast pięciu rzadko poprawia osadzenie odpowiedzi w źródłach. Za to niezawodnie podnosi rachunek. Rozmiar fragmentu i wielkość zakładki po cichu decydują, za ile nadmiarowego tekstu płacisz przy każdym pojedynczym pytaniu, na zawsze. A pobrane dowody nie są tam same: prompt systemowy, schematy narzędzi i historia rozmowy walczą o ten sam budżet. Cache'owanie promptu pomaga, owszem, ale tylko tam, gdzie stała część promptu jest naprawdę stała między kolejnymi zapytaniami.

Streaming, odczuwalna szybkość i to, co czuje użytkownik

Czas do pierwszego tokena znaczy dla ludzi więcej niż całkowity czas odpowiedzi. Wyszukiwanie dzieje się w całości, zanim pojawi się pierwszy token, więc każda milisekunda spędzona na tym etapie ląduje wprost na osobie, która czeka. Streaming zamienia długie czekanie w czytanie. Nie naprawia wolnego wyszukiwania. Cytowania rozwiązywane po generowaniu można dołączać stopniowo, zamiast blokować nimi odpowiedź.

Wskazówka: pokaż w interfejsie postęp wyszukiwania. Nazwanie przeszukiwanych dokumentów kupuje cierpliwość, której sam kręcący się wskaźnik nigdy nie kupi.

Modele w chmurze kontra własna infrastruktura

Modele hostowane oznaczają rozliczenie za token, brak planowania mocy i opóźnienia zależne od cudzej kolejki. Własny hosting oznacza stały koszt sprzętu, przewidywalne opóźnienia przy znanym obciążeniu i wzięcie problemu na siebie, gdy ruch skoczy. Miejsce przechowywania danych i wrażliwość dokumentów zwykle rozstrzygają spór, zanim koszt zdąży dojść do głosu.

1. Gdzie te dokumenty mogą legalnie leżeć?
2. Ile zapytań dziennie, realnie?
3. Jak zmienne opóźnienia zniesie to zastosowanie?
4. Kto będzie utrzymywał stos po starcie?
5. Ile zapasu potrzeba w szczycie?

Rozwiązania mieszane są całkowicie sensowne: embeddingi i indeks na własnych maszynach, generowanie hostowane. Albo odwrotnie.

Koszt indeksowania: rachunek, który przychodzi raz, a potem znowu

Zbudowanie embeddingów dla zbioru dokumentów to wydatek jednorazowy dokładnie do momentu, w którym zmienisz model embeddingów, strategię chunkingu albo same dokumenty. Ponowne przeliczenie embeddingów dużego zbioru to migracja, nie zmiana ustawienia, więc zaplanuj to jak migrację. Przyrostowe indeksowanie przy aktualizacjach utrzymuje koszt bieżący proporcjonalnie do zmian, a nie do wielkości zbioru. Pamięć i przestrzeń dyskowa dla indeksu rosną wraz z liczbą fragmentów i wymiarem wektora, a jedno i drugie masz pod kontrolą. Trzymaj tekst źródłowy obok wektorów, żeby ponowny chunking nigdy nie oznaczał ponownego pobierania treści. Nauczyliśmy się tego boleśnie.

Jak w praktyce profilujemy pipeline

Logujemy czasy i liczby tokenów per etap dla każdego zapytania od pierwszego dnia, a nie po pierwszej skardze. Porównuj medianę z opóźnieniami w ogonie rozkładu, bo to ogon użytkownicy faktycznie zgłaszają. Śledź koszt na odpowiedź, nie koszt na token. Ta druga liczba ci schlebia, pierwsza mówi prawdę. Trzymaj stały zestaw prawdziwych pytań jako pakiet testów regresji i uruchamiaj go przy każdej zmianie modeli, chunkingu albo ustawień wyszukiwania. Potem wywal każdy etap, który nie uzasadnia swojego opóźnienia, i zmierz jeszcze raz.

FAQ

Czy większe okno kontekstu likwiduje potrzebę wyszukiwania?

Nie. Podnosi koszt wejścia i rozprasza uwagę modelu po nieistotnym tekście. Wyszukiwanie utrzymuje prompt krótki, a cytowanie precyzyjne, i o to w tej architekturze chodzi.

Czy mniejszy model generujący wystarczy do RAG?

Często tak, bo dowody siedzą w promptcie, a nie w wagach modelu. Sprawdź to na własnych pytaniach, zanim uznasz, że potrzebujesz największej opcji z menu.

Jaka pojedyncza zmiana najszybciej zmniejsza opóźnienia?

Zmniejsz liczbę pobieranych fragmentów, a potem sprawdź, czy jakość odpowiedzi w ogóle się zmieniła. Zwykle się nie zmienia.

Co to znaczy, gdy budujesz albo kupujesz

Opóźnienia i koszt to decyzje projektowe podejmowane fragment po fragmencie, a nie strojenie doklejane na końcu. Poproś dostawcę o czasy per etap i koszt na odpowiedź zamiast o czas odpowiedzi z demo. Trzymaj pipeline na tyle prosty, żeby dało się wyjaśnić bez zgadywania, skąd wzięła się wolna odpowiedź. Właściwa architektura to najtańsza taka, która nadal odpowiada poprawnie i z podanym źródłem.