Graph Engineering คืออะไร? คู่มือปฏิบัติการออกแบบและดูแล Knowledge Graph ในระดับโปรดักชัน

Graph Engineering หมายถึงกระบวนการทั้งหมดในการออกแบบเอนทิตี (Entity) และความสัมพันธ์ (Relation) ให้อยู่ในรูปแบบโครงสร้างกราฟที่ชัดเจน และรักษาคุณภาพให้คงอยู่จนถึงขั้นตอนการใช้งานจริง เป้าหมายคือการช่วยให้ผู้รับผิดชอบด้านฐานความรู้ (Knowledge Base) หรือ RAG สามารถทำความเข้าใจความสัมพันธ์ที่ซับซ้อน เช่น "ใคร เกี่ยวข้องกับอะไร อย่างไร" ซึ่งเป็นสิ่งที่การค้นหาเอกสารเพียงอย่างเดียวทำได้ยาก ในบทความนี้ เราจะอธิบายขั้นตอนการดำเนินงานอย่างต่อเนื่อง ตั้งแต่การเริ่มต้นจากกราฟขนาดเล็กที่ตรวจสอบได้ ไปจนถึงการกำหนดตัวชี้วัดคุณภาพ การบริหารจัดการ และการเชื่อมต่อกับ RAG เมื่ออ่านจบ คุณจะมีเกณฑ์ในการตัดสินใจออกแบบกราฟให้เหมาะสมกับข้อมูลขององค์กรคุณเอง

【ตัวอย่างสมมติ】แผนกหนึ่งได้รวบรวมข้อมูลการเรียกใช้ LLM API โดยระบุแท็กของแผนกเป็นเวลา 90 วัน ส่งผลให้ลดเวลาการทำงานในการตรวจสอบยอดเรียกเก็บเงินสิ้นเดือนลงได้ 40% โดยมีเงื่อนไขเบื้องต้นคือ "ต้องมีการระบุรหัสแผนกในทุกคำขอ" และสภาพแวดล้อมดังกล่าวเป็นการตั้งค่าที่เพิ่มคอลัมน์แท็กเข้าไปในระบบบันทึกข้อมูล (Log) เดิมที่มีอยู่เพียงคอลัมน์เดียวเท่านั้น

เกณฑ์การตัดสิน: Graph Engineering มีความแตกต่างจากการสร้าง Knowledge Graph โดยตรง ในแง่ของการมองว่าเป็นกระบวนการทางซอฟต์แวร์ (Software Engineering)

โดยทั่วไปแล้ว การสร้าง Knowledge Graph หมายถึงงานสกัดเอนทิตี (Entity) และความสัมพันธ์ (Relation) แล้วนำมาจัดระเบียบตาม Ontology ในขณะที่ Graph Engineering จะครอบคลุมไปถึงการจัดการขอบเขตผลกระทบเมื่อมีการเปลี่ยนแปลงการออกแบบ การเฝ้าติดตามดัชนีคุณภาพอย่างต่อเนื่อง และการดำเนินงานเพื่อให้ระบบสามารถรองรับการอ้างอิงจาก RAG หรือ AI Agent ได้ในระยะยาว

กล่าวคือ เป็นการบูรณาการสามส่วนเข้าด้วยกัน ได้แก่ ชั้นการออกแบบ (Design Layer) ที่ใช้มาตรฐาน W3C เช่น RDF, SPARQL, OWL และ SHACL ในการกำหนด Schema และข้อจำกัดของข้อมูล, ชั้นการควบคุมคุณภาพ (Quality Control Layer) ที่วัดค่าความน่าเชื่อถือและความครอบคลุมของ Edge และชั้นการเชื่อมต่อ (Integration Layer) ที่เชื่อมต่อกับระบบสืบค้นและระบบการอนุมาน (Inference System) ในโครงการสร้างกราฟแบบครั้งเดียวจบ มักเกิดกรณีที่ Schema ไม่ได้รับการอัปเดตหลังการปล่อยเวอร์ชันแรกจนกลายเป็นเพียงรูปแบบที่ไร้การใช้งานจริง ในขณะที่การทำเป็นกระบวนการในรูปแบบ Graph Engineering จะมีการรวมวงจรการจัดการการเปลี่ยนแปลงและการเฝ้าติดตามไว้ตั้งแต่ต้น

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

