ပင်မ လမ်းညွှန်မှု

စိတ်ကြိုက် RAG ဖြေရှင်းချက်များ၏ လက်တွေ့ဥပမာများ

စိတ်ကြိုက် retrieval-augmented generation စနစ်များက လုပ်ငန်းသုံးဗဟုသုတဆိုင်ရာ ရှုပ်ထွေးသည့် ပြဿနာများကို ဖြေရှင်းပုံအား လက်တွေ့ဥပမာများဖြင့် ဖော်ပြထားသည်။

ယနေ့ခေတ်တွင် RAG ကို အပြစ်မြင်တတ်ကြသည်။ အကြောင်းမှာ အချို့က ၎င်းကို လုံးဝရိုးရှင်းသည်ဟု ယူဆကြလို့ဖြစ်သည် (စတင်ရန်တော့ ရိုးရှင်းသော်လည်း အရွယ်အစားချဲ့ရန် မလွယ်ပါ)။ အချို့ကလည်း ‘agentic systems’ များက RAG ကို ကျော်တက်သွားပြီဟု ထင်ကြသည် (သို့သော် မျက်နှာပြင်အောက် အနည်းငယ်လေ့လာလိုက်လျှင် အများစုသည် RAG နှင့် အလွန်ဆင်တူနေတတ်သည်…)။

ဤဘလော့ဂ်တွင် အောက်ပါအဖြစ်များသော စိန်ခေါ်မှုများကို ကျွန်ုပ်တို့ ဖြေရှင်းပုံအား လက်တွေ့ဥပမာတစ်ခုနှစ်ခုဖြင့် ဖော်ပြထားသည်—

  • စာသားနှင့် ကိန်းဂဏန်းဒေတာ ရောနှောမှုကို ကိုင်တွယ်ခြင်းနှင့် ၎င်းကြောင့် ရိုးရှင်းသော RAG ပျက်ကွက်ရပုံ—သော့ချက်စကားလုံးများ ထပ်တူကျပြီး ကိန်းဂဏန်းများတွင် အဓိပ္ပာယ်ဆိုင်ရာ ဆက်နွှယ်မှုမရှိပါ။

  • အနှစ်ချုပ်ကို ဦးစားပေးသည့် embedding ဒီဇိုင်းက ကူညီပုံ— chunk တစ်ခုစီအတွက် ဖော်ပြချက်အကျဉ်းတစ်ခု ဖန်တီးပြီး ထိုအနှစ်ချုပ်ကို embed လုပ်ကာ query ရှာပါ။

  • ဆက်စပ်အကြောင်းအရာပါ အနှစ်ချုပ်များ ဖန်တီးပုံ— ပုံစံတူသော ကိန်းဂဏန်းများကို ခွဲခြားနိုင်ရန် မူရင်းစာတမ်း၏ ဆက်စပ်အကြောင်းအရာကို ထည့်ပါ။

  • ကုဒ်နှင့် Pydantic မော်ဒယ်များကို အားကိုးသင့်သည့်အချိန်— မူရင်းအတိုင်း အတိအကျထားရန် အရေးကြီးသည့်နေရာများတွင် ယုံကြည်စိတ်ချရစေရန် စိတ်ကြိုက်ကုဒ်နှင့်/သို့မဟုတ် Pydantic မော်ဒယ်ကို LLM ခေါ်ဆိုမှုများနှင့် တွဲသုံးပါ။

စိတ်ကြိုက် RAG ဖြေရှင်းချက်များ တည်ဆောက်ခြင်း

အခြေခံများ

RAG စနစ်များက အကူအညီပေးသည့် bot များမှ အဖွဲ့တွင်းဗဟုသုတ အကူစနစ်များအထိ လုပ်ဆောင်ပေးသည်။

နောက်ကွယ်တွင် ပုံမှန်အားဖြင့် အောက်ပါအတိုင်း လုပ်ဆောင်သည်—

  1. မူရင်းစာတမ်းများကို chunk များအဖြစ် ခွဲပါ

  2. chunk တစ်ခုစီကို vector space ထဲသို့ embed လုပ်ပါ

  3. query မေးသည့်အခါ အကိုက်ညီဆုံး chunk K ခုကို ပြန်လည်ရှာဖွေပါ

  4. ထို chunk များကို အခြေခံ၍ အဖြေတစ်ခု ဖန်တီးပါ

