ຄຳຕອບສັ້ນໆ: ເພື່ອສ້າງຕົວແທນ AI ທີ່ເຮັດວຽກໃນການປະຕິບັດ, ໃຫ້ປະຕິບັດກັບມັນຄືກັບວົງຈອນທີ່ຄວບຄຸມ: ຮັບຂໍ້ມູນ, ຕັດສິນໃຈການກະທຳຕໍ່ໄປ, ເອີ້ນເຄື່ອງມືທີ່ມີຂອບເຂດແຄບ, ສັງເກດຜົນໄດ້ຮັບ, ແລະເຮັດຊ້ຳອີກຈົນກວ່າການກວດສອບ "ສຳເລັດ" ທີ່ຊັດເຈນຈະຜ່ານໄປ. ມັນຈະໄດ້ຮັບການຮັກສາໄວ້ເມື່ອໜ້າວຽກມີຫຼາຍຂັ້ນຕອນ ແລະ ຂັບເຄື່ອນດ້ວຍເຄື່ອງມື; ຖ້າການກະຕຸ້ນດຽວແກ້ໄຂມັນໄດ້, ໃຫ້ຂ້າມຕົວແທນ. ເພີ່ມໂຄງຮ່າງເຄື່ອງມືທີ່ເຂັ້ມງວດ, ຂໍ້ຈຳກັດຂັ້ນຕອນ, ການບັນທຶກ, ແລະຕົວກວດສອບ/ວິຈານ ເພື່ອວ່າເມື່ອເຄື່ອງມືລົ້ມເຫຼວ ຫຼື ການປ້ອນຂໍ້ມູນບໍ່ຊັດເຈນ, ຕົວແທນຈະຍົກລະດັບຂຶ້ນແທນທີ່ຈະວົນຊ້ຳ.
ບົດຮຽນຫຼັກ:
ວົງວຽນຄວບຄຸມ : ປະຕິບັດການປ້ອນຂໍ້ມູນ→ກະທຳ→ສັງເກດການຊ້ຳດ້ວຍເງື່ອນໄຂຢຸດທີ່ຊັດເຈນ ແລະ ຂັ້ນຕອນສູງສຸດ.
ການອອກແບບເຄື່ອງມື : ຮັກສາເຄື່ອງມືໃຫ້ແຄບລົງ, ພິມດີດ, ໄດ້ຮັບອະນຸຍາດ ແລະ ກວດສອບຄວາມຖືກຕ້ອງເພື່ອປ້ອງກັນຄວາມວຸ້ນວາຍໃນການ "ເຮັດຫຍັງກໍ່ໄດ້".
ສຸຂະອະນາໄມຄວາມຈຳ : ໃຊ້ສະພາບໄລຍະສັ້ນທີ່ກະທັດຮັດບວກກັບການດຶງຂໍ້ມູນຄືນໄລຍະຍາວ; ຫຼີກລ່ຽງການຖິ້ມບົດບັນທຶກທັງໝົດ.
ການຕ້ານທານການໃຊ້ໃນທາງທີ່ຜິດ : ເພີ່ມລາຍຊື່ອະນຸຍາດ, ຂໍ້ຈຳກັດອັດຕາ, ອຳນາດດຽວກັນ, ແລະ “ການແລ່ນແບບແຫ້ງ” ສຳລັບການກະທຳທີ່ມີຄວາມສ່ຽງ.
ຄວາມສາມາດໃນການທົດສອບ : ຮັກສາຊຸດສະຖານະການ (ຄວາມລົ້ມເຫຼວ, ຄວາມບໍ່ແນ່ນອນ, ການສັກຢາ) ແລະ ດຳເນີນການຄືນໃໝ່ໃນທຸກໆການປ່ຽນແປງ.
🔗 ວິທີການວັດແທກປະສິດທິພາບ AI
ຮຽນຮູ້ຕົວຊີ້ວັດທີ່ໃຊ້ໄດ້ຈິງເພື່ອວັດແທກຄວາມໄວ, ຄວາມຖືກຕ້ອງ ແລະ ຄວາມໜ້າເຊື່ອຖື.
🔗 ວິທີການສົນທະນາກັບ AI
ໃຊ້ການກະຕຸ້ນເຕືອນ, ສະພາບການ ແລະ ການຕິດຕາມຜົນເພື່ອໃຫ້ໄດ້ຄຳຕອບທີ່ດີກວ່າ.
🔗 ວິທີການປະເມີນຮູບແບບ AI
ປຽບທຽບຮູບແບບໂດຍໃຊ້ການທົດສອບ, ຄະແນນ, ແລະຜົນໄດ້ຮັບຂອງໜ້າວຽກໃນໂລກຕົວຈິງ.
🔗 ວິທີການເພີ່ມປະສິດທິພາບຂອງຮູບແບບ AI
ປັບປຸງຄຸນນະພາບ ແລະ ຕົ້ນທຶນດ້ວຍການປັບແຕ່ງ, ການຕັດแต่ง ແລະ ການຕິດຕາມກວດກາ.
1) ຕົວແທນ AI ແມ່ນຫຍັງ, ໃນແງ່ຂອງຄົນທຳມະດາ 🧠
ຕົວແທນ AI ແມ່ນວົງແຫວນ. ເອກະສານ “ຕົວແທນ” ຂອງ LangChain
ແค່ນັ້ນແຫຼະ. ວົງວຽນທີ່ມີສະໝອງຢູ່ກາງ.
ການປ້ອນຂໍ້ມູນ → ຄິດ → ກະທຳ → ສັງເກດ → ເຮັດຊ້ຳ . ເອກະສານຕອບ (ເຫດຜົນ + ການກະທຳ)
ຢູ່ໃສ:
-
ການປ້ອນຂໍ້ມູນ ແມ່ນການຮ້ອງຂໍຂອງຜູ້ໃຊ້ ຫຼື ເຫດການ (ອີເມວໃໝ່, ປີ້ສະໜັບສະໜູນ, ການ ping ຂອງເຊັນເຊີ).
-
ຄິດ ແມ່ນຮູບແບບພາສາທີ່ໃຫ້ເຫດຜົນກ່ຽວກັບຂັ້ນຕອນຕໍ່ໄປ.
-
ການກະທຳກຳ ລັງເອີ້ນເຄື່ອງມື (ຄົ້ນຫາເອກະສານພາຍໃນ, ແລ່ນລະຫັດ, ສ້າງປີ້, ຮ່າງຄຳຕອບ). ຄູ່ມືການເອີ້ນຟັງຊັນ OpenAI
-
Observe ກຳລັງອ່ານຜົນຜະລິດຂອງເຄື່ອງມື.
-
ການເຮັດຊ້ຳ ແມ່ນສ່ວນທີ່ເຮັດໃຫ້ມັນຮູ້ສຶກ "ເປັນຕົວແທນ" ແທນທີ່ຈະເປັນ "ສົນທະນາ". ເອກະສານ "ຕົວແທນ" ຂອງ LangChain
ບາງຕົວແທນແມ່ນມາໂຄຣທີ່ສະຫຼາດ. ບາງຕົວແທນເຮັດໜ້າທີ່ຄືກັບຜູ້ປະຕິບັດງານລະດັບນ້ອຍທີ່ສາມາດຈັດການໜ້າວຽກ ແລະ ກູ້ຄືນຈາກຄວາມຜິດພາດໄດ້. ທັງສອງຢ່າງນີ້ລ້ວນແຕ່ມີຄວາມໝາຍ.
ນອກຈາກນັ້ນ, ເຈົ້າບໍ່ຕ້ອງການຄວາມເປັນເອກະລາດຢ່າງເຕັມທີ່. ໃນຄວາມເປັນຈິງ... ເຈົ້າອາດຈະບໍ່ຕ້ອງການມັນ 🙃
2) ເວລາໃດທີ່ເຈົ້າຄວນສ້າງຕົວແທນ (ແລະ ເວລາໃດທີ່ເຈົ້າບໍ່ຄວນ) 🚦
ສ້າງຕົວແທນເມື່ອ:
-
ວຽກງານດັ່ງກ່າວ ມີຫຼາຍຂັ້ນຕອນ ແລະ ມີການປ່ຽນແປງຂຶ້ນກັບສິ່ງທີ່ເກີດຂຶ້ນລະຫວ່າງກາງທາງ.
-
ວຽກດັ່ງກ່າວຕ້ອງການ ການໃຊ້ເຄື່ອງມື (ຖານຂໍ້ມູນ, CRM, ການປະຕິບັດລະຫັດ, ການສ້າງໄຟລ໌, ໂປຣແກຣມທ່ອງເວັບ, API ພາຍໃນ). ເອກະສານ “ເຄື່ອງມື” ຂອງ LangChain
-
ທ່ານຕ້ອງການ ຜົນໄດ້ຮັບທີ່ເຮັດຊ້ຳໄດ້ ດ້ວຍມາດຕະການປ້ອງກັນ, ບໍ່ພຽງແຕ່ຄຳຕອບຄັ້ງດຽວເທົ່ານັ້ນ.
-
ເຈົ້າສາມາດນິຍາມຄຳວ່າ "ເຮັດແລ້ວ" ໃນວິທີທີ່ຄອມພິວເຕີສາມາດກວດສອບໄດ້, ເຖິງແມ່ນວ່າຈະວ່າງໆກໍຕາມ.
ຢ່າສ້າງຕົວແທນເມື່ອ:
-
ການກະຕຸ້ນເຕືອນ + ການຕອບສະໜອງງ່າຍໆຈະແກ້ໄຂບັນຫາໄດ້ (ຢ່າວິສະວະກຳຫຼາຍເກີນໄປ, ເຈົ້າຈະກຽດຊັງຕົວເອງໃນພາຍຫຼັງ).
-
ເຈົ້າຕ້ອງການຄວາມແນ່ນອນທີ່ສົມບູນແບບ (ຕົວແທນສາມາດມີຄວາມສອດຄ່ອງກັນໄດ້, ແຕ່ບໍ່ແມ່ນຫຸ່ນຍົນ).
-
ທ່ານບໍ່ມີເຄື່ອງມື ຫຼື ຂໍ້ມູນໃດໆທີ່ຈະເຊື່ອມຕໍ່ - ຫຼັງຈາກນັ້ນມັນສ່ວນຫຼາຍແມ່ນພຽງແຕ່ຄວາມຮູ້ສຶກເທົ່ານັ້ນ.
ເວົ້າກົງໄປກົງມາ: ເຄິ່ງໜຶ່ງຂອງ “ໂຄງການຕົວແທນ AI” ອາດຈະເປັນຂະບວນການເຮັດວຽກທີ່ມີກົດລະບຽບການແຕກກິ່ງງ່າສອງສາມຢ່າງ. ແຕ່ບາງຄັ້ງຄວາມຮູ້ສຶກກໍ່ສຳຄັນເຊັ່ນກັນ 🤷♂️
3) ສິ່ງທີ່ເຮັດໃຫ້ຕົວແທນ AI ລຸ້ນດີ ✅
ນີ້ແມ່ນພາກສ່ວນ "ສິ່ງທີ່ເຮັດໃຫ້ເປັນຮຸ່ນທີ່ດີ" ທີ່ເຈົ້າຂໍ, ຍົກເວັ້ນຂ້ອຍຈະເວົ້າກົງໆໜ້ອຍໜຶ່ງ:
ຕົວແທນ AI ລຸ້ນທີ່ດີ ບໍ່ ຕົວແທນທີ່ຄິດວ່າຍາກທີ່ສຸດ. ແຕ່ມັນແມ່ນຕົວແທນທີ່:
-
ຮູ້ວ່າມັນໄດ້ຮັບອະນຸຍາດໃຫ້ເຮັດຫຍັງ (ຂອບເຂດຂອບເຂດ)
-
ໃຊ້ເຄື່ອງມືຕ່າງໆຢ່າງໜ້າເຊື່ອຖື (ການໂທທີ່ມີໂຄງສ້າງ, ການລອງໃໝ່, ການໝົດເວລາ) ຄູ່ມືການໂທຫາຟັງຊັນ OpenAI AWS “ການໝົດເວລາ, ການລອງໃໝ່, ແລະ ການຖອຍຫຼັງດ້ວຍ jitter”
-
ຮັກສາສະຖານະໃຫ້ສະອາດ (ໜ່ວຍຄວາມຈຳທີ່ບໍ່ເນົ່າເປື່ອຍ) LangChain “ພາບລວມຂອງໜ່ວຍຄວາມຈຳ”
-
ອະທິບາຍການກະທຳຂອງມັນ (ຮ່ອງຮອຍການກວດສອບ, ບໍ່ແມ່ນການຖິ້ມຂໍ້ມູນທີ່ເປັນຄວາມລັບ) NIST AI RMF 1.0 (ຄວາມໜ້າເຊື່ອຖື ແລະ ຄວາມໂປ່ງໃສ)
-
ຢຸດຢ່າງເໝາະສົມ (ການກວດສອບຄວາມສຳເລັດ, ຂັ້ນຕອນສູງສຸດ, ການຍົກລະດັບ) ເອກະສານ “ຕົວແທນ” ຂອງ LangChain
-
ລົ້ມເຫຼວຢ່າງປອດໄພ (ຂໍຄວາມຊ່ວຍເຫຼືອ, ບໍ່ໄດ້ຫຼອນຫຼອນຜູ້ມີອຳນາດ) NIST AI RMF 1.0
-
ສາມາດທົດສອບໄດ້ (ທ່ານສາມາດໃຊ້ມັນໃນສະຖານະການທີ່ກຽມໄວ້ລ່ວງໜ້າ ແລະ ໃຫ້ຄະແນນຜົນໄດ້ຮັບ)
ຖ້າຕົວແທນຂອງເຈົ້າບໍ່ສາມາດທົດສອບໄດ້, ໂດຍພື້ນຖານແລ້ວມັນເປັນເຄື່ອງຫຼີ້ນສະລັອດທີ່ໝັ້ນໃຈຫຼາຍ. ມ່ວນໃນງານລ້ຽງ, ໜ້າຢ້ານໃນການຜະລິດ 😬
4) ອົງປະກອບຫຼັກຂອງຕົວແທນ ("ກາຍວິພາກ" 🧩)
ຕົວແທນທີ່ແຂງແກ່ນສ່ວນໃຫຍ່ມີຊິ້ນສ່ວນເຫຼົ່ານີ້:
ກ) ວົງວຽນຄວບຄຸມ 🔁
ນີ້ແມ່ນຜູ້ປະພັນດົນຕີ:
-
ຕັ້ງເປົ້າໝາຍ
-
ຖາມຕົວແບບສຳລັບການກະທຳຕໍ່ໄປ
-
ແລ່ນເຄື່ອງມື
-
ການສັງເກດການເພີ່ມເຕີມ
-
ເຮັດຊ້ຳອີກຈົນກວ່າຈະສຳເລັດ ເອກະສານ "ຕົວແທນ" ຂອງ LangChain
ຂ) ເຄື່ອງມື (ຫຼື ຄວາມສາມາດ) 🧰
ເຄື່ອງມືແມ່ນສິ່ງທີ່ເຮັດໃຫ້ຕົວແທນມີປະສິດທິພາບ: ເອກະສານ "ເຄື່ອງມື" ຂອງ LangChain
-
ການສອບຖາມຖານຂໍ້ມູນ
-
ການສົ່ງອີເມວ
-
ການດຶງໄຟລ໌
-
ລະຫັດທີ່ໃຊ້ງານ
-
ການເອີ້ນໃຊ້ API ພາຍໃນ
-
ຂຽນໃສ່ສະເປຣດຊີດ ຫຼື CRM
ຄ) ຄວາມຊົງຈຳ 🗃️
ສອງປະເພດມີຄວາມສຳຄັນ:
-
ຄວາມຊົງຈຳໄລຍະສັ້ນ : ສະພາບການດຳເນີນງານໃນປະຈຸບັນ, ຂັ້ນຕອນທີ່ຜ່ານມາ, ແຜນການໃນປະຈຸບັນ
-
ຄວາມຊົງຈຳໄລຍະຍາວ : ຄວາມມັກຂອງຜູ້ໃຊ້, ບໍລິບົດຂອງໂຄງການ, ຄວາມຮູ້ທີ່ດຶງມາ (ມັກຈະຜ່ານການຝັງ + ບ່ອນເກັບຂໍ້ມູນເວັກເຕີ) ເຈ້ຍ RAG
ງ) ນະໂຍບາຍການວາງແຜນ ແລະ ການຕັດສິນໃຈ 🧭
ເຖິງແມ່ນວ່າທ່ານຈະບໍ່ເອີ້ນມັນວ່າ "ການວາງແຜນ", ທ່ານກໍ່ຕ້ອງການວິທີການ:
-
ລາຍການກວດສອບ
-
ເອກະສານ ReAct ແບບ “ຄິດແລ້ວໃຊ້ເຄື່ອງມື”
-
ກຣາຟໜ້າວຽກ
-
ຮູບແບບຜູ້ຄວບຄຸມ-ພະນັກງານ
-
ຮູບແບບຜູ້ຄວບຄຸມ-ຜູ້ເຮັດວຽກ Microsoft AutoGen (ຂອບການເຮັດວຽກຫຼາຍຕົວແທນ)
ອ) ຮົ້ວກັ້ນ ແລະ ການປະເມີນຜົນ 🧯
-
ສິດອະນຸຍາດ
-
ແຜນວາດເຄື່ອງມືທີ່ປອດໄພ OpenAI Structured Outputs
-
ການກວດສອບຜົນຜະລິດ
-
ຂີດຈຳກັດຂັ້ນຕອນ
-
ການຕັດໄມ້
-
ການທົດສອບ NIST AI RMF 1.0
ແມ່ນແລ້ວ, ມັນເປັນວິສະວະກຳຫຼາຍກວ່າການກະຕຸ້ນ. ເຊິ່ງມັນ… ເປັນຈຸດປະສົງຫຼັກ.
5) ຕາຕະລາງປຽບທຽບ: ວິທີທີ່ນິຍົມໃນການສ້າງຕົວແທນ 🧾
ຂ້າງລຸ່ມນີ້ແມ່ນ "ຕາຕະລາງປຽບທຽບ" ທີ່ເປັນຈິງ - ພ້ອມດ້ວຍຈຸດແປກໆບາງຢ່າງ, ເພາະວ່າທີມງານຕົວຈິງແມ່ນແປກໆ 😄
| ເຄື່ອງມື / ຂອບການເຮັດວຽກ | ຜູ້ຊົມ | ລາຄາ | ເປັນຫຍັງມັນຈຶ່ງໃຊ້ໄດ້ | ໝາຍເຫດ (ຄວາມວຸ່ນວາຍເລັກນ້ອຍ) | |
|---|---|---|---|---|---|
| LangChain | ຜູ້ກໍ່ສ້າງທີ່ມັກອົງປະກອບແບບເລໂກ້ | ເສລີ + ອິນຟາເຣດ | ລະບົບນິເວດຂະໜາດໃຫຍ່ສຳລັບເຄື່ອງມື, ໜ່ວຍຄວາມຈຳ, ແລະ ລະບົບຕ່ອງໂສ້ | ສາມາດກິນສະປາເກັດຕີ້ໄດ້ໄວຖ້າເຈົ້າບໍ່ບອກຊື່ສິ່ງຕ່າງໆໃຫ້ຊັດເຈນ | |
| ດັດຊະນີລາມາ | ທີມທີ່ມີ RAG ຫຼາຍ | ເສລີ + ອິນຟາເຣດ | ຮູບແບບການດຶງຂໍ້ມູນທີ່ເຂັ້ມແຂງ, ການຈັດດັດສະນີ, ຕົວເຊື່ອມຕໍ່ | ດີຫຼາຍເມື່ອຕົວແທນຂອງເຈົ້າໂດຍພື້ນຖານແລ້ວແມ່ນ "ຄົ້ນຫາ + ປະຕິບັດ"... ເຊິ່ງເປັນເລື່ອງທຳມະດາ | |
| ວິທີການແບບ OpenAI Assistants | ທີມງານທີ່ຕ້ອງການການຕັ້ງຄ່າໄວຂຶ້ນ | ອີງຕາມການນຳໃຊ້ | ຮູບແບບການເອີ້ນເຄື່ອງມືໃນຕົວ ແລະ ສະຖານະການແລ່ນ | ມີຄວາມຍືດຫຍຸ່ນໜ້ອຍລົງໃນບາງມຸມ, ແຕ່ສະອາດສຳລັບຫຼາຍໆແອັບ | OpenAI ແລ່ນ API ການເອີ້ນຟັງຊັນຂອງຜູ້ຊ່ວຍ OpenAI |
| ເຄີເນລຄວາມໝາຍ | ນັກພັດທະນາທີ່ຕ້ອງການການປະສານງານທີ່ມີໂຄງສ້າງ | ແບບອິດສະຫຼະ | ການສະຫຼຸບຢ່າງລະອຽດສຳລັບທັກສະ/ໜ້າທີ່ | ຮູ້ສຶກວ່າ "ວິສາຫະກິດເປັນລະບຽບຮຽບຮ້ອຍ" - ບາງຄັ້ງນັ້ນກໍ່ເປັນຄຳຍ້ອງຍໍ 😉 | |
| ອໍໂຕ້ເຈນ | ຜູ້ທົດລອງຫຼາຍຕົວແທນ | ແບບອິດສະຫຼະ | ຮູບແບບການຮ່ວມມືລະຫວ່າງຕົວແທນກັບຕົວແທນ | ສາມາດເວົ້າຫຼາຍເກີນໄປ; ກຳນົດກົດລະບຽບການຢຸດຕິການດຳເນີນງານຢ່າງເຂັ້ມງວດ | |
| CrewAI | ແຟນໆ “ທີມຕົວແທນ” | ແບບອິດສະຫຼະ | ບົດບາດ + ໜ້າວຽກ + ການມອບໝາຍໜ້າທີ່ ແມ່ນງ່າຍທີ່ຈະສະແດງອອກ | ເຮັດວຽກໄດ້ດີທີ່ສຸດເມື່ອວຽກງານມີຄວາມຄົມຊັດ, ບໍ່ອ່ອນນຸ້ມ | |
| ກອງເຟືອງ | ຄົ້ນຫາ + ຜູ້ຄົນໃນທໍ່ສົ່ງ | ແບບອິດສະຫຼະ | ທໍ່ສົ່ງຂອງແຂງ, ການດຶງຄືນ, ສ່ວນປະກອບຕ່າງໆ | ໜ້ອຍລົງ “ໂຮງລະຄອນຕົວແທນ”, “ໂຮງງານທີ່ໃຊ້ໄດ້ຈິງ” ຫຼາຍຂຶ້ນ | |
| ມ້ວນເອງ (ວົງວຽນແບບກຳນົດເອງ) | ຄົນທີ່ມັກຄວບຄຸມ (ຮັກ) | ເວລາຂອງເຈົ້າ | ເວດມົນໜ້ອຍທີ່ສຸດ, ຄວາມຊັດເຈນສູງສຸດ | ໂດຍປົກກະຕິແລ້ວແມ່ນໄລຍະຍາວທີ່ດີທີ່ສຸດ... ຈົນກວ່າເຈົ້າຈະປະດິດທຸກຢ່າງຂຶ້ນມາໃໝ່ 😅 |
ບໍ່ມີຜູ້ຊະນະຄົນດຽວ. ທາງເລືອກທີ່ດີທີ່ສຸດແມ່ນຂຶ້ນກັບວ່າວຽກຫຼັກຂອງຕົວແທນຂອງທ່ານແມ່ນ ການຄົ້ນຫາຄືນ , ການປະຕິບັດເຄື່ອງມື , ການປະສານງານຫຼາຍຕົວແທນ , ຫຼື ການອັດຕະໂນມັດຂອງຂະບວນການເຮັດ .
6) ວິທີການສ້າງຕົວແທນ AI ແບບເທື່ອລະຂັ້ນຕອນ (ສູດຕົວຈິງ) 🍳🤖
ນີ້ແມ່ນສ່ວນທີ່ຄົນສ່ວນໃຫຍ່ຂ້າມໄປ, ແລ້ວສົງໄສວ່າເປັນຫຍັງຕົວແທນຈຶ່ງປະພຶດຕົວຄືກັບແຣກຄູນຢູ່ໃນຕູ້ເກັບມ້ຽນອາຫານ.
ຂັ້ນຕອນທີ 1: ກຳນົດວຽກໃນປະໂຫຍກດຽວ🎯
ຕົວຢ່າງ:
-
"ຮ່າງຄຳຕອບຂອງລູກຄ້າໂດຍໃຊ້ນະໂຍບາຍ ແລະ ສະພາບການຂອງປີ້, ຈາກນັ້ນຂໍການອະນຸມັດ."
-
"ສືບສວນລາຍງານຂໍ້ຜິດພາດ, ສ້າງມັນຄືນໃໝ່, ແລະ ສະເໜີການແກ້ໄຂ."
-
"ປ່ຽນບັນທຶກການປະຊຸມທີ່ບໍ່ສົມບູນແບບໃຫ້ກາຍເປັນໜ້າວຽກ, ເຈົ້າຂອງ, ແລະເສັ້ນຕາຍ."
ຖ້າທ່ານບໍ່ສາມາດນິຍາມມັນໄດ້ງ່າຍໆ, ຕົວແທນຂອງທ່ານກໍ່ບໍ່ສາມາດນິຍາມໄດ້ຄືກັນ. ຂ້າພະເຈົ້າໝາຍຄວາມວ່າມັນສາມາດເຮັດໄດ້, ແຕ່ມັນຈະປັບປຸງໃຫ້ດີຂຶ້ນ, ແລະການປັບປຸງໃຫ້ດີຂຶ້ນແມ່ນບ່ອນທີ່ງົບປະມານຈະຫາຍໄປ.
ຂັ້ນຕອນທີ 2: ຕັດສິນໃຈລະດັບຄວາມເຂັ້ມຂຸ້ນ (ຕໍ່າ, ກາງ, ເຜັດ) 🌶️
-
ຄວາມເປັນເອກະລາດຕໍ່າ : ຊີ້ບອກຂັ້ນຕອນຕ່າງໆ, ການຄລິກຂອງມະນຸດ "ອະນຸມັດ"
-
ສື່ກາງ : ດໍາເນີນການເຄື່ອງມື, ຮ່າງຜົນຜະລິດ, ຍົກລະດັບຄວາມບໍ່ແນ່ນອນ
-
ສູງ : ປະຕິບັດການເຮັດວຽກແບບ end-to-end, ping ມະນຸດໃນຂໍ້ຍົກເວັ້ນເທົ່ານັ້ນ
ເລີ່ມຕ່ຳກວ່າທີ່ທ່ານຕ້ອງການ. ເຈົ້າສາມາດເລັ່ງມັນຂຶ້ນໄດ້ພາຍຫຼັງສະເໝີ.
ຂັ້ນຕອນທີ 3: ເລືອກຍຸດທະສາດແບບຈຳລອງຂອງເຈົ້າ 🧠
ໂດຍປົກກະຕິແລ້ວທ່ານເລືອກ:
-
ຮູບແບບທີ່ເຂັ້ມແຂງອັນໜຶ່ງສຳລັບທຸກຢ່າງ (ງ່າຍໆ)
-
ຮູບແບບທີ່ເຂັ້ມແຂງອັນໜຶ່ງ + ຮູບແບບຂະໜາດນ້ອຍກວ່າສຳລັບຂັ້ນຕອນລາຄາຖືກ (ການຈັດປະເພດ, ການກຳນົດເສັ້ນທາງ)
-
ຮູບແບບພິເສດ (ວິໄສທັດ, ລະຫັດ, ການປາກເວົ້າ) ຖ້າຈຳເປັນ
ຕັດສິນໃຈຍັງ:
-
ໂທເຄັນສູງສຸດ
-
ອຸນຫະພູມ
-
ບໍ່ວ່າທ່ານຈະອະນຸຍາດໃຫ້ມີຮ່ອງຮອຍການຫາເຫດຜົນຍາວໆພາຍໃນ (ທ່ານສາມາດເຮັດໄດ້, ແຕ່ຢ່າເປີດເຜີຍລະບົບຕ່ອງໂສ້ຄວາມຄິດດິບໃຫ້ກັບຜູ້ໃຊ້ສຸດທ້າຍ)
ຂັ້ນຕອນທີ 4: ກຳນົດເຄື່ອງມືທີ່ມີໂຄງຮ່າງທີ່ເຂັ້ມງວດ 🔩
ເຄື່ອງມືຄວນຈະເປັນ:
-
ແຄບ
-
ພິມແລ້ວ
-
ໄດ້ຮັບອະນຸຍາດ
-
ຜົນໄດ້ຮັບທີ່ມີໂຄງສ້າງ OpenAI ທີ່ຖືກກວດສອບແລ້ວ
ແທນທີ່ຈະເປັນເຄື່ອງມືທີ່ເອີ້ນວ່າ do_anything(input: string) , make:
-
search_kb(ຄຳຖາມ: ສະຕຣິງ) -> ຜົນໄດ້ຮັບ[] -
create_ticket(title: string, body: string, priority: enum) -> ticket_id -
send_email(to: string, subject: string, body: string) -> ສະຖານະຄູ່ມືການເອີ້ນຟັງຊັນ OpenAI
ຖ້າທ່ານເອົາເລື່ອຍຕັດໄມ້ໃຫ້ຕົວແທນ, ຢ່າຕົກໃຈເມື່ອມັນຕັດຮົ້ວອອກໂດຍການຖອດຮົ້ວອອກ.
ຂັ້ນຕອນທີ 5: ສ້າງວົງວຽນຕົວຄວບຄຸມ 🔁
ວົງວຽນຕໍ່າສຸດ:
-
ເລີ່ມຕົ້ນດ້ວຍເປົ້າໝາຍ + ສະພາບການເບື້ອງຕົ້ນ
-
ຖາມຕົວແບບ: “ການກະທຳຕໍ່ໄປບໍ?”
-
ຖ້າເຄື່ອງມືໂທຫາ - ປະຕິບັດເຄື່ອງມື
-
ການສັງເກດການເພີ່ມເຕີມ
-
ກວດສອບສະພາບຈຸດຢຸດ
-
ເຮັດຊ້ຳອີກ (ດ້ວຍຂັ້ນຕອນສູງສຸດ) ເອກະສານ “ຕົວແທນ” ຂອງ LangChain
ເພີ່ມ:
-
ໝົດເວລາ
-
ການລອງໃໝ່ (ລະວັງ - ການລອງໃໝ່ສາມາດວົນຊ້ຳໄດ້) AWS “ໝົດເວລາ, ລອງໃໝ່, ແລະ ຖອຍຫຼັງດ້ວຍຄວາມສັ່ນສະເທືອນ”
-
ການຈັດຮູບແບບຄວາມຜິດພາດຂອງເຄື່ອງມື (ຊັດເຈນ, ມີໂຄງສ້າງ)
ຂັ້ນຕອນທີ 6: ເພີ່ມໜ່ວຍຄວາມຈຳຢ່າງລະມັດລະວັງ 🗃️
ໄລຍະສັ້ນ: ຮັກສາ “ບົດສະຫຼຸບສະຖານະ” ທີ່ກະທັດຮັດໃຫ້ທັນສະໄໝໃນທຸກໆຂັ້ນຕອນ. LangChain “ພາບລວມຄວາມຈຳ”
ໄລຍະຍາວ: ເກັບຮັກສາຂໍ້ເທັດຈິງທີ່ທົນທານ (ຄວາມມັກຂອງຜູ້ໃຊ້, ກົດລະບຽບຂອງອົງກອນ, ເອກະສານທີ່ໝັ້ນຄົງ).
ກົດລະບຽບຫຼັກ:
-
ຖ້າມັນປ່ຽນແປງເລື້ອຍໆ - ໃຫ້ມັນຢູ່ໃນໄລຍະສັ້ນ
-
ຖ້າມັນໝັ້ນຄົງ - ເກັບຮັກສາໄວ້ໃນໄລຍະຍາວ
-
ຖ້າມັນລະອຽດອ່ອນ - ເກັບຮັກສາໄວ້ໜ້ອຍທີ່ສຸດ (ຫຼື ບໍ່ເກັບໄວ້ເລີຍ)
ຂັ້ນຕອນທີ 7: ເພີ່ມການກວດສອບຄວາມຖືກຕ້ອງ ແລະ ໃບຜ່ານ "ວິຈານ" 🧪
ຮູບແບບລາຄາຖືກ ແລະ ໃຊ້ໄດ້ຈິງ:
-
ຕົວແທນສ້າງຜົນໄດ້ຮັບ
-
ຕົວກວດສອບຄວາມຖືກຕ້ອງກວດສອບໂຄງສ້າງ ແລະ ຂໍ້ຈຳກັດ
-
ການທົບທວນຄືນຮູບແບບນັກວິຈານທາງເລືອກສຳລັບຂັ້ນຕອນທີ່ຂາດຫາຍໄປ ຫຼື ການລະເມີດນະໂຍບາຍ NIST AI RMF 1.0
ບໍ່ສົມບູນແບບ, ແຕ່ມັນຈັບເອົາຄວາມບໍ່ສົມເຫດສົມຜົນຫຼາຍຢ່າງທີ່ໜ້າຕົກໃຈ.
ຂັ້ນຕອນທີ 8: ບັນທຶກທຸກຢ່າງທີ່ເຈົ້າຈະເສຍໃຈທີ່ບໍ່ໄດ້ບັນທຶກ 📜
ບັນທຶກ:
-
ການເອີ້ນເຄື່ອງມື + ການປ້ອນຂໍ້ມູນ + ຜົນຜະລິດ
-
ການຕັດສິນໃຈທີ່ໄດ້ເຮັດ
-
ຂໍ້ຜິດພາດ
-
ຜົນຜະລິດສຸດທ້າຍ
-
ໂທເຄັນ ແລະ ຄວາມໜ่วง ເວລາ ຄູ່ມືການສັງເກດການ OpenTelemetry
ອະນາຄົດ - ເຈົ້າຈະຂອບໃຈເຈົ້າ. ປະຈຸບັນ - ເຈົ້າຈະລືມ. ນັ້ນກໍ່ເປັນພຽງຊີວິດ 😵💫
7) ການໂທດ້ວຍເຄື່ອງມືທີ່ບໍ່ທຳລາຍຈິດວິນຍານຂອງເຈົ້າ 🧰😵
ການເອີ້ນໃຊ້ເຄື່ອງມືແມ່ນບ່ອນທີ່ “ວິທີການສ້າງຕົວແທນ AI” ກາຍເປັນວິສະວະກຳຊອບແວທີ່ແທ້ຈິງ.
ເຮັດໃຫ້ເຄື່ອງມືເຊື່ອຖືໄດ້ (ເຊື່ອຖືໄດ້ແມ່ນດີ)
ເຄື່ອງມືທີ່ໜ້າເຊື່ອຖືໄດ້ແກ່:
-
ແບບກຳນົດເອງ
-
ຂອບເຂດແຄບ
-
ງ່າຍຕໍ່ການທົດສອບ
-
ປອດໄພທີ່ຈະເປີດໃຊ້ Stripe “Idempotent requests”
ເພີ່ມລາງປ້ອງກັນຢູ່ຊັ້ນເຄື່ອງມື, ບໍ່ພຽງແຕ່ການກະຕຸ້ນເທົ່ານັ້ນ
ການກະຕຸ້ນເຕືອນແມ່ນຄໍາແນະນໍາທີ່ສຸພາບ. ການກວດສອບຄວາມຖືກຕ້ອງຂອງເຄື່ອງມືແມ່ນປະຕູທີ່ຖືກລັອກໄວ້. ຜົນຜະລິດທີ່ມີໂຄງສ້າງ OpenAI
ເຮັດ:
-
ລາຍຊື່ອະນຸຍາດ (ເຄື່ອງມືໃດທີ່ສາມາດໃຊ້ໄດ້)
-
ການກວດສອບການປ້ອນຂໍ້ມູນ
-
ຂໍ້ຈຳກັດອັດຕາ OpenAI ຄູ່ມືຂໍ້ຈຳກັດອັດຕາ
-
ການກວດສອບສິດອະນຸຍາດຕໍ່ຜູ້ໃຊ້/ອົງກອນ
-
“ໂໝດແລ່ນແຫ້ງ” ສຳລັບການກະທຳທີ່ມີຄວາມສ່ຽງ
ການອອກແບບສຳລັບຄວາມລົ້ມເຫຼວບາງສ່ວນ
ເຄື່ອງມືລົ້ມເຫຼວ. ເຄືອຂ່າຍສັ່ນສະເທືອນ. ການອະນຸຍາດໝົດອາຍຸ. ຕົວແທນຕ້ອງ:
-
ຕີຄວາມຜິດພາດ
-
ລອງໃໝ່ດ້ວຍ backoff ເມື່ອເໝາະສົມ ກົນລະຍຸດການລອງໃໝ່ຂອງ Google Cloud (backoff + jitter)
-
ເລືອກເຄື່ອງມືທາງເລືອກອື່ນ
-
ເພີ່ມຂຶ້ນເມື່ອຕິດຂັດ
ເຄັດລັບທີ່ມີປະສິດທິພາບຢ່າງງຽບໆ: ສົ່ງຄືນຂໍ້ຜິດພາດທີ່ມີໂຄງສ້າງເຊັ່ນ:
-
ປະເພດ: auth_error -
ປະເພດ: ບໍ່ພົບ -
ປະເພດ: rate_limited
ດັ່ງນັ້ນຮູບແບບສາມາດຕອບສະໜອງໄດ້ຢ່າງສະຫຼາດແທນທີ່ຈະຕົກໃຈ.
8) ຄວາມຊົງຈຳທີ່ຊ່ວຍໄດ້ແທນທີ່ຈະຫຼອກຫຼອນເຈົ້າ 👻🗂️
ຄວາມຊົງຈຳມີພະລັງຫຼາຍ, ແຕ່ມັນຍັງສາມາດກາຍເປັນລິ້ນຊັກຂີ້ເຫຍື້ອໄດ້.
ຄວາມຊົງຈຳໄລຍະສັ້ນ: ຮັກສາມັນໃຫ້ກະທັດຮັດ
ໃຊ້:
-
ຂັ້ນຕອນ N ສຸດທ້າຍ
-
ສະຫຼຸບການເຮັດວຽກ (ອັບເດດທຸກໆຮອບ)
-
ແຜນການປັດຈຸບັນ
-
ຂໍ້ຈຳກັດໃນປະຈຸບັນ (ງົບປະມານ, ເວລາ, ນະໂຍບາຍ)
ຖ້າທ່ານຖິ້ມທຸກຢ່າງເຂົ້າໄປໃນສະພາບການ, ທ່ານຈະໄດ້ຮັບ:
-
ຄ່າໃຊ້ຈ່າຍທີ່ສູງຂຶ້ນ
-
ຄວາມໜ່ວງຊ້າລົງ
-
ຄວາມສັບສົນຫຼາຍຂຶ້ນ (ແມ່ນແລ້ວ, ເຖິງແມ່ນວ່າຫຼັງຈາກນັ້ນ)
ຄວາມຊົງຈຳໄລຍະຍາວ: ການດຶງຂໍ້ມູນຄືນມາໃຊ້ໃໝ່ຫຼາຍກວ່າການ “ຕື່ມໃສ່”
“ຄວາມຊົງຈຳໄລຍະຍາວ” ສ່ວນຫຼາຍແມ່ນຄ້າຍຄືກັບ:
-
ການຝັງ
-
ຮ້ານເວັກເຕີ
-
ການສ້າງແບບເຕີມເຕັມເພື່ອດຶງຂໍ້ມູນ (RAG) ເຈ້ຍ RAG
ຕົວແທນບໍ່ໄດ້ຈື່ຈຳ. ມັນດຶງເອົາຂໍ້ມູນທີ່ກ່ຽວຂ້ອງທີ່ສຸດໃນເວລາແລ່ນ. LlamaIndex “ການແນະນຳກ່ຽວກັບ RAG”
ກົດລະບຽບຄວາມຊົງຈຳທີ່ໃຊ້ໄດ້ຈິງ
-
ເກັບຮັກສາ “ຄວາມມັກ” ເປັນຂໍ້ເທັດຈິງທີ່ຊັດເຈນ: “ຜູ້ໃຊ້ມັກສະຫຼຸບຫົວຂໍ້ ແລະ ກຽດຊັງອີໂມຈິ” (lol, ບໍ່ແມ່ນຢູ່ທີ່ນີ້ 😄)
-
ເກັບຮັກສາ “ການຕັດສິນໃຈ” ດ້ວຍປະທັບເວລາ ຫຼື ລຸ້ນຕ່າງໆ (ຖ້າບໍ່ດັ່ງນັ້ນຄວາມຂັດແຍ້ງຈະກອງຊ້ອນກັນ)
-
ຢ່າເກັບຄວາມລັບໄວ້ ເວັ້ນເສຍແຕ່ວ່າທ່ານຈຳເປັນຕ້ອງເກັບໄວ້ແທ້ໆ
ແລະນີ້ແມ່ນຄຳປຽບທຽບທີ່ບໍ່ສົມບູນແບບຂອງຂ້ອຍ: ຄວາມຊົງຈຳກໍຄືກັບຕູ້ເຢັນ. ຖ້າເຈົ້າບໍ່ເຄີຍທຳຄວາມສະອາດມັນ, ໃນທີ່ສຸດແຊນວິດຂອງເຈົ້າກໍ່ຈະມີລົດຊາດຄືກັບຫົວຜັກບົ່ວ ແລະ ຄວາມເສຍໃຈ.
9) ຮູບແບບການວາງແຜນ (ຈາກງ່າຍໆຫາແບບທັນສະໄໝ) 🧭✨
ການວາງແຜນແມ່ນພຽງແຕ່ການແຍກສ່ວນທີ່ຄວບຄຸມໄດ້. ຢ່າເຮັດໃຫ້ມັນເປັນເລື່ອງລຶກລັບ.
ຮູບແບບ A: ໂປຣແກຣມວາງແຜນບັນຊີກວດສອບ ✅
-
ຮູບແບບສະແດງລາຍຊື່ຂັ້ນຕອນຕ່າງໆ
-
ປະຕິບັດໄປເທື່ອລະຂັ້ນຕອນ
-
ອັບເດດສະຖານະລາຍການກວດສອບ
ດີເລີດສຳລັບການເລີ່ມເຮັດວຽກ. ງ່າຍດາຍ, ສາມາດທົດສອບໄດ້.
ຮູບແບບ B: ວົງວຽນປະຕິກິລິຍາ (ເຫດຜົນ + ການກະທຳ) 🧠→🧰
-
ຮຸ່ນຕັດສິນໃຈເອີ້ນໃຊ້ເຄື່ອງມືຕໍ່ໄປ
-
ສັງເກດຜົນຜະລິດ
-
ເຮັດຊ້ຳເອກະສານ ReAct
ນີ້ແມ່ນຄວາມຮູ້ສຶກຂອງຕົວແທນຄລາສສິກ.
ຮູບແບບ C: ຜູ້ຄວບຄຸມ-ພະນັກງານ 👥
-
ຜູ້ຄວບຄຸມແບ່ງເປົ້າໝາຍອອກເປັນໜ້າວຽກຕ່າງໆ
-
ພະນັກງານປະຕິບັດວຽກງານພິເສດ
-
ຜູ້ຄວບຄຸມລວມຜົນໄດ້ຮັບ Microsoft AutoGen (ຂອບການເຮັດວຽກຫຼາຍຕົວແທນ)
ສິ່ງນີ້ມີຄຸນຄ່າເມື່ອໜ້າວຽກສາມາດຂະໜານກັນໄດ້, ຫຼືເມື່ອທ່ານຕ້ອງການ “ບົດບາດ” ທີ່ແຕກຕ່າງກັນເຊັ່ນ:
-
ນັກຄົ້ນຄວ້າ
-
ຜູ້ຂຽນໂປຣແກຣມ
-
ບັນນາທິການ
-
ຕົວກວດສອບ QA
ຮູບແບບ D: ວາງແຜນ-ແລ້ວ-ປະຕິບັດ ດ້ວຍການວາງແຜນຄືນໃໝ່ 🔄
-
ສ້າງແຜນການ
-
ປະຫານຊີວິດ
-
ຖ້າຜົນໄດ້ຮັບຂອງເຄື່ອງມືປ່ຽນແປງຄວາມເປັນຈິງ, ໃຫ້ວາງແຜນຄືນໃໝ່
ສິ່ງນີ້ປ້ອງກັນບໍ່ໃຫ້ຕົວແທນປະຕິບັດຕາມແຜນການທີ່ບໍ່ດີຢ່າງດື້ດ້ານ. ມະນຸດກໍ່ເຮັດແບບນີ້ຄືກັນ, ເວັ້ນເສຍແຕ່ວ່າພວກເຂົາເມື່ອຍ, ໃນກໍລະນີນີ້ພວກເຂົາກໍ່ປະຕິບັດຕາມແຜນການທີ່ບໍ່ດີເຊັ່ນກັນ.
10) ຄວາມປອດໄພ, ຄວາມໜ້າເຊື່ອຖື, ແລະ ການບໍ່ຖືກໄລ່ອອກ 🔐😅
ຖ້າຕົວແທນຂອງທ່ານສາມາດປະຕິບັດໄດ້, ທ່ານຕ້ອງການການອອກແບບຄວາມປອດໄພ. ບໍ່ແມ່ນ "ດີທີ່ຈະມີ". ຕ້ອງການ. NIST AI RMF 1.0
ຂໍ້ຈຳກັດທີ່ຍາກ
-
ຈຳນວນກ້າວສູງສຸດຕໍ່ການແລ່ນ
-
ການໂທຫາເຄື່ອງມືສູງສຸດຕໍ່ນາທີ
-
ການໃຊ້ຈ່າຍສູງສຸດຕໍ່ກອງປະຊຸມ (ງົບປະມານໂທເຄັນ)
-
ເຄື່ອງມືທີ່ຈຳກັດຢູ່ເບື້ອງຫຼັງການອະນຸມັດ
ການຈັດການຂໍ້ມູນ
-
ແກ້ໄຂຂໍ້ມູນປ້ອນຂໍ້ມູນທີ່ລະອຽດອ່ອນກ່ອນການບັນທຶກ
-
ສະພາບແວດລ້ອມແຍກຕ່າງຫາກ (ການພັດທະນາ vs ການຜະລິດ)
-
ການອະນຸຍາດເຄື່ອງມືທີ່ມີສິດທິພິເສດໜ້ອຍທີ່ສຸດ
ຂໍ້ຈຳກັດດ້ານພຶດຕິກຳ
-
ບັງຄັບໃຫ້ຕົວແທນອ້າງອີງຕົວຢ່າງຫຼັກຖານພາຍໃນ (ບໍ່ແມ່ນລິ້ງພາຍນອກ, ພຽງແຕ່ອ້າງອີງພາຍໃນ)
-
ຕ້ອງການສັນຍານຄວາມບໍ່ແນ່ນອນເມື່ອຄວາມໝັ້ນໃຈຕໍ່າ
-
ຕ້ອງການ "ຖາມຄຳຖາມທີ່ຊັດເຈນ" ຖ້າຂໍ້ມູນປ້ອນເຂົ້າບໍ່ຊັດເຈນ
ຕົວແທນທີ່ໜ້າເຊື່ອຖືບໍ່ແມ່ນຕົວແທນທີ່ໝັ້ນໃຈທີ່ສຸດ. ແຕ່ມັນແມ່ນຕົວແທນທີ່ຮູ້ວ່າເວລາໃດທີ່ມັນຄາດເດົາ... ແລະບອກຕົວເອງ.
11) ການທົດສອບ ແລະ ການປະເມີນຜົນ (ສ່ວນທີ່ທຸກຄົນຫຼີກລ່ຽງ) 🧪📏
ເຈົ້າບໍ່ສາມາດປັບປຸງສິ່ງທີ່ເຈົ້າບໍ່ສາມາດວັດແທກໄດ້. ແມ່ນແລ້ວ, ປະໂຫຍກນັ້ນມັນເບິ່ງບໍ່ຊັດເຈນ, ແຕ່ມັນເປັນຄວາມຈິງທີ່ໜ້າລຳຄານ.
ສ້າງຊຸດສະຖານະການ
ສ້າງກໍລະນີທົດສອບ 30-100 ກໍລະນີ:
-
ເສັ້ນທາງທີ່ມີຄວາມສຸກ
-
ກໍລະນີຂອບ
-
ກໍລະນີ "ເຄື່ອງມືລົ້ມເຫລວ"
-
ຄຳຮ້ອງຂໍທີ່ບໍ່ຊັດເຈນ
-
ການກະຕຸ້ນການໂຕ້ຖຽງ (ຄວາມພະຍາຍາມສີດດ່ວນ) OWASP 10 ອັນດັບຕົ້ນໆສຳລັບແອັບ LLM OWASP LLM01 ການກະຕຸ້ນການສີດດ່ວນ
ຜົນໄດ້ຮັບຄະແນນ
ໃຊ້ຕົວຊີ້ວັດເຊັ່ນ:
-
ອັດຕາຄວາມສຳເລັດຂອງໜ້າວຽກ
-
ເວລາທີ່ຈະເຮັດໃຫ້ສຳເລັດ
-
ອັດຕາການກູ້ຄືນຄວາມຜິດພາດຂອງເຄື່ອງມື
-
ອັດຕາການເກີດອາການຫຼອນ (ການອ້າງທີ່ບໍ່ມີຫຼັກຖານ)
-
ອັດຕາການອະນຸມັດຂອງມະນຸດ (ຖ້າຢູ່ໃນໂໝດການຊີ້ນຳ)
ການທົດສອບການຖົດຖອຍສຳລັບການກະຕຸ້ນເຕືອນ ແລະ ເຄື່ອງມືຕ່າງໆ
ທຸກຄັ້ງທີ່ທ່ານປ່ຽນແປງ:
-
ໂຄງຮ່າງເຄື່ອງມື
-
ຄຳແນະນຳຂອງລະບົບ
-
ເຫດຜົນການດຶງຂໍ້ມູນ
-
ຮູບແບບໜ່ວຍຄວາມຈຳ
ເປີດໃຊ້ຊຸດອີກຄັ້ງ.
ຕົວແທນແມ່ນສັດທີ່ລະອຽດອ່ອນ. ຄືກັບຕົ້ນໄມ້ໃນເຮືອນ, ແຕ່ລາຄາແພງກວ່າ.
12) ຮູບແບບການນຳໃຊ້ທີ່ບໍ່ເຮັດໃຫ້ງົບປະມານຂອງເຈົ້າຫຼຸດລົງ 💸🔥
ເລີ່ມຕົ້ນດ້ວຍການບໍລິການດຽວ
-
API ຕົວຄວບຄຸມຕົວແທນ
-
ບໍລິການເຄື່ອງມືທີ່ຢູ່ເບື້ອງຫຼັງມັນ
-
ການບັນທຶກ + ການຕິດຕາມກວດກາ OpenTelemetry observability primer
ເພີ່ມການຄວບຄຸມຄ່າໃຊ້ຈ່າຍແຕ່ຫົວທີ
-
ຜົນໄດ້ຮັບການດຶງຂໍ້ມູນຈາກແຄສ
-
ການບີບອັດສະຖານະການສົນທະນາດ້ວຍບົດສະຫຼຸບ
-
ການນໍາໃຊ້ຮູບແບບຂະໜາດນ້ອຍກວ່າສໍາລັບການກໍານົດເສັ້ນທາງແລະການສະກັດເອົາ
-
ຈຳກັດ “ຮູບແບບການຄິດຢ່າງເລິກເຊິ່ງ” ໃຫ້ເປັນຂັ້ນຕອນທີ່ຍາກທີ່ສຸດ
ການເລືອກສະຖາປັດຕະຍະກຳທົ່ວໄປ
-
ຕົວຄວບຄຸມທີ່ບໍ່ມີສະຖານະ + ບ່ອນເກັບຂໍ້ມູນສະຖານະພາຍນອກ (DB/redis)
-
ການເອີ້ນເຄື່ອງມືແມ່ນ idempotent ບ່ອນທີ່ເປັນໄປໄດ້ Stripe “ການຮ້ອງຂໍ Idempotent”
-
ຄິວສຳລັບໜ້າວຽກທີ່ຍາວ (ດັ່ງນັ້ນທ່ານຈະບໍ່ຖືການຮ້ອງຂໍເວັບໄວ້ຕະຫຼອດໄປ)
ນອກຈາກນີ້: ສ້າງ "kill switch". ເຈົ້າຈະບໍ່ຕ້ອງການມັນຈົນກວ່າເຈົ້າຈະຕ້ອງການມັນແທ້ໆ 😬
13) ບັນທຶກປິດ - ສະບັບສັ້ນໆກ່ຽວກັບວິທີການສ້າງຕົວແທນ AI 🎁🤖
ຖ້າທ່ານຈື່ຫຍັງອີກ, ໃຫ້ຈື່ສິ່ງນີ້:
-
ວິທີການສ້າງຕົວແທນ AI ສ່ວນໃຫຍ່ແມ່ນກ່ຽວກັບການສ້າງວົງຈອນທີ່ປອດໄພອ້ອມຮອບຮູບແບບ. ເອກະສານ “ຕົວແທນ” ຂອງ LangChain
-
ເລີ່ມຕົ້ນດ້ວຍເປົ້າໝາຍທີ່ຊັດເຈນ, ຄວາມເປັນເອກະລາດຕໍ່າ, ແລະເຄື່ອງມືທີ່ເຂັ້ມງວດ. ຜົນຜະລິດທີ່ມີໂຄງສ້າງ OpenAI
-
ເພີ່ມໜ່ວຍຄວາມຈຳຜ່ານການດຶງຂໍ້ມູນຄືນ, ບໍ່ແມ່ນການຕື່ມໃສ່ເນື້ອໃນທີ່ບໍ່ມີທີ່ສິ້ນສຸດ. ເຈ້ຍ RAG
-
ການວາງແຜນສາມາດເປັນເລື່ອງງ່າຍດາຍ - ບັນຊີກວດສອບ ແລະ ການວາງແຜນຄືນໃໝ່ໄປໄດ້ໄກ.
-
ການບັນທຶກ ແລະ ການທົດສອບປ່ຽນຄວາມວຸ້ນວາຍຂອງຕົວແທນໃຫ້ກາຍເປັນສິ່ງທີ່ທ່ານສາມາດສົ່ງໄດ້. ຄູ່ມືການສັງເກດການ OpenTelemetry
-
Guardrails ຢູ່ໃນລະຫັດ, ບໍ່ພຽງແຕ່ຢູ່ໃນ prompts ເທົ່ານັ້ນ. OWASP Top 10 ສຳລັບແອັບ LLM
ຕົວແທນບໍ່ແມ່ນເວດມົນ. ມັນເປັນລະບົບທີ່ຕັດສິນໃຈທີ່ດີເລື້ອຍໆພຽງພໍທີ່ຈະມີຄຸນຄ່າ... ແລະຍອມຮັບຄວາມພ່າຍແພ້ກ່ອນທີ່ມັນຈະເຮັດໃຫ້ເກີດຄວາມເສຍຫາຍ. ເປັນການປອບໂຍນຢ່າງງຽບໆ, ໃນທາງໃດທາງໜຶ່ງ 😌
ແລະແມ່ນແລ້ວ, ຖ້າເຈົ້າສ້າງມັນຢ່າງຖືກຕ້ອງ, ມັນຈະຮູ້ສຶກຄືກັບການຈ້າງພະນັກງານຝຶກງານດິຈິຕອນຕົວນ້ອຍໆທີ່ບໍ່ເຄີຍນອນຫຼັບ, ບາງຄັ້ງກໍ່ຕົກໃຈ, ແລະມັກເຮັດວຽກເອກະສານ. ສະນັ້ນ, ໂດຍພື້ນຖານແລ້ວ, ພະນັກງານຝຶກງານ.
ຄຳຖາມທີ່ຖືກຖາມເລື້ອຍໆ
ຕົວແທນ AI ແມ່ນຫຍັງ, ເວົ້າງ່າຍໆ?
ຕົວແທນ AI ໂດຍພື້ນຖານແລ້ວແມ່ນວົງວຽນທີ່ເຮັດຊ້ຳໆ: ຮັບຂໍ້ມູນ, ຕັດສິນໃຈຂັ້ນຕອນຕໍ່ໄປ, ໃຊ້ເຄື່ອງມື, ອ່ານຜົນໄດ້ຮັບ, ແລະເຮັດຊ້ຳຈົນກວ່າມັນຈະສຳເລັດ. ສ່ວນ "ຕົວແທນ" ມາຈາກການກະທຳ ແລະ ການສັງເກດ, ບໍ່ພຽງແຕ່ການສົນທະນາເທົ່ານັ້ນ. ຕົວແທນຫຼາຍຄົນແມ່ນພຽງແຕ່ລະບົບອັດຕະໂນມັດທີ່ສະຫຼາດດ້ວຍການເຂົ້າເຖິງເຄື່ອງມື, ໃນຂະນະທີ່ຕົວແທນອື່ນໆມີພຶດຕິກຳຄ້າຍຄືກັບຜູ້ປະຕິບັດງານລະດັບນ້ອຍທີ່ສາມາດຟື້ນຕົວຈາກຄວາມຜິດພາດໄດ້.
ຂ້ອຍຄວນສ້າງຕົວແທນ AI ແທນທີ່ຈະໃຊ້ພຽງແຕ່ການກະຕຸ້ນເຕືອນເມື່ອໃດ?
ສ້າງຕົວແທນເມື່ອວຽກງານມີຫຼາຍຂັ້ນຕອນ, ການປ່ຽນແປງໂດຍອີງໃສ່ຜົນໄດ້ຮັບລະດັບກາງ, ແລະຕ້ອງການການໃຊ້ເຄື່ອງມືທີ່ເຊື່ອຖືໄດ້ (APIs, ຖານຂໍ້ມູນ, ticketing, ການປະຕິບັດລະຫັດ). ຕົວແທນຍັງມີປະໂຫຍດເມື່ອທ່ານຕ້ອງການຜົນໄດ້ຮັບທີ່ເຮັດຊ້ຳໄດ້ດ້ວຍ guardrails ແລະວິທີການກວດສອບ "ສຳເລັດແລ້ວ". ຖ້າການຕອບສະໜອງແບບງ່າຍໆເຮັດວຽກໄດ້, ຕົວແທນມັກຈະມີ overhead ທີ່ບໍ່ຈຳເປັນ ແລະຮູບແບບຄວາມລົ້ມເຫຼວເພີ່ມເຕີມ.
ຂ້ອຍຈະສ້າງຕົວແທນ AI ທີ່ບໍ່ຕິດຢູ່ໃນ loops ໄດ້ແນວໃດ?
ໃຊ້ເງື່ອນໄຂການຢຸດແບບແຂງ: ຂັ້ນຕອນສູງສຸດ, ການເອີ້ນເຄື່ອງມືສູງສຸດ, ແລະ ການກວດສອບຄວາມສຳເລັດທີ່ຊັດເຈນ. ເພີ່ມໂຄງຮ່າງເຄື່ອງມືທີ່ມີໂຄງສ້າງ, ການໝົດເວລາ, ແລະ ການລອງໃໝ່ທີ່ຈະບໍ່ລອງໃໝ່ຕະຫຼອດໄປ. ບັນທຶກການຕັດສິນໃຈ ແລະ ຜົນຜະລິດຂອງເຄື່ອງມື ເພື່ອໃຫ້ທ່ານສາມາດເຫັນບ່ອນທີ່ມັນຕົກລາງ. ວາວຄວາມປອດໄພທົ່ວໄປແມ່ນການຍົກລະດັບ: ຖ້າຕົວແທນບໍ່ແນ່ໃຈ ຫຼື ເຮັດຜິດພາດຊ້ຳອີກ, ມັນຄວນຂໍຄວາມຊ່ວຍເຫຼືອແທນທີ່ຈະປັບປຸງ.
ສະຖາປັດຕະຍະກຳຂັ້ນຕ່ຳສຳລັບວິທີການສ້າງຕົວແທນ AI ແມ່ນຫຍັງ?
ຢ່າງໜ້ອຍເຈົ້າຕ້ອງການວົງວຽນຄວບຄຸມທີ່ປ້ອນເປົ້າໝາຍ ແລະ ສະພາບການໃຫ້ກັບໂມເດວ, ຖາມຫາການກະທຳຕໍ່ໄປ, ປະຕິບັດເຄື່ອງມືຖ້າຖືກຮ້ອງຂໍ, ເພີ່ມການສັງເກດ, ແລະ ເຮັດຊ້ຳອີກ. ເຈົ້າຍັງຕ້ອງການເຄື່ອງມືທີ່ມີຮູບຮ່າງການປ້ອນຂໍ້ມູນ/ຜົນຜະລິດທີ່ເຂັ້ມງວດ ແລະ ການກວດສອບ "ສຳເລັດແລ້ວ". ແມ່ນແຕ່ວົງວຽນມ້ວນຕົວເອງກໍ່ສາມາດເຮັດວຽກໄດ້ດີຖ້າເຈົ້າຮັກສາສະຖານະພາບໃຫ້ສະອາດ ແລະ ບັງຄັບໃຊ້ຂໍ້ຈຳກັດຂອງຂັ້ນຕອນ.
ຂ້ອຍຄວນອອກແບບການເອີ້ນເຄື່ອງມືແນວໃດເພື່ອໃຫ້ມັນໜ້າເຊື່ອຖືໃນການຜະລິດ?
ຮັກສາເຄື່ອງມືໃຫ້ແຄບລົງ, ພິມແລ້ວ, ໄດ້ຮັບອະນຸຍາດ, ແລະ ກວດສອບຄວາມຖືກຕ້ອງ—ຫຼີກລ່ຽງເຄື່ອງມື "ເຮັດຫຍັງກໍ່ໄດ້" ທົ່ວໄປ. ມັກຮູບແບບທີ່ເຂັ້ມງວດ (ເຊັ່ນ: ຜົນຜະລິດທີ່ມີໂຄງສ້າງ/ການເອີ້ນຟັງຊັນ) ເພື່ອໃຫ້ຕົວແທນບໍ່ສາມາດສົ່ງຂໍ້ມູນດ້ວຍມືໄດ້. ເພີ່ມລາຍຊື່ອະນຸຍາດ, ຂໍ້ຈຳກັດອັດຕາ, ແລະ ການກວດສອບການອະນຸຍາດຂອງຜູ້ໃຊ້/ອົງກອນຢູ່ຊັ້ນເຄື່ອງມື. ອອກແບບເຄື່ອງມືໃຫ້ປອດໄພໃນການເປີດໃຊ້ງານຄືນໃໝ່ເມື່ອເປັນໄປໄດ້, ໂດຍໃຊ້ຮູບແບບ idempotency.
ວິທີທີ່ດີທີ່ສຸດໃນການເພີ່ມໜ່ວຍຄວາມຈຳໂດຍບໍ່ເຮັດໃຫ້ຕົວແທນຮ້າຍແຮງຂຶ້ນແມ່ນຫຍັງ?
ໃຫ້ປະຕິບັດຕໍ່ໜ່ວຍຄວາມຈຳເປັນສອງສ່ວນຄື: ສະພາບການດຳເນີນງານໄລຍະສັ້ນ (ຂັ້ນຕອນທີ່ຜ່ານມາ, ແຜນການປະຈຸບັນ, ຂໍ້ຈຳກັດ) ແລະ ການດຶງຂໍ້ມູນຄືນໄລຍະຍາວ (ຄວາມມັກ, ກົດລະບຽບທີ່ໝັ້ນຄົງ, ເອກະສານທີ່ກ່ຽວຂ້ອງ). ຮັກສາຄວາມກະທັດຮັດໄລຍະສັ້ນດ້ວຍບົດສະຫຼຸບການດຳເນີນງານ, ບໍ່ແມ່ນບົດບັນທຶກສຽງເຕັມຮູບແບບ. ສຳລັບໜ່ວຍຄວາມຈຳໄລຍະຍາວ, ການດຶງຂໍ້ມູນຄືນ (ການຝັງ + ການເກັບຮັກສາເວັກເຕີ/ຮູບແບບ RAG) ໂດຍປົກກະຕິແລ້ວຈະດີກ່ວາການ "ຕື່ມ" ທຸກຢ່າງເຂົ້າໃນສະພາບການ ແລະ ເຮັດໃຫ້ຮູບແບບສັບສົນ.
ຂ້ອຍຄວນໃຊ້ຮູບແບບການວາງແຜນໃດ: ລາຍການກວດສອບ, ReAct, ຫຼື ຜູ້ຄວບຄຸມ-ພະນັກງານ?
ຕົວວາງແຜນລາຍການກວດສອບແມ່ນດີຫຼາຍເມື່ອວຽກງານສາມາດຄາດເດົາໄດ້ ແລະ ທ່ານຕ້ອງການບາງສິ່ງບາງຢ່າງທີ່ງ່າຍຕໍ່ການທົດສອບ. ການວົນຊ້ຳແບບ ReAct ຈະສະຫວ່າງຂຶ້ນເມື່ອຜົນໄດ້ຮັບຂອງເຄື່ອງມືປ່ຽນແປງສິ່ງທີ່ທ່ານເຮັດຕໍ່ໄປ. ຮູບແບບການແຍກບົດບາດແບບຜູ້ຄວບຄຸມ-ຜູ້ເຮັດວຽກ (ເຊັ່ນ: ການແຍກບົດບາດແບບ AutoGen) ຊ່ວຍໃນເວລາທີ່ວຽກງານສາມາດຂະໜານກັນ ຫຼື ໄດ້ຮັບຜົນປະໂຫຍດຈາກບົດບາດທີ່ແຕກຕ່າງກັນ (ນັກຄົ້ນຄວ້າ, ຜູ້ຂຽນໂປຣແກຣມ, QA). ການວາງແຜນແລ້ວປະຕິບັດດ້ວຍການວາງແຜນຄືນໃໝ່ແມ່ນພື້ນຖານກາງທີ່ໃຊ້ໄດ້ຈິງສຳລັບການຫຼີກລ່ຽງແຜນການທີ່ບໍ່ດີທີ່ແຂງກະດ້າງ.
ຂ້ອຍຈະເຮັດໃຫ້ຕົວແທນປອດໄພໄດ້ແນວໃດ ຖ້າມັນສາມາດປະຕິບັດຕົວຈິງໄດ້?
ໃຊ້ສິດອະນຸຍາດທີ່ມີສິດພິເສດໜ້ອຍທີ່ສຸດ ແລະ ຈຳກັດເຄື່ອງມືທີ່ມີຄວາມສ່ຽງຢູ່ເບື້ອງຫຼັງການອະນຸມັດ ຫຼື ຮູບແບບ "dry-run". ເພີ່ມງົບປະມານ ແລະ ຂີດຈຳກັດ: ຂັ້ນຕອນສູງສຸດ, ການໃຊ້ຈ່າຍສູງສຸດ, ແລະ ຂີດຈຳກັດການເອີ້ນເຄື່ອງມືຕໍ່ນາທີ. ແກ້ໄຂຂໍ້ມູນທີ່ລະອຽດອ່ອນກ່ອນການບັນທຶກ, ແລະ ແຍກນັກພັດທະນາອອກຈາກສະພາບແວດລ້ອມການຜະລິດ. ຮຽກຮ້ອງໃຫ້ມີການເຕືອນຄວາມບໍ່ແນ່ນອນ ຫຼື ການຊີ້ແຈງຄຳຖາມເມື່ອຂໍ້ມູນບໍ່ຊັດເຈນ, ແທນທີ່ຈະປ່ອຍໃຫ້ຄວາມໝັ້ນໃຈທົດແທນຫຼັກຖານ.
ຂ້ອຍຈະທົດສອບ ແລະ ປະເມີນຕົວແທນ AI ແນວໃດເພື່ອໃຫ້ມັນດີຂຶ້ນຕາມການເວລາ?
ສ້າງຊຸດສະຖານະການທີ່ມີເສັ້ນທາງທີ່ມີຄວາມສຸກ, ກໍລະນີຂອບ, ຄວາມລົ້ມເຫຼວຂອງເຄື່ອງມື, ການຮ້ອງຂໍທີ່ບໍ່ຊັດເຈນ, ແລະ ຄວາມພະຍາຍາມໃນການສີດຂໍ້ມູນ (ແບບ OWASP). ໃຫ້ຄະແນນຜົນໄດ້ຮັບເຊັ່ນ: ຄວາມສຳເລັດຂອງໜ້າວຽກ, ເວລາໃນການສຳເລັດ, ການກູ້ຄືນຈາກຄວາມຜິດພາດຂອງເຄື່ອງມື, ແລະ ການຮຽກຮ້ອງໂດຍບໍ່ມີຫຼັກຖານ. ທຸກຄັ້ງທີ່ທ່ານປ່ຽນໂຄງຮ່າງເຄື່ອງມື, ການກະຕຸ້ນ, ການດຶງຂໍ້ມູນ, ຫຼື ການຈັດຮູບແບບໜ່ວຍຄວາມຈຳ, ໃຫ້ເປີດໃຊ້ຊຸດຄືນໃໝ່. ຖ້າທ່ານບໍ່ສາມາດທົດສອບມັນໄດ້, ທ່ານບໍ່ສາມາດສົ່ງມັນໄດ້ຢ່າງໜ້າເຊື່ອຖື.
ຂ້ອຍຈະນຳໃຊ້ຕົວແທນໄດ້ແນວໃດໂດຍບໍ່ເຮັດໃຫ້ເວລາຊັກຊ້າ ແລະ ຄ່າໃຊ້ຈ່າຍເພີ່ມຂຶ້ນ?
ຮູບແບບທົ່ວໄປແມ່ນຕົວຄວບຄຸມທີ່ບໍ່ມີສະຖານະທີ່ມີບ່ອນເກັບຂໍ້ມູນສະຖານະພາຍນອກ (DB/Redis), ການບໍລິການເຄື່ອງມືຢູ່ເບື້ອງຫຼັງມັນ, ແລະການບັນທຶກ/ຕິດຕາມກວດກາທີ່ເຂັ້ມແຂງ (ມັກຈະເປັນ OpenTelemetry). ຄວບຄຸມຄ່າໃຊ້ຈ່າຍດ້ວຍການເກັບຂໍ້ມູນຄືນ, ສະຫຼຸບສະຖານະທີ່ກະທັດຮັດ, ຮູບແບບຂະໜາດນ້ອຍກວ່າສຳລັບການກຳນົດເສັ້ນທາງ/ການສະກັດ, ແລະ ການຈຳກັດ "ການຄິດຢ່າງເລິກເຊິ່ງ" ໃຫ້ກັບຂັ້ນຕອນທີ່ຍາກທີ່ສຸດ. ໃຊ້ຄິວສຳລັບໜ້າວຽກທີ່ຍາວນານ ເພື່ອບໍ່ໃຫ້ເຈົ້າຕ້ອງລໍຖ້າການຮ້ອງຂໍເວັບເປີດຢູ່. ໃຫ້ລວມເອົາ kill switch ສະເໝີ.
ເອກະສານອ້າງອີງ
-
ສະຖາບັນມາດຕະຖານ ແລະ ເຕັກໂນໂລຊີແຫ່ງຊາດ (NIST) - NIST AI RMF 1.0 (ຄວາມໜ້າເຊື່ອຖື ແລະ ຄວາມໂປ່ງໃສ) - nvlpubs.nist.gov
-
OpenAI - ຜົນຜະລິດທີ່ມີໂຄງສ້າງ - platform.openai.com
-
OpenAI - ຄູ່ມືການເອີ້ນຟັງຊັນ - platform.openai.com
-
OpenAI - ຄູ່ມືການຈຳກັດອັດຕາ - platform.openai.com
-
OpenAI - ແລ່ນ API - platform.openai.com
-
OpenAI - ຜູ້ຊ່ວຍເຮັດວຽກການໂທ - platform.openai.com
-
LangChain - ເອກະສານຕົວແທນ (JavaScript) - docs.langchain.com
-
LangChain - ເອກະສານເຄື່ອງມື (Python) - docs.langchain.com
-
LangChain - ພາບລວມຂອງໜ່ວຍຄວາມຈຳ - docs.langchain.com
-
arXiv - ເອກະສານ ReAct (ເຫດຜົນ + ການກະທຳ) - arxiv.org
-
arXiv - ເຈ້ຍ RAG - arxiv.org
-
ຫ້ອງສະໝຸດຜູ້ສ້າງ Amazon Web Services (AWS) - ການໝົດເວລາ, ການລອງໃໝ່, ແລະ ການຖອຍຫຼັງກັບ jitter - aws.amazon.com
-
OpenTelemetry - ຄູ່ມືການສັງເກດການ - opentelemetry.io
-
Stripe - ການຮ້ອງຂໍ Idempotent - docs.stripe.com
-
Google Cloud - ກົນລະຍຸດການລອງໃໝ່ (backoff + jitter) - docs.cloud.google.com
-
OWASP - 10 ອັນດັບຕົ້ນໆສຳລັບແອັບພລິເຄຊັນຮູບແບບພາສາຂະໜາດໃຫຍ່ - owasp.org
-
OWASP - LLM01 ການສັກຢາແບບວ່ອງໄວ - genai.owasp.org
-
LlamaIndex - ການແນະນຳກ່ຽວກັບ RAG - developers.llamaindex.ai
-
Microsoft - ເຄີເນລ ຄວາມໝາຍ - learn.microsoft.com
-
Microsoft AutoGen - ເຟຣມເວີກຫຼາຍຕົວແທນ (ເອກະສານ) - microsoft.github.io
-
CrewAI - ແນວຄວາມຄິດຂອງຕົວແທນ - docs.crewai.com
-
Haystack (deepset) - ເອກະສານກ່ຽວກັບ Retrievers - docs.haystack.deepset.ai