Structured Output ແມ່ນເຕັກນິກການບັງຄັບໃຫ້ຜົນລວມຂອງ LLM ມີໂຄງສ້າງທີ່ຊັດເຈນຕາມ Schema ທີ່ເຄັ່ງຄັດ ເຊັ່ນ: JSON Schema.

ຖ້າຫາກນຳເອົາການຕອບໂຕ້ຂອງ LLM ທີ່ເປັນຂໍ້ຄວາມອິດສະຫຼະໄປໃຊ້ໃນລະບົບທຸລະກິດໂດຍກົງ, ມັກຈະເກີດບັນຫາການແຍກຂໍ້ມູນ (Parse) ຜິດພາດ ຫຼື ຂໍ້ມູນຂາດຫາຍໄປຢ່າງບໍ່ຄາດຄິດ. ດ້ວຍການໃຊ້ Structured Output, ພຽງແຕ່ລະບຸ JSON Schema ໄວ້ໃນ response_format ຂອງ OpenAI API, ທ່ານກໍສາມາດໄດ້ຮັບການຕອບໂຕ້ໃນຮູບແບບທີ່ລະບົບທຸລະກິດສາມາດອ່ານໄດ້ໂດຍກົງຢ່າງໝັ້ນຄົງ.

ບົດຄວາມນີ້ມີຈຸດປະສົງສຳລັບວິສະວະກອນ ແລະ ສະຖາປະນິກທີ່ຕ້ອງການເຊື່ອມຕໍ່ LLM ເຂົ້າກັບລະບົບຂອງບໍລິສັດໂດຍກົງ. ໂດຍຈະອະທິບາຍທຸກຂັ້ນຕອນທີ່ຈຳເປັນຕໍ່ການນຳໃຊ້ຈິງ ຕັ້ງແຕ່ແນວທາງການອອກແບບ JSON Schema, ການຈັດຕັ້ງປະຕິບັດດ້ວຍ TypeScript, ການກວດສອບຄວາມຖືກຕ້ອງ (Validation), ການຈັດການຂໍ້ຜິດພາດ (Error handling), ໄປຈົນເຖິງຮູບແບບການເຊື່ອມຕໍ່ກັບ ERP ແລະ ຄິວແບບບໍ່ປະສານເວລາ (Asynchronous queue).

ເມື່ອສັ່ງໃຫ້ LLM "ສົ່ງເນື້ອຫາຄຳສັ່ງຊື້ໃນຮູບແບບ JSON", ບາງມື້ກໍຈະໄດ້ຮັບ {"item": "ກາເຟ"} ແຕ່ບາງມື້ກໍຈະໄດ້ຮັບເປັນປະໂຫຍກທີ່ວ່າ "ເນື້ອຫາຄຳສັ່ງຊື້ແມ່ນກາເຟ." — ເຄີຍມີປະສົບການແບບນີ້ບໍ່?

ການສົ່ງຜົນລວມຂອງຂໍ້ຄວາມແບບອິດສະຫຼະເຂົ້າສູ່ລະບົບທຸລະກິດໂດຍກົງ ຈະເຮັດໃຫ້ເກີດຄວາມຜິດພາດໃນການແຍກຂໍ້ມູນ (Parsing) ຫຼື ຂໍ້ມູນສູນຫາຍໂດຍບໍ່ຄາດຄິດ. ເຖິງແມ່ນວ່າຈະກຳນົດຮູບແບບໃນ Prompt ແລ້ວ, ແຕ່ເນື່ອງຈາກ LLM ເຮັດວຽກແບບຄວາມໜ້າຈະເປັນ ຈຶ່ງບໍ່ສາມາດຮັບປະກັນຄວາມສະໝ່ຳສະເໝີຂອງຜົນລວມໄດ້. ສົ່ງຜົນໃຫ້ລະບົບຝ່າຍຮັບຕ້ອງເພີ່ມການປະມວນຜົນເບື້ອງຕົ້ນທີ່ຊັບຊ້ອນ ແລະ ການຈັດການຂໍ້ຍົກເວັ້ນຕ່າງໆ ເຮັດໃຫ້ຕົ້ນທຶນໃນການເຊື່ອມຕໍ່ຂໍ້ມູນເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

Structured Output ແມ່ນກົນໄກທີ່ແກ້ໄຂບັນຫານີ້ໄດ້ຢ່າງເດັດຂາດ. ໂດຍການບັງຄັບໃຫ້ຜົນລວມຂອງ Model ຕ້ອງປະຕິບັດຕາມ Schema ທີ່ກຳນົດໄວ້, ຝ່າຍ Application ກໍສາມາດປະລະຂໍ້ສົມມຸດຕິຖານທີ່ວ່າ "ຮູບແບບອາດຈະບໍ່ຖືກຕ້ອງ" ໄດ້. ພຽງແຕ່ເມື່ອຄວາມສະຖຽນຂອງຮູບແບບຜົນລວມໄດ້ຮັບການຮັບປະກັນເທົ່ານັ້ນ, ການອອກແບບເພື່ອເຊື່ອມໂຍງ LLM ເຂົ້າກັບລະບົບທຸລະກິດໂດຍກົງຈຶ່ງຈະສາມາດເປັນຈິງໄດ້.

ໃນໄລຍະເລີ່ມຕົ້ນຂອງການນຳເອົາ LLM ມາລວມເຂົ້າກັບລະບົບທຸລະກິດ, ຫຼາຍຄົນມັກຄິດວ່າ "ພຽງແຕ່ສັ່ງໃນ Prompt ວ່າ 'ໃຫ້ຕອບກັບເປັນ JSON' ກໍພຽງພໍແລ້ວ". ແຕ່ໃນຄວາມເປັນຈິງ, ການໃຫ້ຜົນລາຍງານເປັນຂໍ້ຄວາມອິດສະຫຼະນັ້ນຈະກາຍເປັນປັດໄຈທີ່ເຮັດໃຫ້ລະບົບບໍ່ມີຄວາມສະຖຽນໃນການເຊື່ອມຕໍ່ຂໍ້ມູນ.

ໃນການສົ່ງອອກຂໍ້ຄວາມແບບອິດສະຫຼະແບບດັ້ງເດີມ, ການປະມວນຜົນການແຍກວິເຄາະ (Parsing) ມັກຈະກາຍເປັນການພະນັນທີ່ບໍ່ໝັ້ນຄົງ ເຊິ່ງ "ຖ້າໃຊ້ Regular Expression ກວດພົບກໍຖືວ່າສຳເລັດ, ຖ້າກວດບໍ່ພົບກໍຖືວ່າລົ້ມເຫຼວ". ເມື່ອໃຊ້ Structured Output, ແບບຈຳລອງຈະສ້າງຜົນລັດຕາມຂໍ້ຈຳກັດຂອງປະເພດ JSON Schema, ເຮັດໃຫ້ການປະມວນຜົນການແຍກວິເຄາະຢູ່ຝັ່ງແອັບພລິເຄຊັນມີຄວາມໝັ້ນຄົງຫຼາຍຂຶ້ນ.

ເຫດຜົນທີ່ຄວາມໝັ້ນຄົງເພີ່ມຂຶ້ນແມ່ນມາຈາກການທີ່ຮູບແບບຂອງຜົນລັດໄດ້ຮັບການຮັບປະກັນໄວ້ລ່ວງໜ້າ. ເນື່ອງຈາກປະເພດຂໍ້ມູນເຊັ່ນ string / number / boolean ຖືກບັງຄັບໃນລະດັບ Schema, ຂໍ້ຜິດພາດໃນການແປງປະເພດຂໍ້ມູນ (Type cast error) ຈຶ່ງເກີດຂຶ້ນໄດ້ຍາກ ແລະ ຄີ (Key) ທີ່ລະບຸໄວ້ໃນຟີວ required ຈະຖືກລວມຢູ່ໃນຜົນລັດສະເໝີ. ນອກຈາກນີ້, ຄວາມເລິກຂອງອາເຣ (Array) ແລະ ວັດຖຸ (Object) ຍັງຖືກກຳນົດໄວ້ຕາມ Schema, ເຮັດໃຫ້ບໍ່ເກີດການປ່ຽນແປງໂຄງສ້າງທີ່ບໍ່ຄາດຄິດ.

