รู้จัก ‘Graph Engineering’ เทคนิคจัดระเบียบ AI ให้ทำงานดีขึ้น เทรนด์ใหม่ของการออกแบบ AI Workflow

คำว่า Graph Engineering โผล่ขึ้นมาถี่จนกลายเป็นศัพท์ประจำวันของนักพัฒนา AI ในช่วงไม่กี่เดือนที่ผ่านมา และคนจำนวนไม่น้อยเข้าใจผิดตั้งแต่แรกว่าเป็นเรื่องเดียวกับ Knowledge Graph หรือการทำแบบจำลองข้อมูล ล่าสุด Google ออกมาอธิบายแนวคิดนี้ผ่านคลิป Graph Engineering 101 บนช่อง Google for Developers พร้อมปล่อยบทเรียนแบบลงมือทำ (Codelab) ชื่อ ADK 2 Orchestration: Graph, Collaborative & Dynamic Workflows ให้นักพัฒนาสร้างระบบตามไปด้วยได้จริง

สาระสำคัญของ Graph Engineering คือการออกแบบระบบ AI Agent ให้อยู่ในรูปของกราฟงานที่วาดไว้ล่วงหน้า วิธีที่ Google ใช้อธิบายคือให้นึกถึงผังองค์กร แต่ละโหนด (Node) ในผังคือหนึ่งขั้นตอนของงาน บางโหนดเป็น Agent Node ที่ให้โมเดลคิดและตัดสินใจ บางโหนดเป็น Function Node ที่รันตรรกะแบบกำหนดผลลัพธ์ได้แน่นอนโดยไม่ต้องเรียกโมเดลเลย จากนั้นจึงเชื่อมโหนดเหล่านี้เข้าด้วยกันเป็นเส้นทางเดียวที่ใช้แก้ปัญหา

Harness, Loop และ Graph สามคำที่คนสับสนกันมากที่สุด

ก่อนจะไปต่อ ต้องแยกศัพท์สามคำนี้ให้ออกก่อน เพราะเป็นจุดที่ทำให้หลายคนอ่านเอกสารแล้วหลง

• ชุดโครงรอบโมเดล (Harness) คือทุกอย่างที่ห่อหุ้มโมเดลอยู่ ตั้งแต่เครื่องมือที่โมเดลเรียกใช้ได้ หน่วยความจำ ไปจนถึงรั้วกันความเสี่ยง (Guardrails)
• วงรอบการทำงาน (Loop) คือรอบที่ Agent วิ่งอยู่ภายในโครงนั้น โมเดลคิด ตัดสินใจ หยิบเครื่องมือมาใช้ แล้ววนกลับไปคิดใหม่ ทำแบบนี้ซ้ำจนกว่าจะแก้ปัญหาได้ตามเป้าหมาย
• ส่วน Graph คือผังองค์กรที่กล่าวถึงข้างต้น เป็นชั้นที่อยู่เหนือขึ้นไปอีก ทำหน้าที่กำหนดว่างานจะเดินผ่านโหนดไหนบ้างและเรียงลำดับอย่างไร

สิ่งที่ทำให้กราฟเดินได้จริงคือสถานะร่วม (Shared State) เมื่อสร้างระบบหลาย Agent ด้วย Agent Development Kit (ADK) ของ Google ทุก Agent จะแชร์สถานะเดียวกัน เช่นเดียวกับโหนดต่าง ๆ ในหนึ่งเวิร์กโฟลว์ ข้อมูลและบริบทจึงถูกส่งต่อลงไปตามเส้นทางของกราฟได้โดยไม่ต้องให้แต่ละโหนดไปตามหาเอง

ถอดรื้อระบบรีวิวโค้ดอัตโนมัติ ตัวอย่างที่ทำให้เห็นภาพชัดที่สุด

ตัวอย่างที่ Google เลือกมาใช้อธิบายคือการรีวิว Pull Request (PR) ซึ่งเป็นงานที่นักพัฒนาส่วนใหญ่รู้ขั้นตอนอยู่แล้วว่าต้องทำอะไรก่อนหลัง เมื่อรู้เวิร์กโฟลว์ล่วงหน้า จึงวาดกราฟออกมาได้ทันที และเวิร์กโฟลว์นี้แบ่งเป็นสามส่วน

