Decisiones rápidas y razonamiento deliberado: por qué las ofertas con IA necesitan ambos

Mientras su equipo prepara una oferta, el cliente envía una aclaración:

Para el soporte B-214, utilicen por favor el plano Rev D en su oferta actualizada. La Rev C requería anodizado; la Rev D especifica acabado de mecanizado, sin recubrimiento. La cantidad del pedido se mantiene en 5.000 piezas. Les rogamos que ajusten su oferta al cambio de acabado.

Reconocer que este mensaje le corresponde al departamento de ofertas es sencillo. Actualizar la oferta requiere más trabajo. Alguien tiene que revisar la Rev D, conciliarla con la especificación que rige, identificar qué operaciones cambian y recalcular la estimación.

Cada una de esas tareas pide una herramienta distinta. Una clasificación rápida basta para hacer llegar el mensaje al lugar correcto. Interpretar los requisitos puede requerir un modelo de lenguaje y los documentos pertinentes. El cambio de coste necesita datos de entrada y cálculos explícitos. Y un ingeniero todavía tiene que aprobar el resultado.

Las decisiones pequeñas y frecuentes como estas son una buena aplicación para los modelos System One. En Nyotta probamos Jev con mensajes sintéticos de proveedores, incluida esta aclaración del soporte, para medir sus clasificaciones y su repetibilidad.

Qué significan aquí System 1 y System 2

Daniel Kahneman popularizó la distinción entre el System 1, un pensamiento rápido e intuitivo, y el System 2, un pensamiento deliberado que exige esfuerzo. Es una analogía útil para diseñar flujos de trabajo con IA, aunque no describe literalmente cómo funciona un modelo. Thinking, Fast and Slow

En las ofertas, reconocer una queja por entrega es un juicio pequeño. Decidir qué requisito rige cuando un plano y una especificación se contradicen exige reunir evidencia y analizar el conflicto a fondo. Tratar ambos casos como el mismo tipo de solicitud a un modelo puede desperdiciar esfuerzo en tareas simples o dejar mal planteadas las difíciles.

La distinción también tiene que ver con la tarea. Un LLM de propósito general puede clasificar un mensaje rápidamente o dedicar más tiempo a razonar un problema. Y hay trabajo que no cae en ninguna de las dos categorías: multiplicar una tarifa aprobada por una cantidad debe resolverse con un cálculo, nunca con la intuición de un modelo.

¿Qué es Jev?

Jev es el primer modelo System One de TypeSafe. Usted le entrega la información que debe evaluar y preguntas con tipos de respuesta definidos. Sus primitivas documentadas son Choice, que selecciona una opción; Score, que evalúa una rúbrica; y Noul, que evalúa una proposición con un valor de cero a uno. Choice y Score también devuelven distribuciones de probabilidad y un nivel de confianza. Documentación de TypeSafe

Por ejemplo, le pedimos a Jev asignar un mensaje a uno de estos resultados:

quality | logistics | estimating | purchasing | review | none

La aplicación puede usar esa respuesta para enrutar el trabajo. TypeSafe indica que sus preguntas se evalúan en paralelo, lo que hace interesante explorar esta interfaz cuando varios juicios pequeños se refieren a la misma entrada. Introducing Jev

Cuando el flujo necesita una decisión, no siempre necesita un discurso. La broma es sobre la interfaz: los LLM de propósito general también pueden devolver salidas estructuradas.

Qué probamos

Probamos la clasificación de mensajes y la latencia de las solicitudes con jev-1.13.0 el 21 de septiembre de 2026. Jev recibió texto sintético y nuestras instrucciones, sin planos, historial de pedidos ni conversaciones previas. Escribimos las etiquetas esperadas antes de la ejecución.

Para 30 mensajes de negocio, hicimos dos preguntas de tipo Choice en cada llamada:

1. ¿Qué equipo debe atender la solicitud? Las opciones fueron quality (calidad), logistics (logística), estimating (ofertas), purchasing (compras), review (revisión) y none (ninguno). Review cubría problemas no identificados o ajenos al tema; none cubría avisos explícitos que no requieren acción.
2. ¿En qué estado está la información? Las opciones fueron clear (clara), conflicting (contradictoria), insufficient (insuficiente) y no_action (sin acción). Clear significaba una solicitud o un problema identificable, y no hechos verificados ni autorización para actuar.

Los mensajes abarcaban defectos, retrasos en entregas, cambios de precio, informes contradictorios, contexto que faltaba, avisos de rutina y solicitudes de oferta. Nuestra política de enrutamiento daba prioridad a quality, luego a logistics, estimating y purchasing cuando aparecían varios temas a la vez. Cada mensaje se envió tres veces para medir la repetibilidad.

Para la aclaración del soporte de arriba, Jev devolvió estimating y clear en las tres llamadas. También devolvió estimating y clear para este mensaje:

La especificación del cliente establece: «Rechazar piezas con grietas». Se trata de un criterio de aceptación y no de un aviso de piezas defectuosas. Les rogamos que incluyan en su oferta la inspección de grietas requerida.

Eso coincidió con la distinción que buscábamos entre un requisito de inspección y un defecto actual.

Medida	Resultado
Selecciones de equipo que coincidieron con nuestras etiquetas	90/90 llamadas (100 %)
Selecciones de estado de la información que coincidieron con nuestras etiquetas	87/90 llamadas (96,7 %)
Mensajes que coincidieron en ambas etiquetas en todas las repeticiones	29/30
Mensajes que devolvieron el mismo par de etiquetas en las tres llamadas	30/30 (100 %)

