Structured Output ແມ່ນຫຍັງ? ຄູ່ມືການອອກແບບ ແລະ ການຈັດຕັ້ງປະຕິບັດການຕອບໂຕ້ແບບ Type-safe ຂອງ LLM

Structured Output (ຜົນລວມທີ່ມີໂຄງສ້າງ) ແມ່ນກົນໄກທີ່ LLM (Large Language Model) ສ້າງຄຳຕອບໂດຍປະຕິບັດຕາມຮູບແບບທີ່ກຳນົດໄວ້ລ່ວງໜ້າ ເຊັ່ນ: JSON schema. ເມື່ອປຽບທຽບກັບການຕອບຄຳຖາມແບບເສລີດ້ວຍພາສາທຳມະຊາດ, ການບັງຄັບຮູບແບບຜົນລວມ ແລະ ປະເພດຂອງຄ່າຂໍ້ມູນຈະຊ່ວຍໃຫ້ສາມາດສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ລະບົບທີ່ກ່ຽວຂ້ອງໄດ້ຢ່າງປອດໄພ. ບົດຄວາມນີ້ຈະອະທິບາຍຢ່າງເປັນລະບົບສຳລັບນັກພັດທະນາ ແລະ ສະຖາປະນິກທີ່ກຳລັງສ້າງ AI Agent ຫຼື ຂະບວນການ ຫຼື Pipeline ອັດຕະໂນມັດ ໂດຍເລີ່ມຕັ້ງແຕ່ເຫດຜົນທີ່ຈຳເປັນຕ້ອງມີ Structured Output, ການອອກແບບ JSON schema, ວິທີການບັງຄັບໃຊ້ກັບ LLM, ວິທີຫຼີກລ່ຽງຂໍ້ຜິດພາດທີ່ພົບເລື້ອຍ, ໄປຈົນເຖິງຮູບແບບການນຳໃຊ້ຕົວຈິງ.

ສະຫຼຸບ: ການສົ່ງຜົນຜະລິດຂອງ LLM ໂດຍກົງເຂົ້າສູ່ລະບົບທຸລະກິດ ອາດເຮັດໃຫ້ເກີດຄວາມຜິດພາດໃນການແຍກຂໍ້ມູນ (Parsing) ຫຼື ເກີດບັນຫາຈາກຄວາມບໍ່ຄົງທີ່ຂອງຮູບແບບຂໍ້ມູນ. ການສົ່ງອອກຂໍ້ມູນແບບມີໂຄງສ້າງ (Structured Output) ແມ່ນວິທີການຫຼຸດຜ່ອນຄວາມສ່ຽງດັ່ງກ່າວຕັ້ງແຕ່ຂັ້ນຕອນການອອກແບບ. ບົດຄວາມນີ້ຈະສະຫຼຸບເຖິງຄວາມຈຳເປັນດັ່ງກ່າວ ໂດຍພິຈາລະນາຈາກບັນຫາຂອງຂໍ້ຄວາມແບບອິດສະຫຼະ, ຄວາມສຳພັນກັບບັນຫາ Hallucination ແລະ ຄວາມສຳຄັນໃນການເຮັດວຽກຮ່ວມກັນຂອງ Agent.

ເມື່ອສັ່ງໃຫ້ LLM "ສະກັດຊື່ລູກຄ້າ ແລະ ວັນທີທີ່ຕ້ອງການຈາກການສອບຖາມນີ້", ບາງຄັ້ງມັນຈະຕອບກັບມາວ່າ "ຊື່ລູກຄ້າ: Yamada Taro", ແຕ່ບາງຄັ້ງກໍຕອບວ່າ "ຊື່ຂອງລູກຄ້າແມ່ນທ່ານ Yamada Taro". ເຖິງວ່າສຳລັບມະນຸດຈະມີຄວາມໝາຍດຽວກັນ ແຕ່ສຳລັບໂປຣແກຣມທີ່ນຳຂໍ້ມູນໄປໃຊ້ຕໍ່ນັ້ນຖືເປັນຄົນລະຢ່າງກັນ.

