ผลการทดสอบประสิทธิภาพล่าสุดแสดงให้เห็นว่า การออกแบบหน่วยความจำแบบสองชั้น ซึ่งประกอบด้วย scratchpad บน RAM และคลังเก็บข้อมูล SQLite-vec ในเครื่อง สามารถทำเวลาในการคิวรีเฉลี่ย (median query time) ได้ต่ำกว่า 100 ms พร้อมทั้งช่วยประหยัดค่าใช้จ่าย 135 ดอลลาร์ต่อเดือนที่ต้องจ่ายให้กับบริการ cloud vector store ยอดนิยม นักพัฒนาที่สร้างเอเจนต์ AI อัตโนมัติสามารถรันระบบแบบ on-premise ได้ทั้งหมด ซึ่งจากการทดสอบพบว่าทำงานได้เร็วกว่าและไม่มีค่าใช้จ่ายรายเดือน
ทำไมแนวทางการจัดการหน่วยความจำในปัจจุบันจึงยังไม่ตอบโจทย์
เอเจนต์ AI มักจำเป็นต้องระลึกถึงการโต้ตอบ ข้อมูลจริง หรือผลลัพธ์จากการเรียกใช้เครื่องมือ (tool-call) นับพันรายการภายในช่วงเวลาตอบสนองที่จำกัด ทีมส่วนใหญ่มักจะส่ง embedding ทุกตัวเข้าไปยัง managed vector database และพึ่งพาการค้นหาเวกเตอร์ผ่านระบบทางไกล (remote vector search) ในทุกการเรียกดู แม้โมเดลนี้จะรองรับการขยายตัวได้ แต่ก็บังคับให้ทุกการคิวรีต้องผ่านเครือข่าย ซึ่งทำให้เวลาในการรับส่งข้อมูลไปกลับ (round-trip time) สูงขึ้นและเพิ่มค่าใช้จ่ายรายเดือน จากผลการทดสอบพบว่าค่าความหน่วงเฉลี่ย (median latency) ของบริการบน cloud อยู่ที่ 127 ms และมีค่าใช้จ่ายสูงถึง 135 ดอลลาร์ต่อเดือน นอกจากนี้ในช่วงเวลาที่ทดสอบยังพบปัญหาการหยุดทำงานของระบบ (outage) อีกด้วย
การแบ่งหน่วยความจำออกเป็นสองระดับ
สถาปัตยกรรมแบบสองระดับนี้จะแยก "หน่วยความจำระยะสั้น" (working memory) ออกจาก "หน่วยความจำระยะยาว" (long-term storage):
L1 Scratchpad (RAM)
- ทำงานบนหน่วยความจำของโปรเซส (process memory) ทั้งหมด
- เก็บข้อมูลบริบทของงานปัจจุบัน (task context) และการเรียกใช้เครื่องมือล่าสุด
- เก็บข้อมูลในรูปแบบข้อความดิบ (raw strings) โดยไม่มีการสร้าง embedding
- ส่งคืนผลลัพธ์ได้ในเวลาต่ำกว่า 3 ms ซึ่งเทียบเท่ากับ CPU cache
L2 Vault (SQLite-vec)
- เก็บ embedding อื่นๆ ทั้งหมดไว้ในฐานข้อมูล SQLite ในเครื่องที่ขยายความสามารถด้วยการค้นหาเวกเตอร์
- จัดการชุดข้อมูลความจำทั้งหมด 14,726 รายการที่ใช้ในการทดสอบ
- ส่งคืนข้อมูลที่ตรงกันได้ในเวลาประมาณ 94 ms ซึ่งต่ำกว่าเป้าหมาย 100 ms สำหรับเอเจนต์แบบ real-time ส่วนใหญ่ได้อย่างสบายๆ
- ไม่มีค่าใช้จ่ายใดๆ นอกเหนือจากค่าพื้นที่จัดเก็บข้อมูลของเครื่องโฮสต์
SQLite-vec เป็นส่วนขยายแบบ open-source ที่เพิ่มความสามารถในการค้นหาเพื่อนบ้านใกล้เคียงโดยประมาณ (approximate nearest-neighbor search) ให้กับไฟล์ฐานข้อมูลเชิงสัมพันธ์มาตรฐาน เนื่องจากฐานข้อมูลอยู่บนเครื่องเดียวกับเอเจนต์ จึงไม่มีความล่าช้าจากการข้ามเครือข่าย (network hop) และเอนจินยังใช้เทคนิคการทำดัชนี (indexing) ของ SQLite ที่มีอยู่เดิมเพื่อให้การเรียกดูข้อมูลทำได้อย่างรวดเร็ว
ตัวเลขที่สำคัญ
| ระบบ | ค่าความหน่วงเฉลี่ย (Median latency) | ค่าใช้จ่ายรายเดือน | ความน่าเชื่อถือที่รายงาน |
|---|---|---|---|
| Cloud vector store (Pinecone) | 127 ms | ~$135 | พบปัญหาการหยุดทำงาน (Outages) |
| Local SQLite-vec vault | 94 ms | $0 | uptime 100% |
ส่วนต่างของค่าใช้จ่ายคือ $0 เทียบกับประมาณ $135 ต่อเดือน
การรักษาความสะอาดของคลังข้อมูล (vault)
การเก็บ embedding ทั้งหมดแบบดิบๆ อาจทำให้ความแม่นยำลดลง ผู้เขียนผลการทดสอบจึงได้นำระบบการลดทอน (decay system) มาใช้เพื่อให้คะแนนความจำตามความใหม่ (recency) และความถี่ (frequency) ในการใช้งาน:
- รายการใหม่หรือรายการที่เข้าถึงบ่อยจะได้รับน้ำหนัก (weight) ที่สูงกว่า
- รายการที่ไม่ได้ถูกใช้งานมาสักพักจะค่อยๆ สูญเสียน้ำหนักไป
- การลดทอนแบบถ่วงน้ำหนักนี้ช่วยลด "สัญญาณรบกวนในการดึงข้อมูล" (retrieval noise) หรือข้อมูลที่ไม่เกี่ยวข้องลงได้ถึง 34%
ด้วยการลบข้อมูลที่มีคะแนนต่ำหรือลดลำดับความสำคัญในดัชนี เอเจนต์จะสามารถหลีกเลี่ยงข้อมูลที่ล้าสมัย ในขณะที่ยังรักษาคลังข้อมูลให้มีขนาดกะทัดรัดเพื่อให้ทำงานได้อย่างมีประสิทธิภาพสม่ำเสมอ
บทสรุป
สำหรับเอเจนต์ AI ที่ต้องจัดการกับความจำนับพันรายการภายใต้เงื่อนไขเวลาที่จำกัด การใช้ scratchpad ที่เน้น RAM เป็นหลักควบคู่กับคลังเก็บข้อมูล SQLite-vec ในเครื่อง เป็นทางเลือกที่ใช้งานได้จริงแทนการใช้ cloud-based vector stores แบบเต็มรูปแบบ แนวทางนี้ช่วยลดเวลาตอบสนอง กำจัดค่าธรรมเนียม cloud ที่เกิดขึ้นต่อเนื่อง และให้บริการได้อย่างไม่ขัดข้อง ในขณะที่ยังคงความสามารถในการลบข้อมูลที่ไม่เกี่ยวข้องออกได้ ดังนั้น การนำโมเดลแบบสองระดับนี้มาใช้จึงสามารถทำให้เอเจนต์ทำงานได้เร็วขึ้น ประหยัดขึ้น และมีความน่าเชื่อถือมากขึ้น
