Bazy danych SQL, NoSQL i wektorowe w pracy AI Engineera: PostgreSQL, MongoDB, Redis i retrieval w praktyce

Intro

Wyobraź sobie taki bardzo realistyczny wtorek o 10:13. Masz w firmie asystenta AI dla supportu. Użytkownik zadaje pytanie o błąd w płatnościach, system w locie sprawdza historię klienta, wyciąga najnowszą procedurę z wewnętrznej bazy wiedzy, dociąga podobne incydenty z ostatnich trzech miesięcy, a potem składa z tego odpowiedź, która brzmi sensownie i jeszcze podaje źródła. Demo wygląda świetnie. Product jest zadowolony. Ktoś mówi: „dobra, to przecież tylko model plus jakaś baza danych”. I właśnie w tym miejscu większość zespołów zaczyna upraszczać temat tak mocno, że potem miesiącami odkręca skutki.

Bo w praktyce to prawie nigdy nie jest „jakaś baza danych”. Pytanie brzmi raczej: która warstwa danych ma przechowywać prawdę biznesową, która ma dawać szybkość, która ma trzymać elastyczny stan, a która ma służyć do wyszukiwania po znaczeniu. Jeśli pomylisz te role, system jeszcze przez chwilę może wyglądać dobrze. Potem zaczyna się klasyczny teatr produkcyjny: powolne zapytania, rozjechane embeddingi, nieaktualne indeksy, dziwne duplikaty, brak spójności między danymi źródłowymi a retrieverem i to nieprzyjemne uczucie, że niby wszystko działa, ale nikt nie ufa odpowiedziom.

Wokół baz danych w AI narosły dwa równie szkodliwe uproszczenia. Pierwsze mówi: „PostgreSQL załatwi wszystko, bo ma SQL, JSONB i pgvector”. Drugie mówi: „nie, teraz wszystko robi się na NoSQL i vector database, bo relacyjne bazy są za stare do AI”. Oba brzmią wygodnie. Oba są w połowie fałszywe. Prawda jest bardziej inżynierska i trochę mniej efektowna: nowoczesne systemy AI prawie zawsze korzystają z polyglot persistence, czyli z kilku modeli przechowywania danych naraz, gdzie każda technologia odpowiada za inny problem.

I to jest ważne nie tylko dla ludzi od data engineeringu. Dla AI Engineera też. Bo kiedy budujesz RAG, agenta, copilot dla supportu, system ekstrakcji danych z dokumentów albo semantyczne wyszukiwanie, decyzja o tym, gdzie trafiają dokumenty, metadane, embeddingi, cache, historia rozmowy i zdarzenia operacyjne, bezpośrednio wpływa na koszt, latencję, jakość odpowiedzi i łatwość utrzymania. Baza danych przestaje być tłem. Staje się częścią architektury modelu.

W tym tekście zrobimy porządek bez ściemy. Przejdziemy przez SQL, NoSQL i bazy wektorowe tak, jak naprawdę pojawiają się w pracy AI Engineera. Zobaczysz, gdzie PostgreSQL jest świetny i dlaczego pgvector bywa absurdalnie praktyczny. Zobaczysz, po co w ogóle mieć MongoDB, kiedy przecież wszyscy mówią o JSONB. Zobaczysz, dlaczego Redis jest często bardziej „AI-critical”, niż wynikałoby z marketingu wokół modeli. I wreszcie zobaczysz, kiedy dedykowana baza wektorowa ma sens, a kiedy jest po prostu drogim sposobem na uniknięcie sensownego projektu danych.

Jeśli po lekturze będziesz umiał spojrzeć na system AI i powiedzieć: „tu prawda biznesowa siedzi w SQL, tu elastyczny stan i dokumenty w NoSQL, tu szybkość daje Redis, a tu semantyka siedzi w indeksie wektorowym”, to znaczy, że osiągnęliśmy dokładnie to, co trzeba.

Dlaczego ten temat jest ważny właśnie teraz

Jeszcze dwa-trzy lata temu wiele zespołów mogło sobie pozwolić na luksus myślenia o bazie danych w projektach AI dość powierzchownie. Jeśli system był głównie proof of conceptem, wystarczał folder z plikami, prosty indeks i parę wywołań do API modelu. Problem w tym, że rynek szybko przestał nagradzać samo demo. Dziś firmy pytają nie o to, czy umiesz odpalić model, tylko czy umiesz zbudować system, który działa na prawdziwych danych, pod realnym ruchem, z sensownym kosztem, kontrolą uprawnień i jakością, którą da się obronić.

To przesuwa środek ciężkości. W systemie AI największą wartością rzadko jest sam model. Model często kupujesz jako API albo uruchamiasz jako gotowy komponent. Przewaga powstaje w danych i w architekturze dookoła danych. Skąd bierzesz kontekst? Jak filtrujesz dokumenty po tenantach i uprawnieniach? Jak synchronizujesz zmiany między źródłem prawdy a indeksem wektorowym? Jak szybko odpowiadasz na powtarzalne pytania? Jak trzymasz historię rozmowy, żeby była użyteczna, ale nie zamieniła się w śmietnik promptowy? To są pytania bazodanowe równie mocno jak AI-owe. Jeśli chcesz ten wątek domknąć od strony pipeline’ów, świeżości danych i pracy na większej skali, dobrze uzupełnia go też Data Engineering i Big Data w pracy AI Engineera.

Do tego dochodzi bardzo praktyczna zmiana techniczna. Kiedyś „baza wektorowa” była raczej niszowym elementem dla ludzi siedzących głęboko w Information Retrieval. Dziś jest częścią codziennego słownika AI Engineeringu. Embeddingi, nearest neighbor search, metadata filters, hybrid search, reranking, HNSW, cosine similarity. To już nie są egzotyczne pojęcia. Ale właśnie przez tę popularność łatwo wpaść w hype. Wystarczy parę tutoriali i człowiek zaczyna myśleć, że skoro ma vector search, to rozwiązał problem wiedzy. Nie rozwiązał. Rozwiązał najwyżej jeden etap selekcji kandydatów do odpowiedzi.

