AI Ready ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຄືຫຍັງ? ເງື່ອນໄຂຂອງຂໍ້ມູນທີ່ AI ນຳໄປໃຊ້ງານໄດ້ ແລະ ແບບຈຳລອງ 3 ຊັ້ນ

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

ສິ່ງທີ່ຢາກເນັ້ນຢ້ຳໃນທີ່ນີ້ແມ່ນ ບໍ່ແມ່ນການສ້າງ Data Warehouse (DWH), ບໍ່ແມ່ນການຈັດກຽມ BI Dashboard, ແລະ ບໍ່ແມ່ນການນຳເອົາເອກະສານພາຍໃນບໍລິສັດເຂົ້າສູ່ RAG ແຕ່ຢ່າງໃດ. ສິ່ງເຫຼົ່ານັ້ນເຖິງຈະເປັນສ່ວນໜຶ່ງຂອງ AI Ready ແຕ່ກໍບໍ່ແມ່ນທັງໝົດ.

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

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

ໃນຫຼາຍໜ້າວຽກ, ການເຮັດໃຫ້ "AI ສາມາດເຂົ້າເຖິງຂໍ້ມູນໄດ້" ຖືກເຂົ້າໃຈວ່າເປັນການກຽມຄວາມພ້ອມດ້ານ AI (AI Ready). ການເກັບຂໍ້ມູນໄວ້ເທິງຄລາວ, ເຮັດໃຫ້ສາມາດອ້າງອີງຜ່ານ API, ແລະ ການປ່ຽນເອກະສານໃຫ້ເປັນເວັກເຕີເພື່ອໃຫ້ສາມາດຄົ້ນຫາໄດ້ — ສິ່ງເຫຼົ່ານີ້ແມ່ນວຽກງານທີ່ຈຳເປັນແທ້.

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

ສະພາວະທີ່ພ້ອມສຳລັບ AI (AI Ready) ໝາຍເຖິງສະພາວະທີ່ນອກເໜືອຈາກການທີ່ຂໍ້ມູນສາມາດເຂົ້າເຖິງໄດ້ທາງກາຍະພາບແລ້ວ ຍັງຕ້ອງຕອບໂຈດເງື່ອນໄຂດັ່ງນີ້: (1) ຂໍ້ມູນນັ້ນມີຄວາມໜ້າເຊື່ອຖື, (2) ມີການກຳນົດຄວາມໝາຍໄວ້ຢ່າງຊັດເຈນ, (3) ມີການຄວບຄຸມສິດທິການເຂົ້າເຖິງຂອງແຕ່ລະບຸກຄົນ, ແລະ (4) ສາມາດຕິດຕາມຍ້ອນຫຼັງໄດ້ວ່າຂໍ້ມູນນັ້ນມີທີ່ມາຈາກໃສ. ການເຂົ້າເຖິງໄດ້ເປັນພຽງຈຸດເລີ່ມຕົ້ນເທົ່ານັ້ນ.

ດ້ວຍການວິວັດທະນາການຂອງ Generative AI, ການຂຽນ SQL ຈາກພາສາທຳມະຊາດໄດ້ຖືກອັດຕະໂນມັດໄປຫຼາຍແລ້ວ. ແຕ່ການທີ່ AI ສາມາດຂຽນ SQL ໄດ້ ກັບການຕອບຄຳຖາມທາງທຸລະກິດໄດ້ຢ່າງຖືກຕ້ອງນັ້ນ ເປັນຄວາມສາມາດທີ່ແຕກຕ່າງກັນຢ່າງສິ້ນເຊີງ.

ຕົວຢ່າງເຊັ່ນ: ເຖິງຈະສົ່ງພຽງແຕ່ຄຳນິຍາມຂອງຕາຕະລາງ (Table definition) ໃຫ້ AI, ແຕ່ບໍລິບົດທາງທຸລະກິດດັ່ງຕໍ່ໄປນີ້ກໍບໍ່ສາມາດອ່ານໄດ້ຈາກ Schema:

• "ຍອດຂາຍ" ແມ່ນລາຄາທີ່ຍັງບໍ່ລວມພາສີ ຫຼື ລວມພາສີແລ້ວ, ລວມເຖິງການສົ່ງຄືນສິນຄ້າ ຫຼື ການຍົກເລີກແລ້ວຫຼືບໍ່
• ຈະຖືເອົາ Customer ID ແລະ Contract ID ໃດເປັນຫຼັກ
• ໃນບັນດານິຍາມ KPI ທີ່ແຕກຕ່າງກັນໃນແຕ່ລະພະແນກ, ອັນໃດຄືນິຍາມທີ່ເປັນທາງການ
• ຝ່າຍຂາຍ, ຝ່າຍບໍລິການລູກຄ້າ ແລະ ຝ່າຍບໍລິຫານ ໄດ້ໃຊ້ຄຳສັບດຽວກັນໃນຄວາມໝາຍທີ່ແຕກຕ່າງກັນຫຼືບໍ່

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

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

ຄຳວ່າ AI Ready ໄດ້ກາຍເປັນສິ່ງທີ່ມີຄວາມສຳຄັນຂຶ້ນມາຢ່າງກະທັນຫັນ ເນື່ອງຈາກຜູ້ທີ່ນຳໃຊ້ຂໍ້ມູນໄດ້ຂະຫຍາຍຕົວຈາກມະນຸດໄປສູ່ AI agent.

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

ຢ່າງໃດກໍຕາມ, ເມື່ອເຮົາພະຍາຍາມນຳ AI agent ມາໃຊ້ໃນວຽກງານການຂາຍ, ການບໍລິການລູກຄ້າ, ການບໍລິຫານຈັດການ ແລະ ວຽກງານຫຼັງບ້ານ (Back office), ຄວາມຮູ້ທີ່ບໍ່ໄດ້ບັນທຶກໄວ້ເຫຼົ່ານີ້ຈະບໍ່ສາມາດນຳມາໃຊ້ໄດ້ອີກຕໍ່ໄປ. AI ບໍ່ມີຄວາມຊົງຈຳຄືກັບມະນຸດ ແລະ ມີຈຳນວນການເຂົ້າເຖິງຂໍ້ມູນຫຼາຍກວ່າມະນຸດຫຼາຍເທົ່າ. ໂດຍສະເພາະໃນບໍລິສັດສະຕາດອັບ ຫຼື ບໍລິສັດຂະໜາດກາງ, ການຈັດການຂໍ້ມູນມັກຈະຕາມບໍ່ທັນຄວາມໄວໃນການເພີ່ມຂຶ້ນຂອງເຄື່ອງມືຕ່າງໆ ເຊັ່ນ: Product DB, CRM, ສະເປຣດຊີດ, ເຄື່ອງມືສົນທະນາ (Chat tool), ເອກະສານ ແລະ ລະບົບຈັດການການສອບຖາມ ເຮັດໃຫ້ເກີດການແຍກສ່ວນຂອງຂໍ້ມູນໄດ້ງ່າຍ. AI Ready ຈຶ່ງເປັນຄວາມພະຍາຍາມໃນການສ້າງ "ກາວທີ່ມະນຸດເຄີຍໃຊ້ເສີມ" ນັ້ນ ໃຫ້ເຂົ້າໄປຢູ່ໃນໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງຂໍ້ມູນໂດຍກົງ.

ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ພ້ອມສຳລັບ AI ສາມາດຈັດລະບຽບໄດ້ງ່າຍໂດຍການພິຈາລະນາອອກເປັນ 3 ຊັ້ນໃຫຍ່ໆ. ສະຫຼຸບແລ້ວ, AI Ready ບໍ່ແມ່ນບັນຫາຂອງເຕັກໂນໂລຊີສະແຕັກ (Tech Stack) ແຕ່ເປັນບັນຫາຂອງການສະສົມ 3 ຊັ້ນ ຄື: ການຈັດກຽມຂໍ້ມູນ, ການໃຫ້ຄວາມໝາຍ ແລະ ການກຳກັບດູແລ (Governance).

