Cómo decidir cuándo el razonamiento puede sustituir la recuperación — y a qué coste

Tu enrutador elige entre una respuesta directa del modelo y una pasada de recuperación. GPT-5 y Gemini-3 almacenan el 95-98 % de los hechos probados en sus parámetros. El recuerdo directo aún falla en el 26-34 % de los hechos codificados, y el razonamiento recupera el 40-65 % de esos fallos. El compromiso es de tokens y latencia adicionales a cambio de una proporción menor de hechos recuperados. Multiplica la tasa de fallo por la tasa de recuperación para dimensionar el subconjunto de enrutamiento.

Ejecuta una evaluación de coste de recuperación sobre tu propio conjunto de hechos antes de modificar el enrutador. Convierte una decisión intuitiva en una regla de enrutamiento con un punto de equilibrio numérico.

El recuerdo directo marca el suelo

Empieza con los hechos a los que tu producto responde realmente. Extrae un conjunto etiquetado desde tickets de soporte, documentación del producto y preguntas conocidas de usuarios. Mantén las etiquetas simples: correcto, incorrecto o no respondible. Haz que el conjunto refleje el tráfico de producción, no un benchmark de juguete. Incluye las preguntas que generaron quejas de usuarios, no solo la documentación más limpia.

• Mide el recuerdo directo. Pide al modelo cada hecho sin razonamiento. Registra una tabla de acierto/fallo por hecho y una tasa de fallo en la que puedas confiar.
• Recupera los fallos con razonamiento. Envía solo los hechos fallidos a una pasada de razonamiento. La tabla de seguimiento debe mostrar acierto/fallo, recuento de tokens y latencia para cada hecho recuperado.
• Cuenta los hechos que requieren razonamiento. Divide los hechos que el razonamiento recupera tras un fallo directo entre el conjunto total de hechos. Solo el 10-20 % de los hechos evaluados necesita razonamiento, por lo que tenerlo siempre activo desperdicia cómputo. Esa proporción es una proporción de enrutamiento, no una configuración global del modelo.
• Calcula el coste del hecho recuperado. Multiplica los tokens de razonamiento del subconjunto enrutado por tu precio por millón de tokens, suma cualquier penalización por latencia y divide entre los hechos recuperados. Compara esa cifra con el coste de recuperación por respuesta. El resultado es un umbral de punto de equilibrio que puedes aplicar en el enrutador.

Activar el razonamiento para cada hecho paga por hechos que el recuerdo directo ya manejaba. Enruta solo el conjunto de fallos y, dentro de él, solo el subconjunto donde la respuesta justifica el gasto adicional.

El razonamiento se justifica por el valor recuperado

El razonamiento es más eficaz cuando la respuesta requiere encadenamiento, no un dato almacenado. Úsalo para los hechos que el recuerdo directo no captura y que siguen importando al usuario. Si el hecho fallido es un detalle de bajo valor, la recuperación o un mensaje de alternativa puede ser más económico.

Estratifica el conjunto de hechos por valor para el usuario. Un error de precio, una restricción de seguridad o una búsqueda crítica para el flujo de trabajo merece un umbral de recuperación más alto que un fallo de trivialidad. Asigna al enrutador un nivel de valor para cada hecho antes de que gaste tokens.

Vuelve a ejecutar la evaluación cuando cambies el modelo, el conjunto de hechos o el índice de recuperación. Un hecho que hoy es barato de recuperar puede ser caro de razonar mañana.

Los costes deciden el enrutador

Atribuye el coste a la respuesta, no al modelo. Para cada hecho recuperado, registra tokens de razonamiento, tokens de prompt, tokens de salida y latencia real. Convierte la latencia en el coste que tu producto realmente paga: espera del usuario, profundidad de cola o riesgo de timeout. Usa las mismas unidades en todos los modelos y rutas de recuperación.

Compara el coste del hecho recuperado con el de la recuperación. La recuperación tiene su propio precio: mantenimiento del índice, llamadas de embedding, reranking y la latencia de una pasada de búsqueda. Si el razonamiento cuesta menos que ese paquete para el subconjunto enrutado, puede sustituir la recuperación para esos hechos.

Establece un umbral por nivel. Un hecho de alto valor puede absorber más tokens y latencia que uno de bajo valor. Almacena el umbral como un número en el enrutador, no como una intuición en el documento de arquitectura.

Construye el enrutador en torno a una decisión, no a una preferencia de modelo. Devuelve el recuerdo directo cuando sea correcto. Enruta el razonamiento solo tras un fallo directo en un hecho de alto valor. Recurre a la recuperación o a un mensaje claro de incertidumbre cuando el razonamiento falle o el coste supere el umbral. Registra cada ruta para que la próxima evaluación parta de evidencia de producción, no de memoria o costumbre.