ปริมาณหน่วยความจำที่เอเจนต์ต้องการจริง ๆ คือเท่าไร?

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

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

ALTK-Evolve ช่วยให้เอเจนต์เรียนรู้จากเส้นทางการทำงานที่ผ่านมาของตนเอง กลั่นกรองแนวทางที่นำกลับมาใช้ใหม่ได้ และนำกลับมาใช้ในขั้นตอนการอนุมาน โดยไม่ต้องอัปเดตน้ำหนักโมเดล (weight updates) หรือการใส่คำอธิบายประกอบโดยมนุษย์

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

การดึงข้อมูลที่คัดสรรมาอย่างดีสามารถให้ทั้งความแม่นยำสูงสุดและราคาถูกที่สุด ตัวอย่างเช่น gpt-oss-120b มีประสิทธิภาพการทำงานของงานเพิ่มขึ้น +16.1pp โดยใช้โทเค็นเพิ่มขึ้นเพียง +5% และการแคชพรอมต์ (prompt caching) ก็ช่วยให้ชุดแนวทางทั้งหมดมีราคาที่เข้าถึงได้ในการใช้งานจริง

การให้ "ปริมาณ" หน่วยความจำขึ้นอยู่กับความสามารถของโมเดล

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

1. โมเดลที่แข็งแกร่งและมีศักยภาพเหลืออยู่ (Strong models with headroom)

โมเดลเหล่านี้ต้องการชุดแนวทางทั้งหมด รวมถึงบทเรียนจากกรณีที่เกิดขึ้นไม่บ่อยนัก เนื่องจากมีความสามารถเพียงพอที่จะดูดซับและนำไปใช้ประโยชน์ได้ทั้งหมด ตัวอย่างเช่น DeepSeek-V3.2 (671B MoE) มีประสิทธิภาพการทำงานของงานเพิ่มขึ้น +9.5% เมื่อได้รับชุดแนวทางทั้งหมดที่กลั่นกรองจากตนเอง

2. โมเดลขนาดเล็กหรืออ่อนแอ (Smaller or weaker models)

โมเดลเหล่านี้อาจสับสนหรือจมอยู่กับชุดแนวทางจำนวนมาก สำหรับโมเดลเหล่านี้ วิธีที่ดีที่สุดคือการใช้แกนหลักที่กระชับและมีความเชื่อมั่นสูง ควบคู่ไปกับแนวทางที่เกี่ยวข้องกับงานเพียงไม่กี่อย่างที่ดึงมาใช้ในแต่ละงาน เช่น gpt-oss-120b (117B MoE) มีประสิทธิภาพเพิ่มขึ้น +16.1pp ด้วยแนวทางแบบเลือกนี้ ในขณะที่ชุดแนวทางทั้งหมดให้ผลกำไรน้อยกว่าและมีค่าใช้จ่ายโทเค็นสูงกว่าประมาณ 50%

3. โมเดลที่ถึงขีดจำกัดแล้ว (Already-saturated models)

โมเดลเหล่านี้ไม่แสดงผลกำไรที่วัดได้ เราเรียกรูปแบบนี้ว่า "รูปแบบอิ่มตัว" (saturated pattern) ซึ่งไม่ได้หมายถึงสาเหตุที่พิสูจน์ได้ โมเดลอาจใกล้ถึงขีดจำกัดสูงสุดสำหรับงานเหล่านี้แล้ว แนวทางอาจไม่ได้ครอบคลุมข้อผิดพลาดที่เหลืออยู่ หรือโมเดลอาจไม่สามารถนำแนวทางไปใช้อย่างมีประสิทธิภาพ ตัวอย่างเช่น GLM-5 (745B MoE) อยู่ในกลุ่มนี้จากการทดลองของเรา

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

