เจาะลึก
AI Agents
ทำ AI Agent ให้ใช้จริงในProduction ไม่ใช่แค่ RAG แล้วจบ ต้องมี Knowledge Graph เป็นฐาน
Cassie Shum ชี้ว่า agentic AI ที่จะรอดในงานจริงต้องมีโครงสร้างความรู้รองรับ ไม่ใช่โยนทุกอย่างให้ vector search แล้วหวังว่าจะเวิร์ก
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
ต่อให้โมเดลเก่งแค่ไหน ถ้าฐานความรู้ข้างหลังมันยุ่งเหยิง ระบบ agent ก็พังทั้งระบบอยู่ดี
ถ้าคุณเคยลองสร้าง AI agent ไว้ใช้งานจริงในองค์กร น่าจะเคยเจอปัญหาเดิมๆ — ต่อให้ใช้ RAG (Retrieval-Augmented Generation) ดึงข้อมูลจาก vector database มาให้โมเดลอ่านแล้ว มันก็ยังตอบมั่วบ้าง ลืมบริบทบ้าง หรือไม่ก็เผา token ไปกับข้อมูลที่ไม่ได้ใช้จริง งานนำเสนอของ Cassie Shum ในงานเวทีของ InfoQ เลยชี้ว่า ปัญหามันไม่ได้อยู่ที่ตัวโมเดล แต่อยู่ที่ "โครงสร้างความรู้" ที่เราโยนให้มันต่างหาก
ประเด็นของ Shum คือ knowledge graph ควรเป็นชั้นฐานรากของระบบ agentic AI ไม่ใช่ของแถมที่ค่อยมาต่อทีหลัง เธอไม่พูดถึง RAG แบบที่คนส่วนใหญ่เข้าใจกันในเชิงว่า "แปะ vector store แล้วจบ" แต่บอกตรงๆ ว่ามันต้องไปไกลกว่านั้น — ต้องมีโครงสร้างที่บอกได้ว่าข้อมูลชิ้นไหนเชื่อมกับชิ้นไหน ใครตัดสินใจอะไรจากข้อมูลอะไร และ agent แต่ละตัวมองเห็นข้อมูลส่วนไหนได้บ้าง
Shum แจกแจง 4 architectural pattern ที่เธอบอกว่าใช้ได้จริงใน production ไม่ใช่ทฤษฎีบนกระดาษ ลองไล่ดูทีละอันว่ามันแก้ปัญหาอะไร
Context Bundling
รวมบริบทที่เกี่ยวข้องให้เป็นก้อนเดียว แทนที่จะปล่อยให้ agent ไปดึงข้อมูลกระจัดกระจายเอง — ลดโอกาสที่โมเดลจะหยิบผิดชิ้น
Decision Provenance
ตามรอยได้ว่าการตัดสินใจของ agent มาจากข้อมูลอะไร เหมือนมี audit trail — จำเป็นมากเวลาต้องดีบักหรืออธิบายผลลัพธ์ให้คนอื่นฟัง
Code as Truth
ใช้โค้ดเป็นแหล่งความจริงหลัก แทนที่จะพึ่งการตีความของโมเดลล้วนๆ — ลดการเดา ลด hallucination
Agent Visibility
กำหนดชัดว่า agent แต่ละตัวเข้าถึงข้อมูลส่วนไหนได้บ้าง — คุมขอบเขตการมองเห็น ป้องกันข้อมูลรั่วหรือ agent ทำเกินหน้าที่
ที่สำคัญ Shum ไม่ได้แค่พูดทฤษฎี แต่เธอสาธิต engineering harness ที่สร้างบน knowledge graph จริงๆ ด้วย — อันนี้คือส่วนที่ทำให้งานนำเสนอของเธอน่าสนใจกว่าคนอื่นที่พูดเรื่อง agentic AI ลอยๆ เพราะ harness ตัวนี้ทำหน้าที่ streamline feedback loop หมายความว่าเมื่อ agent ทำงานผิดหรือได้ผลลัพธ์ไม่ดี เราสามารถป้อน feedback กลับเข้าไปในระบบได้อย่างเป็นระบบ ไม่ใช่แก้กันแบบงูๆ ปลาๆ
อีกเรื่องที่เธอแตะคือ token usage optimization ซึ่งคนที่เคยทำ agent ใช้จริงจะรู้ว่าอันนี้คือจุดเจ็บที่สุด เพราะยิ่ง agent ดึงข้อมูลเยอะ ยิ่งเผา token เร็ว ค่าใช้จ่ายบานปลาย และ latency ก็พุ่ง การมี knowledge graph ที่จัดโครงสร้างดีช่วยให้ agent ดึงเฉพาะข้อมูลที่เกี่ยวข้องจริงๆ ไม่ต้องลากทุกอย่างเข้ามาใน context window ให้เปลือง
แต่ที่ผมคิดว่าน้ำหนักที่สุดคือเรื่อง system reliability — Shum ย้ำว่าระบบ agent ที่จะใช้ในงานจริงต้องเชื่อถือได้ ซึ่งจะเชื่อถือได้ก็ต่อเมื่อเราควบคุมสิ่งที่มันเห็น สิ่งที่มันตัดสินใจ และที่มาของการตัดสินใจนั้นได้ทั้งหมด ซึ่ง RAG เปล่าๆ ให้ไม่ได้
ถ้ายังคิดว่า agentic AI คือแค่ต่อ LLM เข้ากับ vector database แล้วจบ ข่าวนี้คือสัญญาณว่าคุณกำลังสร้างระบบที่จะพังตอน scale จริง — knowledge graph ไม่ใช่ buzzword แต่เป็นโครงสร้างพื้นฐานที่ขาดไม่ได้ถ้าอยากให้ agent ทำงานได้อย่างที่ควรจะเป็นใน production
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 3
กำลังโหลดความคิดเห็น...