RAG on-premise: co tracisz, a co zyskujesz

Nikt nie pyta "chmura czy on-premise" z ciekawości. To pytanie pojawia się zawsze przy konkretnym katalogu. Umowy, dokumentacja medyczna, kod źródłowy, akta spraw - coś, z czym wiąże się jakiś przepis. RAG on-premise oznacza, że dokumenty, indeks, etap embeddingu i inference modelu zostają w infrastrukturze kontrolowanej przez klienta. Chmura nie jest tu opcją niebezpieczną, a on-prem nie jest automatycznie bezpieczny. Obie to decyzje inżynierskie z innymi rodzajami ryzyka, a poniżej opisujemy, co realnie zmienia się po każdej stronie tej granicy.

Co zostaje w środku, gdy hostujesz sam

Własny hosting przenosi za twoją granicę każdą warstwę, która dotyka treści dokumentów. I nie pomijaj logu zapytań - pytania zadawane przez pracowników zdradzają negocjowane umowy, trwające incydenty i transakcje, o których nikt jeszcze nie poinformował. Elementy, które trafiają do ciebie:

• Parser i etap OCR
• Wagi modelu embeddingowego
• Indeks wektorowy i reranking
• Model generujący i warstwa orkiestracji
• Logi i dane ewaluacyjne

Praktyczny test każdej deklaracji o on-premie: narysuj granicę sieci, a potem sprawdź, czy cokolwiek ją przekracza. Łącznie z telemetrią i aktualizacjami modelu.

Co tracisz

Najpierw zawęża się wybór modelu. Najmocniejsze modele hostowane nie są udostępniane jako wagi, więc pracujesz na rodzinach open-weight i godzisz się na realną różnicę przy trudnym rozumowaniu i bardzo długim kontekście. Ścieżka aktualizacji też jest twoja. Nic nie poprawia się samo z dnia na dzień, a każda zmiana biblioteki czy modelu staje się projektem z testami. Sprzęt zamienia się w ograniczenie planistyczne - pamięć GPU decyduje, co się zmieści, a liczba równoległych zapytań jest ograniczona tym, co stoi w szafie. Monitoring, backupy, przebudowy indeksu, wersje sterowników, dyżury: wszystko po twojej stronie. Zakupy sprzętu wydłużają też czas do pierwszego działającego asystenta.

Co zyskujesz

Masz czystą odpowiedź na pytanie, które naprawdę zadają audytorzy, klienci i rady pracownicze. Dokąd trafia tekst i kto może go przeczytać. Prostsza robi się też strona umowna: żadnego łańcucha umów powierzenia, żadnej analizy transferu poza granice, żadnej listy podprzetwarzających do przeglądu co roku. Koszt przybiera przewidywalny kształt - wydatek inwestycyjny i znany pobór mocy zamiast rozliczenia za tokeny, które rośnie wraz z użyciem. Opóźnienia i dostępność masz pod kontrolą, łącznie z lokalizacjami odciętymi od sieci. A najlepsze jest to, że możesz zaindeksować wrażliwy zbiór dokumentów, a nie jego okrojoną część. Zwykle właśnie w tym momencie asystent staje się naprawdę przydatny.

Kiedy wygrywa wdrożenie mieszane

Rzeczywiste architektury rzadko stoją na którymś skraju. Sensowne pytanie brzmi: który etap przetwarza wrażliwy tekst. Częsty układ trzyma embeddingi i bazę wektorową lokalnie, a generuje hostowany model, przy czym redakcja treści ogranicza to, co trafia do promptu. Odwrotnie też działa: zbiór objęty ograniczeniami zostaje w całości lokalnie, a hostowane modele obsługują wyłącznie treści publiczne.

1. W pełni hostowane - szybki efekt, bez własnego zespołu od infrastruktury
2. Hostowany model, prywatny indeks - zbiór zostaje na miejscu, generowanie pożyczone
3. W pełni własny hosting - granica prawna lub umowna obejmuje cały tekst
4. Odcięte od sieci - żaden ruch wychodzący nie jest dozwolony

Wskazówka: sklasyfikuj zbiór dokumentów, zanim wybierzesz architekturę. Jeden katalog z ograniczeniami nie powinien ciągnąć całego systemu na on-prem, jeśli może stać we własnej instancji.

Jak decydujemy razem z klientami

Zaczynamy od najostrzej chronionej klasy dokumentów w zakresie, a nie od średniej, bo to ta klasa wyznacza granicę. Potem pytamy, kto to zatwierdza - bezpieczeństwo, dział prawny, regulator, umowa z klientem - i jakie dowody każde z nich akceptuje. Liczy się docelowa liczba zapytań, bo porównanie kosztów odwraca się gdzieś między ruchem pilotażowym a użyciem w całej organizacji. Sprawdzamy, czy jakiś zespół już utrzymuje infrastrukturę GPU, a gdy odpowiedź brzmi "zatrudnimy kogoś", traktujemy to jako ryzyko, nie jako plan. Wymagania dotyczące podawania źródeł też pojawiają się wcześnie, bo przesuwają ciężar w stronę wyszukiwania i uprawnień.

Wskazówka: prowadź pilotaż na tym wdrożeniu, które zamierzasz zostawić. Wyszukiwanie dostrojone pod jeden model rzadko przenosi się bez zmian na inny.

Najczęściej zadawane pytania

Czy asystent on-premise odpowiada gorzej niż ten w chmurze?

Przy najtrudniejszym rozumowaniu tak - różnica na modelach open-weight jest realna i mówimy to wprost. Ale przy odpowiadaniu na pytania w oparciu o twoje własne dokumenty o wyniku zwykle decyduje chunking, jakość wyszukiwania i filtrowanie po uprawnieniach, a nie wybór modelu.

Jakiego sprzętu naprawdę potrzebujemy?

Dobór wynika z logiki, a nie z numeru katalogowego. Rozmiar modelu i kwantyzacja wyznaczają pamięć GPU, liczba równoczesnych użytkowników wyznacza przepustowość, a sam indeks jest stosunkowo tani w utrzymaniu. Zmierz obciążenie na pilotażu i dopiero pod nie kupuj.

Czy możemy zacząć w chmurze i przenieść się później na on-premise?

Tak, pod warunkiem że wczytywanie dokumentów, wyszukiwanie i generowanie zostaną osobnymi, wymiennymi elementami. Koszt migracji siedzi w ponownym liczeniu embeddingów dla całego zbioru i w przestrajaniu promptów, więc zaplanuj ponowną ewaluację, a nie zwykłe przeniesienie.

Jak podjąć decyzję

Czytaj to jak wymianę, a nie wyrok: kontrolę i szczelność kupujesz sufitem możliwości i bieżącą pracą operacyjną. W jedną stronę cofa się łatwiej niż w drugą, więc spisz założenia, które stały za twoim wyborem. Niezależnie od wyboru zostaje to, dla czego w ogóle warto budować takie systemy - odpowiedzi oparte na twoich własnych dokumentach, z podanym źródłem, żeby pracownicy sprawdzali, a nie ufali na słowo. Zmapuj zbiór dokumentów, wskaż najostrzej chronioną klasę i pozwól, żeby to ona wybrała wdrożenie.