Legora elevou a precisão das citações jurídicas de 70% para 99% sem acesso aos dados

A equipe da Legora enfrenta um problema incômodo, mas cada vez mais comum: seu agente jurídico trabalha com documentos confidenciais, enquanto os desenvolvedores não podem simplesmente abrir um rastro e verificar onde o modelo tomou o rumo errado. Os dados pertencem aos clientes dos escritórios de advocacia. Isso significa que o ciclo habitual de “encontrar uma resposta ruim, ler a consulta e corrigir o prompt” não funciona nesse contexto.

A Legora estrutura a avaliação de outra forma. Engenheiros e advogados criam ambientes de teste semelhantes ao trabalho real: salas com milhares de arquivos e tarefas de localização de cláusulas em contratos, preparação de minutas e verificação de citações. Não são cópias perfeitas dos casos dos clientes, mas constituem um campo de testes suficientemente próximo da realidade para detectar erros recorrentes antes do lançamento.

Como avaliar aquilo que não pode ser visto

Imagine um agente encarregado de revisar 10.000 contratos e montar uma tabela com prazo de vigência, direito de rescisão, multas e um link para o trecho original. Em um projeto real, o desenvolvedor não tem permissão para ler nem os contratos nem as respostas do agente. Mas pode montar um conjunto artificial com a mesma estrutura: documentos longos, anexos contraditórios, campos ausentes e diversas redações da mesma cláusula.

Em seguida, a equipe define antecipadamente as respostas corretas e mede as etapas separadamente: se o documento certo foi encontrado, se a cláusula foi extraída, se a conclusão corresponde à fonte e se a citação leva ao local correto. Em uma entrevista, o CTO da Legora, Jacob Lauritzen, descreve uma equipe dedicada de engenheiros e advogados que constrói esses ambientes. Eles lembram “mundos” de jogos usados para treinar agentes: o sistema recebe uma tarefa realista, mas não entra em contato com o caso privado do cliente.

Quando uma falha ocorre em dados reais, a Legora procura não levar o texto original para fora do ambiente protegido. A equipe usa exemplos anonimizados ou parafraseados e reduz os problemas a 10–20 tipos. Por exemplo, o agente pode escolher a versão errada de um contrato, ignorar uma exceção à regra ou apresentar uma citação que parece convincente, mas não sustenta a conclusão. Essa classe de falha pode então ser reproduzida em um conjunto seguro.

Métricas são mais importantes que uma demonstração impecável

O exemplo das citações é particularmente revelador. Segundo Lauritzen, em um dos testes o modelo indicava corretamente as fontes em cerca de 70% dos casos. Após outra atualização do modelo subjacente, o índice subiu para 99%, embora a Legora não tivesse alterado seu próprio sistema. É uma boa notícia para o produto, mas também um alerta: a qualidade do agente não depende apenas do seu código. O fornecedor do modelo pode corrigir repentinamente um ponto fraco — ou quebrar algo que funcionava ontem.

Por isso, uma única pontuação geral não é suficiente. São necessárias avaliações separadas para busca, extração de fatos, citações, processamento de documentos longos e preenchimento de tabelas. Um novo modelo não deve ser lançado apenas porque responde melhor a algumas perguntas feitas manualmente. Ele deve ser executado em um conjunto fixo de tarefas e comparado com a versão anterior em cada cenário crítico.

O que pode ser aplicado a um produto convencional

A abordagem da Legora não é útil apenas para advogados. Um assistente bancário, um agente médico ou uma ferramenta de busca corporativa enfrentam o mesmo limite: o produto precisa melhorar, mas os dados brutos não podem ser entregues aos desenvolvedores. A fórmula prática tem quatro partes: descrever os fluxos de trabalho reais, construir equivalentes seguros, rotular os resultados esperados e manter um catálogo de falhas recorrentes.

A limitação é evidente: uma simulação é sempre mais pobre que a realidade. Ela não revelará uma redação rara, uma estrutura incomum de arquivo ou um erro que surge apenas em uma combinação específica de documentos. Por isso, os testes sintéticos não substituem o feedback protegido dos usuários nem as métricas agregadas do produto. Eles oferecem algo diferente: um ambiente reproduzível no qual é possível alterar o modelo, a busca e a interface sem acessar segredos alheios.

A principal conclusão para o desenvolvedor é simples: se os rastros são privados, a observabilidade não desaparece — ela precisa ser projetada. Comece não pelo registro indiscriminado de tudo, mas por uma lista das decisões pelas quais o agente é responsável e dos indicadores mensuráveis de um resultado correto. Assim, a privacidade deixa de ser uma justificativa para a ausência de avaliações e passa a ser uma restrição em torno da qual o sistema de engenharia é construído.