Context Engineering คืออะไร? กระบวนทัศน์ใหม่ของการพัฒนา LLM และวิวัฒนาการจาก Prompt Engineering

Context Engineering คือวิธีการออกแบบเพื่อปรับแต่งกลุ่มโทเค็น (System Prompt, คำสั่ง, ความรู้, ประวัติการสนทนา, และคำจำกัดความของเครื่องมือ) ที่ถูกป้อนเข้าสู่ LLM ในขณะประมวลผล โดยเป็นแนวคิดที่เหนือกว่า "Prompt Engineering" ซึ่งเน้นเพียงการขัดเกลาข้อความใน Prompt เท่านั้น Anthropic ได้เริ่มนำเสนอแนวคิดนี้ตั้งแต่ช่วงกลางปี 2025 และได้รับการยอมรับให้เป็นเทคโนโลยีหลักใน Agents SDK ของ OpenAI รวมถึง Agent สำหรับการใช้งานจริงของ Vercel

บทความนี้จัดทำขึ้นสำหรับทีมพัฒนาแอปพลิเคชัน LLM ในกลุ่ม B2B โดยจะสรุปความแตกต่างจาก Prompt Engineering, องค์ประกอบของ Context Window, รูปแบบการออกแบบ ไปจนถึงข้อควรระวังในการดำเนินงาน เมื่ออ่านจบ คุณจะได้รับมุมมองใหม่ในการปรับเปลี่ยนการพัฒนา RAG หรือ Agent ของบริษัทให้เป็น "ปัญหาการออกแบบบริบทโดยรวม" (Context-wide design problem)

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

