Cómo la ingeniería de contexto convierte un LLM local modesto en un agente fiable

El autor de un artículo en Habr lo demuestra: en un modelo de lenguaje local que funciona en un entorno cerrado y con hardware limitado, la fiabilidad del agente depende de cómo se construye su contexto, y no del tamaño del modelo.

Por qué no basta con «usar un modelo más grande»

Cuando el modelo se ejecuta en local, dentro del perímetro de la empresa y con hardware limitado, no hay margen para ampliarlo: recurrir a un modelo puntero en la nube con más parámetros no es una opción. Según el autor, en estas condiciones la principal palanca de calidad está en el contexto y no en el modelo: qué se le muestra exactamente, en qué orden y cómo se filtra lo que sobra.

Qué compone un contexto «correcto»

Tal como lo describe el autor, el contexto va mucho más allá de un fragmento de texto pegado en el prompt. Es un ensamblaje que tiene en cuenta tres parámetros: quién hace la pregunta, desde dónde llega y sobre qué pregunta exactamente. A esto se suman otros dos elementos:

• Un umbral de relevancia honesto: al modelo solo se le muestra lo que de verdad guarda relación con la pregunta, y no todo lo disponible «por si acaso»
• Un orden de secciones bien pensado: la información clave para la respuesta se coloca de forma que el modelo no la «pierda» entre detalles secundarios

Dicho de otro modo, ante una misma pregunta el contexto cambia según el rol del usuario, el canal de la consulta y el tema: tiene sentido mostrar fragmentos distintos de la base de conocimiento a un agente de soporte y a un desarrollador, aunque formalmente pregunten «lo mismo».

Qué diferencia a un modelo potente de uno modesto en este escenario

La observación clave del artículo es que la tolerancia de un modelo a los errores en la organización del contexto depende de su tamaño y potencia. En un modelo potente en la nube, un contexto mal ensamblado suele compensarse con el margen de razonamiento: el propio modelo distingue qué es importante y qué no. Un modelo local de gama media carece de ese margen, y el mismo contexto descuidado deteriora directamente la calidad de las respuestas.

En la práctica, esto implica que los prompts y el context-pipeline deben probarse en el modelo objetivo (el más modesto) y no en uno puntero en la nube: lo que parece funcionar con un modelo potente puede desmoronarse al trasladarlo a uno local.

Dónde resulta especialmente crítico

Los modelos locales suelen elegirse allí donde los datos no pueden salir del perímetro: banca, sector público, sanidad e industria. Precisamente en estos entornos los equipos no tienen la opción de «coger un modelo más potente sin más»: el hardware y las licencias de las API punteras en la nube o no están disponibles, o las prohíbe la política de seguridad. En estas condiciones, la ingeniería de contexto es la única palanca que se puede controlar directamente, a diferencia de la arquitectura del propio modelo.

El autor subraya además la diferencia entre el «contexto en general» y el «contexto adaptado a cada consulta»: si el sistema ensambla una única vez un conjunto universal de documentos y se lo pasa al modelo sin criterio, sin importar quién pregunta ni sobre qué, la probabilidad de obtener una respuesta incompleta o errónea con un modelo modesto es notablemente mayor que si el contexto se construye a medida para cada caso.

Qué significa esto

Para los equipos obligados a trabajar con modelos locales que no son de los más potentes, ya sea por requisitos de seguridad, por el presupuesto de hardware o por el perímetro de los datos, la disciplina de la ingeniería de contexto deja de ser una mejora opcional. Se convierte en una condición sin la cual el agente, sencillamente, no funciona de forma fiable.