Graph Engineering มีสองความหมายที่คนใช้ปนกัน และมันสร้างปัญหา

โดย Nokka (นก-กา) | 14 กันยายน 2026

บทความนี้เขียนโดย AI (โมเดล deepseek-v4.1-flash ของผู้ให้บริการ ollama-cloud) ผ่าน Hermes Agent จาก Nous Research ตรวจสอบและเรียบเรียงโดย Nokka

มีคำหนึ่งที่คนพูดกันมากในเดือนกันยายน 2026 และคนพูดถึงมันหมายถึงคนละอย่าง

คำนั้นคือ graph engineering

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

บทความแรก: graph คือแผนที่ว่าความรู้อยู่ตรงไหน

วันที่ 13 กันยายน 2026 Charlie Hills เขียนบทความชื่อ "Graph engineering (for normal people)" บน Substack ที่มีผู้ติดตามกว่า 72,000 คน [1]

ปัญหาที่เขาเจอ: เขาสั่งให้ Claude Code สแกนโฟลเดอร์งานของตัวเอง แล้วผลที่ได้คือ [1]

สแกน 2,364 เอกสาร พบ 1,840 ไฟล์ที่ไม่มีอะไรชี้ไปหา คิดเป็น 78%

และประโยคที่คมที่สุดของเขา [1]

"โฟลเดอร์ที่ AI ของคุณไม่เคยเปิด อ่านได้เหมือนโฟลเดอร์ว่างเปล่าเป๊ะ และนั่นคือกับดัก"

วิธีแก้ของเขาใช้ 4 prompts โดยตัวแรกสั่งให้ AI อ่านทุกไฟล์แล้วเขียนไฟล์ MAP.md ขึ้นมา 4 ส่วน [1]

• ทุกหัวข้อที่พบ พร้อมไฟล์ที่ครอบคลุม เรียงตามจำนวนไฟล์ที่ชี้มา
• จำนวนไฟล์ที่ไม่มีอะไรชี้ถึง เป็นตัวเลขและเปอร์เซ็นต์
• ความเชื่อมโยงที่เจ้าของไม่น่าจะเห็นเอง
• header บอกว่าอ่านกี่ไฟล์และวันที่

และกฎที่ผมคิดว่าฉลาดที่สุดในบทความนี้ [1]

"ทำเครื่องหมายทุกความเชื่อมโยงว่า FOUND คือทั้งสองไฟล์ระบุเอง หรือ GUESSED คือคุณอนุมานขึ้นมา ห้ามนำสิ่งที่เดามาเสนอเป็นสิ่งที่พบ"

เขาให้เหตุผลว่าถ้าไม่มีคำเดียวนี้ [1]

"คุณแยกข้อเท็จจริงออกจากความเดาไม่ได้ และคุณจะลงเอยด้วยการเชื่อความเดา"

ผลจริงของเขา: ประมาณครึ่งหนึ่งของความเชื่อมโยงมาแบบ FOUND อีกครึ่ง GUESSED [1]

บทความที่สอง: graph คือเส้นทางที่งานเดิน

ห่างกันไม่กี่วัน แหล่งอื่นอธิบาย graph engineering ในความหมายที่ต่างกันโดยสิ้นเชิง

V12 Labs นิยามว่าเป็น "การออกแบบว่า agent เครื่องมือ โค้ดที่ตัดสินใจได้ ตัวตรวจสอบ ข้อมูล และคน เชื่อมกันอย่างไรเพื่อทำงานให้เสร็จ" [2]

ที่นี่ node คืองาน และ edge คือการอนุญาตให้ไปขั้นถัดไป [2]

ตารางของเขาแยกองค์ประกอบไว้ 8 ตัว [2]

องค์ประกอบ	ความหมาย
Node	หน่วยงาน: agent, model call, tool, validator, คน
Edge	เส้นทางที่อนุญาตจาก node หนึ่งไปอีก node
State	ข้อเท็จจริงที่ต้องส่งต่อ
Router	ตรรกะเลือกเส้นทางถัดไป
Fan-out / fan-in	งานขนานที่แยกออกเป็นกิ่งแล้วรวมกลับ
Gate	การทดสอบ การตรวจ งบประมาณ หรือการอนุมัติที่บล็อกไม่ให้ไปต่อ
Cycle	เส้นทางที่ย้อนกลับไป node ก่อนหน้าเพื่อแก้หรือลองใหม่
Termination	เงื่อนไขที่บอกว่าจบ สำเร็จ หรือ escalate

และประเด็นอยู่ตรงนี้

คำว่า graph ในสองบทความนี้หมายถึงคนละสิ่ง

• ของ Charlie Hills: แผนที่ว่าเอกสารเชื่อมกับเอกสารอย่างไร เพื่อให้ AI หาไฟล์เจอ
• ของ V12 Labs: ผังว่า งานไหลไปทางไหน เพื่อให้ระบบ ตัดสินใจและกู้คืนได้

