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

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

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

ສະຫຼຸບ: Context Engineering ແມ່ນເຕັກນິກການອອກແບບ ແລະ ເພີ່ມປະສິດທິພາບຂໍ້ມູນທັງໝົດທີ່ຈະສົ່ງໃຫ້ LLM, ເຊິ່ງສາມາດເພີ່ມຄວາມແມ່ນຍຳໄດ້ຫຼາຍກວ່າການປັບປຸງພຽງແຕ່ Prompt ຢ່າງດຽວ.

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

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

ການປ່ຽນແນວຄິດນີ້ ຄືຄວາມແຕກຕ່າງທີ່ສຳຄັນລະຫວ່າງ Prompt Engineering ແລະ Context Engineering.

ເມື່ອຈັດລະບຽບຄວາມແຕກຕ່າງຂອງທັງສອງຢ່າງນີ້ ຈະໄດ້ດັ່ງນີ້:

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

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

ທີມງານ LangChain ໄດ້ຈັດປະເພດຍຸດທະສາດຫຼັກໃນການຈັດການ Context ໄວ້ 4 ຢ່າງໃນບົດຄວາມບລັອກທີ່ເປີດຕົວ ຫຼື Launch ໃນເດືອນກໍລະກົດ 2025 ຄື: "Write / Select / Compress / Isolate". ນີ້ແມ່ນຊັ້ນການອອກແບບທີ່ແຕກຕ່າງຈາກການປັບປຸງ Prompt ຢ່າງຊັດເຈນ.

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

ອົງປະກອບຫຼັກທີ່ປະກອບເປັນບໍລິບົດມີດັ່ງນີ້:

• System Prompt: ຄຳສັ່ງທີ່ກຳນົດໜ້າວຽກທັງໝົດ ເຊັ່ນ: ບົດບາດຂອງແບບຈຳລອງ, ຂໍ້ຈຳກັດ ແລະ ຮູບແບບການສະແດງຜົນ.
• User Input: ຂໍ້ຄວາມ ຫຼື ຄຳຖາມຫຼ້າສຸດໃນການສົນທະນາ.
• Conversation History: ບັນທຶກການສົນທະນາທີ່ຜ່ານມາ (ຈຳນວນ Token ຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ຕາມຈຳນວນຮອບຂອງການສົນທະນາ).
• External Knowledge: ເອກະສານທີ່ໄດ້ມາຈາກ RAG, ຜົນການຄົ້ນຫາຈາກຖານຂໍ້ມູນ ແລະ ການຕອບກັບຂອງ API.
• Tool Definition/Execution Results: ສະກີມາຂອງຟັງຊັນ ແລະ ຜົນການຮຽກໃຊ້ງານໃນການຕັ້ງຄ່າ Agent.
• Structured Notes: ສະຖານະກາງ ຫຼື ບົດສະຫຼຸບທີ່ສະສົມໄວ້ໃນວຽກໄລຍະຍາວ (ວິທີການທີ່ Anthropic ເອີ້ນວ່າ "structured note-taking").

ຖ້າຫາກວຽກງານເປັນພຽງການຖາມ-ຕອບແບບງ່າຍໆ, ການໃຊ້ພຽງ System Prompt ແລະ User Input ກໍຖືວ່າພຽງພໍໃນຫຼາຍກໍລະນີ. ໃນທາງກົງກັນຂ້າມ, ຖ້າເປັນວຽກງານຂອງ Agent ທີ່ມີຫຼາຍຂັ້ນຕອນ, ຈຳເປັນຕ້ອງມີການຈັດການໂດຍການລວມເອົາ Conversation History, ຜົນການຮຽກໃຊ້ງານ Tool ແລະ External Knowledge ເຂົ້າດ້ວຍກັນ. ການຈະເລືອກເອົາອົງປະກອບໃດມາໃສ່ໃນບໍລິບົດນັ້ນ ແມ່ນຂຶ້ນຢູ່ກັບຄວາມຊັບຊ້ອນຂອງວຽກງານ ແລະ ຄວາມຖືກຕ້ອງທີ່ຕ້ອງການ.

ສິ່ງທີ່ສຳຄັນຄື ທັງໝົດນີ້ແມ່ນການແບ່ງປັນຊັບພະຍາກອນທີ່ມີຈຳກັດ ເຊິ່ງກໍຄື Token Window. ອີງຕາມຂໍ້ມູນທາງການຂອງ Google Cloud, ໃນແບບຈຳລອງປັດຈຸບັນສາມາດໃຊ້ Window ໄດ້ເຖິງ 1 ລ້ານຫາ 2 ລ້ານ Token, ແຕ່ກໍບໍ່ໄດ້ໝາຍຄວາມວ່າຈະບໍ່ມີຂີດຈຳກັດ.

"ບໍ່ວ່າຈະປັບແຕ່ງ Prompt ຫຼາຍສໍ່າໃດ ແຕ່ເປັນຫຍັງຄວາມແມ່ນຍຳຈຶ່ງບໍ່ເພີ່ມຂຶ້ນເລີຍ" — ເຊື່ອວ່າຜູ້ພັດທະນາຫຼາຍຄົນຄົງເຄີຍມີປະສົບການແບບນີ້. ເບື້ອງຫຼັງຂອງຄວາມສົນໃຈທີ່ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆຕໍ່ Context Engineering ນັ້ນມາຈາກສອງກະແສຫຼັກ ຄື: ການພັດທະນາປະສິດທິພາບຂອງ LLM ແລະ ຄວາມຊັບຊ້ອນຂອງຄວາມຕ້ອງການໃນການເຮັດວຽກຕົວຈິງ.

ປັດໄຈຫຼັກທີ່ເຮັດໃຫ້ເກີດຄວາມສົນໃຈມີດັ່ງນີ້:

• ການຂະຫຍາຍ Context Window ຢ່າງມະຫາສານ: ອີງຕາມຂໍ້ມູນທາງການຂອງ Google Cloud, ຮຸ່ນປັດຈຸບັນ (ຕົວຢ່າງ: Gemini 3.1) ຮອງຮັບ Context Window ໄດ້ເຖິງ 1 ລ້ານ - 2 ລ້ານ Token. ເມື່ອປະລິມານຂໍ້ມູນທີ່ສາມາດຈັດການໄດ້ເພີ່ມຂຶ້ນ, ການອອກແບບວ່າ "ຈະໃສ່ຫຍັງລົງໄປ" ຈຶ່ງກາຍເປັນປັດໄຈທີ່ຕັດສິນຄວາມແມ່ນຍຳ.
• ການແຜ່ຫຼາຍຂອງ AI ແບບ Agent: Use case ໄດ້ປ່ຽນຈາກການຖາມ-ຕອບແບບຄັ້ງດຽວ ໄປສູ່ການປະຕິບັດວຽກງານແບບອັດຕະໂນມັດທີ່ຫຼາຍຂັ້ນຕອນ. ໃນບົດຄວາມທາງເຕັກນິກທີ່ Anthropic ໄດ້ເປີດຕົວ ຫຼື Launch ໃນເດືອນກັນຍາ 2025, ໄດ້ມີການແນະນຳວິທີການຕ່າງໆ ເຊັ່ນ: ການບີບອັດບໍລິບົດ (compaction) ສຳລັບວຽກງານໄລຍະຍາວ ແລະ ການບັນທຶກແບບມີໂຄງສ້າງ ເຊິ່ງເປັນການຢືນຢັນເຖິງຄວາມສຳຄັນຂອງການອອກແບບຂໍ້ມູນອີກຄັ້ງ.
• ມຸມມອງດ້ານການເພີ່ມປະສິດທິພາບຕົ້ນທຶນ: ອີງຕາມຂໍ້ມູນທາງການຂອງ Google Cloud, ການນຳໃຊ້ Context Cache ສາມາດຊ່ວຍຫຼຸດຕົ້ນທຶນໄດ້ສູງສຸດເຖິງ 90%, ເຮັດໃຫ້ການອອກແບບຂໍ້ມູນກາຍເປັນບັນຫາທີ່ສົ່ງຜົນໂດຍກົງບໍ່ພຽງແຕ່ຕໍ່ປະສິດທິພາບເທົ່ານັ້ນ ແຕ່ຍັງລວມເຖິງຕົ້ນທຶນໃນການດຳເນີນງານອີກດ້ວຍ.

ໃນບລັອກທີ່ທີມງານ LangChain ໄດ້ເປີດຕົວ ຫຼື Launch ໃນເດືອນກໍລະກົດ 2025, ຍັງໄດ້ມີການຈັດລະບົບການຈັດການ Context ໃຫ້ເປັນ 4 ຍຸດທະສາດ ຄື "Write / Select / Compress / Isolate" ເຊິ່ງເຮັດໃຫ້ເກີດພາສາກາງທີ່ໃຊ້ຮ່ວມກັນໃນທົ່ວອຸດສາຫະກຳ.

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

ຂໍ້ຈຳກັດຂອງ Token window, ການຂາດຫາຍໄປຂອງບໍລິບົດ (Context), ແລະ ການບໍ່ສາມາດຮອງຮັບວຽກງານທີ່ຊັບຊ້ອນໄດ້ — ທັງສາມບັນຫານີ້ແມ່ນຍາກທີ່ຈະແກ້ໄຂໄດ້ດ້ວຍການປັບປຸງພຽງແຕ່ Prompt ເທົ່ານັ້ນ. ໃນແຕ່ລະຫົວຂໍ້ H3 ຈະເຈາະເລິກເຖິງເຫດຜົນດັ່ງກ່າວຢ່າງລະອຽດ.

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

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

ໂດຍສະເພາະ, ບັນຫາຕໍ່ໄປນີ້ມັກຈະເກີດຂຶ້ນໄດ້ງ່າຍ:

• ຂໍ້ມູນສຳຄັນຖືກກົບຝັງ: ເມື່ອຄຳສັ່ງ ຫຼື ຂໍ້ເທັດຈິງທີ່ເປັນຫົວໃຈສຳຄັນຖືກກົບຝັງຢູ່ໃນຂໍ້ຄວາມຈຳນວນມະຫາສານ, ໂມເດວມີທ່າອ່ຽງທີ່ຈະເບິ່ງຂ້າມສິ່ງເຫຼົ່ານັ້ນ.
• ຄວາມສັບສົນຈາກສິ່ງລົບກວນ (Noise): ຍິ່ງມີຂໍ້ມູນທີ່ບໍ່ກ່ຽວຂ້ອງຫຼາຍເທົ່າໃດ, ຄວາມສ່ຽງທີ່ໂມເດວຈະອ້າງອີງເຫດຜົນທີ່ຜິດພາດກໍຍິ່ງ ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.
• ຕົ້ນທຶນທີ່ເພີ່ມຂຶ້ນ: ການສົ່ງ Token ທີ່ບໍ່ຈຳເປັນໄປເລື້ອຍໆ ຈະເຮັດໃຫ້ຕົ້ນທຶນ API ສູງຂຶ້ນ ໃນຂະນະທີ່ຄວາມຖືກຕ້ອງບໍ່ໄດ້ເພີ່ມຂຶ້ນ.