LangChain၊ LlamaIndex နှင့် OpenAI ၏ Filestore ကဲ့သို့ လူသုံးများသော toolkit များကြောင့် ထိုအဆင့်များက အလွန်လွယ်ကူလာသည်။ သို့သော် လက်တွေ့ pipeline များတွင် စာသားသက်သက်မဟုတ်သော ဒေတာများနှင့် ကြုံရမည်ဖြစ်ပြီး အခြေခံ RAG က ၎င်းတို့ကို ကောင်းစွာမကိုင်တွယ်နိုင်ပါ။ အောက်ပါကဏ္ဍများတွင် ဒေတာဆိုင်ရာ စိန်ခေါ်မှုများကို လက်တွေ့ဥပမာများဖြင့် ပြသပြီး ရှုပ်ထွေးမှု တိုးလာသည်နှင့်အမျှ ဖြေရှင်းချက်ကို တစ်ဆင့်ချင်း တည်ဆောက်သွားမည်။

အခြေအနေ ပိုမိုရှုပ်ထွေးလာသည့်အခါ

  1. သင့်ဒေတာက စာသားသက်သက် မဟုတ်သည့်အခါ (တကယ်တော့ အဖြစ်များပါသည်)

ဂိမ်းနှင့်ဆိုင်သော အောက်ပါဒေတာ chunk ကို စဉ်းစားကြည့်ပါ—

JSON

{ "Attack": { "Range": { "default": 5, "with_Draconic_Ascension": 5.5, }, "Speed": { "default": "2 seconds", "with_Draconic_Ascension": "2.2 seconds", }, "Damage": { "default": 10, "with_Draconic_Ascension": 12, } }}

Embedding များ အလုပ်လုပ်နိုင်ခြင်းမှာ အဓိပ္ပာယ်နှင့် သဒ္ဒါမှတစ်ဆင့် စကားလုံးများအကြား သင်ယူထားသည့် ဆက်နွှယ်မှုများကြောင့် ဖြစ်သည်။ အထက်ပါဒေတာတွင် စာသားနှင့် ကိန်းဂဏန်းများ ရောနှောနေပြီး ဤသီးခြားဆက်စပ်အကြောင်းအရာမှ ခွဲထုတ်လိုက်ပါက ကိန်းဂဏန်းများနှင့် စကားလုံးများအကြား ဆက်နွှယ်မှုမရှိပါ။ ထို့ကြောင့် ဤဒေတာ chunk သည် အနည်းငယ်ဖော်ပြပေးနိုင်သော စကားလုံးများနောက်တွင် ကျပန်းကိန်းဂဏန်းအချို့ လိုက်ပါလာသည့် ပေါင်းစပ်မှုသာ ဖြစ်သည်ဟု ဆိုနိုင်သည်။

ကျွန်ုပ်တို့တွင် ဤဒေတာအမျိုးအစားတစ်မျိုးတည်းသာ ရှိပါက ပြဿနာမဖြစ်ပါ။ ရှိနေသော ဖော်ပြချက်စကားလုံးအနည်းငယ်၏ embedding များဖြင့် ရှာနိုင်သေးသည် (သို့မဟုတ် text-to-SQL ကိုသာ သုံးနိုင်သည်)။ သို့သော် ဤစကားလုံးများ ပါဝင်သည့် စာသားထူထပ်သော chunk အများအပြားကြားတွင် ယခု chunk မြုပ်နေပါက မည်သို့ဖြစ်မည်နည်း။ ဥပမာ—

JSON

{"Draconic_Ascension": { "description": "Transform into dragon form. Attack range and speed are increased by 10%, damage is boosted by 20%.", "details": { "activation_conditions": "Can only be activated when HP is below 50%or Fury meter is full.", "visual_effects": "Wings unfurl, scales shimmer with embers, voice lines change to echoing growls.", "lore": "An ancient bloodline awakens. The bearer of the mark channels the soul of the last Flamewing Wyrm, becoming a living storm of fire and fury." } }}

