คำสำคัญ: การจัดการความจำ AI, กราฟความรู้, สถาปัตยกรรมเครื่องยนต์คู่, นิพจน์การสืบค้น JSON, การค้นหาเวกเตอร์

ด้วยการพัฒนาอย่างรวดเร็วของโมเดลภาษาขนาดใหญ่ (LLM) และเทคโนโลยี AI Agent การทำให้ AI มี “ความจำระยะยาว” คล้ายมนุษย์ได้กลายเป็นปัญหาสำคัญที่ต้องได้รับการแก้ไขอย่างเร่งด่วนในแวดวงเทคโนโลยี วิธีการใดที่จะสามารถทำความเข้าใจในระดับความหมายที่คลุมเครือ และในขณะเดียวกันก็สามารถจับคู่ตรรกะและข้อความได้อย่างแม่นยำ จากประวัติการโต้ตอบ เอกสาร และความรู้ทั่วไปจำนวนมหาศาล?

โครงการโอเพ่นซอร์ส Hypatia เป็นระบบจัดการความจำสำหรับ AI โดยจัดเก็บความรู้ที่มีโครงสร้างเป็นกราฟที่ประกอบด้วยรายการความรู้ (โหนด) และทรีเพิลคำสั่ง (ขอบ) และทำการสืบค้นผ่านภาษานิพจน์การค้นหา JSON ที่กำหนดเอง (JSE) ระบบหลักสร้างขึ้นบน SQLite FTS5 และ DuckDB รองรับโมเดลฝังตัวที่กำหนดค่าได้ (ONNX ในเครื่องหรือ API ระยะไกล) เพื่อให้สามารถค้นหาเวกเตอร์เชิงความหมายได้

บทความนี้จะวิเคราะห์หลักการทำงานของ Hypatia ปัญหาหลักที่มันแก้ไข และจุดนวัตกรรมสำคัญในการนำไปปฏิบัติทางวิศวกรรม

สารบัญบทความ

• 1. คู่มือเริ่มต้นแบบง่ายสุด: ให้ AI มีความจำได้ทันที
  • 1.1 การคอมไพล์และการกำหนดค่าโมเดลในเครื่อง
  • 1.2 การเขียนความรู้และการสร้างกราฟความรู้
  • 1.3 ประสบการณ์การสืบค้นหลายมิติ
• 2. ปัญหาหลัก: ทำไม AI ถึงต้องการระบบจัดการความจำเฉพาะตัว?
• 3. จุดนวัตกรรมหลักและแนวทางการแก้ไขของ Hypatia
  • 3.1 สถาปัตยกรรม “ความร่วมมือของฐานข้อมูลคู่” ที่คิดค้นขึ้นเอง
  • 3.2 ภาษาการสืบค้นที่ออกแบบสำหรับ AI: JSE (JSON Search Expression)
  • 3.3 การสนับสนุนโมเดลในเครื่องแบบฝังตัวที่พร้อมใช้งานทันที
• 4. การวิเคราะห์การนำไปปฏิบัติหลัก: ตั้งแต่สถาปัตยกรรมจนถึงรายละเอียดโค้ด
  • 4.1 การเขียนข้อมูลลงเครื่องยนต์คู่ของกราฟความรู้
  • 4.2 ต้นไม้คอมไพล์ AST ของนิพจน์การสืบค้น JSE
• 5. การวิเคราะห์ข้อมูลประสิทธิภาพและการทดสอบมาตรฐาน
  • 5.1 การเปรียบเทียบประสิทธิภาพของโมเดล Embedding และเครื่องยนต์การสืบค้นต่างๆ บนมาตรฐาน LoCoMo
  • 5.2 การวิเคราะห์เชิงลึกของข้อมูลหลักและความเชื่อมโยงกับการปรับปรุงประสิทธิภาพ
• บทสรุป

1. คู่มือเริ่มต้นแบบง่ายสุด: ให้ AI มีความจำได้ทันที