ในกรณีของ RAG ที่เน้นการค้นหาเอกสาร (Document Search) ระบบสามารถตอบคำถามได้ด้วยความหมายที่ใกล้เคียงกันในระดับ Chunk เดียว แต่สำหรับคำถามที่จำเป็นต้องติดตามความสัมพันธ์ระหว่างหลาย Entity การใช้เพียง Vector Search มักจะทำให้ข้อมูลอ้างอิงกระจัดกระจาย ตัวอย่างเช่น คำถามประเภท "กลุ่มสัญญาที่เกี่ยวข้องกับบริษัทแม่ของคู่ค้ารายหนึ่ง" นั้น การค้นหาความคล้ายคลึงในระดับเอกสารไม่สามารถสร้างห่วงโซ่ความสัมพันธ์ขึ้นมาใหม่ได้

เบื้องหลังเรื่องนี้คือการสั่งสมองค์ความรู้มายาวนานในด้าน Search Engine และเทคโนโลยีเว็บ โดย schema.org เริ่มต้นขึ้นในปี 2011 จากความร่วมมือของเหล่าผู้ให้บริการ Search Engine และในปี 2012 Google ได้เปิดตัว Knowledge Graph ซึ่งเป็นการจัดโครงสร้างความสัมพันธ์ระหว่าง Entity จากแหล่งข้อมูลต่างๆ เช่น Freebase, Wikipedia และ CIA World Factbook บนพื้นฐานของการสั่งสมองค์ความรู้นี้เอง ทำให้เกิดแนวทางอย่าง GraphRAG ซึ่งเป็นวิธีการนำโครงสร้างกราฟมาคั่นกลางระหว่างการค้นหาและการสร้างเนื้อหา ที่เริ่มเป็นรูปธรรมมากขึ้นในงานวิจัยตั้งแต่ปี 2024 เป็นต้นมา

จากแนวโน้มดังกล่าว Knowledge Graph จึงเปลี่ยนสถานะจากแนวคิดในเชิงวิจัยไปสู่การเป็นองค์ประกอบสำคัญของระบบที่ใช้งานจริง ในขณะเดียวกัน เนื่องจากทั้งการเปลี่ยนแปลง Schema และคุณภาพของ Edge ที่ลดลงส่งผลกระทบโดยตรงต่อผลลัพธ์ของ AI Agent จึงจำเป็นต้องมีการออกแบบในฐานะกระบวนการดำเนินงาน (Operation) ไม่ใช่เพียงแค่ขั้นตอนการสร้างเท่านั้น

กระบวนการออกแบบของ Graph Engineering จะเลือกใช้วิธีที่แตกต่างกันไปตามความชัดเจนของโครงสร้างข้อมูลเป้าหมาย หากเป็นข้อมูลทางธุรกิจที่มีสคีมา (Schema) คงที่ จะเหมาะกับการออกแบบที่เข้มงวดโดยอิงตาม RDF หรือ SHACL แต่หากเน้นการสกัดข้อมูลจากเอกสารที่ไม่มีโครงสร้าง จะเหมาะกับการออกแบบเชิงวนซ้ำ (Iterative design) ที่มีหัวใจสำคัญคือการสกัดความสัมพันธ์ด้วย LLM ต่อไปนี้คือภาพรวมของขั้นตอนทั้งหมดและจุดตัดสินใจที่สำคัญ

หากไม่แน่ใจในการตัดสินใจ แนะนำให้เริ่มจากการทำต้นแบบ (Prototype) เฉพาะสคีมาและการสกัดเอนทิตีในโดเมนขนาดเล็กก่อน จากนั้นจึงตรวจสอบความแม่นยำของความสัมพันธ์ด้วยมนุษย์ แล้วค่อยออกแบบขั้นตอนการรวมและการจัดเก็บข้อมูลตามลำดับ สิ่งสำคัญคืออย่าเพิ่งกำหนดขั้นตอนให้ตายตัวตั้งแต่แรก แต่ควรออกแบบให้สามารถย้อนกลับไปแก้ไขได้ตามผลลัพธ์ที่ตรวจสอบพบ

ควรจะกำหนด "โหนด" (Node) หรือ "เอดจ์" (Edge) ก่อน เพื่อลดการแก้ไขงานในขั้นตอนถัดไป?

