ການຄົ້ນຫາແບບ Cross-lingual Embedding ແມ່ນເທັກໂນໂລຢີທີ່ຊອກຫາເອກະສານໃນພາສາອື່ນດ້ວຍຄຳຄົ້ນ (Query) ຂອງພາສາໜຶ່ງ ໂດຍບໍ່ຈຳເປັນຕ້ອງແປພາສາ ແຕ່ໃຊ້ພຽງແຕ່ຄວາມໃກ້ຄຽງທາງຄວາມໝາຍເທົ່ານັ້ນ. ແບບຈຳລອງ Embedding ຫຼາຍພາສາ (Multilingual Embedding Model) ຖືກຄາດຫວັງວ່າຈະເຮັດໃຫ້ສິ່ງນີ້ເກີດຂຶ້ນໄດ້ໃນພື້ນທີ່ Vector ດຽວທີ່ກວມເອົາທຸກພາສາ. ແຕ່ຈາກການທົດສອບຕົວຈິງຂອງພວກເຮົາໃນໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ການຄົ້ນຫາຄວາມຮູ້ (RAG) ທີ່ຮອງຮັບພາສາຢີ່ປຸ່ນ, ອັງກິດ, ໄທ ແລະ ລາວ, ພົບວ່າສຳລັບພາສາລາວ ເຊິ່ງເປັນພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍ (Low-resource language) ນັ້ນ, ການຄົ້ນຫາຂ້າມພາສາເກືອບຈະບໍ່ສາມາດໃຊ້ງານໄດ້ເລີຍ. ບົດຄວາມນີ້ໄດ້ລວບລວມຂໍ້ມູນຂັ້ນຕົ້ນທີ່ວັດແທກປະສິດທິພາບການແຍກແຍະຕາມແຕ່ລະພາສາ, ຄຳອະທິບາຍທາງໂຄງສ້າງກ່ຽວກັບສາເຫດ, ແລະ ວິທີແກ້ໄຂທີ່ເປັນຈິງທີ່ເອີ້ນວ່າ "ດັດຊະນີແຍກຕາມພາສາ" (Language-specific index). ກຸ່ມເປົ້າໝາຍຂອງບົດຄວາມນີ້ແມ່ນວິສະວະກອນທີ່ອອກແບບລະບົບການຄົ້ນຫາຄວາມຮູ້ຫຼາຍພາສາ ຫຼື RAG, ເຊິ່ງເມື່ອອ່ານຈົບແລ້ວ ທ່ານຈະສາມາດທົບທວນຄືນສົມມຸດຕິຖານທີ່ວ່າ "ການຄົ້ນຫາແບບ Cross-lingual ບໍ່ໄດ້ໃຊ້ໄດ້ກັບທຸກພາສາ" ແລະ ໄດ້ຮັບຂັ້ນຕອນການວັດແທກປະສິດທິພາບການແຍກແຍະສຳລັບແຕ່ລະພາສາເປົ້າໝາຍກັບຄືນໄປນຳ.

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

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

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

ຜົນການວັດແທກແມ່ນມີຄວາມຊັດເຈນ. ພາສາຍີ່ປຸ່ນ, ພາສາອັງກິດ ແລະ ພາສາໄທ ສາມາດເຮັດວຽກແບບຂ້າມພາສາ (Cross-lingual) ໄດ້, ສ່ວນພາສາລາວພັດມີຄ່າຄວາມຄ້າຍຄືກັນຕໍ່າກວ່າປະໂຫຍກທີ່ບໍ່ກ່ຽວຂ້ອງກັນ, ເຊິ່ງໃນທາງປະຕິບັດແລ້ວແມ່ນຕັ້ງສາກກັບພາສາອື່ນໆ. ຕໍ່ໄປນີ້ແມ່ນຄ່າທັງໝົດທີ່ບໍລິສັດຂອງພວກເຮົາໄດ້ວັດແທກດ້ວຍຕົວແບບການຝັງຫຼາຍພາສາ (Multilingual Embedding Model) ດຽວກັນ (ຍິ່ງປະໂຫຍກທີ່ມີຄວາມໝາຍດຽວກັນມີຄ່າຄວາມຄ້າຍຄືກັນສູງເທົ່າໃດ ກໍຍິ່ງດີ).