ການນຳເອົາຂໍ້ຄວາມໃນຮູບແບບອິດສະຫຼະ (Free-form text) ມາຈັດການໃນລະບົບ ມັກຈະພົບກັບອຸປະສັກດັ່ງຕໍ່ໄປນີ້:

• ຄຳເວົ້າ ຫຼື ລຳດັບຂອງຜົນລັອກທີ່ປ່ຽນແປງໄປໃນທຸກຄັ້ງ ເຮັດໃຫ້ການໃຊ້ Regular Expression ຫຼື ການແບ່ງຂໍ້ຄວາມ (String split) ບໍ່ມີຄວາມສະຖຽນ
• ມີການແຊກຂໍ້ຄວາມເກີນຄວາມຈຳເປັນ (ເຊັ່ນ: "ຮັບຊາບ", "ນີ້ຄືຜົນລັອກ") ເຂົ້າມາ
• ຮູບແບບຂອງຕົວເລກ ຫຼື ວັນທີມີຄວາມຜັນຜວນ ເຮັດໃຫ້ການປ່ຽນແປງປະເພດຂໍ້ມູນ (Type conversion) ລົ້ມເຫຼວ

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

ຮາລູຊິເນຊັນ (Hallucination) ສາມາດແບ່ງອອກໄດ້ເປັນ 2 ປະເພດໃຫຍ່ໆ ຄື: "ຮາລູຊິເນຊັນດ້ານເນື້ອຫາ (ຄຳຕອບທີ່ບໍ່ກົງກັບຄວາມເປັນຈິງ)" ແລະ "ຮາລູຊິເນຊັນດ້ານຮູບແບບ (ການຕອບກັບດ້ວຍໂຄງສ້າງທີ່ບໍ່ຄາດຄິດ)". ການສົ່ງອອກຂໍ້ມູນແບບມີໂຄງສ້າງ (Structured output) ສາມາດຄວບຄຸມປະເພດຫຼັງໄດ້ໂດຍກົງ.

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

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

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

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

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

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

ວິທີການບັນລຸຜົນຜະລິດທີ່ມີໂຄງສ້າງ (Structured Output) ຈະແຕກຕ່າງກັນໄປຕາມ LLM ຫຼື API mode ທີ່ໃຊ້. ກ່ອນການປະຕິບັດງານ, ກະລຸນາກວດສອບວ່າໂມເດວທີ່ວາງແຜນຈະໃຊ້ຮອງຮັບວິທີການໃດ.

ວິທີການທີ່ເປັນຕົວແທນມີດັ່ງນີ້:

• ໂໝດທີ່ສົ່ງ Schema ໂດຍກົງ ແລະ ຮັບປະກັນປະເພດຂອງມັນ (ການປະຕິບັດຕາມ Schema ຢ່າງເຂັ້ມງວດ)
• ວິທີການຮັບຂໍ້ມູນທີ່ມີໂຄງສ້າງເປັນ Argument ຂອງການກຳນົດຟັງຊັນ (Function Calling / Tool Use)
• ໂໝດ JSON ແບບຜ່ອນປົນທີ່ລະບຸພຽງແຕ່ "ສົ່ງຄືນເປັນ JSON"

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

ຄຸນນະພາບຂອງຜົນລັອກທີ່ເປັນໂຄງສ້າງ (Structured output) ແມ່ນຂຶ້ນກັບຄຸນນະພາບຂອງ JSON Schema ທີ່ສົ່ງໃຫ້ເປັນຫຼັກ. ຢ່າງໜ້ອຍທີ່ສຸດ, ການອອກແບບຈະດຳເນີນໄປຢ່າງສະດວກຫາກສາມາດຈັດການກັບອົງປະກອບຕໍ່ໄປນີ້ໄດ້:

• type (ປະເພດຂອງຄ່າ ເຊັ່ນ: string / number / boolean / object / array)
• properties (ການກຳນົດແຕ່ລະຟີລໃນ Object)
• required (ການລະບຸຟີລທີ່ຈຳເປັນ)
• enum (ການຈຳກັດຄ່າທີ່ສາມາດເປັນໄປໄດ້)
• description (ການເສີມຄວາມໝາຍຂອງແຕ່ລະຟີລດ້ວຍພາສາທຳມະຊາດ)

