บริบทแบบยาว

โมเดล Gemini หลายรุ่นมีหน้าต่างบริบทขนาดใหญ่ที่รองรับโทเค็น 1 ล้านโทเค็นขึ้นไป ในอดีต โมเดลภาษาขนาดใหญ่ (LLM) ถูกจำกัดอย่างมากด้วย ปริมาณข้อความ (หรือโทเค็น) ที่ส่งไปยังโมเดลได้ในครั้งเดียว หน้าต่างบริบทแบบยาวของ Gemini จะปลดล็อกกรณีการใช้งานใหม่ๆ และกระบวนทัศน์ของนักพัฒนาซอฟต์แวร์ มากมาย

โค้ดที่คุณใช้ในกรณีต่างๆ เช่น การสร้างข้อความหรืออินพุตแบบมัลติโมดอลจะทำงานได้โดยไม่ต้องเปลี่ยนแปลงใดๆ เมื่อใช้กับบริบทแบบยาว

เอกสารนี้จะให้ภาพรวมของสิ่งที่คุณทำได้โดยใช้โมเดลที่มีหน้าต่างบริบทขนาด 1 ล้านโทเค็นขึ้นไป หน้านี้จะให้ภาพรวมโดยย่อของหน้าต่างบริบท และสำรวจวิธีที่นักพัฒนาซอฟต์แวร์ควรพิจารณาบริบทแบบยาว กรณีการใช้งานจริงต่างๆ สำหรับบริบทแบบยาว และวิธีเพิ่มประสิทธิภาพการใช้งานบริบทแบบยาว

ดูขนาดหน้าต่างบริบทของโมเดลที่เฉพาะเจาะจงได้ที่หน้าโมเดล

หน้าต่างบริบทคืออะไร

วิธีพื้นฐานในการใช้โมเดล Gemini คือการส่งข้อมูล (บริบท) ไปยังโมเดล ซึ่งจะสร้างคำตอบในภายหลัง การเปรียบเทียบ หน้าต่างบริบทคือหน่วยความจำระยะสั้น หน่วยความจำระยะสั้นของคนเราจัดเก็บข้อมูลได้จำกัด และโมเดล Generative ก็เช่นกัน

อ่านเพิ่มเติมเกี่ยวกับวิธีการทำงานของโมเดลเบื้องหลังได้ในคำแนะนำเกี่ยวกับโมเดล Generative

เริ่มต้นใช้งานบริบทแบบยาว

โมเดล Generative เวอร์ชันก่อนหน้าประมวลผลได้ครั้งละ 8,000 โทเค็นเท่านั้น โมเดลรุ่นใหม่ๆ ได้ขยายขีดจำกัดนี้ออกไปอีกโดยยอมรับโทเค็น 32,000 หรือแม้แต่ 128,000 โทเค็น Gemini เป็นโมเดลแรกที่รับโทเค็นได้ 1 ล้านโทเค็น

ในทางปฏิบัติ โทเค็น 1 ล้านรายการจะมีลักษณะดังนี้

• โค้ด 50,000 บรรทัด (มีอักขระมาตรฐาน 80 ตัวต่อบรรทัด)
• ข้อความทั้งหมดที่คุณส่งในช่วง 5 ปีที่ผ่านมา
• นวนิยายภาษาอังกฤษความยาวปานกลาง 8 เรื่อง
• ข้อความถอดเสียงของตอนพอดแคสต์ที่มีความยาวโดยเฉลี่ยกว่า 200 ตอน

หน้าต่างบริบทที่จำกัดมากขึ้นซึ่งพบได้ทั่วไปในโมเดลอื่นๆ อีกมากมายมักต้องใช้กลยุทธ์ต่างๆ เช่น การทิ้งข้อความเก่าโดยพลการ การสรุปเนื้อหา การใช้ RAG กับฐานข้อมูลเวกเตอร์ หรือการกรองพรอมต์เพื่อประหยัดโทเค็น

แม้ว่าเทคนิคเหล่านี้จะยังคงมีประโยชน์ในบางสถานการณ์ แต่หน้าต่างบริบทที่กว้างขวางของ Gemini ก็ช่วยให้คุณใช้วิธีการที่ตรงไปตรงมามากขึ้นได้ นั่นคือการให้ข้อมูลที่เกี่ยวข้องทั้งหมด ตั้งแต่แรก เนื่องจากโมเดล Gemini สร้างขึ้นมาโดยเฉพาะให้มีความสามารถด้านบริบท จำนวนมาก จึงแสดงให้เห็นถึงการเรียนรู้ในบริบทที่มีประสิทธิภาพ ตัวอย่างเช่น การใช้เฉพาะสื่อการเรียนการสอนในบริบท (ไวยากรณ์อ้างอิง 500 หน้า พจนานุกรม และประโยคคู่ขนานประมาณ 400 ประโยค) ทำให้ Gemini เรียนรู้ที่จะแปลจากภาษาอังกฤษเป็นภาษากาลามัง ซึ่งเป็นภาษาปาปัวที่มีผู้พูดน้อยกว่า 200 คน โดยมีคุณภาพคล้ายกับผู้เรียนที่เป็นมนุษย์ซึ่งใช้สื่อเดียวกัน ซึ่งแสดงให้เห็นถึงการเปลี่ยนแปลงกระบวนทัศน์ที่บริบทแบบยาวของ Gemini ช่วยให้เกิดขึ้นได้ โดยการเพิ่มความเป็นไปได้ใหม่ๆ ผ่านการเรียนรู้ในบริบทที่แข็งแกร่ง