ໃນບລັອກທີ່ທີມງານ LangChain ໄດ້ ເປີດຕົວ ຫຼື Launch ໃນເດືອນກໍລະກົດ 2025, ໄດ້ນຳສະເໜີຍຸດທະສາດການຈັດການ Context ໂດຍແບ່ງອອກເປັນ 4 ປະເພດຄື: "Write / Select / Compress / Isolate". ເຊິ່ງເປັນແນວຄິດທີ່ວ່າ ບໍ່ແມ່ນພຽງແຕ່ການເພີ່ມຂໍ້ມູນ (Write) ເທົ່ານັ້ນ, ແຕ່ການ ຄັດເລືອກ (Select) · ບີບອັດ (Compress) · ແຍກສ່ວນ (Isolate) ແມ່ນສິ່ງທີ່ຂາດບໍ່ໄດ້.

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

ເມື່ອຂາດບໍລິບົດ, ບັນຫາຂອງ LLM ຄືການບໍ່ຕອບວ່າ "ບໍ່ຮູ້" ແຕ່ຈະສ້າງ "ຄຳຕອບທີ່ເບິ່ງຄືວ່າຖືກຕ້ອງ" ຈາກຂໍ້ມູນທີ່ບໍ່ຄົບຖ້ວນ.

ຮູບແບບທີ່ມັກເກີດຄຳຕອບຜິດມີ 3 ຢ່າງຫຼັກໆດັ່ງນີ້:

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

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

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

ທ່ານເຄີຍຮູ້ສຶກບໍ່ວ່າ "ເຖິງຈະພະຍາຍາມປັບປຸງ Prompt ຢ່າງຕໍ່ເນື່ອງ ແຕ່ຍິ່ງວຽກງານມີຄວາມຊັບຊ້ອນຫຼາຍເທົ່າໃດ ຜົນລັພທີ່ອອກມາກໍຍິ່ງບໍ່ຊັດເຈນ——ເປັນຍ້ອນຫຍັງກັນແນ່?"

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

ໃນບົດຄວາມທາງເຕັກນິກທີ່ Anthropic ໄດ້ເປີດຕົວ ຫຼື Launch ອອກມາ ກໍໄດ້ເນັ້ນຢ້ຳເຖິງຄວາມສຳຄັນຂອງການຈັດການບໍລິບົດໃນວຽກງານໄລຍະຍາວ ແລະ ໄດ້ແນະນຳໂຄງສ້າງທີ່ Sub-agent ຈະສົ່ງຜົນລວມ ຫຼື Merge ຂໍ້ມູນປະມານ 1,000-2,000 Token ໃນຕອນທ້າຍ. ນີ້ເປັນຕົວຢ່າງທີ່ດີທີ່ສະແດງໃຫ້ເຫັນວ່າ ການຈະຮັບມືກັບວຽກງານທີ່ຊັບຊ້ອນໄດ້ນັ້ນ ບໍ່ແມ່ນພຽງແຕ່ການໃຊ້ Prompt ດຽວ ແຕ່ຕ້ອງເລີ່ມຈາກການອອກແບບໂຄງສ້າງຂອງຂໍ້ມູນ ແລະ ວິທີການສົ່ງຕໍ່ຂໍ້ມູນນັ້ນເອງ.

ການອອກແບບ Prompt ເປັນພຽງເຕັກນິກໃນການປັບໃຫ້ "ການຖາມຄັ້ງດຽວ" ມີປະສິດທິພາບສູງສຸດເທົ່ານັ້ນ. ສິ່ງທີ່ຈຳເປັນສຳລັບວຽກງານທີ່ຊັບຊ້ອນ ຄືການອອກແບບວິທີການເລືອກຂໍ້ມູນ, ການບີບອັດຂໍ້ມູນ ແລະ ການເລືອກຊ່ວງເວລາທີ່ເໝາະສົມໃນການສົ່ງຂໍ້ມູນໃຫ້ Model——ນັ້ນກໍຄືມຸມມອງຂອງ Context Engineering.

ບໍ່ພຽງແຕ່ "ຈະສົ່ງຫຍັງໃຫ້" ເທົ່ານັ້ນ, ແຕ່ຍັງລວມເຖິງ "ສົ່ງໃນລຳດັບໃດ" ແລະ "ສົ່ງໃນປະລິມານເທົ່າໃດ" ໃຫ້ກັບ LLM — Context Engineering ແມ່ນເຕັກນິກໃນການອອກແບບສາມປັດໄຈນີ້ຢ່າງເປັນລະບົບ.

ຕໍ່ຈາກນີ້, ຈະຂໍອະທິບາຍພາບລວມຕາມລຳດັບ ເລີ່ມຈາກການຈັດລະບຽບອົງປະກອບທີ່ປະກອບເປັນ Context, ວຽກງານການອອກແບບເຊັ່ນ: ການເລືອກ, ການບີບອັດ, ແລະ ການຈັດວາງຂໍ້ມູນ, ໄປຈົນເຖິງຄວາມສຳພັນກັບ RAG ແລະ ການຈັດການ Memory.

ຫຼາຍຄົນມັກຄິດວ່າບໍລິບົດ (Context) ມີພຽງແຕ່ "ເນື້ອໃນຂອງພຣອມ (Prompt)" ເທົ່ານັ້ນ, ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ແຫຼ່ງຂໍ້ມູນທີ່ສົ່ງຜົນຕໍ່ຄຸນນະພາບຜົນລັດຂອງ LLM ນັ້ນກວ້າງຂວາງກວ່າຫຼາຍ. ໂດຍອີງຕາມແນວຄວາມຄິດການອອກແບບບໍລິບົດທີ່ LangChain ໄດ້ຈັດລະບຽບໄວ້, ເຮົາສາມາດແບ່ງອົງປະກອບອອກເປັນ 5 ປະເພດດັ່ງນີ້:

• System Prompt: ພື້ນຖານທີ່ໃຊ້ກຳນົດບົດບາດ, ຂໍ້ຈຳກັດ ແລະ ຮູບແບບການສະແດງຜົນຂອງ AI. ຖ້າສ່ວນນີ້ບໍ່ຊັດເຈນ, ຜົນລັດກໍຈະມີໂອກາດຜິດພ້ຽນໄດ້ງ່າຍ ເຖິງແມ່ນວ່າຂໍ້ມູນໃນສ່ວນຕໍ່ມາຈະຖືກຕ້ອງກໍຕາມ.
• User Input: ຄຳສັ່ງ ຫຼື ຄຳຖາມທີ່ຜູ້ໃຊ້ໃຫ້ໃນຂະນະດຳເນີນການ. ຍິ່ງເຈດຕະນາບໍ່ຊັດເຈນເທົ່າໃດ, ຄວາມສ່ຽງທີ່ຈະໄດ້ຮັບຄຳຕອບທີ່ຜິດພາດກໍຍິ່ງສູງຂຶ້ນ.
• External Knowledge (ເອກະສານທີ່ໄດ້ມາຈາກ RAG, ແລະ ອື່ນໆ): ຂໍ້ມູນສະເພາະດ້ານ ຫຼື ຂໍ້ມູນຫຼ້າສຸດທີ່ຈຳເປັນຕໍ່ວຽກງານ. ເຊິ່ງລວມເຖິງຜົນການຄົ້ນຫາຈາກເອກະສານພາຍໃນບໍລິສັດ ຫຼື ຖານຂໍ້ມູນ.
• Conversation History/Memory: ການສົນທະນາທີ່ຜ່ານມາ ຫຼື ຜົນລັດລະຫວ່າງທາງ. ໃນກໍລະນີຂອງ Anthropic, ໄດ້ມີການນຳໃຊ້ວິທີ "compaction" ເພື່ອສະຫຼຸບ ແລະ ບີບອັດການສົນທະນາໃນວຽກງານໄລຍະຍາວ ເຮັດໃຫ້ສາມາດຈັດການ Context Window ໄດ້ຢ່າງມີປະສິດທິພາບ.
• Tool Output/Structured Data: ຂໍ້ມູນທີ່ມີໂຄງສ້າງທີ່ Agent ໄດ້ມາ ເຊັ່ນ: ຜົນການປະມວນຜົນໂຄ້ດ, API Response, ສະເປຣດຊີດ, ແລະ ອື່ນໆ.

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

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

ການອອກແບບບໍລິບົດ (Context) ໃນທາງປະຕິບັດ ສາມາດແບ່ງອອກເປັນ 3 ວຽກງານຄື: "ການເລືອກ", "ການບີບອັດ", ແລະ "ການຈັດວາງ". ແຕ່ລະວຽກງານມີຫຼັກການຕັດສິນໃຈທີ່ເປັນເອກະລາດ, ຖ້າຫາກລະເລີຍຂໍ້ໃດຂໍ້ໜຶ່ງໄປ ຈະສົ່ງຜົນໃຫ້ຄວາມຖືກຕ້ອງຫຼຸດລົງ.

ການເລືອກ: ຈະລວມຫຍັງເຂົ້າໄປໃນບໍລິບົດ?

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

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

ການບີບອັດ: ຈະເຮັດໃຫ້ຂໍ້ມູນມີຄວາມກະທັດຮັດໄດ້ແນວໃດ?

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

ການຈັດວາງ: ຈະສົ່ງຂໍ້ມູນໄປໃນລຳດັບໃດ?

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

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

RAG (Retrieval-Augmented Generation) ແລະ ການຈັດການໜ່ວຍຄວາມຈຳ (Memory Management) ຖືກຈັດໃຫ້ເປັນວິທີການຈັດຕັ້ງປະຕິບັດຫຼັກຂອງ Context Engineering. ຄວາມສຳພັນຂອງທັງສອງສາມາດສະຫຼຸບໄດ້ດັ່ງນີ້:

• RAG: ທຽບເທົ່າກັບການປະຕິບັດງານ "ຂຽນ (Write)" ຂໍ້ມູນທີ່ກ່ຽວຂ້ອງຈາກຖານຂໍ້ມູນຄວາມຮູ້ພາຍນອກເຂົ້າໄປໃນບໍລິບົດ.
• ການຈັດການໜ່ວຍຄວາມຈຳ: ທຽບເທົ່າກັບການປະຕິບັດງານ "ເລືອກ (Select) / ບີບອັດ (Compress)" ສະເພາະຂໍ້ມູນທີ່ຈຳເປັນ ໂດຍການຮັກສາ ແລະ ບີບອັດປະຫວັດການສົນທະນາທີ່ຜ່ານມາ ຫຼື ສະຖານະກາງ ເພື່ອສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ບໍລິບົດ.

ທີມງານ LangChain ໄດ້ຈັດກຸ່ມຍຸດທະສາດຫຼັກໃນການຈັດການບໍລິບົດອອກເປັນ 4 ແກນ ຄື "Write / Select / Compress / Isolate". ພາຍໃຕ້ກອບການເຮັດວຽກນີ້, RAG ເປັນຕົວຢ່າງທີ່ໂດດເດັ່ນຂອງຍຸດທະສາດ Write, ສ່ວນການຈັດການໜ່ວຍຄວາມຈຳຈະເຮັດໜ້າທີ່ເປັນການປະສົມປະສານລະຫວ່າງ Select ແລະ Compress.

