บริบทแบบยาว

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

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

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

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

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

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

ใน Gemini 4 (gemini-4-argon) หน้าต่างบริบทขนาด 1 ล้านโทเค็นจะแชร์กันระหว่างโทเค็นอินพุต โทเค็นการคิด และโทเค็นเอาต์พุต และโมเดลสามารถสร้างโทเค็นเอาต์พุตได้สูงสุด 1 ล้านโทเค็นโดยใช้การถอดรหัสแบบยาว หากโทเค็นอินพุตบวก max_output_tokens เกิน 1,048,576 โทเค็น API จะจำกัดเอาต์พุตโดยอัตโนมัติให้เหลือพื้นที่ในหน้าต่างบริบท (1,048,576 ลบด้วยโทเค็นอินพุต) โมเดล Gemini 3 และ 2.5 รุ่นก่อนหน้าใช้โควต้าอินพุต 1 ล้านโทเค็นและเอาต์พุต 64,000 โทเค็นแยกกัน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เสียงแบบยาว

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

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

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

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

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

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

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

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

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

ตำแหน่งที่ดีที่สุดในการวางการค้นหาของฉันในหน้าต่างบริบทคือที่ใด

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

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

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

ฉันจะลดค่าใช้จ่ายในการค้นหาบริบทแบบยาวได้อย่างไร

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

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

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