ໃນດ້ານການແບ່ງເງື່ອນໄຂ, ຖ້າຜົນລັດຢູ່ໃນ Schema ດຽວທີ່ຄົງທີ່, ການຕັ້ງຄ່າ strict: true ເພື່ອຮັກສາໃຫ້ການປະມວນຜົນການແຍກວິເຄາະງ່າຍຂຶ້ນແມ່ນມີປະສິດທິພາບ. ໃນທາງກົງກັນຂ້າມ, ຖ້າຄາດການວ່າຈະມີຮູບແບບຜົນລັດຫຼາຍຮູບແບບ, ການໃຊ້ oneOf ຫຼື anyOf ເພື່ອກຳນົດການແບ່ງເງື່ອນໄຂຢູ່ຝັ່ງ Schema ແລະ ການກວດສອບຟີວ type ຢູ່ຝັ່ງໂຄ້ດທີ່ຮັບຂໍ້ມູນແມ່ນການອອກແບບທີ່ປອດໄພ.

ການທີ່ການປະມວນຜົນການແຍກວິເຄາະມີຄວາມໝັ້ນຄົງຂຶ້ນ, ຍັງສົ່ງຜົນໃຫ້ຜົນກະທົບຕໍ່ຕັກກະຍະທາງທຸລະກິດ (Business logic) ທີ່ຢູ່ປາຍນ້ຳປ່ຽນແປງໄປນຳ.

ເມື່ອພະຍາຍາມເຊື່ອມຕໍ່ ERP ຫຼື ລະບົບທຸລະກິດເຂົ້າກັບ LLM, ທ່ານເຄີຍຮູ້ສຶກບໍ່ວ່າ "ເປັນຫຍັງຈຶ່ງຕ້ອງຂຽນຂະບວນການ Parsing ຫຼາຍຂະໜາດນີ້ ພຽງເພື່ອຮັບຜົນລັດຈາກ LLM?"

Structured Output ຈະຊ່ວຍຫຼຸດຕົ້ນທຶນການເຊື່ອມຕໍ່ນີ້ຢ່າງເປັນໂຄງສ້າງ. ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງກົນໄກນີ້ມີ 3 ປະການຄື:

• ການຕົກລົງກ່ຽວກັບ Schema ລ່ວງໜ້າ: ເນື່ອງຈາກມີການປະກາດຊື່ຟິວ, ປະເພດຂໍ້ມູນ ແລະ ລາຍການທີ່ຈຳເປັນທີ່ LLM ຈະສົ່ງກັບມາດ້ວຍ JSON Schema, ລະບົບຜູ້ຮັບຈຶ່ງສາມາດຮັບຮູ້ໄດ້ລ່ວງໜ້າວ່າ "ມີ Key ໃດແດ່ທີ່ປາກົດຢູ່".
• ການລະເວັ້ນຂະບວນການ Parsing: ບໍ່ຈຳເປັນຕ້ອງມີໂຄ້ດສຳລັບວິເຄາະຂໍ້ຄວາມອິດສະຫຼະດ້ວຍ Regular Expression ຫຼື ການແຍກສະຕຣິງອີກຕໍ່ໄປ, ສາມາດປ່ຽນເປັນ Object ໄດ້ດ້ວຍ JSON.parse ພຽງຄັ້ງດຽວ.
• ການລວມສູນການກວດສອບຄວາມຖືກຕ້ອງ (Validation): ເນື່ອງຈາກການກຳນົດ Schema ກາຍເປັນແຫຼ່ງຂໍ້ມູນທີ່ໜ້າເຊື່ອຖືໄດ້ພຽງແຫຼ່ງດຽວ, ຈຶ່ງສາມາດອ້າງອີງ Schema ດຽວກັນໄດ້ໃນແຕ່ລະຊັ້ນຂອງ Frontend, Backend ແລະ ການເຊື່ອມຕໍ່ ERP.

ຕົວຢ່າງເຊັ່ນ: ໃນກໍລະນີທີ່ສະກັດຂໍ້ມູນການສັ່ງຊື້ດ້ວຍ LLM, ແຕ່ກ່ອນຈຳເປັນຕ້ອງມີເຫດຜົນ (Logic) ສະເພາະຕົວເພື່ອດຶງ "ລະຫັດສິນຄ້າ", "ຈຳນວນ", ແລະ "ກຳນົດສົ່ງ" ອອກຈາກຂໍ້ຄວາມ. ຖ້າໃຊ້ Structured Output, ພຽງແຕ່ກຳນົດຟິວເຫຼົ່ານີ້ໄວ້ໃນ Schema, LLM ກໍຈະສົ່ງ JSON ທີ່ຈັດຮູບແບບມາໃຫ້ແລ້ວ. ຝ່າຍ ERP ສາມາດ POST ຂໍ້ມູນ JSON ທີ່ໄດ້ຮັບໄປຍັງ API Endpoint ໄດ້ໂດຍກົງ, ເຊິ່ງຈະຊ່ວຍຫຼຸດຕົ້ນທຶນການພັດທະນາຊັ້ນການປ່ຽນແປງຂໍ້ມູນ (Intermediate conversion layer) ໄດ້ຢ່າງມະຫາສານ.

ສະຫຼຸບ: ຄວາມສຳເລັດ ຫຼື ຄວາມລົ້ມເຫຼວຂອງການນຳໄປໃຊ້ງານ ແມ່ນຂຶ້ນກັບສາມປັດໄຈຫຼັກ ຄື: ການເລືອກໂມເດວ, ການອອກແບບ Schema ແລະ ສະພາບແວດລ້ອມໃນການພັດທະນາ. ການຂາດການກຽມພ້ອມລ່ວງໜ້າຈະນຳໄປສູ່ການແກ້ໄຂງານໃນຂັ້ນຕອນຕໍ່ໄປ.

ກ່ອນທີ່ຈະເລີ່ມຕົ້ນການນຳໃຊ້ Structured Output, ຈຳເປັນຕ້ອງມີການກຽມພ້ອມສາມຢ່າງ ຄື: ການກວດສອບໂມເດວທີ່ຮອງຮັບ, ແນວທາງການອອກແບບ JSON Schema ແລະ ການຈັດຕຽມ Library ທີ່ກ່ຽວຂ້ອງ. ຕໍ່ໄປນີ້ແມ່ນຄຳອະທິບາຍໃນແຕ່ລະຂັ້ນຕອນ.

ໃນຕອນທຳອິດ ເຮົາມັກຈະຄິດວ່າ "ຖ້າເປັນໂມເດວລຸ້ນໃໝ່ລ່າສຸດ ກໍສາມາດໃຊ້ Structured Outputs ໄດ້ທັງໝົດ" ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ສະຖານະການຮອງຮັບຈະແຕກຕ່າງກັນໄປຕາມການປະສົມປະສານລະຫວ່າງໂມເດວ ແລະ ເວີຊັນ ດັ່ງນັ້ນການກວດສອບລ່ວງໜ້າຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

Structured Outputs ຂອງ OpenAI (ຮູບແບບ json_schema) ໄດ້ລະບຸໄວ້ຢ່າງຊັດເຈນໃນທາງການວ່າ ສາມາດໃຊ້ງານໄດ້ໃນ GPT-4o, GPT-4 Turbo ແລະ ໂມເດວຕັ້ງແຕ່ gpt-3.5-turbo-1106 ເປັນຕົ້ນໄປ. ສ່ວນຮູບແບບ json_object ແບບເກົ່ານັ້ນ ໄດ້ຖືກແນະນຳໃຫ້ຫຼີກລ່ຽງ ແລະ ໃນການປະຕິບັດງານໃໝ່ໆ ຄວນຍຶດຖືນະໂຍບາຍພື້ນຖານໃນການເລືອກໃຊ້ຮູບແບບ json_schema ເປັນຫຼັກ.

ການອອກແບບ Schema ທີ່ດີ ຫຼື ບໍ່ດີ ມີຜົນກະທົບຢ່າງຫຼວງຫຼາຍຕໍ່ອັດຕາການຕິດຕາມຂອງ Model. Schema ທີ່ງ່າຍດາຍ ແລະ ຊັດເຈນ ຈະເຮັດໃຫ້ LLM ມີແນວໂນ້ມທີ່ຈະປະຕິບັດຕາມຄຳສັ່ງໄດ້ຢ່າງຖືກຕ້ອງ.

