ROADMAP_LLM_COMPLETO.md

# Roadmap do modelo de LLM completo

**Status:** As sete pendências abaixo foram implementadas (config, KB, L5, unificação com agente, avaliação, chat, API).

---

# O que falta para um modelo de LLM completo (itens implementados)

Este documento lista o que já existe no projeto e o que ainda falta programar para se ter um **modelo de LLM completo** (inferência + geração de texto + RAG + avaliação + entrega).

---

## O que já existe

| Componente | Arquivo(s) | Estado |
|------------|------------|--------|
| Pipeline epistemológico L1→L4 | `pipeline.py`, `l1_concept_table.py`, `l2_kantian_judgments.py`, `syllogism_module.py`, `l3_paraconsistent.py`, `l4_synthesis.py` | ✅ Completo (raciocínio simbólico) |
| Regras paraconsistentes (Fuzzy.txt) | `paraconsistent_rules.py`, `train_truth_model.py` | ✅ L3 treinável por regras |
| Base teórica L4 (Russell) | `l4_russell_equivalence.py`, `train_l4_russell.py` | ✅ Síntese por equivalência |
| Modelo de verdade neural (μ, λ) | `neural_truth_model.py` | ✅ Opcional na L3 |
| LM customizado (TransformerEncoder) | `custom_lm_model.py`, `custom_tokenizer.py`, `pretrain_custom_lm.py` | ✅ Existe mas **não está ligado ao pipeline** |
| Agente de pesquisa (Groq + Chroma + DuckDuckGo) | `agente_busca_web.py` | ✅ Funcional, **separado** do pipeline L1–L4 |
| Banco de conhecimento | `SEED_KNOWLEDGE_BASE` em `pipeline.py` | ⚠️ Estático, dicionário fixo |
| Geração de “resposta” na L4 | `l4_synthesis._generate_response` | ⚠️ Só monta texto a partir da melhor hipótese (template), **não gera texto livre** |

---

## O que falta programar

### 1. **Geração de texto integrada ao pipeline (resposta livre)**

**Problema:** Hoje a L4 devolve um texto do tipo:  
`"Com alta confiança (v=0.85): [melhor proposição] [KB: ...]"` — é um template, não geração token a token.

**O que falta:**

- **Opção A (rápida):** Usar um LLM externo (Groq/OpenAI) na etapa 8:
  - Montar um **prompt estruturado** com: conceitos (L1), juízos filtrados (L2/SYL), valores μ/λ e estado (L3), síntese (L4) e a pergunta do usuário.
  - Chamar o LLM com esse prompt e usar a saída como **resposta final** do pipeline.
- **Opção B (end-to-end):** Integrar o `EpistemicLanguageModel` (ou um decoder pequeno) como gerador:
  - O contexto L1–L4 vira “condição” (ex.: embedding ou texto serializado).
  - O decoder gera a resposta autoregressivamente (`generate_text` já existe em `custom_lm_model.py`).
  - Exige definir formato de contexto (ex.: texto plano com juízos + valores) e treino/ajuste para esse cenário.

**Arquivos a criar/alterar:**  
Novo módulo, ex.: `l5_generation.py` (ou extensão em `l4_synthesis.py`) que recebe `SynthesisResult` + prompt e chama LLM ou `generate_text`; `pipeline.py` passa a usar essa camada na etapa 8.

---

### 2. **Unificar pipeline L1–L4 com o agente de pesquisa**

**Problema:** O pipeline híbrido e o `agente_busca_web.py` são independentes. O pipeline não usa RAG nem busca web.

**O que falta:**

- **Caminho 1:** O pipeline usar o agente como “fonte de fatos”:
  - Antes ou durante L3/L4, chamar o agente (busca local Chroma + DuckDuckGo) com a pergunta ou com as proposições filtradas.
  - Inserir os trechos recuperados no KB ou num contexto extra para a síntese/geração.
- **Caminho 2:** O agente usar o pipeline como “motor de raciocínio”:
  - Após a busca, passar os documentos + pergunta pelo pipeline L1–L4 e usar a `SynthesisResult` para montar o prompt final do LLM do agente.

**Arquivos a criar/alterar:**  
Um orquestrador (ex.: `pipeline_rag.py` ou opções em `pipeline.py`) que instancia tanto `HybridLLMPipeline` quanto o agente e define quando chamar cada um e como combinar saídas.

---

### 3. **Base de conhecimento escalável (KB + RAG)**

**Problema:** O KB é um dicionário fixo em código (`SEED_KNOWLEDGE_BASE`). Não há carregamento a partir de dados nem RAG dentro do pipeline.

**O que falta:**

- Carregar o KB a partir de arquivo(s) (JSON/CSV) ou de um banco.
- Opcional: popular uma base vetorial (ex.: Chroma em `meu_vector_db`) com os mesmos conceitos/evidências e, no pipeline, usar **retrieval** (como no agente) para enriquecer L3/L4 com trechos relevantes à pergunta.
- Manter a interface atual (termo → grau de evidência) para não quebrar L3/L4.

