สร้างหน่วยความจำระยะยาวของการสนทนาใน LLM ด้วยการสรุปแบบเรียกซ้ำ

 (arxiv.org)
1 คะแนน โดย GN⁺ 2023-09-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แชตบอตสนทนาระยะยาวแม้จะมีหน้าต่างคอนเท็กซ์ขนาดใหญ่ ก็ยังยากที่จะสะท้อนแก่นสำคัญของปฏิสัมพันธ์ในอดีตลงในคำตอบได้อย่างเสถียร และงานวิจัยนี้ว่าด้วยวิธีลดปัญหาความสม่ำเสมอด้วย หน่วยความจำการสรุปแบบเรียกซ้ำ
  • ขั้นตอนหลักคือสร้างหน่วยความจำเริ่มต้นจากบทสนทนาสั้น ๆ ก่อน แล้วทุกครั้งที่มีการเพิ่มเซสชันใหม่ จะนำ หน่วยความจำเดิมกับบทสนทนาใหม่ มาสรุปร่วมกันเพื่ออัปเดตเป็นหน่วยความจำล่าสุด
  • วิธีแบบ retrieval-based ต้องพึ่งตัวค้นหาที่สามารถดึงคำพูดในอดีตที่จำเป็นได้อย่างแม่นยำ และวิธีแบบ memory-based เดิมอาจมี ข้อมูลเก่า ที่ไม่ได้รับการอัปเดตมารบกวนคุณภาพคำตอบ
  • ในการทดลองกับ LLM ทั้งแบบเปิดและปิด เช่น Llama, ChatGLM และ OpenAI GPT-3.5-Turbo ทั้งการประเมินอัตโนมัติและการประเมินโดยมนุษย์แสดงให้เห็นว่ามี ความสม่ำเสมอ ในการสนทนาระยะยาวสูงกว่าวิธีเดิม
  • วิธีนี้ยังใช้ร่วมกับหน้าต่างคอนเท็กซ์ยาวหรือ LLM แบบเสริม retrieval ได้ จึงอาจเป็นทางเลือกเชิงปฏิบัติสำหรับการจัดการ บริบทการสนทนาที่ยาวมาก โดยไม่ต้องเพิ่มความยาวของบทสนทนาทั้งหมดแบบตรง ๆ

ความจำของการสนทนาระยะยาวที่คอนเท็กซ์ยาวอย่างเดียวก็ยังไม่พอ

  • LLM อย่าง GPT-4 และ ChatGPT สามารถสนทนาได้อย่างไดนามิกและสอดคล้องกับบริบทในหัวข้อหลากหลาย แต่เมื่อเป็น การสนทนาระยะยาว ก็อาจพลาดข้อมูลในอดีตและสร้างคำตอบที่ไม่สม่ำเสมอได้
  • แม้หน้าต่างคอนเท็กซ์ยาวจะช่วยให้ป้อนประวัติการสนทนาทั้งหมดเป็นอินพุตได้ แต่ความสามารถในการเข้าใจปฏิสัมพันธ์ในอดีตและผสานข้อมูลสำคัญเข้ากับคำตอบก็ยังมีข้อจำกัด
  • กรณีตัวอย่างสำคัญที่ต้องอาศัยความทรงจำจากการสนทนาในอดีตคือ AI companion ส่วนบุคคลและบริการผู้ช่วยด้านสุขภาพ
    • AI companion ส่วนบุคคลต้องนึกถึงบทสนทนาก่อนหน้าเพื่อสร้างความสัมพันธ์
    • บริการผู้ช่วยด้านสุขภาพต้องพิจารณาประวัติคำถามของผู้ป่วยทั้งหมดเพื่อให้ผลการวินิจฉัย
  • ในตัวอย่างจาก Multi-Session Chat Dataset หลังจากผ่านไปราว 20 เทิร์น เมื่อผู้ใช้พูดถึงหัวข้อ “การแต่งเพลง” ในอดีตขึ้นมาอีกครั้ง ChatGPT เวอร์ชัน gpt-turbo-3.5-0301 ตอบว่าตนเป็น “โมเดลภาษา AI ที่ไม่มีอาชีพในความหมายดั้งเดิม” ทำให้เกิดคำตอบที่ ไม่สอดคล้อง กับ persona ก่อนหน้า

