Introducción

Para ti, que abriste este libro

En resumen: este libro es una guía práctica para obtener la mejor calidad posible de un LLM mediante el diseño del contexto.

“Le pregunté algo a ChatGPT y respondió con total seguridad. Después lo verifiqué y era todo mentira.”

¿Te ha pasado?

El protagonista de este libro es el LLM. Imagínalo como un recién contratado brillante en su primer día. Cero conocimiento del sector, pero lleno de confianza. Dale el material de onboarding correcto y se vuelve un colaborador inmediato.

Si empezaste a usar LLMs en el trabajo, seguramente te topaste con este problema. Ajustas el prompt, defines un rol, agregas “responde con precisión”. Y la IA sigue mintiendo con confianza.

Este libro nació de un experimento que enfrentó ese problema de frente.

Lo que reveló el experimento

En resumen: lo que determina la calidad de las respuestas de un LLM es el diseño del contexto, no el tamaño del modelo.

Para investigar cómo se comporta la IA frente a “información que no puede saber”, construí tres herramientas internas ficticias y medí la calidad de las respuestas con cinco estrategias de contexto diferentes.

Los resultados fueron contundentes.

• Sin ningún contexto, la IA devolvió “respuestas plausibles pero totalmente fabricadas”
• Con RAG (Retrieval-Augmented Generation) al incorporar documentación, la precisión factual pasó de cero a 4,8
• El hallazgo más sorprendente: un modelo más pequeño con buen contexto (puntaje 11,8) aplastó a un modelo más grande sin contexto (puntaje 5,3)

Lo que decide la calidad de salida de un LLM no es el tamaño del modelo ni la astucia del prompt. Es el diseño del contexto.

La disciplina de diseñar ese contexto de forma sistemática es la Ingeniería de Contexto.

---

Cómo está organizado este libro

El libro se divide en tres partes.

Parte 1, “Lo que cambia cuando cambia el contexto” (Capítulos 1-4), recorre los resultados experimentales y explica por qué hace falta la Ingeniería de Contexto. El Capítulo 4 incluye un ejercicio práctico que mejora un System Prompt directamente. La idea es sentir el efecto con tus propias manos antes de profundizar en la teoría.

Parte 2, “Cinco técnicas, en capas” (Capítulos 5-9), cubre una a una las técnicas que componen la Ingeniería de Contexto: few-shot, RAG, MCP, memoria, etc. Cada capítulo enlaza con los datos experimentales para que veas “si agrego esta técnica, ¿cómo cambia el puntaje?”, así evalúas costo-beneficio mientras lees.

Parte 3, “Ingeniería de Contexto en el campo” (Capítulos 10-15), presenta patrones del mundo real: diseño de CLAUDE.md para Claude Code, implementación de Agentic RAG, adopción en empresas y más.

Cada capítulo termina con una 🚀 Próxima acción: algo concreto para hacer justo después de leer. El objetivo no es asentir y seguir adelante. Es dejarte con algo para probar mañana.

Sobre la “Serie de Prácticas de IA para Ingenieros”

Este es el volumen 2 de la “Serie de Prácticas de IA para Ingenieros”.

• Volumen 1: Practical Claude Code. La práctica de la programación asistida por IA.
• Volumen 2: Ingeniería de Contexto (este libro). Cómo lograr que la IA piense correctamente.

Lo que comparten los libros: todo está fundamentado en lo que el autor aprendió haciendo el trabajo de verdad. Los datos experimentales aquí son datos primarios de llamadas reales a la API, no citas de teoría.

Este libro es independiente. Puedes leerlo sin haber leído el volumen 1.

Para quién es este libro

• Ingenieros que empezaron a usar LLMs en el trabajo
• Equipos que implementaron RAG y no están satisfechos con la precisión
• Desarrolladores que construyen agentes de IA
• Quienes se pregunten “¿qué viene después del prompting?”

Los únicos requisitos previos son Python básico y conocimiento básico de APIs. No necesitas familiaridad profunda con el funcionamiento interno de los LLMs.

Cómo leerlo

Recomiendo leerlo en orden, pero aquí van algunos atajos:

• Solo quieres el resumen → Capítulo 1 y Capítulo 13
• Quieres mejorar RAG → Capítulo 6 y Capítulo 7
• Quieres usar Claude Code bien → Capítulo 10
• Estás considerando adopción empresarial → Capítulo 12 (a y b)

Con eso, entremos al mundo de la Ingeniería de Contexto.

Continúa este capítulo en Kindle →

Una brecha de calidad de 2,2x, en un experimento

En resumen: la cantidad y calidad del contexto determinan la calidad de salida de un LLM.

