Motores de recomendación para aplicaciones de agentes de IA: de cero a producción

Los motores de recomendación solían parecer un tema especializado de ML: filtrado colaborativo, factorización de matrices, modelos de ranking, métricas offline y pruebas A/B. Los agentes de IA cambiaron la forma de los productos que los rodean.

En una aplicación moderna con agentes, las recomendaciones no son solo «elementos que podrían gustarte». Pueden ser herramientas que llamar, documentos que leer, próximos pasos que sugerir, productos que agrupar, personas a las que derivar una tarea, workflows que automatizar, prompts que reutilizar o agentes a los que delegar. El recomendador ya no es solo un modelo detrás de un carrusel. A menudo es la capa de decisión que ayuda a un agente a elegir qué hacer después.

Eso hace que los sistemas de recomendación sean más importantes, no menos. El mejor patrón para producción sigue siendo aburrido en el mejor sentido: recopilar eventos limpios, recuperar un conjunto manejable de candidatos, ordenarlo con las features adecuadas, aplicar restricciones de negocio y seguridad, observar los resultados y mejorar mediante la evaluación. La capa de agentes debería hacer que este sistema sea más interactivo y explicable, no reemplazarlo por completo con un prompt gigante.

TL;DR

• Un recomendador en producción es un sistema, no un modelo. Incluye recopilación de eventos, identidad, catálogos de elementos, retrieval, ranking, filtrado, exploración, evaluación, observabilidad, seguridad y ciclos de retroalimentación del producto.
• Empieza por lo simple. Un MVP basado en reglas o popularidad suele superar a un modelo complejo si tienes pocos datos, tu catálogo es pequeño o tu PM todavía necesita descubrir qué significa «bueno».
• La mayoría de los sistemas maduros usan una arquitectura de varias etapas: recuperan muchos candidatos a bajo costo, ordenan con cuidado un conjunto más pequeño y después aplican restricciones y lógica de presentación. Tanto el artículo de YouTube sobre recomendaciones con deep learning como los ejemplos de producción de NVIDIA Merlin usan esta estructura de retrieval y ranking (artículo de YouTube, ejemplo de NVIDIA Merlin).
• Los agentes de IA son útiles alrededor del recomendador: para obtener preferencias, refinar resultados mediante conversación, dar explicaciones, planificar workflows, orquestar herramientas y ayudar con el arranque en frío. No se les debe permitir omitir silenciosamente el ranking, las políticas, los permisos o las evals.
• Las métricas offline son necesarias, pero incompletas. La calidad de las recomendaciones en producción requiere pruebas online, análisis contrafactual, guardrails, análisis de trazas, métricas de negocio y monitoreo de los ciclos de retroalimentación a largo plazo.

Qué aprenderás aquí

• Cómo funcionan los motores de recomendación, desde cero hasta producción.
• Por qué retrieval, ranking, filtrado y ordenamiento son tareas distintas.
• Dónde encajan el filtrado colaborativo clásico, la factorización de matrices, los modelos two-tower y wide-and-deep, los LLM y los agentes.
• Cómo diseñar una arquitectura de recomendación para aplicaciones complejas con agentes.
• Qué evaluar antes del lanzamiento y qué monitorear después.
• Un pequeño ejemplo de código para un endpoint de recomendación híbrido.
• Las principales brechas que los equipos suelen pasar por alto al pasar de una demo a producción.

La revisión de fuentes

Para este artículo revisé fuentes primarias y otras cercanas a las primarias: artículos clásicos sobre recomendadores industriales de Amazon, Netflix, Google/YouTube y Google Play; materiales oficiales de TensorFlow Recommenders y NVIDIA Merlin; guías de OpenAI, Anthropic, Google Cloud, Microsoft, OWASP y OpenTelemetry para agentes de IA en producción; y estudios recientes de revisión sobre sistemas de recomendación impulsados por LLM y agentes.

El patrón más claro entre las fuentes es este:

• Los sistemas de recomendación necesitan una arquitectura por etapas porque la escala, la actualidad de los datos y la precisión imponen exigencias distintas.
• Los sistemas de agentes necesitan controles explícitos porque la autonomía, el uso de herramientas y la confianza del usuario imponen exigencias distintas.
• La intersección necesita ambas disciplinas: el rigor de los sistemas de recomendación para las decisiones de ranking y el rigor de la ingeniería de agentes para el contexto, las herramientas, la seguridad, las trazas y el control humano.

