Glean အပြည့်အစုံ အသုံးပြုသင်ခန်းစာ: ကုမ္ပဏီအနှံ့ ပြန့်ကျဲနေသည့် အသိပညာကို စကားတစ်ခွန်းနှင့် မေးလိုက်ရုံ အဖြေရအောင်ပြောင်း
ဝန်ထမ်းအသစ် ကုမ္ပဏီဝင်ပထမအပတ်တွင် အမေးများဆုံးမေးခွန်းက «ခွင့်ယူရေးလုပ်ငန်းစဉ်စာရွက်စာတမ်း ဘယ်မှာလဲ» ဖြစ်ပြီး၊ အရရှိဆုံးအဖြေက «ရှာကြည့်ပါဦးမယ်» ဖြစ်သည်။ Glean ဖြေရှင်းလိုသည်က ဤအရာဖြစ်သည်။ ဤဆောင်းပါးက ၄င်းဘာလဲ၊ ဘာလုပ်နိုင်လဲ မှစ၍ connector ဘယ်လိုချိန်၊ permission ဘယ်လိုစီစစ်၊ Agent ဘယ်လိုတည်ဆောက်၊ ထို့ပြင် ကုမ္ပဏီများ ထည့်သွင်းသည့်အခါ အလွယ်ဆုံးထိမိသည့် တွင်းသုံးခုအထိ ဆွဲသွားသည်။
Glean အပြည့်အစုံ အသုံးပြုသင်ခန်းစာ: ကုမ္ပဏီအနှံ့ ပြန့်ကျဲနေသည့် အသိပညာကို စကားတစ်ခွန်းနှင့် မေးလိုက်ရုံ အဖြေရအောင်ပြောင်း
တနင်္လာနေ့ မနက် ကိုးနာရီခွဲ၊ software ကုမ္ပဏီတစ်ခု၏ ဝန်ထမ်းအသစ်တစ်ဦးက ကွန်ပျူတာဖွင့်ကာ ငွေတောင်းခံရန် ဘယ် form version သုံးရမည်ကို သိလိုသည်။ သူ ဘေးက လုပ်ဖော်ကိုင်ဖက်ကို အရင်မေးရာ၊ လုပ်ဖော်က «Google Drive ထဲမှာ ဖြစ်မှာပါ» ဟုဆိုသည်; မိနစ်နှစ်ဆယ် ရှာ၍ မတွေ့တော့ Slack ပေါ်ရှိ ရုံးအုပ်ကို မေးရာ၊ ရုံးအုပ်က Notion link တစ်ခု ပေးလိုက်သည်; ဖွင့်ကြည့်လိုက်တော့ နောက်ဆုံးတည်းဖြတ်ရက်စွဲက ၂၀၂၃ ဖြစ်နေသည်။
ဤမြင်ကွင်းက ကုမ္ပဏီများအတွင်း နေ့စဉ် အကြိမ်ရာနှင့်ချီ ဖြစ်ပျက်နေသည်။ လုပ်ငန်းအသိပညာက မရှိသည်မဟုတ်ဘဲ၊ system ခြောက်ခုထဲတွင် ပြန့်ကျဲနေပြီး ဘယ်တစ်ခုက အတည်ဖြစ်နေဆဲလဲ ဘယ်သူမှ မသိကြခြင်းဖြစ်သည်။ Glean က ဤအရာကို တိုက်ရိုက် ရည်ရွယ်ထားသည်။
Glean ဆိုတာဘာလဲ
Glean သည် လုပ်ငန်းအဆင့် AI ရှာဖွေမှုနှင့် agent platform ဖြစ်သည်။ ၄င်းက သင့်ကို စာရွက်စာတမ်းရွှေ့ခိုင်းခြင်း၊ knowledge base ပြန်ရေးခိုင်းခြင်း မလုပ်ဘဲ — connector များဖြင့် ကုမ္ပဏီ၏ ရှိပြီးသား system များ (Google Drive၊ Slack၊ Confluence၊ Jira၊ Salesforce၊ GitHub စသည်) ကို index လုပ်ကာ တရားဝင် Enterprise Graph ဟုခေါ်သည့် လုပ်ငန်းအသိပညာ graph ကို တည်ဆောက်ပြီး၊ ဝန်ထမ်းများကို သဘာဝဘာသာစကားဖြင့် တိုက်ရိုက်မေးခွင့်ပြုသည်။
သာမန်ရှာဖွေမှုနှင့် အကြီးဆုံးကွာခြားချက် နှစ်ခုရှိသည်။ ပထမက «သင့်ကို နားလည်ခြင်း»: တူညီစွာ «Q3 ပန်းတိုင်» ကို ရှာလျှင်၊ sales မြင်သည်နှင့် engineer မြင်သည့်ရလဒ်က မတူပါ၊ အဘယ်ကြောင့်ဆိုသော် ၄င်းက သင်၏ ဌာန၊ ရာထူးနှင့် ပူးပေါင်းဆက်ဆံရေးကို နားလည်သောကြောင့်ဖြစ်သည်။ ဒုတိယက permission ချက်ချင်းအကျိုးသက်ရောက်ခြင်း — သင် မူလကတည်းက ကြည့်ခွင့်မရှိသည့်အရာကို ရှာ၍မတွေ့ပါ၊ ဤသည်က လုပ်ငန်းထည့်သွင်းမှု၏ အခြေခံမျဉ်းဖြစ်ပြီး၊ ကုမ္ပဏီများစွာက အချက်အလက်ကို ယေဘုယျ AI ထဲ ထည့်ရဲမည်မဟုတ်သည့် အကြောင်းရင်းလည်းဖြစ်သည်။
တရားဝင်အနေဖြင့် ၂၀၂၆ ၅ လပိုင်းတွင် Agent Development Lifecycle (ADLC) ကို ထုတ်ခဲ့ပြီး၊ «လုပ်ငန်းများ AI agent ကို ဘယ်လိုတည်ဆောက်၊ စီမံအုပ်ချုပ်၊ တိုင်းတာမည်» ကို နည်းစနစ်ရှိသည့် framework အဖြစ် ပြောင်းလိုက်သည်၊ ၄င်းသည် search tool မှ agent platform သို့ ဆင့်ကဲပြောင်းလဲရာတွင် အဓိကခြေလှမ်းတစ်ခုဖြစ်သည်။
ဘာလုပ်နိုင်သလဲ
လက်တွေ့တွင် အလွှာသုံးခုခွဲ၍၊ ဤအစီအစဉ်အတိုင်း ထည့်သွင်းရန် အကြံပြုသည်:
- Search: system များဖြတ်ကျော် တစ်ပေါင်းတည်းရှာဖွေမှုဝင်ပေါက်၊ «ဘယ် system သွားရှာရမလဲ» ကို အစားထိုး။
- Assistant: စကားဝိုင်းပုံစံ မေးဖြေ၊ စုစည်းအဖြေပေးပြီး ကိုးကားရင်းမြစ်ပါ၊ မူရင်းစာရွက်စာတမ်းသို့ ပြန်နှိပ်၍ အတည်ပြုနိုင်။
- Agents: အလိုအလျောက်လုပ်ငန်းစဉ်။ တရားဝင်က Agent Library ready-made template (ဌာနအလိုက်ခွဲ၊ engineering၊ HR၊ marketing၊ sales၊ customer service၊ IT ပါ) ပေးပြီး၊ Agent Builder ဖြင့် သဘာဝဘာသာစကားဖြင့် ကိုယ်တိုင်တည်ဆောက်နိုင် — အဓိကသဘောတရားက trigger၊ step၊ action၊ flow နှင့် memory ဆိုသည့် အချက်ငါးခုဖြစ်သည်။
တရားဝင်က connector ၁၀၀ ကျော်ရှိကြောင်း ဖော်ပြပြီး၊ မတူညီသည့် underlying LLM ကို ရွေးသုံးနိုင်သည်။
ဘယ်လိုသုံးမလဲ: အစမှစသည့် ခြေလှမ်းခြောက်ဆင့်
ခြေလှမ်းတစ်: သင့်အချက်အလက်ရင်းမြစ်ကို စာရင်းယူ၊ သို့သော် အားလုံးမချိတ်နဲ့
အစပြုသူ အမှားအများဆုံးက «ရှိသမျှ ချိတ်» ဖြစ်သည်။ ပထမလှိုင်းတွင် တကယ့်အဓိက system သုံးလေးခုကိုသာ ချိတ်ရန် အကြံပြုသည် — များသောအားဖြင့် document library (Google Drive သို့ SharePoint)၊ ဆက်သွယ်ရေး (Slack သို့ Teams)၊ project (Jira သို့ Notion)။ များများချိတ်ရင် အဆုံးသတ်က သက်တမ်းကုန်အမှိုက်တွေ index ဝင်ကာ၊ ဝန်ထမ်းက တစ်ခါမေး၍ အဖြေဆိုးရလျှင် ဒုတိယအကြိမ် ဘယ်တော့မှ မသုံးတော့ပါ။
ခြေလှမ်းနှစ်: connector နှင့် permission mapping ကိုသတ်မှတ်
IT admin က backend တွင် connector တည်ဆောက်ရပြီး၊ system တစ်ခုချင်း၏ admin ခွင့်ပြုချက်လိုသည်။ ဤအဆင့်တွင် အဓိကဆုံးက ချိတ်ဆက်မှုမဟုတ်ဘဲ permission mapping မှန်ကန်ကြောင်း အတည်ပြုခြင်းဖြစ်သည်။ Glean ၏ ဒီဇိုင်းက runtime တွင် permission ကို ချက်ချင်းနှိုင်းယှဉ်သည်၊ သို့သော် ရင်းမြစ် system ၏ permission ကိုယ်တိုင် သန့်ရှင်းရမည်။ သင့်ကုမ္ပဏီ၏ Google Drive တွင် «link သိသူတိုင်း ကြည့်နိုင်» file များ များနေပါက၊ ထိုအရာများ ကုမ္ပဏီတစ်ခုလုံး ရှာနိုင်လာမည် — ထည့်သွင်းမီ permission ကျန်းမာရေးစစ်ဆေးမှု တစ်ကြိမ် အရင်လုပ်ရမည်။
ခြေလှမ်းသုံး: index ပြီးအောင်စောင့်၊ ပြီးရင် ကိုယ်တိုင် တစ်ပတ် အရင်သုံး
index က အချိန်လိုသည်၊ အချက်အလက်များသည့်ကုမ္ပဏီက ရက်အနည်းငယ်ကြာနိုင်သည်။ ပြီးသွားရင် ကုမ္ပဏီတစ်ခုလုံးကို ချက်ချင်းမကြေညာဘဲ၊ IT နှင့် seed user အနည်းငယ်ကို တစ်ပတ် အရင်သုံးစေ၍၊ «သင် အဖြေမှန်သိသည့်» မေးခွန်းဆယ်ခု တကယ်ရှာကာ၊ ၄င်းပေးသည့်အဖြေ မှန်မမှန်၊ ကိုးကားရင်းမြစ် သင့်မသင့် စစ်ပါ။
ခြေလှမ်းလေး: Agent Library ready-made template မှ စ
အစကတည်းက Agent ကိုယ်တိုင်မတည်ဆောက်ပါနှင့်။ တရားဝင် template library မှ သင့်ဌာနနှင့်ဆိုင်သည့် တစ်နှစ်ခု (ဥပမာ customer service ၏ «ကုန်ပစ္စည်း spec ရှာ»၊ HR ၏ «ဝန်ထမ်းအကျိုးခံစားခွင့်မေးခွန်းဖြေ») ကို အရင်ရွေး၍ run ကြည့်ပါ။ template ၏ တန်ဖိုးက trigger နှင့် step ကို ဒီဇိုင်းဆွဲပြီးသားဖြစ်ခြင်း၊ သင် အချက်အလက်ရင်းမြစ်ကိုသာ ချိန်ရသည်။
ခြေလှမ်းငါး: Agent Builder ဖြင့် ကိုယ်ပိုင် ပထမ agent တည်ဆောက်
ရင်းနှီးပြီးမှ သဘာဝဘာသာစကားဖြင့် ကိုယ်ပိုင်တည်ဆောက်ပါ။ ပထမ Agent အတွက် «ထပ်ခါထပ်ခါ၊ စည်းကမ်းရှင်း၊ မှားရင် ကုန်ကျစရိတ်နိမ့်» လုပ်ငန်းကို ရွေးရန် အကြံပြုသည် — ဥပမာ «တနင်္လာတိုင်း ပြီးခဲ့သည့်အပတ် Jira ပေါ်တွင် blocker အဖြစ်သတ်မှတ်ခံရသည့် ပြဿနာအားလုံးကို စုစည်း၍ အနှစ်ချုပ်»။ အဓိကသဘောတရားငါးခုတွင် အလွယ်ဆုံးလျစ်လျူရှုခံရသည်က memory ဖြစ်သည်: ၄င်းက Agent သည် multi-turn ဆက်ဆံမှုတွင် ဘာမှတ်မိမည်ကို ဆုံးဖြတ်ပြီး၊ မှားချိန်လျှင် စကားဝိုင်း ရှေ့နောက်မညီဖြစ်စေမည်။
ခြေလှမ်းခြောက်: အသုံးပြုမှုအချက်အလက်ကြည့်၊ ဘယ်သူမှမသုံးသည့်အရာကို ဖြတ်
ထည့်သွင်းပြီး သုံးလကြာလျှင် အချက်အလက်ကို မဖြစ်မနေ ကြည့်ရမည်: ဘယ် query များဆုံး၊ ဘယ် query ဖြေမရ၊ ဘယ် Agent ကို ဘယ်သူမှ မသုံး။ လုပ်ငန်း AI tool ၏ အသေဆုံးနည်းက မကောင်းလို့မဟုတ်ဘဲ၊ «online ပြီးနောက် ဘယ်သူမှ ပြန်မကြည့်» ခြင်းဖြစ်သည်။
အဆင့်မြင့်နည်းစနစ်
မေးခွန်းကောင်းရေးခြင်းက ထင်ထားသည်ထက် အရေးကြီးသည်။ ယေဘုယျ AI ကို အလွန်ဝိုးဝါးမေးနိုင်သော်လည်း၊ Glean က သင့်ကုမ္ပဏီ၏ အချက်အလက်ပေါ်တွင် ရှာသည်။ «ကျွန်တော်တို့ pricing strategy ဘာလဲ» မေးမည့်အစား၊ «၂၀၂၆ Q2 နောက်ပိုင်း၊ enterprise version plan ၏ လျှော့စျေးအတည်ပြုခွင့် ဘယ်သူ့မှာလဲ» ဟု မေးလျှင် ပိုကောင်းသည် — တိကျသည့် အချိန်၊ ပစ်မှတ်၊ အတိုင်းအတာက ရလဒ်ကို အများကြီးတိကျစေသည်။
ကိုးကားရင်းမြစ်ကို အသိပညာစစ်ဆေးရန် အသုံးချ။ Glean က အဖြေတစ်ခုနှင့် ရင်းမြစ်သုံးခုပေးသည့်အခါ၊ နှစ်ခုက ၂၀၂၃ စာဟောင်းဖြစ်နေလျှင်၊ သင့် knowledge base ကို စည်းစနစ်တကျ လုပ်ရမည့်အချိန်ဖြစ်ကြောင်း ကိုယ်စားပြုသည်။ ၄င်းသည် Glean ၏ လျှော့တွက်ခံရသည့် အသုံးဝင်မှုတစ်ခုဖြစ်သည်: သင့်ကုမ္ပဏီ အသိပညာစီမံခန့်ခွဲမှု ဘယ်လောက်ရှုပ်ပွနေသည်ကို ရိုးသားစွာ ဖော်ထုတ်ပေးသည်။
Agent ကို «မသိရင် မသိဘူးလို့ပြော» သည့် ဘောင် သတ်မှတ်ရမည်။ Agent တည်ဆောက်ချိန်တွင် အချက်အလက်မလုံလောက်ချိန် «သက်ဆိုင်ရာအချက်အလက်မတွေ့ပါ၊ ဌာနတစ်ခုကို ဆက်သွယ်ပါ» ဟုဖြေရန် ရှင်းရှင်းညွှန်ကြားပါ၊ မလုပ်ဘဲ ဇွတ်မတည်ပါစေနှင့်။ ၄င်းသည် အဖြေနှုန်းလိုက်ခြင်းထက် အများကြီး အရေးကြီးသည်။
သတိပြုစရာ
- ၄င်းက သင့်အသိပညာကို စီစဉ်မပေးပါ။ Glean သည် search layer ဖြစ်ပြီး knowledge base မဟုတ်ပါ။ သင့်ကုမ္ပဏီတွင် ဘယ်သူမှ စာရွက်စာတမ်း မရေးလျှင်၊ Glean ရှာထုတ်လာသည်က Slack စကားဝိုင်း အပိုင်းအစများသာ ဖြစ်မည်။ အသိပညာစီစဉ်ခြင်း လိုပါက၊ Guru ကဲ့သို့ verification ရှိသည့် knowledge base tool ကမှ သင့်လျော်ပြီး၊ နှစ်ခုက တကယ်တော့ မကြာခဏ တွဲရှိကြသည်။
- permission ကျန်းမာရေးစစ်ဆေးမှုကို ရှေ့တွင် မဖြစ်မနေလုပ်ရမည်။ ဤအချက်ကို ထပ်ပြောထိုက်သည်။ Glean ထည့်သွင်းပြီးနောက်၊ မူလက «folder အနက်ရှိုင်းတွင် ဝှက်နေသဖြင့် ဘယ်သူမှ မမြင်» သည့် sensitive file များ ရုတ်တရက် အလွယ်တကူ ရှာနိုင်လာမည်။ လုံခြုံရေး ဆိုးမသွားသော်လည်း၊ မြင်နိုင်စွမ်း အလွန်တိုးလာသည်၊ ဤနှစ်ခုကို ခွဲရမည်။
- ကုန်ကျစရိတ် နိမ့်မဟုတ်၊ လုပ်ငန်းအဆင့်ဝယ်ယူမှုဖြစ်။ တရားဝင်က self-service စျေးနှုန်း မထုတ်ဘဲ၊ sales လုပ်ငန်းစဉ်သွားရသည်။ အသေးအလတ်အဖွဲ့က အရွယ်အစားအကျိုးကို အရင်အကဲဖြတ်ရမည်။
- မြန်မာဘာသာအကြောင်းအရာ၏ ရှာဖွေမှုအရည်အသွေးကို ရှေ့တွင် တကယ်စမ်းရမည်။ မြန်မာကုမ္ပဏီ၏ အတွင်းစာရွက်စာတမ်း အများစုက မြန်မာဘာသာဖြစ်ပြီး၊ အင်္ဂလိပ် နည်းပညာဝေါဟာရ ရောနေသည်။ ဤပေါင်းစပ်၏ ရှာဖွေမှုအကျိုးက အင်္ဂလိပ်သက်သက်ပတ်ဝန်းကျင်နှင့် ကွာဟမှုရှိသည်၊ POC အဆင့်တွင် တကယ့်မြန်မာစာရွက်စာတမ်းဖြင့် စမ်းပြီး၊ အင်္ဂလိပ် demo ကြည့်ရုံ စာချုပ်မချုပ်ပါနှင့်။
ကုမ္ပဏီများ ထည့်သွင်းသည့် တွင်သုံးခု
ပထမ၊ tool ဝယ်လိုက်ရုံ အသိပညာစီမံခန့်ခွဲမှု ပြေလည်မည်ဟု ထင်ခြင်း။ tool ဖြေရှင်းသည်က «ရှာတွေ့နိုင်ခြင်း» ဖြစ်၊ «ဘယ်သူမှ မရေးခြင်း» ကို မဖြေရှင်းနိုင်။
ဒုတိယ၊ owner မသတ်မှတ်ခြင်း။ Glean က တစ်ဦးဦးက အချက်အလက်ဆက်ကြည့်၊ connector ချိန်၊ Agent ထိန်းသိမ်းရန် လိုသည်။ ဤအရာက ဘယ်သူ့ KPI ထဲ မဝင်လျှင်၊ ခြောက်လကြာ ဘယ်သူမှ မကြည့်တော့ပါ။
တတိယ၊ permission ကျန်းမာရေးစစ်ဆေးမှု ကျော်လွှားခြင်း။ ကျွန်ုပ်တွေ့ဖူးသည့် အကျပ်တည်းဆုံးဖြစ်ရပ်က ထည့်သွင်းပြီး ဒုတိယအပတ်တွင်၊ ဝန်ထမ်းတစ်ဦးက မကြည့်သင့်သည့် လစာအတိုင်းအတာ file ကို ရှာတွေ့သွားခြင်း — ထို file က မူလကတည်းက permission မှားထားခြင်းဖြစ်ပြီး၊ အရင်က ဘယ်သူမှ ရှာ၍မတွေ့ခဲ့ရုံသာ ဖြစ်သည်။
အခြား tool များနှင့်တွဲ၍ workflow စီစဉ်လိုပါက၊ site ပေါ်ရှိ prompt template နှင့် task အခြေအနေ ကို ကြည့်နိုင်သည်။
TheAI Academy ၏ သုံးသပ်ချက်
ကျွန်ုပ်က လုပ်ငန်း AI tool ကို အမြဲ ရွေးချယ်တတ်သည်၊ အဘယ်ကြောင့်ဆိုသော် ဤ product မျိုး၏ demo က လှပလှပ၊ online ပြီး ဆိုးဆိုးဖြစ်လေ့ရှိသောကြောင့်ဖြစ်သည်။ Glean က ကျွန်ုပ်ကို ပိုတည်ငြိမ်စေသည်က ၄င်း၏ အနေအထားက အလွန်ရိုးသားခြင်းဖြစ်သည် — ၄င်းက အသိပညာစီမံခန့်ခွဲမှုကို အစားထိုးနိုင်ဟု မဟန်ဆောင်ဘဲ၊ «ရှာတွေ့အောင် ကူညီပေးမယ်» ဟုသာ ဆိုသည်။ ဤထိန်းချုပ်မှုက လက်တွေ့တွင် ၄င်းကို ရပ်တည်နိုင်စေသည်။
သို့သော် ပွင့်ပွင့်လင်းလင်းပြောရလျှင်၊ ၄င်း၏ တန်ဖိုးက သင့်ကုမ္ပဏီ၏ အချက်အလက်အရည်အသွေးအပေါ် အလွန်မူတည်သည်။ system တစ်ခုတည်းကို စာရွက်စာတမ်းလုံလုံ့လရေးသည့်ကုမ္ပဏီနှင့် ဘာမဆို နှုတ်ဖြင့်ပြောသည့်ကုမ္ပဏီတွင် တပ်လျှင်၊ အကျိုးက မိုးနှင့်မြေ ကွာမည်။
သုံးသပ်ချက်: Glean သည် အလွန်ကောင်းသည့် search layer ဖြစ်သော်လည်း၊ ၄င်းထင်ဟပ်ပြသည်က သင့်ကုမ္ပဏီ၏ အသိပညာစီမံခန့်ခွဲမှု၏ တကယ့်ပုံရိပ်ဖြစ်သည် — အချက်အလက်ဆိုးလျှင် အဖြေဆိုးမည်။
စာဖတ်သူများအတွက် ကွက်တိအကြံ: ထည့်သွင်းမီ permission ကျန်းမာရေးစစ်ဆေးမှု တစ်ကြိမ်လုပ်၍၊ တာဝန်ခံ တစ်ဦးကို ရှင်းရှင်းလင်းလင်း သတ်မှတ်ပါ။ သင့်ကုမ္ပဏီ လူ ၅၀ အောက်ဖြစ်လျှင် သို့မဟုတ် အတွင်းစာရွက်စာတမ်း မူလကတည်းက နည်းလျှင်၊ Glean ကို အလျင်စလို မကြည့်ဘဲ၊ Notion AI ကဲ့သို့ ပေါ့ပါးသည့်နည်းလမ်းကို ကောင်းကောင်းသုံးခြင်းက ပိုတန်နိုင်သည်။ တကယ်ထည့်သွင်းမည်ဆိုလျှင်၊ POC အဆင့်တွင် မြန်မာဘာသာ တကယ့်စာရွက်စာတမ်းဖြင့် မဖြစ်မနေစမ်းပါ၊ အင်္ဂလိပ် demo ၏ ချောမွေ့မှုဖြင့် မဆွဲဆောင်ခံပါစေနှင့်။
အချက်အလက်ရင်းမြစ်
- Glean တရားဝင် website
- Glean တရားဝင် သတင်းထုတ်ပြန်ချက်: Enterprise Agent Development Lifecycle
- Glean Agents တရားဝင်လမ်းညွှန်
အများသိရှိနိုင်သည့် အချက်အလက်များအရ စုစည်းထားပြီး၊ တရားဝင်ကို အတည်ယူပါ။
မေးလေ့ရှိသောမေးခွန်းများ
Glean နှင့် သာမန် enterprise search ဘာကွာသလဲ?
အဓိကကွာခြားချက်နှစ်ခု: တစ်ခုက ၄င်းက လုပ်ငန်းအသိပညာ graph တည်ဆောက်ကာ သင်၏ ရာထူး၊ ဌာနနှင့် ပူးပေါင်းဆက်ဆံရေးကို နားလည်သဖြင့်၊ query တစ်ခုတည်းကို လူမတူသည့်အခါ ရလဒ်အစီအစဉ် မတူပေးခြင်း; နှစ်ခုက permission ကို runtime တွင် ချက်ချင်းနှိုင်းယှဉ်၍၊ သင် မူလကတည်းက ကြည့်ခွင့်မရှိသည့်အကြောင်းအရာကို ရှာ၍မတွေ့ခြင်း။ ရိုးရာ keyword search က ဤနှစ်ခုကို မလုပ်နိုင်ပါ။
Glean ထည့်သွင်းရန် ကုမ္ပဏီစာရွက်စာတမ်းကို အရင်စီစဉ်ထားရမလား?
ရွှေ့ခြင်း သို့ ပြန်ရေးခြင်း မလိုပါ၊ ဤသည်ကမှ ၄င်းနှင့် knowledge base tool ၏ အကြီးဆုံးကွာခြားချက်ဖြစ်သည် — ၄င်းက သင့်ရှိပြီးသား system ကို index လုပ်သည်။ သို့သော် စိတ်ပြင်ထားရမည်: အချက်အလက်အရည်အသွေးက အဖြေအရည်အသွေးကို ဆုံးဖြတ်သည်။ သင့်ကုမ္ပဏီ၏ စာရွက်စာတမ်း မူလကတည်းက နည်းလျှင် သို့မဟုတ် အချက်အလက်အများစု နှုတ်နှင့် private message တွင်သာ ရှိလျှင်၊ Glean ရှာထုတ်လာသည်က မလှပါ။
မြန်မာကုမ္ပဏီ၏ မြန်မာ-အင်္ဂလိပ်ရော စာရွက်စာတမ်းကို Glean ကိုင်တွယ်နိုင်မလား?
ဤသည်က မြန်မာတွင် ထည့်သွင်းသည့်အခါ အတကယ်စမ်းသင့်ဆုံးအပိုင်းဖြစ်သည်။ မြန်မာလုပ်ငန်းစာရွက်စာတမ်း၏ ပုံစံက မြန်မာအဖွင့်နှင့် အင်္ဂလိပ်နည်းပညာဝေါဟာရ၊ ကုန်ပစ္စည်း code ရောနေခြင်းဖြစ်ပြီး၊ ဤရောနှောဘာသာစကားပတ်ဝန်းကျင်၏ ရှာဖွေမှုအကျိုးက အင်္ဂလိပ်သက်သက်ပတ်ဝန်းကျင်နှင့် ကွာဟမှုရှိသည်။ POC အဆင့်တွင် ကိုယ့်ကုမ္ပဏီ တကယ့်မြန်မာစာရွက်စာတမ်းဖြင့် စမ်းရန် ပြင်းပြင်းထန်ထန် အကြံပြုသည်၊ စက်ရုံ၏ အင်္ဂလိပ်ပြသမှုကိုသာ မကြည့်ပါနှင့်။
ကုမ္ပဏီငယ်များ Glean သုံးထိုက်သလား?
ပွင့်ပွင့်လင်းလင်းပြောရလျှင်၊ လူ ၅၀ အောက်၊ စာရွက်စာတမ်းအရေအတွက်ကန့်သတ်သည့်ကုမ္ပဏီက များသောအားဖြင့် မတန်ပါ။ Glean ၏ တန်ဖိုးက «အချက်အလက်များလွန်း၍ လူ ရှာမတွေ့» ဟူသည့် အခြေခံမှလာသည်၊ အချက်အလက်မလုံလောက်ချိန်တွင် စည်းစနစ်တကျ Notion သို့ ဖိုင်တွဲမျှဝေမှုတစ်ခုက လုံလောက်သည်။ system များဖြတ်ကျော်အချက်အလက်ရှာခြင်းက တကယ် နေ့စဉ်နာကျင်မှုဖြစ်လာမှ စဉ်းစားလည်း မနောက်ကျပါ။