ຖາມເປັນພາສາລາວ ແຕ່ໄດ້ຮັບຄຳຕອບເປັນພາສາອັງກິດ — ນີ້ຄືກຳແພງທຳອິດທີ່ພວກເຮົາພົບໃນຕອນທີ່ສ້າງ AI chatbot ໃນລາວເປັນຄັ້ງທຳອິດ. ສຳລັບ LLM ຊັ້ນນຳຂອງໂລກ, ພາສາລາວຖືວ່າເປັນ "ພາສາທີ່ແทບຈະບໍ່ຮູ້ຈັກ", ແລະ ການໃຊ້ວິທີການດຽວກັນກັບພາສາອັງກິດບໍ່ສາມາດບັນລຸລະດັບການໃຊ້ງານຕົວຈິງໄດ້. ໃນບົດຄວາມນີ້, ອີງຕາມສະຖາປັດຕະຍະກຳ RAG (Retrieval-Augmented Generation) + LLM ທີ່ພວກເຮົານຳໃຊ້ຕົວຈິງໃນໂຄງການສຳລັບລາວ, ພວກເຮົາຈະອະທິບາຍເປັນຂັ້ນຕອນ ຕັ້ງແຕ່ເກນການຄັດເລືອກ LLM ສຳລັບພາສາລາວ, ຂັ້ນຕອນການສ້າງ, ໄປຈົນເຖິງການອັດຕະໂນມັດການປະເມີນຄຸນນະພາບ. ນີ້ຄືຄູ່ມືປະຕິບັດຕົວຈິງສຳລັບຜູ້ທີ່ຕ້ອງການສ້າງ chatbot ທີ່ "ໃຊ້ງານໄດ້ຈິງ" ເປັນພາສາລາວ.

ຖ້າເປັນ chatbot ພາສາອັງກິດ, ພຽງແຕ່ເອີ້ນໃຊ້ API ແລະຂຽນ prompt ກໍສາມາດໃຊ້ງານໄດ້. ແຕ່ສຳລັບພາສາລາວ, ວິທີການດຽວກັນນີ້ບໍ່ສາມາດໃຊ້ໄດ້ຜົນ. ສາເຫດມາຈາກລັກສະນະສະເພາະຂອງພາສາເອງ ແລະ ຄວາມບໍ່ສົມດຸນຂອງຂໍ້ມູນຝຶກສອນຂອງ LLM.

ປະສິດທິພາບຫຼາຍພາສາຂອງ LLM ແມ່ນເກືອບສັດສ່ວນໂດຍກົງກັບປະລິມານຂໍ້ຄວາມທີ່ລວມຢູ່ໃນ corpus ການຝຶກອົບຮົມ. ເມື່ອເບິ່ງອັດຕາສ່ວນຂໍ້ມູນຂອງ Common Crawl, ພາສາອັງກິດຄິດເປັນປະມານ 46%, ໃນຂະນະທີ່ພາສາລາວມີໜ້ອຍກວ່າ 0.01%. ຄວາມແຕກຕ່າງກວ່າ 4,000 ເທົ່ານີ້ ສະທ້ອນອອກມາໂດຍກົງເປັນຄວາມແຕກຕ່າງດ້ານຄຸນນະພາບຂອງການຕອບສະໜອງ.

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

ພາສາລາວບໍ່ມີຊ່ອງຫວ່າງລະຫວ່າງຄຳ ແລະ ບໍ່ມີເຄື່ອງໝາຍສິ້ນສຸດປະໂຫຍກທີ່ຊັດເຈນ. ຖ້າເປັນພາສາອັງກິດ "I love cats" ໃຊ້ພຽງ 3 token, ແຕ່ "ຂ້ອຍຮັກແມວ" ໃນພາສາລາວອາດຖືກແບ່ງອອກເປັນຫຼາຍກວ່າ 10 token ດ້ວຍ tokenizer ແບບ BPE (Byte Pair Encoding).

ຜົນກະທົບຕໍ່ການນຳໃຊ້ຕົວຈິງມີ 2 ຢ່າງ.

• ການບີບອັດ context window: ເຖິງແມ່ນຂໍ້ມູນຈະມີປະລິມານເທົ່າກັນ ແຕ່ກໍໃຊ້ token ຫຼາຍກວ່າພາສາອັງກິດ 2〜3 ເທົ່າ. ຍິ່ງການສົນທະນາຍາວຂຶ້ນ, ບໍລິບົດໃນອະດີດກໍຈະຖືກດັນອອກໄປ ເຮັດໃຫ້ຄຸນນະພາບຂອງການຕອບສະໜອງຫຼຸດລົງ
• ຄວາມຍາກໃນການແບ່ງຂໍ້ຄວາມ: ໃນການແບ່ງເອກະສານ (chunking) ສຳລັບ RAG, "ການແບ່ງຜິດພາດ" ທີ່ຕັດກາງຄຳ ຫຼື ກາງປະໂຫຍກເກີດຂຶ້ນເລື້ອຍໆ. sentence splitter ທີ່ອອກແບບສຳລັບພາສາອັງກິດແทบຈະໃຊ້ບໍ່ໄດ້ກັບພາສາລາວ

ຫຼາຍຄົນມັກຄິດວ່າ ຖ້າປະສິດທິພາບຂອງ LLM ໃນພາສາລາວຕໍ່າ ກໍ່ພຽງແຕ່ "ແປຄຳຖາມເປັນພາສາອັງກິດກ່ອນ → ຄົ້ນຫາ ແລະ ວິເຄາະເປັນພາສາອັງກິດ → ແປຜົນລັບກັບເປັນພາສາລາວ" ກໍ່ພໍ——ບໍລິສັດຂອງພວກເຮົາເອງກໍ່ໄດ້ທົດລອງວິທີນີ້ໃນໄລຍະເລີ່ມຕົ້ນ.

