โมเดลภาษาแบบเรียกซ้ำ (Recursive Language Models)

 (arxiv.org)
2 คะแนน โดย GN⁺ 2026-01-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการเสนอ กลยุทธ์การอนุมานแบบใหม่ RLM (Recursive Language Model) ที่ทำให้ โมเดลภาษาขนาดใหญ่ (LLM) สามารถประมวลผลพรอมป์ตอินพุตที่ยาวมากได้
  • RLM มองพรอมป์ตยาวเป็น ส่วนหนึ่งของสภาพแวดล้อมภายนอก และเปิดให้โมเดลสามารถ สำรวจ·แยกย่อย·เรียกซ้ำแบบโปรแกรมได้
  • วิธีนี้ ก้าวข้ามข้อจำกัดของ context window เดิม โดยรองรับอินพุตขนาดได้สูงสุดหลายสิบล้านโทเค็น และ ให้คุณภาพดีกว่า LLM แบบเดิมอย่างมาก
  • ผลการทดลองพบว่า RLM ที่อิง GPT-5 และ Qwen3-Coder ให้ประสิทธิภาพดีขึ้นระดับเลขสองหลักในงานข้อความยาวหลายประเภท ขณะที่ต้นทุนใกล้เคียงกันหรือต่ำกว่า
  • แนวทางนี้ถูกประเมินว่าเป็น วิธีทั่วไปที่สามารถขยายความสามารถด้านการอนุมานของ LLM ได้อย่างมาก โดยช่วยแก้ข้อจำกัดของการประมวลผลบริบทยาว

ภาพรวมของ RLM

  • Recursive Language Model (RLM) ถูกออกแบบให้ LLM ไม่ต้องป้อนอินพุตยาวเข้าโครงข่ายประสาทโดยตรง แต่ให้ ปฏิบัติต่อมันเป็นตัวแปรในสภาพแวดล้อมภายนอก แล้วโต้ตอบกับมัน
    • โหลดพรอมป์ตอินพุต P เป็นตัวแปรในสภาพแวดล้อม Python REPL และให้ LLM ใช้โค้ดเพื่อสำรวจ·แยกย่อย·เรียกซ้ำกับมัน
    • LLM รับรู้สถานะของสภาพแวดล้อม REPL (เช่น ความยาวของสตริง) สังเกตผลข้างเคียงจากการรันโค้ด และค่อย ๆ แก้ปัญหาไปทีละขั้น
  • โครงสร้างนี้แก้ปัญหาที่แนวทาง context compaction หรือ แนวทางแบบอิงการสรุป แบบเดิมสูญเสียรายละเอียด
  • RLM ถูกนำเสนอเป็นกระบวนทัศน์การอนุมานทั่วไปที่สามารถ ขยายได้ทั้งความยาวของอินพุตและเอาต์พุต

ข้อจำกัดของแนวทางเดิม

  • LLM แบบเดิมมีปัญหา context rot ที่ประสิทธิภาพลดลงอย่างรวดเร็วเมื่อรับอินพุตยาว เนื่องจาก ข้อจำกัดของ context window
  • เทคนิค context compaction จะสรุปซ้ำเมื่อเกินความยาวที่กำหนด แต่ ไม่เหมาะกับงานที่ต้องเข้าถึงข้อมูลรายละเอียดอย่างละเอียด
  • RLM จัดการพรอมป์ตในฐานะวัตถุภายนอก จึงสามารถ ขยายขนาดอินพุตให้เกินขีดจำกัดของโมเดลได้

การตั้งค่าการทดลอง

  • โมเดลที่ใช้ประเมิน: GPT-5 (OpenAI, 2025) และ Qwen3-Coder-480B-A35B (Team, 2025)
  • วิธีที่ใช้เปรียบเทียบ:
    • การเรียก LLM พื้นฐานโดยตรง
    • Summary agent
    • เอเจนต์ค้นหาแบบ CodeAct + BM25
    • RLM (รวมสภาพแวดล้อม REPL) และ RLM (REPL, ไม่มีการเรียกซ้ำ)
  • ในการทดลองกับ GPT-5 ใช้ GPT-5-mini สำหรับการเรียกซ้ำ และใช้ GPT-5 เป็นโมเดลราก เพื่อสร้างสมดุลระหว่างประสิทธิภาพกับต้นทุน

