SONNET CODE
← Volver a todos los artículos
Desarrollo de IA25 de junio de 2026·11 min de lectura

La ingeniería de contexto supera a RAG en el 60% de los desarrollos de agentes del segundo trimestre de 2026

Lo que el cambio del segundo trimestre de 2026 dice realmente y el patrón de ingeniería que llega con él

El patrón de arquitectura en producción por defecto para las funciones de LLM se reasentó de forma silenciosa a lo largo del segundo trimestre de 2026, y la hoja de cálculo de compras aún no se ha puesto al día. Durante abril, mayo y junio, el patrón de ingeniería en el que convergió la categoría de IA en producción pasó de RAG — recuperar los K documentos principales, meterlos en el prompt, confiar en que el modelo atienda a los correctos — a la ingeniería de contexto: tratar la ventana de contexto como una superficie de arquitectura de aplicación de primera clase, diseñarla explícitamente a lo largo de los documentos recuperados, la memoria de trabajo estructurada, el estado de borrador de las llamadas a herramientas, la compresión por turno, la política de desalojo por paso y un presupuesto de tokens por clase de carga de trabajo. La encuesta de junio a líderes de ingeniería de IA agéntica empujó el cambio más allá del punto de inflexión: más del 60% de los nuevos desarrollos de agentes del segundo trimestre señalaron la arquitectura de contexto como el trabajo principal de ingeniería, con la integración de la base de datos vectorial relegada a un componente entre cinco.

Las piezas importantes desde el punto de vista operativo:

  • El patrón de RAG por defecto era la respuesta correcta para el mundo de ventana de 32K y un solo turno contra el que fue diseñado. Cuando la carga de trabajo de IA en producción era un usuario hace una pregunta, el sistema recupera tres documentos, el modelo responde a partir de ellos en un solo turno, el trabajo de ingeniería era embeddings, fragmentación, base de datos vectorial, recuperación de los K principales, plantilla de prompt. El pipeline de RAG era fundamental porque la ventana de contexto no podía contener el corpus; la recuperación era la única vía de entrada.
  • La ventana de contexto de 1M+ y el bucle de agente multiturno rompen la suposición contra la que se construyó RAG. Cuando la carga de trabajo de IA en producción es el agente ejecuta un bucle de 30 pasos usando herramientas contra un modelo de contexto de un millón de tokens, con documentos recuperados que llegan en el paso 4, memoria estructurada que se actualiza en el paso 9, un sandbox de Python que devuelve una salida de 12K tokens en el paso 14 y un subagente que devuelve un resumen de 40K tokens en el paso 22, el trabajo de ingeniería ya no es qué K documentos principales van en el prompt. Es a qué 200K tokens de los 600K totales de contexto debe atender el modelo en este turno, qué se comprime antes del siguiente turno, qué se desaloja, qué se fija, qué se resume en memoria de trabajo estructurada — y la restricción vinculante es la disciplina del equipo de ingeniería frente a la propia ventana de contexto, no el pipeline de recuperación.
  • El proveedor de la base de datos vectorial es ahora uno de cinco componentes, no la arquitectura. La pila de ingeniería de contexto en la que convergió la categoría de IA en producción tiene cinco componentes fundamentales: (1) recuperación (vectorial + por palabras clave + estructurada), (2) memoria de trabajo estructurada (estado tipado que el agente lee y escribe), (3) borrador de llamadas a herramientas (salida intermedia turno a turno), (4) compresión por turno y política de desalojo, (5) aplicación del presupuesto de tokens por clase de carga de trabajo. La base de datos vectorial es uno de los cinco; la hoja de cálculo de compras que enumera proveedor de base de datos vectorial como la partida de IA en producción está operando contra un patrón de arquitectura que la base instalada ha superado estructuralmente en un solo trimestre.
  • La competencia de ingeniería fundamental del equipo pasó de "embeddings y fragmentación" a "orquestación de la ventana de contexto". Hace doce meses, la habilidad fundamental del ingeniero de IA en producción era escribir la estrategia de fragmentación que preserva la semántica, ajustar el modelo de embeddings, calibrar el umbral de recuperación. Hoy, la habilidad fundamental del mismo ingeniero es diseñar la estructura de la ventana de contexto a lo largo de los cinco componentes, escribir las reglas de compresión y desalojo por turno, instrumentar el presupuesto de tokens por clase de carga de trabajo, depurar los modos de fallo de la ventana de contexto cuando el agente atiende a la subcadena equivocada de un estado de 600K tokens. La competencia es distinta en tipo, no solo en grado; el equipo que se dotó de personal para la habilidad de FY25 no es el equipo que entrega el agente en producción de FY27.