Równolegle klasyczne bazy relacyjne bardzo się wzmocniły w kontekście AI. PostgreSQL nie jest już tylko „solidną open-source’ową relacyjną bazą”. Dzięki JSONB, pełnotekstowemu wyszukiwaniu, partycjonowaniu, rozbudowanym indeksom i rozszerzeniu pgvector stał się potężnym narzędziem do budowania systemów, które chcą mieć w jednym miejscu transakcyjną prawdę biznesową i podstawowe możliwości retrievalu semantycznego. W wielu produktach to ogromna przewaga, bo nie rozbijasz architektury na pięć osobnych usług tylko dlatego, że pojawiło się słowo „AI”.

NoSQL też nie zniknął. Wręcz przeciwnie. Wraz z agentami, pamięcią rozmowy, elastycznymi strukturami dokumentów, niejednorodnymi metadanymi i zdarzeniowym przetwarzaniem danych zewnętrznych, systemy dokumentowe znowu stały się bardzo praktyczne. MongoDB dobrze czuje się tam, gdzie struktura danych zmienia się szybciej niż zespół chce robić migracje. Redis jest prawie wszędzie tam, gdzie liczy się czas odpowiedzi, cache, kolejki, sesje lub krótkie stany pośrednie. I to nie jako technologiczny folklor. Po prostu w systemach AI każda sekunda opóźnienia i każdy niepotrzebny request do modelu mają cenę.

Najważniejsze jest jednak to, że dziś mało kto buduje AI na pustym polu. Zwykle wchodzisz do firmy, która już ma backend, użytkowników, compliance, CRM, billing, logowanie zdarzeń, polityki dostępu i jakiś rodzaj historycznych danych. W takim świecie pytanie nie brzmi: „która baza jest najlepsza absolutnie?”. Brzmi: jak dobrać warstwy danych tak, żeby AI realnie współpracowało z istniejącym systemem, a nie było osobną wyspą z ładnym demo i słabym utrzymaniem.

Od podstaw: jak myśleć o SQL, NoSQL i bazach wektorowych w jednym systemie

Najprostszy błąd początkujący brzmi: trzeba wybrać jedną bazę. To jest odruch zrozumiały, bo w klasycznych projektach często dało się długo jechać na jednej relacyjnej bazie i to miało sens. W systemach AI dużo częściej sprawdza się myślenie warstwowe. Nie „jedna baza do wszystkiego”, tylko „jaki rodzaj danych mam i jakiego zachowania od tej warstwy potrzebuję”.

Mówiąc brutalnie: transakcja to nie to samo co pamięć rozmowy, pamięć rozmowy to nie to samo co cache, a cache to nie to samo co indeks semantyczny. Każda z tych rzeczy ma inną naturę. Jeśli wrzucisz je do jednego worka tylko po to, żeby mieć mniej komponentów, prędzej czy później system zacznie ci oddawać ten dług z odsetkami.

Dobra zasada na start: relacyjna baza trzyma fakty biznesowe, NoSQL trzyma elastyczny stan i dokumenty, Redis trzyma szybkość, a indeks wektorowy trzyma podobieństwo znaczeniowe. Pomyłka ról jest droższa niż sam wybór technologii.

SQL: gdzie powinna mieszkać prawda biznesowa

SQL i relacyjne bazy danych nadal są absolutnie podstawowe wszędzie tam, gdzie masz dane o jasno określonych relacjach, wymagania dotyczące spójności i potrzebę mocnego modelu zapytań. Dla AI Engineera oznacza to zwykle takie rzeczy jak użytkownicy, organizacje, uprawnienia, dokumenty źródłowe, wersje treści, zdarzenia systemowe, rekordy workflow, billing, audyt i wszystkie te byty, które muszą być prawdziwe nie „mniej więcej”, tylko naprawdę.

Dlatego PostgreSQL jest tak częstym wyborem. Łączy rzeczy, które w praktyce AI są wyjątkowo cenne: dojrzały model transakcyjny, bardzo mocny SQL, rozbudowane indeksy, JSONB do półustrukturyzowanych danych i możliwość dołożenia pgvector bez budowania osobnego świata technologicznego. To jest ten typ nudnej mocy, który w produkcji wygrywa częściej niż nowość z dobrym landing page’em.

Jeśli budujesz system RAG dla supportu, to w PostgreSQL bardzo naturalnie trzymasz rekord dokumentu, tenant, właściciela, wersję, status publikacji, powiązane tagi, daty aktualizacji, reguły dostępu i powiązanie z chunkami. Dzięki temu masz jeden spójny model danych dla biznesu i retrievalu. Możesz JOIN-ować wyniki wektorowe z realnymi bytami systemu, filtrować po klientach, produktach i językach, kontrolować widoczność treści na poziomie danych, a nie tylko na poziomie promptu. To ogromna różnica.

Krótki przykład pokazujący sens takiego układu wygląda tak:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id bigserial PRIMARY KEY,
  tenant_id uuid NOT NULL,
  title text NOT NULL,
  source_type text NOT NULL,
  status text NOT NULL,
  metadata jsonb NOT NULL DEFAULT '{}'::jsonb,
  created_at timestamptz NOT NULL DEFAULT now(),
  updated_at timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE document_chunks (
  id bigserial PRIMARY KEY,
  document_id bigint NOT NULL REFERENCES documents(id) ON DELETE CASCADE,
  chunk_no integer NOT NULL,
  content text NOT NULL,
  embedding vector(1536) NOT NULL,
  metadata jsonb NOT NULL DEFAULT '{}'::jsonb
);

Ten model jest prosty, ale ma bardzo ważną zaletę: dokument jako byt biznesowy i chunk jako byt retrievalowy nie są tym samym, ale żyją blisko siebie. Dzięki temu łatwiej zachować spójność. Kiedy dokument znika, zmienia status albo tenant traci do niego dostęp, możesz wykonać jawne operacje na pochodnych rekordach zamiast liczyć, że osobna baza wektorowa „jakoś się dowie”.