ນະໂຍບາຍພື້ນຖານໃນການອອກແບບ

• ຈຳກັດ Field ໃຫ້ມີໜ້ອຍທີ່ສຸດເທົ່າທີ່ຈຳເປັນ: ຄວນກຳນົດຈຳນວນ Property ຕໍ່ 1 Schema ບໍ່ໃຫ້ເກີນ 10 ຢ່າງ. ຍິ່ງ Field ເພີ່ມຂຶ້ນຫຼາຍເທົ່າໃດ ກໍຍິ່ງເຮັດໃຫ້ Model ມີໂອກາດຕື່ມຄ່າທີ່ຜິດພາດຫຼາຍຂຶ້ນເທົ່ານັ້ນ.
• ລະບຸປະເພດ (Type) ໃຫ້ຊັດເຈນ: ບໍ່ຄວນໃຊ້ພຽງແຕ່ string ເທົ່ານັ້ນ ແຕ່ຄວນນຳໃຊ້ enum ຫຼື format (ຕົວຢ່າງ: "format": "date") ເຂົ້າມາຊ່ວຍ ເພື່ອລະບຸຂອບເຂດຂອງຄ່າທີ່ຍອມຮັບໄດ້ຢ່າງຈະແຈ້ງ.
• ຢ່າລະເລີຍການໃສ່ description: ການໃສ່ description ໃຫ້ກັບແຕ່ລະ Field ຈະຊ່ວຍໃຫ້ Model ສາມາດຕີຄວາມໝາຍຂອງເຈດຕະນາໄດ້ຢ່າງຖືກຕ້ອງງ່າຍຂຶ້ນ.

ການຕັດສິນໃຈກ່ຽວກັບການກຳນົດ Type ໃນແຕ່ລະກໍລະນີ

ການຈັດການ Field ທີ່ຈຳເປັນ (Required) ແລະ ທາງເລືອກ (Optional) ຈຳເປັນຕ້ອງເລືອກໃຊ້ໃຫ້ເໝາະສົມກັບຈຸດປະສົງ. ນະໂຍບາຍພື້ນຖານຄື: Field ທີ່ໃຊ້ສຳລັບການຂຽນຂໍ້ມູນລົງໃນລະບົບທຸລະກິດຄວນລວມຢູ່ໃນ required, ສ່ວນຂໍ້ມູນເສີມ ຫຼື Field ສຳລັບການຂະຫຍາຍໃນອະນາຄົດ ຄວນກຳນົດເປັນ Optional ໂດຍໃຊ້ nullable. ໃນທາງກົງກັນຂ້າມ, ຖ້າຕ້ອງການໃຫ້ LLM ເປັນຜູ້ຕັດສິນໃຈວ່າຈະມີຄ່າ ຫຼື ບໍ່ນັ້ນ ຄວນອອກແບບໂດຍອະນຸຍາດໃຫ້ເປັນ null ໂດຍມີເງື່ອນໄຂວ່າຈະຕ້ອງມີການປະມວນຜົນຕໍ່ໃນຊັ້ນ Validation.

"ຫ້ອງສະໝຸດ (Library) ໃດທີ່ຄວນຕິດຕັ້ງເພື່ອໃຫ້ເຮັດວຽກໄດ້ໄວທີ່ສຸດ?" —— ກ່ອນທີ່ຈະເລີ່ມລົງມືປະຕິບັດງານ, ການຫາຄຳຕອບໃຫ້ກັບຄຳຖາມນີ້ຈະຊ່ວຍປ້ອງກັນການແກ້ໄຂງານຄືນໃໝ່ໃນພາຍຫຼັງ.

ໃນກໍລະນີທີ່ໃຊ້ TypeScript, ອົງປະກອບຂັ້ນຕໍ່າສຸດມີດັ່ງນີ້:

• openai (SDK ທາງການ): ຮອງຮັບການສົ່ງອອກຂໍ້ມູນແບບມີໂຄງສ້າງ (Structured Output) ຜ່ານ response_format ໂດຍກົງ
• zod: ຫ້ອງສະໝຸດສຳລັບການກຳນົດ Schema ແລະ ການກວດສອບຄວາມຖືກຕ້ອງໃນຂະນະເຮັດວຽກ (Runtime Validation) ດ້ວຍຄວາມປອດໄພທາງດ້ານ Type
• zod-to-json-schema ຫຼື ຟັງຊັນ zodResponseFormat ທີ່ມາພ້ອມກັບ SDK ຂອງ openai: ສຳລັບການປ່ຽນ Zod Schema ໃຫ້ເປັນ JSON Schema ໂດຍອັດຕະໂນມັດ

ຕົວຢ່າງຄຳສັ່ງໃນການຕິດຕັ້ງມີດັ່ງນີ້:

ແນະນຳໃຫ້ໃຊ້ Node.js ເວີຊັນ LTS (18 ຂຶ້ນໄປ) ເນື່ອງຈາກມີການຮອງຮັບ fetch ໂດຍກຳເນີດ ເຊິ່ງຈະເຮັດໃຫ້ການເພິ່ງພາອາໄສ (Dependency) ຂອງ SDK ມີຄວາມສະຖຽນ.

ສຳລັບການຈັດການຕົວແປສະພາບແວດລ້ອມ (Environment Variables), ຄວນໃຊ້ dotenv ຄວບຄູ່ກັນໄປ ແລະ ຫຼັກການພື້ນຖານຄືຫ້າມຂຽນ OPENAI_API_KEY ລົງໃນໂຄ້ດໂດຍກົງ. ໃນຂະບວນການ ຫຼື Pipeline ຂອງ CI/CD, ແນະນຳໃຫ້ໃຊ້ການຕັ້ງຄ່າທີ່ມອບໝາຍໃຫ້ບໍລິການຈັດການຄວາມລັບ (Secret Management Service) ເຊັ່ນ GitHub Actions Secrets ຫຼື Azure Key Vault.

ສະຫຼຸບ: ສາມາດປະຕິບັດໄດ້ໃນ 3 ຂັ້ນຕອນ ຄື: ການອອກແບບ Schema, ການຕັ້ງຄ່າ API Parameter ແລະ ການກວດສອບຄວາມຖືກຕ້ອງ (Validation).

ການປະຕິບັດ Structured Output ແມ່ນດຳເນີນໄປຕາມລຳດັບ ຄື: ການກຳນົດ Schema, ການລວມເຂົ້າກັບ API ແລະ ການກວດສອບ Response. ການປະຕິບັດຕາມແຕ່ລະຂັ້ນຕອນຢ່າງຖືກຕ້ອງ ຈະຊ່ວຍໃຫ້ທ່ານສາມາດສ້າງ ຂະບວນການ ຫຼື Pipeline ທີ່ມີຄວາມສະຖຽນ ເພື່ອສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ ລະບົບທຸລະກິດໂດຍກົງຈາກຜົນລວມຂອງ LLM ໄດ້.

ບາດກ້າວທຳອິດຂອງການອອກແບບ Schema ທີ່ນັກພັດທະນາຫຼາຍຄົນມັກພາດກໍຄື ແນວຄວາມຄິດທີ່ວ່າ "ຄ່ອຍມາຂະຫຍາຍເພີ່ມເຕີມໃນພາຍຫຼັງກໍໄດ້". ໃນຄວາມເປັນຈິງແລ້ວ, ຖ້າບໍ່ກຳນົດຄວາມເຂັ້ມງວດຂອງປະເພດຂໍ້ມູນ (Type) ແລະ ໂຄງສ້າງຂອງ Field ໃຫ້ຊັດເຈນຕັ້ງແຕ່ຂັ້ນຕອນການອອກແບບເບື້ອງຕົ້ນ, ລະບົບທີ່ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ໃນພາຍຫຼັງກໍຈະເກີດຄວາມຜິດພາດໄດ້ງ່າຍ.

ນະໂຍບາຍພື້ນຖານໃນການກຳນົດ Schema

ກ່ອນອື່ນ ໃຫ້ລະບຸ Field ທີ່ຈຳເປັນສຳລັບການສະແດງຜົນອອກມາໃຫ້ຄົບຖ້ວນ, ຈາກນັ້ນກຳນົດ Type ທີ່ເໝາະສົມໃຫ້ກັບແຕ່ລະ Field.