ຜົນທີ່ໄດ້ຮັບນັ້ນຫຍໍ້ທໍ້ຫຼາຍ.

• ຄວາມຖືກຕ້ອງຂອງການແປ ລາວ → ອັງກິດ ຕໍ່າຕັ້ງແຕ່ຕົ້ນ: «ສິນເຊື່ອ» ຖືກແປຫຍໍ້ເປັນ "credit" ເຮັດໃຫ້ສູນເສຍບໍລິບົດທາງດ້ານການເງິນ. ຄຳສັບທາງກົດໝາຍ ແລະ ການບໍລິຫານຂອງລາວຫຼາຍຄຳບໍ່ສາມາດແປຕົງໆເປັນພາສາອັງກິດໄດ້
• ການແປສອງຊັ້ນເພີ່ມ latency 2〜3 ວິນາທີ: ຖ້າ chatbot ໃຊ້ເວລາຕອບໂຕ້ຫຼາຍກວ່າ 5 ວິນາທີ ອັດຕາການລາອອກຂອງຜູ້ໃຊ້ຈະເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ
• ຊື່ສະຖານທີ່ ແລະ ຊື່ສະຖາບັນພັງໃນການແປ: ຊື່ສະຖານທີ່ໃນລາວ (ເຊັ່ນ: ຊື່ບ້ານໃນແຂວງຫຼວງພະບາງ) ແລະ ຊື່ສະຖາບັນຕ່າງໆ ຖືກບິດເບືອນໄປໃນລະຫວ່າງການແປໄປ-ມາ ຈົນບໍ່ສາມາດກັບຄືນສູ່ຮູບເດີມໄດ້

ຈາກປະສົບການນີ້ ບໍລິສັດຂອງພວກເຮົາຈຶ່ງປ່ຽນທິດທາງມາໃຊ້ວິທີການປະມວນຜົນຂໍ້ຄວາມພາສາລາວໃນຮູບແບບພາສາລາວໂດຍກົງ——ນັ້ນກໍ່ຄືການເສີມຄວາມຮູ້ດ້ວຍ RAG.

ຄຸນນະພາບຂອງ chatbot ແມ່ນຖືກກຳນົດໂດຍການເລືອກ LLM ເປັນສ່ວນໃຫຍ່. ແຕ່ວ່າແທບຈະບໍ່ມີ benchmark ທີ່ອ້າງວ່າ "ຮອງຮັບພາສາລາວ" ຢູ່ເລີຍ. ບໍ່ມີທາງເລືອກອື່ນນອກຈາກຕ້ອງກວດສອບດ້ວຍຕົນເອງ.

ບໍລິສັດຂອງພວກເຮົາໄດ້ປະເມີນປະສິດທິພາບ LLM ພາສາລາວໃນ 4 ແກນດັ່ງຕໍ່ໄປນີ້.

1. ຄວາມເປັນທຳມະຊາດຂອງການສົນທະນາປະຈຳວັນ: ການຖາມ-ຕອບພື້ນຖານຖືກຕ້ອງຕາມໄວຍາກອນ ແລະ ເປັນທຳມະຊາດຫຼືບໍ່
2. ຄວາມຖືກຕ້ອງຂອງຄຳສັບວິຊາສະເພາະ: ສາມາດຈັດການຄຳສັບພາສາລາວໃນດ້ານການເງິນ, ການບໍລິຫານ ແລະ IT ໄດ້ຢ່າງຖືກຕ້ອງຫຼືບໍ່
3. ການປະຕິບັດຕາມຄຳສັ່ງ: ສາມາດຮັກສາຂໍ້ຈຳກັດ ເຊັ່ນ: "ຕອບເປັນພາສາລາວ" ແລະ "ຕອບໂດຍອ້າງອີງສະເພາະຂໍ້ມູນທີ່ອ້າງອີງເທົ່ານັ້ນ" ໄດ້ຫຼືບໍ່
4. ປະສິດທິພາບດ້ານຕົ້ນທຶນ: ພາສາລາວເກີດການຂະຫຍາຍ token ຈຶ່ງມີຄ່າໃຊ້ຈ່າຍສູງກວ່າພາສາອັງກິດ 2〜3 ເທົ່າ. ຕົ້ນທຶນທີ່ແທ້ຈິງໂດຍຄຳນຶງເຖິງປັດໃຈດັ່ງກ່າວ

ສຳລັບການກວດສອບ, ພວກເຮົາໄດ້ກຽມ FAQ ວຽກງານພາສາລາວ (50 ຄຳຖາມ) ແລະ ໃຫ້ແຕ່ລະ model ຕອບພາຍໃຕ້ເງື່ອນໄຂດຽວກັນ.

ສະຫຼຸບຜົນການທົດສອບຂອງໂມເດລຫຼັກ ณ ປີ 2025.

※ ລາຄາອາດປ່ຽນແປງຕາມໄລຍະເວລາ. ພາສາລາວມີການຂະຫຍາຍ token ເຮັດໃຫ້ຕົ້ນທຶນທີ່ແທ້ຈິງສູງກວ່າພາສາອັງກິດ 2〜3 ເທົ່າ.

