ปรับขนาดการสรุปฝั่งไคลเอ็นต์ในหน้าต่างบริบทขนาดเล็ก

เผยแพร่: 12 มีนาคม 2025 อัปเดตล่าสุด: 28 พฤษภาคม 2025

วิดีโออธิบาย เว็บ ส่วนขยาย สถานะ Chrome ความตั้งใจ
MDN Chrome 138 Chrome 138 ดู Intent to Ship

Summarizer API ช่วยสร้างสรุปข้อมูลในความยาวและรูปแบบต่างๆ ใช้กับ Gemini Nano ใน Chrome หรือโมเดลภาษาอื่นๆ ที่ฝังอยู่ในเบราว์เซอร์เพื่ออธิบายข้อความที่ยาวหรือซับซ้อนอย่างกระชับ

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

สรุปของสรุปคืออะไร

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

เช่น หากเอกสารแบ่งออกเป็น 3 ส่วน ระบบจะสรุปแต่ละส่วน ระบบจะรวมสรุปทั้ง 3 รายการเข้าด้วยกันและสรุปอีกครั้งเพื่อดูผลลัพธ์สุดท้าย

แบ่งเนื้อหาอย่างรอบคอบ

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

ซึ่งทำได้หลายวิธี ในตัวอย่างต่อไปนี้ เราใช้ Recursive Text Splitter จาก LangChain.js ซึ่งจะปรับสมดุลระหว่างประสิทธิภาพและคุณภาพเอาต์พุต ซึ่งควรใช้ได้กับปริมาณงานส่วนใหญ่

เมื่อสร้างอินสแตนซ์ใหม่ พารามิเตอร์หลักๆ มี 2 รายการดังนี้

  • chunkSize คือจํานวนอักขระสูงสุดที่อนุญาตในการแยกแต่ละรายการ
  • chunkOverlap คือจำนวนอักขระที่จะซ้อนกันระหว่างการแยก 2 ครั้งติดต่อกัน วิธีนี้ช่วยให้มั่นใจว่าแต่ละกลุ่มจะมีบริบทบางส่วนจากกลุ่มก่อนหน้า

แยกข้อความด้วย splitText() เพื่อแสดงผลอาร์เรย์สตริงที่มีแต่ละกลุ่ม

LLM ส่วนใหญ่มีหน้าต่างบริบทที่แสดงเป็นจํานวนโทเค็น ไม่ใช่จํานวนตัวอักษร โดยเฉลี่ยแล้ว โทเค็นจะมีอักขระ 4 ตัว ในตัวอย่างนี้ chunkSize มีความยาว 3, 000 อักขระ ซึ่งเท่ากับโทเค็นประมาณ 750 รายการ

กำหนดความพร้อมใช้งานของโทเค็น

หากต้องการดูจํานวนโทเค็นที่ใช้ได้สําหรับอินพุต ให้ใช้เมธอด measureInputUsage() และพร็อพเพอร์ตี้ inputQuota ในกรณีนี้ การใช้งานจะไม่มีขีดจํากัด เนื่องจากคุณไม่สามารถทราบจํานวนครั้งที่เครื่องมือสรุปจะทํางานเพื่อประมวลผลข้อความทั้งหมด

สร้างข้อมูลสรุปสำหรับการแยกแต่ละรายการ

เมื่อตั้งค่าวิธีแบ่งเนื้อหาแล้ว คุณสามารถสร้างสรุปสำหรับแต่ละส่วนด้วย Summarizer API

สร้างอินสแตนซ์ของเครื่องมือสรุปด้วยฟังก์ชัน create() เราได้ตั้งค่าพารามิเตอร์ format เป็น plain-text, type เป็น tldr และ length เป็น long เพื่อให้บริบทมากที่สุด

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

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

สรุปแบบเรียกซ้ำของสรุป

เมื่อคุณมีข้อความยาวมาก ความยาวของสรุปที่ต่อเชื่อมกันอาจใหญ่กว่ากรอบบริบทที่มีอยู่ จึงทําให้สรุปไม่สําเร็จ วิธีแก้ปัญหานี้คือคุณสามารถสรุปข้อมูลสรุปแบบซ้ำ

หากสรุปของสรุปยังยาวเกินไป คุณสามารถทำซ้ำขั้นตอนนี้ได้ ในทางทฤษฎีแล้ว คุณทำซ้ำขั้นตอนนี้ได้ไม่จำกัดจำนวนครั้งจนกว่าจะได้รับความยาวที่เหมาะสม

เรายังคงรวบรวมการแยกรายได้ครั้งแรกที่สร้างขึ้นโดย RecursiveCharacterTextSplitter จากนั้น ในฟังก์ชัน recursiveSummarizer() เราจะวนรอบกระบวนการสรุปตามความยาวของตัวอักษรของส่วนที่มีการต่อเชื่อม หากความยาวอักขระของข้อมูลสรุปเกิน 3000 เราจะต่อข้อมูลสรุปเป็น fullSummaries หากไม่ถึงขีดจํากัด ระบบจะบันทึกสรุปเป็น partialSummaries

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

เราได้ทดสอบโซลูชันนี้กับ Internet Relay Chat (IRC) RFC ซึ่งมีอักขระมากถึง 110,030 ตัว ซึ่งประกอบด้วยคํา 17,560 คํา Summarizer API ให้ข้อมูลสรุปดังต่อไปนี้

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

ถือว่ามีประสิทธิภาพดีทีเดียว และมีความยาวเพียง 309 อักขระ

ข้อจำกัด

เทคนิคสรุปของสรุปช่วยให้คุณทํางานภายในกรอบบริบทของโมเดลขนาดลูกค้าได้ แม้ว่าประโยชน์ของ AI ฝั่งไคลเอ็นต์จะมีประโยชน์มากมาย แต่คุณอาจพบปัญหาต่อไปนี้

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

เรามีตัวอย่างเครื่องมือสรุป และคุณสามารถดูซอร์สโค้ดแบบเต็มได้

แชร์ความคิดเห็น

ลองใช้เทคนิคสรุปของสรุปที่มีความยาวของข้อความอินพุตต่างกัน ขนาดการแยกต่างกัน และความยาวที่ซ้อนทับต่างกันด้วย Summarizer API