El contexto de un agente necesita una especificación. Defina cuatro propiedades antes de culpar al modelo
Los lanzamientos de la semana atacaron el contexto de los agentes por cuatro lados: significado, calidad de la evidencia, frescura y la capacidad de no encontrar nada. Trátelo como un producto.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
Cuando un agente empresarial da una respuesta errónea, el análisis suele empezar por el modelo. ¿Era el modelo equivocado, el prompt estaba poco claro, conviene probar la nueva versión? A menudo el modelo hizo exactamente lo que se le pidió con lo que se le dio. Lo que se le dio estaba mal: una política obsoleta, un documento que el usuario no debería ver, una definición de “cliente activo” que finanzas dejó de usar el año pasado, o cinco pasajes vagamente relacionados cuando la respuesta honesta era “no hay nada sobre esto”.
Tres lanzamientos de esta semana atacaron, cada uno, uno de esos fallos, desde proveedores distintos:
- Significado. Agent Knowledge Foundation de NVIDIA incluye la librería Auto-Ontology, que mapea datos en bruto a conceptos de negocio y sus relaciones, y modelos Kumo que predicen a partir de datos relacionales.
- Evidencia y abstención. Rerank 5 de Cohere devuelve puntuaciones de relevancia calibradas, en las que 0,7 significa un 70% de probabilidad de que el documento sea útil, y selección por pasajes.
- Frescura. AWS redujo a la mitad, a cinco segundos, el intervalo de actualización por defecto de las colecciones de búsqueda y vectoriales de OpenSearch Serverless, para que los datos recién ingeridos se puedan buscar antes.
Ninguno es la respuesta completa. Juntos sugieren una forma de pensar el contexto de los agentes que falta en la mayoría de los programas: como un producto con una especificación.
Cuatro propiedades, cada una con responsable y prueba
| La pregunta que responde | Cómo probarla | Quién es responsable | |
|---|---|---|---|
| Significado | ¿Nuestros términos significan una sola cosa, y es la vigente? | Definiciones resueltas contra el glosario aprobado | El responsable de negocio de cada definición |
| Evidencia | ¿Lo que leyó el agente es relevante, permitido y atribuible? | Evals de búsqueda; comprobación de permisos por usuario | Responsables del contenido y equipo de plataforma |
| Frescura | ¿Qué antigüedad puede tener el contexto cuando el agente lo usa? | Tiempo desde un cambio en la fuente hasta que se puede recuperar | Ingeniería de datos, por fuente |
| Abstención | ¿Sabe el agente cuándo no encontró nada utilizable? | Preguntas sin respuesta en el corpus | El responsable de producto del agente |
El significado es la propiedad que más falta. Los agentes leen las definiciones al pie de la letra. Si “ingresos” es una columna para el panel de ventas y otra para finanzas, el agente elegirá una, con seguridad. Defendimos que las definiciones de negocio se están convirtiendo en infraestructura compartida de los agentes; una ontología generada automáticamente hace la cuestión más urgente, porque produce definiciones más rápido de lo que nadie las revisa.
La evidencia tiene tres partes, y los equipos suelen medir solo la primera: relevancia, permiso y atribución. El documento tiene que responder a la pregunta, el usuario tiene que tener permiso para verlo y la respuesta tiene que decir de dónde procede. La relevancia se puede evaluar; explicamos cómo al medir la búsqueda como un sistema propio. El permiso debe aplicarse por usuario, no por agente.
La frescura es un número, y debería escribirse por fuente. El cambio de AWS de diez a cinco segundos es un ajuste de actualización por defecto, no una garantía de extremo a extremo: lo que importa es el tiempo desde un cambio en el sistema de origen, pasando por la ingesta y la indexación, hasta que el agente puede recuperarlo. Para un agente de precios, unos minutos pueden ser demasiado. Para un asistente de políticas internas, un día puede bastar. Sin un objetivo, nadie nota cuándo se degrada.
La abstención es la propiedad que convierte la búsqueda de una ordenación en una decisión. Si las puntuaciones de relevancia significan probabilidades, un umbral puede significar “nada de esto es suficientemente bueno”, y el agente puede decirlo, hacer una pregunta aclaratoria o derivar a una persona. Un agente que siempre responde con sus cinco primeros resultados siempre responderá, también cuando no debería.
Por qué “especificación” y no “buenas prácticas”
Porque una especificación se puede probar y tiene responsable, y una buena práctica no. Cada propiedad anterior tiene un número o una comprobación que puede ejecutarse a diario, y una persona cuyo trabajo es mantenerla. Cuando una respuesta sale mal, el análisis puede preguntar qué propiedad falló antes de que nadie toque el modelo. Cuando un proveedor cambia algo, como el modelo detrás del alias “stable” en Agent Search de Google, las pruebas lo detectan.
También redistribuye el trabajo. En muchos programas, el equipo de IA es responsable de todo, del prompt al índice, incluidas definiciones sobre las que no tiene autoridad. Una especificación de contexto devuelve el significado al negocio, la frescura a ingeniería de datos y la evidencia a los responsables del contenido, y deja al equipo de IA a cargo de lo que realmente controla.
Por dónde empezar
Elija un agente en producción y escriba su especificación de contexto en una página: los diez términos de los que depende y quién es responsable de cada uno, las fuentes que lee con sus objetivos de frescura, el conjunto de evaluación de la búsqueda con comprobaciones de permisos, y las preguntas que debe negarse a responder. Ejecute las pruebas cada semana. La primera ejecución suele explicar más respuestas erróneas que un mes de cambios en el prompt.