သင့် RAG pipeline ကို Postgres က ကိုင်တွယ်နိုင်သလား။

• LLM များသည် တစ်ကြိမ်လျှင် စာသားပမာဏအကန့်အသတ်ကိုသာ “မြင်” နိုင်သည် (context window)။ ၎င်းသည် အလုပ်ငယ်များအတွက် အဆင်ပြေသော်လည်း အသိပညာအခြေခံတွင် စာမျက်နှာထောင်ပေါင်းများစွာ ပါဝင်လာလျှင် အလုပ်မဖြစ်တော့ပါ။ context window လုံလောက်သည့်တိုင် “ကောက်ရိုးပုံထဲ အပ်ရှာရသည့်” ပြဿနာကြောင့် စွမ်းဆောင်ရည် ကျဆင်းနိုင်သေးသည်။

• RAG (“အချက်အလက်ပြန်လည်ရှာဖွေမှုဖြင့် မြှင့်တင်ထားသော အကြောင်းအရာဖန်တီးမှု”) သည် အသုံးများလာသည့် နည်းလမ်းတစ်ခုဖြစ်သည်။ အသိပညာအခြေခံ (စာရွက်စာတမ်းများ၊ wiki များ၊ မူဝါဒများ၊ စာသားမှတ်တမ်းများ စသည်) ကို ထိန်းသိမ်းထားပြီး သုံးစွဲသူ၏ မေးခွန်းကို semantic search လုပ်ကာ embeddings ဖြင့် ဆီလျော်မှုအရှိဆုံး အပိုင်းများကို ရှာဖွေပြီးနောက် ထိုအပိုင်းများနှင့် မေးခွန်းကို LLM ထဲသို့ အတူထည့်ပေးခြင်းဖြစ်သည်။ ၎င်းက မော်ဒယ်၏ context ကို ကန့်သတ်ပေးပြီး မှန်ကန်စွာ လုပ်ဆောင်ပါက အဖြေအရည်အသွေးကို မြှင့်တင်ကာ အချက်အလက်မမှန် ဖန်တီးမှုကို လျှော့ချပေးနိုင်သည်။

• pgai သည် ယုံကြည်စိတ်ချရသည့် open-source database PostgreSQL ပေါ်တွင် “AI retrieval” workflow များ တည်ဆောက်နိုင်ရန် ကူညီပေးသော open-source Postgres extension (နှင့် တွဲဖက်ကိရိယာများ) ဖြစ်သည်။

• အဓိကအယူအဆမှာ DB ကို embeddings အတွက် “သိုလှောင်ရာသက်သက်” ဟု မသတ်မှတ်ဘဲ ပုံမှန် RAG pipeline ၏ အစိတ်အပိုင်းများကို database layer ထဲသို့ ပိုမိုထည့်သွင်းရန်ဖြစ်သည် (ထည့်သွင်း → အပိုင်းခွဲ → embed လုပ် → embeddings များကို ထပ်တူကျအောင် ထိန်းသိမ်း)။

• ကနဦးသုံးသပ်ချက်အရ အလားအလာရှိသော်လည်း RAG pipeline အနည်းငယ်မျှ ရှုပ်ထွေးလာသည်နှင့် (အထူးသဖြင့် အပိုင်းခွဲသည့်နည်းလမ်းများတွင်) မသင့်တော်တော့ပါ။ သို့သော် ဤပရောဂျက်ကို ကျွန်ုပ်တို့ အနီးကပ် စောင့်ကြည့်သွားမည်။

RAG တည်ဆောက်ရန် နည်းလမ်းများစွာရှိသည်။ မတူညီသော RAG နည်းလမ်းများအကြောင်း ပိုမိုအသေးစိတ်သိလိုပါက စိတ်ကြိုက်ပြင်ဆင်ထားသော RAG ဖြေရှင်းနည်းများ၏ လက်တွေ့ဥပမာများကို ဖတ်ပါ။ အရည်အသွေးကို အလေးထားလာသည်နှင့် ဒီဇိုင်းရွေးချယ်စရာများသည် မျှော်လင့်ထားသည်ထက် ပိုမိုနက်ရှိုင်းလာပြီး အသုံးများသော “မူလ” နည်းလမ်းမှာ ယေဘုယျအားဖြင့် အောက်ပါအတိုင်းဖြစ်သည်။