ພວກເຮົາໄດ້ກຳນົດໃຫ້ເອກະສານເປັນພາສາជប៉ុນ ແລະ ວັດແທກຄວາມຄ້າຍຄືກັນຂອງເອກະສານທີ່ມີຄວາມໝາຍດຽວກັນຈາກຄຳຖາມ (Query) ຂອງແຕ່ລະພາສາ. ຄວາມຄ້າຍຄືກັນຂອງເອກະສານທີ່ບໍ່ກ່ຽວຂ້ອງກັນແມ່ນປະມານ 0.21, ເຊິ່ງຖ້າຕ່ຳກວ່າລະດັບນີ້ສາມາດຕັດສິນໄດ້ວ່າ "ບໍ່ມີຄວາມໝາຍເຊື່ອມໂຍງກັນ".

ສະຫຼຸບ: ພາສາជប៉ុນ, ພາສາອັງກິດ ແລະ ພາສາໄທ ມີຄ່າສູງກວ່າມາດຕະຖານສຽງລົບກວນ (ປະມານ 0.21) ຢ່າງພຽງພໍ, ແຕ່ພາສາລາວມີຄ່າພຽງ 0.03 ເຊິ່ງຕ່ຳກວ່າສຽງລົບກວນ ແລະ ເກືອບຈະຕັ້ງສາກກັນ.

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

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

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

ການກ່າວວ່າ "ພາສາລາວມີບັນຫາ" ບໍ່ໄດ້ໝາຍຄວາມວ່າພາສາລາວທັງໝົດໃຊ້ການບໍ່ໄດ້. ເມື່ອວັດແທກວ່າສາມາດແຍກປະໂຫຍກທີ່ມີຄວາມໝາຍດຽວກັນອອກຈາກປະໂຫຍກທີ່ບໍ່ກ່ຽວຂ້ອງກັນພາຍໃນພາສາໄດ້ຫຼາຍປານໃດ (ຄວາມສາມາດໃນການຈຳແນກ = ຄວາມຄ້າຍຄືກັນຂອງຄວາມໝາຍດຽວກັນ - ຄວາມຄ້າຍຄືກັນຂອງສິ່ງທີ່ບໍ່ກ່ຽວຂ້ອງ), ພາສາລາວກໍຍັງເຮັດວຽກໄດ້.

ເຖິງວ່າຄ່າ 0.34 ຂອງພາສາລາວຈະຕໍ່າກວ່າພາສາອື່ນ ແຕ່ກໍຍັງສາມາດແຍກອອກຈາກປະໂຫຍກທີ່ບໍ່ກ່ຽວຂ້ອງໄດ້. ຄ່າທີ່ນ້ອຍກວ່ານີ້ເລັກນ້ອຍແມ່ນຍ້ອນວ່າປະໂຫຍກທີ່ບໍ່ກ່ຽວຂ້ອງກັນກໍມີຄ່າຄວາມຄ້າຍຄືກັນທີ່ສູງ (ພື້ນທີ່ຖືກບີບອັດ). ນອກຈາກນີ້, ເມື່ອປຽບທຽບກັບ Model ຝັງຂໍ້ມູນແບບທົ່ວໄປອື່ນ (Model ເກົ່າ), ຈະເຫັນໄດ້ວ່າການເຊື່ອມໂຍງລະຫວ່າງພາສາ (Cross-lingual) ຂອງພາສາລາວໃນ Model ເກົ່ານັ້ນກໍລົ້ມເຫຼວ (ຄວາມໝາຍດຽວກັນ 0.14 < ບໍ່ກ່ຽວຂ້ອງ 0.25). ໃນທາງກັບກັນ, ຄວາມສາມາດໃນການຈຳແນກພາຍໃນພາສາລາວເອງໄດ້ມີການປັບປຸງຈາກ 0.18 ໃນ Model ເກົ່າ ມາເປັນ 0.34 ໃນ Model ປັດຈຸບັນ. ສະຫຼຸບໄດ້ວ່າ ການລົ້ມເຫຼວຂອງ Cross-lingual ບໍ່ແມ່ນ Bug ສະເພາະຂອງ Model ໃດໜຶ່ງ ແຕ່ເປັນຂໍ້ຈຳກັດທາງໂຄງສ້າງທີ່ພົບເຫັນໄດ້ທົ່ວໄປໃນພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍ.

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

