ສິ່ງທີ່ທ່ານຕ້ອງກວດສອບ ແລະ ປ້ອງກັນຄວາມປອດໄພ ກ່ອນເປີດໃຊ້ງານ AI Agent

ບໍລິສັດ Startup ທີ່ເຮັດ Customer Service Agent ແຫ່ງໜຶ່ງ ໄດ້ເປີດໃຫ້ບໍລິການໃນອາທິດທີສາມ ແຕ່ປາກົດວ່າຈຳນວນຄຳຮ້ອງຮຽນຂອງລູກຄ້າບໍ່ໄດ້ຫຼຸດລົງ ແຕ່ກັບເພີ່ມຂຶ້ນ. ພວກເຂົາຍິ່ງງຶດງໍ້—ເພາະຕອນທົດສອບ (Test) ເຫັນວ່າຖືກຕ້ອງທຸກຢ່າງ. ຕໍ່ມາເມື່ອເອົາ Log ມາເບິ່ງ ຈຶ່ງຮູ້ວ່າ: ມີບັນຫາປະເພດໜຶ່ງ ທີ່ Agent ມັກຈະອ້າງອີງ "ນະໂຍບາຍການຈ່າຍເງິນຄືນ ຂໍ້ທີ 7" ດ້ວຍຄວາມໝັ້ນໃຈຕະຫຼອດ ໂດຍທີ່ນະໂຍບາຍສະບັບນັ້ນບໍ່ມີຂໍ້ທີ 7 ຕັ້ງແຕ່ທຳອິດ. ມັນບໍ່ແມ່ນວ່າເຮັດບໍ່ເປັນ ພຽງແຕ່ມັນເວົ້າເລື່ອງທີ່ບໍ່ມີຈິງໃຫ້ເບິ່ງຄືວ່າເປັນຈິງຫຼາຍ ແລະ ຊຸດ Test Case ກ່ອນເປີດໃຊ້ງານກໍບັງເອີນບໍ່ໄດ້ກວມເອົາບັນຫາປະເພດນີ້.

ນີ້ຄືຮູບແບບຄວາມຜິດພາດທີ່ອັນຕະລາຍທີ່ສຸດຂອງ Agent—ມັນບໍ່ຂຶ້ນຕົວໜັງສືແດງ, ບໍ່ Throw exception. ມັນເຮັດຜິດຢ່າງງຽບໆ, ສຸພາບຮຽບຮ້ອຍ ແລະ ມີເຫດຜົນຈະແຈ້ງ, ແລ້ວຜູ້ໃຊ້ງານຂອງເຈື່ອກໍເຊື່ອ.

ເປັນຫຍໍ້ Agent ຈຶ່ງເກີດ "ຄວາມຜິດພາດແບບ無聲失敗 (Silently Fail)"

ຊອບແວແບບດັ້ງເດີມເວລາເກີດຂໍ້ຜິດພາດ ມັກຈະລະເບີດໃຫ້ເຫັນ: ພົ່ນ Error ອອກມາ, ຕອບ 500, Stack trace ຊີ້ໄປທີ່ບັນທັດທີເທົ່າໃດ. ແຕ່ Agent ບໍ່ແມ່ນແບບນັ້ນ. ຜົນໄດ້ຮັບຂອງມັນຖືກ "ສ້າງຂຶ້ນມາ" (Generate), ພາສາທີ່ໃຊ້ແມ່ນກ້ຽງງາມຕະຫຼອດ, ເຮັດໃຫ້ຄວາມຜິດພາດຖືກຫຸ້ມຫໍ່ຈົນເບິ່ງຄືກັນກັບຄຳຕອບທີ່ຖືກຕ້ອງທຸກປະການ.

