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

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

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

ຄຸນນະພາບຂອງແອັບພລິເຄຊັນ LLM ໄດ້ຮັບການຍອມຮັບຢ່າງກວ້າງຂວາງໃນການນຳໃຊ້ຈິງວ່າ ຂຶ້ນຢູ່ກັບ "ຈະໃສ່ຫຍັງ, ໃສ່ໃນລຳດັບໃດ ແລະ ໃສ່ໃນ Context Window ຫຼາຍເທົ່າໃດ" ຫຼາຍກວ່າວິທີການຂຽນ Prompt. ບລັອກດ້ານວິສະວະກຳຂອງ Anthropic ໄດ້ນິຍາມ Context ວ່າເປັນ "ຊຸດຂອງ Token ທີ່ຖືກສຸ່ມຕົວຢ່າງໃນຂະນະປະມວນຜົນ" ແລະ ຈັດຕຳແໜ່ງໃຫ້ຄວາມເປັນປະໂຫຍດຂອງມັນເປັນບັນຫາທາງວິສະວະກຳທີ່ຕ້ອງມີການປັບໃຫ້ເໝາະສົມໃນຖານະຊັບພະຍາກອນທີ່ມີຈຳກັດ (ທີ່ມາ: Anthropic Engineering – Effective context engineering for AI agents)。

Prompt Engineering ແມ່ນການເນັ້ນໃສ່ການປັບປ່ຽນຄຳສັ່ງ (Prompt) ທີ່ໃຫ້ກັບ LLM ເພື່ອດຶງເອົາປະສິດທິພາບຂອງວຽກງານອອກມາ. ໃນທາງກົງກັນຂ້າມ, Context Engineering ແມ່ນການລວມເອົາອົງປະກອບຕ່າງໆທີ່ຢູ່ອ້ອມຂ້າງຄຳສັ່ງ ເຊັ່ນ: ເອກະສານທີ່ຖືກຄົ້ນຫາ (RAG), ປະຫວັດການສົນທະນາທີ່ຜ່ານມາ, ຄໍານິຍາມຂອງເຄື່ອງມືທີ່ສາມາດນຳໃຊ້ໄດ້, ໜ່ວຍຄວາມຈຳໄລຍະຍາວ, ຈົນເຖິງຕົວຢ່າງ Few-shot ເຂົ້າໄປໃນຂອບເຂດຂອງການອອກແບບ.

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

ຕົວຢ່າງທີ່ເຫັນໄດ້ຊັດເຈນຄື Vercel ໄດ້ລາຍງານໃນບລັອກດ້ານວິສະວະກຳຂອງຕົນວ່າ ຫຼັງຈາກທີ່ໄດ້ຫຼຸດຈຳນວນເຄື່ອງມືຂອງ Agent ຈາກ 15 ຕົວ ເຫຼືອພຽງ 2 ຕົວ, ຜົນການທົດສອບ (Benchmark) 5 ຄິວຣີ (Query) ພົບວ່າຄວາມຖືກຕ້ອງເພີ່ມຂຶ້ນຈາກ 80% ເປັນ 100%, ປະລິມານ Token ຫຼຸດລົງ 37% ແລະ ຄວາມໄວໃນການຕອບສະໜອງດີຂຶ້ນເຖິງ 3.5 ເທົ່າ. ນີ້ບໍ່ແມ່ນຜົນສຳເລັດຈາກການຂຽນຄຳສັ່ງ Prompt ໃໝ່, ແຕ່ເປັນຜົນສຳເລັດຈາກການຄັດເລືອກຂໍ້ມູນທີ່ຈະນຳມາໃສ່ໃນ Context ໃຫ້ມີຄວາມຊັດເຈນຂຶ້ນ.

ເຫດຜົນທີ່ Context Engineering ໄດ້ຮັບຄວາມສົນໃຈຢ່າງວ່ອງໄວນັບແຕ່ກາງປີ 2025 ເປັນຕົ້ນມາ ແມ່ນຍ້ອນການປ່ຽນແປງສະໜາມຮົບຂອງແອັບພລິເຄຊັນ LLM ຈາກ "ການຖາມ-ຕອບແບບຄັ້ງດຽວ" ໄປສູ່ "ຕົວແທນອັດຕະໂນມັດ (Autonomous Agents) ທີ່ເຮັດວຽກຫຼາຍຮອບ".

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

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

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