Warto też pamiętać, że SQL daje coś, czego wiele zespołów AI potrzebuje, a późno to zauważa: potężne możliwości analityczne i diagnostyczne. CTE, window functions, sensowne JOIN-y, agregacje i filtrowanie zdarzeń pozwalają nie tylko budować produkt, ale też rozumieć jego zachowanie. Które dokumenty są najczęściej zwracane? Jakie pytania kończą się fallbackiem? Które tenanty mają największy wolumen odwołań do wiedzy? To są pytania, na które relacyjna baza odpowiada bardzo dobrze.

PostgreSQL i pgvector: absurdalnie praktyczny duet

Wokół pgvector pojawia się sporo emocji, bo to rozszerzenie bardzo skutecznie psuje prosty marketing dedykowanych baz wektorowych. Nagle okazuje się, że w jednej instancji PostgreSQL możesz trzymać dokumenty, metadane, prawa dostępu i embeddingi, a do tego robić wektorowe ORDER BY po odległości i budować indeksy HNSW. Dla wielu projektów to wystarcza na bardzo długo.

Przykład wyszukiwania podobnych chunków jest wręcz zaskakująco prosty:

CREATE INDEX document_chunks_embedding_hnsw
ON document_chunks USING hnsw (embedding vector_cosine_ops);

WITH nearest AS (
  SELECT
    dc.document_id,
    dc.content,
    dc.metadata,
    dc.embedding <=> $1 AS distance
  FROM document_chunks dc
  WHERE dc.metadata @> '{"lang":"pl"}'
  ORDER BY dc.embedding <=> $1
  LIMIT 20
)
SELECT d.title, nearest.content, nearest.distance
FROM nearest
JOIN documents d ON d.id = nearest.document_id
WHERE d.tenant_id = $2
  AND d.status = 'published'
ORDER BY nearest.distance
LIMIT 5;

I tu jest sedno. Sama operacja wektorowa to tylko część zapytania. Reszta to klasyczny SQL, który pilnuje, żebyś szukał tylko w odpowiednim tenantcie, tylko po opublikowanych treściach, tylko w konkretnym języku albo produkcie. W praktyce właśnie to zwykle decyduje o jakości produktu bardziej niż sama liczba wymiarów embeddingu.

Czy pgvector jest rozwiązaniem na wszystko? Nie. Gdy masz dziesiątki albo setki milionów wektorów, bardzo wysoką częstotliwość aktualizacji, rozbudowane wymagania dotyczące replikacji retrievalu, osobne profile indeksów dla wielu kolekcji i bardzo wyśrubowane oczekiwania czasowe, dedykowana baza wektorowa może być lepsza. Ale ogromna liczba projektów AI w realnych firmach wcale nie jest na tym etapie. One potrzebują prostoty architektury, spójności danych i możliwości sensownego rozwoju. Właśnie dlatego PostgreSQL + pgvector tak często okazuje się wyborem nie modnym, tylko po prostu mądrym.

MongoDB: kiedy dokument jest naprawdę dokumentem, a nie źle zamodelowanym SQL-em

MongoDB ma ciekawą pozycję w rozmowie o AI. Z jednej strony wiele jego dawnych przewag przejął PostgreSQL z JSONB. Z drugiej strony nadal są przypadki, w których dokumentowy model danych jest po prostu naturalniejszy. Jeśli przechowujesz historię rozmowy, stan agenta, złożone wyniki ekstrakcji z dokumentów, konfiguracje workflow, struktury zależne od typu źródła albo półustrukturyzowane metadane, których kształt szybko się zmienia, MongoDB potrafi być bardzo wygodne.

Dobra intuicja jest taka: jeśli twoja aplikacja regularnie pracuje na obiektach, które są bardziej „samodzielnym dokumentem z własnym życiem” niż zestawem ściśle znormalizowanych relacji, MongoDB może przyspieszyć pracę. To szczególnie widać przy agentach i conversational AI. Jedna sesja może mieć wiadomości, streszczenia pośrednie, listę wykonanych narzędzi, snapshot stanu, feedback użytkownika, różne typy załączników i metadane zależne od integracji. Da się to zamodelować relacyjnie. Pytanie brzmi: czy warto, jeśli produkt zmienia się co tydzień?

Przykład aktualizacji stanu rozmowy w stylu dokumentowym wygląda bardzo naturalnie:

db.conversations.updateOne(
  { _id: conversationId },
  {
    $push: {
      messages: {
        role: "user",
        content: userMessage,
        createdAt: new Date(),
      },
    },
    $set: {
      lastActivityAt: new Date(),
      modelProfile: "support-agent-v3",
      retrievalContext: latestContext,
    },
  },
  { upsert: true },
);

To jest czytelne, szybkie w iteracji i dobrze pasuje do systemów, gdzie schemat ewoluuje razem z produktem. Ale tu też jest pułapka: dokumentowość nie zwalnia z myślenia o granicach. Jeśli wszystko wrzucisz do jednego gigantycznego dokumentu rozmowy, w końcu zderzysz się z rozmiarem, konkurencyjnymi zapisami, problemami archiwizacji i kosztami odczytu. MongoDB działa świetnie, gdy dokument ma sens jako jednostka życia danych. Działa gorzej, gdy próbujesz nim zamaskować brak decyzji modelujących.

Redis: najszybsza warstwa systemu i najczęściej niedoceniany bohater AI

Jeśli ktoś mówi, że w jego systemie AI najważniejsze są model i baza wektorowa, a nie wspomina o cache’u, to często znaczy, że jeszcze nie miał prawdziwego ruchu albo prawdziwych rachunków. Redis jest w aplikacjach AI niesamowicie praktyczny, bo rozwiązuje kilka problemów naraz: przechowuje szybkie stany sesji, służy jako cache odpowiedzi lub pośrednich wyników, potrafi robić za lekką kolejkę, pomaga w rate limiting i odciąża drogie komponenty systemu.