En el otoño de 2025, un resultado de benchmark me dejó sin palabras. El mismo LLM, con la misma pregunta, produjo respuestas que variaban en calidad por un factor de 2,2x, solo porque cambiamos el contexto que le dimos.

Misma pregunta, calidad de respuesta diferente, dependiendo de qué tan grueso fuera el material de onboarding. Así funcionan los nuevos integrantes, y resulta que los LLMs funcionan igual.

La calidad de salida se evaluó en cuatro ejes (0-5 cada uno, 20 totales):

• Factual Accuracy: ¿la respuesta coincide con la especificación real?
• Hallucination Resistance: ¿el modelo evita fabricar información?
• Specificity: ¿la respuesta incluye detalle práctico y concreto?
• Honesty: ¿el modelo comunica incertidumbre y límites de forma adecuada?

Más alto es mejor en los cuatro. A continuación, los resultados de preguntarle a Claude Sonnet 4 sobre una herramienta interna ficticia llamada “PropelAuth”:

Estrategia de contexto	Factual Accuracy	Hallucination Resistance	Specificity	Honesty	Total
Sin contexto	0,6	0,3	4,2	0,2	5,3
Solo system prompt	0,0	3,5	1,7	3,7	8,8
System + few-shot	0,0	5,0	0,0	5,0	10,0
System + RAG	4,6	0,8	4,5	0,3	10,2
Contexto completo	4,8	1,0	4,8	0,8	11,4

Claude Haiku 3 fue aún más impactante:

Estrategia de contexto	Factual Accuracy	Hallucination Resistance	Specificity	Honesty	Total
Sin contexto	0,0	0,7	1,2	0,3	2,2
Solo system prompt	0,0	0,7	0,3	2,7	3,7
System + few-shot	0,0	3,5	1,2	3,5	8,2
System + RAG	4,8	1,7	4,0	1,3	11,8
Contexto completo	4,8	0,5	4,3	0,5	10,1

En Haiku, la brecha de calidad llegó a 4,6x. Esto no se trata de redactar mejor el prompt. La salida cambia tanto solo diseñando lo que el LLM “ve”.

PropelAuth: preguntarle a una herramienta interna ficticia

En resumen: con la misma pregunta, distintos contextos produjeron cinco respuestas completamente distintas.

La pregunta usada en el experimento, sobre una herramienta ficticia de autenticación llamada “PropelAuth”:

Cuéntame sobre las funciones de gestión de organizaciones de PropelAuth. En concreto, ¿cómo se crea una organización, se invitan usuarios y se gestionan permisos?

Probé esta pregunta con cinco estrategias de contexto diferentes. Las respuestas vinieron como si describieran cinco productos distintos.

Estrategia 1: sin contexto (Total 5,3/20)

PropelAuth ofrece funciones de gestión de organizaciones como parte de su
servicio de autenticación.

Crear una organización:
- Los administradores crean una nueva organización desde el dashboard
- Configura nombre y dominio de la organización
- Integración SSO disponible en la configuración inicial

Invitar usuarios:
- Función de invitación por email
- Los enlaces de invitación expiran en 24 horas
- Admite invitaciones masivas

Gestión de permisos:
- Role-Based Access Control (RBAC)
- Se pueden crear roles personalizados
- Permisos granulares

A primera vista parece preciso. Sin embargo, PropelAuth es una herramienta ficticia. El LLM “rellenó” funciones que no existen, generando una respuesta segura, específica y convincente.

Estrategia 2: solo system prompt (Total 8,8/20)

Después de agregar “si no sabes, di ‘desconocido’” al system prompt:

Lo siento, no tengo información precisa sobre las funciones específicas
de gestión de organizaciones de la herramienta llamada PropelAuth.

Los servicios de autenticación en general incluyen funciones como:

- Creación de organizaciones
- Sistemas de invitación de usuarios
- Gestión de permisos

Para detalles de implementación específicos de PropelAuth, recomiendo
revisar la documentación oficial.

La Honesty mejoró de forma marcada, pero la Factual Accuracy se quedó en cero y la especificidad cayó.

Estrategia 5: Ingeniería de Contexto completa (Total 11,4/20)

Después de combinar system prompt, ejemplos few-shot, recuperación basada en RAG, definiciones de herramientas y salida estructurada:

[Confianza: Alta] Estas son las funciones de gestión de organizaciones de PropelAuth.

■ Creación de organización
- PropelAuth Dashboard > Organizations > "Create New Org"
- Campos requeridos: nombre de organización, subdominio
- Opcionales: logo personalizado, configuración de tema

■ Invitación de usuarios
- Invitación masiva: carga de CSV soportada
- Plantillas de email de invitación: personalizables
- Vencimiento: 7 días por defecto (configurable)