**Arquivos a criar/alterar:**  
Módulo `knowledge_base.py` (ou estender `pipeline.py`) para: carregar KB de disco; opcionalmente conectar a Chroma e expor uma função que, dada a pergunta, retorna um dicionário termo→peso ou trechos para contexto.

---

### 4. **Avaliação e métricas**

**Problema:** Não há como medir qualidade das respostas nem comparar versões do modelo.

**O que falta:**

- Dataset de avaliação: pares (pergunta, resposta_referência) ou (pergunta, valor_verdade_esperado).
- Script de avaliação que:
  - Roda o pipeline (e, se existir, o gerador) em cada pergunta.
  - Calcula métricas, por exemplo:
    - Coerência com L3 (ex.: valor de verdade médio, ausência de trivialização).
    - Se houver referência: similaridade semântica (embedding), BLEU/ROUGE, ou métricas de QA.
- Opcional: relatório (JSON/Markdown) com médias e exemplos.

**Arquivos a criar:**  
`eval_pipeline.py`, pasta `data/eval/` com conjuntos de teste e, se quiser, `metrics.py` com funções de métrica reutilizáveis.

---

### 5. **API ou serviço para uso em produção**

**Problema:** Só existe REPL (`python pipeline.py --repl`). Não há endpoint HTTP nem CLI estável para integração.

**O que falta:**

- **API REST (recomendado):** FastAPI (ou Flask) expondo, por exemplo:
  - `POST /process` — recebe `{"prompt": "..."}` e devolve a resposta do pipeline (e, no futuro, do gerador).
  - Opcional: `POST /agent` — repassa para o agente de pesquisa.
- **CLI:** `python -m pipeline --prompt "..."` (ou similar) que imprime só a resposta final, para uso em scripts.
- Configuração por variáveis de ambiente ou arquivo (YAML/JSON) para modelo, paths do KB, Chroma, etc.

**Arquivos a criar:**  
`api.py` (FastAPI) e/ou entrypoint em `pipeline.py` com `argparse`; opcional `config.yaml`.

---

### 6. **Histórico de diálogo (chat multi-turno)**

**Problema:** O pipeline processa um único prompt. Não há memória de conversa.

**O que falta:**

- Manter uma lista de (role, content) para o usuário e o assistente.
- Para cada nova mensagem: montar contexto (ex.: últimas N trocas ou resumo) e passar ao pipeline (e ao gerador, quando existir).
- Definir se L1–L4 usam só a última pergunta ou o contexto resumido (para não estourar tamanho e custo).

**Arquivos a criar/alterar:**  
Classe ou módulo `chat_session.py` (ou dentro do pipeline) que mantém histórico e chama `process`/gerador com contexto; REPL e API passam a usar essa sessão.

---

### 7. **Persistência e configuração**

**Problema:** Caminhos e opções estão espalhados (hardcoded ou env). Não há um “estado” do sistema salvo de forma única.

**O que falta:**

- Arquivo de configuração (YAML/JSON) para:
  - Caminho do KB, Chroma, modelo L3 (truth_scoring_model.pt), base Russell (l4_russell_concepts.json).
  - Flags: usar agente ou não, usar gerador externo ou LM interno, etc.
- Carregar essa config no arranque do pipeline e da API.
- Documentar onde ficam os artefatos treinados (L3, L4, LM customizado) e como recarregá-los.

**Arquivos a criar/alterar:**  
`config.yaml` (ou `.json`) e função `load_config()` usada em `pipeline.py` e `api.py`.

---

## Priorização sugerida

| Ordem | Item | Impacto | Esforço |
|-------|------|--------|--------|
| 1 | Geração de texto integrada (LLM externo no pipeline) | Alto — resposta natural em vez de template | Médio |
| 2 | Base de conhecimento escalável (carregar KB + opcional RAG) | Alto — dados reais | Médio |
| 3 | Unificar pipeline com agente (RAG no fluxo L1–L4) | Alto — um único sistema | Alto |
| 4 | API REST (FastAPI) | Médio — uso em produção | Baixo |
| 5 | Avaliação (dataset + script + métricas) | Médio — evolução guiada | Médio |
| 6 | Histórico de diálogo | Médio — experiência de chat | Médio |
| 7 | Configuração centralizada e persistência | Baixo — organização | Baixo |

---

## Resumo em uma frase

Hoje você tem um **motor de raciocínio epistemológico (L1–L4)** e um **agente de pesquisa** separado; para um **modelo de LLM completo** falta: **integrar um gerador de texto (LLM externo ou LM interno) ao pipeline**, **conectar o pipeline ao agente e ao KB/RAG**, **avaliar respostas** e **expor tudo via API e configuração clara**.