PoC ຂອງ RAG ເຮັດວຽກໄດ້. ແຕ່ທັນທີທີ່ deploy ໄປໃນ production environment, ຄວາມຖືກຕ້ອງກໍຫຼຸດລົງ, ແລະຜູ້ໃຊ້ກໍເວົ້າວ່າ "ໃຊ້ບໍ່ໄດ້" ——ຖ້າທ່ານຮູ້ສຶກຄຸ້ນເຄີຍກັບຮູບແບບນີ້, ບົດຄວາມນີ້ຖືກຂຽນຂຶ້ນເພື່ອຕື່ມຊ່ອງຫວ່າງດັ່ງກ່າວ. ພວກເຮົາຈະອະທິບາຍເທື່ອລະຂັ້ນຕອນ ຕັ້ງແຕ່ວິທີການເພີ່ມຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາ 15〜30% ດ້ວຍ Hybrid earch ທີ່ລວມ Dense vector search ແລະ BM25 ເຂົ້າກັນ, ໄປຈົນເຖິງການສ້າງ dynamic search pipeline ທີ່ຕອບສະໜອງຕໍ່ຄວາມຕັ້ງໃຈຂອງ query ດ້ວຍ Agentic RAG — ລວມທັງການອອກແບບ implementation pattern ແລະ evaluation metric. ພ້ອມກັນນັ້ນ, ພວກເຮົາຍັງຈະນຳສະເໜີສິ່ງທ້າທາຍສະເພາະຂອງ low-resource language ທີ່ພວກເຮົາໄດ້ພົບໃນລະຫວ່າງການສ້າງ RAG chatbot ພາສາລາວ, ພ້ອມທັງຈັດລະບຽບການຕັດສິນໃຈດ້ານການອອກແບບທີ່ຈຳເປັນສຳລັບການຍ້າຍຈາກ PoC ໄປສູ່ production.

ລະຫວ່າງ PoC environment ແລະ production environment ນັ້ນ ມີຄວາມແຕກຕ່າງພື້ນຖານໃນດ້ານຄຸນນະພາບ, ປະລິມານ, ແລະຄວາມຫຼາກຫຼາຍຂອງຂໍ້ມູນ. ໃນ PoC ນັ້ນ ຈະທຳການກວດສອບດ້ວຍ "ຂໍ້ມູນທີ່ໄດ້ຜົນດີ" ແຕ່ໃນ production ນັ້ນ query ທີ່ບໍ່ໄດ້ຄາດຄິດໄວ້ຈະຖືກສົ່ງເຂົ້າມາເປັນຈຳນວນຫຼວງຫຼາຍ. ໃນ section ນີ້ ຈະທຳການວິເຄາະໂຄງສ້າງຂອງ accuracy gap ໃຫ້ລະອຽດ.

1つ目はຄວາມເປັນເອກະພາບຂອງຂໍ້ມູນດ້ວຍ. ໃນ PoC ນັ້ນ, ມີການທົດສອບດ້ວຍເອກະສານພາຍໃນທີ່ຈັດຮູບແບບແລ້ວຈຳນວນຫຼາຍສິບຫາຫຼາຍຮ້ອຍລາຍການ. ແຕ່ໃນການໃຊ້ງານຈິງ, ເອກະສານຈຳນວນຫຼາຍໝື່ນລາຍການທີ່ມີຮູບແບບ ແລະ ໂທນທີ່ແຕກຕ່າງກັນ ເຊັ່ນ: PDF, Markdown, HTML, ບົດບັນທຶກການປະຊຸມ, ບັນທຶກການສົນທະນາ ຈະໄຫຼເຂົ້າມາ. ພຽງແຕ່ຂອບເຂດຂອງ chunking ຜິດພາດ, context ທີ່ຈຳເປັນສຳລັບຄຳຕອບກໍ່ຈະຂາດຫາຍໄປ.

2つ目はຄວາມຫຼາກຫຼາຍຂອງ queryດ້ວຍ. Query ທົດສອບໃນ PoC ນັ້ນ ມີແນວໂນ້ມທີ່ຈະຖືກຂຽນໂດຍນັກພັດທະນາ ໃນລັກສະນະ "ຄຳຖາມທີ່ຮູ້ຢູ່ແລ້ວວ່າມີຄຳຕອບທີ່ຖືກຕ້ອງ". ຜູ້ໃຊ້ງານຈິງຈະຖາມຄຳຖາມທີ່ບໍ່ຊັດເຈນ, ຄຳຖາມທີ່ສັບສົນ, ແລະ ຍັງຖາມຄຳຖາມທີ່ຢູ່ນອກຂອບເຂດຂອງ RAG ອີກດ້ວຍ.

3つ目はການຂາດການປະເມີນຜົນດ້ວຍ. ໃນ PoC ນັ້ນ ມັກຈະຜ່ານໄປດ້ວຍຄວາມຮູ້ສຶກ "ດູຄືວ່າດີ", ແຕ່ໃນການໃຊ້ງານຈິງ ຖ້າບໍ່ມີຕົວຊີ້ວັດຄວາມຖືກຕ້ອງທາງດ້ານປະລິມານ ກໍ່ຈະບໍ່ສາມາດສັງເກດເຫັນການຖົດຖອຍໄດ້. ໃນຄັ້ງທີ່ບໍລິສັດຂອງພວກເຮົາສ້າງ RAG ພາສາລາວ, ໃນ PoC ນັ້ນ ໄດ້ຢືນຢັນຄວາມຖືກຕ້ອງດ້ວຍການທົດສອບການແປເອກະສານພາສາອັງກິດເທົ່ານັ້ນ, ແຕ່ query ຂອງຜູ້ໃຊ້ທີ່ໃຊ້ພາສາລາວຈິງໆ ນັ້ນ ມີການສະແດງອອກທາງປາກເວົ້າ ແລະ ພາສາຖິ່ນລວມຢູ່ດ້ວຍ, ຊຶ່ງແຕກຕ່າງຈາກຄະແນນໃນຕອນ PoC ໂດຍສິ້ນເຊີງ.

