Cómo la Ingeniería de Contexto Hace que un LLM Local Débil Sea un Agente Confiable

El autor de un artículo en Habr demostró: para un modelo de lenguaje local que se ejecuta en un circuito cerrado en hardware limitado, la confiabilidad de un agente se determina no por el tamaño del modelo, sino por cómo se organiza su contexto.

Por qué simplemente "tomar un modelo más grande" no funciona

Cuando un modelo se ejecuta localmente — dentro del perímetro de una empresa, en hardware limitado — aumentar su tamaño simplemente no es posible: no hay forma de tomar un modelo en la nube de nivel superior con una gran cantidad de parámetros. El autor argumenta que en estas condiciones, el principal impulsor de la calidad no es el modelo en sí, sino el contexto: exactamente qué se le muestra, en qué orden y cómo se filtra la información innecesaria.

Qué compone el contexto "correcto"

Según la descripción del autor, el contexto no es solo texto insertado, sino un conjunto que tiene en cuenta tres parámetros: quién hace la pregunta, de dónde viene y qué exactamente se está preguntando. Se añaden dos elementos más a esto:

• Un umbral de relevancia honesto — al modelo se le muestra solo lo que realmente se relaciona con la pregunta, no todo "por si acaso"
• Un orden de secciones reflexivo — la información importante para responder se coloca para que el modelo no la "pierda" entre detalles secundarios

En otras palabras, para la misma pregunta, el contexto será diferente dependiendo del rol del usuario, el canal de comunicación y el tema: un empleado de soporte y un desarrollador deberían ver fragmentos diferentes de la base de conocimiento, incluso si formalmente están haciendo "la misma pregunta".

Cómo los modelos fuertes se diferencian de los débiles en este escenario

La observación clave del artículo — cómo un modelo perdona errores en la organización del contexto — depende de su tamaño y potencia. En un modelo en la nube fuerte, el contexto ensamblado descuidadamente a menudo se perdona por reservas de razonamiento — el modelo averiguará por sí solo qué es importante y qué no. En un modelo local de nivel medio, no hay tal reserva: el mismo contexto descuidado rompe directamente la calidad de la respuesta.

En la práctica, esto significa que los prompts y el context-pipeline deben probarse en el modelo objetivo (débil), no en un modelo en la nube de nivel superior — lo que se ve viable en un modelo fuerte puede desmoronarse cuando se transfiere a uno local.

Dónde esto es especialmente crítico

Los modelos locales se eligen con mayor frecuencia donde los datos no pueden abandonar el perímetro — bancos, sector público, medicina, manufactura. En tales entornos, el equipo no tiene la opción de "simplemente tomar un modelo más poderoso": el hardware y las licencias para API en la nube de nivel superior no están disponibles o están prohibidos por la política de seguridad. En estas condiciones, la ingeniería de contexto — el único impulsor que se puede gestionar directamente, a diferencia de la arquitectura del modelo en sí.

El autor hace énfasis especial en la diferencia entre "contexto en general" y "contexto para una solicitud específica": si un sistema una vez ensambló un conjunto universal de documentos y los alimenta al modelo indiscriminadamente, independientemente de quién pregunta y sobre qué, las posibilidades de obtener una respuesta fragmentaria o incorrecta en un modelo débil son notablemente más altas que con un ensamblaje preciso para cada caso.

Qué significa esto

Para equipos obligados — por requisitos de seguridad, restricciones de presupuesto de hardware o alcance de datos — a trabajar con modelos locales, no muy potentes, la disciplina de la ingeniería de contexto se convierte en no una mejora opcional, sino en una condición sin la cual un agente simplemente no funciona de manera confiable.