ຂະໜາດຊັງກ໌

ເປັນຫຍັງຈຶ່ງຕ້ອງການການແບ່ງສ່ວນ

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 ຈະເພີ່ມຂຶ້ນ.