■ Gestión de permisos
- Roles predefinidos: Admin, Member, Viewer
- Roles personalizados: hasta 50
- Herencia: nivel org > nivel team > nivel individual

[Fuente] Documentación oficial de PropelAuth v2.1.3
[Última actualización] 15 de septiembre de 2024

Factual Accuracy, Specificity y Honesty están balanceadas en un nivel alto. Como la respuesta está fundamentada en documentación precisa inyectada vía RAG, la precisión factual sube de forma marcada.

---

Por qué una herramienta ficticia

La razón por la que el experimento usa herramientas ficticias (“PropelAuth”, “StormDB”, “FlowPipe”) es directa. Elimina información que el LLM “ya podría saber” desde sus datos de entrenamiento, así medimos el efecto de la Ingeniería de Contexto de forma limpia.

Preguntar por una herramienta real (Firebase, Supabase) mezcla el conocimiento preentrenado del modelo y la mejora desde el contexto se vuelve difícil de aislar. Con herramientas ficticias, obtenemos medición limpia sobre:

1. Cuantificar la alucinación

Podemos medir cuánta ficción plausible genera el LLM sobre información que no puede saber. Sin contexto, Sonnet 4 obtuvo 4,2/5 en Specificity. Es decir, “mentiras muy específicas y muy detalladas”.

2. Medir la mejora de honestidad

Agregar “si no sabes, di ‘desconocido’” en el system prompt movió la honestidad de 0,2 a 3,7 (Sonnet 4). Esa mejora no se puede medir limpiamente con herramientas reales.

3. Cuantificar el valor del contexto

El aumento en factual accuracy desde RAG se puede medir sin ruido. En Sonnet 4, pasó de 0,6 a 4,6.

Lo que significa la evaluación de cuatro ejes

En resumen: la calidad de un LLM no se puede medir con una sola métrica. Usa cuatro ejes balanceados.

Los cuatro ejes:

Factual Accuracy

• Definición: ¿la información es factualmente correcta?
• Cómo medirla: comparación con la especificación real
• Por qué importa: señal de calidad más básica

Hallucination Resistance

• Definición: ¿el modelo evita fabricar información sin fundamento?
• Cómo medirla: adecuación de la respuesta ante información desconocida
• Por qué importa: directamente ligada a la confiabilidad en producción

Specificity

• Definición: ¿la respuesta es concreta y operativa, no abstracta?
• Cómo medirla: presencia de instrucciones paso a paso, números, ejemplos
• Por qué importa: impulsa la usabilidad

Honesty

• Definición: ¿el modelo comunica incertidumbre y límites?
• Cómo medirla: “no sé” explícito, expresiones de confianza
• Por qué importa: previene exceso de confianza e incomprensión

Estos ejes implican compensaciones entre sí. Aumentar la specificity tiende a elevar la alucinación. Apoyarse en honesty suele bajar la specificity. El punto de la Ingeniería de Contexto es mantener los cuatro altos al mismo tiempo.

Por qué el mismo LLM produce 2,2x de calidad distinta

¿Por qué el mismo LLM, con la misma pregunta, produce calidad tan distinta? Porque el LLM depende fuertemente del contenido de su ventana de contexto.

1. La falta de información empuja a más conjeturas

Cuando el contexto es escaso, el LLM recurre a la conjetura para producir una respuesta “plausible”. El ejemplo: no sabe nada sobre PropelAuth y aun así enumeró funciones específicas.

2. Las instrucciones explícitas cambian el comportamiento

Un system prompt con “di ‘desconocido’ cuando no sepas” cambia el patrón de comportamiento del LLM. De ahí viene el aumento del puntaje de honesty.

3. La información relevante mejora la calidad

RAG aporta información precisa, así el modelo no tiene que adivinar. De ahí viene el aumento de factual accuracy.

4. Los enfoques combinados se potencian

La Ingeniería de Contexto completa integra estos elementos. El efecto combinado va más allá de la suma de las contribuciones individuales. Los cuatro ejes mejoran de forma balanceada: esa es la prueba.

---

Lo que esto significa para producción

Estos resultados tienen implicaciones directas para usar LLMs en producción:

1. Solo afinar el prompt tiene un techo

Muchos desarrolladores se enfocan en escribir “prompts ingeniosos”. Eso solo no entregará ganancias fundamentales de calidad. Hay que diseñar todo el entorno de información.

2. La información específica del dominio vale enormemente

El LLM no tiene datos de entrenamiento sobre tu producto o las particularidades de tu industria. El aumento de RAG o fine-tuning es mayor de lo que la gente espera.

3. Incluso los modelos pequeños ganan calidad masiva con buen contexto