• ຂໍ້ມູນປະເພດຂໍ້ຄວາມໃຫ້ລະບຸຢ່າງຊັດເຈນດ້ວຍ "type": "string" ແລະ ຕົວເລກດ້ວຍ "type": "number" ຫຼື "integer"
• ຂໍ້ມູນທີ່ມີຄ່າຄົງທີ່ໃຫ້ໃຊ້ "enum" ເພື່ອຈຳກັດບໍ່ໃຫ້ Model ສົ່ງຄ່າຂໍ້ຄວາມອື່ນທີ່ບໍ່ໄດ້ກຳນົດໄວ້
• ລະບຸ Field ທີ່ຈຳເປັນທັງໝົດໄວ້ໃນ Array ຂອງ required ແລະ ແຍກ Field ທີ່ເປັນທາງເລືອກ (Optional) ອອກມາຢ່າງຈະແຈ້ງ

ຕົວຢ່າງເຊັ່ນ: ໃນກໍລະນີທີ່ຕ້ອງການດຶງຂໍ້ມູນການສັ່ງຊື້, ການເລີ່ມຕົ້ນດ້ວຍໂຄງສ້າງຂັ້ນຕອນຕ່ຳສຸດຢ່າງ order_id (string), amount (number), ແລະ status (enum: "pending" / "confirmed" / "cancelled") ຈະຊ່ວຍໃຫ້ Model ມີຄວາມຖືກຕ້ອງຕາມຄຳສັ່ງຫຼາຍຂຶ້ນ.

ການເຮັດວຽກຮ່ວມກັບການອອກແບບ Prompt

ນອກຈາກການກຳນົດ Schema ແລ້ວ, ການລະບຸເຈດຕະນາຂອງໂຄງສ້າງຂໍ້ມູນລົງໃນ System Prompt ຢ່າງຊັດເຈນກໍມີຄວາມສຳຄັນເຊັ່ນກັນ. ການສັ່ງພຽງແຕ່ວ່າ "ໃຫ້ຕອບກັບເປັນ JSON ເທົ່ານັ້ນ" ອາດຈະບໍ່ພຽງພໍ, ແຕ່ການເພີ່ມຂໍ້ຄວາມທີ່ສະແດງເຖິງຄວາມຄາດຫວັງທີ່ເປັນຮູບປະທຳ ເຊັ່ນ: "ໃຫ້ປະຕິບັດຕາມ Field ຕໍ່ໄປນີ້ ແລະ ສະແດງຜົນຕາມ Type ທີ່ກຳນົດໄວ້" ຈະຊ່ວຍໃຫ້ Model ສາມາດປະຕິບັດຕາມ Schema ໄດ້ງ່າຍຂຶ້ນ.

ເມື່ອການກຳນົດ Schema ສຳເລັດແລ້ວ, ຂັ້ນຕອນຕໍ່ໄປແມ່ນການຕັ້ງຄ່າພາຣາມິເຕີໃນເວລາເອີ້ນໃຊ້ API. ໃນ OpenAI API, ການສົ່ງ {"type": "json_schema", "json_schema": {...}} ໄປທີ່ response_format ຈະເປັນການເປີດໃຊ້ງານ Structured Outputs. ເນື່ອງຈາກວິທີ "json_object" ແບບເກົ່າໄດ້ຖືກຍົກເລີກການນຳໃຊ້ແລ້ວ, ດັ່ງນັ້ນໃນການນຳໃຊ້ໃໝ່ໃຫ້ເລືອກວິທີ "json_schema" ແທນ.

ການຕັ້ງຄ່າພື້ນຖານໃນ TypeScript ມີດັ່ງນີ້:

ໂດຍຄ່າເລີ່ມຕົ້ນແລ້ວ, ທຸງ strict ຈະເປັນ false, ແຕ່ສຳລັບການເຊື່ອມຕໍ່ລະບົບທຸລະກິດ ຂໍແນະນຳໃຫ້ຕັ້ງຄ່າເປັນ true.

ເມື່ອ API ສົ່ງ JSON ກັບມາ, ປະສົບການທີ່ມັກພົບເຫັນເລື້ອຍໆໃນໜ້າວຽກຕົວຈິງຄື "ທັງທີ່ຄວນຈະເປັນໄປຕາມ Schema ແລ້ວ ແຕ່ກໍຍັງເກີດຂໍ້ຜິດພາດໃນການ Parse". ເຖິງແມ່ນວ່າຈະເປີດໃຊ້ງານ Structured Outputs ແລ້ວ, ແຕ່ກໍຍັງມີກໍລະນີທີ່ JSON ບໍ່ສົມບູນສົ່ງກັບມາເນື່ອງຈາກເຄືອຂ່າຍຕັດຂາດ ຫຼື ຂໍ້ມູນຂອງ Model ເກີນຂອບເຂດ, ດັ່ງນັ້ນຊັ້ນການກວດສອບ (Validation layer) ຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

ການປະມວນຜົນ Response ຄວນຈັດຕັ້ງປະຕິບັດຕາມ 3 ຂັ້ນຕອນດັ່ງນີ້ເພື່ອຄວາມປອດໄພ:

• JSON Parse: ໃຊ້ try-catch ຄອບ JSON.parse() ເພື່ອຈັບຂໍ້ຜິດພາດທາງໄວຍາກອນໃນເບື້ອງຕົ້ນ
• Schema Validation: ກວດສອບຄວາມສອດຄ່ອງຂອງ Schema ໂດຍໃຊ້ Library ເຊັ່ນ Zod ຫຼື ajv
• Business Rule Validation: ກວດສອບຄວາມສອດຄ່ອງທາງຄວາມໝາຍຂອງຂອບເຂດຄ່າ ແລະ ຟີລທີ່ຈຳເປັນ

ຕໍ່ໄປນີ້ແມ່ນຕົວຢ່າງການຈັດຕັ້ງປະຕິບັດໂດຍໃຊ້ TypeScript + Zod:

ສະຫຼຸບ: ຫຼັງຈາກໄດ້ຮັບຜົນລວມທີ່ມີໂຄງສ້າງແລ້ວ, ສາມາດເຊື່ອມຕໍ່ໂດຍກົງກັບລະບົບໄດ້ຜ່ານ 3 ເສັ້ນທາງ ຄື: ການປ້ອນຂໍ້ມູນເຂົ້າ ERP ໂດຍອັດຕະໂນມັດ, ຄິວແບບບໍ່ປະສານເວລາ (Asynchronous queue), ແລະ ການສ້າງໂຄ້ດທີ່ມີຄວາມປອດໄພດ້ານປະເພດຂໍ້ມູນ (Type-safe code).

ເມື່ອໄດ້ຮັບ JSON ທີ່ປະຕິບັດຕາມສະກີມາ (Schema) ແລ້ວ, ສິ່ງທີ່ຈະຕ້ອງພິຈາລະນາຕໍ່ໄປຄືວິທີການສົ່ງຂໍ້ມູນເຂົ້າສູ່ລະບົບທຸລະກິດຕົວຈິງ. ຕໍ່ໄປນີ້ຈະອະທິບາຍຮູບແບບການຈັດຕັ້ງປະຕິບັດແຕ່ລະຢ່າງ ບໍ່ວ່າຈະເປັນການເຊື່ອມຕໍ່ຜ່ານ REST API, ການປະມວນຜົນແບບບໍ່ປະສານເວລາ, ແລະ ການແບ່ງປັນປະເພດຂໍ້ມູນ (Type) ກັບຝັ່ງ Front-end.

ການປ້ອນຂໍ້ມູນເຂົ້າ ERP ໂດຍອັດຕະໂນມັດມັກຈະຖືກຄິດວ່າ "ພຽງແຕ່ລອງສົ່ງ POST ໄປກໍໜ້າຈະໄດ້ແລ້ວ", ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ການກວດສອບ Schema ດ້ວຍ Structured Output ກ່ອນການສົ່ງຂໍ້ມູນ ຈະຊ່ວຍໃຫ້ການຈັດການ Rollback ຢູ່ປາຍທາງຫຼຸດລົງຈົນເກືອບເປັນສູນ.

