Kako izgraditi RAG pipeline s PostgreSQL-om i pgvectorom

Dobar RAG sustav nije prompt trik. To je indexing i retrieval sustav s modelom pričvršćenim na njega.

Ako ga gradite na PostgreSQL-u i pgvectoru, osnovna arhitektura postaje vrlo razumljiva: unosite izvorni materijal, dijelite u chunkove, stvarate embeddngse, spremate s metapodacima, dohvaćate najbolja podudaranja i šaljete taj kontekst modelu.

Osnovni tok

LangChain RAG dokumentacija vrlo jasno opisuje osnovnu podjelu: indeksiranje se događa unaprijed, a retrieval i generation u runtimeu.

Ta razlika važna je jer drži skupi rad izvan korisničkog request patha. Ne želite učitavati, chunkati i embedati dokumente svaki put kada netko postavi pitanje.

Praktičan pipeline izgleda ovako:

1. Prikupite autoritativne izvorne podatke.
2. Podijelite sadržaj u chunkove prilagođene dohvaćanju.
3. Generirajte embeddings za svaki chunk.
4. Spremite vektore i metapodatke u PostgreSQL s pgvectorom.
5. Dohvatite najrelevantnije chunkove za korisnički upit.
6. Predajte dohvaćeni kontekst modelu.

Zašto ovaj stack radi

Ovaj stack radi zato što svaki layer radi jedan posao.

PostgreSQL upravlja relacijskim podacima, metapodacima, filtriranjem i perzistencijom. pgvector obavlja semantic similarity search. Application layer vodi prompting, orchestration i korisničko iskustvo.

Ta podjela dovoljno je jednostavna za održavanje, a dovoljno fleksibilna za rast.

Također se uklapa u to kako stvarni business sustavi rade. Većina RAG projekata nije samo pretraživanje teksta. Trebaju status dokumenta, tenant filtering, permissions, mogućnost revizije i put za ažuriranje sadržaja kada se izvor promijeni.

Detalji implementacije koji su važni

Kvaliteta retrieval layera ovisi o kvaliteti ingestion layera.

To znači da morate paziti na:

1. Veličinu chunkova i preklapanje.
2. Kvalitetu metapodataka.
3. Koji embedding model koristite.
4. Trebate li točno ili približno pretraživanje.
5. Kako filtrirate rezultate prije nego dođu do modela.

Ako su chunkovi preveliki, retrieval postaje grub. Ako su premali, model gubi kontekst. Ako su metapodaci slabi, filtriranje postaje neuredno. Ako ne mjerite kvalitetu retrievala, završavate u pogađanju.

Kako izgleda dobar retrieval

Dobar retrieval nije samo “top 5 nearest neighbors”.

To je kombinacija pravih chunkova, pravih filtera i prompta koji modelu govori da se prema dohvaćenom sadržaju odnosi kao prema podacima, a ne kao prema uputama.

Tu može pomoći i hibridni retrieval. Ako korisnici pretražuju s internim imenima, kraticama ili točnim product terminima, keyword-style filtriranje može nadopuniti semantic similarity umjesto da mu konkurira.

Gdje je još uvijek ljudski posao

RAG ne uklanja potrebu za prosudbom.

I dalje trebate odlučiti koji je sadržaj autoritativan, koliko često se mijenja, kako evaluirati odgovore i što sustav treba napraviti kada retrieval vrati slab ili prazan rezultat.

Zato volim PostgreSQL i pgvector za praktične deploye. Drže sustav dovoljno blizu podacima da je lakše razmišljati o tradeoffima.

Zaključak

RAG pipeline s PostgreSQL-om i pgvectorom često je najpraktičniji početak za timove koji žele semantic retrieval bez gradnje zasebne platforme oko njega.

Arhitektura ostaje kompaktna, data model poznat, a retrieval layer ostaje povezan s ostatkom business sustava.

Reference: pgvector README i LangChain RAG tutorial.