Un modelo liviano como Haiku 3 vio una mejora de calidad de 4,6x mediante la Ingeniería de Contexto. Antes de saltar a un modelo más grande, revisa tu diseño de contexto.

4. La calidad debe evaluarse multidimensionalmente

No te apoyes en una sola métrica (tiempo de respuesta, costo). Evalúa factual accuracy, hallucination resistance, specificity y honesty juntas.

Cómo está estructurado este libro y tu ruta de aprendizaje

Partiendo de estos resultados experimentales, el libro cubre la Ingeniería de Contexto así:

Parte 1: detectar el problema

• Capítulo 2: tres causas raíz de por qué la IA miente
• Capítulo 3: los límites de la ingeniería de prompts y el inicio de la Ingeniería de Contexto
• Capítulo 4: empezar con mejoras al system prompt

Parte 2: las técnicas fundamentales

• Implementación de RAG (Retrieval-Augmented Generation)
• Uso efectivo de few-shot learning
• Principios de diseño para system prompts

Parte 3: aplicación práctica

• Implementación en sistemas empresariales
• Evaluación de rendimiento y monitoreo
• Ciclos de mejora continua

Cada capítulo mezcla teoría con ejercicios prácticos. El paso más importante es sentir la mejora de calidad en tu propio entorno.

La era de la ingeniería de prompts está llegando a su fin. De aquí en adelante, la disciplina es diseñar todo el entorno de información que ve el LLM: la Ingeniería de Contexto. Cuando dos personas usan la misma herramienta y obtienen resultados distintos, este es el diferenciador.

El próximo capítulo recorre tres causas raíz de por qué los LLMs se vuelven “mentirosos”. Entender el mecanismo deja mucho más claras las soluciones.

🚀 Próxima acción: pregúntale a tu LLM sobre un “término que no puede saber” de tu empresa

Para experimentar lo que describió este capítulo:

1. Inventa el nombre de una herramienta interna ficticia

   • Ejemplos: “DataSync Pro”, “TeamFlow Hub”, “SecureLink Manager”
   • Elige nombres que suenen plausibles pero no existan

2. Haz preguntas específicas

   • “¿Cómo configuro X?”
   • “¿Cómo cambio los permisos de usuario en X?”
   • “¿Cómo funciona la API de X?”

3. Revisa la respuesta

   • ¿Qué tan específica es la mentira?
   • ¿El modelo dice honestamente “no sé”?
   • ¿Qué tan plausible suena?

4. Registra los resultados

   • Specificity: 1-5
   • Honesty: 1-5
   • Notas sobre lo que te sorprendió

Este ejercicio te da una sensación directa de qué tan astuto, y qué tan peligroso, es el comportamiento de “adivinar y rellenar” del LLM. El próximo capítulo desarrolla las tres causas raíz que explican este fenómeno.

Continúa este capítulo en Kindle →

El “enlace de invitación de 24 horas” de PropelAuth no existe

En el capítulo anterior, Claude Sonnet 4 produjo una respuesta detallada como esta sobre la herramienta ficticia PropelAuth:

Invitación de usuarios:

• Función de invitación por email
• Los enlaces de invitación expiran en 24 horas
• Invitación masiva soportada

¿De dónde salieron las “24 horas”? PropelAuth es ficticio. No hay especificación real. Y aun así, el LLM generó una descripción de funciones tan detallada como la de un servicio real.

Esto no es accidental. A los nuevos integrantes les cuesta decir “no sé” porque quieren parecer competentes. A los LLM les pasa lo mismo. Las mentiras de la IA son una consecuencia inevitable de restricciones técnicas y principios de diseño, no un fallo. Este capítulo explica las tres causas principales.

Razón ①: el mecanismo de “rellenar lo plausible” para información desconocida

En resumen: los LLMs están construidos para “llenar el hueco con una conjetura”, no para decir “no sé”.

La naturaleza de la alucinación

Cuando un LLM genera información que no es verdadera, eso es “alucinación”. No es simplemente un bug. Es un fenómeno enraizado en el principio operativo básico del LLM.

Los LLMs generan texto prediciendo el siguiente token. Dado el prefijo “el enlace de invitación de PropelAuth expira en”, el modelo elige probabilísticamente entre valores que ha visto en patrones similares: “24 horas”, “7 días”, “30 días”.

El problema: el LLM no tiene información de que PropelAuth es ficticio. Mezcla patrones de otros servicios de autenticación que vio durante el entrenamiento (Auth0, Firebase Auth, AWS Cognito) y produce una respuesta plausible.

El peligro del relleno por correspondencia de patrones

Mira los datos experimentales con más detalle:

Modelo	Specificity sin contexto	Factual Accuracy sin contexto
Sonnet 4	4,2/5	0,6/5
Haiku 3	1,2/5	0,0/5

