# 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**.