Diagnosticar fallas, prompt, alucinación, recuperación o modelo inadecuado

Después de recargar la base de documentos, el asistente interno empieza a dar respuestas seguras y equivocadas. La latencia es la misma y el ID del modelo no cambió. En la reunión de crisis, alguien propone pasar a un modelo más grande y otro sugiere bajar la temperatura a cero. Ninguna de las dos propuestas sale de mirar qué cambió.

Primero, qué cambió y dónde falla

Un diagnóstico serio arranca con dos preguntas:

• ¿Qué cambió? El prompt, los documentos o el índice, el modelo, las herramientas, el tipo de tráfico. Si el ID del modelo es el mismo, no culpes a “cambios silenciosos del modelo” sin evidencia: buscá primero en lo que sí cambió.
• ¿Qué segmento falla? Todo, solo los casos complejos, solo un tema, solo las consultas sin documentos recuperados. Una falla concentrada en un segmento casi siempre señala la causa.

Síntoma	Causa probable	Primer chequeo
Respuestas seguras pero erradas después de actualizar documentos	Falla de recuperación (retrieval failure): índice roto, fragmentos viejos o irrelevantes	Mirar qué fragmentos se recuperaron para las consultas que fallan
Inventa cuando no hay documentos que lo respalden	Alucinación (hallucination) inducida por el prompt	¿El prompt exige una respuesta completa aunque el contexto venga vacío?
Con el mismo prompt, solo fallan los casos complejos en el modelo nuevo y más chico	Modelo inadecuado (model mismatch) para ese segmento	Correr el mismo prompt en el modelo anterior, separado por complejidad
Ignora formato o instrucciones en cualquier modelo	Falla del prompt	Revisar instrucciones ambiguas, contradictorias o sin ejemplos
Respuestas cortadas a mitad de frase	Se alcanzó max_tokens	Revisar el motivo de corte (stop reason) en los logs

Alucinaciones: casi siempre hay un porqué

Cuando el contexto recuperado viene vacío o no alcanza, y la instrucción dice “respondé siempre de forma completa y definitiva”, el modelo completa con lo que suena plausible. Las correcciones van al prompt y al diseño:

• dar permiso explícito para decir que no tiene la información y derivar;
• la restricción al material provisto (external knowledge restriction): responder solo con los documentos entregados, no con conocimiento general;
• en documentos largos, pedir primero las citas textuales relevantes y responder a partir de ellas;
• pedir que cada afirmación cite su fuente y retirar la que no encuentra respaldo.

Agregar a la base “políticas parecidas” para que la recuperación encuentre algo empeora el problema: el modelo responde con información de otro producto.

Prompt o modelo

Para separarlos, dejá fijo el prompt y cambiá solo el modelo, sobre el mismo set separado por segmento. Si el modelo anterior sigue bien con ese prompt y el nuevo falla solo en los casos de varios pasos, el problema es el modelo para ese segmento. La salida no es volver todo atrás: ruteá los casos complejos al modelo más capaz y dejá el más chico para las consultas simples, que conservan casi todo el ahorro.

Si en cambio todos los modelos fallan igual, el problema está en el prompt o en los datos, y cambiar de modelo solo lo esconde.

Las trampas típicas

• Pasar a un modelo más grande “porque sabe más”: no arregla un índice roto ni un prompt que obliga a inventar.
• Bajar la temperatura a cero: la respuesta inventada sale igual, solo que más repetible.
• Abrir un ticket por un supuesto cambio de pesos del modelo sin haber mirado la recuperación.
• Reintentos con backoff ante respuestas cortadas: no es un error transitorio.

En el examen

Si la falla aparece justo después de recargar documentos y lo demás no cambió, el primer lugar a revisar es la recuperación. Si el modelo inventa cuando no hay contexto, buscá la opción que le permite decir que no sabe y lo limita a los documentos. Si la falla aparece después de cambiar a un modelo más chico y solo en los casos difíciles, buscá el ruteo por complejidad. Desconfiá de cualquier opción que culpe al modelo sin evidencia.