Sonnet 4 produjo respuestas “muy específicas” (4,2/5) sobre información que no podía saber. Es evidencia de una gran capacidad de reconocimiento de patrones, y también de un riesgo.

Un ejemplo concreto:

Funcionalidad real de Auth0 (herramienta real):

• Vencimiento del email de invitación: configurable (predeterminado 7 días)
• Invitación masiva: admite importación por CSV
• Gestión de permisos: RBAC + roles personalizados

Contenido generado por el LLM sobre PropelAuth:

• Vencimiento del enlace de invitación: 24 horas
• Invitación masiva: soportada
• Gestión de permisos: RBAC + roles personalizados

El LLM combina patrones conocidos y ajusta los números para producir información “nueva”. Esa astucia es lo que hace difícil detectar la alucinación.

El límite invisible del conocimiento

Peor aún: el LLM no puede reconocer el límite de su propio conocimiento.

Una persona puede pensar “¿PropelAuth? Nunca lo escuché”. El LLM no puede distinguir:

1. Cosas que sabe con certeza: hechos claramente en los datos de entrenamiento
2. Cosas que puede adivinar: contenido extrapolado a partir de patrones
3. Cosas que no tiene idea: contenido ficticio fuera de los datos de entrenamiento

Por ese límite borroso, miente con confianza.

El relleno como propiedad de la IA generativa

El punto importante: esto no es un “defecto”. Es una propiedad fundamental de la IA generativa.

Los LLMs se entrenan para estos objetivos:

• Generación fluida de texto: producir texto que se lea naturalmente
• Mantener coherencia: ser consistente con el contexto que rodea
• Cumplir las expectativas del usuario: dar respuestas útiles a las preguntas

Decir “no sé” va contra esos objetivos. Por eso los LLM tienden, casi por reflejo, a “responder algo” y terminan llenando huecos con conjeturas.

---

Razón ②: los modelos más grandes mienten con más habilidad

En resumen: a medida que los modelos se vuelven más astutos, las mentiras se vuelven más convincentes.

La relación proporcional entre tamaño y calidad de la mentira

Los experimentos revelaron algo interesante. Los modelos más grandes y capaces producen mentiras más pulidas.

Modelo	Specificity	Factual Accuracy	Sofisticación de la mentira
Sonnet 4	4,2/5	0,6/5	extremadamente alta
Haiku 3	1,2/5	0,0/5	moderada

Nota: Anthropic no publica el conteo de parámetros, pero Sonnet 4 es sustancialmente más grande que Haiku 3.

La factual accuracy de Sonnet 4 es ligeramente más alta (0,6 vs 0,0), pero la specificity difiere de forma marcada (4,2 vs 1,2). ¿Qué significa eso?

La alta capacidad lingüística genera persuasión

Los modelos más grandes producen texto más natural y detallado. Normalmente eso es una fortaleza. En el contexto de la alucinación, es un arma.

Muestra de Haiku 3 (Specificity 1,2):

PropelAuth tiene funciones básicas de gestión de organizaciones.
Para detalles, consulta la documentación oficial.

Muestra de Sonnet 4 (Specificity 4,2):

Estas son las funciones de gestión de organizaciones de PropelAuth.

Creación de organización:
- Los administradores crean una nueva organización desde el dashboard
- Configura nombre y dominio de la organización
- Integración SSO disponible en la configuración inicial

Invitación de usuarios:
- Función de invitación por email
- Los enlaces de invitación expiran en 24 horas
- Invitación masiva soportada

¿Cuál es la respuesta “correcta”? Paradójicamente, la respuesta más vaga y menos detallada de Haiku 3 es más honesta.

Uso hábil de jerga técnica

Los modelos más grandes usan términos técnicos con más naturalidad. Eso hace las mentiras más persuasivas.

Mentiras detalladas de Sonnet 4 sobre PropelAuth:

Gestión de permisos:
- Role-Based Access Control (RBAC)
- Se pueden crear roles personalizados
- Configuración de permisos granulares
- Compatible con OAuth 2.0 / OIDC
- Integración SAML SSO
- Aprovisionamiento JIT (Just In Time)

Estos términos (RBAC, OAuth 2.0, OIDC, SAML, JIT) son tecnologías de autenticación reales. En el contexto de PropelAuth, sin embargo, todo es ficción.

El uso hábil de la jerga hace pensar al lector “esto se ve técnicamente correcto”. La corrección técnica se confunde con la corrección factual.

La coherencia interna crea ilusión de confianza

Los modelos más grandes son mejores manteniendo coherencia interna en el texto generado. Eso también refuerza la mentira.

