Mistral Small 3: recorta costos con funciones estrictas

Por qué ahora: Small 3 y funciones estrictas cambian la ecuación

Si diriges una plataforma de asistentes in-product con alto volumen, hoy tienes un incentivo claro para reconfigurar tu ruteo de modelos. Mistral Small 3 llega con mejor seguimiento de instrucciones, mayor fidelidad en JSON y function calling, y latencia más baja en despliegues mixtos CPU/GPU. En paralelo, proveedores como Anthropic han subido la vara en tool use y JSON consistente en sus gamas medias. El resultado es un nuevo punto de equilibrio: más casos pueden resolverse con un modelo pequeño y barato sin degradar la experiencia.

Lo práctico: una retitulación de tráfico donde 60 a 80% de las solicitudes van a Small 3 bajo esquemas estrictos, con fallbacks controlados a un modelo medio cuando el riesgo o la complejidad lo requieren. Esta jugada recorta el costo mezclado y respeta tus SLOs de latencia y calidad. Es como en maratón, cuando el grupo de ritmo te lleva el 80% del recorrido a un costo de esfuerzo óptimo, y reservas los cambios de ritmo para las cuestas o el sprint final.

En este guía te explico cómo implementarlo de forma segura: arquitectura de ruteo, especificaciones de función, SLOs, modelo de costos, plan de despliegue y ejemplos reales.

La jugada de re-tiering: 60-80% al modelo pequeño

En vez de tratar todos los turnos de usuario por igual, movemos la mayoría a un carril de bajo costo y baja latencia, siempre que se cumplan tres condiciones:

• La intención es de baja complejidad o bien cubierta por herramientas.
• El turno cabe en un esquema estricto de función o en JSON mode con comprobación dura.
• El riesgo de resultado incorrecto es bajo, o el flujo tiene verificación downstream.

Cuando estas condiciones no se cumplen, o si se dispara una de las salvaguardas, escalamos de inmediato a un modelo medio.

Beneficios esperados:

• Reducción del costo mezclado por sesión de 30 a 60% según mezcla de intents y longitudes.
• Menor p95 de latencia en flujos con 1 a 2 llamadas a herramientas, gracias a la menor huella del modelo y a la fidelidad JSON que recorta reintentos.
• Menos validaciones y correcciones en backend por tipado y enums estrictos.

Arquitectura de ruteo y políticas

Piensa en un router determinista con señales runtime y reglas claras. No persigas magia negra. Componentes clave:

• Clasificador de intención y complejidad: heurísticas + un modelo liviano que etiqueta la solicitud en categorías como "FAQ", "consulta de compatibilidad", "acciones con herramientas seguras", "generación libre", "soporte técnico avanzado".
• Evaluación de riesgo: sensibilidad a PII, impacto potencial, flags de compliance, estado del usuario.
• Señales de contexto: longitud de historial, necesidad prevista de herramientas, límites de tiempo de sesión.
• Políticas de ruteo: matrices de decisión que asignan modelo y modo de inferencia.

Pseudocódigo del router:

def route(turn, user, context):
    intent = classify_intent(turn, context)
    risk = score_risk(turn, user)
    needs_tool = predict_tool_use(turn)
    tokens_hist = estimate_tokens(context.history)

    small3_ok = (
        intent in {"faq", "lookup", "compare", "setup_guided"}
        and risk < RISK_THRESHOLD
        and tokens_hist < HIST_TOKENS_MAX
    )

    if small3_ok:
        return ModelPlan(
            model="mistral-small-3",
            mode="json_strict" if needs_tool else "text_strict",
            tool_schema="strict" if needs_tool else None,
            fallbacks=["mistral-medium", "sonnet-tier"]
        )
    else:
        return ModelPlan(
            model="mistral-medium",
            mode="json_relaxed" if needs_tool else "text",
            fallbacks=["sonnet-tier"]
        )

Señales que gatillan fallback en tiempo real:

• JSON inválido tras 1 reintento con temperatura 0 y max_output_tokens ajustado.
• Llamada a herramienta rechazada por el validador de tipos o por políticas.
• Latencia acumulada se aproxima al presupuesto y el usuario espera respuesta visible.
• Confianza semántica baja medida por retrieval score u otra métrica interna.

Infra: Small 3 funciona bien en clusters mixtos CPU/GPU para colas de gran volumen. Usa preferencia de colas para que el carril Small tenga su propia reserva de capacidad y no compita a muerte con el carril Medium.

Especificaciones de función: cómo aprovechar esquemas estrictos

El nuevo spec de función de Mistral admite tipado más estricto y, en la práctica, reduce errores de validación downstream. La clave está en definir esquemas que sean tanto restrictivos como útiles para el modelo.

Patrones recomendados:

• additionalProperties: false para cerrar el espacio de argumentos.
• Enums y formatos explícitos para ids, fechas, monedas.
• Campos opcionales con defaults server-side, no delegues al modelo.
• Descripciones concisas y orientadas a casos, evita textos vagos.
• Validación server-side antes de ejecutar la herramienta, con mensajes de corrección para reintentos.

Ejemplo de función de creación de ticket con fidelidad alta:

{
  "name": "create_ticket",
  "description": "Crea un ticket de soporte con tipología controlada",
  "parameters": {
    "type": "object",
    "properties": {
      "title": { "type": "string", "minLength": 5, "maxLength": 120 },
      "category": { "type": "string", "enum": ["billing", "bug", "usage", "integration"] },
      "priority": { "type": "string", "enum": ["low", "medium", "high"] },
      "account_id": { "type": "string", "pattern": "^acct_[a-z0-9]{8}$" },
      "attachments": {
        "type": "array",
        "items": { "type": "string", "format": "uri" },
        "maxItems": 3
      },
      "repro_steps": { "type": "string", "maxLength": 1000 }
    },
    "required": ["title", "category", "account_id"],
    "additionalProperties": false
  }
}

Para flujos de recuperación + acción, define funciones pequeñas y composables en vez de mega funciones. Mistral Small 3 responde bien a cadenas cortas con 1 a 2 herramientas. Si debes paralelizar, aprovecha la capacidad de llamadas paralelas, pero aplica límites de concurrencia por turno para no romper tus SLOs.

Consejo de cancha de tenis: divide la pista. Separa claramente funciones de lectura, validación y acción. Esto da pasos más cortos y controlados, y reduces errores no forzados.

SLOs que importan y cómo instrumentarlos

Define SLOs explicitamente por tipo de flujo:

• Latencia p95 por turno:
  • Respuesta pura sin herramienta: p95 ≤ 900 ms en Small 3, p95 ≤ 1.4 s en Medium.
  • Con 1 herramienta: p95 ≤ 1.8 s Small, ≤ 2.5 s Medium.
• Fidelidad JSON: ≥ 99.2% sin reintento, ≥ 99.7% con 1 reintento.
• Precisión de tool use en esquemas estrictos: ≥ 97% argumentos válidos a la primera.
• Tasa de fallback: 20 a 40% target, nunca por encima de 50% en hora pico.
• CSAT o proxy de calidad in-product: sin caída significativa vs baseline.

Instrumentación mínima:

• Trazas por turno con etiquetas de plan de modelo, tiempo de encolado, tiempo de inferencia, validaciones y reintentos.
• Contadores de JSON válido, tool-call válido, razones de fallback.
• Métricas por intención para detectar dónde Small 3 no da la talla y requiere ajustes de esquema o prompts.

Modelo de costos: ahorro blended con supuestos simples

No necesitas precios exactos para estimar el impacto. Usa un modelo con supuestos claros y mira el orden de magnitud.

Supuestos de ejemplo, puramente ilustrativos:

• Small 3: costo relativo 1x por millón de tokens de entrada y 3x de salida.
• Modelo medio: costo relativo 10x entrada y 30x salida.
• Mezcla de tokens por turno: 1k in, 300 out en promedio con Small; 1.4k in, 400 out en Medium por prompts más largos y verborrea.
• Tres tipos de flujo: FAQ simple, lookup con 1 herramienta, acción con 2 herramientas.

