Decider V1.1 27B es el checkpoint de decisión actualizado de Perplexity. Evalúa el contenido proporcionado respecto a una pregunta definida y produce probabilidades sobre las respuestas válidas. Su artefacto nativo tiene un componente de lectura de decisiones, en lugar de una cabeza de generación de lenguaje sobre el vocabulario completo. El resultado útil es una distribución acotada de decisión y su respuesta interpretada, no una explicación abierta ni una respuesta de chat general.
Perplexity identifica este modelo como una actualización de Decider V1 27B que conserva la misma arquitectura base, con cambios en la configuración de atención y más datos de entrenamiento. Su arquitectura base es Qwen3.8-27B. La edición V1.1 debe conservar su propio nombre y configuración, en lugar de describirse como una copia intercambiable del checkpoint anterior.
El ejemplo publicado proporciona una fila que contiene un estado y una pregunta de tipo choice. La pregunta incluye instrucciones y criterios cuyas claves son las respuestas semánticas y cuyas descripciones definen cuándo se aplica cada una. El modelo predice probabilidades y, después, la función auxiliar de respuesta del productor interpreta esas probabilidades para la pregunta. El ejemplo de inferencia puede procesar una lista de filas, con una decisión vinculada a la evidencia y a la pregunta de cada fila.
Para asignar solicitudes, proporciona el mensaje real y el contexto pertinente y define después los departamentos o categorías disponibles. Una tarea ilustrativa puede distinguir entre una falla de integración, un problema de acceso y una solicitud de información del producto. Haz que cada descripción sea lo bastante precisa para resolver un caso limítrofe y conserva las definiciones de las opciones junto con el resultado. Una distribución de categorías puede entonces apoyar una decisión de asignación o un paso de revisión cuando las alternativas sigan próximas. El resultado elegido por el modelo no ejecuta por sí mismo la acción del flujo de trabajo.
La implementación nativa acepta imágenes junto con el estado y la pregunta mediante entradas de archivos de imagen, imágenes en memoria o datos de imagen codificados. Para una imagen de documento o una captura de pantalla, proporciona la evidencia visual y plantea una pregunta cerrada cuyas opciones describan los resultados pertinentes. Identifica la característica visible que importa y proporciona el contexto textual necesario para interpretarla. Por ejemplo, clasifica si un artículo fotografiado pertenece a una de las categorías de producto suministradas, en lugar de pedir al modelo de decisión que redacte una descripción completa del producto.
El procesador conserva la relación de aspecto al redimensionar y redondea los lados de la imagen a múltiplos de 32 píxeles. El área procesada documentada comienza en 65,536 píxeles y queda acotada por un máximo configurable; su valor predeterminado es 4,194,304 píxeles, o 2048 por 2048. Cada parche de 32 por 32 aporta un token visual, de modo que ese valor predeterminado permite hasta 4,096 tokens visuales por imagen. Estas cifras describen la preparación nativa de imágenes del productor, no un contrato general de carga de archivos de una aplicación.
El paso prepare documentado exige que el texto y todas las imágenes de una decisión quepan en 8,192 tokens. La entrada que supera el tamaño permitido se rechaza, en lugar de truncarse silenciosamente. Varias imágenes comparten ese presupuesto con el estado escrito y la pregunta. Reduce el texto de origen irrelevante o el límite de tamaño de imagen al preparar una decisión combinada, conservando el detalle que determina la respuesta.
La configuración de entrenamiento y de evaluación comunicada limitó las imágenes a 512 por 512, equivalentes a 262,144 píxeles y hasta 256 tokens visuales. El límite configurable de inferencia puede conservar más detalle, pero la ficha advierte de que una resolución más alta queda fuera de esa distribución de entrenamiento y utiliza más memoria y tiempo de procesamiento. Por tanto, un ajuste de imagen mayor no garantiza una decisión mejor. Mantén la preparación de entrada coherente con la pregunta y comprueba si la característica visual necesaria está representada con claridad.
Las capas de atención completa del checkpoint nativo utilizan un modo de atención no causal guardado, mientras que sus capas de atención lineal conservan su propio comportamiento. El fabricante afirma que la inferencia causal predeterminada no reproduce la configuración evaluada. Su implementación de predicción aplica la temperatura de calibración guardada; si se utilizan los logits directamente, esa temperatura se aplica una vez y las probabilidades se normalizan sobre los candidatos válidos actuales. Estos detalles pertenecen al perfil de decisión exacto y deben conservarse al interpretar sus salidas numéricas.
El componente separado de lectura de decisiones también distingue este artefacto de una exportación generativa. Una conversión a una interfaz de generación basada en vocabulario necesita una correspondencia explícita y debe conservar el comportamiento de atención. Prepara preguntas cerradas para el perfil nativo de decisión; utiliza un modelo de generación adecuado cuando la tarea necesite chat, código, explicaciones o solicitudes de herramientas.
Un artefacto final útil mantiene asociados el estado, la pregunta, las respuestas permitidas y la distribución resultante. Define la pregunta en torno a evidencia realmente presente, revisa los casos ambiguos frente a esa evidencia y utiliza ejemplos etiquetados de la tarea prevista para decidir cómo las salidas numéricas deben afectar a la asignación o clasificación. El modelo proporciona probabilidades de decisión; los criterios y la aplicación que lo integra determinan cómo esas probabilidades se convierten en una acción útil o en una etiqueta registrada.
", "aboutText": "Decider V1.1 27B es el checkpoint de decisión actualizado de Perplexity. Evalúa el contenido proporcionado respecto a una pregunta definida y produce probabilidades sobre las respuestas válidas. Su artefacto nativo tiene un componente de lectura de decisiones, en lugar de una cabeza de generación de lenguaje sobre el vocabulario completo. El resultado útil es una distribución acotada de decisión y su respuesta interpretada, no una explicación abierta ni una respuesta de chat general.\n\n### Qué cambia en la edición V1.1\n\nPerplexity identifica este modelo como una actualización de Decider V1 27B que conserva la misma arquitectura base, con cambios en la configuración de atención y más datos de entrenamiento. Su arquitectura base es Qwen3.8-27B. La edición V1.1 debe conservar su propio nombre y configuración, en lugar de describirse como una copia intercambiable del checkpoint anterior.\n\n### Estado, pregunta y respuestas válidas\n\nEl ejemplo publicado proporciona una fila que contiene un estado y una pregunta de tipo choice. La pregunta incluye instrucciones y criterios cuyas claves son las respuestas semánticas y cuyas descripciones definen cuándo se aplica cada una. El modelo predice probabilidades y, después, la función auxiliar de respuesta del productor interpreta esas probabilidades para la pregunta. El ejemplo de inferencia puede procesar una lista de filas, con una decisión vinculada a la evidencia y a la pregunta de cada fila.\n\nPara asignar solicitudes, proporciona el mensaje real y el contexto pertinente y define después los departamentos o categorías disponibles. Una tarea ilustrativa puede distinguir entre una falla de integración, un problema de acceso y una solicitud de información del producto. Haz que cada descripción sea lo bastante precisa para resolver un caso limítrofe y conserva las definiciones de las opciones junto con el resultado. Una distribución de categorías puede entonces apoyar una decisión de asignación o un paso de revisión cuando las alternativas sigan próximas. El resultado elegido por el modelo no ejecuta por sí mismo la acción del flujo de trabajo.\n\n### Evidencia textual y de imágenes\n\nLa implementación nativa acepta imágenes junto con el estado y la pregunta mediante entradas de archivos de imagen, imágenes en memoria o datos de imagen codificados. Para una imagen de documento o una captura de pantalla, proporciona la evidencia visual y plantea una pregunta cerrada cuyas opciones describan los resultados pertinentes. Identifica la característica visible que importa y proporciona el contexto textual necesario para interpretarla. Por ejemplo, clasifica si un artículo fotografiado pertenece a una de las categorías de producto suministradas, en lugar de pedir al modelo de decisión que redacte una descripción completa del producto.\n\nEl procesador conserva la relación de aspecto al redimensionar y redondea los lados de la imagen a múltiplos de 32 píxeles. El área procesada documentada comienza en 65,536 píxeles y queda acotada por un máximo configurable; su valor predeterminado es 4,194,304 píxeles, o 2048 por 2048. Cada parche de 32 por 32 aporta un token visual, de modo que ese valor predeterminado permite hasta 4,096 tokens visuales por imagen. Estas cifras describen la preparación nativa de imágenes del productor, no un contrato general de carga de archivos de una aplicación.\n\n### Límites de entrada combinada y alcance de la resolución\n\nEl paso prepare documentado exige que el texto y todas las imágenes de una decisión quepan en 8,192 tokens. La entrada que supera el tamaño permitido se rechaza, en lugar de truncarse silenciosamente. Varias imágenes comparten ese presupuesto con el estado escrito y la pregunta. Reduce el texto de origen irrelevante o el límite de tamaño de imagen al preparar una decisión combinada, conservando el detalle que determina la respuesta.\n\nLa configuración de entrenamiento y de evaluación comunicada limitó las imágenes a 512 por 512, equivalentes a 262,144 píxeles y hasta 256 tokens visuales. El límite configurable de inferencia puede conservar más detalle, pero la ficha advierte de que una resolución más alta queda fuera de esa distribución de entrenamiento y utiliza más memoria y tiempo de procesamiento. Por tanto, un ajuste de imagen mayor no garantiza una decisión mejor. Mantén la preparación de entrada coherente con la pregunta y comprueba si la característica visual necesaria está representada con claridad.\n\n### Atención, lectura de decisiones y calibración de probabilidades\n\nLas capas de atención completa del checkpoint nativo utilizan un modo de atención no causal guardado, mientras que sus capas de atención lineal conservan su propio comportamiento. El fabricante afirma que la inferencia causal predeterminada no reproduce la configuración evaluada. Su implementación de predicción aplica la temperatura de calibración guardada; si se utilizan los logits directamente, esa temperatura se aplica una vez y las probabilidades se normalizan sobre los candidatos válidos actuales. Estos detalles pertenecen al perfil de decisión exacto y deben conservarse al interpretar sus salidas numéricas.\n\nEl componente separado de lectura de decisiones también distingue este artefacto de una exportación generativa. Una conversión a una interfaz de generación basada en vocabulario necesita una correspondencia explícita y debe conservar el comportamiento de atención. Prepara preguntas cerradas para el perfil nativo de decisión; utiliza un modelo de generación adecuado cuando la tarea necesite chat, código, explicaciones o solicitudes de herramientas.\n\nUn artefacto final útil mantiene asociados el estado, la pregunta, las respuestas permitidas y la distribución resultante. Define la pregunta en torno a evidencia realmente presente, revisa los casos ambiguos frente a esa evidencia y utiliza ejemplos etiquetados de la tarea prevista para decidir cómo las salidas numéricas deben afectar a la asignación o clasificación. El modelo proporciona probabilidades de decisión; los criterios y la aplicación que lo integra determinan cómo esas probabilidades se convierten en una acción útil o en una etiqueta registrada.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "626121567521448eaa0647c7b247d75a0c806eeeed3ad86b0554dece0d8a0ce9", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "es-mx", "methods": [ { "html": "perplexity/pplx-decider-v1.1-27bDecider V1.1 27B de Perplexity evalúa un estado y una pregunta proporcionados y devuelve probabilidades entre las respuestas permitidas. Su checkpoint nativo de decisión admite texto e imágenes, con un componente específico de lectura de decisiones y límites documentados de preparación de entrada, en lugar de un contrato de generación de texto libre.
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.
Decider V1.1 27B es el checkpoint de decisión actualizado de Perplexity. Evalúa el contenido proporcionado respecto a una pregunta definida y produce probabilidades sobre las respuestas válidas. Su artefacto nativo tiene un componente de lectura de decisiones, en lugar de una cabeza de generación de lenguaje sobre el vocabulario completo. El resultado útil es una distribución acotada de decisión y su respuesta interpretada, no una explicación abierta ni una respuesta de chat general.
Perplexity identifica este modelo como una actualización de Decider V1 27B que conserva la misma arquitectura base, con cambios en la configuración de atención y más datos de entrenamiento. Su arquitectura base es Qwen3.8-27B. La edición V1.1 debe conservar su propio nombre y configuración, en lugar de describirse como una copia intercambiable del checkpoint anterior.
El ejemplo publicado proporciona una fila que contiene un estado y una pregunta de tipo choice. La pregunta incluye instrucciones y criterios cuyas claves son las respuestas semánticas y cuyas descripciones definen cuándo se aplica cada una. El modelo predice probabilidades y, después, la función auxiliar de respuesta del productor interpreta esas probabilidades para la pregunta. El ejemplo de inferencia puede procesar una lista de filas, con una decisión vinculada a la evidencia y a la pregunta de cada fila.
Para asignar solicitudes, proporciona el mensaje real y el contexto pertinente y define después los departamentos o categorías disponibles. Una tarea ilustrativa puede distinguir entre una falla de integración, un problema de acceso y una solicitud de información del producto. Haz que cada descripción sea lo bastante precisa para resolver un caso limítrofe y conserva las definiciones de las opciones junto con el resultado. Una distribución de categorías puede entonces apoyar una decisión de asignación o un paso de revisión cuando las alternativas sigan próximas. El resultado elegido por el modelo no ejecuta por sí mismo la acción del flujo de trabajo.
La implementación nativa acepta imágenes junto con el estado y la pregunta mediante entradas de archivos de imagen, imágenes en memoria o datos de imagen codificados. Para una imagen de documento o una captura de pantalla, proporciona la evidencia visual y plantea una pregunta cerrada cuyas opciones describan los resultados pertinentes. Identifica la característica visible que importa y proporciona el contexto textual necesario para interpretarla. Por ejemplo, clasifica si un artículo fotografiado pertenece a una de las categorías de producto suministradas, en lugar de pedir al modelo de decisión que redacte una descripción completa del producto.
El procesador conserva la relación de aspecto al redimensionar y redondea los lados de la imagen a múltiplos de 32 píxeles. El área procesada documentada comienza en 65,536 píxeles y queda acotada por un máximo configurable; su valor predeterminado es 4,194,304 píxeles, o 2048 por 2048. Cada parche de 32 por 32 aporta un token visual, de modo que ese valor predeterminado permite hasta 4,096 tokens visuales por imagen. Estas cifras describen la preparación nativa de imágenes del productor, no un contrato general de carga de archivos de una aplicación.
El paso prepare documentado exige que el texto y todas las imágenes de una decisión quepan en 8,192 tokens. La entrada que supera el tamaño permitido se rechaza, en lugar de truncarse silenciosamente. Varias imágenes comparten ese presupuesto con el estado escrito y la pregunta. Reduce el texto de origen irrelevante o el límite de tamaño de imagen al preparar una decisión combinada, conservando el detalle que determina la respuesta.
La configuración de entrenamiento y de evaluación comunicada limitó las imágenes a 512 por 512, equivalentes a 262,144 píxeles y hasta 256 tokens visuales. El límite configurable de inferencia puede conservar más detalle, pero la ficha advierte de que una resolución más alta queda fuera de esa distribución de entrenamiento y utiliza más memoria y tiempo de procesamiento. Por tanto, un ajuste de imagen mayor no garantiza una decisión mejor. Mantén la preparación de entrada coherente con la pregunta y comprueba si la característica visual necesaria está representada con claridad.
Las capas de atención completa del checkpoint nativo utilizan un modo de atención no causal guardado, mientras que sus capas de atención lineal conservan su propio comportamiento. El fabricante afirma que la inferencia causal predeterminada no reproduce la configuración evaluada. Su implementación de predicción aplica la temperatura de calibración guardada; si se utilizan los logits directamente, esa temperatura se aplica una vez y las probabilidades se normalizan sobre los candidatos válidos actuales. Estos detalles pertenecen al perfil de decisión exacto y deben conservarse al interpretar sus salidas numéricas.
El componente separado de lectura de decisiones también distingue este artefacto de una exportación generativa. Una conversión a una interfaz de generación basada en vocabulario necesita una correspondencia explícita y debe conservar el comportamiento de atención. Prepara preguntas cerradas para el perfil nativo de decisión; utiliza un modelo de generación adecuado cuando la tarea necesite chat, código, explicaciones o solicitudes de herramientas.
Un artefacto final útil mantiene asociados el estado, la pregunta, las respuestas permitidas y la distribución resultante. Define la pregunta en torno a evidencia realmente presente, revisa los casos ambiguos frente a esa evidencia y utiliza ejemplos etiquetados de la tarea prevista para decidir cómo las salidas numéricas deben afectar a la asignación o clasificación. El modelo proporciona probabilidades de decisión; los criterios y la aplicación que lo integra determinan cómo esas probabilidades se convierten en una acción útil o en una etiqueta registrada.
POST /v1/systemonetext, imagedecisions| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites perplexity/pplx-decider-v1.1-27b | 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, image |
Parámetrooptional_controls | Contratoprovider, session_id, trace, user |
Parámetromultimodal_input_binding | ContratoUsa únicamente la representación exacta declarada de estado o documento. La capacidad de imagen del fabricante por sí sola no establece un formato de entrada de imagen aceptado específico del modelo. |
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.00004 / 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.00004 / 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": "perplexity/pplx-decider-v1.1-27b",\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']='perplexity/pplx-decider-v1.1-27b'\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 perplexity/pplx-decider-v1.1-27b
Usa las rutas de método indicadas arriba.