Hypatia เน้น “พร้อมใช้งานทันที” และการแยกตัวในเครื่อง เพียงไม่กี่คำสั่ง ก็สามารถกำหนดค่าสภาพแวดล้อม เขียนข้อมูล และทำการสืบค้นหลายมิติได้

1.1 การคอมไพล์และการกำหนดค่าโมเดลในเครื่อง

ไม่จำเป็นต้องติดตั้งเซิร์ฟเวอร์ฐานข้อมูลเพิ่มเติม เพียงคอมไพล์และวางโมเดล Embedding ขนาดเล็ก (ค่าเริ่มต้นคือ BGE-M3) ในเครื่อง ก็สามารถเปิดใช้งานเครื่องยนต์เวกเตอร์ได้:

bash

คอมไพล์และสร้างโปรเจกต์

cargo build –release

ดาวน์โหลดและกำหนดค่าโมเดลเวกเตอร์ในเครื่อง (ไปยังไดเรกทอรี Shelf เริ่มต้น)

mkdir -p ~/.hypatia/default
hf download BAAI/bge-m3 –local-dir /tmp/bge-m3
cp /tmp/bge-m3/onnx/model.onnx* /tmp/bge-m3/tokenizer.json ~/.hypatia/default/

1.2 การเขียนความรู้และการสร้างกราฟความรู้

เขียนโหนดเอนทิตีและทรีเพิลความสัมพันธ์ลงในเครื่องยนต์คู่ผ่าน CLI โดยตรง:

bash

สร้างโหนดความรู้ (ระบุชื่อ, รายละเอียดคำอธิบาย -d และแท็ก -t)

hypatia knowledge-create “Rust” -d “systems programming language” -t “language,compiled”

สร้างความสัมพันธ์ในกราฟ (สร้างทรีเพิล ประธาน-กริยา-กรรม)

hypatia statement-create “Rust” “is_a” “systems language”

1.3 ประสบการณ์การสืบค้นหลายมิติ

ไม่ว่าจะเป็นการจับคู่ข้อความที่แม่นยำ การค้นหาเชิงความหมายที่คลุมเครือ หรือการอนุมานตรรกะที่ซับซ้อน ก็สามารถทำได้ด้วยคำสั่งเดียว:

bash

1. การสืบค้นข้อความเต็มแบบเร็วสุด (ใช้ SQLite FTS5)

hypatia search “programming language”

2. การสืบค้นเวกเตอร์เชิงความหมาย (คำนวณความคล้ายโคไซน์ ครั้งแรกที่ใช้ต้องรัน hypatia backfill เพื่อเติมเวกเตอร์)

hypatia similar “coding tools”

3. การสืบค้นกราฟความรู้ที่มีโครงสร้างด้วย JSE (ล็อกคุณสมบัติได้แม่นยำ)

hypatia query ‘[“$knowledge”, [“$eq”, “name”, “Rust”]]’

2. ปัญหาหลัก: ทำไม AI ถึงต้องการระบบจัดการความจำเฉพาะตัว?

ก่อนที่ Hypatia จะปรากฏตัว วิธีการหลักในอุตสาหกรรมในการจัดการความจำของ AI คือการแบ่งส่วนประวัติการสนทนาหรือเอกสารอย่างง่าย แล้วแปลงเป็นเวกเตอร์มิติสูงผ่านโมเดล Embedding และเก็บไว้ในฐานข้อมูลเวกเตอร์ (เช่น ChromaDB, Pinecone)

อย่างไรก็ตาม เส้นทางที่ง่ายและรุนแรงนี้เผชิญกับความยากลำบากสามประการที่ยากจะก้าวข้าม:

2. ข้อจำกัดของโซลูชันแบบดั้งเดิมและการกำเนิดของ Hypatia

โซลูชันฐานข้อมูลเวกเตอร์หลักในปัจจุบันเผชิญกับความท้าทายหลักหลายประการเมื่อสร้างระบบความจำสำหรับ AI:

1. การขาดการรับรู้เชิงโครงสร้างและความสัมพันธ์
   ความจำของมนุษย์เป็นเครือข่ายความสัมพันธ์ที่มีโครงสร้างสูง (คือกราฟความรู้) ตัวอย่างเช่น คำสั่ง “Rust เป็นภาษาการเขียนโปรแกรมระดับระบบ” ประกอบด้วยเอนทิตี “Rust” และความสัมพันธ์ของคุณสมบัติของมัน ฐานข้อมูลเวกเตอร์ล้วนๆ ยากที่จะแสดงเครือข่ายกราฟเช่น “ประธาน-กริยา-กรรม” ได้อย่างมีประสิทธิภาพ เมื่อ AI ต้องการทำ “การอนุมานหลายขั้น” การค้นหาความคล้ายเวกเตอร์แบบดั้งเดิมมักจะเกิดการเลื่อนของความหมายหรือการสูญเสียข้อมูล

2. จุดอ่อนของการเรียกคืนข้อความเต็มที่แม่นยำ
   การสืบค้นเชิงความหมายที่ใช้ความคล้ายโคไซน์เก่งใน “การจับคู่ความตั้งใจ” แต่เมื่อเผชิญกับสถานการณ์ที่ต้องการ “การจับคู่ที่แม่นยำ” เช่น ชื่อเฉพาะ หมายเลข เศษโค้ดเฉพาะ มักจะทำงานได้ไม่ดี นักพัฒนามักต้องติดตั้งเครื่องมือค้นหาข้อความเต็มเพิ่มเติม เช่น Elasticsearch ซึ่งเพิ่มความซับซ้อนและต้นทุนการบำรุงรักษาของระบบอย่างมาก

3. โครงสร้างพื้นฐานที่หนักและปัญหาความเป็นส่วนตัว
   เพื่อให้บรรลุการสืบค้นความจำแบบหลายรูปแบบและมีประสิทธิภาพสูง นักพัฒนามักต้องพึ่งพา API บนคลาวด์หรือติดตั้งคลัสเตอร์ฐานข้อมูลขนาดใหญ่ ซึ่งขัดกับแนวโน้มวิวัฒนาการของ AI Agent ที่มุ่งไปสู่การทำงานบนอุปกรณ์ปลายทางและเน้นการแยกตัวเพื่อความเป็นส่วนตัว

ในบริบทเช่นนี้ Hypatia จึงถือกำเนิดขึ้น โดยมีเป้าหมายเพื่อแก้ไขปัญหาหลัก: ในสภาพแวดล้อมเครื่องเดียวในเครื่อง ด้วยการใช้ทรัพยากรที่ต่ำมาก จะจัดหาเครื่องยนต์ความจำขนาดเบาที่รวมการแสดงความสัมพันธ์กราฟ การสืบค้นข้อความเต็มที่แม่นยำ และการค้นหาเวกเตอร์เชิงความหมายให้กับ AI ได้อย่างไร?

3. จุดนวัตกรรมหลักและแนวทางการแก้ไขของ Hypatia

Hypatia มีประสิทธิภาพดีเยี่ยมในการจัดการความจำของ AI เนื่องจากนวัตกรรมสำคัญหลายประการในการออกแบบระดับพื้นฐาน:

3.1 สถาปัตยกรรม “ความร่วมมือของฐานข้อมูลคู่” ที่คิดค้นขึ้นเอง

Hypatia ไม่ได้สร้างล้อใหม่ตั้งแต่ต้น แต่รวมสองฐานข้อมูลแบบฝังตัวที่成熟แล้วเข้าด้วยกันอย่างชาญฉลาด: DuckDB และ SQLite FTS5