El modelo mental

Un recomendador responde a una de estas preguntas:

Given:
  user or account context
  current task or session context
  item or action catalog
  business constraints
  safety constraints

Return:
  a ranked set of useful next options

En una aplicación de medios, las opciones son videos o canciones. En una aplicación de comercio electrónico, son productos o paquetes. En un producto con agentes de IA, pueden ser mucho más operativas:

• ¿Qué documento debería leer el agente a continuación?
• ¿Qué herramienta debería llamar?
• ¿Qué workflow debería sugerir?
• ¿Qué respuesta de soporte debería redactar?
• ¿Qué producto debería recomendar?
• ¿Qué persona debería aprobar el siguiente paso?
• ¿Qué subagente especializado debería encargarse de esta parte?

Por eso los sistemas de recomendación y los sistemas de agentes están empezando a solaparse.

Un flujo de recomendación para producción

La mayoría de los equipos deberían pensar en etapas:

Events + Catalog + User State
          |
          v
Candidate retrieval
  popularity, content, vector search,
  collaborative filtering, two-tower model
          |
          v
Filtering
  permissions, inventory, safety,
  freshness, policy, dedupe
          |
          v
Ranking
  relevance, intent, context,
  predicted value, uncertainty
          |
          v
Re-ranking / ordering
  diversity, exploration,
  business rules, UX constraints
          |
          v
Presentation + feedback events

Este patrón aparece una y otra vez en los sistemas de producción. El artículo sobre recomendaciones de YouTube describe una red de generación de candidatos seguida de una red de ranking, porque un sistema con un corpus enorme necesita una forma económica de reducir las opciones antes de aplicar features más ricas (artículo de YouTube). NVIDIA Merlin describe los workflows de recomendación en producción como procesos de varias etapas que incluyen preprocesamiento, retrieval, filtrado, ranking y ordenamiento (ejemplo de varias etapas de NVIDIA Merlin).

La versión con agentes agrega una capa más:

User goal
   |
   v
Agent runtime
   |
   +--> asks recommender for options
   +--> explains or refines user preferences
   +--> applies approvals for risky actions
   +--> calls tools only inside permission boundaries
   |
   v
Ranked recommendation or next action

El recomendador debe seguir siendo un servicio controlado. El agente puede pedir candidatos, explicar por qué una opción es buena o ayudar al usuario a refinar su intención. Pero no debe inventar opciones no autorizadas ni omitir verificaciones de políticas porque la respuesta generada sonaba convincente.

Etapa 0: Define la tarea de recomendación

Antes de pensar en modelos, decide qué significa «bueno».

Para los PMs, esto significa escribir el contrato de recomendación:

• ¿Quién recibe la recomendación?
• ¿Qué elemento o acción se recomienda?
• ¿Qué tarea del usuario ayuda a resolver?
• ¿Qué nunca se debe recomendar?
• ¿Cuál es la métrica de éxito?
• ¿Cuál es la métrica de daño?
• ¿Qué tan rápido necesita reaccionar el sistema?

Para los ingenieros, esto se convierte en una interfaz:

type RecommendationRequest = {
  userId: string;
  sessionId?: string;
  intent?: string;
  surface: "home" | "search" | "chat" | "agent_action";
  limit: number;
  constraints?: {
    allowedItemTypes?: string[];
    requireApproval?: boolean;
    excludeIds?: string[];
  };
};

type Recommendation = {
  id: string;
  type: "article" | "product" | "tool" | "workflow" | "agent";
  score: number;
  reason: string;
  requiresApproval: boolean;
};

Este contrato es sencillo, pero evita el caos. Tu agente puede pedir «el mejor workflow a seguir», pero el recomendador sigue devolviendo objetos tipados con puntuaciones, motivos e indicadores de aprobación.

Etapa 1: Empieza con una línea base

El primer recomendador no necesita deep learning. Necesita crear un ciclo de retroalimentación útil.

Buenas líneas base para un MVP:

• Elementos populares en la categoría actual.
• Elementos usados recientemente por el mismo usuario.
• Elementos similares según etiquetas o embeddings.
• Selecciones editoriales controladas por los PMs.
• Reglas basadas en la etapa del ciclo de vida o el tipo de tarea.
• Recomendaciones de elemento a elemento para catálogos pequeños.

