Graph Engineering ແມ່ນຫຍັງ? ຄູ່ມືພາກປະຕິບັດໃນການອອກແບບ ແລະ ດຳເນີນງານ Knowledge Graphs ທີ່ມີຄຸນນະພາບລະດັບ Production

Graph Engineering ໝາຍເຖິງຂະບວນການທັງໝົດໃນການອອກແບບເອນຕິຕີ (entities) ແລະ ຄວາມສຳພັນໃຫ້ເປັນໂຄງສ້າງກຣາຟທີ່ຊັດເຈນ, ແລະ ຮັກສາໂຄງສ້າງນັ້ນໄວ້ຕະຫຼອດການດຳເນີນງານໃນການຜະລິດ ພ້ອມທັງຮັກສາຄຸນນະພາບໄປນຳ. ຈຸດປະສົງແມ່ນເພື່ອໃຫ້ຜູ້ປະຕິບັດງານດ້ານຖານຄວາມຮູ້ ແລະ RAG ສາມາດນຳໃຊ້ຄວາມເຂົ້າໃຈກ່ຽວກັບຄວາມສຳພັນໄດ້—"ໃຜເຊື່ອມຕໍ່ກັບຫຍັງ ແລະ ແນວໃດ"—ເຊິ່ງເປັນສິ່ງທີ່ຍາກທີ່ຈະຈັດການຜ່ານການຄົ້ນຫາເອກະສານພຽງຢ່າງດຽວ. ບົດຄວາມນີ້ຈະພາທ່ານໄປເບິ່ງຂະບວນການຢ່າງຕໍ່ເນື່ອງ ເລີ່ມຈາກກຣາຟຂະໜາດນ້ອຍທີ່ສາມາດກວດສອບໄດ້ ແລະ ດຳເນີນໄປຕາມຂັ້ນຕອນການອອກແບບ, ການຈັດການຄຸນນະພາບ, ແລະ ການເຊື່ອມໂຍງ RAG, ໂດຍສະແດງໃຫ້ເຫັນວິທີການສ້າງກຣາຟໃນທາງປະຕິບັດ ໃນຂະນະທີ່ດຳເນີນການວັດແທກຄຸນນະພາບ ແລະ ການປະຕິບັດງານ. ເມື່ອອ່ານຈົບ, ທ່ານຄວນຈະມີກອບການຕັດສິນໃຈສຳລັບການອອກແບບກຣາຟທີ່ເໝາະສົມກັບຂໍ້ມູນຂອງອົງກອນທ່ານເອງ.

[ຕົວຢ່າງປະກອບ] ພະແນກໜຶ່ງໄດ້ລວບລວມການຮຽກໃຊ້ LLM API ທີ່ຕິດແທັກດ້ວຍລະຫັດພະແນກໃນໄລຍະເວລາ 90 ວັນ, ເຊິ່ງຊ່ວຍຫຼຸດຊົ່ວໂມງການເຮັດວຽກທີ່ໃຊ້ໃນການກວດສອບໃບບິນທ້າຍເດືອນລົງໄດ້ 40%. ຫຼັກການແມ່ນ "ລະຫັດພະແນກຖືກຕິດໄວ້ກັບທຸກຄຳຮ້ອງຂໍ," ແລະ ສະພາບແວດລ້ອມກໍເປັນພຽງ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ການບັນທຶກຂໍ້ມູນທີ່ມີຢູ່ແລ້ວ ໂດຍມີຖັນແທັກເພີ່ມຕື່ມອີກໜຶ່ງຖັນ.

ເກນການຕັດສິນໃຈ: Graph Engineering ມີຄວາມແຕກຕ່າງຈາກການສ້າງ Knowledge Graph ໂດຍກົງ ເນື່ອງຈາກມັນປະຕິບັດຕໍ່ກຣາຟໃນຖານະເປັນຂະບວນການວິສະວະກຳຊອບແວ.

ໂດຍທົ່ວໄປແລ້ວ, ການສ້າງ Knowledge Graph ໝາຍເຖິງວຽກງານການສະກັດເອົາ Entity ແລະ ຄວາມສຳພັນຕ່າງໆ ແລ້ວຈັດລະບຽບພວກມັນຕາມ Ontology. ໃນທາງກົງກັນຂ້າມ, Graph Engineering ບໍ່ພຽງແຕ່ກວມເອົາວຽກງານການສ້າງດັ່ງກ່າວເທົ່ານັ້ນ, ແຕ່ຍັງລວມເຖິງການຄຸ້ມຄອງຂອບເຂດຜົນກະທົບຈາກການປ່ຽນແປງການອອກແບບ, ການຕິດຕາມຕົວຊີ້ວັດດ້ານຄຸນນະພາບຢ່າງຕໍ່ເນື່ອງ, ແລະ ການຮັກສາການດຳເນີນງານໃນຮູບແບບທີ່ສາມາດຮອງຮັບການອ້າງອີງຈາກ RAG ແລະ AI agents ໄດ້.

ຢ່າງເປັນຮູບປະທຳ, ມັນແມ່ນການປະຕິບັດແບບລວມສູນທີ່ປະສົມປະສານ 3 ຊັ້ນເຂົ້າດ້ວຍກັນ: ຊັ້ນການອອກແບບທີ່ກຳນົດ Schema ແລະ ຂໍ້ຈຳກັດຂອງຂໍ້ມູນໂດຍໃຊ້ W3C standards ເຊັ່ນ: RDF, SPARQL, OWL, ແລະ SHACL; ຊັ້ນການຄຸ້ມຄອງຄຸນນະພາບທີ່ວັດແທກຄວາມໜ້າເຊື່ອຖື ແລະ ການກວມເອົາຂອງ Edge; ແລະ ຊັ້ນການເຊື່ອມໂຍງທີ່ເຊື່ອມຕໍ່ກັບລະບົບການຄົ້ນຫາ ແລະ ການຫາເຫດຜົນ. ໃນໂຄງການສ້າງກຣາຟແບບຄັ້ງດຽວຈົບ, ເປັນເລື່ອງປົກກະຕິທີ່ Schema ຈະບໍ່ໄດ້ຮັບການອັບເດດຫຼັງຈາກການ ເປີດຕົວ ຫຼື Launch ຄັ້ງທຳອິດ ແລະ ກາຍເປັນພຽງຮູບແບບທາງການເທົ່ານັ້ນ. ແຕ່ເມື່ອຖືກຈັດໂຄງສ້າງເປັນ Graph Engineering, ວົງຈອນການຄຸ້ມຄອງການປ່ຽນແປງ ແລະ ການຕິດຕາມກວດກາຈະຖືກສ້າງຂຶ້ນຕັ້ງແຕ່ຕົ້ນ.