• DuckDB รับผิดชอบโครงสร้างและเวกเตอร์: DuckDB ด้วยประสิทธิภาพการวิเคราะห์ที่แข็งแกร่งและการสนับสนุน JSON แบบดั้งเดิม ถูกใช้เพื่อจัดเก็บเอนทิตี ความสัมพันธ์ และการแสดงเวกเตอร์ของพวกมัน ความสามารถในการคำนวณอาร์เรย์ของมันสามารถใช้ในการคำนวณระยะทางโคไซน์ที่มีประสิทธิภาพโดยตรง เพื่อให้เกิดการสืบค้นเวกเตอร์แบบเบา
• SQLite FTS5 รับผิดชอบการสืบค้นข้อความเต็ม: SQLite ร่วมกับส่วนขยาย FTS5 (มีตัวแยกคำ Porter และอัลกอริทึม BM25 ในตัว) ถูกใช้โดยเฉพาะเพื่อให้เกิดการจับคู่ข้อความเต็มและดัชนีคำพ้องความหมายที่เร็วสุด สถาปัตยกรรมการเขียนและอ่านคู่ที่ซิงโครไนซ์อัตโนมัตินี้ ทำให้ระบบไม่เพียงแต่รองรับการกรองที่ซับซ้อนในระดับ SQL (เช่นกรองตามเวลา แท็ก) แต่ยังสามารถเรียกคืนข้อความด้วยความล่าช้าในระดับมิลลิวินาที

3.2 ภาษาการสืบค้นที่ออกแบบสำหรับ AI: JSE

AI เมื่อสร้างการสืบค้น จะเก่งกว่าในการส่งออกรูปแบบ JSON ที่มีโครงสร้าง แทนที่จะเป็นสตริง SQL ที่มักเกิดข้อผิดพลาดทางไวยากรณ์ Hypatia จึงออกแบบภาษา JSE ขึ้น โดยแยกการสืบค้น SQL และ FTS ระดับพื้นฐานที่ซับซ้อนออกเป็นต้นไม้ไวยากรณ์ JSON

เครื่องยนต์สืบค้น JSE ในตัวระบบจะคอมไพล์นิพจน์ JSON ที่คล้ายกับ ["$and", ["$eq", "name", "Rust"], ["$contains", "tags", "systems"]] ไปเป็น SQL ที่มีพารามิเตอร์อย่างปลอดภัยโดยอัตโนมัติ และยังรองรับคำสั่งการสำรวจกราฟหลายขั้นเช่น $k-hop อีกด้วย

3.3 การสนับสนุนโมเดลในเครื่องแบบฝังตัวที่พร้อมใช้งานทันที

ต่างจากโซลูชันแบบดั้งเดิมที่พึ่งพา API บนคลาวด์ Hypatia ผ่านรันไทม์ ONNX รวมและรันโมเดล Embedding ขนาดเล็กในหน่วยความจำโดยตรง (รองรับ BAAI/bge-m3 ที่ดีเยี่ยมหลายภาษาโดยค่าเริ่มต้น) ซึ่งไม่เพียงแต่รับประกันความเป็นส่วนตัวแบบออฟไลน์ล้วน แต่ยังช่วยให้ผู้ใช้ไม่ต้องกังวลกับการติดตั้งบริการโมเดลเพิ่มเติม ทำให้เกิด “พร้อมใช้งานทันที” และการแยกสภาพแวดล้อมอย่างแท้จริง

4. การวิเคราะห์การนำไปปฏิบัติหลัก: ตั้งแต่สถาปัตยกรรมจนถึงรายละเอียดโค้ด

เพื่อให้เข้าใจการทำงานภายในของ Hypatia อย่างชัดเจน เราจะเจาะลึกรหัสหลักของมัน ศึกษารายละเอียดการนำ “เครื่องยนต์เขียนคู่” และ “การคอมไพล์ JSE” ไปปฏิบัติ

4.1 การเขียนข้อมูลลงเครื่องยนต์คู่ของกราฟความรู้