Najbardziej oczywisty use case to cache. Jeżeli użytkownicy regularnie zadają podobne pytania, nie chcesz za każdym razem wykonywać pełnego retrievalu i wywołania dużego modelu. Czasem wystarczy klasyczny cache po znormalizowanym kluczu. Czasem, jeśli pytania są podobne semantycznie, wchodzi semantic caching. Idea jest prosta: jeśli nowe pytanie jest bardzo podobne do pytania już rozwiązanego, system może zwrócić wcześniejszą odpowiedź albo przynajmniej użyć jej jako shortcutu.

Najprostsza wersja stanu sesji w Redisie wygląda tak:

import json

session_key = f"chat:session:{session_id}"

redis.setex(
    session_key,
    3600,
    json.dumps(
        {
            "last_user_message": user_message,
            "tool_trace": tool_trace,
            "active_profile": "billing-assistant"
        }
    ),
)

To jest bardzo przyziemne, ale przyspiesza produkt dokładnie tam, gdzie użytkownik to czuje. Redis świetnie sprawdza się też jako warstwa krótkotrwałej pamięci dla agentów: trzymasz tam checkpointy, stan workflow, wyniki pośrednich narzędzi albo status asynchronicznego przetwarzania. Nie dlatego, że Redis jest „AI-native”. Po prostu jest szybki i tani operacyjnie tam, gdzie dane nie muszą być wieczne.

Warto też wspomnieć o Redis Streams i o możliwościach Redis Stack, w tym wyszukiwaniu wektorowym. Czy to znaczy, że Redis zastąpi ci pełnoprawną bazę wektorową? Czasem dla prostych przypadków. Częściej jednak wygrywa jako warstwa pomocnicza: cache, sesje, eventy, rate limiting, krótka pamięć, czasem lekka pamięć semantyczna dla bardzo szybkich odczytów.

Baza wektorowa: nie źródło prawdy, tylko indeks znaczenia

To jest chyba najważniejsze rozróżnienie całego artykułu. Baza wektorowa nie jest zwykle miejscem, w którym powinna mieszkać prawda biznesowa. Jest miejscem, w którym przechowujesz pochodną reprezentację treści potrzebną do wyszukiwania semantycznego. To trochę jak indeks pełnotekstowy, tylko oparty o embeddingi, metryki odległości i techniki approximate nearest neighbor.

Dlaczego to takie ważne? Bo jeśli zaczniesz traktować bazę wektorową jak centralny system rekordów, bardzo szybko trafisz w problemy z wersjonowaniem, uprawnieniami, audytem i synchronizacją. Dokument źródłowy zmienia się w SQL albo w obiektowym magazynie, ktoś aktualizuje status, usuwa treść, zmienia tenant, a indeks wektorowy dalej spokojnie przechowuje starą wersję chunków. Nagle system odpowiada na podstawie treści, której już nie powinien znać. To nie jest abstrakcja. To bardzo realna awaria projektowa. W praktyce ten temat bardzo szybko zahacza też o kontrolę dostępu, data leakage i bezpieczeństwo całego workflow, co szerzej rozkładam w tekście o bezpieczeństwie AI i cybersecurity bez ściemy.

Dlatego bezpieczniejszy model myślenia brzmi: baza wektorowa przechowuje indeks powiązany z dokumentem źródłowym, a nie samodzielne uniwersum prawdy. Kluczem jest spójny identyfikator, jawna synchronizacja i możliwość rekalkulacji indeksu wtedy, gdy zmienia się źródło, embedding model albo strategia chunkingu.

Głębsze niuanse: jak to naprawdę działa pod spodem

Dobra, to teraz ta część, w której większość tutoriali robi szybki skrót i udaje, że wszystko jest łatwe. Nie jest. To, że potrafisz zapisać embedding i wykonać ORDER BY distance LIMIT 5, nie znaczy jeszcze, że masz dobry system retrievalu. Pod spodem dzieje się kilka rzeczy naraz: indeksowanie, filtrowanie, synchronizacja, kompromisy między dokładnością a szybkością i klasyczny problem danych pochodnych, które bardzo lubią się starzeć.

Indeksy w SQL: B-tree, GIN, GiST i dlaczego to nadal ma znaczenie

Zacznijmy od rzeczy pozornie mało sexy. W systemie AI nawet jeśli kluczową nowością są embeddingi, to ogrom pracy robią nadal klasyczne indeksy. B-tree odpowiada za typowe filtry i sortowania po identyfikatorach, datach, tenantach czy statusach. GIN świetnie działa z JSONB i pełnotekstowym wyszukiwaniem. GiST ma swoje miejsce przy danych przestrzennych i niektórych typach zaawansowanych indeksów. Jeśli używasz JSONB do metadanych dokumentów, ale nie zbudujesz rozsądnych indeksów, to vector search szybko przestanie być problemem numer jeden. Problemem stanie się powolne filtrowanie wszystkiego wokół niego.

To ważne zwłaszcza przy RAG-u wielotenantowym. Sam embedding nie wystarczy. Najpierw musisz zawęzić przestrzeń dokumentów do tych, które użytkownik w ogóle ma prawo zobaczyć. Często oznacza to filtry po tenantcie, produkcie, typie dokumentu, języku, statusie publikacji albo zakresie czasowym. Bez tego system może znaleźć semantycznie idealny dokument, który jednocześnie jest niedozwolony lub nieaktualny. Czyli znaleźć technicznie dobrze i biznesowo fatalnie.

pgvector, HNSW i ANN: dlaczego szybkie szukanie jest przybliżone z definicji

Wyszukiwanie wektorowe przy większej skali prawie nigdy nie jest naiwnym porównywaniem każdego wektora z każdym. To byłoby zbyt wolne. Dlatego stosuje się approximate nearest neighbor, czyli techniki, które znajdują bardzo dobrych kandydatów szybko, ale nie zawsze dają matematycznie idealny top-k. To ważne, bo dużo ludzi przez przypadek traktuje wyniki wektorowe jak coś absolutnego. A one są wynikiem algorytmu optymalizującego kompromis między szybkością a dokładnością.

