La ingeniería de contexto de la IA consiste en diseñar todo lo que rodea al agente en cuanto a información, límites e instrucciones, para que sepa qué puede ver, qué debe hacer y cómo comportarse cuando se enfrenta a una situación nueva o a datos incompletos. Según explican Doug Whitley, director de ingeniería de Stack Overflow, y Ash Zade, director de producto, el objetivo no es inundar al agente con todos los datos disponibles, sino proporcionarle el contexto específico que necesita para realizar una tarea cuyo resultado sea predecible.
Esto se trató en una conversación publicada por Stack Overflow Blog dentro de la serie “No Dumb Questions”, en la que se analizaron las diferencias entre la ingeniería de contexto, la infraestructura de contexto y la ingeniería de contexto, además de la relación de estos conceptos con las tecnologías RAG y MCP y las razones por las que las empresas optan por comprar soluciones listas para usar en lugar de construirlo todo internamente.
De la infraestructura a la ingeniería
Whitley distingue entre la infraestructura de contexto, relacionada con la forma de almacenar, mostrar y proporcionar el contexto al agente, y la ingeniería de contexto, que se centra en diseñar el sistema y en las razones para organizar sus componentes de una determinada manera. En cuanto a la ingeniería de contexto en sentido práctico, esta se refiere a construir realmente el sistema, por ejemplo, eligiendo los algoritmos, los lenguajes de programación y las herramientas que se utilizarán.
Whitley sitúa RAG en una zona que reúne los tres niveles. Los índices, los almacenes de contexto y los métodos de búsqueda representan el aspecto de la infraestructura, mientras que el proceso de construir el sistema con un lenguaje como .NET, Python o Rust representa el aspecto de la ingeniería. Por otro lado, la arquitectura determina la forma general del sistema y las reglas que rigen su funcionamiento. En cuanto a MCP, Whitley lo considera un protocolo con requisitos específicos, pero la decisión de integrarlo en el sistema, los lenguajes utilizados y las funciones que admitirá son decisiones de diseño.
Reducir el espacio de decisiones que toma el agente
Zade explica la idea mediante el ejemplo de buscar neumáticos para automóviles. Si se envía a un agente a una biblioteca para buscar “neumáticos”, puede encontrar información sobre aviones, bicicletas y carretillas, porque todas coinciden con la palabra solicitada. Sin embargo, un sistema bien diseñado determina desde el principio que la tarea se refiere a neumáticos para automóviles, o específicamente a neumáticos para autos deportivos, y limita la información disponible a ese ámbito.
Zade considera que poner estas instrucciones únicamente en una indicación de texto no garantiza que el agente las siga. Por eso, la ingeniería de contexto requiere controlar los datos a los que el agente puede acceder, además de determinar qué debe hacer cuando se enfrenta a información incompleta o incorrecta. De este modo, se eliminan algunas variables de las decisiones del agente, en lugar de dejar que decida por sí mismo si la información es fiable o si debe ampliar el alcance de la búsqueda.
El sistema también incluye la memoria del agente, para que conserve lo que ha hecho, aprendido, tratado y construido hasta ese momento. Esta memoria adquiere mayor importancia cuando trabajan varios agentes o cuando una tarea se detiene y se reanuda más adelante.
Confianza, permisos e intervención humana
Stack Internal, según los ponentes, ofrece un ejemplo de conexión entre el contexto y un sistema de confianza con un flujo de verificación por parte de expertos. El conocimiento se clasifica con niveles alto, medio o bajo. Si el nivel es medio o bajo, se puede dirigir al usuario a un experto en el tema para verificar la información o completar las carencias, en lugar de permitir que el agente tome una decisión basándose en conocimientos no confirmados.
La protección de datos va más allá de preguntar si el agente puede ver una determinada información. Es posible que el usuario tenga acceso a ella, pero que no sea adecuada para la tarea que ejecuta el agente. Por ello, los ponentes describen dos niveles de control:
- Permisos de la fuente: el agente hereda los permisos del usuario en los sistemas en los que realiza búsquedas, como Slack, MS Teams, Google Drive o SharePoint.
- Ámbitos: el usuario puede limitar el alcance de los datos disponibles para el agente aunque tenga permiso para acceder a un conjunto más amplio de información.
- Datos nuevos: se puede restringir lo que el agente crea o devuelve al sistema, de modo que primero lo envíe al usuario y no lo añada automáticamente a la base de conocimientos general ni lo comparta con el equipo.
Esta distinción indica que la gestión del contexto no se limita a la recuperación, sino que también incluye el control de la memoria y del conocimiento que crea el agente.
¿Por qué podría una empresa comprar la solución en lugar de construirla?
Whitley afirma que construir una ingeniería de contexto es posible, pero que el desafío no se limita a escribir código. Cuando una empresa reúne datos de Slack, MS Teams, Google Drive, SharePoint, Confluence, GitHub y Jira, debe determinar cómo indexarlos, filtrarlos y volver a clasificarlos, y cómo gestionar la información contradictoria, incompleta o incorrecta.
Zade considera que gran parte del trabajo consiste en definir la confianza misma. Un usuario experto puede confiar en los resultados de la IA cuando coinciden con sus expectativas y experiencia previa, pero este enfoque no está igualmente disponible para quienes carecen de experiencia en el ámbito en el que se pide a la IA que trabaje. Por ello, el sistema requiere debates sobre qué hace que la información sea digna de confianza, y no solo soluciones técnicas para recopilarla.
Whitley añade que comprar una solución lista para usar puede proporcionar a la empresa la experiencia acumulada a partir de problemas a los que se han enfrentado otros clientes, incluidos los casos extremos y los problemas cotidianos que, según afirma, su equipo clasifica en aproximadamente 20 categorías. No obstante, los ponentes no descartan la construcción interna; puede ser adecuada cuando el caso de uso es nuevo o cuando la empresa necesita decisiones de diseño propias.
Para Whitley y Zade, la calidad de la ingeniería de contexto se mide por la flexibilidad del sistema y su capacidad para ofrecer resultados coherentes y predecibles, no simplemente por limitarlo a una sola tarea. Además, filtrar la información pronto puede reducir el número de tokens que procesa el agente: buscar en libros sobre automóviles cuesta menos que buscar en una biblioteca completa, y buscar en páginas sobre neumáticos cuesta menos que revisar todos los libros. El objetivo final sigue siendo permitir que el agente ejecute la tarea prevista y que se detenga o solicite ayuda humana cuando llegue a límites que no debería sobrepasar.