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

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

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

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

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

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

การปรับเปลี่ยนมุมมองนี้คือความแตกต่างที่สำคัญระหว่าง Prompt Engineering และ Context Engineering

สรุปความแตกต่างของทั้งสองอย่างได้ดังนี้:

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

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

ทีม LangChain ได้จำแนกกลยุทธ์หลักในการจัดการ Context ไว้ 4 ประการในบล็อกโพสต์ที่เผยแพร่เมื่อเดือนกรกฎาคม 2025 ได้แก่ "Write / Select / Compress / Isolate" ซึ่งถือเป็นเลเยอร์การออกแบบที่แตกต่างจากการปรับแต่ง Prompt อย่างชัดเจน

บริบท (Context) หมายถึงข้อมูลทั้งหมดที่ LLM สามารถอ้างอิงได้ในขณะทำการอนุมาน (Inference) ซึ่งไม่ได้ครอบคลุมเพียงแค่ข้อความที่เขียนใน Prompt เท่านั้น แต่ยังรวมถึงองค์ประกอบในวงกว้างอีกด้วย

องค์ประกอบหลักที่ประกอบกันเป็นบริบทมีดังนี้:

• System Prompt: คำสั่งที่กำหนดภาพรวมของงาน เช่น บทบาทของโมเดล ข้อจำกัด และรูปแบบของผลลัพธ์
• User Input: ข้อความหรือคำถามล่าสุดในการสนทนา
• Conversation History: บันทึกการสนทนาที่ผ่านมา (ยิ่งจำนวน Turn มากขึ้น การใช้ Token ก็จะยิ่งเพิ่มขึ้น)
• External Knowledge: เอกสารที่ดึงข้อมูลผ่าน RAG, ผลลัพธ์การค้นหาจากฐานข้อมูล และการตอบกลับจาก API
• Tool Definitions & Execution Results: สคีมาของฟังก์ชันและผลลัพธ์การเรียกใช้งานในการกำหนดค่า Agent
• Structured Notes: สถานะกลางหรือบทสรุปที่สะสมไว้ในงานระยะยาว (วิธีที่ Anthropic เรียกว่า "structured note-taking")

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

สิ่งสำคัญคือองค์ประกอบทั้งหมดนี้ใช้ทรัพยากรที่มีจำกัดร่วมกันที่เรียกว่า Token Window ตามข้อมูลอย่างเป็นทางการของ Google Cloud ปัจจุบันโมเดลรุ่นใหม่ๆ สามารถรองรับ Window ได้ตั้งแต่ 1 ล้านถึง 2 ล้าน Token แต่ก็ไม่ใช่จำนวนที่ไม่จำกัด

「การขัดเกลา Prompt เท่าไหร่ก็ยังไม่สามารถเพิ่มความแม่นยำได้」— เชื่อว่านักพัฒนาหลายคนคงเคยประสบกับประสบการณ์เช่นนี้ การที่ Context Engineering ได้รับความสนใจเพิ่มมากขึ้นนั้น มีที่มาจากกระแสหลักสองประการ ได้แก่ วิวัฒนาการของประสิทธิภาพ LLM และความซับซ้อนของความต้องการในทางปฏิบัติ

ปัจจัยหลักที่ทำให้ได้รับความสนใจมีดังนี้:

• การขยาย Context Window ครั้งใหญ่: ตามข้อมูลอย่างเป็นทางการของ Google Cloud โมเดลในปัจจุบัน (เช่น Gemini 3.1) รองรับ Context Window ตั้งแต่ 1 ล้านถึง 2 ล้านโทเค็น เมื่อปริมาณข้อมูลที่สามารถจัดการได้เพิ่มขึ้น การออกแบบว่า「ควรใส่ข้อมูลอะไรลงไป」จึงกลายเป็นปัจจัยชี้ขาดความแม่นยำ
• การแพร่หลายของ Agentic AI: ยูสเคสได้เปลี่ยนจากการถาม-ตอบแบบครั้งเดียว ไปสู่การทำงานแบบอัตโนมัติหลายขั้นตอน (Multi-step) ในบทความทางเทคนิคที่ Anthropic เผยแพร่เมื่อเดือนกันยายน 2025 ได้มีการแนะนำเทคนิคต่างๆ เช่น การบีบอัดบริบท (Context Compaction) และการใช้บันทึกที่มีโครงสร้าง (Structured Notes) สำหรับงานระยะยาว ซึ่งเป็นการตอกย้ำถึงความสำคัญของการออกแบบข้อมูลอีกครั้ง
• มุมมองด้านการเพิ่มประสิทธิภาพต้นทุน: ตามข้อมูลอย่างเป็นทางการของ Google Cloud การใช้ Context Caching สามารถช่วยลดต้นทุนได้สูงสุดถึง 90% ทำให้การออกแบบข้อมูลกลายเป็นโจทย์ที่ส่งผลโดยตรงต่อทั้งประสิทธิภาพและต้นทุนการดำเนินงาน