ข้อจำกัดของแนวทางแบบ retrieval-based และ memory-based

  • แนวทางหลักในการเสริมความสามารถของการสนทนาระยะยาวแบ่งได้เป็น วิธีแบบ retrieval-based และ วิธีแบบ memory-based
  • วิธีแบบ retrieval-based จะเก็บคำพูดในอดีตไว้ในสโตเรจ แล้วใช้ตัวค้นหาดึงประวัติที่เกี่ยวข้องกับการสนทนาปัจจุบันมากที่สุดมาใช้สร้างคำตอบ
    • ข้อจำกัดคือยากที่จะได้ตัวค้นหาในอุดมคติที่จับความหมายที่จำเป็นต่อบทสนทนาปัจจุบันได้อย่างครบถ้วน
  • วิธีแบบ memory-based จะใช้โมเดลที่ฝึกมาเฉพาะหรือ LLM ที่มีความสามารถสูงเพื่อสรุปบทสนทนาในอดีตและเก็บข้อมูลสำคัญไว้
    • หากขาดกลไกการอัปเดตแบบวนซ้ำ ข้อมูลเก่า ที่ถูกเก็บไว้อาจทำลายคุณภาพคำตอบโดยตรง
  • MemoChat จะจัดโครงสร้างประวัติการสนทนาในอดีตตามหัวข้อของผู้พูด และ prompt ให้ LLM ดึงข้อมูลจากหน่วยความจำแบบมีโครงสร้างระหว่างการสร้างคำตอบ
  • MemoryBank เสนอเมกานิซึมหน่วยความจำที่สร้างสรุปของแต่ละเซสชันก่อน แล้วบีบอัดต่อเป็นสรุประดับโกลบอล
    • หากหน่วยความจำที่เก็บไว้ถูกตรึงคงที่ทั้งหมด ก็ยากที่จะรับประกันความสอดคล้องกับบทสนทนาที่กำลังดำเนินอยู่

การสร้างหน่วยความจำที่อัปเดตแบบเรียกซ้ำ

  • วิธีที่เสนอเป็นแนวทางแบบปลั๊กอินที่เรียบง่าย โดยให้ LLM เองสร้างสรุปและอัปเดตพร้อมทบทวนบริบทในอดีตอย่างต่อเนื่อง เพื่อเก็บ ข้อมูลแบบเรียลไทม์ ของผู้พูด
  • กระบวนการประกอบด้วย 3 ขั้นตอน
    • LLM เชิงกำเนิดรับบริบทบทสนทนาสั้น ๆ เป็นอินพุตและสร้างสรุปเริ่มต้น
    • หลังจากนั้นจะรวมหน่วยความจำเดิมกับบทสนทนาภายหลัง แล้วอัปเดตสรุปหรือหน่วยความจำใหม่ต่อเนื่อง
    • แชตบอตจะใช้หน่วยความจำล่าสุดเป็นแหล่งอ้างอิงหลักเพื่อตอบการสนทนาปัจจุบัน
  • เนื่องจากสรุปที่สร้างขึ้นสั้นกว่าบทสนทนาทั้งหมดมาก จึงสามารถจัดการบริบทที่ยาวมากข้ามหลายเซสชันได้ โดยไม่ต้องเพิ่มความยาวอินพุตสูงสุดอย่างสิ้นเปลือง
  • การสนทนาระยะยาวถูกนิยามเป็น Multi-Session Dialogue ที่ประกอบด้วยหลายเซสชัน
    • ใช้ชุดของเซสชันในอดีต S = {S1, S2, ..., SN} บริบทการสนทนาของเซสชันปัจจุบัน Ct และคำตอบจริง rt
    • เป้าหมายคือสร้างคำตอบที่เกี่ยวข้องและมีความสม่ำเสมอสูงจากเซสชันในอดีตและบริบทปัจจุบัน
  • หน่วยความจำ Mi คือหน่วยความจำที่พร้อมใช้งานเมื่อจบเซสชันที่ i และกระบวนการทั้งหมดถูกนิยามเป็น กระบวนการแบบลำดับ ที่แต่ละหน่วยความจำขึ้นอยู่กับเพียงเซสชันปัจจุบันและหน่วยความจำก่อนหน้า