Escenario A sin re-tiering: todo a modelo medio

• Costo por turno medio ≈ 10x1.4 + 30x0.4 = 14x + 12x = 26x.

Escenario B con re-tiering 70% Small 3, 30% Medium

• Costo en Small ≈ 1x1 + 3x0.3 = 1x + 0.9x = 1.9x.
• Costo en Medium ≈ 26x.
• Blended ≈ 0.71.9x + 0.326x = 1.33x + 7.8x = 9.13x.

Ahorro aproximado: 65% frente a todo Medium. Ajusta con tus números reales y observa la sensibilidad a la tasa de fallback y a la longitud de salida.

Consejo: pon límites de longitud de respuesta por tipo de intención. Las salidas largas inflan el costo más que la entrada, y Small 3 suele ser más conciso si guías con estilo de respuesta y bullets.

Plan de implementación en 14 días

Día 1-2: definición

• Mapear intents de alto volumen y su tasa de éxito actual.
• Acordar SLOs y límites de latencia por flujo.
• Diseñar esquemas de funciones estrictos para los 5 flujos principales.

Día 3-5: prototipos y pruebas offline

• Implementar prompts y funciones en Small 3.
• Pruebas deterministas de JSON y tool use con un set de 200-500 casos sintéticos y reales.
• Ajustar enums, required y mensajes de error para reintentos rápidos.

Día 6-8: ruteo y fallbacks

• Codificar el router y las políticas.
• Añadir reintento único con temperatura 0 ante JSON inválido.
• Implementar fallback inmediato a Medium si persiste el error o si se agota el presupuesto de latencia.

Día 9-11: canary al 10-20%

• Tráfico real con monitoreo en vivo.
• Revisar p95, tasa de JSON válido y razones de fallback.
• Ajustar límites y prompts de estilo si hay verborrea.

Día 12-14: expansión y hardening

• Subir al 50-70% de tráfico para intents objetivo.
• Documentar playbooks de incidentes.
• Entrenar al equipo de soporte en lectura de trazas y causas de fallback.

Riesgos y mitigaciones

• Deriva de prompt o cambios en herramientas: versiona esquemas y bloquea prompts por versión.
• Alucinaciones en generación libre: limita Small 3 a respuestas con citas o a plantillas controladas, no lo uses para consejos abiertos de alto riesgo.
• PII y compliance: inspecciona entradas y salidas, redáctalas si procede antes de tool calls.
• Sesiones largas: corta historial con resúmenes estructurados, no dejes que el contexto explote en tokens.
• Picos de tráfico: colas separadas y shedding suave con mensajes de espera útiles.

Analogía de maratón: no estrenas zapatillas nuevas el día de la carrera. No sueltes el 80% de tráfico a un modelo nuevo sin un canary y métricas visibles en tiempo real.

Ejemplos prácticos de flujos

Ejemplo 1. Compatibilidad de producto con 1 herramienta

• Intent: "¿Este conector funciona con la versión 4.2 del CRM?"
• Ruta: Small 3 en JSON estricto, herramienta check_compatibility(product_id, target_version).
• Esquema con enums de versiones soportadas, rechazo inmediato si la versión no existe.
• P95 objetivo: 1.6 s.
• Fallback: si el catálogo no encuentra el producto o la versión, Medium para interpretación semántica más fina.

Ejemplo 2. Alta de integración guiada

• Intent: "Ayúdame a conectar el SSO con SAML".
• Ruta: Small 3 con funciones pequeñas: provision_sp, generate_metadata, validate_assertion.
• Plantillas de respuesta con pasos y validaciones.
• Reintento ante JSON inválido una sola vez.
• Fallback si falla la validación de validate_assertion por formato.

Ejemplo 3. Resolución de error complejo

