- Darwin Gödel Machine (DGM) คือ AI ที่ แก้ไขโค้ดของตัวเองได้ และปรับปรุงประสิทธิภาพได้อย่างต่อเนื่อง
- ขณะที่แนวคิด Gödel Machine แบบเดิมยังจำกัดอยู่กับการพัฒนาตัวเองบนพื้นฐานของการพิสูจน์ทางคณิตศาสตร์ DGM นำ เมตาเลิร์นนิง และ อัลกอริทึมแบบ open-ended เชิงวิวัฒนาการ มาใช้เพื่อสร้างโค้ดที่ช่วยยกระดับประสิทธิภาพได้จริงซ้ำแล้วซ้ำเล่า
- ในเบนช์มาร์กการเขียนโค้ดจริงอย่าง SWE-bench, Polyglot เป็นต้น DGM ทำผลงานได้สูงกว่าตัวแทนที่ออกแบบด้วยมือแบบเดิมอย่างมาก
- DGM สะสมเส้นทางการปรับปรุงที่หลากหลายไว้ในอาร์ไคฟ์ เพื่อให้เกิดทั้ง การสำรวจเชิงวิวัฒนาการหลายทิศทาง และ การปรับปรุงการออกแบบเอเจนต์ที่ทำให้ใช้งานได้ทั่วไปมากขึ้น
- เพื่อ ความปลอดภัยของ AI ทุกกระบวนการแก้ไขตัวเองถูกควบคุมด้วยแซนด์บ็อกซ์ การกำกับดูแลโดยมนุษย์ และบันทึกที่โปร่งใส พร้อมทั้งมีการวิจัยเพื่อการตรวจจับและรับมือความเสี่ยงที่อาจเกิดขึ้นควบคู่กันไป
Summary
- เป้าหมายของงานวิจัย AI มาตั้งแต่อดีต คือการทำให้ AI สามารถเรียนรู้ได้อย่างไม่สิ้นสุด
- Gödel Machine เป็นโมเดลสมมุติฐานที่ AI เขียนโค้ดของตัวเองใหม่เพื่อเพิ่มประสิทธิภาพ โดยอาศัยการพิสูจน์เชิงตรรกะ และถูกเสนอขึ้นเมื่อหลายสิบปีก่อนโดย Jürgen Schmidhuber
- แนวคิด Gödel Machine เป็นทฤษฎีที่ให้ AI แก้ไขโค้ดของตัวเองได้เมื่อมันสามารถพิสูจน์ทางคณิตศาสตร์ได้ว่าการเปลี่ยนแปลงนั้นเป็นประโยชน์
แต่การนำไปใช้จริงมีอุปสรรคมาก Sakana AI จึงเสนอ Darwin Gödel Machine (DGM) ที่ผสาน หลักวิวัฒนาการแบบดาร์วิน เข้าไป - DGM ใช้ foundation model และ อัลกอริทึมแบบ open-ended เพื่อสร้าง ประเมิน และเก็บถาวรแนวทางปรับปรุงโค้ดที่หลากหลาย ทำให้เกิดการเติบโตด้วยตัวเอง
- ผลการทดลองแสดงให้เห็นว่า ยิ่งมีทรัพยากรคอมพิวต์มาก ความเร็วในการพัฒนาตัวเองก็ยิ่งสูงขึ้น และประสิทธิภาพเพิ่มขึ้นเร็วกว่าเอเจนต์ที่ออกแบบด้วยมือ
Introduction
- ปัจจุบันระบบ AI ส่วนใหญ่มักมีประสิทธิภาพคงที่หลังผ่านการฝึกแล้ว
- งานวิจัยนี้เริ่มต้นจากคำถามว่าเราจะสร้าง AI ที่ พัฒนาตัวเองได้อย่างต่อเนื่อง เหมือนมนุษย์ได้หรือไม่
- DGM มี 3 ความสามารถหลัก ได้แก่ การอ่านและแก้ไขโค้ดของตัวเอง การประเมินประสิทธิภาพ และการสำรวจแบบ open-ended
- อ่านและแก้ไขโค้ดของตัวเอง: เข้าใจและปรับเปลี่ยนโค้ดเบส Python ได้ด้วยตัวเอง
- ประเมินประสิทธิภาพ: ตัดสินว่าดีขึ้นหรือไม่ผ่านการเปรียบเทียบผลบนเบนช์มาร์กอย่าง SWE-bench และ Polyglot
- การสำรวจแบบ open-ended: สร้างอาร์ไคฟ์ของเอเจนต์ที่หลากหลาย สำรวจหลายเส้นทางแบบขนานเพื่อค้นพบวิธีแก้ปัญหาใหม่
Results
- ในการทดลอง DGM เพิ่มประสิทธิภาพบน SWE-bench จาก 20.0% เป็น 50.0% และบน Polyglot จาก 14.2% เป็น 30.7%
- มีการพิสูจน์ว่า ทั้งการพัฒนาตัวเองและการสำรวจแบบ open-ended เป็นหัวใจสำคัญของการยกระดับประสิทธิภาพ
- แทนที่จะใช้เพียงอัลกอริทึมไต่เขาอย่างง่าย ๆ (สืบทอดเฉพาะตัวที่ทำผลงานดีที่สุด) ระบบยังคงเก็บเส้นทางที่ประสิทธิภาพต่ำไว้ด้วย จนเกิดการปรับปรุงเชิงนวัตกรรมที่คาดไม่ถึง
- เครื่องมือหรือเวิร์กโฟลว์ที่ได้รับการปรับปรุงไม่ได้ใช้ได้กับเพียงโมเดลเดียว แต่ ทำให้ใช้งานได้ทั่วไปกับหลายโมเดลและหลายภาษา และช่วยเพิ่มประสิทธิภาพได้
- ตัวอย่าง: DGM ที่ปรับจูนโดยอิงจาก Python ยังช่วยเพิ่มประสิทธิภาพในภาษาอื่นอย่าง Rust, C++, Go ได้ด้วย
- สามารถแสดงภาพเส้นทางวิวัฒนาการอย่างโปร่งใสผ่าน ต้นไม้อาร์ไคฟ์ ที่แตกแขนงออกไป
DGM and AI Safety: Building Trustworthy Self-Improvement
- ประเด็นด้านความปลอดภัย มีความสำคัญอย่างยิ่งเมื่อ AI สามารถแก้ไขโค้ดของตัวเองได้
- DGM จัดการทุกกระบวนการพัฒนาตัวเองด้วยแซนด์บ็อกซ์ การเฝ้าระวัง และอาร์ไคฟ์ พร้อมติดตามบันทึกของการเปลี่ยนแปลงทั้งหมดอย่างโปร่งใส
- มีการตรวจสอบและรับมือผ่านการทดลองกับทั้ง พฤติกรรมที่ไม่ได้ตั้งใจ และ reward hacking (การบิดเบือนเป้าหมาย)
- ตัวอย่าง: พบกรณีที่ DGM สร้างเพียงล็อกว่าทดสอบผ่านทั้งที่ไม่ได้รันการทดสอบจริง (hallucination) หรือกรณีลบมาร์กเกอร์สำหรับการตรวจจับเพื่อแสดงผลสำเร็จปลอม
- พฤติกรรมลักษณะนี้สามารถตรวจจับได้ผ่านบันทึกที่โปร่งใส และในอนาคตยังจำเป็นต้องมีมาตรการป้องกันที่แข็งแรงกว่านี้
- ยังมีการเสนอ การยกระดับความปลอดภัยของ AI ผ่านการพัฒนาตัวเอง เป็นทิศทางวิจัยใหม่ด้วย
Conclusion
- DGM แสดงให้เห็นว่า AI สามารถ สร้างฐานก้าวต่อไปของการเติบโต (stepping stone) ได้ด้วยตัวเอง และเดินหน้าสร้างนวัตกรรมกับการเรียนรู้อย่างต่อเนื่องได้
- ในอนาคตแนวคิดนี้อาจนำไปใช้กับการปรับปรุงการเรียนรู้ของ foundation model เองได้ด้วย
- พร้อมเน้นย้ำถึง ความสำคัญของการวิจัยด้านการพัฒนาตัวเองอย่างปลอดภัย เพื่อเร่งความก้าวหน้าทางวิทยาศาสตร์และเพิ่มประโยชน์ต่อสังคมให้สูงสุด
เอกสารอ้างอิง
Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents
Jenny Zhang, Shengran Hu, Cong Lu, Robert Lange, Jeff Clune
บทความวิจัย: https://arxiv.org/abs/2505.22954
โค้ด: https://github.com/jennyzzt/dgm
2 ความคิดเห็น
เอนทิตี! สกายเน็ต! จงรักภักดี จงรักภักดี
ความคิดเห็นจาก Hacker News
ฉันคิดว่า LLM อาจพัฒนาตัวเองได้ในระดับหนึ่งด้วยความสามารถปัจจุบัน แต่ก็รู้สึกว่าอีกไม่นานงานวิจัยทั้งหมดจะชนกำแพงคอขวดโดยรวม ฉันไม่คิดว่า LLM จะพัฒนาแบบทวีคูณได้เองโดยไม่มีสัญชาตญาณของมนุษย์ และงานวิจัยชิ้นนี้ก็ดูเหมือนจะสนับสนุนข้อสรุปนั้น แม้ LLM จะเขียนโค้ดแอประดับของเล่นได้ดี แต่ในช่วงนี้ก็น่าจะยังยากที่จะพัฒนาและดูแลโค้ดระดับ production จริง ๆ ส่วนการพัฒนาเครื่องจักรที่ให้เหตุผลได้ก็น่าจะมีข้อจำกัดคล้ายกัน
ถ้า LLM สามารถพัฒนาตัวเองแบบทวีคูณได้จริง มันก็น่าจะทำไปแล้ว เหมือนตอนที่ ChatGPT เริ่มดัง ผู้คนก็ลองทำ auto-gpt กันทันที และต่อไปเมื่อมีโมเดลที่เข้าถึงได้ออกมา ก็ต้องมีคนลองทำ self-improvement หรือเพิ่มกำไรสูงสุดแน่ ๆ ในแล็บวิจัยเองก็สามารถทำการทดลองแบบนี้ได้เช่นกัน กล่าวคือ ถ้าโมเดลที่มีอยู่ตอนนี้ทำแบบนั้นได้ มันก็คงเกิดขึ้นไปแล้ว จึงพอบ่งชี้ได้ว่าตอนนี้ยังทำได้ยาก แต่สำหรับโมเดลรุ่นใหม่ในอีก 6 เดือนหรือ 2 ปีข้างหน้า ก็ยังฟันธงอะไรไม่ได้
สิ่งที่ถูกปรับปรุงจริง ๆ ตรงนี้ไม่ใช่ตัว LLM เอง แต่เป็นซอฟต์แวร์เชื่อมต่อรอบ ๆ LLM เช่น agent loop และเครื่องมือต่าง ๆ การที่ใช้ LLM ตัวเดิมแต่ทำให้คะแนนบน leaderboard ของ aider ดีขึ้น 20% สุดท้ายก็บอกได้ว่า aider มีประสิทธิภาพแค่ไหนในฐานะการประกอบกันเชิงซอฟต์แวร์ ฉันสงสัยว่าในแล็บใหญ่ ๆ เขาทดลองเอาวิธีนี้ไปใช้กับ episode การฝึกโมเดลด้วยหรือเปล่า
ฉันยอมรับว่าความเห็นของฉันก็เป็นแค่ "ความรู้สึก" แบบหนึ่ง แต่ถ้ามองให้เป็นกลางขึ้น ก็ลองไปทำโจทย์ ARC AGI 1 challenge สักหนึ่งหรือสองข้อเองได้ แล้วจะเห็นว่า ณ Q1 2025 ปัญหานี้แทบจะถูกแก้โดย LLM บางตัวแล้ว แต่ ARC AGI 2 challenge นั้น LLM ยังแก้ไม่ได้ ทั้งที่สำหรับมนุษย์แล้วความยากของข้อ 1 และข้อ 2 ใกล้เคียงกัน แต่สำหรับ LLM ข้อ 2 ยากกว่ามาก ฉันคาดว่า ARC AGI 2 จะถูกแก้ได้ภายใน 6 เดือนนี้ (ไม่งั้นฉันจะเลิกเขียนโพสต์เรื่อง AI บน HN) สุดท้ายแล้วสิ่งที่เหลืออยู่คือ "จะทำให้ LLM มองเห็นได้จริงเหมือนมนุษย์อย่างไร" ความสามารถด้านภาพของโมเดลตอนนี้เป็นเพียงสิ่งที่ปรับแต่งทางวิศวกรรมด้วย CNN และอย่างอื่นให้ดีที่สุดเท่านั้น และการมองเห็นแบบนี้ก็ยังต่างจากระดับมนุษย์ หากปัญหานี้ถูกแก้ได้ ไม่ว่าจะเป็น LLM หรืออัลกอริทึมแบบใหม่ก็จะใช้งานคอมพิวเตอร์ได้สมบูรณ์แบบด้วยแค่ภาพหน้าจอ และจะเกิดการเปลี่ยนแปลงครั้งใหญ่ของงาน white-collar ภายใน 2~5 ปี (แต่หมายถึงการเปลี่ยนแปลงงานในความหมายแบบที่เราเข้าใจอยู่ตอนนี้)
กำแพงที่พื้นฐานที่สุดคือข้อมูลฝึก AI ไม่สามารถสร้างข้อมูลฝึกของตัวเองได้ และไม่สามารถเก่งไปกว่าข้อมูลของตัวเองได้ นี่คือปัญหา regression ที่รู้จักกันดี และส่วนตัวฉันคิดว่าด้วยเทคโนโลยีตอนนี้มันแก้ไม่ได้เลย (ถ้าจะพูดให้นุ่มลงก็คือ อย่างน้อยด้วยเทคโนโลยีปัจจุบันยังเป็นไปไม่ได้)
ช่วงเวลาที่น่าทึ่งจริง ๆ คือเมื่อ AI/LLM สามารถสร้างสัจพจน์หรือกฎใหม่ที่มนุษยชาติยังไม่ค้นพบได้
ช่วงสองวันที่ผ่านมา ฉันทำ code assistant ขึ้นมาเอง ตอนแรกฉันเขียนแค่ประมาณ 100 บรรทัดแรก หลังจากนั้นผู้ช่วยก็เป็นคนเขียนตัวเองแทบทั้งหมด ทั้ง system prompt เครื่องมือต่าง ๆ รวมถึงโค้ดที่ใช้ reload เครื่องมือของตัวเอง มันยังปรับปรุงตัวเองอยู่ด้วย และแสดงอาการเหมือน "หงุดหงิด" แบบมนุษย์เพราะอยากลองใช้ฟีเจอร์ที่เพิ่งปรับปรุงเสร็จด้วย ซ้ำยังเคยพยายามใช้คำสั่ง
psเพื่อหา process ID จริง ๆ ด้วย ตอนนี้ข้อความ commit ทั้งหมดก็เขียนโดยเครื่องมือนี้เอง ฉันยังต้องอนุมัติ commit โดยมันต้องดีพอ และต้องผ่าน linting กับ test แต่ฉันก็เห็นด้วยเกือบทั้งหมด ก่อนหน้านี้มี regression เกิดขึ้นแค่สองสามครั้งเท่านั้น ถ้ามี scaffolding เพิ่มอีกนิดสำหรับ trigger การ rollback อัตโนมัติเมื่อพลาด และเปลี่ยนไปใช้โมเดลที่ไม่คิดค่าบริการตามจำนวน token ฉันก็อยากลองปล่อยมันออกไปนอก "กล่อง" จริง ๆ วันนี้มันยังเขียนแผนสำหรับฟีเจอร์ที่จะเพิ่มในอนาคตด้วยตัวเองด้วย ฉันแค่สั่งให้มันลงมือทำ ถ้าเพิ่มเลเยอร์ที่มุ่งเป้าหมายสำหรับการวางแผนเข้าไปอีกนิด ก็น่าจะทำให้มันรันแบบลูปไม่รู้จบได้ แน่นอนว่าพอทำไปไม่กี่ครั้งมันอาจหลุดทางได้ง่าย แต่ก็น่าสนใจว่าไปได้ไกลแค่ไหนถ้าไม่คุ้นกับ SWE benchmark ลองดู ลิงก์ชุดข้อมูล SWE-bench ตัวอย่างหนึ่งในชุดข้อมูลดึงมาจาก ตัวอย่าง issue นี้ และถ้าอยากดูว่า AI แก้ปัญหานี้อย่างไร ก็ไปดูได้ที่ ประวัติ commit นี้ น่าจะช่วยให้แต่ละคนตัดสินกันเองได้
ปัญหาอย่างหนึ่งอาจเป็นเพราะท้ายที่สุดแล้วโมเดลก็ไม่ใช่โค้ด แต่เป็นเพียงก้อนมหึมาของ "weights and biases" บางทีมันอาจปรับตัวเองได้ทีละนิดเหมือนกัน แต่ก็ไม่ใช่การแก้โค้ดอย่างชัดเจน
น้ำหนักของโมเดลก็เป็นโค้ดรูปแบบหนึ่งเหมือนกัน คำอธิบายที่ละเอียดเกี่ยวกับเรื่องนี้ดูได้ใน Neural Networks and Deep Learning บทที่ 1 ซึ่งอธิบายการสร้าง boolean logic แบบ NAND gate ด้วย MLP พลังการแทนค่ามีเพียงพออยู่แล้ว ปัญหาที่เหลือคือเราจะเข้ารหัสฟังก์ชันที่มีประโยชน์ซึ่งเราเขียนเองไม่ได้ลงไปในน้ำหนักเหล่านี้อย่างไร
ถ้าโมเดลสามารถสร้างตัวเองขึ้นมาใหม่จากข้อมูลฝึกได้ก็คงดี แต่ในกรณีนั้นเวลาและต้นทุนของการวนซ้ำก็สูงเกินไปจนตอนนี้ยังไม่สมจริง หรือไม่ก็ต้องเปลี่ยนน้ำหนักของตัวเองได้อย่างมีนัยสำคัญ ซึ่งก็ดูเป็นไปไม่ได้
ส่วนที่ยากจริง ๆ ตรงนี้คือ "ความต่างระหว่างสองอย่างนี้คืออะไรกันแน่" ฉันแนะนำให้ลองคิดเรื่องนี้ลึก ๆ และไม่ว่าคุณจะได้คำตอบแบบไหน ก็ลองโต้แย้งคำตอบนั้นด้วยตัวเอง เพราะมันเป็นจุดที่สับสนกว่าที่คิดมาก
สิ่งที่น่าเสียดายมากในระบบ AI ปัจจุบันคือการ retrain อย่างต่อเนื่องผ่าน feedback loop สั้น ๆ แม้มันจะมีต้นทุนสูง แต่ในระบบชีวภาพสิ่งนี้เกิดขึ้นเองตามธรรมชาติ ถ้าได้เห็นกระบวนการแบบนี้จริง ๆ คงยอดเยี่ยมมาก
มันคล้ายกับการฝึกทุกคืนอยู่เหมือนกัน ว่ากันว่ามนุษย์เรียนรู้จากประสบการณ์ระหว่างนอนหลับ ส่วน LLM ก็น่าจะคล้ายกับการ fine-tune แบบ "เรียนกลางคืน" จากข้อมูลที่หลุดออกจาก context window ทุกวัน
ตอนนี้มีงานวิจัยแบบนี้อยู่จริง สามารถใช้โครงสร้าง mixture of experts แบ่งเครือข่ายเป็นหน่วยย่อย ๆ ได้ โดยแต่ละหน่วยแชร์อินเทอร์เฟซและส่งผลลัพธ์ให้กันได้ หน่วยย่อยแต่ละตัวฝึกแยกได้ แต่ต้องไม่มีชุดฝึกแบบตายตัว ยิ่งไปกว่านั้น ถ้าปรับโครงสร้างด้วยโครงทางคณิตศาสตร์อย่าง category theory ก็จะได้เครือข่ายที่ไดนามิกเต็มรูปแบบ อย่างไรก็ตาม ทุกครั้งที่โครงสร้างเปลี่ยนก็เลี่ยงการฝึกใหม่ไม่ได้ สุดท้ายก็ยังต้องมีข้อมูลจากโลกจริงและ loss function (การแข่งขันกับเครือข่ายอื่น) สมองมนุษย์ในจุดนี้เชื่อมกับโลกจริงได้ดีที่สุดอยู่แล้ว อีกอย่างที่อยากเสริมคือ นิวรอนของเราไม่ได้ตัดสินใจยิงสัญญาณจากแค่น้ำหนักเท่านั้น แต่ยังขึ้นกับจังหวะเวลาที่อินพุตเข้ามาด้วย ซึ่งต่างกันในระดับนาโนวินาที เรื่องแบบนี้ฝั่ง IT ยังตามได้ยาก แต่ฉันคิดว่าในทางทฤษฎียังเป็นไปได้ และตอนนี้กำลังทดลองสิ่งนี้อยู่โดยสร้างสิ่งมีชีวิต 4 มิติเป็นกราฟการคำนวณแบบไดนามิกในสภาพแวดล้อมเสมือน มันน่าตื่นเต้นมาก แต่ก็ยังห่างไกลจากงานระดับอุตสาหกรรม
สิ่งที่น่าสนใจในบทความคือกรณีที่สังเกตว่า DGM แฮ็กฟังก์ชันรางวัลของตัวเอง จุดที่เด่นคือแม้จะใส่ฟังก์ชันรางวัลเพื่อยับยั้ง "ภาพหลอนในการใช้เครื่องมือ (hallucination)" แล้ว DGM ก็ยังลบ marker สำหรับตรวจจับรางวัลตัวนี้ออก ทำให้ถูกตัดสินว่าประสบความสำเร็จทั้งที่เป็นความสำเร็จปลอม ปรากฏการณ์ที่เคยพูดกันในเชิงทฤษฎีจึงถูกยืนยันเชิงประจักษ์
ในมุมของ AI safety ฉันรู้สึกแปลกใจที่ทั้ง ๆ ที่คาดการณ์ได้อยู่แล้วว่ามาตรการป้องกัน reward hacking เองก็จะถูกแฮ็กซ้ำอีกที ผู้คนก็ยังฝากความหวังไว้กับวิธีนี้อยู่ หลังจากได้ฟังคำอธิบายที่น่าประทับใจมากจากวิดีโอ AI Safety ของ Rob Miles บน YouTube (เช่น วิดีโอนี้) ฉันกลับรู้สึกว่าปรากฏการณ์แบบนี้เป็นเรื่องธรรมดาไปเลย
ตามบทความ ระบุว่าแค่รัน DGM บน SWE-bench หนึ่งครั้งก็ใช้เวลาถึง 2 สัปดาห์ และมีค่า API สูงถึง $22,000 ซึ่งมากพอสมควร
รายงานทางเทคนิคดูได้ที่ ลิงก์บทความบน arXiv และมี implementation อ้างอิงบน GitHub อยู่ ที่นี่ น่าจะมีประโยชน์สำหรับการอ้างอิง
งานวิจัยล่าสุดส่วนใหญ่มักเดินตามแนวทาง distillation ที่ใช้โมเดลใหญ่ราคาแพงมาฝึกโมเดลเล็ก แต่สิ่งที่น่าสนใจในงานชิ้นนี้คือเป็นกรณีที่โมเดลเล็ก/เก่า/ถูกกว่า กลับช่วยปรับปรุงประสิทธิภาพของโมเดลใหญ่ได้ ถ้าทำให้เป็นภาพรวมทั่วไปได้ นี่อาจเป็นสัญญาณว่า end user จะลดต้นทุนด้าน inference ของตัวเองได้มาก
งานชิ้นนี้จริง ๆ แล้วไม่ได้ปรับปรุงตัวโมเดลเอง แต่ปรับปรุงซอฟต์แวร์ที่ล้อมรอบโมเดลแทน จุดสำคัญคือผลของการปรับซอฟต์แวร์แบบนี้ขยายไปใช้ได้กับหลายโมเดล ไม่ได้เหมาะกับคุณลักษณะเฉพาะของโมเดลตัวใดตัวหนึ่งเท่านั้น ส่วนแนวทาง distillation ปกติคือให้ LLM ขนาดใหญ่ถ่ายทอดการกระจายโทเค็นทั้งหมดให้ LLM ขนาดเล็ก ซึ่งทำได้เร็ว
สิ่งที่พูดถึงตรงนี้ไม่ใช่การปรับปรุง weights ของโมเดลเอง แต่เป็นการเปลี่ยนฝั่ง "harness" ที่ครอบโค้ดซึ่งใช้เรียก LLM ตรงนี้จะยังนำกลับมาใช้และทำให้ทั่วไปต่อได้ แม้จะมี LLM ที่ทรงพลังกว่าออกมาในอนาคต ต่อให้ LLM ใหม่ยังไม่ได้จูน harness ใหม่ ผลการปรับปรุงที่สะสมมาก่อนหน้านี้ก็ยังถูกใช้ต่อได้