Construa com TypeSafe
TypeSafe torna unidades de inteligência de IA utilizáveis como primitivas de programação: pequenos julgamentos que podem ser compostos em capacidades maiores. Seus modelos Sistema Um retornam julgamentos rápidos e focados que o software pode consumir diretamente. Jev é o carro-chefe e primeiro modelo Sistema Um da TypeSafe. Ele entende linguagem natural e retorna respostas e probabilidades tipadas, em vez de gerar texto ou explicações de raciocínio. O código é o dono do fluxo de trabalho; o modelo fornece senso comum programável onde o código comum precisa de compreensão semântica.
Leia a documentação ao vivo
A documentação ao vivo da TypeSafe é a fonte da verdade. Leia-a como parte da tarefa. Esta habilidade fornece direcionamento; a documentação contém conceitos atuais, orientações de prompt, contratos de API, uso do SDK, modelos, limites e exemplos práticos.
- Comece pelo índice da documentação para descobrir páginas relevantes e cookbooks. Use leituras direcionadas em vez de carregar o site inteiro.
- O Mintlify serve Markdown anexando
.mdao caminho de uma página, por exemplo como construir com TypeSafe. Siga os links do índice; converta links de páginas de documentação sem extensão para.mdquando for útil. Resolva links relativos com base emhttps://docs.typesafe.ai. - Antes de escrever uma integração, leia a página atual da API ou do SDK escolhido e a orientação de pergunta relevante ao design. Para um novo fluxo de trabalho, inspecione também o cookbook mais próximo: ele geralmente mostra uma decomposição melhor do que um classificador genérico.
- Se o índice não estiver disponível, use os links diretos abaixo ou a navegação do site. Se a obtenção do Markdown falhar, tente a página normal. Se o acesso ao vivo não estiver disponível, use a documentação local disponível ou os tipos do SDK instalados, declare essa limitação e evite inventar detalhes dependentes de versão.
| Tarefa | Comece por aqui; siga os detalhes relevantes |
|---|---|
| Entender o modelo de programação | Sistema Um, guia de construção |
| Explorar o que construir | Mapa de casos de uso, depois cookbooks relevantes do índice |
| Preparar entradas e perguntas | Estado, primitivas, depois a página da primitiva escolhida |
| Decidir como lidar com incertezas | Confiança |
| Escrever código de API | API HTTP, SDK Python, ou SDK JavaScript |
| Atualizar uma integração antiga | Guia de migração e a referência atual do SDK instalado |
Encontre a forma útil
Comece pelo comportamento que o usuário deseja: o que o aplicativo mostrará, selecionará, alterará ou delegará? Trabalhe de trás para frente para os julgamentos de que necessita. Mantenha regras conhecidas, cálculos, consultas exatas e execução no código. Preserve a pilha e o escopo escolhidos pelo usuário; adicione TypeSafe onde a compreensão semântica ajuda.
Ao fazer brainstorming ou escolher uma arquitetura, considere mais do que classificação. Os padrões abaixo são pontos de partida: combine primitivas em torno do objetivo do usuário, incluindo ideias que não se encaixam em uma receita estabelecida.
- Roteie e preencha argumentos conhecidos. Uma solicitação pode selecionar um manipulador e seus parâmetros tipados. Faça perguntas específicas de ramificação úteis antecipadamente e consuma apenas as respostas relevantes. Explore chamada de função e fan-out especulativo.
- Selecione em vez de gerar. Encontre valores candidatos ou trechos de origem no código, use um julgamento para selecionar o pretendido, depois copie ou normalize-o. O código também pode montar texto de origem em um documento formatado ou guia de leitura. Explore extração de valor e recuperação de estrutura.
- Encontre e julgue evidências. Recupere candidatos, compare sua relevância para uma consulta e selecione contexto útil. Explore reordenamento e classificação hierárquica.
- Transforme julgamentos em dados reutilizáveis. Pontue dimensões uma vez, depois deixe que o código ou controles do usuário alterem pesos, limites, classificações e visualizações. Com resultados rotulados, esses sinais podem se tornar características clássicas de ML. Explore pontuação composta e descoberta de características.
- Verifique e escale. Verifique reivindicações ou campos específicos contra suas evidências; envie casos incertos ou com falha para uma pessoa ou modelo de raciocínio. Explore verificações de citação e cascatas de extração.
- Responda a mudanças de estado. O código pode reter objetivos e observações enquanto novos julgamentos guiam o próximo passo limitado. Mantenha o estado inferido distinto dos fatos observados e verifique a atualidade antes de aplicar um resultado a uma situação alterada.
Para solicitações abertas, ofereça as poucas direções que melhor atendam ao objetivo do usuário e recomende um ponto de partida. Para uma solicitação concreta, escolha o padrão relevante e construa; um brainstorming não é um desvio obrigatório.
Projete os julgamentos
Escolha pelo que a resposta significa, depois leia a página da primitiva relevante:
| Necessidade | Primitiva | Distinção importante |
|---|---|---|
| Um de um conjunto definido | Escolha | Seleciona uma opção; sua distribuição compara opções concorrentes |
| Se uma condição é verdadeira | Noul | Probabilidade de sim; sem confiança separada; use um por rótulo quando vários podem se aplicar |
| Grau ao longo de uma dimensão descrita | Pontuação | Posição ponderada por probabilidade em níveis ordenados; use Pontuações comparáveis por item para classificação graduada |
Dê a cada pergunta estado relevante suficiente para responder: texto de origem, identidades,
relacionamentos, políticas e fatos atuais. Prefira campos JSON nomeados quando o contexto
tiver várias partes. Coloque o julgamento nas instruções e defina suas respostas possíveis
nos critérios. IDs de pergunta são para código e não são enviados ao modelo;
inclua significado completo na pergunta. Referencie estado aninhado com caminhos entre crases,
como ticket.messages[0].text.
Faça um julgamento estreito e coerente por pergunta. Divida dimensões independentemente úteis, sem destruir o relacionamento que está sendo julgado. Uma seleção de ação limitada ou interpretação contextual é válida; atômico não significa extração literal de fato ou limite de uma frase. Strings funcionam para perguntas simples. Use objetos ou arrays estruturados quando definições, contrastes, exclusões ou exemplos esclarecem instruções ou critérios. Os níveis de Pontuação devem descrever situações concretas e ser autossuficientes.
Mantenha as respostas necessárias disponíveis. Inclua um resultado de não correspondência quando nada couber; use um julgamento de presença separado quando for independentemente útil. Para seleção de valor de origem, verifique a cobertura de candidatos: o modelo não pode escolher um valor omitido.
Componha e verifique
Faça perguntas independentes sobre o mesmo estado juntas, incluindo perguntas especulativas úteis. Elas são executadas em paralelo e não podem ver as respostas umas das outras. Declare cada premissa especulativa explicitamente; o código consome as respostas aplicáveis. Uma segunda solicitação é justificada quando uma resposta anterior é necessária para buscar evidências, construir novo estado ou determinar as próximas opções. Perguntas extras ainda usam tokens; meça orçamentos reais de requisição, custo e latência de ponta a ponta.
Use probabilidades e confiança para orientar o comportamento, com limites avaliados nos dados do usuário e consequências. A confiança de Escolha/Pontuação resume a concentração da distribuição, não a correção geral do fluxo de trabalho ou permissão para agir. Um Noul próximo de 0.5 significa probabilidade similar para sim e não, não intensidade média. Várias alternativas aceitáveis também podem espalhar probabilidade; baixa confiança não precisa invalidar uma escolha de preferência inofensiva. Ignore incerteza em ramos não utilizados.
Mantenha a política explícita e os julgamentos brutos reutilizáveis. Pontuações ponderadas são adequadas para preferências compensatórias; uma regra de "qualquer violação grave" precisa de condições separadas. Alterar um peso ou filtro de exibição não precisa reexecutar a inferência quando as evidências e os significados das perguntas não mudam. A saída tipada garante a interface, não a verdade. Modelos Sistema Um são treinados para decisões calibradas; valide seu desempenho no domínio alvo.
Teste casos representativos e o comportamento resultante do aplicativo. Para falhas, inspecione o estado exato, perguntas, candidatos, respostas, composição e resultado observado. Separe evidência faltante, erros do modelo, erros de código e falhas de serviço. Trate limites de cookbook e resultados de demonstração como exemplos para avaliar, não regras universais ou limitações permanentes do modelo. Mantenha credenciais de API no lado do servidor em aplicativos web.