Jak przyspieszyliśmy RAG o 50%

RAG zwiększa trafność odpowiedzi agentów AI, opierając odpowiedzi LLM na dużych bazach wiedzy. Zamiast wysyłać całą bazę wiedzy do LLM, RAG tworzy embedding zapytania, pobiera najtrafniejsze informacje i przekazuje je modelowi jako kontekst. W naszym systemie najpierw przepisujemy zapytanie, zamieniając historię dialogu w precyzyjne, samodzielne zapytanie przed wyszukiwaniem.

W przypadku bardzo małych baz wiedzy łatwiej może być przekazać wszystko bezpośrednio w prompcie. Gdy jednak baza wiedzy rośnie, RAG staje się niezbędny, by odpowiedzi były trafne bez przeciążania modelu.

Wiele systemów traktuje RAG jako zewnętrzne narzędzie, ale my wbudowaliśmy go bezpośrednio w potok żądań, więc działa przy każdym zapytaniu. Zapewnia to stałą trafność, ale niesie też ryzyko opóźnień.

Dlaczego przepisywanie zapytań nas spowalniało

Większość próśb użytkowników odnosi się do wcześniejszych wypowiedzi, dlatego system musi zamienić historię dialogu w precyzyjne, samodzielne zapytanie.

Na przykład:

• Jeśli użytkownik pyta: „Czy możemy dostosować te limity do naszych wzorców ruchu w godzinach szczytu?”
• System przepisuje to na: „Czy limity liczby żądań API w planie Enterprise można dostosować do konkretnych wzorców ruchu?”

Przepisywanie zamienia niejasne odniesienia, takie jak „te limity”, w samodzielne zapytania, z których mogą korzystać systemy wyszukiwania. Poprawia to kontekst i trafność końcowej odpowiedzi. Poleganie na jednym zewnętrznie hostowanym LLM uzależniało nas jednak od jego szybkości i dostępności. Ten etap odpowiadał za ponad 80% opóźnienia RAG.

Jak rozwiązaliśmy to dzięki wyścigowi modeli

Przeprojektowaliśmy przepisywanie zapytań tak, by działało jak wyścig:

• Wiele modeli równolegle. Każde zapytanie wysyłamy jednocześnie do kilku modeli, w tym hostowanych przez nas modeli Qwen 3-4B i 3-30B-A3B. Wygrywa pierwsza poprawna odpowiedź.
• Mechanizmy awaryjne, które utrzymują płynność rozmowy. Jeśli żaden model nie odpowie w ciągu sekundy, używamy surowej wiadomości użytkownika. Może być mniej precyzyjna, ale zapobiega przestojom i zapewnia ciągłość rozmowy.

Wpływ na wydajność

Ta nowa architektura skróciła medianę opóźnienia RAG o połowę — z 326 ms do 155 ms. W przeciwieństwie do wielu systemów, które uruchamiają RAG wybiórczo jako zewnętrzne narzędzie, my korzystamy z niego przy każdym zapytaniu. Przy medianie opóźnienia na poziomie 155 ms dodatkowy narzut jest znikomy.

Opóźnienia przed i po:

• Mediana: 326 ms → 155 ms
• p75: 436 ms → 250 ms
• p95: 629 ms → 426 ms

Architektura zwiększyła też odporność systemu na zmienność modeli. Modele hostowane zewnętrznie mogą zwalniać w godzinach największego zapotrzebowania, a nasze modele wewnętrzne działają względnie stabilnie. Wyścig modeli wygładza te różnice, zamieniając nieprzewidywalną wydajność pojedynczych modeli w bardziej stabilne działanie systemu.

Na przykład gdy w zeszłym miesiącu jeden z dostawców LLM miał awarię, rozmowy płynnie trwały dalej na naszych modelach hostowanych we własnej infrastrukturze. Ponieważ używamy jej już w innych usługach, dodatkowy koszt obliczeń jest znikomy.

Dlaczego to ważne

Przepisywanie zapytań RAG w czasie poniżej 200 ms usuwa istotne wąskie gardło dla agentów konwersacyjnych. Dzięki temu system zachowuje kontekst i działa w czasie rzeczywistym, nawet na dużych firmowych bazach wiedzy. Gdy narzut wyszukiwania jest niemal znikomy, agenci konwersacyjni mogą się skalować bez utraty wydajności.