Platform Skeleton (Mini Palantir) alcançado: início de Graph-RAG local + middleware cognitivo + colaboração externa no JAMES v0.3.0 (open source, alpha)

 (github.com/Hashevolution)
7 pontos por skanxhakr12 6 일 전 | 1 comentários | Compartilhar no WhatsApp

Resumo em uma linha

Um motor de conhecimento Graph-RAG 100% local que trata segurança como princípio de design.
Ao alcançar o v0.3.0 Platform Skeleton (2026-05-17), a camada de middleware cognitivo
não está mais só no design, mas já entrou na branch principal como código.

  • GitHub: https://github.com/Hashevolution/James-RAG-Evol
  • Versão atual: v0.3.0 (Foundation Hardening aprovado em 6/6 eixos, gate liberado em 2026-05-13)
  • Licença: MIT
  • Validação externa: badge passing do OpenSSF Best Practices (Tiered 111%, project #12806)
  • Apelido: "Mini Palantir" (Palantir é uma marca da Palantir Technologies, sem relação direta com JAMES — apenas uma analogia porque o padrão de typed-graph + preservação de trilhas de auditoria é parecido)

[IMG] Visualização de ontologia 3D do JAMES

v0.2 → v0.3: o que mudou em 9 dias

  1. A camada de middleware cognitivo Phase 2 se estabeleceu na branch principal
    • verification engine (PR #290) / planner·task decomposition (PR #297) / tool router (PR #295)
    • verificação, planejamento e roteamento de ferramentas deixaram de ser apenas design docs e viraram módulos importáveis
  2. Knowledge Cascade Phase A → E: migração para produção concluída com 213 entities / 656 relations
  3. Pipeline de segurança em 3 estágios mantido: entrada pre_check → busca ABAC → saída post_filter + máscara de PII
  4. Log de auditoria de autoevolução: todos os patches possuem approver_username, sem possibilidade de bypass
  5. Senha com bcrypt + migração transparente para SHA-256 (PR #173), baseline ruff F-class + workflow de lint no GitHub Actions (PR #205)

O que aconteceu fora do projeto (prova de que não foi feito sozinho)

  • Primeira colaboração externa em andamento com Ali Afana (fundador da Provia, dev.to Featured) — 6 trocas por DM no LinkedIn + thread de comentários no dev.to
    • Trabalho conjunto: separação da suíte de regressão de injeção com 83 itens, benchmark das variantes Gemma 4 no v0.3 (E4B / 26B MoE / 31B Dense)
    • Entrega conjunta: injection-fixtures schema v1.1 (PR #311 → #317 → #322, incorporando invariantes de normalização propostos por Ali, expected_block_stage e catalog_context, todos com origem registrada no diff-log)
    • Registro prévio: plano de avaliação 3×3 (3 variantes × 3 temperaturas × 1 estrutura de prompt, 4 hipóteses + decision matrix, travado no PR #315 antes de qualquer célula rodar)
    • Ponto de contato para implementadores externos: contrato de LLM Provider (PR #316, 6 comportamentos obrigatórios + kwargs/env vars reservados, incluindo um rascunho de backend da Gemini API com ~30 linhas)
  • Segundo candidato a colaboração — Matija Fućek (@mfucek_, naumu.ai) respondeu ao tuíte da visualização 3D compartilhando o demo do próprio projeto (um app plug-and-play de cérebro corporativo), abrindo um canal de colaboração
  • Envio concluído para 2 trilhas do Gemma 4 Challenge:

Limitações honestas (fase alpha, nada a esconder)

  • O middleware cognitivo Phase 2 entrou na branch principal, mas a validação com múltiplos usuários e alta carga ficou para o gate do v0.4
  • Multimodal já está integrado até LLaVA, Whisper e ffmpeg (working prototype). A integração com retrieval fica entre v0.3.x e v0.4
  • O scaffold de autoevolução foi validado em ambiente de usuário único; workflow com múltiplos aprovadores ainda não foi validado
  • O Gemma 4 E4B gerou 5 respostas vazias na etapa cognitiva, e nenhuma das 4 hipóteses conseguiu confirmar a root cause (isso está publicado exatamente assim no texto da trilha Write)

Onde isso pode ser usado

  • Quando você quer lidar com wiki/notas internas apenas localmente, sem enviar para APIs externas
  • Em demos/pesquisas de RAG onde o caminho de raciocínio (um typed graph_path no formato A --[CAUSES]--> X --[REQUIRES]--> Y) precisa ser exposto como grafo junto com a resposta
  • Como referência de padrões de segurança em RAG (pipeline em 3 estágios, instruction isolation, migração para bcrypt, baseline de ruff — tudo aberto em nível de PR)
  • Para quem precisa de ponto de entrada de plugin — o loader JAMES_PLUGINS e o Backend Protocol estão sendo estabilizados no v0.3.x

Como começar

git clone https://github.com/Hashevolution/James-RAG-Evol  
cp .env.example .env  
pip install -r requirements.txt  
ollama pull gemma2:2b      # Se não tiver GPU, comece por este  
python server_llmwiki.py   # http://localhost:8000

Leituras relacionadas

1 comentários

 
skanxhakr12 6 일 전

Olá. Perguntas são sempre bem-vindas —

Abaixo está uma comparação em nível de design de sistema.

A arquitetura atual do JAMES (v0.3.0) é a seguinte.

  1. Ausência de uma camada de formal query language — a busca híbrida em core/retrieval_engine.py usa fusão de pontuação em 4 vias de dense embedding + BM25 + keyword + name, e não converte consultas em NL para linguagens formais como SPARQL/RDF/SQL. As pontuações de embedding e BM25 são usadas diretamente na seleção dos nós candidatos.

  2. A resposta do LLM é em NL — em core/reasoning/modes/chat.py, o LLM recebe prompts em NL e gera respostas em texto NL, sem uma etapa intermediária em linguagem formal.

  3. A atualização do KG é separada por um gate de aprovação humana — declarado na primeira frase da docstring do 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." Ou seja, não existe no sistema um caminho para adicionar/modificar/remover automaticamente no KG com base na resposta do LLM. O wiki_edit também tem um gate de permissão de admin e força o fluxo propose → review → apply do change_request (veja também CLAUDE.md §3, ARCHITECTURE.md §5.6).

Por favor, considerem que o JAMES ainda está em estágio alpha e não comercial.

Além disso, se quiserem uma análise mais profunda, seria ótimo discutir isso juntos em uma GitHub Issue.

Acredito que feedbacks diversos são o que há de mais valioso para permitir uma verificação honesta das escolhas de design do projeto. Obrigado.