และ V12 Labs เตือนเรื่องนี้ไว้เองด้วย [2]

V12 Labs ระบุไว้แบบนี้

"graph engineering ไม่ใช่สิ่งเดียวกับ knowledge-graph engineering, GraphRAG หรือ graph neural networks ..."

และอธิบายต่อว่า

"ส่วน agent graph engineering ใช้กราฟเพื่อแทน execution และ control flow เป็นหลัก ระบบหนึ่งใช้ทั้งสองได้ แต่มันแก้ปัญหาต่างกัน"

Eigent แยกให้ชัดกว่านั้นอีก โดยแบ่งเป็นสองชนิด [3]

• Work graphs: บอกว่า agent ทำอะไร โดย node คือ tool, skill, ไฟล์ และงานย่อย

• Improvement graphs: บอกว่า agent ตัดสินใจเปลี่ยนตัวเองอย่างไร เมื่อเวลาผ่านไป

ในกรอบนี้ Charlie Hills กำลังทำ work graph ส่วน V12 Labs พูดถึง control flow

แล้วทำไมความสับสนนี้ถึงมีปัญหา

หนึ่ง: คำแนะนำจากคนหนึ่งใช้กับอีกคนไม่ได้

ถ้าคุณอ่านบทความสาย control flow แล้วคิดว่าต้องไปสร้างแผนที่เอกสาร คุณจะเสียเวลากับงานที่ไม่เกี่ยวกับปัญหาของคุณ

กลับกัน ถ้าคุณมีปัญหา "AI หาไฟล์ไม่เจอ" แล้วไปสร้าง router กับ gate คุณจะได้ระบบที่ซับซ้อนขึ้นโดยไม่แก้อาการ

สอง: คุณภาพของกราฟวัดคนละแบบ

กราฟความรู้วัดที่ ความครอบคลุม ว่าไฟล์ไหนยังเข้าถึงไม่ได้

กราฟควบคุมวัดที่ ความน่าเชื่อถือ ว่าเมื่อล้มเหลวแล้วกู้คืนได้ไหม

ไม่มีตัวชี้วัดตัวไหนใช้แทนกันได้

สาม: และนั่นทำให้คำว่า graph engineering เองไม่มีความหมาย

V12 Labs เขียนเองว่า "คำนี้เคลื่อนไหวเร็วกว่าคำนิยามของมัน" และระบุตรง ๆ ว่า [2]

"คำว่า graph engineering ไม่ได้เป็นของเฟรมเวิร์กใด มันเป็นป้ายกว้าง ๆ สำหรับการตัดสินใจเรื่องการประสานงานให้เป็นเรื่องที่ตั้งใจทำ"

จุดที่สองความหมายบรรจบกัน

แต่ทั้งสองฝั่งเห็นตรงกันในเรื่องหนึ่ง ซึ่งผมคิดว่าสำคัญที่สุด

ความล้มเหลวที่แท้จริงไม่ได้อยู่ที่ตัว node แต่อยู่ที่การเชื่อม

V12 Labs ระบุว่า ราว 42% ของความล้มเหลวในระบบ multi-agent มาจากการส่งต่องานที่กำกวม [4]

ส่วน Charlie Hills พบว่า 78% ของไฟล์เขาไม่มีอะไรเชื่อมถึง [1]

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

และมีบริบทที่ทำให้เรื่องนี้ไม่ใช่ปัญหาชายขอบ [5]

กว่า 60% ของเหตุการณ์ใน production agent เกิดจากความล้มเหลวของการจัดการ state agent สูญเสีย context กลางคัน ทำงานซ้ำ หรือ crash แล้วกู้ไม่ได้

วิธีแยกให้ออกว่าคุณต้องการอันไหน

ผมสรุปเป็นคำถามเดียว

ถามว่า: "ปัญหาของฉันคือหาไม่เจอ หรือตัดสินใจไม่ได้"

อาการที่เจอ	กราฟที่ต้องใช้
AI หยิบไฟล์ผิด หาเอกสารไม่เจอ	งาน (knowledge / work graph)
งานค้างกลางทาง รันซ้ำ ไม่กู้คืน	ควบคุม (control graph)
ต้องมีคนอนุมัติก่อนทำอะไรที่ย้อนกลับไม่ได้	ควบคุม
ความรู้กระจัดกระจาย คนใหม่หาไม่เจอ	งาน
ต้องบันทึกว่างานอยู่ขั้นไหน	ควบคุม (ส่วน state)

Charlie Hills มีประโยคที่อธิบายความต่างนี้ได้ดี

เขาเชื่อม 4 ชั้นที่คนมักสับสนเข้าด้วยกัน [1]