ในบล็อกที่ทีม LangChain เผยแพร่เมื่อเดือนกรกฎาคม 2025 ก็ได้มีการจัดระบบการจัดการบริบทไว้เป็น 4 กลยุทธ์ ได้แก่ 「Write / Select / Compress / Isolate」ซึ่งแสดงให้เห็นว่ากำลังมีการสร้างภาษาที่เป็นมาตรฐานเดียวกันทั้งอุตสาหกรรม

สรุป: การขัดเกลาเพียงแค่ถ้อยคำใน Prompt ไม่สามารถทำให้ LLM ได้รับข้อมูลที่จำเป็นอย่างเหมาะสม และมีข้อจำกัดเชิงโครงสร้างในการเพิ่มความแม่นยำ

ข้อจำกัดของ Token window, การขาดหายไปของบริบท และการไม่สามารถรองรับงานที่ซับซ้อนได้ ปัญหาทั้งสามประการนี้ยากที่จะแก้ไขได้ด้วยการปรับปรุงเพียงแค่ Prompt เท่านั้น โดยในหัวข้อ H3 แต่ละหัวข้อจะเจาะลึกถึงเหตุผลดังกล่าวอย่างละเอียด

เมื่อบริบท (Context Window) ขยายกว้างขึ้น หลายคนมักคิดว่าเราควรใส่ข้อมูลทุกอย่างลงไปให้เต็ม แต่ในความเป็นจริง มีรายงานว่าการเพิ่มข้อมูลโดยไม่เลือกสรรอาจทำให้ความแม่นยำในการตอบคำถามของ LLM ลดลง

หัวใจสำคัญของปัญหานี้อยู่ที่ ความหนาแน่นของข้อมูล (Information Density) โดย Token Window หมายถึงขีดจำกัดสูงสุดของตัวอักษรหรือคำที่โมเดลสามารถประมวลผลได้ในคราวเดียว ข้อมูลอย่างเป็นทางการจาก Google Cloud ระบุว่า โมเดลหลักในปัจจุบันบางรุ่นมีหน้าต่างบริบทที่กว้างขวางถึง 1 ล้านถึง 2 ล้านโทเค็น อย่างไรก็ตาม การที่หน้าต่างกว้างไม่ได้หมายความว่าโมเดลจะสามารถใช้ข้อมูลภายในนั้นได้อย่างแม่นยำเสมอไป

โดยเฉพาะอย่างยิ่ง ปัญหาต่อไปนี้มักเกิดขึ้นได้ง่าย:

• ข้อมูลสำคัญถูกกลบ (Lost in the Middle): เมื่อคำสั่งหรือข้อเท็จจริงที่เป็นหัวใจสำคัญถูกฝังอยู่ท่ามกลางข้อความจำนวนมาก โมเดลมีแนวโน้มที่จะมองข้ามข้อมูลเหล่านั้น
• ความสับสนจากสัญญาณรบกวน (Noise): ยิ่งมีข้อมูลที่ไม่เกี่ยวข้องมากเท่าไร ความเสี่ยงที่โมเดลจะอ้างอิงหลักฐานที่ผิดพลาดก็ยิ่งสูงขึ้น
• ต้นทุนที่เพิ่มขึ้น: การส่งโทเค็นที่ไม่จำเป็นเข้าไปเรื่อยๆ จะทำให้ค่าใช้จ่าย API สูงขึ้น ในขณะที่ความแม่นยำไม่ได้เพิ่มขึ้นตาม

ในบล็อกที่ทีม LangChain เผยแพร่เมื่อเดือนกรกฎาคม 2025 ได้นำเสนอกลยุทธ์การจัดการบริบทไว้ 4 ประเภท ได้แก่ "Write / Select / Compress / Isolate" ซึ่งเป็นแนวคิดที่ว่านอกเหนือจากการเพิ่มข้อมูล (Write) แล้ว การ คัดเลือก (Select) บีบอัด (Compress) และแยกส่วน (Isolate) ข้อมูลยังเป็นสิ่งที่ขาดไม่ได้

การมอง Token Window ว่าเป็น "เวที" แทนที่จะเป็น "ความจุ" จึงเป็นวิธีที่เหมาะสมกว่า เพราะยิ่งวางอุปกรณ์ประกอบฉากที่ไม่จำเป็นไว้บนเวทีมากเท่าไร การแสดงของตัวเอกก็จะยิ่งดูจืดจางลงเท่านั้น