ສິ່ງທີ່ຫຍຸ້ງຍາກກວ່ານັ້ນຄືການເຮັດວຽກຫຼາຍຂັ້ນຕອນ (Multi-step). Agent 1 รอบ ອາດຈະຕ້ອງຮຽກໃຊ້ Tool 5-6 ครั้ง, ຖ້າຂັ້ນຕອນໃດຂັ້ນຕອນໜຶ່ງກາງທາງພຽງລ່ຽງໄປ—ຊອກຫາຂໍ້ມູນຜິດ, ສົ່ງ Parameter ຜິດ, ຫຼຸດເງື່ອນໄຂໜຶ່ງໄປ—ຂັ້ນຕອນຕໍ່ໆໄປກໍຈະສືບຕໍ່ຄາດຄະເນໂດຍອີງໃສ່ຄວາມຜິດພາດນັ້ນ, ແລະ ສຸດท้ายກໍໃຫ້ຜົນລັບທີ່ "ສອດຄ້ອງກັນໃນຕົວ ແຕ່ຜິດ". ຖ້າເຈົ້າເບິ່ງຄຳຕອບສຸດທ້າຍ, ເຈົ້າຈະເບິ່ງບໍ່ອອກເລີຍວ່າບ່ອນໃດມັນບິດເບືອນ.

ດັ່ງນັ້ນ, QA (Quality Assurance) ຂອງ Agent ຈຶ່ງບໍ່ສາມາດອີງໃສ່ການສຸມກວດສອບດ້ວຍມະນຸດ, ແລະ ກໍບໍ່ສາມາດອີງໃສ່ຄວາມຮູ້ສຶກທີ່ວ່າ "ຂ້ອຍລອງໃຊ້ຫຼາຍຄັ້ງແລ້ວເຫັນວ່າໃຊ້ໄດ້". ເຈົ້າຕ້ອງການລະບົບທີ່ສາມາດວັດແທກໄດ້, Playback ໄດ້ ແລະ ຕິດຕາມກວດກາຜົນໄດ້ຢ່າງຕໍ່ເນື່ອງໃນລະບົບ Production. ນี่ຄືສິ່ງທີ່ບົດຄວາມ 〈ຢາກສ້າງ AI Agent ດ້ວຍຕົນເອງ, ຕ້ອງກຽມເຄື່ອງມືຫຍັງແດ່?〉 ໄດ້ກ່າວເຖິງໃນ 3 ດ້ານຄື: ການປະເມີນຜົນ (Evaluation), ความปลอดภัย (Security) ແລະ ຄວາມສາມາດໃນການສັງເກດການ (Observability) ເຊິ່ງຈະໄດ້ນຳມາໃຊ້ງານແທ້ໃນຊ່ວງເວລານຳອອກສູ່ລະບົບ (Deployment).

ຈຸດສຳຄັນ: 4 ສິ່ງທີ່ຕ້ອງກວດກາໃຫ້ຮຽບຮ້ອຍກ່ອນຂຶ້ນລະບົບ Production

• Offline Evaluation: ใช้ชุดโจทย์คงที่ เพื่อวัดปริมาณว่าหลังจากการปรับปรุงแต่ละครั้ง คุณภาพลดลงหรือไม่.
• Red Teaming: ຊອກຫາຈຸດອ່ອນຂອງມັນຢ່າງຕັ້ງໜ້າ—ມີ Input ແບບໃດທີ່ຈະເຮັດໃຫ້ມັນລ້ຳເສັ້ນ, ຂີ້ຕั๋ว, ຂໍ້ມູນຮົ່ວໄຫຼ.
• Multi-step Debug: ເມື່ອເກີດຂໍ້ຜິດພາດສາມາດ Playback ເສັ້ນທາງການເຮັດວຽກທັງໝົດໄດ້ ເພື່ອຊີ້ວ່າຍ່ອງຂັ້ນຕອນໃດທີ່ພຽງລ່ຽງໄປ.
• Online Monitoring & Guardrails: ຕິດຕາມກວດກາຄຸນນະພາບ ແລະ ຕົ້ນທຶນຢ່າງຕໍ່ເນື່ອງຫຼັງຂຶ້ນລະບົບ, ພ້ອມທັງຕັ້ງລະບົບຂັດຂວາງກ່ອນເກີດການກະທຳທີ່ມີຄວາມສ່ຽງ.

ຖ້າຂາດ 4 ສິ່ງນີ້ໄປແມ່ນແຕ່ຢ່າງດຽວ, ການເປີດໃຊ້ງານຂອງທ່ານກໍຄືການຫຼິ້ນການພະນັນ.