1. การกระจายงาน (Fan-out) เปิดการประมวลผลแบบขนาน (Parallel Processing) ห้าสายพร้อมกันเพื่อดึงข้อมูลของ Pull Request นั้นมาให้ครบ แทนที่จะทำทีละอย่างแล้วรอต่อคิวกัน
2. โหนดรวมผล (Join Node) ทำหน้าที่รอสายที่ช้าที่สุดให้เสร็จ แล้วสังเคราะห์ผลลัพธ์ทั้งหมดเข้าด้วยกันเป็นก้อนเดียวที่พร้อมส่งต่อ
3. ตัวจัดเส้นทาง (Router) ตัดสินว่าข้อมูลก้อนนั้นจะไปทางไหนต่อ ในตัวอย่างนี้เงื่อนไขคือถ้าโค้ดไม่ผ่าน ให้ส่งต่อไปยัง Agent เฉพาะทางที่ทำหน้าที่แก้ไข แต่ถ้าโค้ดผ่าน ให้ส่งเข้าขั้นตอนขออนุมัติจากมนุษย์

หลักการของ Router ใกล้เคียงกับ Router บนเซิร์ฟเวอร์ที่รับ URL เข้ามาแล้วจับคู่กับหน้าเว็บที่ต้องเสิร์ฟ ต่างกันตรงที่ปลายทางเปลี่ยนจากหน้าเว็บเป็น Agent ย่อย ผู้เชี่ยวชาญเฉพาะทาง หรือเวิร์กโฟลว์อีกชุดหนึ่ง

Graph Engineering ไม่ใช่ Knowledge Graph และไม่ใช่ GraphRAG

ความสับสนเกิดจากศัพท์ที่มีคำว่า Graph อยู่เต็มไปหมด ทั้ง Graph Engineering, GraphRAG และ Knowledge Graph ทั้งที่ทั้งสามคำนี้พูดคนละเรื่องกัน

เส้นแบ่งที่ชัดที่สุดคือ Knowledge Graph ให้ความสำคัญกับข้อมูล ว่าข้อมูลแต่ละชิ้นสัมพันธ์กันอย่างไร ส่วน Graph Engineering ให้ความสำคัญกับพฤติกรรมของระบบ ว่า 'อะไรเข้ามาก่อน เรียงลำดับอย่างไร แล้วเกิดอะไรขึ้นต่อ' ซึ่งก็คือสิ่งที่ตัวอย่างรีวิวโค้ดข้างต้นแสดงให้เห็น

เมื่อไรควรใช้ Loop และเมื่อไรควรวาดเป็น Graph

อีกคำที่มาคู่กันคือ Loop Engineering ซึ่งคือการปล่อยให้ Agent วนอยู่ในลูปเดียวไปเรื่อย ๆ จนกว่าจะบรรลุเป้าหมาย ต่างจาก Graph Engineering ที่วางกราฟไว้ก่อน แล้วให้งานเดินผ่านโหนดและเส้นเชื่อมที่กำหนดไว้

เกณฑ์เลือกใช้ค่อนข้างตรงไปตรงมา งานที่โจทย์ไม่ซับซ้อน เช่น ขอบทสรุปหนึ่งย่อหน้า ใช้ลูปเดียวก็จบ แต่งานที่มีชิ้นส่วนเยอะและมีเงื่อนไขหลายชั้น เช่น การผลิตเอกสารความยาวห้าสิบหน้าที่มีทั้งกราฟิกและองค์ประกอบหลายแบบ การวาดเป็นกราฟจะคุมผลลัพธ์ได้ดีกว่ามาก

Graph Engineering กับ Agent Swarm ต่างกันที่ใครเป็นคนกำหนดเส้นทาง

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

ใน Graph Engineering วิศวกรเป็นคนนิยามทุกโหนดเอง ว่าแต่ละขั้นตอนเกิดอะไรขึ้น หน้าตาข้อมูลเป็นอย่างไร และ Agent ที่อยู่ในโหนดหนึ่งไม่จำเป็นต้องรู้ว่าก่อนหน้านั้นเกิดอะไรขึ้นมาบ้าง ผลที่ได้คือระบบที่คาดเดาผลลัพธ์ได้ ไล่หาจุดผิดพลาดได้ และควบคุมได้ ซึ่งเหมาะกับปัญหาที่นิยามขอบเขตได้ชัดอย่างเวิร์กโฟลว์รีวิวโค้ด