ปัญหาของ LLM คือเมื่อขาดบริบท แทนที่จะตอบว่า "ไม่ทราบ" กลับสร้าง "คำตอบที่ดูสมเหตุสมผล" ขึ้นมาจากข้อมูลที่ไม่ครบถ้วนแทน

รูปแบบที่มักทำให้เกิดคำตอบที่ผิดพลาดมี 3 ประการหลัก ดังนี้:

• การเติมเต็มด้วยข้อมูลทดแทน: เมื่อข้อมูลที่จำเป็นไม่ถูกส่งให้ LLM จะเติมเต็มช่องว่างด้วย "ความรู้ที่ใกล้เคียงที่สุด" จากข้อมูลที่ใช้ฝึกฝน ส่งผลให้มีข้อมูลเก่าที่ไม่ตรงกับสเปกจริงหรือข้อมูลทั่วไปปะปนอยู่ในคำตอบ
• การเข้าใจเจตนาของคำสั่งผิด: เมื่อได้รับคำสั่งที่คลุมเครือโดยไม่มีข้อมูลพื้นฐาน LLM จะเลือก "การตีความที่มีสถิติสูงที่สุด" จากหลายความเป็นไปได้ ทำให้ได้คำตอบที่ไม่ตรงกับความหมายที่ผู้รับผิดชอบตั้งใจไว้
• ไม่สามารถอ้างอิงบทสนทนาก่อนหน้าได้: ในการสนทนาที่ยาวนาน ข้อมูลที่ถูกดันออกไปนอกหน้าต่างบริบท (Context Window) จะไม่ถูกนำมาอ้างอิง ทำให้เกิดคำตอบที่ขัดแย้งกันหรือมีการตอบซ้ำ

หากพิจารณาในแง่ของเงื่อนไขการทำงาน หากเป็นงานถาม-ตอบแบบครั้งเดียว ผลกระทบจากการขาดบริบทจะอยู่ในระดับต่ำ แต่หากเป็นงานที่ต้องทำหลายขั้นตอนหรือต้องอาศัยการตัดสินใจในโดเมนเฉพาะทาง การขาดบริบทมักจะทำให้ข้อผิดพลาดขยายตัวเป็นลูกโซ่

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

คุณเคยรู้สึกไหมว่า "ทำไมยิ่งปรับแต่ง Prompt เท่าไหร่ แต่พอเจองานที่ซับซ้อนขึ้น ผลลัพธ์กลับยิ่งไม่เสถียร?"

การพยายามให้ AI ประมวลผลแบบรวดเดียวจบในขั้นตอน "การกำหนดความต้องการ (Requirement Definition) → การออกแบบ (Design) → การเขียนโค้ด (Code Generation) → การสร้างข้อกำหนดการทดสอบ (Test Specification)" มักจะทำให้เห็นขีดจำกัดของการออกแบบ Prompt ได้ชัดเจน โดยมีเหตุผลหลัก 3 ประการ ประการแรก Prompt เดียวไม่สามารถรักษา "สถานะ (State)" ได้ว่าขณะนี้อยู่ในขั้นตอนใด ทำให้เมื่อขั้นตอนดำเนินไปเรื่อยๆ บริบทก่อนหน้าจะสูญหายไป ส่งผลให้เกิดผลลัพธ์ที่ขัดแย้งกันได้ง่าย ประการต่อมา คือไม่มีกลไกในการส่งผ่านผลลัพธ์จากขั้นตอนก่อนหน้าไปยังขั้นตอนถัดไปโดยอัตโนมัติ ทำให้ผู้ใช้มักต้องใช้วิธีคัดลอกและวางด้วยตนเอง และประการสุดท้าย การยัดเยียดข้อจำกัดหรือบทบาทหลายอย่างลงใน Prompt เดียว จะทำให้โมเดลไม่สามารถตัดสินใจได้ว่าควรให้ความสำคัญกับคำสั่งใด ส่งผลให้มักจะให้คำตอบที่คลุมเครือ

ในบทความทางเทคนิคที่ Anthropic เผยแพร่ ได้เน้นย้ำถึงความสำคัญของการจัดการบริบทในงานระยะยาว โดยมีการนำเสนอโครงสร้างที่ให้ Sub-agent ส่งคืนผลสรุปขนาดประมาณ 1,000–2,000 Token ในตอนท้าย นี่เป็นตัวอย่างที่ดีที่แสดงให้เห็นว่า การจะรับมือกับงานที่ซับซ้อนได้นั้น ไม่ใช่แค่การใช้ Prompt เพียงอย่างเดียว แต่ต้องอาศัยการออกแบบโครงสร้างข้อมูลและวิธีการส่งผ่านข้อมูลด้วย

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

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

