Adiciona ROADMAP_AGENTICO.md: análise para v3.0.0 (sistema agêntico)
- Diagnóstico do padrão atual (PRC_26AI_TECH single-shot) vs. padrão de agentes/tasks/tools/teams de um case bancário de referência (DBMS_CLOUD_AI_AGENT, Property Graph, Blockchain Table, VPD, Knowledge Graph chain). - Mapeamento de analogia Persona/Agente/Task/Tools aplicado ao domínio de vulnerability management do AMPM. - Achado prático destacado: padrão fn_analise_carteira_json (separar cálculo determinístico de narrativa da IA) — não depende de agentes, pode entrar como v2.1.0. - Achado de acelerador: app pronto da Oracle 'Ask Oracle Select AI Chatbot' já expõe builder visual de agentes sobre o mesmo DBMS_CLOUD_AI_AGENT. - Sequenciamento: v3.0.0 depende do v2.0.0 estar em produção primeiro. Nenhuma mudança no trabalho em andamento do v2.0.0. - README.md e TASKS.md referenciam o novo doc. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
119
ROADMAP_AGENTICO.md
Normal file
119
ROADMAP_AGENTICO.md
Normal file
@@ -0,0 +1,119 @@
|
||||
# Roadmap — ampmInsights Agêntico (v3.0.0, ainda não iniciado)
|
||||
|
||||
Análise feita em 2026-09-09 a partir de um material de referência compartilhado pelo usuário (case
|
||||
bancário "DEMO_CONVERGENTE" — Oracle AI Database 26ai + APEX, com `DBMS_CLOUD_AI_AGENT`, Property
|
||||
Graph, Blockchain Table, VPD e Knowledge Graph chain) e de dois repositórios `oracle-devrel`. Este
|
||||
documento **não implementa nada** — é a base para decidir se/quando o AMPM evolui de um Q&A
|
||||
semântico de tiro único para um sistema agêntico. Não altera nem depende de nenhuma tarefa aberta
|
||||
do v2.0.0 (`TASKS.md`), exceto onde indicado explicitamente na seção 4.
|
||||
|
||||
## 1. Diagnóstico: onde o ampmInsights está hoje
|
||||
|
||||
`PRC_26AI_TECH` é **single-shot**: monta um JSON com a linha de `V_26AI_TECH` e manda para **um
|
||||
único prompt genérico**, que responde de uma vez os 4 blocos (análise, diagnóstico,
|
||||
recomendações, plano de ação). Não há divisão de trabalho — é um "analista generalista"
|
||||
respondendo tudo, sempre.
|
||||
|
||||
## 2. O padrão do case bancário (Agent Framework)
|
||||
|
||||
O case usa `DBMS_CLOUD_AI_AGENT` para construir uma hierarquia:
|
||||
|
||||
```
|
||||
TEAM (supervisor_agent = ROTEADOR)
|
||||
├─ AGENT "ANALISE_CENARIO_ECONOMICO" → TASK → TOOL (function)
|
||||
├─ AGENT "OBTER_DADOS_DE_CLIENTE" → TASK → TOOL (SQL profile)
|
||||
└─ AGENT "OBTER_PERFIL_INVESTIDOR" → TASK → TOOL (function)
|
||||
```
|
||||
|
||||
O agente roteador (`supervisor: true`) **classifica a pergunta e delega para um único
|
||||
especialista** — nunca responde ele mesmo, nunca deixa dois agentes tentarem a mesma pergunta.
|
||||
Cada especialista só vê o profile/tools do seu domínio (ex.: `OBTER_DADOS_DE_CLIENTE` não consegue
|
||||
interpretar perfil de risco, mesmo que o dado estivesse acessível).
|
||||
|
||||
## 3. Mapeamento de analogia para o AMPM
|
||||
|
||||
Do slide original (Persona → Agente/Competências → Task → Tools), aplicado ao domínio de gestão
|
||||
de vulnerabilidades:
|
||||
|
||||
| Slide (genérico) | Case bancário | AMPM (proposta) |
|
||||
|---|---|---|
|
||||
| Persona/Cargo | Gerente de Investimento | Gestor de Vulnerabilidades / CISO Ops |
|
||||
| Agente (competências) | Cenário econômico / Dados cliente / Perfil investidor | **Triagem CVE/Threat Intel**, **Contexto de Ativo (CMDB)**, **Remediação/Patch Plan**, **Relatório Executivo** |
|
||||
| Task | "responder pergunta sobre X" | "priorizar achado", "explicar exposição do ativo", "montar plano 30-60-90" |
|
||||
| Tools | `CONSULTAR_DADOS_CLIENTE`, `CONSULTAR_PERFIL_INVESTIDOR` | `CONSULTAR_CVE_CRITICO` (CVSS/EPSS/CISA KEV), `CONSULTAR_CONTEXTO_ATIVO` (CMDB: criticidade, responsável, SO), `CONSULTAR_HISTORICO_REMEDIACAO` |
|
||||
|
||||
Um roteador (`ROTEADOR_VULNERABILIDADES`, `supervisor: true`) classificaria a pergunta/achado e
|
||||
delegaria a **um** especialista — resolvendo o problema real de hoje, onde um único prompt tenta
|
||||
simultaneamente avaliar severidade técnica, contexto de negócio do ativo e plano de ação.
|
||||
|
||||
**Pré-requisito de dados:** os tools de triagem/CMDB só funcionam depois que as colunas Tier-1
|
||||
do v2.0.0 (`DEFINITION_CVE`, `DEFINITION_CVSS3_BASE_SCORE`, `DEFINITION_EPSS_SCORE`,
|
||||
`CISA_KEV_FLAG`, etc. — ver `sql/03_v2_ddl_schema_evolution.sql`) estiverem carregadas com dado
|
||||
real. **v3.0.0 depende do v2.0.0 estar em produção, não o contrário.**
|
||||
|
||||
## 4. O achado mais diretamente portável — não depende de agentes
|
||||
|
||||
`fn_analise_carteira_json` → `fn_analise_carteira_com_ia_json` é o padrão de maior valor prático
|
||||
do material, e é **ortogonal** à arquitetura de agentes:
|
||||
|
||||
1. Uma função PL/SQL determinística calcula em SQL puro (sem LLM) os números que importam —
|
||||
no case: concentração por emissor, por grau de risco, por prazo. No AMPM seria: % de achados na
|
||||
lista CISA KEV, distribuição por faixa de CVSS/EPSS, aging vs. SLA de correção, concentração por
|
||||
sistema/criticidade — usando exatamente os campos novos do v2.0.0.
|
||||
2. Uma segunda função monta um prompt que **só interpreta esse JSON já calculado** (não pede pro
|
||||
LLM "adivinhar" a matemática) e devolve uma narrativa.
|
||||
3. `JSON_MERGEPATCH` junta o JSON determinístico + a narrativa da IA num único documento.
|
||||
|
||||
Resultado: menos alucinação (números vêm de SQL, não do modelo), mais barato (prompt menor,
|
||||
menos tokens), e auditável (o JSON determinístico pode ser conferido independente do texto da
|
||||
IA). **Isso pode entrar como evolução do `PRC_26AI_TECH` já dentro do ciclo v2.0.0/v2.1.0**, uma
|
||||
vez que os campos novos estejam carregados — não precisa esperar o framework de agentes.
|
||||
|
||||
## 5. Outros padrões do material — aplicabilidade
|
||||
|
||||
| Padrão | O que faz no case | Aplicação no AMPM | Quando |
|
||||
|---|---|---|---|
|
||||
| **Property Graph** | `Cliente→Produto→Emissor→Agência`, perguntas tipo "produtos de baixo risco pro perfil do cliente X" | Resolve a decisão que ficou **em aberto** no gap-analysis do v2.0.0 (seção 5): normalizar CVE/pacote como grafo `Ativo→Pacote→CVE` para "quantos ativos têm a CVE-X" / "quais VMs rodam pacote Y desatualizado" — sem herdar custo de JOINs relacionais complexos | Candidato a v2.1.0/v3.0.0, não v2.0.0 (que decidiu manter texto/lista na linha) |
|
||||
| **Blockchain Table** | Saldo diário imutável e verificável (`SALDO_FECHAMENTO_BCT`) | Histórico de status de vulnerabilidade à prova de edição retroativa, se surgir exigência de auditoria formal | Não há gatilho identificado hoje — só mapeado |
|
||||
| **Knowledge Graph chain** (`kc_chain_api`) | Organiza documentos internos por assunto (`ANALISE→MACROECONOMIA→INFLACAO`) para RAG dirigido | Runbooks de remediação, políticas internas de segurança, playbooks por criticidade — hoje `TB_26AI_TECH_VECTOR` só vetoriza *insights já gerados* (memória), não conhecimento de referência. É uma lacuna real | v3.0.0 |
|
||||
| **VPD** (`vpd_filter_customers`) | Cada gerente só vê os clientes/contas sob sua responsabilidade | Analista só vendo ativos do seu grupo responsável — colunas `GRUPO_RESPONSÁVEL`/`ANALISTA_RESPONSAVEL` já existem no schema | Relevante só quando o app tiver múltiplos usuários com visões restritas |
|
||||
|
||||
## 6. Achado sobre acelerador pronto da Oracle
|
||||
|
||||
O app **"Ask Oracle Select AI Chatbot"** (`oracle-devrel/oracle-autonomous-database-samples`,
|
||||
`apex/Ask-Oracle-Select-AI-Chatbot/V 5.0.0.1`) já entrega um **construtor visual de
|
||||
agentes/times** + "Agent Team Map" rodando sobre o mesmo `DBMS_CLOUD_AI_AGENT` do case bancário,
|
||||
empacotado como app APEX instalável (export completo em
|
||||
`ADB-AskOracle-Chatbot-2026-08-06.sql`, requer APEX 24.2.17+). **Antes de programar um framework
|
||||
de agentes do zero para o AMPM, vale avaliar esse app como acelerador** — instalar, testar se o
|
||||
"Team Map" já serve de UI de administração dos agentes, e decidir se dá pra reaproveitar em vez
|
||||
de reconstruir à mão.
|
||||
|
||||
## 7. Sequenciamento proposto
|
||||
|
||||
```
|
||||
v2.0.0 (em andamento) v2.1.0 (proposto) v3.0.0 (proposto, este doc)
|
||||
DDL aditivo + view/proc → fn_analise_..._json/ia → Agentes (roteador + especialistas)
|
||||
carga real dos campos (item 4 — ponte, sem + Property Graph CVE/pacote
|
||||
Tenable/ServiceNow depender de agentes) + Knowledge Graph de runbooks
|
||||
+ avaliar app pronto (seção 6)
|
||||
```
|
||||
|
||||
## 8. Próximos passos (nenhum iniciado)
|
||||
|
||||
- [ ] Validar v2.0.0 ponta a ponta primeiro (pré-requisito de dados para tudo abaixo).
|
||||
- [ ] Desenhar `fn_analise_ampm_json` / `fn_analise_ampm_com_ia_json` (item 4) como próximo passo
|
||||
documentável do v2.0.0/v2.1.0.
|
||||
- [ ] Instalar e avaliar o "Ask Oracle Select AI Chatbot" (seção 6) num ambiente de teste, à parte
|
||||
do AMPM em si, só para decidir se é acelerador viável.
|
||||
- [ ] Só depois disso, desenhar o primeiro agente/task/tool real (provavelmente
|
||||
`CONSULTAR_CONTEXTO_ATIVO` sobre o CMDB, o mais parecido com `CONSULTAR_DADOS_CLIENTE` do
|
||||
case) como piloto, antes de construir o roteador completo.
|
||||
|
||||
## Fontes
|
||||
|
||||
- Material de referência: case bancário "DEMO_CONVERGENTE" (5 scripts SQL: cadastro/VPD/spatial,
|
||||
grafo de investimentos + função determinística+IA, agentes/tasks/tools/teams, knowledge graph
|
||||
chain de documentos, admin/ACL) — compartilhado pelo usuário em 2026-09-09, não versionado neste
|
||||
repositório (é material de outro projeto/cliente, não da AM/PM).
|
||||
- `https://github.com/oracle-devrel/oracle-autonomous-database-samples/tree/main/apex/Ask-Oracle-Select-AI-Chatbot/V%205.0.0.1`
|
||||
Reference in New Issue
Block a user