Problem
Zespół potrzebował rozmawiać z własnymi dokumentami przy użyciu LLM, ale bez wysyłania treści do chmury publicznej. Klasyczny czat bez retrievalu „zmyślał“, a wrażliwość danych wykluczała gotowe usługi SaaS.
Kontekst
Rozwiązanie zaprojektowane do wdrożenia lokalnego/we własnej infrastrukturze, z rozdziałem warstwy aplikacyjnej od warstwy obliczeniowej (model, embeddingi). Priorytetem była kontrola nad danymi i możliwość pracy na lokalnym modelu.
Wymagania
- Czat z historią rozmów i rolami użytkowników.
- Wgrywanie dokumentów i budowanie indeksu RAG.
- Retrieval z bazy wektorowej + odpowiedzi z lokalnego modelu.
- Możliwość rozdzielenia wdrożenia (aplikacja vs. obliczenia).
Rola
Zaprojektowałem architekturę i zaimplementowałem całość: frontend i API (Next.js), warstwę auth i persystencji, osobny serwis RAG (FastAPI) oraz integrację z bazą wektorową i lokalnym modelem.
Architektura
Technologie
Next.js 14 + React 18 (UI i API), NextAuth + Prisma + PostgreSQL (auth, rozmowy, metadane dokumentów), Qdrant (baza wektorowa), FastAPI (serwis RAG), Ollama (lokalny model), opcjonalny serwis embeddingowo-rerankingowy.
Decyzje projektowe
- Osobny serwis RAG zamiast logiki retrievalu w aplikacji webowej — czysty podział odpowiedzialności i niezależne skalowanie.
- Baza relacyjna + wektorowa obok siebie: PostgreSQL na metadane i rozmowy, Qdrant na retrieval.
- Lokalny model (Ollama) jako domyślny, z możliwością podmiany na zdalny.
Trade-offy
- Lokalny model = pełna kontrola nad danymi, kosztem wydajności i większych wymagań sprzętowych względem chmury.
- Więcej usług (Next.js + FastAPI + Qdrant + Ollama) = elastyczność wdrożenia kosztem złożoności operacyjnej.
Problemy techniczne
- Jakość odpowiedzi zależna od jakości chunkowania i retrievalu.
- Rozdział warstwy aplikacyjnej i obliczeniowej wymagał jasnych kontraktów między usługami.
- Zarządzanie stanem rozmów i powiązaniem ich z dokumentami/indeksem.
Rozwiązania
- Wydzielony serwis RAG z jasnym API (indeksowanie, zapytania) i opcjonalnym rerankiem.
- Metadane i historia w PostgreSQL, wektory w Qdrant — każde narzędzie do swojego zadania.
- Tryby wdrożenia rozdzielające aplikację od obliczeń (możliwość osobnych hostów).
Rezultat
Powstała pełna platforma czatu z RAG działająca lokalnie: auth, UI, indeksowanie dokumentów i retrieval, z zachowaniem kontroli nad danymi. Architektura pozwala skalować lub podmieniać warstwę obliczeniową niezależnie od aplikacji.
Lessons learned
- Największy wpływ na jakość ma pipeline retrievalu (chunking, embeddingi, rerank), nie sam model.
- Rozdział usług od początku ułatwia późniejsze skalowanie i debugowanie.
What I’d do differently today
- Dodałbym ewaluację jakości odpowiedzi (zestawy testowe, metryki) i obserwowalność retrievalu.
- Rozważyłbym warstwę cache dla najczęstszych zapytań i embeddingów.
Interview talking points
- Dlaczego PostgreSQL i Qdrant obok siebie, a nie jedna baza.
- Jak rozdział aplikacja/serwis RAG wpływa na skalowanie i bezpieczeństwo danych.
- Kompromis lokalny model vs. usługa zdalna w kontekście prywatności.