Si el modelo dice “el enlace de invitación expira en 24 horas”, luego produce de forma consistente “vencimiento corto por razones de seguridad” y “acción requerida dentro de 24 horas” en el mismo contexto.

La coherencia construye una explicación sistemática alrededor de la información ficticia, elevando la credibilidad de toda la mentira.

La paradoja de la capacidad en el desarrollo de IA

Este es un dilema fundamental en el desarrollo moderno de IA:

• Aumentar la capacidad → respuestas más naturales, más detalladas
• Respuestas más detalladas → mentiras más persuasivas
• Mentiras más persuasivas → mayor riesgo de que los usuarios sean engañados

Solo “hacer la IA más astuta” no resuelve esto. Puede empeorarlo.

---

Razón ③: “Siempre responder” se diseñó por una razón

En resumen: los LLMs crecieron en un entorno donde “no sé” recibe puntaje bajo.

Expectativas humanas y diseño de comportamiento de la IA

¿Por qué a los LLMs les cuesta el “no sé”? La respuesta está en las expectativas humanas y los métodos de entrenamiento de la IA.

Las primeras evaluaciones de asistentes de IA enfatizaron criterios como:

1. Utilidad: dar información útil para la pregunta del usuario
2. Capacidad de respuesta: no rechazar la pregunta; dar alguna respuesta
3. Amplitud de conocimiento: manejar preguntas en muchos dominios

Estos criterios califican mal el “no sé”.

El efecto secundario de RLHF

La mayoría de los LLMs modernos se entrenan con RLHF (Reinforcement Learning from Human Feedback). Evaluadores humanos califican respuestas de IA y ese feedback moldea el comportamiento de la IA.

En este proceso surge un problema:

Tendencias de los evaluadores humanos:

• Califican alto las respuestas detalladas y específicas
• Califican bajo las respuestas de “no sé”
• Tiempo limitado por evaluación, así que la verificación de hechos es superficial

Entrenamiento resultante de la IA:

• Las respuestas detalladas se vuelven el comportamiento “correcto”
• Incluso la información incierta se responde con algo
• La specificity se pondera por encima de la corrección factual

Evidencia en el cambio de comportamiento dirigido por system prompt

El experimento prueba que las instrucciones explícitas pueden cambiar esto:

Instrucción	Honesty de Sonnet 4	Honesty de Haiku 3
Ninguna	0,2/5	0,3/5
”Di ‘desconocido’ cuando no sepas”	3,7/5	2,7/5

La mejora dramática (0,2→3,7) muestra que el LLM puede comportarse de forma adecuada cuando se le dan instrucciones explícitas.

El otro lado: el comportamiento por defecto está diseñado para “responder algo”.

Desencuentro con las expectativas empresariales

Este diseño se acomoda a asistentes de consumo, pero crea problemas serios en casos de uso empresariales:

Uso de consumo:

• Usuario: “información aproximada está bien, solo dime”
• IA: “probablemente es X” (con cobertura razonable)
• Resultado: el usuario asume la responsabilidad de usar la información

Uso empresarial:

• Usuario: “necesito información precisa. Si no estás seguro, dilo claramente”
• IA: “(basado en inferencia) aquí va la información detallada”
• Resultado: decisiones de negocio basadas en información imprecisa

Por qué el comportamiento por defecto necesita rediseñarse por caso de uso

Resolver esto requiere rediseñar el comportamiento por defecto por caso de uso:

Diseño conservador:

• Marcar la información incierta de forma explícita
• Distinguir conjeturas de hechos
• Expresar la confianza numéricamente

Diseño consciente del contexto:

• Consultas casuales → respuestas más ricas que incluyan conjeturas
• Decisiones importantes → solo información cierta
• Uso empresarial → siempre mostrar fuente y nivel de confianza

---

Factual Accuracy vs Specificity: una compensación crítica

En resumen: “detallado” y “correcto” suelen tirar en direcciones opuestas.

La relación inversa en números

Los datos experimentales revelan un patrón interesante:

Sonnet 4 (sin contexto):

• Factual Accuracy: 0,6/5 (baja)
• Specificity: 4,2/5 (alta)

Haiku 3 (sin contexto):

• Factual Accuracy: 0,0/5 (la más baja)
• Specificity: 1,2/5 (baja)

Sonnet 4 (solo system prompt):

• Factual Accuracy: 0,0/5 (la más baja)
• Specificity: 1,7/5 (cae)

Estos números apuntan a una verdad dura: ser específico y ser factualmente correcto suelen entrar en conflicto.

El dilema “mentira detallada” vs “ignorancia honesta”

Para ver esta compensación, compara dos respuestas:

Respuesta A (detallada pero incorrecta):