ຄວາມແຕກຕ່າງນີ້ຍັງມີຄວາມສຳຄັນໃນມຸມມອງຂອງການຖ່າຍທອດຄວາມຮູ້. ຖ້າເຫດຜົນທີ່ຢູ່ເບື້ອງຫຼັງການຕັດສິນໃຈໃນການອອກແບບຖືກບັນທຶກໄວ້, ຈຸດປະສົງຂອງກຣາຟກໍຈະສາມາດສືບຕໍ່ໄດ້ງ່າຍຂຶ້ນເຖິງແມ່ນວ່າບຸກຄະລາກອນຈະມີການປ່ຽນແປງກໍຕາມ.

ໃນ RAG ທີ່ເນັ້ນການຄົ້ນຫາເອກະສານ, ຄຳຕອບສາມາດຖືກສົ່ງກັບຄືນໂດຍອີງໃສ່ຄວາມໃກ້ຄຽງທາງຄວາມໝາຍຂອງຂໍ້ມູນພຽງສ່ວນດຽວ (chunk). ຢ່າງໃດກໍຕາມ, ສຳລັບຄຳຖາມທີ່ຕ້ອງການການຕິດຕາມຄວາມສຳພັນລະຫວ່າງຫຼາຍໜ່ວຍຂໍ້ມູນ (entities), ຫຼັກຖານມັກຈະກະຈັດກະຈາຍເມື່ອອາໄສພຽງແຕ່ການຄົ້ນຫາແບບ vector. ຕົວຢ່າງເຊັ່ນ: ຄຳຖາມປະເພດ "ກຸ່ມສັນຍາທີ່ກ່ຽວຂ້ອງກັບບໍລິສັດແມ່ຂອງຄູ່ຮ່ວມທຸລະກິດໃດໜຶ່ງ" ບໍ່ສາມາດສ້າງຄືນໃໝ່ເປັນຕ່ອງໂສ້ຄວາມສຳພັນຜ່ານການຄົ້ນຫາຄວາມຄ້າຍຄືກັນໃນລະດັບເອກະສານໄດ້.

ເບື້ອງຫຼັງສິ່ງນີ້ແມ່ນປະຫວັດສາດອັນຍາວນານຂອງການສັ່ງສົມຜົນງານໃນຂະແໜງ Search Engine ແລະ Web. schema.org ໄດ້ເລີ່ມຕົ້ນໃນ ຮອບ 10 ປີ ທີ່ຜ່ານມາ ໃນຖານະການລິເລີ່ມຮ່ວມກັນລະຫວ່າງບໍລິສັດ Search Engine, ແລະໃນປີ 2012 Google ໄດ້ ເປີດຕົວ ຫຼື Launch Knowledge Graph, ເຊິ່ງເປັນການຈັດໂຄງສ້າງຄວາມສຳພັນລະຫວ່າງໜ່ວຍຂໍ້ມູນຈາກແຫຼ່ງຕ່າງໆ ເຊັ່ນ: Freebase, Wikipedia, ແລະ CIA World Factbook. ໂດຍການສ້າງຕໍ່ຍອດຈາກພື້ນຖານທີ່ສັ່ງສົມມາ, ວິທີການຕ່າງໆເຊັ່ນ GraphRAG—ເຊິ່ງ ໃສ່ໂຄງສ້າງກຣາຟໄວ້ລະຫວ່າງການດຶງຂໍ້ມູນ (retrieval) ແລະການສ້າງຂໍ້ມູນ (generation)—ໄດ້ມີຮູບຮ່າງທີ່ຊັດເຈນໃນການຄົ້ນຄວ້າຕັ້ງແຕ່ປີ 2024 ເປັນຕົ້ນມາ.

ເສັ້ນທາງນີ້ໄດ້ປ່ຽນແປງ knowledge graph ຈາກແນວຄວາມຄິດໃນການຄົ້ນຄວ້າ ໄປສູ່ການເປັນອົງປະກອບໜຶ່ງຂອງລະບົບການຜະລິດ. ໃນຂະນະດຽວກັນ, ເນື່ອງຈາກການປ່ຽນແປງ schema ແລະການຫຼຸດລົງຂອງຄຸນນະພາບຂໍ້ມູນຂອບເຂດ (edge quality) ສົ່ງຜົນກະທົບໂດຍກົງຕໍ່ຜົນລັດຂອງ AI agent, ການອອກແບບໃນຖານະຂະບວນການປະຕິບັດງານ—ບໍ່ແມ່ນພຽງແຕ່ການກໍ່ສ້າງ—ຈຶ່ງກາຍເປັນສິ່ງທີ່ຈຳເປັນ.