ສິ່ງທີ່ຈຳເປັນໃນເບື້ອງຕົ້ນແມ່ນການສ້າງຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້. ໂດຍການລວບລວມຂໍ້ມູນທີ່ກະແຈກກະຈາຍຢູ່ໃນ Product DB, CRM, ການຈັດການໃບແຈ້ງໜີ້, ປະຫວັດການສອບຖາມ, ບັນທຶກການໃຊ້ງານ, ສະເປຣດຊີດ ແລະ ອື່ນໆ ໃຫ້ມາຢູ່ໃນຮູບແບບທີ່ສາມາດນຳໄປວິເຄາະ ຫຼື ໃຊ້ງານກັບ AI ໄດ້.

ໃນຂັ້ນຕອນນີ້, ສິ່ງທີ່ມີປະສິດທິພາບຄື "Medallion Architecture" ທີ່ Databricks ໄດ້ນຳສະເໜີ ແລະ ເຜີຍແຜ່ຢ່າງກວ້າງຂວາງ. ເປັນແນວຄິດການກັ່ນຕອງຂໍ້ມູນເປັນຂັ້ນຕອນ, ໂດຍ Bronze ຈະຄົງຄ່າໄວ້ (ແຊ່ແຂງໄວ້) ຂໍ້ມູນດິບໃນຮູບແບບເດີມ, Silver ຈະເຮັດການທຳຄວາມສະອາດ, ລຶບຂໍ້ມູນຊ້ຳ, ປ່ຽນຮູບແບບຂໍ້ມູນ, ລວມ ຫຼື Merge, ແລະ ກວດສອບ, ສ່ວນ Gold ຈະປັບແຕ່ງໃຫ້ຢູ່ໃນຮູບແບບທີ່ສາມາດນຳໄປໃຊ້ງານທາງທຸລະກິດໄດ້ ເຊັ່ນ: KPI, ລາຍງານແຍກຕາມພາກສ່ວນ, ຫຼື ຕົວຊີ້ວັດການບໍລິຫານ.

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

ຕໍ່ໄປສິ່ງທີ່ຈຳເປັນຄື ການເຮັດໃຫ້ຂໍ້ມູນຢູ່ໃນຮູບແບບທີ່ AI ສາມາດຕີຄວາມໝາຍໄດ້. ກົນໄກທີ່ເປັນຕົວແທນໄດ້ແກ່: Semantic Model, Metrics Layer, Data Catalog ແລະ Ontology.

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

ສິ່ງທີ່ສຳຄັນແທ້ໆສຳລັບ AI ບໍ່ແມ່ນປະລິມານຂໍ້ມູນ, ແຕ່ແມ່ນຄວາມໝາຍ, ຄວາມສຳພັນ, ຂໍ້ຈຳກັດ ແລະ ກົດລະບຽບທາງທຸລະກິດຂອງຂໍ້ມູນນັ້ນ. ຖ້າປາດສະຈາກຊັ້ນຂໍ້ມູນນີ້, AI ກໍມີແຕ່ຕ້ອງຄາດເດົາຄວາມໝາຍຈາກຊື່ຕາຕະລາງ ຫຼື ຊື່ຄໍລຳເທົ່ານັ້ນ. ໃນທາງກົງກັນຂ້າມ, ຖ້າລວມນິຍາມຂອງຕົວຊີ້ວັດໄວ້ທີ່ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ແລະ ເຮັດໃຫ້ເຄື່ອງມື BI ຫຼື AI ທີ່ຢູ່ປາຍທາງສາມາດອ້າງອີງໄດ້ຢ່າງສອດຄ່ອງກັນ, AI ກໍຈະສາມາດຕີຄວາມໝາຍຂໍ້ມູນໃນຮູບແບບທີ່ໃກ້ຄຽງກັບພາສາທາງທຸລະກິດຂອງມະນຸດໄດ້. ການທີ່ແຕ່ລະບໍລິສັດພາກັນ ເປີດຕົວ ຫຼື Launch "ການກຳນົດຕົວຊີ້ວັດໄວ້ທີ່ຈຸດສຳຄັນ" ຫຼື "Semantic Model + Ontology" ກໍຍ້ອນວ່າພວກເຂົາເຫັນວ່າຊັ້ນຂໍ້ມູນນີ້ເອງທີ່ເປັນຕົວຕັດສິນຄວາມຖືກຕ້ອງໃນການນຳໃຊ້ AI.

ໃນໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂໍ້ມູນທີ່ພ້ອມສຳລັບ AI, ການທີ່ຂໍ້ມູນ "ໃຊ້ງານໄດ້" ຢ່າງດຽວນັ້ນຍັງບໍ່ພຽງພໍ ແຕ່ຕ້ອງ "ໃຊ້ງານໄດ້ຢ່າງປອດໄພ" ນຳອີກ.

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

ເມື່ອ AI Agent ເຂົ້າສູ່ຂະບວນການເຮັດວຽກ, ຈຳນວນຄັ້ງ ແລະ ເສັ້ນທາງໃນການເຂົ້າເຖິງຂໍ້ມູນຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ເມື່ອທຽບກັບ BI ແບບດັ້ງເດີມ. ດ້ວຍເຫດນີ້, ການຄວບຄຸມສິດທິ ແລະ ບັນທຶກການກວດສອບ (Audit Log) ຈຶ່ງບໍ່ຄວນຖືກຈັດຕັ້ງປະຕິບັດພຽງແຕ່ໃນຝັ່ງແອັບພລິເຄຊັນເທົ່ານັ້ນ, ແຕ່ຕ້ອງສາມາດຄວບຄຸມໄດ້ຢ່າງສອດຄ່ອງຈາກຝັ່ງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງຂໍ້ມູນ. ຖ້າຫາກສ້າງລະບົບສິດທິແຍກກັນໃນແຕ່ລະແອັບ, ມັນຈະເກີດຊ່ອງວ່າງຂຶ້ນຢ່າງແນ່ນອນ.

ໃນຈຸດນີ້, ແນວຄິດເລື່ອງຄວາມສາມາດໃນການສັງເກດການ (Observability) ຈຶ່ງມີບົດບາດສຳຄັນ. OpenTelemetry ໄດ້ນິຍາມຄວາມສາມາດໃນການສັງເກດການວ່າເປັນ "ຄວາມສາມາດໃນການເຂົ້າໃຈສະຖານະພາຍໃນຂອງລະບົບຈາກຜົນລວມທີ່ອອກມາ". ການເຮັດໃຫ້ສາມາດຕິດຕາມຄວາມລ່າຊ້າຂອງຂະບວນການ ຫຼື Pipeline, ການຫຼຸດລົງຂອງຄຸນນະພາບ, ແລະ ແຫຼ່ງທີ່ມາຂອງຄຳຕອບຂອງ AI ຈາກຜົນລວມທີ່ອອກມາໄດ້ນັ້ນ, ຖືເປັນເງື່ອນໄຂເບື້ອງຕົ້ນໃນການນຳ AI ມາໃຊ້ໃນການເຮັດວຽກ. ສຳລັບລາຍລະອຽດເພີ່ມເຕີມ, ກະລຸນາເບິ່ງທີ່ AIガバナンスとEU AI Act対応 ເພີ່ມເຕີມ.

ໃນໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂໍ້ມູນຍຸກ AI, ຂໍ້ມູນທີ່ມີໂຄງສ້າງເຊັ່ນ: ຍອດຂາຍ ຫຼື ສັນຍາ ພຽງຢ່າງດຽວນັ້ນບໍ່ພຽງພໍ. "ເຫດຜົນ" ຂອງການຕັດສິນໃຈທາງທຸລະກິດ ສ່ວນຫຼາຍມັກຈະຝັງຢູ່ໃນຂໍ້ມູນທີ່ບໍ່ມີໂຄງສ້າງ. ວິທີການເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນ ທັງສອງປະເພດນີ້ເຂົ້າດ້ວຍກັນ ຄືຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ທີ່ຕັດສິນວ່າຈະກ້າວໄປສູ່ຄວາມພ້ອມດ້ານ AI (AI Ready) ໄດ້ຫຼືບໍ່.

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

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