ສິ່ງທີ່ທຸກໂມເດລມີຮ່ວມກັນຄື ການໃຊ້ພາສາລາວຢ່າງດຽວບໍ່ສາມາດຕອບຄຳຖາມດ້ານວິຊາຊີບໄດ້ຢ່າງຖືກຕ້ອງ. ບໍ່ວ່າຈະເລືອກໃຊ້ໂມເດລໃດ ການເສີມຄວາມຮູ້ດ້ວຍ RAG ກໍຍັງເປັນສິ່ງຈຳເປັນສະເໝີ.

ໃນໂຄງສ້າງພື້ນຖານ chatbot ຂອງບໍລິສັດເຮົາ, ເຮົາໄດ້ນຳໃຊ້ Claude Sonnet ຜ່ານ AWS Bedrock. ມີ 3 ເຫດຜົນຫຼັກໃນການຕັດສິນໃຈຄັ້ງນີ້.

1. ຄວາມໝັ້ນຄົງໃນການປະຕິບັດຕາມຄຳສັ່ງ. ໃນ RAG, ຜົນການຄົ້ນຫາຈະຖືກໃສ່ເຂົ້າໄປໃນ system prompt. ໃນກໍລະນີນີ້, ຖ້າ LLM ບໍ່ປະຕິບັດຕາມຄຳສັ່ງທີ່ວ່າ "ໃຫ້ຕອບໂດຍອ້າງອີງສະເພາະ context ທີ່ສະໜອງໃຫ້ເທົ່ານັ້ນ", ກໍ່ຈະເກີດ hallucination (ການຕອບສະໜອງທີ່ບໍ່ຕົງກັບຄວາມເປັນຈິງ) ຂຶ້ນ. Claude ມີຄວາມສາມາດໃນການປະຕິບັດຕາມຂໍ້ຈຳກັດນີ້ສູງທີ່ສຸດ, ແລະ ມີການເບິ່ງຂ້າມໜ້ອຍທີ່ສຸດ ແມ່ນແຕ່ໃນ context ພາສາລາວ.

2. ການລວມເຂົ້າກັບ AWS ecosystem. ການໃຊ້ Bedrock ເຮັດໃຫ້ສາມາດຄວບຄຸມການເຂົ້າເຖິງດ້ວຍ IAM, ຕິດຕາມ log ດ້ວຍ CloudWatch, ແລະ ເຊື່ອມຕໍ່ແບບ private ຈາກພາຍໃນ VPC ໄດ້. ລູກຄ້າຂອງບໍລິສັດເຮົາສ່ວນໃຫຍ່ເປັນສະຖາບັນການເງິນ, ດັ່ງນັ້ນ ການທີ່ຂໍ້ມູນບໍ່ອອກໄປນອກ region ຈຶ່ງເປັນຂໍ້ກຳນົດທີ່ຂາດບໍ່ໄດ້.

3. ຄວາມຍືດຫຍຸ່ນໃນການສັບປ່ຽນ multi-model. Bedrock ສາມາດເອີ້ນໃຊ້ Mistral, Llama, ແລະ Amazon Nova ນອກຈາກ Claude ໄດ້ດ້ວຍ API ດຽວກັນ. ເມື່ອໃດທີ່ model ທີ່ເຂັ້ມແຂງດ້ານພາສາລາວຖືກພັດທະນາຂຶ້ນໃນອະນາຄົດ, ກໍ່ສາມາດສັບປ່ຽນໄດ້ໂດຍບໍ່ຕ້ອງປ່ຽນແປງ code.

ດັ່ງທີ່ໄດ້ຢືນຢັນໃນບົດກ່ອນໜ້າ, LLM ທຸກຕົວບໍ່ມີຄວາມຮູ້ຊ່ຽວຊານໃນພາສາລາວໂດຍລຳພັງ. ການລວມເຂົ້າກັບ RAG ຊ່ວຍເສີມຂໍ້ຈຳກັດພື້ນຖານນີ້ໄດ້.

RAG（Retrieval-Augmented Generation）ແມ່ນວິທີການທີ່ໃຊ້ການຄົ້ນຫາແບບ vector ເພື່ອດຶງເອົາເອກະສານທີ່ກ່ຽວຂ້ອງກັບຄຳຖາມຂອງຜູ້ໃຊ້ງານ, ຈາກນັ້ນນຳເນື້ອຫານັ້ນໄປໃສ່ໃນ prompt ຂອງ LLM ເພື່ອສ້າງຄຳຕອບ.

ຄວາມແຕກຕ່າງລະຫວ່າງ LLM ແບບດຽວ ແລະ RAG ນັ້ນເດັ່ນຊັດເປັນພິເສດໃນພາສາລາວ.

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

Pipeline ທີ່ບໍລິສັດຂອງເຮົານຳໃຊ້ມີໂຄງສ້າງດັ່ງຕໍ່ໄປນີ້.

ຄຳຖາມຂອງຜູ້ໃຊ້ (ພາສາລາວ)
  ↓
[Embedding] ແປງຂໍ້ຄວາມໃຫ້ເປັນ Vector
  ↓
[Vector Search] ດຶງ Chunk ທີ່ຄ້າຍຄືກັນ 50 ລາຍການດ້ວຍ Supabase pgvector
  ↓
[Reranking] ກັ່ນຕອງດ້ວຍຄະແນນຄວາມຄ້າຍຄືກັນ → ຄັດເລືອກເຫຼືອ 5 ລາຍການເທິງສຸດ
  ↓
[LLM] ສົ່ງ Context + ຄຳຖາມໄປຫາ AWS Bedrock Claude
  ↓