ຂະບວນການອອກແບບສຳລັບ Graph Engineering ຮຽກຮ້ອງໃຫ້ມີວິທີການທີ່ແຕກຕ່າງກັນ ຂຶ້ນຢູ່ກັບວ່າໂຄງສ້າງຂອງຂໍ້ມູນເປົ້າໝາຍນັ້ນມີຄວາມຊັດເຈນແລ້ວຫຼືບໍ່. ຂໍ້ມູນທາງທຸລະກິດທີ່ມີ Schema ທີ່ຄົງທີ່ແມ່ນເໝາະສົມກັບການອອກແບບທີ່ເຂັ້ມງວດໂດຍອີງໃສ່ RDF ແລະ SHACL, ໃນຂະນະທີ່ຂໍ້ມູນທີ່ເນັ້ນໃສ່ການສະກັດຈາກເອກະສານທີ່ບໍ່ມີໂຄງສ້າງແມ່ນເໝາະສົມກວ່າກັບການອອກແບບແບບເຮັດຊ້ຳ (iterative design) ທີ່ມີ LLM ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການສະກັດຄວາມສຳພັນ. ມາເລີ່ມວາງຂະບວນການໂດຍລວມ ແລະ ເບິ່ງວ່າການຕັດສິນໃຈຈະແຍກອອກຈາກກັນບ່ອນໃດ.

ຖ້າທ່ານບໍ່ແນ່ໃຈວ່າຈະຕັດສິນໃຈແນວໃດ, ມັນສາມາດຈັດການໄດ້ໂດຍການສ້າງຕົ້ນແບບ (prototype) ສະເພາະ Schema ແລະ ການສະກັດ Entity ໃນຂະແໜງຂະໜາດນ້ອຍກ່ອນ, ກວດສອບຄວາມຖືກຕ້ອງຂອງຄວາມສຳພັນດ້ວຍຕົນເອງ, ແລ້ວຈຶ່ງອອກແບບຂັ້ນຕອນການລວມຂໍ້ມູນ ແລະ ການຈັດເກັບໃນພາຍຫຼັງ. ແທນທີ່ຈະກຳນົດຂະບວນການທັງໝົດໃນຄັ້ງດຽວ, ມັນເປັນສິ່ງສຳຄັນທີ່ຈະອອກແບບໃຫ້ສາມາດກັບຄືນໄປແກ້ໄຂໄດ້ໂດຍອີງໃສ່ຜົນການກວດສອບ.

ຄວນລັອກສ່ວນໃດກ່ອນລະຫວ່າງ nodes ຫຼື edges ເພື່ອຫຼຸດຜ່ອນການແກ້ໄຂງານຄືນໃໝ່ໃນຂັ້ນຕອນຕໍ່ໄປ?

ໃນການອອກແບບ entity, ສິ່ງສຳຄັນແມ່ນຕ້ອງລະບຸ "ສິ່ງຕ່າງໆ" ທີ່ມີຄວາມໝາຍໃນທາງທຸລະກິດໃນລະດັບຄຳນາມກ່ອນ, ແລະຕ້ອງເຮັດໃຫ້ມັນເປັນມາດຕະຖານໃນຮູບແບບ aliases ເມື່ອແນວຄວາມຄິດດຽວກັນມີຫຼາຍຊື່ເອີ້ນ. ຕົວຢ່າງ: ຖ້າ "customer", "business partner", ແລະ "client" ໝາຍເຖິງ entity ປະເພດດຽວກັນ, ການບໍ່ກຳນົດກົດລະບຽບມາດຕະຖານໄວ້ແຕ່ຕົ້ນ ຈະເຮັດໃຫ້ຕ້ອງມາລວມ ຫຼື Merge nodes ຄືນໃໝ່ທົ່ວທັງກຣາຟໃນພາຍຫຼັງ.

ໃນການອອກແບບຄວາມສຳພັນ, ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ແມ່ນບໍ່ຄວນແບ່ງປະເພດຄວາມສຳພັນແບບຫຍາບເກີນໄປ. ການສ້າງ edges ໂດຍໃຊ້ພຽງແຕ່ປ້າຍຊື່ທົ່ວໄປເຊັ່ນ "related to" ຈະເຮັດໃຫ້ບໍ່ສາມາດກັ່ນຕອງຂໍ້ມູນທີ່ມີຄວາມໝາຍໃນລະຫວ່າງການຄົ້ນຫາໄດ້. ດັ່ງນັ້ນ, ຄວນເຮັດໃຫ້ຄວາມສຳພັນມີຄວາມຊັດເຈນໂດຍໃຊ້ປ້າຍຊື່ທີ່ເປັນຄຳກິລິຍາ ເຊັ່ນ "orders from", "belongs to", ຫຼື "depends on", ແລະກຳນົດທິດທາງຂອງ edge ລວມເຖິງຄວາມຫຼາກຫຼາຍ (multiplicity) ຕາມຄວາມຈຳເປັນ ໂດຍໃຊ້ OWL property hierarchies ຫຼື SHACL constraints.

ການອອກແບບປະເພດ entity ແລະ edge ໂດຍຄຳນຶງເຖິງການສອບຖາມຂໍ້ມູນດ້ວຍ SPARQL ຈະຊ່ວຍເພີ່ມຄວາມຖືກຕ້ອງ. ໃນທາງປະຕິບັດ, ວິທີທີ່ມີປະສິດທິຜົນແມ່ນການລະບຸຄຳຖາມທີ່ຕ້ອງການຄຳຕອບກ່ອນ, ຈາກນັ້ນຈຶ່ງກວດສອບວ່າຄຳຖາມເຫຼົ່ານັ້ນສາມາດແປງເປັນຮູບແບບກຣາຟ (graph patterns) ໄດ້ຫຼືບໍ່.

ເກນການຕັດສິນໃຈ: ຖ້າປາສະຈາກຕົວຊີ້ວັດ, ຄຸນນະພາບຂອງການອອກແບບທີ່ຫຼຸດລົງຈະບໍ່ຖືກສັງເກດເຫັນ.

ກຣາຟ (Graph) ບໍ່ແມ່ນສິ່ງທີ່ທ່ານສ້າງຂຶ້ນຄັ້ງດຽວແລ້ວສຳເລັດ, ຄຸນນະພາບຂອງມັນຈະຜັນຜວນຕາມການເພີ່ມຂໍ້ມູນ ຫຼື ການປ່ຽນແປງໂຄງສ້າງ (Schema) ໃນທຸກຄັ້ງ. ໃນການດຳເນີນງານ, ມັນມີປະສິດທິຜົນທີ່ຈະວັດແທກຕົວຊີ້ວັດຕ່າງໆຢ່າງຕໍ່ເນື່ອງ ເຊັ່ນ:

ບໍ່ຈຳເປັນຕ້ອງເຮັດໃຫ້ສິ່ງເຫຼົ່ານີ້ເປັນອັດຕະໂນມັດທັງໝົດໃນຄັ້ງດຽວ. ລຳດັບທີ່ເປັນໄປໄດ້ຈິງຄືການນຳເອົາຕົວຊີ້ວັດທີ່ກວດສອບໄດ້ງ່າຍທາງກົນຈັກຜ່ານ SPARQL ຫຼື ການກວດສອບຂໍ້ກຳນົດ SHACL—ເຊັ່ນ: ອັດຕາການຊ້ຳກັນຂອງ Entity ແລະ ອັດຕາຂອງ Node ທີ່ໂດດດ່ຽວ—ເຂົ້າສູ່ການດຳເນີນງານກ່ອນ, ແລ້ວຈຶ່ງເພີ່ມຕົວຊີ້ວັດການດຳເນີນງານ ເຊັ່ນ: ຄວາມຊັກຊ້າໃນການອັບເດດ ຕາມຫຼັງ.

ສຳລັບໂຄງສ້າງການດຳເນີນງານ, ຈຳເປັນຕ້ອງຕັດສິນໃຈລ່ວງໜ້າວ່າໃຜເປັນຜູ້ກວດພົບການຫຼຸດລົງຂອງຕົວຊີ້ວັດ ແລະ ໃຜເປັນຜູ້ອະນຸມັດການປ່ຽນແປງ Schema. ຖ້າການດຳເນີນງານເລີ່ມຕົ້ນໂດຍທີ່ຄວາມຮັບຜິດຊອບຍັງບໍ່ຈະແຈ້ງ, ຄຸນນະພາບທີ່ຫຼຸດລົງມັກຈະບໍ່ໄດ້ຮັບການແກ້ໄຂ.

ເມື່ອເປົ້າໝາຍການຄົ້ນຫາແມ່ນການກວດສອບຄວາມຖືກຕ້ອງພາຍໃນເອກະສານສະບັບດຽວ, RAG (Retrieval-Augmented Generation) ທີ່ເນັ້ນການຄົ້ນຫາແບບ vector ແມ່ນພຽງພໍແລ້ວ. ຢ່າງໃດກໍຕາມ, ສຳລັບຄຳຖາມທີ່ກ່ຽວຂ້ອງກັບຄວາມສຳພັນເຊິ່ງຕ້ອງມີການຕິດຕາມຜ່ານຫຼາຍ entities, ການຄົ້ນຫາຜ່ານ knowledge graph ແມ່ນມີປະສິດທິພາບ. GraphRAG ໄດ້ຖືກສະເໜີໃຫ້ເປັນວິທີການທີ່ລວມເອົາການຄົ້ນຫາແບບ vector ເຂົ້າກັບການທ່ອງໄປໃນກຣາຟ (graph traversal), ໂດຍການເກັບກຳຫຼັກຖານຜ່ານການຕິດຕາມເສັ້ນທາງລະຫວ່າງ entities.

ໂດຍສະເພາະ, ການຄົ້ນຫາແບບ vector ຫຼື BM25 ຈະຖືກນຳໃຊ້ກ່ອນເພື່ອລະບຸ nodes ທີ່ກ່ຽວຂ້ອງກັບຄຳຖາມ, ຈາກນັ້ນ edges ທີ່ຢູ່ເທິງກຣາຟຈະຖືກຕິດຕາມຈາກຈຸດນັ້ນເພື່ອດຶງຂໍ້ມູນ entities ແລະ ເຫດການທີ່ກ່ຽວຂ້ອງເພີ່ມເຕີມ. ໃນຂະນະທີ່ການຄົ້ນຫາເອກະສານແບບງ່າຍໆມີຈຸດອ່ອນໃນການຕອບຄຳຖາມປະເພດ "ຄວາມສຳພັນລະຫວ່າງ A ແລະ B ແມ່ນຫຍັງ," ການໃສ່ການທ່ອງໄປໃນກຣາຟເຂົ້າໄປມັກຈະຊ່ວຍປັບປຸງຄວາມຖືກຕ້ອງຂອງຄຳຕອບສຳລັບ ຄຳຖາມທີ່ກ່ຽວຂ້ອງກັບຄວາມສຳພັນແບບ multi-hop.

ສຳລັບການເຊື່ອມໂຍງກັບ AI agents, ການອອກແບບທີ່ກຣາຟຖືກເອີ້ນໃຊ້ເປັນເຄື່ອງມື (tool) ແມ່ນມີຄວາມເປັນໄປໄດ້ໃນທາງປະຕິບັດ. ການຕັ້ງຄ່າການຄົ້ນຫາແບບປະສົມ (Hybrid search) ຖືກນຳໃຊ້ໂດຍທີ່ agent ຈະສະຫຼັບລະຫວ່າງການທ່ອງໄປໃນກຣາຟ ແລະ ການຄົ້ນຫາແບບ vector ຂຶ້ນຢູ່ກັບຈຸດປະສົງຂອງຄຳຖາມ, ຫຼື ລວມຜົນລັອກຈາກທັງສອງວິທີໂດຍໃຊ້ວິທີການຕ່າງໆເຊັ່ນ RRF. ໃນລະບົບ multi-agent, ການແຍກ agent ທີ່ຮັບຜິດຊອບການອັບເດດກຣາຟອອກຈາກ agent ທີ່ຮັບຜິດຊອບການຄົ້ນຫາຈະຊ່ວຍຫຼຸດຜ່ອນໂອກາດທີ່ຄວາມບໍ່ສອດຄ່ອງໃນລະຫວ່າງການອັບເດດຈະສົ່ງຜົນກະທົບຕໍ່ຄຸນນະພາບຂອງຄຳຕອບ.

