RAG na firmowych dokumentach offline - jaki sprzęt i jak zacząć (RODO)

Krótka odpowiedź: RAG to sposób, żeby model językowy odpowiadał na pytania na podstawie Twoich dokumentów — a lokalnie, gdy dokumenty zawierają dane, których firma nie chce lub nie może wypuszczać do zewnętrznych usług. (RODO bywa jednym z powodów takiej decyzji, ale samo korzystanie z chmury nie jest automatycznie niezgodne z RODO — do tego wrócę.) Do samych embeddingów wystarczy lekka karta — Tesla P4 8GB albo NVIDIA A2 16GB. Cały ciężar to LLM, który generuje odpowiedzi — tu chcesz dużo VRAM, więc V100 32GB albo Tesla P40 24GB. Można zacząć od jednej karty 24 GB i Ollamy, a rozbudować później. I tak — sprzedajemy te karty, pełne zastrzeżenie na końcu.

Piszę to głównie do firm, kancelarii i biur, które mają realny problem: setki albo tysiące dokumentów, w których nikt już nie umie szybko czegoś znaleźć, a nie wszystkie z tych dokumentów firma chce lub może przekazywać do zewnętrznego API. Nie jest to poradnik „AI zmieni Twój biznes" — to konkret, jak zbudować wyszukiwarkę-z-odpowiedziami po własnych aktach, tak żeby dane nie opuściły serwerowni.

Czym jest RAG (bez marketingu)

RAG to skrót od Retrieval-Augmented Generation — „generowanie wspomagane wyszukiwaniem". W praktyce działa tak: zadajesz pytanie, system najpierw znajduje fragmenty Twoich dokumentów pasujące do pytania, a potem wkłada je do LLM razem z poleceniem „odpowiedz na podstawie tych fragmentów". Efekt: model odpowiada Twoją wiedzą — treścią umów, procedur, protokołów, korespondencji — a nie tym, co „gdzieś widział w internecie".

Dlaczego to lepsze niż samo dopytywanie modelu? Bo LLM sam z siebie zmyśla (halucynuje), zwłaszcza o rzeczach specyficznych dla Twojej firmy, których nie ma w jego wiedzy. RAG daje modelowi konkretne fragmenty jako kontekst i może wymusić pokazanie źródła — „to jest w umowie X, paragraf 4" — co dla prawnika czy księgowej jest różnicą między zabawką a narzędziem pracy. Sam mechanizm nie gwarantuje jednak, że model zawsze zostanie w granicach podanych fragmentów (o tym w FAQ).

Po co offline — RODO, poufność i kontrola nad danymi

To nie zawsze jest „miło mieć". Dla części firm lokalne przetwarzanie jest istotnym wymaganiem ze względów prawnych, bezpieczeństwa lub poufności:

• Dane osobowe — w tym w niektórych przypadkach dane szczególnych kategorii (np. dokumentacja medyczna) oraz materiały objęte tajemnicą zawodową (adwokacka, radcowska). Wysłanie takich danych do zewnętrznego API oznacza powierzenie ich przetwarzania zewnętrznemu dostawcy i wymaga odpowiedniego uregulowania tej relacji. Jeśli dane trafiają poza EOG, dochodzą dodatkowo wymagania dotyczące transferu do państwa trzeciego.
• Tajemnica przedsiębiorstwa — umowy, wyceny, strategie. Nie chcesz, żeby trafiły na cudze serwery, choćby „tylko do przetwarzania".
• Suwerenność i przewidywalność — działa bez internetu, bez zależności od cudzego cennika i dostępności usługi.

Offline RAG znaczy: model, baza wektorowa i dokumenty żyją na Twoim sprzęcie. W poprawnie skonfigurowanym środowisku lokalnym treść dokumentów nie jest przekazywana do zewnętrznego API, co eliminuje potrzebę powierzania tej konkretnej operacji zewnętrznemu dostawcy. Zastrzeżenie: „lokalnie" to nie „z automatu zgodnie z RODO" — sama aplikacja może wysyłać telemetrię, pobierać modele czy robić backup na zewnątrz, więc środowisko trzeba świadomie odciąć i uzupełnić o kontrolę dostępu, logowanie i kopie (o tym niżej).

