การจดจำบันทึกเซสชันไม่ได้มีประโยชน์ต่อเอเจนต์
(12gramsofcarbon.com)- ในงาน SWE หากเอเจนต์สามารถเห็นคอนเท็กซ์อย่างเอกสาร, PR และคอมมิตอยู่แล้ว การ ค้นหาบันทึกเซสชัน ในอดีตไม่ได้สร้างข้อได้เปรียบด้านประสิทธิภาพ
- วิธีที่พบบ่อยคือเก็บ transcript ทั้งหมดลง DB แล้วเพิ่ม vector search, Elasticsearch, SQL search และ graph จากนั้นเปิดให้ใช้ผ่าน MCP หรือ CLI skill แต่จากการทดสอบเปรียบเทียบหลายเดือนพบว่าไม่ได้สร้างความแตกต่าง และบางครั้งอาจทำให้คุณภาพของโมเดลแย่ลง
- ในสภาพแวดล้อมที่มี commit message, PR message, เอกสาร และ metadata ที่ดี ข้อมูลสำคัญถูกจัดระเบียบไว้แล้วใน ผลงานจากการเขียนโค้ด ทำให้บันทึกเซสชันเป็นเพียงข้อมูลซ้ำและบันทึกชั่วคราวที่ถูกอ่านกลับเข้าไปเป็น token
- เอเจนต์ทำ การลบคอนเท็กซ์ ที่จำเป็นต่อหน่วยความจำระยะยาวได้ไม่ดี และเพราะไม่มีสถานะ จึงอาจมองโค้ด, บันทึก และ token ทั้งหมดใน input context เป็นเจตนา ทำให้ intent drift สะสม
- บันทึกเซสชันอาจมีประโยชน์ต่อ observability ของทีม แต่ในฐานะเครื่องมือเพิ่มประสิทธิภาพกลับเป็นผลลบ และข้อเสนอการเปลี่ยนแปลงรายสัปดาห์ของ nori bots ก็ยังต้องให้คนตรวจ diff โดยอัตราการยอมรับจริงต่ำกว่า 20%
เหตุผลที่การค้นหาบันทึกเซสชันไม่ช่วยเพิ่มประสิทธิภาพ
- ในงาน SWE แม้จะให้ค้นหาบันทึกเซสชันในอดีต ภายใต้เงื่อนไขที่มีคอนเท็กซ์อื่นอยู่แล้ว ก็พบว่า ข้อได้เปรียบด้านประสิทธิภาพเป็น 0
- ความพยายามให้ไล่ดูบันทึกเซสชันโดยอัตโนมัติเพื่อปรับปรุงคอนเท็กซ์ของเอเจนต์ ก็ไม่ได้มีข้อได้เปรียบมากนักหากไม่มี การตรวจสอบโดยคน
- สถาปัตยกรรม memory แบบอิงเซสชันที่พบบ่อยมักมี flow ดังนี้
- เก็บ transcript ทั้งหมดของทั้งองค์กรลง DB
- เพิ่มเลเยอร์ vector search, Elasticsearch และ SQL search ไว้ด้านบน
- ทีมที่ทะเยอทะยานกว่านั้นใช้ทั้งสามอย่างและรวม graph ด้วย
- เปิดให้เอเจนต์ใช้งานผ่าน MCP หรือ CLI ที่มี skill
- จากการเปรียบเทียบหลายเดือนระหว่างการมีและไม่มีแนวทางค้นหาเซสชัน พบว่างานเพิ่มเติมนี้ไม่ได้สร้างความแตกต่าง และในบางกรณีอาจทำให้โมเดลแย่ลง
- ข้อมูลที่มีประโยชน์ถูกจัดระเบียบไว้แล้วใน ผลงานจากการเขียนโค้ด
- การเปลี่ยนแปลงโค้ดมี commit message ที่ดี, PR message, เอกสารครอบคลุม และ metadata ที่ถูกคอมมิตไปพร้อมกับโค้ด
- เมื่อเอเจนต์ทำงานกับโค้ดเฉพาะส่วน จะถูกสั่งให้ดูเอกสารและ PR ก่อนหน้า
- การค้นหาบันทึกเซสชันทำให้ต้องอ่านสิ่งที่รู้อยู่แล้วซ้ำอีกครั้ง และยังใช้ token ไปกับการตัดสินใจชั่วคราวและ scratchpad ที่ตั้งใจไม่บันทึกตั้งแต่แรก
จุดที่ memory อัตโนมัติสั่นคลอน
- เอเจนต์ไม่สามารถทำ การจัดระเบียบ memory ที่สำคัญต่อการรักษาหน่วยความจำระยะยาวได้
- ไม่เคยเห็นกรณีที่ลบคอนเท็กซ์จริง ๆ จากเซสชันหลายพันรายการ
- นี่ไม่ใช่คุณสมบัติที่แก้ได้ด้วย prompt engineering และเพราะเอเจนต์ไม่มีสถานะ จึงถือว่าทุกอย่างใน input context window เป็น ground truth
- โค้ด, memory เดิม และ token ทุกตัวถูกถือว่าเป็นการแสดงออกของเจตนา ไม่เว้นแม้แต่การตัดสินใจโดยพลการจากเซสชันเอเจนต์ก่อนหน้า หรือเนื้อหาที่ยังไม่มีคนตรวจสอบ
- ในกระบวนการนี้ intent drift จะสะสม
- ยิ่งเอเจนต์สร้างฐาน memory ด้วยตนเองมากเท่าไร การตีความเจตนาจาก input ก่อนหน้าที่ผิดพลาดก็ยิ่งสะสมต่อเนื่อง
- ไม่มี coding benchmark ใดที่สมมติว่า input data ปนเปื้อน และโมเดลจะเสียเปรียบเสียด้วยซ้ำหากสมมติว่า input data ผิด
- ไม่มีวิธีง่าย ๆ ที่จะทำให้ “อย่าลบ codebase” และ “ให้ลบคอนเท็กซ์ input บางส่วน” เป็นจริงพร้อมกัน
- สุดท้ายการท่องจำอัตโนมัตินำไปสู่ คอนเท็กซ์ขยะที่ไม่จำเป็น ซึ่งใช้ token เพิ่มต้นทุน และทำให้คุณภาพโมเดลลดลง
- บันทึกเซสชันอาจมีประโยชน์ต่อ observability ของทีม แต่ยากที่จะมองว่าเป็นเครื่องมือที่ทำให้เอเจนต์ดีขึ้น
วิธีของ nori bots ที่ให้คนตรวจสอบ
- แนวทางการเรียนรู้คอนเท็กซ์ตามเวลาไม่ได้เป็นไปไม่ได้เสียทีเดียว และ nori bots จะตรวจสอบสิ่งที่เกิดขึ้นในบริษัททุกสัปดาห์ เช่น PR, Slack, Drive แล้วเสนอการเปลี่ยนแปลงต่อ nori skillsets ในตัว
- ข้อเสนอการเปลี่ยนแปลงจะแท็กทีมใน Slack แต่ค่าเริ่มต้นคือปฏิเสธทั้งหมด
- หากต้องการยอมรับการเปลี่ยนแปลง ต้องดู diff ด้วยตนเองและตรวจว่าสอดคล้องกับเจตนาหรือไม่
- อัตราการยอมรับต่ำกว่า 20% และมองว่า “การอัปเดตอัตโนมัติ” อีก 80% ที่เหลือน่าจะทำให้โมเดลแย่ลง
- หากองค์กรขนาดหลายร้อยคนบันทึกการอัปเดตแบบนี้โดยอัตโนมัติเสมอ ก็อาจยิ่งไม่ยั่งยืนมากขึ้น
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
นึกถึงตอนที่ OpenAI บอกว่าใส่ฟีเจอร์ความจำข้ามเซสชันให้ ChatGPT สุดท้ายมันรู้สึกเหมือนเป็นฟีเจอร์ที่ไปหาข้อมูลจิปาถะเกี่ยวกับฉัน แล้วคัดลอกวางแทรกระหว่างพรอมป์โดยที่ฉันไม่ได้ยินยอมอย่างชัดเจน
ประมาณว่า “ช่วยเปรียบเทียบรถสามคันนี้ให้หน่อย อ้อ ข้อมูลประกอบนะ ฉันเป็น data engineer นามสกุลก่อนแต่งงานของแม่คือ Joana ฉันแพ้บทกวีแย่ ๆ โค้ดควรเป็น DRY ฉันชอบ SQL มากกว่า Python แล้วดอกไม้ที่มีพิษรุนแรงที่สุดในสแกนดิเนเวียคืออะไร?”
บริบทที่ถูกจำไว้ รั่วไหลเข้ามาในโปรเจกต์และบทสนทนาที่ไม่เกี่ยวข้องกันเลย จนได้ผลลัพธ์ประหลาดมากมาย เลยเป็นฟีเจอร์แรก ๆ ที่ปิด
เห็นด้วยอย่างมาก ระบบความจำของ claude-code มีประโยชน์เป็นบางครั้ง แต่บ่อยกว่ามากที่มันดึงข้อมูลเก่า ๆ ที่ทำให้งานปัจจุบันมัวลงมาใช้จนเป็นผลเสีย เห็นบ่อยมากว่าความจำของ Claude เองทำให้ Claude เข้าใจผิดไปไกล
ถ้าให้เดา น่าจะเกี่ยวกับการที่กระบวนการฝึกทำให้โมเดลแยก “สิ่งที่กำลังเกิดขึ้นตอนนี้” กับ “สิ่งที่เคยเกิดขึ้นมาก่อน” ไม่ออก ถ้ากระบวนการอนุมานจากความจำถูกใส่ไว้ในการฝึกด้วยก็คงต่างออกไป แต่เพราะเป็นฟีเจอร์ที่มาแปะเฉพาะตอน inference เลยให้ความรู้สึกว่าทำให้โมเดลสับสน
LLM ยังไม่ฉลาดพอที่จะทนต่อ มลพิษของบริบท แม้เพียงเล็กน้อยได้
ความคิดหรือบริบทที่ทำให้มันไปทางนั้นมีแรงเฉื่อยอยู่ ถ้าปล่อยไว้ก็จะเหนียวติดค้างอยู่แบบนั้น
แต่ถ้าภายหลังมันไปดึงสิ่งนั้นกลับมาจากความจำอีก ก็น่าหงุดหงิดทีเดียว
แนวคิดเรื่องการฝึกโดยรวมความจำเข้าไปด้วยน่าสนใจ
โดยทั่วไปแล้ว ไม่สำคัญนักว่าโค้ด “ตั้งใจจะให้ทำอะไร” สิ่งสำคัญคือ โค้ดทำอะไรจริง ๆ
log ของเซสชันมีประโยชน์ได้แน่นอน แต่มีประโยชน์ตอนเข้าสู่ ขั้นตอนตรวจสอบ ไม่ใช่ตอนพัฒนาต่อโดยกองสิ่งต่าง ๆ ทับลงไปเรื่อย ๆ บนนั้น ช่วงนั้นก็คือระหว่างแผนใน Markdown กับ CI ผ่าน มีโค้ดใหม่เพิ่มมา 800 บรรทัด และพอคลิกดูคร่าว ๆ ก็ดูใช้ได้
log ของเซสชันสามารถบอกได้ว่ามีการตรวจสอบด้วยมืออะไรบ้าง CI รันชุดทดสอบเดิม โค้ดบอกได้ว่า unit test ใหม่มีอะไร แต่ log ของเซสชันบอกได้ว่าเอเจนต์ใช้ Playwright จัดการแอปด้วยตัวเองหรือไม่ และได้อ่านรวมถึงพิจารณาไม่ใช่แค่ config สำหรับ dev แต่รวมถึง config สำหรับ prod ด้วยหรือไม่
ไม่ได้สมบูรณ์แบบ แต่ไม่ใช่ว่างานตรวจสอบทุกอย่างต้องกลายเป็น test ที่อยู่ใน repository ตลอดไป เราได้ผลลัพธ์มากจากการวิเคราะห์เซสชันย้อนหลัง เพื่อหาจุดที่เอเจนต์ตัดสินใจเองโดยไม่ถาม แล้วบังคับให้มันพิจารณาการตรวจสอบสำหรับการตัดสินใจเหล่านั้น เรื่องแบบนี้สั่งตั้งแต่ต้นได้ยาก แต่เห็นได้ง่ายจาก log ของเซสชัน
เป็นปัญหาน่ารำคาญ คำถามแบบ สมมติฐาน ที่เคยถามไว้ก่อนหน้านี้ทำให้มันสร้างสมมติฐานปลอมขึ้นมาตลอด
แค่เพราะฉันเคยถามให้ช่วยค้นอะไรบางอย่าง มันก็สรุปว่าฉันเป็นเจ้าของ data center และมี GPU จำนวนมาก
ผมว่านี่ก็เป็นรูปแบบหนึ่งของ บทเรียนราคาแพง หรือเปล่า บริบทกับเอเจนต์ที่เราลงแรงสร้างขึ้นมา มีโอกาสสูงว่าจะหายความสำคัญไปเมื่อมีโมเดลที่ใหญ่กว่าและดีกว่าออกมา
ประวัติการสนทนาแบบนั้นมีประโยชน์มากกับโมเดลที่ความสามารถต่ำกว่า แต่แทบอาจไม่จำเป็นเลยสำหรับโมเดลแนวหน้า
ผมใช้ harness แบบ custom ที่อิงจาก https://minimal-agent.com/ ซึ่งอิงจาก swe-mini-agent และ logic หลักมีประมาณ 50 บรรทัด แค่มี Bash ก็พอ
สำหรับงานเล็ก ๆ มันเร็วกว่าฮาร์เนสมาตรฐานของแต่ละโมเดลประมาณ 8 เท่า และใช้ token น้อยกว่าประมาณ 8 เท่า
สำหรับงานใหญ่ ยังไม่ได้ทดสอบมากนัก มันใช้งานได้ แต่ในกรณีนั้นดูเหมือนจะโฟกัสน้อยลงและผลิตภาพลดลงเล็กน้อย system prompt ขนาด 20,000 token ของ harness ใหญ่ ๆ อาจกำลังทำงานสำคัญในการกำกับ flow การพัฒนาซอฟต์แวร์อยู่ก็ได้ เช่น ได้ยินว่า Fable มี custom system prompt สำหรับ Claude Code ซึ่งอาจเป็นเหตุผลที่มันทำงานเชิงรุกกว่ามาก
ดังนั้นผมยังอยากมองว่า context engineering ยังมีคุณค่าอยู่ เพียงแต่ดูเหมือนคุณค่านั้นลดลงทุกครั้งที่มีโมเดลใหม่ออกมา เพราะโดยรวมโมเดลถูก fine-tune ให้ทำพฤติกรรมโง่ ๆ น้อยลง ทำให้ต้องจูงมือน้อยลง
ก่อนอื่น ผมคิดว่าโมเดลยังต้องมี ชั้นของบริบท อยู่ วิธีหนึ่งในการมองบริบทคือการบีบอัด เราให้บริบทเพื่อทำให้โมเดลเข้าใจได้ง่ายขึ้นว่าควรทำอะไร แม้ในโลกที่ความจุของโมเดลและความยาวบริบทไม่มีขีดจำกัด มันก็ยังมีประโยชน์ เพราะช่วยไม่ให้ต้องอนุมานทุกอย่างใหม่จากหลักการพื้นฐานทุกครั้ง ตราบใดที่โมเดลทำงานได้ดีขึ้นด้วย token น้อยลง และเรายังสนใจต้นทุน token บริบทก็เป็นทางลัดที่มีประโยชน์ หรืออาจถึงขั้นจำเป็น
ถ้าเห็นว่าจำเป็นต้องมีชั้นบริบทในรูปแบบใดรูปแบบหนึ่ง คำถามถัดไปก็คือควรเป็นชั้นแบบไหน ตรงนี้ผมเห็นด้วยว่าควรทำงานร่วมกับรูปแบบที่โมเดลคุ้นเคย เช่นไฟล์ Markdown ที่วางอยู่ข้างโค้ด แต่เรื่องนี้ใกล้เคียงกับปัญหาที่วิธีแก้แบบออกแบบมากเกินไปไม่เข้าใจผู้ใช้หลัก ซึ่งก็คือเอเจนต์ มากกว่าปัญหาว่าจำเป็นต้องมีบริบทหรือไม่
แต่ผมสงสัยมากว่าการทำนาย token ถัดไปที่ดีกว่านี้มาก ๆ จะทำให้โครงสร้างทั้งหมดนั้นกลายเป็นของล้าสมัยไปเลยหรือไม่ ไม่ว่าคำตอบจะออกมาทางไหน ก็น่าจะเปิดเผยอะไรหลายอย่าง
ต้องจำไว้ว่าโครงสร้างของสมองเองก็ถูกเรียนรู้เช่นกัน เพียงแต่เกิดขึ้นในสเกลเวลาที่ยาวกว่าช่วงชีวิตของปัจเจกมาก
เห็นด้วยว่าไม่จำเป็นต้องสร้างระบบความจำที่ซับซ้อนขึ้นมาโดยเฉพาะ สิ่งที่ควรค่าแก่การจดจำควรอยู่ใน เอกสาร, ไกด์, คอมเมนต์ในซอร์ส, ข้อความคอมมิต, ตั๋วงาน
ไม่จำเป็นต้องมีอีกชั้นหนึ่ง ความละเอียดทุกระดับที่นึกออกล้วนถูกครอบคลุมไว้แล้วด้วยแนวปฏิบัติที่ดีที่มีอยู่
ส่วนขยายนี้ทำสิ่งต่อไปนี้: https://github.com/gitsense/pi-brains
ตอนนี้ “มนุษย์” ยังต้องกำหนดกฎ routing สำหรับวิธีเข้าถึงข้อมูล แต่ในอนาคตจะรองรับ “knowledge agent” ที่คอยมอนิเตอร์บทสนทนาแล้วฉีดบริบทเข้าไปเมื่อจำเป็น
~/.claude/…ยิ่งเป็นแบบนั้นในโปรเจกต์ที่ต้องการความจำ ผมแค่เพิ่มบรรทัดหนึ่งใน AGENTS.md ให้เขียน MEMORY.md เพื่อเก็บความจำ หรือใช้ STATUS.md เพื่อติดตามความคืบหน้า
แต่ถ้าติดแท็กไว้ใน tracking log ก็จะหาได้อย่างมีประสิทธิภาพเมื่อจำเป็น แถมเอกสารเสื่อมสภาพไปตามเวลา แต่ tracking log สามารถแนบ commit hash หรือข้อมูลอื่น ๆ เพื่อทำให้อายุความถูกต้องชัดเจนกว่าได้
ตรงนี้ขอค้านอย่างแรง
ผมให้ Claude/Codex ทิ้ง log ไว้ [1] แค่สั่งด้วย prompt ใน AGENTS.md [0] เท่านั้น
“ทุก session ต้องสร้างอย่างใดอย่างหนึ่งระหว่าง session log หรือแผน และตอนท้ายต้องต่อด้วยสรุปที่เขียนไว้ ค่าเริ่มต้นคือ log และใช้แผนเฉพาะกับงานออกแบบที่มีสาระจริง ๆ เท่านั้น”
เรื่องนี้มีคุณค่ามหาศาล เช่น วันนี้ผมเริ่ม session หลายอันแบบนี้: “สถานะงาน Renovate เป็นยังไง?”, “ช่วงหลังทำงาน X ไว้ หาให้หน่อย”, “แก้ปัญหา backup แล้วหรือยัง? ขั้นต่อไปคืออะไร?”, “บั๊กนี้กลับมาอีกแล้ว ไม่ใช่ว่าเราแก้ไปแล้วเหรอ?”
[0]: https://github.com/shepherdjerred/monorepo/blob/main/AGENTS....
[1]: https://github.com/shepherdjerred/monorepo/tree/main/package...
โดยรวมแล้วผมชอบระบบความจำ อ้างอิงคือส่วนใหญ่ใช้ Opus 4.8 + Max effort
มันดึงเรื่องที่เกี่ยวข้องจากความจำออกมาค่อนข้างบ่อย เช่น ถ้าขอให้เสนอผู้ให้บริการ OIDC แบบ self-hosted สักสองสามตัว มันจะพูดทำนองว่า “ถ้าพิจารณาขนาดทีมปฏิบัติการแล้ว ตัวนี้อาจเหมาะกว่าเพราะ X และ Y”
แน่นอนว่าข้อมูลแบบนี้อาจเป็นสิ่งที่ควรใส่ไว้ใน CLAUDE.md แต่ในกรณีนั้นผมไม่ได้คิดเองด้วยซ้ำว่าควรเอาไปใส่ CLAUDE.md และดีที่ความจำดึงมันขึ้นมาให้
บางครั้งก็พลาดเหมือนกัน วันนี้ผมถามเรื่องปัญหา authentication แล้วมันบอกว่า “เพราะวางแอปไว้หลัง haproxy อาจติดการตั้งค่า trusted proxy นี้” สำหรับ 95% ของแอปเราเป็นคำพูดที่ถูกและควรกล่าวถึง แต่ครั้งนี้ไม่ใช่ เลยต้องแก้ให้ถูก ถึงอย่างนั้น ถ้าจริง ๆ แล้วอยู่หลัง proxy มันก็อาจช่วยประหยัดเวลาได้มาก ดังนั้นดีแล้วที่มันพูดขึ้นมา
โดยเฉพาะถ้าถามคำถามเชิงสมมติบ่อย ๆ หรือช่วยแก้ปัญหาของคนอื่น เรื่องนี้จะยิ่งยากขึ้น ถ้าเป็นมนุษย์ก็น่าจะไม่สรุปเอง แต่ถามยืนยันว่า “นี่เป็นเรื่องของทีมปฏิบัติการของ X ใช่ไหม? ขนาดทีมยังเป็น Y อยู่หรือเปล่า?”, “แอปนี้ก็อยู่หลัง proxy เหมือนแอปอื่น ๆ ที่เคยพูดถึงก่อนหน้านี้ไหม?”
บริบทแบบนี้ยังมีโครงสร้างลำดับชั้นที่ชัดเจนซึ่งต้อง model ให้ถูกต้องด้วย เช่น คนหนึ่งอาจเกี่ยวข้องกับหลายทีมพร้อมกันที่อยู่ภายใต้กฎต่างกัน และมนุษย์เข้าใจเรื่องแบบนี้ได้อย่างเป็นธรรมชาติ
ต่อให้ปิดความจำ เรื่องแบบนี้ก็เกิดขึ้นได้ภายในบทสนทนาเดียว
เหมือน เพื่อนน่ารำคาญ ที่จำอะไรบางอย่างจากบทสนทนาเก่า ๆ แล้วคอยยกมันมาพูดใส่ ทั้งที่ผมเติบโตและเปลี่ยนไปแล้ว
โดยแก่นแล้วนี่คือ ปัญหาฮาร์ดแวร์ 1 ล้าน token ไม่ใช่บริบทที่พอจะเข้าใจ codebase ได้แบบที่มนุษย์เข้าใจ
ความสามารถในการลืมแบบเลือกได้นั้นอาจมีคุณค่ามาก แต่ตอนนี้มันเป็นเพียงระดับที่มาทดแทนความสามารถของมนุษย์ในการจำรูปทรงคร่าว ๆ ของบางสิ่ง ตัดสินว่ามันไม่น่าสนใจ และจำได้ว่ามันไม่น่าสนใจ
มีคนบอกว่าความจำมีประโยชน์ก็ต่อเมื่อมนุษย์คอยนำทาง แต่ผมคิดว่าคำตอบที่ถูกต้องลึกกว่านั้น บางทีอาจเป็นการเอา codebase ทั้งหมดและทุก session ของ agent เข้าไป fine-tune โมเดล。ただเมื่อถึงจุดนั้นอาจต้องมีคำแนะนำไม่ให้ใส่บาง session เข้าไปในโมเดล หรืออาจไม่ต้องก็ได้ และบทเรียนอันเจ็บปวดอาจถูกนำไปใช้