O Kev-4B é um modelo de decisão compacto para responder a perguntas tipadas sobre um estado fornecido. O estado é o documento ou registo em avaliação, e cada pergunta define as opções que o modelo pode pontuar. O resultado é uma distribuição de probabilidades e um registo de decisão tipado, o que o torna útil para classificação de documentos, encaminhamento, triagem, escolhas de extração e verificações face a critérios enunciados.
O modelo combina uma arquitetura base Qwen3.5-4B-Base congelada com um adaptador LoRA e uma cabeça de apontador. A arquitetura base tem 32 camadas, compostas por 24 camadas Gated DeltaNet e oito camadas de atenção completa. O adaptador atua sobre as projeções de atenção, MLP e DeltaNet; a cabeça de apontador pontua as opções fornecidas e converte essas pontuações em probabilidades. Trata-se de um fluxo de decisão apenas com pré-preenchimento, em que as opções formam o espaço de respostas.
Podem surgir três tipos de pergunta no mesmo pedido. Uma pergunta de escolha aceita 1–255 opções nomeadas, opcionalmente com descrições, e devolve a opção mais provável, um valor de confiança separado e as probabilidades das opções. Uma pergunta de sim/não, designada noul no formato do fabricante, devolve a probabilidade de sim. Defina o significado de sim na pergunta, em vez de assumir que um número elevado significa sempre um resultado positivo para a aplicação.
Uma pergunta de pontuação ordenada aceita 1–255 níveis e devolve as probabilidades dos níveis e o respetivo índice esperado. Os índices dos níveis começam em zero. O formato de resultado do fabricante inclui também a legenda dos níveis e um valor de confiança separado. Um índice esperado pode ser fracionário: resume a distribuição pelos seus níveis ordenados, em vez de selecionar uma nova etiqueta textual. Mantenha a ordem e a legenda dos níveis com o resultado, para que uma classificação possa ser interpretada de forma coerente.
As perguntas partilham o mesmo estado, mas são avaliadas de forma independente. Uma pergunta não consegue ler a resposta de outra, e o estado é calculado uma vez e reutilizado. Se uma decisão posterior depender do resultado de uma decisão anterior, torne essa dependência explícita num estado subsequente, em vez de esperar que as perguntas de um pedido formem uma cadeia. Isto torna o fluxo de estado partilhado adequado para várias verificações independentes sobre o mesmo documento.
Prepare o estado com a evidência de que as perguntas realmente precisam. Pode ser texto simples ou um objeto ou matriz JSON apresentado como texto etiquetado. Mantenha claros os nomes dos campos, as unidades, as condições das políticas e os excertos de origem relevantes. Escreva uma instrução específica para cada pergunta e dê às suas opções significados que possam ser distinguidos a partir do registo. Numa tarefa original de encaminhamento de suporte, o estado pode conter o pedido e o respetivo contexto, enquanto as escolhas definem categorias de entrega, acesso e suporte ao produto com descrições curtas.
Uma segunda pergunta pode avaliar a urgência, e uma pergunta ordenada pode classificar o grau de acompanhamento de que o pedido necessita. Estas respondem a questões operacionais diferentes, por isso defina cada uma separadamente. Inclua uma opção adequada de revisão ou de evidência em falta quando a tarefa de escolha precisar dela, e conserve a distribuição completa quando várias categorias forem plausíveis. A aplicação decide como encaminhar ou rever um resultado; o modelo fornece o registo pontuado.
O Kev-4B destina-se a decisões tipadas sobre documentos de alguns milhares de tokens. O perfil de serviço do fabricante aceita estados até 65.536 tokens e reserva espaço adicional para cada pergunta, enquanto o comprimento de contexto validado para este ponto de verificação é de 8192 tokens. São limites diferentes: aceitar um estado mais longo não demonstra decisões igualmente fiáveis em todos os comprimentos. Mantenha compactos os excertos decisivos e preserve as respetivas etiquetas ao preparar um registo longo para classificação.
O perfil publicado é em inglês. As tarefas em que é útil dependem da evidência no estado fornecido e das opções definidas, e não de conversa aberta, resumo ou respostas baseadas em conhecimento geral. A aritmética de datas ao nível do dia é uma limitação específica: o fabricante disponibiliza um pré-processador separado de factos de datas que fornece intervalos calculados. Para verificar um prazo, inclua no estado as datas relevantes e os intervalos em dias calculados, juntamente com a regra que os utiliza.
O ponto de verificação inclui uma calibração de probabilidades ajustada, mas a confiança pode variar com o domínio do documento e o desenho da pergunta. O fabricante documenta também a afinação do ponto de verificação aberto com etiquetas específicas da tarefa e o ajuste da calibração de probabilidades a essa carga de trabalho; trata-se de um fluxo de personalização separado da pontuação de um estado fornecido. Escolha os limiares de decisão com exemplos etiquetados da carga de trabalho real e mantenha os casos incertos visíveis para revisão. O fabricante exclui decisões com consequências relevantes sobre pessoas que sejam totalmente automatizadas sem revisão humana. A ordem das opções também pode afetar uma resposta, por isso mantenha uma ordenação estável ao comparar resultados. Avalie a etiqueta escolhida, o campo de confiança separado e a distribuição de probabilidades de acordo com o papel que cada um desempenha no seu fluxo de trabalho.
A versão atual do Kev-4B descrita pelo fabricante pertence ao Kev 1.0 e utiliza a base Qwen3.5. As versões anteriores baseadas no Qwen3 e as versões apenas da fase de documentos continuam a ser versões distintas. Mantenha a edição escolhida e as definições das perguntas associadas às saídas ao desenvolver um fluxo específico para a tarefa, em vez de misturar resultados de perfis diferentes.
Um artefacto final útil é um conjunto nomeado de registos de decisão com as perguntas originais, as definições das opções, as distribuições e as eventuais legendas de níveis ordenados. Numa verificação da qualidade de respostas, o estado deve incluir a resposta proposta, a evidência e o critério a testar. Numa triagem de políticas, deve incluir a regra aplicável e os factos relevantes. Preserve essa entrada junto do resultado, para que uma revisão possa determinar por que razão uma decisão foi adequada ou que facto em falta tem de ser fornecido.
", "aboutText": "O Kev-4B é um modelo de decisão compacto para responder a perguntas tipadas sobre um estado fornecido. O estado é o documento ou registo em avaliação, e cada pergunta define as opções que o modelo pode pontuar. O resultado é uma distribuição de probabilidades e um registo de decisão tipado, o que o torna útil para classificação de documentos, encaminhamento, triagem, escolhas de extração e verificações face a critérios enunciados.\n\nO modelo combina uma arquitetura base Qwen3.5-4B-Base congelada com um adaptador LoRA e uma cabeça de apontador. A arquitetura base tem 32 camadas, compostas por 24 camadas Gated DeltaNet e oito camadas de atenção completa. O adaptador atua sobre as projeções de atenção, MLP e DeltaNet; a cabeça de apontador pontua as opções fornecidas e converte essas pontuações em probabilidades. Trata-se de um fluxo de decisão apenas com pré-preenchimento, em que as opções formam o espaço de respostas.\n\nPodem surgir três tipos de pergunta no mesmo pedido. Uma pergunta de escolha aceita 1–255 opções nomeadas, opcionalmente com descrições, e devolve a opção mais provável, um valor de confiança separado e as probabilidades das opções. Uma pergunta de sim/não, designada noul no formato do fabricante, devolve a probabilidade de sim. Defina o significado de sim na pergunta, em vez de assumir que um número elevado significa sempre um resultado positivo para a aplicação.\n\nUma pergunta de pontuação ordenada aceita 1–255 níveis e devolve as probabilidades dos níveis e o respetivo índice esperado. Os índices dos níveis começam em zero. O formato de resultado do fabricante inclui também a legenda dos níveis e um valor de confiança separado. Um índice esperado pode ser fracionário: resume a distribuição pelos seus níveis ordenados, em vez de selecionar uma nova etiqueta textual. Mantenha a ordem e a legenda dos níveis com o resultado, para que uma classificação possa ser interpretada de forma coerente.\n\nAs perguntas partilham o mesmo estado, mas são avaliadas de forma independente. Uma pergunta não consegue ler a resposta de outra, e o estado é calculado uma vez e reutilizado. Se uma decisão posterior depender do resultado de uma decisão anterior, torne essa dependência explícita num estado subsequente, em vez de esperar que as perguntas de um pedido formem uma cadeia. Isto torna o fluxo de estado partilhado adequado para várias verificações independentes sobre o mesmo documento.\n\nPrepare o estado com a evidência de que as perguntas realmente precisam. Pode ser texto simples ou um objeto ou matriz JSON apresentado como texto etiquetado. Mantenha claros os nomes dos campos, as unidades, as condições das políticas e os excertos de origem relevantes. Escreva uma instrução específica para cada pergunta e dê às suas opções significados que possam ser distinguidos a partir do registo. Numa tarefa original de encaminhamento de suporte, o estado pode conter o pedido e o respetivo contexto, enquanto as escolhas definem categorias de entrega, acesso e suporte ao produto com descrições curtas.\n\nUma segunda pergunta pode avaliar a urgência, e uma pergunta ordenada pode classificar o grau de acompanhamento de que o pedido necessita. Estas respondem a questões operacionais diferentes, por isso defina cada uma separadamente. Inclua uma opção adequada de revisão ou de evidência em falta quando a tarefa de escolha precisar dela, e conserve a distribuição completa quando várias categorias forem plausíveis. A aplicação decide como encaminhar ou rever um resultado; o modelo fornece o registo pontuado.\n\nO Kev-4B destina-se a decisões tipadas sobre documentos de alguns milhares de tokens. O perfil de serviço do fabricante aceita estados até 65.536 tokens e reserva espaço adicional para cada pergunta, enquanto o comprimento de contexto validado para este ponto de verificação é de 8192 tokens. São limites diferentes: aceitar um estado mais longo não demonstra decisões igualmente fiáveis em todos os comprimentos. Mantenha compactos os excertos decisivos e preserve as respetivas etiquetas ao preparar um registo longo para classificação.\n\nO perfil publicado é em inglês. As tarefas em que é útil dependem da evidência no estado fornecido e das opções definidas, e não de conversa aberta, resumo ou respostas baseadas em conhecimento geral. A aritmética de datas ao nível do dia é uma limitação específica: o fabricante disponibiliza um pré-processador separado de factos de datas que fornece intervalos calculados. Para verificar um prazo, inclua no estado as datas relevantes e os intervalos em dias calculados, juntamente com a regra que os utiliza.\n\nO ponto de verificação inclui uma calibração de probabilidades ajustada, mas a confiança pode variar com o domínio do documento e o desenho da pergunta. O fabricante documenta também a afinação do ponto de verificação aberto com etiquetas específicas da tarefa e o ajuste da calibração de probabilidades a essa carga de trabalho; trata-se de um fluxo de personalização separado da pontuação de um estado fornecido. Escolha os limiares de decisão com exemplos etiquetados da carga de trabalho real e mantenha os casos incertos visíveis para revisão. O fabricante exclui decisões com consequências relevantes sobre pessoas que sejam totalmente automatizadas sem revisão humana. A ordem das opções também pode afetar uma resposta, por isso mantenha uma ordenação estável ao comparar resultados. Avalie a etiqueta escolhida, o campo de confiança separado e a distribuição de probabilidades de acordo com o papel que cada um desempenha no seu fluxo de trabalho.\n\nA versão atual do Kev-4B descrita pelo fabricante pertence ao Kev 1.0 e utiliza a base Qwen3.5. As versões anteriores baseadas no Qwen3 e as versões apenas da fase de documentos continuam a ser versões distintas. Mantenha a edição escolhida e as definições das perguntas associadas às saídas ao desenvolver um fluxo específico para a tarefa, em vez de misturar resultados de perfis diferentes.\n\nUm artefacto final útil é um conjunto nomeado de registos de decisão com as perguntas originais, as definições das opções, as distribuições e as eventuais legendas de níveis ordenados. Numa verificação da qualidade de respostas, o estado deve incluir a resposta proposta, a evidência e o critério a testar. Numa triagem de políticas, deve incluir a regra aplicável e os factos relevantes. Preserve essa entrada junto do resultado, para que uma revisão possa determinar por que razão uma decisão foi adequada ou que facto em falta tem de ser fornecido.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "70b28ddab318d5ddf709a0d84cfdc32c85f86e1d79f733e53d5f0aa98f9e15ee", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "pt-pt", "methods": [ { "html": "jaredpalmer/kev-4bO Kev-4B pontua perguntas tipadas sobre um documento em inglês fornecido e devolve probabilidades calibradas sobre as opções que definir. Utilize perguntas de sim/não, de escolha e de pontuação ordenada para classificação, encaminhamento, triagem e verificações que precisam de uma decisão estruturada em vez de texto gerado.
Esta descrição apresenta as capacidades do modelo. As entradas, saídas e opções disponíveis no Ailoot para o método selecionado estão indicadas abaixo.
O Kev-4B é um modelo de decisão compacto para responder a perguntas tipadas sobre um estado fornecido. O estado é o documento ou registo em avaliação, e cada pergunta define as opções que o modelo pode pontuar. O resultado é uma distribuição de probabilidades e um registo de decisão tipado, o que o torna útil para classificação de documentos, encaminhamento, triagem, escolhas de extração e verificações face a critérios enunciados.
O modelo combina uma arquitetura base Qwen3.5-4B-Base congelada com um adaptador LoRA e uma cabeça de apontador. A arquitetura base tem 32 camadas, compostas por 24 camadas Gated DeltaNet e oito camadas de atenção completa. O adaptador atua sobre as projeções de atenção, MLP e DeltaNet; a cabeça de apontador pontua as opções fornecidas e converte essas pontuações em probabilidades. Trata-se de um fluxo de decisão apenas com pré-preenchimento, em que as opções formam o espaço de respostas.
Podem surgir três tipos de pergunta no mesmo pedido. Uma pergunta de escolha aceita 1–255 opções nomeadas, opcionalmente com descrições, e devolve a opção mais provável, um valor de confiança separado e as probabilidades das opções. Uma pergunta de sim/não, designada noul no formato do fabricante, devolve a probabilidade de sim. Defina o significado de sim na pergunta, em vez de assumir que um número elevado significa sempre um resultado positivo para a aplicação.
Uma pergunta de pontuação ordenada aceita 1–255 níveis e devolve as probabilidades dos níveis e o respetivo índice esperado. Os índices dos níveis começam em zero. O formato de resultado do fabricante inclui também a legenda dos níveis e um valor de confiança separado. Um índice esperado pode ser fracionário: resume a distribuição pelos seus níveis ordenados, em vez de selecionar uma nova etiqueta textual. Mantenha a ordem e a legenda dos níveis com o resultado, para que uma classificação possa ser interpretada de forma coerente.
As perguntas partilham o mesmo estado, mas são avaliadas de forma independente. Uma pergunta não consegue ler a resposta de outra, e o estado é calculado uma vez e reutilizado. Se uma decisão posterior depender do resultado de uma decisão anterior, torne essa dependência explícita num estado subsequente, em vez de esperar que as perguntas de um pedido formem uma cadeia. Isto torna o fluxo de estado partilhado adequado para várias verificações independentes sobre o mesmo documento.
Prepare o estado com a evidência de que as perguntas realmente precisam. Pode ser texto simples ou um objeto ou matriz JSON apresentado como texto etiquetado. Mantenha claros os nomes dos campos, as unidades, as condições das políticas e os excertos de origem relevantes. Escreva uma instrução específica para cada pergunta e dê às suas opções significados que possam ser distinguidos a partir do registo. Numa tarefa original de encaminhamento de suporte, o estado pode conter o pedido e o respetivo contexto, enquanto as escolhas definem categorias de entrega, acesso e suporte ao produto com descrições curtas.
Uma segunda pergunta pode avaliar a urgência, e uma pergunta ordenada pode classificar o grau de acompanhamento de que o pedido necessita. Estas respondem a questões operacionais diferentes, por isso defina cada uma separadamente. Inclua uma opção adequada de revisão ou de evidência em falta quando a tarefa de escolha precisar dela, e conserve a distribuição completa quando várias categorias forem plausíveis. A aplicação decide como encaminhar ou rever um resultado; o modelo fornece o registo pontuado.
O Kev-4B destina-se a decisões tipadas sobre documentos de alguns milhares de tokens. O perfil de serviço do fabricante aceita estados até 65.536 tokens e reserva espaço adicional para cada pergunta, enquanto o comprimento de contexto validado para este ponto de verificação é de 8192 tokens. São limites diferentes: aceitar um estado mais longo não demonstra decisões igualmente fiáveis em todos os comprimentos. Mantenha compactos os excertos decisivos e preserve as respetivas etiquetas ao preparar um registo longo para classificação.
O perfil publicado é em inglês. As tarefas em que é útil dependem da evidência no estado fornecido e das opções definidas, e não de conversa aberta, resumo ou respostas baseadas em conhecimento geral. A aritmética de datas ao nível do dia é uma limitação específica: o fabricante disponibiliza um pré-processador separado de factos de datas que fornece intervalos calculados. Para verificar um prazo, inclua no estado as datas relevantes e os intervalos em dias calculados, juntamente com a regra que os utiliza.
O ponto de verificação inclui uma calibração de probabilidades ajustada, mas a confiança pode variar com o domínio do documento e o desenho da pergunta. O fabricante documenta também a afinação do ponto de verificação aberto com etiquetas específicas da tarefa e o ajuste da calibração de probabilidades a essa carga de trabalho; trata-se de um fluxo de personalização separado da pontuação de um estado fornecido. Escolha os limiares de decisão com exemplos etiquetados da carga de trabalho real e mantenha os casos incertos visíveis para revisão. O fabricante exclui decisões com consequências relevantes sobre pessoas que sejam totalmente automatizadas sem revisão humana. A ordem das opções também pode afetar uma resposta, por isso mantenha uma ordenação estável ao comparar resultados. Avalie a etiqueta escolhida, o campo de confiança separado e a distribuição de probabilidades de acordo com o papel que cada um desempenha no seu fluxo de trabalho.
A versão atual do Kev-4B descrita pelo fabricante pertence ao Kev 1.0 e utiliza a base Qwen3.5. As versões anteriores baseadas no Qwen3 e as versões apenas da fase de documentos continuam a ser versões distintas. Mantenha a edição escolhida e as definições das perguntas associadas às saídas ao desenvolver um fluxo específico para a tarefa, em vez de misturar resultados de perfis diferentes.
Um artefacto final útil é um conjunto nomeado de registos de decisão com as perguntas originais, as definições das opções, as distribuições e as eventuais legendas de níveis ordenados. Numa verificação da qualidade de respostas, o estado deve incluir a resposta proposta, a evidência e o critério a testar. Numa triagem de políticas, deve incluir a regra aplicável e os factos relevantes. Preserve essa entrada junto do resultado, para que uma revisão possa determinar por que razão uma decisão foi adequada ou que facto em falta tem de ser fornecido.
POST /v1/systemonetextdecisions| Campo | Tipo | Requisito | Valores e limites | Predefinição |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObrigatório | Valores e limites jaredpalmer/kev-4b | Predefinição— |
Campoprovider | Tiposchema | RequisitoOpcional | Valores e limites | Predefinição— |
Campoquestions | Tipoobject | RequisitoObrigatório | Valores e limites | Predefinição— |
Camposession_id | Tipostring | RequisitoOpcional | Valores e limites | Predefinição— |
Campostate | Tiposchema | RequisitoObrigatório | Valores e limites | Predefinição— |
Campotrace | Tiposchema | RequisitoOpcional | Valores e limites | Predefinição— |
Campouser | Tipostring | RequisitoOpcional | Valores e limites | Predefinição— |
Campoquestions.<id>.type | Tipostring | RequisitoObrigatório | Valores e limites noul, choice, score | Predefinição— |
Campoquestions.<id>.instructions | Tipostring|object|array | RequisitoObrigatório | Valores e limites | Predefinição— |
Campoquestions.<id>.criteria | Tipoobject|array | RequisitoOpcional | Valores e limites Condições: choice/score: obrigatório; noul: opcional. Os critérios de choice são um objeto; score é uma matriz com minItems1. | Predefinição— |
Campoquestions.<id>.criteria.true | Tipostring|object|array | RequisitoObrigatório | Valores e limites Aplica-se quando: Objeto de critérios noul fornecido | Predefinição— |
Campoquestions.<id>.criteria.false | Tipostring|object|array | RequisitoObrigatório | Valores e limites Aplica-se quando: Objeto de critérios noul fornecido | Predefinição— |
noul · Obrigatório: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Obrigatório: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Obrigatório: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parâmetro | Contrato |
|---|---|
Parâmetrocontent_type | Contratoapplication/json |
Parâmetrorequired | Contratomodel, state, questions |
Parâmetromaterial_types | Contratotext |
Parâmetrooptional_controls | Contratoprovider, session_id, trace, user |
Parâmetromultimodal_input_binding | Contratonull |
Ciclo de vida: synchronous
Envie o ID exato do modelo e conserve a resposta nativa completa.
As referências tarifárias não acrescentam opções ao pedido. Os parâmetros suportados constam do método selecionado.
Associe cada custo às condições apresentadas. Use uma única tarifa para cada conjunto de configurações alternativas.
| Configuração | Tabela de tarifas | Tokens de contexto, mais de | Tokens de contexto, até ao limite inclusive | Custo |
|---|---|---|---|---|
| ConfiguraçãoTarifas base dos tokens | Tabela de tarifasTarifa base | Tokens de contexto, mais de— | Tokens de contexto, até ao limite inclusiveSem limite superior | Custo Entrada · Tokens de entrada $0.000084 / 1K tokens Saída · Tokens de saída $0 / 1K tokens Entrada · Leitura da cache — / 1K tokens Entrada · Escrita na cache — / 1K tokens Entrada · Escrita na cache, 1 hora — / 1K tokens |
| ConfiguraçãoEscalão 1 por comprimento do pedido | Tabela de tarifas— | Tokens de contexto, mais de0 | Tokens de contexto, até ao limite inclusiveSem limite superior | Custo Entrada · Tokens de entrada $0.000084 / 1K tokens Saída · Tokens de saída $0 / 1K tokens Entrada · Leitura da cache — / 1K tokens Entrada · Escrita na cache — / 1K tokens Entrada · Escrita na cache, 1 hora — / 1K tokens |
O Ailoot reserva um montante estimado antes de um pedido. Após o resultado, liquida o custo final com base na utilização medida. No streaming, a liquidação usa o registo final de utilização. Como funcionam a reserva e a liquidação →
{\n "model": "jaredpalmer/kev-4b",\n "questions": {\n "is_bug": {\n "criteria": {\n "false": "The customer is asking a question or requesting a feature.",\n "true": "The customer describes broken or unexpected product behavior."\n },\n "instructions": "Is the customer reporting a software defect?",\n "type": "noul"\n },\n "team": {\n "criteria": {\n "account": "Login, permissions, or profile issues.",\n "frontend": "Rendering, layout, or browser compatibility issues.",\n "payments": "Checkout, billing, or payment processing issues."\n },\n "instructions": "Which team should own this ticket?",\n "type": "choice"\n },\n "urgency": {\n "criteria": [\n "Can wait for the next release",\n "Should be fixed this week",\n "Blocking revenue right now"\n ],\n "instructions": "How urgent is this ticket?",\n "type": "score"\n }\n },\n "state": {\n "customer_tier": "enterprise",\n "ticket": "My checkout page shows a blank screen after I click Pay. I have tried two browsers."\n }\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='jaredpalmer/kev-4b'\nPath('request.json').write_text(json.dumps(p,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/systemone \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
Guarde cada resposta, ficheiro e parte de conteúdo devolvidos na íntegra.
É conservada cada resposta fornecida a um ID de pergunta, com o respetivo tipo exato, valor noul/choice/score, confiança, probabilidades e legenda. O JSON original completo é armazenado e devolvido apenas após a liquidação.
Conserve a operação original e a resposta completa/parcial; não repita o POST.
| Campo | Tipo |
|---|---|
Campomodel | Tipostring |
Campoid | Tipostring |
Campoprovider | Tipostring |
Campoanswers.<id>.type | Tipostring |
Campoanswers.<id>.noul | Tiponumber |
Campoanswers.<id>.choice | Tipostring |
Campoanswers.<id>.score | Tiponumber |
Campoanswers.<id>.confidence | Tiponumber |
Campoanswers.<id>.probabilities | Tipoobject |
Campoanswers.<id>.legend | Tipoobject |
Campousage.input_tokens | Tipointeger |
Campousage.output_tokens | Tipointeger |
Campousage.cost | Tiponumber |
| Resposta | Condição | Passo seguinte |
|---|---|---|
Resposta400 · invalid_request_error | CondiçãoCampo obrigatório, representação ou valor inválido | Passo seguinteCorrija o campo indicado no pedido. |
Ailoot Ultra jaredpalmer/kev-4b
Use os caminhos dos métodos indicados acima.