ການບໍ່ເໝາະຮວມເອີ້ນພຽງແຕ່ "Prompt" ແຕ່ຫາກເປັນການແຍກອົງປະກອບອອກມາຈັດການນັ້ນ ຄືບາດກ້າວທຳອິດຂອງການອອກແບບ Context. ໃນບໍລິສັດຂອງພວກເຮົາເອງ ເວລາອອກແບບ Agent ພາຍໃນ ກໍມັກຈະເລີ່ມຕົ້ນດ້ວຍ Workshop ການແຍກອົງປະກອບຂອງ Context ດ້ວຍ 6 ປະເພດນີ້ກ່ອນສະເໝີ.

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

Task Instruction ແມ່ນທຽບເທົ່າກັບຄຳຮ້ອງຂໍທີ່ລະອຽດເຊິ່ງສົ່ງມາຈາກຜູ້ໃຊ້ໃນແຕ່ລະ Turn. ໃນຂະນະທີ່ System Prompt ກຳນົດວ່າ "ຈະປະຕິບັດຕົວແນວໃດ", Task Instruction ຈະເປັນຕົວລະບຸວ່າ "ຄັ້ງນີ້ຕ້ອງການໃຫ້ເຮັດຫຍັງ".

Few-shot Example ແມ່ນຄູ່ຂອງ Input-Output ທີ່ຖືກໃສ່ເຂົ້າມາເພື່ອສະແດງຕົວຢ່າງຂອງຮູບແບບຜົນລວມ ຫຼື ຂະບວນການຄິດ. ບໍ່ແມ່ນວ່າຕົວຢ່າງຍິ່ງຫຼາຍຍິ່ງດີ, ແຕ່ກົດເກນທົ່ວໄປຄືການຄັດເລືອກຢ່າງລະມັດລະວັງປະມານ 2-5 ຕົວຢ່າງ ເພື່ອໃຫ້ກວມເອົາຮູບແບບທີ່ຫຼາກຫຼາຍ. ສຳລັບ Task ທີ່ກັງວົນເລື່ອງຄວາມບໍ່ສະໝ່ຳສະເໝີຂອງຜົນລວມ, ການອອກແບບ Few-shot ຈະມີປະສິດທິຜົນຫຼາຍ.

ຄວາມຮູ້ພາຍນອກທີ່ໃສ່ເຂົ້າໃນ RAG ໝາຍເຖິງເອກະສານທີ່ກ່ຽວຂ້ອງທີ່ໄດ້ມາຈາກການຄົ້ນຫາແບບ Vector ຫຼື ການຄົ້ນຫາແບບເຕັມຮູບແບບ (Full-text search). ຖ້າຈຳນວນເອກະສານຫຼາຍເກີນໄປ ຄວາມກ່ຽວຂ້ອງຈະຫຼຸດໜ້ອຍລົງ, ແລະ ຖ້າໜ້ອຍເກີນໄປຈະເຮັດໃຫ້ຂໍ້ມູນບໍ່ພຽງພໍ ແລະ ເກີດອາການ Hallucination ເພີ່ມຂຶ້ນ. ສຳລັບການປັບປຸງຄວາມແມ່ນຍຳໂດຍໃຊ້ Hybrid Search, ກະລຸນາອ້າງອີງບົດຄວາມທີ່ກ່ຽວຂ້ອງ "Hybrid Search ແມ່ນຫຍັງ? ກົນໄກ ແລະ ການນຳໃຊ້ເພື່ອເພີ່ມຄວາມແມ່ນຍຳຂອງ RAG ດ້ວຍ Vector Search × Full-text Search".

