Context Windows กำลังขยายใหญ่ขึ้นอย่างมหาศาล
คนส่วนใหญ่ใช้คำว่า agent กับทุกสิ่งทุกอย่าง
ฟังก์ชันที่เรียกใช้ tool คือ agent, แชทบอทที่มีหน่วยความจำคือ agent, สคริปต์ที่มีลูปก็คือ agent
ความผิดพลาดนี้ส่งผลให้เกิดวิศวกรรมที่แย่ ทีมงานมักออกแบบระบบที่ซับซ้อนเกินไป (over-engineer) สำหรับงานง่ายๆ และออกแบบระบบที่ง่ายเกินไป (under-engineer) สำหรับงานที่ซับซ้อน ผมเห็นหลายทีมใช้เวลาหลายสัปดาห์ไปกับการทำ agent orchestration สำหรับเวิร์กโฟลว์ที่ต้องการเพียงแค่ prompt ดีๆ เพียงอันเดียวเท่านั้น
นี่คือคำจำกัดความของ agent ที่แท้จริงในมุมมองของผม
Agent ต้องมีวัตถุประสงค์ (objective) มันไม่ได้แค่ทำตามคำสั่ง แต่มันตัดสินใจได้ว่าจะทำอะไรต่อไป มันจัดการกับความล้มเหลวได้ และมันรู้ว่าเมื่อไหร่ควรหยุด
ใช้เกณฑ์เหล่านี้ในการวัดผล:
- หากมนุษย์ต้องคอยชี้นำในทุกขั้นตอน นั่นคือ chat interface
- หากระบบสามารถกู้คืนสถานะได้หลังจากเรียกใช้ tool ล้มเหลว นั่นคือการเริ่มขยับเข้าใกล้ความเป็น agent
- หากระบบสามารถย่อยเป้าหมายออกเป็นงานย่อยๆ (tasks) และมอบหมายงานเหล่านั้นได้ นั่นคือ agent ที่แท้จริง
Agent ที่ประสบความสำเร็จส่วนใหญ่มักจะเป็นแบบเฉพาะทาง (narrow) พวกมันทำงานอย่างใดอย่างหนึ่งได้ดี เช่น การคัดกรองงานสนับสนุนลูกค้า (customer support triage) หรือการดึงข้อมูลจากเอกสาร (document extraction) พวกมันไม่ใช่เครื่องยนต์การใช้เหตุผลทั่วไป (general reasoning engines)
ทีมที่ประสบความสำเร็จจะมุ่งเน้นไปที่ 3 สิ่งนี้:
- Tool design: อินเทอร์เฟซสะอาดและใช้งานง่ายแค่ไหน?
- Failure handling: จะเกิดอะไรขึ้นเมื่อ tool ไม่คืนค่าอะไรกลับมาเลย?
- Observability: คุณสามารถตรวจสอบย้อนกลับได้หรือไม่ว่าทำไม agent ถึงตัดสินใจเช่นนั้น?
ทีมที่ไม่ประสบความสำเร็จมักจะแค่เปลี่ยนโมเดลหนึ่งเป็นโมเดลที่ใหม่กว่าแล้วคาดหวังผลลัพธ์ที่ดีขึ้น โดยที่พวกเขามองข้ามการออกแบบระบบ (system design)
Framework อย่าง LangChain หรือ CrewAI เปลี่ยนแปลงทุกเดือน รูปแบบ (pattern) จึงมีความสำคัญมากกว่าตัว framework
ใช้รูปแบบเหล่านี้:
- Plan then execute: แยกขั้นตอนการใช้เหตุผลออกจากขั้นตอนการลงมือทำ
- Separate retrieval from reasoning: การดึงบริบท (context) เป็นงานที่ต่างจากการนำบริบทนั้นมาใช้
- Explicit handoffs: ใช้ structured logs เมื่อ agent ตัวหนึ่งส่งต่องานให้อีกตัวหนึ่ง
Framework เป็นเพียงแค่โครงนั่งร้าน แต่อาคารที่แท้จริงคือสถาปัตยกรรม (architecture)
RAG เป็นมาตรฐานทั่วไป แต่การทำ chunking มักจะมีปัญหา หากคุณแบ่งเอกสารไม่ดี โมเดลจะสูญเสียบริบท ซึ่งนำไปสู่การเกิดอาการหลอน (hallucinations)
หากผลลัพธ์ของ RAG ไร้ประโยชน์ ให้ตรวจสอบการทำ chunking และ metadata ของคุณ ปัญหาแทบจะไม่ใช่ที่ตัวโมเดลเลย
โมเดลจะเก่งขึ้น Context windows จะใหญ่ขึ้น และต้นทุน token จะลดลง
แต่สิ่งเหล่านั้นไม่ได้ช่วยแก้ปัญหาความท้าทายทางวิศวกรรมที่แท้จริง คุณต้องสร้างระบบที่ทำงานได้อย่างถูกต้องแม้ในยามที่คุณไม่ได้เฝ้าดูอยู่
จงมุ่งเน้นไปที่การกำกับดูแล (governance), การสังเกตการณ์ (observability) และการใช้ tool ที่เชื่อถือได้ วิศวกรที่เก่งที่สุดจะไม่ใช่ผู้วิจัยโมเดล (model researchers) แต่จะเป็นนักออกแบบระบบ (systems designers) ผู้สร้าง AI ที่เชื่อถือได้
Context window กำลังขยายใหญ่ขึ้นเรื่อยๆ และนี่คือเหตุผลว่าทำไมมันถึงเปลี่ยนทุกอย่าง
เมื่อไม่นานมานี้ หน้าต่างบริบท (context window) ขนาด 8k หรือ 32k tokens ถือว่าใหญ่มากแล้ว แต่ในปัจจุบัน เรากำลังเห็นโมเดลอย่าง Gemini 1.5 Pro ที่นำเสนอ context window ขนาด 1 ล้านถึง 2 ล้าน tokens นี่ไม่ใช่แค่การปรับปรุงเพียงเล็กน้อย แต่มันคือการเปลี่ยนกระบวนทัศน์ (paradigm shift) ครั้งสำคัญในโลกของ AI
Context window คืออะไร?
ให้ลองนึกภาพว่า context window คือความจำระยะสั้นของโมเดล มันคือปริมาณข้อมูลที่โมเดลสามารถ "เก็บไว้ในหัว" ได้ในขณะใดขณะหนึ่งในขณะที่กำลังประมวลผล prompt หากข้อมูลที่คุณป้อนเข้าไปมีขนาดเกินกว่าที่ context window จะรับได้ โมเดลก็จะเริ่ม "ลืม" ข้อมูลส่วนแรกๆ ที่คุณใส่เข้าไป
ยุคของ RAG vs. ยุคของ Long Context
ในช่วงสองสามปีที่ผ่านมา RAG (Retrieval-Augmented Generation) เป็นมาตรฐานระดับสูง (gold standard) ในการช่วยให้ LLMs เข้าถึงข้อมูลภายนอกได้ แทนที่จะพยายามยัดข้อมูลทั้งหมดลงใน prompt เราจะใช้วิธีค้นหาข้อมูลที่เกี่ยวข้องที่สุดจากฐานข้อมูล (vector database) แล้วส่งเฉพาะ "snippets" หรือส่วนย่อยของข้อมูลเหล่านั้นไปให้โมเดล
แต่ด้วยการมาถึงของโมเดลที่มี context window ขนาดมหาศาล วิธีการที่เราสร้างแอปพลิเคชัน AI กำลังจะเปลี่ยนไป
ทำไมสิ่งนี้ถึงเปลี่ยนทุกอย่าง
1. ประสบการณ์ของนักพัฒนาที่เรียบง่ายขึ้น (Simpler Developer Experience)
แทนที่จะต้องสร้าง pipeline ของ RAG ที่ซับซ้อน ซึ่งต้องประกอบด้วยการทำ embedding, การจัดการ vector database, และการทำ retrieval ที่แม่นยำ คุณสามารถทำสิ่งที่เรียบง่ายกว่านั้นได้ นั่นคือการ "โยน" เอกสารทั้งหมดหรือฐานข้อมูลทั้งชุดลงใน context window โดยตรง สิ่งนี้ช่วยลดความซับซ้อนของระบบลงอย่างมหาศาล
2. การใช้เหตุผลและการเข้าใจภาพรวมที่ดีขึ้น (Better Reasoning and Holistic Understanding)
RAG มักจะดึงข้อมูลมาเพียงบางส่วน ซึ่งอาจทำให้โมเดลขาดบริบทที่สำคัญไป แต่ด้วย long context โมเดลสามารถเห็น "ภาพรวม" ของข้อมูลทั้งหมดได้ ไม่ว่าจะเป็นหนังสือทั้งเล่ม, โค้ดทั้งโปรเจกต์, หรือบันทึกการประชุมยาวๆ สิ่งนี้ช่วยให้โมเดลสามารถเชื่อมโยงความสัมพันธ์ระหว่างข้อมูลที่อยู่ห่างกันได้ดีขึ้น นำไปสู่การใช้เหตุผล (reasoning) ที่แม่นยำกว่าเดิม
ข้อแลกเปลี่ยนที่ต้องพิจารณา (The Trade-offs)
แม้ว่า long context จะฟังดูเหมือนเป็นทางออกของทุกปัญหา แต่ก็ยังมีข้อควรระวัง:
1. ค่าใช้จ่าย (Cost)
การประมวลผล tokens จำนวนมหาศาลย่อมมีราคาแพง การส่ง context window ขนาด 1 ล้าน tokens ในทุกๆ prompt จะทำให้ค่าใช้จ่ายในการใช้งาน API พุ่งสูงขึ้นอย่างรวดเร็วเมื่อเทียบกับการใช้ RAG ที่ส่งเฉพาะข้อมูลที่จำเป็น
2. ความหน่วง (Latency)
ยิ่งมีข้อมูลที่ต้องประมวลผลมากเท่าไหร่ โมเดลก็ยิ่งต้องใช้เวลาในการประมวลผลนานขึ้นเท่านั้น สิ่งนี้อาจส่งผลต่อประสบการณ์ผู้ใช้งานในแอปพลิเคชันที่ต้องการการตอบสนองแบบเรียลไทม์
3. ความแม่นยำและปัญหา "Lost in the Middle"
มีงานวิจัยหลายชิ้นชี้ให้เห็นว่า โมเดลบางตัวมีปัญหาในการค้นหาข้อมูลที่ถูกฝังอยู่ "ตรงกลาง" ของ context window ขนาดใหญ่ โดยมักจะให้ความสำคัญกับข้อมูลที่อยู่ตอนต้นหรือตอนท้ายมากกว่า ปรากฏการณ์นี้เรียกว่า "Lost in the Middle" ซึ่งอาจทำให้ความแม่นยำลดลงหากข้อมูลสำคัญของคุณอยู่ผิดที่
บทสรุป
อนาคตของการพัฒนา AI ไม่ใช่การเลือกระหว่าง RAG หรือ Long Context อย่างใดอย่างหนึ่ง แต่มันคือการเรียนรู้วิธีใช้ทั้งสองอย่างร่วมกันอย่างมีประสิทธิภาพ สำหรับงานที่ต้องการความเร็วและประหยัด RAG ยังคงเป็นตัวเลือกที่ดี แต่สำหรับงานที่ต้องการความเข้าใจเชิงลึกและบริบทที่ครบถ้วน Long Context คือเครื่องมือที่ทรงพลังที่สุดเท่าที่เราเคยมีมา