แนวทางการตั้งค่า Context Tokens สำหรับ LLM

Context คืออะไร?

Context ของ LLM (Large Language Model) หมายถึงขอบเขตของข้อมูลก่อนหน้าที่โมเดลนำมาพิจารณาในการสร้างข้อความ สำหรับ LLM แล้ว context เปรียบเสมือน “หน่วยความจำ” ที่ช่วยให้โมเดลตัดสินใจขั้นต่อไปโดยอ้างอิงจากเนื้อหาที่เคยเห็นหรือสร้างมาก่อน Context อาจเป็นประโยคเดียว ย่อหน้า เอกสาร หรือชุดหลายเอกสาร ขึ้นกับสถาปัตยกรรมและการออกแบบของโมเดล

Context สำคัญกับโมเดลภาษา เพราะช่วยให้โมเดลเข้าใจงานปัจจุบันและสร้างคำตอบที่สอดคล้องกับข้อมูลก่อนหน้า เช่น ในการสนทนา context อาจรวมทุกข้อความที่แลกเปลี่ยนกันจนถึงจุดนั้น ทำให้โมเดลตอบกลับได้ตรงกับธีมและโทนของบทสนทนา

แต่เนื่องจากข้อจำกัดด้านทรัพยากรคอมพิวเตอร์และหน่วยความจำ โมเดลภาษาส่วนใหญ่จะมีความยาว context ตายตัว ความยาว context ของโมเดลกระแสหลักปัจจุบันอยู่ที่ประมาณ 128K ถึง 1M tokens เมื่อ LLM พัฒนาไป การรองรับ context ที่ยาวขึ้นจะกลายเป็นเทรนด์ทั่วไป แต่ในมุมมองของต้นทุน token คุณภาพการตอบสนอง LLM และเวลาในการตอบในเชิงพาณิชย์ การบริหารจัดการ context อย่างแม่นยำและมีประสิทธิภาพจึงสำคัญ

Token คือ หน่วยทางภาษา เช่น คำ เครื่องหมายวรรคตอน หรือองค์ประกอบทางภาษาอื่น ๆ

แนวทางการตั้งค่า Context

เมื่อเข้าใจแล้วว่า context คือ “ปริมาณข้อมูลที่ LLM ประมวลผลได้ในครั้งเดียว” การจัดสรรทรัพยากรในพื้นที่ข้อมูลจำกัดนี้จึงเป็นหัวใจของการออกแบบ Agent GPTBots กำหนด context ของ LLM เป็น: หน่วยความจำระยะยาว, หน่วยความจำระยะสั้น, Identity Prompts, คำถามจากผู้ใช้, Tools Data และ Knowledge Data โดยการโต้ตอบกับ LLM หนึ่งครั้ง อาจมี context ทุกประเภทนี้ร่วมกัน แต่ละประเภทมีลำดับความสำคัญต่างกัน

หมายเหตุ: หากความยาวรวมของ context ทุกประเภทในการโต้ตอบกับ LLM เกินขีดจำกัด ระบบ GPTBots จะตัด context ประเภทที่มีลำดับความสำคัญต่ำสุดออกก่อน เพื่อให้การเรียกใช้งาน LLM สำเร็จ

คำถามจากผู้ใช้

เนื้อหาล่าสุดที่ผู้ใช้ป้อนระหว่างสนทนากับ Agent มีหลายรูปแบบ เช่น

• ข้อความที่พิมพ์เอง
• ข้อความเสียงที่บันทึกผ่านไมโครโฟน
• ข้อความรูปภาพ ข้อความวิดีโอ ข้อความเอกสาร ข้อความเสียง และไฟล์ที่อัปโหลดแนบมา

หมายเหตุ:
เมื่อเปิดใช้งาน “Agent-Configuration-Input-Attachment” แบบ System Recognition GPTBots จะรับรู้ไฟล์แนบทุกประเภทเป็นเนื้อหาข้อความและถือว่าเป็น คำถามจากผู้ใช้
สำหรับข้อความประเภทไฟล์ GPTBots จะเปลี่ยนไฟล์เป็น URL link เพื่อใช้เป็น คำถามจากผู้ใช้

Identity Prompts

ข้อมูลระบุตัวตนที่ตั้งค่าให้ LLM ใน Agent ของ GPTBots ถือเป็นหลักสำคัญในการกำกับการทำงานของ AI Agent โดยระบบจะปรับให้เป็น system message หรือ developer message ตามเวอร์ชันของโมเดล

• Identity prompt สำคัญมากในธุรกิจ ควรเขียนให้ชัดเจนและครอบคลุมเพื่อกำกับการทำงานและคำตอบของ AI
• โดยทั่วไปไม่ต้องกังวลเรื่องความยาว identity prompt เพราะคุณภาพสำคัญกว่าความยาว และควรลงทุน token กับส่วนนี้มากขึ้น
• การเขียน identity prompt ที่ดีควรชัดเจน มีตรรกะถูกต้อง และให้คำแนะนำที่แม่นยำ โดยควรระบุเป้าหมาย หลักการ ทักษะ และตรรกะการทำงานให้ครบ พร้อมหลีกเลี่ยงคำสั่งที่คลุมเครือ

หน่วยความจำระยะสั้น

ข้อมูลจาก X รอบบทสนทนาล่าสุดระหว่างผู้ใช้กับ Agent จะถูกส่งไปกับทุกคำขอ LLM หากปิดฟังก์ชันนี้หรือเพิ่งเริ่มบทสนทนา ส่วนนี้จะว่างเปล่า

ข้อควรพิจารณา:

• หาก Agent ไม่ต้องการ context หรือ context ส่งผลเสียต่อคุณภาพการตอบของ AI สามารถปิดหน่วยความจำระยะสั้นเพื่อประหยัด token และเพิ่มประสิทธิภาพ
• หาก Agent ต้องพึ่ง context อย่างมาก (เช่น ต้องใช้ context ในการตอบคำถาม) ควรกำหนดจำนวนรอบหน่วยความจำให้มากที่สุดเท่าที่เหมาะสม

Knowledge Data

เมื่อผู้ใช้ป้อนข้อมูล Agent จะดึงความรู้จากฐานความรู้ที่เกี่ยวข้องผ่าน vector search หาก Agent ไม่มีฐานความรู้หรือไม่สามารถดึงข้อมูลได้ ส่วนนี้จะว่างเปล่า

ข้อควรพิจารณา:

• หาก Agent ไม่ต้องใช้ฐานความรู้ สามารถปิดฟีเจอร์นี้เพื่อประหยัด token
• หาก Agent ต้องพึ่งผลลัพธ์จากฐานความรู้ (เช่น กรณีถาม-ตอบเอกสาร) ควรกำหนดจำนวนข้อมูลสูงสุดที่ดึงได้ คะแนนความเกี่ยวข้อง และพารามิเตอร์อื่น ๆ ใน "Knowledge Base" เพื่อให้ได้ปริมาณและคุณภาพของ RAG (retrieved augmented generation) ที่เหมาะสม

หน่วยความจำระยะยาว

เมื่อผู้ใช้ป้อนข้อมูล ระบบจะดึงประวัติการสนทนาจากทุกบทสนทนาใน Agent ผ่าน vector search หากปิดฟังก์ชันนี้หรือเพิ่งเริ่มต้นสนทนา ส่วนนี้จะว่างเปล่า

ข้อควรพิจารณา:

• หาก Agent ต้องใช้ประวัติสนทนา (เช่น กรณีตัวละครเสมือน) ควรเปิดใช้หน่วยความจำระยะยาว
• หากไม่จำเป็นต้องใช้ประวัติสนทนา สามารถปิดเพื่อประหยัด token

Tools Data

เมื่อระบบส่งข้อมูลคำขอไปยัง LLM จะรวมข้อมูล Tools ที่ Agent เลือกไว้ เพื่อช่วยให้ LLM เลือก Tool ที่ต้องการใช้งานได้ถูกต้อง หลังจากเรียกใช้ Tool สำเร็จ ผลลัพธ์ที่ได้จาก API จะถูกส่งกลับไปยัง LLM อีกครั้ง หากปิดฟังก์ชัน Tools ส่วนนี้จะว่างเปล่า

ข้อควรพิจารณา:

• หาก Agent ไม่ต้องใช้ Tools สามารถละเว้นการเพิ่ม Tools เพื่อประหยัด token
• หาก Tool มีหลาย API สามารถปิด API ที่ไม่จำเป็นในหน้าตั้งค่า Tool ได้ API ที่ปิดจะไม่ถูกส่งให้ LLM จึงช่วยประหยัด token

LLM Output

ความยาว token ของข้อมูลผลลัพธ์จาก LLM จะถูกกำหนดและสำรองไว้ตั้งแต่ตอนขอใช้งาน LLM GPTBots รองรับการตั้งค่าความยาว token ของการตอบกลับ LLM ได้เอง และส่วนนี้จะไม่ถูกจำกัดด้วย input ด้านบน

กรณีศึกษา

ตัวอย่างการจัดสรร context tokens ในสถานการณ์จริง สมมติใช้ LLM ที่มีขีดจำกัด context 8K tokens:

กรณี: ผู้ช่วยบริการลูกค้าออนไลน์

Agent ผู้ช่วยบริการลูกค้าออนไลน์ต้อง:

• จำเนื้อหาบทสนทนาล่าสุดกับผู้ใช้
• ดึงข้อมูลจากฐานความรู้สินค้า
• เรียกใช้อินเทอร์เฟซตรวจสอบคำสั่งซื้อ
• รักษาภาพลักษณ์ความเป็นมืออาชีพ

แผนการจัดการ Token

ข้อเสนอแนะการปรับแต่ง

1. ปรับแบบไดนามิก
   • เมื่อคำถามผู้ใช้สั้น สามารถนำ token ที่เหลือไปเพิ่มให้ knowledge data ได้
   • เมื่อไม่ได้ใช้ Tools สามารถนำพื้นที่ไปเพิ่มให้ short-term memory ได้
2. ลำดับความสำคัญ
   • หาก token รวมเกินขีดจำกัด ให้ตัดตามลำดับความสำคัญ:
   • คงไว้: คำถามจากผู้ใช้, หน่วยความจำระยะสั้น, Identity Prompt, Knowledge Data, Tools Data
   • บีบอัด/ตัดออก: หน่วยความจำระยะยาว
3. คงประสิทธิภาพ
   • ให้แน่ใจว่าฟังก์ชันหลัก (เช่น การตรวจสอบคำสั่งซื้อ) สมบูรณ์เมื่อ token ไม่พอ
   • หน่วยความจำระยะยาวสามารถถูกตัดทอนได้เพื่อรักษาคุณภาพการตอบ

ด้วยการวางแผนแบบนี้ Agent ผู้ช่วยบริการลูกค้าจะสามารถทำงานหลักได้ครบถ้วนภายใต้ข้อจำกัด token พร้อมรักษาความต่อเนื่องและความเป็นมืออาชีพของบทสนทนา