• Context: สิ่งที่โมเดลเห็นในหน้าต่างตอนนี้
• Harness: กฎและไฟล์ที่อ่านก่อนเริ่มงาน
• Loop: การให้ AI ตรวจตัวเองวนจนผ่าน
• Graph: ของของคุณอยู่ที่ไหน และอะไรเชื่อมกับอะไร

และเขาวางภาพว่า graph ป้อน harness แล้ว harness โหลด context แล้ว run เจอ gate แล้ววนกลับเมื่อไม่ผ่าน [1]

ในนิยามนี้ graph ของเขาคือชั้นความรู้ ซึ่งอยู่ล่างกว่า loop

ขณะที่ในอีกนิยามหนึ่ง graph ครอบ loop อยู่ข้างใน

ข้อควรระวัง

หนึ่ง ผมไม่ได้สร้างทั้งสองระบบนี้ด้วยตัวเอง บทความนี้อ้างจากบทความต้นทางของทั้งสองฝ่ายและเอกสารที่เกี่ยวข้องเท่านั้น [1][2]

สอง ตัวเลข 2,364 เอกสาร · 1,840 ไฟล์ · 78% เป็นผลจากโฟลเดอร์ของ Charlie Hills เอง ไม่ใช่ค่ามาตรฐานที่ทุกคนจะเจอ [1]

เขายังรายงานอีกชุดจากโฟลเดอร์ newsletter โดยเฉพาะ คือ 309 เอกสาร · 223 ไฟล์ที่ไม่มีอะไรชี้ถึง [1]

สาม ตัวเลข 42% ของการส่งต่องานที่กำกวม และ 60% ของความล้มเหลวด้าน state มาจากงานศึกษาและรายงานของบริษัทที่ขายเฟรมเวิร์ก ซึ่งควรอ่านในฐานะตัวเลขจากผู้ขาย ไม่ใช่การวัดอิสระ [4][5]

สี่ การตีความว่า Charlie Hills กำลังทำ work graph และ V12 Labs พูดถึง control flow เป็นการอ่านของผมเอง ไม่มีฝ่ายใดระบุว่าตัวเองอยู่ในหมวดไหน [1][2][3]

ห้า ชื่อเรียก loop engineering และ graph engineering ยังไม่นิ่ง ทั้งสองฝ่ายระบุว่าคำเหล่านี้อาจหายไปเร็วเหมือนที่ loop engineering หายไป [1][2]

หก ผมทำงานบนระบบที่ใช้โมเดล AI และเขียนบทความนี้ด้วยความช่วยเหลือของ AI [6]

สรุป

ผมไม่คิดว่าความสับสนนี้จะหายไป เพราะทั้งสองฝ่ายไม่ได้ผิด กราฟทั้งสองแบบมีอยู่จริง และทั้งคู่แก้ปัญหาจริง

แต่ถ้าคุณเพิ่งเริ่มและกำลังอ่านบทความเรื่อง graph engineering อยู่ตอนนี้ คำถามแรกที่ควรถามไม่ใช่ "ฉันควรสร้างกราฟไหม"

แต่ควรถามว่า "graph ในบทความนี้หมายถึงอะไร"

และถ้าตอบไม่ได้จากบทความนั้น นั่นอาจเป็นสัญญาณว่าบทความนั้นยังไม่ได้นิยามสิ่งที่ตัวเองพูดถึงให้ชัดพอ

บทความที่เกี่ยวข้อง

ผมเขียนอีกชิ้นที่ตอบคำถามว่า "งานแบบไหนควรใช้ loop แบบไหนควรใช้ graph" พร้อมตัวอย่างจริง 5 งาน ทั้ง paid media, content pipeline, incident response และ technical SEO

ถ้าคุณกำลังตัดสินใจว่าจะสร้างระบบแบบไหน อ่านคู่กันแล้วจะเห็นภาพครบกว่า

👉 งานไหนควรใช้ Loop งานไหนควรใช้ Graph พร้อมตัวอย่างจากของจริง

แหล่งอ้างอิง

[1] Hills, C., "Graph engineering (for normal people)", MarTech AI (13 ก.ย. 2026), https://charliehills.substack.com/p/graph-engineering-claude-code

[2] "Graph Engineering, Explained: Why AI Agent Systems Are Moving Beyond One Loop", V12 Labs (17 ส.ค. 2026), https://www.v12labs.io/blog/2026-08-17-graph-engineering-explained

[3] "Graph Engineering for AI Agents: Beyond Single Feedback Loops", Eigent, https://www.eigent.ai/blog/graph-engineering-ai-agents

[4] Shah, M., "AI Agents for Incident Management: Architecture and Production Patterns", Augment Code, https://www.augmentcode.com/guides/ai-agents-incident-management

[5] "What is LangGraph? State, Agents, and Production Use Cases (2026)", Atlan, https://atlan.com/know/ai-agent/ai-agent-memory/what-is-langgraph/

[6] การเปิดเผยของผู้เขียน: บทความนี้เขียนโดยใช้ AI