ການຄົ້ນຫາແບບ Hybrid ແມ່ນສະຖາປັດຕະຍະກຳການຄົ້ນຫາທີ່ລວມເອົາການຄົ້ນຫາແບບ Vector (Dense Model) ແລະ ການຄົ້ນຫາແບບເຕັມຮູບແບບ (Sparse Model ເຊັ່ນ BM25) ເຂົ້າດ້ວຍກັນ ເພື່ອຊົດເຊີຍຈຸດອ່ອນຂອງແຕ່ລະວິທີ.

ຄວາມຖືກຕ້ອງຂອງລະບົບ RAG (Retrieval-Augmented Generation) ແມ່ນສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຄຸນນະພາບຂອງຂັ້ນຕອນການຄົ້ນຫາໂດຍກົງ. ໃນຂະນະທີ່ການຄົ້ນຫາແບບ Vector ມີຈຸດແຂງໃນດ້ານຄວາມຄ້າຍຄືກັນທາງຄວາມໝາຍ, ມັນມັກຈະເກີດການຕົກຫຼົ່ນໃນກໍລະນີທີ່ຕ້ອງການຄວາມຖືກຕ້ອງຂອງຄຳສັບແບບ 100% ເຊັ່ນ: ເລກລຸ້ນ, ຊື່ສະເພາະ, ຫຼື ລະຫັດໂຄ້ດ (Code snippet).

ບົດຄວາມນີ້ຈະອະທິບາຍຢ່າງເປັນລະບົບກ່ຽວກັບຄວາມຮູ້ທີ່ສາມາດນຳໄປໃຊ້ງານໄດ້ຈິງ, ຕັ້ງແຕ່ກົນໄກຂອງການຄົ້ນຫາແບບ Hybrid, ການລວມຄະແນນດ້ວຍ RRF (Reciprocal Rank Fusion), ຕົວຢ່າງການຈັດຕັ້ງປະຕິບັດໃນ Weaviate, Qdrant, Elasticsearch, ແລະ PostgreSQL, ໄປຈົນເຖິງວິທີການປະເມີນຄວາມຖືກຕ້ອງ. ເນື້ອຫານີ້ແມ່ນສຳລັບວິສະວະກອນທີ່ກຳລັງພິຈາລະນາປັບປຸງຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາຂອງລະບົບ RAG ແລະ ທີມງານທີ່ກຳລັງຈະນຳລະບົບໄປໃຊ້ໃນສະພາບແວດລ້ອມຈິງ.

ການຄົ້ນຫາແບບ Hybrid ແມ່ນວິທີການຄົ້ນຫາທີ່ປະສົມປະສານລະຫວ່າງ ການຄົ້ນຫາແບບ Vector (Dense Model) ແລະ ການຄົ້ນຫາແບບເຕັມຮູບແບບ (Sparse Model ເຊັ່ນ BM25) ເຂົ້າດ້ວຍກັນ. ການຄົ້ນຫາແບບ Vector ມີຈຸດແຂງໃນດ້ານຄວາມຄ້າຍຄືກັນທາງຄວາມໝາຍ, ໃນຂະນະທີ່ BM25 ມີຈຸດແຂງໃນດ້ານການຈັບຄູ່ຄຳສັບ, ແຕ່ທັງສອງວິທີກໍຍັງມີ Query ທີ່ບໍ່ສາມາດກວມເອົາໄດ້ຢ່າງຄົບຖ້ວນເມື່ອໃຊ້ພຽງວິທີດຽວ. ການນຳໃຊ້ທັງສອງວິທີຮ່ວມກັນຈະຊ່ວຍໃຫ້ສາມາດຈັບຄູ່ໄດ້ທັງຄວາມຄ້າຍຄືກັນທາງຄວາມໝາຍ ແລະ ການຈັບຄູ່ຄຳສັບໄປພ້ອມໆກັນ. ນີ້ແມ່ນໜຶ່ງໃນວິທີການທີ່ມີປະສິດທິຜົນທີ່ສຸດໃນປັດຈຸບັນ ເພື່ອຍົກລະດັບຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາຂອງລະບົບ RAG.

ການຄົ້ນຫາແບບ Vector (Dense Model) ສະແດງເຖິງຄວາມໃກ້ຄຽງທາງຄວາມໝາຍດ້ວຍ Embedding ເຊິ່ງສາມາດຮອງຮັບຄຳສັບທີ່ມີຄວາມໝາຍຄ້າຍຄືກັນ ຫຼື ການໃຊ້ຄຳອື່ນແທນໄດ້. ໃນທາງກົງກັນຂ້າມ, ມັນຍັງມີຈຸດອ່ອນຕໍ່ກັບຄຳຄົ້ນຫາທີ່ ຕ້ອງມີການກົງກັນທາງຄຳສັບເທົ່ານັ້ນຈຶ່ງຈະມີຄວາມໝາຍ ເຊັ່ນ: ເລກລຸ້ນ, ຊື່ສະເພາະ, ຫຼື ລະຫັດຕ່າງໆ. ຕົວຢ່າງເຊັ່ນ: ເມື່ອຄົ້ນຫາ "PS-3200A", ໃນພື້ນທີ່ Vector ເອກະສານທີ່ມີຄວາມໝາຍໃກ້ຄຽງອາດຈະຖືກຈັດລຳດັບຄວາມສຳຄັນກ່ອນ ເຮັດໃຫ້ເອກະສານທີ່ມີເລກລຸ້ນທີ່ຖືກຕ້ອງຖືກກົບຝັງໄປ.

ຂໍ້ຈຳກັດຫຼັກຂອງການຄົ້ນຫາແບບ Vector

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

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

ຂໍ້ຈຳກັດຫຼັກຂອງການຄົ້ນຫາແບບເຕັມຮູບແບບ (BM25)

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

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

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

ຂົງເຂດທີ່ການຄົ້ນຫາແບບ Semantic ບໍ່ຖະໜັດນັ້ນມີຄວາມຊັດເຈນ. ລະຫັດຮຸ່ນສິນຄ້າເຊັ່ນ "ABC-1234-X" ແມ່ນແຍກອອກຈາກລະຫັດທີ່ຄ້າຍຄືກັນໃນພື້ນທີ່ Embedding ໄດ້ຍາກ, ແລະຊື່ສະເພາະເຊັ່ນ ຊື່ຄົນ ຫຼື ຊື່ສະຖານທີ່ ມັກຈະມີຄວາມຖີ່ໃນການປາກົດຕົວຕ່ຳ ເຮັດໃຫ້ Vector ຄວາມໝາຍບໍ່ຄົງທີ່. git rebase --onto ແລະ git rebase ມີຄວາມໝາຍໃກ້ຄຽງກັນ ແຕ່ການເຮັດວຽກນັ້ນແຕກຕ່າງກັນຢ່າງສິ້ນເຊີງ.

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

