อย่าเชื่อหน้าต่างคอนเท็กซ์ขนาดใหญ่
(garrit.xyz)- หน้าต่างคอนเท็กซ์ของ LLM อาจแบ่งออกเป็น ช่วงอัจฉริยะ ที่โมเดลทำงานได้เฉียบคม และ ช่วงทื่อ ที่ความใส่ใจลดลงจนเริ่มลืมคำสั่งก่อนหน้า
- จุดแบ่งอยู่ราว 100k โทเค็น และแม้ขนาดหน้าต่างคอนเท็กซ์ที่โฆษณาไว้จะใหญ่ ก็ไม่ได้หมายความว่าช่วงที่ใช้งานได้จริงจะใหญ่ตามไปด้วย
- เอเจนต์สำหรับเขียนโค้ดสามารถใช้โทเค็นหมดไปอย่างรวดเร็ว และแตะ 100k โทเค็นได้เพียงแค่อ่านไฟล์ ดีบักยาว ๆ และรันชุดทดสอบขนาดใหญ่
- รายงาน RULER และ รายงาน context rot ของ Chroma แสดงให้เห็นว่า effective context เป็นเพียงส่วนหนึ่งของตัวเลขที่โฆษณาไว้ และประสิทธิภาพจะค่อย ๆ ลดลงเมื่อเติมหน้าต่างจนเต็ม
- แทนที่จะพึ่งการสรุปอัตโนมัติสำหรับเซสชันยาว ๆ การเก็บข้อมูลไว้นอกเซสชันด้วย สเปกและชิ้นงานขนาดเล็ก ที่เขียนเอง จะช่วยให้งานอยู่ในช่วงอัจฉริยะได้
ข้อจำกัดที่แท้จริงของหน้าต่างคอนเท็กซ์
- หน้าต่างคอนเท็กซ์ของ LLM อาจแบ่งออกเป็น ช่วงอัจฉริยะ ที่โมเดลทำงานได้คม และ ช่วงทื่อ ที่ความใส่ใจลดลง
- ในช่วงทื่อ โมเดลจะเริ่มลืมสิ่งที่ส่งให้ไปเมื่อไม่กี่นาทีก่อน
- จุดแบ่งอยู่ราว 100k โทเค็น
- แม้ขนาดหน้าต่างคอนเท็กซ์ที่โฆษณาไว้จะใหญ่ จุดแบ่งนี้ก็ไม่ได้หายไป
- เอเจนต์สำหรับเขียนโค้ดใช้โทเค็นอย่างรวดเร็วในรูปแบบการใช้งานสมัยใหม่
- เพียงแค่อ่านไฟล์ไม่กี่ครั้ง ดีบักต่อเนื่องยาว ๆ หรือรันการทดสอบวงกว้าง ก็อาจแตะ 100k โทเค็นได้แล้ว
- ผู้ให้บริการโฆษณาหน้าต่างคอนเท็กซ์ขนาด 200k, 1M, 2M แต่ตัวเลขเหล่านี้ไม่ได้หมายถึงชุดงานที่ใช้งานได้จริง
- หน้าต่างคอนเท็กซ์ขนาดใหญ่ส่วนใหญ่ใกล้เคียงกับการเป็น ตัวเลขทางการตลาด
- สถาปัตยกรรมเบื้องหลังนั้นใช้งานได้ แต่ก็เป็นการปิดทับปัญหาที่กลไก attention พื้นฐานยังแก้ไม่ได้จริง
- ตัวเลขที่แสดงบนผลิตภัณฑ์เพิ่มขึ้นทุกครั้งที่ออกรุ่นใหม่ แต่ส่วนที่ใช้งานได้จริงไม่ได้เพิ่มตามในอัตราเดียวกัน
- RULER และ รายงาน context rot ของ Chroma แสดงให้เห็นว่า effective context เป็นเพียงส่วนหนึ่งของตัวเลขที่โฆษณาไว้
- ยิ่งเติมหน้าต่างคอนเท็กซ์มาก ประสิทธิภาพก็จะค่อย ๆ ลดลง
วิธีทำงานที่ทำให้เซสชันสั้น
- เอเจนต์รุ่นใหม่เริ่มมีความสามารถบีบอัดอัตโนมัติเพื่อจัดการกับเซสชันที่ยาว
- Claude Code จะทำ auto-compact โดยสรุปประวัติและเริ่มใหม่เมื่อเซสชันยาวเกินไป
- วิธีนี้มีประโยชน์ แต่จะเริ่มทำงานหลังจากใช้เวลาอยู่ในช่วงทื่อไปแล้ว
- ตัวสรุปเองก็ถูกสร้างโดยโมเดลที่ประสิทธิภาพลดลงแล้วเช่นกัน
- วิธีส่งต่องานที่ดีกว่าคือเปิดเซสชันใหม่แล้วส่งสเปกที่เขียนเองต่อให้
- สเปกที่เขียนเองเป็นเอกสารส่งต่องานที่มีสัญญาณชัดกว่าการสรุปอัตโนมัติ
- เพราะมนุษย์สามารถตัดสินใจเองได้ว่าอะไรสำคัญต่อจากนี้
- วิธีนี้สอดคล้องกับแนวทาง breadcrumb ที่ทิ้งชิ้นงานไว้ให้เซสชันถัดไปหรือคนถัดไปมารับช่วงได้อย่างสะอาด
- obra/superpowers และ mattpocock/skills ออกแบบเวิร์กโฟลว์ของเอเจนต์โดยยึดชิ้นงานขนาดเล็กที่มีชื่อกำกับเป็นศูนย์กลาง
- PRD, แผนงาน, skill และการส่งต่องานให้ sub-agent เป็นตัวอย่างของชิ้นงานเหล่านี้
- ชิ้นงานแต่ละชิ้นจะย้ายข้อมูลออกจากเซสชันสดเพื่อให้เซสชันถัดไปกลับมาอ่านได้
- วิธีนี้ช่วยให้เซสชันการทำงานอยู่ในช่วงอัจฉริยะได้
- หน้าต่างคอนเท็กซ์ควรถูกมองเหมือน งบประมาณ
- ควรตั้งสมมติฐานว่าส่วนที่ช่วยได้จริงคือเพียงไม่กี่ชังก์แรกด้านหน้า
- ข้อมูลที่ย้ายจากเซสชันสดไปเป็น written artifact จะช่วยลดสิ่งที่ต้องแย่งความใส่ใจของโมเดล
2 ความคิดเห็น
ไม่ใช่แค่ 100,000 หรอก แค่ราว ๆ 40,000-50,000 โทเคนก็ดูออกแล้วว่ามันเริ่มรับมือไม่ไหว
ความคิดเห็นจาก Hacker News
การเรียนรู้พื้นฐานของ AI ค่อนข้างสนุก แต่ไม่เห็นด้วยกับทิศทางที่กำลังไหลไปตอนนี้
ยากจะอธิบายเป็นคำพูดว่าคอมเมนต์ในเธรดแบบนี้ให้ความรู้สึกน่ากังวลแค่ไหน คำบอกเล่าประสบการณ์ด้วยเจตนาดีแบบ “XYZ เป็นแบบนี้สำหรับฉัน” ดูเหมือนคำแนะนำในเธรด Facebook เรื่องดูแลสัตว์เลี้ยงหรือทำอาหาร
กลุ่ม Facebook เรื่อง 3D printing หนักกว่านั้นอีก แต่ถ้าเป็นคนที่พิมพ์งานจริงและอยากเข้าใจว่ามีอะไรเกิดขึ้นจริง ๆ ก็น่าจะรู้ว่าหมายถึงอะไร
ในโลกของ LLM โดยเฉพาะโลกของ LLM บนคลาวด์ ความเข้มงวดร่วมกันที่เคยมีเหมือนพังทลายหมดแล้ว และสุดท้ายก็เหลือแค่การทำตามกันแบบกึ่งไสยศาสตร์ ใครก็ไม่ได้ถูกหรือผิดไปกว่าใครอีกต่อไป
บรรยากาศประมาณว่า “ลองล้าง context ด้วยน้ำยาล้างจาน Dawn เช็ดให้แห้ง แล้วทา glue stick บาง ๆ หนึ่งชั้นหรือยัง?”
ไม่อยากพูดแรงเกินไปกับคนที่พยายามจะช่วย แค่รู้สึกว่ามันต่างจากเธรดหัวข้ออื่นมาก ปกติข้อเสนอของใครสักคนจะถูกคนอื่นโต้แย้งหรือขัดเกลา และบางทีก็มีคนมาอธิบายอะไรอย่างวิธีเลือกจาก bash history จนชีวิตเปลี่ยนได้ แต่เธรดแบบนี้สุดท้ายมักไหลไปจบที่ “มันไม่แปลกเหรอที่ถ้าขู่แล้วใช้ได้ผล?”
แต่ agent ก็ยอดเยี่ยมมาก และการได้เป็น “ผู้ออกแบบกระบวนการคิด” ก็สนุกด้วย ผมคงไม่ย้อนกลับไปแล้ว ต่อให้การพัฒนา AI หยุดวันนี้ เส้นทางอาชีพของผมก็คงไม่เหมือนเดิมอีก
ผมผ่านการประชุมมามากเกินไปที่การตัดสินใจไม่ได้อยู่บนเกณฑ์เชิงวัตถุและวัดได้ แต่เป็น “เพราะบริษัทที่ดังขึ้นมานิดหน่อยเขาทำแบบนั้น” แม้จะมีหลักฐานว่าบริษัทนั้นเองก็ไม่ได้ใช้แนวทางนั้นเป็นปกติ หลักฐานนั้นก็มักแทบไม่มีน้ำหนักอย่างน่าตกใจ
พอรวมกับข้อเท็จจริงที่ว่า LLM ไม่เป็นเชิงกำหนดอย่างมาก คำแนะนำเกี่ยวกับ LLM ก็แทบกลายเป็นคำแนะนำเรื่องจัดสวน
แม้แต่ “benchmark” ส่วนใหญ่ก็ใกล้เคียงกับความพยายามแช่แข็งความรู้สึกของใครบางคนให้อยู่ในรูปที่พอจะใช้ได้สำเร็จระดับหนึ่งเท่านั้น
สุดท้ายเลยกลับไปใช้
/planแล้วสั่งว่า “เขียนลงในเอกสาร Markdown ไว้เผื่ออนาคตก่อนจะวนทำ implementation” และหวังว่าอีกประมาณเดือนหน้าจะมีอะไรที่เข้มงวดและมีเหตุผลรองรับมากกว่านี้ออกมาส่วน glue stick ผมไม่ได้ใช้เลย เพราะไม่จำเป็น แต่ Dawn ดูจะช่วยให้ Bambu build plate กลับมาติดดีอีกครั้งได้ค่อนข้างมีประสิทธิภาพ ไม่ได้ไปหามาใช้โดยเฉพาะ แค่มีอยู่แล้วไว้ล้างจาน IPA ไม่ได้ผลเลยลองใช้ Dawn ดู และมันก็ช่วยให้ชิ้นงานกลับมาติดดีได้หลายครั้งแล้ว ยังไปไม่ถึง N=30 นะ
ตลอดหลายทศวรรษที่อยู่ในวงการเทคโนโลยี ผมแทบไม่ค่อยเห็นความเข้มงวดอะไรเลย เครื่องมือเพิ่มขึ้น กระบวนทัศน์เกิดขึ้น ตายไป แล้วก็กลับมาใหม่ และไม้บรรทัดที่ใช้วัดอะไรก็ตามก็มักมีไม้บรรทัดคู่แข่งอีกอันที่ใช้คนละหน่วยเสมอ เมื่อพ้นจากฟิสิกส์ของพลังงานและสัญญาณ กับต้นทุนที่ครอบงำของ silicon wafer ไปแล้ว พวกเราแทบทั้งหมดก็ใกล้เคียงกับช่างซ่อมที่ต่างกันแค่ระดับความชำนาญ เมื่อเทียบกับศาสตร์จำนวนน้อยที่เก่าแก่กว่ามาก
เราจัดการข้อจำกัดของ context กันมาได้ค่อนข้างง่ายมาโดยตลอด แค่กำหนดสเปกและจำกัดขอบเขตให้ชัด LLM ต้องการสเปกที่ชัดเจนและการกำกับที่เข้มแข็งจึงจะให้ผลลัพธ์ที่ดี
แต่สิ่งนี้เองก็อาจเป็นเพียงสัญชาตญาณการทำงานแบบแก้ขัดของยุคปัจจุบัน บางทีอีก 90 วัน ภาระนี้อาจหายไปด้วยซ้ำ และ prompt ง่าย ๆ เพียงอันเดียวอาจสร้างระบบปฏิบัติการระดับโลก ภาษาโปรแกรมระดับโลก และรากฐานเชิงรูปนัยทางคณิตศาสตร์สำหรับทั้งสองอย่างได้
มีการตั้งข้อจำกัดง่าย ๆ อย่างหนึ่งไว้ใน agent loop เพื่อหลีกเลี่ยง ปัญหาขนาดคอนเท็กซ์ โดยบล็อกการเรียกใช้เครื่องมือทั้งหมดในเธรดสนทนาหลักของผู้ใช้ งานที่ต้องเรียกเครื่องมือจะเกิดขึ้นได้เฉพาะภายในการเรียกซ้ำของเอเจนต์ และส่งกลับมาเฉพาะผลลัพธ์ให้ตัวเรียก
แม้ในโค้ดเบสที่มีมากกว่า 1 ล้าน LOC ก็ยังคุยกันในระดับสูงต่อเนื่องได้ทั้งวันโดยไม่ชนขีดจำกัดโทเคนที่มีนัยสำคัญ ไม่ต้องพึ่งเทคนิคบีบอัดหรือสรุปอะไรเลย ต่อให้เผาไป 50 ล้านโทเคนในการเรียกซ้ำ เธรดสนทนาหลักก็อาจยังไม่แตะ 1 แสนโทเคนด้วยซ้ำ
ทุกครั้งที่เอเจนต์กลับลงไปยัง Narnia ก็ต้องมีงานทำซ้ำเพื่อ “bootstrap” ใหม่ แต่ก็ยังมีประสิทธิภาพกว่าการแบกคอนเท็กซ์แบนขนาดใหญ่ที่พยายามยัดทุกอย่างไว้ตลอดเวลา
การเรียกซ้ำ มีประสิทธิภาพมากในการควบคุมการใช้โทเคน แต่ก็มีข้อจำกัดเช่นกัน ไม่เคยได้ประโยชน์จากความลึกของการเรียกซ้ำเกิน 1 เลย เห็นเอเจนต์ลองทำอยู่บ้างหลายครั้ง แต่ประสิทธิภาพจริงไม่ออกมา ดูเหมือนว่าการเรียกซ้ำเชิงสัญลักษณ์จากภายนอกจะไม่ใช่สิ่งที่โมเดลแนวหน้าถูกฝึกมา มันเก่งมากในการเลียนแบบการเรียกซ้ำภายในคอนเท็กซ์ แต่ถ้าจุดประสงค์คือการลดการใช้โทเคน นั่นกลับเป็นทิศทางที่ไม่ต้องการ
ณ จุดนี้ บทสนทนาหลักจะทำหน้าที่แค่ประสานงานของงานเท่านั้น
เจอบ่อยในโฟลว์แก้ปัญหาหรือวิเคราะห์ข้อมูล โดยโยนงานเก็บและรวมข้อมูลไปให้ sub-agent แล้วดึงกลับมาแค่ผลสรุป
ในทำนองเดียวกัน บางทีก็ให้เอเจนต์หลักคงคอนเท็กซ์ไว้ในเอกสารออกแบบหรือไฟล์ Markdown แล้วค่อยอัปเดตไปเรื่อย ๆ แบบนั้นก็ลบ เริ่มใหม่ หรือส่งต่องานได้ทุกเมื่อ
พูดอีกแบบคือมันคล้าย recursion ที่มี tail call optimization
ในบางแง่ มันคือการทำแนวทางที่ขับเคลื่อนด้วยสเปกให้เป็นภาพรวมทั่วไปขึ้น โดยนอกจากสเปกเชิงรูปแบบแล้ว ยังมีบัฟเฟอร์ที่สืบทอดต่อกันได้ค้างอยู่ในหน่วยความจำ
ต่อให้ไม่ใช่ผู้เชี่ยวชาญ “เคล็ดลับง่าย ๆ” นี้ก็ดูเหมือนจะแก้ปัญหาคอนเท็กซ์และทำให้ควบคุมการใช้โทเคนได้ละเอียดขึ้นมาก ขอบคุณที่แชร์ทิปนี้ในคอมเมนต์ HN ต่อไปวิธีที่คนวงในใช้ AI agent อาจเปลี่ยนไปเลยก็ได้ ตามให้ทันยากจริง ๆ
ตั้งแต่ Anthropic ให้ หน้าต่างคอนเท็กซ์ 1 ล้านโทเคน ในแพ็กเกจสมัครสมาชิก ผมก็ไม่ค่อยเจอประสบการณ์แบบนี้ใน Opus อีกแล้ว ปกติก็เกิน 5 แสนโทเคนบ่อย ๆ และบางครั้งใกล้ 8 แสนโทเคนก็ยังไม่เห็นปัญหานี้
มีเห็นอยู่บ้างเมื่อเข้าใกล้ขีดจำกัดจริง ๆ ที่เกิน 9 แสนโทเคน แต่ก็ไม่รุนแรงเท่าที่ผู้เขียนเจอ
ตั้งแต่แรกแล้ว ในงานเดี่ยวหรือกลุ่มงานที่เกี่ยวข้องกันมากพอจะคงคอนเท็กซ์เดียวกันไว้ ก็ไม่ค่อยได้เติมหน้าต่างคอนเท็กซ์จนเต็มขนาดนั้น ปกติก็อยู่แถว 2 แสนถึง 6 แสน
ไม่ได้แปลว่าไม่มีใครเจอประสบการณ์แบบนี้เลย แต่ที่บางคนเจอบ่อยจนถึงขั้นตั้งชื่อให้มันก็ดูแปลก ๆ อยู่
ส่วนตัวผมมองว่าช่วงที่ Opus ฉลาดจริงคือ ต่ำกว่า 6 หมื่นโทเคน และ Opus 4.7 กับ 4.8 แย่กว่าเพราะใช้ tokenizer ที่ละเอียดขึ้น
ดูเหมือนคุณภาพจะเป็นแนวโน้มขาขึ้น
แต่ละโมเดลและแต่ละเวอร์ชันของโมเดลใช้ โครงสร้าง attention ต่างกัน ซึ่งส่งผลต่อประสิทธิภาพในคอนเท็กซ์ยาว ปริมาณและประเภทของการฝึก long-context ก็ต่างกันแน่ ๆ
แต่ละเอเจนต์ก็จัดคอนเท็กซ์และทำ context compression ต่างกันด้วย
ถ้าไม่ใช่โมเดลเดียวกัน เอเจนต์/harness เดียวกัน และงานที่คล้ายกันมาก ก็ไม่มีเหตุผลอะไรที่จะคาดหวังว่าประสบการณ์เรื่องพฤติกรรมของโมเดลเมื่อคอนเท็กซ์ใหญ่จะเหมือนกัน
สำหรับบางปัญหา หน้าต่างคอนเท็กซ์ใหญ่ก็อาจใช้ได้ แต่ผมรู้สึกว่าการเอนเอียงไปทางคอนเท็กซ์ที่เล็กกว่า ต่ำกว่า 3 แสน มีประสิทธิภาพกว่า
Opus 4.5 พอใกล้ขีดจำกัด 2 แสน การเรียกเครื่องมือก็เริ่มล้มเหลว, Opus 4.6 ไปได้ราว 3 แสนก่อนจะเริ่มสับสน, Opus 4.7 ขยายได้ถึงประมาณ 4 แสนแต่หลังจากนั้นก็เข้าสู่ช่วงโง่ลง, ส่วน Opus 4.8 มีบางเซสชันที่เกิน 5 แสนได้แบบสบาย ๆ
Fable แม้จะมีเวลาลองใช้น้อย แต่ก็มีหลายเซสชันที่ไปถึง 8–9 แสนได้โดยไม่มีปัญหา
Opus เวอร์ชันล่าสุดเกิน 1 แสนแล้วยังโอเค แต่โดยทั่วไปผมพยายามคงไว้ต่ำกว่า 2 แสน
เพราะงั้นผมเลยคิดว่าสิ่งที่เรียกว่า ระบบหน่วยความจำ มักเป็นความผิดพลาดที่ทำให้โมเดลโง่ลง โมเดลไม่ได้มีหน่วยความจำ มีแต่คอนเท็กซ์ และยิ่งยัดข้อเท็จจริงที่ไม่เกี่ยวข้องเข้าไปในคอนเท็กซ์มากเท่าไร คอนเท็กซ์ที่ใช้กับปัญหาจริงก็ยิ่งน้อยลงเท่านั้น ยิ่งมีสิ่งรบกวนน้อย ผลลัพธ์ก็ยิ่งดี
วิธีทำให้เอเจนต์ “จำ” อะไรได้ คือให้มันจัดทำเอกสารงานเหมือนเวลานักพัฒนามนุษย์ทำโปรเจกต์ให้เป็นมิตรกับนักพัฒนาคนอื่น การเก็บเอกสารพัฒนาที่ดีพร้อมหน้าดัชนี และแผนงานที่ดีพร้อมเช็กลิสต์ ไว้เป็นไฟล์ Markdown แบบกระชับแล้ว commit เข้า repository คือหน่วยความจำในอุดมคติสำหรับโมเดล และเป็นเอกสารในอุดมคติที่ใช้ดูว่าโมเดลทำอะไรไปบ้าง มันยังช่วยเวลาคนหรือโมเดลอื่นมา code review ด้วย และแทบไม่มีข้อเสียเลย
สุดท้าย “จำไว้ว่าต้องเช็ก memory!” ก็เลยถูกบันทึกกลับลง memory อีกที ชัดเจนว่าไม่ใช่ระบบที่ทำงานดีนัก
ความเห็นที่นี่แทบทั้งหมดอ้างอิงจาก ประสบการณ์ส่วนตัว กันเกือบหมด ตรงกันข้ามกับบทความต้นทางที่อ้างอิงงานวิจัยสองชิ้นซึ่งเปรียบเทียบประสิทธิภาพจากการทดสอบแบบมาตรฐานของหลายโมเดล
จะบอกไม่ได้ว่าชุดทดสอบเหล่านั้นดีแค่ไหน แต่ก็คงไม่แย่ไปกว่าหลักฐานเชิงเกร็ดเล็กเกร็ดน้อยสำหรับสิ่งที่กำกวมและเป็นอัตวิสัยอย่างประสิทธิภาพของ LLM
ในผลของ Chroma เห็นมี Sonnet 4 ซึ่งจากประสบการณ์ของฉัน Sonnet 4 ก็แย่มากเหมือนกัน พรอมป์ต์เดียวกันที่ทำงานได้สมบูรณ์บน Sonnet 4.5 กลับล้มเหลวแบบเละเทะบน Sonnet 4
ฉันอยากเห็นการทดสอบใหม่ที่รวมทั้งโมเดลระดับท็อปล่าสุดและโมเดล open weights เพราะดูเหมือนว่าโมเดลระดับท็อปจะทำตามคำสั่งได้ดีกว่าและหลุดประเด็นน้อยกว่าเสมอ ถ้ามีข้อมูลมาสนับสนุนก็คงดี
ฉันได้ผลค่อนข้างดีจากการให้มันทำตัวเหมือน ผู้จัดการผลิตภัณฑ์ ของ AI และย้ำหนัก ๆ ให้เขียน PRD สั้น ๆ สำหรับทุกฟีเจอร์ที่จะสร้าง
แบบนี้พอเวลาผ่านไปก็ยังย้อนมาดูได้ว่าสร้างอะไรไปแล้วบ้าง และแต่ละฟีเจอร์ก็หลงทางน้อยลง ฉันแยกบทสนทนาไว้คนละอันสำหรับแต่ละฟีเจอร์
สำหรับฉันมันเป็นจุดประนีประนอมที่ดีพอ คือกันไม่ให้ออกนอกลู่นอกทาง แต่ก็ยังอ้างอิงการตัดสินใจก่อนหน้าได้เมื่อจำเป็น สิ่งที่ฉันไม่ชอบในวิธีของ Pocock คือเขาเขียน PRD น้อยกว่าและไปจัดแนวความเข้าใจกันด้วยการคุยเชิงลึกก่อน ซึ่งมันเปลืองช่วงเวลาที่ดีที่สุดไปกับการโต้ตอบช่วงต้นมากเกินไป
ฉันเองก็ชอบวางแผนก่อนเหมือนกัน แต่พอมันค้างอยู่เป็นรายการสิ่งที่ต้องทำในเซสชัน ก็อ้างอิงทีหลังได้ยาก
การคอยไล่ดูว่าเกิดอะไรขึ้นภายในเอเจนต์ คงจะไม่เป็นส่วนหนึ่งของงานพัฒนาซอฟต์แวร์ไปอีกนานนัก
ส่วนตัวฉันมอง LLM และเอเจนต์เป็น กล่องดำ ไปแล้ว ฉันโยนคำขอฟีเจอร์เดียวกันให้หลาย LLM แล้วเปรียบเทียบผลลัพธ์ ฉันไม่เขียน “เซสชัน” แบบแมนนวล ฉันดูแค่ผลลัพธ์ ถ้าไม่ชอบก็
git reset --hardแล้วเปลี่ยนพรอมป์ต์ก่อนเริ่มคำขอฟีเจอร์ใหม่ฉันเก็บล็อกไว้เพื่อรักษาความรู้สึกว่าตอนนี้เอเจนต์ตัวไหนทำได้ดีที่สุดอย่างต่อเนื่อง และคำนวณคะแนน ELO ของเอเจนต์ที่ตอบโจทย์ความต้องการของฉันได้ดีที่สุด สำหรับฉัน สิ่งสำคัญคือคะแนนนั้น ไม่ใช่ว่าเอเจนต์บรรลุผลนั้นมาได้อย่างไร
เดาว่าสำหรับงานฝั่งฟรอนต์เอนด์ที่ไม่ต้องมีความปลอดภัยหรือการตรวจสอบมากนัก มันอาจใช้ได้ดี
แต่สำหรับอุตสาหกรรมที่มีการกำกับดูแล หรือการงานที่ต้องระมัดระวังอย่างยิ่ง มันดูไม่เหมาะ
ใช่แล้ว การจัดการคอนเท็กซ์ต์ คือหัวใจสำคัญ
ฉันสร้างเฟรมเวิร์กของตัวเองและใช้เวลาไปมากกับการดีบักปัญหานี้ โดยปัญหาใหญ่กว่าขนาดคอนเท็กซ์ต์ล้วน ๆ คือโอกาสที่ในหน้าต่างจะมีขยะหรือคำชี้นำผิดทิศทางปะปนอยู่ จนไปกลบข้อมูลที่ผู้ใช้คิดว่าสำคัญ
มันแสดงออกมาเป็นการที่ LLM พยายามทำสิ่งที่ล้มเหลวไปแล้วในแนวทางเมื่อกี้ซ้ำอีก ถ้าอะไรบางอย่างโผล่บ่อยในหน้าต่างคอนเท็กซ์ต์ มันก็จะมีน้ำหนัก แม้ว่าสิ่งนั้นจะผิดก็ตาม
ยังมีเทคนิคอีกเยอะ เช่น อย่าให้เครื่องมือกับ LLM เยอะเกินไป แต่ให้เครื่องมือสำหรับค้นหาเครื่องมือแทน
แต่คำตอบที่ใหญ่กว่านั้นอยู่ที่กระบวนการ ใช้อะไรอย่าง superpowers เพื่อบังคับให้ LLM ทำงานเป็นขั้นตอน และควบคุมคอนเท็กซ์ต์ที่จะพาไปข้างหน้า
ฉันทำส่วนขยายส่วนตัวเล็ก ๆ สำหรับ Pi เพื่อเพิ่มคำสั่ง
/lastมันจะล้างทั้งเซสชันและคงไว้แค่ข้อความผลลัพธ์ล่าสุดของเอเจนต์แบบนี้เลยทำ “การบีบอัด” ด้วยมือได้ โดยพื้นฐานคือฉันจะบอกเอเจนต์ว่า “สรุปแผนที่คุยกันไว้ พร้อมอ้างอิงไฟล์ที่ต้องแก้” แล้วเรียก
/lastจากนั้นค่อยสั่งให้ลงมือทำ[1] https://pi.dev/
ฉันไม่ชอบการเหมารวมเรียกทั้งหมดว่า “โมเดล” แบบนี้ แต่ละโมเดลมี สถาปัตยกรรม attention ต่างกัน และเพราะอย่างนั้นพฤติกรรมกับคอนเท็กซ์ต์ยาว ๆ ก็อาจต่างกันมาก
จริงอยู่ที่คอนเท็กซ์ต์ยาวเป็นปัญหา และในโมเดลส่วนใหญ่คุณภาพจะลดลง แต่ฉันจะไม่เหมารวมพฤติกรรมของโมเดลเก่าไปใช้กับโมเดลใหม่ตรง ๆ