กรณีการใช้งานบริบทแบบยาว

แม้ว่ากรณีการใช้งานมาตรฐานสำหรับโมเดล Generative ส่วนใหญ่ยังคงเป็นการป้อนข้อความ แต่กลุ่มโมเดล Gemini ก็ช่วยให้เกิดกระบวนทัศน์ใหม่ของกรณีการใช้งานแบบมัลติโมดัล โมเดลเหล่านี้เข้าใจข้อความ วิดีโอ เสียง และรูปภาพได้โดยกำเนิด โดยมาพร้อมกับ Gemini API ที่รับไฟล์มัลติโมดัลเพื่อความสะดวก

ข้อความแบบยาว

ข้อความพิสูจน์ให้เห็นว่าเป็นเลเยอร์ของข้อมูลอัจฉริยะที่รองรับโมเมนตัมส่วนใหญ่เกี่ยวกับ LLM ดังที่ได้กล่าวไปก่อนหน้านี้ ข้อจำกัดในทางปฏิบัติของ LLM ส่วนใหญ่เกิดจากการไม่มีหน้าต่างบริบทที่ใหญ่พอที่จะทำงานบางอย่างได้ ซึ่งนำไปสู่การนำการสร้างแบบดึงข้อมูลเสริม (RAG) และเทคนิคอื่นๆ มาใช้กันอย่างรวดเร็ว ซึ่งจะให้ข้อมูลเชิงบริบทที่เกี่ยวข้องแก่โมเดล แบบไดนามิก ปัจจุบันหน้าต่างบริบทมีขนาดใหญ่ขึ้นเรื่อยๆ จึงมีเทคนิคใหม่ๆ ที่ช่วยให้สามารถใช้กับ Use Case ใหม่ๆ ได้

กรณีการใช้งานที่กำลังมาแรงและมาตรฐานสำหรับบริบทขนาดยาวที่เป็นข้อความมีดังนี้

• สรุปคลังข้อความขนาดใหญ่
  • ตัวเลือกการสรุปก่อนหน้านี้ที่มีโมเดลบริบทขนาดเล็กกว่าจะต้องใช้ หน้าต่างแบบเลื่อนหรือเทคนิคอื่นๆ เพื่อรักษาสถานะของส่วนก่อนหน้า เมื่อมีการส่งโทเค็นใหม่ไปยังโมเดล
• การถามและตอบ
  • ในอดีต การดำเนินการนี้ทำได้เฉพาะกับ RAG เนื่องจากบริบทมีจำนวนจำกัดและโมเดลเรียกคืนข้อเท็จจริงได้ต่ำ
• เวิร์กโฟลว์ของ AI ในการดำเนินการได้เอง
  • ข้อความเป็นรากฐานของวิธีที่เอเจนต์รักษาสถานะของสิ่งที่ทำไปแล้ว และสิ่งที่ต้องทำ การมีข้อมูลเกี่ยวกับโลก และเป้าหมายของเอเจนต์ไม่เพียงพอเป็นข้อจำกัดด้านความน่าเชื่อถือของเอเจนต์

การเรียนรู้ในบริบทแบบหลายตัวอย่างเป็นหนึ่งในความสามารถที่โดดเด่นที่สุดที่โมเดลบริบทแบบยาวปลดล็อก งานวิจัยแสดงให้เห็นว่า การใช้ตัวอย่าง "แบบนัดเดียวจบ" หรือ "แบบหลายนัดจบ" ที่พบได้ทั่วไป ซึ่งโมเดล จะได้รับตัวอย่างงาน 1-2 ตัวอย่าง และการขยายขนาดตัวอย่างเหล่านั้นเป็น หลายร้อย หลายพัน หรือแม้แต่หลายแสนตัวอย่าง อาจนำไปสู่ ความสามารถใหม่ๆ ของโมเดลได้ นอกจากนี้ แนวทางแบบหลายนัดยังแสดงให้เห็นว่ามีประสิทธิภาพ คล้ายกับโมเดลที่ได้รับการปรับแต่งสำหรับงานที่เฉพาะเจาะจง สำหรับกรณีการใช้งาน ที่ประสิทธิภาพของโมเดล Gemini ยังไม่เพียงพอสำหรับการเปิดตัว ในเวอร์ชันที่ใช้งานจริง คุณสามารถลองใช้แนวทางแบบหลายนัด ดังที่คุณอาจได้เห็นในส่วนการเพิ่มประสิทธิภาพบริบทแบบยาวในภายหลัง การแคชบริบททำให้ภาระงานของโทเค็นอินพุตสูงประเภทนี้มีความเป็นไปได้ทางเศรษฐศาสตร์มากขึ้น และยังช่วยลดเวลาในการตอบสนองในบางกรณีอีกด้วย

