jev-latest

O Jev é o modelo principal da TypeSafe e o primeiro de uma nova classe, System One. Não escreve texto: toma rapidamente decisões que um programa pode utilizar de imediato. Fornece-se um estado (state) — texto ou JSON — e um conjunto de perguntas, e recebem-se valores tipados com probabilidades calibradas.

Os modelos de linguagem escrevem palavras para pessoas; segundo a TypeSafe, o Jev está mais próximo do código: a resposta vem logo no formato de que o código precisa, com elevada velocidade e sem valores fora das opções definidas. O modelo foi concebido para dar respostas estáveis a pedidos repetidos.

Em que difere o System One de um modelo de linguagem

• Não gera conteúdo. O Jev não escreve respostas para o utilizador, código ou explicações do raciocínio. As respostas possíveis são definidas por quem faz o pedido, através de um dos três tipos de pergunta.
• Treinado para decisões calibradas. A TypeSafe treina o modelo pelo método RLCD (Reinforcement Learning for Calibrated Decisions): as probabilidades são ajustadas aos resultados reais e refletem a incerteza. Numa grande amostra de respostas com probabilidade 0,8, cerca de 80% deverão estar corretas. A calibração é uma propriedade de uma amostra grande, e não uma garantia de que uma resposta individual está correta.
• Um objetivo de treino diferente. Os modelos de conversação são treinados para agradar às pessoas (RLHF); segundo a observação da TypeSafe, isto incentiva respostas complacentes e erros que soam confiantes. Diogo Almeida, um dos coautores do RLHF, é cofundador da TypeSafe.

O nome remete para o «Sistema 1» do livro de Daniel Kahneman «Pensar, Depressa e Devagar»: o juízo intuitivo rápido, em contraste com o pensamento lento e deliberado do «Sistema 2». O Jev foi criado para juízos rápidos e bem delimitados.

Três tipos de pergunta

Uma pergunta corresponde a um juízo sobre o estado; a resposta é um valor que o código compara com um limiar, ordena ou transmite à etapa seguinte.

1. Choice — escolha de uma opção. O departamento responsável por um pedido, a categoria de um produto ou a linguagem de um fragmento de código. As opções são um dicionário «opção → descrição», com até 255 entradas. A resposta inclui a opção escolhida, choice, as probabilidades probabilities de todas as opções, cuja soma é 1, e a confiança confidence. Se a lista puder não abranger todos os casos, acrescente «outro» ou «nenhuma das opções».
2. Score — avaliação numa escala. Uma posição numa escala ordenada definida por quem faz o pedido: gravidade de um erro, irritação de um cliente ou nível de uma competência. Existem entre 2 e 10 níveis, do mais baixo ao mais alto; o modelo avalia cada nível separadamente, sem ver o seu número nem os níveis vizinhos. A resposta inclui score — a soma dos números dos níveis multiplicados pelas respetivas probabilidades, pelo que o valor pode situar-se entre níveis —, legend com as descrições dos níveis, probabilities e confidence.
3. Noul — sim ou não. Indica se uma afirmação é verdadeira. A resposta noul é a probabilidade de «sim», entre 0 e 1: perto de 1 significa um «sim» confiante; perto de 0, um «não» confiante; perto de 0,5, o modelo está indeciso. Não existe um confidence separado: um único número descreve a resposta por completo. O campo opcional criteria especifica o que deve contar como «sim» e como «não».

Como escolher: opções conhecidas sem ordem — choice; graus de um espectro — score; «sim/não» puro, em que a própria probabilidade é importante — noul. Noul 0,5 significa probabilidades iguais de «sim» e «não», e não um «nível médio»: é o score que mede o grau. Se dois tipos forem adequados, escolha aquele que permita ao código agir de imediato: choice para ramificações, score para um limiar e noul para if.

Os tipos podem ser combinados num pedido. A resposta está sempre limitada às opções definidas e é independente das outras perguntas: é possível acrescentar ou retirar perguntas sem alterar as restantes respostas.

Estado

O estado é aquilo que o modelo avalia: uma mensagem de um cliente, um fragmento de documento, um registo de uma base de dados ou o estado da aplicação.

• Cadeia de texto — quando existe um único texto: uma mensagem, um artigo ou um excerto.
• Objeto — campos com nome, registos relacionados ou o estado da aplicação. A TypeSafe recomenda objetos para a maioria dos pedidos: cada parte tem um nome claro.
• Matriz — uma sequência de mensagens ou registos.

Prepare o estado como prepararia materiais para especialistas: junte a correspondência, a encomenda e as regras de devolução se a decisão exigir a sua comparação. Coloque o conteúdo no estado e os juízos nas perguntas. Se uma pergunta disser respeito a uma parte do estado, indique nela o caminho até essa parte entre acentos graves, por exemplo ticket.messages[0].text.

