Seis conceptos de IA que le indican qué verificar antes de confiar en una respuesta

Le entregas un informe a un asistente de IA y recibes un resumen pulido que incluye un gráfico que no puedes encontrar en ningún lugar del documento. Cuando preguntas al respecto, el asistente se disculpa y ofrece otro gráfico. ¿Faltaba información, falló la recuperación o simplemente se inventó el número? Seis conceptos clave, entendidos en función de las decisiones que afectan, te permiten reemplazar la pregunta “¿Por qué miente?”, por una pregunta de diagnóstico precisa, y también te ayudan a controlar los costos y evaluar las afirmaciones de los proveedores.

Por qué el escepticismo es una actitud razonable por defecto

La desconfianza hacia los resultados generados por la IA es común incluso entre quienes la utilizan a diario. En la Encuesta de Desarrolladores de Stack Overflow de 2025, el 46% de los encuestados a la pregunta sobre precisión manifestó desconfiar en los resultados de la IA, frente al 33% que confiaba en ellos, según 33,244 respuestas (resultados de la encuesta). Lea eso con atención: registra las opiniones de los desarrolladores, no una medición de la precisión del modelo, y no constituye una muestra representativa de la población. Sin embargo, sí refleja una tensión real: las personas adoptan estas herramientas pero aún no creen en todo lo que dicen.

Primero, aplique el mismo escrutinio a los titulares

El contenido sobre la IA suele prometer que conocer unos pocos términos te coloca “por delante del 90% de las personas”. Eso suena como un resultado de investigación, pero al no haber estudio que lo respalde, se trata de marketing disfrazado de estadística. Hazte las preguntas obvias: ¿por delante de quién? ¿Cómo se mide? ¿Con qué participantes? ¿Y dónde se publican los resultados? Sin evaluación, sin muestra y sin datos, ese porcentaje carece de fundamento. Eso no significa que todas las explicaciones asociadas estén equivocadas, ni dice nada sobre las intenciones de nadie; simplemente indica que esa cifra no tiene peso alguno.

Saber las definiciones es un punto de partida. Aplicarlas, reconocer las excepciones y verificar los resultados reales son habilidades distintas, y ninguna de ellas se mide mediante un porcentaje halagador.

La misma disciplina se aplica a las promesas de que una sola solicitud puede sustituir a todo un equipo, o de que alguna herramienta multiplica por diez la velocidad de todos. Solicite la tarea específica, los parámetros de referencia, cómo se midió y cuáles fueron las limitaciones. Una sola demostración impresionante no puede establecer un resultado general. Un título llamativo está bien; los problemas comienzan cuando la afirmación es más precisa que las pruebas que la respaldan. Aplique este mismo estándar a esta guía.

1. Tokens: el tamaño real de una tarea

Un token es la unidad de texto que procesa realmente un modelo de lenguaje. Dependiendo del tokenizador, un token puede ser una palabra completa, un fragmento de palabra, un signo de puntuación o algún otro trozo de texto, y el tokenizador asigna a cada uno de ellos un ID numérico.

No existe una regla fija como “una palabra equivale a un token”. La descripción general de los tokenizadores de Hugging Face menciona varios enfoques, incluyendo la codificación por pares de bytes, WordPiece y métodos relacionados con SentencePiece; además, la misma oración puede dividirse de maneras muy diferentes según el tokenizador utilizado. Los idiomas distintos al inglés, el código y los formatos inusuales suelen requerir más tokens por palabra.

La importancia de esto se hace evidente con una pregunta como esta:

¿Cuáles son las tres quejas de los clientes que aparecen con más frecuencia?

La pregunta en sí es muy breve. Pero si responderla implica leer miles de mensajes de soporte, esa pregunta representa un error de redondeo en la cantidad total de datos de entrada. Como ilustración aproximada, 400 mensajes con unos 150 tokens cada uno ya suman 60,000 tokens antes de incluir instrucciones u otro contexto.

Por lo tanto, la pregunta importante no es cuán largo es su prompt, sino cuánto material obliga a procesar el sistema la tarea. Dado que los precios, la latencia y los límites de contexto suelen expresarse en tokens, eso es también lo que determina el costo. Antes de abordar una tarea con un documento largo, elimine las firmas de correo electrónico repetidas, los apéndices irrelevantes y los registros duplicados que no aportan evidencia alguna, manteniendo solo todo aquello de lo cual realmente depende la respuesta.

2. Ventana de contexto: qué puede ver el modelo en una solicitud

La ventana de contexto limita la cantidad de material con el que puede trabajar un modelo en una sola solicitud. Las instrucciones del sistema, el historial de conversaciones, los fragmentos recuperados y cualquier otro tipo de entrada consumen ese límite; la forma en que se contabilizan los tokens de salida depende del modelo y de la API. La documentación de Google sobre contexto extendido muestra cómo las ventanas más grandes permiten trabajar con grandes colecciones de texto y otros medios.