ယခု “What is the attack range with Draconic Ascension?” ကို ရှာလိုသည်ဟု စိတ်ကူးကြည့်ပါ။ လိုချင်သည့် သက်ဆိုင်ရာ chunk ကို ရှာတွေ့နိုင်ဖွယ်မရှိပါ။ အကြောင်းမှာ တူညီသော သော့ချက်စကားလုံးများပါသည့် အခြား chunk များ၏ ဆူညံမှုကြားတွင် ၎င်းက မြုပ်နေသောကြောင့် ဖြစ်သည်။

အဓိကပြဿနာမှာ ဤဒေတာ chunk များသည် အကြောင်းအရာတူသည့်တိုင် မတူညီသော သတင်းအချက်အလက်အမျိုးအစားများ ပါဝင်နေခြင်းကို ကောင်းစွာခွဲခြားမရခြင်း ဖြစ်သည်။ ၎င်းကို တစ်နည်းနည်းဖြင့် အချက်အလက်ဖြည့်စွက်ပြီး ပိုကောင်းအောင် လုပ်နိုင်မလား။ လုပ်နိုင်တာပေါ့ :smile:

  1. သင့်ဒေတာကို အနှစ်ချုပ်ခြင်းဖြင့် ပိုမိုပြည့်စုံအောင်လုပ်ပါ၊ ဟုတ်ပါတယ်၊ ဖတ်လိုက်တာ မမှားပါဘူး

chunk ကို တိုက်ရိုက် embed လုပ်မည့်အစား ဒေတာအကြောင်း ဖော်ပြသည့် အနှစ်ချုပ်တစ်ခုကို ဦးစွာဖန်တီးပြီး ထိုအနှစ်ချုပ်ကို embed လုပ်ကာ ရှာဖွေနိုင်သည်။ အဖြေဖန်တီးသည့်အဆင့်တွင် အနှစ်ချုပ်နှင့် ချိတ်ဆက်ထားသော မူရင်းဒေတာကိုသာ ဆက်လက်အသုံးပြုမည်။

ထို့ကြောင့် အထက်ပါ chunk ဥပမာနှစ်ခုအတွက် အောက်ပါကဲ့သို့ အနှစ်ချုပ်များ ဖန်တီးမည်—

  1. တိုက်ခိုက်နိုင်သည့်အကွာအဝေး၊ အမြန်နှုန်းနှင့် ထိခိုက်မှုဆိုင်ရာ ကိန်းဂဏန်းများ (ပုံမှန်နှင့် Draconic Ascension သုံးထားချိန်)။

  2. ဖွင့်သုံးရန် သတ်မှတ်ချက်များ၊ မြင်ကွင်းအထူးပြုလုပ်ချက်များနှင့် နောက်ခံဇာတ်ကြောင်းအပါအဝင် Draconic Ascension ၏ ဖော်ပြချက်နှင့် အသေးစိတ်အချက်များ။

ထို့နောက် အနှစ်ချုပ်နှင့် “ကိုက်ညီ” စေရန် query ကိုလည်း ဖြည့်စွက်ပြင်ဆင်သည်။ ဥပမာ “What is the attack range with Draconic Ascension?” ကို “What is the statistics of attack range with Draconic Ascension?” ဟု ပြောင်းမည်။ နည်းပညာနယ်ပယ်ပြင်ပမှ သုံးစွဲသူများက ~~“freestyle”~~ သာမန်လူသုံးစကားဖြင့် retrieval query မေးလာသည့်အခါ ၎င်းသည် အထူးအရေးကြီးသည်။ အဘယ်ကြောင့်ဆိုသော် RAG က precision/recall ကို အမြင့်ဆုံးရအောင် မည်သို့လုပ်ဆောင်သည်ကို သိရန်မှာ သူတို့၏ အသိပညာ သို့မဟုတ် စိတ်ဝင်စားမှုအပိုင်း မဟုတ်သောကြောင့်ဖြစ်သည်။

အခြေအနေ ပိုမိုရှုပ်ထွေးလာပုံကို ဖော်ပြသည့် ပုံကြမ်း။

  1. အကြောင်းအရာတစ်ခုကို ဆက်စပ်အခြေအနေမှ ခွဲမထုတ်ပါနှင့် (ဘဝတွင်လည်း ယေဘုယျအားဖြင့် သက်ဆိုင်သည်)