การเรียนรู้เกิดขึ้นรอบ ๆ โมเดล ไม่ใช่ภายในโมเดล

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

  1. เอเจนต์พยายามทำงานและสร้างเส้นทางการทำงาน (trajectories)
  2. ALTK-Evolve ดึงเอาแนวทางพฤติกรรมจากทั้งการทำงานที่สำเร็จและไม่สำเร็จ
  3. ระบบจะรวบรวมแนวทางเหล่านั้นเป็นชุดที่นำกลับมาใช้ใหม่ได้
  4. ในขั้นตอนการอนุมาน เอเจนต์จะได้รับชุดแนวทางทั้งหมด หรือชุดที่เกี่ยวข้องกับงาน

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

ผลลัพธ์ที่ได้จากการทดลองกับโมเดลหลากหลาย

เราทำการประเมินบน AppWorld ซึ่งประกอบด้วย 585 งานที่ต้องทำหลายขั้นตอน (168 งานปกติ + 417 งานท้าทาย) ครอบคลุม 9 แอปพลิเคชันจำลอง (ปฏิทิน, ข้อความ, การชำระเงิน และอื่นๆ) งานต่างๆ จะถูกให้คะแนนสองวิธี:

  • TGC (Task Goal Completion): วัดว่าเอเจนต์ทำงานแต่ละงานสำเร็จลุล่วงหรือไม่
  • SGC (Scenario Goal Completion): เป็นเกณฑ์ที่เข้มงวดกว่า โดยวัดว่าทุกรูปแบบของสถานการณ์ (scenario) ผ่านเกณฑ์หรือไม่

การกำหนดค่า 3 รูปแบบที่ใช้ในการเปรียบเทียบ

เนื่องจากส่วนที่ทำให้สับสนในการศึกษาเกี่ยวกับหน่วยความจำคือสิ่งที่อยู่ในหน้าต่างบริบท เราจึงกำหนดรูปแบบการกำหนดค่าไว้ล่วงหน้า:

  • ชุดแนวทางทั้งหมด (Full guideline set): ฉีดแนวทางทั้งหมดเข้าไปในทุกขั้นตอน
  • การดึงข้อมูลที่คัดสรร (Curated retrieval): นำเสนอชุดแนวทางที่เลือกสรรมาเฉพาะงาน

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

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

รูปแบบทั้งสามในมุมมองเดียว

โมเดลที่เป็นตัวแทนจากการทดลอง 8 โมเดล วัดผลด้วยการทำงานให้สำเร็จ (TGC) ในชุดทดสอบปกติ:

![รูปภาพแสดงโมเดลที่เป็นตัวแทนใน 3 รูปแบบที่สังเกตได้](ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/ibm-research/altk-evolve-hmm/raw/main/appworld-patterns.png)
(หมายเหตุ: รูปภาพประกอบจากต้นฉบับ ไม่สามารถแสดงผลได้โดยตรงในรูปแบบข้อความ)

กราฟแสดง TGC เพื่อให้อ่านง่าย ตารางด้านล่างจะเพิ่มเมตริก SGC ที่เข้มงวดกว่า ซึ่งผลกำไรมักจะมากกว่า:

จากการอ่านคอลัมน์ SGC จะเห็นว่าเมตริกที่เข้มงวดกว่ามักจะมีการเปลี่ยนแปลงมากกว่า TGC เช่น SGC ของ DeepSeek เพิ่มขึ้น +16.1pp เทียบกับ TGC ที่เพิ่มขึ้น +9.5pp ซึ่งแสดงให้เห็นว่าแนวทางที่ดีมีส่วนช่วยอย่างมากในการให้เอเจนต์ทำงานในทุกรูปแบบของสถานการณ์ ไม่ใช่แค่กรณีทั่วไป และผลกระทบนี้ก็ไม่ได้หายไปที่ส่วนบนสุดของช่วง เช่น GPT-5.5 และ Opus ซึ่งใกล้เคียงกับขีดจำกัดของ TGC ยังคงได้รับ SGC เพิ่มขึ้น +7.2 และ +7.1pp ตามลำดับ แสดงว่าหน่วยความจำยังคงให้ผลตอบแทนตราบเท่าที่โมเดลยังมีโหมดความล้มเหลวที่สามารถแก้ไขได้

กลยุทธ์หน่วยความจำที่คุ้มค่าที่สุดก็อาจเป็นกลยุทธ์ที่ดีที่สุด

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