La lectura estructural no es RAG está muerto. Es que RAG es un componente de una arquitectura de ingeniería de contexto más amplia en la que la categoría de IA en producción se asentó a lo largo del segundo trimestre de 2026, y la pregunta de compra que era qué proveedor de base de datos vectorial ahora es qué disciplina de ingeniería de contexto tiene el equipo la dotación de ingeniería senior para operar. La función de IA en producción cuyo diagrama de arquitectura todavía tiene pipeline de RAG como una sola caja es la función cuyo número de fiabilidad del tercer trimestre va a decepcionar.

Lo que el cambio hacia la arquitectura de contexto reestructura en la ingeniería de IA en producción

Cuatro cambios concretos que se derivan cuando la ingeniería de contexto se convierte en el patrón de ingeniería de IA en producción por defecto.

El documento de arquitectura de cada función de IA en producción adquiere una sección de ventana de contexto que el documento de arquitectura de FY25 no tenía. El documento de arquitectura de IA en producción de FY25 tenía cuatro secciones — selección de modelo, pipeline de recuperación, plantilla de prompt, conjunto de evaluación. El documento de arquitectura del tercer trimestre de 2026 tiene una quinta — arquitectura de la ventana de contexto: asignación de presupuesto de tokens por componente entre recuperación, memoria estructurada, borrador de llamadas a herramientas e historial de conversación; reglas de compresión y desalojo por turno; suite de pruebas de modos de fallo de la ventana de contexto por clase de carga de trabajo. La nueva sección es la sección contra la que se mide el número de fiabilidad en producción; el documento de arquitectura que no la tiene es el documento que entrega un agente cuya fiabilidad se degrada cuando la ventana de contexto se llena más allá del 60%.

El listón de calidad de ingeniería del equipo pasa de "¿la recuperación devolvió el documento correcto?" a "¿el modelo atendió a la subcadena correcta del contexto ensamblado?". El listón de calidad de IA en producción de FY25 era la precisión y exhaustividad de la recuperación — medible contra el conjunto de referencia, depurable contra el modelo de embeddings, ajustable contra la estrategia de fragmentación. El listón de calidad del tercer trimestre de 2026 es la precisión de atención contra el contexto ensamblado — medible contra la distribución de atención por turno, depurable contra la política de desalojo, ajustable contra la estrategia de compresión. El listón es más difícil de medir, más difícil de depurar y más difícil de mejorar — pero es el listón contra el que se mide la fiabilidad en el mundo real de la función de IA en producción, y el equipo que no lo eleva hasta ahí entrega un agente cuyo número de fiabilidad del cuarto trimestre no sobrevive a la rotación de guardia.

La aplicación del presupuesto de tokens por clase de carga de trabajo se convierte en una superficie de fiabilidad en producción de primera clase. Una ventana de contexto de un millón de tokens no significa que toda carga de trabajo deba ejecutarse a un millón de tokens. La disciplina de fiabilidad en producción que impone el patrón de ingeniería de contexto es la asignación de presupuesto de tokens por clase de carga de trabajo — este flujo se ejecuta a 60K tokens de contexto, este a 200K, este a 800K — con reglas de desalojo explícitas cuando se supera el presupuesto y una contabilidad explícita del costo por tarea contra el presupuesto. Los equipos que no imponen presupuestos por clase de carga de trabajo obtienen un agente cuyo costo por tarea crece sin límite contra la mezcla de cargas de trabajo; los equipos que sí los imponen obtienen una superficie de fiabilidad en producción que la función de FinOps puede respaldar.

