LLM hanya dapat “melihat” teks dalam jumlah terbatas pada satu waktu (jendela konteks). Cara ini cocok untuk tugas kecil, tetapi tidak lagi efektif ketika basis pengetahuan mencakup ribuan halaman. Bahkan ketika jendela konteksnya memadai, performa masih dapat menurun akibat masalah “mencari jarum dalam tumpukan jerami”.
RAG (‘retrieval augmented generation’ atau pembuatan berbantuan pengambilan) telah menjadi pola yang sangat umum: Anda mengelola basis pengetahuan (dokumen, wiki, kebijakan, transkrip, dan sebagainya), menjalankan pencarian semantik atas kueri pengguna untuk mengambil cuplikan paling relevan menggunakan embedding, lalu memasukkan potongan tersebut ke LLM bersama pertanyaannya. Cara ini membatasi konteks model dan, jika diterapkan dengan benar, dapat meningkatkan kualitas jawaban serta mengurangi halusinasi.
pgai adalah ekstensi Postgres sumber terbuka (beserta alat pendampingnya) yang membantu Anda membangun alur kerja “pengambilan AI” di atas PostgreSQL, basis data sumber terbuka yang tepercaya.
Gagasan utamanya adalah memindahkan lebih banyak proses standar RAG ke lapisan basis data (serap → pecah → buat embedding → jaga agar embedding tetap sinkron), alih-alih memperlakukan basis data sebagai “sekadar penyimpanan” embedding.
Kesan awal kami, pgai cukup menjanjikan, tetapi tidak cocok begitu pipeline RAG Anda mulai agak rumit, terutama dalam pendekatan pemecahan teks. Meski demikian, kami akan terus memantau proyek ini dengan saksama.
Ada banyak cara untuk membangun RAG. Untuk pembahasan lebih panjang tentang berbagai pendekatannya, baca Contoh Praktis Solusi RAG yang Disesuaikan. Ruang desainnya ternyata sangat luas ketika kualitas menjadi perhatian, dan pendekatan “bawaan” yang umum biasanya seperti ini:
Kumpulkan sejumlah dokumen.
Pecah dokumen menjadi beberapa potongan. Ada banyak metode untuk melakukannya (misalnya berdasarkan paragraf atau pengelompokan semantik).
Ubah setiap potongan menjadi embedding.
Simpan embedding dalam basis data vektor (Pinecone, Milvus, dan sebagainya) atau di Postgres menggunakan pgvector.
Saat kueri dijalankan, cari potongan terdekat `dan masukkan ke LLM (sekali lagi... ada banyak cara untuk melakukannya).
Dalam banyak tumpukan teknologi, langkah (1)–(3) berlangsung di luar basis data, dalam kode aplikasi atau pipeline data. Basis data terutama digunakan untuk:
menyimpan embedding
mencari embedding
pgai adalah ekstensi Postgres sumber terbuka yang dikembangkan oleh Timescale dan berupaya mengaburkan batas tersebut.
Alih-alih menjadikan embedding sesuatu yang harus dikelola aplikasi Anda secara manual, pgai menjadikannya fitur basis data:
Anda menentukan tabel atau dokumen yang ingin dibuatkan embedding.
Anda menentukan model embedding dan strategi pemecahan teks.
pgai mengelola sisanya, termasuk memperbarui embedding ketika data sumber Anda berubah.
Tawaran ini menarik:
Lebih sedikit kode perekat khusus yang perlu dipelihara.
Embedding seharusnya lebih mudah dijaga agar tetap ‘mutakhir’ saat dokumen sumber yang mendasarinya berubah.
Postgres/pgai mengelola percobaan ulang, batas laju, pekerjaan yang gagal, dan sebagainya.
Catatan untuk pembaca: pgai menyertakan pgvector (ekstensi Postgres lain yang sangat populer untuk RAG) di dalamnya. pgvector menambahkan penyimpanan vektor dan pencarian kemiripan ke Postgres, sedangkan pgai memanfaatkannya untuk mengotomatiskan tahapan pipeline RAG, seperti pemecahan teks, pembuatan embedding, dan pemutakhiran embedding tersebut.
1) Mudah untuk mulai dijalankan.
Alur idealnya cukup sederhana:
Tarik image Docker Timescale (basis data + worker).
Masukkan kunci API penyedia embedding Anda.
Jalankan sedikit SQL untuk mendeklarasikan vectoriser (intinya: apa yang akan dibuatkan embedding, bagaimana memecahnya, dan model mana yang digunakan).
Setelah itu, pgai mengatur agar worker vectoriser berjalan sebagai proses terpisah dan menghasilkan embedding secara asinkron (misalnya setiap 5 menit atau sesuai frekuensi yang Anda inginkan).
2) Menyenangkan bisa menjalankan seluruh pipeline “di dekat” basis data.
pgai dapat menyerap konten dari tabel serta memuat dokumen dari tempat seperti S3, lalu mengurai, memecah, dan membuat embedding-nya. pgai juga dapat menangani berbagai format dokumen teks, seperti PDF, Markdown, dan sebagainya.
1) Anda kehilangan banyak kendali (padahal RAG terkadang membutuhkannya).
Sistem RAG berperforma tinggi (jika diukur berdasarkan kualitas jawaban) sering kali memerlukan pipeline khusus, seperti:
aturan pemecahan khusus (berdasarkan judul bagian, halaman, giliran pembicara, dan sebagainya)
pemecahan yang mempertimbangkan metadata (mempertahankan judul bagian, stempel waktu, penulis, dan jenis dokumen)
strategi embedding yang berbeda untuk setiap jenis dokumen
pgai menawarkan fleksibilitas yang lebih terbatas untuk hal-hal di atas.
Saat ini ada dua strategi pemecahan utama: pemisah teks berdasarkan karakter dan pemisah teks karakter rekursif, serta opsi tanpa pemecahan. Itu mungkin cukup untuk beberapa kasus penggunaan, tetapi banyak sistem RAG produksi memerlukan penyesuaian lebih lanjut.
Akan sangat menarik jika Timescale dapat menyertakan strategi pemecahan yang lebih canggih seperti yang tersedia dalam pustaka semacam Chonkie, sekaligus mendukung desain tingkat lanjut seperti pengambilan kontekstual Anthropic.
2) Mengutamakan teks, bukan multimodal.
Banyak persoalan RAG yang menarik kini tidak lagi terbatas pada teks:
PDF dengan diagram
tangkapan layar/gambar
rekaman audio
klip video
Meskipun Anda dapat “mengekstrak teks” dari sumber-sumber tersebut, hasilnya tidak sama dengan pipeline embedding multimodal yang sesungguhnya.
Jika kelak pgai mendukung model multimodal secara menyeluruh (memuat → memecah → membuat embedding untuk gambar besar/audio/video yang tersimpan di S3, dengan sinkronisasi yang andal), itu akan sangat menarik. Namun, saat ini pgai masih berupa alur kerja embedding teks.
3) Jika hanya memerlukan embedding, Anda mungkin tidak memerlukan pgai.
Jika pipeline penyerapan Anda sudah dibuat khusus (atau memang harus demikian), maka “membuat embedding dari potongan teks” bukanlah bagian tersulit dari RAG. Dalam kondisi tersebut, pgai hanya menyelesaikan bagian termudah dari masalahnya.
Selain itu, jika basis pengetahuan Anda jarang diperbarui, manfaat sinkronisasi embedding otomatis juga tidak terlalu besar.
Salah satu cara yang sangat baik untuk menggunakan pgai adalah menerapkan antarmuka text-to-SQL pada basis data Anda. Ini dapat dilakukan dengan cukup mudah menggunakan modul semantic_catalog yang disediakan pgai. Cukup lakukan penyiapan seperti ini:
Bash
lalu gunakan katalog semantik untuk memindai kamus data Anda dengan pgai semantic-catalog create. Langkah ini menghasilkan konteks dari penyimpanan data Anda yang kurang lebih terlihat seperti ini:
Plain Text
Konteks ini kini tersedia bagi pgai melalui berbagai cara;
Melalui pencarian semantik:
Kueri ini akan menampilkan tabel, fungsi, dan objek lain yang mungkin relevan dengan kueri bahasa alami Anda:
Bash
Dapatkan konteks mentah:
Ini akan merender konteks YAML mentah yang terkait dengan kueri bahasa alami Anda:
Bash
Buat SQL:
Atau, Anda dapat langsung menghasilkan SQL mentah yang diperlukan untuk menjawab kueri Anda. Konteks dari langkah sebelumnya dikirim ke LLM, lalu respons dihasilkan:
Bash
Jika Anda membangun sistem RAG yang relatif sederhana, pgai patut dicoba apabila Anda menginginkan:
Postgres sebagai sistem pencatatan utama,
kode perekat seminimal mungkin,
embedding yang otomatis tetap sinkron,
cara cepat untuk menerapkan text-to-SQL pada basis data Anda,
mencoba berbagai alat RAG dan ekstensi Postgres baru.
Sebaiknya tunda penggunaan pgai jika pipeline RAG Anda memerlukan salah satu hal berikut:
logika penyerapan atau pemecahan teks khusus yang kompleks
banyak jenis dokumen dengan kebutuhan penguraian yang berbeda
embedding multimodal
Terakhir, meskipun pgvector jelas telah diadopsi secara luas, belum jelas apakah pgai akan mendapatkan tingkat minat dan dukungan yang sama (meski baru tersedia sekitar 18 bulan).
pgai menawarkan pendekatan RAG yang menarik dengan menyerahkan lebih banyak pekerjaan operasional rutin kepada basis data agar kode aplikasi Anda lebih sederhana.
Saat ini, pgai:
dapat digunakan dan benar-benar nyaman untuk konfigurasi RAG sederhana
belum cukup fleksibel untuk pipeline yang lebih khusus (terutama multimodal)
pgai menunjukkan potensi dan perkembangannya jelas layak terus dipantau.