ຖ້າຖາມວ່າການນຳຂໍ້ມູນທີ່ບໍ່ມີໂຄງສ້າງ (Unstructured data) ໃສ່ເຂົ້າໄປໃນ RAG ຈະສາມາດແກ້ໄຂບັນຫາໄດ້ຫຼືບໍ່, ຄຳຕອບຄືພຽງເທົ່ານັ້ນຍັງບໍ່ພຽງພໍ. ການນຳເອກະສານເຂົ້າໄປໃນ Vector Database ເພື່ອໃຫ້ສາມາດຄົ້ນຫາໄດ້ນັ້ນ ເປັນພຽງຈຸດເລີ່ມຕົ້ນເທົ່ານັ້ນ ບໍ່ແມ່ນເປົ້າໝາຍສຸດທ້າຍ.

ສິ່ງທີ່ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ແທ້ໆຄືການເຊື່ອມຕໍ່ຂໍ້ມູນທີ່ບໍ່ມີໂຄງສ້າງເຂົ້າກັບຂໍ້ມູນທີ່ມີໂຄງສ້າງ ແລະ ຜູກມັດເຂົ້າກັບບັນດາ Business Entity ຕ່າງໆ ເຊັ່ນ: ລູກຄ້າ, ສັນຍາ, ໂຄງການ, ຜູ້ຮັບຜິດຊອບ, ຜະລິດຕະພັນ ແລະ KPI. ຖ້າບໍ່ຮູ້ວ່າບັນທຶກການເຈລະຈາທຸລະກິດນັ້ນເປັນຂອງ "ລູກຄ້າຄົນໃດ" ຫຼື "ໂຄງການໃດ", AI ກໍຈະບໍ່ສາມາດວາງຂໍ້ຄວາມທີ່ຄົ້ນຫາພົບນັ້ນໃຫ້ຢູ່ໃນບໍລິບົດ (Context) ທີ່ຖືກຕ້ອງໄດ້.

ເພື່ອເພີ່ມຄວາມແມ່ນຍຳ, ການອອກແບບລະບົບການຄົ້ນຫາກໍເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້. ວິທີການຕ່າງໆເຊັ່ນ: Hybrid Search ທີ່ປະສົມປະສານລະຫວ່າງ Vector Search ແລະ Full-text Search, ຫຼື Agentic RAG ທີ່ເຮັດການຄົ້ນຫາ ແລະ ການອະນຸມານຊ້ຳໄປຊ້ຳມາ ແມ່ນມີປະສິດທິຜົນ, ແຕ່ພື້ນຖານຂອງມັນຄື "ການທີ່ຂໍ້ມູນບໍ່ມີໂຄງສ້າງຖືກເຊື່ອມຕໍ່ກັບ Business Entity" ເປັນເງື່ອນໄຂເບື້ອງຕົ້ນ. ບັນຫາດ້ານຄວາມແມ່ນຍຳຂອງ RAG ສ່ວນຫຼາຍບໍ່ໄດ້ເກີດຈາກເທັກໂນໂລຊີການຄົ້ນຫາ, ແຕ່ເກີດຈາກການຂາດການເຊື່ອມຕໍ່ນີ້. ຂໍ້ຜິດພາດທີ່ພົບເລື້ອຍໄດ້ຖືກສະຫຼຸບໄວ້ໃນ ຮູບແບບຄວາມລົ້ມເຫຼວໃນການສ້າງ RAG.

ຂ້າງລຸ່ມນີ້ແມ່ນການແບ່ງ 3 ຊັ້ນທີ່ກ່າວມາຂ້າງເທິງໃຫ້ເປັນ 5 ຂໍ້ກຳນົດທີ່ສາມາດກວດສອບໄດ້ໃນການປະຕິບັດງານຕົວຈິງ. ສະຫຼຸບກໍຄື, ຄວາມພ້ອມດ້ານ AI (AI Ready) ສາມາດຕັດສິນໄດ້ຈາກການມີຄົບທັງ 5 ຈຸດ ຄື: "ຄວາມເຊື່ອໝັ້ນ, ຄວາມໝາຍ, ການເຊື່ອມຕໍ່, ສິດອຳນາດ, ແລະ ຫຼັກຖານ".