ໃນບົດຄວາມທາງເຕັກນິກຂອງ Anthropic, ການອອກແບບ Agent ສຳລັບວຽກງານໄລຍະຍາວໄດ້ລະບຸວ່າ "compaction (ການບີບອັດບໍລິບົດໂດຍການສະຫຼຸບການສົນທະນາ)" ແລະ "structured note-taking (ການຈັດການຄວາມຈຳຜ່ານການຈົດບັນທຶກແບບມີໂຄງສ້າງ)" ເປັນເຕັກໂນໂລຊີທີ່ສຳຄັນ. ຍັງມີການແນະນຳໂຄງສ້າງທີ່ Sub-agent ສົ່ງຄ່າສະຫຼຸບປະມານ 1,000–2,000 tokens ກັບຄືນມາ ເຊິ່ງນີ້ກໍຄືຕົວຢ່າງຂອງການຈັດຕັ້ງປະຕິບັດການບີບອັດບໍລິບົດ (Context Compression) ໂດຍກົງ.

ສະຫຼຸບ: ຖ້າປ່ອຍໃຫ້ມີຄວາມເຂົ້າໃຈຜິດກ່ຽວກັບການອອກແບບບໍລິບົດ (Context Design), ມາດຕະການປັບປຸງກໍຈະບໍ່ກົງຈຸດ.

ການອອກແບບບໍລິບົດ (Context Engineering) ມັກຈະມີຄວາມເຂົ້າໃຈຜິດທີ່ວ່າ "ພຽງແຕ່ເຮັດໃຫ້ Prompt ຍາວຂຶ້ນກໍພຽງພໍແລ້ວ" ຫຼື "ສາມາດໃຊ້ການ Fine-tuning ແທນໄດ້". ໃນແຕ່ລະຫົວຂໍ້ H3 ຈະມີການຈັດລະບຽບຄວາມເຂົ້າໃຈຜິດເຫຼົ່ານັ້ນ ແລະ ຊີ້ແນະແນວທາງໃນການຕັດສິນໃຈອອກແບບທີ່ຖືກຕ້ອງ.

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

ເຫດຜົນຫຼັກທີ່ເຮັດໃຫ້ Prompt ຍາວເກີນໄປສົ່ງຜົນກົງກັນຂ້າມ ມີ 3 ປະການດັ່ງນີ້:

• ຄວາມສົນໃຈທີ່ເຈືອຈາງລົງ (Attention dilution): ເມື່ອຈຳນວນ Token ເພີ່ມຂຶ້ນ, ກົນໄກການເອົາໃຈໃສ່ (Attention mechanism) ຂອງ Model ມັກຈະສຸມໃສ່ຂໍ້ມູນສຳຄັນໄດ້ຍາກຂຶ້ນ.
• ການປົນເປື້ອນຂອງສິ່ງລົບກວນ (Noise): ເມື່ອຂໍ້ມູນທີ່ບໍ່ກ່ຽວຂ້ອງເພີ່ມຂຶ້ນ, ຄວາມສ່ຽງທີ່ Model ຈະອ້າງອີງເຖິງຂໍ້ຄຶດທີ່ຜິດພາດກໍຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.
• ຕົ້ນທຶນ ແລະ ຄວາມໜ່ວງທີ່ເພີ່ມຂຶ້ນ: ການປ້ອນຂໍ້ມູນທີ່ຍາວໂດຍບໍ່ຈຳເປັນ ຈະເຮັດໃຫ້ຕົ້ນທຶນໃນການປະມວນຜົນ ແລະ ເວລາໃນການຕອບໂຕ້ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

ໃນໜ້າເວັບໄຊທາງການຂອງ Google Cloud, ໄດ້ມີການແນະນຳວ່າໃນຂະນະທີ່ Model ປັດຈຸບັນ (ຕົວຢ່າງ: Gemini 3.1) ສາມາດຮອງຮັບ Context window ໄດ້ເຖິງ 1 ລ້ານຫາ 2 ລ້ານ Token, ແຕ່ກໍຍັງມີການນຳສະເໜີການຫຼຸດຕົ້ນທຶນໄດ້ສູງສຸດເຖິງ 90% ໂດຍຜ່ານ Context caching. ການທີ່ Window ຂະຫຍາຍກວ້າງຂຶ້ນເຮັດໃຫ້ເກີດແນວຄິດທີ່ວ່າ "ການຍັດຂໍ້ມູນໃສ່ໃຫ້ເຕັມຈະຊ່ວຍແກ້ໄຂບັນຫາໄດ້" ງ່າຍຂຶ້ນ, ແຕ່ໃນມຸມມອງຂອງການປັບແຕ່ງຕົ້ນທຶນໃຫ້ເໝາະສົມ, ການອອກແບບໂດຍການຕັດຂໍ້ມູນທີ່ບໍ່ຈຳເປັນອອກແມ່ນມີຄວາມສຳຄັນຫຼາຍ.

ໃນກອບການເຮັດວຽກ "Write / Select / Compress / Isolate" ທີ່ທີມງານ LangChain ໄດ້ສະເໜີໄວ້, Select (ການເລືອກສະເພາະຂໍ້ມູນທີ່ຈຳເປັນ) ແລະ Compress (ການບີບອັດເພື່ອເພີ່ມຄວາມໜາແໜ້ນຂອງຂໍ້ມູນ) ໄດ້ຖືກຈັດໃຫ້ເປັນຂັ້ນຕອນທີ່ເປັນເອກະລາດ. ສິ່ງນີ້ສະແດງໃຫ້ເຫັນວ່າ ການປັບຄຸນນະພາບໃຫ້ດີທີ່ສຸດ, ບໍ່ແມ່ນການເພີ່ມປະລິມານ, ຄືຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການອອກແບບ Context.

ຄວາມຍາວຂອງ Prompt ເປັນພຽງວິທີການ, ບໍ່ແມ່ນຈຸດປະສົງ.

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