W świecie pgvector najczęściej spotkasz HNSW i czasem IVFFlat. HNSW, czyli Hierarchical Navigable Small World, to struktura grafowa, która bardzo dobrze sprawdza się w szybkich zapytaniach po podobieństwie. W praktyce często bywa domyślnym sensownym wyborem. IVFFlat z kolei grupuje wektory w klastry i też przyspiesza wyszukiwanie, ale ma inne kompromisy jakościowe i konfiguracyjne. Dla AI Engineera ważniejsze od teorii algorytmów jest zrozumienie jednej rzeczy: to nie jest dokładne skanowanie całego świata, tylko pragmatyczne szukanie dobrych kandydatów w dużym zbiorze.

I tu zaczyna się robić ciekawie. Jeśli twój chunking jest słaby, embedding model źle dobrany, a metadane nieprzemyślane, to żaden indeks HNSW cię nie uratuje. On tylko szybciej znajdzie złych kandydatów. To trochę jak bardzo wydajny system kolejkowy, który perfekcyjnie rozprowadza zły payload. Wydajność nie naprawia złej reprezentacji problemu.

Embedding to reprezentacja, nie wyrok

Bardzo warto pamiętać, że embedding nie jest „obiektywną prawdą o znaczeniu tekstu”. To wynik konkretnego modelu embeddingowego. Dwa modele mogą inaczej rozkładać przestrzeń podobieństwa. Ten sam dokument po zmianie modelu może mieć inny układ sąsiedztw. Dlatego przy każdej zmianie embedding modelu wchodzisz de facto w zmianę indeksu i zachowania retrievalu. To nie jest kosmetyka. To jest nowa wersja ważnej warstwy systemu.

Dotyczy to szczególnie polskiego i wielojęzycznych zastosowań. Model świetny na benchmarkach angielskich niekoniecznie będzie równie dobry w dokumentacji po polsku z mieszanką słów branżowych, skrótów i nazw własnych. W praktyce bardzo często większą różnicę robi dobrze dobrany embedding model plus sensowne metadane niż przeskok z jednej bazy wektorowej na drugą.

Synchronizacja: najbardziej niedoceniany problem całego stacku

Jeśli miałbym wskazać jedną rzecz, którą zespoły AI regularnie lekceważą, byłaby to synchronizacja między źródłem danych a warstwą retrievalu. Dokument zmienia treść? Musisz przeliczyć chunki i embeddingi. Dokument zmienia uprawnienia? Musisz upewnić się, że stary indeks nie wypuści go w wynikach. Usuwasz rekord? Musisz usunąć albo oznaczyć wszystkie pochodne wpisy. Zmieniasz strategię chunkingu? Musisz przebudować indeks, bo poprzednie granice chunków przestały odpowiadać nowemu modelowi myślenia o dokumencie.

To jest klasyczny problem danych pochodnych. Tyle że w AI koszt niespójności bywa zdradliwy, bo system nie wybucha błędem. On odpowiada płynnie i przekonująco na podstawie złych albo starych danych. Dlatego sensowna architektura ingestionu zwykle ma jawne identyfikatory wersji, kolejkę reindeksacji, idempotentne upserty i możliwość pełnej przebudowy indeksu bez chaosu.

W praktyce bardzo rozsądny wzorzec wygląda tak: źródło prawdy trzymasz w relacyjnej bazie albo obiektowym storage, zapis zmian emituje zdarzenie, worker chunkingu i embeddingów tworzy pochodne rekordy, a indeks wektorowy przechowuje odwołanie do wersji dokumentu. Dzięki temu możesz potem powiedzieć nie tylko „to jest wynik podobny semantycznie”, ale też „to jest wynik oparty o wersję dokumentu X z dnia Y”. To robi ogromną różnicę przy audycie i debugowaniu jakości.

Hybrid search i reranking: bo same wektory rzadko wystarczają

Większość realnych systemów AI nie działa dziś na czystym dense retrieval. Zbyt często potrzebujesz połączenia semantyki z klasycznym wyszukiwaniem po słowach kluczowych. Użytkownik pyta o „błąd 502 z gatewaya”, „numer procedury FIN-14”, „parametr customer_tier” albo nazwę konkretnego endpointu. W takich przypadkach wektory są przydatne, ale BM25, pełnotekst, filtrowanie po tagach i zwykłe exact-match potrafią być równie ważne.

Stąd bierze się hybrid search. Łączysz sygnał wektorowy z klasycznym wyszukiwaniem i dopiero potem robisz reranking mocniejszym modelem, który ocenia, które fragmenty naprawdę odpowiadają na pytanie. W praktyce to bardzo produkcyjne podejście, bo poprawia zarówno recall, jak i precision. I znowu: nie chodzi o to, żeby mieć najbardziej futurystyczny komponent, tylko żeby wyniki były trafne. A jeśli chcesz to później mierzyć zamiast ufać intuicji, zobacz też RAG Evals i RAGAS Metrics.

Kiedy PostgreSQL + pgvector wystarcza, a kiedy lepiej iść w dedykowaną bazę wektorową

To pytanie wraca bez końca, więc warto odpowiedzieć uczciwie. Jeśli masz małą lub średnią skalę, chcesz prostszej architektury, potrzebujesz ścisłego połączenia z danymi biznesowymi i nie chcesz mnożyć komponentów bez powodu, PostgreSQL + pgvector jest często świetnym wyborem. Szczególnie gdy retrieval jest tylko jedną warstwą większego systemu, a nie centralnym silnikiem firmy.

Dedykowana baza wektorowa zaczyna wygrywać wtedy, gdy retrieval jest sam w sobie dużym problemem infrastrukturalnym. Na przykład masz bardzo duży wolumen wektorów, wiele kolekcji, złożone polityki shardingu, niezależne skalowanie warstwy semantycznej, zaawansowane payload filters, replikację nastawioną pod search i wysoką częstotliwość aktualizacji. Wtedy narzędzia takie jak Qdrant, Weaviate, Pinecone czy Milvus potrafią dać przewagę operacyjną.

