Długi kontekst czy RAG? Pomiary Qwena i polskiego RAG
Długi kontekst przesyła cały materiał do modelu. RAG najpierw wybiera potrzebne fragmenty. Porównujemy pomiary Qwena i polskie badanie na 146 pytaniach.
Syntalith
W długim kontekście aplikacja wysyła modelowi cały materiał wraz z pytaniem. W RAG, czyli generowaniu wspomaganym wyszukiwaniem, moduł wyszukujący najpierw wybiera pasujące fragmenty, a generator tworzy odpowiedź na podstawie tego wyboru. Długi kontekst upraszcza przepływ. RAG ogranicza ilość tekstu przekazywanego przy każdym pytaniu i rozdziela wyszukiwanie od generowania.
Qwen3.8-27B odtworzył trzy sprawdzane fakty z wejścia zawierającego 230 085 tokenów. Ten pojedynczy przebieg trwał 563,4 s od uruchomienia do końca odpowiedzi. Przy 50 059 tokenach taki sam test zakończył się po 59,3 s. Wynik pokazuje, że model przyjął bardzo duży pakiet, a ponowne przesyłanie całego pakietu ma wyraźny koszt czasowy.
RAG wymaga odpowiedzi na dwa osobne pytania. Najpierw sprawdzamy, czy wyszukiwanie zwróciło właściwe źródła. Później sprawdzamy, czy generator użył ich poprawnie. Sama długość kontekstu nie odpowiada na żadne z tych pytań w pełnym systemie produkcyjnym.
Nasz pomiar długiego kontekstu
Na domowym komputerze z kartą RTX 3090 uruchomiliśmy trzy konfiguracje llama.cpp. Różniły się wagami modelu, pamięcią kontekstu i wielkością paczki, ponieważ każda musiała zmieścić się w 24 GB VRAM. Dobieraliśmy ustawienia pod kątem praktycznego uruchomienia. Nie izolowaliśmy jednego parametru.
W syntetycznym materiale umieściliśmy po jednym sprawdzalnym fakcie na początku, w środku i na końcu. Każdą długość uruchomiliśmy raz. Przebieg uznawaliśmy za zaliczony, gdy zwracał wszystkie trzy fakty, czyli 3/3:
| Profil | Tokeny wejścia | Przetworzenie wejścia | Generowanie | Czas | Szczyt VRAM | Odtworzone fakty |
|---|---|---|---|---|---|---|
| 60k | 50 059 | 890,7 tok./s | 49,24 tok./s | 59,3 s | 22 287 MiB | 3/3 |
| 120k | 115 074 | 681,6 tok./s | 40,46 tok./s | 172,6 s | 22 649 MiB | 3/3 |
| 250k | 230 085 | 412,4 tok./s | 28,05 tok./s | 563,4 s | 23 623 MiB | 3/3 |
Przetwarzanie wejścia to tempo, w jakim serwer przetwarza tokeny wejściowe przed rozpoczęciem odpowiedzi. Generowanie to tempo tworzenia tokenów odpowiedzi. Czas oznacza łączny czas od uruchomienia do końca przebiegu, a VRAM pokazuje najwyższe zmierzone użycie pamięci karty. Wniosek jest wąski: model odtworzył trzy umieszczone przez nas fakty w tych trzech wejściach. Próba nie mierzyła jakości cytatów, aktualności dokumentów, obsługi sprzecznych wersji, odmowy przy braku źródła ani kontroli uprawnień. Nie daje więc podstaw do oceny całego firmowego systemu wiedzy.
Co zmierzono w rzeczywistym polskim RAG
W pracy Evaluation of Two Leading Polish Language Models in a Real-world RAG Scenario wykorzystano rzeczywistą dokumentację techniczną platformy low-code. Korpus obejmował około 1200 fragmentów, a zestaw oceny 146 pytań referencyjnych wybranych jako prawdopodobne pytania użytkowników. Pracownicy pomagali przygotować odpowiedzi wzorcowe.
Badacze porównali cztery modele do wyszukiwania semantycznego oraz wyszukiwanie wektorowe, pełnotekstowe i hybrydowe. Najlepszy wariant OrlikB/KartonBERT-USE-base-v1 w wyszukiwaniu wektorowym uzyskał:
| Liczba zwracanych fragmentów | Trafność | Pełność | F1 | NDCG |
|---|---|---|---|---|
| 5 | 0,891 | 0,744 | 0,485 | 0,682 |
| 7 | 0,899 | 0,796 | 0,424 | 0,701 |
W tej tabeli trafność oznacza udział zwróconych fragmentów zgodnych z zestawem wzorcowym według definicji autorów, a pełność pokazuje, jaką część istotnych fragmentów udało się znaleźć. F1 jest średnią harmoniczną tych dwóch miar i obniża się, gdy mocno się różnią. NDCG uwzględnia pozycję wyniku: nagradza trafne fragmenty wysoko na liście silniej niż trafne fragmenty znalezione dalej. Wszystkie wartości pochodzą z definicji i adnotacji autorów publikacji.
Zwiększenie liczby fragmentów z pięciu do siedmiu podniosło pełność oraz NDCG, a obniżyło F1. Więcej wyników w pakiecie dla generatora nie poprawiło każdej miary jednocześnie.
W części generacyjnej model otrzymywał pięć dokumentów. Autorzy użyli trzech modeli jako osobnych, automatycznych oceniających: gpt-oss-20b, Mistral-Small-3.2-24B-Instruct-2506 oraz Qwen3-30B-A3B-Instruct-2507. Podali średnią ocenę odpowiedzi w skali od 1 do 5: 4,521 dla Bielik-11B-v2.3-Instruct oraz 4,025 dla PLLuM-12B-nc-chat. Ocena 5 oznaczała odpowiedź w pełni poprawną i wyczerpującą, a 1 odpowiedź błędną albo nie na temat. Wyższa wartość oznacza lepszą ocenę według kryteriów tego badania. To wynik konkretnych wersji modeli, tego korpusu i tej procedury oceny. Qwen3.8-27B nie brał udziału w tym porównaniu.
Czego nie rozstrzygają oba pomiary
Nasza tabela nie rozstrzyga, czy długi kontekst jest lepszy od RAG. Tabela z publikacji nie rozstrzyga, czy RAG będzie szybszy albo lepszy w dowolnej firmie. Oba pomiary użyły innych korpusów, pytań, urządzeń i generatorów. Odpowiadają na dwa praktyczne pytania:
- pomiar Qwena rejestruje wynik umieszczenia około 50 tys., 115 tys. i 230 tys. tokenów w jednym wejściu;
- badanie RAG mierzy wyszukiwanie i generowanie na rzeczywistej polskiej dokumentacji;
- decyzja wdrożeniowa nadal wymaga zestawu pytań i dokumentów konkretnej firmy.
Kiedy długi kontekst ma sens
Długi kontekst warto rozważyć, gdy pytanie dotyczy kompletnego, jednorazowego pakietu, a relacje między odległymi częściami materiału są częścią zadania. Może też uprościć pierwszy prototyp, ponieważ nie wymaga dzielenia dokumentów na fragmenty ani budowy indeksu.
Nadal trzeba sprawdzić, czy model cytuje właściwy fragment, rozpoznaje sprzeczne wersje i odmawia, gdy źródła nie zawierają odpowiedzi. Zaliczony test trzech faktów nie daje takich gwarancji.
Kiedy RAG ma sens
RAG warto rozważyć, gdy ten sam duży korpus obsługuje wiele pytań, dokumenty często się zmieniają albo dostęp zależy od roli użytkownika. Warstwa wyszukiwania może odfiltrować niedozwolone źródła przed generowaniem i pokazać, które fragmenty wpłynęły na odpowiedź.
O jakości RAG decyduje cały łańcuch. Badanie LREC pokazało mierzalne różnice między k=5 i k=7, gdzie k oznacza liczbę fragmentów przekazanych dalej. W firmie trzeba osobno ocenić odczytywanie plików, podział dokumentów, model do wyszukiwania semantycznego, filtry, ponowne porządkowanie wyników i generator.
Jak wygląda uczciwa próba na danych firmy
Zaczynamy od pytań, które pracownicy rzeczywiście zadają, oraz źródeł potrzebnych do udzielenia poprawnej odpowiedzi. Dla każdego przypadku zapisujemy obowiązującą wersję dokumentu, dozwolony zakres dostępu, właściwe fragmenty i sytuację, w której system ma odmówić.
Następnie uruchamiamy co najmniej dwie architektury na tych samych pytaniach: cały pakiet oraz RAG. Zachowujemy ranking źródeł, odpowiedź, cytaty, czas, wersję modelu i decyzję osoby sprawdzającej. Dopiero taki zapis pozwala ocenić, czy indeks daje przewagę nad prostszym pakietem.
Co może wdrożyć Syntalith
Syntalith przygotowuje zestaw pytań i źródeł, uruchamia lokalne wersje modeli oraz wariant API i przekazuje porównanie wyników. Po wyborze architektury wdrażamy potrzebne moduły: odczyt plików, indeks, filtrowanie po uprawnieniach, cytaty, panel oceny, monitoring regresji i szkolenie zespołu. Qwen jest jednym z kandydatów na generator. O wyborze decyduje test na procesie klienta.
Audyt procesu AI zaczyna się od 4990 zł netto. Jeżeli wynik uzasadnia własny system wiedzy, Aplikacje AI obejmują wykonanie i przekazanie rozwiązania. Bezpłatny skan procesu pomaga ustalić, czy firma potrzebuje RAG, długiego kontekstu, zwykłego wyszukiwania czy po prostu lepiej uporządkowanych dokumentów.
Bezpłatny skan procesów
Zacznij od bezpłatnego skanu procesów.
- 30 minut z inżynierem, który może prowadzić Twoje wdrożenie.
- Przegląd procesów, które kosztują Cię najwięcej czasu i pieniędzy.
- Pisemne podsumowanie: co zautomatyzować, w jakiej kolejności, z widełkami kosztów.
W 30 minut wybieramy proces do oceny, a w ciągu 2 dni roboczych dostajesz rekomendację, także gdy lepsza będzie prostsza droga.
0 zł
30 minut · pisemne podsumowanie w 2 dni robocze
Terminy zobaczysz w swojej strefie czasowej.
Wolisz napisać? Opisz proces