ຂະໜາດຊັງກ໌

## ເປັນຫຍັງຈຶ່ງຕ້ອງການການແບ່ງສ່ວນ LLM ມີຂີດຈຳກັດຂອງ context window. ເນື່ອງຈາກບໍ່ສາມາດສົ່ງຄູ່ມືພາຍໃນອົງກອນທີ່ມີຫຼາຍຮ້ອຍໜ້າໄປໂດຍກົງໄດ້, ຈຶ່ງຕ້ອງແບ່ງເອກະສານອອກເປັນຂະໜາດທີ່ເໝາະສົມ (chunking) ແລ້ວທຳການ vectorize, ຈາກນັ້ນຈຶ່ງຄົ້ນຫາ ແລະ ດຶງເອົາສະເພາະສ່ວນທີ່ກ່ຽວຂ້ອງກັບຄຳຖາມ. ໃນຂັ້ນຕອນນີ້, "ຈະຕັດໃນຂະໜາດໃດ" ຈຶ່ງກາຍເປັນບັນຫາຂອງ chunk size. ## ໃຫຍ່ເກີນໄປກໍ່ບໍ່ດີ, ນ້ອຍເກີນໄປກໍ່ມີບັນຫາ ຖ້າ chunk ນ້ອຍເກີນໄປ, ບໍລິບົດທີ່ຢູ່ໃນ chunk ດຽວຈະບໍ່ພຽງພໍ, ແມ່ນແຕ່ຈະຖືກຄົ້ນພົບໃນການຄົ້ນຫາ, LLM ກໍ່ຍັງຂາດຂໍ້ມູນທີ່ຈຳເປັນສຳລັບການສ້າງຄຳຕອບ. ໃນທາງກົງກັນຂ້າມ, ຖ້າໃຫຍ່ເກີນໄປ, ຂໍ້ມູນທີ່ບໍ່ກ່ຽວຂ້ອງຈະຖືກປົນເຂົ້າມາເປັນ noise, ສົ່ງຜົນໃຫ້ຄວາມຖືກຕ້ອງຂອງຄຳຕອບຫຼຸດລົງ ແລະ ຄ່າໃຊ້ຈ່າຍ token ກໍ່ເພີ່ມຂຶ້ນດ້ວຍ. ໂດຍທົ່ວໄປແລ້ວ, ປະມານ 256〜1,024 token ຖືວ່າເປັນຈຸດເລີ່ມຕົ້ນ, ແຕ່ຄ່າທີ່ດີທີ່ສຸດຂຶ້ນຢູ່ກັບ domain ແລະ ລັກສະນະຂອງຄຳຖາມ. ນະໂຍບາຍພື້ນຖານໃນການປະຕິບັດຕົວຈິງຄື: ຖ້າເປັນ Q&A ສັ້ນໆ ແບບ FAQ ໃຫ້ຕັ້ງຄ່າໃຫ້ນ້ອຍລົງ, ຖ້າເປັນເອກະສານທີ່ບໍລິບົດກ່ອນໜ້າ ແລະ ຫຼັງຈາກນັ້ນມີຄວາມສຳຄັນ ເຊັ່ນ: ເອກະສານຂໍ້ກຳນົດທາງເທັກນິກ ໃຫ້ຕັ້ງຄ່າໃຫ້ໃຫຍ່ຂຶ້ນ. ## ເຕັກນິກທີ່ເອີ້ນວ່າ Overlap ເພື່ອບັນເທົາບັນຫາທີ່ບໍລິບົດຖືກຕັດຂາດທີ່ຂອບເຂດຂອງ chunk, ມັກຈະໃຊ້ "overlap" ທີ່ເຮັດໃຫ້ chunk ທີ່ຢູ່ຕິດກັນຊ້ອນທັບກັນບາງສ່ວນ. ຕົວຢ່າງ: ຖ້າ chunk size ແມ່ນ 512 token ແລະ overlap ແມ່ນ 64 token, ສ່ວນທ້າຍ 64 token ຂອງ chunk ກ່ອນໜ້າຈະຖືກລວມຢູ່ໃນຕອນຕົ້ນຂອງ chunk ຕໍ່ໄປດ້ວຍ. ວິທີນີ້ຊ່ວຍປັບປຸງຄວາມຖືກຕ້ອງຂອງ BM25 ແລະ vector search, ແຕ່ storage ແລະ index size ຈະເພີ່ມຂຶ້ນ.