နောက်ထပ်အခြေအနေတစ်ခုမှာ အောက်ပါအတိုင်း ပုံစံတူနေသည့် ဒေတာ chunk အမြောက်အမြားကို ကိုင်တွယ်ရခြင်း ဖြစ်သည်—

Plain Text

# Chunk one{ "Attack": { "Range": { "default": 9, }, ... }}# Chunk two{ "Attack": { "Range": { "default": 6, }, ... }}# Chunk three{ "Attack": { "Range": { "default": 7, }, ... }}

ယခင်နည်းလမ်းအတိုင်း ဆက်လုပ်ပြီး “what is character X’s attack range?” ဟု မေးသည်ဆိုပါစို့။ ယခုဖန်တီးထားသည့် အနှစ်ချုပ်များကလည်း အလွန်ဆင်တူမည်ဖြစ်သောကြောင့် ကံကို အားကိုးပြီး မှန်းဆရသလို ဖြစ်နေမည်။ ထိုသို့ဆိုလျှင် ၎င်းတို့ကို မည်သို့ခွဲခြားနိုင်မည်နည်း။

ရိုးရှင်းသောအဖြေက ဆက်စပ်အကြောင်းအရာ ထည့်ပေးရန်ဖြစ်သည်။ ဒေတာ chunk ထဲတွင် ၎င်း၏ မူရင်းစာတမ်းကို ရည်ညွှန်းချက်တစ်ခု ရိုးရိုးထည့်နိုင်သည်။ ဤကိစ္စတွင် ဥပမာ {”character”: “X”} ဖြစ်သည်။ ထိုအခါ ဇာတ်ကောင် Y နှင့် Z အတွက် တူညီသောဒေတာရှိနေလျှင်ပင် ဇာတ်ကောင် X ၏ မှန်ကန်သောဒေတာကို တိကျစွာရှာနိုင်မည်။

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

  1. ဤ chunk တွင် ဇာတ်ကောင် X အတွက် … ၏ အသေးစိတ်ကိန်းဂဏန်းများကို ဖော်ပြထားသည်။ တိုက်ခိုက်မှုအမြန်နှုန်းတွင် X ၏ အားသာချက်ကို ပြသခြင်းဖြင့် ဤ chunk သည် စာတမ်းတစ်ခုလုံးနှင့် ဆက်စပ်နေသည်…

  2. ဤ chunk တွင် ဇာတ်ကောင် Y အတွက် … ၏ အသေးစိတ်ကိန်းဂဏန်းများကို ဖော်ပြထားသည်။ Y ၏ အထူးစွမ်းရည်ကြောင့် မြင့်တက်လာသော ကိန်းဂဏန်းများကို ပြသခြင်းဖြင့် ဤ chunk သည် စာတမ်းတစ်ခုလုံးနှင့် ဆက်စပ်နေသည်…

  3. ဤ chunk တွင် ဇာတ်ကောင် Z အတွက် … ၏ အသေးစိတ်ကိန်းဂဏန်းများကို ဖော်ပြထားသည်။ အသင်းလိုက်ပွဲများတွင် tank အဖြစ် ကောင်းစွာသင့်တော်သော Z ၏ ကိန်းဂဏန်းများကို ပြသခြင်းဖြင့် ဤ chunk သည် စာတမ်းတစ်ခုလုံးနှင့် ဆက်စပ်နေသည်…

ဤနည်းလမ်းသည် (Anthropic ထံမှ တစ်စိတ်တစ်ပိုင်း အကြံယူထားသည်) အထက်ပါဥပမာအတွက် လိုအပ်သည်ထက် ပိုရှုပ်ထွေးသလို ထင်ရနိုင်သည်။ သို့သော် “ဆက်စပ်အခြေအနေမှ ခွဲထုတ်လိုက်သောအခါ” အဓိပ္ပာယ်လွဲနိုင်သည့် chunk များအတွက် အလွန်ထိရောက်သည်။ ထို့အပြင် chunk အားလုံးအတွက် အသုံးပြုနိုင်သော တစ်ပြေးညီနည်းလမ်းဖြစ်၍ အင်ဂျင်နီယာ pipeline ကိုလည်း စနစ်တကျရှိစေသည်။

