O problema
Numa operação com vários clientes e projetos, cada um com seu contrato, a informação sobre o que foi acordado fica espalhada: no PDF do contrato, nos anexos, nas especificações e, principalmente, nos aditivos. Quando alguém da operação precisa saber o prazo, o valor, a obrigação de uma parte ou o que acontece em caso de atraso, a resposta depende de achar o documento certo e de ler cláusulas em textos longos.
Os aditivos eram o ponto mais difícil. Um aditivo altera pedaços específicos do que foi contratado, então a resposta correta muitas vezes está na combinação do contrato original com um ou mais aditivos, e não em um único documento. Sem uma visão centralizada, o risco é decidir com base em informação incompleta ou desatualizada sobre o escopo.
O objetivo do 3e Lex foi reunir os documentos de cada projeto em um só lugar e permitir que pessoas autorizadas perguntem em linguagem natural, recebendo respostas com a fonte: documento, cláusula, página e o trecho literal.
Decisões de arquitetura
Em contrato, uma resposta plausível mas errada é pior do que nenhuma resposta. Por isso as principais decisões giraram em torno de rastreabilidade, não de fluência do texto gerado.
- Time de agentes, cada um com uma responsabilidade. Um agente lê o PDF (com OCR para páginas escaneadas) e o divide em cláusulas; outro indexa para busca semântica; outro identifica cláusulas de multa e penalidade; um orquestrador decide o caminho de cada pergunta; e um respondedor redige a resposta com citação obrigatória.
- Auditor de citação determinístico. Antes de exibir a resposta, um auditor confere por código se os trechos citados existem de fato no documento e se números e datas da resposta aparecem na fonte. Não usei um segundo LLM como validador principal: ele também pode alucinar e "confirmar" uma citação que não bate. O LLM entra só no caso ambíguo.
- Chunking por cláusula. Dividir o contrato em blocos de tamanho fixo corta cláusulas ao meio e prejudica tanto a busca quanto a citação. A unidade de indexação respeita a estrutura do contrato, e cada trecho carrega cláusula e página de origem.
- Vários documentos ativos por projeto. Contrato, aditivos e anexos são consultados juntos, no mesmo índice. Um novo upload soma aos existentes; para aposentar um documento, o administrador o desativa explicitamente, e as citações antigas continuam rastreáveis.
- Isolamento por projeto. O usuário só consulta os projetos aos quais tem acesso, e há teste automatizado de isolamento entre projetos. Os PDFs ficam cifrados em disco e todo acesso e alteração entra no histórico de atividades.
- Resposta só com base nos documentos. Se a informação não está lá, o sistema diz que não encontrou, em vez de completar com conhecimento geral.
Em contrato, o valor do assistente não está em responder rápido, e sim em responder de um jeito que dê para conferir.
Desafios & aprendizados
O aprendizado mais importante veio justamente dos aditivos. O planejamento inicial tratava um aditivo como uma nova versão do contrato, que substituiria a anterior. A versão final foi diferente: todos os documentos do projeto ficam ativos ao mesmo tempo. Um aditivo costuma alterar pontos específicos, e não reescrever o contrato inteiro, então responder bem exige ler o conjunto.
O segundo aprendizado foi sobre o escopo da consulta. O sistema nasceu com chat por projeto. Com o uso, foram surgindo o chat por cliente, o chat geral com um guia de dois passos para escolher cliente e projeto, e o resumo executivo com valor, escopo e riscos por contrato. A pergunta operacional raramente se limita a um único documento.
O terceiro é sobre confiança. Mesmo com auditor, citação e fonte clicável, o sistema não substitui a leitura do trecho: o próprio guia de uso avisa que, em decisão contratual importante, a fonte deve ser aberta e conferida. O que a arquitetura faz é tornar essa conferência rápida, porque cada resposta já aponta para a página certa do PDF.
Resultado
O 3e Lex passou a ser usado na tomada de decisão operacional. O ganho mais claro está na informação de escopo: o que antes ficava difundido entre contratos, anexos e aditivos passou a ficar centralizado, com respostas mais precisas e com a origem visível. Os aditivos, que eram o maior ponto de dificuldade, deixaram de exigir uma busca manual documento a documento.
Este artigo não traz números de ganho de tempo ou de volume de uso: o impacto que afirmo aqui é qualitativo, e a evolução do sistema (chat por cliente, resumo executivo, histórico de atividades) segue guiada pelo que a operação pede.
Python 3.12 e FastAPI no backend; LangGraph para orquestrar os agentes; PostgreSQL com pgvector para busca semântica; Celery e Redis para o processamento dos documentos em segundo plano; OpenRouter como gateway de LLM; React com TypeScript no frontend; Docker para execução e implantação.