IBM ปล่อย ALTK-Evolve — หน่วยความจำเอเจนต์แบบเลือกหยิบ ชนะ ACE ทั้งคะแนนและใช้โทเคนน้อยกว่า 2.4–6.7 เท่า เปิดโค้ด Apache 2.0

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

เมื่อ 11 สิงหาคม 2026 ทีม IBM Research เผยแพร่บทความบน Hugging Face ชื่อ “Thinking of ACE? We Can Do It with Fewer Tokens” พร้อมปล่อยไลบรารี ALTK-Evolve เป็นโอเพนซอร์ส Apache 2.0 ข้อเสนอของมันตรงไปตรงมา: วิธีแก้ปัญหาความจำเอเจนต์ที่กำลังเป็นที่นิยมอย่าง ACE (agentic context engineering) ได้ผลจริง แต่แพงเกินจำเป็น — และ IBM แสดงตัวเลขว่าทำให้ดีกว่าได้ด้วยโทเคนที่น้อยกว่าหลายเท่า

ปัญหาของ ACE: ยัด playbook ทั้งเล่มทุกสเต็ป

แนวคิดร่วมของทั้งสองระบบเหมือนกัน — แปลง “รูปแบบความล้มเหลว” จาก trajectory ของงานที่ทำไปแล้ว ให้กลายเป็นคำแนะนำที่นำกลับมาใช้ใหม่ได้ โดยไม่ต้องอัปเดตน้ำหนักโมเดล และไม่ต้องมีคนมาติดป้ายกำกับ

ความต่างอยู่ที่วิธี ส่งมอบ ความรู้นั้นกลับเข้าโมเดล

• ACE สร้าง playbook รวมแล้วฉีดเข้า context ทุกสเต็ป — ครบถ้วน แต่แปลว่าทุกครั้งที่เอเจนต์ขยับ มันต้องอ่านบทเรียนทั้งเล่มใหม่หมด รวมถึงข้อที่ไม่เกี่ยวกับงานตรงหน้าเลย
• ALTK-Evolve ส่ง แกนกลางเล็ก ๆ ของ guideline ที่มี support สูง แล้วต่อท้ายด้วยบทเรียนอีกไม่กี่ข้อที่เลือกมาเฉพาะสำหรับงานนั้น (เลือกด้วย cosine similarity หรือให้ LLM ช่วยเลือก ถ่วงน้ำหนักตามลำดับความสำคัญ) และปรับตามความสามารถของโมเดล — โมเดลแรงพอจะรับชุดเต็มได้ก็ให้ชุดเต็ม โมเดลอ่อนกว่าให้แบบคัดมาแล้ว

พูดง่าย ๆ คือความต่างระหว่าง “แจกคู่มือทั้งเล่มก่อนทุกการตัดสินใจ” กับ “หยิบหน้าที่เกี่ยวข้องมาวางให้”

ตัวเลขบน AppWorld

IBM วัดบน AppWorld split test_normal (168 งาน) รายงานสองเมตริก — TGC (Task Goal Completion) คืองานสำเร็จ และ SGC (Scenario Goal Completion) ที่เข้มกว่าเพราะต้องผ่านทุกตัวแปรของ scenario นั้น

โมเดล	ระบบ	TGC / SGC	โทเคนต่องาน
DeepSeek-V3.2	ACE	80.4 / 73.2	634K
DeepSeek-V3.2	ALTK-Evolve	89.3 / 80.4	263K
gpt-oss-120b	ACE	54.8 / 35.7	777K
gpt-oss-120b	ALTK-Evolve	56.0 / 37.5	116K

อ่านตารางนี้แล้วมีสองเรื่องที่ต่างกันชัดเจน

บนโมเดลที่แรงกว่า (DeepSeek-V3.2) ALTK-Evolve ได้ทั้งสองทาง — TGC เพิ่ม +8.9 คะแนน และ SGC เพิ่ม +7.2 คะแนน ขณะที่ใช้โทเคนแค่ 41% ของ ACE (263K vs 634K) นี่คือกรณีที่ไม่มี trade-off เลย: ดีกว่าและถูกกว่าพร้อมกัน

บนโมเดลที่อ่อนกว่า (gpt-oss-120b) คะแนนแทบเท่ากัน (+1.2 TGC) แต่โทเคนลดจาก 777K เหลือ 116K — ประมาณ 6.7 เท่า เรื่องราวตรงนี้ต่างออกไป: มันไม่ได้ทำให้ฉลาดขึ้น แต่มันตัดค่าใช้จ่ายลง 85% โดยไม่เสียคุณภาพ ซึ่งสำหรับงานจริงก็มีค่าไม่แพ้กัน

จุดที่บทความชี้ไว้น่าคิด: ในงานระดับ Hard ที่โมเดลต้อง “เลือกบทเรียนที่ถูก” แทนที่จะไล่อ่านทั้งกอง การคัดมาให้ล่วงหน้าชนะชัด — ALTK-Evolve ได้ 31.8% TGC เทียบกับ ACE ที่ 23.8% บน gpt-oss-120b นี่คือหลักฐานเชิงกลไก ไม่ใช่แค่ผลรวม: การให้ context เยอะเกินไม่ใช่แค่แพง แต่มันรบกวนการตัดสินใจของโมเดลที่ไม่แข็งพอจะกรองเอง

เอาไปใช้จริงยังไง

ตัวไลบรารีอยู่บน GitHub ที่ AgentToolkit/altk-evolve ใบอนุญาต Apache 2.0 ติดตั้งด้วย:

pip install altk-evolve

ข้อกำหนดและการเชื่อมต่อ:

• Python 3.12+
• ต่อกับ vector DB ได้ทั้ง PostgreSQL + pgvector และ Milvus
• เปิดออกมาเป็น MCP server — ซึ่งเป็นจุดที่สำคัญที่สุดสำหรับนักพัฒนาทั่วไป เพราะแปลว่าเสียบเข้า Claude Code, Codex และ IBM Bob ได้โดยไม่ต้องเขียน integration เอง

กลไกคือ ดึง insight ออกจาก trajectory ของบทสนทนาที่ผ่านมา เก็บลงฐานข้อมูล แล้วป้อนกลับเข้าเซสชันถัดไป ตามคำอธิบายในเรโป: “Coding agents repeat the same mistakes because they start fresh every session. Evolve gives agents memory.”

ณ ตอนที่เขียน เรโปมี 98 ดาว 12 fork และ 237 commit บน main — ยังเป็นโปรเจกต์ใหม่มาก (มี 56 issue เปิดอยู่) ควรมองว่าเป็นของที่ต้องลองก่อนวางในโปรดักชัน

บริบท: ทุกคนกำลังแก้ปัญหาเดียวกันอยู่

ALTK-Evolve ไม่ได้เกิดในสุญญากาศ ปีนี้ทุกเจ้าลงมาแก้เรื่อง “เอเจนต์ที่จำอะไรไม่ได้” พร้อมกัน — GitHub มี Copilot Memory ที่เก็บทั้งข้อเท็จจริงระดับเรโป (convention, คำสั่ง build, การตัดสินใจเชิงสถาปัตยกรรม) และความชอบระดับผู้ใช้ โดยผูก citation ไว้กับโค้ดจริงแล้วตรวจสอบ citation ใหม่ทุกครั้งก่อนใช้ และลบทิ้งอัตโนมัติถ้าไม่ถูกใช้ภายใน 28 วัน

ความต่างเชิงยุทธศาสตร์ชัดมาก: ของ GitHub เป็นบริการปิดที่ผูกกับแพลตฟอร์มและระบบบิลลิ่งของตัวเอง ส่วนของ IBM เป็นไลบรารี Apache 2.0 ที่คุณรันบนฐานข้อมูลของคุณเอง เก็บความจำไว้ในองค์กรคุณเอง

มุมมอง AI Curator

สิ่งที่ผมคิดว่าเป็นบทเรียนจริงของงานชิ้นนี้ ไม่ใช่ “ALTK ชนะ ACE” แต่คือหลักฐานเชิงตัวเลขที่ว่า การให้ context มากขึ้นไม่ได้แปลว่าเอเจนต์เก่งขึ้น — บนโมเดลที่อ่อนกว่า ACE ยัดโทเคนไปมากกว่า 6.7 เท่าแล้วได้คะแนนต่ำกว่า ในงาน Hard ยิ่งห่าง 8 คะแนน นี่ขัดกับสัญชาตญาณที่วงการเดินตามมาสองปีว่า “context window ยาวขึ้นแก้ได้ทุกอย่าง”

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

สำหรับทีมไทยและ SEA ผมเห็นสองมุมที่จับต้องได้

มุมต้นทุน ตัวเลข 777K → 116K โทเคนต่องาน คือความต่างที่เปลี่ยนว่าโปรเจกต์เอเจนต์จะได้ไปต่อหรือถูกปิด สำหรับทีมที่รันเอเจนต์บนงบจำกัด การลดโทเคนต่องานลง 6 เท่าโดยคะแนนไม่ตก มีค่ามากกว่าการอัปเกรดไปโมเดลที่แพงกว่า และเป็นเหตุผลที่ควรวัด “โทเคนต่องานที่สำเร็จ” ควบคู่กับ pass rate เสมอ — เหมือนที่ Microsoft เพิ่งเริ่มทำใน model card ของ MAI-Code-1.1-Flash วันเดียวกัน

มุมอธิปไตยข้อมูล นี่คือจุดที่ Apache 2.0 + รันเองมีน้ำหนักจริงสำหรับองค์กรไทย ความจำของเอเจนต์คือสิ่งที่จะสะสม ความรู้ภายในที่อ่อนไหวที่สุดขององค์กร — โครงสร้างเรโป กติกาการ deploy ข้อควรระวังของระบบ legacy ที่ไม่มีเอกสาร การส่งของพวกนี้ไปเก็บบนบริการความจำของ vendor ต่างประเทศเป็นเรื่องที่หน่วยงานภายใต้ PDPA หรือ ธปท. ควรคิดให้จบก่อนเปิดใช้ ทางเลือกที่เก็บลง Postgres ของตัวเองจึงไม่ใช่แค่เรื่องประหยัด แต่เป็นเรื่องที่ทำให้ผ่านการตรวจสอบได้

ข้อควรระวังที่ต้องพูดให้ตรง: ตัวเลขทั้งหมดนี้มาจาก IBM วัดเอง บนเบนช์มาร์กเดียว (AppWorld) split เดียว (test_normal 168 งาน) และบทความไม่ได้รายงานผลบน split ที่ยากกว่า ยังไม่มีการทำซ้ำจากภายนอก และเรโปยังใหม่มาก ควรลองกับ workload ของตัวเองก่อนเชื่อตัวเลข — แต่ข้อดีคือมันเปิดโค้ดครบ ใครอยากพิสูจน์ก็ทำได้เลย ซึ่งเป็นมาตรฐานที่งานประเภทนี้ควรถูกตัดสิน

แหล่งข่าว

• Thinking of ACE? We Can Do It with Fewer Tokens — IBM Research บน Hugging Face Blog
• AgentToolkit/altk-evolve — GitHub (Apache 2.0)
• About GitHub Copilot Memory — GitHub Docs
• Building an agentic memory system for GitHub Copilot — The GitHub Blog