ໂດຍສະເພາະ description ມັກຈະຖືກເບິ່ງຂ້າມ, ແຕ່ LLM ຈະໃຊ້ຂໍ້ຄວາມອະທິບາຍນີ້ເປັນເບາະແສໃນການຕີຄວາມໝາຍຂອງຟີລ. ການຂຽນວ່າ "ວັນທີ" ຢ່າງດຽວ ຈະບໍ່ດີເທົ່າກັບການຂຽນວ່າ "ວັນທີທີ່ຕ້ອງການຈອງ. ຮູບແບບ YYYY-MM-DD" ເຊິ່ງຈະຊ່ວຍໃຫ້ໄດ້ຜົນລັອກທີ່ໃກ້ຄຽງກັບຄວາມຕ້ອງການຫຼາຍກວ່າ.

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

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

ເກນໃນການຕັດສິນໃຈມີດັ່ງນີ້:

• ຖ້າເປັນການສະກັດຂໍ້ມູນ ຫຼື ການຈັດໝວດໝູ່ທົ່ວໄປ, ສ່ວນຫຼາຍສາມາດຈັດການໄດ້ດ້ວຍ Schema ແລະ Prompt.
• ຖ້າກ່ຽວຂ້ອງກັບຄຳສັບສະເພາະທາງທຸລະກິດ ຫຼື ການຕັດສິນໃຈທີ່ຊັບຊ້ອນເກີນກວ່າຈະອະທິບາຍໄດ້ດ້ວຍ Prompt, ການເຮັດ Fine-tuning ຈຶ່ງຈະກາຍເປັນທາງເລືອກໜຶ່ງ.

ເຖິງວ່າ Fine-tuning ຈະມີຊ່ອງວ່າງໃນການເພີ່ມຄວາມແມ່ນຍຳ, ແຕ່ກໍມີຕົ້ນທຶນໃນການດຳເນີນງານທັງດ້ານການກຽມຂໍ້ມູນ ແລະ ການຝຶກຝົນໃໝ່ (Re-training). ການພິຈາລະນາຫຼັງຈາກທີ່ໄດ້ຢືນຢັນແລ້ວວ່າ Prompt Engineering ບໍ່ສາມາດບັນລຸຄວາມແມ່ນຍຳຕາມເປົ້າໝາຍໄດ້ນັ້ນ ຈະເຮັດໃຫ້ສາມາດປະເມີນຄວາມຄຸ້ມຄ່າຂອງການລົງທຶນ (ROI) ໄດ້ງ່າຍຂຶ້ນ. ຂ້ອຍຂໍແນະນຳໃຫ້ເລີ່ມຈາກວິທີທີ່ງ່າຍກ່ອນ ແລະ ປ່ຽນໄປໃຊ້ວິທີທີ່ຊັບຊ້ອນຂຶ້ນເມື່ອເຫັນຂີດຈຳກັດຂອງວິທີເດີມແລ້ວ.

ສະຫຼຸບ: ສະກີມາ (Schema) ທີ່ດີສາມາດສ້າງໄດ້ດ້ວຍ 3 ຂັ້ນຕອນຄື: "ກຳນົດລາຍການທີ່ຈຳເປັນຈາກ Use case, ລະບຸປະເພດ (Type) ແລະ ຂໍ້ຈຳກັດໃຫ້ຊັດເຈນ, ແລະ ຮັກສາໂຄງສ້າງໃຫ້ຮາບພຽງທີ່ສຸດເທົ່າທີ່ຈະເປັນໄປໄດ້". ສະກີມາທີ່ຊັບຊ້ອນເກີນໄປຈະເຮັດໃຫ້ LLM ບໍ່ສາມາດປະຕິບັດຕາມໄດ້ ແລະ ສົ່ງຜົນກົງກັນຂ້າມ. ຕໍ່ໄປເຮົາຈະມາເບິ່ງຂັ້ນຕອນການອອກແບບຢ່າງລະອຽດກັນ.

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

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

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

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

ມີ 3 ຈຸດສຳຄັນດັ່ງນີ້:

• ກຳນົດປະເພດໃຫ້ລະອຽດ: ຖ້າເປັນ "ຕົວເລກ" ໃຫ້ລະບຸວ່າເປັນຈຳນວນເຕັມ ຫຼື ຈຳນວນທົດສະນິຍົມ ແລະ ມີຂອບເຂດເທົ່າໃດ.
• ແຍກລະຫວ່າງສິ່ງທີ່ຈຳເປັນ ແລະ ທາງເລືອກ: ລາຍການທີ່ຂະບວນການ ຫຼື Pipeline ຕໍ່ໄປຕ້ອງໃຊ້ຢ່າງແນ່ນອນ ໃຫ້ໃສ່ໄວ້ໃນ required ເພື່ອປ້ອງກັນຂໍ້ມູນຕົກຫຼົ່ນ.
• ກຳນົດຄ່າທີ່ເປັນໄປໄດ້ດ້ວຍ enum: ສຳລັບລາຍການທີ່ມີທາງເລືອກແນ່ນອນ ເຊັ່ນ: ໝວດໝູ່ ຫຼື ສະຖານະ ໃຫ້ໃຊ້ການກຳນົດຄ່າແບບລາຍການ (Enumeration).

ໂດຍສະເພາະ enum ແມ່ນມີປະສິດທິພາບສູງ, ຖ້າຈຳກັດຄ່າໄວ້ພຽງ 3 ຄ່າ ຄື: "ດ່ວນ", "ປົກກະຕິ", "ຕ່ຳ", ມັນຈະບໍ່ເປີດໂອກາດໃຫ້ LLM ສ້າງຄຳສັບກາງໆຂຶ້ນມາເອງ ເຊັ່ນ: "ດ່ວນເລັກນ້ອຍ". ການແຍກແຍະໃຫ້ອອກວ່າສ່ວນໃດຄວນເປັນການປ້ອນຂໍ້ມູນແບບອິດສະຫຼະ ແລະ ສ່ວນໃດຄວນຈຳກັດດ້ວຍທາງເລືອກ ແມ່ນມີຜົນໂດຍກົງຕໍ່ຄວາມແຂງແກ່ນຂອງຂະບວນການ ຫຼື Pipeline ທີ່ຕາມມາ.

ໂຄງສ້າງ Schema ຍິ່ງມີການຊ້ອນກັນເລິກເທົ່າໃດ LLM ກໍຍິ່ງປະຕິບັດຕາມໄດ້ຍາກ ແລະ ຍັງເຮັດໃຫ້ການໃຊ້ງານ Token ເພີ່ມຂຶ້ນ. ຂໍແນະນຳໃຫ້ແຜ່ຂະຫຍາຍໂຄງສ້າງທີ່ຊ້ອນກັນເກີນ 3 ຊັ້ນ ຫຼື ໂຄງສ້າງແບບ Recursive ໃຫ້ເປັນແບບແປ (Flat) ຫຼາຍທີ່ສຸດເທົ່າທີ່ຈະເຮັດໄດ້.

ໃນຕອນທຳອິດ ທ່ານອາດຈະຢາກຄັດລອກໂຄງສ້າງຕາມຄວາມເປັນຈິງ, ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ການໃຊ້ການປະສົມປະສານລະຫວ່າງ Array ແບບ Flat ແລະ Key ມັກຈະເຮັດໃຫ້ຜົນລັອກມີຄວາມສະຖຽນຫຼາຍກວ່າ. ຕົວຢ່າງເຊັ່ນ: ແທນທີ່ຈະເຮັດການຊ້ອນກັນເລິກໆຂອງ "ພະແນກ, ທີມ, ສະມາຊິກ", ການໃສ່ຊື່ພະແນກ ແລະ ຊື່ທີມລົງໃນ Array ຂອງສະມາຊິກຈະເຮັດໃຫ້ LLM ຈັດການໄດ້ງ່າຍກວ່າ.

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

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