ການກຳນົດເຄື່ອງມື (Tool definition) ແມ່ນ ມາດຕະຖານ ຫຼື Specification (ຊື່, ພາຣາມິເຕີ, ຄຳອະທິບາຍ) ຂອງຟັງຊັນທີ່ Agent ສາມາດເອີ້ນໃຊ້ໄດ້. ດັ່ງທີ່ຕົວຢ່າງຂອງ Vercel ໄດ້ສະແດງໃຫ້ເຫັນ, ພຽງແຕ່ການໃສ່ເຄື່ອງມືທີ່ບໍ່ຈຳເປັນເຂົ້າໄປ ກໍເຮັດໃຫ້ຄວາມແມ່ນຍຳຫຼຸດລົງຢ່າງເຫັນໄດ້ຊັດ. ຫຼັກການແມ່ນການຈຳກັດຈຳນວນເຄື່ອງມືໃຫ້ເຫຼືອພຽງ "ສິ່ງທີ່ໃຊ້ໃນວຽກງານນີ້ແທ້ໆ" ບໍ່ແມ່ນ "ມີໄວ້ກໍສະດວກດີ".

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

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

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

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

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

ໃນກໍລະນີທີ່ມີຈຳນວນເອກະສານ ຫຼື ປະຫວັດການສົນທະນາທີ່ໄດ້ມາຈາກ RAG ເປັນຈຳນວນຫຼາຍ, ບໍ່ຄວນນຳທັງໝົດໃສ່ລົງໄປ, ແຕ່ໃຫ້ນຳເຂົ້າໄປໃນບໍລິບົດ (Context) ຕາມລຳດັບຄວາມສຳຄັນໂດຍອີງໃສ່ຄະແນນຄວາມກ່ຽວຂ້ອງ. ໂດຍທົ່ວໄປແລ້ວ, ຈະມີການນຳໃຊ້ Vector Similarity, BM25, ແລະ Reranker Model (ຕົວຢ່າງ: Cohere Rerank) ມາປະສົມປະສານກັນ ເພື່ອຮັກສາໄວ້ພຽງແຕ່ N ລາຍການເທິງສຸດເທົ່ານັ້ນ.

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

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

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

ອີກຮູບແບບໜຶ່ງທີ່ສຳຄັນຄື ການແຍກໜ່ວຍຄວາມຈຳ (Memory Separation). ໂດຍການແຍກປະຫວັດການສົນທະນາໄລຍະສັ້ນ ອອກຈາກຂໍ້ມູນຄວາມມັກຂອງຜູ້ໃຊ້ ແລະ ຂໍ້ມູນໂຄງການທີ່ຕ້ອງເກັບຮັກສາໄວ້ຢ່າງຖາວອນ ໄວ້ໃນບ່ອນຈັດເກັບຂໍ້ມູນ (Store) ແຍກຕ່າງຫາກ, ແລ້ວເລືອກໃສ່ເຂົ້າໄປໃນບໍລິບົດຕາມຄວາມຈຳເປັນ. Session Memory ທີ່ OpenAI Agents SDK ສະໜອງໃຫ້ ສາມາດຖືວ່າເປັນຄວາມພະຍາຍາມໃນການເຮັດໃຫ້ການແຍກສ່ວນນີ້ເປັນມາດຕະຖານ. ເຊິ່ງຮອງຮັບທັງວິທີການ Trimming ທີ່ເກັບໄວ້ສະເພາະ N ລາຍການຫຼ້າສຸດ ແລະ ວິທີການ Summarization ທີ່ປ່ຽນແທນປະຫວັດເກົ່າດ້ວຍການສະຫຼຸບ.

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

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

ໃນ Coding Agent ຫຼື Autonomous Research Agent, ການເອີ້ນໃຊ້ງານ Tool ຫຼາຍສິບຄັ້ງອາດເກີດຂຶ້ນໄດ້ໃນໜຶ່ງ Task. ຖ້າຫາກເກັບຮັກສາຜົນລັອກຂອງ Tool ທັງໝົດໄວ້ໂດຍກົງ, Context ຈະເຕັມຢ່າງວ່ອງໄວ, ດັ່ງນັ້ນ ການສະຫຼຸບຜົນລັອກຂອງ Tool ຈຶ່ງເປັນສິ່ງທີ່ຈຳເປັນຢ່າງຍິ່ງ.