ในการออกแบบเอนทิตี (Entity Design) สิ่งสำคัญคือต้องเริ่มจากการระบุ "สิ่งต่างๆ" ที่มีความหมายในเชิงธุรกิจออกมาในระดับคำนาม และหากมีหลายคำที่สื่อถึงแนวคิดเดียวกัน ให้ทำการปรับให้เป็นมาตรฐาน (Normalize) โดยใช้ชื่อนามแฝง (Alias) ตัวอย่างเช่น หากคำว่า "ลูกค้า" (Customer), "คู่ค้า" (Business Partner) และ "ไคลเอนต์" (Client) หมายถึงเอนทิตีประเภทเดียวกัน หากไม่กำหนดกฎการปรับให้เป็นมาตรฐานไว้ตั้งแต่แรก จะทำให้เกิดงานที่ต้องนำโหนดทั้งหมดในกราฟมาบูรณาการใหม่ในภายหลัง

ในการออกแบบความสัมพันธ์ (Relation Design) จุดสำคัญคือไม่ควรแบ่งประเภทความสัมพันธ์แบบกว้างเกินไป หากสร้างกราฟโดยใช้เพียงเอดจ์ทั่วไปอย่าง "เกี่ยวข้องกับ" (Related to) จะไม่สามารถกรองข้อมูลที่มีความหมายในขณะสืบค้นได้ ควรทำให้เป็นรูปธรรมโดยใช้คำกริยา เช่น "สั่งซื้อ" (Order), "สังกัด" (Belong to), "ขึ้นอยู่กับ" (Depend on) และกำหนดทิศทางรวมถึงความเป็นพหุคูณ (Multiplicity) ของเอดจ์โดยใช้ลำดับชั้นคุณสมบัติของ OWL หรือข้อจำกัดของ SHACL ตามความจำเป็น

การออกแบบประเภทของเอนทิตีและเอดจ์โดยคำนึงถึงการสืบค้นด้วย SPARQL จะช่วยเพิ่มความแม่นยำได้ ขั้นตอนที่มีประสิทธิภาพในการปฏิบัติงานจริงคือการระบุคำถามที่ต้องการคำตอบให้ชัดเจนก่อน แล้วจึงตรวจสอบว่าสามารถแปลงประโยคคำถามเหล่านั้นให้เป็นรูปแบบกราฟ (Graph Pattern) ได้หรือไม่

เกณฑ์การตัดสิน: คุณภาพการออกแบบจะไม่สามารถสังเกตเห็นการเสื่อมถอยได้หากไม่มีการกำหนดเป็นดัชนีชี้วัด

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

ไม่จำเป็นต้องทำระบบอัตโนมัติสำหรับดัชนีทั้งหมดในคราวเดียว ขั้นตอนที่เหมาะสมคือเริ่มจากดัชนีที่ตรวจสอบด้วยเครื่องมือได้ง่ายผ่านการตรวจสอบเงื่อนไขด้วย SPARQL หรือ SHACL เช่น อัตราความซ้ำซ้อนของ Entity และอัตรา Node โดดเดี่ยว แล้วจึงค่อยเพิ่มดัชนีด้านการดำเนินงาน เช่น ความล่าช้าในการอัปเดตในภายหลัง

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

หากเป้าหมายการค้นหาคือการตรวจสอบข้อเท็จจริงภายในเอกสารฉบับเดียว การใช้ RAG (Retrieval-Augmented Generation) ที่เน้นการค้นหาแบบเวกเตอร์ (Vector Search) ก็เพียงพอแล้ว แต่หากต้องการตอบคำถามเกี่ยวกับความสัมพันธ์ที่ต้องไล่เรียงผ่านหลายเอนทิตี (Entity) การค้นหาผ่านกราฟความรู้ (Knowledge Graph) จะมีประสิทธิภาพมากกว่า GraphRAG ถูกนำเสนอขึ้นมาในฐานะวิธีการที่รวมการค้นหาแบบเวกเตอร์เข้ากับการสำรวจกราฟ โดยจะรวบรวมหลักฐานไปพร้อมกับการไล่เรียงเส้นทางระหว่างเอนทิตีต่างๆ

ในทางปฏิบัติ ขั้นแรกจะใช้การค้นหาแบบเวกเตอร์หรือ BM25 เพื่อระบุโหนดที่เกี่ยวข้องกับคำค้นหา จากนั้นจึงไล่ตามเส้นเชื่อม (Edge) บนกราฟเพื่อดึงข้อมูลเอนทิตีหรือเหตุการณ์ที่เกี่ยวข้องมาเสริม ในขณะที่การค้นหาเอกสารแบบทั่วไปมักมีจุดอ่อนต่อคำถามที่ถามถึง "ความสัมพันธ์ระหว่าง A และ B" การแทรกขั้นตอนการสำรวจกราฟเข้าไปจะช่วยให้ความแม่นยำในการตอบคำถามที่มี ความสัมพันธ์หลายระดับ (Multi-hop relationships) สูงขึ้น

