Limitadong dami lamang ng text ang kayang “makita” ng mga LLM nang sabay-sabay (ang context window). Gumagana ito para sa maliliit na gawain, ngunit hindi na kapag libo-libong pahina ang saklaw ng isang knowledge base. Kahit sapat ang context window, maaari pa ring bumaba ang performance dahil sa problemang “karayom sa bunton ng dayami.”
Ang RAG (‘retrieval augmented generation’) ay naging napakakaraniwang pattern kung saan nagpapanatili ka ng knowledge base (mga dokumento, wiki, patakaran, transcript, atbp.), nagsasagawa ng semantic search sa query ng user upang kunin ang mga pinakanauugnay na snippet gamit ang mga embedding, at pagkatapos ay ipinapasok ang mga chunk na iyon sa LLM kasama ng tanong. Nililimitahan nito ang context ng modelo at, kapag ginawa nang tama, maaari nitong pagandahin ang kalidad ng sagot at bawasan ang mga hallucination.
Ang pgai ay isang open-source na extension ng Postgres (at mga katuwang na tool) na tumutulong sa iyong bumuo ng mga workflow para sa “AI retrieval” gamit ang pinagkakatiwalaang open-source database na PostgreSQL.
Ang pangunahing ideya ay ilipat ang mas malaking bahagi ng karaniwang RAG pipeline sa database layer (ingest → chunk → embed → panatilihing naka-sync ang mga embedding), sa halip na ituring ang DB bilang “imbakan lang” ng mga embedding.
Sa aming unang pagsusuri, mukhang may potensyal ito, ngunit kapag medyo naging komplikado na ang iyong RAG pipeline—lalo na ang mga paraan ng pag-chunk—hindi na ito angkop. Gayunman, tututukan namin ang proyektong ito.
Maraming paraan upang bumuo ng RAG. Para sa mas detalyadong paliwanag sa iba't ibang paraan, basahin ang Mga Praktikal na Halimbawa ng Mga Customized na RAG Solution. Nakakagulat ang lalim ng mga posibilidad sa disenyo kapag mahalaga ang kalidad, at karaniwang ganito ang “default” na paraan:
Kumuha ng maraming dokumento.
Hatiin ang mga ito sa mga chunk. Maraming paraan upang gawin ito (hal., ayon sa mga talata o semantic grouping).
Gawing embedding ang bawat chunk.
I-store ang mga embedding sa isang vector database (Pinecone, Milvus, atbp.) o sa Postgres gamit ang pgvector.
Kapag may query, hanapin ang pinakamalalapit na chunk `at ipasa ang mga ito sa LLM (muli...marami ring paraan upang gawin ito).
Sa maraming tech stack, nagaganap ang mga hakbang (1)–(3) sa labas ng database, sa application code o data pipeline, at pangunahing ginagamit ang database para sa:
pag-store ng mga embedding
paghahanap sa mga embedding
Ang pgai ay isang extension ng Postgres (open source, binuo ng Timescale) na naglalayong palabuin ang hangganang iyon.
Sa halip na ituring ang mga embedding bilang bagay na mano-manong pinamamahalaan ng iyong app, ginagawa ng pgai na feature ng database ang mga ito:
Tinutukoy mo kung aling table o mga dokumento ang lalagyan ng embedding.
Tinutukoy mo ang modelo para sa embedding at ang diskarte sa pag-chunk.
Pinamamahalaan ng pgai ang iba pa, kabilang ang pagpapanatiling updated ng mga embedding habang nagbabago ang source data mo.
Kaakit-akit ang pangako nito:
Mas kaunting custom na glue code na kailangang panatilihin.
Dapat mas madaling panatilihing ‘sariwa’ ang mga embedding habang nagbabago ang pinagmumulang mga dokumento.
Pinamamahalaan ng Postgres/pgai ang mga retry, rate limit, bigong job, atbp.
Paalala sa mambabasa: Kasama sa pgai ang pgvector (isa pang napakasikat na RAG extension para sa Postgres). Nagdaragdag ang pgvector ng vector storage at similarity search sa Postgres, habang ginagamit naman iyon ng pgai upang i-automate ang mga hakbang sa RAG pipeline tulad ng pag-chunk, pag-embed, at pagpapanatiling updated ng mga embedding.
1) Madali itong paandarin.
Medyo simple ang pinakamadaling proseso:
Kunin ang mga Docker image ng Timescale (database + worker).
Ibigay ang API key ng iyong embedding provider.
Magpatakbo ng kaunting SQL upang ideklara ang vectoriser (sa madaling salita: ano ang ie-embed, paano ito hahatiin sa mga chunk, at aling modelo ang gagamitin).
Pagkatapos, inaayos ng pgai na tumakbo ang isang vectoriser worker bilang hiwalay na proseso at gumawa ng mga embedding nang asynchronous (hal., bawat 5 minuto o sa anumang iskedyul na gusto mo).
2) Magandang gawin ang buong pipeline “malapit” sa database.
Maaaring mag-ingest ang pgai ng content mula sa mga table at mag-load ng mga dokumento mula sa mga lokasyon gaya ng S3, saka i-parse, i-chunk, at i-embed ang mga ito. Kaya rin nitong pangasiwaan ang iba't ibang format ng text document gaya ng PDF, Markdown, at iba pa.
1) Malaki ang nababawas sa kontrol mo (at kailangan kung minsan ng RAG ang kontrol).
Ang mga RAG system na mahusay ang performance batay sa kalidad ng sagot ay madalas na nangangailangan ng mga custom na pipeline, gaya ng:
mga custom na panuntunan sa pag-chunk (ayon sa heading, pahina, pagpapalitan ng speaker, atbp.)
pag-chunk na isinasaalang-alang ang metadata (panatilihin ang mga pamagat ng seksyon, timestamp, may-akda, at uri ng dokumento)
magkakaibang diskarte sa embedding para sa bawat uri ng dokumento
Mas limitado ang flexibility ng pgai sa mga nabanggit.
Sa ngayon, may dalawang pangunahing diskarte sa pag-chunk: character text splitter at recursive character text splitter, bukod pa sa opsyong walang pag-chunk. Maaaring sapat iyon para sa ilang use case, ngunit mas maraming customization ang kailangan ng maraming production RAG system.
Magiging mahusay kung maisasama ng Timescale ang ilan sa mas sopistikadong diskarte sa pag-chunk na makikita sa mga library gaya ng Chonkie, at masuportahan din ang mga advanced na disenyo tulad ng contextual retrieval ng Anthropic.
2) Text muna, hindi multimodal.
Maraming kawili-wiling problema sa RAG ang hindi na puro text lamang:
Mga PDF na may mga diagram
mga screenshot / larawan
mga audio recording
mga video clip
Kahit kaya mong “mag-extract ng text” mula sa mga source na ito, hindi iyon katumbas ng tunay na multimodal embedding pipeline.
Kung susuportahan kalaunan ng pgai ang mga multimodal na modelo nang end-to-end (load → chunk → embed para sa malalaking larawan/audio/video na naka-store sa S3, na may maaasahang pag-sync), magiging kapaki-pakinabang iyon. Ngunit sa ngayon, workflow ito para sa text embedding.
3) Kung mga embedding lang ang kailangan mo, baka hindi mo kailangan ang pgai.
Kung custom na ang iyong ingestion pipeline (o kailangan itong maging custom), hindi ang “pag-embed ng mga chunk ng text” ang pinakamahirap na bahagi ng RAG. Sa ganitong sitwasyon, ang pinakamadaling bahagi ng problema ang nilulutas ng pgai.
Dagdag pa, kung bihirang i-update ang iyong knowledge base, hindi ganoon kalaki ang pakinabang ng awtomatikong pag-sync ng mga embedding.
Isang mahusay na paraan ng paggamit sa pgai ang pag-deploy ng text-to-SQL interface sa iyong mga database. Madali itong magagawa gamit ang semantic_catalog module na inaalok ng pgai. I-set up lang nang ganito:
Bash
at ipakuha sa semantic catalog ang iyong mga data dictionary gamit ang pgai semantic-catalog create. Gumagawa ito ng context mula sa iyong datastore na ganito ang hitsura:
Plain Text
Magagamit na ngayon ng pgai ang context na ito sa iba't ibang paraan;
Sa pamamagitan ng semantic search:
Ibabalik ng query na ito ang mga table, function, at iba pang object na maaaring nauugnay sa iyong natural-language query:
Bash
Kunin ang raw context:
Ire-render nito ang raw YAML context na nauugnay sa iyong natural-language query:
Bash
Bumuo ng SQL:
O maaari mong direktang buuin ang raw SQL na kailangan upang sagutin ang iyong query. Ipinapadala sa isang LLM ang context mula sa nakaraang hakbang at bumubuo ito ng sagot:
Bash
Kung bumubuo ka ng medyo simpleng RAG system, sulit subukan ang pgai kung gusto mo ng:
Postgres bilang iyong system of record,
kaunting glue code,
mga embedding na awtomatikong nananatiling naka-sync,
mabilis na paraan upang maglapat ng text-to-SQL sa iyong mga database,
pagkakataong subukan ang mga bagong RAG tool at extension ng Postgres.
Mas mabuting maghintay muna bago gumamit ng pgai kung kailangan ng iyong RAG pipeline ang alinman sa mga sumusunod:
maraming custom na logic para sa pag-ingest o pag-chunk
maraming uri ng dokumento na may magkakaibang kinakailangan sa pag-parse
mga multimodal embedding
Panghuli, bagama't malinaw na malawak ang paggamit sa pgvector, hindi pa tiyak kung magkakaroon ang pgai ng kaparehong antas ng interes at suporta (bagama't humigit-kumulang 18 buwan pa lamang itong umiiral).
Ang pgai ay isang kawili-wiling paraan ng paggamit ng RAG na nagbibigay-daan sa mga database na gawin ang mas marami sa rutinang operational na gawain, upang maging mas simple ang application code mo.
Sa ngayon, ito ay:
magagamit at talagang madaling gamitin para sa mga simpleng RAG setup
hindi sapat ang flexibility para sa mas custom na pipeline (lalo na sa multimodal)
May potensyal ito at talagang sulit subaybayan ang pag-unlad nito.