El trabajo inicial de Amazon sobre filtrado colaborativo de elemento a elemento sigue valiendo la pena porque se enfoca en la escala y el ajuste al producto, no en lo llamativo del modelo. La decisión clave fue comparar elementos similares en lugar de buscar usuarios similares al momento de la solicitud, lo que hizo viables las recomendaciones para un catálogo enorme (artículo de Amazon sobre recomendaciones de elemento a elemento).

Una línea base para el MVP te da algo más valioso que una arquitectura sofisticada: logs. Sin eventos de exposición, clic, descarte, conversión y satisfacción, tu siguiente modelo estará, en gran medida, adivinando.

Etapa 2: Recopila los eventos adecuados

Los datos de recomendación no son solo «en qué hizo clic el usuario». Los clics son útiles, pero están sesgados por lo que decidiste mostrar.

Como mínimo, registra:

• exposure: se mostró el elemento.
• position: dónde apareció.
• surface: inicio, búsqueda, chat, checkout, editor, panel de agentes.
• request_context: intención, filtros, configuración regional, dispositivo, estado de la cuenta.
• action: hacer clic, guardar, comprar, ejecutar, aprobar, descartar, ocultar, calificar.
• outcome: éxito, reembolso, escalamiento, finalización de la tarea, señal de abandono.
• policy_result: bloqueado, permitido, requiere aprobación.
• model_version y ranking_version.

Esto importa porque los sistemas de recomendación generan sus propios datos de entrenamiento futuros. Si solo muestras elementos populares, estos reciben más interacciones y tus logs te dirán que sigas mostrándolos. El sesgo de posición es el ejemplo más sencillo: los elementos mejor posicionados reciben más atención en parte porque están mejor posicionados, no solo porque son mejores.

La lección para producción: registra lo que mostraste, no solo en qué hicieron clic los usuarios.

Bad log:
  user clicked item_42

Useful log:
  request r123 showed [item_42, item_7, item_9]
  positions [1, 2, 3]
  user clicked item_42
  item_7 was ignored
  ranker=v4.2
  policy=allowed
  session_intent="compare pricing"

Etapa 3: Retrieval de candidatos

El retrieval de candidatos es la etapa rápida y amplia. Su trabajo es reducir millones de elementos posibles a cientos o miles de candidatos plausibles.

Métodos comunes de retrieval:

• Popularidad por segmento.
• Búsqueda basada en contenido mediante texto, etiquetas, metadatos o embeddings.
• Filtrado colaborativo de elemento a elemento.
• Factorización de matrices.
• Búsqueda aproximada de vecinos más cercanos sobre embeddings de usuarios y elementos.
• Modelos neuronales two-tower para retrieval.
• Retrieval asistido por LLM para el arranque en frío o la intención expresada en lenguaje natural.

La factorización de matrices es una técnica clásica de filtrado colaborativo: aprende vectores latentes para usuarios y elementos y después asigna puntuaciones según la similitud entre vectores. La época del Netflix Prize hizo famosa esta familia de métodos, especialmente porque podía incorporar feedback implícito y otras señales además de las calificaciones explícitas (Koren, Bell y Volinsky).

El retrieval two-tower es el equivalente moderno que muchos ingenieros conocen primero. Una torre codifica al usuario o la consulta, otra codifica el elemento y el retrieval se realiza mediante una búsqueda de vecinos más cercanos. TensorFlow Recommenders describe este patrón directamente en su tutorial de retrieval (retrieval con TensorFlow Recommenders).

User tower                         Item tower
----------                         ----------
user history                       title
session intent       ----->        category
account features                   metadata
current context                    content embedding
     |                                  |
     v                                  v
 user embedding                    item embedding
     |                                  |
     +---------- dot product -----------+
                    |
                    v
              candidate set

En las aplicaciones con agentes, el retrieval suele ser híbrido. Puedes recuperar:

• documentos por similitud semántica,
• workflows según la intención de la tarea,
• herramientas según su capacidad,
• productos según las características del catálogo,
• acciones exitosas anteriores según la similitud entre usuarios.

