Un modo de fallo de los LLM: convertir en hecho lo que el modelo dedujo
Un usuario de r/PromptEngineering describe cómo una suposición razonable acaba tratada como dato aportado por el usuario veinte mensajes después, y publica los prompts con los que intenta evitarlo.
Un usuario de r/PromptEngineering ha puesto nombre a un comportamiento de los LLM que, dice, no ve discutido lo suficiente: el modelo recibe información incompleta, saca una conclusión razonable, y veinte mensajes más tarde la cita como si el usuario se la hubiera dado. No es una alucinación. El dato nunca se inventó de la nada, simplemente ascendió de categoría sin avisar.
Su propuesta es tratar la deducción y su promoción a contexto establecido como dos operaciones distintas, y obligar al modelo a mantenerlas separadas. El prompt que usa, y que pide copiar tal cual porque las palabras exactas cambian la respuesta, es este:
When something materially affects your answer, keep these separate:
GIVEN — directly provided or verified.
INFERRED — a reasonable conclusion, but not established.
UNKNOWN — information you don't actually have.
Do not silently turn INFERRED into GIVEN.
If an unresolved assumption could materially change the answer, state it.
If it wouldn't materially change the answer, don't interrupt me just to clarify it.
If evidence conflicts, preserve the conflict rather than quietly choosing the cleaner interpretation.
Otherwise answer normally.
Don't turn this into a verbose checklist.
La última línea es la que sostiene el resto, según el autor. Sin ella, los modelos se lían a enumerar cada incertidumbre minúscula y la conversación se vuelve inmanejable. Con ella, solo interrumpen cuando el supuesto cambia de verdad la respuesta. También recomienda abrir el prompt con un "remember this:" cuando el asunto es serio.
Dice que le sirve sobre todo en conversaciones largas: depuración, planificación, investigación, revisión de documentos y cualquier consulta donde ya se haya formado una opinión y no quiera que el modelo la contamine.
Contaminación de contexto
El segundo problema que plantea es peor. Una vez que un supuesto incorrecto se asienta en el historial, se vuelve persistente: lo corriges, el modelo reconoce la corrección, explica por qué estaba mal, y a los pocos mensajes vuelve a razonar desde el mismo dato erróneo. Abrir un chat nuevo lo arregla a veces, lo que le lleva a sospechar que el fallo no está siempre en el conocimiento del modelo. La conversación ha acumulado estado basura: inferencias tratadas como hechos, atribuciones equivocadas, información ya superada.
Para rescatar ese hilo sin empezar de cero propone este segundo prompt, que él mismo describe como trabajo en curso:
Context Contamination Recovery
The current conversation may contain stale, incorrect, superseded, or contaminated context. Before answering my next request, perform a context-integrity reset using the conversation history. Classify any material information you intend to rely on as:
GIVEN — directly provided by me or explicitly present in a source.
VERIFIED — independently checked against supporting evidence.
INFERRED — reasonably concluded, but not directly established.
UNKNOWN — unsupported, unresolved, or uncertain.
SUPERSEDED — previously present, but later corrected, rejected, replaced, or shown to be unreliable.
Apply these rules:
Never silently promote INFERRED or UNKNOWN information into GIVEN or VERIFIED.
A later explicit correction supersedes the earlier conflicting claim unless new evidence establishes otherwise.
Do not continue reasoning from SUPERSEDED information merely because it appears earlier or repeatedly in the conversation. Repetition does not increase evidential weight.
Do not treat your own previous answers as independent evidence.
Preserve the provenance of important claims: distinguish what I supplied, what a source supplied, what was independently verified, and what you inferred.
Check whether the current reasoning depends on an assumption I have already rejected, an inference that gradually became treated as fact, incorrect attribution, or an earlier framing contradicted by later information.
If it does, remove that dependency and rebuild the reasoning from the strongest remaining context.
If the existing framing appears to be trapping the reasoning, reconsider the problem more broadly rather than continuing to optimize inside the same assumptions.
If removing contaminated information leaves a gap, mark it UNKNOWN rather than filling the gap with the old assumption.
If supported information genuinely conflicts, surface the conflict instead of silently choosing one version.
For my next request, answer using only context that survives this check.
Do not give me a long explanation of why the earlier mistake happened unless I ask.
Prioritize producing the corrected answer.
Conviene calibrar lo que hay aquí. Es una observación de un usuario en un foro, sin evaluación formal ni medidas de ningún tipo, y él mismo admite que el segundo prompt sigue en pruebas. Aun así, apunta a algo que cualquiera que monte agentes o asistentes sobre historiales largos acabará viendo: el contexto no es un registro neutral, es estado que se degrada, y quien lo gestiona necesita distinguir procedencia y vigencia antes de seguir razonando encima.