Aceptar un documento, sin embargo, no es lo mismo que utilizar de manera fiable cada detalle relevante en él. El estudio de 2023 “Lost in the Middle” probó la respuesta a preguntas con múltiples documentos y la recuperación de datos tipo clave-valor, y descubrió que, en los modelos analizados, la precisión solía disminuir cuando la información relevante se encontraba en medio de una entrada larga en lugar de cerca del inicio o final. Considérelo como evidencia histórica sobre esos experimentos específicos, no como una puntuación para los modelos actuales, pero la lección sobre la necesidad de verificar sigue siendo válida.

También es raro que los productos de chat se comporten como sugiere su interfaz. Cuando una conversación supera el límite de la ventana, una aplicación no tiene por qué eliminar simplemente los mensajes más antiguos; puede resumirlos, seleccionar o recuperar material anterior en su lugar. Lo que ve en el historial de chat no representa una imagen fiable de lo que llega al modelo en cada llamada.

En la práctica:

• Para tareas que requieren mucho tiempo de ejecución, mantenga un resumen breve y explícito con los requisitos y decisiones actuales, y réstelo cuando sea necesario.
• Cuando una conclusión depende de un pasaje específico, pida al asistente que cite o localice ese pasaje antes de llegar a la conclusión.

Una ventana grande brinda al sistema espacio para trabajar; eso no demuestra que el sistema haya utilizado las pruebas adecuadas.

3. Temperatura: control de la variedad, no de la verdad

En cada paso de generación, el modelo califica todos los tokens posibles siguientes. La temperatura modifica la distribución de probabilidades utilizada para seleccionar a partir de esas calificaciones: los valores bajos concentran la probabilidad en los candidatos más probables, mientras que los valores altos la distribuyen entre más opciones. Hugging Face documenta la temperatura junto con otros controles de generación relacionados, como el muestreo top-p y la decodificación ávida.

El atajo tentador es “baja temperatura significa precisión”. Pero no es así. Si la respuesta más probable del modelo está equivocada, hacer que sea menos variada no aportará el hecho faltante; solo hará que el mismo error se repita de forma más constante. Del mismo modo, aumentar la temperatura no garantiza ideas mejores, solo ideas más variadas.

Dos tareas contrastantes muestran la diferencia. Generar cinco nombres para una cafetería ficticia se beneficia de la variedad. Extraer números de factura se beneficia de un formato consistente, pero los números aún deben coincidir con las facturas reales, y la temperatura no tiene nada que ver con eso.

Considere la temperatura como un parámetro con el que experimentar, y evalúe si cumple con las necesidades reales de la tarea. En el caso de la extracción, cuente los campos incorrectos o faltantes; en el de la generación de ideas, pregúntese si estas son útiles y realmente diferentes entre sí. La previsibilidad y la corrección requieren verificaciones separadas.

4. Alucinaciones: resultados que van más allá de las pruebas disponibles

Aquí, una alucinación se refiere a contenido generado que es inventado, factualmente incorrecto o no respaldado por el material del cual supuestamente toma información. Un tono confiado dificulta detectarlo, pero la confianza no forma parte de la definición; una oración cautelosa puede ser igualmente infundada.

Un artículo de investigación inventado es el caso obvio. Uno más sutil y común es un artículo real citado por un resultado que nunca informó, el cual pasa desapercibido a simple vista precisamente porque existe esa cita.

El benchmark TruthfulQA presentó 817 preguntas distribuidas en 38 categorías, basadas en conceptos erróneos comunes. En la evaluación inicial, el mejor modelo probado fue fiable al responder correctamente en el 58% de las preguntas, frente al 94% logrado por los seres humanos. Se trata de resultados históricos de investigaciones realizadas en 2021 y 2022, no una medida de los chatbots actuales ni una tasa universal de alucinaciones. Lo que demuestra este trabajo es que los modelos pueden reproducir fielmente creencias falsas que aparecen en textos escritos por humanos.

Cuando un resumen contenga una cifra sorprendente, solicite explícitamente su origen:

Indique el pasaje de donde proviene, su fecha y la población que se midió. Si el pasaje no respalda esa cifra, indique que la información carece de sustento.

Luego revise la referencia con sus propios ojos. Cualquier cita que genere un modelo es solo una afirmación hasta que haya confirmado tanto que la página existe como que realmente contiene esa oración específica.

5. RAG: obtener evidencias antes de responder

La generación mejorada por recuperación combina un paso de búsqueda con un paso de generación. El sistema busca material relevante en una colección externa, lo pasa al modelo y le pide que responda a partir de ese material.