วิดีโอแบบยาว

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

กรณีการใช้งานที่กำลังมาแรงและมาตรฐานสำหรับบริบทแบบยาวของวิดีโอมีดังนี้

• การถามและตอบคำถามผ่านวิดีโอ
• หน่วยความจำวิดีโอ ดังที่แสดงใน Project Astra ของ Google
• การใส่คำบรรยายแทนเสียงในวิดีโอ
• ระบบวิดีโอแนะนำโดยการเพิ่มข้อมูลเมตาที่มีอยู่ด้วยความเข้าใจแบบมัลติโมดัลใหม่
• การปรับแต่งวิดีโอโดยดูจากคลังข้อมูลและข้อมูลเมตาวิดีโอที่เกี่ยวข้อง แล้วนำส่วนของวิดีโอที่ไม่เกี่ยวข้องกับผู้ชมออก
• การกลั่นกรองเนื้อหาวิดีโอ
• การประมวลผลวิดีโอแบบเรียลไทม์

เมื่อทำงานกับวิดีโอ สิ่งสำคัญคือต้องพิจารณาว่าวิดีโอได้รับการ ประมวลผลเป็นโทเค็นอย่างไร ซึ่งจะส่งผลต่อ การเรียกเก็บเงินและโควต้าการใช้งาน ดูข้อมูลเพิ่มเติมเกี่ยวกับการแจ้งโดยใช้ไฟล์วิดีโอได้ในคำแนะนำในการแจ้ง

เสียงแบบยาว

โมเดล Gemini เป็นโมเดลภาษาขนาดใหญ่ที่ทำงานได้กับข้อมูลหลายรูปแบบแบบเนทีฟ รุ่นแรกที่เข้าใจเสียง โดยปกติแล้ว เวิร์กโฟลว์ของนักพัฒนาซอฟต์แวร์จะ เกี่ยวข้องกับการเชื่อมโยงโมเดลเฉพาะโดเมนหลายรายการเข้าด้วยกัน เช่น โมเดลเสียงพูดเป็นข้อความและโมเดลข้อความเป็นข้อความ เพื่อประมวลผลเสียง ซึ่งส่งผลให้เกิดเวลาในการตอบสนองเพิ่มเติมที่จำเป็นโดยการส่งคำขอแบบไปกลับหลายครั้ง และประสิทธิภาพลดลงซึ่งมักเกิดจากสถาปัตยกรรมที่ไม่ได้เชื่อมต่อของ การตั้งค่าโมเดลหลายรายการ

กรณีการใช้งานที่กำลังมาแรงและมาตรฐานสำหรับบริบทเสียงมีดังนี้

• การถอดเสียงเป็นคำและการแปลภาษาแบบเรียลไทม์
• การถามและตอบคำถามเกี่ยวกับพอดแคสต์ / วิดีโอ
• การถอดเสียงเป็นคำและการสรุปการประชุม
• ผู้ช่วยแบบเสียง

ดูข้อมูลเพิ่มเติมเกี่ยวกับการแจ้งด้วยไฟล์เสียงได้ในคำแนะนำ การแจ้ง

การเพิ่มประสิทธิภาพบริบทที่ยาว