BM25 ຄຳນວນຄະແນນໂດຍໃຊ້ຄວາມຖີ່ຂອງ Token ແລະ IDF (Inverse Document Frequency). ລະຫັດຮຸ່ນສິນຄ້າ ແລະ ຊື່ສະເພາະມີຄວາມຖີ່ໃນການປາກົດຕົວຕ່ຳໃນທົ່ວ Corpus, ເຮັດໃຫ້ຄ່າ IDF ສູງຂຶ້ນ ແລະ ສົ່ງຜົນໃຫ້ຄະແນນ BM25 ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ຖ້ານຳເອົາການຄົ້ນຫາແບບ Hybrid ມາໃຊ້ ກໍຈະສາມາດແບ່ງໜ້າທີ່ກັນໄດ້ຄື "ໃຊ້ BM25 ໃນການເກັບລະຫັດຮຸ່ນສິນຄ້າ ແລະ ໃຊ້ການຄົ້ນຫາແບບ Vector ເສີມໃນສ່ວນຂອງບໍລິບົດ". ໂດຍສະເພາະໃນລະບົບທີ່ການຈັບຄູ່ຂໍ້ຄວາມທີ່ຖືກຕ້ອງແມ່ນປັດໄຈຊີ້ຂາດຄຸນນະພາບ ເຊັ່ນ: ການຄົ້ນຫາຄູ່ມືຜະລິດຕະພັນ, ຖານຂໍ້ມູນກົດໝາຍ ແລະ ເອກະສານ API, ຄວນພິຈາລະນາການລວມເອົາການຄົ້ນຫາແບບເຕັມຂໍ້ຄວາມ (Full-text search) ເຂົ້າໄປເປັນບູລິມະສິດ.

RAG ທີ່ອາໄສພຽງແຕ່ການຄົ້ນຫາແບບ Semantic ມັກຈະເຮັດໃຫ້ເກີດອາການ Hallucination ໃນຮູບແບບສະເພາະ. ສາເຫດແມ່ນມາຈາກບັນຫາດ້ານໂຄງສ້າງທີ່ວ່າ "ເຖິງຈະສາມາດດຶງຂໍ້ມູນທີ່ມີຄວາມໝາຍໃກ້ຄຽງກັນມາໄດ້ ແຕ່ກໍບໍ່ໄດ້ມີຂໍ້ມູນທີ່ຈຳເປັນຢ່າງຖືກຕ້ອງ".

• ການປົນເປື້ອນຂອງເອກະສານທີ່ຄ້າຍຄືກັນ: ເມື່ອສອບຖາມກ່ຽວກັບ "ມາດຕະຖານ ຫຼື Specification ຂອງຜະລິດຕະພັນ A" ແລ້ວ "ມາດຕະຖານ ຫຼື Specification ຂອງຜະລິດຕະພັນ B" ປາກົດຂຶ້ນມາເປັນອັນດັບຕົ້ນໆ ເຮັດໃຫ້ LLM ສະແດງເລກລຸ້ນ ຫຼື ມາດຕະຖານ ຫຼື Specification ທີ່ຜິດພາດ
• ການເຂົ້າໃຈເວີຊັນຜິດ: Release note ຂອງ v2.1 ແລະ v2.0 ມີຄວາມໃກ້ຄຽງກັນໃນ Embedding space ເຮັດໃຫ້ເຖິງຈະມີການອ້າງອີງຂໍ້ມູນເກົ່າ ແຕ່ຄະແນນການຄົ້ນຫາກໍບໍ່ໄດ້ແຕກຕ່າງກັນຫຼາຍ
• ການເບິ່ງຂ້າມເງື່ອນໄຂປະຕິເສດ ຫຼື ຂໍ້ຍົກເວັ້ນ: ຄຳວ່າ "ບໍ່ສາມາດ..." ຫຼື "ຍົກເວັ້ນ..." ມັກຈະບໍ່ຖືກສະທ້ອນຢູ່ໃນ Vector ຄວາມໝາຍ ເຮັດໃຫ້ເອກະສານທີ່ມີລັກສະນະຢືນຢັນຖືກໃຫ້ຄວາມສຳຄັນກ່ອນ

BM25 ຈະໃຫ້ຄະແນນໂດຍກົງຈາກການກົງກັນຂອງຄຳສັບ ຈຶ່ງສະແດງຄວາມແມ່ນຍຳທີ່ສູງກວ່າການຄົ້ນຫາແບບ Vector ໃນດ້ານເລກລຸ້ນ, ເລກເວີຊັນ ແລະ ຄຳນາມສະເພາະ. ການຄົ້ນຫາແບບ Semantic ພຽງຢ່າງດຽວມີຄວາມສ່ຽງທີ່ LLM ຈະສ້າງຂໍ້ມູນທີ່ຜິດພາດແຕ່ເບິ່ງຄືວ່າໜ້າເຊື່ອຖືໂດຍອີງໃສ່ເອກະສານທີ່ "ກ່ຽວຂ້ອງແຕ່ບໍ່ຖືກຕ້ອງ", ເຊິ່ງການຄົ້ນຫາແບບ Hybrid ເປັນວິທີທີ່ມີປະສິດທິພາບໃນການຫຼຸດຜ່ອນຄວາມສ່ຽງນີ້ໃນດ້ານໂຄງສ້າງ.

ວິທີການເຮັດໃຫ້ Vector Database ແລະ BM25 index ຢູ່ຮ່ວມກັນ, ລວມເຖິງການອອກແບບ Chunk size ແລະ Embedding model. ຖ້າບໍ່ກຳນົດ 2 ຈຸດນີ້ໃຫ້ຊັດເຈນລ່ວງໜ້າ, ມັກຈະເກີດການ Refactoring ຂະໜາດໃຫຍ່ໃນເວລາລວມ ຫຼື Merge ລະບົບ. ຕໍ່ໄປນີ້ຈະອະທິບາຍແຕ່ລະຈຸດຢ່າງລະອຽດ.

ຈຸດຕັດສິນໃຈທຳອິດແມ່ນການເລືອກ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure. ເພື່ອໃຫ້ການຄົ້ນຫາແບບ Vector ແລະ ການຄົ້ນຫາດ້ວຍ Keyword ເຮັດວຽກຢູ່ໃນລະບົບດຽວກັນ, ທ່ານຕ້ອງເລືອກແພລດຟອມທີ່ມີທັງສອງຟັງຊັນນີ້ແບບ Native ຫຼື ນຳໃຊ້ເຄື່ອງມືສະເພາະມາປະສົມປະສານກັນ.

• Weaviate: ໃຫ້ keyword search (BM25F) ແລະ vector index ຢູ່ຮ່ວມກັນໃນ Collection ດຽວ. ຮອງຮັບ hybrid query ເປັນລະດັບຕົ້ນໆ, ບໍ່ຈຳເປັນຕ້ອງໃຊ້ບໍລິການພາຍນອກເພີ່ມເຕີມ ແລະ ຊ່ວຍໃຫ້ຄວບຄຸມຕົ້ນທຶນໃນການດຳເນີນງານໄດ້ງ່າຍ
• Qdrant: ຈັດເກັບ Dense vectors ແລະ sparse named vectors ໄວ້ໃນ 1 Collection. ໃນສ່ວນຂອງ sparse ສາມາດສະແດງຜົນໄດ້ຕັ້ງແຕ່ການຄົ້ນຫາແບບ classic BM25 ໄປຈົນເຖິງ learned sparse retrieval ເຊັ່ນ SPLADE ແລະ ສາມາດເຮັດ hybrid fusion ຢູ່ຝັ່ງເຊີບເວີໄດ້ດ້ວຍ Query API
• Elasticsearch: BM25 ມີຄວາມພ້ອມສູງ. ໃນເວີຊັນປັດຈຸບັນຍັງຮອງຮັບການຄົ້ນຫາແບບ Vector ໄດ້ແບບ Native ແລະ ມີຟັງຊັນມາດຕະຖານໃນການເຮັດ hybrid search ຜ່ານ RRF ແລະ ການລວມແບບເສັ້ນຊື່ (linear combination)
• PostgreSQL (pgvector + tsvector): ເຮັດໃຫ້ hybrid search ເກີດຂຶ້ນໄດ້ເທິງ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ມີຢູ່. Supabase ໄດ້ແນະນຳຢ່າງເປັນທາງການ ເຊິ່ງຊ່ວຍໃຫ້ບໍ່ຈຳເປັນຕ້ອງເພີ່ມ Vector DB ສະເພາະເຂົ້າໄປ

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ທີ່ຄວນຈື່ໃນການອອກແບບໃຫ້ຢູ່ຮ່ວມກັນ