La taxonomía de modos de fallo de la función de IA en producción duplica su tamaño, y el equipo tiene que instrumentar contra los nuevos modos de fallo de forma explícita. La taxonomía de modos de fallo de IA en producción de FY25 era la recuperación no encontró el documento correcto, la recuperación mostró el documento equivocado, el modelo alucinó contra un contexto ausente. La taxonomía del tercer trimestre de 2026 añade cinco más — la estrategia de compresión resumió y eliminó el dato fundamental, la política de desalojo descartó el turno fundamental, la memoria de trabajo estructurada se desvió de la narrativa del agente, el borrador de llamadas a herramientas contaminó la atención del modelo, el presupuesto por clase de carga de trabajo se desbordó contra una entrada de caso límite. Cada nuevo modo de fallo necesita su propia instrumentación, su propia suite de pruebas por modo, su propio runbook por modo. El equipo que no escribe la taxonomía es el equipo cuyo ciclo de post-mortem recorre el mismo modo de fallo tres veces antes de nombrarlo.

Dónde el patrón es señal y dónde es ruido

Cuatro lecturas honestas sobre lo que el cambio hacia la ingeniería de contexto le dice realmente al comprador.

Señal: el cambio de RAG a la ingeniería de contexto es un cambio real de patrón de arquitectura, no un cambio de marca. La pila de cinco componentes de la ingeniería de contexto es estructuralmente distinta del pipeline de cuatro componentes de RAG — restricciones vinculantes distintas, modos de fallo distintos, competencias de ingeniería distintas. Los equipos que leen el cambio como RAG con un prompt más largo pierden la implicación arquitectónica; los equipos que lo leen como la arquitectura de IA en producción adquirió un quinto componente fundamental están leyendo la misma señal en la que converge la base instalada.

Señal: la competencia de ingeniería de IA en producción que el equipo necesita es materialmente distinta de la competencia de FY25, y la decisión de dotación de personal debería medirse contra esa diferencia. El cambio de competencia es la señal de grado de decisión de compra que el plan de FY27 debería codificar. El equipo que se dotó de la competencia de RAG de FY25 en el plan de FY27 se está dotando de personal contra un patrón de arquitectura que la categoría de IA en producción ya dejó atrás; el equipo que se dota de competencia en ingeniería de contexto se está dotando para el trabajo que la función de IA en producción de FY27 realmente requiere.

Ruido: el titular de "RAG está muerto" es el encuadre equivocado y los equipos que actúan en consecuencia entregan la refactorización equivocada. RAG es un componente de una arquitectura de ingeniería de contexto más amplia; eliminar el pipeline de RAG no produce una arquitectura de ingeniería de contexto, produce una arquitectura de ingeniería de contexto a la que le falta su componente de recuperación. La lectura honesta es RAG no está muerto; RAG es uno de cinco componentes, y el equipo que lo trata como la arquitectura en lugar de como un componente es el equipo cuya función de IA en producción no compone.

Ruido: la ventana de contexto de 1M+ no significa que toda carga de trabajo deba ejecutarse a 1M tokens. Una ventana de contexto de 1M tokens es un límite superior, no un objetivo. La disciplina de presupuesto por clase de carga de trabajo es lo que convierte el límite superior en una capacidad útil en lugar de una superficie de costo sin límite; el equipo que predetermina toda carga de trabajo al máximo de la ventana de contexto sin presupuestos por clase de carga de trabajo es el equipo que entrega una superficie de costo por tarea que la función de FinOps no puede respaldar.

Lo que el equipo de ingeniería debería hacer este trimestre

Cuatro acciones concretas que cierran la brecha entre el patrón de ingeniería de contexto y la función de IA en producción que la arquitectura requiere.

Audita cada función de IA en producción en busca de la sección de ventana de contexto en su documento de arquitectura. Para cada función de IA en producción de la base instalada, comprueba si el documento de arquitectura tiene la sección de ventana de contexto de cinco componentes. Las funciones cuyo documento de arquitectura todavía describe un pipeline de RAG de cuatro componentes son las funciones que el equipo debería rearquitectar contra el patrón de ingeniería de contexto dentro del tercer trimestre. El resultado de la auditoría es la lista de tareas de refactorización; la lista de tareas es contra lo que se mide el plan de fiabilidad de FY27.