ວິທີທີ່ແນ່ນອນທີ່ສຸດແມ່ນການໃຊ້ໂໝດ Function Calling (Tool Use) ຂອງ API ເພື່ອຮັບຂໍ້ມູນທີ່ມີໂຄງສ້າງເປັນອາກິວເມັນ (Argument) ຂອງຟັງຊັນ. ໃນໂໝດນີ້, ຜົນລວມຂອງ LLM ຈະຖືກຊີ້ແນະໂດຍຝັ່ງ API ໃຫ້ເປັນໄປຕາມສະກີມາ (Schema) ທີ່ກຳນົດໄວ້.

ຂັ້ນຕອນການນຳໃຊ້ແມ່ນງ່າຍດາຍ:

• ກຳນົດໂຄງສ້າງຂໍ້ມູນທີ່ຕ້ອງການຮັບເປັນສະກີມາຂອງອາກິວເມັນຟັງຊັນ
• ໃຫ້ LLM ຕອບສະໜອງໃນຮູບແບບຂອງການ "ຮຽກໃຊ້" ຟັງຊັນນັ້ນ
• ຮັບເອົາອາກິວເມັນທີ່ສົ່ງກັບມາເປັນຂໍ້ມູນທີ່ມີໂຄງສ້າງ

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

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

ສິ່ງທີ່ມີປະສິດທິຜົນຄືການສະແດງຕົວຢ່າງຄູ່ຂອງ Input ແລະ Output ທີ່ຄາດຫວັງໄວ້ປະມານ 1-2 ຕົວຢ່າງ (Few-shot). ການສະແດງຕົວຢ່າງຜົນລັອກຕົວຈິງໃຫ້ເຫັນ 1 ຕົວຢ່າງ ຈະຊ່ວຍໃຫ້ເຂົ້າໃຈເຖິງລະດັບຄວາມລະອຽດຂອງຟິວ (Field) ແລະ ໂທນສຽງໄດ້ດີກວ່າການອະທິບາຍດ້ວຍຂໍ້ຄວາມວ່າ "ໃຫ້ຂຽນຢ່າງສຸພາບ".

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

ເຖິງແມ່ນວ່າຈະມີການກຳນົດໂໝດ ແລະ ພຣອມ (Prompt) ໄວ້ແລ້ວ ແຕ່ກໍບໍ່ມີການຮັບປະກັນວ່າຜົນລວມຈະກົງກັບສະກີມາ (Schema) ຢ່າງສົມບູນ. ດັ່ງນັ້ນ, ທ່ານຕ້ອງກຽມກົນໄກໃນການກວດສອບຂໍ້ມູນທີ່ໄດ້ຮັບດ້ວຍສະກີມາສະເໝີ ແລະ ຫາກພົບວ່າບໍ່ຖືກຕ້ອງ ໃຫ້ດຳເນີນການລອງໃໝ່ (Retry).

ວົງຈອນການເຮັດວຽກພື້ນຖານມີດັ່ງນີ້:

• ກວດສອບຄວາມຖືກຕ້ອງ (Validate) ຂອງຜົນລວມດ້ວຍສະກີມາ
• ຖ້າລົ້ມເຫຼວ ໃຫ້ຮ້ອງຂໍການສ້າງຂໍ້ມູນໃໝ່ອີກຄັ້ງໂດຍແນບເນື້ອຫາຂອງຂໍ້ຜິດພາດໄປນຳ
• ຖ້າບໍ່ສຳເລັດພາຍໃນຈຳນວນຄັ້ງທີ່ກຳນົດໄວ້ ໃຫ້ປ່ຽນໄປໃຊ້ຂະບວນການສຳຮອງ (Fallback)

ໃນເວລາລອງໃໝ່, ການສົ່ງຂໍ້ມູນໄປໃນພຣອມວ່າ "ຟີລ (Field) ໃດທີ່ບໍ່ຖືກຕ້ອງ ແລະ ຍ້ອນຫຍັງ" ຈະຊ່ວຍໃຫ້ການແກ້ໄຂໃນການລອງຄັ້ງຕໍ່ໄປງ່າຍຂຶ້ນ. ເພື່ອຫຼີກລ່ຽງວົງຈອນບໍ່ຮູ້ຈົບ (Infinite loop), ຕ້ອງກຳນົດຈຳນວນຄັ້ງສູງສຸດໃນການລອງ ແລະ ຕັ້ງຄ່າເວລາໝົດອາຍຸ (Timeout) ໄວ້ສະເໝີ. ການຈັດຕັ້ງປະຕິບັດການກວດສອບ ແລະ ການລອງໃໝ່ໃຫ້ເປັນໜ້າທີ່ຂອງຝັ່ງແອັບພລິເຄຊັນ (App) ຖືເປັນປ້ອມປ້ອງກັນສຸດທ້າຍທີ່ຈະເຮັດໃຫ້ການສົ່ງອອກຂໍ້ມູນທີ່ມີໂຄງສ້າງ (Structured output) ມີຄວາມສະຖຽນໃນສະພາບແວດລ້ອມການໃຊ້ງານຈິງ (Production).

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