[Streaming] ແຈກຢາຍການຕອບສະໜອງເປັນຂັ້ນຕອນດ້ວຍ SSE
  ↓
[Auto Scoring] ວັດແທກຄະແນນຄຸນນະພາບອັດຕະໂນມັດດ້ວຍ Mastra Evaluations

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

ການຝັງ (Embedding) (ການແປງຂໍ້ຄວາມເປັນ vector) ແມ່ນອົງປະກອບທີ່ສຳຄັນທີ່ສຸດທີ່ກຳນົດຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາຂອງ RAG.

ຖ້າໃຊ້ embedding model ທີ່ຮອງຮັບຫຼາຍພາສາ, ຂໍ້ຄວາມພາສາລາວກໍ່ສາມາດແປງເປັນ vector ໄດ້. ຖ້າເປັນ model ທີ່ຮອງຮັບຫຼາຍກວ່າ 100 ພາສາ, ກໍ່ຈະຮອງຮັບພາສາລາວດ້ວຍ.

ຢ່າງໃດກໍ່ຕາມ, ກໍ່ຍັງມີຂໍ້ຈຳກັດ. ເນື່ອງຈາກພາສາລາວມີຂໍ້ມູນສຳລັບການຝຶກສອນໜ້ອຍ, ໄລຍະຫ່າງ vector ຂອງຄຳສັບທີ່ມີຄວາມໝາຍຄ້າຍຄືກັນ ຫຼື ການໃຊ້ຄຳເວົ້າທີ່ຕ່າງກັນຈຶ່ງບໍ່ຖືກຕ້ອງເທົ່າກັບພາສາອັງກິດ. ໂດຍສະເພາະ, ອາດມີກໍລະນີທີ່ «ສິນເຊື່ອ» (ການໃຫ້ກູ້ຢືມໂດຍອີງໃສ່ຄວາມໜ້າເຊື່ອຖື) ແລະ «ເງິນກູ້» (ເງິນກູ້) ບໍ່ຖືກຈັດວາງໃຫ້ຢູ່ໃກ້ກັນໃນຖານະທີ່ເປັນແນວຄິດດຽວກັນ. ບັນຫານີ້ໄດ້ຮັບການບັນເທົາດ້ວຍການອອກແບບ pipeline ທີ່ດຶງຜົນການຄົ້ນຫາເບື້ອງຕົ້ນໃຫ້ກວ້າງ (50 ລາຍການ) ແລ້ວຈຶ່ງຄັດກອງດ້ວຍ reranking (5 ລາຍການ).

ຈາກນີ້ໄປຈະອະທິບາຍຂັ້ນຕອນການສ້າງຢ່າງລະອຽດ. ເຕັກໂນໂລຊີສະແຕັກທີ່ໃຊ້ເປັນພື້ນຖານຄື TypeScript + Next.js + Supabase + Mastra, ແຕ່ແນວຄິດດ້ານສະຖາປັດຕະຍະກຳສາມາດນຳໄປປະຍຸກໃຊ້ກັບສະແຕັກອື່ນໆໄດ້ເຊັ່ນກັນ.

ກະກຽມຄວາມຮູ້ (knowledge) ທີ່ chatbot ຈະອ້າງອີງ (ຄູ່ມືການເຮັດວຽກ, FAQ, ເອກະສານຂໍ້ກຳນົດ ແລະ ອື່ນໆ) ແລ້ວແບ່ງອອກເປັນໜ່ວຍທີ່ສາມາດຄົ້ນຫາໄດ້.

ການແບ່ງຂໍ້ຄວາມພາສາລາວແມ່ນສິ່ງທີ່ຍາກທີ່ສຸດ. ເນື່ອງຈາກຄຳສັບບໍ່ໄດ້ຖືກຄັ່ນດ້ວຍຊ່ອງຫວ່າງ ແລະ ເກືອບບໍ່ມີການໃຊ້ເຄື່ອງໝາຍຈົບປະໂຫຍກ (ທຽບເທົ່າກັບ「。」), ສະນັ້ນ sentence splitter ທີ່ອອກແບບສຳລັບພາສາອັງກິດຈຶ່ງໃຊ້ງານບໍ່ໄດ້. ທາງບໍລິສັດຂອງພວກເຮົາໃຊ້ກົນລະຍຸດການແບ່ງຂໍ້ຄວາມຂອງ Mastra RAG ໂດຍແຍກຕາມປະເພດດັ່ງນີ້.

ການຕັ້ງຄ່າທີ່ແນະນຳ: ສຳລັບເອກະສານພາສາລາວ ໃຫ້ໃຊ້ recursive (chunk size 512 tokens, overlap 50 tokens) ເປັນພື້ນຖານ. ເຫດຜົນທີ່ຕ້ອງໃສ່ overlap ແມ່ນເພື່ອໃຫ້ chunk ກ່ອນໜ້າ ແລະ ຖັດໄປສາມາດເສີມເນື້ອຫາກັນໄດ້ ໃນກໍລະນີທີ່ຈຸດແບ່ງຕົກຢູ່ກາງບໍລິບົດຂອງພາສາລາວ.

ທຳການ vectorize ຊັ້ນຂໍ້ຄວາມທີ່ຖືກແບ່ງແຍກ ແລະ ເກັບຮັກສາໄວ້ໃນສະຖານະທີ່ສາມາດຄົ້ນຫາໄດ້. ທາງບໍລິສັດໃຊ້ pgvector extension ຂອງ Supabase.

ມີ 3 ເຫດຜົນທີ່ເລືອກໃຊ້ Supabase pgvector.