• ເນື່ອງຈາກ Vector index ແລະ Keyword index ຖືກສ້າງຂຶ້ນແຍກກັນສຳລັບເອກະສານດຽວກັນ, ຈຶ່ງຈຳເປັນຕ້ອງມີກົນໄກໃນການ ປັບເວລາການອັບເດດ Index ໃຫ້ກົງກັນ
• ການຕັ້ງຄ່າ analyzer/tokenizer ຂອງ Text field ສຳລັບການຄົ້ນຫາດ້ວຍ Keyword ມີຜົນໂດຍກົງຕໍ່ຄຸນນະພາບການຄົ້ນຫາ (ໂດຍສະເພາະໃນສະພາບແວດລ້ອມພາສາຢີ່ປຸ່ນ)
• ຖ້າເປັນການສ້າງລະບົບໃໝ່ (Greenfield), ການໃຊ້ Weaviate ຫຼື Qdrant ຈະຊ່ວຍໃຫ້ການອອກແບບງ່າຍຂຶ້ນ, ສ່ວນຖ້າມີ Elasticsearch ຢູ່ແລ້ວ ການນຳໃຊ້ຟັງຊັນ hybrid ແບບ Native ຈະຊ່ວຍຫຼຸດຕົ້ນທຶນໃນການຍົກຍ້າຍລະບົບໄດ້ດີກວ່າ

ການປ່ຽນແປງຂະໜາດ Chunk ແລະ Embedding model ໃນພາຍຫຼັງຈະເຮັດໃຫ້ມີຕົ້ນທຶນໃນການເຮັດ Re-indexing ສູງ, ດັ່ງນັ້ນການກຳນົດນະໂຍບາຍໄວ້ລ່ວງໜ້າຈຶ່ງເປັນສິ່ງສຳຄັນ.

ແນວທາງການອອກແບບຂະໜາດ Chunk

• Chunk ຂະໜາດສັ້ນ (128-256 tokens): ເໝາະສຳລັບການສະກັດເອົາຂໍ້ເທັດຈິງແບບເຈາະຈົງ. ເຂົ້າກັນໄດ້ດີກັບ BM25 ແລະ ເຮັດໃຫ້ອັດຕາການພົບ Keyword ສູງຂຶ້ນ.
• Chunk ຂະໜາດຍາວ (512-1024 tokens): ເໝາະສຳລັບບົດອະທິບາຍ ຫຼື ຄູ່ມືຂັ້ນຕອນທີ່ຕ້ອງການຄວາມຕໍ່ເນື່ອງຂອງບໍລິບົດ. ຄວາມຄ້າຍຄືກັນທາງຄວາມໝາຍຂອງ Vector search ຈະມີຄວາມສະຖຽນຫຼາຍກວ່າ.
• ວິທີການ Sliding window: ການກຳນົດໃຫ້ມີສ່ວນຊ້ອນກັນ (Overlap) ລະຫວ່າງ Chunk ປະມານ 50-100 tokens ຈະຊ່ວຍຫຼຸດການຂາດຫາຍຂອງຂໍ້ມູນທີ່ຢູ່ລະຫວ່າງຮອຍຕໍ່ໄດ້.

ໃນຄູ່ມືທາງເຕັກນິກ ຫຼື ເອກະສານກົດລະບຽບຕ່າງໆ ມັກຈະນິຍົມໃຊ້ຂະໜາດປະມານ 256-512 tokens. ຢ່າງໃດກໍຕາມ, ຄ່າທີ່ເໝາະສົມທີ່ສຸດຈະແຕກຕ່າງກັນໄປຕາມລັກສະນະຂອງເອກະສານ ແລະ ກໍລະນີການນຳໃຊ້ (Use case), ດັ່ງນັ້ນການກຽມທາງເລືອກໄວ້ 2-3 ຮູບແບບເພື່ອທົດສອບປຽບທຽບດ້ວຍ Recall@K ຈຶ່ງເປັນວິທີທີ່ເໝາະສົມໃນທາງປະຕິບັດ.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການເລືອກ Embedding model

• ການຮອງຮັບຫຼາຍພາສາ: ຖ້າມີພາສາຢີ່ປຸ່ນ ຫຼື ພາສາໄທລວມຢູ່ດ້ວຍ ຄວນເລືອກ Model ທີ່ຮອງຮັບຫຼາຍພາສາ (ເຊັ່ນ: multilingual-e5, Gemini Embedding 2). Model ທີ່ໃຊ້ສະເພາະພາສາອັງກິດມັກຈະມີຄວາມແມ່ນຍຳໃນການສະແດງຜົນຂໍ້ຄວາມທີ່ບໍ່ແມ່ນພາສາອັງກິດຕໍ່າ.
• ຈຳນວນມິຕິ (Dimensions) ແລະ ຕົ້ນທຶນ: ຈຳນວນມິຕິຈະແຕກຕ່າງກັນໄປຕາມ Model (Gemini Embedding 2 ມີຄ່າເລີ່ມຕົ້ນທີ່ 3072 ມິຕິ ແລະ ສາມາດຫຼຸດຂະໜາດລົງໄດ້). ຄວນເລືອກຄວາມສົມດຸນລະຫວ່າງ Storage, Latency ແລະ ຄວາມແມ່ນຍຳ ຕາມຄວາມຕ້ອງການຂອງລະບົບ.
• ຄວາມເໝາະສົມກັບ Domain: ໃນຂົງເຂດທີ່ມີຄຳສັບສະເພາະທາງຫຼາຍ, ການໃຊ້ Model ທີ່ອອກແບບມາສະເພາະທາງ (Domain-specific model) ມັກຈະຊ່ວຍປັບປຸງຄວາມແມ່ນຍຳໃນການຄົ້ນຫາໃຫ້ດີຂຶ້ນ.

ຂະໜາດ Chunk ແລະ Embedding model ມີຜົນກະທົບເຊິ່ງກັນແລະກັນ, ດັ່ງນັ້ນການປະເມີນຜົນໂດຍພິຈາລະນາເປັນຊຸດ (Set) ຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

ເນື່ອງຈາກຄະແນນຂອງ Vector search ແລະ BM25 ມີຫົວໜ່ວຍທີ່ແຕກຕ່າງກັນ, ການນຳມາບວກກັນໂດຍກົງຈຶ່ງບໍ່ສາມາດໃຫ້ຜົນລັດທີ່ມີຄວາມໝາຍໄດ້. ວິທີແກ້ໄຂບັນຫານີ້ຄື RRF (Reciprocal Rank Fusion). RRF ຈະໃຊ້ "ອັນດັບ" ແທນທີ່ຈະເປັນຄ່າສຳບູນຂອງຄະແນນໃນການລວມ ຫຼື Merge, ເຮັດໃຫ້ສາມາດລວມ ຫຼື Merge ຜົນລັດຈາກວິທີການຄົ້ນຫາທີ່ແຕກຕ່າງກັນໄດ້ຢ່າງໝັ້ນຄົງ.