ในสถาปัตยกรรมของ Hypatia ไฟล์ src/service/knowledge.rs เป็นไฟล์บริการหลักที่จัดการโหนดความรู้ เมื่อระบบเก็บความจำหนึ่งรายการ ระบบต้องรับประกันความสอดคล้องของข้อมูลระหว่าง DuckDB และ SQLite FTS และสร้าง Embedding โดยอัตโนมัติในพื้นหลัง

ต่อไปนี้คือการแสดงรหัสเทียมตามตรรกะหลักของไฟล์นั้น:

rust
// รหัสเทียม: ตรรกะการสร้างโหนดความรู้ในชั้นบริการหลักของ Hypatia
pub fn create(&mut self, name: &str, content: Content) -> Result {
// ขั้นตอนที่ 1: แทรกข้อมูลโหนดทั้งหมด (รวมถึง payload JSON) ลงในเครื่องยนต์โครงสร้างหลัก DuckDB
self.shelf.duckdb.insert_knowledge(name, &content)?;

// ขั้นตอนที่ 2: สร้างโครงสร้างเอกสารแบบแบนราบที่จำเป็นสำหรับดัชนีข้อความเต็ม
let doc = Self::build_fts_doc(&content, name);
// ขั้นตอนที่ 3: เขียนลงในเครื่องยนต์ SQLite FTS5 สร้างดัชนีกลับ BM25 และรวมแท็กและคำพ้องความหมาย
self.shelf.sqlite.upsert_doc("knowledge", name, &doc)?;

// ขั้นตอนที่ 4: เรียกใช้โมเดล Embedding ที่ฝังตัว (เช่น BGE-M3 ของ ONNX)
// แยกข้อความหลักที่ต้องถูกแปลงเป็นเวกเตอร์และสร้าง Vector
if let Some(vector) = self.shelf.embedder.maybe_embed(&content.embedding_text(name))? {
    // ขั้นตอนที่ 5: เก็บเวกเตอร์มิติสูงในรูปแบบอาร์เรย์กลับไปที่ DuckDB เพื่อใช้ในการค้นหาเชิงความหมายในภายหลัง
    self.shelf.duckdb.upsert_knowledge_embedding(name, &vector)?;
}

// ขั้นตอนที่ 6: อ่านวัตถุสุดท้ายที่สร้างขึ้นใหม่จาก DuckDB (พร้อมประทับเวลาที่สร้างโดยฐานข้อมูล) และส่งคืน
let knowledge = self.shelf.duckdb.get_knowledge(name)?;
Ok(knowledge)

}

โค้ดนี้แฝงความชาญฉลาดทางวิศวกรรม: Hypatia ไม่ได้พยายามแก้ปัญหาทั้งหมดด้วยฐานข้อมูลเดียว
* DuckDB รับ Content ทั้งหมด ดั้งเดิม รักษาโครงสร้างโทโพโลยีที่สมบูรณ์ของข้อมูล
* SQLite FTS5 รับเฉพาะฟิลด์สำคัญที่ลดมิติและทำให้แบนราบผ่าน build_fts_doc เท่านั้น
กลไกธุรกรรมรับประกันความสอดคล้องสุดท้ายของฐานข้อมูลทั้งสอง สิ่งที่ชาญฉลาดยิ่งกว่าคือ การสร้าง Embedding ในเครื่องถูกดำเนินการเป็นแง่มุมหนึ่งของชั้นบริการอย่างเงียบๆ นักพัฒนาเมื่อใช้ CLI จะไม่รับรู้ถึงกระบวนการแปลงเป็นเวกเตอร์ระดับพื้นฐานเลย

4.2 ต้นไม้คอมไพล์ AST ของนิพจน์การสืบค้น JSE

สำหรับ AI Agent ที่ต้องการสืบค้น “เอนทิตีที่เป็นเพื่อนของเพื่อน

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง

☕ สนับสนุนค่ากาแฟทีมงาน

หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay

SCAN TO PAY WITH ANY BANK