Irregularidades do Jev 1.13

O Jev não é perfeito. Eis algumas arestas irregulares de que temos conhecimento no jev-1.13. Muitas serão corrigidas em versões posteriores.

O jev-1.13 é rápido, calibrado e bom em julgamentos de senso comum, mas não é perfeito. O jev-1.13 é melhor em tarefas de System One. Pode ter dificuldades com tarefas que exigem níveis adicionais de indireção. Pode ser bastante literal na sua compreensão. Tem dificuldades com tarefas que exigem precisão numérica.

Os modos de falha em detalhe

Leitura literal

O jev-1.13 responde à pergunta que escreveste, não à que querias. Palavras de âmbito, negações e condições implícitas são lidas à letra. Uma pergunta será respondida com base nas palavras escritas na instrução, ao passo que uma pessoa poderia ter lido a intenção por trás das instruções.

Em vez disso: indica a condição exata no instructions. Sê específico. Coloca os casos-limite nos criteria. Quando olhares para uma resposta errada e te apanhares a explicar o que realmente querias dizer, essa explicação é a metade que falta da instrução. Onde a interpretação for inevitável, divide-a em duas perguntas literais e combina-as em código.

Matemática e números

O Jev não é uma calculadora. Recomendamos vivamente que implementes qualquer lógica matemática em código. O Jev terá um desempenho melhor em perguntas semânticas do que em perguntas matemáticas.

Contar

O jev-1.13 não conta de forma fiável. Isto abrange carateres numa palavra, ocorrências de um termo numa passagem e itens numa lista longa. O modelo reconhece a forma de uma resposta em vez de contar, e o erro cresce com o tamanho da coisa que está a ser contada.

Antes de fazer uma pergunta de contagem, pergunta por que razão a contagem precisa sequer de um modelo. Se a unidade for algo que uma expressão regular ou um parser conseguem encontrar, a contagem pertence ao código e o modelo não tem nada a acrescentar.

Em vez disso: conta em código. Quando quiseres contar itens que correspondem a certos criteria, itera em código sobre os candidatos e faz uma pergunta por cada um, depois soma tu mesmo as respostas.

from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient(model="jev-1.13")
YES = 0.5  # up to you on what you want the threshold to be, depends on your usecase.

items = ["typesafe", "apple", "california", "banana", "likes", "calibration", "orange", "vertex"]

result = client.system_one(
    {"items": items},
    {
        f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?")
        for i in range(len(items))
    },
)

count = sum(result.nouls[f"item_{i}"].noul > YES for i in range(len(items)))

Representações numéricas

O jev-1.13 terá um desempenho melhor em representações semânticas do que em numéricas. Por exemplo, perguntas sobre cores com valores hexadecimais terão pior desempenho do que as que usam os nomes em inglês. Dados triplos RGB ou valores hexadecimais, não consegue julgar de forma fiável se dois valores estão próximos um do outro.

Do mesmo modo, perguntas sobre linguagens de programação de alto nível terão melhor desempenho do que perguntas sobre assembly de baixo nível ou instruções codificadas em binário.

Em vez disso: faz a conversão em código e passa o número calculado ou um intervalo nomeado. Guarda o modelo para a parte que é genuinamente um julgamento, como se uma cor se lê como um aviso.

Matemática com score

Não uses os resultados de score (por exemplo, expetativas e probabilidade) para calcular a magnitude exata de um número entre dois níveis de um critério. Podes usar a expetativa para verificar se passa um determinado limiar, mas os níveis de score do jev-1.13 são fracos em calibração numérica. Não te conseguirá ajudar a reconstruir o número exato por interpolação entre os dois níveis mais próximos.

Comparação de datas e horas

O jev-1.13 lê as datas como texto, não como quantidades ordenadas. Perguntar qual de duas datas vem primeiro, a que distância estão, ou se uma cai dentro de uma janela, não é fiável. Piora com formatos mistos, referências relativas e fronteiras de domínio como trimestres, janelas de liquidação e períodos de acumulação.

Em vez disso: divide o trabalho. A extração é um julgamento, por isso dá-a ao modelo. A aritmética não é, por isso mantém-na no código.

Cada parte de uma data é um pequeno conjunto fechado: doze meses, trinta e um dias possíveis, um intervalo limitado de anos. Isso transforma a extração num Choice sobre opções enumeradas em vez de análise de forma livre, e dá-te um lugar para colocar uma opção explícita “não indicado”, para que uma parte em falta seja comunicada em vez de adivinhada. O código junta as partes numa data real e é dono de tudo o que vem depois, incluindo ordenação, duração, deslocamento e dia da semana.

O cookbook de extração de datas tem a versão desenvolvida, incluindo datas relativas e gating por confiança.

Indireção

Instruções com duplas negações ou indireção complexa são respondidas com menos fiabilidade. Uma pergunta sobre uma propriedade de uma propriedade, ou algo que exige vários saltos de raciocínio, custa precisão.

Em vez disso: escreve as tuas instruções o mais diretamente possível. Quando possível, identifica as partes relevantes do estado pelo nome.

Estado grande cheio de detalhes irrelevantes

A precisão cai à medida que o estado cresce com conteúdo não relacionado com a decisão. Os detalhes não relacionados funcionam como distratores, e um estado grande torna mais difícil perceber que parte da entrada produziu uma resposta errada.

Em vez disso: recupera e filtra primeiro em código, e envia apenas os campos de que a pergunta precisa. Quando não for possível filtrar no estado, podes usar um Noul para filtrar por relevância. O cookbook de classificação de passagens de RAG tem um exemplo desenvolvido.

Conteúdo adversário

O estado é dados, e o jev-1.13 não o trata como hostil por predefinição. Conteúdo escrito para dirigir o modelo de forma adversária, seja uma instrução injetada, um enquadramento deliberadamente enganador ou texto que argumenta a favor da sua própria classificação, pode mover a resposta. Esperamos melhorar isto no futuro.

Em vez disso: sê explícito nos criteria. Testa a tua integração minuciosamente antes de a implementar para muitos utilizadores.

Instruções e criteria contraditórios

Quando o instructions e os criteria pedem coisas diferentes, o jev-1.13 pode ficar confuso. O melhor desempenho vem de uma formulação clara. Por exemplo, um Noul em que true corresponde a não e false corresponde a sim terá pior desempenho. Procura instruções que sejam fáceis de ler e compreender para uma pessoa comum.

Em vez disso: trata os criteria como uma extensão da instrução. Alinha os dois com uma linguagem clara e precisa.

Ordem das opções de um Choice

Em alguns casos, observámos que a ordem das opções de um Choice pode afetar a resposta, e o jev-1.13 tende para a opção que vem primeiro.

Em vez disso: reordena as opções para verificar se a resposta permanece consistente.

Geração

O jev-1.13 não é treinado para gerar texto. Embora possas forçá-lo a fazê-lo encadeando choices, isso não funcionará bem e será muito lento. Para extração de dados, é melhor extrair as opções possíveis usando regex ou um modelo generativo e deixar o jev-1.13 escolher a extração correta.

Em vez disso: quando o espaço de respostas é limitado, transforma a extração num Choice sobre as opções em vez de pedires o valor em si. Se realmente precisares de gerar texto… há outros modelos para isso.