Structured note-taking (Scratchpad) ທີ່ Anthropic ແນະນຳ ແມ່ນຮູບແບບທີ່ໃຫ້ Agent ຂຽນບັນທຶກລົງໃນ External Store ແລະໃນ Turn ຕໍ່ໄປກໍພຽງແຕ່ອ້າງອີງເຖິງບັນທຶກນັ້ນເພື່ອສ້າງລາຍລະອຽດຄືນໃໝ່. ວິທີນີ້ເຮັດໃຫ້ສາມາດສ້າງໂຄງສ້າງທີ່ຊ່ວຍໃຫ້ຂໍ້ມູນດິບຈາກຜົນລັອກຂອງ Tool ຖືກຍົກອອກຈາກ Context ໂດຍທີ່ຂໍ້ມູນທີ່ຈຳເປັນຕໍ່ການຕັດສິນໃຈຍັງຄົງຢູ່.

ສຳລັບການຮອງຮັບ Long Task, ການອອກແບບໃຫ້ມີເປົ້າໝາຍ, ເງື່ອນໄຂການສຳເລັດ ແລະ Task ທີ່ຍັງເຫຼືອຂອງທັງໝົດເປັນ "ແຜນການ" (Plan) ຢ່າງຊັດເຈນ ແລະ ໃສ່ຂໍ້ມູນນີ້ເຂົ້າໄປໃນຕອນຕົ້ນຂອງທຸກ Turn ກໍມີປະສິດທິຜົນເຊັ່ນກັນ. ວິທີນີ້ຈະຊ່ວຍປ້ອງກັນບໍ່ໃຫ້ Model ລືມສະຖານະປັດຈຸບັນຂອງຕົນເອງ ແລະ ຊ່ວຍຄວບຄຸມບໍ່ໃຫ້ທິດທາງການເຮັດວຽກຜິດພ້ຽນໃນລະຫວ່າງທາງ. ບົດຄວາມທີ່ກ່ຽວຂ້ອງ "AI Agent ຈະນຳໄປໃຊ້ງານຈິງໄດ້ແນວໃດ? ຂັ້ນຕອນການປະຕິບັດຈາກ Pilot ສູ່ການຜະລິດຈຳນວນຫຼາຍ" ກໍໄດ້ແນະນຳວິທີການທີ່ຄ້າຍຄືກັນນີ້ໄວ້ເຊັ່ນກັນ.

ເພື່ອເປັນມາດຕະການປ້ອງກັນບໍ່ໃຫ້ເກີດຄວາມບວມ (肥大化), ກ່ອນອື່ນໝົດແມ່ນໃຫ້ຈັດສັນງົບປະມານ Token ໃຫ້ແກ່ແຕ່ລະອົງປະກອບຂອງ Context. ຕົວຢ່າງເຊັ່ນ: "ລະບົບ 1,500, ວຽກງານ 500, RAG 3,000, ປະຫວັດ 2,000, ການກຳນົດເຄື່ອງມື 1,000" ໂດຍຄິດໄລ່ຍ້ອນກັບຈາກຄ່າລວມ ແລະ ໃສ່ເຫດຜົນ (Logic) ເພື່ອບີບອັດ ຫຼື ລຶບອອກເມື່ອເກີນງົບປະມານ.

ໃນດ້ານການຕິດຕາມກວດກາ, ໃຫ້ບັນທຶກຈຳນວນ Token ຂາເຂົ້າ, Token ຂາອອກ, ຄ່າໃຊ້ຈ່າຍ ແລະ Latency ຂອງແຕ່ລະ Turn ໄວ້ໃນ Log ທັງໝົດ, ພ້ອມທັງເຮັດໃຫ້ແນວໂນ້ມເຫັນພາບໄດ້ຊັດເຈນຜ່ານ Dashboard. ສຳລັບ Log ນັ້ນ, ຄວນອ້າງອີງຈາກມຸມມອງທີ່ໄດ້ແນະນຳໄວ້ໃນບົດຄວາມທີ່ກ່ຽວຂ້ອງ "AI Observability ແມ່ນຫຍັງ? ກົນໄກ ແລະ ຄູ່ມືການປະຕິບັດຕົວຈິງໃນການຕິດຕາມກວດກາ LLM ໃນການນຳໃຊ້ງານຈິງ" ໂດຍການເຮັດໃຫ້ສາມາດກັ່ນຕອງ (Filter) ດ້ວຍ Request ID, Session ID ແລະ Model Version ຈະຊ່ວຍໃຫ້ການກວດສອບໃນພາຍຫຼັງເຮັດໄດ້ໄວຂຶ້ນ.