Como formular perguntas

• Um juízo rápido por pergunta. Uma boa pergunta é aquela a que uma pessoa conhecedora, com o contexto necessário, responderia num segundo: «A mensagem transmite urgência?». «Analisa a mensagem e decide o que fazer» já exige raciocínio lento; deve ser dividido em perguntas simples.
• A pergunta completa em instructions. A chave da pergunta, por exemplo refund_requested, serve apenas para o código e não é transmitida ao modelo.
• Todas as perguntas sobre o mesmo estado num único pedido. O modelo avalia-as em paralelo: segundo a TypeSafe, perguntas adicionais quase não aumentam o tempo de resposta e custam apenas os seus próprios tokens. Uma pergunta «por precaução» custa muito pouco; o código decide quais as respostas de que precisa.
• Um juízo complexo dividido em partes. Em vez de «avalia a candidatura da startup», pergunte separadamente sobre a dimensão do mercado, a viabilidade técnica e as diferenças face à concorrência, e calcule o resultado no código com pesos. Se as prioridades mudarem, alteram-se os pesos, sem reformular a pergunta.
• Perguntas dependentes num segundo pedido. As respostas de um pedido não servem de contexto umas às outras. Um segundo pedido só é necessário se não puder ser construído sem a primeira resposta: por exemplo, para carregar dados ou escolher as opções da pergunta seguinte.
• Uma pergunta longa em formato de objeto. instructions e criteria são normalmente cadeias de texto, mas também podem ser um objeto ou uma matriz: a pergunta num campo e os dados noutros. Isto facilita, por exemplo, a comparação de um currículo com registos de uma base de dados através de uma única pergunta.

Confiança

Em choice e score, confidence, entre 0 e 1, indica até que ponto a probabilidade se concentra numa única resposta: 1 significa que está toda numa opção; 0, que está distribuída igualmente por todas. Em score, um nível vizinho reduz menos a confiança do que um nível distante. Em noul, a confiança é o próprio valor: quanto mais se afasta de 0,5, mais firme é a resposta.

A TypeSafe recomenda três intervalos:

1. Confiança elevada — agir automaticamente.
2. Média — agir com cautela, por exemplo, pedir confirmação ao utilizador.
3. Baixa — encaminhar o caso para uma pessoa, esclarecer o pedido ou utilizar uma alternativa, como um modelo mais potente com raciocínio.

Quanto maior for o custo de um erro, mais rigoroso deve ser o limiar: para ações irreversíveis, deve ser mais elevado do que para leitura. A resposta indica o que escolher; a confiança indica se vale a pena agir. Ajuste os limiares com os seus próprios dados, comparando confiança e exatidão.

Como construir um sistema em torno do Jev

O Jev foi concebido para programas em que o código controla o processo e o modelo responde a perguntas semânticas específicas, em vez de agentes que escolhem autonomamente o passo seguinte e podem perder o rumo em cada ciclo. Oito passos de conceção segundo a TypeSafe:

1. Tudo o que puder ser feito em código deve ser feito em código, de forma fiável e económica.
2. Coloque no estado apenas o que as perguntas atuais exigem; obtenha factos recentes na sua própria base de conhecimento, em vez de os obter da memória do modelo.
3. Estruture o estado: JSON aninhado e, na pergunta, o caminho até ao campo necessário entre acentos graves, quando isso reduzir a ambiguidade.
4. Faça perguntas tão específicas e concretas quanto possível — segundo a TypeSafe, esta é talvez a regra principal: uma pergunta abrangente esconde vários juízos numa única resposta.
5. Estruture as perguntas: mantenha a pergunta em si curta; coloque explicações, exemplos e valores da sua base de dados em campos adjacentes do objeto instructions ou criteria, em vez de uma única cadeia de texto longa.
6. Reúna muitas perguntas independentes sobre o mesmo estado num único pedido, para obter mais utilidade por dólar.
7. Combine as respostas em código: através de regras, de uma soma ponderada ou como características para um modelo clássico de aprendizagem automática.
8. Crie ramificações segundo a confiança: os casos incertos vão para uma pessoa ou para um modelo com raciocínio.

O Jev não é um modelo de conversação nem de preenchimento automático de código, e não pode substituir um modelo de linguagem num agente de programação. Um agente pode, contudo, escrever código que chame o Jev quando for necessária uma resposta rápida e calibrada.

Aplicações