การวนซ้ำหน่วยความจำและการสร้างคำตอบ

  • วิธีที่เสนอให้ LLM ใด ๆ รับผิดชอบ 2 งาน
    • การวนซ้ำหน่วยความจำ: สรุปข้อมูลสำคัญแบบเรียกซ้ำตามลำดับของการสนทนาระยะยาว
    • การสร้างคำตอบโดยอิงหน่วยความจำ: รวมหน่วยความจำล่าสุดกับบทสนทนาปัจจุบันเพื่อสร้างคำตอบที่เหมาะสมและสม่ำเสมอ
  • การวนซ้ำหน่วยความจำคือกระบวนการเพื่อให้แชตบอตได้สรุปที่มีความสม่ำเสมอและอัปเดตล่าสุดสำหรับใช้งาน
  • งานวิจัยเดิมบางส่วนใช้ “ฮาร์ดโอเปอเรชัน” เช่น replace, append และ delete กับสรุปเพื่ออัปเดตหน่วยความจำ
    • วิธีเช่นนี้ต้องพึ่งบทสนทนาคุณภาพสูงที่มีป้ายกำกับโอเปอเรชัน รบกวนความสอดคล้องเชิงความหมายของสรุป และไม่เหมาะกับการจัดการระยะยาว
  • วิธีที่เสนอจะป้อนทั้งบริบทการสนทนาและหน่วยความจำก่อนหน้าเข้าไปพร้อมกัน เพื่อให้ LLM สร้างหน่วยความจำหรือสรุปแบบเรียกซ้ำ
    • การใช้สรุปก่อนหน้าช่วยให้โมเดลย่อยบริบทการสนทนาปัจจุบันได้ดีขึ้นและสร้างหน่วยความจำคุณภาพสูงได้
  • ในตัวอย่าง หลังจบเซสชันแรกจะมีการสร้างหน่วยความจำเริ่มต้น และหลังจบเซสชันที่สองจะมีการผสานข้อมูลลักษณะใหม่ว่า “บอตเพิ่งสมัครฟิตเนสใหม่ที่เปิด 24 ชั่วโมง” เข้ากับหน่วยความจำเดิม