ທັງ 5 ຂໍ້ນີ້ ຖ້າຂາດຂໍ້ໃດຂໍ້ໜຶ່ງໄປ ກໍຈະເຮັດໃຫ້ພາບລວມເຮັດວຽກໄດ້ຍາກ. ຕົວຢ່າງເຊັ່ນ: ເຖິງຈະມີຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້ (ຂໍ້ກຳນົດທີ 1) ແຕ່ຖ້າບໍ່ມີການກຳນົດຄວາມໝາຍ (ຂໍ້ກຳນົດທີ 2) AI ກໍຈະຕີຄວາມໝາຍຜິດພາດ. ເຖິງຈະມີການກຳນົດຄວາມໝາຍແລ້ວ ແຕ່ຖ້າບໍ່ມີການຈັດການສິດອຳນາດ (ຂໍ້ກຳນົດທີ 4) ກໍຈະບໍ່ສາມາດເປີດໃຊ້ງານໄດ້ຢ່າງປອດໄພ. ການນຳເອົາສະຖານະປັດຈຸບັນຂອງບໍລິສັດຕົນເອງມາທຽບໃສ່ຕາຕະລາງນີ້ ເພື່ອເບິ່ງວ່າຂໍ້ກຳນົດໃດຍັງອ່ອນແອ ຄືບາດກ້າວທຳອິດຂອງການກຽມຄວາມພ້ອມດ້ານ AI (AI Ready).

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

BI ແບບດັ້ງເດີມແມ່ນການທີ່ມະນຸດເປີດແຜງຄວບຄຸມ (Dashboard) ເພື່ອຊອກຫາຄວາມຜິດປົກກະຕິ, ກວດສອບສາເຫດ ແລະ ຄິດຫາການກະທຳຕໍ່ໄປ. ຈຸດເລີ່ມຕົ້ນທັງໝົດແມ່ນຢູ່ທີ່ "ການທີ່ຄົນເຮົາຕ້ອງເຂົ້າໄປເບິ່ງເອງ".

ເທິງພື້ນຖານທີ່ພ້ອມສຳລັບ AI (AI Ready), AI ຈະສາມາດເຄື່ອນໄຫວໄດ້ດ້ວຍຕົນເອງ. ມັນຈະກວດຈັບການປ່ຽນແປງຂອງ KPI, ອະທິບາຍຂະໜາດ ແລະ ຄວາມຜິດປົກກະຕິຂອງການປ່ຽນແປງນັ້ນ, ກວດສອບປັດໄຈທີ່ກ່ຽວຂ້ອງ, ນຳສະເໜີຂໍ້ມູນ ແລະ ເອກະສານອ້າງອີງ, ສະເໜີການກະທຳຕໍ່ໄປ ແລະ ແຈ້ງເຕືອນຜູ້ຮັບຜິດຊອບຕາມຄວາມຈຳເປັນ—ເຊິ່ງນີ້ຄືຂະບວນການທີ່ຕໍ່ເນື່ອງກັນ. ເຄື່ອງມືການເບິ່ງເຫັນຂໍ້ມູນ (Data Visualization) ລຸ້ນໃໝ່ທີ່ກຳລັງຊູຈຸດເດັ່ນເລື່ອງ "ຄວາມເຂົ້າໃຈແບບ Proactive" ຫຼື "BI ແບບເນັ້ນການປະຕິບັດ" ແມ່ນເພື່ອແນໃສ່ການຫັນປ່ຽນໄປໃນທິດທາງນີ້. BI ກຳລັງປ່ຽນແປງລັກສະນະຈາກ "ສິ່ງທີ່ຕ້ອງເບິ່ງ" ໄປສູ່ "ສິ່ງທີ່ສາມາດເຄື່ອນໄຫວໄດ້".