แต่ไม่ใช่ทุกปัญหาที่นิยามได้ขนาดนั้น กรณีที่โจทย์คลุมเครือ Agent Swarm จะยืดหยุ่นกว่า เพราะแต่ละ Agent ได้รับแค่บุคลิกของตัวเองแล้วโยนปัญหาเข้าไปให้ช่วยกันแก้ โดยไม่ต้องกำหนดเส้นทางล่วงหน้า สรุปสั้น ๆ คือถ้ารู้ขั้นตอนอยู่แล้วให้ใช้กราฟ ถ้ายังไม่รู้ว่าคำตอบจะมาจากทางไหนให้ใช้ Swarm

Codelab ที่ Google เตรียมไว้ให้ลองของจริง

สำหรับคนที่อยากลงมือทำ Codelab ตัวใหม่ของ Google พาสร้างแอปพลิเคชันชื่อ Marathon Race Day Coach ที่ให้คำแนะนำเรื่องกลยุทธ์การวิ่งและการคุมจังหวะ โดยไล่สร้างทีละระดับรวมเก้าระดับ ใช้ ADK เวอร์ชัน 2 บน Python คู่กับโมเดล Gemini

โครงสร้างของบทเรียนเริ่มจากการโชว์ปัญหาก่อน ด้วยการใช้พรอมต์ก้อนใหญ่ก้อนเดียวจนระบบกุข้อมูลที่ไม่เคยดึงมาจริง เช่น สภาพอากาศและบันทึกการซ้อม เพื่อให้เห็นว่าทำไมโครงสร้างถึงจำเป็น จากนั้นค่อยไล่ขึ้นไปทีละชั้น ตั้งแต่ Agent เดี่ยว เวิร์กโฟลว์ที่ผสม Function Node กับ Agent Node การกระจายงานแบบขนานพร้อมโหนดรวมผล ไปจนถึงเวิร์กโฟลว์ที่รูปร่างเปลี่ยนไปตามอินพุตและเรียกตัวเองซ้ำได้

บทเรียนปิดท้ายด้วยแนวทางเลือกใช้รูปแบบที่ตอบง่ายกว่าที่คิด นั่นคือถามตัวเองว่าวาดWorkflow ออกมาได้ไหมก่อนที่อินพุตจะเข้ามา ถ้าวาดได้ให้ใช้ Graph Workflow ถ้ารู้ว่ามีทีมงานชุดไหนบ้างแต่แต่ละคำขอเลือกใช้ไม่เหมือนกัน ให้ใช้ Collaborative Agents ที่ปล่อยให้โมเดลตัดสินว่าจะเรียกใครต่อ และถ้ารูปร่างของงานขึ้นอยู่กับอินพุตจริง ๆ ให้ใช้ Dynamic Workflows ที่โค้ดตัดสินใจตอนรันไทม์ ทั้งสามรูปแบบประกอบร่วมกันได้ โหนดในกราฟจะบรรจุตัวประสานงานแบบ Collaborative ไว้ข้างในก็ทำได้เช่นกัน

เมื่อดูภาพรวมทั้งหมด สิ่งที่ Graph Engineering ทำก็คือการหยิบหลักการควบคุมลำดับการทำงานที่วิศวกรซอฟต์แวร์ใช้กันมานาน กลับมาใช้กับระบบ AI อีกครั้ง จนคนในคลิปเองยังตั้งคำถามติดตลกว่าทั้งหมดนี้คือการประดิษฐ์โครงสร้างข้อมูลและอัลกอริทึม (Data Structures and Algorithms) ขึ้นมาใหม่สำหรับยุค Agent หรือเปล่า และเทรนด์ถัดไปอาจจะเป็น Hashtable Engineering หรือ Stack Engineering ก็ได้ ซึ่งถ้ามองจากทิศทางที่เครื่องมืออย่าง ADK กำลังเดินอยู่ คำตอบก็คงไม่ไกลจากนั้นมากนัก

ที่มา: Google for Developers, Google Codelabs