Llegó a Platform Skeleton (Mini Palantir): Graph-RAG local + middleware cognitivo + comienzo de colaboración externa, JAMES v0.3.0 (open source, alpha)

 (github.com/Hashevolution)
7 puntos por skanxhakr12 6 일 전 | 1 comentarios | Compartir por WhatsApp

Resumen en una línea

Un motor de conocimiento Graph-RAG 100% local que trata la seguridad como principio de diseño.
Al llegar a v0.3.0 Platform Skeleton (2026-05-17), la capa de middleware cognitivo
ya no está en diseño, sino subida a main como código.

  • GitHub: https://github.com/Hashevolution/James-RAG-Evol
  • Versión actual: v0.3.0 (Foundation Hardening superó 6/6 ejes, gate liberado el 2026-05-13)
  • Licencia: MIT
  • Verificación externa: insignia OpenSSF Best Practices passing (Tiered 111%, proyecto #12806)
  • Alias: "Mini Palantir" (Palantir es una marca de Palantir Technologies, sin relación directa con JAMES — solo es una metáfora porque se parece el patrón de typed-graph + preservación de trazas de auditoría)

[IMG] Visualización 3D de ontología de JAMES

v0.2 → v0.3, qué cambió en 9 días

  1. La capa de middleware cognitivo Phase 2 quedó asentada en main
    • verification engine (PR #290) / planner·task decomposition (PR #297) / tool router (PR #295)
    • La verificación, planificación y enrutamiento de herramientas ya no son design docs, sino módulos importables
  2. Knowledge Cascade Phase A → E: migración a producción completada con 213 entities / 656 relations
  3. Se mantiene el pipeline de seguridad de 3 etapas: entrada pre_check → búsqueda ABAC → salida post_filter + máscara de PII
  4. Log de auditoría de autoevolución: todos los parches incluyen approver_username, imposible de omitir
  5. Contraseñas con bcrypt + migración transparente a SHA-256 (PR #173), baseline F-class de ruff + workflow de lint en GitHub Actions (PR #205)

Lo que pasó afuera (prueba de que no fue hecho en solitario)

  • Ya está en marcha la primera colaboración externa con Ali Afana (fundador de Provia, destacado en dev.to) — 6 rondas por LinkedIn DM + hilo de comentarios en dev.to
    • Trabajo conjunto: separación de una suite de regresión de inyección de 83 ítems, benchmark de variantes Gemma 4 para v0.3 (E4B / 26B MoE / 31B Dense)
    • Entregable conjunto: injection-fixtures schema v1.1 (PR #311 → #317 → #322, incorporando por completo los invariantes de normalización, expected_block_stage y catalog_context propuestos por Ali, con la procedencia indicada en el diff-log)
    • Prerregistro: plan de evaluación 3×3 (3 variantes × 3 temperaturas × 1 estructura de prompt, 4 hipótesis + decision matrix, bloqueado con PR #315 antes de ejecutar una sola celda)
    • Punto de contacto para implementadores externos: contrato de proveedor LLM (PR #316, 6 comportamientos requeridos + kwargs/env vars reservadas, incluyendo un boceto de backend Gemini API de ~30 líneas)
  • Segundo posible colaborador — Matija Fućek(@mfucek_, naumu.ai) respondió al tuit de visualización 3D compartiendo una demo de su proyecto (app plug-and-play de cerebro corporativo), y se abrió un canal de colaboración
  • Envíos completados a 2 tracks del Gemma 4 Challenge:

Limitaciones honestas (etapa alpha, no hay nada que ocultar)

  • Phase 2 del middleware cognitivo ya está en main, pero la validación para múltiples usuarios y carga a gran escala queda como gate de v0.4
  • Lo multimodal ya está conectado hasta LLaVA·Whisper·ffmpeg (working prototype). La integración con retrieval va de v0.3.x a v0.4
  • El andamiaje de autoevolución fue validado en entorno de un solo usuario; el workflow con múltiples aprobadores no ha sido validado
  • Gemma 4 E4B produjo 5 respuestas vacías en la etapa cognitiva, y ninguna de las 4 hipótesis ha podido confirmar la root cause (tal como se publicó en el artículo del track Write)

Para qué se puede usar

  • Cuando quieres manejar una wiki/notas internas solo en local, sin enviarlas a APIs externas
  • Demos/investigación de RAG donde la ruta de razonamiento (un typed graph_path con forma A --[CAUSES]--> X --[REQUIRES]--> Y) debe exponerse como grafo junto con la respuesta
  • Referencia de patrones de Security RAG (pipeline de 3 etapas, instruction isolation, migración a bcrypt, baseline de ruff, todo publicado por PR)
  • Para quienes necesitan un punto de entrada de plugins — el loader JAMES_PLUGINS y el Backend Protocol están estabilizándose en v0.3.x

Primeros pasos

git clone https://github.com/Hashevolution/James-RAG-Evol  
cp .env.example .env  
pip install -r requirements.txt  
ollama pull gemma2:2b      # Si no tienes GPU, empieza con esto  
python server_llmwiki.py   # http://localhost:8000

Lecturas relacionadas

1 comentarios

 
skanxhakr12 6 일 전

Hola. Las preguntas siempre son bienvenidas.

A continuación, una comparación a nivel de diseño del sistema.

La arquitectura actual de JAMES (v0.3.0) es la siguiente.

  1. No existe una capa de lenguaje de consulta formal — la búsqueda híbrida de core/retrieval_engine.py utiliza una fusión de puntajes en 4 vías de dense embedding + BM25 + keyword + name, y no convierte las consultas en NL a un lenguaje formal como SPARQL/RDF/SQL. Los puntajes de embedding y BM25 se usan tal cual para seleccionar los nodos candidatos.

  2. La respuesta del LLM está en NL — en core/reasoning/modes/chat.py, el LLM recibe prompts en NL y genera respuestas como texto en NL, y no existe una etapa intermedia en lenguaje formal.

  3. La actualización del KG está separada mediante una compuerta de aprobación humana — se indica explícitamente en la primera oración del docstring del módulo 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." Es decir, no existe en el sistema una ruta que haga add/modify/remove en el KG automáticamente con base en la respuesta del LLM. wiki_edit también tiene una compuerta de permisos de admin y fuerza el flujo propose → review → apply de change_request (ver también CLAUDE.md §3, ARCHITECTURE.md §5.6).

Tomen en cuenta que JAMES está en una etapa alpha no comercial.

Además, si quieren un análisis más profundo, me gustaría que lo revisáramos juntos en GitHub Issue.

Creo que los distintos comentarios son lo más valioso, porque permiten revisar con honestidad las decisiones de diseño del proyecto. Gracias.