Arquitectura b\u00e1sica<\/h2>\n\n\n\n
El patr\u00f3n tiene tres componentes:<\/p>\n\n\n\n
- \n
- Router<\/strong>: El punto de decisi\u00f3n. Recibe el input y produce una clasificaci\u00f3n.<\/li>\n\n\n\n
- Handlers<\/strong>: Los flujos especializados. Cada uno maneja un tipo de input espec\u00edfico.<\/li>\n\n\n\n
- Fallback<\/strong>: La ruta por defecto. Maneja lo que el router no clasific\u00f3.<\/li>\n<\/ul>\n\n\n\n
La estructura es esencialmente un switch-case, pero en lugar de reglas est\u00e1ticas, la decisi\u00f3n puede tomarla un modelo de lenguaje, un clasificador ML, o l\u00f3gica determinista.<\/p>\n\n\n\n
![\"\"](\"https:\/\/atlaszn.com\/blog\/wp-content\/uploads\/2026\/06\/diagrama_routing-1024x683.webp\")
<\/figure>\n\n\n\n\n<\/code><\/pre>\n\n\n\nEl router puede estar en la entrada del sistema, clasificando la solicitud primaria, o en cualquier punto intermedio. De hecho, uno de los usos m\u00e1s efectivos es el mid-chain routing<\/em>: un pipeline avanza normalmente hasta que un resultado intermedio requiere una decisi\u00f3n. Por ejemplo, un sistema de an\u00e1lisis financiero extrae datos, y dependiendo de si detecta anomal\u00edas, deriva a un flujo de alerta o a uno de reporte est\u00e1ndar.<\/p>\n\n\n\n
Ejemplo: estructura de un router<\/h3>\n\n\n\n
Un router funcional en Python se reduce a esto:<\/p>\n\n\n\n
class Router:\n def __init__(self, llm_router, rule_patterns, handlers):\n self.llm_router = llm_router\n self.rule_patterns = rule_patterns # [(regex, categoria), ...]\n self.handlers = handlers # {categoria: handler_func}\n\n def classify(self, input_text: str) -> str:\n # 1. Intenta rule-based primero\n for pattern, category in self.rule_patterns:\n if pattern.search(input_text):\n return category\n\n # 2. Fallback a LLM-based\n return self.llm_router.route(input_text)\n\n def execute(self, input_text: str) -> str:\n category = self.classify(input_text)\n handler = self.handlers.get(category, self.handlers[\"default\"])\n return handler(input_text)<\/code><\/pre>\n\n\n\nTres capas: regla r\u00e1pida, LLM como red de seguridad, fallback como \u00faltimo recurso. Es el patr\u00f3n que m\u00e1s se repite en producci\u00f3n porque suele resolver la mayor\u00eda de los casos sin costo de tokens y deja que el modelo maneje lo impredecible.<\/p>\n\n\n\n
Los cuatro m\u00e9todos de routing<\/h2>\n\n\n\n
En la literatura sobre sistemas LLM, suelen distinguirse cuatro mecanismos principales de routing. Cada uno tiene un perfil de latencia, costo y precisi\u00f3n distinto. Elegir mal aqu\u00ed no rompe el sistema, lo hace ineficiente.<\/p>\n\n\n\n
LLM-based routing<\/h3>\n\n\n\n
El modelo mismo clasifica el input mediante un prompt estructurado y devuelve una etiqueta. Es el m\u00e1s flexible: entiende contexto, intenci\u00f3n impl\u00edcita, y generaliza a inputs no vistos.<\/p>\n\n\n\n
El problema es que cuesta. Cada decisi\u00f3n de routing es una llamada completa al modelo. En sistemas de alto volumen, eso se acumula r\u00e1pido. La mitigaci\u00f3n est\u00e1ndar es usar un modelo peque\u00f1o y r\u00e1pido exclusivamente para el router (un modelo de 1-3B par\u00e1metros suele ser suficiente para clasificaci\u00f3n de intenci\u00f3n). No necesitas GPT-5 para decidir si algo es una queja o una consulta.<\/p>\n\n\n\n
En LangChain se implementa con
RunnableBranch<\/code>. En LangGraph, las aristas condicionales del grafo son esencialmente routing basado en estado.<\/p>\n\n\n\nfrom langchain.chat_models import init_chat_model\nfrom langchain_core.runnables import RunnableBranch\n\nmodel = init_chat_model(\"qwen2.5-3b\", provider=\"ollama\")\n\nrouter = RunnableBranch(\n (\n lambda x: \"precio\" in x[\"input\"].lower() or \"costo\" in x[\"input\"].lower(),\n lambda x: f\"Consultando precios: {x['input']}\", # handler precios\n ),\n (\n lambda x: \"soporte\" in x[\"input\"].lower() or \"problema\" in x[\"input\"].lower(),\n lambda x: f\"Derivando a soporte: {x['input']}\", # handler soporte\n ),\n # Fallback: LLM clasifica lo que las reglas no atraparon\n model.bind(\n response_format={\"type\": \"json_schema\", \"json_schema\": {...}}\n ).pipe(lambda x: x.json()[\"categoria\"]),\n)\n\nresult = router.invoke({\"input\": \"Mi suscripci\u00f3n no funciona\"})<\/code><\/pre>\n\n\n\nN\u00f3tese que las ramas con lambda son reglas simples, solo la rama por defecto llama al modelo. Eso ya es el patr\u00f3n h\u00edbrido en practica: rule-based como filtro, LLM como catch-all.<\/p>\n\n\n\n
Embedding-based routing<\/h3>\n\n\n\n
El input se vectoriza y se compara contra embeddings pre-calculados de cada ruta. La ruta con mayor similitud sem\u00e1ntica gana.<\/p>\n\n\n\n
Esto funciona bien cuando las rutas son estables y conocidas de antemano. Si tienes 5 categor\u00edas de soporte, calculas sus embeddings una vez y el routing se reduce a una operaci\u00f3n de similitud coseno, b\u00e1sicamente instant\u00e1nea y gratuita.<\/p>\n\n\n\n
El problema aparece cuando las categor\u00edas son sem\u00e1nticamente cercanas o ambiguas. \u00abMi cuenta est\u00e1 bloqueada\u00bb vs \u00abno puedo iniciar sesi\u00f3n\u00bb, dos frases que comparten contexto pero requieren acciones distintas. La similitud coseno tiende a confundirlas; un LLM-based router distingue mejor los matices porque entiende intenci\u00f3n, no solo proximidad vectorial.<\/p>\n\n\n\n
import numpy as np\n\ndef cosine_similarity(a, b):\n return np.dot(a, b) \/ (np.linalg.norm(a) * np.linalg.norm(b))\n\n# Embeddings pre-calculados de cada ruta\nroute_embeddings = {\n \"precios\": embed(\"precios, tarifas, planes, costo, factura\"),\n \"soporte\": embed(\"error, problema, no funciona, ayuda, bug\"),\n \"ventas\": embed(\"demo, prueba, comprar, contactar, empresa\"),\n}\n\ndef route_by_embedding(input_text: str) -> str:\n input_vec = embed(input_text)\n scores = {\n route: cosine_similarity(input_vec, vec)\n for route, vec in route_embeddings.items()\n }\n return max(scores, key=scores.get)<\/code><\/pre>\n\n\n\nLa funcion
embed<\/code> puede ser cualquier modelo de embeddings, sentence-transformers, Ollama con nomic-embed, o incluso el API de OpenAI. Una vez calculados los embeddings de las rutas, el routing en si no requiere llamadas al modelo.<\/p>\n\n\n\nRule-based routing<\/h3>\n\n\n\n
if\/else, regex, match de keywords. Determinista, r\u00e1pido, barato.<\/p>\n\n\n\n
Y fr\u00e1gil. Un input que no coincide con ninguna regla cae al fallback. Si las reglas son exhaustivas, funciona perfecto pero \u00abexhaustivo\u00bb es una palabra peligrosa en producci\u00f3n. Los usuarios siempre encuentran formas de preguntar que no anticipaste.<\/p>\n\n\n\n
El uso correcto de rule-based routing no es como mecanismo principal, sino como primer filtro. Intercepta los casos obvios; \u00abprecio\u00bb, \u00abfactura\u00bb, \u00abcontrato\u00bb y deja que el LLM-based router maneje lo que sobra. Esa combinaci\u00f3n reduce el costo total significativamente.<\/p>\n\n\n\n
import re\n\nRULES = [\n (re.compile(r\"\\b(precio|costo|tarifa|factura|cobro)\\b\", re.I), \"precios\"),\n (re.compile(r\"\\b(error|problema|falla|no funciona|bug)\\b\", re.I), \"soporte\"),\n (re.compile(r\"\\b(demo|prueba gratuita|empresa|contactar)\\b\", re.I), \"ventas\"),\n (re.compile(r\"\\b(hola|buenos d[\u00edi]as|saludos)\\b\", re.I), \"saludo\"),\n]\n\ndef rule_route(text: str) -> str | None:\n for pattern, category in RULES:\n if pattern.search(text):\n return category\n return None # fallback necesario\n\nresult = rule_route(\"Tengo un error con mi factura\") # \u2192 \"soporte\"<\/code><\/pre>\n\n\n\nML model-based routing<\/h3>\n\n\n\n
Un clasificador discriminativo fine-tuned toma la decisi\u00f3n. No genera texto, eval\u00faa par\u00e1metros y devuelve una categor\u00eda. Es m\u00e1s barato que llamar a un LLM general-purpose y m\u00e1s preciso que embeddings simples.<\/p>\n\n\n\n
Pero requiere datos de entrenamiento y mantenimiento. Si las categor\u00edas de routing cambian con frecuencia, algo com\u00fan en productos en crecimiento, fine-tunar un clasificador cada vez que a\u00f1ades una ruta se vuelve costoso en ingenier\u00eda. Tiene m\u00e1s sentido en sistemas maduros donde el espacio de clasificaci\u00f3n es estable.<\/p>\n\n\n\n
Comparativa<\/h3>\n\n\n\n
M\u00e9todo<\/th> Latencia<\/th> Costo<\/th> Precisi\u00f3n<\/th> Flexibilidad<\/th> Mantenimiento<\/th><\/tr><\/thead> LLM-based<\/td> Media-Alta<\/td> Alto (tokens)<\/td> Alta-Muy alta<\/td> Muy alta<\/td> Bajo (cambiar prompt)<\/td><\/tr> Embedding-based<\/td> Baja<\/td> Bajo<\/td> Media<\/td> Media<\/td> Medio (recalcular embeddings)<\/td><\/tr> Rule-based<\/td> M\u00ednima<\/td> Cero<\/td> Muy alta (casos previstos)<\/td> Baja<\/td> Alto (mantener reglas)<\/td><\/tr> ML model-based<\/td> Baja<\/td> Medio (fine-tuning)<\/td> Alta<\/td> Media-Alta<\/td> Alto (reentrenar)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Routing en la pr\u00e1ctica: d\u00f3nde colocarlo<\/h2>\n\n\n\n
La posici\u00f3n del router en el flujo determina qu\u00e9 tipo de decisi\u00f3n toma. Hay tres ubicaciones comunes:<\/p>\n\n\n\n
- \n
- Entry-point routing<\/strong>: Clasifica la solicitud del usuario antes de cualquier procesamiento. Es el patr\u00f3n m\u00e1s visible: un chatbot que deriva entre \u00abventas\u00bb, \u00absoporte\u00bb y \u00abt\u00e9cnico\u00bb desde el primer mensaje.<\/li>\n\n\n\n
- Mid-chain routing<\/strong>: Aparece despu\u00e9s de uno o m\u00e1s pasos de procesamiento. Un pipeline de an\u00e1lisis primero extrae datos, y dependiendo de lo que encuentre, activa rutas distintas. Aqu\u00ed es donde Routing gana sobre Chaining puro: el pipeline se adapta a los datos en lugar de seguir un guion fijo.<\/li>\n\n\n\n
- Subroutine routing<\/strong>: Elige entre herramientas o sub-agentes. Function calling puede verse como una forma de subroutine routing donde el modelo selecciona una herramienta espec\u00edfica. La diferencia con Routing como patr\u00f3n es que subroutine routing suele ser una decisi\u00f3n puntual dentro de un flujo mayor, no el mecanismo principal de decisi\u00f3n.<\/li>\n<\/ul>\n\n\n\n
He visto sistemas que ponen routing en las tres capas simult\u00e1neamente, entry-point para la intenci\u00f3n general, mid-chain para decisiones basadas en datos, y subroutine para selecci\u00f3n de herramientas. Funciona, pero cada capa a\u00f1ade latencia. En producci\u00f3n, el overhead de tres decisiones secuenciales puede superar el beneficio de la especializaci\u00f3n.<\/p>\n\n\n\n
C\u00f3mo medir si tu routing funciona<\/h2>\n\n\n\n
Un router en producci\u00f3n sin m\u00e9tricas es una caja negra. No sabes si est\u00e1 tomando las decisiones correctas hasta que un usuario se queja. Estos son los indicadores m\u00ednimos:<\/p>\n\n\n\n
- \n
- Porcentaje de requests por ruta<\/strong>: La distribuci\u00f3n te dice si las categor\u00edas est\u00e1n equilibradas. Si el 70% de todo el tr\u00e1fico cae en una sola ruta, probablemente est\u00e1s subutilizando los handlers especializados o las descripciones de ruta est\u00e1n mal definidas.<\/li>\n\n\n\n
- Tasa de fallback<\/strong>: El porcentaje de inputs que el router no clasific\u00f3. Como regla pr\u00e1ctica, una tasa de fallback persistentemente alta suele indicar que las categor\u00edas o reglas necesitan revisi\u00f3n. Si el fallback crece con el tiempo, el espacio de clasificaci\u00f3n est\u00e1 cambiando y no lo est\u00e1s siguiendo.<\/li>\n\n\n\n
- Confianza media del router<\/strong>: En embedding-based, la puntuaci\u00f3n de similitud coseno. Cuando el proveedor lo expone, los log-probs de la etiqueta elegida o alguna puntuaci\u00f3n de confianza derivada del modelo. Una confianza media baja significa que el router opera en zona gris, clasifica, pero inseguro. Es se\u00f1al de que las rutas necesitan redefinici\u00f3n.<\/li>\n\n\n\n
- Rutas m\u00e1s confundidas<\/strong>: Cuando dos categor\u00edas compiten consistentemente por el mismo input, las descripciones de ruta se superponen. Revisar los pares de rutas con mayor tasa de clasificaci\u00f3n incorrecta (si tienes ground truth) es la forma m\u00e1s directa de encontrar ambig\u00fcedades.<\/li>\n\n\n\n
- Coste por decisi\u00f3n<\/strong>: En un router h\u00edbrido, esto te dice cu\u00e1ntos requests alcanzaron la capa LLM. Si el rule-based filtro intercepta el 80%, el coste real es una fracci\u00f3n del peor caso. Monitorear esto con el tiempo detecta si la distribuci\u00f3n de inputs est\u00e1 cambiando.<\/li>\n<\/ul>\n\n\n\n
No necesitas un dashboard completo. Un log estructurado con
{input_hash, ruta, metodo, confianza, timestamp}<\/code> y un resumen diario es suficiente para mantener el router bajo control. Lo que importa es detectar la deriva antes de que se convierta en un problema visible para el usuario.<\/p>\n\n\n\nAnti-patrones que rompen el routing<\/h2>\n\n\n\n
Los errores aqu\u00ed no son t\u00e9cnicos, son de dise\u00f1o. El c\u00f3digo de routing rara vez falla; falla la decisi\u00f3n de qu\u00e9<\/em> enrutar y cu\u00e1ndo<\/em>.<\/p>\n\n\n\n
- \n
- Todo por un agente monol\u00edtico<\/strong>: Si un solo agente maneja reservas, consultas, quejas y debugging, el contexto se contamina y el modelo produce resultados mediocres en todo. Routing existe para evitar esto.<\/li>\n\n\n\n
- Sin fallback<\/strong>: Inputs no clasificados causan fallos silenciosos o respuestas gen\u00e9ricas que frustran al usuario. La ruta por defecto no es opcional.<\/li>\n\n\n\n
- Rutas superpuestas<\/strong>: Si dos rutas describen \u00absoporte t\u00e9cnico\u00bb y \u00abproblemas con el producto\u00bb, el router oscila entre ellas. Las descripciones de ruta deben ser mutuamente excluyentes.<\/li>\n\n\n\n
- Over-routing<\/strong>: A\u00f1adir capas de routing donde un pipeline lineal resuelve el problema. Cada decisi\u00f3n de routing a\u00f1ade latencia. Si el flujo es predecible, Chaining es m\u00e1s barato y m\u00e1s r\u00e1pido.<\/li>\n<\/ul>\n\n\n\n
Cu\u00e1ndo NO usar Routing<\/h2>\n\n\n\n
Routing es soluci\u00f3n a un problema espec\u00edfico: inputs impredecibles que requieren flujos distintos. Si tu sistema procesa un tipo conocido de input en una secuencia fija, Routing a\u00f1ade complejidad sin retorno.<\/p>\n\n\n\n
Ejemplos concretos donde Routing sobra:<\/p>\n\n\n\n
- \n
- Un pipeline de extracci\u00f3n de datos de PDFs siempre sigue los mismos pasos.<\/li>\n\n\n\n
- Un sistema que genera res\u00famenes desde texto, no necesita decidir entre flujos.<\/li>\n\n\n\n
- Un classificador binario (spam\/no spam), es routing de dos ramas, pero un modelo directo es m\u00e1s eficiente que un router + dos handlers.<\/li>\n<\/ul>\n\n\n\n
La regla pr\u00e1ctica: si puedes describir el flujo como \u00absiempre haz A, luego B, luego C\u00bb, no necesitas Routing. \u00dasalo cuando la pregunta real es \u00ab\u00bfcu\u00e1l de estos caminos tomar?\u00bb.<\/p>\n\n\n\n
Routing y Prompt Chaining: no son rivales<\/h2>\n\n\n\n
- Sin fallback<\/strong>: Inputs no clasificados causan fallos silenciosos o respuestas gen\u00e9ricas que frustran al usuario. La ruta por defecto no es opcional.<\/li>\n\n\n\n
- Tasa de fallback<\/strong>: El porcentaje de inputs que el router no clasific\u00f3. Como regla pr\u00e1ctica, una tasa de fallback persistentemente alta suele indicar que las categor\u00edas o reglas necesitan revisi\u00f3n. Si el fallback crece con el tiempo, el espacio de clasificaci\u00f3n est\u00e1 cambiando y no lo est\u00e1s siguiendo.<\/li>\n\n\n\n
- Mid-chain routing<\/strong>: Aparece despu\u00e9s de uno o m\u00e1s pasos de procesamiento. Un pipeline de an\u00e1lisis primero extrae datos, y dependiendo de lo que encuentre, activa rutas distintas. Aqu\u00ed es donde Routing gana sobre Chaining puro: el pipeline se adapta a los datos en lugar de seguir un guion fijo.<\/li>\n\n\n\n
- Handlers<\/strong>: Los flujos especializados. Cada uno maneja un tipo de input espec\u00edfico.<\/li>\n\n\n\n