• ການແຍກ tenant: ດ້ວຍ RLS (Row Level Security) ຂອງ PostgreSQL, ສາມາດແຍກ knowledge ຕາມແຕ່ລະ client ໄດ້
• ບໍ່ຕ້ອງເສຍຄ່າໃຊ້ຈ່າຍເພີ່ມ: ພຽງແຕ່ເພີ່ມ extension ເຂົ້າໃນ Supabase project ທີ່ມີຢູ່ແລ້ວ. ບໍ່ຈຳເປັນຕ້ອງໃຊ້ບໍລິການພາຍນອກເຊັ່ນ Pinecone ເປັນຕົ້ນ
• ການລວມເຂົ້າກັບ SQL: ສາມາດລວມການຄົ້ນຫາ vector ແລະ filter ທຳມະດາ (ລະຫັດພາສາ, ໝວດໝູ່ ແລະ ອື່ນໆ) ໄດ້ໃນ 1 query ດຽວ

ຈຸດສຳຄັນຂອງການອອກແບບຕາຕະລາງຄື ການລວມລະຫັດພາສາໄວ້ໃນ metadata. ໃນກໍລະນີທີ່ຄົ້ນຫາສະເພາະ knowledge ພາສາລາວ ໃຫ້ filter ດ້ວຍ language = 'lo', ແລະ ໃນກໍລະນີທີ່ຄົ້ນຫາຂ້າມທຸກພາສາ ໃຫ້ຖອດ filter ອອກ——ການສະຫຼັບນີ້ສາມາດເຮັດໄດ້ດ້ວຍ WHERE clause ຂອງ SQL ພຽງ 1 ແຖວ.

ການຄົ້ນຫາດ້ວຍ vector ບໍ່ພຽງພໍທີ່ຈະ "ສົ່ງຄືນຕາມລຳດັບຄວາມຄ້າຍຄືກັນ" ເທົ່ານັ້ນ. ໃນພາສາລາວ, ຄວາມຖືກຕ້ອງຂອງ embedding ບໍ່ສູງເທົ່າກັບພາສາອັງກິດ, ສະນັ້ນ chunk ທີ່ມີຄວາມກ່ຽວຂ້ອງຕ່ຳຈຶ່ງສາມາດຊຶມເຂົ້າມາຢູ່ໃນອັນດັບຕົ້ນໄດ້ງ່າຍ.

pipeline ຂອງພວກເຮົາກອງຂໍ້ມູນດ້ວຍ 2 ຂັ້ນຕອນ.

1. ການຄົ້ນຫາເບື້ອງຕົ້ນ: ດຶງຂໍ້ມູນ 50 ລາຍການທຳອິດຢ່າງກວ້າງຂວາງດ້ວຍ pgvector
2. ການກອງດ້ວຍຄ່າຄວາມຄ້າຍຄືກັນ + reranking: ລຶບ noise ດ້ວຍຄະແນນ cosine similarity ແລ້ວສົ່ງ 5 ລາຍການທີ່ຈັດລຳດັບໃໝ່ຕາມຄວາມກ່ຽວຂ້ອງໄປຫາ LLM

ເປັນຫຍັງຈຶ່ງດຶງເຖິງ 50 ລາຍການ? ໃນ embedding ພາສາລາວ, chunk ທີ່ຄວນຈະຢູ່ອັນດັບ 1 ອາດຈະຖືກຝັງຢູ່ອັນດັບທີ 20 ໄດ້. ສາເຫດມາຈາກບັນຫາຄຳສັບພ້ອງຄວາມໝາຍ ເຊັ່ນ: ເມື່ອຄົ້ນຫາດ້ວຍ "ສິນເຊື່ອ" ແຕ່ chunk ທີ່ມີ "ເງິນກູ້" ບໍ່ຂຶ້ນມາຢູ່ອັນດັບຕົ້ນ. ການດຶງຂໍ້ມູນໃຫ້ກວ້າງກ່ອນ ແລ້ວຈຶ່ງຈັດລຳດັບໃໝ່ດ້ວຍ reranking ຈະຊ່ວຍຫຼຸດການຕົກຫຼົ່ນຂອງຜົນການຄົ້ນຫາໄດ້ດີກວ່າ.

ສົ່ງຜົນການຄົ້ນຫາໄປໃຫ້ LLM ເພື່ອສ້າງການຕອບສະໜອງເປັນພາສາລາວ. ໂດຍຄຳນຶງເຖິງປະສົບການຂອງຜູ້ໃຊ້, ຈຶ່ງນຳໃຊ້ການສົ່ງຂໍ້ມູນແບບ Streaming ຜ່ານ SSE（Server-Sent Events）.

ດ້ວຍການ Streaming, ສາມາດຫຼຸດ TTFT（ເວລາທີ່ໃຊ້ຈົນກວ່າ Token ທຳອິດຈະສະແດງຜົນ）ລົງເຫຼືອປະມານ 0.8 ວິນາທີ. ເມື່ອ Token ຂາເຂົ້າເພີ່ມຂຶ້ນຈາກການໃສ່ Context ຂອງ RAG, ວິທີທີ່ລໍຖ້າສ້າງຂໍ້ຄວາມທັງໝົດກ່ອນຈະໃຊ້ເວລາ 5〜10 ວິນາທີ, ແຕ່ດ້ວຍ Streaming ຕົວອັກສອນທຳອິດຈະເລີ່ມສະແດງຜົນພາຍໃນ 1 ວິນາທີ.

ການອອກແບບ System Prompt ສະເພາະສຳລັບພາສາລາວ:

ສຳລັບ Chatbot ພາສາລາວ, ຈຳເປັນຕ້ອງລະບຸຄຳແນະນຳຕໍ່ໄປນີ້ໃນ System Prompt ຢ່າງຊັດເຈນ.

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

ຊາດບອດບໍ່ພຽງພໍທີ່ຈະ "ເຮັດວຽກໄດ້" ເທົ່ານັ້ນ. ຄຸນນະພາບຂອງການຕອບສະໜອງມີການປ່ຽນແປງຢູ່ຕະຫຼອດເວລາຈາກການເພີ່ມ knowledge ແລະ ການອັບເດດ LLM.

ບໍລິສັດຂອງພວກເຮົາໃຊ້ Mastra Evaluations ເພື່ອວັດແທກ 3 ຕົວຊີ້ວັດຕໍ່ໄປນີ້ໂດຍອັດຕະໂນມັດໃນເວລາຈິງ.

ສຳລັບການປະເມີນຜົນ ຈະໃຊ້ LLM ທີ່ແຕກຕ່າງຈາກ model ຫຼັກທີ່ໃຊ້ສ້າງການຕອບສະໜອງ. ນີ້ເພື່ອຫຼີກລ່ຽງ bias ຂອງການໃຫ້ຄະແນນຕົນເອງ ທີ່ວ່າ "ປະເມີນຄຳຕອບທີ່ຕົນເອງສ້າງຂຶ້ນດ້ວຍຕົນເອງ".

ພວກເຮົາຂໍແບ່ງປັນຮູບແບບຄວາມລົ້ມເຫຼວທີ່ໄດ້ປະສົບໃນໂຄງການສຳລັບລາວ. ທັງໝົດນີ້ແມ່ນສິ່ງທີ່ສາມາດຫຼີກລ່ຽງໄດ້ຫາກຮູ້ລ່ວງໜ້າ.

ສິ່ງທີ່ເກີດຂຶ້ນ: ເມື່ອແບ່ງຄູ່ມືການປະຕິບັດງານພາສາລາວດ້ວຍຍຸດທະສາດ sentence ພົບວ່າເອກະສານທັງໝົດກາຍເປັນ 1 chunk ດຽວ ຫຼື ກົງກັນຂ້າມກໍຖືກຕັດແຍກເປັນໜ່ວຍລະດັບ byte ຊຶ່ງເປັນຜົນລັບທີ່ສຸດໂຕ່ງທັງສອງດ້ານ. ສາເຫດແມ່ນງ່າຍດາຍ ຄື ພາສາລາວແทบບໍ່ມີການໃຊ້ເຄື່ອງໝາຍທ້າຍປະໂຫຍກທີ່ທຽບເທົ່າກັບ「。」. ເນື່ອງຈາກ sentence splitter ເຮັດວຽກໂດຍໃຊ້ເຄື່ອງໝາຍທ້າຍປະໂຫຍກເປັນຈຸດຕັດ ຈຶ່ງບໍ່ສາມາດຊອກຫາຈຸດຕັດໄດ້ເລີຍໃນຂໍ້ຄວາມພາສາລາວ.

ວິທີແກ້ໄຂ: ປ່ຽນໄປໃຊ້ຍຸດທະສາດ recursive ແທນ. ດຳເນີນການ chunking ໂດຍອີງໃສ່ການຂຶ້ນບັນທັດໃໝ່ແລະການຕັດວັກ ໂດຍຕັ້ງຄ່າ chunk size ທີ່ 512 token ແລະ overlap ທີ່ 50 token. ເນື່ອງຈາກເອກະສານພາສາລາວສ່ວນໃຫຍ່ມີການຂຶ້ນບັນທັດໃໝ່ໃນແຕ່ລະວັກ ວິທີນີ້ຈຶ່ງສາມາດແບ່ງໄດ້ຢ່າງໃຊ້ງານໄດ້ຈິງ.

ສິ່ງທີ່ເກີດຂຶ້ນ: ເນື່ອງຈາກ knowledge base ມີເອກະສານທັງພາສາອັງກິດ ແລະ ພາສາຍີ່ປຸ່ນລວມຢູ່ດ້ວຍ, ຈຶ່ງເກີດກໍລະນີທີ່ chunk ພາສາອັງກິດຖືກດຶງຂຶ້ນມາຕອບຄຳຖາມພາສາລາວ ແລ້ວ LLM ກໍຕອບກັບເປັນພາສາອັງກິດໂດຍກົງເລື້ອຍໆ. ສາເຫດມາຈາກການທີ່ system prompt ບໍ່ໄດ້ລະບຸຄຳສັ່ງກ່ຽວກັບພາສາທີ່ໃຊ້ໃນການຕອບ.

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

ວິທີແກ້ໄຂ: ໄດ້ດຳເນີນມາດຕະການ 2 ຢ່າງພ້ອມກັນ. (1) ເພີ່ມຂໍ້ຄວາມລະບຸໃນ system prompt ຢ່າງຊັດເຈນວ່າ "ຕ້ອງຕອບດ້ວຍພາສາດຽວກັນກັບພາສາທີ່ຜູ້ໃຊ້ໃຊ້ສະເໝີ". (2) ເພີ່ມ language code ໃສ່ metadata ຂອງ knowledge base ແລ້ວ implement filter ທີ່ຈະດຶງ chunk ພາສາລາວໃຫ້ມີຄວາມສຳຄັນກ່ອນໃນການຄົ້ນຫາເມື່ອຄຳຖາມເປັນພາສາລາວ.

