Knowledge graph

Knowledge graph คือวิธีเก็บความรู้ในรูปของความสัมพันธ์ระหว่างสิ่งของ แทนที่จะเก็บเป็นก้อนข้อความยาวๆ แล้วปล่อยให้คนหรือ AI ไปนั่งอ่านหาเอาเอง หัวใจของมันเรียบง่ายกว่าที่ชื่อฟัง เอกสารแนะนำ RDF 1.1 Primer ของ W3C อธิบายว่าข้อความบอกข้อมูลหนึ่งข้อจะมีโครงสร้างเป็น subject, predicate และ object เสมอ ซึ่งแปลเป็นภาษาคนได้ว่า "ใคร เกี่ยวข้องแบบไหน กับอะไร" เช่น บริษัท ก เป็นบริษัทลูกของ บริษัท ข หรือ คุณสมชาย ดูแลบัญชีของ ลูกค้ารายนี้ เอกสารฉบับเดียวกันบอกต่อว่าเมื่อวาดข้อมูลชุดนี้ออกมาจะเห็นเป็น graph ที่ประกอบด้วย node กับเส้นเชื่อม โดย subject และ object กลายเป็น node ส่วน predicate กลายเป็นเส้นที่ลากระหว่างกัน เอาข้อความแบบนี้มาต่อกันหลายพันข้อก็ได้แผนที่ความรู้ขององค์กรหนึ่งผืน ซึ่งเป็นรูปแบบหนึ่งของ contextual-knowledge ที่ระบบหยิบไปใช้ได้ทันที และเป้าหมายใหญ่ข้อหนึ่งของการใช้ RDF คือการรวมข้อมูลที่เป็นประโยชน์จากหลายแหล่งเข้าด้วยกันโดยอัตโนมัติจนได้กองข้อมูลที่ใหญ่ขึ้นแต่ยังสอดคล้องกันและใช้งานได้

พอลงมือทำจริง มีสองสายหลักที่คนใช้เก็บ graph แบบนี้ คู่มือของ Amazon Neptune ซึ่งเป็นบริการฐานข้อมูล graph ของ AWS ระบุว่ารองรับทั้งฝั่ง property graph ที่ใช้ภาษา Gremlin กับ openCypher และฝั่ง RDF ที่ใช้ภาษา SPARQL โดยยกตัวอย่างงานที่คนเอา graph ไปใช้ เช่น recommendation engine การตรวจจับการฉ้อโกง knowledge graph การค้นพบยาใหม่ และความปลอดภัยของเครือข่าย เหตุผลที่ต้องมีฐานข้อมูลสายนี้แยกออกมา คู่มือเล่มเดียวกันเขียนไว้ตรงๆ ว่าการเขียน SQL กับข้อมูลที่เชื่อมโยงกันหนาแน่นนั้นซับซ้อนและปรับให้ทำงานเร็วได้ยาก ขณะที่ภาษาสาย graph เขียนคำถามแบบไล่ตามความสัมพันธ์ได้ง่ายกว่า จุดที่ควรระวังคือชื่อที่มีคำว่า knowledge graph ติดอยู่ ไม่ได้แปลว่าจะได้ graph กลับมาเสมอ เอกสารของ Google Knowledge Graph Search API เขียนไว้ว่า API ตัวนี้เป็นแบบอ่านอย่างเดียว และคืนค่าเฉพาะ entity ที่ตรงกับคำค้นทีละตัว ไม่ได้คืน graph ของ entity ที่เชื่อมโยงกัน ถ้าต้องการแบบหลัง Google แนะนำให้ไปใช้ data dump ของ Wikidata แทน หน้าเดียวกันยังเตือนด้วยว่า API ตัวนี้ไม่เหมาะกับการใช้เป็นบริการที่ระบบต้องพึ่งพาในระดับวิกฤต และไม่ควรออกแบบผลิตภัณฑ์ให้ขึ้นกับมันแบบขาดไม่ได้ นอกจากนี้ Google ยังแจ้งว่ากำลังย้าย API ตัวนี้ไปยัง Cloud Enterprise Knowledge Graph เพื่อรองรับความต้องการระดับองค์กรและการเรียกใช้ปริมาณสูง graph จึงมักถูกวางไว้เป็นอีกชั้นข้างๆ การค้นหาแบบเดิม คล้ายแนวคิดของ hybrid-search ที่ใช้หลายวิธีค้นประกอบกันแทนที่จะเลือกอย่างเดียว