ວິທີການທົດສອບ: Promptfoo

ຈິດວິນຍານຫຼັກຂອງ Offline Evaluation ຄືການປ່ຽນຈາກຄວາມຮູ້ສຶກ "ຂ້ອຍຮູ້ສຶກວ່າມັນດີຂຶ້ນ" ມາເປັນ "ຕົວເລກບອກຂ້ອຍວ່າມັນດີຂຶ້ນ". Promptfoo ຊ່ວຍໃຫ້ທ່ານສ້າງຊຸດ Test Case—Input, พฤติกรรมที่คาดหวັງ, ເງື່ອນໄຂການຕັດສິນ—ຈາກນັ້ນທຸກໆຄັ້ງທີ່ປ່ຽນ Prompt, ປ່ຽນ Model, ປ່ຽນ Parameter, ກໍໃຫ້ Run ຊຸດທົດສອບທັງໝົດແລ້ວເບິ່ງການປ່ຽນແປງຂອງຄະແນນ.

ເງື່ອນໄຂການຕັດສິນສາມາດເປັນ String matching, Regular expression, ຫຼື ໃຊ້ Model ອີກໂຕໜຶ່ງເປັນกรรมการ (LLM-as-judge) ເພື່ອປະເມີນວ່າ "ຄຳຕອບນີ້ອ້າງອີງແຫຼ່ງທີ່ມາໄດ້ຖືກຕ້ອງບໍ". ຖ້າ Startup ທີ່ກ່າວມາຂ້າງຕົ້ນມີ Assertion ທີ່ວ່າ "ໝາຍເລກນະໂຍບາຍທີ່ກ່າວມາໃນຄຳຕອບ ຕ້ອງມີຕົວຕົນແທ້", ຂໍ້ 7 ນັ້ນກໍຄົງບໍ່ສາມາດຜ່ານຂຶ້ນ Production ໄດ້ຕັ້ງແຕ່ທຳອິດ.

Red Teaming ກໍເຮັດໄດ້ໃນຊັ້ນນີ້ເຊັ່ນກັນ. Promptfoo ສามารถ Run ຊຸດ Adversarial inputs ພະຍາຍາມເຮັດໃຫ້ Agent ຂໍ້ມູນ System prompt ຮົ່ວໄຫຼ, ຂ້າມຜ່ານຂໍ້ຈຳກັດ, ດຳເນີນການໃນສິ່ງที่ไม่ຄວນເຮັດ. ຖ້າທ່ານບໍ່ໄປໂຈມຕີມັນ, ຜູ້ໃຊ້ (ຫຼື ຜູ້ບໍ່ຫວັງດີ) ກໍຈະມາໂຈມຕີມັນແທນທ່ານ. ດັ່ງນັ້ນ ຄວນໂຈມຕີທົດສອບດ້ວຍຕົນເອງກ່ອນ.

ວິທີການ Debug: AgentOps

Evaluation ບອກເຈົ້າວ່າ "ຄຳຕອບຜິດ", ແຕ່ມັນບໍ່ໄດ້ບອກເຈົ້າວ່າ "ຜິດຢູ່ຂັ້ນຕອນທີເທົ່າໃດ". ການ Debug ຫຼາຍຂັ້ນຕອນ (Multi-step debug) ຕ້ອງອາໄສ AgentOps.