ເມື່ອຈັດລະບຽບພາລະບົດບາດຂອງທັງສອງຢ່າງ, ສາມາດແບ່ງອອກໄດ້ດັ່ງນີ້:

• Fine-tuning: ອັບເດດພາຣາມິເຕີຂອງຕົວແບບຈຳລອງເອງ ເພື່ອເສີມສ້າງການປັບຕົວໃຫ້ເຂົ້າກັບໂທນສຽງ, ຮູບແບບ ແລະ ຄຳສັບສະເພາະດ້ານ (Domain vocabulary) ທີ່ກຳນົດໄວ້.
• Context Engineering: ເພີ່ມປະສິດທິພາບໂຄງສ້າງ, ລຳດັບ ແລະ ຄວາມໜາແໜ້ນຂອງຂໍ້ມູນທີ່ສົ່ງໃຫ້ໃນຂະນະປະມວນຜົນ ເພື່ອສ້າງສະພາບແວດລ້ອມທີ່ເຮັດໃຫ້ແບບຈຳລອງສາມາດປະມວນຜົນໄດ້ຢ່າງຖືກຕ້ອງ.

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

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

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

"ການອອກແບບບໍລິບົດ (Context Design) ເປັນໜ້າທີ່ຂອງວິສະວະກອນ, ຕົນເອງບໍ່ກ່ຽວຂ້ອງ" — ເຊື່ອວ່າຜູ້ຮັບຜິດຊອບດ້ານທຸລະກິດ ຫຼື Product Owner ຫຼາຍຄົນຄົງຄິດແບບນັ້ນ. ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ, ການຕັດສິນໃຈຫຼາຍຢ່າງທີ່ສົ່ງຜົນຕໍ່ຄຸນນະພາບຂອງການອອກແບບບໍລິບົດນັ້ນ ມີພຽງແຕ່ຜູ້ທີ່ບໍ່ແມ່ນວິສະວະກອນທີ່ມີຄວາມຮູ້ໃນ Domain ນັ້ນໆເທົ່ານັ້ນທີ່ສາມາດຕັດສິນໃຈໄດ້.

ການອອກແບບບໍລິບົດມີການຕັດສິນໃຈທີ່ກ່ຽວຂ້ອງແບ່ງອອກເປັນ 2 ປະເພດໃຫຍ່ໆ:

• ການຕັດສິນໃຈດ້ານການປະຕິບັດທາງເຕັກນິກ: ວິທີການບີບອັດ Token, ລໍຊິກການຄົ້ນຫາຂອງ RAG, ກົນໄກການຈັດການ Memory, ແລະ ອື່ນໆ.
• ການຕັດສິນໃຈດ້ານການອອກແບບຂໍ້ມູນ: ຄວນສົ່ງຂໍ້ມູນໃດໃຫ້ AI, ຄວນນຳສະເໜີຕາມລຳດັບໃດ, ແລະ ຄວນຕັດສິ່ງໃດອອກ.

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

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

ໃນທາງປະຕິບັດ, ການແບ່ງໜ້າທີ່ດັ່ງຕໍ່ໄປນີ້ມັກຈະເຮັດວຽກໄດ້ດີ:

• ຜູ້ຮັບຜິດຊອບວຽກງານ/PO: ການຈັດລຳດັບຄວາມສຳຄັນຂອງຂໍ້ມູນທີ່ຄວນສົ່ງ, ການກຳນົດ Use Case, ການປະເມີນຄຸນນະພາບຜົນລວມ.
• ວິສະວະກອນ: ການຈັດຕັ້ງປະຕິບັດການດຶງຂໍ້ມູນ, ການບີບອັດຂໍ້ມູນ, ການນຳຂໍ້ມູນເຂົ້າ (Injection), ແລະ ການເພີ່ມປະສິດທິພາບ (Performance Optimization).

ການປັບປ່ຽນມຸມມອງໃຫ້ເຫັນວ່າ Context Engineering ເປັນກິດຈະກຳການອອກແບບຂອງທັງທີມ ຄືບາດກ້າວທຳອິດທີ່ຈະຊ່ວຍຍົກລະດັບຄວາມຖືກຕ້ອງໃນການນຳໃຊ້ LLM ໃຫ້ສູງຂຶ້ນ.

ສະຫຼຸບ: ການປັບປຸງຄວາມແມ່ນຍຳຂອງ LLM ແມ່ນຂຶ້ນກັບຫຼັກການອອກແບບທີ່ວ່າ "ຈະວາງຫຍັງ, ໄວ້ບ່ອນໃດ ແລະ ວາງແນວໃດ" ໃນບໍລິບົດ (Context).

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

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

LLM ບໍ່ໄດ້ອ້າງອີງຂໍ້ມູນໃນທົ່ວທັງ Context Window ຢ່າງເທົ່າທຽມກັນ ແຕ່ມີແນວໂນ້ມທີ່ຈະອ້າງອີງຂໍ້ມູນທີ່ວາງໄວ້ໃນຕອນຕົ້ນຂອງການປ້ອນຂໍ້ມູນໄດ້ດີກວ່າ. ສິ່ງນີ້ເປັນທີ່ຮູ້ຈັກກັນໃນນາມ "Primacy Effect" ແລະມີການລາຍງານຜ່ານການທົດລອງວ່າ ຂໍ້ມູນທີ່ຖືກຝັງໄວ້ໃນສ່ວນກາງຂອງ Context ທີ່ມີຄວາມຍາວຫຼາຍນັ້ນ ມັກຈະຖືກເບິ່ງຂ້າມໄດ້ງ່າຍ.

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

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

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

