Context Engineering คืออะไร? ต่างจาก Prompt Engineering ยังไง

Context Engineering คืออะไร? ถ้าอธิบายแบบง่ายที่สุด คือการออกแบบว่า AI ควรได้รับข้อมูลอะไร ในลำดับไหน ภายใต้กติกาใด และต้องส่งผลลัพธ์กลับมาในรูปแบบใด เพื่อให้ทำงานหนึ่งอย่างได้สม่ำเสมอ ไม่ใช่แค่เขียนคำสั่งให้สวยขึ้น

คำนี้ยังไม่ได้มีนิยามเดียวที่ทุกบริษัทใช้เหมือนกัน บทความนี้จึงใช้เป็นกรอบคิดเชิงปฏิบัติ: Prompt คือคำสั่ง ส่วน Context คือสภาพแวดล้อมของงานทั้งหมดที่ทำให้คำสั่งนั้นมีความหมาย

Prompt Engineering กับ Context Engineering ต่างกันอย่างไร

• Prompt Engineering: ออกแบบคำสั่ง บทบาท เป้าหมาย โทนภาษา ขั้นตอน และตัวอย่าง
• Context Engineering: ออกแบบทั้งชุดข้อมูลที่ส่งให้โมเดล เช่น คำสั่งระบบ ประวัติ เอกสาร ผลจากเครื่องมือ สิทธิ์ และ schema ของ output
• Workflow: กำหนดว่าเมื่อไรจะดึงข้อมูล เมื่อไรให้ AI วิเคราะห์ และเมื่อไรต้องให้คนตรวจ

ตัวอย่างเช่น Prompt อาจบอกว่า “สรุปเอกสารนี้ให้ผู้บริหาร” แต่ Context Engineering ต้องตัดสินใจว่าเอกสารฉบับใดล่าสุด ข้อมูลใดเป็นความลับ ต้องอ้างหน้าที่เท่าไร และผลลัพธ์ต้องเป็นตารางหรือย่อหน้า

Context stack มีอะไรบ้าง

1. Instruction: เป้าหมาย บทบาท และข้อห้าม
2. Task context: คำถาม ลูกค้า ไฟล์ หรือ event ของรอบนี้
3. Reference context: เอกสาร ลิงก์ และข้อมูลที่ผ่านการคัดเลือก
4. Conversation state: ประวัติที่จำเป็น ไม่ใช่แชตเก่าทั้งหมด
5. Tools and permissions: เครื่องมือที่เรียกได้และขอบเขตการอ่าน/เขียน
6. Output contract: field รูปแบบ และเงื่อนไขให้หยุดเมื่อหลักฐานไม่พอ

การแยกชั้นช่วยให้แก้ปัญหาได้ถูกจุด ถ้าคำตอบผิดเพราะเอกสารเก่า ก็แก้ retrieval ไม่ใช่เพิ่มคำสั่งยาว ๆ

ตัวอย่าง: ให้ AI ตอบคำถามจากคู่มือบริษัท

ก่อนส่งคำถามเรื่องวันลาเข้าโมเดล workflow ควรระบุประเทศและประเภทพนักงาน ค้นเฉพาะคู่มือฉบับที่ยังมีผล แนบชื่อไฟล์ วันที่ และเลขหน้า แล้วกำหนดให้ AI บอกว่า “ไม่พบหลักฐาน” เมื่อข้อมูลไม่พอ ผลลัพธ์ควรมีคำตอบสั้น แหล่งอ้างอิง และ flag ให้ HR ตรวจกรณีมีข้อยกเว้น

คุณภาพจึงมาจาก context ที่ถูกเลือก สด และตรวจสอบย้อนกลับได้ ไม่ใช่จาก prompt ที่ยาวที่สุด

บริบทเยอะขึ้นไม่ได้แปลว่าดีขึ้นเสมอ

การส่งเอกสารทั้งหมดอาจเพิ่มต้นทุนและทำให้ข้อมูลสำคัญถูกกลบ Google อธิบายว่าผลลัพธ์จาก long context ขึ้นกับงานและตำแหน่งข้อมูล จึงควรส่งเฉพาะส่วนที่จำเป็นและตั้งคำถามให้ชัด

ถ้าต้องใช้ข้อมูลชุดเดิมซ้ำ ๆ อาจใช้ context caching ตามความสามารถของ API นั้น ๆ แต่ต้องตรวจ model, token ขั้นต่ำ, TTL, ราคา และนโยบายข้อมูลก่อน การ cache ไม่ได้ทำให้ข้อมูลเก่าถูกต้องขึ้น

ออกแบบ Context Engineering ใน 6 ขั้นตอน

1. กำหนดงาน: ระบุผู้ใช้ ผลลัพธ์ และความผิดพลาดที่รับไม่ได้
2. ทำ source of truth: ระบุเจ้าของข้อมูล วันที่มีผล และวิธีถอนฉบับเก่า
3. ออกแบบ retrieval: เลือกหลักฐานที่เกี่ยวข้องพร้อม citation และ metadata
4. กำหนด contract: บังคับ field ภาษา หน่วย และทางเลือก “ข้อมูลไม่พอ”
5. จำกัดสิทธิ์: แยกอ่าน/เขียนและหยุดก่อนส่ง ลบ แก้ หรือเผยแพร่
6. ทดสอบ: วัด citation accuracy, เวลาแก้คำตอบ, cost และ fallback rate

ข้อผิดพลาดที่พบบ่อย

• ยัดข้อมูลทุกอย่างเข้า prompt โดยไม่จัดลำดับ
• ใช้ประวัติที่หมดอายุหรือขัดกับเอกสารล่าสุด
• ไม่แยกหลักฐานออกจากตัวอย่าง
• ให้เครื่องมือมีสิทธิ์กว้างเกินจำเป็น
• บังคับให้ตอบเสมอแทนที่จะอนุญาต “ไม่พบข้อมูล”
• วัดแค่ความเร็วแต่ไม่วัดเวลาที่คนต้องแก้

FAQ

ต้องใช้ฐานข้อมูลหรือ RAG ไหม

ไม่เสมอไป งานเล็กอาจใช้ข้อความที่คัดด้วยมือ แต่ข้อมูลจำนวนมากหรือเปลี่ยนบ่อยควรมี retrieval, citation และ version control

Context Engineering แทน Prompt Engineering ไหม

ไม่ใช่ Prompt เป็นหนึ่งชั้นของ context stack การออกแบบที่ดีต้องดูข้อมูล เครื่องมือ สิทธิ์ และ review ประกอบ

ส่ง context ยาวที่สุดได้ไหม

ควรทดสอบกับข้อมูลจริงและเทียบคุณภาพ ต้นทุน latency และเวลาแก้ไขก่อนตัดสินใจ

สรุป

Context Engineering คือการออกแบบสภาพแวดล้อมทั้งหมดที่ AI ใช้ตัดสินใจ ตั้งแต่คำสั่ง แหล่งข้อมูล ประวัติ เครื่องมือ สิทธิ์ ไปจนถึงรูปแบบผลลัพธ์ เริ่มจากงานเล็กที่มี source of truth ชัด บังคับหลักฐานและ fallback แล้วค่อยขยาย