ແບບຈຳລອງການຝັງ (Embedding model) ສາມາດເຮັດຄະແນນໄດ້ 0.80 ໃນການຄົ້ນຫາພາສາລາວດ້ວຍກັນເອງນັ້ນ ກໍຍ້ອນວ່າມັນສາມາດຮຽນຮູ້ໄດ້ວ່າ "ຂໍ້ຄວາມພາສາລາວແຕ່ລະອັນມີຄວາມໝາຍໃກ້ຄຽງກັນຫຼາຍສ່ຳໃດ". ສິ່ງນີ້ສາມາດບັນລຸໄດ້ຫາກມີການກະຈາຍຕົວພາຍໃນພາສາໜຶ່ງໆຢ່າງພຽງພໍ. ໃນທາງກົງກັນຂ້າມ, ການຄົ້ນຫາແບບຂ້າມພາສາ (Cross-lingual search) ຮຽກຮ້ອງໃຫ້ມີຄວາມສາມາດໃນການຈັດລຽງ (Alignment) ເພື່ອ "ແປງແນວຄິດຂອງພາສາລາວ ໃຫ້ໄປຢູ່ໃນພື້ນທີ່ຍ່ອຍ (Subspace) ດຽວກັນກັບແນວຄິດດຽວກັນໃນພາສາອື່ນ", ເຊິ່ງສິ່ງນີ້ຈຳເປັນຕ້ອງໃຊ້ເບາະແສໃນການແປ (Parallel corpus ຫຼື ການປາກົດຮ່ວມກັນລະຫວ່າງພາສາ) ຈຳນວນມະຫາສານ. ເຖິງແມ່ນວ່າຄວາມຄ້າຍຄືກັນພາຍໃນພາສາດຽວກັນຈະເຮັດວຽກໄດ້ດີ, ແຕ່ຖ້າຂາດການຈັດລຽງລະຫວ່າງພາສາ, ພຽງແຕ່ການຄົ້ນຫາແບບຂ້າມພາສາກໍຈະເສຍຫາຍກ່ອນ. ສິ່ງທີ່ສັງເກດເຫັນໃນພາສາລາວຄັ້ງນີ້ ກໍຄືສະພາວະ "ເຮັດວຽກໄດ້ພຽງດ້ານດຽວ" ນີ້ເອງ. ຖ້າຈະປຽບທຽບກໍຄື ແຜນທີ່ພາສາລາວຖືກແຕ້ມຂຶ້ນຢ່າງຖືກຕ້ອງພາຍໃນໂລກຂອງພາສາລາວ, ແຕ່ບໍ່ມີລະບົບພິກັດທີ່ໃຊ້ໃນການວາງແຜນທີ່ນັ້ນລົງເທິງຕຳແໜ່ງທີ່ຖືກຕ້ອງຂອງແຜນທີ່ໂລກ. ຄວາມລະອຽດຂອງແຜນທີ່ເອງ (ຄວາມຄ້າຍຄືກັນພາຍໃນພາສາດຽວກັນ) ແລະ ພະລັງໃນການວາງແຜນທີ່ລົງເທິງພິກັດຮ່ວມ (ການຈັດລຽງລະຫວ່າງພາສາ) ແມ່ນບັນຫາທີ່ແຕກຕ່າງກັນໂດຍສິ້ນເຊີງ.

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