Ale uwaga: wiele zespołów próbuje „rozwiązać jakość retrievalu” zmianą silnika, gdy prawdziwy problem siedzi w chunkingu, embeddingach, filtrach albo złym zdefiniowaniu źródła prawdy. To trochę jak wymiana bazy danych przy problemie, który tak naprawdę bierze się z kiepskiego modelu danych. Czasem silnik jest winny. Bardzo często jednak nie on.

Praktyczne zastosowania i przykłady z życia

Teoria teorią, ale dopiero konkretne układy technologiczne pokazują, po co cały ten podział. Zobaczmy trzy bardzo typowe use-case’y z pracy AI Engineera.

Use case 1: asystent supportu na PostgreSQL, pgvector i Redisie

To jeden z najbardziej praktycznych wzorców. Masz system supportowy, dokumentację operacyjną, historię incydentów i dane klienta. Chcesz, żeby agent AI potrafił odpowiedzieć na pytania konsultanta, podać źródła i zasugerować kolejne kroki. W takim układzie PostgreSQL trzyma użytkowników, tenanty, dokumenty źródłowe, historię wersji, tagi, uprawnienia i chunki. pgvector indeksuje embeddingi chunków. Redis przechowuje stan sesji, krótkie wyniki narzędzi i cache powtarzalnych odpowiedzi.

To działa dobrze, bo wszystkie krytyczne byty biznesowe siedzą w jednej bazie transakcyjnej. Możesz zrobić retrieval tylko dla dokumentów opublikowanych dla konkretnego klienta, połączyć wynik z danymi CRM i jeszcze policzyć, które odpowiedzi są najczęściej akceptowane przez konsultantów. Redis odciąża warstwę modelu tam, gdzie nie ma sensu liczyć wszystkiego od nowa.

Przepływ jest zwykle bardzo prosty. Użytkownik zadaje pytanie, system sprawdza w Redisie, czy podobna odpowiedź nie jest już świeżo wyliczona. Jeśli nie, generuje embedding pytania, robi wektorowy search w pgvector, filtruje po tenantcie i statusie dokumentów, składa prompt, wywołuje model, a wynik buforuje na krótko. Brzmi zwyczajnie? Właśnie o to chodzi. Produkcyjne systemy wygrywają nudą.

Warstwa aplikacyjna może wyglądać tak:

async def answer_support_question(question: str, tenant_id: str, session_id: str):
    cache_key = f"answer:{tenant_id}:{normalize(question)}"
    cached = await redis.get(cache_key)
    if cached:
        return json.loads(cached)

    query_embedding = embed(question)
    rows = await pg.fetch(
        """
        WITH nearest AS (
          SELECT document_id, content, embedding <=> $1 AS distance
          FROM document_chunks
          ORDER BY embedding <=> $1
          LIMIT 12
        )
        SELECT d.title, n.content, n.distance
        FROM nearest n
        JOIN documents d ON d.id = n.document_id
        WHERE d.tenant_id = $2
          AND d.status = 'published'
        ORDER BY n.distance
        LIMIT 6
        """,
        query_embedding,
        tenant_id,
    )

    answer = await llm_answer(question, rows)
    await redis.setex(cache_key, 300, json.dumps(answer))
    return answer

Ten kod nie jest „magiczny”. I właśnie dlatego jest dobry jako przykład. Pokazuje, że AI aplikacja to zwykle kompozycja kilku bardzo zwyczajnych decyzji: dobra baza źródłowa, retrieval blisko danych, krótki cache i model na końcu, nie na początku.

Use case 2: agent operacyjny z elastycznym stanem w MongoDB

Drugi scenariusz to agent, który wykonuje dłuższe workflow: zbiera dane z kilku narzędzi, trzyma ślady działań, ma checkpointy, może wznowić pracę po przerwaniu i przechowuje różne typy wyników. Tu często MongoDB jest bardzo wygodne, bo stan jednej sesji albo jednego zadania faktycznie jest dokumentem z własnym życiem. Masz wiadomości, plan, wykonane kroki, wyniki API, załączniki, oceny pośrednie i metadata zależne od typu narzędzia.

Oczywiście nadal nie chcesz trzymać wszystkiego tylko w Mongo. Fakty biznesowe i twarde identyfikatory użytkowników mogą spokojnie siedzieć w SQL. Ale dla stanu samego agenta dokumentowy model bywa bardzo naturalny. Zespół nie musi robić migracji przy każdej zmianie kształtu pamięci sesji. To przyspiesza iterację, a w agentowych systemach iteracja naprawdę się liczy.

Krótki przykład pobrania ostatnich aktywnych dokumentów wiedzy do rozszerzenia kontekstu może wyglądać tak:

db.knowledge_docs
  .find(
    {
      product: "billing",
      status: "active",
      "metadata.lang": "pl",
    },
    {
      projection: {
        title: 1,
        version: 1,
        summary: 1,
        tags: 1,
      },
    },
  )
  .sort({ version: -1 })
  .limit(5);

W praktyce MongoDB świetnie sprawdza się też jako miejsce, w którym przechowujesz wyniki parsowania niestandardowych dokumentów wejściowych albo półustrukturyzowane profile źródeł. Na przykład jeden dokument pochodzi z PDF-a, drugi z CRM-a, trzeci z webhooka partnera i każdy ma trochę inny zestaw pól. W SQL da się to zmieścić, ale dokumentowy model bywa zwyczajnie wygodniejszy.

Ograniczenie jest jedno i trzeba o nim mówić wprost: MongoDB nie zwalnia z projektowania. Jeśli dokumenty agentów zaczynają puchnąć bez kontroli, to zamiast zyskać elastyczność, dostajesz tylko trudniej diagnozowalny bałagan.

Use case 3: semantyczne wyszukiwanie produktów i wiedzy na dedykowanej bazie wektorowej