La regla práctica: el retrieval debe optimizar el recall. Puede ser aproximado. El ranking será más preciso.

Etapa 4: Filtrado y políticas

El filtrado es donde entra en juego la realidad de producción.

Filtra antes del ranking cuando un elemento nunca deba ser elegible:

• el usuario no tiene permiso,
• el elemento está agotado,
• el documento es confidencial,
• la herramienta está deshabilitada,
• el workflow no está disponible en esta región,
• el contenido infringe las políticas,
• la acción requiere aprobación y no existe una vía para obtenerla.

Filtra después del ranking cuando la regla dependa de la lista final:

• eliminar elementos similares duplicados,
• limitar la cantidad de elementos de una categoría,
• garantizar diversidad,
• agregar espacios de exploración,
• evitar repetir la misma recomendación con demasiada frecuencia.

En una aplicación con agentes, esto no es opcional. La guía de seguridad para agentes de OpenAI destaca la inyección de prompts y las llamadas riesgosas posteriores a herramientas como cuestiones importantes de diseño, y la guía de seguridad de agentes de IA de OWASP señala la inyección de prompts, el abuso de herramientas, la escalada de privilegios y la exfiltración de datos como riesgos importantes (seguridad de agentes de OpenAI, guía de seguridad de agentes de IA de OWASP).

Eso significa que tu recomendador no solo debe responder «¿qué es relevante?». También debe responder «¿qué está permitido?».

Etapa 5: Ranking

El ranking es la etapa más lenta y precisa. Recibe un conjunto manejable de candidatos y los ordena usando features más ricas.

Las features de ranking suelen incluir:

• historial de interacciones entre el usuario y el elemento,
• intención de la sesión actual,
• qué tan reciente es el elemento,
• calidad del creador o la marca,
• precio, margen o disponibilidad,
• coincidencia semántica,
• validación social,
• probabilidad prevista de clic o conversión,
• satisfacción prevista a largo plazo,
• puntuaciones de seguridad o confianza,
• incertidumbre.

Los modelos wide-and-deep son un puente histórico útil en este punto. El artículo Wide & Deep de Google describe cómo combinar la memorización de cruces de features lineales de la parte wide con la generalización de embeddings neuronales profundos, y reporta su uso en producción en Google Play (artículo Wide & Deep). La arquitectura es antigua para los estándares actuales, pero la lección de producto sigue vigente: los modelos de ranking de recomendadores suelen necesitar tanto patrones exactos conocidos como capacidad de generalización a nuevas combinaciones.

En muchos equipos de producción, el modelo de ranking evoluciona así:

Rules
  -> logistic regression / gradient boosted trees
  -> matrix factorization features
  -> deep ranking model
  -> multi-task ranker
  -> contextual bandit or online learner for selected surfaces

No te saltes pasos solo porque el último suena más avanzado. Un modelo de ranking con gradient boosting y buena instrumentación puede superar a un modelo profundo que se entiende poco.

Etapa 6: Re-ranking, diversidad y exploración

Un modelo de ranking puede producir una lista técnicamente correcta pero aburrida.

Si todos los elementos recomendados son casi idénticos, los usuarios pueden hacer clic una vez y luego perder la confianza. Si el sistema nunca explora, los elementos nuevos nunca tienen una oportunidad justa. Si la lista solo optimiza los clics a corto plazo, puede perjudicar la retención o la satisfacción del usuario a largo plazo.

Objetivos comunes del re-ranking:

• diversificar categorías,
• diversificar creadores o proveedores,
• incluir elementos recientes,
• reservar espacios de exploración,
• limitar las recomendaciones repetidas,
• equilibrar la relevancia con las restricciones de negocio,
• evitar inferencias sensibles o manipuladoras.

Los bandits contextuales ofrecen una forma fundamentada de gestionar la exploración y la explotación, especialmente cuando el contenido cambia rápido. El artículo sobre LinUCB de Yahoo News planteó la recomendación personalizada de noticias como un problema de bandits contextuales, en el que el sistema elige artículos, observa los clics como feedback y aprende mientras atiende a los usuarios (Li et al., 2010). En la práctica, los bandits son potentes, pero exigentes desde el punto de vista operativo: necesitas registros cuidadosos, guardrails y evaluación porque el modelo aprende de exposiciones reales.

Dónde encajan los agentes de IA