ເມື່ອພົບວ່າການຄົ້ນຫາແບບຂ້າມພາສາ (Cross-lingual) ມີບັນຫາ, ສິ່ງທຳອິດທີ່ຢາກຈະລົງມືເຮັດຄືການປັບແຕ່ງຂໍ້ມູນເບື້ອງຕົ້ນ (Pre-processing) ເຊັ່ນ: ຕົວຕັດຄຳ (Tokenizer), ການປັບຮູບແບບຕົວອັກສອນ, ຫຼື ການຈັດການຄຳທີ່ບໍ່ມີຄວາມໝາຍ (Stop words). ແຕ່ການພັງທະລາຍໃນຄັ້ງນີ້ບໍ່ແມ່ນບັນຫາຂອງຊັ້ນການປັບແຕ່ງຂໍ້ມູນເບື້ອງຕົ້ນ. ຄວາມຈິງທີ່ວ່າການຄົ້ນຫາພາຍໃນພາສາລາວດ້ວຍກັນເອງມີຄ່າຢູ່ທີ່ 0.80 ເຊິ່ງເຮັດວຽກໄດ້ດີນັ້ນ, ໄດ້ສະແດງໃຫ້ເຫັນວ່າການປັບແຕ່ງຂໍ້ມູນເບື້ອງຕົ້ນເຮັດວຽກໄດ້ຢ່າງຖືກຕ້ອງ. ສິ່ງທີ່ເສຍຫາຍແມ່ນຄວາມສອດຄ່ອງລະຫວ່າງພາສາທີ່ Embedding model ໄດ້ຮຽນຮູ້, ບໍ່ວ່າຈະປັບແຕ່ງວິທີການປ້ອນຂໍ້ມູນໃຫ້ດີຂຶ້ນເທົ່າໃດ, ເວັກເຕີຂອງພາສາລາວກໍຈະບໍ່ເຂົ້າໃກ້ພື້ນທີ່ຂອງພາສາອື່ນ. ກ່ອນທີ່ຈະເສຍເວລາໄປກັບການປັບປຸງການປັບແຕ່ງຂໍ້ມູນເບື້ອງຕົ້ນ, ຄວນແຍກໃຫ້ອອກກ່ອນວ່າ "ພາສາອັນດຽວກັນຍັງເຮັດວຽກໄດ້ ແຕ່ມີພຽງການຄົ້ນຫາແບບຂ້າມພາສາເທົ່ານັ້ນທີ່ເສຍຫາຍ" ຫຼື "ເສຍຫາຍທັງສອງຢ່າງ". ຖ້າເປັນກໍລະນີທຳອິດ, ສາເຫດແມ່ນມາຈາກການຂາດຄວາມສາມາດໃນການສ້າງຄວາມສອດຄ່ອງ, ແລະ ການແກ້ໄຂບໍ່ໄດ້ຢູ່ທີ່ການປັບແຕ່ງຂໍ້ມູນເບື້ອງຕົ້ນ ແຕ່ຢູ່ທີ່ຝັ່ງຂອງສະຖາປັດຕະຍະກຳການຄົ້ນຫາ.