Trzeci scenariusz to sytuacja, w której retrieval sam w sobie jest krytyczną usługą. Masz dużo treści, wiele kolekcji, intensywne zapytania, złożone filtry i potrzebę niezależnego skalowania warstwy semantycznej. Wtedy dedykowana baza wektorowa bywa uzasadniona. Załóżmy, że budujesz platformę AI dla wielu klientów, każdy klient ma własną bazę wiedzy, własne dokumenty, własne uprawnienia i wysokie oczekiwania co do czasu odpowiedzi. Tu systemy takie jak Qdrant czy Weaviate zaczynają błyszczeć.

Przykład zapytania w Qdrancie pokazuje, o co chodzi:

from qdrant_client import QdrantClient, models

client = QdrantClient(url=qdrant_url, api_key=qdrant_api_key)

hits = client.query_points(
    collection_name="incident_docs",
    query=query_embedding,
    query_filter=models.Filter(
        must=[
            models.FieldCondition(
                key="tenant_id",
                match=models.MatchValue(value=tenant_id),
            ),
            models.FieldCondition(
                key="product",
                match=models.MatchValue(value="billing"),
            ),
        ]
    ),
    limit=8,
)

Z punktu widzenia produktu nie chodzi tu o samą egzotykę silnika. Chodzi o to, że warstwa semantyczna jest samodzielnie skalowalna, ma rozbudowane payload filters, lepiej znosi bardzo duże kolekcje i potrafi być centralną usługą retrievalu dla wielu aplikacji jednocześnie. Nadal jednak dobrze jest trzymać źródło prawdy i krytyczne metadane w SQL albo storage źródłowym. Baza wektorowa ma ci pomóc znaleźć kandydatów do odpowiedzi, nie przejąć odpowiedzialność za pełny model domeny.

Redis w aplikacjach AI: jeszcze jeden przykład, który naprawdę oszczędza pieniądze

Warto dorzucić czwarty, krótszy przykład, bo Redis zasługuje na więcej niż rolę „jakiegoś cache’a obok”. Wyobraź sobie system, w którym użytkownicy regularnie pytają o te same rzeczy różnymi słowami: „jak zresetować API key”, „jak wygenerować nowy klucz”, „gdzie odświeżyć token do integracji”. Semantycznie to prawie to samo. Jeśli za każdym razem wykonujesz pełen retrieval i pełne generowanie, płacisz za tę samą pracę kilka razy.

Tu wchodzi semantic cache. Możesz zapisać odpowiedź wraz z embeddingiem pytania i przy kolejnym zapytaniu najpierw sprawdzić, czy podobny problem nie był już rozwiązany. Nie musi to dawać 100% trafień, żeby miało sens. Wystarczy, że urwiesz część powtarzalnego ruchu. W systemach z dużą liczbą FAQ to realnie obniża koszt i poprawia czas odpowiedzi.

Typowe błędy i pułapki

Pierwsza pułapka jest bardzo modna: traktowanie bazy wektorowej jak cudownego zamiennika modelowania danych. Większość ludzi myśli: skoro użytkownik zadaje pytania naturalnym językiem, to wystarczy wrzucić wszystko do embeddingów i problem znika. Nie znika. Wektor mówi ci, co jest podobne semantycznie. Nie mówi, co jest aktualne, dozwolone, oficjalne, rozstrzygające albo ważniejsze biznesowo. Bez dobrej warstwy metadanych, filtrów i źródła prawdy retrieval bardzo szybko zaczyna zwracać rzeczy „prawie dobre”, a to w AI jest szczególnie zdradliwe.

Druga pułapka to wrzucanie całego elastycznego stanu do MongoDB tylko dlatego, że „JSON jest wygodny”. Jest wygodny. Pytanie, czy nadal będzie, gdy trzeba zrobić audyt, policzyć zależności, dołożyć silne reguły spójności i zacząć aktualizować wiele dokumentów naraz. Dokumentowy model ma sens tam, gdzie dokument naprawdę jest jednostką życia danych. Jeśli używasz go do maskowania niechęci do modelowania relacji, płacisz później w debugowaniu.

Trzecia pułapka to traktowanie Redisa jak trwałej bazy danych dla rzeczy, które nie mogą zniknąć. Redis jest świetny do szybkości, ale właśnie dlatego trzeba go używać świadomie. TTL, polityki eviction, limity pamięci, hot keys, odporność na restart. To nie są szczegóły. To są parametry architektury. Jeśli trzymasz w Redisie coś, czego utrata rozwala proces biznesowy, to nie masz sprytnej architektury. Masz hazard.

Czwarta pułapka jest najbardziej podstępna: brak strategii synchronizacji między źródłem a indeksem. Dokument zmienia treść, a embedding zostaje stary. Uprawnienie znika, a retriever nadal to zwraca. Model embeddingowy się zmienia, a ty porównujesz nowe wektory ze starym indeksem. To nie daje efektu „mało idealnego”. To daje semantycznie błędny system, który brzmi wiarygodnie. Czyli najgorszy rodzaj błędu.

Piąta pułapka to zbyt wiara w sam silnik. Zespoły potrafią tygodniami porównywać Qdrant do Weaviate albo pgvector do Pinecone, podczas gdy prawdziwy problem siedzi w chunkingu, kiepskich metadanych, braku hybrid search albo w tym, że pytania użytkowników wymagają zwykłego exact-match po identyfikatorach. Mówiąc wprost: większość tutoriali o bazach wektorowych trochę kłamie, bo sugeruje, że kluczowym wyborem jest vendor. W praktyce kluczowe są reprezentacja treści, filtry i jakość pipeline’u.

Ecosystem i narzędzia, które warto znać

Ekosystem wokół danych dla AI bardzo dojrzał i dziś problemem nie jest brak narzędzi, tylko sensowny wybór. Warto znać kilka grup rozwiązań i rozumieć ich charakter, nie w formie fanbojskiego rankingu, tylko pragmatycznej mapy.