เป็นที่ยอมรับกันอย่างกว้างขวางในการใช้งานจริงแล้วว่า คุณภาพของแอปพลิเคชัน LLM นั้นขึ้นอยู่กับ "ว่าจะใส่ข้อมูลอะไร ลำดับอย่างไร และปริมาณเท่าใดลงใน Context Window" มากกว่าวิธีการเขียน Prompt โดยบล็อกด้านวิศวกรรมของ Anthropic ได้นิยาม Context ว่าเป็น "ชุดของโทเค็นที่ถูกสุ่มตัวอย่างในขณะประมวลผล" และจัดให้ความมีประโยชน์ของมันเป็นปัญหาทางวิศวกรรมที่ต้องปรับให้เหมาะสมในฐานะทรัพยากรที่มีจำกัด (ที่มา: 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 จึงไม่สามารถควบคุมคุณภาพของบริบทที่สะสมอยู่ได้

ตัวอย่างเช่น บล็อกด้านวิศวกรรมของ Vercel ได้รายงานว่า หลังจากลดจำนวนเครื่องมือของ Agent ลงจาก 15 เหลือ 2 ตัว ผลการทดสอบด้วย Benchmark จำนวน 5 คำถาม พบว่าความแม่นยำเพิ่มขึ้นจาก 80% เป็น 100%, ปริมาณโทเค็นลดลง 37% และความเร็วในการตอบสนองดีขึ้นถึง 3.5 เท่า ซึ่งผลลัพธ์นี้ไม่ได้เกิดจากการเขียน Prompt ใหม่ แต่เกิดจากการคัดกรองข้อมูลที่ใส่ลงไปในบริบท (Context) นั่นเอง

บริบทที่ทำให้ Context Engineering ได้รับความสนใจอย่างรวดเร็วตั้งแต่ช่วงกลางปี 2025 เป็นต้นมา คือการที่สมรภูมิหลักของแอปพลิเคชัน LLM ได้เปลี่ยนจาก "การถาม-ตอบแบบครั้งเดียว" ไปสู่ "เอเจนต์อิสระแบบหลายเทิร์น (Multi-turn autonomous agents)"

ในลูปการอนุมาน (Inference loop) เอเจนต์จะทำการสะสมผลลัพธ์การค้นหา ผลลัพธ์การรันเครื่องมือ และการอนุมานขั้นกลางลงในบริบทอย่างต่อเนื่อง Anthropic ได้จัดระเบียบเรื่องนี้ว่าเป็น "ปัญหาการจัดการทรัพยากรที่มีจำกัด" และจำแนกโหมดความล้มเหลวออกเป็น 3 ประเภท ได้แก่ ประการแรก คืออาการหลอน (Hallucination) ที่เกิดจากการขาดข้อมูล ประการที่สอง คือภาวะบริบทล้น (Context overflow) ที่เกิดจากข้อมูลมากเกินไป และประการที่สาม คือความเกี่ยวข้องที่ลดลงเนื่องจากการจัดวางข้อมูลที่ไม่เหมาะสม

การจัดระเบียบนี้แสดงให้เห็นถึงขีดจำกัดของแนวคิดเดิมที่ว่า "แค่ปรับแต่ง Prompt ก็เอาอยู่" หากไม่มีการออกแบบรูปแบบของบริบทโดยตรง เอเจนต์ที่ทำงานต่อเนื่องเป็นเวลานานย่อมมีประสิทธิภาพเสื่อมถอยลงในไม่ช้า

องค์ประกอบที่สามารถใส่ลงใน Context Window แบ่งออกได้เป็น 6 ประเภทหลัก เนื่องจากแต่ละประเภทส่งผลต่อการตัดสินใจของ LLM แตกต่างกัน การออกแบบโดยคำนึงถึงบทบาทของแต่ละองค์ประกอบจึงเป็นสิ่งที่ขาดไม่ได้

การไม่เหมารวมทุกอย่างว่าเป็นเพียง "Prompt" แต่แยกแยะองค์ประกอบออกมาจัดการ คือก้าวแรกของการออกแบบ Context ในการออกแบบ AI Agent ภายในบริษัทของเรา เรามักจะเริ่มต้นด้วยเวิร์กชอปเพื่อแยกแยะ Context ออกเป็น 6 องค์ประกอบนี้เสมอ

System Prompt คือข้อความพื้นฐานที่ใช้สั่งการ LLM เกี่ยวกับบทบาท ข้อจำกัด และรูปแบบของผลลัพธ์ โดยปกติแล้วจะถูกใช้แบบคงที่ในทุกเทิร์นและเป็นรากฐานของบริบท ทั้งนี้ควรระมัดระวังหาก System Prompt ยาวเกินไป (เช่น เกิน 3,000 โทเค็น) เพราะจะไปเบียดบังพื้นที่ขององค์ประกอบแบบไดนามิกที่จะเพิ่มเข้ามาในภายหลัง

Task Instruction คือคำขอที่เฉพาะเจาะจงซึ่งได้รับจากผู้ใช้ในแต่ละเทิร์น ในขณะที่ System Prompt กำหนดว่า "ต้องทำตัวอย่างไร" Task Instruction จะเป็นตัวกำหนดว่า "ต้องการให้ทำอะไรในครั้งนี้"

Few-shot Example คือคู่ของอินพุตและเอาต์พุตที่ใส่เข้ามาเพื่อแสดงตัวอย่างของรูปแบบผลลัพธ์หรือกระบวนการคิด การมีตัวอย่างมากเกินไปไม่ใช่เรื่องดีเสมอไป โดยทั่วไปแล้วควรคัดเลือกให้เหลือเพียง 2-5 ตัวอย่างที่ครอบคลุมรูปแบบที่หลากหลาย ยิ่งงานใดที่มีความกังวลเรื่องความไม่สม่ำเสมอของผลลัพธ์ การออกแบบ Few-shot ก็จะยิ่งส่งผลดีมากขึ้นเท่านั้น

ความรู้ภายนอกที่แทรกผ่าน RAG หมายถึงเอกสารที่เกี่ยวข้องซึ่งได้มาจากการค้นหาแบบเวกเตอร์ (Vector Search) หรือการค้นหาแบบเต็มรูปแบบ (Full-text Search) หากจำนวนเอกสารมากเกินไปจะทำให้ความเกี่ยวข้องลดลง และหากน้อยเกินไปจะทำให้ข้อมูลไม่เพียงพอจนเกิดอาการประสาทหลอน (Hallucination) เพิ่มขึ้น สำหรับการปรับปรุงความแม่นยำด้วยการค้นหาแบบไฮบริด (Hybrid Search) สามารถดูเพิ่มเติมได้ที่บทความที่เกี่ยวข้องเรื่อง "Hybrid Search คืออะไร? กลไกและวิธีการนำไปใช้เพื่อเพิ่มความแม่นยำของ RAG ด้วยการรวม Vector Search และ Full-text Search"

การกำหนดเครื่องมือ (Tool Definition) คือข้อกำหนดของฟังก์ชัน (ชื่อ, อาร์กิวเมนต์, คำอธิบาย) ที่เอเจนต์สามารถเรียกใช้ได้ ดังที่กรณีศึกษาของ Vercel แสดงให้เห็นว่า เพียงแค่ใส่เครื่องมือที่ไม่จำเป็นเข้าไปก็ทำให้ความแม่นยำลดลงอย่างเห็นได้ชัด หลักการสำคัญคือการจำกัดจำนวนเครื่องมือให้เหลือเพียง "สิ่งที่ต้องใช้จริงในงานนั้นๆ" ไม่ใช่ "มีไว้ก็สะดวกดี"

ประวัติการสนทนาและหน่วยความจำระยะยาว (Dialogue History / Long-term Memory) คือองค์ประกอบที่เก็บคำพูดของผู้ใช้ การตอบกลับของโมเดล และผลลัพธ์จากเครื่องมือในแต่ละเทิร์นตามลำดับเวลา สำหรับงานระยะยาว พื้นที่ส่วนนี้จะขยายตัวอย่างรวดเร็วที่สุด ดังนั้นกลยุทธ์การบีบอัดข้อมูลที่จะกล่าวถึงต่อไปจึงเป็นสิ่งที่จำเป็นอย่างยิ่ง

ในการใช้งานจริง เราจำเป็นต้องเปลี่ยนแนวคิดจากการจัดการบริบทให้เป็น "Prompt ขนาดใหญ่" แบบคงที่ มาเป็นการประกอบองค์ประกอบที่จำเป็นสำหรับแต่ละงานแบบไดนามิก ในส่วนนี้จะสรุปรูปแบบการออกแบบ 3 รูปแบบที่ใช้กันบ่อยในหน้างานจริง

รูปแบบพื้นฐานที่สุดคือ Dynamic Slot Method ซึ่งเป็นการกำหนดสล็อต (ช่องว่าง) ไว้ในเทมเพลต แล้วเติมองค์ประกอบที่จำเป็นในแต่ละเทิร์นก่อนส่งออกไป สล็อตจะถูกแบ่งออกเป็นส่วนต่างๆ เช่น "คำสั่งระบบ (System Instructions)", "คำจำกัดความของงาน (Task Definition)", "เอกสารที่เกี่ยวข้อง (Related Documents)", "คำจำกัดความของเครื่องมือ (Tool Definition)", "ประวัติล่าสุด (Recent History)" และ "คำพูดของผู้ใช้ (User Utterance)" โดยเนื้อหาที่จะใส่ในแต่ละสล็อตจะถูกสร้างขึ้นด้วยตรรกะที่แยกจากกัน

ข้อดีของวิธีนี้คือช่วยให้แยกแยะได้ง่ายว่าองค์ประกอบใดที่มีผลต่อคุณภาพ ตัวอย่างเช่น หากทำ A/B Testing เฉพาะสล็อตเอกสารที่เกี่ยวข้อง ก็จะสามารถวัดผลการปรับปรุงกลยุทธ์การค้นหาได้อย่างอิสระ ในทางกลับกัน หากละเลยการแยกสล็อตและใช้วิธีประกอบสตริง Prompt ขนาดใหญ่โดยตรง จะทำให้การระบุสาเหตุของความผิดพลาดในภายหลังทำได้ยากมาก

เมื่อบริษัทของเราออกแบบเอเจนต์สำหรับตอบคำถามภายในองค์กร ช่วงแรกเราใช้งานโดยใช้ Prompt Template แบบเดี่ยว แต่ก็ประสบปัญหาที่การจัดการประวัติและการจัดการผลลัพธ์การค้นหาพันกันจนไม่สามารถแยกแยะปัญหาได้ หลังจากเปลี่ยนมาใช้วิธีแบ่งสล็อต เราจึงสามารถหารือเรื่องการปรับปรุงเลเยอร์การค้นหาและกลยุทธ์การจัดการประวัติไปพร้อมๆ กันได้

ในกรณีที่มีจำนวนเอกสารหรือประวัติการสนทนาที่ดึงข้อมูลมาได้จาก RAG เป็นจำนวนมาก ไม่ควรใส่ข้อมูลทั้งหมดลงไป แต่ให้จัดลำดับความสำคัญตามคะแนนความเกี่ยวข้อง (Relevance Score) ก่อนนำเข้าสู่บริบท (Context) โดยทั่วไปมักใช้วิธีผสมผสานระหว่าง Vector Similarity, BM25 และ Reranker model (เช่น Cohere Rerank) เพื่อคัดเลือกเฉพาะ N รายการที่มีคะแนนสูงสุดไว้

ข้อผิดพลาดที่มักพบในการออกแบบระบบควบคุมลำดับความสำคัญคือ การตัดข้อมูลด้วยเกณฑ์คะแนน (Threshold) แบบตายตัว หากข้อมูลที่อยู่คาบเกี่ยวกันบนเกณฑ์นั้นมีความสัมพันธ์กันในเชิงบริบทที่ไม่สามารถแยกออกจากกันได้ (เช่น ข้อสัญญาและส่วนขยายในสัญญาฉบับเดียวกัน) การตัดข้อมูลออกจะทำให้ความสอดคล้องของผลลัพธ์เสียหาย ในทางปฏิบัติจึงมักเลือกใช้ตรรกะการคัดเลือกแบบไฮบริดที่ว่า "N รายการที่มีคะแนนสูงสุด + ส่วนที่เกี่ยวข้องภายในเอกสารเดียวกัน"

สำหรับงานที่การประเมินความเกี่ยวข้องทำได้ยาก การเพิ่มคู่ข้อมูลที่ถูกต้อง (Correct pairs) ของโดเมนบริษัทตนเองลงในข้อมูลสำหรับฝึกสอน (Training data) ของ Reranker จะให้ผลลัพธ์ที่มีประสิทธิภาพสูง ซึ่งเป็นประเด็นสำคัญที่ถูกหยิบยกมาเป็นวิธีหลีกเลี่ยงปัญหาในบทความเรื่อง "10 รูปแบบความล้มเหลวในการสร้าง RAG และวิธีแก้ไข" ด้วยเช่นกัน

สำหรับเอเจนต์ที่ทำงานเป็นระยะเวลานาน ประวัติการสนทนาจะสะสมเพิ่มขึ้นเป็นหลักหมื่นโทเค็น จึงจำเป็นต้องมีการทำ Context Compression (การบีบอัดบริบท) ภายใต้เงื่อนไขที่กำหนด โดยวิธี "compaction" ที่ Anthropic นำเสนอ คือการให้โมเดลสรุปประวัติการสนทนาเก่าด้วยตัวเอง แล้วแทนที่ด้วยข้อความสรุปนั้น

อีกรูปแบบหนึ่งที่สำคัญคือ Memory Separation (การแยกหน่วยความจำ) โดยการแยกประวัติการสนทนาระยะสั้นออกจากข้อมูลความชอบของผู้ใช้หรือข้อมูลโปรเจกต์ที่ต้องเก็บรักษาไว้อย่างถาวรไว้ในที่จัดเก็บข้อมูลคนละส่วนกัน และเลือกแทรกข้อมูลเข้าสู่บริบทตามความจำเป็น ซึ่ง Session Memory ที่ OpenAI Agents SDK จัดเตรียมไว้นั้น ถือเป็นความพยายามในการสร้างมาตรฐานสำหรับการแยกส่วนนี้ โดยรองรับทั้งวิธี trimming (การเก็บไว้เฉพาะ N รายการล่าสุด) และวิธี summarization (การแทนที่ประวัติเก่าด้วยบทสรุป)

ช่วงเวลาในการบีบอัดข้อมูลนั้นขึ้นอยู่กับเงื่อนไขการใช้งาน เช่น "เมื่ออินพุตโทเค็นเกินเกณฑ์ที่กำหนด" หรือ "เมื่อผ่านไปได้จำนวนเทิร์นที่กำหนดภายในงานเดียวกัน" หากบีบอัดช้าเกินไปอาจทำให้เกิดปัญหา Overflow จนระบบล่ม แต่หากบีบอัดเร็วเกินไป อาจทำให้สูญเสียรายละเอียดเล็กๆ น้อยๆ ในบริบทไปได้

ความท้าทายด้านบริบทเฉพาะของเอเจนต์คือประวัติการสนทนาที่ขยายตัวแบบทวีคูณเมื่อผ่านไปหลายรอบ (multi-turn) ในที่นี้จะขอสรุปแนวทางการออกแบบโดยพิจารณาทั้งในด้านงานระยะยาวและการป้องกันข้อมูลบวมโต

ใน Coding Agent หรือ Autonomous Research Agent อาจเกิดการเรียกใช้เครื่องมือ (Tool call) มากกว่าหลายสิบครั้งในหนึ่งงาน หากเก็บผลลัพธ์จากเครื่องมือทั้งหมดไว้โดยตรง จะทำให้บริบท (Context) เต็มอย่างรวดเร็ว ดังนั้น การสรุปผลลัพธ์จากเครื่องมือ จึงเป็นสิ่งที่จำเป็นอย่างยิ่ง

Structured note-taking (Scratchpad) ที่ Anthropic แนะนำ คือรูปแบบที่ให้ Agent เขียนบันทึกลงในที่จัดเก็บข้อมูลภายนอก และในรอบถัดไป Agent จะสามารถสร้างรายละเอียดขึ้นมาใหม่ได้เพียงแค่อ้างอิงจากบันทึกนั้น วิธีนี้ช่วยให้สามารถนำข้อมูลดิบจากผลลัพธ์ของเครื่องมือออกจากบริบทได้ โดยที่ยังคงรักษาข้อมูลที่จำเป็นต่อการตัดสินใจไว้ได้

สำหรับการรองรับงานระยะยาว (Long-task) การออกแบบโดยให้มี "แผนงาน" (Plan) ที่ระบุเป้าหมาย เงื่อนไขความสำเร็จ และงานที่เหลืออยู่ของทั้งโปรเจกต์ไว้อย่างชัดเจน และแทรกข้อมูลนี้ไว้ที่ส่วนต้นของทุกรอบการทำงาน ก็เป็นวิธีที่มีประสิทธิภาพเช่นกัน ซึ่งจะช่วยป้องกันไม่ให้โมเดลสูญเสียจุดยืนของตัวเองและช่วยลดการเปลี่ยนทิศทางระหว่างทำงานได้ คุณสามารถดูแนวทางที่คล้ายกันได้ในบทความที่เกี่ยวข้องเรื่อง "AI เอเจนท์กับการใช้งานจริง: ขั้นตอนปฏิบัติจากระดับนำร่องสู่การผลิตจำนวนมาก"

เพื่อป้องกันปัญหาการขยายตัวของข้อมูล (Bloat) ขั้นตอนแรกคือการจัดสรรงบประมาณ Token ให้กับองค์ประกอบแต่ละส่วนของ Context ตัวอย่างเช่น การคำนวณย้อนกลับจากค่ารวม เช่น "System 1,500, Task 500, RAG 3,000, History 2,000, Tool Definition 1,000" และใส่ตรรกะสำหรับการบีบอัดหรือลบข้อมูลเมื่อเกินงบประมาณที่กำหนดไว้

ในด้านการตรวจสอบ (Monitoring) ให้บันทึกจำนวน Input Token, Output Token, ค่าใช้จ่าย และ Latency ในแต่ละเทิร์นลงใน Log ทั้งหมด และแสดงผลแนวโน้มผ่าน Dashboard โดยอ้างอิงมุมมองจากบทความที่เกี่ยวข้องเรื่อง "AI Observability คืออะไร? กลไกและคู่มือปฏิบัติสำหรับการตรวจสอบ LLM ในการใช้งานจริง" หากจัดเก็บ Log โดยให้สามารถกรองข้อมูลด้วย Request ID, Session ID และ Model Version ได้ จะช่วยให้การตรวจสอบในภายหลังทำได้รวดเร็วยิ่งขึ้น

นอกจากนี้ การหมั่นตรวจสอบ (Audit) เป็นระยะว่ามีการระบุข้อมูลซ้ำซ้อนทั้งใน System Instruction และ History หรือไม่ จะช่วยให้พบ Token ส่วนเกินได้มากกว่าที่คาดไว้ โดยจากประสบการณ์พบว่า 20% ของ Context มักเป็นข้อมูลที่ "หลงเหลือมาจากอดีตแต่จริงๆ แล้วไม่จำเป็น"

Context Engineering ไม่ใช่สิ่งที่ออกแบบครั้งเดียวแล้วจบไป แต่จำเป็นต้องดำเนินการโดยเป็นกระบวนการที่วัดคุณภาพของผลลัพธ์จากการอนุมาน (Inference) อย่างต่อเนื่อง และปรับปรุงโครงสร้างของ Context ซ้ำๆ อย่างสม่ำเสมอ

การวัดความแม่นยำของบริบท (Context Accuracy) จะถูกออกแบบเป็น 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 Configuration) จะต้องผ่านการตรวจสอบด้วย A/B Testing ก่อนนำไปใช้จริงเสมอ โดยทั่วไปสิ่งที่ต้องเปลี่ยนแปลงมักได้แก่ "จำนวนเอกสารที่ดึงมา", "จังหวะเวลาในการสรุปประวัติ" และ "ตรรกะการคัดกรองเครื่องมือ" ซึ่งสิ่งเหล่านี้มักส่งผลกระทบต่อกันได้ง่าย กฎเหล็กจึงคือการเปลี่ยนแปลงทีละจุดเท่านั้น