ສົມມຸດຕິຖານທີ່ວ່າ "ໂມເດວການຝັງຕົວແບບຫຼາຍພາສາ (Multilingual embedding model) = ສາມາດຄົ້ນຫາເອກະສານໃນພາສາໃດກໍໄດ້ດ້ວຍຄຳຄົ້ນ (Query) ຈາກພາສາໃດກໍໄດ້" ນັ້ນ ເປັນພຽງການປະມານການທີ່ໃຊ້ໄດ້ກັບພາສາທີ່ມີຊັບພະຍາກອນສູງ ແລະ ປານກາງເທົ່ານັ້ນ. ສຳລັບຜູ້ໃຊ້ພາສາທີ່ມີຊັບພະຍາກອນຕ່ຳ, ບໍ່ຄວນເພິ່ງພາການຄົ້ນຫາແບບຂ້າມພາສາ (Cross-lingual search). ສິ່ງທີ່ຫຍຸ້ງຍາກກໍຄື ຄວາມຜິດພາດນີ້ເກີດຂຶ້ນຢ່າງງຽບໆ ໂດຍບໍ່ມີການແຈ້ງເຕືອນ ຫຼື ບັນທຶກ Log ໃດໆ. ພຽງແຕ່ຄ່າຄວາມຄ້າຍຄືກັນ (Similarity) ຕ່ຳ, ລະບົບກໍຈະສົ່ງເອກະສານທີ່ບໍ່ກ່ຽວຂ້ອງກັບມາຢ່າງໜ້າຕາເສີຍ ຫຼື ສົ່ງຜົນລາຍງານວ່າບໍ່ພົບຂໍ້ມູນ (Zero results) ຂຶ້ນກັບຄ່າ Threshold. ສຳລັບຜູ້ໃຊ້, ມັນເບິ່ງຄືວ່າ "ບໍ່ມີຄຳຕອບ", ໃນຂະນະທີ່ຝ່າຍປະຕິບັດງານເຫັນວ່າ "ລະບົບການຄົ້ນຫາຍັງເຮັດວຽກປົກກະຕິ". ດັ່ງນັ້ນ, ຖ້າກວດສອບພຽງແຕ່ພາສາທີ່ມີຊັບພະຍາກອນສູງແລ້ວບໍ່ພົບບັນຫາ, ກໍຈະບໍ່ມີໃຜຮູ້ເລີຍວ່າຜູ້ໃຊ້ພາສາທີ່ມີຊັບພະຍາກອນຕ່ຳກຳລັງຖືກບັງຄັບໃຫ້ໃຊ້ການຄົ້ນຫາທີ່ບໍ່ໄດ້ຜົນ. ຖ້າຕ້ອງການຕິດຕາມກວດສອບ, ຄວນສະແດງອັດຕາການພົບຂໍ້ມູນ (Hit rate) ແລະ ຄ່າສະເລ່ຍຄວາມຄ້າຍຄືກັນແຍກຕາມພາສາໄວ້ໃນ Dashboard ເພື່ອເບິ່ງວ່າພາສາໃດພາສາໜຶ່ງມີຄ່າຕ່ຳຜິດປົກກະຕິຢ່າງຕໍ່ເນື່ອງຫຼືບໍ່. ຈາກນັ້ນ, ມີຂໍ້ສະເໜີແນະສອງຢ່າງທີ່ເປັນປະໂຫຍດຕໍ່ການອອກແບບ.

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

