Kev-4B es un modelo compacto de decisión para responder a preguntas de tipos definidos sobre un estado proporcionado. El estado es el documento o registro que se evalúa, y cada pregunta define las opciones que el modelo puede puntuar. Su resultado es una distribución de probabilidades y un registro de decisión de tipo definido, lo que lo hace útil para clasificación de documentos, asignación, triaje, elecciones de extracción y comprobaciones frente a criterios establecidos.
El modelo combina una arquitectura base congelada Qwen3.5-4B-Base con un adaptador LoRA y un cabezal de puntero. La arquitectura base tiene 32 capas, compuestas por 24 capas Gated DeltaNet y ocho capas de atención completa. El adaptador actúa sobre proyecciones de atención, MLP y DeltaNet; el cabezal de puntero puntúa las opciones proporcionadas y convierte esas puntuaciones en probabilidades. Este es un flujo de decisión que utiliza únicamente la fase prefill, con las opciones como espacio de respuestas.
Los tres tipos de pregunta pueden aparecer en la misma solicitud. Una pregunta choice acepta entre 1 y 255 opciones con nombre, opcionalmente con descripciones, y devuelve la opción más probable, un valor de confianza separado y las probabilidades de las opciones. Una pregunta de sí/no, llamada noul en el formato del fabricante, devuelve la probabilidad de sí. Define el significado de sí en la pregunta, en lugar de suponer que un número alto siempre implica un resultado positivo para la aplicación.
Una pregunta de puntuación ordenada acepta entre 1 y 255 niveles y devuelve las probabilidades de los niveles y su índice esperado. Los índices de nivel comienzan en cero. El formato de resultado del fabricante también contiene la leyenda de niveles y un valor de confianza separado. Un índice esperado puede ser fraccionario: resume la distribución entre tus niveles ordenados, en lugar de seleccionar una nueva etiqueta textual. Conserva el orden y la leyenda de los niveles junto con el resultado, para que una valoración pueda interpretarse de forma coherente.
Las preguntas comparten el mismo estado, pero se evalúan de forma independiente. Una pregunta no puede leer la respuesta de otra, y el estado se calcula una vez y se reutiliza. Si una decisión posterior depende del resultado de una decisión anterior, haz explícita esa dependencia en un estado posterior, en lugar de esperar que las preguntas de una solicitud formen una cadena. Esto hace que el flujo con estado compartido sea adecuado para varias comprobaciones independientes sobre el mismo documento.
Prepara el estado con la evidencia que realmente requieran las preguntas. Puede ser texto sin formato o un objeto o array JSON representado como texto etiquetado. Mantén claros los nombres de campos, las unidades, las condiciones de las políticas y los pasajes pertinentes de las fuentes. Escribe una instrucción específica para cada pregunta y da a sus opciones significados que puedan distinguirse a partir del registro. Para una tarea original de asignación de soporte, el estado puede contener la solicitud y su contexto, mientras que las opciones definen categorías de entrega, acceso y soporte del producto con descripciones cortas.
Una segunda pregunta puede evaluar la urgencia, y una pregunta ordenada puede valorar cuánto seguimiento necesita la solicitud. Responden a cuestiones operativas distintas, así que define cada una por separado. Incluye una opción adecuada de revisión o falta de evidencia cuando la tarea de elección la necesite y conserva la distribución completa cuando varias categorías sean plausibles. La aplicación decide cómo asignar o revisar un resultado; el modelo proporciona el registro puntuado.
Kev-4B está destinado a decisiones de tipos definidos sobre documentos de unos pocos miles de tokens. El perfil de servicio de su fabricante acepta estados de hasta 65,536 tokens y reserva espacio adicional para cada pregunta, mientras que la longitud de contexto validada para este checkpoint es de 8192 tokens. Son límites distintos: aceptar un estado más largo no establece decisiones igual de fiables a cualquier longitud. Mantén compactos los pasajes decisivos y conserva sus etiquetas al preparar un registro largo para clasificación.
El perfil publicado está en inglés. Sus tareas útiles dependen de la evidencia del estado proporcionado y de las opciones definidas, en lugar de chat abierto, resúmenes o respuestas amplias basadas en conocimientos. La aritmética de fechas a nivel de días es una limitación específica: el fabricante proporciona un preprocesador separado de datos de fechas que suministra intervalos calculados. Para comprobar un plazo, incluye en el estado las fechas pertinentes y los intervalos de días calculados, junto con la regla que los utiliza.
El checkpoint se distribuye con una calibración de probabilidades ajustada, pero la confianza puede cambiar con el dominio del documento y el diseño de las preguntas. El fabricante también documenta el ajuste del checkpoint abierto con etiquetas específicas de la tarea y la adaptación de su calibración de probabilidades a esa carga de trabajo; este es un flujo de personalización separado de la puntuación de un estado proporcionado. Elige los umbrales de decisión utilizando ejemplos etiquetados de la carga real y mantén visibles los casos inciertos para revisión. El fabricante excluye las decisiones con consecuencias para personas totalmente automatizadas sin revisión humana. El orden de las opciones también puede afectar a una respuesta, por lo que conviene mantenerlo estable al comparar resultados. Evalúa la etiqueta elegida, el campo separado de confianza y la distribución de probabilidades según el papel de cada uno en tu flujo de trabajo.
La edición actual de Kev-4B descrita por el fabricante pertenece a Kev 1.0 y utiliza la base Qwen3.5. Las ediciones anteriores basadas en Qwen3 y las que solo operaban en la etapa de documento siguen siendo versiones distintas. Mantén la edición elegida y las definiciones de preguntas asociadas a las salidas al desarrollar un flujo específico de la tarea, en lugar de mezclar resultados de perfiles diferentes.
Un artefacto final útil es un conjunto con nombre de registros de decisión con las preguntas originales, las definiciones de opciones, las distribuciones y las leyendas de niveles ordenados que corresponda. Para comprobar la calidad de una respuesta, el estado debe incluir la respuesta propuesta, la evidencia y el criterio que se evalúa. Para el triaje de políticas, debe incluir la regla aplicable y los hechos pertinentes. Conserva esa entrada junto al resultado para que una revisión pueda establecer por qué una decisión fue adecuada o qué hecho ausente se debe aportar.
", "aboutText": "Kev-4B es un modelo compacto de decisión para responder a preguntas de tipos definidos sobre un estado proporcionado. El estado es el documento o registro que se evalúa, y cada pregunta define las opciones que el modelo puede puntuar. Su resultado es una distribución de probabilidades y un registro de decisión de tipo definido, lo que lo hace útil para clasificación de documentos, asignación, triaje, elecciones de extracción y comprobaciones frente a criterios establecidos.\n\nEl modelo combina una arquitectura base congelada Qwen3.5-4B-Base con un adaptador LoRA y un cabezal de puntero. La arquitectura base tiene 32 capas, compuestas por 24 capas Gated DeltaNet y ocho capas de atención completa. El adaptador actúa sobre proyecciones de atención, MLP y DeltaNet; el cabezal de puntero puntúa las opciones proporcionadas y convierte esas puntuaciones en probabilidades. Este es un flujo de decisión que utiliza únicamente la fase prefill, con las opciones como espacio de respuestas.\n\nLos tres tipos de pregunta pueden aparecer en la misma solicitud. Una pregunta choice acepta entre 1 y 255 opciones con nombre, opcionalmente con descripciones, y devuelve la opción más probable, un valor de confianza separado y las probabilidades de las opciones. Una pregunta de sí/no, llamada noul en el formato del fabricante, devuelve la probabilidad de sí. Define el significado de sí en la pregunta, en lugar de suponer que un número alto siempre implica un resultado positivo para la aplicación.\n\nUna pregunta de puntuación ordenada acepta entre 1 y 255 niveles y devuelve las probabilidades de los niveles y su índice esperado. Los índices de nivel comienzan en cero. El formato de resultado del fabricante también contiene la leyenda de niveles y un valor de confianza separado. Un índice esperado puede ser fraccionario: resume la distribución entre tus niveles ordenados, en lugar de seleccionar una nueva etiqueta textual. Conserva el orden y la leyenda de los niveles junto con el resultado, para que una valoración pueda interpretarse de forma coherente.\n\nLas preguntas comparten el mismo estado, pero se evalúan de forma independiente. Una pregunta no puede leer la respuesta de otra, y el estado se calcula una vez y se reutiliza. Si una decisión posterior depende del resultado de una decisión anterior, haz explícita esa dependencia en un estado posterior, en lugar de esperar que las preguntas de una solicitud formen una cadena. Esto hace que el flujo con estado compartido sea adecuado para varias comprobaciones independientes sobre el mismo documento.\n\nPrepara el estado con la evidencia que realmente requieran las preguntas. Puede ser texto sin formato o un objeto o array JSON representado como texto etiquetado. Mantén claros los nombres de campos, las unidades, las condiciones de las políticas y los pasajes pertinentes de las fuentes. Escribe una instrucción específica para cada pregunta y da a sus opciones significados que puedan distinguirse a partir del registro. Para una tarea original de asignación de soporte, el estado puede contener la solicitud y su contexto, mientras que las opciones definen categorías de entrega, acceso y soporte del producto con descripciones cortas.\n\nUna segunda pregunta puede evaluar la urgencia, y una pregunta ordenada puede valorar cuánto seguimiento necesita la solicitud. Responden a cuestiones operativas distintas, así que define cada una por separado. Incluye una opción adecuada de revisión o falta de evidencia cuando la tarea de elección la necesite y conserva la distribución completa cuando varias categorías sean plausibles. La aplicación decide cómo asignar o revisar un resultado; el modelo proporciona el registro puntuado.\n\nKev-4B está destinado a decisiones de tipos definidos sobre documentos de unos pocos miles de tokens. El perfil de servicio de su fabricante acepta estados de hasta 65,536 tokens y reserva espacio adicional para cada pregunta, mientras que la longitud de contexto validada para este checkpoint es de 8192 tokens. Son límites distintos: aceptar un estado más largo no establece decisiones igual de fiables a cualquier longitud. Mantén compactos los pasajes decisivos y conserva sus etiquetas al preparar un registro largo para clasificación.\n\nEl perfil publicado está en inglés. Sus tareas útiles dependen de la evidencia del estado proporcionado y de las opciones definidas, en lugar de chat abierto, resúmenes o respuestas amplias basadas en conocimientos. La aritmética de fechas a nivel de días es una limitación específica: el fabricante proporciona un preprocesador separado de datos de fechas que suministra intervalos calculados. Para comprobar un plazo, incluye en el estado las fechas pertinentes y los intervalos de días calculados, junto con la regla que los utiliza.\n\nEl checkpoint se distribuye con una calibración de probabilidades ajustada, pero la confianza puede cambiar con el dominio del documento y el diseño de las preguntas. El fabricante también documenta el ajuste del checkpoint abierto con etiquetas específicas de la tarea y la adaptación de su calibración de probabilidades a esa carga de trabajo; este es un flujo de personalización separado de la puntuación de un estado proporcionado. Elige los umbrales de decisión utilizando ejemplos etiquetados de la carga real y mantén visibles los casos inciertos para revisión. El fabricante excluye las decisiones con consecuencias para personas totalmente automatizadas sin revisión humana. El orden de las opciones también puede afectar a una respuesta, por lo que conviene mantenerlo estable al comparar resultados. Evalúa la etiqueta elegida, el campo separado de confianza y la distribución de probabilidades según el papel de cada uno en tu flujo de trabajo.\n\nLa edición actual de Kev-4B descrita por el fabricante pertenece a Kev 1.0 y utiliza la base Qwen3.5. Las ediciones anteriores basadas en Qwen3 y las que solo operaban en la etapa de documento siguen siendo versiones distintas. Mantén la edición elegida y las definiciones de preguntas asociadas a las salidas al desarrollar un flujo específico de la tarea, en lugar de mezclar resultados de perfiles diferentes.\n\nUn artefacto final útil es un conjunto con nombre de registros de decisión con las preguntas originales, las definiciones de opciones, las distribuciones y las leyendas de niveles ordenados que corresponda. Para comprobar la calidad de una respuesta, el estado debe incluir la respuesta propuesta, la evidencia y el criterio que se evalúa. Para el triaje de políticas, debe incluir la regla aplicable y los hechos pertinentes. Conserva esa entrada junto al resultado para que una revisión pueda establecer por qué una decisión fue adecuada o qué hecho ausente se debe aportar.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "2aea8a5bfb3c6b3c6a968f88705d27afa7662840188e3a1c36d904cfd18170b4", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "es-mx", "methods": [ { "html": "jaredpalmer/kev-4bKev-4B puntúa preguntas de tipos definidos sobre un documento en inglés proporcionado y devuelve probabilidades calibradas entre las opciones que definas. Utiliza preguntas de sí/no, elección y puntuación ordenada para clasificación, asignación, triaje y comprobaciones que necesiten una decisión estructurada en lugar de prosa generada.
Esta descripción cubre las capacidades del modelo. Las entradas, salidas y opciones disponibles en Ailoot se indican a continuación para el método seleccionado.
Kev-4B es un modelo compacto de decisión para responder a preguntas de tipos definidos sobre un estado proporcionado. El estado es el documento o registro que se evalúa, y cada pregunta define las opciones que el modelo puede puntuar. Su resultado es una distribución de probabilidades y un registro de decisión de tipo definido, lo que lo hace útil para clasificación de documentos, asignación, triaje, elecciones de extracción y comprobaciones frente a criterios establecidos.
El modelo combina una arquitectura base congelada Qwen3.5-4B-Base con un adaptador LoRA y un cabezal de puntero. La arquitectura base tiene 32 capas, compuestas por 24 capas Gated DeltaNet y ocho capas de atención completa. El adaptador actúa sobre proyecciones de atención, MLP y DeltaNet; el cabezal de puntero puntúa las opciones proporcionadas y convierte esas puntuaciones en probabilidades. Este es un flujo de decisión que utiliza únicamente la fase prefill, con las opciones como espacio de respuestas.
Los tres tipos de pregunta pueden aparecer en la misma solicitud. Una pregunta choice acepta entre 1 y 255 opciones con nombre, opcionalmente con descripciones, y devuelve la opción más probable, un valor de confianza separado y las probabilidades de las opciones. Una pregunta de sí/no, llamada noul en el formato del fabricante, devuelve la probabilidad de sí. Define el significado de sí en la pregunta, en lugar de suponer que un número alto siempre implica un resultado positivo para la aplicación.
Una pregunta de puntuación ordenada acepta entre 1 y 255 niveles y devuelve las probabilidades de los niveles y su índice esperado. Los índices de nivel comienzan en cero. El formato de resultado del fabricante también contiene la leyenda de niveles y un valor de confianza separado. Un índice esperado puede ser fraccionario: resume la distribución entre tus niveles ordenados, en lugar de seleccionar una nueva etiqueta textual. Conserva el orden y la leyenda de los niveles junto con el resultado, para que una valoración pueda interpretarse de forma coherente.
Las preguntas comparten el mismo estado, pero se evalúan de forma independiente. Una pregunta no puede leer la respuesta de otra, y el estado se calcula una vez y se reutiliza. Si una decisión posterior depende del resultado de una decisión anterior, haz explícita esa dependencia en un estado posterior, en lugar de esperar que las preguntas de una solicitud formen una cadena. Esto hace que el flujo con estado compartido sea adecuado para varias comprobaciones independientes sobre el mismo documento.
Prepara el estado con la evidencia que realmente requieran las preguntas. Puede ser texto sin formato o un objeto o array JSON representado como texto etiquetado. Mantén claros los nombres de campos, las unidades, las condiciones de las políticas y los pasajes pertinentes de las fuentes. Escribe una instrucción específica para cada pregunta y da a sus opciones significados que puedan distinguirse a partir del registro. Para una tarea original de asignación de soporte, el estado puede contener la solicitud y su contexto, mientras que las opciones definen categorías de entrega, acceso y soporte del producto con descripciones cortas.
Una segunda pregunta puede evaluar la urgencia, y una pregunta ordenada puede valorar cuánto seguimiento necesita la solicitud. Responden a cuestiones operativas distintas, así que define cada una por separado. Incluye una opción adecuada de revisión o falta de evidencia cuando la tarea de elección la necesite y conserva la distribución completa cuando varias categorías sean plausibles. La aplicación decide cómo asignar o revisar un resultado; el modelo proporciona el registro puntuado.
Kev-4B está destinado a decisiones de tipos definidos sobre documentos de unos pocos miles de tokens. El perfil de servicio de su fabricante acepta estados de hasta 65,536 tokens y reserva espacio adicional para cada pregunta, mientras que la longitud de contexto validada para este checkpoint es de 8192 tokens. Son límites distintos: aceptar un estado más largo no establece decisiones igual de fiables a cualquier longitud. Mantén compactos los pasajes decisivos y conserva sus etiquetas al preparar un registro largo para clasificación.
El perfil publicado está en inglés. Sus tareas útiles dependen de la evidencia del estado proporcionado y de las opciones definidas, en lugar de chat abierto, resúmenes o respuestas amplias basadas en conocimientos. La aritmética de fechas a nivel de días es una limitación específica: el fabricante proporciona un preprocesador separado de datos de fechas que suministra intervalos calculados. Para comprobar un plazo, incluye en el estado las fechas pertinentes y los intervalos de días calculados, junto con la regla que los utiliza.
El checkpoint se distribuye con una calibración de probabilidades ajustada, pero la confianza puede cambiar con el dominio del documento y el diseño de las preguntas. El fabricante también documenta el ajuste del checkpoint abierto con etiquetas específicas de la tarea y la adaptación de su calibración de probabilidades a esa carga de trabajo; este es un flujo de personalización separado de la puntuación de un estado proporcionado. Elige los umbrales de decisión utilizando ejemplos etiquetados de la carga real y mantén visibles los casos inciertos para revisión. El fabricante excluye las decisiones con consecuencias para personas totalmente automatizadas sin revisión humana. El orden de las opciones también puede afectar a una respuesta, por lo que conviene mantenerlo estable al comparar resultados. Evalúa la etiqueta elegida, el campo separado de confianza y la distribución de probabilidades según el papel de cada uno en tu flujo de trabajo.
La edición actual de Kev-4B descrita por el fabricante pertenece a Kev 1.0 y utiliza la base Qwen3.5. Las ediciones anteriores basadas en Qwen3 y las que solo operaban en la etapa de documento siguen siendo versiones distintas. Mantén la edición elegida y las definiciones de preguntas asociadas a las salidas al desarrollar un flujo específico de la tarea, en lugar de mezclar resultados de perfiles diferentes.
Un artefacto final útil es un conjunto con nombre de registros de decisión con las preguntas originales, las definiciones de opciones, las distribuciones y las leyendas de niveles ordenados que corresponda. Para comprobar la calidad de una respuesta, el estado debe incluir la respuesta propuesta, la evidencia y el criterio que se evalúa. Para el triaje de políticas, debe incluir la regla aplicable y los hechos pertinentes. Conserva esa entrada junto al resultado para que una revisión pueda establecer por qué una decisión fue adecuada o qué hecho ausente se debe aportar.
POST /v1/systemonetextdecisions| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites jaredpalmer/kev-4b | Predeterminado— |
Campoprovider | Tiposchema | RequisitoOpcional | Valores y límites | Predeterminado— |
Campoquestions | Tipoobject | RequisitoObligatorio | Valores y límites | Predeterminado— |
Camposession_id | Tipostring | RequisitoOpcional | Valores y límites | Predeterminado— |
Campostate | Tiposchema | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campotrace | Tiposchema | RequisitoOpcional | Valores y límites | Predeterminado— |
Campouser | Tipostring | RequisitoOpcional | Valores y límites | Predeterminado— |
Campoquestions.<id>.type | Tipostring | RequisitoObligatorio | Valores y límites noul, choice, score | Predeterminado— |
Campoquestions.<id>.instructions | Tipostring|object|array | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campoquestions.<id>.criteria | Tipoobject|array | RequisitoOpcional | Valores y límites Condiciones: choice/score: obligatorios; noul: opcional. Los criterios de choice son un objeto; score es un arreglo con minItems1. | Predeterminado— |
Campoquestions.<id>.criteria.true | Tipostring|object|array | RequisitoObligatorio | Valores y límites Se aplica cuando: Se proporcionó el objeto de criterios noul | Predeterminado— |
Campoquestions.<id>.criteria.false | Tipostring|object|array | RequisitoObligatorio | Valores y límites Se aplica cuando: Se proporcionó el objeto de criterios noul | Predeterminado— |
noul · Obligatorio: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Obligatorio: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Obligatorio: 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
Envía el ID exacto del modelo y conserva la respuesta nativa completa.
Las referencias tarifarias no añaden opciones a la solicitud. Los parámetros admitidos se indican en el método seleccionado.
Relaciona cada cargo con las condiciones mostradas. Usa una tarifa para cada conjunto de configuraciones alternativas.
| Configuración | Tabla de tarifas | Tokens de contexto, más de | Tokens de contexto, hasta inclusive | Cargo |
|---|---|---|---|---|
| ConfiguraciónTarifas base por token | Tabla de tarifasTarifa base | Tokens de contexto, más de— | Tokens de contexto, hasta inclusiveSin límite superior | Cargo Entrada · Tokens de entrada $0.000084 / 1K tokens Salida · Tokens de salida $0 / 1K tokens Entrada · Lectura de caché — / 1K tokens Entrada · Escritura en caché — / 1K tokens Entrada · Escritura en caché, 1 hora — / 1K tokens |
| ConfiguraciónNivel 1 por longitud de la solicitud | Tabla de tarifas— | Tokens de contexto, más de0 | Tokens de contexto, hasta inclusiveSin límite superior | Cargo Entrada · Tokens de entrada $0.000084 / 1K tokens Salida · Tokens de salida $0 / 1K tokens Entrada · Lectura de caché — / 1K tokens Entrada · Escritura en caché — / 1K tokens Entrada · Escritura en caché, 1 hora — / 1K tokens |
Ailoot reserva un monto estimado antes de la solicitud. Tras obtener el resultado, liquida el cargo definitivo según el uso medido. En las respuestas en flujo, la liquidación usa el registro de uso final. Cómo funcionan la reserva y la liquidación →
{\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
Conserva todas las respuestas, archivos y partes de contenido completos recibidos.
Se conserva cada respuesta al ID de pregunta proporcionado con su tipo exacto, valor noul/choice/score, confianza, probabilidades y leyenda. El JSON original completo se almacena y devuelve únicamente después de liquidar el cargo.
Conserva la operación original y la respuesta completa o parcial; no repitas el 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 |
| Respuesta | Condición | Siguiente paso |
|---|---|---|
Respuesta400 · invalid_request_error | CondiciónCampo obligatorio, representación o valor no válido | Siguiente pasoCorrige el campo indicado de la solicitud. |
Ailoot Ultra jaredpalmer/kev-4b
Usa las rutas de método indicadas arriba.