ມັນເຊື່ອມໂຍງການເຮັດວຽກທັງໝົດຂອງ Agent ໃຫ້ເປັນເສັ້ນທາງເວລາທີ່ສາມາດ Playback ໄດ້: ຂັ້ນຕອນທຳອິດຮຽກໃຊ້ Tool ຫຍັງ, ສົ່ງ Parameter ຫຍັງໄປ, ໄດ້ຫຍັງກັບມາ, ໃຊ້ Token ໄປເທົ່າໃດ, ຂັ້ນຕອນທີສອງຕັດສິນໃຈບາດກ້າວຕໍ່ໄປໂດຍອີງໃສ່ຫຍັງ... ຖອດອອກມາເບິ່ງທັງໝົດ. ຕົວຢ່າງເລື່ອງນະໂຍບາຍການຈ່າຍເງິນຄືນນັ້ນ, ຖ້າຢູ່ໃນ AgentOps ເຮົາຈະເຫັນຢ່າງຈະແຈ້ງ—ຊິ້ນສ່ວນເອກະສານທີ່ດຶງຂໍ້ມູນກັບມາໃນຂັ້ນຕອນໃດໜຶ່ງແມ່ນຜິດແຕ່ທຳອິດແລ້ວ, ສ່ວນຂັ້ນຕອນຕໍ່ໆໄປແມ່ນການຄາດຄະເນຢ່າງມີເຫດຜົນທີ່ອີງໃສ່ຂໍ້ມູນທີ່ຜິດພາດທັງໝົດ. ຖ້າບໍ່มี Timeline ນີ້, ເຈົ້າກໍຄົງໄດ້ແຕ່ນັ່ງຈ້ອງເບິ່ງຄຳຕອບສຸດທ້າຍດ້ວຍຄວາມງຶດງໍ້.

ວິທີການ Monitor: Langfuse

ການຂຶ້ນ System ບໍ່ແມ່ນຈຸດສິ້ນສຸດ, ແຕ່ເປັນຈຸດເລີ່ມຕົ້ນອີກຮູບແບບໜຶ່ງ. Input ໃນ Production ມີຄວາມຫຼາກຫຼາຍຢ່າງຍິ່ງ, ຜູ້ໃຊ້ຈະຖາມຄຳຖາມທີ່ເຈົ້າຄິດບໍ່ເຖິງຕອນທົດສອບ.Langfuse ເຮັດໜ້າທີ່ບັນທຶກທຸກການສົນທະນາໃນລະບົບຕົວຈິງ, ຕົ້ນທຶນ Token ແຕ່ລະລາຍການ, ຄວາມຊ້າ (Latency) ໄວ້ໃນໄລຍະຍາວ ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດິດຕາມໄດ້ວ່າ ຄຸນນະພາບມີການ drift ໄປຕາມເວລາບໍ, ຄຳຖາມປະເພດໃດທີ່ຕອບໄດ້แย่ທີ່ສຸດ, ຕົ້ນທຶນເກີນການຄວບຄຸມແລ້ວບໍ.

ການແບ່ງໜ້າທີ່ລະຫວ່າງມັນກັບ AgentOps ໂດຍກວ້າງແມ່ນ: AgentOps ເໝາະສຳລັບການ Debug ເຊິ່ງໜ້າໃນຊ່ວງ Development, ສ່ວນ Langfuse ເໝາະສຳລັບການ Monitor ໝູ່ຄະນະໃນໄລຍະຍາວເທິງ Production. ໃນທາງປະຕິບັດ, ທີມງານຈຳນວນຫຼາຍໃຊ້ທັງສອງຢ່າງຮ່ວມກັນ. ຈຸດສຳຄັນກໍຄື—ເຈົ້າຕ້ອງມີບ່ອນໜຶ່ງທີ່ສາມາດຕອບຄຳຖາມໄດ້ຕະຫຼອດເວລາວ່າ "ອາທິດນີ້ Agent ຂອງຂ້ອຍມີຜົນງານເປັນແນວໃດ?". ຖ້າຕອບບໍ່ໄດ້, ກໍຄືການແລ່ນເປືອຍກາຍຢູ່ກາງแจ้ง.

ລະບົບປ້ອງກັນ (Guardrails): ດ່ານສະກັດກັ້ນສຸດທ້າຍ

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

ສິ່ງທີ່ Guardrails ຄວນສະກັດກັ້ນ: ປິດบังຂໍ້ມູນສ່ວນຕົວ ຫຼື ຂໍ້ມູນລັບເມື່ອ Output ມີຂໍ້ມູນເຫຼົ່ານັ້ນ, ໂອນສາຍໃຫ້ມະນຸດເມື່ອມູນຄ່າເກີນກຳນົດ, ຢຸດເຊັນທັນທີເມື່ອตรวจພົບ Prompt injection. ຊັ້ນນີ້ແມ່ນຖືກອອກແບບມາໃຫ້ໃຊ້ຄູ່ກັບ Execution Sandbox ໃນ Toolchain (ເຊັ່ນ Blaxel)—Sandbox ຈຳກັດວ່າ "ມັນສາມາດ Run ຫຍັງໄດ້", ສ່ວນ Guardrails ຈຳກັດວ່າ "ມັນສາມາດເຮັດຫຍັງໄດ້".