ການເສື່ອມຄຸນນະພາບຄວາມຖືກຕ້ອງເກີດຂຶ້ນໃນ 3 ຊັ້ນຫຼັກ.

ຊັ້ນການຄົ້ນຫາ (Search Layer) ເປີດເຜີຍຂໍ້ຈຳກັດຂອງ Dense Search ທີ່ໃຊ້ຢ່າງດຽວ. ຄຳສັບທາງວິຊາການ ແລະ ຊື່ສະເພາະ (proper nouns) ອາດຈະບໍ່ຖືກຈັດໃຫ້ຢູ່ໃກ້ກັນໃນ Embedding Space ສົ່ງຜົນໃຫ້ເອກະສານທີ່ກ່ຽວຂ້ອງທາງຄວາມໝາຍຖືກຂ້າມໄປ. ໃນທາງກົງກັນຂ້າມ, ກໍ່ມີກໍລະນີທີ່ chunk ທີ່ມີຄວາມຄ້າຍຄືກັນທາງໜ້າຜິວ ແຕ່ມີ context ທີ່ແຕກຕ່າງກັນຖືກສົ່ງຄືນໃນອັນດັບຕົ້ນ.

ຊັ້ນ Chunking (Chunking Layer) ການຕັດຂໍ້ມູນດ້ວຍຄວາມຍາວຄົງທີ່ກໍ່ໃຫ້ເກີດບັນຫາການຂາດຕອນຂອງຂໍ້ມູນ. ເຊັ່ນ: ການຕັດກາງຕາຕະລາງ ຫຼື ລາຍການ, ຫຼື ການສ້າງ chunk ທີ່ບໍ່ສາມາດເຂົ້າໃຈຄວາມໝາຍໄດ້ຫາກຂາດ context ກ່ອນໜ້າ ແລະ ຫຼັງຈາກນັ້ນ.

ຊັ້ນການສ້າງ (Generation Layer) ການສົ່ງຜົນການຄົ້ນຫາທີ່ມີຄຸນນະພາບຕ່ຳໃຫ້ LLM ເຮັດໃຫ້ເກີດ Hallucination ແລະ ຄຳຕອບທີ່ຜິດທາງເພີ່ມຂຶ້ນ. ຫາກຄວາມຖືກຕ້ອງຂອງການຄົ້ນຫາຕ່ຳ, ບໍ່ວ່າຈະໃຊ້ LLM ທີ່ມີປະສິດທິພາບສູງພຽງໃດ, ຜົນລັບກໍ່ຈະບໍ່ດີຂຶ້ນ. ຄວາມຖືກຕ້ອງຂອງ RAG ຖືກກຳນົດໂດຍການຄົ້ນຫາເປັນອັນດັບທຳອິດ.

ບົດຄວາມນີ້ຈະອະທິບາຍກ່ຽວກັບສະພາບແວດລ້ອມ ແລະ ຄວາມຮູ້ທີ່ຈຳເປັນໃນການນຳໄປປະຕິບັດຕາມຂັ້ນຕອນຂອງບົດຄວາມນີ້.

ການຕັ້ງຄ່າດ້ວຍ pgvector + PostgreSQL ເໝາະສຳລັບການເລີ່ມຕົ້ນໃນຂະໜາດນ້ອຍ. ໃນລະບົບ RAG ພາສາລາວຂອງບໍລິສັດເຮົາ ກໍໄດ້ເລີ່ມຕົ້ນດ້ວຍ pgvector ກ່ອນ ແລ້ວຈຶ່ງພິຈາລະນາການຍ້າຍໄປໃຊ້ Vector DB ສະເພາະທາງຕາມຂະໜາດທີ່ຂະຫຍາຍຕົວຂຶ້ນ.

ຖ້າທ່ານເຂົ້າໃຈສິ່ງຕໍ່ໄປນີ້, ທ່ານຈະສາມາດດຳເນີນຂັ້ນຕອນໃນບົດຄວາມນີ້ໄດ້ຢ່າງລາບລື່ນ.

• ແນວຄິດພື້ນຖານຂອງ Vector Search (Embedding, Cosine Similarity, ANN)
• ກົນໄກຂອງ BM25 (ການໃຫ້ຄະແນນແບບ TF-IDF)
• ການເອີ້ນໃຊ້ API ຂອງ LLM (ການອອກແບບ Prompt, ການຈັດການ Token)
• ກະແສການທຳງານພື້ນຖານຂອງ RAG (ການຄົ້ນຫາ → ການໃສ່ Context → ການສ້າງຜົນລັບ)

ຫາກທ່ານຍັງບໍ່ແນ່ໃຈໃນເລື່ອງເຫຼົ່ານີ້, ແນະນຳໃຫ້ທ່ານສ້າງຄວາມເຂົ້າໃຈພື້ນຖານກ່ອນໂດຍການອ່ານຄູ່ມື RAG ສຳລັບ AI Chatbot ພາສາລາວ.

