O que você precisa saber
Jev é apresentado pela TypeSafe como um modelo para decisões não generativas: recebe um estado e produz resultados por primitivas como Choice, Score e Noul. Não generativo não significa sem contexto. O estado descreve a situação; a aplicação continua responsável por fontes, permissões e execução.
Corrigindo a ideia de IA 'não contextual'
Uma decisão depende de informações sobre a situação. Na documentação da TypeSafe, state é a representação desse contexto de decisão. Ela pode incluir dados estruturados e texto relevante. Portanto, chamar Jev de 'IA não contextual' confunde o mecanismo. A diferença proposta é decidir dentro de saídas delimitadas, sem produzir uma resposta textual livre como etapa central.
O nome System One identifica a abordagem do fornecedor. Não é uma classificação universal de todos os sistemas de IA nem uma garantia de qualidade. Especificações, versões, idiomas e limitações precisam ser verificadas na documentação vigente antes de uma integração. Este guia explica critérios de avaliação; não anuncia integração ativa nos produtos Genial.
Saída tipada reduz uma classe de problemas
Um Choice pode representar a escolha entre alternativas fornecidas pela aplicação; Score representa avaliação segundo a primitiva disponível; Noul permite formular perguntas com resultados definidos pelo fornecedor. Receber um valor delimitado evita interpretar um texto arbitrário para descobrir qual ação foi sugerida. Ainda é possível escolher a alternativa errada.
O fluxo correto tem quatro contratos
Primeiro, a aplicação monta um estado com dados autorizados e atuais. Segundo, define a pergunta e as alternativas válidas. Terceiro, valida a saída recebida, considerando versão, formato e critério de aceitação. Quarto, um executor aplica regras de negócio antes de realizar qualquer mudança. A decisão do modelo não deve assumir o papel de uma permissão.
Exemplo hipotético: o modelo sugere 'agendar' a partir da mensagem de uma família. O executor ainda precisa confirmar identidade, unidade, disponibilidade e autorização. Se essas informações faltam, a saída é revisão ou esclarecimento. Uma escolha válida de catálogo não torna um horário disponível nem confirma o consentimento de alguém.
Estados possíveis de falha
Resultado malformado, alternativa desconhecida, serviço indisponível ou evidência insuficiente devem seguir uma saída segura, como needs_review. Esse estado precisa ser parte do fluxo real, com dono e forma de continuidade. A aplicação não deve converter uma falha técnica na primeira opção do catálogo.
Para continuar este critério: Machine learning: o que é, como aprende e quando usar →
Confiança depende da definição e da calibração
Uma pontuação de confiança não é prova de verdade. Em uma definição documentada para Choice, a confiança transforma a probabilidade máxima considerando a chance uniforme entre n escolhas: (pmax − 1/n)/(1 − 1/n). Com três escolhas e pmax de 0,90, o resultado desse cálculo é 0,85. Ele não significa que a ação está autorizada ou que 85% de todos os casos futuros serão corretos.
As definições não devem ser transferidas automaticamente entre primitivas. Uma probabilidade para uma pergunta Noul e uma confiança normalizada para Choice representam contratos distintos. Registre a definição, a versão, o limiar e os casos usados na avaliação. Se os números forem usados para priorizar revisão, teste também sua calibração no público e no idioma da aplicação.
Limiar acompanha a consequência
Classificar um conteúdo para revisão tem um custo de erro diferente de acionar uma mudança financeira. Um limiar único para todos os fluxos costuma esconder esse contraste. Defina custo de falso positivo, falso negativo, abstenção e latência por tarefa, e compare com regras ou classificadores alternativos.
Quando testar Jev e quando preferir outro mecanismo
A abordagem pode ser candidata quando as alternativas são finitas, a tarefa se repete, a saída precisa ser simples e existe um conjunto de avaliação. Extração livre de documentos complexos, redação extensa e síntese com muitas fontes podem exigir outros modelos. Cálculos exatos, saldos e regras invariáveis devem ser resolvidos por lógica ou consulta oficial, não por uma preferência estatística.
Um pipeline pode usar LLM para extrair candidatos, Jev ou outro classificador para uma decisão, regras para validação e um executor para a ação. Esse desenho só vale a complexidade adicional se melhorar a tarefa medida. Mais modelos significam também mais versões, pontos de falha, custos e necessidade de observabilidade.
Evite empacotar várias decisões numa pergunta ambígua
Se urgência, intenção e permissão são perguntas diferentes, represente-as separadamente quando apropriado. Uma categoria 'agendar urgente autorizado' mistura dimensões e dificulta descobrir por que o modelo falhou. A decomposição permite testar cada resultado; o executor combina os critérios segundo regras explícitas.
Avaliação antes da integração
Prepare mensagens reais autorizadas ou casos representativos, incluindo português, abreviações, negativas, campos incompletos e números. A documentação do modelo deve ser consultada para limitações por idioma e tipos de tarefa. Uma alegação de robustez do fornecedor não substitui testes adversariais e de distribuição próprios.
Compare com o procedimento atual e uma alternativa simples. Meça matriz de confusão, cobertura, abstenção, custo e tempo de revisão. Separe avaliação da escolha de avaliação da execução: o modelo pode acertar a intenção e o sistema ainda alterar a unidade errada. Registre evidência de estado final sem copiar dados privados para relatórios públicos.
Contrato mínimo de aceite
Somente alternativas conhecidas, nenhum acesso inferido pelo modelo, falha com revisão, testes de idioma e versão registrados, ações idempotentes e limites de custo. Se um desses controles não existe, a saída tipada ainda não está pronta para autonomia operacional.