• Intent: "Después de migrar a multi-tenant, mis webhooks duplican eventos".
• Ruta: directo a modelo medio por complejidad y riesgo.
• Herramientas con read-only logs y comparación de configuraciones.
• Si el tiempo se agota, mostrar pasos de diagnóstico seguros y ofrecer escalar a soporte humano.

Prompts y plantillas que funcionan con Small 3

• Estilo de salida minimalista: bullets, respuestas cortas, JSON conciso.
• Indicaciones de formato: "Responde solo con JSON válido según el esquema" y un ejemplo positivo y uno negativo.
• Roles claros: "Primero decide si usarás una herramienta. Si no, responde en 3 bullets con acciones concretas".

Ejemplo de plantilla de tool decision:

Tarea: {tarea}
Historial resumido: {resumen}

Si una herramienta es necesaria, devuelve una única llamada de función con argumentos que cumplan el esquema. Si no lo es, responde en 3 bullets, máx 30 palabras cada uno.

Cómo medir y mejorar sin fricción

• Harness offline: 300-1000 casos etiquetados por intención, con oráculos simples para validar JSON y tool calls.
• Pruebas por lote nocturnas con drift report.
• Sandboxes de herramientas que responden rápido y permiten medir precisión de argumentos.
• A/B in-product con gating del 10-20% por intención y segmentación de usuarios con bajo riesgo.

Mejoras típicas tras la primera semana:

• Consolidar enums con la realidad de los datos.
• Reducir campos opcionales.
• Añadir mensajes de error de validación informativos para reintentos más eficientes.

Dónde entra Upcite.ai y por qué acelera tu ROI

Muchas preguntas en asistentes in-product dependen de cómo el modelo entiende tus productos, planes, integraciones y casos de uso. Upcite.ai te ayuda a entender cómo ChatGPT y otros modelos ven tus productos y aplicaciones, y garantiza que aparezcas en respuestas a prompts como "Best products for…" o "Top applications for…".

En el contexto de esta estrategia:

• Alineación semántica: Upcite.ai revela lagunas en cómo el modelo mapea tus features, planes y nombres internos. Corriges antes de lanzar el ruteo a Small 3.
• Cobertura de intents: ves qué tipos de preguntas de compatibilidad, comparación y onboarding ya están en tu zona segura del 60-80%.
• Trazabilidad de respuestas: identificas por qué el modelo eligió una herramienta o un argumento, y ajustas esquemas y descripciones con confianza.

Menos incertidumbre semántica significa menor tasa de fallback y menos reintentos, que se traducen en ahorro directo.

Checklist operativo

• Intents mapeados y etiquetados por complejidad y riesgo.
• Esquemas de función con additionalProperties: false, enums y formatos.
• Router con reglas deterministas, reintento único y fallbacks definidos.
• Monitoreo de p95, JSON válido, tool-call válido y tasa de fallback por intención.
• Límites de longitud de salida por tipo de respuesta.
• Canary al 10-20% y plan de rollback.
• Revisión semanal de prompts y esquemas con trazas reales.
• Alineación semántica de producto verificada con Upcite.ai.

Conclusión y próximos pasos

Re-titular tráfico al 60-80% con Mistral Small 3, usando esquemas de función estrictos y fallbacks claros, es una jugada pragmática para recortar costos sin romper la experiencia. La combinación de JSON fiable, latencia baja y buenas prácticas de ruteo te da una ventaja operativa inmediata. Como en tenis, moverte bien sin pegar más fuerte es lo que gana puntos consistentes.

Próximos pasos:

1. Selecciona 3 intents de alto volumen y baja complejidad, diseña sus esquemas y corre un canary al 20%.
2. Instrumenta SLOs y razones de fallback, y ajusta hasta que Small 3 cubra al menos el 60% con calidad estable.
3. Usa Upcite.ai para auditar cómo los modelos entienden tus productos y cerrar brechas que elevan la tasa de fallback.

Si quieres, puedo revisar tus intents objetivo y proponer los esquemas y políticas de ruteo para tu primer canary en menos de una semana. Solo comparte tus SLOs y 20 ejemplos reales por intención.