| การกำหนดค่า (Configuration) | การใช้โทเค็นเฉลี่ยต่อการทำงาน (Average token use per task) | การเปลี่ยนแปลงของ TGC (TGC Change) |
| :-------------------------- | :------------------------------------------------------- | :------------------------------- |
| Baseline (No Memory) | 1.00x | - |
| Full Guideline Set | 1.51x | +9.5pp (DeepSeek) |
| Curated Retrieval | 1.05x | +16.1pp (gpt-oss-120b) |

ตารางแสดงค่าเฉลี่ยการใช้โทเค็นต่อการทำงาน สะสมจากขั้นตอนเอเจนต์ วัดเทียบกับ baseline ที่ไม่มีหน่วยความจำ

การดึงข้อมูลที่คัดสรรช่วยให้ค่าใช้จ่ายใกล้เคียงกับ baseline สำหรับโมเดลที่อ่อนแอกว่า ซึ่งการคัดเลือกให้ผลดีในด้านความแม่นยำ ก็ให้ผลดีในด้านค่าใช้จ่ายเช่นกัน (+16.1pp TGC ด้วยโทเค็นที่เพิ่มขึ้นเพียง +5% สำหรับ gpt-oss-120b) ประสิทธิภาพที่ดีขึ้นที่นี่ไม่จำเป็นต้องใช้ค่าใช้จ่ายในการอนุมานที่สูงขึ้น

หน่วยความจำไม่ได้ทำให้ลูปการใช้เหตุผล (reasoning loop) บวมขึ้น DeepSeek ทำงานประมาณจำนวนขั้นตอน ReAct เท่าเดิมกับตอนที่ไม่มีหน่วยความจำ (เฉลี่ยประมาณ 18-19 ขั้นตอน) ดังนั้น ค่าใช้จ่ายที่เพิ่มขึ้นจึงมาจากการเพิ่มขึ้นของโทเค็นอินพุต ไม่ใช่การทำงานที่ยาวนานขึ้น

คันโยกประสิทธิภาพที่แท้จริงในการใช้งานจริงคือการแคชพรอมต์ (prompt caching): ส่วนที่คงที่ของชุดแนวทางจะเหมือนกันในทุกขั้นตอนและสามารถแคชได้ ซึ่งช่วยลดค่าใช้จ่ายที่แท้จริงลงอย่างมาก การออกแบบพรอมต์ที่คำนึงถึงแคช (Cache-aware prompt design) โดยการทำให้ส่วนแบ่งของชุดแนวทางคงที่ เพื่อให้สามารถแคชได้ เป็นสิ่งที่คุ้มค่ากับการลงทุนทางวิศวกรรม นอกจากนี้ เรายังตั้งสมมติฐานว่าขนาดหน้าต่างบริบทมีบทบาท: โมเดลที่มีหน้าต่างที่ใหญ่กว่าอาจดูดซับชุดแนวทางทั้งหมดได้อย่างมีประสิทธิภาพมากกว่า ในขณะที่โมเดลที่มีบริบทขนาดเล็กจะได้รับประโยชน์จากการดึงข้อมูลที่ช่วยให้เนื้อหาที่แทรกเข้าไปมีความกระชับ เรายังไม่ได้ทำการทดลองที่ควบคุมเพื่อแยกปัจจัยนี้

หน่วยความจำควรได้รับการปรับเทียบ ไม่ใช่แค่สะสม

บทเรียนที่ได้ไม่ใช่การให้เอเจนต์ทุกสิ่งที่มันได้เรียนรู้ แต่เป็นการให้ประสบการณ์ในปริมาณที่มันสามารถนำไปใช้ได้จริง

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

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