ການຕັດແບ່ງ (Chunking) ແມ່ນພື້ນຖານຂອງຄວາມຖືກຕ້ອງຂອງ RAG. ຫຼີກໜີຈາກການ "ແບ່ງດ້ວຍ 500 token ໄປກ່ອນ" ໃນຂັ້ນ PoC ແລ້ວອອກແບບຍຸດທະສາດທີ່ເໝາະສົມກັບໂຄງສ້າງຂອງເອກະສານ.

ບໍ່ມີຄຳຕອບທີ່ຖືກຕ້ອງສຳລັບ chunk size ທຸກກໍລະນີ. ແຕ່ວ່າມີແນວທາງປະຕິບັດຕົວຈິງຢູ່.

• chunk ສັ້ນ (200〜400 token): ຄວາມແມ່ນຍຳໃນການຄົ້ນຫາສູງຂຶ້ນ, ແຕ່ context ມັກຈະບໍ່ພຽງພໍ. ເໝາະສຳລັບ FAQ ແລະ ຊຸດຄຳນິຍາມ
• chunk ຍາວ (800〜1200 token): context ອຸດົມສົມບູນ, ແຕ່ noise ກໍເພີ່ມຂຶ້ນດ້ວຍ. ເໝາະສຳລັບເອກະສານດ້ານວິຊາການ ແລະ ສັນຍາ
• overlap: ການໃຫ້ chunk ຊ້ອນທັບກັນ 10〜20% ລະຫວ່າງ chunk ຊ່ວຍຫຼຸດຜ່ອນການສູນເສຍຂໍ້ມູນທີ່ຂອບເຂດ

ຈາກປະສົບການຂອງຜູ້ຂຽນ, ການເລີ່ມຕົ້ນດ້ວຍ 400 token ແລະ overlap 50 token, ຈາກນັ້ນປັບໂດຍອ້າງອີງຕາມ metric ການປະເມີນ, ເປັນວິທີທີ່ມີປະສິດທິພາບສູງສຸດ. ໄດ້ເຫັນໂຄງການທີ່ໃຊ້ເວລາ 2 ອາທິດໄປກັບການພະຍາຍາມກຳນົດຄ່າທີ່ດີທີ່ສຸດຕັ້ງແຕ່ຕົ້ນ, ແຕ່ການ tuning ໃນຂັ້ນຕອນທີ່ຍັງບໍ່ທັນມີ evaluation pipeline ນັ້ນເປັນການເສຍເວລາເປົ່າ.

ສິ່ງທີ່ສົ່ງຜົນຕໍ່ຄວາມຖືກຕ້ອງຂອງ RAG ໃນການຜະລິດຢ່າງຫຼວງຫຼາຍ ຄືການຕິດ metadata ໃສ່ chunk.

ເມື່ອນຳໃຊ້ pre-filtering ດ້ວຍ metadata, ສາມາດຈຳກັດຂອບເຂດການຄົ້ນຫາກ່ອນ ແລ້ວຈຶ່ງດຳເນີນການຄົ້ນຫາແບບ Dense/BM25 ໄດ້. ສຳລັບ query ເຊັ່ນ "ລະບຽບພາຍໃນຫຼ້າສຸດກ່ຽວກັບຄວາມປອດໄພຂໍ້ມູນ", ການຄົ້ນຫາຫຼັງຈາກ filter ດ້ວຍ document_type = "policy" ແລະ section LIKE '%セキュリティ%' ກ່ອນ ຈະໃຫ້ຄວາມຖືກຕ້ອງສູງກວ່າການຄົ້ນຫາໃນທຸກ chunk ຢ່າງຫຼວງຫຼາຍ.

ໃນຕອນທີ່ບໍລິສັດຂອງພວກເຮົາກຳລັງສ້າງ RAG chatbot ພາສາລາວ, ສິ່ງທີ່ຫຍຸ້ງຍາກທີ່ສຸດໃນຂັ້ນຕອນ chunking ແມ່ນການກວດຈັບຂອບເຂດຂອງຄຳ (word boundary detection). ພາສາລາວ ຄືກັນກັບພາສາໄທ ແມ່ນພາສາທີ່ບໍ່ໃຊ້ຊ່ອງຫວ່າງໃນການແຍກຄຳ, ດັ່ງນັ້ນ tokenizer ທີ່ອອກແບບມາສຳລັບພາສາອັງກິດຈຶ່ງຕັດຂອບເຂດ chunk ກາງປະໂຫຍກ.

ໃນທີ່ສຸດ, ພວກເຮົາໄດ້ implement custom splitter ທີ່ໃຊ້ເຄື່ອງໝາຍວັກຕອນຂອງພາສາລາວ (ເຄື່ອງໝາຍທີ່ທຽບເທົ່າກັບ 。) ເປັນ primary delimiter ແລະ ໃຊ້ຄວາມຍາວ byte ເປັນ secondary delimiter. ພຽງແຕ່ການປັບປຸງນີ້ເທົ່ານັ້ນ, ຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາ (Hit Rate@5) ກໍ່ດີຂຶ້ນຈາກ 0.42 ເປັນ 0.61. ສຳລັບ low-resource language, ຖ້າໃຊ້ chunking library ທົ່ວໄປໂດຍກົງ ຄວາມຖືກຕ້ອງກໍ່ຈະບໍ່ດີ. ການ preprocessing ທີ່ເໝາະສົມກັບພາສານັ້ນໆ ຈຶ່ງເປັນເງື່ອນໄຂຂັ້ນພື້ນຖານສຳລັບຄຸນນະພາບລະດັບ production.

