เจาะประเด็น
AI / Engineering
AI โค้ดดิ้งพังเพราะ "ยัดเยียด" ข้อมูลเยอะเกินไป ทางแก้อาจต้อง "ขี้เกียจ" บ้าง
สองกูรูวงการซอฟต์แวร์ชี้ชัด ปัญหาไม่ได้อยู่ที่โมเดลโง่ แต่อยู่ที่เราไม่รู้จัก "คุมบริบท" ให้เป็น
ทีมข่าว เอไอไทย.com
⏱ อ่าน 5 นาที
เพื่อนๆ ที่ลองใช้ AI เขียนโค้ดคงเคยเจออาการแบบนี้: ตอนแรกมันเก่งเว่อร์ เข้าใจโจทย์เป๊ะ เขียนโค้ดเสร็จไว แต่ยิ่งเราใส่ข้อมูลเยอะขึ้นเรื่อยๆ หวังให้มัน "เห็นภาพ" มากขึ้น มันกลับเริ่มเพี้ยน ลืมสิ่งที่เราสั่งไว้ตอนต้น เอาข้อมูลเก่ามาปนกับของใหม่ หรือที่หนักสุดคือมันมั่นใจผิดๆ ทั้งที่เรายัดบริบทให้เต็มหน้าต่างไปหมดแล้ว
ฟังดูคุ้นใช่ไหม? ถ้าใช่ แสดงว่าคุณกำลังเจอปัญหาที่ Baruch Sadogursky และ Patrick Debois พูดถึงในงานประชุมสายเทคเมื่อเร็วๆ นี้ พวกเขาออกมาฟันธงว่าต้นตอของความหายนะไม่ได้อยู่ที่ตัวโมเดล แต่เป็นเพราะเรากำลังยัด "ขยะ" เข้าไปใน Context Window จนเต็ม แล้วก็แปลกใจว่าทำไม AI ถึงทำงานห่วยทั้งที่ให้ข้อมูลไปเยอะแยะ
ลองคิดตามนะ สมมติคุณต้องอ่านหนังสือทั้งเล่มเพื่อหาคำตอบแค่ประโยคเดียว สมองคุณจะล้าและพลาดข้อมูลสำคัญได้ง่ายๆ AI ก็เหมือนกัน การยัดโค้ดทั้งโปรเจกต์ ไฟล์เอกสารทุกอัน หรือประวัติการสนทนาทุกบรรทัดเข้าไปในพรอมพ์ มันไม่ได้ทำให้ AI "รู้มากขึ้น" แต่กลับทำให้มัน "โฟกัสไม่ถูก" ต่างหาก สิ่งที่สองคนนี้เสนอคือแนวคิดที่เรียกว่า Context Engineering ซึ่งไม่ใช่เรื่องเวทมนตร์ แต่เป็นวิศวกรรมจ๋าๆ ที่ต้องวางแผนอย่างมีระบบ
ใจความสำคัญคือ เราต้องเปลี่ยนวิธีคิดจากการ "ป้อนข้อมูล" มาเป็น "ออกแบบบริบท" เช่น การใช้ Lazy-Loaded Skills — แนวคิดที่ให้ AI เรียกใช้ความสามารถเฉพาะทางเฉพาะตอนที่จำเป็นจริงๆ แทนที่จะโหลดทุกอย่างไว้ตลอดเวลา เหมือนเราไม่ต้องเปิดคู่มือการใช้รถทุกครั้งที่สตาร์ทเครื่อง แต่เปิดเฉพาะตอนที่ไฟโชว์เตือนเท่านั้น
อีกหนึ่งไอเดียที่น่าสนใจคือการทำ Versioned Context Artifacts — หมายความว่าเราควรจัดการ "ชุดบริบท" ที่ป้อนให้ AI เหมือนกับที่เราจัดการเวอร์ชันโค้ดใน Git ไม่ใช่แค่เขียนไฟล์ Markdown ทิ้งไว้แล้วหวังให้ AI เข้าใจเอง แต่ต้องมีเวอร์ชัน มีประวัติการแก้ไข รู้ว่าอันไหนเก่า อันไหนใหม่ อันไหนใช้ได้ อันไหนถูกยกเลิกไปแล้ว ซึ่งจะช่วยลดความสับสนของ AI ได้มหาศาล
ที่เด็ดไปกว่านั้นคือแนวคิด Externalized Memory Banks หรือการแยก "ความทรงจำ" ออกจากตัวบทสนทนา แทนที่จะต้องเล่าประวัติศาสตร์ทั้งหมดทุกครั้งที่เริ่มแชทใหม่ ให้ AI ดึงข้อมูลจากคลังความรู้ภายนอกเฉพาะส่วนที่เกี่ยวข้องกับงานตรงหน้าแทน ซึ่งช่วยลดภาระของ Context Window ได้เยอะมาก และทำให้ AI ตอบได้แม่นขึ้นด้วย
ประโยคเด็ดจากงานนี้คือ "The right 300 tokens beat 100k noisy ones" — โทเคนที่ใช่ 300 ตัว ดีกว่าโทเคนไร้สาระ 100,000 ตัว นี่คือหัวใจของเรื่องทั้งหมด เรามัวแต่คิดว่ายิ่งให้ข้อมูลเยอะ AI ยิ่งฉลาด แต่ความจริงคือมันแค่ทำให้โมเดลสับสนและใช้พลังงานในการประมวลผลโดยใช่เหตุ
แล้วจะรู้ได้ยังไงว่าบริบทไหน "ใช่" หรือ "ไม่ใช่"? สองคนนี้แนะนำให้ใช้วิธี LLM-as-a-Judge — ใช้ AI อีกตัวหนึ่งเป็นกรรมการตัดสินคุณภาพของชุดบริบทที่เราสร้างขึ้น เพื่อประเมินว่าเมื่อป้อนข้อมูลชุดนี้ให้โมเดลทำงาน ผลลัพธ์ที่ได้แม่นยำแค่ไหน แล้วค่อยปรับปรุงชุดข้อมูลนั้นแบบวนซ้ำไปเรื่อยๆ เหมือนการทำเทสต์ให้โค้ดนั่นแหละ แต่เทสต์ชุดพรอมพ์แทน
ประเด็นสำคัญคือเรื่องนี้ไม่ได้เกี่ยวกับคนเขียนโค้ดทั่วไปเท่านั้น แต่เกี่ยวกับ Software Architect และ Engineering Leader ที่ต้องออกแบบระบบให้ทีมทั้งทีมใช้ AI ทำงาน ถ้ายังปล่อยให้ทุกคนยัดพรอมพ์มั่วๆ กันเอง โค้ดที่ออกมาจะเละเทะไปหมด แต่ถ้าออกแบบระบบบริบทดีๆ จะเปลี่ยนไฟล์ Markdown ธรรมดาๆ ให้กลายเป็น Agentic Workflow ที่ทำงานได้อย่างน่าเชื่อถือ
ฟังดูแล้วมันไม่ได้ยากเกินความสามารถ แต่ต้องเปลี่ยน mindset ครั้งใหญ่ ยุคที่เราจะยัดทุกอย่างเข้าไปในพรอมพ์แล้วรอดวงตายไปได้แล้ว ต่อไปนี้ "การเลือก" ว่าจะให้ AI เห็นอะไรสำคัญกว่า "การให้" เยอะๆ เพราะในโลกของ Context Engineering น้อยแต่มากคือความจริง ไม่ใช่แค่สโลแกน
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 3
กำลังโหลดความคิดเห็น...