เมื่อโยนงานก้อนใหญ่ให้ Claude Code หรือ Codex จัดการในแชทเดียว คำตอบที่ได้อาจดูเรียบร้อยและน่าเชื่อเมื่ออ่านผ่าน ๆ แต่พอไล่ทีละบรรทัดกลับพบว่าพลาดมาตั้งแต่ข้อสมมติแรก ทางแก้ที่คนมักนึกถึงก่อนคือเขียน prompt ให้ดีขึ้น หรือป้อน context ให้ครบกว่าเดิม

graph engineering เข้ามาเสริมสองอย่างนี้อีกชั้นหนึ่ง ถ้า prompt engineering คือการสั่งงาน AI ให้ดีขึ้น และ context engineering คือการป้อนข้อมูลให้ AI ได้ดีขึ้น graph engineering ก็คือการออกแบบโครงสร้างของงานรอบ AI เพื่อไม่ให้งานทั้งชิ้นต้องจบอยู่ในแชทก้อนเดียว

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

กราฟในวงการ AI มีสองแบบ ต้องรู้ก่อนว่ากำลังสร้างอันไหน

คำว่า graph ในวงการ AI ใช้เรียกของสองอย่างที่ทำหน้าที่ต่างกัน และความหมายสองแบบนี้เองที่ทำให้คนสับสนกันมากที่สุด

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

agent graph กำกับว่างานเดินยังไง: planner แจกงานให้ researcher หลายตัวทำพร้อมกัน skeptic ตรวจผลที่ได้ synthesizer รวมชิ้นส่วนเข้าด้วยกัน แล้วมนุษย์ค่อยเคาะคำตอบสุดท้าย

จากนี้บทความจะพูดถึงแบบหลังเท่านั้น เพราะ founder ครีเอเตอร์ หรือทีมเล็ก ๆ เริ่มใช้ได้ตั้งแต่วันนี้ ศัพท์ที่ต้องใช้มีแค่สามคำ: job คือสเต็ปหนึ่งของงาน arrow บอกว่าจะเกิดอะไรต่อจากสเต็ปนั้น ส่วน state คือบันทึกร่วมของสิ่งที่ระบบรู้แล้ว ซึ่งจะไหลผ่านทุกสเต็ปไปจนจบเส้นทาง

Diamond Pattern คือรูปทรงแรกที่ควรหัดวาด

กราฟแรกที่ควรหัดวาดเรียกว่า The Diamond Pattern ตัวอย่างนี้เริ่มจากคำถามว่าควรทำโปรดักต์ AI สำหรับงานบัญชีของร้านค้าบน Shopify ไหม จากนั้น planner จะแตกคำถามเป็นสามเลนที่ทำงานขนานกัน คือฝั่งลูกค้าและปัญหาเรื่องบัญชี ฝั่งคู่แข่ง และฝั่งช่องทางเข้าถึงลูกค้า ทั้งสามเลนไม่ได้พึ่งพากัน การหาข้อมูลลูกค้าไม่ต้องรอผลจากฝั่งคู่แข่ง จึงไม่มีเหตุผลให้ทำเรียงกันทีละเลน

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

เปลี่ยนงานที่ทำซ้ำอยู่แล้วให้เป็นกราฟ

วิธีเริ่มที่เสียแรงน้อยที่สุดคือไม่ต้องคิดงานใหม่ แค่เลือกงาน AI ที่ทำซ้ำอยู่แล้วทุกสัปดาห์มาหนึ่งงาน แล้วไล่ตามนี้

1. เขียนผลลัพธ์สุดท้ายที่ต้องการออกมาเป็นประโยคเดียว
2. ไล่ดูว่าถ้าให้คนที่เก่งเรื่องนี้ลงมือ เขาจะทำอะไรบ้าง แล้วเขียนแต่ละอย่างออกมาเป็นหนึ่ง job
3. ลากลูกศรเฉพาะตรงที่สเต็ปหนึ่งต้องใช้ผลจากอีกสเต็ปจริง ๆ ส่วนสเต็ปที่ไม่ต้องรอกันให้เดินขนานกันไป
4. วางจุดอนุมัติของมนุษย์ไว้หนึ่งจุดก่อนถึงสเต็ปที่พลาดแล้วแพง ส่วน memo ที่อ่านกันเองภายในใช้ gate หลวม ๆ ได้ แต่อีเมลถึงลูกค้า โพสต์สาธารณะ การ deploy โค้ด การคืนเงิน หรืออะไรก็ตามที่แตะข้อมูล production ต้องใช้ gate ที่เข้มกว่านั้น
5. เดินทั้งกราฟด้วยมือหนึ่งรอบ