ພື້ນຖານຂອງການກຳຈັດສິ່ງລົບກວນ (Noise) ຄື "ການກຳຈັດຂໍ້ມູນທີ່ບໍ່ກ່ຽວຂ້ອງກັບວຽກອອກໄປທາງກາຍະພາບ". ໂດຍສະເພາະແມ່ນການຈັດລະບຽບຕາມມຸມມອງຕໍ່ໄປນີ້:

• ການກຳຈັດຂໍ້ມູນຊ້ຳຊ້ອນ: ໃນກໍລະນີທີ່ມີຂໍ້ເທັດຈິງດຽວກັນຂຽນໄວ້ຫຼາຍບ່ອນ ໃຫ້ລວມ (Merge) ໄວ້ບ່ອນດຽວ
• ການລຶບຄຳນຳ ຫຼື ຂໍ້ຄວາມປະຕິເສດຄວາມຮັບຜິດຊອບທີ່ບໍ່ຈຳເປັນ: ຂໍ້ຄວາມແບບຟອມເຊັ່ນ "ເອກະສານສະບັບນີ້ຖືກສ້າງຂຶ້ນເພື່ອຈຸດປະສົງ..." ມັກຈະບໍ່ມີຄວາມໝາຍສຳລັບຕົວແບບ (Model)
• ການຄັດເລືອກຂໍ້ມູນເມຕາ (Meta information): ຊື່ໄຟລ໌, ວັນທີອັບເດດ, ຜູ້ສ້າງ ແລະ ອື່ນໆ ໃຫ້ເກັບໄວ້ສະເພາະໃນກໍລະນີທີ່ຈຳເປັນຕໍ່ວຽກເທົ່ານັ້ນ

ສິ່ງທີ່ມີປະສິດທິພາບໃນການເພີ່ມຄວາມໜາແໜ້ນຂອງຂໍ້ມູນ ຄືຍຸດທະສາດ "Compress (ການບີບອັດ)" ທີ່ LangChain ໄດ້ສະເໜີໄວ້. ການສະຫຼຸບເອກະສານຍາວໆກ່ອນຈະນຳໄປໃສ່ໃນບໍລິບົດ ຈະຊ່ວຍໃຫ້ທ່ານສາມາດບັນຈຸສະເພາະຂໍ້ມູນທີ່ເປັນແກນຫຼັກ (ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ) ລົງໃນຂອບເຂດຂອງ Token ທີ່ມີຈຳກັດໄດ້.

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

ນອກຈາກນີ້, ຮູບແບບໂຄງສ້າງ ທີ່ໃຊ້ການຂຽນແບບເປັນຂໍ້ໆ ຫຼື ຫົວຂໍ້ຍັງຊ່ວຍເພີ່ມຄວາມໜາແໜ້ນຂອງຂໍ້ມູນໄດ້ອີກດ້ວຍ. ຂໍ້ຄວາມທີ່ມີການຈັດໂຄງສ້າງຈະມີແນວໂນ້ມທີ່ຕົວແບບສາມາດອ້າງອີງຂໍ້ມູນໄດ້ງ່າຍກວ່າຂໍ້ຄວາມແບບຮ້ອຍແກ້ວ.

"ເປັນຫຍັງຄວາມຖືກຕ້ອງຈຶ່ງຫຼຸດລົງສະເພາະບາງຄຳຖາມ ທັງທີ່ໃຊ້ System Prompt ດຽວກັນໃນການຈັດການທຸກວຽກ?" ຄຳຖາມນີ້ເປັນສິ່ງທີ່ຫຼາຍທີມພັດທະນາພົບພໍ້. ສາເຫດສ່ວນໃຫຍ່ມາຈາກການທີ່ Context ຖືກຄົງຄ່າໄວ້ແບບຄົງທີ່.

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

ໂດຍສະເພາະ, ການປັບປ່ຽນໃນລັກສະນະດັ່ງຕໍ່ໄປນີ້:

• ການປັບປ່ຽນຕາມປະເພດວຽກ: ສົ່ງເອກະສານທັງໝົດສຳລັບວຽກງານສະຫຼຸບຄວາມ, ແຕ່ສົ່ງສະເພາະ Chunk ທີ່ກ່ຽວຂ້ອງເຊິ່ງໄດ້ຈາກການຄົ້ນຫາສຳລັບວຽກງານ Q&A
• ການປັບປ່ຽນຕາມຄຸນລັກສະນະຂອງຜູ້ໃຊ້: ແຊກຄຳອະທິບາຍພື້ນຖານສຳລັບຜູ້ເລີ່ມຕົ້ນ, ແລະ ໃຫ້ຄວາມສຳຄັນກັບ ມາດຕະຖານ ຫຼື Specification ລະອຽດສຳລັບຜູ້ໃຊ້ລະດັບສູງ
• ການບີບອັດ ແລະ ຄັດເລືອກປະຫວັດການສົນທະນາ: ໃນການສົນທະນາໄລຍະຍາວ ຈະບໍ່ຮັກສາປະຫວັດທັງໝົດ ແຕ່ຈະຮັກສາໄວ້ພຽງແຕ່ການສົນທະນາທີ່ສຳຄັນຫຼ້າສຸດ ແລະ ບົດສະຫຼຸບເທົ່ານັ້ນ

ການຈັດປະເພດ "Write / Select / Compress / Isolate" ທີ່ LangChain ນຳສະເໜີ ກໍເປັນການຈັດລະບົບການຈັດການຂໍ້ມູນແບບ Dynamic ນີ້ເຊັ່ນກັນ. ໂດຍສະເພາະການປະສົມປະສານລະຫວ່າງ "Select (ການຄັດເລືອກ)" ແລະ "Compress (ການບີບອັດ)" ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການປັບປ່ຽນຕາມວຽກ.

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

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

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