Architektura — co się z czego składa

Sercem RAG są trzy klocki:

1. Embeddingi — model zamienia każdy fragment dokumentu (i Twoje pytanie) na wektor liczb, który reprezentuje „znaczenie". Podobne znaczeniowo teksty mają podobne wektory. To lekki, szybki krok.
2. Baza wektorowa — przechowuje te wektory i błyskawicznie znajduje najbardziej podobne do pytania. Popularne, darmowe i uruchamialne lokalnie: Qdrant, Chroma, Milvus. Chroma dobrze nadaje się do szybkiego prototypowania, a Qdrant jest częstym wyborem przy wdrożeniach serwerowych wymagających trwałego storage, filtrowania i większej kontroli operacyjnej.
3. LLM — dostaje znalezione fragmenty + pytanie i formułuje odpowiedź po polsku. Zwykle najcięższy obliczeniowo element i w największym stopniu decyduje o wymaganiach VRAM — ale liczy się nie tylko rozmiar modelu, też jego kwantyzacja, długość kontekstu, KV cache i liczba równoległych zapytań.

Przepływ w jednym zdaniu: dokument → embedding → baza wektorowa → (na pytanie) wyszukanie fragmentów → LLM → odpowiedź z cytatami.

Jaki sprzęt — i dlaczego dzielimy zadania

Kluczowa obserwacja, która oszczędza pieniądze: embeddingi i LLM mają zupełnie różne apetyty.