ໃນກໍລະນີທີ່ສົ່ງ JSON ທີ່ LLM ຕອບກັບມາໄປຍັງ REST API endpoint ຂອງ ERP ໂດຍກົງ, ການເຮັດໃຫ້ຂັ້ນຕອນຕໍ່ໄປນີ້ເປັນມາດຕະຖານແມ່ນມີຄວາມສຳຄັນຫຼາຍ:

1. ການກວດສອບ Schema (Schema Validation): ທັນທີທີ່ໄດ້ຮັບການຕອບກັບຈາກ LLM, ໃຫ້ກວດສອບດ້ວຍ JSON Schema ທີ່ກຳນົດໄວ້. ການກວດສອບນີ້ຈະຊ່ວຍກວດພົບຄວາມບໍ່ສອດຄ່ອງຂອງປະເພດຂໍ້ມູນ (Type) ຫຼື ຟີລທີ່ຈຳເປັນທີ່ຂາດຫາຍໄປ.
2. ການຈັບຄູ່ຟີລ (Field Mapping): ໃນກໍລະນີທີ່ຊື່ Key ຂອງຜົນລວມຈາກ LLM ບໍ່ກົງກັບຊື່ຟີລທີ່ ERP API ຕ້ອງການ, ໃຫ້ໃຊ້ຊັ້ນ Mapper ບາງໆເພື່ອແປງຂໍ້ມູນ. ການເຮັດໃຫ້ຊັ້ນນີ້ເປັນອິດສະຫຼະຈະຊ່ວຍຫຼຸດຜ່ອນຂອບເຂດຜົນກະທົບເມື່ອມີການປ່ຽນແປງ Schema.
3. ການກຳນົດ Idempotency Key: ເພື່ອປ້ອງກັນບໍ່ໃຫ້ເກີດການລົງທະບຽນຊ້ຳຊ້ອນຢູ່ຝັ່ງ ERP, ໃຫ້ເພີ່ມ Idempotency Key (ຕົວຢ່າງ: Idempotency-Key) ໃສ່ໃນ Request Header.
4. ການສົ່ງກັບຄືນເມື່ອເກີດຂໍ້ຜິດພາດ: ຖ້າ ERP ຕອບກັບມາເປັນ 4xx / 5xx, ແທນທີ່ຈະສ້າງຜົນລວມຈາກ LLM ໃໝ່ທັນທີ, ໃຫ້ກວດສອບ Log ຂອງຊັ້ນ Mapping ກ່ອນເພື່ອແຍກແຍະບັນຫາຂອງການກຳນົດຟີລ.

ຕົວຢ່າງການປະຕິບັດງານດ້ວຍ TypeScript ໂດຍຫຍໍ້ມີດັ່ງນີ້:

ເມື່ອສົ່ງເອກະສານຈຳນວນຫຼາຍໃຫ້ LLM ໃນຄັ້ງດຽວ, ການສັ່ງງານ API ແບບ ເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນ ໂດຍກົງແບບຂະໜານ (Parallel) ມັກຈະເຮັດໃຫ້ເກີດຂໍ້ຜິດພາດດ້ານອັດຕາການຈຳກັດ (Rate limit error) ເລື້ອຍໆ ແລະ ເຮັດໃຫ້ການປະມວນຜົນໂດຍລວມບໍ່ສະຖຽນ. ການນຳໃຊ້ຄິວແບບບໍ່ປະສານເວລາ (Asynchronous queue) ເຂົ້າມາຊ່ວຍ ຈະສາມາດເຮັດໃຫ້ທັງປະສິດທິພາບ (Throughput) ແລະ ຄວາມໜ້າເຊື່ອຖືມີຄວາມສົມດຸນກັນ.

ໃນກໍລະນີທີ່ຈຳນວນການປະມວນຜົນມີໜ້ອຍ (ປະມານສິບກວ່າລາຍການ) ການປະມວນຜົນແບບຂະໜານດ້ວຍ Promise.allSettled ກໍພຽງພໍແລ້ວ, ແຕ່ສຳລັບການປະມວນຜົນແບບ Batch ທີ່ມີຫຼາຍຮ້ອຍລາຍການຂຶ້ນໄປ, ການກະຈາຍວຽກຜ່ານ Message queue ເຊັ່ນ BullMQ ຫຼື AWS SQS ຈະເໝາະສົມກວ່າ.

ທ່ານເຄີຍມີປະສົບການທີ່ໄດ້ປະຕິບັດ Structured Output ໃນຝັ່ງ Backend ແລ້ວ ແຕ່ເກີດ Runtime error ເນື່ອງຈາກບໍ່ສອດຄ່ອງກັບການກຳນົດ Type ໃນຝັ່ງ Frontend ບໍ? ບັນຫານີ້ສາມາດແກ້ໄຂໄດ້ໂດຍການລວມສູນ "Single Source of Truth" ຂອງ Type ໄວ້ທີ່ JSON Schema.

ຂະບວນການພື້ນຖານໃນການສ້າງ Type ມີດັ່ງນີ້:

• ຈັດວາງ JSON Schema ໄວ້ໃນໄດເຣັກທໍຣີທີ່ໃຊ້ຮ່ວມກັນ (Shared directory) ຂອງ Repository
• ໃຊ້ເຄື່ອງມືເຊັ່ນ json-schema-to-typescript (json2ts) ເພື່ອສ້າງການກຳນົດ Type ຂອງ TypeScript (.d.ts) ໂດຍອັດຕະໂນມັດ
• ທັງຝັ່ງ Frontend ແລະ Backend ຈະນຳເຂົ້າ (Import) ແລະ ນຳໃຊ້ການກຳນົດ Type ນີ້

ດ້ວຍວິທີນີ້, ເມື່ອມີການປ່ຽນແປງ Schema, ການກຳນົດ Type ກໍຈະຖືກອັບເດດໂດຍອັດຕະໂນມັດ ແລະ ສາມາດກວດພົບຄວາມບໍ່ສອດຄ່ອງໄດ້ໃນເວລາ Compile.

ຈຸດສຳຄັນຂອງຕົວຢ່າງການປະຕິບັດ ມີດັ່ງນີ້:

ເນື່ອງຈາກ Response ຂອງ LLM ຖືກດຶງມາໂດຍໃຊ້ strict: true, ມັນຈຶ່ງບໍ່ມີ Field ທີ່ນອກເໜືອໄປຈາກ Schema. ເຮັດໃຫ້ຝັ່ງ Frontend ບໍ່ຈຳເປັນຕ້ອງຂຽນໂຄ້ດ Validation ເພີ່ມເຕີມ.

ສະຫຼຸບ: ຄວາມຜິດພາດທີ່ມັກເກີດຂຶ້ນຫຼັງຈາກການນຳໄປໃຊ້ງານ ຈະສຸມໃສ່ 3 ຈຸດຫຼັກ ຄື: ການອອກແບບ Schema, ການຈັດການ null ແລະ ການຄວບຄຸມເວີຊັນ.

ເຖິງແມ່ນວ່າຈະມີການນຳໃຊ້ Structured Output ແລ້ວ, ແຕ່ບັນຫາທີ່ເກີດຈາກ Schema ກໍຍັງມີໂອກາດເກີດຂຶ້ນໄດ້ງ່າຍ. ໃນຫົວຂໍ້ H3 ຕໍ່ໄປນີ້, ພວກເຮົາຈະສະຫຼຸບຮູບແບບຄວາມຜິດພາດທີ່ພົບເລື້ອຍ ແລະ ວິທີການຫຼີກລ່ຽງ.

ຫຼາຍຄົນມັກຄິດວ່າການອອກແບບ Schema ຢ່າງລະອຽດຈະຊ່ວຍເພີ່ມຄວາມຖືກຕ້ອງໄດ້, ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ, ຍິ່ງ Schema ມີຄວາມຊັບຊ້ອນຫຼາຍເທົ່າໃດ, ໂມເດວ (Model) ກໍຍິ່ງມີແນວໂນ້ມທີ່ຈະບໍ່ສາມາດປະຕິບັດຕາມໄດ້ຫຼາຍຂຶ້ນເທົ່ານັ້ນ.

ຕົວຢ່າງຄວາມຜິດພາດທີ່ພົບເຫັນໄດ້ທົ່ວໄປ ມີດັ່ງນີ້:

