Feature Store (ຟີເຈີສະໂຕ)

Feature Store (フィーチャーストア) ແມ່ນພື້ນຖານຂໍ້ມູນສຳລັບການຈັດການ ແລະ ນຳໃຊ້ຄຸນລັກສະນະ (Feature) ທີ່ໃຊ້ໃນການຝຶກຝົນ ແລະ ການຄາດຄະເນຂອງແບບຈຳລອງ Machine Learning ຄືນໃໝ່. ມັນມີບົດບາດໃນການຫຼຸດຜ່ອນວຽກງານທີ່ຊ້ຳຊ້ອນໃນການພັດທະນາແບບຈຳລອງ ແລະ ຮັບປະກັນຄວາມສອດຄ່ອງຂອງຄຸນລັກສະນະລະຫວ່າງສະພາບແວດລ້ອມການຝຶກຝົນ ແລະ ສະພາບແວດລ້ອມການນຳໃຊ້ຈິງ (Production).

ເປັນຫຍັງຈຶ່ງຕ້ອງມີ Feature Store?

ເມື່ອໂຄງການ Machine Learning ເພີ່ມຂຶ້ນພາຍໃນອົງກອນ, ມັກຈະເກີດຄວາມບໍ່ມີປະສິດທິພາບທີ່ທີມງານໜຶ່ງສ້າງຄຸນລັກສະນະຂຶ້ນມາໃໝ່ ໃນຂະນະທີ່ອີກທີມໜຶ່ງກໍໄດ້ສ້າງຄຸນລັກສະນະດຽວກັນນັ້ນໄວ້ແລ້ວ. ຕົວຢ່າງເຊັ່ນ: ຄຸນລັກສະນະ "ຄວາມຖີ່ໃນການຊື້ຂອງຜູ້ໃຊ້ໃນ 30 ວັນທີ່ຜ່ານມາ" ອາດຈະຖືກນຳໃຊ້ທັງໃນແບບຈຳລອງການແນະນຳ (Recommendation Model) ແລະ AI ຄາດຄະເນຄວາມຕ້ອງການ. Feature Store ສະໜອງກົນໄກໃນການເກັບຮັກສາຄຸນລັກສະນະເຫຼົ່ານີ້ເປັນຊັບສິນຮ່ວມກັນ ເພື່ອໃຫ້ສາມາດນຳກັບມາໃຊ້ໃໝ່ໄດ້ໃນທົ່ວທີມງານ.

ອີກໜຶ່ງບັນຫາສຳຄັນຄື ຄວາມບໍ່ສອດຄ່ອງຂອງຂໍ້ມູນລະຫວ່າງການຝຶກຝົນ ແລະ ການຄາດຄະເນ ຫຼືທີ່ເອີ້ນວ່າ "Training-Serving Skew". ມັນບໍ່ແມ່ນເລື່ອງແປກທີ່ຄວາມຖືກຕ້ອງຂອງແບບຈຳລອງບໍ່ສາມາດເຮັດຊ້ຳໄດ້ໃນສະຖານະການຈິງ ເນື່ອງຈາກເຫດຜົນທາງດ້ານຕັກກະການຄຳນວນຄຸນລັກສະນະທີ່ໃຊ້ໃນຕອນຝຶກຝົນ ແລະ ຕອນນຳໃຊ້ຈິງມີຄວາມແຕກຕ່າງກັນເລັກນ້ອຍ. Feature Store ຈະແກ້ໄຂບັນຫານີ້ຢ່າງເປັນໂຄງສ້າງ.

ກົນໄກທາງເຕັກນິກ

ໂດຍທົ່ວໄປແລ້ວ Feature Store ປະກອບດ້ວຍອົງປະກອບດັ່ງນີ້:

• Offline Store: ບ່ອນຈັດເກັບຂໍ້ມູນສຳລັບການປະມວນຜົນແບບ Batch ເພື່ອຮັກສາຂໍ້ມູນຈຳນວນມະຫາສານສຳລັບການຝຶກຝົນ (ມັກໃຊ້ Data Warehouse ຫຼື Object Storage).
• Online Store: ຊັ້ນ Cache ທີ່ມີຄວາມໜ່ວງຕໍ່າ (Low Latency) ເພື່ອດຶງຄຸນລັກສະນະໃນເວລາຈິງໃນຂະນະທີ່ຄາດຄະເນ (ຕົວຢ່າງທີ່ເປັນແບບຢ່າງຄື Redis ຫຼື DynamoDB).
• Feature Pipeline: ຂະບວນການໄຫຼວຽນຂອງຂໍ້ມູນໃນການຄຳນວນ ແລະ ອັບເດດຄຸນລັກສະນະຈາກຂໍ້ມູນດິບ.
• Feature Registry: Catalog ສຳລັບຈັດການຄຳນິຍາມ, Metadata ແລະ ເວີຊັນຂອງຄຸນລັກສະນະ.