ບໍ່ຈຳເປັນຕ້ອງມີມາດຕະຖານ ຫຼື Specification ພິເສດ. ສຳລັບແຕ່ລະພາສາ, ພຽງແຕ່ກຽມ (1) ຄູ່ຂອງ Query ແລະ ເອກະສານທີ່ມີຄວາມໝາຍດຽວກັນ (ຄູ່ທີ່ມີຄວາມໝາຍຄືກັນ), ແລະ (2) ຄູ່ຂອງ Query ແລະ ເອກະສານທີ່ບໍ່ກ່ຽວຂ້ອງກັນ (ຄູ່ທີ່ບໍ່ກ່ຽວຂ້ອງ) ຢ່າງລະຫຼາຍສິບຄູ່, ແລ້ວປຽບທຽບການກະຈາຍຂອງຄ່າຄວາມຄ້າຍຄືກັນຂອງແຕ່ລະຄູ່ກໍພຽງພໍແລ້ວ. ຖ້າຄ່າຄວາມຄ້າຍຄືກັນຂອງຄູ່ທີ່ມີຄວາມໝາຍຄືກັນສູງກວ່າຄູ່ທີ່ບໍ່ກ່ຽວຂ້ອງຢ່າງເຫັນໄດ້ຊັດ ສະແດງວ່າລະບົບເຮັດວຽກໄດ້ດີ, ແຕ່ຖ້າຄ່າເທົ່າກັນ ຫຼື ຕ່ຳກວ່າ ສະແດງວ່າລະບົບລົ້ມເຫຼວ. ຖ້າຕ້ອງການວັດແທກການຂ້າມພາສາ (Cross-lingual), ໃຫ້ກຽມຄູ່ທີ່ Query ແລະ ເອກະສານມີພາສາທີ່ແຕກຕ່າງກັນ. ຖ້າຕົວຢ່າງໜ້ອຍເກີນໄປ ການກະຈາຍຈະບໍ່ຄົງທີ່, ດັ່ງນັ້ນຄວນມີຢ່າງໜ້ອຍຫຼາຍສິບຄູ່ໃນແຕ່ລະເງື່ອນໄຂ. ການລວມເອົາຄຳສັບ ຫຼື ວະລີທີ່ພົບເລື້ອຍໃນການນຳໃຊ້ຕົວຈິງ ຈະຊ່ວຍໃຫ້ການຕັດສິນມີຄວາມໃກ້ຄຽງກັບສະຖານະການຈິງຫຼາຍຂຶ້ນ. ຄ່າເກນມາດຕະຖານ (Threshold) ໃນການຕັດສິນ ກໍຄວນກຳນົດຈາກການກະຈາຍນີ້. ຖ້າເຮົາເຂົ້າໃຈວ່າຄ່າຄວາມຄ້າຍຄືກັນຂອງຄູ່ທີ່ບໍ່ກ່ຽວຂ້ອງຈະສູງຂຶ້ນເຖິງລະດັບໃດ, ເຮົາກໍສາມາດປັບຄ່າ Cut-off ໃນການຕັດສິນໃຈວ່າຈະນຳໃຊ້ຜົນການຄົ້ນຫາຫຼືບໍ່ ໃຫ້ເໝາະສົມກັບແຕ່ລະພາສາໄດ້. ຄວນລະວັງວ່າ ຖ້ານຳໃຊ້ຄ່າເກນດຽວກັນກັບທຸກພາສາ, ພາສາທີ່ມີພື້ນທີ່ການຈັດເກັບຂໍ້ມູນແບບບີບອັດອາດຈະເຮັດໃຫ້ເກີດການດຶງເອົາປະໂຫຍກທີ່ບໍ່ກ່ຽວຂ້ອງເຂົ້າມາໄດ້ງ່າຍ. ການກວດສອບໃນຄັ້ງນີ້ກໍເຊັ່ນກັນ, ພຽງແຕ່ການປຽບທຽບແບບງ່າຍໆລະຫວ່າງ "ຄວາມໝາຍຄືກັນ vs ບໍ່ກ່ຽວຂ້ອງ" ກໍສາມາດຊີ້ໃຫ້ເຫັນເຖິງຄວາມລົ້ມເຫຼວຂອງພາສາລາວໄດ້ຢ່າງຊັດເຈນ.

ເຖິງແມ່ນວ່າ Cross-lingual ຈະໃຊ້ງານບໍ່ໄດ້ ແຕ່ການເຮັດວຽກພາຍໃນພາສາດຽວກັນ (ລາວ ↔ ລາວ = 0.80) ກໍຍັງເຮັດວຽກໄດ້ດີ. ໂດຍການນຳໃຊ້ຈຸດນີ້, ການແປຄວາມຮູ້ເປັນພາສາຂອງຜູ້ໃຊ້ແລ້ວບັນທຶກ ແລະ ຝັງຂໍ້ມູນ (Embedding) ໄວ້, ຈາກນັ້ນນຳເອົາການຄົ້ນຫາໄປປຽບທຽບໃນພາສາດຽວກັນ ນັ້ນຄືດັດຊະນີແຍກຕາມພາສາ (Language-specific index).

