flowchart TD
A[Sesión común del expediente] --> B[Contexto investigador]
A --> C[Contexto analista]
A --> D[Contexto redactor]
E[Memoria persistente autorizada] --> B
E --> C
F[RAG / fuentes externas] --> B
B --> G[Resultados de investigación]
G --> C
C --> H[Hallazgos validados]
H --> D
RAG, sesión y memoria
Tres mecanismos diferentes para disponer de información: recuperar conocimiento externo, mantener la mesa de trabajo actual y conservar continuidad entre sesiones.
En context engineering reunimos distintas clases de información para construir el input de cada paso.
Tres mecanismos aparecen una y otra vez:
RAG, sesión y memoria.
Es fácil mezclarlos porque los tres permiten que el sistema trabaje con información que no está escrita literalmente en el último mensaje del usuario.
Pero cumplen funciones diferentes.
Un agente puede recuperar una política mediante RAG, mantener en la sesión que el DPA todavía está pendiente y recordar entre sesiones que un proyecto utiliza un criterio previamente aprobado.
Si llamamos “memoria” a todo lo anterior perdemos la capacidad de diseñar y gobernar cada función correctamente.
Idea central
En el marco pedagógico del curso:
- RAG aporta conocimiento externo pertinente a una tarea.
- Sesión mantiene la mesa de trabajo del encargo actual.
- Memoria proporciona continuidad persistente entre sesiones.
Los tres pueden terminar incorporando información al contexto del modelo, pero no son equivalentes por origen, duración ni finalidad.
Una vista general
| Mecanismo | Pregunta que resuelve | Horizonte típico |
|---|---|---|
| RAG | ¿Qué información externa necesito recuperar ahora? | Según consulta o tarea |
| Sesión | ¿Qué ha ocurrido durante este trabajo actual? | Conversación o ejecución actual |
| Memoria | ¿Qué información conviene conservar para futuras interacciones? | Persistente según diseño |
La tabla es deliberadamente conceptual. Las implementaciones técnicas pueden variar.
RAG: conocimiento externo
RAG ya tuvo una página propia. No necesitamos volver a enseñar embeddings, chunking, bases vectoriales o técnicas de recuperación.
El delta para agentes es éste:
el agente puede decidir cuándo necesita conocimiento externo y activar recuperación como parte de su ciclo.
Supongamos que el sistema está revisando una cláusula de incidentes.
Puede observar:
“Tengo el texto contractual, pero para evaluarlo necesito el estándar interno vigente.”
Entonces realiza una búsqueda y recupera únicamente el fragmento pertinente.
La información existe fuera de la sesión.
No se vuelve “memoria del agente” simplemente porque fue recuperada.
RAG como bibliotecario
La analogía del bibliotecario sigue siendo útil.
La tarea actual necesita una fuente. El bibliotecario localiza material relevante y lo trae a la mesa.
La analogía ayuda porque separa:
tener acceso a una colección
de > tener todos sus contenidos permanentemente en el contexto.
Deja de servir si imaginamos que el bibliotecario siempre recupera la fuente correcta. La recuperación también puede fallar: puede traer una versión antigua, un fragmento irrelevante o una fuente de menor autoridad.
Sesión: la mesa de trabajo
Google define una sesión como el contenedor de la conversación o interacción actual, incluyendo el historial cronológico y un estado de trabajo.
Para un principiante, la mejor intuición es la mesa de trabajo.
Durante una revisión colocamos sobre la mesa:
- lo que pidió el usuario;
- respuestas anteriores;
- documentos consultados;
- resultados de herramientas;
- decisiones provisionales;
- pendientes;
- estado actual.
Mientras trabajamos, necesitamos que esa información esté disponible.
Eventos
La sesión puede registrar acontecimientos de la interacción:
10:02 usuario carga contrato
10:03 agente solicita DPA
10:05 herramienta encuentra DPA
10:07 agente identifica transferencia internacional
10:08 revisión de privacidad activadaEstos eventos permiten mantener continuidad.
Estado
Además del historial, podemos conservar una representación estructurada del caso:
contrato = recibido
DPA = recibido
SLA = faltante
privacidad = en_revision
seguridad = pendiente
preguntas_proveedor = borradorEl estado evita depender exclusivamente de volver a leer toda la conversación.
Sesión no significa persistencia ilimitada
Que una aplicación mantenga una sesión no implica necesariamente que todo su contenido deba conservarse indefinidamente.
Desde un punto de vista técnico, una sesión puede persistirse para que la aplicación continúe funcionando entre solicitudes. Desde un punto de vista de gobierno, debemos decidir qué parte debe mantenerse, durante cuánto tiempo y con qué acceso.
Memoria: continuidad
La memoria cumple otra función.
Busca conservar información seleccionada más allá del encargo inmediato para que pueda recuperarse en una interacción futura.
Google la describe como un mecanismo de persistencia de largo plazo que extrae y consolida información significativa, en vez de tratar necesariamente toda la conversación literal como memoria permanente.
Del escritorio al archivador
La analogía utilizada en los materiales de Google es especialmente útil.
La sesión es un escritorio cubierto por papeles durante un proyecto.
La memoria es un archivador organizado.
Al terminar, no guardamos automáticamente:
- borradores inútiles;
- repeticiones;
- errores ya corregidos;
- conversaciones incidentales.
Seleccionamos aquello que merece continuidad.
La analogía ayuda porque introduce una idea esencial: persistir es una decisión de selección.
Deja de servir si imaginamos que el archivador es infalible. Una memoria puede quedar desactualizada, ser incorrectamente extraída o pertenecer a un contexto donde ya no corresponde utilizarla.
Qué podría conservar una memoria
En un sistema jurídico bien delimitado podría interesar conservar, por ejemplo:
- una preferencia documental expresamente definida para un proyecto;
- una decisión de clasificación ya confirmada por una persona;
- un criterio de formato adoptado por el equipo;
- un antecedente estable del asunto;
- el resultado consolidado de una etapa terminada.
Pero debemos resistir una conclusión demasiado fácil:
“Si recordar mejora la experiencia, entonces conviene recordar todo.”
En trabajo jurídico puede ocurrir exactamente lo contrario.
RAG y memoria pueden utilizar tecnologías parecidas
Aquí aparece una fuente habitual de confusión.
Una memoria puede almacenarse en una base y recuperarse mediante búsqueda semántica.
RAG también puede recuperar documentos mediante búsqueda semántica.
Técnicamente pueden compartir componentes.
Conceptualmente siguen cumpliendo funciones distintas.
RAG
Busca información desde una fuente de conocimiento externa.
Ejemplo:
política corporativa vigente sobre subprocesadores.
Memoria
Recupera información persistida sobre interacciones, decisiones o contexto previo.
Ejemplo:
en una revisión anterior el equipo confirmó que este proyecto no utilizará datos de menores.
La diferencia no está necesariamente en el motor de búsqueda.
Está en qué corpus se consulta, por qué existe y qué función cumple.
Un ejemplo completo
Supongamos que retomamos una revisión de proveedor dos días después.
El usuario escribe:
“Sigamos con el análisis de transferencia internacional.”
La sesión
Si seguimos en el mismo espacio de trabajo, contiene:
- contrato;
- DPA;
- preguntas anteriores;
- estado de revisión;
- resultado de herramientas.
Permite comprender qué significa “sigamos”.
RAG
Para analizar la transferencia necesitamos recuperar:
- política interna vigente;
- cláusulas modelo;
- quizás una fuente normativa autorizada.
Es conocimiento externo respecto del trabajo actual.
Memoria
Podría aportar un antecedente previamente consolidado:
“El proyecto ha sido clasificado internamente como servicio crítico.”
Si esa clasificación fue persistida de manera autorizada y sigue vigente, puede ser relevante.
El sistema debe poder distinguir las tres procedencias.
La procedencia importa
No debería ser equivalente que una afirmación provenga de:
CONTRATO
POLÍTICA RECUPERADA
ESTADO DE SESIÓN
MEMORIA
INFERENCIA DEL MODELOEn un sistema jurídico, la procedencia puede afectar cuánto peso atribuimos a la información y qué verificación exige.
Una memoria del proyecto no sustituye el texto de una norma.
Un estado temporal no sustituye una aprobación formal.
Un fragmento recuperado no sustituye la revisión de vigencia cuando ésta es necesaria.
Límites de retención
La memoria abre un problema de gobernanza que no aparece con igual intensidad en una interacción efímera.
Persistir información significa crear un nuevo objeto que debe administrarse.
¿Qué se conserva?
No todo el historial merece persistencia.
¿Por cuánto tiempo?
Una memoria útil hoy puede volverse obsoleta.
¿A qué usuario, asunto o cliente pertenece?
Google subraya la necesidad de aislamiento entre usuarios o tenants. En trabajo jurídico esta separación puede ser crítica para evitar reutilización indebida de información confidencial.
¿Quién puede corregirla?
Si una memoria contiene un dato incorrecto, necesitamos una vía para actualizarla o eliminarla.
¿Puede borrarse?
La capacidad de eliminación puede ser relevante tanto por gobierno de información como por obligaciones jurídicas aplicables.
¿Cómo se evita la contaminación?
Una memoria generada desde contenido malicioso o incorrecto puede persistir el error más allá de una sesión.
Google advierte específicamente sobre riesgos de memory poisoning y recomienda validar información antes de incorporarla a memoria persistente.
Sesión y memoria en sistemas con varios agentes
La distinción se vuelve todavía más importante cuando intervienen varios agentes.
Supongamos que un coordinador delega tareas a:
- investigador;
- analista;
- redactor.
Todos participan en el mismo encargo, pero no necesitan recibir idéntico contexto.
El investigador puede necesitar la consulta y las fuentes disponibles.
El analista necesita los fragmentos recuperados y los criterios.
El redactor necesita hallazgos ya validados, no necesariamente todo el historial de búsquedas.
Podemos representar la idea así:
La sesión puede funcionar como un espacio común de coordinación, mientras cada agente recibe sólo la parte que necesita.
Compartir no significa copiar todo
En un sistema multiagente, enviar el historial completo de un agente a todos los demás puede producir:
- ruido;
- duplicación;
- exposición innecesaria;
- dificultad para distinguir información vigente de borradores.
Es preferible intercambiar artefactos o estados claramente definidos cuando sea posible.
Por ejemplo:
resultado_investigacion = fuentes + fragmentos + metadatos
resultado_analisis = hallazgos + criterio + incertidumbreAsí la continuidad se mantiene sin convertir la sesión en una conversación interminable entre componentes.
Memoria no es autoridad
Supongamos que la memoria contiene:
“Este proveedor fue aprobado el año pasado.”
Eso no significa:
“Este proveedor debe aprobarse este año.”
La memoria puede aportar un antecedente.
No crea automáticamente una regla ni reemplaza la evaluación actual.
Las condiciones pueden haber cambiado:
- versión del servicio;
- subprocesadores;
- contrato;
- finalidad;
- riesgo;
- política interna.
Este ejemplo muestra por qué una memoria debería conservar también suficiente procedencia y temporalidad para ser interpretada correctamente.
Confidencialidad y memoria
Las orientaciones profesionales sobre IA generativa insisten en que los abogados deben comprender cómo se procesan y conservan los datos introducidos en las herramientas y utilizar salvaguardas adecuadas para información confidencial.
La memoria amplía esa preocupación.
Ya no preguntamos únicamente:
“¿qué ocurre con el prompt que envío?”
También:
- ¿qué parte se convierte en memoria?;
- ¿quién puede recuperarla después?;
- ¿se mezcla con otros usuarios?;
- ¿se reutiliza para otra finalidad?;
- ¿qué plazo de retención aplica?;
Un sistema “más personalizado” puede ser simultáneamente un sistema con mayor carga de gobierno de información.
Una comparación final
flowchart LR
A[Tarea actual] --> B[Sesión]
C[Base documental externa] --> D[RAG]
E[Información persistida] --> F[Memoria]
B --> G[Contexto del paso]
D --> G
F --> G
G --> H[Modelo]
La convergencia ocurre en el contexto.
La diferencia permanece en el origen y la función.
Qué debes recordar
RAG trae conocimiento externo pertinente.
La sesión mantiene la continuidad del trabajo actual.
La memoria conserva información seleccionada para usos posteriores.
Pueden compartir mecanismos técnicos, pero no son la misma cosa.
La pregunta de gobierno tampoco es “¿tiene memoria?”.
Es:
¿qué conserva, de quién, durante cuánto tiempo, con qué procedencia y bajo qué reglas de recuperación y eliminación?
El problema que todavía queda abierto
Ya sabemos cómo un agente puede disponer de información durante y entre tareas.
Pero disponer de información y disponer de herramientas abre una pregunta más delicada:
¿qué está autorizado a hacer con ellas?
Leer un contrato, preparar un borrador, enviar un correo y modificar un sistema no tienen el mismo impacto.
La siguiente página estudia permisos y autonomía a partir de una regla básica: cuanto mayor sea el efecto y menor la reversibilidad de una acción, mayor debe ser el control sobre su autorización.