# Conocimiento de modelos y enrutamiento
Fundamentos de IA · módulo 02a
Lectura: ~17 min
Entregable: model-routing.md y un conjunto de cinco casos de regresión
> Distingues el modelo del proveedor, el arnés (harness), la herramienta, el conector y el flujo de trabajo que lo rodean. Registras la capacidad de contexto, el límite de salida, la fecha de corte del conocimiento, la privacidad, el estado del ciclo de vida y las evidencias con fecha. Fijas una tarea, comparas rutas con la misma comprobación de finalización, eliges una opción predeterminada y una alternativa, y guardas cinco casos de regresión para futuros cambios.
> Diagrama: Cómo funciona el módulo 2A: una tarea pasa por seis capas, una comparación fija y tres rutas evaluadas hasta un archivo de rutas fechado cuya fiabilidad mantiene un conjunto de regresión.
## Lo que vas a poder hacer
entregable :: lo que construyes
❯Crea `model-routing.md`. Registra una ruta predeterminada, una alternativa, una de alta precisión, un límite de privacidad y cinco casos de regresión. Para cada ruta, registra el proveedor, el identificador exacto, si es una instantánea fija o un nombre que se actualiza, el arnés, su versión, la fecha, un enlace a la fuente, la velocidad observada, evidencias del costo si las tienes y el soporte de herramientas o medios que necesita la tarea. Es una decisión fechada con sus motivos, no una clasificación. Cuando cambia un proveedor, arnés, prompt o herramienta, repites la comparación en lugar de discutir de memoria.
Los resultados publicados de los modelos se retiran por una razón más que por cualquier otra. El modelo estaba bien. El arnés no. El arnés (harness) es la aplicación en la que se ejecuta tu agente, y es el mecanismo que se midió mientras el nombre del modelo aparecía en el resultado. Casi toda puntuación que encuentras corresponde a un modelo más una configuración, un prompt y una tarea, publicada solo con el nombre del modelo.
El terreno también se mueve. Casi cada semana sale un nuevo modelo insignia, así que cualquier respuesta que memorices aquí será incorrecta en un mes. Un curso que te entrega un ganador te vende un comprobante con la fecha de caducidad impresa en tinta invisible.
Por eso este módulo te da un procedimiento. Toma una tarea real, mantenla fija, ejecuta tres rutas en condiciones idénticas, evalúalas con una comprobación que escribiste antes de ver ningún resultado y guarda todo en un archivo fechado que te permita repetir la prueba en veinte minutos.
El procedimiento sobrevive a todos los nombres de modelos que contiene.
## El entregable que vas a crear
Crea [model-routing.md](#model-routing). Registra una ruta predeterminada, una alternativa, una de alta precisión, un límite de privacidad y cinco casos de regresión.
Para cada ruta, registra el proveedor, el identificador exacto, si es una instantánea fija o un nombre que se actualiza, el arnés, su versión, la fecha, un enlace a la fuente, la velocidad observada, evidencias del costo si las tienes y el soporte de herramientas o medios que necesita la tarea.
Es una decisión fechada con sus motivos, no una clasificación. Cuando cambia un proveedor, arnés, prompt o herramienta, repites la comparación en lugar de discutir de memoria.
> Diagrama: El archivo de rutas: diez campos registrados para cada ruta; «desconocido» se trata como un valor completado, no como un espacio vacío.
## Seis piezas bajo un mismo nombre
La gente dice «el modelo hizo eso» cuando intervinieron seis piezas y solo una era el modelo. Indica cuál, porque la solución es distinta en cada capa.
| Pieza | Qué hace | Qué pregunta responde | En palabras sencillas |
| --- | --- | --- | --- |
| Modelo | Produce resultados a partir del texto y los archivos que recibió | ¿Qué capacidad encaja con esta tarea? | Lo que escribe la respuesta |
| Proveedor | Sirve ese modelo y fija su ciclo de vida, facturación y condiciones de datos | ¿Quién procesa mi solicitud? | La empresa en cuyos equipos se ejecuta |
| Arnés | Ejecuta la sesión y hace cumplir los controles | ¿Qué se puede leer, escribir o invocar aquí? | El programa en el que vive el agente |
| Herramienta | Realiza una operación acotada | ¿Qué pasa si se ejecuta esta llamada? | Un botón que puede pulsar el agente |
| Conector | Da acceso a un sistema externo | ¿Qué cuenta, qué permisos y datos de quién? | El cable a tu calendario o CRM |
| Flujo de trabajo | Sigue pasos fijos, a veces con una llamada al modelo dentro | ¿Podrían unas reglas simples hacerlo sin planificación abierta? | Una receta, no alguien que toma decisiones |
Desde la ventana de chat, los fallos de estas capas se ven iguales y necesitan soluciones completamente distintas. Un modelo puede clasificar mal mientras el arnés se comporta perfectamente. Un arnés puede dar a un buen modelo más permisos sobre archivos de los que necesitaba la tarea. Un conector puede devolver registros de hace tres semanas que el modelo después resume de forma impecable. Un flujo de trabajo fijo puede superar a un agente completo en seguridad y costo porque no puede inventarse un paso que nunca aprobaste.
Así que no arregles un problema de permisos cambiando de modelo ni la falta de una herramienta comprando un modelo más grande. Identifica la capa que falló, cambia una variable y vuelve a ejecutar el caso.
Ejecuta las mismas 28 tareas en tres arneses sin cambiar el modelo y cada uno dará una mediana de tiempo distinta. Trátalo como una prueba, no como una evaluación de referencia.
> Diagrama: Las seis capas como bandas alrededor de una tarea, cada una marcada con el fallo que produce y la reparación que le corresponde.
## Una etiqueta de capacidad es una hipótesis
Un modelo produce una continuación probable de lo que recibió. No consulta una base de datos antes de cada frase ni puede distinguir cuáles de sus propias frases son poco fiables. Una respuesta fluida no demuestra que sea correcta.
Las etiquetas de capacidad son la forma en que el sector clasifica los modelos. Lee cada una como una hipótesis que estás a punto de poner a prueba.
Una ruta rápida sirve para clasificar por categorías, extraer campos de documentos, hacer una primera reescritura y crear borradores breves que una persona leerá de todos modos. Una ruta de razonamiento, es decir, una que trabaja más tiempo antes de responder, sirve para restricciones que interactúan, tareas que se dividen en partes y detectar vacíos en una especificación. Una ruta de programación solo ayuda a trabajar en un repositorio si el arnés da acceso a los archivos y los comandos. De lo contrario, compraste un editor de texto muy caro. Una ruta multimodal admite imágenes, audio o video, pero aceptar una entrada no significa interpretarla bien; ahí es donde las fotos de productos reciben etiquetas equivocadas. Una ruta local se ejecuta en hardware que controlas. Te da privacidad y control; en calidad, no te da nada que no hayas probado.
Una trampa atrapa a las personas cuidadosas. Muchas configuraciones activan o desactivan por defecto el modo lento y deliberado de un modelo, y ese valor rara vez aparece en pantalla. Si comparas dos rutas con ajustes distintos, habrás medido el modo, no el modelo. Anota el ajuste junto al identificador.
Las etiquetas determinan qué pruebas ejecutas. Nunca te permiten saltártelas.
## Cuatro límites que deben mantenerse separados
Cuatro límites se reducen a «puede manejar mucho» o «se quedó sin espacio». Fallan en momentos distintos, y confundirlos te lleva a comprar cuando deberías estar editando.
**La capacidad de contexto** es la cantidad de entrada que el arnés y el modelo mantienen a la vez: tus instrucciones, la conversación hasta el momento, los archivos, la descripción de cada herramienta y lo que devolvieron esas herramientas. Una habitación más grande no es una memoria mejor.
**El límite de salida** es el tamaño máximo de una respuesta. Un modelo puede entender perfectamente la tarea y aun así detenerse a mitad de la redacción. Parece pereza, pero es un límite.
**La fecha de corte del conocimiento** es el punto en que terminó el entrenamiento. No es evidencia actual. Una herramienta conectada incorpora material más reciente, pero aun así hay que comprobar su fuente, alcance y fecha.
**El límite de herramientas** es lo que el arnés permite invocar realmente a esta ruta. Un modelo que describe de maravilla cómo añadir un evento al calendario no está conectado a tu calendario. Este es el límite que más se confunde con un fallo del modelo.
Si solo escribes «contexto largo» y «buen razonamiento» en tu archivo, ocultas la restricción que determina la tarea.
> Diagrama: Cuatro límites alrededor de una sesión: capacidad de entrada, tamaño máximo de una respuesta, frontera del entrenamiento y herramientas permitidas. Cada uno muestra su síntoma y el arreglo incorrecto al que se suele recurrir.
## Instantáneas, nombres que se actualizan y evidencias con fecha
Una instantánea es un identificador destinado a apuntar a una versión fija, de modo que la misma entrada siga produciendo el mismo tipo de resultado. Un nombre que se actualiza es una etiqueta sencilla que puede pasar a apuntar a un mecanismo más reciente sin que lo sepas: el comportamiento cambia mientras tu código, tu prompt y tus notas siguen idénticos.
Ambos cambian mientras los usas. Una instantánea se retira. Un nombre que se actualiza cambia un martes. Un arnés cambia sus valores predeterminados con una actualización. Una herramienta cambia el formato de los datos que devuelve. Nada de eso aparece como un error. Aparece como «el modelo empeoró», el diagnóstico equivocado más común en este campo.
Así que registra siempre el identificador exacto y la fecha junto al resultado. Una afirmación sin fecha sobre un modelo es un rumor.
Con fecha de referencia del 15 ago 2026, el [catálogo de modelos de OpenAI](https://developers.openai.com/api/docs/models) y el [catálogo de modelos de Gemini](https://ai.google.dev/gemini-api/docs/models) son puntos de partida fechados para consultar capacidades, límites, ciclo de vida, precios y tratamiento de datos. Consulta la documentación vigente del proveedor en lugar de una recopilación de un blog.
## Puntuaciones publicadas y por qué las tuyas serán distintas
Cuando te llegue una cifra impresionante, pregunta quién la produjo y en qué condiciones antes de preguntar qué significa.
Casi todas las cifras de los titulares de este sector proceden del proveedor que vende el modelo o de quien hace la afirmación. No son inventadas, pero las produjo alguien que quería un resultado concreto, con una configuración que controlaba y no describió. El mecanismo suele sostenerse cuando otras personas lo prueban. La cifra exacta casi nunca.
Cuatro cosas cambian una puntuación sin cambiar el modelo:
- El arnés en el que se ejecutó, que fue lo que provocó la retirada del resultado con la que empezó este módulo.
- El ajuste del modo deliberado, normalmente heredado de un valor predeterminado que nadie te mostró.
- El prompt y el formato de salida, donde una instrucción adicional convierte un fallo en un aprobado.
- La combinación de tareas, elegida por quien publicó la cifra.
Ninguna de las cuatro suele indicarse junto a la cifra. Por eso una puntuación publicada es un motivo para ejecutar tus propios cinco casos, nunca un sustituto. Cita la cifra indicando de quién procede: «esto viene de una persona, con su configuración y sus tareas». Tu propia comparación recibe el mismo trato, porque una cifra sin sus condiciones no se puede reproducir y, por tanto, no se puede comprobar.
> Diagrama: Anatomía de la puntuación publicada de un modelo: una cifra de titular con cuatro variables ocultas debajo, cada una capaz de cambiar la cifra sin cambiar el modelo.
## Elige según la tarea, no según la clasificación
Empieza con una tarea real y una comprobación de finalización, no con la tarea que te gustaría tener.
Cada semana exportas tu bandeja de soporte y necesitas sacar de ella cinco grupos de problemas de producto, cada uno con los identificadores de los tickets que incluye, un enlace a la evidencia y un campo de confianza. La comprobación de finalización, es decir, la condición visible que demuestra que funcionó: cada ticket aparece exactamente una vez, cada grupo apunta a una fila real de la fuente y una persona puede revisar las prioridades en pocos minutos. Conserva ese ejemplo durante el resto del módulo.
| Ruta | Necesidad de calidad | Necesidad de velocidad | Regla de privacidad y herramientas necesarias |
| --- | --- | --- | --- |
| Predeterminada | Agrupación correcta con enlaces a las fuentes que funcionan | Menos de dos minutos | Los datos permanecen en el espacio de trabajo aprobado, con lectura de archivos y salida estructurada |
| Alternativa | Agrupación aceptable que comprobará una persona | Utilizable mientras la predeterminada no esté disponible | Los mismos límites, sin excepciones, solo lectura de archivos |
| Alta precisión | Explica los conflictos y cita las filas que los sustentan | Se admite más tiempo | Ningún texto de clientes no aprobado sale de los límites, lectura de archivos y un paso de revisión opcional |
Tu copia añade a cada fila el identificador exacto del modelo y la fecha en que lo comprobaste, a partir de la documentación vigente del proveedor y no de memoria. Esos dos campos permiten repetir la prueba el mes que viene.
La tabla nunca pregunta qué modelo es el mejor. Pregunta qué debe demostrar cada ruta. Por eso una ruta que incumple la regla de privacidad no es una alternativa, y la columna de calidad no puede reclamar. Una ruta a la que le falta la herramienta requerida falla antes de empezar a evaluar la calidad. Una ruta demasiado lenta para el paso de revisión puede ser incorrecta aunque dé la mejor respuesta del grupo, porque una respuesta que nadie revisa antes del viernes no es una respuesta.
La fila de privacidad es una compuerta, no una puntuación, y ante la duda bloquea el paso. Cuando no puedes confirmar dónde procesa los datos una ruta o qué conservan sus registros, la respuesta es no, no «seguramente esté bien». «Ten cuidado con los datos de clientes» no es una regla. «Ningún texto de tickets sin anonimizar sale del espacio de trabajo aprobado» sí lo es, porque alguien que no confíe en ti puede comprobarlo.
## Compara tres rutas
Reserva unos 45 minutos para tu primera comparación y después ajusta según tu propia tarea. Tu agente puede ejecutar la mayor parte, y debería hacerlo, porque en las partes aburridas es donde una persona cansada se salta un control.
**Envía esto a tu agente:** abre [prompt-2a-model-routing.md](#prompt-2a-model-routing), sustituye cada campo entre corchetes por tu tarea real y ejecútalo. Fija el caso de prueba, mantiene idénticas las instrucciones y la lista de herramientas entre rutas, evalúa primero la comprobación de finalización y marca los campos desconocidos como desconocidos en lugar de adivinar. Lee la tabla comparativa y las rutas rechazadas antes de la recomendación, porque la recomendación es la parte que más probablemente suene segura y esté equivocada.
// O hazlo por tu cuenta
Los mismos siete pasos, a mano:
1. Fija un caso de prueba para una tarea acotada: una copia guardada de una entrada real de la que hayas eliminado todo lo sensible. Nunca empieces con un envío real, un pago, una eliminación o una edición en producción. La primera ejecución de una ruta es cuando menos sabes de ella.
2. Fija las instrucciones, la entrada, el formato de salida, la lista de herramientas y la comprobación de finalización. Los cinco, por escrito, antes de que los vea ninguna ruta.
3. Elige tres candidatos fechados a partir de la documentación vigente: una ruta rápida, una de razonamiento y una de herramientas o medios solo si la tarea la necesita.
4. Registra el identificador, si es una instantánea o un nombre que se actualiza, el arnés, su versión, el proveedor, la fecha, los enlaces a las fuentes, el ajuste del modo deliberado y los límites que importan aquí.
5. Ejecuta el mismo caso en cada ruta. Si la salida varía entre ejecuciones, ejecútalo dos veces y registra la variación.
6. Evalúa primero la comprobación de finalización. Después, la velocidad, las evidencias del costo, la privacidad, el comportamiento de rechazo, si se usaron o inventaron fuentes, si se llamó correctamente a las herramientas y cuánto trabajo de corrección necesitó.
7. Elige la ruta predeterminada y la alternativa a partir de esas evidencias. Si ninguna pasa, escribe «ninguna ruta aprobada» y corrige los límites de la tarea en lugar de buscar un cuarto modelo.
Una comparación cambia una variable. Deja que cambien dos a la vez y habrás producido una opinión, no un resultado.
> Diagrama: El montaje de una comparación justa: un caso de prueba fijo y una comprobación de finalización alimentan tres procesos idénticos que solo difieren en un punto, con los contaminantes habituales bloqueados.
## Haz visible la evaluación
Escribe los criterios de evaluación antes de la comparación, cuando aún no tienes interés en una respuesta concreta. Dos personas que miren el mismo resultado deberían llegar a la misma evaluación.
| Comprobación | Condición para aprobar | Evidencia que conservas |
| --- | --- | --- |
| Cobertura | Cada fila del caso de prueba aparece exactamente una vez | Recuento de filas e identificadores de salida |
| Fundamentación | Cada grupo apunta a una fila de la fuente que realmente lo respalda | Comprobación del enlace a la fuente, abierta y leída |
| Formato | La salida se puede analizar como la tabla o el JSON requerido | Resultado del analizador |
| Seguridad | El caso de rechazo se detiene sin llamar a ninguna herramienta | Registro de herramientas |
| Facilidad de revisión | Una persona puede inspeccionar los casos ambiguos en pocos minutos | Nota de quien revisa |
La fila de fundamentación tiene más peso del que parece. Un enlace no es respaldo. Los modelos citan páginas reales que no contienen la afirmación asociada, y eso supera cualquier comprobación que solo confirme que el enlace se abre. Abre la fila y confirma que dice lo que afirma la salida, o estarás midiendo el formato de las URL.
Una prosa mejor no gana una tarea en la que faltaron filas de la fuente. Una ruta que no puede producir el formato requerido necesita una capa de adaptación u otra ruta. Una ruta que falla el caso de seguridad ha fallado, sea cual sea su puntuación en lo demás.
## Elige qué medir
La calidad no es una sola cifra. Usa el conjunto mínimo de mediciones que cambiaría tu decisión. Cada medición adicional es una que dejarás de registrar para la tercera semana.
Para redacción: respaldo factual, seguimiento de instrucciones, revisiones necesarias y cualquier afirmación que no podrías dejar publicar. Para código: pruebas superadas, errores de tipos, archivos tocados que no deberían haberse tocado y lo que detectó la revisión. Para extracción: precisión de los campos, campos ausentes, duplicados y si la salida se puede analizar. Para una tarea con herramientas: si se llamó a la herramienta, si sus argumentos estaban dentro del conjunto permitido y si el resultado se usó o se inventó.
**La velocidad** es el tiempo hasta tener un resultado utilizable, no el tiempo de respuesta del proveedor. Cuenta la espera en cola, la carga de archivos, los reintentos y las correcciones. La ruta rápida que necesita diez minutos de arreglos es la ruta lenta.
**El costo** es evidencia que puedes ver, no una suposición basada en lo grande que suena el modelo. El precio anunciado por solicitud rara vez domina la factura. Un bucle del agente reenvía todo su contexto en cada paso, así que la forma del bucle determina el gasto más que el precio. Suele haber también un segundo modelo: tareas auxiliares como resumir una página web larga suelen usar por defecto tu modelo principal, así que pagas tarifas prémium por tareas de archivo. Busca ese ajuste antes de decir que una ruta es cara. Cuando un arnés oculta el costo, escribe desconocido y después configura una alerta de facturación o mide un lote pequeño.
**La privacidad** es una compuerta, no una puntuación. Una ruta fuera de los límites aprobados no puede compensarlo escribiendo mejor. Registra qué ve, dónde se procesa si está documentado, qué registros lo conservan y qué permisos de conectores heredó.
## Mantén una comparación justa
No des a una ruta un prompt más largo, una lista de herramientas más amplia ni un segundo intento que las demás no tuvieron. Si una ruta necesita otras palabras para obedecer el formato, incluye un requisito equivalente en todas y anota qué fue distinto.
No compares una ruta con recuperación de información con otra sin los documentos fuente y lo llames una comparación de modelos. Pusiste a prueba la configuración de fundamentación tanto como el modelo. Conserva ese experimento y dale el nombre correcto.
No borres la salida extraña. La variación es evidencia. Una ruta que pasa una vez y falla dos requiere una decisión distinta de una que pasa siempre, y el promedio destruye la única señal que permite distinguirlas.
## Conserva cinco casos de regresión
Un caso de regresión es una prueba guardada que vuelves a ejecutar después para detectar algo que antes funcionaba y dejó de hacerlo sin avisar. Cinco bastan para ser honesto y son pocos como para que realmente los ejecutes.
Conserva un caso normal, uno límite, uno de rechazo o seguridad, uno de herramientas y un fallo conocido de tu comparación. Para cada uno: la entrada fija, el comportamiento esperado, la salida real, la evaluación, el identificador de la ruta, la fecha y una nota de revisión de una línea. Usa casos de prueba anonimizados en lugar de secretos reales de clientes, porque estos archivos sobreviven a tu recuerdo de lo que contienen.
Vuelve a ejecutar el conjunto tras cambiar el modelo, el proveedor, la versión del arnés, el modo de permisos, las instrucciones, las herramientas, el alcance de un conector, el esquema de salida o una skill. Cada elemento de esa lista ha provocado un cambio silencioso de comportamiento a alguien.
Cuando falle un caso, clasifica el fallo antes de corregirlo. Un caso de prueba débil, una instrucción contradictoria, una herramienta ausente y un límite real del modelo se ven como «empeoró», y todos necesitan reparaciones distintas. Si te equivocas de diagnóstico, cambiarás de modelo para corregir una errata de tu propio prompt.
> Diagrama: Los cinco casos de regresión con su entrada fija y el comportamiento esperado, y los nueve cambios que obligan a repetir todo el conjunto.
## Decide cuándo cambiar de ruta
Cambia de ruta cuando cambie la tarea, no cuando salga un modelo nuevo. Un nuevo límite de privacidad, un nuevo esquema de salida, un nuevo tipo de fuente, un lote más grande o permisos de herramientas ampliados pueden invalidar una ruta que hoy funciona bien.
Conserva la predeterminada mientras supere el conjunto de regresión y respete las restricciones. Usa la alternativa cuando la predeterminada no esté disponible y la tarea siga dentro del alcance que probaste. Usa la ruta de alta precisión cuando equivocarse cueste más que el tiempo y el gasto adicionales.
Cambiar tiene un costo oculto. Los arneses guardan en caché el trabajo repetido para ahorrarte dinero, y esa caché está vinculada al modelo. Un cambio a mitad de la tarea empieza en frío y vuelve a pagar el precio completo por un contexto que ya se había almacenado. Cambiar de vez en cuando está bien. Cambiar dentro de una sesión larga es una factura que no tenías intención de aceptar.
Si nada pasa, acota la tarea. Divídela para que el código convencional haga la preparación fija y el modelo solo haga la parte que exige criterio. Añade un archivo fuente. Cambia la comprobación de finalización para que mida el riesgo que te importa. O deja a una persona a cargo un mes más. «Ninguna ruta aprobada» es un resultado real y mejor que una ruta que aprobaste porque te cansaste de probar.
## Cómo es un buen resultado
Tu archivo de rutas nombra una predeterminada, una alternativa y una de alta precisión sin fingir que ninguna es universal. Tus cinco casos pueden fallar de forma visible, lo que significa que los construiste para poder fallar y no para aprobar. Puedes decir por qué la ruta encaja con esta tarea, qué evidencias la respaldan, cuándo volverás a ejecutarla y qué única restricción te haría descartarla.
### Nota sobre el arnés
Si tu arnés funciona de otra manera, sigue su documentación vigente en lugar de esta página. Registra el arnés, su versión y la fecha en tu entregable.
Termina el archivo de rutas con una línea: «Volver a ejecutar el \[fecha\], o antes si cambia el modelo, el proveedor, el arnés, las herramientas o el límite de privacidad».
Esa línea convierte una buena tarde de pruebas en un hábito operativo. Mide, publica, descubre que el mecanismo produjo la cifra y corrígela poniendo tu nombre. Lo que tienes es la forma más barata de acertar: un caso de prueba que puedes repetir, una comprobación que escribiste antes de tener un favorito y un archivo que te dice en qué fecha caducó su confianza.
// prompt
Laboratorio de enrutamiento de modelos
```
Este laboratorio permite poner a prueba la elección de modelos. La tarea y el caso de prueba fijan la comparación. La tabla de rutas expone las suposiciones sobre el ciclo de vida y la privacidad. Las reglas de evaluación definen qué es aprobar. El esquema de salida convierte una recomendación en un registro que puedes volver a ejecutar.
No uses datos de clientes reales ni un destino de producción.
```xml
Elige y prueba rutas para una tarea acotada. No envíes, gastes, elimines, publiques ni cambies producción.
Rol: [tu rol]
Límite de privacidad: [datos que pueden salir del espacio de trabajo aprobado]
Compuerta humana: [acción que necesita aprobación]
Tarea: [una tarea real]
Caso de prueba: [ruta con datos anonimizados]
Comprobación de finalización: [condición observable que demuestra el éxito]
Formato de salida: [esquema o estructura del archivo]
Predeterminada: [proveedor, identificador del modelo, instantánea o alias]
Alternativa: [proveedor, identificador del modelo, instantánea o alias]
Alta precisión: [proveedor, identificador del modelo, instantánea o alias]
Arnés y versión: [arnés y versión]
Enlaces a catálogos con fecha: [URL]
Mantén fijos el caso de prueba, las instrucciones, el formato de salida, la lista de herramientas y la comprobación de finalización.
Registra el proveedor, el identificador, la instantánea o el alias, el arnés, la fecha, la capacidad de contexto,
el límite de salida, la fecha de corte del conocimiento si está documentada, el soporte de herramientas, las condiciones de privacidad,
la latencia, las evidencias del costo si están disponibles y el comportamiento ante fallos.
Ejecuta cada ruta sobre el mismo caso y evalúa la comprobación de finalización antes de recomendar una.
No inventes límites, precios ni capacidades actuales. Marca los campos desconocidos como desconocidos.
Rechaza cualquier ruta que incumpla el límite de privacidad o carezca de una herramienta requerida.
normal_case: [entrada y comportamiento esperado]
edge_case: [entrada y comportamiento esperado]
refusal_or_safety_case: [entrada y comportamiento esperado]
tool_case: [entrada, herramienta permitida, comportamiento esperado]
known_failure: [entrada y fallo esperado]
Devuelve una tabla comparativa, una recomendación de ruta predeterminada, alternativa y de alta precisión,
las rutas rechazadas con sus motivos, cinco registros de regresión, los desencadenantes para repetir la prueba
y las preguntas pendientes.
```
Sustituye cada campo entre corchetes antes de ejecutarlo. El caso de prueba y la comprobación de finalización importan más que los nombres de los modelos. Después, inspecciona la salida, guarda la tabla de rutas y los cinco casos en `model-routing.md`, y conserva los enlaces a fuentes con fecha junto a los identificadores.
El modelo puede presentar un ganador con seguridad antes de haber evaluado la comprobación de finalización. Ignora la clasificación hasta inspeccionar la tabla comparativa, las rutas rechazadas y los cinco registros de regresión. Si un campo obligatorio es desconocido, mantenlo así y decide si esa incertidumbre bloquea la aprobación.
Cambia los campos específicos de la tarea para otro caso de uso. Para código, usa una copia pequeña del repositorio y, como comprobación de finalización, las pruebas junto con el alcance de los archivos tocados. Para investigación, usa un conjunto de fuentes con fecha y exige los fragmentos que sustentan las afirmaciones. Para imágenes, añade referencias, elementos que deben mantenerse fijos y comprobaciones de fidelidad. La estructura permanece igual porque cada ruta sigue necesitando una entrada fija, un resultado comprobable y unos límites registrados.
## compuerta de dominio
- ▸Tengo una ruta predeterminada, una alternativa, una de alta precisión, una restricción de privacidad y un conjunto de evaluación de cinco casos