Los agentes pueden mejorar los productos de recomendación de cinco maneras importantes.

1. Obtención de preferencias

El arranque en frío es difícil porque el sistema sabe poco sobre un usuario o elemento nuevo. Un agente puede hacer preguntas específicas:

Agent:
  "Are you looking for a quick prototype, a production architecture,
   or a research-heavy comparison?"

User:
  "Production architecture."

Recommender context:
  intent=production_architecture
  depth=advanced
  item_types=[article, template, repo, workflow]

El agente convierte una intención vaga en features estructuradas que el recomendador puede usar.

2. Refinamiento conversacional

Las interfaces tradicionales de recomendación obligan a los usuarios a hacer clic en filtros. Las interfaces con agentes permiten que los usuarios digan:

• «Más práctico, menos académico».
• «Muéstrame opciones más baratas».
• «Ya leí eso».
• «Prefiero ejemplos en Python».
• «Excluye todo lo que requiera Kubernetes».

El agente debe traducir esos ajustes en restricciones y features, y volver a llamar al recomendador.

3. Explicación

Los LLM son buenos dando explicaciones, pero estas deben basarse en las features del modelo de ranking y en las decisiones de políticas.

Mejor:

"I recommended this because it matches your current FastAPI stack,
uses Postgres like your project, and has the highest success rate
among similar teams."

Riesgoso:

"I recommended this because I think it is perfect for you."

La primera explicación se puede auditar. La segunda son puras impresiones con signos de puntuación.

4. Planificación de workflows

En aplicaciones complejas, el recomendador puede devolver posibles próximos pasos:

• crear un ticket,
• ejecutar un diagnóstico,
• solicitar una aprobación,
• enviar un mensaje,
• asignar un revisor,
• abrir un dashboard,
• iniciar un workflow de remediación.

El agente puede planificar a partir de esas opciones, pero los permisos de herramientas y las aprobaciones no deben quedar a la imaginación del modelo. La guía de Anthropic sobre agentes recomienda comenzar con patrones simples y componibles, y aumentar la autonomía solo cuando sea necesario; la guía práctica de OpenAI también enfatiza la importancia de una orquestación clara, herramientas, guardrails y supervisión humana para los agentes en producción (guía de Anthropic para construir agentes efectivos, guía práctica de OpenAI).

5. Simulación de usuarios e investigación

Investigaciones recientes exploran el uso de agentes impulsados por LLM para sistemas de recomendación, incluidas la simulación de usuarios, la recomendación conversacional y los benchmarks de recomendación con agentes. Agent4Rec, por ejemplo, usa agentes generativos inicializados con datos de MovieLens para simular interacciones de recomendación (artículo de Agent4Rec). Las revisiones sobre agentes impulsados por LLM para sistemas de recomendación describen módulos como perfiles, memoria, planificación y acción como componentes emergentes (revisión sobre agentes impulsados por LLM para sistemas de recomendación).

Esto es prometedor, especialmente para la investigación y la exploración del arranque en frío. Pero los usuarios sintéticos no sustituyen la telemetría de producción. Trátalos como un entorno de prueba adicional, no como prueba de que los usuarios reales se comportarán de la misma manera.

Una arquitectura de referencia para recomendaciones con agentes

                             +----------------------+
                             | Admin / PM controls  |
                             | rules, inventory,    |
                             | campaigns, policies  |
                             +----------+-----------+
                                        |
                                        v
+-------------+     +-------------------+-------------------+
| User / App  | --> | Agent or API recommendation request    |
+-------------+     +-------------------+-------------------+
                                        |
                                        v
                             +----------+-----------+
                             | Context builder      |
                             | user, session,       |
                             | intent, permissions  |
                             +----------+-----------+
                                        |
                    +-------------------+-------------------+
                    |                                       |
                    v                                       v
          +---------+----------+                 +----------+---------+
          | Candidate retrieval |                 | Policy service     |
          | vectors, CF, search |                 | auth, safety,      |
          | popularity, tools   |                 | compliance         |
          +---------+----------+                 +----------+---------+
                    |                                       |
                    +-------------------+-------------------+
                                        |
                                        v
                             +----------+-----------+
                             | Ranker / re-ranker   |
                             | relevance, diversity |
                             | exploration          |
                             +----------+-----------+
                                        |
                                        v
                             +----------+-----------+
                             | Response + reasons   |
                             | trace + event log    |
                             +----------+-----------+
                                        |
                                        v
                             +----------+-----------+
                             | Training + eval loop |
                             +----------------------+