RRF ແມ່ນການຄິດໄລ່ຄະແນນຂອງແຕ່ລະເອກະສານດ້ວຍສູດ Σ 1/(k + rank_i) ໂດຍທີ່ rank_i ແມ່ນອັນດັບໃນວິທີການຄົ້ນຫາ i ແລະ k ແມ່ນຄ່າຄົງທີ່ໃນການເຮັດໃຫ້ຂໍ້ມູນລຽບ (smoothing constant). ຄ່າເລີ່ມຕົ້ນຂອງ k ຈະແຕກຕ່າງກັນໄປຕາມແຕ່ລະຜະລິດຕະພັນ ເຊັ່ນ: Elasticsearch ໃຊ້ 60, Qdrant ໃຊ້ 2 ແລະ ຕົວຢ່າງທາງການຂອງ Supabase ໃຊ້ 50.

ຕົວຢ່າງ: ຖ້າ k=60, ເອກະສານໜຶ່ງໄດ້ອັນດັບ 1 ໃນການຄົ້ນຫາແບບ Vector ແລະ ອັນດັບ 3 ໃນ BM25 ຈະໄດ້ 1/61 + 1/63 ≈ 0.0323. ສ່ວນອີກເອກະສານໜຶ່ງໄດ້ອັນດັບ 5 ໃນ Vector ແລະ ອັນດັບ 2 ໃນ BM25 ຈະໄດ້ 1/65 + 1/62 ≈ 0.0315. ເອກະສານທຳອິດຈະຖືກສະແດງຢູ່ອັນດັບສູງກວ່າ.

ແນວທາງການປັບຄ່າ k

• ການເຮັດໃຫ້ k ມີຄ່ານ້ອຍລົງ ຈະເຮັດໃຫ້ຄວາມເຂັ້ມຂຸ້ນຂອງອັນດັບສູງເພີ່ມຂຶ້ນ, ແລະຖ້າເຮັດໃຫ້ຄ່າໃຫຍ່ຂຶ້ນ ຜົນກະທົບຈາກຄວາມແຕກຕ່າງຂອງອັນດັບຈະຫຼຸດລົງ.
• ໂດຍທົ່ວໄປແລ້ວ ຄວນກວດສອບຄ່າເລີ່ມຕົ້ນຂອງແພລດຟອມທີ່ນຳໃຊ້ ແລະ ປັບຄ່າໂດຍພິຈາລະນາຈາກ Recall@K ແລະ MRR.

ການຂະຫຍາຍໄປສູ່ RRF ແບບມີນ້ຳໜັກ (Weighted RRF)

ຍັງສາມາດຂະຫຍາຍໂດຍການຄູນນ້ຳໜັກໃຫ້ກັບແຕ່ລະວິທີການຄົ້ນຫາໄດ້. ຖ້າໃຊ້ສູດ α × 1/(k + rank_Vector) + β × 1/(k + rank_BM25), ໃນເອກະສານທາງເຕັກນິກທີ່ມີເລກຮຸ່ນຫຼາຍອາດຈະເພີ່ມຄ່າ β ໃຫ້ສູງຂຶ້ນ, ສ່ວນໃນ FAQ ທີ່ເນັ້ນແນວຄວາມຄິດອາດຈະເພີ່ມຄ່າ α ໃຫ້ສູງຂຶ້ນ. ການເຮັດໃຫ້ຜົນລວມຂອງ α ແລະ β ເທົ່າກັບ 1 ຈະຊ່ວຍໃຫ້ການຕັ້ງຄ່າ Threshold ມີຄວາມສະຖຽນ. ແນະນຳໃຫ້ກຳນົດຄ່າທີ່ແນ່ນອນໂດຍຜ່ານການປະເມີນຜົນແບບ Offline ໂດຍໃຊ້ Golden Set.

ແພລດຟອມຫຼັກແຕ່ລະແຫ່ງມີວິທີການທີ່ແຕກຕ່າງກັນໃນການຮອງຮັບການຄົ້ນຫາແບບ Hybrid.

Weaviate — ໃຊ້ hybrid query ເພື່ອດຳເນີນການຄົ້ນຫາດ້ວຍ Keyword (BM25F) ແລະ Vector search ຈາກ API ດຽວ. ສາມາດປັບນ້ຳໜັກໄດ້ດ້ວຍ alpha (0 ຫາ 1, 0=pure keyword, 1=pure vector). ຮູບແບບການລວມຂໍ້ມູນສາມາດເລືອກໄດ້ 2 ປະເພດ ຄື: Relative Score Fusion (ຄ່າເລີ່ມຕົ້ນຕັ້ງແຕ່ v1.24 ເປັນຕົ້ນໄປ) ແລະ Ranked Fusion (ການລວມໂດຍອີງໃສ່ອັນດັບ 1/(rank+60)). ສຳລັບພາສາຢີ່ປຸ່ນ ຈຳເປັນຕ້ອງຕັ້ງຄ່າ tokenization ສຳລັບ CJK ເຊັ່ນ: gse ຫຼື kagome_ja.

Qdrant — ນຳໃຊ້ prefetch+fusion ເພື່ອປະຕິບັດການຄົ້ນຫາແບບ Hybrid ລະຫວ່າງ Dense vectors ແລະ Sparse vectors. ໃນຝັ່ງ Sparse ນັ້ນ ຮອງຮັບຕັ້ງແຕ່ການຄົ້ນຫາແບບ Classic BM25 ໄປຈົນເຖິງ Learned sparse retrieval ເຊັ່ນ SPLADE, ແລະສາມາດເລືອກ RRF ຫຼື Distribution-Based Score Fusion ໄດ້ທີ່ຝັ່ງ Server. ຄ່າເລີ່ມຕົ້ນຂອງຄົງທີ່ k ໃນ RRF ແມ່ນ 2 (ແຕກຕ່າງຈາກ 60 ຂອງ Elasticsearch).

Elasticsearch — ຮອງຮັບການຄົ້ນຫາແບບ Hybrid ແບບ Native. ໂດຍມີທັງ RRF ແລະ Linear combination ໃຫ້ໃຊ້ເປັນຟັງຊັນມາດຕະຖານຜ່ານ retriever API (ເພີ່ມເຂົ້າມາໃນເວີຊັນ 8.14 ແລະເປັນ GA ໃນ 8.16). ຈຸດແຂງຄືສາມາດນຳໃຊ້ຄວາມຮູ້ດ້ານການປັບແຕ່ງ BM25 ຂອງ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ມີຢູ່ແລ້ວໄດ້ທັນທີ. ສຳລັບພາສາຢີ່ປຸ່ນສາມາດໃຊ້ kuromoji analyzer, ສ່ວນພາສາໄທສາມາດໃຊ້ thai analyzer ຫຼື ICU tokenizer ໄດ້.

PostgreSQL / Supabase — ສາມາດປະຕິບັດໄດ້ດ້ວຍ pgvector+tsvector/tsquery. Supabase ໄດ້ແນະນຳການຄົ້ນຫາແບບ Hybrid ຢ່າງເປັນທາງການ ແລະມີຕົວຢ່າງການນຳໃຊ້ GIN index (Full-text search) ຄວບຄູ່ກັບ HNSW (Vector search). ສຳລັບ RRF ນັ້ນຈະເປັນຮູບແບບການປະຕິບັດຜ່ານ SQL function.

ເນື່ອງຈາກທຸກແພລດຟອມມີການປ່ຽນແປງ ມາດຕະຖານ ຫຼື Specification ຢູ່ເລື້ອຍໆ, ກະລຸນາກວດສອບເອກະສານຫຼ້າສຸດກ່ອນການນຳໄປປະຕິບັດຈິງ.

