MLOps

## «ການສ້າງໂມເດລ» ແລະ «ການດໍາເນີນງານໂມເດລ» ແມ່ນວຽກທີ່ແຕກຕ່າງກັນ ເຖິງແມ່ນວ່າຈະສ້າງໂມເດລທີ່ມີຄວາມຖືກຕ້ອງສູງໃນ Jupyter Notebook ໄດ້ກໍຕາມ, ການດໍາເນີນງານໂມເດລນັ້ນຢ່າງໝັ້ນຄົງໃນສະພາບແວດລ້ອມການຜະລິດຕ້ອງການຊຸດທັກສະທີ່ແຕກຕ່າງກັນໂດຍສິ້ນເຊີງ. ການອັບເດດຂໍ້ມູນການຝຶກ, ການຝຶກໂມເດລໃໝ່, ການຈັດການເວີຊັນ, A/B testing, ການກວດຈັບການເສື່ອມຖອຍຂອງຄວາມຖືກຕ້ອງ——ຖ້າດໍາເນີນການສິ່ງເຫຼົ່ານີ້ດ້ວຍຕົນເອງ, ລະບົບຈະລົ້ມເຫລວໂດຍບໍ່ຂຶ້ນກັບຂະໜາດຂອງທີມ. MLOps ແມ່ນການນໍາແນວຄິດຂອງ DevOps ມາໃຊ້ກັບ machine learning, ແຕ່ມີສິ່ງທ້າທາຍສະເພາະທີ່ແຕກຕ່າງຈາກການ deploy ຊອບແວ. ນັ້ນຄື: ຄວາມຈໍາເປັນຕ້ອງຈັດການເວີຊັນຂອງ 3 ສ່ວນພ້ອມກັນ ໄດ້ແກ່ code, ຂໍ້ມູນ, ແລະ model weights; ປະສິດທິພາບຂອງໂມເດລຈະເສື່ອມຖອຍໄປຕາມເວລາຍ້ອນການປ່ຽນແປງຂອງການກະຈາຍຂໍ້ມູນ (drift); ແລະຄວາມຈໍາເປັນຕ້ອງຮັບປະກັນຄວາມສາມາດໃນການທໍາຊ້ໍາການທົດລອງ. ## ອົງປະກອບຂອງ MLOps Pipeline **Data pipeline**: ອັດຕະໂນມັດການເກັບກໍາ, ການປະມວນຜົນລ່ວງໜ້າ, ແລະການກວດສອບຂໍ້ມູນການຝຶກ. ເນື່ອງຈາກຄຸນນະພາບຂອງຂໍ້ມູນກໍານົດຄຸນນະພາບຂອງໂມເດລໂດຍກົງ, ນີ້ຈຶ່ງເປັນ layer ທີ່ສໍາຄັນທີ່ສຸດ. **ການຈັດການການທົດລອງ**: ບັນທຶກ hyperparameter, learning curve, ແລະ evaluation metric ດ້ວຍເຄື່ອງມືເຊັ່ນ MLflow, Weights & Biases, Comet ເພື່ອຮັບປະກັນຄວາມສາມາດໃນການທໍາຊ້ໍາການທົດລອງ. **Model registry**: ເກັບຮັກສາໂມເດລທີ່ຝຶກແລ້ວດ້ວຍການກໍານົດເວີຊັນ, ແລະຈັດການ flow ການສົ່ງເສີມຈາກ staging ໄປສູ່ production. **Serving**: ເຜີຍແຜ່ໂມເດລໃນຮູບແບບ API. vLLM, TensorRT-LLM, Triton Inference Server ແລະອື່ນໆຖືກໃຊ້ເປັນ inference engine. **Monitoring**: ນອກຈາກ latency ຂອງການ inference ແລະອັດຕາ error ແລ້ວ, ຍັງຕິດຕາມ data drift (ການປ່ຽນແປງການກະຈາຍຂອງຂໍ້ມູນນໍາເຂົ້າ) ແລະ model drift (ການເສື່ອມຖອຍຂອງຄວາມຖືກຕ້ອງໄປຕາມເວລາ). ກົນໄກທີ່ trigger ການຝຶກໃໝ່ໂດຍອັດຕະໂນມັດເມື່ອເກີນ threshold ກໍເປັນເລື່ອງທົ່ວໄປ. ## MLOps ໃນຍຸກ LLM ດ້ວຍການເພີ່ມຂຶ້ນຂອງ LLM, ແນວຄິດຍ່ອຍທີ່ເອີ້ນວ່າ «LLMOps» ກໍໄດ້ເກີດຂຶ້ນ. ສິ່ງທ້າທາຍດ້ານການດໍາເນີນງານໃໝ່ທີ່ບໍ່ມີໃນ MLOps ແບບດັ້ງເດີມໄດ້ຖືກເພີ່ມເຂົ້າມາ, ເຊັ່ນ: ການຈັດການເວີຊັນຂອງ prompt, ການປະເມີນ RAG pipeline, ການຕັ້ງຄ່າ guardrail, ແລະການເພີ່ມປະສິດທິພາບຕົ້ນທຶນການ inference. ຊຸດເຄື່ອງມືກໍເພີ່ມຂຶ້ນດ້ວຍເຄື່ອງມືທີ່ສະເພາະສໍາລັບ LLM ເຊັ່ນ LangSmith, Braintrust, Arize AI ແລະອື່ນໆ.