เฟรมเวิร์ก AI ที่ฮอตที่สุดในตอนนี้ มีข้อบกพร่องที่ร้ายแรง

เดี๋ยวนี้ใครๆ ก็เรียกทุกอย่างว่าเป็น agent กันไปหมด

ฟังก์ชันที่เรียกใช้ tool คือ agent, แชทบอทที่มีความจำคือ agent, สคริปต์ที่มี loop คือ agent นี่คือความเข้าใจที่ผิด

เมื่อคุณขาดคำนิยามที่ชัดเจน คุณจะออกแบบระบบที่ซับซ้อนเกินความจำเป็น (over-engineer) สำหรับงานง่ายๆ และออกแบบระบบที่ง่ายเกินไป (under-engineer) สำหรับงานที่ซับซ้อน ผมเห็นหลายทีมใช้เวลาหลายสัปดาห์ไปกับการทำ agentic orchestration สำหรับ workflow ที่จริงๆ แล้วต้องการแค่ prompt ดีๆ เพียงอันเดียวเท่านั้น

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

  • ถ้ามนุษย์ต้องบอกระบบทุกขั้นตอน นั่นคือ chat interface
  • ถ้าระบบสามารถกู้คืนตัวเองได้จากการเรียกใช้ tool ที่ล้มเหลว แสดงว่าคุณกำลังมาถูกทางแล้ว
  • ถ้าระบบสามารถย่อยเป้าหมายออกเป็นงานย่อยๆ (subtasks) ได้ นั่นแหละคือ agent ที่แท้จริง

Agent ที่ประสบความสำเร็จส่วนใหญ่เป็นแบบเฉพาะทาง (narrow) พวกมันทำสิ่งเดียวได้ดีเยี่ยม เช่น จัดการงานบริการลูกค้า หรือการดึงข้อมูลจากเอกสาร (document extraction) พวกมันไม่ใช่เครื่องยนต์การใช้เหตุผลทั่วไป (general reasoning engines)

ทีมที่ประสบความสำเร็จจะมุ่งเน้นไปที่ 3 ด้านนี้:

  • การออกแบบ tool: interface สะอาดและใช้งานง่ายแค่ไหน?
  • การจัดการความล้มเหลว: จะเกิดอะไรขึ้นเมื่อ tool ไม่คืนค่าอะไรกลับมาเลย?
  • การสังเกตการณ์ (Observability): คุณสามารถตรวจสอบย้อนกลับได้ไหมว่าทำไม agent ถึงตัดสินใจเช่นนั้น?

ทีมที่เปลี่ยนโมเดลไปเรื่อยๆ โดยหวังว่าจะได้ผลลัพธ์ที่ดีขึ้นโดยไม่เปลี่ยนสถาปัตยกรรม (architecture) จะต้องล้มเหลว

Framework อย่าง LangChain หรือ CrewAI มีความสำคัญน้อยกว่า "รูปแบบ" (patterns) เพราะรูปแบบสามารถใช้งานได้ไม่ว่าจะใช้เครื่องมือใดก็ตาม

จงใช้รูปแบบเหล่านี้:

  • วางแผนแล้วค่อยลงมือทำ (Plan then execute): ใช้ขั้นตอนหนึ่งในการวางแผน และอีกขั้นตอนหนึ่งแยกต่างหากในการลงมือทำ
  • แยกการดึงข้อมูลออกจากความสามารถในการใช้เหตุผล (Separate retrieval from reasoning): การดึงข้อมูล (fetching data) และการใช้ข้อมูล (using data) เป็นงานที่ต่างกัน
  • การส่งต่องานที่ชัดเจน (Explicit handoffs): ใช้ structured logs เมื่อ agent ตัวหนึ่งส่งต่องานให้อีกตัวหนึ่ง

Framework คือนั่งร้าน ส่วน architecture คือตัวอาคาร

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

หาก RAG ของคุณให้ผลลัพธ์ที่ถูกต้องแต่ใช้งานไม่ได้ ให้ไปแก้ที่การทำ chunking หรือ metadata ของคุณ อย่าไปโทษ embedding model

เลิกวิ่งไล่ตาม benchmark ได้แล้ว ให้หันมาโฟกัสที่การสร้างระบบที่คุณไว้วางใจได้ ให้ความสำคัญกับ governance, observability และการใช้งาน tool ที่เชื่อถือได้

วิศวกรที่มีความสำคัญคือผู้ที่สามารถสร้างระบบที่คนอื่นสามารถดูแลรักษาต่อได้ นี่คือเรื่องของการออกแบบระบบ (systems design) ไม่ใช่การวิจัยโมเดล (model research)

แหล่งที่มา: https://dev.to/aibughunter/the-hottest-ai-framework-right-now-has-a-fatal-flaw-nobody-mentions-3hd1

ชุมชนแห่งการเรียนรู้เพิ่มเติม: https://t.me/GyaanSetuAi