Cuando un sistema de IA empresarial proporciona una respuesta poco fiable, el diagnóstico habitual culpa al modelo. Sin embargo, según el artículo fuente, un fallo más frecuente y más difícil de detectar está en otra parte: un modelo de lenguaje grande (LLM) puede razonar correctamente a partir de un contexto mal seleccionado.
Los remedios más comunes son un modelo más potente, un prompt más largo, más documentos recuperados o una ventana de contexto más amplia, es decir, la cantidad de información que un modelo puede procesar a la vez. Cada uno puede ayudar, pero ninguno resuelve directamente este problema. En los sistemas analíticos, el cálculo puede ser correcto y la explicación coherente, y la respuesta seguir siendo falsa: el sistema ha elegido pruebas erróneas, seguido un enlace incorrecto entre tablas o dado a un término empresarial ambiguo una definición que el usuario no tenía en mente. El error ocurre antes de cualquier cálculo.
Tomemos una pregunta simple: ¿cuántas horas trabaja Cam de media al día? La palabra « día » no está definida. Puede designar cada día calendario del período, un año de trabajo estandarizado, cada registro de planificación o cada fecha en la que Cam trabajó efectivamente. Dividir el total de horas por los días calendario da una media más baja que dividirlo por los días realmente trabajados en cuanto Cam tiene días de descanso. Un control clásico, que verifica que los totales coinciden, no detecta necesariamente esta mala elección de denominador.
Una pregunta empresarial, un programa de análisis
La pregunta « ¿Qué marca ha mejorado la confianza este trimestre? » parece una simple búsqueda. Responderla supone, sin embargo, decidir varios puntos: qué pregunta del cuestionario mide la confianza, qué oleadas de la encuesta forman « este trimestre », cuál es el perímetro de los encuestados, si los resultados están ponderados y qué cuenta como una mejora.
El artículo toma un caso ilustrativo. Dos tablas cruzadas parecen corresponder a la solicitud, con una descripción que solo difiere en unas pocas palabras. La primera, ponderada, se refiere al conjunto de los encuestados y muestra un ligero aumento. La segunda, no ponderada, solo se refiere a los encuestados que conocen la marca y muestra una ligera disminución. Una herramienta de búsqueda basada en la similitud las clasificaría casi a la par. Un sistema que retiene el primer resultado proporciona una respuesta fundamentada y argumentada, que puede ser falsa, sin que la elección efectuada aparezca en el resultado final. Un sistema basado en un recorrido, en cambio, detecta la diferencia de población y de ponderación y pregunta al usuario qué perímetro retener. El coste de esta pregunta de aclaración es, según el autor, muy inferior al de una cifra falsa que se parece a la correcta.
Benchmarks que miden sistemas
Los trabajos de investigación van en la misma dirección. Spider 2.0, un benchmark empresarial de text-to-SQL compuesto por 632 problemas procedentes de flujos de trabajo reales, se publicó a finales de 2024. Su sistema más eficaz, un agente construido sobre o1-preview, resolvió aproximadamente el 17 % de las tareas, frente a aproximadamente el 91 % para los mejores sistemas en el benchmark original Spider. La clasificación ha evolucionado desde entonces: su pista Snow muestra una puntuación del 96,7 %, enviada por un editor, procedente de un sistema de agente. Las puntuaciones son enviadas por los equipos mismos, y el artículo señala que los mejores resultados se basan en sistemas diseñados alrededor del modelo más que en modelos solos.
Alargar el contexto tampoco basta. Un estudio de Chroma, titulado « Context Rot », constata que los modelos se vuelven menos fiables a medida que aumenta la longitud de la entrada, incluso en tareas simples, y que distractores de apariencia similar agravan el problema.
Un recorrido en lugar de un montón
Frente a la incertidumbre, el reflejo consiste en proporcionar más información al modelo. Sin embargo, esto puede multiplicar las interpretaciones concurrentes. El enfoque descrito consiste en organizar el contexto de forma secuencial: primero la intención del estudio, luego la estructura del cuestionario, las preguntas y sus definiciones, los segmentos, los mercados, las oleadas y las reglas de ponderación, y finalmente la tabla cruzada que contiene la prueba. Cada capa hereda las restricciones de la que la precede.
Anthropic presenta la ingeniería del contexto como la continuación natural de la ingeniería del prompt, definiéndola como la gestión del conjunto del contexto de un agente, considerado como un recurso finito. El artículo considera este encuadre pertinente, pero lo sitúa un paso antes: se trata de saber qué significa la pregunta y qué pruebas pueden responderla. Para el caso de la confianza en la marca, el procedimiento sigue cinco pasos: resolver la intención, aplicar las reglas del estudio, identificar las fuentes, validar el recorrido, luego calcular con una herramienta autorizada y presentar el resultado con su definición, su base de encuestados, su ponderación y su fuente.
El autor insiste finalmente en la trazabilidad. Cada resultado debe poder relacionarse con su tabla fuente, su definición, sus filtros, su ponderación, su período y el cálculo utilizado.
