Update docs/ML - ACATS - Exposuper - Trilhas - GPT.txt

docs/ML - ACATS - Exposuper - Trilhas - GPT.txt

@@ -1,70 +1,21 @@
-Quem é Karla Capela ?
+Usuário: Me fale sobre a empresa OM30:
+Sistema: A OM30 é uma empresa de tecnologia especializada no desenvolvimento de sistemas para a gestão pública nas áreas da saúde, educação e gestão documental.
+Nós conhecemos os desafios enfrentados diariamente por gestores públicos. Por isso, as soluções que desenvolvemos proporcionam uma gestão mais eficiente, análise de dados em tempo real, otimização do capital humano e de recursos e muito mais!
 
-possui graduação em Direito pela Universidade Católica de Pernambuco (2002). Atualmente é sócia da Raimundo & Capela- CONSULTORIA JURÍDICA. Tem experiência na área de Direito, com ênfase em Direito do Trabalho e Processo do Trabalho, Direito Civil e Processo Civil, Direito do Consumidor mormente a regulamentação 9.656/98 (que regula o setor de planos de saúde). Ela é minha mãe e também diretora da startup KOY
+Usuário: Quais os valores da OM30?:
+Sistema: Trabalho em equipe em todo o tempo
+Cumprir com os compromissos sempre
+Excelência no que nos propomos a fazer
+Simplificamos as relações
+Cliente no centro da estratégia
+Respeito e valorização de todos
+Relações éticas e transparentes
+Integridade em tudo o que fazemos
+Investimos em tecnologia de ponta, revisamos e aprimoramos constantemente nossos processos, e montamos um time vencedor. Isso é o que nós chamamos de tecnologia movida por pessoas.
+Na OM30 nós trabalhamos em equipe, cumprimos com os compromissos, entregamos com excelência, simplificamos as relações, colocamos o cliente no centro da estratégia, respeitamos e valorizamos a todos, cultivamos relações éticas e transparentes, agimos com integridade. Sempre.
 
-Introdução
-O KOY é um sistema de gestão baseado em dados puxados automaticamente e sem interferência humana e analisa esses dados gerando recomendações. Isso serve pra passivo, precatório, bloqueios, depósitos recursais.
-Acreditamos que isso é possível a partir do poder dos dados, que estão disponíveis nos sistemas judicias brasileiros, a todo momento. 
-O que nós fazemos é desvendar a sua complexidade, transformando-os em conhecimento e em soluções inovadoras que vão muito além da gestão.
-Oferecemos uma gestão operacional de recuperação financeira feita por meio da segmentação e atualização constante de dados dos clientes, além de gerar relatórios customizáveis dos resultados para apoiar a tomada de decisão dos nossos usuários.
-Porque somos diferentes:
+Usuário: Me fale sobre o sistema Saúde Simples:
+Sistema: Nosso sistema possui integração com os sistemas do governo, o que traz mais agilidade e eficiência na coleta e transmissão de dados. Tudo isso em conformidade com as regras exigidas pelo SUS. Integrações: Hórus, e-SUS, Ministério da Saúde e CADSUS.
 