งานประเมิน

  • S-NIAH: ปัญหาแบบ ‘needle-in-a-haystack’ เดี่ยว มีต้นทุนการประมวลผลคงที่ไม่ขึ้นกับความยาวอินพุต
  • BrowseComp-Plus: งานถาม-ตอบแบบ multi-hop ที่ต้องข้ามหลายเอกสาร โดยมีคำตอบอยู่ในเอกสาร 1,000 ฉบับ
  • OOLONG: งานอนุมานข้อความยาว ที่ต้องแปลงและรวมความหมายของเกือบทุกรายการในอินพุต โดยต้นทุนประมวลผลแปรผันเชิงเส้นตามความยาวอินพุต
  • OOLONG-Pairs: รูปแบบย่อยของ OOLONG ที่ต้อง รวมข้อมูลเป็นคู่ ๆ และมีต้นทุนประมวลผล แปรผันตามกำลังสองของความยาวอินพุต
  • LongBench-v2 CodeQA: งานแบบหลายตัวเลือกที่ต้องเข้าใจคลังโค้ด ซึ่งเป็นปัญหาที่ยากแม้สำหรับโมเดลรุ่นใหม่

ผลลัพธ์สำคัญ

  • RLM แทบไม่มีประสิทธิภาพตกลงเมื่อเจอบริบทยาว เมื่อเทียบกับ GPT-5
    • GPT-5 มีประสิทธิภาพลดลงอย่างรวดเร็วเมื่อความยาวอินพุตและความซับซ้อนของงานเพิ่มขึ้น
    • RLM ประมวลผลอินพุตที่ เกินขีดจำกัด 272K โทเค็น (สูงสุดมากกว่า 10M โทเค็น) ได้อย่างมีประสิทธิภาพ
  • RLM ให้ประสิทธิภาพดีขึ้นระดับเลขสองหลักเหนือกว่าวิธีอื่นในทุกงานข้อความยาว
  • ยังรักษา ความคุ้มค่าด้านต้นทุน ได้ โดยมีต้นทุนต่อคำถามใกล้เคียงกับแนวทางเดิมหรือถูกกว่า

การวิเคราะห์ความซับซ้อนของงานข้อความยาว

  • context window ที่ใช้งานได้จริง ของ LLM อาจสั้นกว่าขีดจำกัดทางกายภาพ ขึ้นอยู่กับ ความซับซ้อนของงาน
    • ปัญหา NIAH แบบง่ายสามารถแก้ได้แม้ที่ 1M+ โทเค็น
    • งานตระกูล OOLONG ที่ซับซ้อนกว่ามีประสิทธิภาพลดลงแม้ที่ความยาวสั้นกว่านั้นมาก
  • ดังนั้นจึงต้องพิจารณาทั้ง ความหนาแน่นของข้อมูลของงาน และ ความสัมพันธ์กับความยาวอินพุต ไปพร้อมกัน

