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 ແລະອື່ນໆ.