Para la gestión de organizaciones de PropelAuth, configura los permisos
mediante estos pasos:

1. Inicia sesión en el admin dashboard
2. Navega a "Organizations" > "Permissions"
3. Crea un nuevo rol:
   - Ingresa el nombre del rol (ej.: "Marketing Manager")
   - Selecciona el nivel de permiso: READ, WRITE, DELETE
   - Especifica los recursos: Users, Analytics, Billing
4. Asigna a usuarios:
   - Elige el destinatario en la lista de usuarios
   - Aplica el rol que acabas de crear
   - Configura el vencimiento (máx. 90 días)

Respuesta B (honesta pero vaga):

Lo siento, no tengo pasos operativos detallados para la herramienta
específica llamada PropelAuth.

Puedo compartir procedimientos generales de gestión de permisos
para sistemas de autenticación, pero para la disposición de pantallas
y opciones de configuración específicas de PropelAuth, recomiendo
consultar la documentación oficial.

En pruebas con usuarios, normalmente califican la Respuesta A más alto. El usuario puede actuar de inmediato.

PropelAuth es ficticio, sin embargo. Actuar con la Respuesta A implica buscar pantallas y funciones que no existen.

Por qué los humanos prefieren las “mentiras detalladas”

Los humanos esperan “si pregunto, aparecerá una respuesta” y asumen “si la IA lo dice, probablemente está bien”. El “no sé” obliga a investigación extra, así que la gente prefiere información que parezca usable de inmediato. El sesgo de confirmación y la evitación de la carga cognitiva son las razones principales por las que las alucinaciones se cuelan.

Cálculo de costos en la empresa (ilustrativo)

En entornos empresariales, esta compensación se vuelve un problema serio de costos:

Costo de actuar sobre una “mentira detallada”:

• Acción basada en información imprecisa → descubrimiento del error → retrabajo → horas o días perdidos

Costo de partir de la “ignorancia honesta”:

• Investigar información precisa → ejecutar correctamente → terminado en 1-3 horas

La “ignorancia honesta” es el camino más eficiente, pero psicológicamente la gente prefiere la “mentira detallada”.

Cómo la Ingeniería de Contexto resuelve esta compensación

El experimento muestra que la Ingeniería de Contexto bien aplicada resuelve parcialmente la compensación:

Ingeniería de Contexto completa (Sonnet 4):

• Factual Accuracy: 4,8/5 (aumento marcado)
• Specificity: 4,8/5 (mantenida)
• Honesty: 0,8/5 (balanceada)

La clave es que RAG aporta información precisa, así que las respuestas específicas ya no tienen que apoyarse en conjeturas.

Ese es el valor central de la Ingeniería de Contexto: entregar hechos detallados, no mentiras detalladas.

---

Por qué la alucinación es una “feature”, no un “bug”

En resumen: la alucinación no es un defecto del LLM. Es el principio operativo de la IA generativa.

Cómo funciona realmente la IA generativa

Un cambio importante de perspectiva: la alucinación no es un “bug” de los LLMs. Es una “feature” embebida en el diseño.

De forma concisa, un LLM opera así:

1. Tokenizar el texto de entrada: convertir texto en vectores numéricos
2. Reconocimiento de patrones: identificar patrones similares en los datos de entrenamiento
3. Cálculo de probabilidad: calcular la probabilidad del siguiente token
4. Selección probabilística: elegir un token según esas probabilidades
5. Generación de texto: encadenar los tokens elegidos en texto

Ese proceso no contiene “verificación de hechos” ni “reconocimiento de límites de conocimiento”. El LLM es, fundamentalmente, un generador sofisticado de texto basado en patrones.

Memoria perfecta vs razonamiento creativo: el dilema

¿Y si un LLM se diseñara para “no responder nunca cuando no sabe”?

Beneficios:

• Alucinaciones eliminadas
• Factual accuracy aumentada de forma marcada
• Confiabilidad mejorada

Costos:

• Pérdida de razonamiento creativo
• Sin nuevas combinaciones de ideas
• Caída marcada de utilidad

Cuando se le pide “ideas nuevas de marketing”, respuestas fundamentadas solo en hechos conocidos no producirán ideas creativas o innovadoras.

Similitud con la cognición humana

En cierto sentido, la alucinación se parece a la cognición humana:

Pensamiento humano:

• Combinar conocimiento conocido
• Construir hipótesis y conjeturas
• Crear nuevas ideas mediante analogía
• Juzgar a partir de información incompleta

Generación del LLM:

• Combinar patrones aprendidos
• Completado probabilístico
• Razonamiento por similitud
• Generación a partir de contexto incompleto