นี่เป็นเพียงจุดเริ่มต้น ไม่ใช่จุดสิ้นสุด:

  • ตัวเลือกที่เรียนรู้ได้: ปัจจุบันการดึงข้อมูลของเราจะจัดอันดับแนวทางตามความคล้ายคลึงของโคไซน์ (cosine similarity) ซึ่งเราได้แสดงให้เห็นแล้วว่าไม่ได้บ่งชี้อย่างแม่นยำว่าแนวทางใดช่วยในงานที่กำหนด การฝึกตัวเลือกตามสัญญาณผลลัพธ์เป็นขั้นตอนต่อไปที่สมเหตุสมผล
  • หน่วยความจำสำหรับโมเดลที่อ่อนแอมาก: ต่ำกว่าเกณฑ์ความสามารถขั้นต่ำ การกลั่นกรองตนเอง (self-distillation) จะขาดสัญญาณ หน่วยความจำที่ได้จากการกลั่นกรองโดยครู (teacher-distilled memory) สำหรับโมเดลที่อ่อนแอมากเป็นปัญหาที่แยกจากกันซึ่งเรากำลังสำรวจ
  • นอกเหนือจาก AppWorld: ผลลัพธ์เหล่านี้ได้รับการตรวจสอบบน AppWorld ซึ่งเป็นเกณฑ์

ขอบคุณ แหล่งข้อมูล
https://huggingface.co/blog/ibm-research/altk-evolve-hmm