ເມື່ອການສົ່ງອອກຂໍ້ມູນແບບມີໂຄງສ້າງ (Structured output) ບໍ່ປະສົບຜົນສຳເລັດ, ສາເຫດສ່ວນໃຫຍ່ມັກຈະມາຈາກຝັ່ງຂອງ Schema ບໍ່ແມ່ນຕົວ Model. ຄວາມຊັບຊ້ອນຕ່າງໆ ເຊັ່ນ: ການມີ Field ຫຼາຍເກີນໄປ, ການມີ Nest ທີ່ເລິກເກີນໄປ, ຫຼື ຂໍ້ຈຳກັດທີ່ຂັດແຍ່ງກັນ ເຮັດໃຫ້ Model ປະຕິບັດຕາມໄດ້ຍາກ.

ສັນຍານທີ່ພົບເຫັນເລື້ອຍໆ ມີດັ່ງນີ້:

• ຂໍ້ມູນບາງຢ່າງທີ່ຈຳເປັນຂາດຫາຍໄປ
• ຄ່າໃນຊັ້ນຂໍ້ມູນທີ່ເລິກເກີນໄປເກີດຄວາມຜິດພາດ
• ຂໍ້ມູນທີ່ສົ່ງອອກມາຖືກຕັດຂາດກາງຄັນ

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

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

ສິ່ງທີ່ອັນຕະລາຍຄືການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຂະບວນການຖັດໄປໂດຍບໍ່ມີການກວດສອບຄ່າທີ່ສົ່ງອອກມາ. ຕົວຢ່າງເຊັ່ນ: ຖ້າຫາກນຳເອົາຂໍ້ຄວາມທີ່ຢູ່ໃນຜົນລວມນັ້ນໄປຝັງໄວ້ໃນ SQL, ຄຳສັ່ງ Shell, ຫຼື HTML ໂດຍກົງ, ມັນອາດຈະກາຍເປັນຊ່ອງໂຫວ່ຂອງການໂຈມຕີແບບ Injection ໄດ້. ເຊິ່ງສິ່ງນີ້ຖືກເອີ້ນວ່າ "ການຈັດການຜົນລວມທີ່ບໍ່ເໝາະສົມ (Improper Output Handling)" ແລະ ເປັນທີ່ຮູ້ຈັກກັນດີວ່າເປັນຄວາມສ່ຽງຫຼັກຂອງແອັບພລິເຄຊັນ LLM.

ວິທີການປ້ອງກັນຄືການປະຕິບັດຕໍ່ຜົນລວມດັ່ງກ່າວດ້ວຍທັດສະນະຄະຕິແບບດຽວກັນກັບການຈັດການຂໍ້ມູນຈາກພາຍນອກ:

• ກວດສອບປະເພດຂໍ້ມູນ (Type) ແລະ ຂອບເຂດຂອງຄ່າດ້ວຍ Schema.
• ເມື່ອສົ່ງຂໍ້ມູນໄປຍັງຖານຂໍ້ມູນ ຫຼື ຄຳສັ່ງຕ່າງໆ ຕ້ອງເຮັດການ Escape ຫຼື Parameterize ສະເໝີ.
• ຖ້າພົບຄ່າທີ່ບໍ່ໄດ້ຄາດຄິດໄວ້ ໃຫ້ໃຊ້ລະບົບ Fallback ເພື່ອກັ່ນຕອງອອກ.