ผลการทดลองและความเป็นไปได้ในการใช้งาน

  • การทดลองถูกทำบน LLM สมัยใหม่ทั้งแบบเปิดและปิด เช่น Llama, ChatGLM และ OpenAI GPT-3.5-Turbo
  • ประสิทธิภาพของการสนทนาระยะยาวสูงกว่าวิธียอดนิยมเดิมทั้งในการประเมินอัตโนมัติและการประเมินโดยมนุษย์
  • งานนี้ยืนยันทั้งประสิทธิผลของการใช้หน่วยความจำแบบชัดเจนกับการสนทนาระยะยาว และข้อเท็จจริงว่าหน่วยความจำที่สร้างด้วยวิธีนี้ย่อยง่ายกว่าสำหรับ LLM
  • เมื่อผสาน in-context learning (ICL) ก็สามารถเพิ่มคุณภาพคำตอบได้อีก
    • ป้อนตัวอย่างหลายชุดในรูปแบบ (บทสนทนา, หน่วยความจำ, คำตอบจริง) ให้ LLM
    • ช่วยให้ LLM ใช้หน่วยความจำที่สร้างขึ้นได้อย่างยืดหยุ่นมากขึ้น
  • ใน text-davinci-003 คะแนน BLEU ดีขึ้นราว +3%
  • วิธีที่เสนอสามารถเสริม LLM ที่มีหน้าต่างคอนเท็กซ์ยาว เช่น GPT-3.5-Turbo-16k, LongLoRA-8k และ LLM แบบเสริม retrieval เช่น LLM-BM25, LLM-DPR
  • โค้ดสาธารณะมีให้ที่ qingyue2014/Rsum

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-09-04
ความเห็นจาก Hacker News

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

    • อาจดูแฮ็ก ๆ ก็จริง แต่แนวคิดของ LLM แบบสนทนา เองก็ถือว่าเป็นแบบนั้นได้เหมือนกัน
      สุดท้ายก็คือการสั่งให้มันเติมคำถัดไปอีกหนึ่งคำต่อจากบทสนทนาที่ให้มา และเมื่อถึงจุดหนึ่งมันส่งโทเคนจบออกมา แอปพลิเคชันก็คืนการควบคุมให้ผู้ใช้อีกครั้ง
      ผมคิดว่าพื้นที่ latent กับพื้นที่ข้อความไม่ได้ห่างกันอย่างที่คิด LLM ค่อนข้างทื่อ แต่เก่งมากเรื่องการพูด และการเขียนโค้ดก็คล้ายกันคือทำได้ดี แต่จะพังเมื่อเจอโดเมนที่ต้องใช้การคิดเชิงนามธรรมจริง ๆ อย่างคณิตศาสตร์
      การแฮ็กพื้นที่ข้อความแบบนี้ใช้ได้ผลจริงค่อนข้างดี และนั่นเป็นเหตุผลที่พรอมป์ต์อย่าง “คิดทีละขั้น” กลายเป็นเรื่องปกติ
      LoRA ใกล้เคียงกับทิศทางที่พูดถึงมากกว่า และยอดเยี่ยมในการอัดความเข้าใจจำนวนมากไว้ในข้อมูลเพียงเล็กน้อย แต่การปรับ weight เพื่อบทสนทนาเดียวในตอนนี้ยังไม่สมจริง จึงกำลังสำรวจพื้นที่ข้อความสำหรับการใช้งานนั้นอยู่
    • ลองคิดว่าใช้วิธีนี้ในหัวของตัวเองก็ได้ ถ้าสรุปการสนทนาที่ผ่านมาซ้ำแบบ recursive อาจช่วยให้จำได้ดีขึ้น
      การสรุปอะไรบางอย่างในหัวอาจรู้สึก “แฮ็ก ๆ” แต่ผมคิดว่าส่วนใหญ่ของ วิธีที่ความจำทำงานจริง ก็คล้ายกับสิ่งนั้น
    • น่าสนใจที่วิธีสร้างสรุปซ้ำไปเรื่อย ๆ ไม่ได้ต่างจากวิธีที่เชื่อว่าสมองมนุษย์ หรืออย่างน้อย ความจำระยะยาว ทำงาน มากนัก
      https://news.northwestern.edu/stories/2012/09/your-memory-is...
    • แทบทุกอย่างในการประมวลผลที่เราใช้กันทุกวันนี้ก็เช่นกัน โดยแก่นแล้วมักเป็น สิ่งประกอบที่แฮ็ก ๆ เพียงแต่ถูกทำให้เป็นนามธรรมมากพอและมีการจัดการข้อผิดพลาดเสริมเข้ามา จึงไม่ดูเหมือนการแฮ็ก
    • สงสัยว่าทำไมถึงมีสัญชาตญาณว่า พื้นที่ embedding แบบหนาแน่นจะสามารถ รักษาความหมายได้ครบถ้วน
      ตามที่ผมเข้าใจ embedding โดยธรรมชาติใกล้เคียงกับการบีบอัดแบบสูญเสียข้อมูล ถ้าเป็นการสรุปข้อความ อย่างน้อย agent ก็ยังตรวจสอบได้ว่าสรุปนั้นแทนข้อมูลเดิมได้ถูกต้องหรือไม่

  • ที่ CodeRabbit เราใช้วิธีแบบนี้อยู่แล้วสำหรับ การรีวิว PR แบบค่อยเป็นค่อยไป และการสนทนาในบริบทของการเปลี่ยนแปลงโค้ด
    มันทำให้บ็อตดูเหมือนมีบริบทมากกว่าความเป็นจริงมาก และเป็นหนึ่งในเทคนิคหลายอย่างที่เราใช้เพื่อขยายการรีวิวโค้ดด้วย AI ไปถึง PR ขนาดใหญ่ (มากกว่า 100 ไฟล์)
    ในแต่ละ commit จะสรุป diff แยกตามไฟล์ จากนั้นสร้างสรุปของสรุปอีกที และอัปเดตแบบค่อยเป็นค่อยไปทุกครั้งที่มี commit เพิ่มใน PR สรุปของสรุปเหล่านี้ถูกซ่อนและเก็บไว้ในคอมเมนต์ของ PR และใช้เมื่อตรวจรีวิวแต่ละไฟล์หรือเมื่อตอบคำถามผู้ใช้
    โค้ดบางส่วนเป็นโอเพนซอร์ส และพรอมป์ต์ที่เกี่ยวข้องซึ่งใช้กับการสรุปแบบ recursive อยู่ที่นี่: https://github.com/coderabbitai/ai-pr-reviewer/blob/main/src...
    [0]: coderabbit.ai

    • สงสัยว่ามีปัญหาเวลาพาร์สผลลัพธ์ของพรอมป์ต์หรือไม่
      ถ้ามี ก็สงสัยว่าเคยลองใช้ function calling แทนการพาร์สเอาต์พุตข้อความอิสระหรือยัง

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

    • เห็นด้วย นี่เป็นไอเดียที่เรียบง่ายมากซึ่งไม่ต้องใช้โค้ดเยอะ ดังนั้นการจัดระเบียบและเผยแพร่ไม่น่าจะยาก
      ผมเคยทดลองไอเดียคล้าย ๆ กันมาก่อนโดยปรับพรอมป์ต์เองใน API dashboard แม้จะดูมีศักยภาพ แต่ก็ไม่ได้ดูคุ้มค่าเท่ากับค่า API บางที วิธีแบบ vector embedding อาจดีกว่ามาก

  • จากกรณีส่วนตัว บริษัทมี “Briefings” เป็นการประชุม panel แบบออฟไลน์ยาวหนึ่งชั่วโมง บางครั้งยาวทั้งวัน อยู่หลายพันรายการ
    ผมสรุปแต่ละ briefing ได้สำเร็จ และ transcript ที่รก ๆ ก็ถูกจัดระเบียบเป็น สรุปห้าย่อหน้า ได้ดี
    ส่วนที่เกี่ยวข้องกว่านั้นคือ เราจัดหมวดหมู่แต่ละ briefing เป็นหัวข้อและหัวข้อย่อยแบบ 1:N โดยมี briefing หลายสิบรายการอยู่ในแต่ละหัวข้อ และราวสิบกว่ารายการในแต่ละหัวข้อย่อย จากนั้นนำชุดย่อยของสรุปที่เกี่ยวข้องมาสรุปซ้ำเพื่อทดสอบอย่างกว้างขวาง ซึ่งได้ผลลัพธ์ดีมากด้วย LLM
    ตอนแรกผมสงสัยว่าจะทำได้หรือไม่ แต่กลับทำงานได้ดีมาก ถ้ามีหน้าต่าง context ที่ใหญ่พอ ก็คงไม่ทำแบบนี้ แต่โชคดีที่มันไม่เป็นปัญหา

    • ถึงหน้าต่าง context จะใหญ่ เทคนิคนี้ก็ยังมีประโยชน์
      ผมคิดว่าการแบ่งปัญหาเหมือน MapReduce ทำได้ดีกว่าการยัดทุกอย่างเข้าไปในหน้าต่าง context ขนาดยักษ์ 32k แล้วให้แก้ทีเดียวมาก

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

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

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

    • ถ้าดูหน้าสุดท้าย จะมี พรอมป์ อยู่
    • ยังเขียนไว้ด้วยว่า “โค้ดและสคริปต์จะเผยแพร่ภายหลัง”
      ชักอยากลองเขียนบทความแบบนี้สักไม่กี่ชิ้นเหมือนกัน สงสัยว่าต้องเขียนกี่ชิ้นถึงจะติดตำแหน่ง “ML researcher” ไว้บนสุดของเรซูเม่ได้
    • รู้สึกเหมือนเอาหัวข้อเรียบง่ายไปยัดใส่รูปแบบบทความวิทยาศาสตร์ แล้วทำให้มันซับซ้อนขึ้นมาก
      ควรใช้เวลากับตัวอย่างและพรอมป์มากกว่านี้มาก

  • ผมเคยเขียนทำนองเดียวกันเมื่อไม่กี่สัปดาห์ก่อน แต่ผู้คนทำให้ส่วน การสรุป เรียบง่ายเกินไป: https://news.ycombinator.com/item?id=37117515
    คุณค่าของหน่วยความจำระยะยาวมีความละเอียดอ่อนแตกต่างกันไปตามแต่ละ use case
    ถ้าคุณกำลังสร้างผู้ช่วยในบ้าน ก็ควรใช้ NER เพื่อระบุชื่อ และเข้าใจว่าคนคนนั้นชอบให้พูดกับเขาด้วยน้ำเสียงแบบใด รวมถึงเข้าใจสถานที่และวิธีการเดินทาง
    ถ้าคุณกำลังสร้างบอตบริการลูกค้า ก็ควรระบุคำถามที่ต่อเนื่องเป็นบทสนทนายาว ๆ หรือคำถามที่นำไปสู่การทิ้งตะกร้าสินค้าอย่างกะทันหัน
    แค่ระดับการสรุปทั่วไปก็ทำเดโมที่ดูหวือหวาได้ แต่ถ้าจะสร้างผลิตภัณฑ์ที่มีประโยชน์จริงในตอนนี้ ต้องไปไกลกว่านั้นอีกขั้น

  • ไม่ค่อยแน่ใจว่าตรงนี้มีอะไรใหม่
    การสรุปหน่วยความจำประวัติแชตด้วย LLM เป็นเทคนิคที่รู้จักกันดีและมีใช้อยู่แล้วใน LLM framework จำนวนมาก ถ้าสรุปทุกข้อความแบบในบทความวิจัย จะกลายเป็น คอขวดด้านประสิทธิภาพ ใหญ่ และเพิ่มความหน่วงให้กับลูปแชตอย่างมาก
    การใช้งานจำนวนมากใช้บัฟเฟอร์ขนาดคงที่ แล้วค่อย ๆ สรุปชุดความจำเก่าที่ถูกดันออกนอกบัฟเฟอร์ ตามอุดมคติ งานนี้ก็ควรถูกจัดการนอกลูปแชตด้วย
    ผมเป็นหนึ่งในผู้เขียน Zep ซึ่งเป็นที่เก็บหน่วยความจำระยะยาวแบบโอเพนซอร์ส และเราใช้การสรุปในลักษณะนี้
    0: https://github.com/getzep/zep

    • Aider ก็ทำแบบนี้ โดยสรุปข้อความที่เก่ากว่า N ข้อความล่าสุดใน เธรดเบื้องหลัง
      https://github.com/paul-gauthier/aider/blob/main/aider/histo...
    • ผมเองก็ยังค่อนข้างมือใหม่ แต่เคยฟังคอร์ส LangChain หนึ่งชั่วโมงของ Andrew Ng และในนั้นพูดถึง การสรุปแบบเรียกตัวเอง ว่าเป็นเทคนิคมาตรฐานในการจัดการหน่วยความจำ
      https://www.deeplearning.ai/short-courses/langchain-for-llm-...
    • ใช่ ไม่มีอะไรใหม่เลย ผู้ใช้ ChatGPT ระดับมัธยมต้นก็น่าจะรู้

  • เรื่องนี้อาจจะเฉออกไปจากบทความหรือการถกเถียงเล็กน้อย แต่หน่วยความจำสั้นเป็นข้อจำกัดจริง
    อย่างไรก็ตาม ผมคิดว่าคำวิจารณ์ส่วนใหญ่ต่อความสามารถของ GPT-4 ก็ใช้กับมนุษย์ได้เหมือนกัน หรืออาจรุนแรงกว่าด้วยซ้ำ
    ในสถานการณ์ การทดสอบทัวริงแบบย้อนกลับ ผมไม่คิดว่าจะมีคนมีชีวิตคนไหนโน้มน้าวผมได้ว่าตัวเองคือ GPT-4 แค่คำตอบที่รวดเร็วและเป็นระเบียบของ GPT-4 ก็เหนือกว่าความสามารถมนุษย์แล้ว
    แม้กระทั่งถ้าทีมมนุษย์มีเวลาตอบคำถามละ 60 นาที ก็อาจตามคำตอบของ GPT-4 ต่อคำถามที่น่าสนใจได้ยาก น่าจะเป็นการแข่งขันที่สนุกดี

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