ถ้าเป็นงานโค้ด กราฟอาจเริ่มจากการวางแผน แล้วแยกให้ agent ตัวหนึ่งแก้โค้ด อีกตัวรีวิว diff อีกตัวรันเทสต์ อีกตัวเปิดเบราว์เซอร์ดู UI จริง และอีกตัวไล่หา edge case ก่อนจบที่คนกดอนุมัติ pull request ปลายทางของทุกสายคือตัวตรวจที่ไม่ได้เขียนงานชิ้นนั้นเอง

เมื่อเดินกราฟด้วยมือแล้วงานดีขึ้นจริง ค่อยขยับขึ้นไปขั้นถัดไป

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

กราฟที่ควรสร้าง กับกราฟที่แค่ดูดี

กับดักถัดมาคือการคิดว่ายิ่งมี agent มาก งานยิ่งดี ทั้งที่จำนวน agent อาจเพิ่มเสียงรบกวนได้พอ ๆ กับเพิ่มคุณภาพงาน เช่น AI หลายตัวอาจพูดไอเดียผิดเรื่องเดียวกันซ้ำ ๆ ด้วยน้ำเสียงมั่นใจ หรือระบบอาจเสียเวลาไปกับการประสานงานกันเองมากกว่าคิดงาน เป้าหมายจึงเป็นกราฟที่เล็กที่สุดเท่าที่จะทำให้คุณภาพงานดีขึ้นได้

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

งานที่คุ้มกับการทำเป็นกราฟมักมีหลายสเต็ป ใช้ข้อมูลหลายแหล่ง มีเส้นทางที่เป็นไปได้หลายทาง มีการตรวจ มีความเสี่ยง หรือต้องขออนุมัติ ตัวอย่างเช่น deep research แผน go to market การคัดแยก support ticket การรีวิวโค้ด การเตรียมคอลขาย การสังเคราะห์ฟีดแบ็กจากลูกค้า และงานผลิตคอนเทนต์ที่ทำซ้ำเป็นรอบ ๆ ส่วนงานอย่างการคิดชื่อสิบชื่อหรือสรุปอีเมลสั้น ๆ ใช้แชทเดียวจบจะดีกว่า

graph engineering ไม่ได้ตัดสินใจแทนใคร สิ่งที่มันให้คือวิธีผลิตหลักฐานที่ดีขึ้นสำหรับใช้ตัดสินใจ

ของที่เหลืออยู่หลังกราฟเดินจบหนึ่งรอบ

เมื่อกราฟเดินจบแต่ละรอบ จะเหลือทั้งโน้ตจากการคุย หลักฐานที่รวบรวมมา ดราฟต์ แหล่งอ้างอิง และร่องรอยว่าตัดสินใจอะไรไปเพราะอะไร ของเหล่านี้จะสะสมเพิ่มขึ้นเรื่อย ๆ และเป็นคุณค่าของ graph engineering ที่คนมักมองข้ามมากที่สุด

กราฟวิจัยลูกค้าทำให้โน้ตเกี่ยวกับลูกค้าละเอียดขึ้นในทุกรอบ กราฟคอนเทนต์สะสมทั้งตัวอย่างที่ใช้ได้จริงและสิ่งที่รู้เกี่ยวกับคนดู ส่วนกราฟ support สะสมฟีดแบ็กที่ส่งกลับไปฝั่งโปรดักต์ได้ รอบถัดไปจึงมีข้อมูลพร้อมใช้มากกว่ารอบก่อนตั้งแต่เริ่ม คลิปต้นทางเรียกสิ่งที่สะสมนี้ว่า moat

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

---

ที่มา: คลิป Why Graph Engineering will 10x your Claude/Codex จากช่อง Greg Isenberg