"ການມີໂຄງສ້າງ = ຄວາມປອດໄພ" ແມ່ນບໍ່ເປັນຄວາມຈິງ. ການກວດສອບຮູບແບບ ແລະ ການເຮັດໃຫ້ເນື້ອໃນປອດໄພ (Sanitization) ເປັນມາດຕະການທີ່ແຍກອອກຈາກກັນ, ດັ່ງນັ້ນທ່ານຄວນດຳເນີນການທັງສອງຢ່າງ.

ເມື່ອສະກີມາ (Schema) ຫຼື ຂໍ້ມູນນຳເຂົ້າ (Input data) ມີຂະໜາດໃຫຍ່, ມັນອາດຈະເຮັດໃຫ້ຮອດຂີດຈຳກັດຂອງ Context Window ແລະ ເຮັດໃຫ້ຜົນລວມທີ່ອອກມາຖືກຕັດຂາດ. ອາການທີ່ພົບເລື້ອຍຄືສ່ວນທ້າຍຂອງ JSON ທີ່ຍາວເກີນໄປຖືກຕັດອອກ ເຮັດໃຫ້ການ Parse ລົ້ມເຫຼວ.

ໃນຕອນທຳອິດ ມັນອາດຈະເບິ່ງຄືວ່າເປັນ "ຄວາມຜິດປົກກະຕິຂອງ Model", ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ມັກຈະມີສາເຫດມາຈາກການຂາດແຄນ Token. ກະລຸນາກວດສອບຈຸດຕໍ່ໄປນີ້:

• ຄຳນິຍາມຂອງສະກີມາ ຫຼື ຕົວຢ່າງ Few-shot ຍາວເກີນໄປຫຼືບໍ່?
• ໄດ້ສົ່ງຂໍ້ຄວາມນຳເຂົ້າໄປທັງໝົດເລີຍຫຼືບໍ່? (ສາມາດຈຳກັດໃຫ້ເຫຼືອພຽງສ່ວນທີ່ຈຳເປັນໄດ້ຫຼືບໍ່?)
• ຈຳນວນ Token ສູງສຸດຂອງຜົນລວມ ພຽງພໍກັບຄວາມຍາວຂອງ JSON ທີ່ຄາດໄວ້ຫຼືບໍ່?

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

ສະຫຼຸບ: ການສົ່ງອອກຂໍ້ມູນແບບມີໂຄງສ້າງ (Structured Output) ບໍ່ໄດ້ຈຳກັດຢູ່ພຽງແຕ່ການສະກັດຂໍ້ມູນເທົ່ານັ້ນ, ແຕ່ຍັງເປັນພື້ນຖານຂອງການອອກແບບຂັ້ນສູງ ເຊັ່ນ: ການຈັດຮູບແບບຄຳຕອບຂອງ RAG ແລະ ການເຊື່ອມຕໍ່ກັນຢ່າງປອດໄພຂອງລະບົບ Multi-agent. ການກຳນົດຮູບແບບຜົນລວມ (Type) ໃຫ້ຄົງທີ່ ຈະຊ່ວຍຮອງຮັບຄວາມໜ້າເຊື່ອຖືຂອງຂະບວນການ ຫຼື Pipeline ທີ່ມີຄວາມຊັບຊ້ອນ. ຕໍ່ໄປນີ້ຈະຂໍແນະນຳ 2 ຕົວຢ່າງການນຳໃຊ້ທີ່ສຳຄັນ.

ໃນ RAG (Retrieval-Augmented Generation), LLM ຈະສ້າງຄຳຕອບໂດຍອີງໃສ່ເອກະສານທີ່ຄົ້ນຫາໄດ້. ຖ້າປ່ຽນຄຳຕອບນີ້ຈາກຂໍ້ຄວາມຮູບແບບອິດສະຫຼະມາເປັນການສົ່ງອອກແບບມີໂຄງສ້າງ (Structured Output), ຈະເຮັດໃຫ້ການສະແດງຜົນ ຫຼື ການກວດສອບໃນຂັ້ນຕອນຕໍ່ໄປງ່າຍຂຶ້ນຫຼາຍ.

