"Deletable": la palabra más importante en sistemas LLM
Puedes borrar el documento. Su sombra se queda en todas partes. Qué cambió cuando dejé de confiar en la palabra "borrado".
Un cliente me hizo una pregunta sencilla: si nos vamos, ¿pueden borrar todo lo que el sistema sabe de nosotros? Dije que sí antes de haberme ganado el derecho a decirlo.
Después fui a revisar. Los documentos fuente, claro, esos se borran. Pero los chunks que salieron de ellos seguían en el index. Los embeddings seguían en un ANN graph. Un cached answer todavía citaba un párrafo cuyo documento ya no existía. Un summary escrito dos semanas antes todavía cargaba un dato que me habían pedido olvidar. El origen ya no estaba. Su sombra seguía en otros cinco lugares.
El documento ya no está. Sus sombras sí.
Esa pregunta resultó ser la prueba más limpia que tengo para saber si un sistema LLM está de verdad bajo control. No la calidad del retrieval. No qué modelo usas. ¿Puedes borrar algo y que de verdad desaparezca?
Si no puedes, no sabes bien qué sabe tu sistema. Y un sistema cuyo conocimiento no puedes enumerar es uno que no puedes debuggear, ni razonar, ni defender cuando alguien pregunta.
La mayoría de los stacks son buenísimos para agregar estado. Para quitarlo son malísimos. Esa asimetría no se nota el día del lanzamiento. Aparece la primera vez que alguien te pide devolver algo, y descubres cuántas copias hiciste sin querer.
Qué cambió cuando hice del borrado un camino de primera clase
Un prompt que no puedes revertir es un prompt que te da miedo tocar. Lo mismo aplica al sistema entero: los datos que no puedes quitar limpiamente son datos sobre los que dejas de razonar. Así que empecé a diseñar el camino de borrado desde el día uno, junto al de escritura, en vez de descubrirlo la semana en que un cliente se va.
En la práctica vive en cuatro capas, de fácil a difícil.
1. Prompts — quizá ya lo resolviste
Ya argumenté que los prompts merecen migraciones, no improvisación: versionados, revisados, reversibles. La deletability es ese mismo argumento por el otro lado. Si cada versión de un prompt es un checkpoint, entonces "quita esta instrucción" es un diff que revisas y reviertes, no un acto de fe. Si tus prompts ya viven bajo version control, esta capa está lista. Es la fácil.
2. Documentos — el origen es el 10% fácil
Un documento fuente se ramifica en chunks, embeddings, una entrada en el index, quizás un cached answer que lo citó.
Borrar el documento es el 10% fácil. Lo que derivó de él es el 90% que todos se saltan.
La trampa: los datos derivados son una copia que olvidaste que hiciste. La regla que sigo ahora es aburrida y carga el peso de todo. Cada artefacto derivado guarda una referencia de vuelta al origen del que salió, y el borrado recorre esas referencias. Hazlo bien y quitar algo es una cascada limpia. Hazlo mal y "borrado" pasa a significar "casi borrado", que es el peor tipo de error, porque se lee como terminado.
3. Conocimiento derivado — la capa que miente
Summaries. La memoria del agente. Un fine-tune. Un cache de "datos de esta cuenta". Esta es la capa difícil, porque para cuando un dato llega a un summary, el hilo de vuelta a su origen ya está cortado.
No tengo una solución limpia acá, y desconfiaría de quien te venda una. Lo que tengo es una restricción: desconfía de cualquier proceso que convierta fuentes en conocimiento derivado sin registrar qué fuentes lo alimentaron. Si no puedes responder "cómo se vería este summary si el documento X nunca hubiera existido", construiste algo que no puedes retractar del todo. Puede ser un trade aceptable. Nunca debería ser una sorpresa.
4. Tenants — la arquitectura responde antes que tú
En un sistema multi-tenant, "borra todo de este cliente" es el juego completo, y tu modelo de aislamiento escribió la respuesta antes de que llegara la petición.
¿Shared tables con una columna tenant_id? Borrar es un DELETE ... WHERE tenant_id = ? en cada tabla, index y cache, y "todo" es tan completo como tu memoria de dónde se filtró ese ID. ¿Database-per-tenant? Borrar es un DROP DATABASE. Una instrucción. Completa por construcción. Fácil de explicarle a un auditor.
Elegí database-per-tenant en Clarytia por varias razones. La que mejor envejece es que vuelve el camino de borrado trivial y total. La decisión cara de aislamiento del día uno es lo que convierte una pregunta existencial en una operación de una línea más adelante.
Dónde me mordió
No llegué acá razonando. Llegué quemándome.
Al principio, un tenant se dio de baja. Corrí los deletes, vi desaparecer las filas y lo di por hecho. Tres días después, probando algo no relacionado, una respuesta sacó a flote una frase de uno de sus documentos. El documento ya no estaba en su tabla. El cache de respuestas le había sobrevivido. Nadie de afuera lo vio nunca. Pero yo me había dicho "borrado" cuando quería decir "borré la parte que recordé".
Ese cache fue la versión más barata posible de esta falla. Las caras involucran embeddings, summaries y el abogado de un cliente. Construí la cascada después de eso, no antes, que es el orden honesto en que suelen llegar estas lecciones.
Diseña primero el camino de borrado
Por esto abro con el borrado y no con las features. El camino de borrado es la auditoría más honesta de tu arquitectura. Para quitar algo limpiamente tienes que saber a dónde fue a parar, y un sistema cuyo flujo de datos puedes rastrear hacia atrás es uno que de verdad puedes operar.
Borras lo que el sistema sabe. Conservas el registro de lo que hizo.
Confundir esas dos cosas es su propia falla, y la inmutabilidad tiene su lugar: los audit logs y la procedencia nunca deberían poder borrarse. La reversibilidad no es "haz todo mutable". Es decidir, a propósito, qué tiene que poder quitarse, y pagar por eso en vez de por todo.
Así que antes de las preguntas emocionantes sobre retrieval y modelos, ahora hago primero la aburrida: cuando esto termine, ¿podemos hacer que desaparezca? La respuesta me dice más sobre si estoy en control que cualquier benchmark.
Si de verdad resolviste la capa 3 —quitar conocimiento derivado limpiamente, no solo las fuentes— quiero saber cómo. Es la que todavía me cuesta de verdad, y no creo que el campo tenga una respuesta real.