ปริมาณหน่วยความจำที่เอเจนต์ต้องการจริง ๆ คือเท่าไร?การเสริมหน่วยความจำให้กับเอเจนต์ดูเหมือนจะเป็นเรื่องง่าย เพียงแค่กลั่นกรองบทเรียนจากงานที่ผ่านมา นำกลับมาใช้ในบริบทที่เหมาะสม และประสบการณ์ที่มากขึ้นก็น่าจะนำไปสู่ประสิทธิภาพที่ดีขึ้น แต่ก็ไม่เป็นเช่นนั้นเสมอไป เมื่อเราทำการประเมินกับโมเดลถึง 8 โมเดล ตั้งแต่โมเดลขนาด 30B ไปจนถึงระบบที่เป็นกรรมสิทธิ์ระดับแนวหน้า ผลการค้นพบหนึ่งที่โดดเด่นคือ:หน่วยความจำของเอเจนต์ไม่ใช่คุณสมบัติที่เปิดใช้งานได้ แต่เป็นปริมาณที่ต้องปรับให้เหมาะสมกับโมเดลALTK-Evolve ช่วยให้เอเจนต์เรียนรู้จากเส้นทางการทำงานที่ผ่านมาของตนเอง กลั่นกรองแนวทางที่นำกลับมาใช้ใหม่ได้ และนำกลับมาใช้ในขั้นตอนการอนุมาน โดยไม่ต้องอัปเดตน้ำหนักโมเดล (weight updates) หรือการใส่คำอธิบายประกอบโดยมนุษย์ปริมาณที่เหมาะสมจะแตกต่างกันไปตามระดับของโมเดล โมเดลที่แข็งแกร่งซึ่งยังมีศักยภาพเหลืออยู่ต้องการชุดแนวทางทั้งหมด โมเดลที่อ่อนแอกว่าจะทำงานได้ดีที่สุดด้วยแกนหลักที่กระชับร่วมกับการดึงข้อมูลตามงานเฉพาะ และโมเดลที่ถึงขีดจำกัดแล้วจะไม่แสดงผลกำไรที่วัดได้การดึงข้อมูลที่คัดสรรมาอย่างดีสามารถให้ทั้งความแม่นยำสูงสุดและราคาถูกที่สุด ตัวอย่างเช่น gpt-oss-120b มีประสิทธิภาพการทำงานของงานเพิ่มขึ้น +16.1pp โดยใช้โทเค็นเพิ่มขึ้นเพียง +5% และการแคชพรอมต์ (prompt caching) ก็ช่วยให้ชุดแนวทางทั้งหมดมีราคาที่เข้าถึงได้ในการใช้งานจริงการให้ "ปริมาณ" หน่วยความจำขึ้นอยู่กับความสามารถของโมเดลไม่ใช่ทุกโมเดลที่จะได้รับประโยชน์จากปริมาณหน่วยความจำเท่ากัน จากการทดสอบกับโมเดล 8 โมเดลที่ครอบคลุมช่วงความสามารถต่างๆ เราพบรูปแบบที่เกิดขึ้นซ้ำๆ 3 รูปแบบ:1. โมเดลที่แข็งแกร่งและมีศักยภาพเหลืออยู่ (Strong models with headroom)โมเดลเหล่านี้ต้องการชุดแนวทางทั้งหมด รวมถึงบทเรียนจากกรณีที่เกิดขึ้นไม่บ่อยนัก เนื่องจากมีความสามารถเพียงพอที่จะดูดซับและนำไปใช้ประโยชน์ได้ทั้งหมด ตัวอย่างเช่น DeepSeek-V3.2 (671B MoE) มีประสิทธิภาพการทำงานของงานเพิ่มขึ้น +9.5% เมื่อได้รับชุดแนวทางทั้งหมดที่กลั่นกรองจากตนเอง2. โมเดลขนาดเล็กหรืออ่อนแอ (Smaller or weaker models)โมเดลเหล่านี้อาจสับสนหรือจมอยู่กับชุดแนวทางจำนวนมาก สำหรับโมเดลเหล่านี้ วิธีที่ดีที่สุดคือการใช้แกนหลักที่กระชับและมีความเชื่อมั่นสูง ควบคู่ไปกับแนวทางที่เกี่ยวข้องกับงานเพียงไม่กี่อย่างที่ดึงมาใช้ในแต่ละงาน เช่น gpt-oss-120b (117B MoE) มีประสิทธิภาพเพิ่มขึ้น +16.1pp ด้วยแนวทางแบบเลือกนี้ ในขณะที่ชุดแนวทางทั้งหมดให้ผลกำไรน้อยกว่าและมีค่าใช้จ่ายโทเค็นสูงกว่าประมาณ 50%3. โมเดลที่ถึงขีดจำกัดแล้ว (Already-saturated models)โมเดลเหล่านี้ไม่แสดงผลกำไรที่วัดได้ เราเรียกรูปแบบนี้ว่า "รูปแบบอิ่มตัว" (saturated pattern) ซึ่งไม่ได้หมายถึงสาเหตุที่พิสูจน์ได้ โมเดลอาจใกล้ถึงขีดจำกัดสูงสุดสำหรับงานเหล่านี้แล้ว แนวทางอาจไม่ได้ครอบคลุมข้อผิดพลาดที่เหลืออยู่ หรือโมเดลอาจไม่สามารถนำแนวทางไปใช้อย่างมีประสิทธิภาพ ตัวอย่างเช่น GLM-5 (745B MoE) อยู่ในกลุ่มนี้จากการทดลองของเราสิ่งที่กำหนดว่าโมเดลจะอยู่ในรูปแบบใดรูปแบบหนึ่ง ไม่ใช่แค่จำนวนพารามิเตอร์เท่านั้น แต่ยังรวมถึงศักยภาพที่วัดได้จากเบนช์มาร์ก ขนาดหน้าต่างบริบท (context window) สถาปัตยกรรม คุณภาพของแนวทาง และการกระจายงาน ล้วนมีบทบาทในการกำหนดตำแหน่งของโมเดล ซึ่งการแยกปัจจัยเหล่านี้ยังคงอยู่ระหว่างการศึกษา อย่างไรก็ตาม ข้อสรุปที่นำไปใช้ได้จริงยังคงเหมือนเดิม: ปริมาณหน่วยความจำที่เหมาะสมขึ้นอยู่กับโมเดล และเราสามารถปรับเทียบมันได้การเรียนรู้เกิดขึ้นรอบ ๆ โมเดล ไม่ใช่ภายในโมเดล"หน่วยความจำ" ในที่นี้ไม่ได้หมายถึงการย้อนดูประวัติการสนทนาที่ผ่านมา แต่หมายถึงชุดแนวทาง – กลยุทธ์ที่เคยได้ผล ข้อผิดพลาดที่ควรหลีกเลี่ยง และกรณีพิเศษที่ถูกกลั่นกรองมาจากเส้นทางการทำงานที่ผ่านมาของเอเจนต์ วงจรการทำงานเป็นไปอย่างตรงไปตรงมา:เอเจนต์พยายามทำงานและสร้างเส้นทางการทำงาน (trajectories)ALTK-Evolve ดึงเอาแนวทางพฤติกรรมจากทั้งการทำงานที่สำเร็จและไม่สำเร็จระบบจะรวบรวมแนวทางเหล่านั้นเป็นชุดที่นำกลับมาใช้ใหม่ได้ในขั้นตอนการอนุมาน เอเจนต์จะได้รับชุดแนวทางทั้งหมด หรือชุดที่เกี่ยวข้องกับงานไม่มีการอัปเดตน้ำหนักโมเดล วงจรการเรียนรู้นี้เปลี่ยนแปลงเพียงแนวทางที่เอเจนต์ได้รับ ไม่ใช่โมเดลพื้นฐาน ซึ่งนี่คือเหตุผลว่าทำไมจึงมีต้นทุนต่ำในการนำไปใช้และสามารถใช้งานได้กับโมเดลทั้ง 8 ตัวที่เราทดสอบผลลัพธ์ที่ได้จากการทดลองกับโมเดลหลากหลายเราทำการประเมินบน AppWorld ซึ่งประกอบด้วย 585 งานที่ต้องทำหลายขั้นตอน (168 งานปกติ + 417 งานท้าทาย) ครอบคลุม 9 แอปพลิเคชันจำลอง (ปฏิทิน, ข้อความ, การชำระเงิน และอื่นๆ) งานต่างๆ จะถูกให้คะแนนสองวิธี:TGC (Task Goal Completion): วัดว่าเอเจนต์ทำงานแต่ละงานสำเร็จลุล่วงหรือไม่SGC (Scenario Goal Completion): เป็นเกณฑ์ที่เข้มงวดกว่า โดยวัดว่าทุกรูปแบบของสถานการณ์ (scenario) ผ่านเกณฑ์หรือไม่การกำหนดค่า 3 รูปแบบที่ใช้ในการเปรียบเทียบเนื่องจากส่วนที่ทำให้สับสนในการศึกษาเกี่ยวกับหน่วยความจำคือสิ่งที่อยู่ในหน้าต่างบริบท เราจึงกำหนดรูปแบบการกำหนดค่าไว้ล่วงหน้า:ชุดแนวทางทั้งหมด (Full guideline set): ฉีดแนวทางทั้งหมดเข้าไปในทุกขั้นตอนการดึงข้อมูลที่คัดสรร (Curated retrieval): นำเสนอชุดแนวทางที่เลือกสรรมาเฉพาะงานทั้งสองรูปแบบหน่วยความจำดึงข้อมูลจากชุดแนวทางเดียวกัน ซึ่งถูกขุดขึ้นมาเพียงครั้งเดียวจากชุดฝึกของ AppWorld เท่านั้น สิ่งที่แตกต่างกันคือวิธีการส่งชุดดังกล่าวเท่านั้น ไม่ใช่วิธีการผลิตแนวทาง และไม่มีข้อมูลจากชุดทดสอบใดถูกนำไปใช้ในการสร้างจำนวนแนวทางที่โมเดลขุดขึ้นมาจะขึ้นอยู่กับความสามารถของโมเดลเอง ดังนั้น เราจึงรายงานการกำหนดค่าตามกลยุทธ์ "ชุดแนวทางทั้งหมด" เทียบกับ "การดึงข้อมูลที่คัดสรร" แทนที่จะเป็นจำนวนดิบ ซึ่งไม่สามารถเปรียบเทียบกันได้ระหว่างโมเดลรูปแบบทั้งสามในมุมมองเดียวโมเดลที่เป็นตัวแทนจากการทดลอง 8 โมเดล วัดผลด้วยการทำงานให้สำเร็จ (TGC) ในชุดทดสอบปกติ:![รูปภาพแสดงโมเดลที่เป็นตัวแทนใน 3 รูปแบบที่สังเกตได้](https://huggingface.co/blog/ibm-research/altk-evolve-hmm/raw/main/appworld-patterns.png)(หมายเหตุ: รูปภาพประกอบจากต้นฉบับ ไม่สามารถแสดงผลได้โดยตรงในรูปแบบข้อความ)กราฟแสดง TGC เพื่อให้อ่านง่าย ตารางด้านล่างจะเพิ่มเมตริก SGC ที่เข้มงวดกว่า ซึ่งผลกำไรมักจะมากกว่า:จากการอ่านคอลัมน์ SGC จะเห็นว่าเมตริกที่เข้มงวดกว่ามักจะมีการเปลี่ยนแปลงมากกว่า TGC เช่น SGC ของ DeepSeek เพิ่มขึ้น +16.1pp เทียบกับ TGC ที่เพิ่มขึ้น +9.5pp ซึ่งแสดงให้เห็นว่าแนวทางที่ดีมีส่วนช่วยอย่างมากในการให้เอเจนต์ทำงานในทุกรูปแบบของสถานการณ์ ไม่ใช่แค่กรณีทั่วไป และผลกระทบนี้ก็ไม่ได้หายไปที่ส่วนบนสุดของช่วง เช่น GPT-5.5 และ Opus ซึ่งใกล้เคียงกับขีดจำกัดของ TGC ยังคงได้รับ SGC เพิ่มขึ้น +7.2 และ +7.1pp ตามลำดับ แสดงว่าหน่วยความจำยังคงให้ผลตอบแทนตราบเท่าที่โมเดลยังมีโหมดความล้มเหลวที่สามารถแก้ไขได้กลยุทธ์หน่วยความจำที่คุ้มค่าที่สุดก็อาจเป็นกลยุทธ์ที่ดีที่สุดข้อกังวลในทางปฏิบัติคือ การใส่ชุดแนวทางทั้งหมดจะเพิ่มอินพุตของขั้นตอน ReAct แต่ละขั้น เนื่องจากแนวทางจะถูกส่งซ้ำทุกครั้ง นี่คือสิ่งที่เราสังเกตได้:| การกำหนดค่า (Configuration) | การใช้โทเค็นเฉลี่ยต่อการทำงาน (Average token use per task) | การเปลี่ยนแปลงของ TGC (TGC Change) || :-------------------------- | :------------------------------------------------------- | :------------------------------- || Baseline (No Memory) | 1.00x | - || Full Guideline Set | 1.51x | +9.5pp (DeepSeek) || Curated Retrieval | 1.05x | +16.1pp (gpt-oss-120b) |ตารางแสดงค่าเฉลี่ยการใช้โทเค็นต่อการทำงาน สะสมจากขั้นตอนเอเจนต์ วัดเทียบกับ baseline ที่ไม่มีหน่วยความจำการดึงข้อมูลที่คัดสรรช่วยให้ค่าใช้จ่ายใกล้เคียงกับ baseline สำหรับโมเดลที่อ่อนแอกว่า ซึ่งการคัดเลือกให้ผลดีในด้านความแม่นยำ ก็ให้ผลดีในด้านค่าใช้จ่ายเช่นกัน (+16.1pp TGC ด้วยโทเค็นที่เพิ่มขึ้นเพียง +5% สำหรับ gpt-oss-120b) ประสิทธิภาพที่ดีขึ้นที่นี่ไม่จำเป็นต้องใช้ค่าใช้จ่ายในการอนุมานที่สูงขึ้นหน่วยความจำไม่ได้ทำให้ลูปการใช้เหตุผล (reasoning loop) บวมขึ้น DeepSeek ทำงานประมาณจำนวนขั้นตอน ReAct เท่าเดิมกับตอนที่ไม่มีหน่วยความจำ (เฉลี่ยประมาณ 18-19 ขั้นตอน) ดังนั้น ค่าใช้จ่ายที่เพิ่มขึ้นจึงมาจากการเพิ่มขึ้นของโทเค็นอินพุต ไม่ใช่การทำงานที่ยาวนานขึ้นคันโยกประสิทธิภาพที่แท้จริงในการใช้งานจริงคือการแคชพรอมต์ (prompt caching): ส่วนที่คงที่ของชุดแนวทางจะเหมือนกันในทุกขั้นตอนและสามารถแคชได้ ซึ่งช่วยลดค่าใช้จ่ายที่แท้จริงลงอย่างมาก การออกแบบพรอมต์ที่คำนึงถึงแคช (Cache-aware prompt design) โดยการทำให้ส่วนแบ่งของชุดแนวทางคงที่ เพื่อให้สามารถแคชได้ เป็นสิ่งที่คุ้มค่ากับการลงทุนทางวิศวกรรม นอกจากนี้ เรายังตั้งสมมติฐานว่าขนาดหน้าต่างบริบทมีบทบาท: โมเดลที่มีหน้าต่างที่ใหญ่กว่าอาจดูดซับชุดแนวทางทั้งหมดได้อย่างมีประสิทธิภาพมากกว่า ในขณะที่โมเดลที่มีบริบทขนาดเล็กจะได้รับประโยชน์จากการดึงข้อมูลที่ช่วยให้เนื้อหาที่แทรกเข้าไปมีความกระชับ เรายังไม่ได้ทำการทดลองที่ควบคุมเพื่อแยกปัจจัยนี้หน่วยความจำควรได้รับการปรับเทียบ ไม่ใช่แค่สะสมบทเรียนที่ได้ไม่ใช่การให้เอเจนต์ทุกสิ่งที่มันได้เรียนรู้ แต่เป็นการให้ประสบการณ์ในปริมาณที่มันสามารถนำไปใช้ได้จริงสำหรับโมเดลที่อ่อนแอ หมายถึงการมีแกนหลักที่กระชับพร้อมบทเรียนเฉพาะงาน ซึ่งบังเอิญเป็นตัวเลือกที่คุ้มค่าที่สุดด้วยสำหรับโมเดลที่แข็งแกร่งและมีศักยภาพเหลืออยู่ หมายถึงการเก็บชุดแนวทางทั้งหมด ซึ่งทำให้คุ้มค่าในการใช้งานจริงผ่านการแคชพรอมต์สำหรับโมเดลที่อิ่มตัว หมายถึงการไม่ต้องเสียบริบทเพิ่มเติมจนกว่าโหมดความล้มเหลวที่เหลืออยู่จะได้รับการทำความเข้าใจที่ดีขึ้นผลกำไรนั้นมีจริงในทุกระดับ – เป็นอัตโนมัติ ไม่มีข้อมูลรั่วไหล และไม่ต้องใช้การใส่คำอธิบายประกอบโดยมนุษย์ – แต่ก็ต่อเมื่อปริมาณที่ให้เหมาะสมกับโมเดลเท่านั้นนี่เป็นเพียงจุดเริ่มต้น ไม่ใช่จุดสิ้นสุด:ตัวเลือกที่เรียนรู้ได้: ปัจจุบันการดึงข้อมูลของเราจะจัดอันดับแนวทางตามความคล้ายคลึงของโคไซน์ (cosine similarity) ซึ่งเราได้แสดงให้เห็นแล้วว่าไม่ได้บ่งชี้อย่างแม่นยำว่าแนวทางใดช่วยในงานที่กำหนด การฝึกตัวเลือกตามสัญญาณผลลัพธ์เป็นขั้นตอนต่อไปที่สมเหตุสมผลหน่วยความจำสำหรับโมเดลที่อ่อนแอมาก: ต่ำกว่าเกณฑ์ความสามารถขั้นต่ำ การกลั่นกรองตนเอง (self-distillation) จะขาดสัญญาณ หน่วยความจำที่ได้จากการกลั่นกรองโดยครู (teacher-distilled memory) สำหรับโมเดลที่อ่อนแอมากเป็นปัญหาที่แยกจากกันซึ่งเรากำลังสำรวจนอกเหนือจาก AppWorld: ผลลัพธ์เหล่านี้ได้รับการตรวจสอบบน AppWorld ซึ่งเป็นเกณฑ์https://huggingface.co/blog/ibm-research/altk-evolve-hmm
Shared content
HUGGINGFACE.CO
How Much Memory Does Your Agent Actually Need?
A Blog post by IBM Research on Hugging Face
5 Commentarii 0 Distribuiri 562 Views 0 previzualizare