ນອກຈາກນີ້, ການໝັ່ນກວດສອບຄືນເປັນໄລຍະວ່າຂໍ້ມູນດຽວກັນມີການຂຽນຊ້ຳກັນທັງໃນຄຳສັ່ງລະບົບ (System Instruction) ແລະ ປະຫວັດ (History) ຫຼືບໍ່, ຈະເຮັດໃຫ້ພົບເຫັນ Token ສ່ວນເກີນຫຼາຍກວ່າທີ່ຄິດ. ຕາມກົດເກນປະສົບການແລ້ວ, Context ປະມານ 2 ສ່ວນ 10 ມັກຈະເປັນ "ສິ່ງທີ່ຍັງຄົງຄ້າງມາຈາກປະຫວັດຄວາມເປັນມາ ແຕ່ໃນຄວາມເປັນຈິງແລ້ວແມ່ນບໍ່ຈຳເປັນ".

Context Engineering ບໍ່ແມ່ນການອອກແບບພຽງຄັ້ງດຽວແລ້ວຈົບ. ມັນຈຳເປັນຕ້ອງໄດ້ດຳເນີນການເປັນຂະບວນການໃນການວັດແທກຄຸນນະພາບຂອງຜົນລວມການອະນຸມານ (Inference) ຢ່າງຕໍ່ເນື່ອງ ແລະ ປັບປຸງໂຄງສ້າງ Context ໃຫ້ດີຂຶ້ນຊ້ຳໆ.

ການວັດແທກຄວາມຖືກຕ້ອງຂອງບໍລິບົດ (Context) ໄດ້ຖືກອອກແບບມາເປັນ 3 ຊັ້ນຫຼັກ. ຊັ້ນທີໜຶ່ງຄື ຊັ້ນການຄົ້ນຫາ (Retrieval Layer), ເຊິ່ງຈະປະເມີນວ່າ RAG ສາມາດດຶງເອົາເອກະສານທີ່ຖືກຕ້ອງຂຶ້ນມາໄວ້ໃນອັນດັບຕົ້ນໆໄດ້ຫຼືບໍ່ ໂດຍໃຊ້ Recall@K ແລະ MRR. ຊັ້ນທີສອງຄື ຊັ້ນການນຳໃຊ້ (Utilization Layer), ເຊິ່ງຈະວັດແທກອັດຕາສ່ວນຂອງເອກະສານທີ່ຖືກດຶງມາໃຊ້ໃນຜົນລວມຕົວຈິງ (Attribution). ຊັ້ນທີສາມຄື ຊັ້ນຜົນລວມ (Output Layer), ເຊິ່ງຈະກວດສອບຄວາມຖືກຕ້ອງຂອງຄຳຕອບສຸດທ້າຍໂດຍໃຊ້ LLM-as-a-Judge ຫຼື ການປະເມີນໂດຍມະນຸດ.

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

ລາຍລະອຽດຂອງວິທີການປະເມີນຜົນໄດ້ກ່າວໄວ້ໃນບົດຄວາມທີ່ກ່ຽວຂ້ອງຫົວຂໍ້ "LLM-as-a-Judge ແມ່ນຫຍັງ? ວິທີການປະເມີນຜົນລວມຂອງ AI ດ້ວຍ AI ແລະ ການຈັດຕັ້ງປະຕິບັດການກວດຈັບ Hallucination". ໃນການໝູນວຽນຮອບວຽນການປັບປຸງ Context Engineering, ການກຽມພື້ນຖານການປະເມີນຜົນໄວ້ລ່ວງໜ້າຖືເປັນການລົງທຶນທີ່ມີຄຸນຄ່າຢ່າງຍິ່ງ.

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