RRF ແມ່ນ "ການລວມອັນດັບ" (Reciprocal Rank Fusion) ເຊິ່ງບໍ່ໄດ້ວັດແທກຄວາມສອດຄ່ອງທາງຄວາມໝາຍລະຫວ່າງ Query ແລະ ເອກະສານໂດຍກົງ. ດັ່ງນັ້ນ, ຈຶ່ງມີການນຳໃຊ້ໂຄງສ້າງທີ່ເພີ່ມ Reranking model ເຂົ້າໄປໃນຂັ້ນຕອນຫຼັງ.

ໂຄງສ້າງຂະບວນການ ຫຼື Pipeline ແບບທົ່ວໄປ

• ຂັ້ນຕອນທີ 1 (Retrieve): ດຶງຂໍ້ມູນ Top-50〜100 ລາຍການດ້ວຍ Hybrid Search
• ຂັ້ນຕອນທີ 2 (Rerank): ໃຫ້ຄະແນນຄູ່ຂອງ Query ແລະ ແຕ່ລະເອກະສານດ້ວຍ Cross-Encoder
• ຂັ້ນຕອນທີ 3 (Generate): ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ LLM ໂດຍໃຊ້ຂໍ້ມູນ Top 3〜10 ລາຍການເປັນບໍລິບົດ (Context)

Cross-Encoder ຈະເຮັດການ Encode Query ແລະ ເອກະສານພ້ອມກັນເພື່ອສະແດງຄະແນນຄວາມກ່ຽວຂ້ອງ. ເຖິງວ່າຈະມີຕົ້ນທຶນການຄຳນວນທີ່ສູງກວ່າ Vector Search ທີ່ອີງໃສ່ Bi-Encoder, ແຕ່ມັນມີຄວາມແມ່ນຍຳທີ່ດີກວ່າ ແລະ ຖ້ານຳໃຊ້ໃນຂັ້ນຕອນຫຼັງຈາກການຄັດເລືອກຜູ້ສະໝັກແລ້ວ ກໍສາມາດຄວບຄຸມ Latency ໃຫ້ຢູ່ໃນຂອບເຂດທີ່ຍອມຮັບໄດ້.

ຕົວຢ່າງທາງເລືອກທີ່ສຳຄັນໄດ້ແກ່ Cohere Rerank API (ຮອງຮັບຫຼາຍພາສາ/Cloud), bge-reranker-v2-m3 (ຮອງຮັບຫຼາຍພາສາ/OSS), ແລະ cross-encoder/ms-marco-MiniLM (ພາສາອັງກິດ/ນ້ຳໜັກເບົາ). ໃນການເຮັດ RAG ຫຼາຍພາສາ, ແນະນຳໃຫ້ປະເມີນຄວາມແມ່ນຍຳໃນພາສາເປົ້າໝາຍດ້ວຍ Golden Set ລ່ວງໜ້າ. ເມື່ອເພີ່ມການ Reranking ເຂົ້າໄປ, ຄວນລະວັງເລື່ອງ Latency ທີ່ເພີ່ມຂຶ້ນ ແລະ ຮັບປະກັນ Throughput ດ້ວຍການປະມວນຜົນແບບບໍ່ລໍຖ້າ (Asynchronous) ຫຼື ການໃຊ້ Cache.

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

ຂໍ້ຜິດພາດໃນການປະຕິບັດງານທີ່ພົບເຫັນຫຼາຍທີ່ສຸດ ຄື ການລວມຄະແນນໂດຍບໍ່ໄດ້ປັບສະເກັດ (Scale) ໃຫ້ເທົ່າກັນ.

ຄະແນນທາງຝັ່ງການຄົ້ນຫາແບບ Vector ບໍ່ວ່າຈະເປັນ cosine similarity / cosine distance / ຄະແນນການແປງພາຍໃນ (Internal conversion score) ແລະ ອື່ນໆ ລ້ວນແລ້ວແຕ່ມີຄວາມໝາຍທີ່ແຕກຕ່າງກັນໄປຕາມ Engine ຫຼື ຟັງຊັນໄລຍະຫ່າງ (ທາງຄະນິດສາດ cosine similarity ຈະມີຄ່າຕັ້ງແຕ່ -1 ເຖິງ 1). ສ່ວນຄະແນນຂອງ BM25 ກໍມີຊ່ວງຄ່າທີ່ປ່ຽນແປງຢ່າງຫຼວງຫຼາຍຕາມຂະໜາດຂອງຊຸດເອກະສານ ຫຼື ຄວາມຍາວຂອງຂໍ້ຄວາມ ເຊິ່ງອາດສູງເຖິງຫຼັກສິບ ຫຼື ຫຼັກຮ້ອຍ. ຖ້າຫາກນຳມາບວກກັນໂດຍກົງໃນສະພາບນີ້, ຝັ່ງ BM25 ຈະຄອບງຳຜົນລັພທັງໝົດ ແລະ ເຮັດໃຫ້ປະໂຫຍດຂອງການຄົ້ນຫາແບບ Semantic ເປັນສູນ.

ຮູບແບບທີ່ມັກພົບເຫັນເປັນອາການ:

• Chunk ສັ້ນໆທີ່ມີຄຳສຳຄັນ (Keyword) ຈະຄອບຄອງອັນດັບຕົ້ນໆ ໃນຂະນະທີ່ Chunk ຍາວທີ່ມີຄວາມກ່ຽວຂ້ອງທາງບໍລິບົດສູງກັບຕົກອັນດັບ.
• ພຽງແຕ່ປ່ຽນຮູບແບບຂອງ Query ເລັກນ້ອຍ ກໍເຮັດໃຫ້ຜົນລັພອັນດັບຕົ້ນໆ ປ່ຽນແປງໄປຢ່າງຫຼວງຫຼາຍ.
• ພົບເຫັນໄດ້ຊັດເຈນໂດຍສະເພາະໃນການປະຕິບັດງານທີ່ໃຊ້ການລວມແບບ Weighted Sum ໂດຍບໍ່ໄດ້ໃຊ້ RRF.

ຖ້າຫາກເລືອກໃຊ້ RRF ຈະຊ່ວຍປະຢັດເວລາໃນການເຮັດ Normalization ແຕ່ຖ້າຕ້ອງການນຳໃຊ້ຄວາມແຕກຕ່າງຂອງຄະແນນໃຫ້ເກີດປະໂຫຍດ, ການໃຊ້ Linear Combination ທີ່ມີການ Normalization ຢ່າງຊັດເຈນຈະເປັນທາງເລືອກທີ່ເໝາະສົມກວ່າ. ການສ້າງນິໄສໃນການ Log ແລະ ເຮັດໃຫ້ການແຈກແຈງຂອງຄະແນນທັງສອງຝັ່ງເຫັນພາບໄດ້ຊັດເຈນໃນຂັ້ນຕອນການພັດທະນາ ຈະຊ່ວຍໃຫ້ທ່ານຄົ້ນພົບຄວາມຜິດພາດໄດ້ຕັ້ງແຕ່ຫົວທີ.

ກໍລະນີທີ່ຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາຫຼຸດລົງຢ່າງຫຼວງຫຼາຍມັກມີສາເຫດມາຈາກ analyzer/tokenizer ທາງດ້ານການຄົ້ນຫາດ້ວຍຄຳສຳຄັນ (Keyword search). ການນຳໃຊ້ BM25 ທີ່ອີງໃສ່ພາສາອັງກິດຈະແບ່ງ token ໂດຍໃຊ້ຊ່ອງຫວ່າງ, ສະນັ້ນໃນພາສາທີ່ບໍ່ມີການວັກຕອນລະຫວ່າງຄຳ ເຊັ່ນ: ພາສາຢີ່ປຸ່ນ ຫຼື ພາສາໄທ ຈຶ່ງບໍ່ສາມາດແບ່ງໄດ້ຢ່າງຖືກຕ້ອງ.

