Matryoshka: โปรเจกต์ TypeScript ค้นหาไฟล์ใหญ่ไร้ LLM Key
ทดสอบเครื่องมือ Matryoshka MCP Server ของ Dmitri Sotnikov ด้วยวรรณกรรม War and Peace และล็อก 10,000 บรรทัด โดยไม่มี LLM API Key

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- Matryoshka เป็นโปรเจกต์ TypeScript โอเพนซอร์สโดย Dmitri Sotnikov สำหรับจัดการเอกสารขนาดใหญ่
- ทำงานผ่าน MCP Server โดยให้เอเจนต์ใช้ภาษาสืบค้นภาษา S-expression แทนการอ่านไฟล์ทั้งหมด
- บทความทดสอบการใช้งานจริงกับนวนิยาย War and Peace และไฟล์ล็อก 10,000 บรรทัดโดยไร้ LLM Key
- ผลทดสอบระบุว่าการค้นหาใช้เวลาตั้งแต่ 1 ถึง 430 มิลลิวินาที พร้อมประหยัดโทเค็นได้มากกว่าร้อยละ 97
เมื่อเอเจนต์เขียนโค้ดต้องดึงข้อมูลจากไฟล์ที่มีขนาดใหญ่เกินกว่า context window ปกติมักจะต้องเลือกวิธีแบ่งอ่านทีละส่วนหรือพึ่งพา RAG index ซึ่งทั้งสองวิธีมักสูญเสียข้อมูลระหว่างรอยต่อของส่วนต่างๆ Matryoshka จึงเลือกแนวทางที่สามในการแก้ปัญหานี้
โปรเจกต์นี้พัฒนาด้วย TypeScript โดย Dmitri Sotnikov ผู้สร้างเฟรมเวิร์ก Luminus Clojure โดยแนวคิดอ้างอิงมาจากงานวิจัย Recursive Language Models ของ Alex L. Zhang, Tim Kraska และ Omar Khattab จาก MIT CSAIL ซึ่ง Matryoshka เป็นการพัฒนาอิสระตามแนวทางดังกล่าว

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
จากการตรวจสอบเมื่อวันที่ 4 ตุลาคม 2569 รีโพสิเจอรีนี้มีดาว 149 ครั้ง ฟอร์ก 20 ครั้ง และไม่มีปัญหาค้างคา ใช้ไลเซนส์ Apache-2.0 โดยการปล่อยเวอร์ชันล่าสุดคือนพเอ็ม matryoshka-rlm 0.2.40 เมื่อวันที่ 17 พฤษภาคม 2569 ผู้ทดสอบจึงนำมาทดลองใช้งานกับไฟล์จริงภายใต้ข้อจำกัดที่ไม่มี LLM API Key และไม่มี Ollama ในเครื่อง
ระบบใช้ภาษา S-expression ขนาดเล็กที่เรียกว่า Nucleus แทนการเขียน JavaScript หรือ Python โดยคำสั่งเช่น (grep "ERROR") หรือ (count RESULTS) จะถูกประมวลผลผ่าน Lattice engine และเก็บผลลัพธ์ไว้ในหน่วยความจำ SQLite พร้อมส่งคืนสตับสั้นๆ ให้ไคลเอนต์ ดึงข้อมูลบรรทัดจริงเฉพาะเมื่อจำเป็นผ่านคำสั่ง lattice_expand
"The README claims this gives '97%+ token savings', and '80%+ token savings compared to reading files directly' for the MCP server."
Dmitri Sotnikov
ในการทดสอบบนสภาพแวดล้อม Linux x86_64 ที่มี 8 vCPUs และแรม 15 GB การติดตั้งแพ็กเกจใช้เวลา 2.5วินาที และใช้พื้นที่ 220 เมกะไบต์ในโฟลเดอร์ node_modules พร้อมกันนี้ยังพบข้อควรระวังสำคัญ เช่น การเรียกใช้ npx lattice-mcp โดยตรงอาจดาวน์โหลดแพ็กเกจอื่นที่ไม่เกี่ยวข้อง จึงควรใช้ไบนารีที่มาพร้อมกับแพ็กเกจหลักแทน
การใช้งานเครื่องมือในลักษณะที่ให้เอเจนต์สืบค้นผ่านภาษาเฉพาะบนเซิร์ฟเวอร์ โดยส่งกลับเพียงแฮนเดิลหรือตัวอย่างข้อมูลสั้นๆ ช่วยลดภาระการส่งข้อมูลข้อความขนาดยักษ์เข้าสู่โมเดล LLM ได้อย่างมหาศาล แนวทางนี้สะท้อนทิศทางการพัฒนาสถาปัตยกรรมเอเจนต์ที่เน้นประสิทธิภาพการจัดการหน่วยความจำและปริมาณโทเค็น ซึ่งมีความสำคัญอย่างยิ่งเมื่อต้องประมวลผลเอกสารขนาดใหญ่ระดับตำราหรือไฟล์บันทึกประวัติระบบยาวนับหมื่นบรรทัด
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น