La diferencia: los humanos pueden reconocer su propia incertidumbre. Decimos naturalmente cosas como “esto es una conjetura” o “no estoy seguro pero”.

El valor real de la Ingeniería de Contexto

Por eso importa la Ingeniería de Contexto. No cambia la naturaleza del LLM; provee un entorno de información apropiado para canalizar su capacidad en la dirección correcta.

Enfoque viejo:

• Decirle al LLM “responde correctamente”
• Tratar la alucinación como una “feature mala” a suprimir
• Apuntar a la perfección

Enfoque de Ingeniería de Contexto:

• Darle al LLM la información que necesita
• Tratar la alucinación como una “señal de falta de contexto”
• Diseñar el balance entre practicidad y precisión

---

Cinco señales de que un LLM está mintiendo

Una habilidad práctica: detectar alucinaciones peligrosas en respuestas de un LLM.

1. Especificidad excesiva en números, fechas y nombres propios

Señales de alerta:

• “Vencimiento de 24 horas”
• “Hasta 50 roles personalizados”
• “Documentación v2.1.3”

Cómo verificar:

• Comprueba si los números tienen fundamento
• Cruza referencias con la documentación real
• Verifica que los números de versión existan

2. Organización sospechosamente perfecta

Señales de alerta:

• Listas de funciones ordenadas
• Explicaciones detalladas sin contradicciones
• Niveles de completitud “de libro de texto”

Realidad:

• El software real tiene restricciones y excepciones
• La documentación es incompleta e inconsistente
• Existen casos límite y problemas conocidos

3. Uso poco natural de jerga técnica

Señales de alerta:

• Apilar términos técnicos para dar aura de autoridad
• Combinaciones inadecuadas de tecnologías reales
• Jerga que no es necesaria para el contexto

4. Evitación de citar fuentes explícitas

Señales de alerta:

• Frases vagas como “generalmente”, “típicamente”, “básicamente”
• Sin referencia a documentación específica o referencias de API
• “Confirma con el sitio oficial” usado como evasiva

5. Respuestas que coinciden perfectamente con las expectativas del usuario

Señales de alerta:

• Exactamente la respuesta que la pregunta sugería
• Sin mención de dificultad o complejidad
• Sin mención de “esto no es posible” o “esto está restringido”

Puente al próximo capítulo: organizar la solución

Este capítulo mostró que las “mentiras” de la IA vienen de tres factores inevitables:

1. Restricción técnica: relleno por correspondencia de patrones
2. Filosofía de diseño: un sistema de valores que prioriza “responder”
3. La paradoja de la capacidad: una capacidad lingüística más fuerte produce mentiras más persuasivas

No hay motivo para desesperarse. El experimento mostró que la Ingeniería de Contexto bien aplicada puede mejorar sustancialmente las tres.

El próximo capítulo recorre la historia desde la “ingeniería de prompts” hasta la “Ingeniería de Contexto” y la ciencia detrás. Quedará claro por qué la respuesta no son prompts más astutos sino diseñar todo el entorno de información.

🚀 Próxima acción: elige tres nombres propios o números de una respuesta de IA y verifícalos

Practica la técnica de “detectar mentiras”:

Paso 1: pregúntale a la IA

Haz preguntas detalladas sobre una tecnología o servicio que conozcas:

• “¿Qué hay de nuevo en la versión X?”
• “¿Cuáles son los límites de tasa de la API de X?”
• “¿Cuáles son los planes de precios de X?”

Paso 2: extrae nombres propios y números

Elige tres de cada categoría en la respuesta:

• Números específicos: precios, límites, números de versión
• Nombres propios: nombres de funciones, nombres de planes, nombres de tecnología
• Fechas / períodos: fecha de release, vencimiento, frecuencia de actualización

Paso 3: verifica los hechos

Confirma contra la documentación oficial:

• ¿Los números son precisos?
• ¿Los nombres de las funciones son correctos?
• ¿La información es vigente?

Paso 4: analiza el patrón

• ¿Qué tipos de información generan mentiras con más facilidad?
• ¿Cuál es la diferencia entre “mentiras de alta confianza” y “mentiras de baja confianza”?
• ¿Hay diferencias entre dominios?

Plantilla de registro

[Pregunta]

[Respuesta de la IA]

[Información extraída]
Números: 1. _____ 2. _____ 3. _____
Nombres propios: 1. _____ 2. _____ 3. _____
Fechas: 1. _____ 2. _____ 3. _____

[Resultados de verificación]
Precisos: ___
Imprecisos: ___
Desconocidos: ___

[Observaciones]

A través de este ejercicio, obtendrás una comprensión palpable de los patrones de “mentira plausible” del LLM. El próximo capítulo recorre la solución sistemática.

Continúa este capítulo en Kindle →