အခြေအနေ ပိုမိုရှုပ်ထွေးလာပုံကို ဖော်ပြသည့် ပုံကြမ်း။

  1. ~~အရာရာကို ထိန်းချုပ်ချင်သူ~~ တိကျစနစ်ကျရန် လိုအပ်သည့်အခါ

ပုံမှန်အားဖြင့် ဒေတာအပြည့်အစုံကို ရရှိပြီးနောက် RAG စနစ်အတွက် chunk များအဖြစ် ခွဲသည်။ ဤဥပမာတွင် အနည်းငယ်ကွဲပြားသောအခြေအနေကို ပြထားသည်—chunk များအဖြစ် ခွဲပြီးသားဖြစ်သော်လည်း မကောင်းသည့် chunk များဖြစ်သည်။ ၎င်းတို့သည် အမှန်တကယ် ပြန်လည်စုစည်းရန်လိုသော ယုတ္တိကျ chunk တစ်ခုမှ ကျပန်းဖြတ်ပိုင်းများဖြစ်သည်။ ယုတ္တိကျ chunk ဆိုသည်မှာ စာတမ်း၏ ကဏ္ဍခွဲတစ်ခု သို့မဟုတ် အကြောင်းအရာဆက်စပ်သည့် စာပိုဒ်တစ်ပိုဒ်ကဲ့သို့ သဘာဝအလျောက် အတူရှိသင့်သော အကြောင်းအရာအစုကို ဆိုလိုသည်။

အခြေအနေ ပိုမိုရှုပ်ထွေးလာပုံကို ဖော်ပြသည့် ပုံကြမ်း။

ဤဒေတာအတွက် ပထမဆုံးကြိုးပမ်းမှုမှာ အားလုံးကို LLM ခေါ်ဆိုမှုတစ်ခုထဲ ထည့်ပြီး သင့်တော်သလို အုပ်စုဖွဲ့ကာ အုပ်စုဖွဲ့ထားသော အကြောင်းအရာကို ပြန်ပေးရန် တောင်းဆိုခြင်းဖြစ်သည်။ LLM က ဒါမျိုး တော်တော်ကောင်းကောင်း လုပ်နိုင်သင့်တယ်မဟုတ်လား။ ကောင်းပါတယ်၊ ဒါပေမဲ့ အမြဲတော့မဟုတ်ပါဘူး။

အခြားအကြိမ်များစွာတွင်လည်း တွေ့ရသကဲ့သို့ အကြောင်းအရာအပြည့်အစုံနှင့် အတိအကျလိုအပ်သည့်အခါ LLM များသည် အလုပ်လျှော့လုပ်တတ်ပြီး ယုံကြည်စိတ်ချရမှုမရှိပါ။ အထူးသဖြင့် context ရှည်လျားသည့်အခါ ပိုဆိုးသည်။ ဒါကလည်း လုံးဝသဘာဝကျပါတယ်။ သို့သော် ဤအသုံးပြုမှုအတွက်တော့ လက်မခံနိုင်ပါ။ အကြောင်းမှာ အကြောင်းအရာကို စကားလုံးတိုင်း မူရင်းအတိုင်း အတိအကျလိုအပ်သောကြောင့်ဖြစ်သည်—အနှစ်ချုပ်ခြင်းမရှိ၊ မူရင်းအကြောင်းအရာ၏ မည်သည့်အပိုင်းကိုမျှ ချန်ထားခြင်းမရှိရပါ။ မည်သည့်အသေးစိတ်အချက်ကိုမျှ လွတ်သွား၍မရပါ။

အခြားတစ်ဖက်တွင်တော့ ပျက်နေသော chunk များ၏ အဓိပ္ပာယ်နှင့် ဖွဲ့စည်းပုံကို နားလည်ရာတွင် အလွန်ကောင်းမွန်စွာ လုပ်ဆောင်နိုင်ခဲ့သည်။ အကြောင်းအရာအတိအကျကို ပြန်လည်ဖော်ပြရန်သာ မငြင်းလျှင်ပေါ့။ တကယ်စိတ်ပျက်စရာပဲ :/

