Jak zbudować polskiego asystenta wiedzy z RAG

Pracownik pyta o obowiązującą procedurę. Asystent musi znaleźć właściwy dokument, sprawdzić jego wersję i uprawnienia pracownika, a potem podać odpowiedź ze źródłem. Qwen może wygenerować odpowiedź, ale wyszukiwanie i kontrolę dostępu trzeba zbudować wokół niego.

Wybór modelu warto oprzeć na takim pełnym zadaniu. Dwie prace z 2026 roku dały różne wyniki: Bielik prowadził w badaniu RAG na dokumentacji technicznej, PLLuM w badaniu na polskiej Wikipedii. Różniły się wersje modeli, dokumenty, wyszukiwarki i metody oceny. Żaden z tych wyników sam nie rozstrzyga, co zadziała na firmowym dysku.

Pierwsze badanie na rzeczywistej dokumentacji technicznej

W pracy Evaluation of Two Leading Polish Language Models in a Real-world RAG Scenario wykorzystano rzeczywistą dokumentację techniczną platformy low-code, podzieloną na około 1200 fragmentów. Badacze przygotowali 146 pytań referencyjnych wybranych jako prawdopodobne pytania użytkowników. Pracownicy pomagali przygotować odpowiedzi wzorcowe.

Najlepsze wyszukiwanie wektorowe z modelem OrlikB/KartonBERT-USE-base-v1 uzyskało:

Trafność oznacza tu 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ą obu miar i obniża się, gdy mocno się różnią. NDCG uwzględnia kolejność wyników, więc wyżej punktuje istotny fragment na początku listy. Wartości opisują wyłącznie wyszukiwanie. Jakość odpowiedzi generatora oceniano osobno.

Generator otrzymywał pięć dokumentów. Autorzy oceniali odpowiedzi ilościowo oraz parami, korzystając z trzech osobnych modeli jako automatycznych oceniających: gpt-oss-20b, Mistral-Small-3.2-24B-Instruct-2506 oraz Qwen3-30B-A3B-Instruct-2507. W skali od 1 do 5 ocena 5 oznaczała odpowiedź w pełni poprawną i wyczerpującą, a 1 odpowiedź błędną albo nie na temat:

Badanie ujawniło też wpływ kolejności odpowiedzi. Gdy odpowiedź PLLuM była pokazywana pierwsza, Bielik wygrywał 81,5% porównań. Po odwróceniu kolejności udział Bielika spadł do 54,3%. Wynik pokazuje, że porównania parami wymagają losowania kolejności i kontroli stronniczości po stronie oceniających.

Drugie badanie na polskiej Wikipedii

Praca Evaluating Cost-Efficiency of LLMs in a RAG Setup on Polish Wikipedia wykorzystała 1000 pytań PolQA. System pobierał fragmenty z polskiej Wikipedii, ponownie porządkował je według trafności i przekazywał wybrane fragmenty generatorowi. Do porównań parami użyto GPT-4o, osobnego modelu pełniącego rolę automatycznego oceniającego.

Autorzy użyli modelu Bradleya-Terry'ego. Ten model zamienia wyniki porównań parami na wspólny ranking: wyższa liczba oznacza większą szacowaną jakość w tej procedurze. Znak ± pokazuje niepewność raportowaną przez autorów.

W tej procedurze PLLuM uzyskał wyższy ranking. Pierwsza publikacja badała inny układ: inną wersję Bielika, inny korpus, pytania, wyszukiwarkę, sposób porządkowania fragmentów i metodę oceny. Zdanie „najlepszy polski model do RAG” wymaga więc wskazania tych szczegółów.

Gdzie w tym wszystkim jest Qwen3.8-27B

Oficjalna karta Qwen3.8-27B opisuje gęsty model 27B z natywnym oknem kontekstu o długości 262 144 tokenów. W naszym domowym eksperymencie Qwen odtworzył wszystkie sprawdzane fakty z wejść liczących 50 059, 115 074 i 230 085 tokenów. Najdłuższa próba trwała 563,4 s i osiągnęła 23 623 MiB VRAM.

Wynik uzasadnia sprawdzenie Qwena jako kandydata do pracy z długimi pakietami dokumentów. Nie rozstrzyga wyboru generatora do polskiego RAG. Pomiar Qwena obejmował trzy fakty umieszczone w długim tekście, a wyniki RAG dotyczą wyłącznie wersji modeli użytych w cytowanych publikacjach.

System wiedzy ma co najmniej dwa osobne wyniki

Pierwszy wynik dotyczy wyszukiwania: czy właściwy fragment znalazł się wysoko w rankingu. Drugi dotyczy odpowiedzi: czy generator zachował sens źródła, cytat, wersję dokumentu i właściwą odmowę. Te wyniki trzeba śledzić osobno, ponieważ każdy wskazuje inny rodzaj usterki.

Jedna zbiorcza ocena ukrywa miejsce awarii. Gdy odpowiedź jest błędna, zespół powinien umieć ustalić, czy:

• moduł odczytujący zgubił tabelę albo nagłówek;
• podział dokumentu rozdzielił definicję od wyjątku;
• wyszukiwarka nie znalazła właściwego dokumentu;
• filtr uprawnień usunął poprawne źródło lub przepuścił niedozwolone;
• generator zignorował dostarczony fragment;
• w indeksie pozostała nieaktualna wersja.

Co trzeba zachować przy każdej odpowiedzi

Odpowiedź bez śladu źródła jest trudna do sprawdzenia i naprawy. System używany operacyjnie powinien zachować identyfikator oraz wersję dokumentu, znalezione fragmenty i ich kolejność, tożsamość użytkownika i wynik filtra dostępu, dokładną wersję modelu oraz konfigurację, odpowiedź końcową i decyzję osoby oceniającej.

Taki zapis pozwala powtórzyć przypadek po zmianie modułu odczytującego, modelu do wyszukiwania semantycznego albo generatora. Pozwala to wykryć pogorszenie jakości po aktualizacji.

Jak wygląda test przed wdrożeniem

Zestaw powstaje z pytań, które pracownicy naprawdę zadają. Właściciel procesu wskazuje źródło, obowiązującą wersję, dopuszczalną odpowiedź i przypadki wymagające odmowy. Kontrole dostępu trafiają do tego samego zestawu od początku.

Następnie porównujemy dokładne konfiguracje na identycznym indeksie. Jeśli zmieniamy wyszukiwarkę, wyniki wyszukiwania oceniamy osobno od wyników generatora. Raport pokazuje każdą odrzuconą odpowiedź i jej powód. Sama średnia nie wystarcza.

Co Syntalith może zbudować i przekazać

Syntalith buduje prywatnych asystentów na dokumentach firmy. Porządkujemy źródła, przygotowujemy pytania testowe i porównujemy modele. Wdrożenie obejmuje odczyt plików, indeks, uprawnienia, cytaty oraz przegląd odpowiedzi.

Jeśli model myli firmowe kategorie lub format mimo poprawnych źródeł, sprawdzimy też fine-tuning. Opisz dokumenty i pytania zespołu, a zaproponujemy zakres próby. Możemy zacząć od jednego działu i jednego zbioru danych.