Dense ベクトル検索 ມີຄວາມເຂັ້ມແຂງໃນດ້ານຄວາມຄ້າຍຄືກັນທາງຄວາມໝາຍ, ແຕ່ອ່ອນແອໃນການຈັບຄູ່ທີ່ຊັດເຈນຂອງຊື່ສະເພາະ ແລະ ຄຳສຳຄັນ. BM25 ແມ່ນກົງກັນຂ້າມ. Hybrid ການຄົ້ນຫາທີ່ລວມທັງສອງເຂົ້າກັນ ໄດ້ຖືກລາຍງານໃນຫຼາຍ benchmark ວ່າມີຄວາມຖືກຕ້ອງສູງຂຶ້ນ 15〜30% ເມື່ອທຽບກັບການຄົ້ນຫາແບບດຽວ.

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

ມີສອງວິທີຫຼັກໃນການລວມຄະແນນຂອງ Hybrid ການຄົ້ນຫາ.

Reciprocal Rank Fusion（RRF） ແມ່ນການລວມຄະແນນໂດຍໃຊ້ສະເພາະລຳດັບຂອງຜົນການຄົ້ນຫາແຕ່ລະລາຍການ. ບໍ່ຈຳເປັນຕ້ອງ normalize ຄະແນນ ແລະ ສາມາດລວມ search engine ທີ່ມີການກະຈາຍຄະແນນຕ່າງກັນໄດ້ງ່າຍ.

k ປົກກະຕິຕັ້ງຄ່າໄວ້ທີ່ 60. ຄວາມງ່າຍດາຍນີ້ຄືຈຸດແຂງຂອງ RRF ເຊິ່ງໃຫ້ຜົນທີ່ໝັ້ນຄົງກວ່າ ເນື່ອງຈາກມີ tuning parameter ໜ້ອຍ.

ການລວມເສັ້ນຊື່ແບບມີນ້ຳໜັກ (重み付き線形結合) ແມ່ນການ normalize ຄະແນນແຕ່ລະອັນກ່ອນ ແລ້ວຈຶ່ງຄິດໄລ່ຄ່າສະເລ່ຍແບບມີນ້ຳໜັກ.

ຫຼາຍກໍລະນີຕັ້ງຄ່າ α ໄວ້ປະມານ 0.7 (ໃຫ້ຄວາມສຳຄັນກັບ Dense) ແຕ່ຄ່າທີ່ດີທີ່ສຸດຈະປ່ຽນໄປຕາມ domain ແລະ ປະເພດ query. ວິທີທີ່ເປັນຈິງຄືການໃຊ້ grid search ຫາຄ່າ α ໃນ evaluation pipeline.

ຄຳແນະນຳຂອງຜູ້ຂຽນຄື ໃຫ້ເລີ່ມ implement ດ້ວຍ RRF ກ່ອນເພື່ອສ້າງ baseline ຄວາມຖືກຕ້ອງ, ແລ້ວຈຶ່ງພິຈາລະນາຍ້າຍໄປໃຊ້ການລວມເສັ້ນຊື່ແບບມີນ້ຳໜັກຫາກຍັງມີຊ່ອງທາງປັບປຸງຄວາມຖືກຕ້ອງ. ການໃຊ້ເວລາ tune α ຕັ້ງແຕ່ຕົ້ນແມ່ນບໍ່ຈຳເປັນ — ລໍຖ້າໃຫ້ມີຂໍ້ມູນ evaluation ສະສົມພຽງພໍກ່ອນ.

ການຄົ້ນຫາແບບ Hybrid ທີ່ສຳເລັດຮູບໃນ PostgreSQL ໂດຍໃຊ້ pgvector + pg_bigm ມີໂຄງສ້າງ infrastructure ທີ່ງ່າຍດາຍ ແລະ ຄ່າໃຊ້ຈ່າຍໃນການດຳເນີນງານຕ່ຳ.

ລວມຄະແນນດ້ວຍ RRF ແລ້ວສົ່ງ 5〜10 ລາຍການສູງສຸດໃຫ້ LLM. ໃນ benchmark ພາຍໃນຂອງບໍລິສັດ, Hit Rate@5 ຂອງ Dense ແບບດຽວຢູ່ທີ່ 0.72, ໃນຂະນະທີ່ Hybrid（RRF）ປັບປຸງຂຶ້ນເຖິງ 0.87. ໂດຍສະເພາະ, ການປັບປຸງໃນ query ທີ່ມີຄຳນາມສະເພາະ (proper nouns) ແມ່ນໃຫຍ່ຫຼວງ, ເພີ່ມຂຶ້ນຢ່າງໜ້າຕື່ນໃຈຈາກ 0.58 → 0.84.

RAG ແບບດັ້ງເດີມແມ່ນ pipeline ຄົງທີ່ທີ່ປະກອບດ້ວຍ "query → ຄົ້ນຫາ → ສ້າງ". Agentic RAG ໄດ້ຂະຫຍາຍຕໍ່ຈາກນີ້ ໂດຍໃຫ້ LLM agent ຕັດສິນໃຈກົນລະຍຸດການຄົ້ນຫາຢ່າງເໝາະສົມ. ວິທີການນີ້ທີ່ Gartner ໄດ້ຮັບຮູ້ວ່າເປັນ trend ທີ່ໜ້າຈັບຕາ ສາມາດເພີ່ມຄວາມຖືກຕ້ອງຕໍ່ query ທີ່ສັບສົນໄດ້ຢ່າງຫຼວງຫຼາຍ.

