Show GN: Platform Skeleton(Mini Palantir) 도달: 로컬 Graph-RAG + 인지 미들웨어 + 외부 협업 시작 JAMES v0.3.0(오픈소스, alpha)

(github.com/Hashevolution)

7P by skanxhakr12 23시간전 | ★ favorite | 댓글 1개

한 줄 요약

보안을 디자인 원칙으로 다룬 100% 로컬 Graph-RAG 지식 엔진.
v0.3.0 Platform Skeleton(2026-05-17) 에 도달하면서, 인지 미들웨어 레이어가
설계가 아니라 코드로 메인에 올라온 상태입니다.

GitHub: https://github.com/Hashevolution/James-RAG-Evol
현재 버전: v0.3.0 (Foundation Hardening 6/6 axes 통과, 2026-05-13 게이트 클리어)
라이선스: MIT
외부 검증: OpenSSF Best Practices passing 뱃지 (Tiered 111%, project #12806)
별칭: "Mini Palantir" (Palantir는 Palantir Technologies의 상표, JAMES와 직접 관련 없음 — 단지 typed-graph + audit 흔적 보존 패턴이 닮았다는 비유)

[IMG] JAMES 3D 온톨로지 시각화

v0.2 → v0.3, 9일간 무엇이 바뀌었나

인지 미들웨어 레이어 Phase 2가 메인에 안착
- verification engine (PR #290) / planner·task decomposition (PR #297) / tool router (PR #295)
- 검증·계획·도구 라우팅이 더 이상 design doc이 아니라 import 가능한 모듈
Knowledge Cascade Phase A → E: 213 entities / 656 relations 프로덕션 마이그레이션 완료
3-stage 보안 파이프라인 유지: 입력 pre_check → 검색 ABAC → 출력 post_filter + PII mask
자가진화 감사 로그: 모든 패치는 approver_username 보유, 우회 불가
bcrypt 비밀번호 + SHA-256 투명 마이그레이션(PR #173), ruff F-class baseline + GitHub Actions 린트 워크플로(PR #205)

외부에서 일어난 일 (혼자 만든 게 아니라는 증거)

Ali Afana (Provia 창업자, dev.to Featured)와 첫 외부 협업 진행 중 — LinkedIn DM 6턴 + dev.to 댓글 스레드
- 공동 작업: 83-item injection regression 스위트 분리, v0.3 Gemma 4 변종 벤치(E4B / 26B MoE / 31B Dense)
- 공동 산출물: injection-fixtures schema v1.1 (PR #311 → #317 → #322, Ali 제안 normalization 불변식·expected_block_stage·catalog_context 모두 반영, diff-log에 출처 명시)
- 사전 등록: 3×3 평가 계획 (3 변종 × 3 온도 × 1 프롬프트 구조, 4 가설 + decision matrix, 단일 셀이 돌기 전에 PR #315로 잠금)
- 외부 구현자 접점: LLM Provider contract (PR #316, 6 required behaviors + reserved kwargs/env vars, ~30줄 Gemini API 백엔드 스케치 포함)
두 번째 협업 후보 — Matija Fućek(@mfucek_, naumu.ai)이 3D 시각화 트윗에 답글로 자기 프로젝트(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 단계, 숨길 게 없음)

인지 미들웨어 Phase 2는 메인에 올라왔지만 다중 사용자·대규모 부하 검증은 v0.4 게이트
멀티모달은 LLaVA·Whisper·ffmpeg까지 와이어드(working prototype). retrieval 통합은 v0.3.x ~ v0.4
자가진화 스캐폴드는 단일 사용자 환경 검증, 다중 승인자 워크플로 미검증
Gemma 4 E4B는 인지 단계에서 5번의 빈 응답을 냈고, 4개 가설 모두 root cause를 확정하지 못한 상태(Write 트랙 글에 그대로 공개)

어디에 쓸 수 있나

사내 위키/노트를 외부 API에 보내지 않고 로컬에서만 다루고 싶을 때
추론 경로(A --[CAUSES]--> X --[REQUIRES]--> Y 형태의 typed graph_path)가 응답과 함께 그래프로 노출되어야 하는 RAG 데모/연구
보안 RAG 패턴 레퍼런스 (3-stage 파이프라인, instruction isolation, bcrypt 마이그레이션, 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 19시간전 [-]

안녕하세요. 질문 언제든지 환영입니다 —

아래는 시스템 디자인 수준의 비교입니다

JAMES (v0.3.0) 의 현재 아키텍처는 다음과 같습니다.

Formal query language 계층 부재 — core/retrieval_engine.py 의 하이브리드 검색은 dense embedding + BM25 + keyword + name 의 4-way score fusion 으로, NL 질의를 SPARQL/RDF/SQL 같은 형식 언어로 변환하지 않습니다. 임베딩과 BM25 점수가 그대로 후보 노드 선택에 사용됩니다.
LLM 응답이 NL — core/reasoning/modes/chat.py 에서 LLM은 NL 프롬프트를 받아 NL 텍스트로 답변을 생성하며, formal-language intermediate 단계가 없습니다.
KG 업데이트가 인간 승인 게이트로 분리 — core/change_request.py 의 모듈 docstring 첫 문장에 명시: "Every write inside JAMES becomes a proposal in this module first; only a separate reviewer's approval turns the proposal into a real write." 즉 LLM의 응답에 근거하여 자동으로 KG에 add/modify/remove 하는 경로 자체가 시스템에 없습니다. wiki_edit 도 admin 권한 게이트가 있고, change_request 의 propose → review → apply 흐름을 강제합니다 (관련 CLAUDE.md §3, ARCHITECTURE.md §5.6 참조).

JAMES가 비상업 alpha 단계인 점 고려해주시고,

추가로 더 깊은 분석을 원하시면 GitHub Issue에서 같이 봐주시면 좋겠습니다.

다양한 피드백은 프로젝트의 디자인 선택을 정직하게 점검할 수 있게 해주는 가장 가치 있는 것이라고 생각합니다. 감사합니다.

답변달기