Irregularidades do Jev 1.13

O Jev não é perfeito. Estas são algumas arestas irregulares que conhecemos no jev-1.13. Muitas serão corrigidas em versões futuras.

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

Os modos de falha em detalhe

Leitura literal

O jev-1.13 responde à pergunta que você escreveu, não à que você quis dizer. Palavras de escopo, negações e condições implícitas são lidas ao pé da letra. Uma pergunta será respondida com base nas palavras escritas na instrução, enquanto uma pessoa poderia ter lido a intenção por trás das instruções.

Em vez disso: indique a condição exata nas instructions. Seja específico. Coloque os casos limítrofes nos criteria. Quando você olhar uma resposta errada e se pegar explicando o que realmente quis dizer, essa explicação é a metade que falta da instrução. Onde a interpretação for inevitável, divida-a em duas perguntas literais e combine-as no código.

Matemática e números

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

Contagem

O jev-1.13 não conta de forma confiável. Isso abrange caracteres de uma palavra, ocorrências de um termo num trecho e itens de uma lista longa. O modelo reconhece a forma de uma resposta em vez de contá-los um a um, e o erro cresce com o tamanho da coisa que está sendo contada.

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

Em vez disso: conte no código. Quando quiser contar itens que correspondem a certos criteria, itere no código sobre os candidatos e faça uma pergunta para cada um, depois some você 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 com representações semânticas do que numéricas. Por exemplo, perguntas sobre cores que usam valores hexadecimais terão desempenho pior que as que usam os nomes em inglês. Dados trios RGB ou valores hexadecimais, ele não consegue julgar de forma confiável se dois valores estão próximos um do outro.

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

Em vez disso: faça a conversão no código e passe o número calculado ou um grupo nomeado. Reserve o modelo para a parte que é genuinamente um julgamento, como se uma cor é lida como um alerta.

Matemática usando score

Não use as saídas de score (por exemplo, expectativas e probabilidade) para calcular a magnitude exata de um número entre dois níveis de um critério. Você pode usar a expectativa para verificar se ele passa de um determinado limiar, mas os níveis de score do jev-1.13 são fracos em calibração numérica. Ele não conseguirá ajudá-lo a reconstruir o número exato interpolando entre os dois níveis mais próximos.

Comparação de datas e horas

O jev-1.13 lê datas como texto, não como quantidades ordenadas. Perguntar qual de duas datas vem primeiro, qual a distância entre elas, ou se uma cai dentro de uma janela não é confiável. Fica pior com formatos mistos, referências relativas e limites de domínio como trimestres, janelas de liquidação e períodos de competência.

Em vez disso: divida o trabalho. A extração é um julgamento, então dê-a ao modelo. A aritmética não é, então mantenha-a 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á a você um lugar para colocar uma opção explícita de “não informado”, para que uma parte ausente seja relatada em vez de adivinhada. O código monta as partes numa data real e cuida de tudo depois disso, incluindo ordenação, duração, fuso e dia da semana.

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

Indireção

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

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

Estado grande cheio de detalhes irrelevantes

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

Em vez disso: recupere e filtre no código primeiro, e envie só os campos que a pergunta precisa. Quando não for possível filtrar no estado, você pode usar um Noul para filtrar por relevância. O cookbook de classificação de trechos RAG tem um exemplo resolvido.

Conteúdo adversário

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

Em vez disso: seja explícito nos criteria. Teste sua integração a fundo antes de implantá-la para muitos usuários.

Instruções e criteria contraditórios

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

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

Ordem das opções de um Choice

Em alguns casos, observamos 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: reordene as opções para verificar se a resposta permanece consistente.

Geração

O jev-1.13 não é treinado para gerar texto. Embora você possa forçá-lo a isso 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, transforme a extração num Choice sobre as opções, em vez de pedir o valor em si. Se você realmente precisar gerar texto… há outros modelos para isso.