- 
-Mostramos os processos numa interface única (Dashboard de análise)
-Alerta de novas ações, de bloqueios judiciais e de novidades no processo (no Dashboard de análise)
-Monitoramos os processos para soluções em precatórios e em gestão em ativos judiciais, antecipação de bloqueios; venda o crédito de seu precatório, compre créditos tributários
-Recomendamos providências pra melhor estratégia processual (Dashboard de Agenda)
-Reduzimos riscos com a gestão de carteira processual 
-Relatórios completos dos processos e seus impactos na carteira com um click
-Relatórios customizáveis
-
-Como fazemos isso?
-Usamos tecnologia num fluxo que tem como referência o conceito de gêmeo digital, com a replicação do trabalho de um recurso humano que recomenda o que fazer de forma antecipada.
-Para isso seguimos o seguinte fluxo:
-Mineração de informações – processamento – Análise – recomendação da providência ao usuário.
-Aqui temos alguns desafios: como o ambiente da justiça é extremamente inóspito os crawler precisam de refatoração recorrente, emergencial porque embora seja possível saber com antecedência sobre uma manutenção nos sistemas da justiça, só sabemos o que realmente mudou quando o serviço é disponibilizado ao público.
-Um outro desafio é que o acesso sequenciado precisa ser bem planejado e bem executado porque esse acesso é feito utilizando um token meu. O cliente não usa o token dele: 1- ainda não temos a estrutura de armazenamento de de senhas e tokens; 2-alguns clientes não querem disponibilizar o token de seus advogados internos porque eles ou tem outros processos pessoais ou fazem protocolos com esses tokens (e o uso recorrente poderia gerar bloqueio do acesso).
-A justiça monitora a quantidade de acessos quantitativamente, de forma que há um limite (ainda não sabido) de quantos processos podemos atualizar por dia. Hoje resolvemos essa questão manualmente, através da inscrição de cada processo numa aba chamada pus. Essa aba gera e-mail de acompanhamento sempre que o processo tem uma novidade. Recebido o e-mail geramos uma lista que vai por e-mail pra Matheus que inicia os crawler especificamente pra esses casos. Esse procedimento também é manual.
-Implantação de um processo:
-Cadastra o processo através da planilha disponível no menu (aba pastas, importar processos NPU). Feito isso com sucesso, cadastramos manualmente esse processo no e-mail push, inserimos o sistema que ele pertence numa planilha (essa planilha é gerada e alimentada diariamente por Matheus e enviada a Bruno que devolve ela no final do dia). Feito isso o crawler é acionado manualmente pra iniciar a busca de dados.
-Quando isso acontece dizemos que o processo entrou na fila de implantação. Nessa fila o procedimento é trazer dados de capa, dados de movimentações processualista e dados de autos virtuais (esse dados ficam inseridos na tela processo).
-Uma vez que o crawler volte com essa informações elas são enviadas pelo backend para o BD e retorna pro usuário na tela processos, Dashboard de análise e agenda com o agendamento automático de atividades (as que devem ser realizadas pelo usuário final). Esse agendamento vai aparecer tanto na tela processo quanto na tela agenda, ficando nessa última registrado por cores que mudam a medida que chega a data final em que o prazo deve ser concluído.
-Obs.: A fila que inicia o crawler hoje é manual (para o que está na VM) e automática no caso do e-SAJ. Essa última precisa ser refeita para que busque APENAS OS CASOS QUE VOLTAREM COM SINALIZAÇÃO DO PUSH. Hoje, por ser feita dessa forma, ela gera um aporte maior de consultas, que são desnecessárias, geram custo e extremo risco operacional por conta da grande probabilidade do token ser bloqueado ou suspenso (conforma narrado acima).
-Uma vez que o processo saia da fila de implantação (fila 1), e isso é determinado pelo retorno com sucesso dos dados de capa, dados de movimentação e os documentos virtuais, o processo segue pra fila de manutenção (fila 2).
-Essa fila de manutenção deverá buscar dados de movimentações e documentos que estão aulas relacionados, sempre que um processo retornar do e-mail push uma nova atualização. Note-se que ele não lê o que está no e-mail, ele startups a fila.
-Temos um parser pra ler o e-mail, mas acredito que esse serviço esteja defasado. Tínhamos um serviço que inscrevia um processo no push e recebia a atualização desse processo, mas esse serviço não está sendo utilizado desde 2020 e acredito que precise ser refatorado e desenvolvido pra outros sistemas, já que ele existia apenas pro PJE de Pernambuco.
-Atualmente não sei como essas filas são definidas, mas com relação ao payload, tínhamos o problema relacionado a nome das partes. Quando desenvolvemos o KOY, ao invés de determinarmos NOME DA PARTE, elegemos a nomenclatura: AUTOR e RÉU. Isso gera um grande problema, inclusive na interface. 1- backend: como o paylod está alicerçado em AUTOR é RÉU e há um conjunto de sinônimos pra designar essas partes (cada sistemas judicial usa um nome diferente) precisamos enriquecer essa lista ao infinito. O outro problema é que um processo poderá ter outras partes como terceiros, recorrente, recorrido, etc, e uma parte pode, por exemplo, ser autor e recorrido num mesmo processo. O backend estava alicerçado nesse racional, Jonas que estava conosco antes chegamos a fazer um trabalho nesse sentido (no backend). 
-No front isso permanece da mesma forma (e gera problemas de UX) e delimita a venda do produto. Por exemplo: fica mais difícil explicar isso no processo de venda (e nos tira do jogo para um determinado produto que de fato temos mas na interface isso não fica claro), tira a confiabilidade sobre os dados, porque quando há recorrido, recorrente, terceiro e etc, isso não aparecerá na interface, nem em nenhum relatório que o sistema emita (embora esse dado fique gravado, pelo menos é a informação que tenho). 
-Esses dados também são importantes pra o claro entendimento do estágio em que está um determinado processo, pra fins de análise e recomendação de providencia, inclusive pra interpretação de uma IA, como falei em reuniões pra usar o Watson seria necessário um novo treinamento.
-*Obs.: sobre a fila de implantação, há algumas regras que precisam ser atendidas. Um processo não pode se repetir pra um mesmo cliente (e o que chamo de cliente, no BD está na tabela ESCRITÓRIO). 
-Embora um processo não possa se repetir pra um mesmo cliente, ele poderá ser cadastrado para um outro cliente. Isso acontece porque um processo envolve partes contrárias e que as mesmas podem contratar o KOY. Já tivemos essa situação em um determinado processo em que um de nossos clientes era o réu e um outro cliente era o autor da ação.
-
-AUTOR: quem entra com a ação
-RÉU: quem é processado numa ação
-EMBARGANTE: quem entra com embargo de declaração (é como se fosse um recurso). Independentemente de ser autor ou réu.
-EMBARGADO: quem tem a decisão embargada. Independentemente de autor ou réu.
-Impetrante: é como se fosse autor de um tipo bem específico de processo.
-Impetrado: é como se fosse o réu de um tipo bem específico de processo.
-(…)
-
-Atualmente há um erro de racional no sistema porque considerou que um processo só seria de uma única parte, desconsiderando que num caso de escalada do KOY o sistema poderia ser contratado por pelo menos 4 players diferentes (A PRÓPRIA EMPRESA, o próprio autor, o advogado da empresa e o advogado do autor). 
-Há a possibilidade de contratação inclusive de outros players pra um mesmo processo. Nenhum deles se comunicas e eles tem visões diferentes do mesmo caso, com agendas diferentes e demais campos com informações antagônicas. Esse racional que precisa ser corrigido. Quanto a uma mesmo cliente, esse sim, não poderá ter duplicidade de processos (para ele há uma trava pra impedir a duplicidade). Lembrando que cliente está na tabela descrito como ESCRITÓRIO. Há uma outra tabela com o TÍTULO CLIENTE mas que se relaciona com o cadastro de clientes do escritório e às provisões e garantias financeiras dos processos judiciais (inclusive esses campos são preenchidos de forma manual).
-Há um outro racional que usamos no KOY pra indicar a área do processo (dado de capa), onde o crawler deve ir (isso não está funcionando, já funcionou num serviço chamado NPU Decoder e foi desativado porque estava gerando duplicidade em processo e instância). Essa duplicidade era gerada em virtude de um erro de lógica. A lógica usada previa que para se achar um processo, desconsiderava-se o NPU e considerava-se uma busca aleatório que uma vez que trouxesse o retorno positivo iria incluir aquele processo como existente. Assim o processo quando era cadastrado (para fins de implantação) era duplicado no sistema e aguardava o retorno do crawler confirmar a existência dele quando ia na justiça e voltava com o sistema, para na sequência buscar os dados de implantação.
-Essa lógica é errada e há uma forma extremamente simples e segura de obter a confirmação. O NPU é o número único de processo. Esse número segue um padrão numérico de 20 dígitos em que os primeiros números são verificadores de existência sendo os demais determinantes da área, o estado onde está o processo e até a vara onde o processo será analisado.
-Nós decodificamos manualmente essa informação que está listada numa planilha com os descritivos acima cujo racional deve ser usado no NPU Decoder (quando o serviço for refatorado). Vou disponibilizar juntos. Esse material tanto a planilha com esse racional quanto a documentação numérica do CNJ (órgão governamental que define essas regras numéricas).Hoje esse trabalho é feito manualmente e o tratamento é para mais de 5 mil processos, isso gera uma baixíssima velocidade de ataque e importação do cliente.
-Esses dados afetam tanto dados de capa quanto dados de instância (ambos exibidos na tela de processo e espelhados na tela de Dashboard de análise e de agenda e exportáveis em Excel no Dashboard de Gestão). Esse dado numérico funciona como um GPS pra encontrar o sistema e iniciar o acionamento do crawler.
-Essas filas são estruturardes pelo Back (hoje estão sendo feitas manualmente seguindo a seguinte lógica: separa-se a listagem por estado e sistema e inicia-se a VM com o crawler responsável por aquela fila. Como é feito manualmente cada VM é acionada uma de cada vez e perdemos a otimização e aumentamos o número de maquinas. Hoje esses crawler que rodam nessas VM’s que estão na IBM serão enviadas pro Google. Quem está responsável por essa tarefa é o pessoal da GoLive. Eles estão refatorado os códigos e enviando pro Google, mas ainda será feita de forma manual, com acionamento manual do crawler.
-Pra isso ser resolvido precisaremos de uma abordagem que considere desde a resolução do número pra designação do crawler que deve ser acionado, até a montagem das filas, significando que o serviço eficiente depende de um serviço de orquestração na montagem e envio dessa lista para as filas que acionarão os crawlers.
-Esse serviço de orquestração deverá considerar além do racional numérico, as questões relacionadas ao serviço de push para que não haja um aporte grande de dados de uma única vez evitando que o serviço seja identificado.
-Há aqui um outro desafio, hoje o crawler disputa conexões no BD com os usuários o que gera uma impacto na otimização e estalagem do produto. Há outras questão de melhoria relacionadas ao BD cujo levantamento foi feito, uma parte foi executado e outra parte está pendente. Essa pendência decorreu do fato de que após a primeira entrega do trabalho para dar seguimento das demais entregas seria necessária a reprogramação do Back, por conta dessas questões acima enumeradas em relação ao payload, por exemplo.
-Quanto à descoberta de um novo processo, consumimos esse serviço da KURIER um player de mercado que é parceiro nisso, mas concorre em outras frentes. Esse serviço é precário, mas funciona. Plugamos na API deles cuja documentação também estou enviando aqui. 
-Uma vez que os processos sejam implantados, ele aciona agendamentos automáticos de atividades. Esses agendamentos de atividades podem ser gerados de forma manual pelo usuário e de forma automática pelo usuário Norma.
-Esses agendamento pode ser feitos em dois locais: 1- no Dashboard de processo; 2- no Dashboard de Agenda. 
-No caso do agendamento automático ele é feito pelo backend e usa tanto algoritmos nossos (baseados em automação de fluxo já usado pelo cliente, que em que sugerimos na fase de implantação algumas melhorias de eficiência) quanto os gerados por WATSON (usamos o WKS 
-Para que Watson leia a informação, há uma triagem prévia do andamento que queremos submeter a essa análise.
-Hoje ele funciona para ler movimentação de audiência, bloqueio, perícia, Sessão de Julgamento, e pra analisar possibilidade de encerramento do processo (esse serviço tem 70% de acurácia, e precisa ser treinado pra abranger novas hipóteses). A ideia é o CHAT GPT substituir essa ferramenta e aumentar o alcance.
-O CHAT GPT deve gerar as providências de agenda (considerando o passo a passo do processo), isso segue uma lógica matemática definida no Código de processo civil, e regras do processo trabalhista, eleitoral, tributário, entre outros, seguindo um racional de árvore decisória. 
-O CHAT GPT deverá promover a análise de um processo pra indicar a melhor tese, deverá ler pra identificar oportunidades de encerramento (de forma mais assertiva), deverá ler guias específicas e extremamente repetitivas e com base nessas guias e decisões pra esse mesmo tipo de tese gerar uma probabilidade de provisionamento. Há muitas formas de utilizarmos essa tecnologia e podemos iniciar com coisas que usamos Watson (principalmente pra indicação de encerramentos, classificando por matéria) e pra fazer e a leitura dessas guias com selagem na interface. 
-Uma vez que exista esse dado setado na interface (via Dashboard de agenda e de processo), poderemos dar o passo seguinte, busca de valores nos processos.
-E por fim a indicação das melhores defesas, melhores ataques (a depender do perfil do usuário).
-O serviço também deve expandir no quesito BI. Hoje temos um Dashboard extremamente empobrecido, embora haja uma quantidade gigantesca de dados armazenados.
+Usuário: ME fale sobre o Educação Simples:
+Sistema: Com nosso sistema, o gestor tem acesso às informações gerenciais em tempo real, podendo identificar problemas e buscar alternativas de solução de maneira muito mais rápida e acompanhar a rotina administrativa de toda a rede municipal de educação.