နည်းပညာတစ်ခု လေ့လာပြီးရင် note ရေးထားဖြစ်တယ်။ နောက်ပိုင်း ပြန်လိုလာတဲ့အခါ အဲဒီ note ကို ပြန်ရှာတယ်။
ကျွန်တော်က အဲဒီ learning notes တွေကို Obsidian မှာ သိမ်းထားတယ်။ ဒီ notes တွေထဲက တချို့ကို search လုပ်ပေးနိုင်တဲ့ system လေးတစ်ခုလည်း စမ်းရေးဖြစ်ခဲ့တယ်။
Notes တွေ များလွန်းလို့ ရှာမရတော့တာမျိုးတော့ မဟုတ်ဘူး။ ရိုးရိုး keyword search နဲ့လည်း ရှာလို့ရသေးတယ်။ အဓိကက ကိုယ်တကယ်သုံးတဲ့ data နဲ့ retrieval နဲ့ evaluation ကို လက်တွေ့လေ့ကျင့်ချင်လို့ပါ။
စမ်းရင်းနဲ့ search result အပြင်၊ အဲဒီ result ကို စစ်ပေးတဲ့ test ကိုပါ ပြန်ကြည့်ဖြစ်သွားတယ်။
Result ပြန်လာရုံနဲ့ မပြီးသေးဘူး
Retrieval ဆိုတာ မေးခွန်းတစ်ခုနဲ့ သက်ဆိုင်တဲ့အကြောင်းအရာကို ပြန်ရှာပေးတဲ့အပိုင်းပါ။ ဒီ project မှာတော့ ကိုယ့် learning notes တွေထဲက သက်ဆိုင်တဲ့အပိုင်းတွေကို ရှာပေးတာပေါ့။
ဒါပေမယ့် result တစ်ခု ပြန်လာတိုင်း အသုံးဝင်တယ်လို့ ပြောလို့မရဘူး။ မေးခွန်းနဲ့ ဆိုင်သလား၊ လိုတဲ့အချက်အလက် ပါသလားဆိုတာ စစ်ဖို့လိုတယ်။
အဲဒါကြောင့် test questions တွေ ပြင်ဆင်ပြီး မေးခွန်းတစ်ခုစီအတွက် ပြန်တွေ့စေချင်တဲ့ note ကို သတ်မှတ်ထားခဲ့တယ်။ အဲဒီ expected note တွေက test ရဲ့ answer key ပေါ့။
ဒီလိုစစ်ကြည့်တဲ့အခါ စိတ်ဝင်စားစရာ result တစ်ခု တွေ့ခဲ့တယ်။
မျှော်လင့်ထားတဲ့ Note မဟုတ်ပေမယ့် အဖြေပါတယ်
Error budget အကြောင်း မေးထားတဲ့ question တစ်ခုမှာ search က roadmap ထဲက Reliability အပိုင်းကို ပထမ result အဖြစ် ပြန်ပေးခဲ့တယ်။
အဲဒီအပိုင်းမှာ မေးခွန်းအတွက် သက်ဆိုင်တဲ့အဖြေ ပါနေတယ်။ ဒါပေမယ့် answer key မှာ လက်ခံထားတာက တခြား note တစ်ခု ဖြစ်နေတယ်။
Test ကတော့ သတ်မှတ်ထားတဲ့ note နဲ့ မကိုက်လို့ miss လို့တွက်လိုက်တယ်။
ဒီမှာ ပြန်စဉ်းစားရတာက—ရှာတွေ့တဲ့ note က မေးခွန်းကို ဖြေနိုင်ရင်၊ ကိုယ်မျှော်လင့်ထားတဲ့ note မဟုတ်တာတစ်ခုတည်းနဲ့ မှားတယ်လို့ သတ်မှတ်သင့်လား?
သဘောတရားကို ရှင်းပြထားတဲ့ ပုံပါ။ တကယ့် test screen သို့မဟုတ် note ထဲက စာသားတွေ မဟုတ်ပါဘူး။
ပြန်ပြင်ရတာက Answer Key
ဒီ case မှာ search result ကိုပဲ ကြည့်လို့ မရတော့ဘူး။ ကိုယ်ရေးထားတဲ့ answer key က လက်ခံနိုင်တဲ့အဖြေကို ကျဉ်းကျဉ်းပဲ သတ်မှတ်ထားမိတာလားဆိုတာပါ ပြန်ကြည့်ဖို့လိုလာတယ်။
အဲဒီနောက် မေးခွန်းတစ်ခုအတွက် မှန်ကန်တဲ့ source note တစ်ခုထက်ပိုရှိရင် လက်ခံနိုင်အောင် answer key ကို ပြင်ခဲ့တယ်။
ဒီပြင်ဆင်မှုက search ကို ပိုကောင်းသွားအောင် လုပ်လိုက်တာ မဟုတ်ဘူး။ ရှာတွေ့ပြီးသား result ကို ပိုသင့်တော်တဲ့နည်းနဲ့ စစ်နိုင်အောင် ပြင်လိုက်တာပါ။
ဒီနှစ်ခုကို ခွဲသိထားဖို့လိုတယ်။ မဟုတ်ရင် score တက်လာတာကို search ပိုကောင်းလာပြီလို့ ထင်မိနိုင်တယ်။
“ဆိုင်တယ်” နဲ့ “ဖြေနိုင်တယ်” ကလည်း မတူဘူး
ဒါဆို topic တူတဲ့ note မှန်သမျှ လက်ခံလိုက်ရင် ရပြီလားဆိုတော့ မရသေးဘူး။
မေးခွန်းထဲက စကားလုံးတွေ ပါနေပေမယ့် လိုတဲ့အဖြေ မပါနိုင်ဘူး။ အကြောင်းအရာချင်း ဆက်စပ်ပေမယ့် မေးထားတဲ့အချက်ကို ဖြေဖို့ မလုံလောက်တာလည်း ဖြစ်နိုင်တယ်။
Result တစ်ခုကို လက်ခံမယ်ဆိုရင် ဒီအချက်တွေကို ကြည့်ဖို့လိုတယ်။
- မေးထားတဲ့အချက်အတွက် အဖြေ တကယ်ပါသလား?
- ဘယ်စာပိုဒ်က အဲဒီအဖြေကို ထောက်ပံ့ပေးထားသလဲ?
- Topic တူနေရုံလား၊ မေးခွန်းကို ဖြေဖို့ လုံလောက်သလား?
ကိုယ်သဘောကျတဲ့ result တစ်ခုကို pass ဖြစ်အောင် ပြင်တာမျိုး မဖြစ်ဖို့လည်း လိုတယ်။ လက်ခံတဲ့အကြောင်းရင်းကို ရှင်းပြနိုင်ရမယ်။ တခြား result တွေကိုလည်း အဲဒီစံနဲ့ပဲ စစ်ရမယ်။
ဒီ Project ကနေ မှတ်ထားမိတာ
ဒီစမ်းသပ်မှုက ကိုယ့် notes အနည်းငယ်နဲ့ လုပ်ထားတဲ့ learning project ပါ။ ဒီမှာ အဆင်ပြေတာနဲ့ တခြား data တွေမှာလည်း အတူတူအလုပ်လုပ်မယ်လို့ မပြောနိုင်သေးဘူး။
နောက်ပြီး ဒီ test က သက်ဆိုင်တဲ့ source ကို ရှာတွေ့သလားဆိုတာ စစ်တာပါ။ အဲဒီ source ကိုသုံးပြီး AI က နောက်ဆုံးရေးပေးတဲ့အဖြေ မှန်သလားဆိုတာက သီးခြားစစ်ဖို့လိုသေးတယ်။
ကျွန်တော် မှတ်ထားမိတာကတော့ ရိုးရိုးလေးပါပဲ။
Test မှာ fail ဖြစ်တဲ့ result ကို ပြန်ဖတ်ကြည့်ဖို့လိုသလို၊ အဲဒီ test က ဘာကို မှန်တယ်လို့ သတ်မှတ်ထားလဲဆိုတာလည်း ပြန်ကြည့်ဖို့လိုတယ်။
ဒီတစ်ခါတော့ search result ကနေ ပြဿနာစတွေ့ပြီး ကိုယ်ရေးထားတဲ့ answer key ကို ပြန်ပြင်ဖြစ်သွားတယ်။