ต่อจากนี้ จะเป็นการอธิบายภาพรวมตามลำดับ ตั้งแต่การจัดระเบียบองค์ประกอบที่ประกอบกันเป็นบริบท (Context) ไปจนถึงงานออกแบบด้านการคัดเลือก การบีบอัด และการจัดวางข้อมูล รวมถึงความสัมพันธ์กับ RAG และการจัดการหน่วยความจำ (Memory Management)

เรามักคิดว่าบริบท (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 Design) สามารถแบ่งออกเป็น 3 กระบวนการ ได้แก่ "การเลือก" (Selection), "การบีบอัด" (Compression) และ "การจัดวาง" (Placement) แต่ละส่วนมีเกณฑ์การตัดสินใจที่เป็นอิสระต่อกัน หากละเลยส่วนใดส่วนหนึ่งไปจะทำให้ความแม่นยำลดลง

การเลือก: สิ่งที่ควรนำมารวมไว้ในบริบท

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

• คัดกรองเฉพาะเอกสารหรือประวัติที่มีความเกี่ยวข้องสูงเท่านั้น
• กรองข้อมูลตามเจตนาของผู้ใช้งาน
• ตัดคำอธิบายเบื้องต้นที่ไม่จำเป็นหรือตัวอย่างที่เยิ่นเย้อออกไป

การบีบอัด: วิธีการย่อข้อมูลให้กระชับ

ในการจัดการของ LangChain กลยุทธ์การจัดการบริบทได้กำหนดให้ "Compress" (การบีบอัด) เป็นงานออกแบบที่แยกออกมาต่างหาก เป้าหมายคือการประหยัดโทเค็น (Token) ผ่านการสรุปความหรือทำเป็นรายการหัวข้อสำหรับประวัติการสนทนาหรือเอกสารที่ยาว โดยยังคงความหนาแน่นของความหมายเอาไว้ หากงานเป็นเพียงการถาม-ตอบแบบครั้งเดียว การสรุปแบบง่ายก็เพียงพอแล้ว แต่หากเป็นการประมวลผลของเอเจนต์ในระยะยาว การบีบอัดแบบเป็นลำดับขั้น เช่น Compaction (การบีบอัดบริบทด้วยการสรุปบทสนทนา) ตามที่ Anthropic ได้แนะนำไว้ จะมีประสิทธิภาพมากกว่า

การจัดวาง: ลำดับในการส่งข้อมูล

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

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

RAG (Retrieval-Augmented Generation) และการจัดการหน่วยความจำ (Memory Management) ถือเป็นวิธีการหลักในการทำ Context Engineering โดยความสัมพันธ์ของทั้งสองสิ่งนี้สามารถสรุปได้ดังนี้:

• RAG: เทียบเท่ากับการ "เขียน (Write)" ข้อมูลลงในบริบท โดยการดึงข้อมูลส่วนที่เกี่ยวข้อง (Chunks) จากฐานความรู้ภายนอกมาใช้อย่างไดนามิก
• การจัดการหน่วยความจำ: เทียบเท่ากับการ "เลือก (Select) / บีบอัด (Compress)" ข้อมูล โดยการเก็บรักษาและบีบอัดประวัติการสนทนาหรือสถานะระหว่างการทำงาน เพื่อส่งเฉพาะข้อมูลที่จำเป็นเข้าสู่บริบท

ทีม LangChain ได้จัดกลุ่มกลยุทธ์หลักในการจัดการบริบทไว้ 4 แกน ได้แก่ "Write / Select / Compress / Isolate" หากมองผ่านกรอบแนวคิดนี้ RAG จะเป็นตัวแทนของกลยุทธ์ Write ส่วนการจัดการหน่วยความจำจะทำหน้าที่เป็นการผสมผสานระหว่าง Select และ Compress

ในบทความทางเทคนิคของ Anthropic ได้ระบุว่า "compaction" (การบีบอัดบริบทด้วยการสรุปบทสนทนา) และ "structured note-taking" (การจัดการความจำด้วยการจดบันทึกแบบมีโครงสร้าง) เป็นเทคโนโลยีที่สำคัญในการออกแบบเอเจนต์สำหรับงานระยะยาว นอกจากนี้ยังมีการนำเสนอโครงสร้างที่ให้ซับเอเจนต์ (Sub-agent) ส่งกลับมาเป็นบทสรุปขนาดประมาณ 1,000–2,000 โทเค็น ซึ่งถือเป็นตัวอย่างของการนำการบีบอัดบริบทไปใช้งานจริง

บทสรุป: หากปล่อยให้ความเข้าใจผิดเกี่ยวกับการออกแบบบริบท (Context Design) ดำเนินต่อไป จะทำให้มาตรการปรับปรุงไม่ตรงจุด

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

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

เหตุผลหลัก 3 ประการที่ Prompt ยาวเกินไปอาจส่งผลเสีย คือ:

• การเจือจางของความสนใจ (Attention Dilution): ยิ่งจำนวน Token มากขึ้น กลไก Attention ของโมเดลก็มีแนวโน้มที่จะจดจ่อกับข้อมูลสำคัญได้ยากขึ้น
• การปนเปื้อนของสัญญาณรบกวน (Noise): เมื่อข้อมูลที่ไม่เกี่ยวข้องเพิ่มมากขึ้น ความเสี่ยงที่โมเดลจะอ้างอิงเบาะแสที่ผิดพลาดก็จะสูงขึ้น
• ต้นทุนและเวลาในการประมวลผลที่เพิ่มขึ้น (Cost & Latency): การป้อนข้อมูลที่ยาวเกินความจำเป็นจะทำให้ต้นทุนการประมวลผลและเวลาในการตอบสนองเพิ่มสูงขึ้น

หน้าเว็บไซต์อย่างเป็นทางการของ Google Cloud ระบุว่า แม้โมเดลปัจจุบัน (เช่น Gemini 1.5) จะรองรับ Context Window ได้ถึง 1-2 ล้าน Token แต่ก็มีการนำเสนอการลดต้นทุนสูงสุดถึง 90% ด้วย Context Caching การที่หน้าต่างบริบทกว้างขึ้นทำให้เกิดแนวคิดที่ว่า "ใส่ข้อมูลเข้าไปให้หมดแล้วจะแก้ปัญหาได้" ได้ง่ายขึ้น แต่ในมุมมองของการเพิ่มประสิทธิภาพด้านต้นทุน การออกแบบโดยตัดข้อมูลที่ไม่จำเป็นออกไปนั้นมีความสำคัญอย่างยิ่ง

แม้แต่ในเฟรมเวิร์ก "Write / Select / Compress / Isolate" ที่ทีม LangChain นำเสนอ ก็ยังกำหนดให้ Select (เลือกเฉพาะข้อมูลที่จำเป็น) และ Compress (บีบอัดข้อมูลเพื่อเพิ่มความหนาแน่น) เป็นขั้นตอนที่แยกออกมาต่างหาก ซึ่งแสดงให้เห็นว่าการเพิ่มประสิทธิภาพเชิงคุณภาพ ไม่ใช่การเพิ่มปริมาณ คือหัวใจสำคัญของการออกแบบบริบท (Context Design)

ความยาวของ Prompt เป็นเพียงวิธีการ ไม่ใช่จุดประสงค์ครับ

การทำ Fine-tuning เป็นเทคนิคที่ใช้สำหรับ "อัปเดตความรู้หรือพฤติกรรมของโมเดล" ซึ่งมีจุดประสงค์แตกต่างจากการทำ Context Engineering โดยพื้นฐาน หากยังคงมีความเข้าใจที่ไม่ชัดเจนในความแตกต่างนี้แล้วตั้งเป้าว่า "ถ้าทำ Fine-tuning แล้วความแม่นยำน่าจะเพิ่มขึ้น" ก็มักจะพบกรณีที่เสียทั้งค่าใช้จ่ายและเวลาโดยไม่ได้รับผลลัพธ์ตามที่คาดหวัง

เมื่อสรุปบทบาทของทั้งสองวิธี จะแบ่งได้ดังนี้:

• Fine-tuning: อัปเดตพารามิเตอร์ของตัวโมเดลเอง เพื่อเสริมการปรับตัวให้เข้ากับโทน รูปแบบ หรือคำศัพท์เฉพาะทางในโดเมนนั้นๆ
• Context Engineering: ปรับโครงสร้าง ลำดับ และความหนาแน่นของข้อมูลที่ส่งให้ในขณะอนุมาน (Inference) เพื่อสร้างสถานการณ์ที่โมเดลสามารถอนุมานได้อย่างถูกต้อง

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

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

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

「การออกแบบบริบท (Context Design) เป็นงานของวิศวกร ดังนั้นจึงไม่เกี่ยวกับฉัน」— เชื่อว่ามีผู้รับผิดชอบด้านธุรกิจและ Product Owner จำนวนไม่น้อยที่คิดเช่นนั้น แต่ในความเป็นจริง การตัดสินใจหลายอย่างที่ส่งผลต่อคุณภาพของการออกแบบบริบทนั้น มีเพียงผู้ที่ไม่ใช่วิศวกรซึ่งมีความรู้เฉพาะทาง (Domain Knowledge) เท่านั้นที่สามารถตัดสินใจได้

การออกแบบบริบทประกอบด้วยการตัดสินใจหลักๆ 2 ประเภท ได้แก่:

