RaMem - RAG as Memory
¿Puede un modelo pequeño recordar más sin crecer?
Proponemos una arquitectura de memoria recuperable que incorpora contexto relevante antes de generar cada respuesta.
Presentamos la motivación, la implementación, el protocolo experimental, los resultados por componente y las limitaciones actuales.

Representación visual de RaMem
Hipótesis de diseño
La memoria vive fuera de los parámetros.
Pregunta de investigación
Pregunta de investigaciónProponemos ampliar el contexto útil de un modelo pequeño sin aumentar sus parámetros.
RaMem desacopla la capacidad de recordar del tamaño del generador. En lugar de almacenar toda la información en los pesos, recuperamos memoria relevante antes de cada respuesta y la incorporamos al contexto de inferencia.
Descripción visual: Un generador de mil millones de parámetros conectado a contexto, recuerdos y evidencia externos.
- Generador
- Gemma 3 · 1B
- La memoria conversacional no forma parte de sus pesos.
- Contexto máximo
- 4.096 tokens
- Incluye instrucciones, conversación reciente, memoria y respuesta.
↳Nuestra hipótesis de diseño es que una memoria externa permite usar mejor un modelo compacto.
Motivación
MotivaciónPartimos del equilibrio entre eficiencia computacional y capacidad de contexto.
Los modelos pequeños reducen requisitos de cómputo, memoria y despliegue, pero disponen de menor capacidad paramétrica para representar conocimiento y resolver tareas generales. Los modelos de mayor escala suelen ampliar estas capacidades a costa de un costo operativo superior.
Descripción visual: Comparación cualitativa entre modelos pequeños y modelos grandes en recursos, contexto interno y costo operativo.
Límite: No realizamos una comparación controlada SLM vs. LLM en esta etapa.
Arquitectura propuesta
Diseño del sistemaDiseñamos un Router que selecciona la ruta de recuperación antes de generar.
El Router analiza la consulta y decide si necesita información externa o memoria previamente indexada. La evidencia recuperada se integra al contexto, el modelo genera una respuesta y el nuevo intercambio vuelve al sistema de memoria.
Descripción visual: El prompt entra al Router, se recupera información externa o memoria previa y el contexto pasa al modelo para generar la respuesta.
↳La separación entre enrutamiento, recuperación y generación permite evaluar cada componente de forma independiente.
Implementación evaluada
Diseño del sistemaImplementamos una V1 local centrada en memoria conversacional persistente.
En la V1, SQLite conserva la conversación como registro canónico. LanceDB combina recuperación vectorial y textual, aplicamos fusión de rankings y diversidad, y entregamos al generador fragmentos identificados mediante citas [D#].
Descripción visual: Secuencia local compuesta por SQLite, LanceDB, evidencia citada y un generador Gemma de mil millones de parámetros.
↳Acotamos esta evaluación a memoria local; la búsqueda externa no forma parte de la V1 medida.
Mecanismo de memoria
Diseño del sistemaPersistimos cada turno antes de inferir y reconstruimos el índice desde la conversación.
Primero confirmamos el mensaje del usuario en SQLite. Después recuperamos evidencia, construimos el contexto y generamos la respuesta. Finalmente, segmentamos el nuevo intercambio y lo incorporamos al índice para consultas futuras.
Descripción visual: Ciclo de cuatro etapas: persistir el mensaje, recuperar evidencia, responder con citas e indexar el nuevo intercambio.
↳Este orden de operaciones prioriza durabilidad y reproducibilidad por encima del índice derivado.
Evaluación del generador
ResultadoLogramos Token F1 de 0,7168 en evaluación interna y 0,6881 en external-dev.
Evaluamos el generador ajustado con contexto proporcionado. En 256 ejemplos internos obtuvimos Exact Match de 0,5469 y Token F1 de 0,7168. En 500 ejemplos de MLQA external-dev obtuvimos Exact Match de 0,4860 y Token F1 de 0,6881.
Descripción visual: Dos barras comparan Token F1 de 0,7168 en la evaluación interna y 0,6881 en MLQA external-dev.
- Evaluación interna · n=256
- F1 0,7168
- EM 0,5469 · latencia media 1,454 s
- MLQA external-dev · n=500
- F1 0,6881
- EM 0,4860 · latencia media 1,521 s
- IDs de cita válidos
- 100 %
- Verifica el identificador emitido, no el soporte semántico de cada afirmación.
Límite: Estas métricas evalúan generación con contexto; no evalúan recuperación conversacional end-to-end.
Protocolo y observaciones
- Mantenemos conjuntos interno y external-dev separados.
- Medimos coincidencia exacta, Token F1, formato de citas y latencia.
- Congelamos la semilla y la configuración durante cada ejecución.
Evaluación de recuperación
ResultadoEn una prueba smoke de 10 casos obtuvimos Recall@10 agregado de 1,0.
Evaluamos ocho consultas con frases relevantes y dos casos de abstención sin evidencia esperada. En los casos de abstención, definimos recall 1,0 cuando no existe evidencia objetivo. La latencia media de recuperación fue 19,5 ms y el percentil 95 fue 60,1 ms.
Descripción visual: Diez casos: ocho con evidencia esperada y dos abstenciones; latencia media de 19,5 milisegundos y p95 de 60,1 milisegundos.
- Recall@10 agregado
- 100 %
- n=10; 8 con evidencia + 2 abstenciones
- Latencia media
- 19,5 ms
- p95 60,1 ms
Límite: Esta prueba verifica el funcionamiento del pipeline con una muestra mínima y embeddings de prueba; no mide generalización.
Protocolo y observaciones
- 8 casos incluyen evidencia objetivo.
- 2 casos evalúan abstención sin evidencia objetivo.
- Indexamos 32 mensajes en 16 fragmentos.
Alcance experimental
AlcanceAún debemos validar memoria, fidelidad y rendimiento a escala.
Antes de realizar afirmaciones de desempeño end-to-end, necesitamos ampliar el conjunto de memoria, congelar un holdout revisado, ejecutar benchmarks conversacionales externos, comparar BF16 con GGUF y medir el sistema con 100.000 mensajes.
Descripción visual: Lista de validaciones pendientes: holdout humano, benchmarks conversacionales, cien mil mensajes, comparación de cuantización y publicación verificable.
Protocolo y observaciones
- Holdout independiente con revisión humana.
- Evaluación de fidelidad semántica y abstención.
- Comparación de cuantización y pruebas de durabilidad a escala.
Conclusión
ConclusiónLogramos una memoria RAG local y trazable para un generador compacto.
RaMem persiste conversaciones, recupera evidencia híbrida, construye contexto con citas y genera respuestas con un modelo de 1B parámetros. Los resultados obtenidos validan componentes del sistema; la evaluación end-to-end y la comparación con modelos de mayor escala permanecen abiertas.
Descripción visual: El mecanismo de memoria está implementado; una ventaja comparativa permanece por validar.
↳Nuestra contribución actual es una arquitectura funcional y evaluable, no una afirmación de equivalencia con un LLM.
Método experimental
Evaluamos generación y recuperación como componentes separados.
Sistema
Arquitectura modular
Separamos persistencia, recuperación, construcción de contexto y generación para medir cada componente.
Generación
Evaluación con contexto
Medimos Exact Match, Token F1, citas y latencia sobre conjuntos interno y external-dev.
Memoria
Evaluación de recuperación
Medimos Recall@10 y latencia, distinguiendo consultas con evidencia y casos de abstención.
Mantenemos denominadores, unidades y condiciones experimentales junto a cada resultado. Esta separación evita atribuir al sistema completo una mejora observada en un solo componente.