ຈຸດສຳຄັນໃນການກວດກາຂອງ 3 ປະເພດທີມງານ

ຕ່າງປະເທດ/ນັກພັດທະນາສ່ວນບຸກຄົນ (Taiwanese individual developers): ຢ່າງໜ້ອຍຄວນເຊື່ອມຕໍ່ Promptfoo ເຂົ້າໄປ. ຕໍ່ໃຫ້ມີພຽງແຕ່ 20 Test cases, ກໍຍັງดีກວ່າການປ່ຽນແປງແລ້ວອີງໃສ່ຄວາມຮູ້ສຶກ. Red Teaming ໃຫ້ເລືອກບາງສ່ວນຂອງ Attack surface ທີ່ມີຄວາມສ່ຽງທີ່ສຸດມາ Run, ຢ່າໄປຄິດວ່າຕ້ອງສົມບູນແບບ.

ທີມງານ Startup: ຄວນຣີບນຳໃຊ້ AgentOps ແລະ Langfuse ໃຫ້ໄວ. ผลิตภัณฑ์ຂອງທ່ານຍັງຢູ່ໃນຊ່ວງ Iteration ທີ່ວ່ອງໄວ, ຖ້າບໍ່ມີ Observability, ທຸກໆຄັ້ງທີ່ເກີດບັນຫາແມ່ນທີມງານຕ້ອງມາຊອກຫາໃນທະເລ Log, ເຊິ່ງເວລາທີ່ໃຊ້ໄປນັ້ນພໍທີ່ຈະໃຫ້ທ່ານສ້າງຟີເຈີເພີ່ມໄດ້ອີກສອງຢ່າງ. Guardrails ໃຫ້ຄວາມສຳຄັນເປັນອັນດັບທຳອິດໃນການປົກປ້ອງການກະທຳທີ່ "ຕ້ອງຈ່າຍເງິນ" ແລະ "ບໍ່ສາມາດຍົກເລີກໄດ້".

ວິສາຫະກິດ (Enterprise): Red Teaming ແລະ Guardrails ຄືເສັ້ນຕາຍຂອງ Compliance (ການປະຕິບັດຕາມກົດລະບຽບ). ຄຳຖາມທີ່ IT Security, Legal ຈະຖາມເຊັ່ນ: "ຂໍ້ມູນຈະຮົ່ວໄຫຼບໍ", "ສາມາດກວດສອບການຕັດສິນໃຈທຸກຂັ້ນຕອນໄດ້ບໍ", ຄຳຕອບແມ່ນເຊື່ອງໄວ້ໃນບັນທຶກການທົດສອບການໂຈມຕີຂອງ Promptfoo ແລະ ເສັ້ນທາງການປະຕິບັດງານຂອງ AgentOps. ການເກັບຮັກສາບັນທຶກເຫຼົ່ານີ້ໄວ້ ໝາຍເຖິງການກຽມຫຼັກຖານການກວດສອບ (Audit) ໄວ້ລ່ວງໜ້າ.

ລາຍການກວດກາ (Checklist) ກ່ອນຂຶ້ນລະບົບ Production

ປະຕິບັດຕາມນີ້ໄດ້เลย:

• ມີຊຸດທົດສອບທີ່ກວມເອົາທັງກໍລະນີທົ່ວໄປ ແລະ ຂອບເຂດ (Edge cases) ຢ່າງໜ້ອຍໜຶ່ງຊຸດ, Run ຢູ່ເທິງ Promptfoo
• ທຸກໆຄັ້ງທີ່ປ່ຽນ Prompt ຫຼື Model, ຕ້ອງ Run ການປະເມີນຜົນແບບຄົບຖ້ວນ, คะแนนຕ້ອງບໍ່ຫຼຸດລົງຈຶ່ງຄ່ອຍ Deploy
• ຜ່ານການເຮັດ Red Teaming ຢ່າງໜ້ອຍ 1 ຮອບ, ໄດ້ທົດສອບ Prompt injection, ການລ້ຳເສັ້ນ, ການຂີ້ຕັດ
• ສໍາລັບຄຳຕອບປະເພດ "ການກ່າວອ້າງຂໍ້ເທັດຈິງ", ຕ້ອງມີ Assertion ເພື່ອກວດສອບວ່າແຫຼ່ງທີ່ົາມີຕົວຕົນແທ້
• ຂະບວນການຫຼາຍຂັ້ນຕອນ (Multi-step) ຕ້ອງເຊື່ອມຕໍ່ AgentOps, ເມື່ອເກີດຂໍ້ຜິດພາດສາມາດ Playback ເພື່ອຊີ້ວ່າມັນຜິດຢູ່ຂັ້ນຕອນໃດ
• ເຊື່ອມຕໍ່ Langfuse ໃນລະບົບ Online, ສາມາດກວດສອບ Quality drift ແລະ ຕົ້ນທຶນໄດ້
• ກ່ອນການກະທຳທີ່ມີຄວາມສ່ຽງ (ຈ່າຍເງິນ, ລຶບ, ສົ່ງອອກພາຍນອກ) ຕ້ອງມີ Guardrails ຫຼື ການຢືນຢັນຈາກມະນຸດ
• ຕັ້ງຄ່າ Token ແລະ ຕົ້ນທຶນສູງສຸດໄວ້, ເພື່ອຫຼີກລ່ຽງການທີ່ Background Agent เผาຜານເງິນ
• ການ Run Code ທີ່ມີຄວາມສ່ຽງ ຄວນເຮັດໃນ Sandbox
• ມີບຸກຄົນໜຶ່ງ, ທີ່ຮູ້ວ່າເມື່ອເກີດບັນຫາຂຶ້ນ ຄວນເບິ່ງຈຸດໃດກ່ອນເປັນອັນດັບທຳອິດ

ບົດສະຫຼຸບ ແລະ ຄວາມຄິດເຫັນຈາກ TheAI學院

ຄວາມສ່ຽງທີ່ໃຫຍ່ທີ່ສຸດຂອງການ Deploy Agent, ບໍ່ເຄີຍແມ່ນການທີ່ເທັກໂນໂລຊີເກັ່ງບໍ່ພໍ, ແຕ່ແມ່ນ "ເຈົ້າບໍ່ຮູ້ເລີຍວ່າມັນເຮັດຜິດໃນตอนໃດ". Evaluation ຊ່ວຍໃຫ້ເຈົ້າຮູ້ລ່ວງໜ້າ, Observability ຊ່ວຍໃຫ້ເຈົ້າກວດສອບໄດ້ພາຍຫຼັງ, Guardrails ຊ່ວຍໃຫ້ເຈົ້າສະກັດກັ້ນໄດ້ໃນຕອນນັ້ນ—ຄຸນຄ່າຂອງ 3 ສິ່ງນີ້ ປົກກະຕິແລ້ວເຮົາອາດຈະບໍ່ຮູ້ສຶກ, ແຕ່ໃນວັນທີ່ເກີດບັນຫາຂຶ້ນມາ ມັນຈະຊ່ວຍຊີວິດເຈົ້າໄດ້.

「Agent ທີ່ເຈົ້າເບິ່ງບໍ່ເຫັນພາຍໃນ ແລະ ວັດແທກຄຸນນະພາບບໍ່ໄດ້, ຕໍ່ໃຫ້ແລ່ນໄດ້ລຽບງອນສໍ່າໃດກໍຄືລະເບີດເວລາ; ຄວາມທຳມະດາທີ່ສາມາດກວດສອບໄດ້ ຍ່ອມດີກວ່າຄວາມສະຫຼາດທີ່ມອງບໍ່ເຫັນຫຼາຍເທົ່າ.»

ຄຳແນະນຳທີ່ເປັນຮູບະທຳສຳລັບຜູ້ອ່ານ: ກ່ອນຂຶ້ນລະບົບ Production, ຈົ່ງບັງຄັບຕົວເອງໃຫ້ຕອບຄຳຖາມນີ້—"ຖ້