ຢ່າງໃດກໍຕາມ, ມີສິ່ງໜຶ່ງທີ່ຕ້ອງລະວັງໃນທີ່ນີ້. ຖ້າພຽງແຕ່ແຈ້ງເຕືອນຜ່ານແຊັດວ່າ "ຍອດຂາຍຫຼຸດລົງ", ນັ້ນກໍເປັນພຽງແຕ່ Alert bot ເທົ່ານັ້ນ. ສິ່ງທີ່ມີຄຸນຄ່າແທ້ຈິງແມ່ນສິ່ງທີ່ເກີດຂຶ້ນຫຼັງຈາກນັ້ນ.

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

ຍົກຕົວຢ່າງ, ໃຫ້ລອງພິຈາລະນາ AI Agent ສໍາລັບການສະໜັບສະໜູນການບໍລິຫານ. ສິ່ງທີ່ຕ້ອງການຄື ຂະບວນການທີ່ກວດຈັບການປ່ຽນແປງຂອງ KPI, ຕັດສິນໃຈວ່າເປັນການເໜັງຕີງປົກກະຕິຫຼືເປັນຄ່າທີ່ຜິດປົກກະຕິ, ເບິ່ງວ່າເກີດຂຶ້ນໃນ Segment ໃດ, ກວດສອບເຫດການທີ່ກ່ຽວຂ້ອງໃນດ້ານການຂາຍ, ການສະໜັບສະໜູນ ແລະ ຜະລິດຕະພັນ, ຈັດລະບຽບສົມມຸດຕິຖານຂອງສາເຫດ, ສະເໜີມາດຕະການຕໍ່ໄປ, ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຜູ້ຮັບຜິດຊອບ, ແລະ ສະສົມຜົນລັພເປັນ Feedback. ເພື່ອໃຫ້ສິ່ງນີ້ເກີດຂຶ້ນໄດ້, ພຽງແຕ່ DWH ຢ່າງດຽວນັ້ນບໍ່ພຽງພໍ. ມັນຈໍາເປັນຕ້ອງມີພື້ນຖານທີ່ຄົບວົງຈອນ ເຊິ່ງລວມເຖິງການກໍານົດຄວາມໝາຍ, Data Catalog, ຄວາມຮູ້ທາງທຸລະກິດ, RAG, ການຈັດການສິດທິ, Audit Log ແລະ Feedback Loop. ການທີ່ Data Platform ທີ່ພ້ອມສໍາລັບ AI (AI Ready) ປ່ຽນຈາກ "ພື້ນຖານສໍາລັບ Dashboard" ມາເປັນ "ພື້ນຖານທາງທຸລະກິດທີ່ຮອງຮັບການຕັດສິນໃຈ ແລະ ການປະຕິບັດງານ" ກໍແມ່ນໝາຍເຖິງເລື່ອງນີ້ເອງ.

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

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