ໃນ RAG ແບບດັ້ງເດີມ (Naive RAG), query ຂອງຜູ້ໃຊ້ຈະກາຍເປັນ query ສຳລັບການຄົ້ນຫາໂດຍກົງ. ແຕ່ composite query ເຊັ່ນ "ປຽບທຽບການຮັບມືກັບ security incident ໃນປີທີ່ຜ່ານມາກັບມາດຕະການປ້ອງກັນໃນປີນີ້" ບໍ່ສາມາດຄອບຄຸມຂໍ້ມູນທີ່ຈຳເປັນທັງໝົດໄດ້ດ້ວຍການຄົ້ນຫາພຽງຄັ້ງດຽວ.

ໃນ Agentic RAG, LLM agent ຈະດຳເນີນການຕັດສິນໃຈຕໍ່ໄປນີ້ຢ່າງອັດຕະໂນມັດ.

• Query Decomposition: ແຍກ composite query ອອກເປັນ sub-query ຫຼາຍອັນ
• ການເລືອກ Search Strategy: ຕັດສິນໃຈວ່າຈະໃຊ້ Dense / BM25 / metadata filter ອັນໃດສຳລັບແຕ່ລະ sub-query
• ການປະເມີນຜົນ: ປະເມີນວ່າຜົນການຄົ້ນຫາພຽງພໍຫຼືບໍ່, ຖ້າຍັງຂາດກໍຈະຄົ້ນຫາໃໝ່
• ການສັງເຄາະຄຳຕອບ: ລວມຜົນການຄົ້ນຫາຫຼາຍອັນເຂົ້າກັນເພື່ອສ້າງຄຳຕອບສຸດທ້າຍ

ນີ້ບໍ່ແມ່ນພຽງແຕ່ການປັບປຸງດ້ານເຕັກນິກເທົ່ານັ້ນ, ແຕ່ເປັນການປ່ຽນແປງ paradigm ຂອງ architecture ຂອງ RAG. Search pipeline ປ່ຽນຈາກ "ສິ່ງທີ່ກຳນົດຕາຍຕົວດ້ວຍໂປຣແກຣມ" ໄປສູ່ "ສິ່ງທີ່ agent ກຳນົດຕາມສະຖານະການ".

Agent ຂອງ Agentic RAG ຈະຖືກມອບເຄື່ອງມືດັ່ງຕໍ່ໄປນີ້.

ສິ່ງສຳຄັນໃນການອອກແບບເຄື່ອງມືຄື ການຂຽນ description ຂອງແຕ່ລະເຄື່ອງມືໃຫ້ຊັດເຈນ. ເນື່ອງຈາກ Agent ຈະອ່ານ description ເພື່ອເລືອກໃຊ້ເຄື່ອງມື, ຫາກຂຽນໄວ້ບໍ່ຊັດເຈນ ກໍຈະເກີດການເລືອກເຄື່ອງມືຜິດພາດຂຶ້ນເລື້ອຍໆ. ແທນທີ່ຈະຂຽນວ່າ "ຄົ້ນຫາ" ຄວນຂຽນໃຫ້ລະອຽດວ່າ "ດຳເນີນການ Hybrid Search ດ້ວຍ Dense + BM25 ແລະ ສົ່ງຄືນລາຍການ chunk ພ້ອມຄະແນນຄວາມກ່ຽວຂ້ອງ".

ສະແດງໃຫ້ເຫັນ flow ຕົວຈິງຂອງ Agentic RAG.

ຜູ້ໃຊ້: "ໃນບັນດາມາດຕະການຄວບຄຸມຂອງ ISO 27001
          ກະລຸນາລາຍຊື່ລາຍການທີ່ບໍລິສັດຂອງເຮົາຍັງບໍ່ໄດ້ດຳເນີນການ"

ການຄິດຂອງ Agent:
  1. ຕ້ອງການລາຍຊື່ມາດຕະການຄວບຄຸມຂອງ ISO 27001
     → metadata_filter(doc_type="standard", title="ISO 27001")
  2. ຕ້ອງການສະຖານະການດຳເນີນການຂອງບໍລິສັດ
     → hybrid_search("ສະຖານະການດຳເນີນການ ຄວາມປອດໄພຂໍ້ມູນ ມາດຕະການຄວບຄຸມ")
  3. ນຳຜົນການຄົ້ນຫາມາທຽບກັນເພື່ອລະບຸລາຍການທີ່ຍັງບໍ່ໄດ້ດຳເນີນການ
     → summarize_results(chunks, original_query)
  4. ຜົນລັບບໍ່ພຽງພໍ (ພົບສະຖານະການດຳເນີນການພຽງບາງສ່ວນ)
     → refine_query("ລາຍງານສະຖານະການຈັດຕັ້ງປະຕິບັດມາດຕະການຄວາມປອດໄພຕາມພະແນກ")
  5. ລວມຜົນລັບເພີ່ມເຕີມເພື່ອສ້າງຄຳຕອບສຸດທ້າຍ

ດ້ວຍວິທີນີ້, Agentic RAG ຈຶ່ງສາມາດທຳການຄົ້ນຫາແລະປະເມີນຜົນຊ້ຳຫຼາຍຄັ້ງຢ່າງອັດຕະໂນມັດສຳລັບ query ດຽວ. ໃນຂະນະທີ່ pipeline ທີ່ຕາຍຕົວຂອງ PoC ຈະຄົ້ນຫາດ້ວຍ "ISO 27001 ມາດຕະການຄວບຄຸມ ທີ່ຍັງບໍ່ໄດ້ດຳເນີນການ" ພຽງຄັ້ງດຽວແລ້ວຈົບ, ແຕ່ Agentic RAG ສາມາດຂະຫຍາຍໄປສູ່ການຄົ້ນຫາຫຼາຍຂັ້ນຕອນທີ່ເໝາະສົມກັບສະພາບການໄດ້.

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