Lo importante es la separación de responsabilidades:

• El agente maneja la conversación y la orquestación de tareas.
• El recomendador se encarga de puntuar a los candidatos.
• El servicio de políticas se encarga de la elegibilidad y la seguridad.
• El pipeline de eventos se encarga del aprendizaje.
• El sistema de evaluación determina si los cambios son mejores.
• La observabilidad da a todos un registro compartido de lo que ocurrió.

Un pequeño ejemplo de recomendador híbrido

Este no es un sistema completo de producción. Es una estructura compacta a partir de la cual puedes crecer.

type Candidate = {
  id: string;
  type: "doc" | "tool" | "workflow";
  baseScore: number;
  metadata: Record<string, string | number | boolean>;
};

type UserContext = {
  userId: string;
  intent: string;
  allowedTypes: Candidate["type"][];
  recentIds: Set<string>;
  role: "viewer" | "operator" | "admin";
};

async function recommendNextActions(ctx: UserContext, limit = 5) {
  const [semantic, popular, recentSuccesses] = await Promise.all([
    retrieveByEmbedding(ctx.intent, 100),
    retrievePopularByRole(ctx.role, 50),
    retrieveSuccessfulForSimilarUsers(ctx.userId, 50),
  ]);

  const candidates = dedupe([...semantic, ...popular, ...recentSuccesses]);

  const eligible = candidates.filter((candidate) => {
    if (!ctx.allowedTypes.includes(candidate.type)) return false;
    if (ctx.recentIds.has(candidate.id)) return false;
    if (!passesPolicy(candidate, ctx)) return false;
    return true;
  });

  const ranked = eligible
    .map((candidate) => ({
      ...candidate,
      score:
        candidate.baseScore +
        intentBoost(candidate, ctx.intent) +
        freshnessBoost(candidate) +
        successRateBoost(candidate, ctx.role) -
        riskPenalty(candidate, ctx.role),
    }))
    .sort((a, b) => b.score - a.score);

  const diversified = diversifyByType(ranked);

  await logRecommendationExposure({
    userId: ctx.userId,
    intent: ctx.intent,
    shownIds: diversified.slice(0, limit).map((item) => item.id),
    rankerVersion: "hybrid-v1",
  });

  return diversified.slice(0, limit).map((item) => ({
    id: item.id,
    type: item.type,
    score: item.score,
    reason: buildGroundedReason(item, ctx),
    requiresApproval: needsApproval(item, ctx),
  }));
}

Este ejemplo conserva los puntos de integración esenciales para producción:

• múltiples fuentes de retrieval,
• filtrado por políticas,
• composición de puntuaciones,
• diversidad,
• registro de exposiciones,
• motivos,
• indicadores de aprobación.

Esa es la estructura que quieres tener antes de agregar ML más complejo.

Evaluación: qué medir antes y después del lanzamiento

Evaluar recomendaciones es complicado porque los datos históricos están sesgados por el sistema anterior. La evaluación offline sigue siendo útil, pero no debe tratarse como una verdad definitiva.

Métricas offline:

• precision@k,
• recall@k,
• NDCG,
• MAP,
• cobertura,
• diversidad,
• novedad,
• calibración,
• tasa de violación de restricciones,
• latencia y costo.

Métricas online:

• tasa de clics,
• conversión,
• finalización de tareas,
• tasa de aceptación,
• tasa de descarte u ocultamiento,
• retención a largo plazo,
• ingresos o ahorros,
• tasa de escalamiento,
• tasa de quejas,
• tasa de intervención humana,
• tasa de incidentes de seguridad.

Métricas específicas de agentes:

• éxito de las llamadas a herramientas,
• tasa de aprobación,
• prevención de acciones incorrectas,
• éxito de la tarea a nivel de traza,
• calidad de las explicaciones fundamentadas,
• tasa de recomendaciones alucinadas,
• intentos de violación de permisos,
• recuperación después de una corrección del usuario.