สำหรับการทำงานร่วมกับ AI Agent การออกแบบให้เรียกใช้กราฟเป็นเครื่องมือ (Tool) ถือเป็นวิธีที่ใช้งานได้จริง โดยมักจะใช้โครงสร้างการค้นหาแบบไฮบริดที่ให้ Agent สลับระหว่างการสำรวจกราฟและการค้นหาแบบเวกเตอร์ตามเจตนาของคำค้นหา หรือใช้เทคนิคอย่าง RRF เพื่อรวมผลลัพธ์จากทั้งสองวิธีเข้าด้วยกัน ในระบบ Multi-agent การแยก Agent ที่รับผิดชอบด้านการอัปเดตกราฟออกจาก Agent ที่รับผิดชอบด้านการค้นหา จะช่วยลดผลกระทบจากความไม่สอดคล้องของข้อมูลระหว่างการอัปเดตที่มีต่อคุณภาพของคำตอบได้

สำหรับรายละเอียดเชิงลึกของการออกแบบ สามารถอ้างอิงแนวคิดเรื่องการแบ่งบทบาทหน้าที่ได้จากบทความ Multi-agent AI คืออะไร? ตั้งแต่รูปแบบการออกแบบไปจนถึงหัวใจสำคัญของการนำไปใช้งานจริง

Q1. ในการนำ Graph Engineering มาใช้ จุดที่มักจะล้มเหลวในช่วงแรกคืออะไร?

กรณีที่พบได้บ่อยคือการพยายามออกแบบ Ontology ทั้งหมดอย่างเคร่งครัดตั้งแต่ต้น จนทำให้เสียเวลาและทรัพยากรไปกับการทำ Modeling เพียงอย่างเดียว การจำกัดขอบเขตของ Schema สำหรับ Entity และ Edge ไว้เพียง 1-2 กรณีการใช้งาน (Use Case) แล้วค่อยๆ ขยายผลไปพร้อมกับการตรวจสอบ จะช่วยลดการทำงานซ้ำซ้อนได้ แนวทางที่กล่าวไปข้างต้นในการเริ่มต้นจากกราฟขนาดเล็กที่ตรวจสอบได้จริงนั้น ถือเป็นแนวทางปฏิบัติเพื่อหลีกเลี่ยงความล้มเหลวนี้

Q2. หากแหล่งข้อมูลกระจายอยู่หลายแผนก ควรเริ่มบูรณาการจากจุดไหนก่อน?

ควรเริ่มจากการเลือก Domain ที่มีการใช้งานบ่อยและมีการสอบถามเกี่ยวกับความสัมพันธ์บ่อยครั้ง (เช่น ลูกค้ากับสัญญา, ผลิตภัณฑ์กับชิ้นส่วน) แล้วเลือกเฉพาะแหล่งข้อมูลที่เกี่ยวข้องกับส่วนนั้นมาดำเนินการ หากพยายามบูรณาการข้อมูลทั้งบริษัทในคราวเดียว ภาระในการทำ Data Cleansing และ Entity Resolution จะเพิ่มสูงขึ้นอย่างรวดเร็ว จนทำให้การตรวจสอบคุณภาพตามไม่ทัน การจำกัดขอบเขตก่อนแล้วค่อยขยาย Schema ไปยัง Domain อื่นในภายหลังเป็นลำดับที่ปลอดภัยกว่า

Q3. หากต้องการเพิ่มกราฟเข้าไปในโครงสร้างพื้นฐาน RAG ที่มีอยู่เดิม ควรตรวจสอบอะไรบ้าง?

อันดับแรกให้ตรวจสอบจาก Log ที่มีอยู่ว่าความแม่นยำในการตอบคำถามของ Vector Search ลดลงเมื่อเป็น "คำถามเกี่ยวกับความสัมพันธ์" หรือไม่ หากการใช้งานหลักคือการตรวจสอบข้อเท็จจริงภายในเอกสารฉบับเดียว การเพิ่มกราฟอาจให้ผลลัพธ์ที่จำกัด หากมีการออกแบบให้เรียกใช้การสำรวจกราฟในโครงสร้างแบบ Multi-agent ควรพิจารณาแนวคิดเรื่องการแยกสิทธิ์ (Permission Separation) และการจัดการ Orchestration ตามที่ระบุไว้ใน Multi-agent AI คืออะไร? ตั้งแต่รูปแบบการออกแบบไปจนถึงจุดสำคัญในการนำไปใช้งานจริง ควบคู่ไปด้วย ซึ่งจะช่วยให้จัดระเบียบลำดับการเรียกใช้งานและการแบ่งหน้าที่ได้ง่ายขึ้น