ສິ່ງທ້າທາຍທີ່ໃຫຍ່ທີ່ສຸດຂອງ RAG ໃນການໃຊ້ງານຈິງແມ່ນ "ການທີ່ບໍ່ສາມາດສັງເກດເຫັນໄດ້ເມື່ອຄວາມຖືກຕ້ອງຫຼຸດລົງ". ໂດຍການລວມ evaluation pipeline ເຂົ້າໃນ CI/CD ຈະສ້າງກົນໄກໃນການກວດຈັບການຫຼຸດລົງຂອງຄວາມຖືກຕ້ອງກ່ອນການ deploy.

ຕົວຊີ້ວັດການປະເມີນຜົນຂອງ RAG ຈຳເປັນຕ້ອງຄອບຄຸມທັງດ້ານການຄົ້ນຫາ ແລະ ການສ້າງຂໍ້ຄວາມ.

ສິ່ງທີ່ຜູ້ຂຽນໃຫ້ຄວາມສຳຄັນຫຼາຍທີ່ສຸດຄື Faithfulness. ສຳລັບການໃຊ້ງານລະດັບ enterprise, hallucination (ຄຳຕອບທີ່ແຕກຕ່າງຈາກຂໍ້ເທັດຈິງ) ຖືເປັນຄວາມສ່ຽງທີ່ໃຫຍ່ທີ່ສຸດ ແລະ ສາມາດທຳລາຍຄວາມໄວ້ວາງໃຈຂອງຜູ້ໃຊ້ໄດ້ໃນທັນທີ. ຜູ້ຂຽນໄດ້ກຳນົດກົດລະບຽບວ່າ ຫາກ Faithfulness ຕໍ່າກວ່າ 0.95 ຈະທຳການ block ການ deploy.

Ragas ຫຼື DeepEval ສາມາດໃຊ້ສ້າງ evaluation pipeline ໄດ້ພາຍໃນໄລຍະເວລາທີ່ຄ່ອນຂ້າງສັ້ນ.

ການສ້າງຊຸດຂໍ້ມູນທົດສອບແມ່ນຂັ້ນຕອນທີ່ໃຊ້ຊັບພະຍາກອນຫຼາຍທີ່ສຸດ. ນອກຈາກ test case ທີ່ໃຊ້ໃນ PoC ແລ້ວ, ຄວນເພີ່ມ case ທີ່ຜູ້ໃຊ້ໃຫ້ feedback ວ່າ "ຄຸນນະພາບຄຳຕອບຕ່ຳ" ຈາກ production log ຢ່າງຕໍ່ເນື່ອງ. ຫາກມີ test case ຢ່າງໜ້ອຍ 100 ລາຍການ, ແລະໃນອຸດົມຄະຕິຄວນມີ 500 ລາຍການຂຶ້ນໄປ, ຈະສາມາດໄດ້ຮັບການປະເມີນທີ່ໜ້າເຊື່ອຖືທາງສະຖິຕິ.

ຈຸດສຳຄັນໃນການນຳໃຊ້ກັບ CI/CD ຄືການກຳນົດ gate ທີ່ອີງໃສ່ threshold.

• PR Merge Gate: ຖ້າ Faithfulness < 0.95 ຫຼື Context Relevance < 0.80 ຈະບລັອກການ merge
• ການປະເມີນ Batch ເປັນໄລຍະ: ດຳເນີນການປະເມີນຕໍ່ກັບຕົວຢ່າງຂໍ້ມູນ production ທຸກວັນ
• Alert: ແຈ້ງເຕືອນຜ່ານ Slack ຖ້າ metric ຫຼຸດລົງ 5% ຂຶ້ນໄປເມື່ອທຽບກັບອາທິດກ່ອນ

ໃນບໍລິສັດຂອງພວກເຮົາ ໄດ້ສ້າງ flow ທີ່ລວມເຂົ້າກັບກົນໄກ HITL（Human-in-the-Loop） ໂດຍໃຫ້ມະນຸດ review ກໍລະນີທີ່ການປະເມີນອັດຕະໂນມັດຕ່ຳກວ່າ threshold. ການປະເມີນອັດຕະໂນມັດບໍ່ແມ່ນວິທີທີ່ດີທີ່ສຸດໃນທຸກດ້ານ ແຕ່ໃນດ້ານການກວດພົບການເສື່ອມຖອຍໃນໄລຍະຕົ້ນ ມັນໄວກວ່າການ review ໂດຍມະນຸດຢ່າງດຽວຢ່າງຫຼວງຫຼາຍ.

PoC → ການຍ້າຍໄປໃຊ້ງານຈິງ, ຂ້າພະເຈົ້າຈະນຳສະເໜີ 3 ຮູບແບບຄວາມລົ້ມເຫຼວທີ່ໄດ້ເຫັນຊ້ຳໆ.