ບັນຫາທີ່ມັກພົບ

• ເມື່ອຄົ້ນຫາຄຳວ່າ "自然言語処理" (ການປະມວນຜົນພາສາທຳມະຊາດ) ໃນພາສາຢີ່ປຸ່ນ, ຖ້າບໍ່ມີການ tokenization ທີ່ເໝາະສົມ ມັນຈະຖືກຈັດການເປັນ 1 token ເຮັດໃຫ້ການຄົ້ນຫາແບບບາງສ່ວນ (partial match) ບໍ່ສາມາດເຮັດວຽກໄດ້
• ພາສາໄທຕ້ອງການຂະບວນການສະເພາະໃນການກວດຫາຂອບເຂດຂອງຄຳ ແຕ່ໃນການຕັ້ງຄ່າເລີ່ມຕົ້ນຈະຖືກລະເລີຍ
• ໃນເອກະສານທີ່ມີພາສາອັງກິດ, ພາສາຢີ່ປຸ່ນ ແລະ ພາສາໄທ ປົນກັນ, ຄວາມລະອຽດຂອງ token ຈະແຕກຕ່າງກັນໄປຕາມແຕ່ລະພາສາ ເຮັດໃຫ້ການປຽບທຽບຄະແນນບໍ່ມີຄວາມຍຸຕິທຳ

ການຈັດການຕາມແພລດຟອມ

• Elasticsearch / OpenSearch: ມີ kuromoji analyzer ສຳລັບພາສາຢີ່ປຸ່ນ ແລະ thai analyzer ຫຼື ICU tokenizer ສຳລັບພາສາໄທໃຫ້ບໍລິການເປັນມາດຕະຖານ. ແນະນຳໃຫ້ອອກແບບໂດຍການແຍກ field mapping ຕາມແຕ່ລະພາສາ
• Weaviate: ມີທາງເລືອກ tokenization ເຊັ່ນ gse ຫຼື kagome_ja ສຳລັບພາສາ CJK. ເນື່ອງຈາກຄວາມຖືກຕ້ອງໃນການແບ່ງຄຳພາສາຢີ່ປຸ່ນຈະຫຼຸດລົງໃນການຕັ້ງຄ່າເລີ່ມຕົ້ນ ຈຶ່ງຈຳເປັນຕ້ອງປ່ຽນແປງການຕັ້ງຄ່າ
• PostgreSQL / Supabase: PGroonga ຮອງຮັບພາສາ CJK ເຊັ່ນ: ພາສາຢີ່ປຸ່ນ ແລະ ພາສາຈີນ. ນອກຈາກນີ້ຍັງມີ bigram index ໂດຍໃຊ້ pg_bigm ເປັນທາງເລືອກ

ໃນກໍລະນີທີ່ມີເອກະສານຫຼາຍພາສາປົນກັນ ຄວນເພີ່ມຂັ້ນຕອນການກວດສອບພາສາ ແລະ ນຳໃຊ້ analyzer ທີ່ແຕກຕ່າງກັນໄປຕາມແຕ່ລະພາສາ. ໃນດ້ານການຄົ້ນຫາດ້ວຍ Vector ສາມາດຮອງຮັບຄວາມແຕກຕ່າງຂອງພາສາໄດ້ດ້ວຍ multilingual embedding model ແຕ່ໃນດ້ານການຄົ້ນຫາດ້ວຍຄຳສຳຄັນ ຖ້າບໍ່ກວດສອບ ແລະ ອອກແບບການຕັ້ງຄ່າ analyzer/tokenizer ໃຫ້ເໝາະສົມກັບແຕ່ລະຜະລິດຕະພັນ ກໍຈະບໍ່ສາມາດຮັບປະກັນຄວາມຖືກຕ້ອງໄດ້.

ເຖິງແມ່ນວ່າຈະນຳໃຊ້ການຄົ້ນຫາແບບ Hybrid Search ແລ້ວ, ແຕ່ຖ້າບໍ່ມີການກວດສອບຢ່າງເປັນປະລິມານວ່າຄວາມຖືກຕ້ອງໄດ້ຮັບການປັບປຸງຂຶ້ນແທ້ຫຼືບໍ່, ວົງຈອນການປັບປຸງກໍຈະບໍ່ສາມາດດຳເນີນໄປໄດ້. ຄວາມຮູ້ສຶກແບບອັດຕະວິໄສທີ່ວ່າ "ຮູ້ສຶກວ່າດີຂຶ້ນ" ນັ້ນ ບໍ່ສາມາດນຳມາເປັນເງື່ອນໄຂໃນການຕັດສິນໃຈສຳລັບການນຳໃຊ້ງານຈິງໄດ້. ການໃຊ້ Recall@K, MRR, NDCG ແລະ ການທົດສອບແບບ Regression ໂດຍໃຊ້ Golden Set ແມ່ນພື້ນຖານທີ່ສຳຄັນ.

Recall@K — ວັດແທກວ່າໃນ K ອັນດັບທຳອິດມີເອກະສານທີ່ຖືກຕ້ອງຢູ່ຈັກອັນ. ໃນ RAG, ໃຊ້ເພື່ອຢືນຢັນວ່າ "ມີຂໍ້ມູນຕົກຫຼົ່ນຫຼືບໍ່" ໂດຍທົ່ວໄປແລ້ວ K=5 ຫຼື K=10 ແມ່ນມາດຕະຖານທີ່ໃຊ້ໃນການເຮັດວຽກຈິງ.

MRR (Mean Reciprocal Rank) — ຄ່າສະເລ່ຍຂອງສ່ວນກັບຂອງອັນດັບທີ່ເອກະສານທີ່ຖືກຕ້ອງປາກົດຂຶ້ນເປັນຄັ້ງທຳອິດ. ຖ້າຢູ່ອັນດັບ 1 ຈະໄດ້ 1.0, ຖ້າຢູ່ອັນດັບ 3 ຈະໄດ້ 0.33. ມີປະສິດທິພາບໃນກໍລະນີທີ່ຕ້ອງການປະເມີນຄຸນນະພາບຂອງຜົນລັພທີ່ເຫັນໃນຕອນຕົ້ນ ແລະ ເໝາະສົມກັບ RAG ປະເພດ Chatbot.

NDCG — ດັດຊະນີທີ່ສາມາດໃຫ້ຄະແນນເປັນລະດັບ (ກົງກັນສົມບູນ/ກົງກັນບາງສ່ວນ/ບໍ່ກ່ຽວຂ້ອງ) ຕາມຄວາມກ່ຽວຂ້ອງ. ຍິ່ງເອກະສານທີ່ມີຄວາມກ່ຽວຂ້ອງສູງມາຢູ່ໃນອັນດັບຕົ້ນໆ ຄະແນນກໍຈະຍິ່ງສູງຂຶ້ນ. ເນື່ອງຈາກມີຕົ້ນທຶນໃນການຕິດປ້າຍກຳກັບ (Labeling) ສູງ, ຈຶ່ງຄວນປະເມີນຢ່າງວ່ອງໄວດ້ວຍ Recall@K ແລະ MRR ກ່ອນ, ແລ້ວຈຶ່ງໃຊ້ NDCG ເພື່ອເຈາະເລິກໃນກໍລະນີທີ່ຄວາມແມ່ນຍຳມີຄວາມສູງສີກັນ.