Q4. ใครควรเป็นผู้รับผิดชอบการควบคุมคุณภาพของกราฟ?

โดยพื้นฐานแล้ว ฝ่ายโครงสร้างพื้นฐานข้อมูล (Data Infrastructure) ควรรับผิดชอบการตรวจสอบการออกแบบ Entity และคุณภาพของ Edge ส่วนผู้เชี่ยวชาญเฉพาะทางใน Domain นั้นๆ ควรเป็นผู้ตัดสินว่าความสัมพันธ์ทางธุรกิจถูกต้องหรือไม่ หากดำเนินงานโดยที่บทบาทของทั้งสองฝ่ายไม่ชัดเจน Edge ที่ผิดพลาดมักจะถูกปล่อยทิ้งไว้ การกำหนดขอบเขตความรับผิดชอบให้เป็นลายลักษณ์อักษรโดยสอดคล้องกับกรอบการกำกับดูแล AI (AI Governance) โดยรวม จะช่วยให้การดำเนินงานมีความเสถียรมากขึ้น

Q5. ในช่วงเริ่มต้นของการนำมาใช้ มีข้อควรระวังด้านความปลอดภัยอย่างไรบ้าง?

ในโครงสร้างที่ส่งผลลัพธ์จากการค้นหากราฟเข้าสู่ LLM โดยตรง มีความเป็นไปได้ที่ Edge หรือ Attribute ที่ไม่ถูกต้องซึ่งปนเปื้อนเข้ามาผ่านข้อมูลภายนอกจะส่งผลต่อคำตอบ ด้วยมุมมองเดียวกับการป้องกัน RAG Poisoning จึงควรมีการตรวจสอบข้อมูลต้นทางและทำการตรวจสอบ (Audit) Edge ที่ผิดปกติอย่างสม่ำเสมอควบคู่กันไป

เพื่อช่วยให้ผู้อ่านที่อาจสับสนในช่วงเริ่มต้นใช้งาน Graph Engineering ผมจะขอตอบ 3 คำถามสำคัญ ได้แก่ วิธีการเริ่มต้น, ความแตกต่างจาก GraphRAG และการเลือกเป้าหมายที่จะทำเป็นกราฟ เนื่องจากรายละเอียดด้านการออกแบบและการดำเนินงานได้อธิบายไปในส่วนก่อนหน้าแล้ว ในที่นี้จึงขอสรุปเฉพาะแนวคิดที่เป็นจุดเริ่มต้นในการตัดสินใจให้กระชับครับ

เกณฑ์การตัดสินใจ: ให้ความสำคัญกับขนาดที่สามารถตรวจสอบได้ มากกว่าความกว้างของขอบเขตงาน

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

จากนั้น สิ่งที่ควรตรวจสอบมี 3 ประการ ดังนี้:

• สามารถตอบคำถามที่คาดหวังผ่านกราฟได้หรือไม่ (เตรียมคำถามที่การค้นหาแบบปกติไม่สามารถดึงความสัมพันธ์ออกมาได้ อย่างน้อย 1 ข้อ)
• เป็นขนาดที่มนุษย์สามารถตรวจสอบการสกัด Entity และการกำหนด Relation ได้หรือไม่ (การเริ่มจากหลักร้อยรายการจะช่วยให้พบข้อผิดพลาดได้ง่าย)
• มีการออกแบบให้สามารถวัดดัชนีคุณภาพ (วิธีการตรวจสอบความแม่นยำและความสามารถในการเรียกคืนที่จะกล่าวถึงในภายหลัง) ได้ตั้งแต่ต้นหรือไม่

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

หากต้องการแยกความแตกต่างระหว่างสองสิ่งนี้ การจัดหมวดหมู่ว่า Graph Engineering คือการถามถึงองค์ประกอบโครงสร้าง ส่วน GraphRAG คือการถามถึงวิธีการสืบค้นขณะรันไทม์ จะช่วยให้เข้าใจได้ง่ายขึ้น