ສຳລັບລາຍລະອຽດການອອກແບບ, ວິທີການແຍກບົດບາດທີ່ໄດ້ສົນທະນາໃນ What Is Multi-Agent AI? From Design Patterns to Implementation and Operational Insights ແມ່ນເອກະສານອ້າງອີງທີ່ມີປະໂຫຍດ.

Q1. ເມື່ອແນະນຳ Graph Engineering, ຈຸດໃດທີ່ມັກເກີດຄວາມຜິດພາດໄດ້ງ່າຍທີ່ສຸດ?

ຮູບແບບທົ່ວໄປແມ່ນການພະຍາຍາມອອກແບບ ontology ທັງໝົດຢ່າງເຂັ້ມງວດຕັ້ງແຕ່ເລີ່ມຕົ້ນ, ເຊິ່ງສຸດທ້າຍຈະເຮັດໃຫ້ເສຍແຮງງານທັງໝົດໄປກັບການສ້າງແບບຈໍາລອງພຽງຢ່າງດຽວ. ມັນດີກວ່າທີ່ຈະຈຳກັດຂອບເຂດໃຫ້ເຫຼືອພຽງໜຶ່ງ ຫຼື ສອງກໍລະນີການນຳໃຊ້ (use cases) ທີ່ເປັນເປົ້າໝາຍ ແລະ ຂະຫຍາຍ entity/edge schema ໃນຂະນະທີ່ກວດສອບຄວາມຖືກຕ້ອງໄປພ້ອມກັນ, ເພາະວິທີນີ້ຈະຊ່ວຍຫຼຸດຜ່ອນການເຮັດວຽກຊໍ້າຊ້ອນ. ແນວທາງທີ່ໄດ້ສົນທະນາໄປກ່ອນໜ້ານີ້—ການເລີ່ມຕົ້ນດ້ວຍກຣາຟຂະໜາດນ້ອຍທີ່ສາມາດກວດສອບໄດ້—ແມ່ນແນວທາງປະຕິບັດທີ່ເໝາະສົມເພື່ອຫຼີກລ່ຽງຄວາມຜິດພາດນີ້.

Q2. ເມື່ອແຫຼ່ງຂໍ້ມູນຖືກກະຈາຍໄປຕາມຫຼາຍພະແນກ, ຄວນເລີ່ມຕົ້ນການເຊື່ອມໂຍງຈາກບ່ອນໃດ?

ໃຫ້ເລີ່ມຕົ້ນໂດຍການເລືອກໂດເມນດຽວທີ່ມີຄວາມຖີ່ໃນການນຳໃຊ້ສູງ ແລະ ມີການສອບຖາມແບບມີຄວາມສຳພັນ (relational queries) ຫຼາຍ (ເຊັ່ນ: ລູກຄ້າ ແລະ ສັນຍາ, ຫຼື ຜະລິດຕະພັນ ແລະ ຊິ້ນສ່ວນ), ແລະ ຈຳກັດຂອບເຂດໃຫ້ມີພຽງແຫຼ່ງຂໍ້ມູນທີ່ກ່ຽວຂ້ອງກັບໂດເມນນັ້ນເທົ່ານັ້ນ. ການພະຍາຍາມເຊື່ອມໂຍງຂໍ້ມູນທັງບໍລິສັດໃນຄັ້ງດຽວມັກຈະສົ່ງຜົນໃຫ້ພາລະໃນການຈັບຄູ່ entity ແລະ ການແກ້ໄຂ entity ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ, ເຮັດໃຫ້ບໍ່ສາມາດຕິດຕາມການກວດສອບຄຸນນະພາບໄດ້ທັນ. ມັນປອດໄພກວ່າທີ່ຈະຈຳກັດຂອບເຂດກ່ອນ, ແລ້ວຈຶ່ງຂະຫຍາຍ schema ໃນແນວນອນ ຫຼື Horizontal ໄປສູ່ໂດເມນອື່ນໆ.

Q3. ເມື່ອປັບປ່ຽນກຣາຟເຂົ້າກັບໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງ RAG ທີ່ມີຢູ່ແລ້ວ, ຄວນກວດສອບຫຍັງແດ່?

ກ່ອນອື່ນ, ໃຫ້ກວດສອບບັນທຶກ (logs) ທີ່ມີຢູ່ເພື່ອຕັດສິນວ່າຄວາມຖືກຕ້ອງຂອງການຕອບສະໜອງຂອງ vector search ຫຼຸດລົງໂດຍສະເພາະສຳລັບ "ຄຳຖາມທີ່ກ່ຽວຂ້ອງກັບຄວາມສຳພັນ" ຫຼືບໍ່. ຖ້າກໍລະນີການນຳໃຊ້ຫຼັກແມ່ນການກວດສອບຂໍ້ເທັດຈິງພາຍໃນເອກະສານດຽວ, ຜົນປະໂຫຍດຂອງການເພີ່ມກຣາຟຈະມີຈຳກັດ. ເມື່ອອອກແບບການຕັ້ງຄ່າຫຼາຍຕົວແທນ (multi-agent) ທີ່ຮຽກໃຊ້ການທ່ອງກຣາຟ (graph traversal), ມັນຍັງຊ່ວຍໃຫ້ພິຈາລະນາແນວຄວາມຄິດຂອງການແຍກສິດທິພິເສດ ແລະ ການຈັດການ (orchestration) ທີ່ໄດ້ສົນທະນາໃນ What Is Multi-Agent AI? From Design Patterns to Implementation and Operational Insights, ເຊິ່ງເຮັດໃຫ້ການຈັດລຳດັບການຮຽກໃຊ້ ແລະ ການແບ່ງຄວາມຮັບຜິດຊອບງ່າຍຂຶ້ນ.

Q4. ໃຜຄວນເປັນຜູ້ຮັບຜິດຊອບໃນການຈັດການຄຸນນະພາບຂອງກຣາຟ?