ໃນການເຮັດວຽກຈິງ, ໃຫ້ປຽບທຽບ 3 ເງື່ອນໄຂ ຄື: ການຄົ້ນຫາດ້ວຍ Vector ຢ່າງດຽວ, BM25 ຢ່າງດຽວ ແລະ ແບບ Hybrid ໂດຍໃຊ້ຊຸດທົດສອບດຽວກັນ ເພື່ອຢືນຢັນລະດັບການປັບປຸງເປັນຕົວເລກ. ຈຸດສຳຄັນແມ່ນການແຍກບົດບາດຂອງແຕ່ລະດັດຊະນີໃນການຕີຄວາມໝາຍ ເຊັ່ນ: Recall@K ໃຊ້ສຳລັບກວດຫາ "ການຕົກຫຼົ່ນ" ແລະ MRR ໃຊ້ສຳລັບຢືນຢັນ "ຄວາມແມ່ນຍຳໃນອັນດັບຕົ້ນ".

Golden Set ແມ່ນຊຸດຂໍ້ມູນສຳລັບການທົດສອບທີ່ກຳນົດໂດຍມະນຸດ ເຊິ່ງປະກອບດ້ວຍຄູ່ຂອງ "Query" ແລະ "ເອກະສານທີ່ຄາດຫວັງວ່າຈະຖືກຕ້ອງ". ໂດຍເລີ່ມຕົ້ນຄວນມີຢ່າງໜ້ອຍ 50-100 ລາຍການ.

ຈຸດສຳຄັນໃນການສ້າງ

• Coverage: ຄວນລວມເອົາທັງ Query ທີ່ກົງກັບຄຳສັບ (Keyword) ແລະ Query ດ້ານຄວາມໝາຍ (Semantic).
• ການກະຈາຍຄວາມຍາກ: ຄວນໃສ່ກໍລະນີທີ່ທ້າທາຍໂດຍເຈດຕະນາ ເຊັ່ນ: ຄຳສັບຄ້າຍຄື, ຄຳຫຍໍ້, ຫຼື ການປົນກັນຂອງຫຼາຍພາສາ.
• ຕົວແທນຂອງ Domain: ການສະກັດເອົາຂໍ້ມູນຈາກ Log ຂອງຜູ້ໃຊ້ຕົວຈິງ ຫຼື ປະຫວັດການສອບຖາມ ຈະເຮັດໃຫ້ໄດ້ລະດັບຄວາມຍາກທີ່ສົມຈິງ.

ການນຳໄປລວມເຂົ້າໃນ CI/CD

Golden Set ຄວນຖືກຈັດການເວີຊັນຄືກັນກັບ Code ແລະ ນຳໄປລວມເຂົ້າໃນຂັ້ນຕອນການທົດສອບຂອງ CI/CD ຂະບວນການ ຫຼື Pipeline. ທຸກຄັ້ງທີ່ມີການປ່ຽນແປງຂະໜາດ Chunk ຫຼື ອັບເດດ Model, ລະບົບຈະຄຳນວນຄ່າ Recall@K ແລະ MRR ໂດຍອັດຕະໂນມັດເພື່ອປຽບທຽບກັບເວີຊັນກ່ອນໜ້າ, ຖ້າຕົວຊີ້ວັດຫຼຸດລົງເກີນກວ່າທີ່ກຳນົດໄວ້ ຈະເຮັດການບລັອກການ ລວມ ຫຼື Merge ນັ້ນ.

ເນື່ອງຈາກປ້າຍກຳກັບທີ່ຖືກຕ້ອງອາດຈະລ້າສະໄໝເມື່ອມີການອັບເດດເອກະສານ, ຈຶ່ງແນະນຳໃຫ້ສ້າງ Feedback Loop ເພື່ອເກັບກຳກໍລະນີການຄົ້ນຫາທີ່ລົ້ມເຫຼວຈາກ Log ການໃຊ້ງານຈິງ ແລ້ວນຳມາເພີ່ມເຂົ້າໃນ Golden Set.

ການຄົ້ນຫາແບບ Hybrid ແມ່ນເຕັກໂນໂລຊີພື້ນຖານຂອງຊັ້ນການຄົ້ນຫາ, ແຕ່ກໍມີຄຳຖາມທີ່ຊັບຊ້ອນທີ່ການຄົ້ນຫາເອກະສານແບບ Flat ບໍ່ສາມາດຕອບສະໜອງໄດ້ໝົດ.

GraphRAG ແມ່ນວິທີການທີ່ນຳມາປະສົມປະສານກັບ Knowledge Graph. ໂດຍການສະກັດເອົາຊື່ສະເພາະຈາກ Chunk ທີ່ພົບໃນການຄົ້ນຫາແບບ Hybrid ແລ້ວນຳໄປເຊື່ອມຕໍ່ກັບ Node ຢູ່ເທິງກຣາຟ, ເຮັດໃຫ້ສາມາດດຶງຂໍ້ມູນຂ້າມໄປໄດ້ຫຼາຍຂັ້ນ ເຊັ່ນ: "ຜະລິດຕະພັນ X → ມາດຕະຖານທີ່ກ່ຽວຂ້ອງ → ພື້ນທີ່ນຳໃຊ້". ການອອກແບບທີ່ເປັນຈິງຄືການວາງ Neo4j ຫຼື Amazon Neptune ໄວ້ໃນຊັ້ນກຣາຟ, ແລະວາງ Qdrant ຫຼື Weaviate ໄວ້ໃນຊັ້ນ Vector, ຈາກນັ້ນຈຶ່ງຮຽກໃຊ້ງານແບບຂະໜານ.

Agentic RAG ແມ່ນວິທີການທີ່ນຳເອົາການຄົ້ນຫາແບບ Hybrid ໄປລວມເຂົ້າກັບ Agent ທີ່ໃຊ້ການອະນຸມານຫຼາຍຂັ້ນຕອນ. Agent ຈະແຍກຄຳຖາມອອກເປັນສ່ວນໆ, ໂດຍ Sub-query ທີ່ມີຊື່ສະເພາະຈະເນັ້ນການຄົ້ນຫາດ້ວຍ Keyword, ສ່ວນ Sub-query ທີ່ເປັນແນວຄິດຈະເນັ້ນການຄົ້ນຫາດ້ວຍ Vector ເພື່ອປັບຄ່າ alpha ແບບເຄື່ອນໄຫວ. ການກຳນົດ Node ການຄົ້ນຫາແບບ Hybrid ໃຫ້ເປັນ State ທີ່ເປັນອິດສະຫຼະໃນ LangGraph ຫຼື LlamaIndex Workflows ຈະຊ່ວຍໃຫ້ການເຮັດວຽກຂອງການ Retry ແລະການແຍກສາຂາ (Branching) ເຮັດໄດ້ງ່າຍຂຶ້ນ.

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

ການຄົ້ນຫາແບບ Hybrid ມີຄ່າໃຊ້ຈ່າຍສູງຂຶ້ນຫຼືບໍ່?