Graph Engineering หมายถึงกระบวนการสร้างและดูแลรักษา Knowledge Graph ตั้งแต่การออกแบบเอนทิตี (Entity), คุณภาพของเอดจ์ (Edge), ไปจนถึงตัวชี้วัดการตรวจสอบ ในขณะที่ GraphRAG เป็นคำรวมที่ใช้เรียกวิธีการนำกราฟที่สร้างเสร็จแล้วมาใช้ในขั้นตอนการดึงข้อมูลสำหรับการสร้างข้อความแบบ RAG (Retrieval-Augmented Generation) โดยมีจุดเด่นคือการใช้การตรวจจับชุมชน (Community Detection) และการสรุปเนื้อหาจากโครงสร้างกราฟ ทำให้สามารถสืบค้นความสัมพันธ์แบบหลายขั้นตอนที่การค้นหาด้วยเวกเตอร์ (Vector Search) เพียงอย่างเดียวเข้าถึงได้ยาก ดังที่ระบุไว้ในที่เก็บข้อมูลการใช้งานของ Microsoft อย่าง "microsoft/graphrag" และในเอกสารวิจัยสำรวจที่เผยแพร่บน arXiv

กล่าวคือ GraphRAG คือ "สถาปัตยกรรมการสืบค้นที่ใช้กราฟ" ส่วน Graph Engineering คือ "กระบวนการสร้างกราฟที่ใช้งานได้จริงอย่างต่อเนื่อง" หากคุณภาพของกราฟต่ำ ความแม่นยำของ GraphRAG ก็จะไม่เพิ่มขึ้น ในทางกลับกัน แม้จะสร้างกราฟที่ละเอียดแม่นยำ แต่หากการออกแบบคิวรี (Query) หรือวิธีการผสมผสานกับการทำ Embedding ในฝั่งการสืบค้นทำออกมาไม่ดี การสืบค้นก็จะล้มเหลวก่อนที่จะดึงความสัมพันธ์ออกมาได้

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

เกณฑ์ในการตัดสินใจคือ ความสัมพันธ์ระหว่างเอนทิตี (Entity) ส่งผลโดยตรงต่อความแม่นยำในการค้นหาหรือการตัดสินใจหรือไม่ หากความสัมพันธ์เป็นแบบ 1 ต่อ 1 ที่เรียบง่าย และสามารถหาคำตอบได้เพียงพอจากเนื้อหาในเอกสาร การใช้ Vector Search หรือ Hybrid Search ด้วย BM25 มักจะเพียงพอแล้ว และไม่คุ้มค่ากับต้นทุนในการทำกราฟ

ข้อมูลที่ควรพิจารณาทำเป็นกราฟคือข้อมูลที่มีความสัมพันธ์แบบหลายต่อหลาย (Many-to-Many) ดังนี้:

• กรณีที่องค์กร บุคคล ผลิตภัณฑ์ หรือสัญญา เชื่อมโยงกันผ่านหลายเส้นทาง และจำเป็นต้องมีการอนุมานโดยการไล่ตามเส้นทางเหล่านั้น
• กรณีที่จำเป็นต้องติดตามความสัมพันธ์เชิงพึ่งพาทางอ้อม เช่น "ใครเป็นผู้อนุมัติ" หรือ "แผนกใดได้รับผลกระทบ"
• กรณีที่ความสัมพันธ์เปลี่ยนแปลงตามช่วงเวลา และประวัติการเปลี่ยนแปลงนั้นมีความหมายในตัวมันเอง (เช่น การโยกย้ายตำแหน่งงาน, ประวัติการต่อสัญญา)

ในทางกลับกัน ข้อมูลที่มีความถี่ในการอัปเดตสูงมากจนต้นทุนในการรักษาความสอดคล้องของข้อมูลสูงกว่าการเพิ่มความแม่นยำในการค้นหา หรือข้อมูลอ้างอิงทั่วไปที่แทบไม่มีความสัมพันธ์กัน ควรลดลำดับความสำคัญในการทำกราฟลง ในทางปฏิบัติ ควรเริ่มจากการคัดแยกกลุ่มคำถามที่การค้นหาเอกสารแบบเดิมให้ความแม่นยำต่ำ แล้วนำคำถามเหล่านั้นมาพิจารณาว่า "จำเป็นต้องไล่ตามความสัมพันธ์หลายฮอป (Multi-hop) หรือไม่" ซึ่งจะช่วยให้เห็นภาพชัดเจนขึ้นว่าข้อมูลใดควรทำเป็นกราฟ เมื่อพิจารณาร่วมกับการจัดลำดับความสำคัญที่กล่าวไว้ในส่วนของการออกแบบเอนทิตีและรีเลชัน (Entity and Relation) จะช่วยให้จำกัดขอบเขตของข้อมูลได้ง่ายขึ้น