บทสรุป

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-01-05
ความคิดเห็นบน Hacker News

  • นี่ดูเหมือนแนวคิด subagent ธรรมดา ๆ
    กล่าวคือ เรียก LLM ตัวอื่นมาอ่านไฟล์และดึงข้อมูลที่ต้องการออกมา เพื่อไม่ให้ main context ซับซ้อนเกินไป
    ไอเดียใช้ได้ แต่ไม่ใช่เรื่องใหม่ทั้งหมด

    • ฉันมองมันเป็นวิธี จัดการคอนเท็กซ์ มากกว่าจะเป็น subagent แบบทำให้มีบุคลิกเหมือนมนุษย์
      ตอนนี้กำลังทดลองในโปรเจกต์ Scope ให้ subagent ที่สังเกตพฤติกรรมได้แยกงานออกแบบ recursive
      แต่ยังไม่รู้ว่าจะปรับปรุง การประเมินขั้นวางแผน นี้อย่างไร
      ตอนนี้บันทึก heuristic เป็นไฟล์ Markdown แต่โครงสร้างหลวมเกินไปจึงวัดผลได้ยาก
      ถ้าใครรู้จักงานวิจัยหรือโปรเจกต์ที่เกี่ยวข้องก็อยากให้ช่วยแนะนำ
    • ใน paper พูดไว้แบบนี้
      RLM ไม่ใช่ agent และไม่ใช่ summary
      การใช้การเรียก LM หลายครั้งภายในระบบเดียวไม่ใช่แนวคิดใหม่ และนี่คือสิ่งที่ agentic scaffold ส่วนใหญ่ทำอยู่แล้ว
      ตัวอย่างที่ใกล้เคียงที่สุดคือ ROMA agent ที่แยกปัญหาแล้วแก้ด้วย sub-agent หลายตัว
      รวมถึง code assistant อย่าง Cursor หรือ Claude Code ก็จะสรุปหรือ prune เมื่อคอนเท็กซ์ยาวขึ้น
      โดยทั่วไปแนวทางเหล่านี้มักแยกตามหน่วยงาน แต่ RLM เน้น การแยกระดับคอนเท็กซ์ และมองว่าการเลือกนั้นควรให้ LM ตัดสินใจเอง
    • ดูจากชื่อแล้วเหมือนการคำนวณทั้งหมดจะ differentiable และฝึกเป็นโมเดลเดียว แต่ของจริงดูเหมือนแค่เรียกโมเดลซ้ำ ๆ เท่านั้น
    • ถ้า subagent ไม่สามารถเรียก subagent ตัวอื่นต่อไปได้แบบไม่สิ้นสุด ก็คงเรียกว่า recursive ไม่ได้
    • ดูเหมือนกำลังพูดถึงแนวคิด sub-agent ที่เข้าถึงและจัดการคอนเท็กซ์เดียวกันได้ (เช่น file system หรือตัวแปรใน REPL)

  • แก่นสำคัญคือ ไม่ควรโยนพรอมป์ต์ยาว ๆ เข้า neural network (Transformer) โดยตรง แต่ควรมองมันเป็นส่วนหนึ่งของ สภาพแวดล้อมที่ LLM โต้ตอบเชิงสัญลักษณ์ได้
    แต่ก็สงสัยว่าโดยพื้นฐานแล้วมันต่างจาก RAG อย่างไร
    ดูจากรูป 4 ความต่างน่าจะอยู่ที่ LLM เป็นคนลงมือทำ retrieval mechanism เองแทนมนุษย์

    • เท่าที่ฉันเห็นมีสองความต่าง
      1️⃣ RAG ใกล้เคียงกับ workflow มากกว่า ส่วนอันนี้มีความเป็น agentic มากกว่า
      2️⃣ มันมี โครงสร้างแบบ recursive
      ใน workflow มนุษย์จะออกแบบ flow ทีละขั้น แต่ในแนวทางแบบ agentic เอเจนต์จะตัดสินใจเองว่าจะค้นหาอะไร เรียกกี่ครั้ง และจะตอบเมื่อไร
      ตัวอย่างเช่น Claude Code หรือ Codex ที่สำรวจ codebase ด้วยการอ่านไฟล์และรัน ripgrep
      ความพยายามแบบ recursive นี้เคยมีมาก่อนแล้ว (เช่น babyagi ราวปี 2023) แต่ตอนนั้นความสามารถของโมเดลยังไม่พอ จึงต้องมี glue code จำนวนมาก
      ตอนนี้โมเดลแข็งแรงพอแล้ว โครงสร้างแบบนี้จึงใช้งานได้จริง

  • เหมือนมุก “T̶u̶r̶t̶l̶e̶s̶ LLMs all the way down” ที่สื่อถึงโครงสร้างที่ LLM เรียก LLM ต่อไปเรื่อย ๆ ไม่รู้จบ

    • เหมือนเอา “attention is all you need” มาใช้ซ้ำแบบ recursive และสุดท้ายสิ่งที่เราควรไล่ตามคือ precision

  • มีเวอร์ชันที่อ่านง่ายกว่าของบทความนี้: โพสต์บล็อกของ alexzhang13

  • สิ่งที่หวังในปี 2026 คือ Anthropic หรือ OpenAI จะเปิดเผยให้ผู้สร้าง CLI plugin รู้ว่า “compaction ทำงานอย่างไร”
    เทคโนโลยีนี้อาจแทนที่ฟีเจอร์ที่ฝังมาใน Claude Code ได้ แต่ตอนนี้ยังไม่มีการเปิด hook หรือความสามารถที่เหมาะสมออกมา

    • ถ้า Codex เป็นโอเพนซอร์ส ก็อ่านเองได้ไม่ใช่หรือ?
      ฉันเคยดูซอร์สของ Gemini แล้ว พบว่าเมื่อ context window เต็ม มันใช้โครงสร้างพรอมป์ต์ง่าย ๆ ที่สรุปทั้งหมด

  • ดูคล้ายกับ paper นี้: arXiv:2510.14826