ການເລືອກ Embedding model ໂດຍອີງໃສ່ຄະແນນ benchmark ພາສາອັງກິດເທົ່ານັ້ນ ມັກຈະເຮັດໃຫ້ຄວາມຖືກຕ້ອງຕໍ່າລົງເມື່ອໃຊ້ກັບເອກະສານພາສາຍີ່ປຸ່ນ ຫຼື ຫຼາຍພາສາ. ໃນລະບົບ RAG ພາສາລາວຂອງບໍລິສັດເຮົາ, text-embedding-3-large ຂອງ OpenAI ໃຫ້ຜົນດີເລີດໃນພາສາອັງກິດ, ແຕ່ສຳລັບພາສາລາວ, model ຫຼາຍພາສາຂອງ Cohere ໃຫ້ Hit Rate ສູງກວ່າເຖິງ 12 ຈຸດ.

ວິທີແກ້ໄຂ: ຕ້ອງທຳການ benchmark ດ້ວຍຂໍ້ມູນ domain ຂອງຕົນເອງສະເໝີ. benchmark ສາທາລະນະ (ເຊັ່ນ MTEB ເປັນຕົ້ນ) ຖືເປັນພຽງຄ່າອ້າງອີງເທົ່ານັ້ນ, ແລະ ຫາກຂໍ້ມູນມີຄຳສັບສະເພາະ domain ຫຼາຍ, ອັນດັບຂອງ model ອາດປ່ຽນແປງໄດ້ຢ່າງຫຼວງຫຼາຍ.

ການໃຊ້ Reranker (Cross-Encoder) ຕໍ່ຈາກ Hybrid ການຄົ້ນຫາ ສາມາດຄາດຫວັງໄດ້ວ່າຈະເພີ່ມຄວາມຖືກຕ້ອງໄດ້ອີກ 5〜15% ແຕ່ມີບາງໂປຣເຈັກທີ່ຕັດສິນໃຈວ່າ "Hybrid ພຽງຢ່າງດຽວກໍ່ພຽງພໍແລ້ວ" ແລ້ວຈົບລົງດ້ວຍຄວາມຖືກຕ້ອງທີ່ຢຸດນິ່ງ.

Reranker ແມ່ນໂມເດລທີ່ທຳການ re-scoring ຜົນການຄົ້ນຫາ 20〜50 ອັນດັບເທິງ ໂດຍຈັບຄູ່ກັບ query. ມີຄ່າໃຊ້ຈ່າຍໃນການຄຳນວນສູງກວ່າ Bi-Encoder (Embedding) ແຕ່ຄວາມຖືກຕ້ອງສູງກວ່າຢ່າງຫຼວງຫຼາຍ. Cohere Rerank ແລະ bge-reranker-v2 ແມ່ນທາງເລືອກທີ່ໃຊ້ງານໄດ້ຈິງ.

ວິທີແກ້ໄຂ: ກຳນົດໃຫ້ pipeline 3 ຂັ້ນຕອນ ຄື Hybrid ການຄົ້ນຫາ → Reranker → ສົ່ງ 5 ອັນດັບເທິງໃຫ້ LLM ເປັນໂຄງສ້າງມາດຕະຖານ. ການເພີ່ມຂຶ້ນຂອງ latency ຢູ່ທີ່ປະມານ 100〜300ms ຊຶ່ງຢູ່ໃນລະດັບທີ່ຍອມຮັບໄດ້ສຳລັບການໃຊ້ງານລະດັບ enterprise.

ເມື່ອເລີ່ມສົ່ງ chunk ຈຳນວນຫຼາຍໄປຫາ LLM ເພື່ອເພີ່ມຄວາມແມ່ນຍຳໃນການຄົ້ນຫາ, ການໃຊ້ token ຈະເພີ່ມຂຶ້ນຢ່າງຮວດໄວ. Context ທີ່ມີ 10 chunk × 500 token = 5,000 token ຈະເພີ່ມຕົ້ນທຶນຕໍ່ 1 request ຂຶ້ນໄປຫຼາຍ cent, ແລະ ສ່ວນຕ່າງດັ່ງກ່າວອາດສູງເຖິງຫຼາຍພັນໂດລາຕໍ່ເດືອນ.

ວິທີແກ້ໄຂ: ໃຊ້ reranker ເພື່ອຄັດເລືອກສະເພາະລາຍການທີ່ດີທີ່ສຸດ, ແລະ ຈຳກັດ chunk ທີ່ສົ່ງໄປຫາ LLM ໃຫ້ເຫຼືອພຽງ 3〜5 ລາຍການ. ນອກຈາກນີ້, ການດຳເນີນການສະຫຼຸບ chunk (Abstractive Summarization) ພາຍໃນ search pipeline ເພື່ອຫຼຸດຈຳນວນ token ກໍ່ເປັນວິທີທີ່ມີປະສິດທິພາບເຊັ່ນກັນ. ການເພີ່ມປະສິດທິພາບດ້ານຕົ້ນທຶນຈຳເປັນຕ້ອງດຳເນີນຄວບຄູ່ໄປພ້ອມກັບການປັບແຕ່ງຄວາມແມ່ນຍຳ.

ຂຶ້ນຢູ່ກັບ domain ແລະ ລັກສະນະຂອງຂໍ້ມູນ, ການປັບປຸງ Hit Rate@5 ໃນລະດັບ 15〜30% ເມື່ອທຽບກັບ Dense ຢ່າງດຽວໄດ້ຮັບການຢືນຢັນໃນເອກະສານວິຊາການຫຼາຍສະບັບ ແລະ ການວັດຜົນຕົວຈິງຂອງບໍລິສັດເຮົາ. ໂດຍສະເພາະ, ການປັບປຸງມີຂະໜາດໃຫຍ່ໃນ query ທີ່ປະກອບດ້ວຍຄຳນາມສະເພາະ ຫຼື ຄ່າຕົວເລກ. ຢ່າງໃດກໍຕາມ, ການປັບປຸງບໍ່ໄດ້ເກີດຂຶ້ນຢ່າງເທົ່າທຽມກັນໃນທຸກປະເພດ query, ແລະ ສຳລັບ query ທີ່ມີຄວາມໝາຍບໍ່ຊັດເຈນ, ອາດຈະໃຫ້ຜົນໃກ້ຄຽງກັບ Dense ຢ່າງດຽວ.