Embeddingi są lekkie. Modele embeddingowe (np. z rodziny multilingual/E5, BGE) to setki milionów parametrów, nie miliardy. Liczą się szybko, mieszczą w kilku GB. Do tego w zupełności wystarczy Tesla P4 8GB (8 GB, do 75 W, low-profile — dobra jako tani, energooszczędny „indekser", pod warunkiem zapewnienia odpowiedniego przepływu powietrza przez radiator karty; to karta pasywna) albo NVIDIA A2 16GB, jeśli chcesz nowszą architekturę i zapas. Nie przepłacaj tu za duży VRAM — to nie tu jest ciężar.

LLM to jest ciężar. Nie dobieraj modelu wyłącznie po liczbie parametrów — zacznij od współczesnego modelu, który dobrze radzi sobie z polskim (rzędu kilku–kilkunastu miliardów parametrów), i sprawdź go na własnych dokumentach; większy bywa lepszy, ale zwiększa wymagania VRAM. Ważny jest też dłuższy kontekst, bo RAG wkłada do promptu znalezione fragmenty (to potrafi być kilka tysięcy tokenów). Kontekst zjada VRAM oprócz wag modelu. Dlatego tu celujesz w maksimum pamięci:

• V100 32GB — jeśli priorytetem jest duży zapas VRAM w rozsądnym budżecie i masz odpowiednią platformę serwerową, to jedna z najmocniejszych opcji w naszej ofercie pod LLM w RAG. Volta z Tensor Cores + 32 GB HBM2 = komfort na większy model, długi kontekst i szybkie przetwarzanie wsadu fragmentów. Zastrzeżenie: starsza architektura, pobiera dużo mocy i wymaga platformy oraz chłodzenia pod kartę serwerową.
• Tesla P40 24GB — budżetowy sposób na 24 GB VRAM. W Ollama/llama.cpp wykorzystasz ją do inferencji modeli kwantyzowanych GGUF; wolniejszy FP16 (to Pascal), więc trzymaj się kwantyzacji — przy tej generacji szczególnie sensowne są warianty Q4/Q5.

W praktyce częsty i sensowny układ to jedna karta 24/32 GB na LLM + ewentualnie tania P4/A2 na embeddingi (albo embeddingi na tej samej karcie, jeśli zostaje pamięć). Ile dokładnie VRAM pod jaki model — rozpisałem w ile VRAM na Llamę 7B/13B/70B. Jeśli zależy Ci na polskim modelu, zobacz też Bielik lokalnie na używanej Tesli — to jeden z modeli, które warto przetestować do polskojęzycznego RAG.

Uwaga na sterownik: aktualna wersja Ollama obsługuje P4, P40 i V100, ale dla kart Pascal (P4/P40, compute capability 6.1) wymaga obecnie sterownika NVIDIA 570 lub nowszego (V100 jako Volta/7.0 ma łagodniejszy próg). Jeśli masz starszą instalację (Ubuntu/Proxmox/Debian ze starszym sterownikiem datacenter), system może poprawnie wykrywać kartę, ale aktualna wersja Ollama może wymagać nowszego sterownika — przed budową serwera sprawdź aktualne wymagania, bo bywają zmieniane.

Co pokazały nasze pomiary

Żeby nie zostać na ogólnikach, przetestowaliśmy poszczególne elementy lokalnego pipeline'u RAG opartego na Ollama + Chroma + LlamaIndex: indeksowanie, retrieval, generację LLM, wykorzystanie VRAM i zachowanie przy równoległych zapytaniach. Testy wykonaliśmy na tym samym polskim korpusie scifact-pl (100 zapytań z osądami trafności), z modelem Bielik 11B i embeddingami e5-large/bge-m3, na kartach ustawionych na pełny power limit i z ECC; szczegółowy zakres każdego pomiaru podaję przy wynikach. To jeden korpus i ograniczony zestaw modeli — traktuj liczby jako punkt odniesienia, nie jako wyrocznię dla każdego zbioru dokumentów.

Pomiar	P4	A2	P40	V100
Indeksowanie ~5 tys. fragmentów	~14 min	~11 min	~6 min	~2 min
Generacja Bielik 11B Q4 (tokeny wyjściowe/s)	—	—	~28	~74–80
Pełna odpowiedź (e2e), 1 użytkownik	—	—	~10 s	~3,5 s

GPU wpływało na czas obliczeń, nie na recall retrievalu — jakość wyszukiwania zależy od modelu embeddingowego. Na korpusie scifact-pl:

Retrieval (scifact-pl)	Recall@10
e5-large (natywne cięcie)	0,83
bge-m3 (natywne cięcie)	0,75
bge-m3, cięcie ~256 tok (osobny eksperyment)	0,82

Embeddingi faktycznie są lekkie. Zaindeksowanie ~5 tys. fragmentów zajęło ~2 min na V100 i ~6 min na P40; A2 ~11 min, a P4 ~14 min. Sam zapis wektorów do bazy trwał ~7 s niezależnie od karty, więc w tym teście GPU nie było ograniczeniem tego etapu — czas wynikał przede wszystkim z części CPU/storage pipeline'u. Mocniejsza karta wyraźnie skraca indeksowanie, ale przy takim wolumenie nawet P4/A2 kończą zadanie w kilkunastu minutach — a że jest to zwykle okresowe zadanie wsadowe w tle, nie musi uzasadniać zakupu mocnego GPU tylko do embeddingów.

LLM to inny świat. Generacja odpowiedzi (Bielik 11B Q4, kontekst 512 tokenów) osiągała ~28 tokenów wyjściowych/s na P40 i ~74–80 na V100 — w samej generacji LLM V100 dała w tych testach około 2,6–2,9× wyższy throughput niż P40 (zależnie od egzemplarza i długości kontekstu). W praktyce pełna odpowiedź (wyszukanie + generacja) to ~3,5 s na V100 wobec ~10 s na P40 dla jednego użytkownika; samo wyszukanie zajmowało ~30 ms, więc w tej konfiguracji zdecydowaną większość latencji generował LLM. Widać też, dlaczego warto zostawić zapas VRAM ponad same wagi modelu: wzrost kontekstu do 8 tys. tokenów podniósł zużycie Q4 z ~6,7–7 do ~8,7 GB, a Q8, czyli mniej agresywna kwantyzacja, potrzebował już ~12–13,5 GB.

8 GB nie wystarczyło na nasz pełny pipeline na jednej karcie. W naszej konfiguracji Tesla P4 8GB policzyła embeddingi i — osobno — uruchomiła sam LLM, ale Bielik 11B Q4 i embedder jednocześnie nie zmieściły się w 8 GB VRAM. To nie defekt karty, tylko granica pojemności tej konkretnej konfiguracji — mniejszy model, CPU offload albo embeddingi liczone na CPU mogą zmienić wynik. Dla tego, co testowaliśmy, 16 GB było już znacznie bezpieczniejszym punktem startowym, a P4 pozostaje świetnym tanim indekserem.

Jakość wyszukiwania zależy od modelu embeddingowego, nie od karty. Na naszym korpusie e5-large wypadł lepiej niż bge-m3 — recall@10 0,83 vs 0,75 (czyli w uproszczeniu: jak często właściwy fragment trafił do pierwszej dziesiątki wyników wyszukiwarki). W osobnym eksperymencie dla bge-m3 zmniejszenie fragmentu do ~256 tokenów podniosło recall@10 z 0,75 do 0,82, kosztem większej liczby jednostek do zaindeksowania. To domenowo-zależne — na Twoich dokumentach kolejność może wyjść inaczej. Nasz wynik pokazuje natomiast, że dla jakości retrievalu warto stroić przede wszystkim model embeddingowy i sposób cięcia dokumentów; mocniejsza karta skraca obliczenia, ale sama nie poprawia recall tego samego pipeline'u.

Współbieżność: w naszym setupie rosła kolejka, nie przepustowość. Dla testowanej konfiguracji (Bielik 11B Q4, jedna instancja) dokładanie równoległych zapytań nie zwiększało przepustowości — rosła przede wszystkim kolejka, a czas p95 wydłużał się wraz z liczbą zapytań. To wynik dla konkretnego modelu i backendu, nie uniwersalna właściwość inferencji LLM: inne serwery wykorzystujące batching mogą zachowywać się inaczej. Jeśli potrzebujesz przewidywalnej latencji dla wielu użytkowników, przetestuj współbieżność na docelowym stosie; jedną z dróg skalowania jest uruchomienie dodatkowych instancji lub kart.

Jak zacząć — najprostsza droga

Nie potrzebujesz zespołu ML, żeby postawić pierwszy działający RAG. Minimalny stos:

1. Ollama jako serwer LLM — ollama run i masz lokalny model z API. Do polskiego wsadź Bielika albo inny model wielojęzyczny.
2. Baza wektorowa — Chroma (najprościej, pip install chromadb) albo Qdrant w Dockerze, jeśli myślisz produkcyjnie.
3. Framework spinający — LangChain albo LlamaIndex. Oba mają gotowe klocki: wczytaj PDF-y/DOCX-y, potnij na fragmenty, policz embeddingi, wsadź do bazy, a na pytanie — wyszukaj i zapytaj LLM. Pierwszy proof-of-concept zbudujesz w kilkudziesięciu liniach kodu; produkcyjne wdrożenie to już większy projekt — dochodzą uprawnienia, aktualizacja indeksu, OCR, monitoring i kontrola jakości odpowiedzi.

Schemat startowy: wczytaj dokumenty → potnij → zaindeksuj (embeddingi do bazy) → pętla pytań (wyszukaj fragmenty → prześlij do Ollamy → pokaż odpowiedź). Zacznij od małego zbioru (jeden dział, jeden typ dokumentów), sprawdź jakość odpowiedzi, dopiero potem skaluj.

Koszt: własny sprzęt vs chmura

Uczciwie, bez naciągania. Chmura wygrywa, gdy używasz RAG sporadycznie, nie przetwarzasz poufnych dokumentów i nie chcesz nic administrować — płacisz za zapytanie i tyle. Własny sprzęt warto rozważyć szczególnie wtedy, gdy spełniony jest choć jeden z warunków: polityka bezpieczeństwa, poufność lub wymagania organizacji narzucają lokalne przetwarzanie, obciążenie jest stałe (asystent używany codziennie przez zespół), albo chcesz przewidywalny koszt bez licznika tokenów.

Tylko uczciwie: próg opłacalności zależy od tego, z czym porównujesz — i nie zawsze wychodzi na korzyść własnego sprzętu.

• Względem wynajmu dedykowanej karty w chmurze 24/7 (np. RTX 4090 od ~0,31–0,35 $/godz. na platformach marketplace/community — dedykowane instancje kosztują więcej; ≈ ~1000 zł/mies. przy pracy 24/7, stan 08.2026) build używanej Tesli za ~2900–3900 zł odpowiada mniej więcej 3–4 miesiącom samego kosztu takiej karty w chmurze. Tu „miesiące, nie lata" faktycznie jest prawdą — pamiętaj tylko, że pełny koszt lokalnego serwera obejmuje jeszcze prąd, sprzęt poza GPU i administrację.
• Względem API rozliczanego per token sprawa wygląda inaczej: najtańsze współczesne modele kosztują dziś ułamki dolara za milion tokenów wejścia, ale bardziej zaawansowane modele kosztują wielokrotnie więcej, a tokeny wyjściowe są zwykle znacznie droższe od wejściowych (stan 08.2026). Przy umiarkowanym wolumenie (setki zapytań dziennie) samo API bywa w czystym rachunku tokenów tańsze niż amortyzacja własnej karty. Wtedy on-prem uzasadniają wymagania dotyczące poufności, compliance i kontroli nad danymi oraz przewidywalność, a nie sama cena — próg czysto kosztowy przeciw API pojawia się dopiero przy dużym, stałym ruchu.

Innymi słowy: jeśli wymagania prawne, umowne lub wewnętrzne wykluczają przekazywanie dokumentów zewnętrznemu dostawcy, porównanie z publicznym API przestaje być wyłącznie decyzją kosztową — i to bywa mocniejszy argument niż sam koszt tokenów. Policz swój wolumen i porównaj z aktualnym cennikiem, zamiast wierzyć w hasło „self-host zawsze taniej".

Do rachunku dolicz też to, czego cennik chmury nie pokazuje: niezależność. Cennik API potrafi się zmienić, model zostać wycofany albo usługa niedostępna w kluczowym momencie. Własna infrastruktura daje większą kontrolę nad środowiskiem i nie zależy bezpośrednio od zmian cennika, limitów czy decyzji dostawcy API — w zamian to firma odpowiada za jej utrzymanie, aktualizacje i awarie. Dla firmy, która buduje proces wokół asystenta na dokumentach, ta przewidywalność bywa warta więcej niż sam koszt tokenów.

Częste błędy na starcie

Zanim zamówisz sprzęt, warto znać typowe pułapki, które psują jakość RAG — i zwykle nie mają nic wspólnego z kartą:

• Złe cięcie dokumentów — za duże fragmenty rozmywają trafność, za małe gubią kontekst. To najczęstsza przyczyna słabych odpowiedzi, nie za mały model.
• Brak metadanych i źródeł — jeśli nie zapiszesz, z którego dokumentu pochodzi fragment, tracisz największy atut RAG: cytowanie. Zadbaj o to od początku.
• Źle dobrany model LLM — nie wybieraj go wyłącznie po rozmiarze ani po tym, ile VRAM zostaje na karcie. Sprawdź jakość na reprezentatywnych pytaniach z własnych dokumentów; większy model (i 24/32 GB pod niego) ma sens dopiero, gdy daje mierzalnie lepsze odpowiedzi.
• Zły model embeddingowy do polskiego — użyj modelu wielojęzycznego dobrze radzącego sobie z polskim, inaczej wyszukiwanie będzie chybiać mimo dobrego LLM.
• Brak kontroli dostępu w warstwie wyszukiwania — lokalny RAG nie znaczy, że każdy użytkownik ma widzieć wszystkie dokumenty. Uprawnienia muszą działać, zanim padnie odpowiedź: retriever nie powinien nawet zwracać fragmentów dokumentów, do których pytający nie ma dostępu — inaczej ktoś ze sprzedaży wyciągnie akta HR samym pytaniem.
• Założenie, że każdy PDF zawiera tekst — wiele firmowych archiwów to skany. Jeśli PDF jest tylko obrazem, potrzebujesz OCR przed indeksowaniem; bez tego nie ma tekstu do pocięcia, osadzenia i wyszukania.

Źródła

• multilingual-e5-large (model embeddingowy wielojęzyczny) — https://huggingface.co/intfloat/multilingual-e5-large
• BAAI/bge-m3 (model embeddingowy wielojęzyczny) — https://huggingface.co/BAAI/bge-m3
• Qdrant (baza wektorowa) — https://github.com/qdrant/qdrant
• Chroma (baza wektorowa) — https://github.com/chroma-core/chroma
• Milvus (baza wektorowa) — https://github.com/milvus-io/milvus
• Ollama (lokalny serwer LLM) — https://github.com/ollama/ollama
• LangChain (framework RAG) — https://python.langchain.com/
• LlamaIndex (framework RAG) — https://docs.llamaindex.ai/
• Ollama — obsługiwany sprzęt (compute capability i wymagane sterowniki NVIDIA) — https://docs.ollama.com/gpu
• Cennik API modeli LLM (per 1M tokenów; floor wejścia rzędu $0,20, modele zaawansowane wielokrotnie drożej, output zwykle kilkukrotnie droższy od wejścia; stan 08.2026) — CloudZero, „LLM API Pricing Comparison 2026" — https://www.cloudzero.com/blog/llm-api-pricing-comparison/
• Cennik wynajmu GPU w chmurze (RTX 4090 ~$0,31–0,35/godz. marketplace/community, dedykowane drożej; stan 08.2026) — Spheron, „GPU Cloud Pricing Comparison 2026" — https://www.spheron.network/blog/gpu-cloud-pricing-comparison-2026/
• Tesla P40 24GB / V100 — nasza oferta (baza kosztu buildu) — https://store.agilesoftware.pl/oferta/p40-24
• Pomiary własne (Agile Store, 09.2026): stos Ollama + Chroma + LlamaIndex; korpus scifact-pl (polski) — stała próbka pierwszych 100 zapytań z qrels test wg rosnącego id; embeddingi e5-large i bge-m3; model Bielik 11B w wariantach Q4_K_M / Q5_K_M / Q8_0; karty na pełnym power limit, ECC on. Liczby w sekcji „Co pokazały nasze pomiary" pochodzą z tego benchmarku (dane surowe wewnętrzne).

---

Uczciwe zastrzeżenie: sprzedajemy używane karty datacenter, więc mam w tym interes — ale RAG offline ma sens niezależnie od tego, u kogo kupisz sprzęt; jeśli Twój wolumen jest mały i dokumenty nie są poufne, czasem lepszym wyborem jest po prostu chmura i to też Ci powiem. To sprzęt używany: każda sztuka przed sprzedażą przechodzi naszą sześcioetapową procedurę kwalifikacji (odcisk techniczny, test VRAM, burn-in z watchdogiem, ECC, PCIe i kontrola poprawności obliczeń), a wynik testów konkretnego egzemplarza dokumentujemy w certyfikacie — pytaj o certyfikat konkretnej karty. Chcesz obgadać architekturę pod swoje dokumenty i budżet? napisz do nas — pomożemy dobrać kartę do LLM i osobną do embeddingów, albo odradzimy zakup, jeśli w Twoim przypadku się nie spina.