คนทำงานมักเจอคำนี้ตอนองค์กรเริ่มเอา AI มาต่อกับข้อมูลภายใน เอกสารของ glean อธิบายว่า Knowledge Graph ของบริการนี้ตั้งอยู่บนสามเสาคือ content, people และ activity โดยฝั่ง people เก็บตัวตนผู้ใช้ บทบาท ทีม และความสัมพันธ์เชิงโครงสร้างองค์กรเอาไว้ นั่นคือเหตุผลที่ระบบแบบนี้ตอบคำถามอย่าง "ลูกค้ารายนี้อยู่ใต้บริษัทแม่ไหน แล้วใครเป็นคนดูแลบัญชี" ได้ ทั้งที่ไม่มีเอกสารฉบับไหนเขียนคำตอบเต็มๆ ไว้ในที่เดียว ฝั่ง Microsoft ก็เปิดโครงการ GraphRAG ซึ่งเอกสารของโครงการอธิบายตัวเองว่าเป็นการดึง knowledge graph ออกมาจากข้อความดิบ สร้างลำดับชั้นของกลุ่ม แล้วเอาโครงสร้างนั้นมาใช้ตอนทำงานแบบ RAG โดยระบุปัญหาที่ตั้งใจแก้ไว้สองข้อ คือ RAG แบบพื้นฐานมักต่อจุดไม่ติดเมื่อคำถามต้องเดินข้ามข้อมูลหลายชิ้นที่เชื่อมกันด้วยคุณสมบัติร่วม และทำได้ไม่ดีเมื่อถูกถามให้เข้าใจภาพรวมเชิงความหมายของกองข้อมูลขนาดใหญ่ เอกสารเดียวกันเคลมว่า GraphRAG ดีขึ้นชัดเจนกับคำถามสองแบบนี้ ไม่ได้เคลมว่าดีกว่าทุกกรณี ข้อควรระวังสำหรับคนที่จะเอาไปใช้มีสองเรื่อง เรื่องแรกคือ graph ดีได้แค่เท่าข้อมูลที่ป้อนเข้าไป ถ้าโครงสร้างทีมหรือสายบังคับบัญชาในระบบต้นทางไม่อัปเดต graph ก็จะตอบผิดอย่างมั่นใจ ซึ่งคนละกลไกกับ hallucination ที่โมเดลแต่งขึ้นเอง แต่ปลายทางเสียหายคล้ายกัน ต่อให้คำตอบมี grounding ชี้กลับไปยังต้นทางได้ก็ตาม เรื่องที่สองคือสิทธิ์เข้าถึง เอกสารของ Glean ระบุว่าตั้งค่าการเข้าถึงได้ถึงระดับรายชิ้น และกำหนดกฎรวมหรือยกเว้นตาม asset ID หรือตามที่เก็บของข้อมูลได้ แปลว่าเรื่อง rbac และ data-governance ต้องออกแบบไปพร้อมกับ graph ตั้งแต่วันแรก เพราะ graph ที่เชื่อมทุกอย่างเข้าหากันก็คือเครื่องมือที่ทำให้ข้อมูลไหลข้ามแผนกได้เร็วขึ้นด้วยเช่นกัน

ตัวอย่างจากบทสนทนาจริง

ฝ่ายขาย: ถามผู้ช่วย AI ว่า "ใครดูแลบัญชีของบริษัทลูกทั้งหมดในเครือลูกค้า A บ้าง" แล้วมันตอบไม่ได้ ทั้งที่ข้อมูลอยู่ในระบบเราหมดเลยครับ ทำไมครับ

ฝ่าย IT: เพราะตอนนี้ระบบค้นเจอเป็นเอกสารทีละใบครับ ใบหนึ่งบอกว่าบริษัทลูกมีใครบ้าง อีกใบบอกว่าใครดูแลบัญชีไหน แต่ไม่มีใบไหนบอกครบทั้งสองชั้น คำถามแบบนี้ต้องเดินสองทอด ถ้าเราทำ knowledge graph คือเก็บไว้เป็นความสัมพันธ์ว่าบริษัทลูกอยู่ใต้บริษัทแม่ไหน และพนักงานคนไหนดูแลบัญชีอะไร ระบบจะไล่ตามเส้นต่อกันเองได้

ฝ่ายขาย: แล้วต้องรื้อระบบเดิมทิ้งไหมครับ

ฝ่าย IT: ไม่ต้องครับ graph เป็นชั้นที่วางเพิ่มข้างบนข้อมูลเดิม แต่ต้องตกลงเรื่องสิทธิ์ให้ชัดก่อน ไม่งั้นพอเชื่อมทุกอย่างเข้าหากันแล้ว คนที่ไม่ควรเห็นข้อมูลบางส่วนจะเห็นทันที

ระวังสับสนกับ

• vector-database : ที่เก็บข้อความในรูปตัวเลขแล้วหาชิ้นที่ความหมายใกล้กัน จุดแข็งคือหาเนื้อหาที่เกี่ยวข้องได้แม้ใช้คำต่างกัน ส่วน knowledge graph เก็บตัวสิ่งของกับเส้นความสัมพันธ์ระหว่างกัน จึงเดินตามเส้นข้ามหลายทอดได้ หลายระบบใช้สองอย่างนี้คู่กันได้ ไม่จำเป็นต้องเลือกอย่างใดอย่างหนึ่ง
• rag : RAG คือรูปแบบการทำงานที่ค้นข้อมูลมาก่อนแล้วให้โมเดลตอบจากสิ่งที่ค้นได้ ส่วน knowledge graph คือรูปแบบการเก็บข้อมูลที่เอามาเป็นแหล่งค้นให้ RAG ได้ GraphRAG ของ Microsoft คือตัวอย่างของการเอาสองอย่างนี้มาต่อกัน
• microsoft-graph : ชื่อมีคำว่า graph เหมือนกันแต่คนละเรื่อง เอกสารของ Microsoft อธิบายว่า Microsoft Graph API เปิด endpoint เดียวคือ graph.microsoft.com ให้เข้าถึงข้อมูลและ insight ที่มีคนเป็นศูนย์กลางใน Microsoft cloud และเดินต่อไปยัง resource อื่นผ่าน relationship เช่น หัวหน้าของผู้ใช้คนนั้น มันคือช่องทางเรียกข้อมูลของแพลตฟอร์มหนึ่ง ไม่ใช่มาตรฐานการเก็บความรู้แบบที่ RDF วางไว้