• การตัดสินใจด้านการนำไปใช้งานทางเทคนิค (Technical Implementation Decisions): เช่น วิธีการบีบอัด Token, ตรรกะการค้นหาของ RAG, กลไกการจัดการหน่วยความจำ เป็นต้น
• การตัดสินใจด้านการออกแบบข้อมูล (Information Design Decisions): เช่น ควรส่งข้อมูลใดให้ AI, ควรนำเสนอข้อมูลตามลำดับใด, หรือควรตัดข้อมูลใดออก

การตัดสินใจในส่วนหลังไม่สามารถทำได้หากไม่เข้าใจบริบทของกระบวนการทำงานหรือการบริการลูกค้า ตัวอย่างเช่น หากสร้าง AI สำหรับฝ่ายสนับสนุนลูกค้า การตัดสินใจว่า「ควรให้ความสำคัญกับหมวดหมู่คำถามที่พบบ่อยใด」「มีข้อควรระวังอะไรบ้างที่ต้องรวมอยู่ในคำตอบ」ถือเป็นขอบเขตที่เจ้าหน้าที่หน้างานหรือผู้วางแผนงานควรเป็นผู้นำ

แม้ว่าวิศวกรจะสร้างสภาพแวดล้อมที่「สามารถส่งข้อมูลอะไรก็ได้」ขึ้นมา แต่หากเลือกข้อมูลที่จะส่งให้ผิดพลาด คุณภาพผลลัพธ์ของ AI ก็จะไม่ดีขึ้น ความผิดพลาดในการออกแบบข้อมูลถือเป็นปัญหาพื้นฐานที่ไม่สามารถแก้ไขได้ด้วยการปรับปรุงวิธีการเขียน Prompt

ในทางปฏิบัติ การแบ่งบทบาทหน้าที่ดังต่อไปนี้มักจะทำงานได้ดีกว่า:

• ผู้รับผิดชอบงาน/PO: การจัดลำดับความสำคัญของข้อมูลที่ควรส่ง, การกำหนด Use Case, การประเมินคุณภาพผลลัพธ์
• วิศวกร: การนำไปใช้งานจริงในการดึงข้อมูล, การบีบอัดข้อมูล, การป้อนข้อมูล (Injection), และการเพิ่มประสิทธิภาพ (Performance Optimization)

การปรับมุมมองใหม่ให้「Context Engineering」เป็นกิจกรรมการออกแบบของทั้งทีม คือก้าวแรกที่จะช่วยยกระดับความแม่นยำในการใช้งาน LLM ให้สูงขึ้น

บทสรุป: การเพิ่มประสิทธิภาพของ LLM ขึ้นอยู่กับหลักการออกแบบว่า "จะวางอะไร ไว้ที่ไหน และอย่างไร" ในบริบท

ลำดับการจัดวางข้อมูล ความหนาแน่น และการสลับข้อมูลแบบไดนามิก คือตัวแปรหลักในการออกแบบที่ส่งผลต่อคุณภาพของคำตอบ รายละเอียดของแต่ละหลักการจะอธิบายในหัวข้อ H3 ถัดไป

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

LLM ไม่ได้อ้างอิงข้อมูลทั่วทั้งหน้าต่างบริบท (context window) อย่างเท่าเทียมกัน แต่มีแนวโน้มที่จะให้ความสำคัญกับข้อมูลที่วางไว้ในช่วงต้นของอินพุตมากกว่า ซึ่งปรากฏการณ์นี้เป็นที่รู้จักกันในชื่อ "Primacy Effect" โดยมีการทดลองยืนยันว่าข้อมูลที่ถูกฝังไว้ในช่วงกลางของบริบทที่มีความยาวมักจะถูกมองข้ามได้ง่าย

เมื่อพิจารณาถึงคุณสมบัตินี้ หลักการพื้นฐานในการออกแบบจึงมีความชัดเจนขึ้น เริ่มจากการวางนิยามของงาน (task definition) ข้อจำกัด และเป้าหมายไว้ที่ส่วนหน้าสุด เพื่อให้โมเดลเข้าใจสิ่งที่ต้องทำตั้งแต่แรก จากนั้นจึงตามด้วยเอกสารหรือข้อเท็จจริงที่เกี่ยวข้องมากที่สุด โดยพื้นฐานแล้วควรวางเอกสารอ้างอิงที่ได้จาก RAG ไว้ค่อนไปทางส่วนต้น ส่วนข้อมูลเสริมหรือความรู้พื้นฐานให้รวบรวมไว้ในส่วนท้าย เนื่องจากข้อมูลที่ไม่จำเป็นหากวางไว้ข้างหน้าจะกลายเป็นสัญญาณรบกวน (noise) นอกจากนี้ การวางตัวอย่าง (few-shot) ไว้หลังนิยามของงานทันที จะช่วยให้บริบทมีความพร้อมก่อนเข้าสู่ขั้นตอนการทำงาน ทำให้โมเดลสามารถดำเนินการต่อได้ง่ายขึ้น

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