• Object ທີ່ມີການຊ້ອນກັນ (Nest) ຕັ້ງແຕ່ 4-5 ຊັ້ນຂຶ້ນໄປ
• ການກຳນົດນິຍາມທີ່ອັດແໜ້ນໄປດ້ວຍ Field ຫຼາຍກວ່າ 30 ລາຍການໃນ Schema ດຽວ
• ການໃຊ້ oneOf / anyOf ເພື່ອແຍກປະເພດແບບປະສົມຫຼາຍເກີນໄປ

ເມື່ອໃຫ້ Schema ທີ່ຊັບຊ້ອນແບບນີ້, ໂມເດວອາດຈະສົ່ງຜົນລັດທີ່ຂ້າມ Field ທີ່ຈຳເປັນ ຫຼື ຕີຄວາມໝາຍຂອງ Type ຜິດພາດ. ເຖິງແມ່ນວ່າ Structured Outputs ຂອງ OpenAI ຈະຮອງຮັບ JSON Schema ໃນຮູບແບບຍ່ອຍ, ແຕ່ຍິ່ງ Schema ມີຂະໜາດໃຫຍ່ຂຶ້ນ, ການໃຊ້ງານ Token ກໍຈະເພີ່ມຂຶ້ນ ແລະ ພະລັງການປະມວນຜົນທີ່ຈັດສັນໄວ້ສຳລັບ "ການເຂົ້າໃຈ Schema" ພາຍໃນ Context ກໍຈະຖືກກົດດັນ.

ວິທີແກ້ໄຂຄື "ການແບ່ງສ່ວນ ແລະ ການຈັດລຳດັບຂັ້ນ (Segmentation and Staging)".

• ຄວນຄວບຄຸມຈຳນວນ Field ໃນ Schema ທີ່ໃຊ້ໃນການເອີ້ນໃຊ້ API ແຕ່ລະຄັ້ງໃຫ້ຢູ່ທີ່ປະມານ 10-15 ລາຍການ
• ແບ່ງ Object ທີ່ຊັບຊ້ອນອອກເປັນການເອີ້ນໃຊ້ຫຼາຍຄັ້ງ ແລ້ວນຳຜົນລັດມາລວມກັນຢູ່ຝັ່ງແອັບພລິເຄຊັນ
• ໃຊ້ $defs ເພື່ອກຳນົດນິຍາມ Sub-schema ທີ່ສາມາດນຳກັບມາໃຊ້ໃໝ່ໄດ້ ເພື່ອໃຫ້ເບິ່ງງ່າຍຂຶ້ນ

ນອກຈາກນີ້, ໃນກໍລະນີທີ່ຕັ້ງຄ່າ strict: true ໄວ້, ຈຳເປັນຕ້ອງລະບຸທຸກ Field ທີ່ມີຢູ່ໃນ Schema ໄວ້ໃນ required. ຕ້ອງລະວັງໃຫ້ດີ ເພາະຖ້າຫາກຍັງບໍ່ໄດ້ເພີ່ມ Field ທີ່ເປັນທາງເລືອກ (Optional) ເຂົ້າໄປໃນ required, ມັນອາດຈະກາຍເປັນສາເຫດທີ່ເຮັດໃຫ້ເກີດ Validation Error (ລາຍລະອຽດຈະອະທິບາຍໃນພາກຕໍ່ໄປ).

ການຈັດການກັບ Optional Field ເບິ່ງຄືວ່າງ່າຍດາຍ ແຕ່ກໍເປັນຈຸດທີ່ມັກເກີດຂໍ້ຜິດພາດໃນການປະຕິບັດງານໄດ້ງ່າຍ.

ຂໍ້ຜິດພາດທີ່ພົບເລື້ອຍຄື ການທີ່ບໍ່ໄດ້ກຳນົດໃຫ້ field ຢູ່ໃນ array ຂອງ required ໃນ JSON Schema ເຮັດໃຫ້ບໍ່ໄດ້ຄາດຄິດວ່າ Model ອາດຈະລະເວັ້ນ field ນັ້ນໄປຢ່າງສິ້ນເຊີງ. ຖ້າ Code ຝັ່ງຮັບຂໍ້ມູນເຂົ້າເຖິງ response.discount_rate ໂດຍກົງ ຈະເຮັດໃຫ້ເກີດຂໍ້ຜິດພາດ undefined ຫຼື null reference exception ເນື່ອງຈາກ field ດັ່ງກ່າວບໍ່ມີຢູ່ແທ້.

ສິ່ງທີ່ຕ້ອງລະວັງຢູ່ທີ່ນີ້ຄື ພຶດຕິກຳທີ່ແຕກຕ່າງກັນລະຫວ່າງກໍລະນີທີ່ field ຖືກລະເວັ້ນ ແລະ ກໍລະນີທີ່ສົ່ງຄ່າກັບມາເປັນ null. ໃນກໍລະນີທີ່ຖືກລະເວັ້ນ, key ຈະບໍ່ມີຢູ່ໃນ object ເລີຍ, ສ່ວນໃນກໍລະນີທີ່ສົ່ງຄ່າເປັນ null ກັບມາ, key ຈະມີຢູ່ແຕ່ຄ່າເປັນວ່າງ ເຊິ່ງຄວາມແຕກຕ່າງນີ້ເຮັດໃຫ້ເຮົາຕ້ອງຂຽນ Logic ການກວດສອບ (Validation) ແຍກອອກຈາກກັນ.

ຮູບແບບຄວາມຜິດພາດທີ່ພົບເລື້ອຍຄື ການກຳນົດ Optional Field ໄວ້ໃນ Schema ໂດຍບໍ່ໄດ້ກຳນົດ Type ໃຫ້ຮອງຮັບຄ່າ null ເຊັ່ນ ["string", "null"]. ເມື່ອ Model ສົ່ງຄ່າ null ກັບມາ ກໍຈະເກີດຂໍ້ຜິດພາດໃນການກວດສອບທັນທີ. ນອກຈາກນີ້, Code ຝັ່ງຮັບທີ່ບໍ່ໄດ້ໃຊ້ ?? ຫຼື ?. ເພື່ອກຳນົດຄ່າເລີ່ມຕົ້ນ ແຕ່ອ້າງອີງໂດຍກົງ ກໍຈະເຮັດໃຫ້ເກີດ Runtime Error ເມື່ອ key ຫາຍໄປ. ວິທີແກ້ໄຂແມ່ນງ່າຍດາຍ ຄືການຕັ້ງຄ່າ strict: true ເພື່ອກຳນົດໃຫ້ທຸກ field ຢູ່ໃນ required ພ້ອມກັບລະບຸ "type": ["string", "null"] ໃຫ້ຊັດເຈນ. ການເຮັດແບບນີ້ຈະຊ່ວຍໃຫ້ສາມາດຄວບຄຸມທັງການລະເວັ້ນ ແລະ ການສົ່ງຄ່າ null ໄດ້ຢ່າງຕັ້ງໃຈ.

"ເມື່ອອາທິດກ່ອນຍັງໃຊ້ງານໄດ້ປົກກະຕິ ແຕ່ມື້ນີ້ກັບເກີດຂໍ້ຜິດພາດໃນການ Parse ຢ່າງກະທັນຫັນ" — ຄຳຖາມລັກສະນະນີ້ມັກຈະເກີດຂຶ້ນເລື້ອຍໆໃນໜ້າວຽກທີ່ບໍ່ມີການຈັດການ Version ຂອງ Schema ຢ່າງເປັນລະບົບ.

ໃນເວລາທີ່ອັບເດດ JSON Schema, ການເພີ່ມ Field ເຂົ້າໄປມັກຈະຮັກສາຄວາມເຂົ້າກັນໄດ້ກັບເວີຊັນກ່ອນໜ້າ (Backward Compatibility) ໄດ້ງ່າຍ ແຕ່ການລຶບ Field, ການປ່ຽນແປງ Type ຫຼື ການປ່ຽນແປງ Flag ທີ່ຈຳເປັນ (Required) ຈະກາຍເປັນການປ່ຽນແປງທີ່ສົ່ງຜົນກະທົບຕໍ່ລະບົບ (Breaking Change). ເມື່ອມີການປ່ຽນແປງ Prompt ຫຼື ຄຳນິຍາມ Schema ທາງຝັ່ງ LLM, ມັນມີຄວາມສ່ຽງທີ່ Code ຝັ່ງຮັບຂໍ້ມູນທີ່ມີຢູ່ແລ້ວຈະໃຊ້ງານບໍ່ໄດ້ທັນທີ.