ໃນການວິນິດໄສ, ພວກເຮົາຈະທຳການກວດສອບສະພາບປັດຈຸບັນຂອງການອອກແບບ Prompt ໂດຍອີງຕາມມຸມມອງດັ່ງນີ້:

• ຂໍ້ມູນຂາດຫາຍ: LLM ໄດ້ຮັບຂໍ້ມູນພື້ນຖານທີ່ຈຳເປັນຕໍ່ການຕອບ (ກົດລະບຽບການເຮັດວຽກ, ຄຳນິຍາມຂອງຄຳສັບ, ການສົນທະນາໃນອະດີດ ແລະ ອື່ນໆ) ແລ້ວຫຼືບໍ່
• ຂໍ້ມູນຫຼາຍເກີນໄປ ຫຼື ຂໍ້ມູນລົບກວນ (Noise): ມີຂໍ້ມູນທີ່ບໍ່ກ່ຽວຂ້ອງປົນເຂົ້າມາ ຈົນເຮັດໃຫ້ຄວາມສົນໃຈຂອງ Model ກະຈັດກະຈາຍຫຼືບໍ່
• ບັນຫາການຈັດວາງ: ຄຳສັ່ງທີ່ສຳຄັນ ຫຼື ຂໍ້ມູນອ້າງອີງຖືກວາງໄວ້ທ້າຍ Prompt ຈົນຖືກບົດຄວາມຍາວໆໃນຕອນຕົ້ນກົບໄວ້ຫຼືບໍ່
• ຄວາມບໍ່ສອດຄ່ອງຂອງບໍລິບົດ (Context): ຂໍ້ມູນພື້ນຖານໄດ້ຖືກສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ລະຫວ່າງຫຼາຍຮອບການສົນທະນາ ຫຼື ຫຼາຍ Agent ແລ້ວຫຼືບໍ່

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

ການຈັດລະບຽບຜົນການວິນິດໄສໃຫ້ຢູ່ໃນຮູບແບບຕາຕະລາງງ່າຍໆ ຈະຊ່ວຍໃຫ້ສາມາດສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ໄລຍະການອອກແບບຕໍ່ໄປໄດ້ງ່າຍຂຶ້ນ.

ເມື່ອບັນຫາໄດ້ຮັບການຊັດເຈນຈາກການວິນິດໄສໃນຂັ້ນຕອນທີ 1 ແລ້ວ, ຂັ້ນຕອນຕໍ່ໄປແມ່ນການອອກແບບ ແລະ ຈັດຕັ້ງໂຄງສ້າງບໍລິບົດ (Context) ໃຫ້ເປັນຮູບປະທຳ.

ພື້ນຖານຂອງການອອກແບບແມ່ນການພິຈາລະນາໂດຍຍຶດເອົາ 4 ການປະຕິບັດທີ່ທີມງານ LangChain ໄດ້ສະເໜີໄວ້ ຄື: "Write / Select / Compress / Isolate".

• Write (ການຂຽນ): ບັນທຶກປະຫວັດການສົນທະນາ ຫຼື ຜົນລັດລະຫວ່າງທາງໄວ້ເປັນບັນທຶກທີ່ມີໂຄງສ້າງ ເພື່ອໃຫ້ສາມາດອ້າງອີງໄດ້ໃນຂັ້ນຕອນຕໍ່ໄປ
• Select (ການເລືອກ): ຄັດກອງສະເພາະຂໍ້ມູນທີ່ກ່ຽວຂ້ອງກັບວຽກງານໃນປັດຈຸບັນອອກມາຈາກ RAG ຫຼື Memory store
• Compress (ການບີບອັດ): ຫຼຸດຈຳນວນ Token ທີ່ບໍ່ຈຳເປັນເພື່ອເພີ່ມຄວາມໜາແໜ້ນຂອງຂໍ້ມູນ ເຊັ່ນດຽວກັບ Compaction (ການສະຫຼຸບຫຍໍ້ການສົນທະນາ) ທີ່ Anthropic ແນະນຳ
• Isolate (ການແຍກອອກ): ມອບໝາຍວຽກຍ່ອຍໃຫ້ກັບ Sub-agent ເພື່ອປ້ອງກັນບໍ່ໃຫ້ເກີດສຽງລົບກວນ (Noise) ປົນເຂົ້າໄປໃນບໍລິບົດຫຼັກ

ສິ່ງສຳຄັນຄືການປັບປ່ຽນຈຸດເນັ້ນໜັກຕາມລັກສະນະຂອງວຽກງານ. ຖ້າເປັນວຽກງານ Q&A ແບບຄັ້ງດຽວຈົບ ຄວນໃຫ້ຄວາມສຳຄັນກັບ Select ແລະ Compress, ແຕ່ຖ້າເປັນວຽກງານປະເພດ Agent ທີ່ມີໄລຍະຍາວ ຄວນອອກແບບໂດຍຍຶດ Write ແລະ Isolate ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ.

ໃນຂັ້ນຕອນການຈັດຕັ້ງປະຕິບັດ, ແນະນຳໃຫ້ເລີ່ມທົດລອງຈາກໜ່ວຍຍ່ອຍໆກ່ອນ.

1. ແຍກລະບົບບໍລິບົດ (ບົດບາດ, ຂໍ້ຈຳກັດ, ຮູບແບບຜົນລັດ) ອອກມາຢ່າງຊັດເຈນໄວ້ທີ່ສ່ວນຕົ້ນຂອງ Prompt ທີ່ມີຢູ່ແລ້ວ
2. ແຊກເອກະສານທີ່ກ່ຽວຂ້ອງເຂົ້າໄປແບບໄດນາມິກດ້ວຍ RAG ແລ້ວປ່ຽນແທນ Prompt ຍາວໆແບບສະຖິດ