La guía actual de OpenAI para evaluar agentes recomienda la evaluación de trazas para detectar problemas a nivel de workflow, porque las trazas capturan de extremo a extremo las llamadas al modelo, las llamadas a herramientas, los guardrails y las transferencias de control (evals de agentes de OpenAI). La guía de evals de Anthropic también plantea las evals como pruebas estructuradas para sistemas de IA, no solo como benchmarks de modelos (evals de Anthropic).

Para los cambios en el recomendador, considera también la evaluación contrafactual u off-policy antes de exponer a los usuarios a cambios riesgosos. El artículo «Offline A/B testing for recommender systems» estudia estimadores diseñados para predecir la mejora en resultados de negocio antes de las pruebas A/B online (Gilotte et al.). La conclusión práctica no es «lo offline reemplaza a lo online». Es «usa métodos offline para evitar lanzamientos claramente malos y luego valida con usuarios reales».

Observabilidad: la capa de depuración

Cuando un usuario pregunta «¿Por qué el agente recomendó esto?», necesitas más que una respuesta final.

Registra la ruta de decisión:

trace_id: rec_8f21
user_intent: "reduce cloud bill"
retrieval_sources:
  semantic: [workflow_12, doc_91, tool_3]
  popular: [workflow_4, doc_22]
filtered:
  tool_3 -> blocked: missing_permission
ranked:
  workflow_12 -> 0.84
  doc_91 -> 0.77
  workflow_4 -> 0.61
reranked:
  workflow_12, doc_91, workflow_4
shown:
  workflow_12, doc_91, workflow_4
outcome:
  user_approved workflow_12

Para los sistemas de agentes, las trazas deben incluir llamadas al modelo, llamadas a herramientas, transferencias de control, guardrails, decisiones de políticas y eventos personalizados. La documentación de trazas de OpenAI Agents SDK describe el tracing como un registro de generaciones, llamadas a herramientas, transferencias de control, guardrails y eventos personalizados (tracing de OpenAI Agents SDK). OpenTelemetry también está estandarizando convenciones semánticas de GenAI para spans y métricas, incluidos spans de agentes y frameworks (spans de agentes de GenAI en OpenTelemetry).

Para los PMs, la observabilidad no es solo para ingenieros. Es la forma de aprender qué superficies de recomendación están ayudando a los usuarios y cuáles están generando confusión.

Seguridad y gobernanza

Los sistemas de recomendación pueden causar daño de manera silenciosa. Los sistemas de recomendación con agentes pueden causarlo de manera activa.

Riesgos para los que debes diseñar:

• recomendar acciones no disponibles o no autorizadas,
• filtrar documentos privados mediante sugerencias personalizadas,
• optimizar los clics a corto plazo por encima del bienestar del usuario,
• reforzar el sesgo hacia la popularidad,
• manipular las decisiones de los usuarios,
• permitir que la inyección de prompts influya en las recomendaciones,
• permitir que un agente llame a herramientas riesgosas a partir de una recomendación,
• generar explicaciones que no se basan en features reales.

La guía de gobernanza de Microsoft para agentes de IA enfatiza que las organizaciones necesitan saber qué agentes existen, quién es responsable de ellos, a qué pueden acceder, qué hacen y cómo detener comportamientos inseguros (gobernanza de agentes de Microsoft). Esto se aplica directamente a los recomendadores con agentes: las recomendaciones que desencadenan acciones deben tener responsables, ser observables, estar sujetas a permisos y poder detenerse.

Una lista sencilla para el lanzamiento:

• Cada acción recomendada tiene una persona responsable.
• Cada recomendación de herramienta incluye una verificación de permisos.
• Las acciones riesgosas requieren aprobación.
• El modelo no puede omitir los filtros de políticas.
• Las explicaciones se generan a partir de features verificables.
• El contenido con inyecciones de prompts se trata como entrada no confiable.
• Los usuarios pueden descartar recomendaciones, corregirlas o restablecer la personalización.
• El sistema registra las exposiciones y los resultados.
• Hay un interruptor de emergencia por superficie, modelo y política.

Hoja de ruta de desarrollo: de cero a producción

Fase 1: Contrato de producto

Define la superficie, la tarea del usuario, el catálogo de elementos, las restricciones y las métricas de éxito. Decide qué nunca se debe recomendar.

Fase 2: Recomendador de línea base