ສິ່ງທີ່ເກີດຂຶ້ນ: ການເກັບຮັກສາ context ຂອງການສົນທະນາພາສາລາວແບບ multi-turn ໄວ້ 20 ຂໍ້ຄວາມ ສົ່ງຜົນໃຫ້ input token ເກີນ 15,000 ແລະ ຄຸນນະພາບຂອງການຕອບສະໜອງຫຼຸດລົງຢ່າງເຫັນໄດ້ຊັດ. ພາສາລາວໃຊ້ token ຫຼາຍກວ່າພາສາອັງກິດ 2〜3 ເທົ່າ. 20 ຂໍ້ຄວາມໃນພາສາອັງກິດອາດຈະບໍ່ມີບັນຫາ, ແຕ່ໃນພາສາລາວຈະກິນພື້ນທີ່ສ່ວນໃຫຍ່ຂອງ context window ໄປເກືອບໝົດ.

ສົ່ງຜົນໃຫ້ບໍ່ມີພື້ນທີ່ພຽງພໍສຳລັບການໃສ່ RAG context (5 chunks, ປະມານ 3,000〜5,000 token), ຜົນການຄົ້ນຫາຖືກຕັດທອນອອກ ແລະ ຄຳຕອບທີ່ "ບໍ່ໄດ້ເບິ່ງ knowledge" ກໍເພີ່ມຂຶ້ນ.

ວິທີແກ້ໄຂ: ປ່ຽນການຄວບຄຸມການເກັບຮັກສາປະຫວັດການສົນທະນາຈາກການນັບຈຳນວນຂໍ້ຄວາມ ມາເປັນການຄວບຄຸມດ້ວຍຂີດຈຳກັດຈຳນວນ token. ທາງບໍລິສັດຂອງເຮົາຈຳກັດປະຫວັດການສົນທະນາລ່າສຸດໄວ້ທີ່ສູງສຸດ 8,000 token ເພື່ອຮັບປະກັນວ່າມີພື້ນທີ່ພຽງພໍສຳລັບ RAG context. ສຳລັບພາສາລາວ, ນີ້ເທົ່າກັບປະມານ 8〜10 ຂໍ້ຄວາມໃນທາງປະຕິບັດ.

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

ບໍລິສັດຂອງພວກເຮົາໃຊ້ຟີເຈີ Live Evaluations ຂອງ Mastra ເພື່ອສະຄໍຣ໌ການຕອບສະໜອງຂອງ chat ໃນສະພາບແວດລ້ອມການຜະລິດແບບ real-time. ເນື່ອງຈາກການສະຄໍຣ໌ດຳເນີນການແບບ asynchronous ກັບການສ້າງການຕອບສະໜອງ, ຈຶ່ງບໍ່ສົ່ງຜົນກະທົບຕໍ່ຄວາມໄວທີ່ຜູ້ໃຊ້ຮູ້ສຶກໄດ້.

ຕົວຊີ້ວັດ 3 ລາຍການທີ່ວັດແທກໄດ້ (Answer Relevancy / Faithfulness / Retrieval Precision) ຈະຖືກບັນທຶກໄວ້ໃນ database ແລະ ສາມາດຕິດຕາມການປ່ຽນແປງຕາມລຳດັບເວລາໄດ້. ການຫຼຸດລົງຢ່າງຮວດໄວຂອງຄະແນນເປັນສັນຍານທີ່ສະແດງເຖິງການຂາດຫາຍຂອງ knowledge ຫຼື ການປ່ຽນແປງພຶດຕິກຳຂອງ model.

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

ເຖິງແມ່ນວ່າ production ຈະຢູ່ທີ່ 10% ແຕ່ຖ້າມີ 1,000 request ຕໍ່ວັນ ກໍ່ຈະສະສົມຂໍ້ມູນຄະແນນໄດ້ 100 ລາຍການ/ວັນ. ຫາກກວດສອບຄ່າສະເລ່ຍເປັນລາຍອາທິດ ກໍ່ສາມາດເຂົ້າໃຈທ່າອ່ຽງຂອງຄຸນນະພາບໄດ້ຢ່າງພຽງພໍ.

ວິທີການປັບປຸງແຕກຕ່າງກັນໄປຕາມແຕ່ລະຕົວຊີ້ວັດ.

Retrieval Precision ຕ່ຳ (< 0.6): ການຄົ້ນຫາກຳລັງສົ່ງຄືນ chunk ທີ່ບໍ່ກ່ຽວຂ້ອງ. ໃຫ້ພິຈາລະນາປັບຂະໜາດ chunk (ຫຼຸດຈາກ 512 → 256 token), ເພີ່ມຄວາມຮູ້ພາສາລາວ, ແລະທົບທວນ metadata filter. ໃນກໍລະນີຂອງພາສາລາວ, ການຫຼຸດຂະໜາດ chunk ລົງມັກຈະຊ່ວຍປັບປຸງໄດ້.

Faithfulness ຕ່ຳ (< 0.8): LLM ກຳລັງເຕີມຂໍ້ມູນທີ່ບໍ່ມີຢູ່ໃນຜົນການຄົ້ນຫາ. ແກ້ໄຂໂດຍການເພີ່ມຂໍ້ຈຳກັດໃນ system prompt ຫຼືຫຼຸດ temperature ລົງ (0.3 → 0.1). ຄວນສັງເກດວ່າພາສາລາວມີຂໍ້ມູນການຝຶກສອນ LLM ໜ້ອຍກວ່າ, ຈຶ່ງເກີດ hallucination ໄດ້ງ່າຍກວ່າພາສາອັງກິດ.

