บรรลุ Platform Skeleton (Mini Palantir): เริ่มต้น Local Graph-RAG + cognitive middleware + ความร่วมมือภายนอก JAMES v0.3.0 (โอเพนซอร์ส, alpha)

สรุปสั้นบรรทัดเดียว

เอนจินความรู้ Graph-RAG แบบโลคัล 100% ที่ยึดความปลอดภัยเป็นหลักการออกแบบ
เมื่อไปถึง v0.3.0 Platform Skeleton (2026-05-17) แล้ว เลเยอร์ cognitive middleware
ไม่ได้อยู่แค่ในแบบออกแบบอีกต่อไป แต่เป็น โค้ดที่ถูกรวมขึ้น main แล้ว

• GitHub: https://github.com/Hashevolution/James-RAG-Evol
• เวอร์ชันปัจจุบัน: v0.3.0 (ผ่าน Foundation Hardening ครบ 6/6 แกน, ผ่านเกตเมื่อ 2026-05-13)
• ไลเซนส์: MIT
• การตรวจสอบภายนอก: ตรา OpenSSF Best Practices passing (Tiered 111%, project #12806)
• ชื่อเรียกอีกแบบ: "Mini Palantir" (Palantir เป็นเครื่องหมายการค้าของ Palantir Technologies และไม่ได้เกี่ยวข้องโดยตรงกับ JAMES — เป็นเพียงอุปมาเพราะมีรูปแบบ typed-graph + การเก็บรักษาร่องรอยการ audit ที่คล้ายกัน)

[IMG] ภาพแสดง ontology แบบ 3D ของ JAMES

จาก v0.2 → v0.3 มีอะไรเปลี่ยนไปใน 9 วัน

1. เลเยอร์ cognitive middleware Phase 2 ปักหลักบน main แล้ว
   • verification engine (PR #290) / planner·task decomposition (PR #297) / tool router (PR #295)
   • การตรวจสอบ การวางแผน และการ route เครื่องมือ ไม่ใช่ design doc อีกต่อไป แต่เป็นโมดูลที่ import ได้
2. Knowledge Cascade Phase A → E: ย้ายขึ้น production ครบแล้วที่ 213 entities / 656 relations
3. คง pipeline ความปลอดภัยแบบ 3-stage: อินพุต pre_check → retrieval ABAC → เอาต์พุต post_filter + PII mask
4. audit log สำหรับการวิวัฒน์ตัวเอง: ทุกแพตช์มี approver_username และข้ามขั้นตอนไม่ได้
5. รหัสผ่าน bcrypt + การย้ายแบบโปร่งใสด้วย SHA-256 (PR #173), ruff F-class baseline + lint workflow บน GitHub Actions (PR #205)

สิ่งที่เกิดขึ้นจากภายนอก (หลักฐานว่าไม่ได้ทำอยู่คนเดียว)

• กำลังเริ่มความร่วมมือภายนอกครั้งแรกกับ Ali Afana (ผู้ก่อตั้ง Provia, dev.to Featured) — LinkedIn DM 6 รอบ + เธรดคอมเมนต์ใน dev.to
  • งานร่วมกัน: แยก regression suite สำหรับ injection จำนวน 83 รายการ, benchmark สายพันธุ์ Gemma 4 ของ v0.3 (E4B / 26B MoE / 31B Dense)
  • ผลลัพธ์ร่วมกัน: injection-fixtures schema v1.1 (PR #311 → #317 → #322, สะท้อน normalization invariant, expected_block_stage, catalog_context ตามข้อเสนอของ Ali ทั้งหมด พร้อมระบุที่มาใน diff-log)
  • ลงทะเบียนล่วงหน้า: แผนประเมินผล 3×3 (3 สายพันธุ์ × 3 อุณหภูมิ × 1 โครงสร้างพรอมป์ต์, 4 สมมติฐาน + decision matrix, ล็อกด้วย PR #315 ก่อนรันแม้แต่เซลล์เดียว)
  • จุดเชื่อมต่อสำหรับผู้พัฒนาภายนอก: LLM Provider contract (PR #316, 6 พฤติกรรมที่จำเป็น + reserved kwargs/env vars พร้อมสเก็ตช์ Gemini API backend ราว 30 บรรทัด)
• ผู้มีแนวโน้มร่วมงานรายที่สอง — Matija Fućek(@mfucek_, naumu.ai) ตอบโพสต์บน X เกี่ยวกับภาพ 3D visualization พร้อมแชร์เดโมโปรเจ็กต์ของตัวเอง (แอปสมององค์กรแบบ plug-and-play) เปิดช่องทางความร่วมมือแล้ว
• ส่งเข้า Gemma 4 Challenge ครบ 2 แทร็กแล้ว:
  • Build with Gemma 4: Building a Mini Palantir on gemma4:e4b
  • Write with Gemma 4: 5 empty responses from gemma4:e4b. 4 hypotheses. 0 root cause. — รูปแบบ fair-witness รายงานความล้มเหลวตามจริงโดยไม่ตกแต่ง

ข้อจำกัดแบบตรงไปตรงมา (อยู่ในขั้น alpha, ไม่มีอะไรต้องปิดบัง)

• cognitive middleware Phase 2 ขึ้น main แล้ว แต่ การตรวจสอบแบบหลายผู้ใช้และโหลดขนาดใหญ่เป็นเกตของ v0.4
• multimodal เชื่อมต่อถึง LLaVA·Whisper·ffmpeg แล้ว (working prototype) ส่วนการรวมเข้ากับ retrieval อยู่ในช่วง v0.3.x ~ v0.4
• scaffolding สำหรับการวิวัฒน์ตัวเองผ่านการตรวจสอบในสภาพแวดล้อมผู้ใช้เดี่ยวแล้ว แต่ยังไม่ผ่านการตรวจสอบ workflow แบบหลายผู้อนุมัติ
• Gemma 4 E4B ให้ผลตอบกลับว่าง 5 ครั้งในขั้นการรับรู้ และแม้มี 4 สมมติฐานก็ยังยืนยัน root cause ไม่ได้ (เปิดเผยไว้ตรง ๆ ในบทความแทร็ก Write)

ใช้กับอะไรได้บ้าง

• เมื่อต้องการจัดการวิกิ/โน้ตภายในองค์กรแบบโลคัลเท่านั้นโดยไม่ส่งออกไปยัง external API
• เดโม/งานวิจัย RAG ที่ต้อง แสดงเส้นทางการอนุมานออกมาเป็นกราฟพร้อมคำตอบ (typed graph_path ในรูปแบบ A --[CAUSES]--> X --[REQUIRES]--> Y)
• เอกสารอ้างอิงแพตเทิร์น Security RAG (pipeline แบบ 3-stage, instruction isolation, bcrypt migration, ruff baseline เปิดเผยเป็นหน่วย PR ทั้งหมด)
• สำหรับผู้ที่ต้องการจุดเริ่มต้นของ Plugin — ตัวโหลด JAMES_PLUGINS และ Backend Protocol กำลังถูกทำให้เสถียรใน v0.3.x

เริ่มต้นใช้งาน

git clone https://github.com/Hashevolution/James-RAG-Evol  
cp .env.example .env  
pip install -r requirements.txt  
ollama pull gemma2:2b      # ถ้าไม่มี GPU ให้เริ่มด้วยตัวนี้  
python server_llmwiki.py   # http://localhost:8000

[skanxhakr12]

สวัสดีครับ ยินดีรับคำถามเสมอ —

ด้านล่างนี้คือการเปรียบเทียบในระดับการออกแบบระบบ

สถาปัตยกรรมปัจจุบันของ JAMES (v0.3.0) มีดังนี้

1. ไม่มีชั้น formal query language — การค้นหาแบบไฮบริดใน core/retrieval_engine.py ใช้การผสานคะแนน 4 ทางของ dense embedding + BM25 + keyword + name และไม่ได้แปลงคำค้นแบบ NL ไปเป็นภาษารูปแบบอย่าง SPARQL/RDF/SQL คะแนนจาก embedding และ BM25 ถูกนำไปใช้ตรง ๆ ในการเลือก candidate node

2. คำตอบของ LLM เป็น NL — ใน core/reasoning/modes/chat.py LLM รับพรอมป์ต์แบบ NL และสร้างคำตอบเป็นข้อความ NL โดยไม่มีขั้นกลางที่เป็น formal-language

3. การอัปเดต KG ถูกแยกออกด้วยเกตการอนุมัติโดยมนุษย์ — ระบุไว้ชัดในประโยคแรกของ module docstring ของ core/change_request.py: "Every write inside JAMES becomes a proposal in this module first; only a separate reviewer's approval turns the proposal into a real write." กล่าวคือ ไม่มีเส้นทางในระบบที่ให้ add/modify/remove กับ KG โดยอัตโนมัติตาม คำตอบของ LLM ได้เลย wiki_edit ก็มีเกตสิทธิ์ admin และบังคับใช้โฟลว์ propose → review → apply ของ change_request (ดู CLAUDE.md §3, ARCHITECTURE.md §5.6 ที่เกี่ยวข้อง)

โปรดพิจารณาด้วยว่า JAMES ยังอยู่ในขั้น alpha ที่ไม่ใช่เชิงพาณิชย์

เพิ่มเติม หากต้องการการวิเคราะห์ที่ลึกกว่านี้ อยากชวนไปช่วยดูร่วมกันใน GitHub Issue ครับ

ผมคิดว่าฟีดแบ็กที่หลากหลายคือสิ่งที่มีคุณค่ามากที่สุด เพราะช่วยให้เราตรวจสอบทางเลือกด้านการออกแบบของโครงการได้อย่างตรงไปตรงมา ขอบคุณครับ