Lanza lógica basada en popularidad, reglas, etiquetas, actualidad o relaciones entre elementos. Agrega el registro de eventos desde el primer día.

Fase 3: Capa de retrieval

Agrega búsqueda semántica, señales colaborativas, factorización de matrices o un modelo two-tower, según el tamaño del catálogo y la madurez de los datos.

Fase 4: Capa de ranking

Entrena un modelo de ranking con features de usuario, elemento, contexto e interacción. Conserva un modelo simple como alternativa y benchmark.

Fase 5: Integración de agentes

Permite que el agente recopile preferencias, refine restricciones, explique recomendaciones y orqueste las próximas acciones aprobadas. Mantén las políticas y el ranking fuera del prompt.

Fase 6: Evaluación y observabilidad

Agrega métricas offline, pruebas de escenarios, evaluación de trazas, experimentos online, dashboards de costo y latencia, y monitoreo de seguridad.

Fase 7: Gobernanza y escala

Agrega responsables, workflows de aprobación, controles de despliegue, seguimiento de modelos y versiones, verificaciones de deriva, revisión de privacidad y respuesta a incidentes.

Decisiones comunes de arquitectura

Limitaciones conocidas de este artículo

Este artículo prioriza deliberadamente la arquitectura. Los temas más importantes que valdría la pena ampliar más adelante son:

• Un notebook práctico que entrene un modelo de retrieval y uno de ranking con un dataset público.
• Una comparación más profunda de bases de datos vectoriales, feature stores y stacks de serving online.
• Una sección completa sobre personalización que preserve la privacidad y retención de datos.
• Un análisis más sólido de la equidad en marketplaces, la equidad para creadores y proveedores, y la salud del ecosistema a largo plazo.
• Más ejemplos para ámbitos ajenos al comercio: herramientas para desarrolladores, bases de conocimiento internas, operaciones de salud, educación y automatización del soporte.

Próximas secciones recomendadas para agregar más adelante

Si este artículo se convierte en una serie, agregaría:

• «Retrieval two-tower desde cero»
• «Cómo evaluar recomendadores sin engañarte»
• «Patrones de UX para recomendaciones con agentes»
• «Feature stores para sistemas de recomendación»
• «Cómo diseñar explicaciones de recomendaciones»
• «Patrones de seguridad para recomendaciones de herramientas y workflows»

Lista de fuentes

• Greg Linden, Brent Smith y Jeremy York, «Amazon.com Recommendations: Item-to-Item Collaborative Filtering» (PDF).
• Yehuda Koren, Robert Bell y Chris Volinsky, «Matrix Factorization Techniques for Recommender Systems» (PDF).
• Paul Covington, Jay Adams y Emre Sargin, «Deep Neural Networks for YouTube Recommendations» (PDF).
• Heng-Tze Cheng et al., «Wide & Deep Learning for Recommender Systems» (arXiv).
• TensorFlow Recommenders, «Recommending movies: retrieval» (guía oficial).
• NVIDIA Merlin, «Building Intelligent Recommender Systems with Merlin» (ejemplo oficial).
• Lihong Li et al., «A Contextual-Bandit Approach to Personalized News Article Recommendation» (página del artículo).
• Alexandre Gilotte et al., «Offline A/B testing for Recommender Systems» (arXiv).
• Lei Li et al., «Large Language Models for Generative Recommendation: A Survey and Visionary Discussions» (arXiv).
• «A Survey on LLM-powered Agents for Recommender Systems» (arXiv).
• «On Generative Agents in Recommendation» / Agent4Rec (arXiv).
• OpenAI, «A Practical Guide to Building Agents» (PDF).
• OpenAI, «Safety in building agents» (documentación oficial).
• OpenAI, «Evaluate agent workflows» (documentación oficial).
• OpenAI Agents SDK, «Tracing» (documentación oficial).
• Anthropic, «Building Effective Agents» (nota de investigación).
• Anthropic, «Demystifying evals for AI agents» (nota de ingeniería).
• Google Cloud, «Choose your agentic AI architecture components» (documentación oficial).
• Microsoft, «Governance and security for AI agents across the organization» (documentación oficial).
• OWASP, «AI Agent Security Cheat Sheet» (guía oficial).
• OpenTelemetry, «Semantic Conventions for GenAI agent and framework spans» (especificación oficial).