• Automatização em segundo plano — decisões executadas um milhão de vezes sem uma pessoa por perto.
• Tempo real — segundo a TypeSafe, a maioria dos pedidos é executada em cerca de 100 ms, o suficiente para processamento em tempo real e interfaces.
• Grandes volumes de dados — pesquisa em grandes conjuntos de documentos, anotação de registos de agentes e características para previsões.
• Verificação de outros modelos — pedidos, extrações, raciocínio e chamadas de ferramentas: contorno de restrições, erros de citação e informação inventada.
• Pesquisa e ordenação — relevância de um par «consulta — candidato», reordenação e seleção de contexto.
• Encaminhamento por intenção — o que pretende o utilizador e qual o tratamento necessário: lógica simples, um modelo especializado ou uma pessoa; o tema, a complexidade e o risco determinam a que modelo de linguagem se atribui o pedido.
• Verificações de proteção — entrada, saída e chamadas de ferramentas de um modelo de linguagem: instruções injetadas, violações de regras e fuga de dados pessoais.
• Apoio ao cliente — tema e intenção do pedido, urgência, irritação, risco de abandono, pedido de reembolso e fila de atendimento.
• Moderação — segundo as regras da plataforma: toxicidade, assédio, spam, fraude, conselhos perigosos e dados pessoais; consoante a gravidade e a confiança, permitir, avisar, verificar ou bloquear.
• Setores — sinistros de seguros, investigações financeiras e KYC, contratos e publicidade, fichas de produtos, recrutamento, potenciais clientes, jogos, riscos, previsão da procura, grafos de conhecimento, revisões científicas e verificações semânticas de código em CI.

Características

• jev-latest — alias da versão estável mais recente, atualmente Jev 1.13; a versão que respondeu consta do campo model, por exemplo jev-1.13.0. Quando surge uma nova versão, o alias passa a apontar para ela, e as respostas podem mudar sem alterações da sua parte; acompanhe este campo se os limiares tiverem sido ajustados a uma versão.
• Contexto — 64K tokens por pedido, contando o estado e todas as perguntas; o estado com a pergunta mais longa pode atingir 32K. O modelo lê o estado uma única vez e verifica todas as perguntas contra ele em paralelo.
• Entrada — apenas texto: uma cadeia de texto, um objeto JSON ou uma matriz de textos. Imagens, áudio e vídeo ainda não são suportados; converta-os previamente em texto.
• Língua — a principal língua de treino é o inglês, que apresenta atualmente a maior exatidão. O modelo aceita outras línguas, incluindo chinês, japonês e coreano, mas com menor exatidão; verifique com os seus próprios dados.
• Preços e faturação na Ailoot API — as condições dependem do método escolhido e estão indicadas na respetiva ficha.
• Configuração — o Jev não é sujeito a treino adicional com dados do cliente: os materiais próprios vão em state, e as regras do domínio, em instructions e criteria.
• Dados — a TypeSafe afirma que o Jev não é treinado com os pedidos e respostas dos clientes.

Limitações conhecidas do Jev 1.13

A TypeSafe enumera abertamente as limitações da versão atual e promete corrigir muitas delas nas seguintes. O modelo é rápido, calibrado e faz bons juízos de senso comum, mas:

1. Lê literalmente. Responde à pergunta escrita, e não à que se pretendia fazer: entende ressalvas, negações e condições implícitas de forma literal. Escreva a condição exata e os casos limite em criteria; se uma interpretação for inevitável, divida-a em duas perguntas literais.
2. Não é uma calculadora. A contagem de caracteres, repetições e elementos de listas é pouco fiável, e o erro aumenta com a dimensão; faça a contagem em código, com uma pergunta por candidato. O modelo compreende pior cores em hex ou RGB do que nomes de cores. score serve para definir um limiar, não para obter um número exato entre níveis.
3. Datas e horas. Determinar qual a data anterior, o intervalo entre datas ou se uma data pertence a um período é pouco fiável, sobretudo com formatos mistos e datas relativas. Extraia as partes da data através de choice, incluindo uma opção «não indicado», e compare-as em código.
4. Formulação indireta. Duplas negações e perguntas sobre uma propriedade de outra propriedade reduzem a exatidão. Escreva diretamente e identifique pelo nome as partes do estado.
5. Conteúdo supérfluo no estado. Texto alheio à tarefa reduz a exatidão. Filtre-o em código; quando isso não for possível, exclua o que não é relevante através de perguntas noul.
6. Texto hostil. Por predefinição, o modelo não espera armadilhas no estado: uma instrução injetada ou um texto que conteste a sua própria classificação pode alterar a resposta. Escreva critérios precisos e verifique casos limite antes de colocar o sistema em funcionamento.
7. Contradições. Se instructions e criteria pedirem coisas diferentes — por exemplo, se numa pergunta noul o «sim» for descrito como «não» —, a exatidão diminui. Os critérios são uma continuação da pergunta.
8. Ordem das opções. Por vezes, o modelo tende para a primeira opção choice. Altere a ordem das opções e verifique se a resposta se mantém.
9. Geração. O Jev não foi treinado para escrever texto. Para extrair dados, encontre candidatos com uma expressão regular ou um modelo generativo e deixe o Jev escolher o correto através de choice.