El influyente artículo sobre RAG de 2020 combinó un generador preentrenado con un sistema de recuperación basado en un índice de Wikipedia y, al publicarse, obtuvo los mejores resultados conocidos en tres pruebas de inteligencia artificial de dominio abierto. Esos resultados describen un sistema de investigación específico, no una garantía de calidad para todos los productos que lleven la etiqueta RAG.

Imaginemos que un empleado pregunta cuántos días tiene para presentar una solicitud de gastos. Un buen sistema obtiene la política actual y responde en base a ella. Si, en cambio, obtiene la política del año anterior, ni una redacción bien elaborada podrá corregir el error; la respuesta será fluida pero incorrecta. Por eso, los fallos en RAG suelen ser más fáciles de diagnosticar por etapas que al observar directamente la respuesta final, un enfoque abordado en evaluar RAG por etapa de fallo.

Hay dos conceptos erróneos que vale la pena aclarar:

• RAG no depende de contar con un almacén de vectores especializado. El paso de búsqueda puede ser una coincidencia clásica de palabras clave, similitud por incrustación o una combinación de ambos, y la descripción general de RAG de Microsoft analiza estas opciones junto con la importancia de preparar el contenido para que pueda buscarse eficazmente.

Subir un PDF no demuestra que se esté realizando la recuperación de información. Algunos sistemas colocan el contenido del documento directamente en la ventana de contexto del modelo, como se describe en la documentación sobre contexto largo de Google. La recuperación y el procesamiento directo de contexto largo son opciones de diseño distintas, y un producto puede combinarlas.

Para evaluar a cualquier asistente de documentos, haz dos preguntas separadas: ¿encontró el pasaje correcto? ¿Su respuesta refleja fielmente ese pasaje?

6. Agentes: sistemas que eligen su siguiente paso

El término “agente” se utiliza de manera amplia, por lo que una distinción concreta ayuda. La guía de Anthropic para crear agentes eficaces describe los flujos de trabajo como sistemas que siguen rutas de código predefinidas, mientras que los agentes permiten al modelo dirigir dinámicamente su propio proceso y uso de herramientas.

Un flujo de trabajo fijo podría extraer campos de una factura, validarlos y guardar un registro, siempre en ese orden. Un agente que se enfrente a una factura incompleta podría decidir por su cuenta abrir un archivo adjunto, buscar el pedido relacionado y enviar una solicitud para obtener los detalles faltantes.

La pregunta clave, por lo tanto, es: ¿qué decisiones y acciones puede tomar el sistema? Una respuesta redactada y un reembolso emitido conllevan consecuencias muy diferentes. Un agente necesita permisos claramente definidos, resultados observables para cada acción y una forma de detenerse cuando no pueda determinar el siguiente paso lógico.

Más pasos también significan más posibilidades de fracasar. Como ilustración deliberadamente simplificada, si una tarea requiere diez pasos y cada uno tiene un 95% de probabilidad de éxito de forma independiente, la probabilidad de que todos los diez tengan éxito es 0,95 elevado a la décima potencia, aproximadamente el 60%. En la práctica, los pasos de un agente dependen unos de otros y las reintentos modifican los cálculos, por lo que esto es más bien una intuición sobre el riesgo compuesto que un punto de referencia. La consecuencia práctica es medir si toda la tarea se completó correctamente, incluidos los efectos secundarios, y no si los pasos individuales parecían plausibles. Para un análisis más completo del bucle en sí, consulte entendiendo a los agentes de IA: objetivos, herramientas, memoria y el bucle del agente.

Una lista de verificación de seis preguntas para tareas reales

Cada concepto se corresponde con una pregunta que puede hacerse sobre cualquier tarea real:

• Tokens: cuánto material requiere realmente esta tarea para que el sistema lo procese, y qué se puede eliminar sin perder pruebas?
• Ventana de contexto: ¿en qué pasaje dependía la respuesta, y el sistema lo utilizó realmente?
• Temperatura: ¿se trata esta tarea de variedad o consistencia, y se han verificado por separado la corrección y la previsibilidad?
• Alucinaciones: ¿dónde está exactamente la fuente de cada afirmación sorprendente, y indica si realmente hace lo que dice la respuesta?
• RAG: ¿se recuperó el documento correcto y actual, y se representó con precisión?
• Agentes: ¿qué está permitido que haga el sistema, y se completó toda la tarea, incluidos sus efectos secundarios, correctamente?

Conclusión

Pruebe estas preguntas en una tarea real, como un resumen de documento, un cambio de código o una respuesta de soporte al cliente, con el material original abierto a su lado. Distinga las pruebas en las que se basó, las conclusiones a las que llegó por sí mismo y las acciones que realmente realizó. Hacer esto de manera constante revela más sobre la fiabilidad de una herramienta que cualquier demostración o estadística destacada, y convierte la desconfianza vaga en problemas específicos y solucionables: una entrada excesivamente larga, un pasaje omitido, un documento incorrecto, una figura sin soporte o un agente con demasiada libertad de acción.