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 に役割・制約・出力形式を指示する基盤となる文章である。通常は全ターンで固定のまま使われ、コンテキストの土台をなす。長すぎる（たとえば 3,000 トークンを超える）システムプロンプトは、以降に積み上がる動的要素を圧迫するため注意が要る。

タスク指示 (Task Instruction) は、各ターンでユーザーから届く具体的なリクエストに相当する。システムプロンプトが「どう振る舞うか」を定義するのに対し、タスク指示は「今回何をしてほしいか」を定義する。

Few-shot 事例は、出力フォーマットや思考プロセスの例を示すために挿入される入出力ペアである。事例は多ければ良いというものではなく、2〜5 件に厳選して多様なパターンを網羅するのが定石となっている。出力のばらつきが気になるタスクほど Few-shot の設計が効きやすい。

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

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

対話履歴・長期メモリ (ประวัติการสนทนาและหน่วยความจำระยะยาว) คือองค์ประกอบที่เก็บคำพูดของผู้ใช้ การตอบกลับของโมเดล และผลลัพธ์ของเครื่องมือในอดีตตามลำดับเวลา ในงานระยะยาว (Long task) พื้นที่ส่วนนี้จะขยายตัวอย่างรวดเร็วที่สุด ดังนั้นกลยุทธ์การบีบอัดข้อมูลที่จะกล่าวถึงต่อไปจึงเป็นสิ่งที่ขาดไม่ได้

ในการใช้งานจริง เราจำเป็นต้องเปลี่ยนแนวคิดจากการจัดการบริบทให้เป็น "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 calls) มากกว่าหลายสิบครั้งในหนึ่งงาน หากเก็บผลลัพธ์จากเครื่องมือทั้งหมดไว้โดยตรง บริบท (Context) จะเต็มอย่างรวดเร็ว ดังนั้น การสรุปผลลัพธ์จากเครื่องมือ จึงเป็นสิ่งที่จำเป็นอย่างยิ่ง

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

สำหรับการรองรับงานระยะยาว (Long-task) การออกแบบให้มี "แผน" (Plan) ที่ระบุเป้าหมาย เงื่อนไขความสำเร็จ และงานที่เหลืออยู่ของทั้งโปรเจกต์ไว้อย่างชัดเจน แล้วนำข้อมูลนี้ใส่เข้าไปในช่วงต้นของทุกรอบการทำงาน ก็เป็นวิธีที่มีประสิทธิภาพเช่นกัน ซึ่งจะช่วยป้องกันไม่ให้โมเดลสูญเสียทิศทางและช่วยลดการออกนอกแผนระหว่างทางได้ ทั้งนี้ ในบทความที่เกี่ยวข้องเรื่อง "AIエージェントを本番運用に乗せるには？パイロットから量産化への実践ステップ" (จะนำ AI Agent ไปใช้งานจริงได้อย่างไร? ขั้นตอนปฏิบัติจากการทดลองสู่การผลิต) ก็ได้มีการแนะนำเทคนิคในลักษณะเดียวกันนี้ไว้ด้วย

เพื่อป้องกันปัญหาการขยายตัวของข้อมูล (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) ในมุมมองของผู้ใช้ นี่อาจกลายเป็นสถานการณ์ที่เลวร้ายที่สุดคือ "คำตอบช้าแถมคุณภาพยังแย่อีกด้วย"

トークンコストの見えにくさも深刻な落とし穴となる。エージェントが内部で何度もツールを呼び、履歴を蓄積していく構造では、1 ユーザーあたりのトークン消費がインタラクションの回数に応じて加速度的に増える。請求書を見て初めて「このユースケースは採算が合わなかった」と気づくケースは珍しくない。

コストの可視化は、単に「月次の API 請求額」だけでは足りない。セッション単位・ユーザー単位・エンドポイント単位にブレイクダウンし、「1 タスクあたり何トークンで済むはずか」というターゲットを持つ必要がある。関連記事「LLMコスト最適化ガイド — トークン削減・モデル選定・キャッシュ実装」で紹介した原則を、コンテキスト設計のレイヤーからも適用することで、コスト暴走を未然に防げる。

本記事のまとめとして、コンテキストエンジニアリングは「何を入れるか」以上に「何を入れないか」の設計が質を決めることを強調したい。プロンプトエンジニアリングでは個々の指示文を磨けば十分だったが、エージェント時代のコンテキスト設計は情報の絞り込みと動的な再構成こそが中核となる。

自社で LLM アプリケーションを本番運用しているチームは、まずコンテキストウィンドウを 6 要素に分解し、それぞれの寄与度を測るところから改善サイクルを開始するとよい。当社でも B2B 顧客の LLM 導入支援で同じアプローチを採用し、コンテキスト設計のリファクタリングだけで体感品質が一段上がるケースを複数見てきた。