ဒါဆို LLM ကျွမ်းကျင်သည့်အရာကို အသုံးချပြီး ၎င်းစိတ်မချရသည့်အပိုင်းကို မည်သို့ရှောင်နိုင်မည်နည်း။ ကျွန်ုပ်တို့၏ မိတ်ဆွေဟောင်း ကုဒ်ထံ ပြန်လှည့်ခဲ့သည် (စိတ်ကြိုက် Python function ဟု ဖတ်ပါ)။ ထို့အပြင် “ဒီထက်မရိုးရှင်းနိုင်တော့သည့်” Pydantic မော်ဒယ်တစ်ခုကိုလည်း သုံးခဲ့သည်။ ဖြေရှင်းနည်းမှာ—

  • လက်ရှိယုတ္တိကျ chunk ကို ထိန်းသိမ်းထားရင်း ကဏ္ဍများကို တစ်ခုပြီးတစ်ခု ဖြတ်သန်းပါ။

  • ကဏ္ဍတိုင်းတွင် “ဤကဏ္ဍသည် လက်ရှိယုတ္တိကျ chunk ထဲ ပါဝင်သလား၊ yes သို့မဟုတ် no ဖြေပါ (Pydantic မော်ဒယ်အတိုင်း)” ဟု LLM ကို မေးပါ။

  • yes ဆိုပါက ထိုကဏ္ဍကို chunk တွင် ပေါင်းထည့်ပါ။ no ဆိုပါက လက်ရှိယုတ္တိကျ chunk ပြီးဆုံးပြီဖြစ်၍ မူရင်းအတိုင်း ထုတ်ယူပြီး ထိုကဏ္ဍဖြင့် chunk အသစ် စတင်ပါ။

အခြေအနေ ပိုမိုရှုပ်ထွေးလာပုံကို ဖော်ပြသည့် ပုံကြမ်း။

အကြောင်းအရာအပြည့်အစုံကို တစ်ကြိမ်တည်း ဖြတ်သန်းခြင်းထက် token အနည်းငယ်ပိုသုံးရသည်မှာ မှန်ပါသည်။ သို့သော် အကြောင်းအရာအတိအကျကို ထိန်းသိမ်းနိုင်ခြင်းက အဓိကဦးစားပေးဖြစ်သည့် ဤအသုံးပြုမှုအတွက်တော့ ထိုအပိုကုန်ကျစရိတ်အနည်းငယ်က အလွန်တန်ပါသည်။

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

စိတ်ကြိုက်ကုဒ်/function များနှင့် Pydantic မော်ဒယ်များကို အသုံးပြုခြင်းဖြင့် LLM များ၏ စွမ်းဆောင်ရည်ကို အပြည့်အဝအသုံးချရင်း ကြိုတင်ခန့်မှန်းနိုင်ပြီး ယုံကြည်စိတ်ချရသော ရလဒ်ကို ရရှိနိုင်သည်။

အနှစ်ချုပ်

မျိုးဆက်သစ် AI ဖြေရှင်းချက်တစ်ခု တည်ဆောက်ခြင်းသည် AI ဆိုင်ရာ စိန်ခေါ်မှုဖြစ်သကဲ့သို့ အင်ဂျင်နီယာဆိုင်ရာ စိန်ခေါ်မှုလည်း ဖြစ်သည်။ ဤဥပမာများက သင့်ကိုယ်ပိုင်ထူးခြားသည့် စိန်ခေါ်မှုများကို ဖြေရှင်းရန် စိတ်အားတက်ကြွစေမည်ဟု မျှော်လင့်ပါသည်။ အင်ဂျင်နီယာကို ဦးစားပေးသည့် မျိုးဆက်သစ် AI ဖြေရှင်းချက်များအကြောင်း ပိုမိုဖတ်ရှုရန် router အခြေပြု agentic system ဒီဇိုင်းဆိုင်ရာ ဘလော့ဂ်ပို့စ်ကို ကြည့်ပါ။

စာရေးသူ

Cynthia Yu