Em resumo: a maioria dos produtos de Legal AI são arquitetonicamente idênticos. Sua pergunta vai para um modelo de propósito geral com um template de prompt em torno dele, e você não consegue dizer isso pela interface. A diferença que importa acontece antes do modelo ser chamado. Quatro perguntas no final desta postagem dirão que tipo de sistema qualquer fornecedor está vendendo a você, em cerca de dez minutos de demonstração.
Todo advogado que avalia Legal AI acaba fazendo a mesma pergunta, geralmente cerca de oito minutos após o início de uma demonstração: como isso é diferente de simplesmente usar o ChatGPT?
É a pergunta certa, e a maioria dos fornecedores a responde mal. Eles falam sobre dados de treinamento, ou um corpus proprietário, ou um fine-tune. Essas respostas são difíceis de verificar e, na maioria das vezes, não é onde a diferença realmente reside.
A resposta honesta é arquitetônica, e se resume a uma coisa: onde o pensamento acontece?
O problema do "wrapper" é real e invisível por fora
Uma grande parte dos produtos de Legal AI funciona assim. Você digita uma pergunta. O produto a envolve em um template de prompt, algumas instruções sobre como ser um assistente jurídico prestativo, talvez alguns exemplos, e encaminha tudo para um modelo de propósito geral. O modelo responde. O produto formata a resposta de forma agradável e a mostra a você.
Não há nada desonesto nisso. Pode ser genuinamente útil. Mas isso significa que a qualidade do produto é quase inteiramente a qualidade do modelo, e o modelo é o mesmo que seu advogado oposto pode acessar por vinte dólares por mês.
A parte desconfortável para um comprador é que você não consegue dizer pela interface. Um wrapper e um motor construído para um propósito específico parecem idênticos: uma caixa de texto, uma resposta em streaming, algumas citações abaixo. A diferença está a montante, onde ninguém pode vê-la, e é exatamente por isso que tão poucos fornecedores são pressionados sobre isso.
Onde o raciocínio realmente pertence
Quando uma pergunta chega à HAQQ, ela não vai primeiro para um modelo geral. Ela passa por uma etapa que possuímos e controlamos, cuja única função é descobrir qual é realmente a solicitação e configurar tudo o que acontece a seguir.
Esse passo resolve as coisas que um associado competente estabeleceria antes de iniciar o trabalho, e as resolve como dados estruturados, em vez de prosa:
- O que está realmente sendo perguntado. Não as palavras digitadas às 23h entre duas chamadas, mas a questão subjacente a elas, reformulada de forma precisa e completa. Isso funciona nativamente em árabe e francês, assim como em inglês, em vez de ser uma tradução anexada posteriormente.
- Que tipo de trabalho jurídico é este. Elaboração, pesquisa, revisão, comparação, uma questão processual. Cada um exige uma forma diferente de resposta, e decidir isso antecipadamente é muito diferente de esperar que um modelo geral o infira.
- Qual jurisdição está em jogo, e separadamente, em que idioma a lei aplicável está escrita. As duas frequentemente não são a mesma coisa, e tratá-las como uma só é uma fonte silenciosa e comum de erro.
- Os fatos, como objetos. Partes, datas, obrigações, valores, lei aplicável, tipo de documento, extraídos da prosa e transformados em dados estruturados antes que algo caro os leia.
- O que a pergunta precisa e o que não precisa. Quais capacidades especializadas devem ser usadas, qual profundidade de raciocínio a pergunta realmente justifica e se ela está dentro do escopo.
Só então o modelo de propósito geral é executado. E ele chega já preparado: as capacidades relevantes carregadas, os fatos extraídos, a jurisdição identificada, o escopo decidido.
O modelo é o último passo da cadeia, não o primeiro.
Por que isso produz uma resposta melhor, e não apenas mais barata
Dois mecanismos, e o segundo nos surpreendeu mais do que o primeiro.
A atenção é um orçamento
A janela de contexto de um modelo é finita, e tudo o que você coloca nela compete pela atenção do modelo. Carregar todas as capacidades que um sistema possui em cada solicitação consome uma parte significativa dessa janela antes que o documento real do advogado seja considerado. Trazer apenas as relevantes deixa espaço para o que importa: o contrato, o estatuto, os fatos.
A análise não é um raciocínio
Este é o efeito maior. Quando um modelo recebe um parágrafo em prosa, uma parte significativa do seu trabalho consiste em descobrir o que o parágrafo contém. Quando ele recebe fatos estruturados, estas partes, esta lei aplicável, esta obrigação, esta data, esse trabalho já está feito, e todo o orçamento é dedicado à questão jurídica.
A consequência prática é que o mesmo modelo de propósito geral produz um trabalho jurídico visivelmente melhor dentro de um sistema como este do que dentro de um "wrapper". O modelo não mudou. O que nós lhe fornecemos sim.
As partes que ninguém coloca numa demo
Duas coisas que nunca chegam a um "deck" de vendas, e ambas decidem se o produto funciona numa terça-feira real.
Ingestão de documentos. Uma grande parte do trabalho jurídico não chega como texto limpo. Chega como uma fotografia de um documento carimbado, uma digitalização de um fax, um PDF que alguém imprimiu e digitalizou torto novamente. Tratamos a leitura desses documentos como um problema de engenharia de primeira classe, em vez de uma reflexão posterior de pré-processamento, porque se um número de cláusula for lido incorretamente na entrada, nenhuma quantidade de raciocínio a jusante o recupera. O sistema raciocinará impecavelmente sobre o número errado.
Memória como estrutura, não transcrição. O mecanismo mantém as relações entre os seus assuntos ao longo do tempo e as utiliza quando uma questão o exige. Isso é diferente de colar as suas últimas vinte mensagens de volta no prompt. É o que permite que o sistema saiba que a contraparte no NDA que você está revisando hoje é a mesma de uma disputa de dois meses atrás.
O que esta arquitetura não resolve
Preferimos dizer isso a que descubra por si mesmo.
Não elimina erros. Qualquer sistema construído sobre um modelo de linguagem pode produzir uma resposta errada, e um fornecedor que lhe diga o contrário ou não está a ser cuidadoso com as palavras ou espera que não verifique. O que uma boa arquitetura faz é tornar os erros mais raros e detetáveis: afirmações geradas com base em fontes recuperadas, citações que pode abrir e sinalizações explícitas onde a lei é genuinamente ambígua, em vez de uma resolução confiante de algo não resolvido.
Não dispensa o advogado. Tudo aqui é concebido com base na suposição de que um profissional revisa a produção e a assina. Isso não é uma limitação pela qual pedimos desculpa. É a restrição de design, e é a razão pela qual a arquitetura tem a aparência que tem.
Não torna a cobertura universal. A qualidade da Legal AI varia consoante a jurisdição, o grau de digitalização da lei de origem e a quantidade de informação pública disponível. A quem lhe apresentar um único número global de cobertura, deve ser perguntado o que ele inclui. Perguntam-nos isso frequentemente, e preferimos responder sobre a sua jurisdição do que apresentar-lhe um número qualquer.
Como testar qualquer fornecedor numa demonstração
Não precisa de ver o diagrama da arquitetura de ninguém. Quatro perguntas, cerca de dez minutos, e funcionam para qualquer fornecedor nesta categoria, incluindo nós.
1. Pergunte algo fora da área jurídica
Um modelo geral envolvido numa solicitação jurídica geralmente responderá a uma questão médica ou financeira, porque, no fundo, é um modelo geral. Um sistema que estabeleça a intenção antes de gerar deve recusar e explicar o porquê.
2. Faça a mesma pergunta em dois idiomas
Não é uma versão traduzida. A mesma questão jurídica, uma vez em inglês e outra em árabe ou francês. Se o conteúdo da resposta mudar, a linguagem está a ser processada após o raciocínio, e não antes.
3. Faça uma digitalização ruim
Fotografe um documento em ângulo, com pouca luz, e faça o upload. Este é o teste mais preditivo de toda a demonstração, porque é a entrada real mais comum e a menos demonstrada.
4. Pergunte o que não sabe
Empurre para uma área do direito ambígua, não resolvida ou com poucas fontes. Um sistema otimizado para sempre produzir uma resposta produzirá uma. Um sistema construído para trabalho profissional lhe dirá que o terreno é incerto e mostrará por quê.
Se um fornecedor se sentir confortável com todos os quatro, a arquitetura provavelmente é real. Se a demonstração desviar deles, isso também é informação.
Principais conclusões
- A diferença significativa entre os produtos de Legal AI é arquitetural e invisível da interface. Pergunte onde o raciocínio acontece.
- Fazer trabalho estruturado antes da chamada do modelo melhora a qualidade da saída, não apenas o custo. Um modelo que recebe fatos extraídos gasta seu orçamento em direito em vez de em análise.
- Os componentes menos glamorosos decidem o desempenho no mundo real. A qualidade da ingestão de documentos é mais preditiva de se uma ferramenta funciona em uma terça-feira do que qualquer pontuação de benchmark.
- Quatro perguntas de demonstração, fora do tópico, dois idiomas, uma digitalização ruim e uma área do direito não resolvida, dirão que tipo de sistema está sendo vendido a você.
- O motor Justinian e como ele raciocina
- 45 sinais de alerta ao avaliar um fornecedor de Legal AI
- Legal AI com intervenção humana
- Engenharia de contexto para Legal AI
Experimente HAQQ AI grátis
Experimente a redação e pesquisa jurídica com IA