สำหรับการปล่อยอัปเดตแบบค่อยเป็นค่อยไป (Gradual Release) ให้เริ่มจากการตรวจสอบการถดถอย (Regression) ด้วยชุดประเมินภายใน (Golden Queries ประมาณ 100-500 รายการ) จากนั้นจึงเปิดให้ใช้งานจริงในวงจำกัดที่ 5-10% ของทราฟฟิกเพื่อสังเกตตัวชี้วัดจริง หากไม่พบข้อผิดพลาดหรือค่าใช้จ่ายที่เพิ่มขึ้น จึงค่อยๆ ขยายการใช้งานออกไป หากข้ามขั้นตอนเหล่านี้ไป มักจะเกิดเหตุการณ์ที่ผลการประเมินดูดีขึ้น แต่เมื่อใช้งานจริงกลับแย่ลงอยู่บ่อยครั้ง

จากประสบการณ์การใช้งาน Agent ภายในบริษัทของเรา เมื่อเราปรับเปลี่ยนการคัดกรองคำจำกัดความของเครื่องมือ (Tool Definition) แล้วนำไปใช้กับผู้ใช้ทุกคนโดยตรง พบว่าในภายหลังเกิดปัญหาคุณภาพคำตอบลดลงในบางกรณี (Edge Cases) นับจากนั้นเป็นต้นมา เราจึงยึดถือแนวปฏิบัติที่จะไม่ข้ามขั้นตอนการปล่อยอัปเดตแบบค่อยเป็นค่อยไป แม้ว่าการเปลี่ยนแปลงนั้นจะดูเหมือน "เป็นการปรับปรุงที่ชัดเจน" ก็ตาม