ການອອກແບບສາມາດສະຫຼຸບໄດ້ເປັນ 3 ຈຸດດັ່ງນີ້:

ອັນທີໜຶ່ງ, ແປເອກະສານຄວາມຮູ້ເປັນພາສາຂອງຜູ້ໃຊ້, ບັນທຶກ ແລະ ຝັງ (Embed) ຂໍ້ມູນໄວ້, ພ້ອມທັງສ້າງແຖວການຝັງຂໍ້ມູນແຍກຕາມແຕ່ລະພາສາ.

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

ອັນທີສາມ, ສຳລັບການແປ ໃຫ້ຈັດລຳດັບຄວາມສຳຄັນໃນການໃຊ້ແບບຈຳລອງພາສາ (Language Model) ທີ່ມີປະສິດທິພາບສູງກັບຄູ່ພາສາທີ່ມີຊັບພະຍາກອນຕ່ຳ, ແລະ ຖ້າຫາກລົ້ມເຫຼວ ໃຫ້ໃຊ້ລະບົບອື່ນສຳຮອງແທນ.

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

ໄດ້ທຳການຄົ້ນຫາ Query ພາສາລາວ (ຄຳຖາມກ່ຽວກັບການຕັ້ງຄ່າ LMS, ການສ້າງ Tenant ແລະ ການລົງທະບຽນຜູ້ໃຊ້) ໂດຍທຽບກັບ Knowledge ທີ່ກ່ຽວຂ້ອງ ແລະ ປຽບທຽບຄ່າຄວາມຄ້າຍຄືກັນ (Similarity) ໃນແຕ່ລະເສັ້ນທາງ.

ສະຫຼຸບ: ການຜ່ານ Index ແຍກຕາມພາສາທີ່ແປເປັນພາສາລາວ ໄດ້ຄ່າ 0.64 ເຊິ່ງສູງກວ່າການຄົ້ນຫາແບບ Cross-lingual ໄປຍັງຕົ້ນສະບັບພາສາຢີ່ປຸ່ນທີ່ໄດ້ຄ່າ 0.42 ຢ່າງຊັດເຈນ.

ຂໍ້ເພີ່ມເຕີມຄື, ໃນຕົວຢ່າງນີ້ທີ່ຕົ້ນສະບັບ Cross-lingual ໄດ້ຄ່າ 0.42 ແມ່ນຍ້ອນວ່າ Token ທີ່ເປັນຕົວອັກສອນລາຕິນທີ່ໃຊ້ຮ່ວມກັນເຊັ່ນ "LMS" ຫຼື "tenant" ທີ່ຢູ່ໃນ Query ມີຜົນ. ຖ້າເປັນ Query ທີ່ເປັນພາສາລາວລ້ວນໆ, ຄ່າຄວາມຄ້າຍຄືກັນຂອງເສັ້ນທາງຕົ້ນສະບັບຈະຫຼຸດລົງເຫຼືອປະມານ 0. ກ່າວຄືໃນການເຮັດວຽກຕົວຈິງ, ຄວາມແຕກຕ່າງກັບ Index ແຍກຕາມພາສາຈະຍິ່ງເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

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

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