ໃນການປ່ອຍຟີເຈີແບບເປັນໄລຍະ (Staged rollout), ກ່ອນອື່ນຕ້ອງກວດສອບການຖົດຖອຍ (Regression) ດ້ວຍຊຸດຂໍ້ມູນປະເມີນຜົນພາຍໃນ (Golden Query ປະມານ 100-500 ລາຍການ), ຈາກນັ້ນຈຶ່ງເປີດຕົວ ຫຼື Launch ໃຫ້ຜູ້ໃຊ້ພຽງ 5-10% ຂອງທຣາຟິກເພື່ອສັງເກດຕົວຊີ້ວັດການໃຊ້ງານຈິງ. ຖ້າບໍ່ພົບຂໍ້ຜິດພາດ ຫຼື ຄ່າໃຊ້ຈ່າຍທີ່ເພີ່ມຂຶ້ນ ກໍໃຫ້ຂະຫຍາຍຂອບເຂດອອກໄປເທື່ອລະຂັ້ນ. ຖ້າຂ້າມຂັ້ນຕອນນີ້ໄປ, ມັກຈະເກີດເຫດການທີ່ວ່າໃນຊຸດຂໍ້ມູນປະເມີນຜົນເຫັນວ່າດີຂຶ້ນ ແຕ່ໃນການໃຊ້ງານຈິງກັບແຍ່ລົງ.

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

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

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

Attention ຂອງ LLM ບໍ່ໄດ້ມີຂີດຈຳກັດທີ່ບໍ່ສິ້ນສຸດ ແລະໃນ Context ທີ່ຍາວນານ ຍັງມີປະກົດການ "lost in the middle" ເຊິ່ງຂໍ້ມູນທີ່ວາງໄວ້ໃນສ່ວນກາງມັກຈະຖືກລະເລີຍ. ເມື່ອປະລິມານຂໍ້ມູນເກີນຂີດຈຳກັດ, ຄຸນນະພາບຂອງຜົນລັພຈະຫຼຸດລົງ. ກໍລະນີການຫຼຸດຈຳນວນເຄື່ອງມືຂອງ Vercel (ຈາກ 15 ເຫຼືອ 2) ແລ້ວຄວາມແມ່ນຍຳເພີ່ມຂຶ້ນຈາກ 80 ເປັນ 100% ນັ້ນ ສາມາດອ່ານໄດ້ວ່າເປັນຕົວຢ່າງການແກ້ໄຂບັນຫານີ້ຢ່າງຊັດເຈນ.

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

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

ການເຮັດໃຫ້ຕົ້ນທຶນເຫັນພາບໄດ້ຊັດເຈນນັ້ນ ພຽງແຕ່ເບິ່ງ "ຍອດເກັບເງິນ API ລາຍເດືອນ" ຢ່າງດຽວຍັງບໍ່ພຽງພໍ. ຈຳເປັນຕ້ອງແຍກລາຍລະອຽດອອກເປັນລາຍ Session, ລາຍຜູ້ໃຊ້, ແລະ ລາຍ Endpoint ພ້ອມທັງກຳນົດເປົ້າໝາຍວ່າ "1 Task ຄວນໃຊ້ຈັກ Token". ການນຳເອົາຫຼັກການທີ່ໄດ້ແນະນຳໄວ້ໃນບົດຄວາມທີ່ກ່ຽວຂ້ອງ "ຄູ່ມືການປັບປຸງຕົ້ນທຶນ LLM — ການຫຼຸດຈຳນວນ Token, ການເລືອກ Model, ແລະ ການນຳໃຊ້ Cache" ມາປະຍຸກໃຊ້ຕັ້ງແຕ່ຊັ້ນການອອກແບບ Context ຈະສາມາດປ້ອງກັນບໍ່ໃຫ້ຕົ້ນທຶນບານປາຍໄດ້.

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

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