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

André Cipriani Bandarra
Alexandra Klepper

เผยแพร่: 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