ໂດຍພື້ນຖານແລ້ວ, ຄວນວັດແທກ "ຄວາມຄ້າຍຄືກັນຂອງປະໂຫຍກທີ່ມີຄວາມໝາຍດຽວກັນ" ແລະ "ຄວາມຄ້າຍຄືກັນຂອງປະໂຫຍກທີ່ບໍ່ກ່ຽວຂ້ອງກັນ" ໃນແຕ່ລະພາສາເປົ້າໝາຍ ເພື່ອເບິ່ງວ່າທັງສອງຄ່ານີ້ມີຄວາມແຕກຕ່າງກັນພຽງພໍຫຼືບໍ່. ຖ້າພາສາໃດມີຄວາມຄ້າຍຄືກັນຂອງປະໂຫຍກທີ່ມີຄວາມໝາຍດຽວກັນຕ່ຳກວ່າ ຫຼື ໃກ້ຄຽງກັບປະໂຫຍກທີ່ບໍ່ກ່ຽວຂ້ອງກັນ, ສາມາດຕັດສິນໄດ້ວ່າການຄົ້ນຫາແບບຂ້າມພາສາ (Cross-lingual search) ບໍ່ປະສົບຜົນສຳເລັດ. ເນື່ອງຈາກບໍ່ມີການສະແດງຂໍ້ຜິດພາດ (Error), ຈຶ່ງຈຳເປັນຕ້ອງກວດສອບດ້ວຍຕົວເລກສະເໝີ. ໃນການປະຕິບັດງານຕົວຈິງ, ກ່ອນອື່ນຄວນກຳນົດຄ່າອ້າງອີງຈາກພາສາທີ່ມີຊັບພະຍາກອນສູງ ເຊັ່ນ: ພາສາຢີ່ປຸ່ນ ຫຼື ພາສາອັງກິດ, ຈາກນັ້ນໃຫ້ກວດເບິ່ງລາຍການເພື່ອເບິ່ງວ່າມີພາສາໃດທີ່ມີຄ່າຕ່ຳຜິດປົກກະຕິຫຼືບໍ່, ເຊິ່ງຈະຊ່ວຍໃຫ້ລະບຸພາສາທີ່ມີບັນຫາໄດ້ຢ່າງວ່ອງໄວ. ຖ້າຫາກມີການສະຫຼຸບຄ່າຄວາມຄ້າຍຄືກັນສະເລ່ຍ ແລະ ອັດຕາການຄົ້ນຫາທີ່ພົບ (Hit rate) ຕາມແຕ່ລະພາສາຈາກບັນທຶກການຄົ້ນຫາ (Search log) ຢ່າງຕໍ່ເນື່ອງ, ກໍຈະສາມາດກວດພົບຄວາມເສື່ອມຖອຍຂອງລະບົບໃນຂະນະທີ່ກຳລັງໃຊ້ງານໄດ້ຢ່າງວ່ອງໄວ.

ນັ້ນກໍຍ້ອນວ່າຄວາມໃກ້ຄຽງກັນຂອງຕົວອັກສອນ ແລະ ຄຳສັບ ກັບປະລິມານຄວາມສອດຄ່ອງລະຫວ່າງພາສາທີ່ແບບຈຳລອງການຝັງ (Embedding model) ໄດ້ຮຽນຮູ້ນັ້ນແມ່ນຄົນລະເລື່ອງກັນ. ພາສາໄທມີປະລິມານການຮຽນຮູ້ທີ່ພຽງພໍໃນຖານະພາສາທີ່ມີຊັບພະຍາກອນປານກາງ (Medium-resource language) ແລະ ມີຄວາມສອດຄ່ອງກັບພາສາອື່ນ, ແຕ່ພາສາລາວເປັນພາສາທີ່ມີຊັບພະຍາກອນຕ່ຳ (Low-resource language) ແລະ ມີການຮຽນຮູ້ດ້ານຄວາມສອດຄ່ອງທີ່ໜ້ອຍ. ຈາກການວັດແທກຕົວຈິງຂອງບໍລິສັດພວກເຮົາກໍພົບວ່າ ພາສາໄທມີຄ່າຢູ່ທີ່ 0.45, ສ່ວນພາສາລາວມີຄ່າຢູ່ທີ່ 0.03 ເຊິ່ງແຕກຕ່າງກັນຢ່າງເຫັນໄດ້ຊັດ. ເຖິງຈະເປັນພາສາທີ່ມີຄວາມໃກ້ຄຽງກັນ ກໍຄວນຈະວັດແທກແຍກກັນ.

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

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