Answer Relevancy ຕ່ຳ (< 0.7): ຄຳຕອບບໍ່ສອດຄ່ອງກັບຄຳຖາມຂອງຜູ້ໃຊ້. ໃຫ້ກວດສອບ Retrieval Precision ກ່ອນ. ຖ້າບໍ່ມີບັນຫາໃນຝ່າຍການຄົ້ນຫາ, ໃຫ້ດຳເນີນການປັບປຸງ prompt (ກຳນົດຮູບແບບຄຳຕອບ, ຄຳແນະນຳໃນການຕີຄວາມຄຳຖາມໃໝ່).

ແທ້ຈິງແລ້ວ, ຍິ່ງມີ knowledge ໜ້ອຍເທົ່າໃດ, ກໍຍິ່ງຮູ້ສຶກເຖິງຜົນໄດ້ຮັບໄດ້ງ່າຍເທົ່ານັ້ນ. ເນື່ອງຈາກ LLM ໂດຍລຳພັງແທບຈະບໍ່ມີຄວາມຮູ້ສະເພາະດ້ານພາສາລາວ, ພຽງແຕ່ການເພີ່ມ knowledge ຈຳນວນ 50 ລາຍການ FAQ ກໍສາມາດປ່ຽນແປງຄວາມຖືກຕ້ອງຂອງຄຳຕອບໄດ້ຢ່າງໜ້າຕື່ນຕາຕື່ນໃຈ. ຜົນຂອງການ "ເພີ່ມ 50 ລາຍການໃສ່ໃນສະຖານະທີ່ເປັນສູນ" ນັ້ນໃຫຍ່ກວ່າຜົນຂອງການ "ເພີ່ມ 50 ລາຍການໃສ່ໃນສະຖານະທີ່ມີ 1,000 ລາຍການຢູ່ແລ້ວ" ຫຼາຍ.

ສາມາດຈັດການໄດ້. ເກັບຮັກສາເອກະສານຂອງແຕ່ລະພາສາໄວ້ໃນ knowledge base ແລະ ກັ່ນຕອງດ້ວຍລະຫັດພາສາໃນ metadata. ລະບົບຂອງພວກເຮົາປະມວນຜົນ 4 ພາສາ ໄດ້ແກ່ ພາສາຍີ່ປຸ່ນ, ພາສາອັງກິດ, ພາສາໄທ ແລະ ພາສາລາວ ໃນ RAG pipeline ດຽວ. ເນື່ອງຈາກພາສາໄທ ແລະ ພາສາລາວ ມີລະບົບຕົວອັກສອນ ແລະ ໄວຍາກອນທີ່ໃກ້ຄຽງກັນ, ຈຶ່ງສາມາດຮອງຮັບໄດ້ດ້ວຍ chunking strategy ແລະ embedding model ດຽວກັນ.

ຖ້າເປັນລະດັບ FAQ (ຄວາມຮູ້ 100 ລາຍການລົງໄປ) ສາມາດສ້າງໄດ້ພາຍໃນ 2〜4 ອາທິດ. ຄ່າໃຊ້ຈ່າຍ Infrastructure ແລະ API ລາຍເດືອນຢູ່ທີ່ປະມານ $200〜500. ສຳລັບ Chatbot ແບບເຕັມຮູບແບບທີ່ລວມການເຊື່ອມຕໍ່ກັບລະບົບງານ ໃຊ້ເວລາ 2〜3 ເດືອນ ແລະ ຄ່າໃຊ້ຈ່າຍລາຍເດືອນຢູ່ທີ່ $500〜2,000 ເປັນເກນ. ຄ່າໃຊ້ຈ່າຍສ່ວນໃຫຍ່ແມ່ນຄ່າ API ຂອງ LLM ໂດຍຕ້ອງລວມເອົາໃນງົບປະມານດ້ວຍວ່າ ພາສາລາວມີການຂະຫຍາຍ Token ເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍສູງກວ່າພາສາອັງກິດ 2〜3 ເທົ່າ.

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

ທົບທວນຄືນ 5 ຂັ້ນຕອນທີ່ໄດ້ອະທິບາຍໄວ້ໃນບົດຄວາມນີ້.

1. ການແບ່ງຂໍ້ຄວາມທີ່ເໝາະສົມກັບລັກສະນະຂອງພາສາລາວ (ກົນລະຍຸດ recursive + overlap)
2. ການສ້າງ vector DB ດ້ວຍ Supabase pgvector (metadata ທີ່ມີລະຫັດພາສາ)
3. pipeline ການຄົ້ນຫາ: ດຶງ 50 ລາຍການ → reranking → 5 ລາຍການ
4. ການຕອບສະໜອງແບບ streaming ດ້ວຍ Bedrock Claude + prompt ຄວບຄຸມພາສາ
5. ການຕິດຕາມອັດຕະໂນມັດ 3 ຕົວຊີ້ວັດດ້ວຍ Mastra Evaluations

ມາດຕະການຄວາມປອດໄພ AI ສຳລັບ chatbot ໄດ້ອະທິບາຍໄວ້ຢ່າງລະອຽດໃນ "ລາຍການກວດສອບມາດຕະການຄວາມປອດໄພ AI ສຳລັບວິສາຫະກິດລາວ". ຜູ້ທີ່ຕ້ອງການເຂົ້າໃຈພາບລວມຂອງການນຳໃຊ້ AI ສາມາດອ້າງອີງ "ຄູ່ມືການນຳໃຊ້ AI ສຳລັບວິສາຫະກິດລາວ" ໄດ້ເຊັ່ນກັນ.