1. စာရွက်စာတမ်းများကို စုစည်းပါ။

2. ၎င်းတို့ကို အပိုင်းများ ခွဲပါ။ ဤသို့လုပ်ရန် နည်းလမ်းများစွာရှိသည် (ဥပမာ စာပိုဒ်အလိုက်၊ အဓိပ္ပာယ်ဆက်စပ်မှုအလိုက် အုပ်စုဖွဲ့ခြင်း)။

3. အပိုင်းတစ်ခုစီကို embedding အဖြစ် ပြောင်းပါ။

4. embeddings များကို vector database (Pinecone၊ Milvus စသည်) တွင်ဖြစ်စေ၊ pgvector သုံး၍ Postgres တွင်ဖြစ်စေ သိမ်းဆည်းပါ။

5. မေးမြန်းချိန်တွင် အနီးစပ်ဆုံးအပိုင်းများကို ရှာဖွေပြီး `၎င်းတို့ကို LLM ထဲသို့ ထည့်ပေးပါ (ဤသို့လုပ်ရန်လည်း နည်းလမ်းများစွာ ရှိပြန်သည်)။

နည်းပညာစနစ်များစွာတွင် အဆင့် (၁)–(၃) ကို database ပြင်ပရှိ application code သို့မဟုတ် data pipeline တွင် လုပ်ဆောင်ပြီး database ကို အဓိကအားဖြင့် အောက်ပါတို့အတွက် အသုံးပြုသည်။

• embeddings များ သိမ်းဆည်းခြင်း

• embeddings များ ရှာဖွေခြင်း

pgai သည် ထိုနယ်နိမိတ်ကို မှေးမှိန်စေရန် ကြိုးပမ်းသည့် Postgres extension တစ်ခုဖြစ်ပြီး open source ဖြစ်ကာ Timescale က ဖန်တီးထားသည်။

embeddings များကို app က ကိုယ်တိုင်စီမံရသည့် အရာအဖြစ် မသတ်မှတ်ဘဲ pgai က ၎င်းတို့ကို database လုပ်ဆောင်ချက်တစ်ခုအဖြစ် ပြောင်းလဲပေးသည်။

• မည်သည့် table သို့မဟုတ် စာရွက်စာတမ်းများကို embed လုပ်မည်ကို သတ်မှတ်ပါ။

• embedding မော်ဒယ်နှင့် အပိုင်းခွဲနည်းကို သတ်မှတ်ပါ။

• မူရင်းဒေတာ ပြောင်းလဲသည့်အခါ embeddings များကို အပ်ဒိတ်ဖြစ်နေစေခြင်းအပါအဝင် ကျန်လုပ်ငန်းအားလုံးကို pgai က စီမံပေးသည်။

မျှော်မှန်းထားသည့် အကျိုးကျေးဇူးများက စိတ်ဝင်စားဖွယ်ဖြစ်သည်။

• ထိန်းသိမ်းရမည့် စိတ်ကြိုက်ချိတ်ဆက် code နည်းသွားမည်။

• မူရင်းစာရွက်စာတမ်းများ ပြောင်းလဲသည့်အခါ embeddings များကို “နောက်ဆုံးအခြေအနေ” အတိုင်း ထိန်းသိမ်းရန် ပိုလွယ်ကူသင့်သည်။

• ထပ်မံကြိုးစားမှုများ၊ rate limit များ၊ မအောင်မြင်သည့် job များ စသည်ကို Postgres/pgai က စီမံပေးသည်။

စာဖတ်သူများအတွက် မှတ်ချက်— pgai တွင် အလွန်လူသုံးများသည့် အခြား RAG Postgres extension တစ်ခုဖြစ်သော pgvector ကို တစ်ပါတည်း ထည့်သွင်းထားသည်။ pgvector က Postgres တွင် vector သိုလှောင်မှုနှင့် similarity search ကို ထည့်သွင်းပေးပြီး pgai က ထိုအပေါ်အခြေခံ၍ အပိုင်းခွဲခြင်း၊ embedding ပြုလုပ်ခြင်းနှင့် embeddings များကို အပ်ဒိတ်ဖြစ်နေစေခြင်းကဲ့သို့ RAG pipeline အဆင့်များကို အလိုအလျောက်လုပ်ဆောင်ပေးသည်။

၁) စတင်အသုံးပြုရန် လွယ်ကူသည်။

အရာအားလုံး အဆင်ပြေသည့်အခါ လုပ်ငန်းစဉ်က အတော်လေး ရိုးရှင်းသည်။

• Timescale docker image များ (database + worker) ကို ရယူပါ။

• သင်၏ embedding provider API key ကို ထည့်ပါ။

• vectoriser ကို သတ်မှတ်ရန် SQL အနည်းငယ်ကို run ပါ (အဓိကအားဖြင့် မည်သည့်အရာကို embed လုပ်မည်၊ မည်သို့အပိုင်းခွဲမည်၊ မည်သည့်မော်ဒယ်ကို သုံးမည် စသည်တို့)။

ထို့နောက် pgai က vectoriser worker ကို သီးခြား process အဖြစ် run စေပြီး embeddings များကို asynchronous နည်းဖြင့် ထုတ်ပေးသည် (ဥပမာ ၅ မိနစ်တစ်ကြိမ် သို့မဟုတ် သင်အလိုရှိသည့် အကြိမ်နှုန်းဖြင့်)။

၂) pipeline တစ်ခုလုံးကို database “အနီး” တွင် လုပ်ဆောင်နိုင်ခြင်းက ကောင်းမွန်သည်။

pgai သည် table များမှ အကြောင်းအရာကို ထည့်သွင်းနိုင်သလို S3 ကဲ့သို့ နေရာများမှ စာရွက်စာတမ်းများကိုလည်း load လုပ်ပြီး parse + အပိုင်းခွဲ + embed လုပ်နိုင်သည်။ PDF၊ Markdown စသည့် စာသားစာရွက်စာတမ်း format မျိုးစုံကိုလည်း ကိုင်တွယ်နိုင်သည်။

၁) ထိန်းချုပ်နိုင်စွမ်းများစွာ ဆုံးရှုံးရသည် (RAG တွင် တစ်ခါတစ်ရံ ထိန်းချုပ်နိုင်မှု လိုအပ်သည်)။

အဖြေအရည်အသွေးအရ စွမ်းဆောင်ရည်မြင့်သည့် RAG စနစ်များတွင် အောက်ပါကဲ့သို့ စိတ်ကြိုက် pipeline များ လိုအပ်လေ့ရှိသည်။

• စိတ်ကြိုက်အပိုင်းခွဲစည်းမျဉ်းများ (ခေါင်းစဉ်အလိုက်၊ စာမျက်နှာအလိုက်၊ စကားပြောသူအလှည့်အလိုက် စသည်)

• metadata ကို ထည့်သွင်းစဉ်းစားသည့် အပိုင်းခွဲခြင်း (ကဏ္ဍခေါင်းစဉ်၊ timestamp၊ ရေးသားသူနှင့် စာရွက်စာတမ်းအမျိုးအစားတို့ကို ထိန်းသိမ်းခြင်း)

• စာရွက်စာတမ်းအမျိုးအစားအလိုက် မတူညီသော embedding နည်းဗျူဟာများ

အထက်ပါအချက်များအတွက် pgai ၏ ပြောင်းလွယ်ပြင်လွယ်မှုက နည်းပါးသည်။

လက်ရှိတွင် အဓိကအပိုင်းခွဲနည်း နှစ်မျိုးရှိသည်—အက္ခရာအရေအတွက်အခြေပြု text splitter နှင့် recursive အက္ခရာအရေအတွက်အခြေပြု text splitter တို့ဖြစ်ပြီး အပိုင်းမခွဲသည့် ရွေးချယ်စရာလည်း ရှိသည်။ အချို့အသုံးပြုမှုများအတွက် လုံလောက်နိုင်သော်လည်း လက်တွေ့လုပ်ငန်းသုံး RAG စနစ်များစွာတွင် ပိုမိုစိတ်ကြိုက်ပြင်ဆင်ရန် လိုအပ်သည်။

Timescale က Chonkie ကဲ့သို့ library များတွင် တွေ့ရသော ပိုမိုအဆင့်မြင့်သည့် အပိုင်းခွဲနည်းအချို့ကို ထည့်သွင်းပေးနိုင်ပြီး Anthropic ၏ contextual retrieval ကဲ့သို့ အဆင့်မြင့်ဒီဇိုင်းများကိုလည်း ပံ့ပိုးပေးနိုင်မည်ဆိုလျှင် အလွန်ကောင်းမွန်မည်။

၂) Multimodal မဟုတ်ဘဲ စာသားကို ဦးစားပေးထားသည်။

စိတ်ဝင်စားဖွယ် RAG ပြဿနာများစွာသည် စာသားသက်သက် မဟုတ်တော့ပါ။

• ပုံကြမ်းများပါသည့် PDF များ

• screenshot များ / ပုံများ

• အသံဖမ်းထားသည့် ဖိုင်များ

• ဗီဒီယိုအပိုင်းများ

ဤရင်းမြစ်များမှ “စာသားထုတ်ယူ” နိုင်သည့်တိုင် ၎င်းသည် အမှန်တကယ် multimodal embedding pipeline နှင့် မတူပါ။

အနာဂတ်တွင် pgai က multimodal မော်ဒယ်များကို အစမှအဆုံး ပံ့ပိုးလာပါက (S3 တွင် သိမ်းထားသည့် ပုံကြီးများ၊ အသံနှင့် ဗီဒီယိုများကို load → အပိုင်းခွဲ → embed လုပ်ပြီး ခိုင်မာစွာ ထပ်တူကျစေခြင်း) အလွန်စိတ်ဝင်စားဖွယ် ဖြစ်လာမည်။ သို့သော် ယနေ့တွင်မူ စာသား embedding workflow သာ ဖြစ်သည်။

၃) embeddings များသာ လိုအပ်ပါက pgai မလိုအပ်နိုင်ပါ။

သင့် data ထည့်သွင်းမှု pipeline ကို စိတ်ကြိုက်ပြုလုပ်ထားပြီးဖြစ်ပါက (သို့မဟုတ် ထိုသို့ပြုလုပ်ရန် လိုအပ်ပါက) “စာသားအပိုင်းများကို embed လုပ်ခြင်း” သည် RAG ၏ အခက်ခဲဆုံးအပိုင်း မဟုတ်ပါ။ ထိုအခြေအနေတွင် pgai က ပြဿနာ၏ အလွယ်ဆုံးအပိုင်းကိုသာ ဖြေရှင်းပေးနေသည်။

ထို့အပြင် သင့်အသိပညာအခြေခံကို မကြာခဏ အပ်ဒိတ်မလုပ်ပါက embeddings များကို အလိုအလျောက် ထပ်တူကျစေခြင်း၏ တန်ဖိုးမှာ မများလှပါ။

pgai ကို အသုံးချရန် အထူးကောင်းမွန်သည့် နည်းတစ်ခုမှာ သင့် database များပေါ်တွင် text-to-SQL interface တစ်ခု ဖြန့်ကျက်ခြင်းဖြစ်သည်။ pgai က ပံ့ပိုးသည့် semantic_catalog module ဖြင့် ဤအရာကို အလွယ်တကူ လုပ်ဆောင်နိုင်သည်။ အောက်ပါအတိုင်း ရိုးရှင်းစွာ စီစဉ်သတ်မှတ်ပါ။

1OPENAI_API_KEY="your-OpenAPI-key-goes-here"2TARGET_DB="postgres://user:password@host:port/database"3CATALOG_DB="postgres://user:password@host:port/database"

ထို့နောက် pgai semantic-catalog create ဖြင့် semantic catalog ကို သင့် data dictionary များမှ အချက်အလက် စုဆောင်းစေပါ။ ၎င်းက သင့် data store မှ အောက်ပါပုံစံနှင့် ဆင်တူသော context ကို ထုတ်ပေးသည်။

1---2schema: postgres_air3name: aircraft4type: table5description: Lists aircraft models with performance characteristics and unique codes.6columns:7- name: model8  description: Commercial name of the aircraft model.9- name: range10  description: Maximum flight range in kilometers.11- name: class12  description: Airframe class category or configuration indicator.13- name: velocity14  description: Cruising speed of the aircraft.15- name: code16  description: Three-character aircraft code serving as the primary key.17...

ယခု ဤ context ကို pgai က နည်းလမ်းမျိုးစုံဖြင့် အသုံးပြုနိုင်သည်။

Semantic search မှတစ်ဆင့်—

ဤ query က သင်၏ သဘာဝဘာသာစကားဖြင့် မေးမြန်းမှုနှင့် ဆီလျော်နိုင်သည့် table များ၊ function များနှင့် အခြား object များကို ပြန်ပေးမည်။

1pgai semantic-catalog search -p "Your natural language question goes here!"

မူရင်း context ရယူရန်—

၎င်းက သင်၏ သဘာဝဘာသာစကားဖြင့် မေးမြန်းမှုနှင့် သက်ဆိုင်သော မူရင်း YAML context ကို ဖော်ပြပေးမည်။

1pgai semantic-catalog search -p "Your natural language question goes here!" --render

SQL ထုတ်လုပ်ရန်—

သို့မဟုတ် သင့်မေးခွန်းကို ဖြေဆိုရန် လိုအပ်သည့် မူရင်း SQL ကို တိုက်ရိုက်ထုတ်လုပ်နိုင်သည်။ ယခင်အဆင့်မှ context ကို LLM ထံ ပေးပို့ပြီး တုံ့ပြန်ချက်ကို ထုတ်ပေးသည်။

1pgai semantic-catalog generate-sql -p "Your natural language question goes here!"

အတော်လေး ရိုးရှင်းသော RAG စနစ်တစ်ခု တည်ဆောက်နေပြီး အောက်ပါအချက်များကို လိုချင်ပါက pgai ကို စမ်းသုံးကြည့်သင့်သည်။

• အဓိကမှတ်တမ်းစနစ်အဖြစ် Postgres ကို သုံးခြင်း၊

• ချိတ်ဆက် code အနည်းဆုံးသာ ရှိခြင်း၊

• အလိုအလျောက် ထပ်တူကျနေသည့် embeddings များ၊

• သင့် database များတွင် text-to-SQL ကို လျင်မြန်စွာ အသုံးချနိုင်ခြင်း၊

• RAG ကိရိယာအသစ်များနှင့် Postgres extension များကို စမ်းသပ်အသုံးပြုခြင်း။

သင့် RAG pipeline တွင် အောက်ပါတို့ထဲမှ တစ်ခုခု လိုအပ်ပါက pgai ကို အသုံးပြုရန် စောင့်ဆိုင်းသင့်သည်။

• များပြားသော စိတ်ကြိုက် data ထည့်သွင်းမှု သို့မဟုတ် အပိုင်းခွဲခြင်း logic

• parse လုပ်ရန် လိုအပ်ချက်မတူသည့် စာရွက်စာတမ်းအမျိုးအစားများစွာ

• multimodal embeddings

နောက်ဆုံးအနေဖြင့် pgvector ကို ကျယ်ကျယ်ပြန့်ပြန့် လက်ခံအသုံးပြုထားသည်မှာ ထင်ရှားသော်လည်း pgai သည် အလားတူ စိတ်ဝင်စားမှုနှင့် ပံ့ပိုးမှုရရှိမည်လား မသေချာသေးပါ (သက်တမ်း ၁၈ လခန့်သာ ရှိသေးသည်ကို ထည့်သွင်းစဉ်းစားသင့်သော်လည်း)။

pgai သည် ပုံမှန်လုပ်ငန်းဆောင်ရွက်မှုများကို database က ပိုမိုတာဝန်ယူစေပြီး application code ကို ပိုရိုးရှင်းစေသည့် စိတ်ဝင်စားဖွယ် RAG နည်းလမ်းတစ်ခုဖြစ်သည်။

လက်ရှိတွင် ၎င်းသည်—

• ရိုးရှင်းသော RAG တည်ဆောက်မှုများအတွက် အသုံးဝင်ပြီး အမှန်တကယ် သုံးရအဆင်ပြေသည်

• ပိုမိုစိတ်ကြိုက်ပြင်ဆင်ထားသော pipeline များအတွက် ပြောင်းလွယ်ပြင်လွယ်မှု မလုံလောက်ပါ (အထူးသဖြင့် multimodal)

အလားအလာရှိပြီး မည်သို့တိုးတက်လာမည်ကို စောင့်ကြည့်သင့်သည်မှာ သေချာသည်။