Context engineering: cómo salir de la meseta del RAG

Casi todos los equipos descubren lo mismo a los tres meses de lanzar su feature de IA: la calidad del retrieval nunca fue el cuello de botella. El problema era cómo se arma el contexto. Los embeddings andan bien. La base vectorial anda bien. Lo que está roto es todo lo que pasa entre que vuelve la llamada de retrieval y el prompt llega al modelo.

La meseta, diagnosticada

Los pipelines de RAG ingenuos meten en el prompt cada fragmento apenas relevante y rezan para que el modelo se arregle solo. Pasada cierta escala, subir el recall del retrieval empeora las respuestas en lugar de mejorarlas: la señal se ahoga entre casi-duplicados, versiones viejas del mismo documento y pasajes que tocan el tema pero no aportan ningún dato útil. Los modelos rinden peor, y se nota en las métricas, cuando tienen que buscar la única oración relevante entre veinte párrafos que parecen razonables.

Los equipos que salen de la meseta dejan de preguntarse "¿cómo recuperamos mejores fragmentos?" y empiezan a preguntarse "¿qué necesita ver realmente el modelo para responder este tipo de pregunta?". Son problemas de ingeniería distintos, con dueños distintos, métricas distintas y soluciones distintas.

Presupuestos, no buffers

Los sistemas en producción tratan la ventana de contexto como un presupuesto con partidas: instrucciones de sistema, memoria de la conversación, evidencia recuperada y espacio de trabajo reciben cada uno una asignación explícita, y alguien rinde cuentas por cada token que se gasta. Si la partida de evidencia es de 4.000 tokens, la capa de retrieval tiene que rankear, deduplicar y comprimir para entrar, y eso fuerza justo la conversación sobre calidad que el relleno ilimitado te deja esquivar.

Una prueba rápida: si nadie en el equipo puede decir qué parte del prompt son instrucciones y qué parte es evidencia en un request típico, el contexto es un buffer, no un presupuesto, y la calidad se va corriendo con cada feature que se agrega aguas arriba.

Compactar es una feature, no un parche

Los resúmenes estructurados le ganan a los fragmentos crudos casi en todos los casos. Una capa de retrieval que reescribe cinco pasajes superpuestos en un único resumen con atribución, conservando los IDs de documento para poder citar, suele rendir mejor que mandar el texto tal cual, porque el modelo usa su capacidad para razonar en vez de para conciliar. Con el historial de la conversación pasa lo mismo: una compactación ponderada por recencia, donde los turnos viejos se condensan en un resumen que se va actualizando, le gana tanto al historial infinito como al recorte brutal.

La consulta es la mitad de la batalla

Un modelo chico y rápido que reescribe la consulta del usuario antes del retrieval (expandiendo siglas, resolviendo pronombres según la conversación, separando preguntas compuestas) mejora la calidad de punta a punta por mucho menos de lo que cuesta pasarse a un modelo de respuesta más grande. El retrieval es tan bueno como la pregunta que recibe, y los usuarios no escriben pensando en tu retriever: escriben como si le preguntaran a un compañero de trabajo.

Evaluá el armado, no solo la respuesta

Los evals de punta a punta esconden dónde ocurren las fallas. Los pipelines maduros puntúan cada etapa por separado: ¿el retrieval trajo un pasaje que contenía la respuesta?, ¿la compactación la conservó?, ¿el modelo la usó? Instrumentar esas tres preguntas convierte un "la IA está rara" en un reporte de bug con dueño. Y eso, más que cualquier upgrade de modelo, es lo que te saca de la meseta.