ການມີໂຄງສ້າງສອງຊັ້ນຄື Offline ແລະ Online ເຮັດໃຫ້ສາມາດຕອບສະໜອງຄວາມຕ້ອງການທີ່ຂັດແຍ່ງກັນໄດ້ ຄືການປະມວນຜົນຂໍ້ມູນຝຶກຝົນຈຳນວນຫຼາຍຢ່າງມີປະສິດທິພາບ ແລະ ການສົ່ງຄຸນລັກສະນະພາຍໃນເວລາບໍ່ເທົ່າໃດມິນລີວິນາທີໃນການນຳໃຊ້ຈິງ.

ຕຳແໜ່ງໃນ MLOps

Feature Store ເຮັດໜ້າທີ່ເປັນອົງປະກອບຫຼັກຂອງ Pipeline MLOps. ໃນບໍລິບົດຂອງ MLOps ທີ່ຈັດການກ່ຽວກັບການຄວບຄຸມເວີຊັນ ແລະ ການ Deploy ແບບຈຳລອງ, ຄຸນລັກສະນະກໍຖືກຈັດເປັນຜົນຜະລິດທີ່ຄວນໄດ້ຮັບການຄວບຄຸມເວີຊັນເຊັ່ນດຽວກັບ Code. ການຈັດການ Lineage ເພື່ອຕິດຕາມວ່າແບບຈຳລອງໃດໃຊ້ຄຸນລັກສະນະໃດ ເມື່ອມີການປ່ຽນແປງຄຸນລັກສະນະນັ້ນ ກໍເປັນໜ້າທີ່ສຳຄັນເຊັ່ນກັນ.

ນອກຈາກນີ້, ໃນຂະນະທີ່ສະຖາປັດຕະຍະກຳທີ່ອ້າງອີງຂໍ້ມູນພາຍນອກໃນຂະນະຄາດຄະເນເຊັ່ນ RAG ແລະ AI Agent ແຜ່ຫຼາຍຂຶ້ນ, ການອອກແບບ Feature Store ທີ່ຄຳນຶງເຖິງການຈັດການຄວາມສົດໃໝ່ຂອງຄຸນລັກສະນະ ແລະ ການເຊື່ອມຕໍ່ກັບ Vector Database ກໍກຳລັງໄດ້ຮັບຄວາມສົນໃຈໃນຊຸມປີມໍ່ໆມານີ້.

ຈຸດທີ່ຄວນຈື່ໃນການນຳມາໃຊ້ງານ

ການນຳໃຊ້ Feature Store ຈະເຫັນຜົນໄດ້ງ່າຍໃນກໍລະນີທີ່ມີຫຼາຍ ML Model ອ້າງອີງຂໍ້ມູນໃນ Domain ດຽວກັນ ຫຼື ໃນສະຖານທີ່ທີ່ຕ້ອງການຄວາມເປັນເວລາຈິງຂອງຄຸນລັກສະນະເຊັ່ນ Smart Factory. ໃນທາງກົງກັນຂ້າມ, ຖ້າສ້າງ Feature Store ຂະໜາດໃຫຍ່ໃນຂັ້ນຕອນທີ່ມີແບບຈຳລອງພຽງໜ້ອຍດຽວ, ຄ່າໃຊ້ຈ່າຍໃນການດຳເນີນງານອາດຈະສູງກວ່າຜົນປະໂຫຍດທີ່ໄດ້ຮັບ. ວິທີການທີ່ເປັນຈິງແມ່ນເລີ່ມຕົ້ນຈາກການຈັດການຄຸນລັກສະນະແບບງ່າຍໆໃນຂັ້ນຕອນ PoC ແລະ ພິຈາລະນາການນຳໃຊ້ຢ່າງເຕັມຮູບແບບເມື່ອຈຳນວນແບບຈຳລອງ ແລະ ທີມງານທີ່ນຳໃຊ້ເພີ່ມຂຶ້ນ.

ໃນດ້ານຄວາມປອດໄພ, ການຄວບຄຸມການເຂົ້າເຖິງໃນກໍລະນີທີ່ຄຸນລັກສະນະມີຂໍ້ມູນສ່ວນບຸກຄົນກໍເປັນສິ່ງທ້າທາຍ. ຈາກມຸມມອງຂອງ AI Governance, ການກຳນົດໃຫ້ຊັດເຈນວ່າໃຜສາມາດອ້າງອີງ ຫຼື ອັບເດດຄຸນລັກສະນະໃດໄດ້ ແລະ ການນຳເອົາແນວຄິດ Shift-left ມາໃຊ້ເພື່ອຮັບປະກັນຄຸນນະພາບຂໍ້ມູນຕັ້ງແຕ່ຂັ້ນຕອນຕົ້ນໆຂອງ Pipeline ຈະນຳໄປສູ່ຄວາມໝັ້ນຄົງໃນການດຳເນີນງານໃນໄລຍະຍາວ.