O Drex 1.5 é o modelo de decisão sobre texto da Nace.AI. Avalia factos fornecidos face a perguntas fechadas e devolve respostas numéricas e tipadas, em vez de uma resposta escrita aberta. Um pedido combina um estado com perguntas nomeadas, e o resultado identifica cada resposta com o mesmo nome da pergunta. Isto dá a um fluxo de trabalho uma categoria, uma probabilidade ou uma posição numa rubrica concretas para utilizar, deixando à aplicação a ação a tomar com base nesse resultado.
O estado é a informação a que todas as perguntas dizem respeito. O Drex aceita uma cadeia de caracteres, um objeto, uma matriz, um número, um valor booleano ou null em JSON, sendo o campo state obrigatório. Forneça evidência com significado, mesmo que null passe na validação do produtor. Uma cadeia de caracteres adequa-se a uma mensagem, um documento ou uma transcrição; um objeto adequa-se a factos já organizados em campos. Conserve a informação que afeta a decisão e omita campos não relacionados quando o material for extenso. Mantenha um formato de entrada estável ao interpretar limiares de probabilidade, porque alterar a representação pode alterar a resposta.
O Drex 1.5 lê apenas texto. A interface documentada rejeita conteúdo de imagem, áudio, vídeo e PDF tanto no estado como nas perguntas, incluindo multimédia codificada e objetos de conteúdo multimédia. Prepare uma legenda, o texto reconhecido de um documento ou uma transcrição antes de utilizar esse material como evidência. Um endereço em texto não é um documento ou imagem obtido: o modelo não o consegue abrir. Para um pedido de suporte, o estado útil é a mensagem real e o contexto relevante, e não uma referência a material que o modelo não recebeu.
Uma pergunta noul pergunta se uma condição se verifica e devolve um número de 0 a 1 que representa a probabilidade estimada de sim. Defina a pergunta através de instruções não vazias ou de pelo menos um critério verdadeiro/falso não vazio. Por exemplo, pergunte se uma mensagem comunica uma funcionalidade avariada e defina se um comportamento lento conta como avaria. O Drex não impõe um ponto de corte de sim/não incorporado; o fluxo de trabalho que consome o resultado escolhe como interpretar a probabilidade.
Uma pergunta de escolha seleciona uma etiqueta fornecida a partir de um conjunto não ordenado e devolve uma probabilidade para cada etiqueta. Os critérios são um objeto cujas chaves são as etiquetas devolvidas, sendo cada descrição uma cadeia de caracteres ou null. Utilize chaves curtas e estáveis e descreva com clareza os limites entre categorias. Uma tarefa ilustrativa de encaminhamento pode distinguir um problema de acesso, um defeito do produto e uma pergunta geral, com uma categoria «outro» para as mensagens que não se enquadram. A etiqueta selecionada é útil para o encaminhamento; a distribuição ajuda a identificar casos em que duas opções continuam difíceis de separar.
Uma pergunta de pontuação utiliza uma matriz ordenada de etiquetas de nível. Os índices começam em 0, e a pontuação devolvida é a soma do índice de cada nível multiplicado pela respetiva probabilidade. Pode, portanto, ficar entre níveis nomeados. Para uma escala de gravidade, defina o que separa um problema estético, um problema com solução alternativa e uma tarefa totalmente bloqueada. O resultado inclui a legenda dos níveis e as probabilidades, bem como a pontuação esperada. Conserve a pontuação fracionária para médias ou tendências; selecionar o nível mais provável e arredondar a pontuação esperada respondem a perguntas diferentes.
O produtor permite de uma a 512 perguntas sobre o mesmo estado. Dê a cada uma um identificador não vazio e com significado, como category ou severity, para que a resposta correspondente possa ser compreendida sem consultar uma pergunta numerada. Separe as questões independentes em perguntas próprias, em vez de combinar vários requisitos num único critério pouco claro. Uma única mensagem pode suportar uma escolha de categoria, uma pontuação de gravidade e uma verificação de condição, cada uma com o seu próprio significado.
As respostas de escolha e de pontuação incluem a confiança separadamente das respetivas distribuições de probabilidade. O produtor distingue explicitamente a confiança da probabilidade da opção mais alta; não calcule uma a partir da outra. Numa decisão de sim/não, conserve a probabilidade em bruto com o resultado escolhido. Numa escolha incerta, inspecione as probabilidades concorrentes em vez de tratar apenas a etiqueta vencedora como prova de certeza. Defina limiares de revisão em função das consequências de um resultado positivo ou negativo errado e utilize casos etiquetados representativos para os avaliar.
O Drex 1.5 documenta um limite de 131.072 tokens para o estado e de 139.264 tokens por linha. O limite por linha diz respeito ao estado mais a pergunta individual mais longa, incluindo as respetivas instruções e opções; não é a soma de todas as perguntas do pedido. O estado e as perguntas serializados também têm de caber, em conjunto, em 1.048.576 bytes UTF-8. Um pedido pode cumprir o limite de bytes e, ainda assim, exceder um limite de tokens. A edição 1.0, mais antiga, indica separadamente 32.768 tokens tanto para o estado como para a linha, pelo que os seus limites não devem ser transpostos para a 1.5.
A Nace documenta drex-v1.5 como um identificador de versão do produtor, enquanto drex-latest é um nome alternativo móvel. Mantenha explícita a edição pretendida quando um fluxo de trabalho depender dos seus limites. Uma pergunta malformada, um estado em falta ou uma entrada demasiado grande são problemas de validação que exigem uma entrada corrigida, e não uma categoria alterada ou uma resposta adivinhada. Prepare os critérios em torno de evidência observável e mantenha juntos o resultado tipado, os factos originais e a definição da pergunta. Isso torna a decisão utilizável para encaminhamento, priorização ou revisão, sem confundir uma probabilidade com um veredicto garantido.
", "aboutText": "O Drex 1.5 é o modelo de decisão sobre texto da Nace.AI. Avalia factos fornecidos face a perguntas fechadas e devolve respostas numéricas e tipadas, em vez de uma resposta escrita aberta. Um pedido combina um estado com perguntas nomeadas, e o resultado identifica cada resposta com o mesmo nome da pergunta. Isto dá a um fluxo de trabalho uma categoria, uma probabilidade ou uma posição numa rubrica concretas para utilizar, deixando à aplicação a ação a tomar com base nesse resultado.\n\n### Preparar o estado\n\nO estado é a informação a que todas as perguntas dizem respeito. O Drex aceita uma cadeia de caracteres, um objeto, uma matriz, um número, um valor booleano ou null em JSON, sendo o campo state obrigatório. Forneça evidência com significado, mesmo que null passe na validação do produtor. Uma cadeia de caracteres adequa-se a uma mensagem, um documento ou uma transcrição; um objeto adequa-se a factos já organizados em campos. Conserve a informação que afeta a decisão e omita campos não relacionados quando o material for extenso. Mantenha um formato de entrada estável ao interpretar limiares de probabilidade, porque alterar a representação pode alterar a resposta.\n\nO Drex 1.5 lê apenas texto. A interface documentada rejeita conteúdo de imagem, áudio, vídeo e PDF tanto no estado como nas perguntas, incluindo multimédia codificada e objetos de conteúdo multimédia. Prepare uma legenda, o texto reconhecido de um documento ou uma transcrição antes de utilizar esse material como evidência. Um endereço em texto não é um documento ou imagem obtido: o modelo não o consegue abrir. Para um pedido de suporte, o estado útil é a mensagem real e o contexto relevante, e não uma referência a material que o modelo não recebeu.\n\n### Probabilidade de sim/não, escolha ou pontuação\n\nUma pergunta noul pergunta se uma condição se verifica e devolve um número de 0 a 1 que representa a probabilidade estimada de sim. Defina a pergunta através de instruções não vazias ou de pelo menos um critério verdadeiro/falso não vazio. Por exemplo, pergunte se uma mensagem comunica uma funcionalidade avariada e defina se um comportamento lento conta como avaria. O Drex não impõe um ponto de corte de sim/não incorporado; o fluxo de trabalho que consome o resultado escolhe como interpretar a probabilidade.\n\nUma pergunta de escolha seleciona uma etiqueta fornecida a partir de um conjunto não ordenado e devolve uma probabilidade para cada etiqueta. Os critérios são um objeto cujas chaves são as etiquetas devolvidas, sendo cada descrição uma cadeia de caracteres ou null. Utilize chaves curtas e estáveis e descreva com clareza os limites entre categorias. Uma tarefa ilustrativa de encaminhamento pode distinguir um problema de acesso, um defeito do produto e uma pergunta geral, com uma categoria «outro» para as mensagens que não se enquadram. A etiqueta selecionada é útil para o encaminhamento; a distribuição ajuda a identificar casos em que duas opções continuam difíceis de separar.\n\nUma pergunta de pontuação utiliza uma matriz ordenada de etiquetas de nível. Os índices começam em 0, e a pontuação devolvida é a soma do índice de cada nível multiplicado pela respetiva probabilidade. Pode, portanto, ficar entre níveis nomeados. Para uma escala de gravidade, defina o que separa um problema estético, um problema com solução alternativa e uma tarefa totalmente bloqueada. O resultado inclui a legenda dos níveis e as probabilidades, bem como a pontuação esperada. Conserve a pontuação fracionária para médias ou tendências; selecionar o nível mais provável e arredondar a pontuação esperada respondem a perguntas diferentes.\n\n### Evidência partilhada e leitura do resultado\n\nO produtor permite de uma a 512 perguntas sobre o mesmo estado. Dê a cada uma um identificador não vazio e com significado, como category ou severity, para que a resposta correspondente possa ser compreendida sem consultar uma pergunta numerada. Separe as questões independentes em perguntas próprias, em vez de combinar vários requisitos num único critério pouco claro. Uma única mensagem pode suportar uma escolha de categoria, uma pontuação de gravidade e uma verificação de condição, cada uma com o seu próprio significado.\n\nAs respostas de escolha e de pontuação incluem a confiança separadamente das respetivas distribuições de probabilidade. O produtor distingue explicitamente a confiança da probabilidade da opção mais alta; não calcule uma a partir da outra. Numa decisão de sim/não, conserve a probabilidade em bruto com o resultado escolhido. Numa escolha incerta, inspecione as probabilidades concorrentes em vez de tratar apenas a etiqueta vencedora como prova de certeza. Defina limiares de revisão em função das consequências de um resultado positivo ou negativo errado e utilize casos etiquetados representativos para os avaliar.\n\n### Versão e limites de tamanho\n\nO Drex 1.5 documenta um limite de 131.072 tokens para o estado e de 139.264 tokens por linha. O limite por linha diz respeito ao estado mais a pergunta individual mais longa, incluindo as respetivas instruções e opções; não é a soma de todas as perguntas do pedido. O estado e as perguntas serializados também têm de caber, em conjunto, em 1.048.576 bytes UTF-8. Um pedido pode cumprir o limite de bytes e, ainda assim, exceder um limite de tokens. A edição 1.0, mais antiga, indica separadamente 32.768 tokens tanto para o estado como para a linha, pelo que os seus limites não devem ser transpostos para a 1.5.\n\nA Nace documenta drex-v1.5 como um identificador de versão do produtor, enquanto drex-latest é um nome alternativo móvel. Mantenha explícita a edição pretendida quando um fluxo de trabalho depender dos seus limites. Uma pergunta malformada, um estado em falta ou uma entrada demasiado grande são problemas de validação que exigem uma entrada corrigida, e não uma categoria alterada ou uma resposta adivinhada. Prepare os critérios em torno de evidência observável e mantenha juntos o resultado tipado, os factos originais e a definição da pergunta. Isso torna a decisão utilizável para encaminhamento, priorização ou revisão, sem confundir uma probabilidade com um veredicto garantido.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "780ef1d567be6dd4c68dc2c92639b323501399f864f5a44335e49348a8ee0fd0", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "pt-pt", "methods": [ { "html": "nace-ai/drex-v1.5O Drex 1.5 avalia texto ou JSON fornecido face a perguntas tipadas e devolve probabilidades, uma etiqueta escolhida ou uma pontuação fracionária numa rubrica. A Nace.AI documenta decisões apenas sobre texto para classificação, encaminhamento e priorização, com limites de estado e de pedido específicos de cada versão.
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 Drex 1.5 é o modelo de decisão sobre texto da Nace.AI. Avalia factos fornecidos face a perguntas fechadas e devolve respostas numéricas e tipadas, em vez de uma resposta escrita aberta. Um pedido combina um estado com perguntas nomeadas, e o resultado identifica cada resposta com o mesmo nome da pergunta. Isto dá a um fluxo de trabalho uma categoria, uma probabilidade ou uma posição numa rubrica concretas para utilizar, deixando à aplicação a ação a tomar com base nesse resultado.
O estado é a informação a que todas as perguntas dizem respeito. O Drex aceita uma cadeia de caracteres, um objeto, uma matriz, um número, um valor booleano ou null em JSON, sendo o campo state obrigatório. Forneça evidência com significado, mesmo que null passe na validação do produtor. Uma cadeia de caracteres adequa-se a uma mensagem, um documento ou uma transcrição; um objeto adequa-se a factos já organizados em campos. Conserve a informação que afeta a decisão e omita campos não relacionados quando o material for extenso. Mantenha um formato de entrada estável ao interpretar limiares de probabilidade, porque alterar a representação pode alterar a resposta.
O Drex 1.5 lê apenas texto. A interface documentada rejeita conteúdo de imagem, áudio, vídeo e PDF tanto no estado como nas perguntas, incluindo multimédia codificada e objetos de conteúdo multimédia. Prepare uma legenda, o texto reconhecido de um documento ou uma transcrição antes de utilizar esse material como evidência. Um endereço em texto não é um documento ou imagem obtido: o modelo não o consegue abrir. Para um pedido de suporte, o estado útil é a mensagem real e o contexto relevante, e não uma referência a material que o modelo não recebeu.
Uma pergunta noul pergunta se uma condição se verifica e devolve um número de 0 a 1 que representa a probabilidade estimada de sim. Defina a pergunta através de instruções não vazias ou de pelo menos um critério verdadeiro/falso não vazio. Por exemplo, pergunte se uma mensagem comunica uma funcionalidade avariada e defina se um comportamento lento conta como avaria. O Drex não impõe um ponto de corte de sim/não incorporado; o fluxo de trabalho que consome o resultado escolhe como interpretar a probabilidade.
Uma pergunta de escolha seleciona uma etiqueta fornecida a partir de um conjunto não ordenado e devolve uma probabilidade para cada etiqueta. Os critérios são um objeto cujas chaves são as etiquetas devolvidas, sendo cada descrição uma cadeia de caracteres ou null. Utilize chaves curtas e estáveis e descreva com clareza os limites entre categorias. Uma tarefa ilustrativa de encaminhamento pode distinguir um problema de acesso, um defeito do produto e uma pergunta geral, com uma categoria «outro» para as mensagens que não se enquadram. A etiqueta selecionada é útil para o encaminhamento; a distribuição ajuda a identificar casos em que duas opções continuam difíceis de separar.
Uma pergunta de pontuação utiliza uma matriz ordenada de etiquetas de nível. Os índices começam em 0, e a pontuação devolvida é a soma do índice de cada nível multiplicado pela respetiva probabilidade. Pode, portanto, ficar entre níveis nomeados. Para uma escala de gravidade, defina o que separa um problema estético, um problema com solução alternativa e uma tarefa totalmente bloqueada. O resultado inclui a legenda dos níveis e as probabilidades, bem como a pontuação esperada. Conserve a pontuação fracionária para médias ou tendências; selecionar o nível mais provável e arredondar a pontuação esperada respondem a perguntas diferentes.
O produtor permite de uma a 512 perguntas sobre o mesmo estado. Dê a cada uma um identificador não vazio e com significado, como category ou severity, para que a resposta correspondente possa ser compreendida sem consultar uma pergunta numerada. Separe as questões independentes em perguntas próprias, em vez de combinar vários requisitos num único critério pouco claro. Uma única mensagem pode suportar uma escolha de categoria, uma pontuação de gravidade e uma verificação de condição, cada uma com o seu próprio significado.
As respostas de escolha e de pontuação incluem a confiança separadamente das respetivas distribuições de probabilidade. O produtor distingue explicitamente a confiança da probabilidade da opção mais alta; não calcule uma a partir da outra. Numa decisão de sim/não, conserve a probabilidade em bruto com o resultado escolhido. Numa escolha incerta, inspecione as probabilidades concorrentes em vez de tratar apenas a etiqueta vencedora como prova de certeza. Defina limiares de revisão em função das consequências de um resultado positivo ou negativo errado e utilize casos etiquetados representativos para os avaliar.
O Drex 1.5 documenta um limite de 131.072 tokens para o estado e de 139.264 tokens por linha. O limite por linha diz respeito ao estado mais a pergunta individual mais longa, incluindo as respetivas instruções e opções; não é a soma de todas as perguntas do pedido. O estado e as perguntas serializados também têm de caber, em conjunto, em 1.048.576 bytes UTF-8. Um pedido pode cumprir o limite de bytes e, ainda assim, exceder um limite de tokens. A edição 1.0, mais antiga, indica separadamente 32.768 tokens tanto para o estado como para a linha, pelo que os seus limites não devem ser transpostos para a 1.5.
A Nace documenta drex-v1.5 como um identificador de versão do produtor, enquanto drex-latest é um nome alternativo móvel. Mantenha explícita a edição pretendida quando um fluxo de trabalho depender dos seus limites. Uma pergunta malformada, um estado em falta ou uma entrada demasiado grande são problemas de validação que exigem uma entrada corrigida, e não uma categoria alterada ou uma resposta adivinhada. Prepare os critérios em torno de evidência observável e mantenha juntos o resultado tipado, os factos originais e a definição da pergunta. Isso torna a decisão utilizável para encaminhamento, priorização ou revisão, sem confundir uma probabilidade com um veredicto garantido.
POST /v1/systemonetextdecisions| Campo | Tipo | Requisito | Valores e limites | Predefinição |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObrigatório | Valores e limites nace-ai/drex-v1.5 | 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.00008 / 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.00008 / 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": "nace-ai/drex-v1.5",\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']='nace-ai/drex-v1.5'\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 nace-ai/drex-v1.5
Use os caminhos dos métodos indicados acima.