¿Se puede reconstruir más adelante una ejecución de un LLM? Lista práctica de procedencia
Una respuesta por sí sola rara vez explica cómo llegó un LLM a ella. Descubre qué registrar para investigar o comparar una ejecución, y cómo hacer visibles las lagunas de procedencia y las decisiones sobre el tratamiento de datos.
Por qué una respuesta por sí sola no basta
Una respuesta guardada indica qué devolvió el sistema, pero no necesariamente el contexto que la determinó. El mismo texto de respuesta puede interpretarse de distintas maneras según el prompt del sistema, los documentos recuperados, la versión del modelo y los parámetros de generación. La tesis proporcionada sobre sistemas mediados por herramientas señala que conservar únicamente el texto de la respuesta podría no bastar para interpretarla o investigarla más adelante ([Tool-mediated systems also complicate attribution and reconstruction, Politecnico di Torino](https://webthesis.biblio.polito.it/41347/1/tesi.pdf)).
Para una respuesta importante, considera crear un registro que distinga el material de entrada, las restricciones del sistema, las instrucciones del usuario, el material recuperado, las transformaciones realizadas con ayuda de herramientas, la salida del modelo, la interpretación generada, la incertidumbre y el posprocesamiento. Esta lista sigue los elementos de registro propuestos en FIELD COMPUTE ATLAS; es una lista de verificación de diseño, no una garantía de que todos los sistemas puedan conservar cada elemento ([FIELD COMPUTE ATLAS, versión 2.1](https://zenodo.org/records/23014733/files/FIELD_COMPUTE_ATLAS_v2_1_FULL_INTEGRATED_20260926.pdf?download=1)).
- ¿Puedes identificar el flujo de trabajo que produjo la respuesta?
- ¿Puedes distinguir la salida del modelo de los cambios que realizó después tu aplicación?
- ¿Qué partes del contexto de la invocación están presentes y cuáles faltan?
Elige el objetivo: reproducir, reconstruir o comparar
Decide qué quieres que permita hacer un registro antes de elegir qué conservar. La reproducción, el diagnóstico y la comparación son objetivos distintos, y un registro que ayuda a explicar una ejecución anterior no necesariamente permite reproducir exactamente el resultado.
Es posible que el estado interno preciso del modelo no esté disponible, como señala FIELD COMPUTE ATLAS. Deja clara esa limitación al describir lo que puede aportar un registro ([FIELD COMPUTE ATLAS, versión 2.1](https://zenodo.org/records/23014733/files/FIELD_COMPUTE_ATLAS_v2_1_FULL_INTEGRATED_20260926.pdf?download=1)).
- Para reproducir una ejecución, conserva las entradas y la configuración que necesitas y tienes permiso para guardar; indica las dependencias que no puedes restablecer.
- Para diagnosticarla, da prioridad al contexto y las transformaciones necesarios para interpretar lo ocurrido.
- Para comparar ejecuciones, identifica qué cambió entre ellas y qué no se pudo verificar.
- No prometas una reproducción exacta si no están disponibles las entradas pertinentes o el estado del modelo.
Registra el contexto del prompt y de la aplicación
El nombre de una plantilla por sí solo quizá no muestre las instrucciones y las entradas que se usaron en una invocación concreta. Si tu sistema lo permite, conserva el prompt ensamblado o sus partes pertinentes, junto con un identificador de revisión del prompt o de la aplicación. La tesis proporcionada recomienda conservar el contexto de la invocación y la procedencia junto con el artefacto de respuesta ([Tool-mediated systems also complicate attribution and reconstruction, Politecnico di Torino](https://webthesis.biblio.polito.it/41347/1/tesi.pdf)).
Explicita los límites del registro. Si no se conservó un campo o una dependencia, márcalo como no disponible en lugar de dar a entender que el registro está completo.
- Cuando tu sistema los represente por separado, mantén diferenciadas las restricciones del sistema, las instrucciones del usuario y los valores pertinentes de las variables.
- Registra la revisión del prompt o de la aplicación cuando esté disponible, y conserva la revisión correspondiente solo si tus normas de gobernanza lo permiten.
- Anota cualquier preprocesamiento o posprocesamiento sustancial que pueda afectar a la interpretación de la respuesta.
Captura la procedencia del modelo, la recuperación y las herramientas
Registra los detalles del modelo y de la solicitud que tu integración pueda observar, y distingue los valores observados de las suposiciones. Las interfaces de los proveedores varían, así que consulta la documentación del servicio específico en vez de confiar en una lista genérica para determinar qué campos están disponibles.
En los flujos de trabajo con recuperación aumentada o uso de herramientas, una referencia a una fuente quizá no muestre el material o el resultado exactos que se usaron. Cuando esté permitido, conserva los pasajes recuperados pertinentes, las entradas y los resultados de las herramientas, y las transformaciones que se produjeron entre ellos. FIELD COMPUTE ATLAS propone distinguir en el registro de una ejecución el material recuperado, las transformaciones realizadas con ayuda de herramientas y la interpretación generada ([FIELD COMPUTE ATLAS, versión 2.1](https://zenodo.org/records/23014733/files/FIELD_COMPUTE_ATLAS_v2_1_FULL_INTEGRATED_20260926.pdf?download=1)).
- Registra los detalles del modelo y de la solicitud que estén disponibles para tu sistema; indica cuándo un valor no está disponible.
- Para el material recuperado, conserva identificadores útiles o el contenido pertinente cuando esté permitido, e indica si el registro no conserva lo que se proporcionó al modelo.
- En la actividad de las herramientas, distingue la entrada y el resultado de la herramienta de la interpretación que el modelo hace de ellos.
- Señala las lagunas de procedencia en lugar de dar a entender que los enlaces a fuentes o el nombre de una herramienta constituyen un registro completo.
Vincula los eventos relacionados y declara las lagunas
Una referencia de ejecución o de traza puede ayudar a organizar entradas, resultados y actividad de herramientas relacionados dentro de tu sistema. Trátala como un enlace a los registros, no como un sustituto de los propios registros. La lista de verificación proporcionada para repositorios de investigación pide específicamente la procedencia del modelo, el prompt, las herramientas y la traza, incluida la declaración de los casos en que no hay procedencia ([The design cannot distinguish these explanations, Zenodo](https://zenodo.org/records/21711582/files/can-an-ai-assisted-research-repository-preserve-a-no-v0.5.0.pdf?download=1)).
Elige una secuencia de eventos y unos identificadores que se ajusten a tu implementación. Si un componente no puede proporcionar un enlace o un evento, registra esa laguna en lugar de inventar una conexión. Las fuentes citadas no establecen convenciones de identificadores de traza específicas de cada proveedor.
- Usa una referencia de ejecución para organizar registros relacionados cuando resulte útil en tu sistema.
- Si están disponibles, mantén diferenciados los identificadores generados por el proveedor y los creados por tu aplicación.
- Haz visibles en el registro los datos de procedencia que falten, se hayan redactado o no estén disponibles.
Usa los registros estructurados con cuidado
Al registrar prompts, documentos recuperados, resultados de herramientas o respuestas, una serialización estructurada puede hacer explícitos los límites entre campos. La tesis proporcionada también analiza la canonicalización, el escape de contenido no confiable y el cálculo de hashes sobre una representación canónica como mecanismos de registro ([Tool-mediated systems also complicate attribution and reconstruction, Politecnico di Torino](https://webthesis.biblio.polito.it/41347/1/tesi.pdf)).
Un hash puede ayudar a comprobar si un artefacto conservado coincide con un registro anterior; no puede recuperar contenido que se descartó. Si usas hashes, documenta qué representación se comprueba y no presentes el hash como sustituto del contenido subyacente.
- Define límites claros entre los campos registrados.
- Si usas canonicalización o hashes, documenta la representación y las decisiones de escape.
- Indica si el contenido subyacente se conserva, se transforma o no está disponible.
Establece reglas de acceso y conservación
Los prompts, los pasajes recuperados, los resultados de herramientas y las respuestas pueden incluir información a la que no debería tener acceso un público amplio. Decide qué recopilar, quién puede acceder a ello y durante cuánto tiempo conservarlo como parte de tus decisiones de gobernanza de datos. La política adecuada depende de tu contexto; esta lista de verificación no prescribe un periodo de conservación específico.
Considera si los campos sensibles deben excluirse, redactarse o almacenarse por separado. Si se omite o transforma contenido, hazlo visible para que quienes lean el registro entiendan qué permite y qué no permite hacer.
- Clasifica los campos de la traza según tus necesidades de investigación y tus normas de datos.
- Limita el acceso de acuerdo con las decisiones de gobernanza de tu organización.
- Documenta las decisiones sobre redacción, conservación y eliminación.
- Indica qué se conservó, transformó, redactó o no estaba disponible.
Preguntas frecuentes
¿Se puede reproducir exactamente más adelante una respuesta de un LLM?
No necesariamente. La reproducción exacta depende de que estén disponibles las entradas y el contexto pertinentes, y de que el servicio del modelo exponga o conserve el estado necesario para repetir la solicitud. FIELD COMPUTE ATLAS señala que quizá no esté disponible el estado interno preciso del modelo. Un registro puede servir para investigar sin garantizar un resultado idéntico.
¿Qué conviene conservar para investigar una ejecución de un LLM?
Considera conservar, cuando esté permitido, el contexto de la invocación, los detalles pertinentes del modelo y de la aplicación, el material recuperado, la actividad de las herramientas y el resultado. Indica también qué falta. Los elementos de registro propuestos en FIELD COMPUTE ATLAS incluyen el material de entrada, las restricciones del sistema, las instrucciones del usuario, el material recuperado, las transformaciones realizadas con ayuda de herramientas, la salida del modelo, la incertidumbre y el posprocesamiento.
¿Basta con un ID de traza para investigar una respuesta?
No. Una referencia de ejecución o de traza puede ayudar a organizar registros relacionados, pero no sustituye al prompt, el material recuperado, los resultados de las herramientas ni la salida. La lista de verificación proporcionada pide registrar la procedencia de la traza y declarar también los casos en que no hay procedencia.
¿Deberían los equipos conservar los prompts completos y los documentos recuperados?
Depende de las necesidades de investigación y de tus normas de datos. Conservar el contenido puede aportar más contexto, pero debes decidir qué recopilar, quién puede acceder a ello y durante cuánto tiempo guardarlo. Indica claramente cuándo se haya omitido o transformado contenido.
¿Los hashes permiten reproducir el contenido descartado de un prompt o del contexto?
No. Un hash calculado sobre una representación canónica puede ayudar a comprobar si un artefacto conservado coincide con un registro anterior, pero no puede recuperar contenido que no se guardó.
Fuentes y lecturas adicionales
- FIELD COMPUTE ATLAS, version 2.1 — Zenodo
- Tool-mediated systems also complicate attribution and reconstruction — Politecnico di Torino thesis repository
- The design cannot distinguish these explanations — Zenodo