การเพิ่มประสิทธิภาพหลักเมื่อทำงานกับบริบทแบบยาวและโมเดล Gemini คือการใช้การแคชบริบท นอกจากข้อจำกัดก่อนหน้านี้ที่ ไม่สามารถประมวลผลโทเค็นจำนวนมากในคำขอเดียวได้แล้ว ข้อจำกัดหลักอีกอย่างก็คือ ค่าใช้จ่าย หากคุณมีแอป "แชทกับข้อมูลของคุณ" ที่ผู้ใช้ อัปโหลด PDF 10 รายการ วิดีโอ และเอกสารงานบางส่วน ในอดีตคุณจะต้อง ทำงานกับเครื่องมือ/เฟรมเวิร์กการสร้างการดึงข้อมูลที่เพิ่มประสิทธิภาพ (RAG) ที่ซับซ้อนมากขึ้น เพื่อประมวลผลคำขอเหล่านี้ และจ่ายค่าโทเค็นจำนวนมาก ที่ย้ายไปยังหน้าต่างบริบท ตอนนี้คุณสามารถแคชไฟล์ที่ผู้ใช้ อัปโหลดและชำระเงินเพื่อจัดเก็บไฟล์เหล่านั้นตามชั่วโมงได้แล้ว ตัวอย่างเช่น ต้นทุนอินพุต / เอาต์พุตต่อคำขอด้วย Gemini Flash จะน้อยกว่าต้นทุนอินพุต / เอาต์พุตมาตรฐานประมาณ 4 เท่า ดังนั้นหากผู้ใช้แชทกับข้อมูลของตนมากพอ คุณในฐานะนักพัฒนาแอปก็จะประหยัดค่าใช้จ่ายได้มาก

ข้อจำกัดของบริบทแบบยาว

ในส่วนต่างๆ ของคู่มือนี้ เราได้พูดถึงวิธีที่โมเดล Gemini บรรลุ ประสิทธิภาพสูงในการประเมินการดึงข้อมูลแบบเข็มในกองฟางต่างๆ การทดสอบเหล่านี้พิจารณาการตั้งค่าพื้นฐานที่สุด ซึ่งคุณมีเข็มเดียวที่กำลังมองหา ในกรณีที่คุณอาจมี "เข็ม" หลายเล่มหรือข้อมูลเฉพาะ ที่คุณกำลังมองหา โมเดลจะไม่ทำงานด้วยความแม่นยำเท่าเดิม ประสิทธิภาพอาจแตกต่างกันอย่างมากตามบริบท คุณควรพิจารณาเรื่องนี้เนื่องจากมีข้อแลกเปลี่ยนโดยธรรมชาติระหว่างการดึงข้อมูลที่ถูกต้องและการดึงข้อมูลที่คุ้มค่า คุณอาจได้รับผลลัพธ์ประมาณ 99% จากการค้นหาครั้งเดียว แต่ คุณต้องจ่ายค่าโทเค็นอินพุตทุกครั้งที่ส่งคำค้นหานั้น ดังนั้น หากต้องการดึงข้อมูล 100 รายการ และต้องการประสิทธิภาพ 99% คุณก็ อาจต้องส่งคำขอ 100 รายการ นี่เป็นตัวอย่างที่ดีที่การแคชบริบท สามารถลดต้นทุนที่เกี่ยวข้องกับการใช้โมเดล Gemini ได้อย่างมาก ในขณะที่ยังคงรักษาประสิทธิภาพไว้ในระดับสูง

คำถามที่พบบ่อย

ฉันควรวางคำค้นหาไว้ที่ใดในหน้าต่างบริบท

ในกรณีส่วนใหญ่ โดยเฉพาะอย่างยิ่งหากบริบททั้งหมดมีความยาว โมเดลจะทำงานได้ดีขึ้นหากคุณวางคำค้นหา / คำถามไว้ที่ส่วนท้ายของพรอมต์ (หลังจากบริบทอื่นๆ ทั้งหมด)

ประสิทธิภาพของโมเดลจะลดลงไหมเมื่อเพิ่มโทเค็นลงในคำค้นหา

โดยทั่วไปแล้ว หากไม่จำเป็นต้องส่งโทเค็นไปยังโมเดล คุณควรหลีกเลี่ยงการส่งโทเค็น อย่างไรก็ตาม หากคุณมีโทเค็นจำนวนมากที่มีข้อมูลบางอย่างและต้องการถามคำถามเกี่ยวกับข้อมูลนั้น โมเดลจะมีความสามารถสูงในการดึงข้อมูลดังกล่าว (ความแม่นยำสูงสุด 99% ในหลายกรณี)

ฉันจะลดต้นทุนด้วยการค้นหาที่มีบริบทแบบยาวได้อย่างไร

หากคุณมีชุดโทเค็น / บริบทที่คล้ายกันซึ่งต้องการนำกลับมาใช้หลายครั้ง การแคชบริบทจะช่วยลดค่าใช้จ่ายที่เกี่ยวข้องกับการถามคำถามเกี่ยวกับข้อมูลนั้นได้

ความยาวบริบทส่งผลต่อเวลาในการตอบสนองของโมเดลไหม

คำขอใดก็ตามจะมีเวลาในการตอบสนองที่แน่นอนไม่มากก็น้อย ไม่ว่าจะมีขนาดเท่าใดก็ตาม แต่โดยทั่วไปแล้ว คำขอที่ยาวกว่าจะมีเวลาในการตอบสนองที่สูงกว่า (เวลาในการแสดงโทเค็นแรก)