ຕາມຫຼັກການພື້ນຖານ, ທີມງານແພລດຟອມຂໍ້ມູນຄວນຈັດການການອອກແບບ entity ແລະ ການກວດສອບຄຸນນະພາບຂອງ edge, ໃນຂະນະທີ່ຜູ້ຊ່ຽວຊານດ້ານໂດເມນຄວນເປັນຜູ້ຕັດສິນວ່າຄວາມສຳພັນທາງທຸລະກິດຖືກຕ້ອງຫຼືບໍ່. ຖ້າທັງສອງບົດບາດຍັງບໍ່ຊັດເຈນໃນລະຫວ່າງການດຳເນີນງານ, edge ທີ່ບໍ່ຖືກຕ້ອງມັກຈະບໍ່ໄດ້ຮັບການແກ້ໄຂ. ເມື່ອເຮັດໃຫ້ການແບ່ງຄວາມຮັບຜິດຊອບເປັນທາງການ, ການລວມເອົາມັນເຂົ້າໃນກົດລະບຽບພາຍໃນຄຽງຄູ່ກັບກອບການກຳກັບດູແລ AI ທີ່ກວ້າງຂວາງຈະຊ່ວຍໃຫ້ການດຳເນີນງານມີຄວາມໝັ້ນຄົງ.

Q5. ມີຂໍ້ພິຈາລະນາດ້ານຄວາມປອດໄພໃດແດ່ທີ່ຄວນລະວັງໃນໄລຍະເລີ່ມຕົ້ນຂອງການນຳໃຊ້?

ໃນການຕັ້ງຄ່າທີ່ຜົນການຄົ້ນຫາກຣາຟຖືກສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ input ຂອງ LLM ໂດຍກົງ, edge ຫຼື attribute ທີ່ເປັນອັນຕະລາຍທີ່ເຂົ້າສູ່ກຣາຟຜ່ານຂໍ້ມູນພາຍນອກອາດຈະສົ່ງຜົນກະທົບຕໍ່ຄຳຕອບທີ່ສ້າງຂຶ້ນ. ຈາກມຸມມອງທີ່ຄ້າຍຄືກັບ RAG poisoning, ແນະນຳໃຫ້ລວມການກວດສອບຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນແຫຼ່ງທີ່ນຳເຂົ້າກັບການກວດສອບ (audits) edge ທີ່ຜິດປົກກະຕິເປັນປະຈຳ.

ພາກນີ້ຈະຕອບສາມຄຳຖາມທີ່ຜູ້ອ່ານມັກຈະສັບສົນ ເມື່ອແນະນຳກ່ຽວກັບ Graph Engineering: ວິທີການເລີ່ມຕົ້ນ, ຄວາມແຕກຕ່າງຈາກ GraphRAG, ແລະ ວິທີການເລືອກເປົ້າໝາຍສຳລັບການເຮັດ Graph. ເນື່ອງຈາກລາຍລະອຽດດ້ານການອອກແບບ ແລະ ການດຳເນີນງານໄດ້ຖືກກ່າວເຖິງໄປກ່ອນໜ້ານີ້ແລ້ວ, ໃນທີ່ນີ້ພວກເຮົາຈະຈັດລະບຽບຈຸດເລີ່ມຕົ້ນສຳລັບການຕັດສິນໃຈໂດຍຫຍໍ້.

ເກນການຕັດສິນໃຈ: ໃຫ້ຄວາມສຳຄັນກັບຄວາມນ້ອຍທີ່ສາມາດກວດສອບໄດ້ ຫຼາຍກວ່າຂອບເຂດທີ່ກວ້າງຂວາງ.

ການພະຍາຍາມສ້າງກຣາຟເອກະສານທັງໝົດຂອງບໍລິສັດຕັ້ງແຕ່ເລີ່ມຕົ້ນ ກໍປຽບເໝືອນການວາງແຜນຜັງເມືອງທັງເມືອງ ກ່ອນທີ່ຈະອອກແບບພິມຂຽວຂອງເຮືອນແມ້ແຕ່ຫຼັງດຽວ—ຈຸດໝາຍປາຍທາງຈະເບິ່ງບໍ່ເຫັນ ແລະ ຄວາມພະຍາຍາມກໍຈະຢຸດສະງັກໄດ້ງ່າຍ. ຈຸດເລີ່ມຕົ້ນແມ່ນການເລືອກພື້ນທີ່ແຄບໆທີ່ມີຄຳຖາມທາງທຸລະກິດເຕົ້າໂຮມກັນຢູ່—ເຊັ່ນ: ຄວາມສຳພັນລະຫວ່າງຜະລິດຕະພັນ ແລະ ຊິ້ນສ່ວນ, ຫຼື ສັນຍາ ແລະ ຂໍ້ກຳນົດຕ່າງໆ—ບ່ອນທີ່ຈຳນວນປະເພດຂອງເອນຕິຕີ້ (Entity types) ແລະ ປະເພດຄວາມສຳພັນສາມາດຮັກສາໄວ້ໃຫ້ມີພຽງເລັກນ້ອຍ, ແລ້ວສ້າງກຣາຟຂະໜາດນ້ອຍໂດຍໃຊ້ຂໍ້ມູນຕົວຈິງ.

ຈາກນັ້ນ, ຄວນກວດສອບ 3 ຈຸດຕໍ່ໄປນີ້:

• ສາມາດຕອບຄຳຖາມທີ່ຕັ້ງໄວ້ຜ່ານທາງກຣາຟໄດ້ຫຼືບໍ່? (ກຽມຢ່າງໜ້ອຍໜຶ່ງຄຳຖາມທີ່ການຄົ້ນຫາແບບທຳມະດາບໍ່ສາມາດເກັບກຳຄວາມສຳພັນນັ້ນໄດ້)
• ຂະໜາດນ້ອຍພໍທີ່ມະນຸດຈະກວດສອບການສະກັດເອນຕິຕີ້ ແລະ ການກຳນົດຄວາມສຳພັນໄດ້ຫຼືບໍ່? (ການເລີ່ມຕົ້ນດ້ວຍບັນທຶກປະມານສອງສາມຮ້ອຍລາຍການຈະເຮັດໃຫ້ກວດພົບຂໍ້ຜິດພາດໄດ້ງ່າຍຂຶ້ນ)
• ການອອກແບບໄດ້ຖືກຕັ້ງໄວ້ເພື່ອວັດແທກຕົວຊີ້ວັດຄຸນນະພາບ (ວິທີການກວດສອບຄວາມຖືກຕ້ອງ/ຄວາມສາມາດໃນການເຮັດຊ້ຳ ທີ່ໄດ້ສົນທະນາກັນໃນພາຍຫຼັງ) ຕັ້ງແຕ່ເລີ່ມຕົ້ນເລີຍຫຼືບໍ່?

ເມື່ອຄຸນນະພາບມີຄວາມໝັ້ນຄົງພາຍໃນຂອບເຂດທີ່ນ້ອຍທີ່ສຸດນີ້ແລ້ວ, ການຂະຫຍາຍໄປສູ່ຂົງເຂດໃກ້ຄຽງເທື່ອລະໜ້ອຍ ແມ່ນວິທີການເລີ່ມຕົ້ນທີ່ເປັນຈິງ ເຊິ່ງຈະຊ່ວຍໃຫ້ພາລະໃນການປະຕິບັດງານຂອງຂະບວນການ ຫຼື Pipeline ປາຍທາງສາມາດຈັດການໄດ້. ເນື່ອງຈາກເກນການອອກແບບສຳລັບເອນຕິຕີ້ ແລະ ຄວາມສຳພັນເອງກໍມີຄວາມຊ້ຳຊ້ອນກັບເນື້ອຫາທີ່ໄດ້ກ່າວມາກ່ອນໜ້ານີ້, ພວກມັນຈຶ່ງຖືກຮັກສາໄວ້ທີ່ນີ້ໃນຖານະເປັນພຽງເກນການຕັດສິນໃຈສຳລັບລຳດັບຂອງວິທີການເຂົ້າຫາເທົ່ານັ້ນ.

ເມື່ອສົນທະນາກ່ຽວກັບຄວາມແຕກຕ່າງຂອງອົງປະກອບ, ແນວຄວາມຄິດໃນການຈັດລະບຽບຂອງ Graph Engineering ຈະມີຄວາມຊັດເຈນກວ່າ; ເມື່ອສົນທະນາກ່ຽວກັບວິທີການດຶງຂໍ້ມູນໃນຂະນະປະມວນຜົນ (runtime retrieval methods), GraphRAG ຈະເປັນກອບການເຮັດວຽກທີ່ມີປະໂຫຍດຫຼາຍກວ່າ.

Graph Engineering ໝາຍເຖິງການປະຕິບັດໃນການສ້າງ ແລະ ດຳເນີນງານ knowledge graph ດ້ວຍຕົນເອງ—ເຊິ່ງລວມເຖິງການອອກແບບ entity, ຄຸນນະພາບຂອງ edge, ແລະ ຕົວຊີ້ວັດການຕິດຕາມ. ໃນທາງກົງກັນຂ້າມ, GraphRAG ເປັນຄຳສັບທົ່ວໄປສຳລັບວິທີການທີ່ນຳເອົາກຣາຟທີ່ສ້າງສຳເລັດຮູບແລ້ວມາລວມເຂົ້າໃນຂະບວນການດຶງຂໍ້ມູນຂອງ Retrieval-Augmented Generation (RAG). ດັ່ງທີ່ໄດ້ຈັດລະບຽບໄວ້ໃນ repository ການນຳໃຊ້ຂອງ Microsoft ຄື "microsoft/graphrag" ແລະ ໃນເອກະສານການສຳຫຼວດທີ່ເຜີຍແຜ່ໃນ arXiv, ຄຸນລັກສະນະທີ່ກຳນົດຄວາມໝາຍຂອງມັນແມ່ນຄວາມສາມາດໃນການຕິດຕາມຄວາມສຳພັນແບບ multi-hop—ຜ່ານການກວດຫາຊຸມຊົນ (community detection) ແລະ ການສ້າງບົດສະຫຼຸບຈາກໂຄງສ້າງກຣາຟ—ເຊິ່ງຍາກທີ່ຈະເກັບກຳໄດ້ດ້ວຍການຄົ້ນຫາແບບ vector ພຽງຢ່າງດຽວ.

ເວົ້າອີກຢ່າງໜຶ່ງ, GraphRAG ແມ່ນ "ສະຖາປັດຕະຍະກຳການດຶງຂໍ້ມູນທີ່ໃຊ້ກຣາຟ," ໃນຂະນະທີ່ Graph Engineering ແມ່ນ "ຂະບວນການທີ່ດຳເນີນຢູ່ຢ່າງຕໍ່ເນື່ອງໃນການສ້າງກຣາຟທີ່ສາມາດນຳໃຊ້ໄດ້." ຖ້າຄຸນນະພາບຂອງກຣາຟຕ່ຳ, ຄວາມຖືກຕ້ອງຂອງ GraphRAG ກໍຈະບໍ່ດີຂຶ້ນ. ໃນທາງກັບກັນ, ເຖິງແມ່ນວ່າຈະມີການສ້າງກຣາຟທີ່ຊັບຊ້ອນຂຶ້ນມາ, ແຕ່ຖ້າການອອກແບບ query ໃນຝັ່ງການດຶງຂໍ້ມູນ ຫຼື ການປະສົມປະສານກັບ embeddings ຍັງບໍ່ມີປະສິດທິພາບ, ການດຶງຂໍ້ມູນກໍຈະລົ້ມເຫຼວກ່ອນທີ່ຈະສາມາດສະກັດເອົາຄວາມສຳພັນຕ່າງໆອອກມາໄດ້.

