Długi kontekst czy RAG? Pomiary Qwena i polskiego RAG

W długim kontekście aplikacja wysyła modelowi cały materiał razem z pytaniem. W RAG, czyli generowaniu wspomaganym wyszukiwaniem, osobny moduł najpierw wybiera kilka pasujących fragmentów. Dopiero te fragmenty trafiają do modelu. Pierwsze podejście jest prostsze, a drugie zwykle lepiej skaluje się przy wielu dokumentach i pytaniach.

Qwen3.8-27B odtworzył wszystkie sprawdzane fakty z wejścia długości 230 085 tokenów. Przebieg trwał jednak 563,4 s. Dla 50 059 tokenów ten sam rodzaj próby zakończył się w 59,3 s. Model może więc przeczytać bardzo duży pakiet, ale ponowne przesyłanie całości przy każdym pytaniu jest kosztowne.

RAG odpowiada na inne pytanie. Zamiast wkładać wszystko do jednego wejścia, najpierw wyszukuje pasujące fragmenty, a dopiero potem przekazuje je generatorowi. Jego jakość zależy więc od dwóch mierzonych etapów: czy znalazł właściwe źródło oraz czy odpowiedź poprawnie użyła tego źródła.

Nasz pomiar długiego kontekstu

Na domowym RTX 3090 uruchomiliśmy trzy profile llama.cpp. Różniły się wagami, pamięcią kontekstu i wielkością paczki, ponieważ każdy miał zmieścić się w 24 GB VRAM. To praktyczne profile wdrożeniowe. Nie był to izolowany eksperyment jednego parametru.

W materiale umieściliśmy sprawdzalne fakty na początku, w środku i na końcu. Każdy profil musiał je zwrócić:

Wniosek jest wąski: model potrafił odtworzyć posadzone fakty w tych trzech wejściach. Próba nie mierzyła jakości cytatów, aktualności dokumentów, konfliktu wersji, odmowy przy braku źródła ani kontroli uprawnień. Nie nazywamy jej benchmarkiem firmowego mózgu.

Co zmierzono w rzeczywistym polskim RAG

Praca Evaluation of Two Leading Polish Language Models in a Real-world RAG Scenario opisuje system zbudowany na rzeczywistej dokumentacji technicznej platformy low-code. Korpus miał około 1200 fragmentów, a zestaw oceny 146 pytań referencyjnych wybranych jako prawdopodobne pytania użytkowników. Pracownicy uczestniczyli w przygotowaniu odpowiedzi wzorcowych.

Badacze porównali cztery modele embeddingowe oraz wyszukiwanie wektorowe, pełnotekstowe i hybrydowe. Najlepszy wariant OrlikB/KartonBERT-USE-base-v1 w wyszukiwaniu wektorowym uzyskał:

To metryki z publikacji, liczone według jej definicji trafnych dokumentów. Zwiększenie liczby fragmentów z pięciu do siedmiu podniosło odsetek znalezionych źródeł i NDCG, ale obniżyło F1. Więcej kontekstu dla generatora nie poprawiło każdej miary naraz.

W części generacyjnej model otrzymywał pięć dokumentów. Średnia ocena w skali 1–5 wyniosła 4,521 dla Bielik-11B-v2.3-Instruct oraz 4,025 dla PLLuM-12B-nc-chat. To wynik tych wersji modeli, tego korpusu i tej procedury. Nie jest wynikiem Qwen3.8-27B.

Czego nie wolno wywnioskować z obu tabel

Nasza tabela nie dowodzi, że długi kontekst pokona RAG. Tabela z publikacji nie dowodzi, że RAG zawsze będzie szybszy albo lepszy. Brakuje wspólnego korpusu, pytań, sprzętu i generatora. Te dwa źródła odpowiadają na różne, ale praktyczne pytania:

• pomiar Qwena pokazuje, co stało się po fizycznym włożeniu 50k, 115k i 230k tokenów do jednego wejścia;
• badanie RAG pokazuje jakość wyszukiwania i odpowiedzi na rzeczywistej polskiej dokumentacji;
• żadne z nich nie zastępuje testu na dokumentach konkretnej firmy.

Kiedy długi kontekst ma sens

Długi kontekst jest sensownym kandydatem, gdy pytanie dotyczy całego, jednorazowego pakietu, a relacje między odległymi częściami dokumentu są częścią zadania. Może też uprościć pierwszy prototyp, bo nie wymaga jeszcze dzielenia dokumentów na fragmenty ani budowy indeksu.

Nadal trzeba sprawdzić, czy model cytuje właściwy fragment, rozpoznaje sprzeczne wersje i odmawia, gdy odpowiedzi nie ma. Zaliczony needle test nie daje tych gwarancji.

Kiedy RAG ma sens

RAG jest naturalnym kandydatem, 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 generacją i pokazać, które fragmenty faktycznie wpłynęły na odpowiedź.

RAG również nie naprawia się samym wyborem modelu. Badanie LREC pokazało mierzalne różnice między k=5 i k=7. W firmie trzeba osobno ocenić odczytywanie plików, podział dokumentów, model wektorowy, 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ł, które powinny rozstrzygnąć odpowiedź. Dla każdego przypadku zapisujemy aktualną wersję dokumentu, dozwolony zakres dostępu, poprawne fragmenty i sytuację, w której system ma odmówić.

Następnie uruchamiamy co najmniej dwa profile architektury na tych samych pytaniach: długi pakiet oraz RAG. Zachowujemy ranking źródeł, odpowiedź, cytaty, czas, wersję modelu i decyzję recenzenta. Dopiero wtedy można powiedzieć, czy indeks daje przewagę nad prostszym pakietem.

Co może wdrożyć Syntalith

Syntalith może przygotować taki test, uruchomić lokalne wersje modeli i wariant API, a następnie wdrożyć zwycięską architekturę. Zakres może obejmować moduły odczytujące pliki, indeks, filtrowanie po uprawnieniach, cytaty, panel oceny, monitoring regresji i szkolenie zespołu. Qwen jest jednym z kandydatów na generator. Zwycięzcę wyłania 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.