LLM mung bisa “ndeleng” teks kanthi jumlah winates sekaligus (jendhela konteks). Iki cocog kanggo tugas cilik, nanging ora efektif nalika basis kawruh nyakup ewonan kaca. Sanajan jendhela konteksé cukup, kinerja isih bisa mudhun amarga masalah “nggoleki dom ing tumpukan dami”.
RAG (‘generasi sing ditambahi panjupuk’) wis dadi pola umum: sampeyan njaga basis kawruh (dokumen, wiki, kabijakan, transkrip, lan liya-liyané), nindakake panggolèkan semantik marang pitakon pangguna kanggo njupuk cuplikan sing paling cocog nganggo embedding, banjur nglebokaké perangan kasebut menyang LLM bebarengan karo pitakoné. Iki mbatesi konteks model lan, yen ditindakake kanthi bener, bisa ningkataké mutu jawaban lan nyuda halusinasi.
pgai yaiku ekstensi Postgres sumber terbuka (lan piranti panyengkuyungé) kanggo mbantu sampeyan mbangun alur kerja “panjupuk AI” ing ndhuwur PostgreSQL, basis data sumber terbuka sing wis dipercaya.
Gagasan utamané yaiku mindhah luwih akèh pipeline RAG standar menyang lapisan basis data (lebokaké → pérang → gawé embedding → jaga sinkronisasi embedding), tinimbang nganggep basis data “mung panyimpenan” embedding.
Panemu awal kita: pgai njanjèkaké, nanging ora cocog nalika pipeline RAG sampeyan dadi rada rumit, mligi ing cara pamérangan. Nanging, kita bakal terus ngawasi proyèk iki kanthi tenanan.
Ana akèh cara kanggo mbangun RAG. Kanggo katrangan luwih jangkep babagan manéka pendekatan RAG, wacanen Conto Praktis Solusi RAG Kustom. Ruang rancangané dadi luwih jero tinimbang sing dikira nalika mutu digatekaké, lan pendekatan “gawan” sing umum biasané kaya mangkéné:
Siapna sakumpulan dokumen.
Pérang dokumen kasebut dadi perangan-perangan. Ana manéka cara kanggo nindakake iki (umpamané adhedhasar paragraf utawa klompok semantik).
Owahana saben perangan dadi embedding.
Simpen embedding ing basis data vektor (Pinecone, Milvus, lan liya-liyané) utawa ing Postgres nganggo pgvector.
Nalika ana pitakon, golèki perangan sing paling cedhak `lan lebokaké menyang LLM (manèh... uga ana akèh cara kanggo nindakake iki).
Ing akèh tumpukan teknologi, langkah (1)–(3) ditindakake ing njaba basis data liwat kode aplikasi utawa pipeline data, déné basis data utamané dienggo kanggo:
nyimpen embedding
nggolèki embedding
pgai yaiku ekstensi Postgres sumber terbuka sing dikembangaké déning Timescale) lan nyoba nyamarké wates kasebut.
Tinimbang nganggep embedding minangka bab sing kudu dikelola manual déning aplikasi, pgai ndadèkaké embedding fitur basis data:
Sampeyan nemtokaké tabel utawa dokumen sing arep digawèkaké embedding.
Sampeyan nemtokaké model embedding lan strategi pamérangan.
pgai ngatur sisané, kalebu njaga embedding supaya tetep dianyari nalika data sumber owah.
Paédah sing dijanjèkaké narik kawigatèn:
Kode penghubung kustom sing kudu dirumat dadi luwih sithik.
Embedding mesthiné luwih gampang dijaga supaya tetep ‘anyar’ nalika dokumen sumberé owah.
Postgres/pgai ngatur upaya balèn, wates laju, tugas sing gagal, lan liya-liyané.
Cathetan kanggo pamaca: pgai wis ngemot pgvector (ekstensi Postgres liya sing uga misuwur banget kanggo RAG). pgvector nambahaké panyimpenan vektor lan panggolèkan kamiripan menyang Postgres, déné pgai migunakaké dhasar kasebut kanggo ngotomatisasi langkah pipeline RAG kayata pamérangan, gawé embedding, lan njaga embedding supaya tetep dianyari.
1) Gampang diwiwiti.
Alur sing tanpa alangan cukup prasaja:
Jupuk image Docker Timescale (basis data + worker).
Lebokaké kunci API panyedhiya embedding sampeyan.
Jalanaké sawetara SQL kanggo ndhéklarasèkaké vectoriser (pokoké: apa sing digawèkaké embedding, cara mérangé, lan model sing dienggo).
Sawisé iku, pgai ngatur supaya worker vectoriser mlaku minangka prosès kapisah lan ngasilaké embedding kanthi asinkron (umpamané saben 5 menit utawa miturut jadwal sing dikarepaké).
2) Nglakokaké kabèh pipeline “cedhak” basis data iku nyenengaké.
pgai bisa nglebokaké kontèn saka tabel lan ngemot dokumen saka papan kayata S3, banjur ngurai + mérang + gawé embedding. pgai uga bisa nangani manéka format dokumen teks kayata PDF, Markdown, lan liya-liyané.
1) Sampeyan kélangan akèh kontrol (lan RAG kadhangkala mbutuhaké kontrol).
Sistem RAG kanthi kinerja dhuwur (yen diukur saka mutu jawaban) kerep mbutuhaké pipeline kustom, kayata:
aturan pamérangan kustom (miturut judhul, kaca, giliran pamicara, lan liya-liyané)
pamérangan sing nggatèkaké metadata (tetep nyimpen judhul bagéan, timestamp, panulis, lan jinis dokumen)
strategi embedding sing béda kanggo saben jinis dokumen
pgai ora pati luwes kanggo kabutuhan ing ndhuwur.
Saiki ana rong strategi pamérangan utama: character text splitter lan recursive character text splitter, ditambah pilihan tanpa pamérangan. Iki bisa cukup kanggo sawetara kasus panggunaan, nanging akèh sistem RAG produksi mbutuhaké kustomisasi luwih akèh.
Bakal apik banget yen Timescale bisa nglebokaké sawetara strategi pamérangan luwih canggih kaya sing ana ing pustaka kayata Chonkie, lan uga ndhukung rancangan maju kayata panjupuk kontekstual Anthropic.
2) Ngutamakaké teks, dudu multimodal.
Akèh masalah RAG sing narik kawigatèn saiki ora mung awujud teks:
PDF kanthi diagram
screenshot / gambar
rekaman audio
klip vidéo
Sanajan sampeyan bisa “ngekstrak teks” saka sumber kasebut, iku ora padha karo pipeline embedding multimodal sing sejati.
Yen ing tembé pgai ndhukung model multimodal saka wiwitan nganti pungkasan (ngemot → mérang → gawé embedding kanggo gambar gedhé/audio/vidéo sing disimpen ing S3, kanthi sinkronisasi sing andal), iki bakal narik kawigatèn. Nanging saiki pgai mung alur kerja embedding teks.
3) Yen mung mbutuhaké embedding, sampeyan bisa uga ora mbutuhaké pgai.
Yen pipeline pamlebuan sampeyan wis kustom (utawa kudu kustom), “nggawé embedding saka perangan teks” dudu bagéan RAG sing paling angel. Ing kahanan kasebut, pgai mung ngrampungaké bagéan masalah sing paling gampang.
Kajaba iku, yen basis kawruh arang dianyari, paédah sinkronisasi embedding otomatis uga ora pati gedhé.
Salah siji cara sing apik banget kanggo migunakaké pgai yaiku masang antarmuka teks-menyang-SQL ing basis data sampeyan. Iki bisa ditindakake kanthi cukup gampang nganggo modul semantic_catalog sing disedhiyakaké pgai. Cukup atur kaya mangkéné:
Bash
banjur gunakna semantic catalog kanggo mindhai kamus data nganggo pgai semantic-catalog create. Iki ngasilaké konteks saka panyimpenan data sampeyan sing kurang luwih katon kaya mangkéné:
Plain Text
Konteks iki saiki kasedhiya kanggo pgai kanthi manéka cara;
Liwat panggolèkan semantik:
Kueri iki bakal ngasilaké tabel, fungsi, lan obyèk liya sing bisa cocog karo kueri basa alami sampeyan:
Bash
Jupuk konteks mentah:
Iki bakal nampilaké konteks YAML mentah sing gegandhèngan karo kueri basa alami sampeyan:
Bash
Gawé SQL:
Utawa, sampeyan bisa langsung ngasilaké SQL mentah sing dibutuhaké kanggo mangsuli kueri. Konteks saka langkah sadurungé dikirim menyang LLM, banjur jawabané diasilaké:
Bash
Yen sampeyan mbangun sistem RAG sing cukup prasaja, pgai pantes dicoba yen sampeyan kepéngin:
Postgres minangka sistem cathetan utama,
kode penghubung sing sethithik,
embedding sing tetep disinkronaké kanthi otomatis,
cara cepet kanggo ngetrapaké teks-menyang-SQL ing basis data sampeyan,
nyoba-nyoba piranti RAG anyar lan ekstensi Postgres.
Sampeyan becik ngentèni dhisik sadurungé nganggo pgai yen pipeline RAG mbutuhaké salah siji saka iki:
logika pamlebuan utawa pamérangan kustom sing abot
akèh jinis dokumen kanthi kabutuhan panguraian sing béda-béda
embedding multimodal
Pungkasan, sanajan pgvector cetha wis diadopsi kanthi wiyar, durung cetha apa pgai bakal éntuk minat lan dhukungan sing padha (senajan umuré lagi watara 18 sasi).
pgai nawakaké pendekatan RAG sing narik kawigatèn kanthi masrahaké luwih akèh tugas operasional rutin marang basis data, saéngga kode aplikasi bisa luwih prasaja.
Saiki, pgai:
bisa dienggo lan pancèn nyenengaké kanggo konfigurasi RAG sing prasaja
durung cukup luwes kanggo pipeline sing luwih kustom (mligi multimodal)
pgai nuduhaké potènsi lan mesthi pantes diawasi kanggo ndeleng perkembangane.