แนวคิดที่ว่ายิ่งใส่ข้อมูลในบริบท (Context) มากเท่าไร ความแม่นยำก็จะยิ่งสูงขึ้นนั้น ไม่เป็นความจริงเสมอไป หากมีข้อมูลที่ไม่เกี่ยวข้องหรือสำนวนที่เยิ่นเย้อปะปนอยู่ LLM อาจมองข้ามข้อมูลที่ควรให้ความสำคัญได้ง่าย

พื้นฐานของการกำจัดสัญญาณรบกวน (Noise) คือ "การตัดข้อมูลที่ไม่เกี่ยวข้องกับงานออกไปจริง ๆ" โดยสามารถจัดระเบียบตามมุมมองต่อไปนี้:

• การขจัดข้อมูลซ้ำซ้อน (De-duplication): หากมีข้อเท็จจริงเดียวกันปรากฏอยู่หลายจุด ให้รวบรวมไว้ที่จุดเดียว
• การลบคำนำหรือข้อความปฏิเสธความรับผิดชอบที่ไม่จำเป็น: ข้อความรูปแบบตายตัว เช่น "เอกสารฉบับนี้จัดทำขึ้นเพื่อวัตถุประสงค์..." มักไม่มีความหมายต่อโมเดล
• การคัดเลือกข้อมูลเมตา (Meta information): ชื่อไฟล์ วันที่อัปเดต หรือผู้จัดทำ ให้เก็บไว้เฉพาะกรณีที่จำเป็นต่องานเท่านั้น

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

เกณฑ์ในการตัดสินใจคือ หากงานนั้นเสร็จสิ้นได้ด้วยการอ้างอิงเอกสารเพียงฉบับเดียว การใส่ข้อมูลทั้งหมดอาจไม่มีปัญหา แต่หากต้องใช้แหล่งข้อมูลหลายแหล่งร่วมกัน ให้พิจารณาบีบอัดข้อมูลแต่ละแหล่งก่อนนำไปใช้ เนื่องจากในกรณีหลัง หากใช้ Token ไปกับข้อมูลที่ไม่ได้บีบอัด อาจมีความเสี่ยงที่แหล่งข้อมูลส่วนท้ายจะถูกละเลยหรือไม่ถูกนำมาอ้างอิงจริง

นอกจากนี้ รูปแบบที่มีโครงสร้าง (Structured format) เช่น การใช้หัวข้อหรือรายการแบบ Bullet point ยังช่วยเพิ่มความหนาแน่นของข้อมูลได้อีกด้วย โดยทั่วไปแล้วโมเดลจะสามารถอ้างอิงข้อมูลจากข้อความที่มีโครงสร้างได้ง่ายกว่าข้อความแบบร้อยแก้วทั่วไป

คำถามที่ว่า "ทำไมความแม่นยำถึงลดลงเฉพาะบางคำถาม ทั้งที่ใช้ System Prompt เดียวกันในการจัดการทุกงาน?" เป็นข้อสงสัยที่พบได้ทั่วไปในทีมพัฒนาหลายแห่ง ซึ่งสาเหตุส่วนใหญ่มักเกิดจากการที่บริบท (Context) ถูกกำหนดไว้อย่างตายตัว (Static)

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

ตัวอย่างการปรับเปลี่ยนข้อมูลที่ชัดเจน ได้แก่:

• การสลับตามประเภทงาน: ส่งเอกสารทั้งหมดสำหรับงานสรุปความ แต่ส่งเฉพาะส่วนที่เกี่ยวข้องซึ่งคัดกรองจากการค้นหาสำหรับงานถาม-ตอบ
• การสลับตามคุณลักษณะของผู้ใช้: แทรกคำอธิบายพื้นฐานสำหรับผู้เริ่มต้น หรือเน้นรายละเอียดเชิงลึกสำหรับผู้เชี่ยวชาญ
• การบีบอัดและคัดเลือกประวัติการสนทนา: ในการสนทนาที่ยาวนาน ให้เก็บเฉพาะการโต้ตอบที่สำคัญล่าสุดและบทสรุป แทนที่จะเก็บประวัติทั้งหมด

การจัดหมวดหมู่ "Write / Select / Compress / Isolate" ที่ LangChain นำเสนอ ก็คือการทำให้การจัดการข้อมูลแบบไดนามิกนี้เป็นระบบ โดยเฉพาะการรวมกันของ "Select (การเลือก)" และ "Compress (การบีบอัด)" ซึ่งเป็นหัวใจสำคัญของการปรับเปลี่ยนข้อมูลตามประเภทของงาน