ຕົວຢ່າງເຊັ່ນ: ນອກຈາກເນື້ອໃນຄຳຕອບແລ້ວ, ສາມາດອອກແບບໃຫ້ສົ່ງຄ່າລາຍການຕໍ່ໄປນີ້ແບບມີໂຄງສ້າງໄດ້:

• ID ຂອງເອກະສານທີ່ອ້າງອີງເປັນຫຼັກຖານໃນການຕອບ
• ລະດັບຄວາມໝັ້ນໃຈຂອງຄຳຕອບ ຫຼື ທຸງ (Flag) ທີ່ບອກວ່າຂໍ້ມູນບໍ່ພຽງພໍ

ການເຮັດໃຫ້ຫຼັກຖານມີໂຄງສ້າງຈະຊ່ວຍໃຫ້ການຄວບຄຸມຕ່າງໆງ່າຍຂຶ້ນ ເຊັ່ນ: ການສະແດງແຫຼ່ງທີ່ມາໃນ UI ຫຼື ການສົ່ງຄຳຕອບທີ່ມີຄວາມໝັ້ນໃຈຕໍ່າໄປໃຫ້ຄົນກວດສອບ (Human Review).

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

ໃນລະບົບທີ່ຫຼາຍ Agent ເຮັດວຽກຮ່ວມກັນ, ຖ້າຮູບແບບຂອງຂໍ້ຄວາມທີ່ສົ່ງຫາກັນລະຫວ່າງ Agent ເກີດຄວາມຜິດພາດ ຈະເຮັດໃຫ້ລະບົບທັງໝົດບໍ່ມີສະຖຽນລະພາບ. ໃນຈຸດນີ້, ການໃຊ້ Structured Output ເປັນ "ສັນຍາລະຫວ່າງ Agent" ຈະຊ່ວຍໃຫ້ການສົ່ງຂໍ້ມູນມີຄວາມປອດໄພທາງດ້ານ Type (Type-safe).

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການອອກແບບມີດັ່ງນີ້:

• ກຳນົດ Schema ຂອງການນຳເຂົ້າ ແລະ ສົ່ງອອກຂໍ້ມູນຂອງແຕ່ລະ Agent ໄວ້ລ່ວງໜ້າ
• ຂໍ້ຄວາມທີ່ໄດ້ຮັບມາ ຈະຕ້ອງຖືກກວດສອບດ້ວຍ Schema ກ່ອນດຳເນີນການສະເໝີ
• ຖ້າພົບການລະເມີດ Schema ໃຫ້ກວດພົບໃນທັນທີ ເພື່ອດຳເນີນການສ້າງຂໍ້ມູນໃໝ່ ຫຼື ຈັດການກັບຂໍ້ຜິດພາດນັ້ນ

ການເຮັດແບບນີ້ຈະຊ່ວຍຮັບປະກັນໂດຍອັດຕະໂນມັດວ່າ ຜົນລັພທີ່ໄດ້ຈາກ Agent ໜຶ່ງ ຈະຕອບໂຈດຄວາມຕ້ອງການຂອງ Agent ຕໍ່ໄປ. ນອກຈາກນີ້ ຍັງສາມາດລະບຸຈຸດທີ່ເກີດບັນຫາໄດ້ງ່າຍ ແລະ ເຖິງແມ່ນວ່າຈະມີການປ່ຽນແທນ Agent ແຕ່ລະຕົວ ແຕ່ຖ້າຍັງຮັກສາສັນຍາໄວ້ໄດ້ ລະບົບໂດຍລວມກໍຈະຍັງເຮັດວຽກຕໍ່ໄປໄດ້.

ກຸນແຈສຳຄັນໃນການຄວບຄຸມຄວາມຊັບຊ້ອນຂອງ Multi-agent ຄືການບໍ່ປ່ອຍໃຫ້ມີການສື່ສານທີ່ເສລີເກີນໄປ ແຕ່ຕ້ອງມີການກຳນົດດ້ວຍ Type ຢ່າງເຂັ້ມງວດ. Structured Output ແມ່ນເທັກໂນໂລຢີພື້ນຖານທີ່ຊ່ວຍຮອງຮັບລະບຽບວິໄນດັ່ງກ່າວ.