Editar el prompt después de enviarlo: qué pasa con lo que vino después
Editar un prompt ya enviado lo reenvía y descarta o ramifica lo que siguió. Cómo diseñar la edición para que la persona entienda qué cambia y qué se pierde.
¿Qué cambia al editar?
Editar no es corregir una palabra. Cuando reenvías un mensaje editado, la conversación vuelve a ese punto y genera una respuesta nueva. Todo lo que vino después depende de la versión anterior, así que queda desactualizado.
La implementación habitual, que describe la documentación de assistant-ui para sus componentes de chat, es esta: editar vuelve a enviar un mensaje de un punto anterior de la conversación y crea una rama nueva. Al enviar desde el editor, los mensajes posteriores se descartan de esa ruta y el asistente genera una respuesta nueva desde el punto editado.
Tras ese único gesto hay intenciones distintas. Tian Pan distingue tres: corregir el rumbo, explorar una alternativa y volver a un punto de bifurcación. Según él, la mayoría de los productos descarta lo posterior por defecto, porque conservarlo crea un problema de navegación que un chat lineal no puede representar. Una señal de que hace falta ramificar es que la gente edite un mensaje y luego reconstruya a mano la versión que perdió.
Si lo que quieres es otra respuesta sin tocar la pregunta, eso es regenerar, no editar. Editar cambia la pregunta; regenerar cambia solo la respuesta.
Para quien usa la herramienta, la diferencia entre “reescribir” y “ramificar” importa. Si el sistema reescribe, la versión original desaparece y no hay forma de volver. Si ramifica, la persona puede comparar y recuperar lo que descartó.
¿Por qué le importa a un diseñador?
Porque la edición tiene tres momentos que la interfaz debe mostrar:
- Antes de enviar. Quien edita debe ver que el texto original está disponible para cancelar sin cambios.
- Al reenviar. Debe quedar claro que lo que sigue se va a regenerar, y si se va a perder algo.
- Después. La conversación debe mostrar qué versión está activa y dónde está la anterior.
Un error común es ocultar el segundo momento. La persona edita un mensaje de hace diez turnos sin saber que descarta nueve respuestas. Cuando lo nota, siente que la herramienta le quitó trabajo.
¿Qué pasa con el modelo?
Un punto que pocas interfaces explican: el modelo solo puede responder bien con lo que recibe. Si el backend guarda la versión original y la editada como dos turnos seguidos, el modelo ve ambas y puede responder a una que la persona ya descartó. Por eso la edición afecta también al historial de conversaciones: lo que la persona ve como una lista debe corresponder a lo que el modelo recibe.
Un análisis reciente sobre la arquitectura de chats describe exactamente ese problema. Según el texto, cuando el backend guarda la conversación como un registro que solo crece, cada edición se añade como versión nueva (message.v2 junto a message.v1), y el modelo recibe el mensaje original, su respuesta, la corrección y la petición nueva. Los síntomas son ediciones que no surten efecto, porque el agente sigue citando el valor original, y respuestas que se apoyan en una respuesta ya descartada. Además, el contenido superado sigue sumando tokens en cada llamada. La solución que propone es guardar los mensajes como nodos con puntero a su padre, de modo que la edición sea un hermano activo del original y solo se envíe al modelo el camino vigente. Una alternativa más ligera es conservar ambos turnos e indicarle al modelo explícitamente cuál reemplaza al otro. Este caso deja claro que el diseño de la edición es también un diseño de datos.
¿Cómo diseñar la edición?
- Usa el mismo lugar que el mensaje original. Editar in situ, con el texto ya cargado en un campo, suele ser más ágil que abrir un formulario aparte.
- Permite cancelar sin reenviar. Un botón de cancelar que restaura el texto original evita ediciones accidentales. En assistant-ui, por ejemplo, cancelar sale del modo edición y restaura el contenido sin reenviar.
- Avisa qué se descarta. Si hay respuestas posteriores, un aviso breve dice cuántas se van a regenerar. No hace falta una alerta grande.
- Conserva la versión anterior como rama. Así la persona puede volver si la nueva respuesta no sirve. Un indicador en línea del tipo “1/3”, con flechas para cambiar de rama, funciona bien con pocas ramas; con muchas conviene un panel de árbol. Esto se relaciona con la ramificación de conversaciones.
- Bloquea mientras responde. Si la IA está generando, editar y reenviar crea estados que nadie puede seguir. Abrir el editor no detiene la respuesta en curso (así funciona assistant-ui), así que bloquear la edición o el envío mientras el asistente responde es decisión tuya: muestra el editor, pero desactiva el envío o pide cancelar primero.
Una edición menor, como corregir una errata, no debería regenerar toda la conversación. Si el sistema puede distinguir una corrección de un cambio de pregunta, esa diferencia ahorra tiempo y tokens. Si no puede, déjalo a la persona.
Ejemplo
Ejemplo ilustrativo: una persona le pide a un asistente un plan de entrevistas para un proyecto. Después de diez mensajes, se da cuenta de que escribió “usuarios de 40 años” y quería “usuarios de 14 años”. Edita el primer mensaje.
La interfaz muestra: “Al reenviar, se regeneran 9 respuestas. La versión anterior queda disponible como rama”. La persona confirma. El plan nuevo aparece con un contador “1 de 2” arriba. Si quiere volver al original, lo hace con una flecha. La edición cuesta un clic y la persona sabe qué perdió.
Sin el aviso, la misma persona habría pensado que el asistente ignoró la corrección y habría pedido de nuevo el plan.
¿Cuándo NO conviene permitir editar?
Cuando la conversación depende de acciones que ya se ejecutaron, como un pedido enviado o un archivo creado, editar el mensaje no deshace esas acciones. En esos casos, la interfaz debe decir qué sigue vigente y qué no. Y en herramientas donde la conversación es un registro legal o de auditoría, la edición debe quedar registrada, no reemplazada.
Antes de lanzarlo
Antes de publicar la edición, prueba tres casos en la herramienta, no en tu cabeza:
- Editar el primer mensaje de una conversación larga y comprobar que el aviso de respuestas regeneradas dice el número correcto.
- Cancelar una edición y verificar que el texto original vuelve sin enviar nada.
- Intentar editar mientras la respuesta todavía se escribe y confirmar que el envío queda bloqueado o que la acción se cancela de forma explícita.
Si alguno de estos casos deja a la persona sin saber qué pasó, la edición no está lista, aunque el flujo principal funcione.
Errores comunes
- Reescribir el mensaje sin conservar la versión anterior.
- Enviar al modelo tanto la versión original como la editada.
- Permitir editar mientras la respuesta se genera.
- No avisar cuántas respuestas posteriores se van a regenerar.
- Usar la edición para corregir erratas y regenerar todo por algo menor.