ຫາກເຊື່ອມຕໍ່ AI ໂດຍທີ່ຍັງບໍ່ທັນມີຄວາມພ້ອມໃນຈຸດນີ້, AI ອາດຈະນຳເອົາຕົວເລກທີ່ແຕກຕ່າງກັນຂອງແຕ່ລະພະແນກມາ ລວມ ຫຼື Merge ເຂົ້າກັນຢ່າງບໍ່ມີບັນຫາ ເຊິ່ງຈະຍິ່ງສ້າງຄວາມສັບສົນຫຼາຍກວ່າເກົ່າ. ດ້ວຍເຫດນີ້, ບໍລິສັດຂອງພວກເຮົາຈຶ່ງແນະນຳວ່າ ເຖິງຈະເປັນການເລີ່ມຕົ້ນແບບຂະໜາດນ້ອຍ (Small Start) ກໍຕາມ, ແຕ່ການໃຫ້ຄວາມໝາຍໃນຊັ້ນທີ 2 (ການກຳນົດຄຳສັບ ແລະ KPI) ແມ່ນສິ່ງທີ່ບໍ່ຄວນຜັດຜ່ອນ. ໃນຕອນເລີ່ມຕົ້ນ, ອາດຈະຈຳກັດຂອບເຂດໃຫ້ຢູ່ໃນພື້ນທີ່ການເຮັດວຽກດຽວກ່ອນກໍໄດ້. ແຕ່ສຳລັບພື້ນທີ່ນັ້ນ, ຕ້ອງອອກແບບການກຳນົດຄຳນິຍາມ, ການເຊື່ອມຕໍ່ຂໍ້ມູນ ແລະ ສິດທິໃນການເຂົ້າເຖິງຂໍ້ມູນໃຫ້ຄົບຊຸດຕັ້ງແຕ່ຕົ້ນ. ເຖິງຈະຈຳກັດຂອບເຂດໃຫ້ແຄບລົງ ແຕ່ຕ້ອງເຮັດໃຫ້ຄົບທຸກຊັ້ນ — ນີ້ຄືລຳດັບຂັ້ນຕອນທີ່ເປັນຈິງທີ່ສຸດເພື່ອຫຼຸດຜ່ອນການເຮັດວຽກຊ້ຳຊ້ອນ.

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

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

ຂ້າພະເຈົ້າໄດ້ລວບລວມຄຳຖາມທີ່ມັກພົບເລື້ອຍໃນສະໜາມການໃຫ້ຄຳປຶກສາກ່ຽວກັບໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ພ້ອມສຳລັບ AI (AI Ready).

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

ບາງສ່ວນອາດຈະເປັນໄປໄດ້ ແຕ່ພຽງເທົ່ານັ້ນມັກຈະເຮັດໃຫ້ຄວາມຖືກຕ້ອງຢຸດຢູ່ກັບທີ່. ການເຮັດໃຫ້ RAG ສາມາດຄົ້ນຫາເອກະສານໄດ້ນັ້ນເປັນພຽງຈຸດເລີ່ມຕົ້ນ, ສິ່ງທີ່ໄດ້ຜົນແທ້ຈິງແມ່ນການເຊື່ອມຕໍ່ຂໍ້ມູນທີ່ບໍ່ມີໂຄງສ້າງ (Unstructured data) ເຂົ້າກັບ Business Entity ເຊັ່ນ: ລູກຄ້າ, ສັນຍາ ແລະ ໂຄງການ. ຖ້າຂາດການເຊື່ອມຕໍ່, AI ຈະບໍ່ສາມາດວາງຜົນການຄົ້ນຫາໄວ້ໃນບໍລິບົດທີ່ຖືກຕ້ອງໄດ້. ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມ, ກະລຸນາເບິ່ງທີ່ ຮູບແບບຄວາມລົ້ມເຫຼວໃນການສ້າງ RAG.

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

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

ການຈະເຮັດໃຫ້ສິ່ງນີ້ເກີດຂຶ້ນໄດ້ ຈຳເປັນຕ້ອງມີ 3 ຊັ້ນ ຄື: ຊັ້ນທີ 1 ການຈັດກຽມຂໍ້ມູນ, ຊັ້ນທີ 2 ການໃຫ້ຄວາມໝາຍ, ແລະ ຊັ້ນທີ 3 ການນຳໃຊ້ຢ່າງປອດໄພ, ພ້ອມດ້ວຍ 5 ຂໍ້ກຳນົດ ຄື: ຄວາມເຊື່ອໝັ້ນ, ຄວາມໝາຍ, ການເຊື່ອມຕໍ່, ສິດອຳນາດ ແລະ ຫຼັກຖານອ້າງອີງ. DWH, BI ແລະ RAG ບໍ່ແມ່ນພຽງແຕ່ຢ່າງໃດຢ່າງໜຶ່ງໃນນັ້ນ, ແຕ່ຕ້ອງເປັນການລວມ ຫຼື Merge ສິ່ງເຫຼົ່ານີ້ເຂົ້າກັນເປັນພາບລວມ ຈຶ່ງຈະກາຍເປັນ AI Ready ໄດ້ຢ່າງແທ້ຈິງ.

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