JSON dentro de instructions e criteria

Um hábito que vem do trabalho com LLMs é serializar tudo em texto: pegar o schema, o registro ou a taxonomia e colar dentro de uma frase longa. Com o Jev isso é desnecessário. Os campos que descrevem uma pergunta aceitam JSON, e a documentação diz que os modelos System One são treinados para entender estrutura.

Onde a estrutura é aceita

Repare no que não está na lista: o state também aceita objeto e lista, mas por outro motivo — ele é o conteúdo avaliado, e o formato dele é assunto de state.

Quando vale estruturar

A documentação dá duas razões, e as duas são boas critérios de decisão.

Quando ajuda na clareza. Uma pergunta com várias partes fica mais legível em JSON, porque as chaves rotulam cada parte. “Compare o nome da organização citada com o domínio do e-mail, olhando para estes dois campos” vira um objeto com question, compare e focus.

Quando a pergunta precisa de dados de apoio. Um schema, uma taxonomia ou uma linha de banco já é JSON. Passe o JSON, ou os subcampos relevantes, em vez de transformá-lo em texto com um gabarito.

E a contra-regra, que vem da página de Score: comece com strings. Estrutura é a resposta para um problema concreto, não um padrão de qualidade.

instructions estruturada

O exemplo oficial descreve um campo a ser verificado uma vez e reutiliza a mesma forma em perguntas de tipos diferentes:

{
  "type": "noul",
  "instructions": {
    "field": {
      "name": "invoice_number",
      "type": "string",
      "description": "The identifier printed on the invoice."
    },
    "extracted_value": "4471",
    "question": "Does `extracted_value` match the `field` as it appears in `source_text`?"
  }
}

Em código, dá para percorrer os campos de um registro e montar uma pergunta por campo, todas na mesma chamada. É exatamente o que o cookbook de cascata faz para verificar uma extração, e o desenho está em cascata de extração.

Lista também funciona, quando a instrução é uma lista de coisas a comparar:

{
  "question": "Does the claimed sender identity conflict with the sending domain?",
  "compare": ["ticket.sender.display_name", "ticket.sender.email"],
  "focus": "Compare the named organization with the email domain."
}

Opção de Choice como objeto

Aqui a estrutura resolve um problema real: marcar a fronteira entre opções que se confundem.

"criteria": {
  "billing": {
    "what": "Cobranças, faturas, estornos ou assinaturas",
    "not_for": "Rastreio de pedido ou acesso à conta",
    "examples": ["Fui cobrado duas vezes", "Cadê meu estorno?"]
  },
  "orders": {
    "what": "Status do pedido, entrega, cancelamento ou devolução",
    "not_for": "Cobranças ou acesso à conta",
    "examples": ["Cadê meu pacote?", "Cancelar meu pedido"]
  }
}

O campo not_for é a parte mais útil: dizer o que a opção não cobre afia a fronteira mais do que alongar o que ela cobre. Esse é o assunto de critérios que separam.

Subárvore de taxonomia como descrição

Esta é a técnica mais interessante da página oficial. Para classificar em uma taxonomia profunda, faça uma pergunta por nível e caminhe a árvore em código — e, em cada passo, o valor de cada opção é a subárvore daquele ramo.

"criteria": {
  "Sporting Goods": {
    "Cycling": ["Bike Bottles & Cages", "Bike Lights", "Helmets"],
    "Outdoor": ["Tents", "Sleeping Bags", "Hydration Packs"]
  },
  "Home & Kitchen": {
    "Drinkware": ["Water Bottles", "Travel Mugs", "Tumblers"]
  }
}

O exemplo oficial usa uma garrafa de 32 onças com bico e encaixe para bicicleta: ela cabe plausivelmente em dois departamentos. Mostrar as subárvores permite ao modelo ver que existem tanto Sporting Goods > Cycling > Bike Bottles & Cages quanto Home & Kitchen > Drinkware > Water Bottles, e pesar a ênfase do anúncio. As probabilidades da resposta dizem se vale explorar os dois ramos.

O aviso oficial que acompanha: subárvores crescem. Se um ramo ficar grande demais, corte o valor para os filhos diretos e uma amostra de folhas. A travessia completa, com vários caminhos vivos, está em beam search hierárquico.

Nível de Score como objeto

Um nível pode ser um resumo mais os sinais que o caracterizam:

"criteria": [
  {
    "summary": "Uma mudança só, claramente descrita",
    "signals": ["Uma correção ou funcionalidade", "Nada descrito como 'aproveitei e'"]
  },
  {
    "summary": "Uma mudança principal e um ajuste pequeno relacionado",
    "signals": ["Uma alteração principal e um retoque adjacente"]
  }
]

Como cada nível é avaliado sozinho contra o state, dar sinais concretos ajuda mais que adjetivar. A mecânica está em níveis de Score.

criteria de Noul estruturado

Quando a fronteira entre sim e não é sutil, definir os dois lados com exemplos é o que fixa o corte:

"criteria": {
  "true": {
    "what": "Pede que a pessoa responda com, digite ou envie senha, PIN ou código de uso único",
    "examples": ["Responda com sua senha", "Envie o código de 6 dígitos"]
  },
  "false": {
    "what": "Nenhuma credencial sensível é pedida",
    "examples": ["Redefina sua senha nas configurações", "Seu extrato está pronto"]
  }
}

A diferença entre “pedir a credencial” e “pedir para trocar a credencial” é o tipo de distinção que uma frase solta erra e um par de exemplos acerta.

O custo disso

Estrutura deixa a pergunta maior, e pergunta maior custa tokens. Só que a pergunta é a parte barata: quem domina o custo é o state, como mostrado em economizar tokens de entrada. Trocar alguns centésimos de centavo por uma fronteira bem marcada costuma ser um bom negócio.

O índice das três primitivas está em primitivas.