PostgreSQL pozostaje jednym z najmocniejszych wyborów produkcyjnych, szczególnie gdy chcesz łączyć dane biznesowe z retrievalem. Do tego dochodzi pgvector dla embeddingów, PgBouncer dla connection poolingu i cały klasyczny ekosystem sterowników oraz ORM-ów, jak psycopg, asyncpg, SQLAlchemy czy Django ORM. To jest produkcyjnie sprawdzone, nudne i bardzo skuteczne.

MongoDB ma sens tam, gdzie dokumentowy model naprawdę odpowiada naturze danych. W praktyce najczęściej spotkasz PyMongo, Motor przy async Pythonie i oczywiście MongoDB Atlas, jeśli zespół nie chce sam zarządzać klastrem. Atlas ma też własne funkcje searchowe i wektorowe, które w niektórych projektach potrafią uprościć architekturę, choć nadal warto uważać, by nie zamienić tego w technologiczną zupę bez jasnych granic odpowiedzialności.

Redis to cały osobny świat. Klasyczny redis-py, Redis Stack, Redis Streams, rate limiting, cache, krótkie workflow state, semantyczny cache. Produkcyjnie Redis jest bardzo sprawdzony, ale wymaga dyscypliny: monitoringu pamięci, świadomych TTL-i, polityki usuwania i ostrożności przy dużych payloadach.

W świecie dedykowanych baz wektorowych najczęściej przewijają się dziś takie nazwy:

• Qdrant: bardzo mocny, open-source’owy, pragmatyczny wybór do payload filters i produkcyjnego retrievalu.
• Weaviate: dobry tam, gdzie chcesz bogatszy ekosystem i trochę bardziej „platformowe” podejście do danych semantycznych.
• Pinecone: wygodny managed service, szczególnie gdy zespół chce szybko ruszyć bez własnego opsu, ale trzeba uważać na koszt przy skali.
• Milvus/Zilliz: sensowne przy większej skali i bardziej wyspecjalizowanych zastosowaniach retrievalowych.
• pgvector: nie osobna platforma, tylko bardzo praktyczny wybór dla ogromnej klasy normalnych projektów AI.

Ważne jest też to, co jest hype’em, a co jest sprawdzone produkcyjnie. Produkcyjnie sprawdzone są dziś na pewno: PostgreSQL, Redis, MongoDB w sensownych rolach, pgvector, Qdrant, Pinecone i szeroko rozumiane podejście hybrydowe do retrievalu. Hype pojawia się zwykle tam, gdzie ktoś próbuje sprzedać sam silnik jako rozwiązanie jakości odpowiedzi. Nie jest. Silnik jest ważny, ale bez dobrego modelu danych, ingestionu, metadanych, reindeksacji i ewaluacji retrievalu nie zrobi z projektu cudu.

Jeśli miałbym dać jedną praktyczną radę: zacznij od technologii, które twój zespół umie utrzymać, a nie od tych, które najlepiej wyglądają na slajdzie architektonicznym. Baza danych, do której nikt nie chce wejść po godzinach, kiedy trzeba zdiagnozować problem z retrievalem, jest słabym wyborem niezależnie od benchmarku.

Podsumowanie i co dalej

Najważniejsza rzecz do zapamiętania jest prosta i jednocześnie bardzo uwalniająca: w systemach AI prawie nigdy nie chodzi o wybór jednej „najlepszej” bazy danych. Chodzi o dobranie warstw do rodzaju danych i rodzaju odpowiedzialności. SQL wygrywa tam, gdzie masz prawdę biznesową, relacje, spójność i potrzebę mocnych zapytań. NoSQL wygrywa tam, gdzie stan jest elastyczny, dokumenty żyją własnym życiem, a schemat zmienia się razem z produktem. Redis wygrywa wszędzie tam, gdzie liczy się szybkość, krótkie stany, cache i odciążenie drogiego ruchu do modeli. Bazy wektorowe wygrywają w wyszukiwaniu semantycznym, ale tylko wtedy, gdy pamiętasz, że są indeksem znaczenia, a nie nowym źródłem prawdy o świecie.

Jeśli spojrzysz na to w ten sposób, wiele architektonicznych sporów przestaje mieć sens. PostgreSQL kontra MongoDB? To często źle postawione pytanie. pgvector kontra dedykowany vector DB? Też bywa źle postawione, jeśli nie znasz swojej skali, rodzaju filtrów i wymagań operacyjnych. Prawdziwe pytania brzmią raczej tak: gdzie mieszkają fakty, gdzie mieszkają pochodne reprezentacje, co musi być transakcyjnie spójne, co może być elastyczne, co ma być błyskawiczne, a co ma dawać dobry recall i precision w retrievalu.

W pracy AI Engineera to podejście daje ogromną przewagę, bo przestajesz myśleć o danych jak o zapleczu modelu, a zaczynasz myśleć o nich jak o części mechaniki całego systemu. To właśnie tu wygrywa się produkcję. Nie samym modelem, tylko tym, że model dostaje właściwy kontekst z właściwych źródeł, w odpowiednim czasie i z odpowiednimi ograniczeniami. Mówiąc jeszcze prościej: dobra architektura danych jest dla AI tym, czym dobra architektura API dla backendu. Nie robi najgłośniejszego wrażenia na demo, ale bez niej wszystko zaczyna się chwiać.

Jeśli chcesz ten temat naprawdę poczuć, zrób sobie jedno konkretne ćwiczenie. Zbuduj małego RAG-a na własnych notatkach albo dokumentacji projektu. Trzymaj dokumenty i metadane w PostgreSQL, embeddingi w pgvector, krótkie odpowiedzi w Redisie, a jeśli chcesz pobawić się stanem sesji albo pamięcią agenta, dorzuć MongoDB do jednego wybranego workflow. Dopiero przy takim małym, ale prawdziwym projekcie zobaczysz, gdzie kończy się teoria typu „ta baza jest lepsza”, a zaczyna praktyka typu „ta warstwa ma tu sens, bo dokładnie ten problem rozwiązuje”. I to jest już poziom myślenia, który bardzo szybko odróżnia osobę robiącą tutoriale od inżyniera, który potrafi dowieźć system.