กับดักของ Context Engineering ส่วนใหญ่มักเกิดจากการตัดสินใจที่ว่า "เพิ่มข้อมูลเข้าไปน่าจะดีกว่า" ในส่วนนี้จะขอสรุปรูปแบบความผิดพลาด 2 ประการที่พบได้บ่อยในการทำงานจริง ก่อนจะเข้าสู่บทสรุปในลำดับถัดไป

ความผิดพลาดที่พบบ่อยที่สุดคือรูปแบบการ ยัดเยียดข้อมูลลงไปในบริบท (Context) ให้มากที่สุดเท่าที่จะทำได้ แนวคิดที่ว่า "ถ้าใส่เอกสารที่น่าจะเกี่ยวข้องทั้งหมดลงไป โมเดลน่าจะเลือกใช้ได้อย่างชาญฉลาด" นั้น มักจะส่งผลเสียเกือบทุกกรณี

กลไก Attention ของ LLM นั้นไม่ได้มีขีดจำกัดเป็นอนันต์ และเป็นที่ทราบกันดีว่าในบริบทที่ยาวเกินไป มักเกิดปรากฏการณ์ "lost in the middle" ซึ่งข้อมูลที่อยู่ตรงกลางมักจะถูกมองข้าม เมื่อปริมาณข้อมูลเกินเกณฑ์ที่กำหนด คุณภาพของผลลัพธ์จะยิ่งลดลง กรณีศึกษาของ Vercel ที่ลดจำนวนเครื่องมือลง (จาก 15 เหลือ 2) แล้วความแม่นยำเพิ่มขึ้นจาก 80% เป็น 100% ถือเป็นตัวอย่างที่ชัดเจนของการแก้ไขปัญหานี้