ໃນທາງປະຕິບັດ, ຖ້າທ່ານໃຫ້ຄວາມສຳຄັນກັບການນຳໃຊ້ GraphRAG ພຽງຢ່າງດຽວໃນໄລຍະເລີ່ມຕົ້ນທີ່ schema ສຳລັບ entities ແລະ ຄວາມສຳພັນຕ່າງໆຍັງບໍ່ທັນໝັ້ນຄົງ, ທ່ານມັກຈະຕ້ອງໄດ້ສ້າງຕັກກະການດຶງຂໍ້ມູນໃໝ່ທຸກຄັ້ງທີ່ກຣາຟຕ້ອງການການອອກແບບໃໝ່. ວິທີການທີ່ເປັນຈິງຫຼາຍກວ່ານັ້ນແມ່ນການເຮັດໃຫ້ກຣາຟຂະໜາດນ້ອຍທີ່ສາມາດກວດສອບໄດ້ມີຄວາມໝັ້ນຄົງຜ່ານ Graph Engineering ກ່ອນ, ແລ້ວຈຶ່ງວາງວິທີການດຶງຂໍ້ມູນຂອງ GraphRAG ຊ້ອນທັບລົງໄປ.

ເກນສຳຄັນແມ່ນຄວາມສຳພັນລະຫວ່າງເອນຕິຕີ (entities) ສົ່ງຜົນໂດຍກົງຕໍ່ຄວາມຖືກຕ້ອງໃນການດຶງຂໍ້ມູນ ຫຼື ການຕັດສິນໃຈຫຼືບໍ່. ສຳລັບຂໍ້ມູນທີ່ມີຄວາມສຳພັນແບບໜຶ່ງຕໍ່ໜຶ່ງ (one-to-one) ທີ່ສາມາດໄດ້ຮັບຄຳຕອບຢ່າງພຽງພໍຈາກຄຳອະທິບາຍພາຍໃນເອກະສານພຽງຢ່າງດຽວ, ການຄົ້ນຫາແບບປະສົມ (hybrid search) ໂດຍໃຊ້ vector search ຫຼື BM25 ມັກຈະພຽງພໍ ແລະ ຕົ້ນທຶນໃນການສ້າງກຣາຟ (graph construction) ກໍບໍ່ມີຄວາມຈຳເປັນ.

ຄວນພິຈາລະນາການສ້າງກຣາຟສຳລັບຂໍ້ມູນທີ່ກ່ຽວຂ້ອງກັບຄວາມສຳພັນແບບຫຼາຍຕໍ່ຫຼາຍ (many-to-many) ເຊັ່ນ:

• ກໍລະນີທີ່ອົງກອນ, ບຸກຄົນ, ຜະລິດຕະພັນ, ສັນຍາ ແລະ ອື່ນໆ ຖືກເຊື່ອມຕໍ່ຜ່ານຫຼາຍເສັ້ນທາງ ເຊິ່ງຕ້ອງໃຊ້ການຫາເຫດຜົນທີ່ຕິດຕາມເສັ້ນທາງເຫຼົ່ານັ້ນ
• ກໍລະນີທີ່ຕ້ອງການຕິດຕາມຄວາມຂຶ້ນຕໍ່ກັນທາງອ້ອມ ເຊັ່ນ: "ໃຜເປັນຜູ້ອະນຸມັດສິ່ງນີ້" ຫຼື "ພະແນກໃດທີ່ໄດ້ຮັບຜົນກະທົບ"
• ກໍລະນີທີ່ຄວາມສຳພັນມີການປ່ຽນແປງຕາມເວລາ ແລະ ປະຫວັດຂອງການປ່ຽນແປງເຫຼົ່ານັ້ນມີຄວາມໝາຍໃນຕົວມັນເອງ (ເຊັ່ນ: ການຍົກຍ້າຍພະນັກງານ, ປະຫວັດການຕໍ່ສັນຍາ)

ໃນທາງກົງກັນຂ້າມ, ຂໍ້ມູນທີ່ມີຄວາມຖີ່ໃນການອັບເດດສູງຫຼາຍ ເຊິ່ງຕົ້ນທຶນໃນການຮັກສາຄວາມສອດຄ່ອງ (consistency) ມີຫຼາຍກວ່າຜົນປະໂຫຍດທີ່ໄດ້ຈາກຄວາມຖືກຕ້ອງໃນການດຶງຂໍ້ມູນ, ຫຼື ຂໍ້ມູນອ້າງອີງແບບງ່າຍໆທີ່ເກືອບບໍ່ມີຄວາມສຳພັນໃດໆ, ຄວນຖືກຈັດໃຫ້ມີບຸລິມະສິດຕ່ຳກວ່າສຳລັບການສ້າງກຣາຟ. ໃນທາງປະຕິບັດ, ວິທີການທີ່ດີແມ່ນການລະບຸຊຸດຄຳຖາມທີ່ການຄົ້ນຫາເອກະສານທີ່ມີຢູ່ນັ້ນຍັງເຮັດວຽກໄດ້ບໍ່ດີກ່ອນ, ຈາກນັ້ນຈຶ່ງທົດສອບວ່າການຕອບຄຳຖາມເຫຼົ່ານັ້ນຈຳເປັນຕ້ອງມີການຕິດຕາມຄວາມສຳພັນຂ້າມຫຼາຍຂັ້ນຕອນ (multiple hops) ຫຼືບໍ່. ສິ່ງນີ້ຈະຊ່ວຍໃຫ້ເຫັນພາບລວມທີ່ຊັດເຈນວ່າຂໍ້ມູນໃດຄວນຖືກນຳມາສ້າງເປັນກຣາຟ. ການນຳສິ່ງນີ້ໄປລວມກັບການຈັດລຳດັບຄວາມສຳຄັນທີ່ໄດ້ກ່າວໄວ້ໃນພາກສ່ວນຂອງການອອກແບບເອນຕິຕີ ແລະ ຄວາມສຳພັນ (entity and relation design) ຈະຊ່ວຍໃຫ້ການຈຳກັດຂອບເຂດຂອງເປົ້າໝາຍງ່າຍຂຶ້ນ.