ກາຍເປັນດັ່ງນັ້ນ. RAG ແບບດັ້ງເດີມຕອບສະໜອງພາຍໃນ 1〜3 ວິນາທີ, ໃນຂະນະທີ່ Agentic RAG ອາດໃຊ້ເວລາ 5〜15 ວິນາທີ. ມາດຕະການຮັບມືທີ່ເປັນຈິງໄດ້ແກ່: ການໃຊ້ streaming response ເພື່ອຫຼຸດຜ່ອນເວລາລໍຖ້າທີ່ຮູ້ສຶກໄດ້, ການກຳນົດຂີດຈຳກັດສູງສຸດຂອງຈຳນວນຂັ້ນຕອນ, ແລະການປະເມີນຄວາມຊັບຊ້ອນຂອງ query ລ່ວງໜ້າເພື່ອ routing query ທີ່ງ່າຍໄປຫາ Naive RAG. ບໍ່ຈຳເປັນຕ້ອງໃຊ້ Agentic ກັບທຸກ query.

ມີປະໂຫຍດໃນທາງປະຕິບັດ, ແຕ່ຕ້ອງການການປັບປຸງເພີ່ມເຕີມ. ຈາກປະສົບການ RAG ພາສາລາວຂອງພວກເຮົາ, ສາມປະເດັນທີ່ສຳຄັນໂດຍສະເພາະແມ່ນ: ການຄັດເລືອກ Embedding model (ຕ້ອງໃຊ້ model ທີ່ຮອງຮັບຫຼາຍພາສາ), ການຮອງຮັບພາສາໃນການ chunking (ການກວດຈັບຂອບເຂດຂອງຄຳ), ແລະ ການຈັດຕຽມຂໍ້ມູນການປະເມີນຜົນ (annotation ໂດຍມະນຸດ). ກ່ອນທີ່ຈະຍອມແພ້ວ່າ "ຄວາມຖືກຕ້ອງບໍ່ດີ" ຈາກການໃຊ້ເຄື່ອງມືທົ່ວໄປໂດຍກົງ, ມັນຄຸ້ມຄ່າທີ່ຈະລອງໃຊ້ການປະມວນຜົນລ່ວງໜ້າທີ່ສະເພາະຕໍ່ພາສານັ້ນໆ. ສຳລັບລາຍລະອຽດເພີ່ມເຕີມ, ກະລຸນາເບິ່ງຄູ່ມືການສ້າງ AI Chatbot ພາສາລາວ.

ກວດສອບການຕັດສິນໃຈດ້ານການອອກແບບທີ່ຕ້ອງຢືນຢັນໃນການຍ້າຍຈາກ PoC ໄປສູ່ການໃຊ້ງານຈິງ.

• chunking ໄດ້ຮັບການປັບໃຫ້ເໝາະສົມກັບ domain ແລະ ພາສາຫຼືບໍ່? ມີການປະນີປະນອມດ້ວຍການແບ່ງຄວາມຍາວຄົງທີ່ຫຼືບໍ່?
• ໄດ້ນຳໃຊ້ Hybrid ການຄົ້ນຫາລະຫວ່າງ Dense search ແລະ BM25 ຫຼືບໍ່?
• ໄດ້ນຳໃຊ້ reranker ເພື່ອ re-scoring ຜົນການຄົ້ນຫາຫຼືບໍ່?
• ໄດ້ພິຈາລະນານຳໃຊ້ Agentic RAG ສຳລັບ query ທີ່ຊັບຊ້ອນຫຼືບໍ່?
• pipeline ການປະເມີນ Faithfulness / Context Relevance ໄດ້ຖືກລວມເຂົ້າໃນ CI/CD ຫຼືບໍ່?
• ໄດ້ຕັ້ງຄ່າການຕິດຕາມກວດສອບ ແລະ ການແຈ້ງເຕືອນສຳລັບຄ່າໃຊ້ຈ່າຍ (ການໃຊ້ token) ຫຼືບໍ່?

ການນຳ RAG ໄປໃຊ້ງານຈິງບໍ່ແມ່ນບັນຫາທີ່ແກ້ໄຂໄດ້ດ້ວຍເທັກໂນໂລຊີດຽວ. ການສະສົມການຕັດສິນໃຈດ້ານການອອກແບບທີ່ເໝາະສົມໃນແຕ່ລະ layer ຂອງ chunking, ການຄົ້ນຫາ, reranking, ການສ້າງ, ແລະ ການປະເມີນ ຈະຊ່ວຍຫຼຸດຊ່ອງຫວ່າງດ້ານຄວາມຖືກຕ້ອງລະຫວ່າງ PoC ແລະ ການໃຊ້ງານຈິງໄດ້. ວິທີການທີ່ໝັ້ນຄົງທີ່ສຸດຄືການເລີ່ມຕົ້ນດ້ວຍການນຳໃຊ້ Hybrid search ແລະ evaluation pipeline ກ່ອນ, ຈາກນັ້ນຈຶ່ງຂະຫຍາຍໄປສູ່ Agentic RAG ຕາມລະດັບຄວາມຊັບຊ້ອນຂອງ query.