La última fila mide la repetibilidad de las etiquetas, con independencia de si coinciden con las nuestras. Las respuestas seleccionadas se mantuvieron iguales entre repeticiones, aunque las distribuciones de probabilidad a veces cambiaron. Tres llamadas por entrada son una revisión de consistencia pequeña; no prueban un comportamiento determinista en solicitudes futuras ni en versiones futuras del modelo.

La discrepancia se dio con este mensaje:

Por favor, resuelvan el tema del pedido 4812 que comenté ayer con su compañero. ¿Podría pedirle los detalles e indicarme el siguiente paso?

Jev devolvió review y clear en las tres llamadas. Nosotros esperábamos review e insufficient, porque faltaba el problema de fondo. Pero nuestra redacción permitía que clear significara una solicitud identificable, y pedirle los detalles a un compañero cumple con eso. La respuesta de Jev es defendible. Jev coincidió con nuestras respuestas esperadas en 87 de 90 llamadas. Las tres discrepancias vinieron de una sola pregunta ambigua repetida tres veces; cualquiera de las dos respuestas era defendible.

Esto importa al definir un flujo de trabajo. «¿Se entiende la solicitud?» y «¿Tenemos información suficiente para resolver el problema?» necesitan preguntas separadas. La confianza de un modelo no puede reparar una definición ambigua.

Cómo cambió la latencia con más preguntas

Usamos un mensaje que informaba de una entrega con retraso, grietas encontradas durante la inspección y una solicitud de subida de precio para el siguiente pedido. Definimos dieciséis preguntas de tipo proposición, entre ellas si el mensaje informaba de grietas, si mencionaba un retraso en la entrega o si incluía un número de pedido de compra.

Luego hicimos la primera pregunta sola, las cuatro primeras juntas y las dieciséis juntas, con seis llamadas por grupo:

Preguntas por llamada	Latencia mediana	Rango observado
1	211 ms	176–285 ms
4	198 ms	190–208 ms
16	237 ms	199–290 ms

Son tiempos HTTP de extremo a extremo, incluida la sobrecarga de red. Las llamadas fueron secuenciales, sin reintentos de la aplicación ni llamadas de calentamiento excluidas. En esta prueba, hacer dieciséis preguntas no tardó dieciséis veces más. Seis observaciones por grupo no bastan para establecer el rendimiento en producción ni una ventaja de velocidad frente a otro modelo.

Junto con siete mensajes de diagnóstico enviados tres veces cada uno (21 llamadas), la evaluación sumó 129 solicitudes correctas, todas aprobadas por nuestras verificaciones locales de la forma de la respuesta. Los mensajes de diagnóstico pusieron a prueba ataques a las instrucciones y solicitudes ajenas al tema; quedan fuera de los resultados de mensajes de negocio presentados arriba.

Cómo aplicamos este enfoque en Nyotta

En Nyotta separamos la clasificación y extracción de documentos de la estimación numérica. Las regiones del plano se clasifican antes de extraer sus características, y esas características conservan su ubicación de origen para la revisión. Un código de estimación dedicado usa los datos de entrada resultantes para producir estimaciones y señalar avisos.

Así, cada componente tiene una función específica. Los modelos ayudan a interpretar la información de ingeniería; los modelos de estimación y el código producen el resultado numérico. Un revisor puede comprobar por separado la interpretación de la fuente y la estimación.

En el caso del soporte, el papel de Jev es acotado: clasificar la aclaración del cliente y enviarla al departamento de ofertas. En nuestro experimento devolvió la ruta esperada en las tres llamadas. Completar la oferta sigue requiriendo el plano y la especificación reales, los datos de coste aceptados y la aprobación de ingeniería.

¿Por qué usar Nyotta y no pedirle la oferta a un LLM genérico?

Los LLM forman parte de Nyotta. Usamos su comprensión del lenguaje y su capacidad de razonamiento para interpretar requisitos, extraer información y ayudar a explicar qué necesita revisión. Una oferta también necesita datos de ingeniería, un método de estimación definido, cálculos y aprobación.

En Nyotta, las características extraídas del plano conservan su ubicación de origen. Un código de estimación dedicado se encarga de las estimaciones numéricas, verifica los datos de entrada y notifica avisos. Esa separación permite que un revisor examine la interpretación de la fuente y la estimación, cada una con sus propios criterios.

En un sistema de ofertas, los roles deben estar explícitos:

Tarea	Herramienta o responsable adecuado
Interpretar un requisito o redactar una aclaración	Un modelo de lenguaje o multimodal, con la fuente disponible para verificar
Clasificar una solicitud acotada	Una regla o un modelo de decisión evaluado para esa tarea
Conciliar requisitos contradictorios	Los documentos pertinentes, razonamiento y revisión de ingeniería
Estimar coste o precio	Un modelo de estimación definido, con los datos de negocio requeridos
Aplicar tarifas, cantidades y restricciones	Código, fórmulas y reglas de validación
Aceptar un supuesto y emitir una oferta	El ingeniero o aprobador autorizado

Un LLM puede llamar a esas herramientas. El cálculo todavía tiene que ejecutarse sobre los datos de entrada aceptados, y el resultado debe conservar su justificación. En el ejemplo del soporte, eliminar el anodizado tiene que reflejarse en los costes de las operaciones correspondientes; el nuevo precio debe derivarse de la estimación.

El valor de Nyotta está en conectar la interpretación del modelo con ese trabajo de ingeniería. Un modelo como Jev encaja en el paso de clasificación. Su utilidad depende de la tarea y de las verificaciones que la rodean, igual que la de un LLM.

La comparación que importa es con una RFQ real: ¿puede su equipo rastrear los requisitos hasta la fuente, revisar los datos de coste y ver qué falta por aprobar?