Pon en marcha la instrumentación del presupuesto de tokens por clase de carga de trabajo como una superficie de fiabilidad en producción de primera clase. Para cada clase de carga de trabajo que maneja la función de IA en producción, fija un presupuesto de tokens por clase de carga de trabajo, instrumenta el consumo de tokens por tarea contra el presupuesto y muestra el costo por tarea por clase de carga de trabajo en el panel de fiabilidad en producción junto con la latencia y la tasa de errores. La instrumentación es la superficie fundamental de FinOps y de fiabilidad; el equipo que no la tiene es el equipo cuyo costo por tarea crece en silencio contra la mezcla de cargas de trabajo hasta que la revisión de FinOps fuerza una rearquitectura de emergencia.

Escribe el runbook de modos de fallo de la ventana de contexto y haz pruebas contra él. Para cada uno de los cinco modos de fallo de la ventana de contexto — compresión-que-resumió-y-eliminó-el-dato-fundamental, desalojo-que-descartó-el-turno-fundamental, deriva-de-memoria-estructurada, contaminación-de-atención-por-borrador, desbordamiento-de-presupuesto-por-clase-de-carga-de-trabajo — escribe un runbook por modo, un caso de prueba por modo y una suite de regresión por modo. El runbook es la memoria institucional del equipo contra la nueva taxonomía de modos de fallo; la suite de pruebas es lo que detecta la siguiente instancia de modo antes de producción.

Vuelve a evaluar el plan de contratación y formación del equipo contra la competencia en ingeniería de contexto, no contra la competencia en RAG. El plan de contratación que filtra por habilidades de embeddings, fragmentación, base de datos vectorial es el plan que contrata para la función de IA en producción de FY25. El plan de contratación que filtra por orquestación de la ventana de contexto, gestión de estado por turno, disciplina de presupuesto por clase de carga de trabajo, depuración de agentes multiturno es el plan que contrata para la función de IA en producción de FY27. El equipo que actualiza la rúbrica de contratación y el currículo de formación interna dentro del tercer trimestre tiene el banco de talento para la función de FY27; el equipo que no lo hace es el equipo cuyo pipeline de contratación del primer trimestre de 2027 produce ingenieros para una generación de arquitectura que la categoría de IA en producción ya ha superado.

El trabajo de juicio senior que la disciplina de ingeniería de contexto hace necesario pero no reemplaza

El patrón de ingeniería de contexto comprime el costo de iterar sobre la función de IA en producción contra las primitivas arquitectónicas correctas — el equipo que adopta el patrón de cinco componentes deja de redescubrir los modos de fallo que la base instalada ya nombró. No comprime el trabajo de juicio senior de elegir qué cargas de trabajo pertenecen a la función de IA en producción en absoluto, escribir los criterios de éxito por carga de trabajo contra los que se mide la función, ser dueño de la integración en la pila de producción que el equipo opera y decidir qué presupuestos de tokens por clase de carga de trabajo y qué runbooks por modo impone la superficie de fiabilidad en producción.

Los equipos que confunden el patrón de arquitectura abaratado con el juicio abaratado estarán, dentro de seis meses, leyendo post-mortems sobre funciones de IA en producción cuya causa raíz es el patrón de ingeniería de contexto se aplicó a la carga de trabajo equivocada, contra los criterios de éxito equivocados, con el presupuesto por clase de carga de trabajo equivocado. Los equipos que mantienen el juicio senior en el centro de la decisión de selección de carga de trabajo y criterios de éxito tendrán, dentro de seis meses, funciones de IA en producción cuyo número de fiabilidad del cuarto trimestre sobrevive a la rotación de guardia.

La pregunta de compra ya no es qué proveedor de base de datos vectorial; es qué disciplina de ingeniería de contexto tiene el equipo la dotación de ingeniería senior para operar, contra qué funciones de IA en producción se aplica la disciplina y qué presupuesto por clase de carga de trabajo impone la superficie de fiabilidad en producción. Los equipos que hacen la pregunta correcta este trimestre se compran una función de IA en producción que compone; los equipos que hacen la equivocada se compran un ciclo de refactorización para el que el plan de FY27 no tiene presupuesto.