ຮູບແບບການປ່ຽນແປງທີ່ສົ່ງຜົນກະທົບຕໍ່ລະບົບ (Breaking Change) ທີ່ພົບເລື້ອຍ

• ການປ່ຽນ Field ຈາກ Type string ມາເປັນ number
• ການປ່ຽນ Field ທີ່ເປັນທາງເລືອກ (Optional) ມາເປັນ required
• ການປ່ຽນຊື່ Field (ຕົວຢ່າງ: price → unit_price)
• ການປ່ຽນແປງໂຄງສ້າງຂອງ Object ທີ່ຊ້ອນກັນ (Nested Object)

ວິທີການຈັດການທີ່ແນະນຳ

1. ຈັດການໄຟລ໌ Schema ໄວ້ໃນ Code Repository ແລະ ຕິດຕາມການປ່ຽນແປງຜ່ານ Pull Request
2. ກຳນົດ Field version ໄວ້ໃນ Schema ເພື່ອໃຫ້ຝັ່ງຮັບຂໍ້ມູນສາມາດກວດສອບເວີຊັນກ່ອນທີ່ຈະແຍກຂະບວນການເຮັດວຽກ (Branching)
3. ໃນກໍລະນີທີ່ມີການປ່ຽນແປງທີ່ສົ່ງຜົນກະທົບຕໍ່ລະບົບ ໃຫ້ສ້າງ Endpoint ໃໝ່ ຫຼື Schema ID ໃໝ່ ແລະ ກຳນົດໄລຍະເວລາໃນການຍ້າຍລະບົບ (Migration Period) ໂດຍໃຫ້ເວີຊັນເກົ່າເຮັດວຽກຄວບຄູ່ກັນໄປ

Q1. Structured Output ສາມາດໃຊ້ກັບທຸກໂມເດວໄດ້ໂດຍບໍ່ຕ້ອງມີການຟາຍຈູນ (Fine-tuning) ບໍ?

ບໍ່ແມ່ນທຸກໂມເດວຈະສາມາດນຳໃຊ້ໄດ້. ໃນກໍລະນີຂອງ OpenAI, Structured Outputs ທີ່ກຳນົດ json_schema ໃນ response_format ຈະໃຊ້ໄດ້ສະເພາະກັບໂມເດວທີ່ຮອງຮັບ ເຊັ່ນ: GPT-4o, GPT (ຕະກູນ GPT-4 Turbo) ແລະ gpt-3.5-turbo-1106 ຂຶ້ນໄປເທົ່ານັ້ນ. ເຖິງວ່າຈະບໍ່ຈຳເປັນຕ້ອງມີການຟາຍຈູນ, ແຕ່ເນື່ອງຈາກສະຖານະການຮອງຮັບແຕກຕ່າງກັນໄປຕາມເວີຊັນຂອງໂມເດວ, ຈຶ່ງແນະນຳໃຫ້ກວດສອບລາຍຊື່ໂມເດວທີ່ຮອງຮັບໃນເອກະສານທາງການກ່ອນນຳໃຊ້. ສຳລັບໂມເດວປະເພດ Open-source, ການສະໜອງຟັງຊັນທີ່ທຽບເທົ່າກັນນັ້ນຈະຂຶ້ນຢູ່ກັບແຕ່ລະໂມເດວ.

Q2. ຄວນແຍກການໃຊ້ງານ strict: true ແລະ strict: false ແນວໃດ?

ເມື່ອຕັ້ງຄ່າ strict: true, ໂມເດວຈະສ້າງຜົນລັດທີ່ປະຕິບັດຕາມສະກີມາ (Schema) ທີ່ກຳນົດໄວ້ຢ່າງເຂັ້ມງວດ. ສຳລັບການນຳໃຊ້ທີ່ບໍ່ອະນຸຍາດໃຫ້ເກີດຄວາມຜິດພາດໃນການແຍກຂໍ້ມູນ (Parsing failure) ເຊັ່ນ: ການປ້ອນຂໍ້ມູນອັດຕະໂນມັດເຂົ້າສູ່ລະບົບທຸລະກິດ, ການໃຊ້ strict: true ແມ່ນເໝາະສົມທີ່ສຸດ. ໃນທາງກົງກັນຂ້າມ, strict: false (ຄ່າເລີ່ມຕົ້ນ) ຈະມີຄວາມຍືດຫຍຸ່ນໃນການປະຕິບັດຕາມສະກີມາຫຼາຍກວ່າ, ເຊິ່ງເໝາະສົມກັບການສຳຫຼວດຄວາມເປັນໄປໄດ້ໃນຂັ້ນຕອນການເຮັດໂປຣໂຕໄທ (Prototype) ຫຼື ການທົດສອບ. ໃນສະພາບແວດລ້ອມການໃຊ້ງານຈິງ (Production), ໂດຍຫຼັກການແລ້ວຄວນເລືອກ strict: true ແລະ ຄວນກວດສອບການອອກແບບສະກີມາໃຫ້ລະອຽດກ່ອນນຳໄປໃຊ້ງານຈິງ.

Q3. ແນວຄວາມຄິດຂອງ Structured Output ສາມາດນຳໄປໃຊ້ກັບຟໍແມັດອື່ນທີ່ບໍ່ແມ່ນ JSON (ເຊັ່ນ: YAML, XML) ໄດ້ບໍ?

ຟັງຊັນ Structured Outputs ຂອງ OpenAI ຖືກອອກແບບໂດຍອີງໃສ່ JSON Schema ເປັນຫຼັກ, ສະນັ້ນຈຶ່ງບໍ່ມີກົນໄກທີ່ບັງຄັບໃຫ້ສົ່ງອອກຜົນລັດເປັນ YAML ຫຼື XML ໂດຍກົງ. ຢ່າງໃດກໍຕາມ, ສາມາດໃຊ້ວິທີການສະເໜີ Template ຂອງ YAML ຫຼື XML ໃຫ້ LLM ຜ່ານທາງ Prompt ແລະ ກວດສອບດ້ວຍ Parser ຫຼັງຈາກໄດ້ຮັບຜົນລັດແລ້ວ. ສຳລັບວິທີທີ່ປອດໄພກວ່າ, ການອອກແບບໂດຍການຮັບຜົນລັດທີ່ມີໂຄງສ້າງເປັນ JSON ກ່ອນ ແລ້ວຈຶ່ງສ້າງ ຂະບວນການ ຫຼື Pipeline ເພື່ອແປງເປັນ YAML ຫຼື XML ໃນຊັ້ນແອັບພລິເຄຊັນ (Application layer) ຈະມີຄວາມສະຖຽນຫຼາຍກວ່າ.

Q4. ເມື່ອມີການປ່ຽນແປງສະກີມາ, ຈະສາມາດຫຼຸດຜ່ອນຜົນກະທົບຕໍ່ລະບົບການເຊື່ອມຕໍ່ທີ່ມີຢູ່ແລ້ວໃຫ້ໜ້ອຍທີ່ສຸດໄດ້ແນວໃດ?

ການເພີ່ມ Field ໃໝ່ສາມາດຮັກສາຄວາມເຂົ້າກັນໄດ້ກັບລະບົບເກົ່າ (Backward compatibility) ໄດ້ງ່າຍ, ແຕ່ການລຶບ Field ຫຼື ການປ່ຽນແປງປະເພດຂໍ້ມູນ (Type) ອາດສົ່ງຜົນກະທົບທີ່ຮຸນແຮງໄດ້. ການນຳໃຊ້ $schema ເພື່ອກຳນົດເວີຊັນໃນສະກີມາ ແລະ ເພີ່ມໝາຍເລກເວີຊັນເມື່ອມີການປ່ຽນແປງແມ່ນວິທີການທີ່ມີປະສິດທິພາບ. ນອກຈາກນີ້, ການກຳນົດໄລຍະເວລາການປ່ຽນຜ່ານ (Transition period) ໂດຍໃຫ້ສະກີມາເກົ່າ ແລະ ໃໝ່ເຮັດວຽກຂະໜານກັນໄປ, ແລະ ຍົກເລີກສະກີມາເກົ່າຫຼັງຈາກຢືນຢັນໄດ້ວ່າລະບົບປາຍທາງ (Downstream system) ຮອງຮັບເວີຊັນໃໝ່ແລ້ວ, ເປັນວິທີທີ່ແນະນຳເພື່ອຮັກສາຄວາມສະຖຽນໃນການເຊື່ອມຕໍ່ລະບົບ.