ຂຶ້ນຢູ່ກັບການອອກແບບ, ຄ່າໃຊ້ຈ່າຍສ່ວນເພີ່ມມີທ່າອ່ຽງທີ່ຈະຖືກຈຳກັດໄວ້. ສາເຫດຫຼັກຂອງຄ່າໃຊ້ຈ່າຍທີ່ເພີ່ມຂຶ້ນແມ່ນການຈັດການດັດສະນີສອງຊັ້ນ (ການເພີ່ມຂຶ້ນຂອງບ່ອນຈັດເກັບຂໍ້ມູນ) ແລະການປະມວນຜົນການຄົ້ນຫາສອງລະບົບແບບຂະໜານ (ຊັບພະຍາກອນການຄຳນວນ), ແຕ່ BM25 ມີນ້ຳໜັກເບົາ ແລະ ມີຄ່າໃຊ້ຈ່າຍໃນການຄຳນວນຕ່ຳກວ່າການຄົ້ນຫາແບບ Vector, ເຊິ່ງໃນຫຼາຍກໍລະນີສາມາດນຳໃຊ້ຮ່ວມກັບ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ມີຢູ່ແລ້ວໄດ້. ໃນທາງກົງກັນຂ້າມ, ເມື່ອຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາເພີ່ມຂຶ້ນ, ຄວາມສູນເປົ່າຂອງບໍລິບົດ (Context) ທີ່ ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ LLM ຈະຫຼຸດລົງ, ເຊິ່ງໃນບາງກໍລະນີສາມາດຫຼຸດຜ່ອນການໃຊ້ Token ທີ່ບໍ່ຈຳເປັນໄດ້. ການນຳໃຊ້ Cache ສຳລັບ Query ທີ່ພົບເລື້ອຍ ແລະ ການປັບຂະໜາດ Chunk ໃຫ້ເໝາະສົມກໍມີປະສິດທິຜົນເຊັ່ນກັນ. ຄ່າໃຊ້ຈ່າຍທີ່ເພີ່ມຂຶ້ນຈະເຫັນໄດ້ຊັດເຈນໃນກໍລະນີທີ່ມີເອກະສານຫຼາຍລ້ານສະບັບຂຶ້ນໄປ ແລະ ມີການອັບເດດ ແບບ Real-time ຢ່າງຖີ່.

ການຈັດຕັ້ງປະຕິບັດລະຫວ່າງ Cloud ແລະ On-premise ມີຄວາມແຕກຕ່າງກັນຫຼືບໍ່?

ແຕກຕ່າງກັນ. ໃນ Cloud, ການຄົ້ນຫາແບບ Hybrid ທີ່ລວມເຖິງ RRF ຈະຖືກສະໜອງໃຫ້ໃນລະດັບ API ເຊັ່ນ: Azure AI Search ຫຼື Amazon OpenSearch Service, ເຮັດໃຫ້ພາລະໃນການຈັດການ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ມີໜ້ອຍ. ການຂະຫຍາຍລະບົບ (Scale-out) ກໍຈະເປັນໜ້າທີ່ຂອງຜູ້ໃຫ້ບໍລິການ. ສຳລັບ On-premise, ການຕັ້ງຄ່າແບບ Self-host ດ້ວຍ Qdrant ຫຼື Elasticsearch ແມ່ນເປັນທີ່ນິຍົມ, ເຊິ່ງທັງສອງຢ່າງນີ້ມີຟັງຊັນການລວມຄະແນນ (Score fusion) ຢູ່ຝັ່ງ Server ໃຫ້, ສະນັ້ນຈຶ່ງບໍ່ຈຳເປັນຕ້ອງຈັດຕັ້ງປະຕິບັດທຸກຢ່າງໃນຊັ້ນ Application. ໃນກໍລະນີທີ່ມີຂໍ້ກຳນົດດ້ານກົດລະບຽບທີ່ບໍ່ສາມາດນຳຂໍ້ມູນອອກໄປພາຍນອກໄດ້ (ເຊັ່ນ: ການເງິນ, ການແພດ, ຫຼື ພາກລັດ), ການໃຊ້ On-premise ຈຶ່ງເປັນສິ່ງທີ່ຈຳເປັນ.

ການຄົ້ນຫາແບບ Hybrid ເປັນວິທີການທີ່ນຳໄປໃຊ້ໄດ້ຈິງ ໂດຍການລວມເອົາ Vector Search ແລະ BM25 ເຂົ້າດ້ວຍກັນ ເພື່ອປົກຄຸມຄຳສັ່ງຄົ້ນຫາ (Query) ທີ່ອາດຕົກຫຼ່ນໄປຫາກໃຊ້ພຽງວິທີໃດວິທີໜຶ່ງ. ວິທີນີ້ສາມາດຮອງຮັບໄດ້ທັງໃນກໍລະນີທີ່ຕ້ອງການຄວາມຖືກຕ້ອງຂອງຄຳສຳຄັນ (Keyword) ເຊັ່ນ: ເລກລຸ້ນ, ຊື່ສະເພາະ, ຫຼື Code snippet ແລະ ກໍລະນີທີ່ຕ້ອງການຄົ້ນຫາເອກະສານໂດຍອີງໃສ່ຄວາມໃກ້ຄຽງທາງຄວາມໝາຍ.

ຂໍ້ສະຫຼຸບທີ່ໄດ້ຈາກບົດຄວາມນີ້ມີດັ່ງນີ້:

• ຂັ້ນຕອນການອອກແບບ: ການເລືອກ Vector DB, ຂະໜາດຂອງ Chunk, ແລະ Embedding model ໃຫ້ພ້ອມກ່ອນລ່ວງໜ້າ ແມ່ນພື້ນຖານຂອງຄວາມແມ່ນຍຳ.
• ການລວມຄະແນນ (Score integration): RRF ມີການນຳໄປໃຊ້ທີ່ງ່າຍ ແລະ ເຫັນຜົນໄດ້ໄວ. ຕ້ອງກວດສອບຄ່າເລີ່ມຕົ້ນຂອງ k ເພາະແຕ່ລະ Platform ຈະມີຄ່າທີ່ແຕກຕ່າງກັນ.
• ການຮອງຮັບຫຼາຍພາສາ: ໃນພາສາຢີ່ປຸ່ນ, ພາສາໄທ ແລະ ອື່ນໆ, ຄວາມບໍ່ສອດຄ່ອງກັນຂອງ Analyzer/Tokenizer ຈະເປັນຕົ້ນເຫດທີ່ເຮັດໃຫ້ຄວາມແມ່ນຍຳຫຼຸດລົງ.
• ການອອກແບບການປະເມີນຜົນ: ຕິດຕາມຄຸນນະພາບຢ່າງຕໍ່ເນື່ອງດ້ວຍ Recall@K, MRR ແລະ Golden set.

ໃນດ້ານການພັດທະນາຕໍ່ຍອດ, ການຂະຫຍາຍໄປສູ່ GraphRAG ຫຼື Agentic RAG ກໍເປັນສິ່ງທີ່ຄວນພິຈາລະນາ, ແຕ່ການເລີ່ມຕົ້ນຈາກການຄົ້ນຫາແບບ Hybrid ທີ່ລຽບງ່າຍເພື່ອຢືນຢັນການຍົກລະດັບຄວາມແມ່ນຍຳກ່ອນ ແລ້ວຈຶ່ງຄ່ອຍໆພັດທະນາໄປຕາມຂັ້ນຕອນນັ້ນເປັນສິ່ງທີ່ເໝາະສົມກວ່າ. ການຫຼຸດຜ່ອນ Hallucination ແລະ ການປັບປຸງຄຸນນະພາບຂອງຄຳຕອບ ຈະບໍ່ສາມາດເກີດຂຶ້ນໄດ້ຫາກບໍ່ມີການປັບປຸງຊັ້ນການຄົ້ນຫາ (Search layer). ຂໍໃຫ້ຖືວ່າການນຳເອົາການຄົ້ນຫາແບບ Hybrid ມາໃຊ້ ເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນວົງຈອນການປັບປຸງຄຸນນະພາບຂອງ RAG ໂດຍລວມ.