Otwarta platforma RAG dla firm
Twoje dokumenty stają się asystentem, który odpowiada i podaje źródło. Wszystko zostaje na twojej infrastrukturze: dokumenty, baza, indeks wektorowy i klucze szyfrujące. Modele wybierasz sam, zmiana dostawcy to plik konfiguracyjny.
Jak działa wczytywanie dokumentu
Plik trafia do storage i przejmuje go workflow Temporala: parsowanie, chunking splitterem dobranym do typu pliku, streszczenie całego dokumentu doklejone jako osobny fragment, embedding gęsty i rzadki, zapis do kolekcji Qdranta należącej do organizacji. Całość idzie asynchronicznie, więc 400-stronicowy PDF niczego nie blokuje.
upload → parsowanie → chunking → streszczenie → embedding hybrydowy → Qdrant Jak działa odpowiadanie
Pytanie jest najpierw przepisywane na samodzielne na podstawie dotychczasowej rozmowy, a potem rozszerzane o alternatywne sformułowanie. Oba idą równolegle jako wyszukiwania hybrydowe. Qdrant łączy wyniki gęste i rzadkie po swojej stronie fuzją RRF, suma jest deduplikowana i, jeśli skonfigurowałeś dostawcę rerankingu, trafia do cross-encodera, zanim zobaczy ją model. Na wierzchu prompt wymuszający cytowanie.
pytanie → samodzielne → +1 wariant → 2× wyszukiwanie hybrydowe → RRF → deduplikacja → reranking → odpowiedź Wyszukiwanie hybrydowe nie jest przełącznikiem. To część schematu, z którym powstają kolekcje, więc jest zawsze włączone. Reranking jest przełącznikiem: wymaga flagi i danych dostawcy, a bez nich jest pomijany. Każdy etap degraduje się zamiast wywalać – błąd rerankera cofa do surowej kolejności wektorowej, błąd rozszerzenia cofa do pojedynczego zapytania.
Uprawnienia przy wyszukiwaniu
Każdy fragment dokumentu nosi filtr accessible_by, stosowany w momencie zapytania. Dokument, którego użytkownik nie może otworzyć, nie wejdzie do odpowiedzi, do cytowania ani do kontekstu wysłanego do modelu.
Wiele firm na jednej instalacji
Osobna kolekcja wektorowa na organizację, guard w warstwie danych zgłaszający każde zapytanie bez filtra organizacji, dwie rozdzielone hierarchie ról. Jedna instalacja obsługuje wielu klientów, bez opłat za stanowisko.
Jak to wypada w porównaniu
| Kryterium | Hostowane „czatuj z dokumentami” | Własny stack na LangChain | Ragen |
|---|---|---|---|
| Gdzie leżą twoje dokumenty | w chmurze dostawcy | u ciebie | u ciebie |
| Wybór modelu | krótka lista dostawcy | dowolny | każdy, który obsługuje LiteLLM |
| Kontrola dostępu | zwykle na poziomie workspace | tyle, ile zbudujesz | per plik i folder, przy wyszukiwaniu |
| Wielu klientów na jednej instancji | per stanowisko, per workspace | tyle, ile zbudujesz | w architekturze, dane i indeks per organizacja |
| Jakość wyszukiwania | nieprzejrzysta | twoja do tuningu i do debugowania | hybryda, reranking, rozszerzanie zapytań, decyzja zapisana przy każdej zmianie |
| Czas do pierwszej odpowiedzi | minuty | tygodnie | minuty, jedno polecenie plus twoje klucze do modeli |
| Kształt kosztu | za stanowisko, na zawsze | czas twoich inżynierów | twoja infrastruktura plus koszt modeli |
| Kiedy się zepsuje | zgłoszenie do supportu | ty | ty, z kodem i z zapisanymi decyzjami |
Jeśli twoje wymagania są naprawdę niestandardowe, zbudowanie tego samemu jest sensowną odpowiedzią. Ragen wypada lepiej wtedy, kiedy chcesz mieć te decyzje już podjęte i opisane, a nie podejmować je samemu.
Wymagania
| Zasób | Do testów | Mała instalacja produkcyjna |
|---|---|---|
| CPU | 4 rdzenie | 4 rdzenie lub więcej |
| RAM | 8 GB dostępne dla Dockera | 16 GB |
| Dysk | 25 GB | 100 GB SSD, rośnie razem z dokumentami |
| Docker | 24.0 lub nowszy, Compose 2.26 lub nowszy | tak samo |
| GPU | niepotrzebne | niepotrzebne |
Bez GPU, chyba że sam je chcesz
Chat, embeddingi i reranking wychodzą przez proxy LiteLLM, więc maszyna z Ragenem nie liczy u siebie żadnego modelu. Wskaż LiteLLM hostowanego dostawcę i wystarczy laptop. GPU wchodzi w grę dopiero wtedy, gdy zdecydujesz się serwować modele samodzielnie. To jest wspierane i jest osobnym tematem.
Gdzie realnie idzie pamięć
| Usługa | Pamięć bezczynna | Potrzebna do |
|---|---|---|
| Presidio analyzer | 959 MB | maskowanie danych osobowych (opcjonalne) |
| Docling | 721 MB | lokalne parsowanie dokumentów |
| LiteLLM | 560 MB | każde wywołanie modelu |
| Temporal | 97 MB | asynchroniczny ingest |
| Postgres | 93 MB | wszystko |
| Presidio anonymizer | 55 MB | maskowanie danych osobowych (opcjonalne) |
| Qdrant | 43 MB | wyszukiwanie, rośnie razem z indeksem |
| Postgres LiteLLM-a i Temporal UI | 38 MB | dwa kontenery wspierające |
| Razem | około 2,6 GB |
Zmierzone na bezczynnym stacku, same usługi wspierające. Dwie pozycje są opcjonalne i razem dają gigabajt: Presidio odpada, jeśli nie maskujesz danych osobowych, a DOCUMENT_PARSER=legacy pomija Docling. Qdrant to linia, która się rusza w miarę dodawania dokumentów, bo liczba powyżej to prawie pusty indeks. Tę jedną wymiaruj pod swój korpus, a nie pod tę tabelę. Cztery aplikacje Ragena działają na wierzchu tego wszystkiego i nie ma ich w tabeli.
Postaw to u siebie
Jedno polecenie stawia komplet: web, API, worker ingestu, panel administracyjny i usługi wspierające. Potem wgraj dokument i o coś zapytaj.