ผลกระทบอีกประการหนึ่งคือค่าความหน่วง (Latency) เนื่องจากเวลาในการประมวลผลจะเพิ่มขึ้นตามจำนวน Token ขาเข้าแบบเส้นตรงหรือมากกว่านั้น การที่บริบทบวมขึ้นจึงส่งผลโดยตรงต่อการลดทอนประสบการณ์ผู้ใช้ (UX) ในมุมมองของผู้ใช้ นี่อาจกลายเป็นสถานการณ์ที่เลวร้ายที่สุดคือ "คำตอบช้าแถมคุณภาพยังแย่อีกด้วย"

โทเคนคอสต์ (Token Cost) ที่มองเห็นได้ยาก ก็เป็นกับดักที่ร้ายแรงเช่นกัน ในโครงสร้างที่เอเจนต์ (Agent) เรียกใช้เครื่องมือภายในหลายครั้งและสะสมประวัติการใช้งานไปเรื่อยๆ การใช้โทเคนต่อผู้ใช้งานหนึ่งคนจะเพิ่มขึ้นแบบทวีคูณตามจำนวนครั้งของการโต้ตอบ ไม่ใช่เรื่องแปลกที่จะพบกรณีที่เพิ่งมาทราบว่า "กรณีการใช้งานนี้ไม่คุ้มทุน" ก็ต่อเมื่อเห็นใบแจ้งหนี้แล้ว