Q5. ສາມາດໃຊ້ວິທີການຈັດຕັ້ງປະຕິບັດແບບດຽວກັນກັບ Azure OpenAI ໄດ້ບໍ?

Structured Outputs ຂອງ Azure OpenAI ຮອງຮັບ JSON Schema subset ແບບດຽວກັນກັບ OpenAI ແລະ ວິທີການກຳນົດ response_format ກໍຄືກັນໂດຍພື້ນຖານ. ເຖິງແມ່ນວ່າ Endpoint ແລະ ວິທີການຢືນຢັນຕົວຕົນຈະເປັນສະເພາະຂອງ Azure, ແຕ່ການອອກແບບສະກີມາ ແລະ Logic ການກວດສອບຄວາມຖືກຕ້ອງ (Validation logic) ສາມາດນຳມາໃຊ້ງານໄດ້ເລີຍ. ຢ່າງໃດກໍຕາມ, ເນື່ອງຈາກສະຖານະການ Deploy ຂອງໂມເດວທີ່ຮອງຮັບ ແລະ ຊ່ວງເວລາການເປີດໃຫ້ບໍລິການຟັງຊັນຕ່າງໆໃນແຕ່ລະ Region ອາດແຕກຕ່າງກັນ, ຈຶ່ງແນະນຳໃຫ້ກວດສອບສະຖານະການຮອງຮັບຫຼ້າສຸດໃນເອກະສານຂອງ Azure.

ຫຼາຍຄົນມັກຄິດວ່າ "ຄວນຈະໃຊ້ໄດ້ກັບທຸກໂມເດວ" ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ການກວດສອບໂມເດວທີ່ຮອງຮັບແມ່ນສິ່ງທີ່ຕ້ອງເຮັດກ່ອນ. Structured Outputs (ການບັງຄັບຜົນລັພເປັນ JSON Schema) ແມ່ນຂຶ້ນກັບສະຖາປັດຕະຍະກຳ ແລະ ການຝຶກຝົນຂອງໂມເດວ ດັ່ງນັ້ນຈຶ່ງບໍ່ສາມາດນຳໄປໃຊ້ກັບໂມເດວໃດກໍໄດ້ຕາມໃຈມັກ.

ການຈັດລະບຽບສະຖານະການຮອງຮັບ

• ຮູບແບບ response_format: { type: "json_schema" } ຂອງ OpenAI ຖືກລະບຸວ່າສາມາດໃຊ້ໄດ້ກັບໂມເດວ GPT-4o, GPT-4 Turbo ແລະ gpt-3.5-turbo-1106 ຂຶ້ນໄປ
• ຮູບແບບ "json_object" ແບບເກົ່າໄດ້ຖືກຍົກເລີກການແນະນຳໃຫ້ໃຊ້ ແລະ ແນະນຳໃຫ້ຍ້າຍໄປໃຊ້ຮູບແບບ "json_schema" ແທນ
• Azure OpenAI ກໍຮອງຮັບ JSON Schema ຊຸດຍ່ອຍດຽວກັນ ແຕ່ເວີຊັນຂອງໂມເດວທີ່ສາມາດໃຊ້ງານໄດ້ນັ້ນຈະຂຶ້ນກັບການຕັ້ງຄ່າການ Deploy ທາງຝັ່ງ Azure

ຄວາມຈຳເປັນໃນການເຮັດ Fine-tuning

ໂດຍຫຼັກການແລ້ວ ບໍ່ຈຳເປັນຕ້ອງເຮັດ Fine-tuning. Structured Outputs ສາມາດເຮັດວຽກໄດ້ພຽງແຕ່ການອອກແບບ Prompt ແລະ ການຕັ້ງຄ່າພາຣາມິເຕີ response_format ເທົ່ານັ້ນ. ຢ່າງໃດກໍຕາມ, ຈຳເປັນຕ້ອງລະວັງຈຸດດັ່ງຕໍ່ໄປນີ້:

ສະຫຼຸບກໍຄື, Structured Outputs ຂອງ OpenAI ແມ່ນມີມາດຕະຖານ ຫຼື Specification ທີ່ອີງໃສ່ JSON ເປັນຫຼັກ, ສະນັ້ນຈຶ່ງບໍ່ສາມາດບັງຄັບໃຫ້ໃຊ້ YAML ຫຼື XML ໂດຍກົງໃນສະກີມາ (Schema) ໄດ້.

ຢ່າງໃດກໍຕາມ, ວິທີການແກ້ໄຂທີ່ເປັນໄປໄດ້ຈະແຕກຕ່າງກັນໄປຕາມຈຸດປະສົງການນຳໃຊ້:

• ກໍລະນີທີ່ຕ້ອງການ YAML: ວິທີທີ່ໝັ້ນຄົງທີ່ສຸດແມ່ນໃຫ້ LLM ສົ່ງຂໍ້ມູນອອກມາເປັນ JSON ກ່ອນ, ຈາກນັ້ນຈຶ່ງໃຊ້ໄລບຣາຣີ (Library) ເຊັ່ນ js-yaml ໃນຝັ່ງແອັບພລິເຄຊັນເພື່ອແປງເປັນ YAML. ການກວດສອບສະກີມາ (Schema validation) ຈະສຳເລັດສົມບູນຕັ້ງແຕ່ຂັ້ນຕອນ JSON, ເຮັດໃຫ້ສາມາດຮັກສາຄວາມປອດໄພຂອງປະເພດຂໍ້ມູນ (Type safety) ໄວ້ໄດ້.
• ກໍລະນີທີ່ຕ້ອງການ XML: ໃນລັກສະນະດຽວກັນ, ວິທີທີ່ເປັນໄປໄດ້ແມ່ນການເພີ່ມຂະບວນການ ຫຼື Pipeline ການແປງ JSON → XML (ເຊັ່ນ: fast-xml-parser) ເຂົ້າໄປ. ແຕ່ຖ້າມີອົງປະກອບທີ່ JSON ບໍ່ສາມາດສະແດງຜົນໄດ້ດີ ເຊັ່ນ: ໂຄງສ້າງ Attribute ຂອງ XML, ຈຳເປັນຕ້ອງມີການກຳນົດ Type ທີ່ຄຳນຶງເຖິງໂຄງສ້າງຫຼັງການແປງຕັ້ງແຕ່ຂັ້ນຕອນການອອກແບບສະກີມາ.

ການສັ່ງໃນ Prompt ວ່າ "ກະລຸນາສົ່ງຜົນອອກມາໃນຮູບແບບ YAML" ແມ່ນສາມາດເຮັດໄດ້ທາງເຕັກນິກ, ແຕ່ໃນກໍລະນີນີ້ ການບັງຄັບດ້ວຍ JSON Schema ຈະບໍ່ເຮັດວຽກ, ເຮັດໃຫ້ຄວາມສະຖຽນຂອງຜົນລັອກຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ. ຈຶ່ງບໍ່ແນະນຳໃຫ້ໃຊ້ໃນການເຊື່ອມຕໍ່ລະບົບທຸລະກິດ.

ຄວນຍຶດຖືຫຼັກການຕັດສິນໃຈທີ່ວ່າ: ຖ້າລະບົບປາຍທາງຕ້ອງການ YAML ຫຼື XML, ໃຫ້ຮັບຂໍ້ມູນເປັນ JSON ແລ້ວຈຶ່ງແປງ, ແລະຖ້າໃຫ້ຄວາມສຳຄັນກັບຄວາມໜ້າເຊື່ອຖືຂອງຜົນລັອກຈາກ LLM ເປັນອັນດັບໜຶ່ງ, ຄວນຮັກສາການບັງຄັບຜົນລັອກດ້ວຍ JSON Schema ໄວ້.