ข้อควรระวังในการนำไปใช้งานคือ ยิ่งตรรกะการสลับข้อมูลมีความซับซ้อนมากเท่าไร ต้นทุนในการดูแลรักษาก็จะยิ่งสูงขึ้นตามไปด้วย ดังนั้นแนวทางที่เป็นจริงที่สุดคือ ให้เริ่มจากการตรวจสอบว่า "สามารถจำกัดประเภทของงานให้เหลือเพียง 2-3 ประเภทได้หรือไม่" แล้วเริ่มจากการใช้เงื่อนไขแบบง่ายๆ ก่อน

เมื่อเข้าใจแนวคิดแล้ว ขั้นตอนต่อไปคือการนำไปปฏิบัติจริง เราจะอธิบายวิธีการดำเนินการอย่างเป็นรูปธรรมใน 2 ขั้นตอน ตั้งแต่การวินิจฉัยปัญหาไปจนถึงการออกแบบและติดตั้งโครงสร้างบริบท (Context Structure)

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

ในการวินิจฉัย เราจะตรวจสอบสถานะปัจจุบันของการออกแบบ Prompt โดยพิจารณาจากมุมมองดังต่อไปนี้:

• ข้อมูลที่ขาดหายไป: LLM ได้รับข้อมูลพื้นฐานที่จำเป็นต่อการตอบคำถาม (เช่น กฎการทำงาน, นิยามคำศัพท์, บทสนทนาในอดีต) ครบถ้วนหรือไม่
• ข้อมูลที่มากเกินไป/สัญญาณรบกวน (Noise): มีข้อมูลที่ไม่เกี่ยวข้องปะปนอยู่จนทำให้ความสนใจของโมเดลกระจัดกระจายหรือไม่
• ปัญหาการจัดวาง: คำสั่งสำคัญหรือข้อมูลอ้างอิงถูกวางไว้ที่ท้าย Prompt จนถูกกลบด้วยข้อความยาวๆ ในส่วนก่อนหน้าหรือไม่
• ความไม่สอดคล้องของบริบท: ข้อมูลที่เป็นพื้นฐานสำคัญได้รับการส่งต่ออย่างต่อเนื่องระหว่างหลายรอบการสนทนาหรือระหว่าง Agent หรือไม่

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

หากจัดระเบียบผลการวินิจฉัยในรูปแบบตารางง่ายๆ จะช่วยให้ส่งต่องานไปยังขั้นตอนการออกแบบถัดไปได้สะดวกยิ่งขึ้น

เมื่อปัญหาชัดเจนขึ้นจากการวินิจฉัยใน Step 1 แล้ว ขั้นตอนถัดไปคือการออกแบบและปรับใช้โครงสร้างบริบท (Context Structure) ให้เป็นรูปธรรม

พื้นฐานของการออกแบบคือการพิจารณาโดยยึดหลัก 4 ปฏิบัติการที่ทีม LangChain ได้เสนอไว้ ได้แก่ "Write / Select / Compress / Isolate"

• Write (การเขียน): บันทึกประวัติการสนทนาหรือผลลัพธ์ระหว่างทางไว้ในรูปแบบ Structured Note เพื่อให้สามารถอ้างอิงได้ในขั้นตอนถัดไป
• Select (การเลือก): คัดกรองเฉพาะข้อมูลที่เกี่ยวข้องกับงานปัจจุบันจาก RAG หรือ Memory Store
• Compress (การบีบอัด): ลดจำนวน Token ที่ไม่จำเป็นเพื่อเพิ่มความหนาแน่นของข้อมูล เช่นเดียวกับ Compaction (การสรุปบทสนทนา) ที่ Anthropic แนะนำ
• Isolate (การแยกส่วน): มอบหมายงานย่อยให้กับ Sub-agent เพื่อป้องกันไม่ให้เกิดสัญญาณรบกวน (Noise) ในบริบทหลัก

สิ่งสำคัญคือต้องปรับจุดเน้นตามลักษณะของงาน หากเป็นงาน Q&A แบบครั้งเดียวควรให้ความสำคัญกับ Select และ Compress แต่หากเป็นงานประเภท Agent ที่ต้องดำเนินการในระยะยาว ควรเน้นการออกแบบที่ Write และ Isolate เป็นหลัก

สำหรับการปรับใช้จริง แนะนำให้เริ่มทดลองจากหน่วยเล็กๆ ดังนี้:

1. แยก System Context (บทบาท, ข้อจำกัด, รูปแบบผลลัพธ์) ออกมาไว้อย่างชัดเจนที่ส่วนต้นของ Prompt เดิม
2. แทรกเอกสารที่เกี่ยวข้องแบบไดนามิกด้วย RAG เพื่อแทนที่ Prompt แบบยาวที่เป็นค่าคงที่