การทำให้ต้นทุนมองเห็นได้ชัดเจนนั้น ไม่เพียงพอแค่การดู "ยอดเรียกเก็บเงิน API รายเดือน" เท่านั้น แต่จำเป็นต้องแจกแจงรายละเอียดตามเซสชัน (Session) ตามผู้ใช้งาน และตามเอนด์พอยต์ (Endpoint) พร้อมทั้งกำหนดเป้าหมายว่า "หนึ่งงานควรใช้โทเคนเท่าใด" การนำหลักการที่แนะนำไว้ในบทความที่เกี่ยวข้องเรื่อง "คู่มือการเพิ่มประสิทธิภาพต้นทุน LLM — การลดโทเคน การเลือกโมเดล และการทำแคช (Cache)" มาประยุกต์ใช้ในระดับการออกแบบบริบท (Context Design) จะช่วยป้องกันไม่ให้ต้นทุนบานปลายได้

บทสรุปของบทความนี้ ขอย้ำว่าหัวใจสำคัญของการทำคอนเท็กซ์เอนจิเนียริ่ง (Context Engineering) คือการออกแบบว่า "จะใส่อะไรเข้าไป" น้อยกว่าการออกแบบว่า "จะไม่ใส่อะไรเข้าไป" ในยุคของพรอมต์เอนจิเนียริ่ง (Prompt Engineering) การขัดเกลาคำสั่งแต่ละชุดอาจเพียงพอแล้ว แต่ในยุคของเอเจนต์ การคัดกรองข้อมูลและการจัดโครงสร้างใหม่แบบไดนามิกคือหัวใจสำคัญของการออกแบบบริบท

สำหรับทีมที่กำลังใช้งานแอปพลิเคชัน LLM ในระดับโปรดักชัน ควรเริ่มวงจรการปรับปรุงจากการแยกองค์ประกอบของคอนเท็กซ์วินโดว์ (Context Window) ออกเป็น 6 ส่วน และวัดระดับการมีส่วนร่วมของแต่ละส่วนดู บริษัทของเราเองก็ได้ใช้วิธีการเดียวกันนี้ในการสนับสนุนลูกค้า B2B ในการนำ LLM ไปใช้งาน และได้เห็นหลายกรณีที่คุณภาพการใช้งานดีขึ้นอย่างเห็นได้ชัดเพียงแค่การรีแฟคเตอร์ (Refactor) การออกแบบบริบทเท่านั้น