Ley de Datos Personales — RAG

¿Qué dice realmente la Ley 21.719 sobre el derecho a la supresión de tus datos? En vez de leer el PDF completo o confiar en lo que un LLM “recuerda” de su entrenamiento, este proyecto le hace la pregunta directamente al texto de la ley — y responde citando el fragmento exacto de donde sacó la información.

TL;DR

Un servicio Spring Boot que ingesta el PDF de la Ley 21.719 (protección de datos personales en Chile), lo vectoriza con nomic-embed-text y responde preguntas con qwen3.5:4b, buscando por similitud los 8 fragmentos más relevantes antes de generar cada respuesta. Todo corre en local con Ollama y PostgreSQL/pgvector — no se envía nada a servicios externos.

Por qué RAG y no memoria del modelo

Preguntarle a un LLM genérico sobre una ley chilena específica tiene dos problemas: no tiene el texto en su entrenamiento con la fidelidad necesaria, y aunque lo tuviera, alucina con total confianza. RAG (Retrieval Augmented Generation) resuelve esto separando el proceso en dos mitades independientes: una que ingesta el documento una sola vez, y otra que busca los fragmentos relevantes en cada pregunta y se los entrega al modelo como contexto obligatorio.

📄 Fuente única de verdad

Las respuestas se construyen a partir del PDF real de la ley, no de lo que el modelo “cree” recordar.

🔒 Todo en local

Modelos servidos con Ollama, base de datos con Docker. Nada sale de la máquina.

⚡ Streaming token a token

Server-Sent Events para que la respuesta aparezca mientras se genera, no al final.

💬 Memoria de conversación

Puedes encadenar preguntas — “¿y en qué artículo dice eso?” entiende el contexto anterior.

Arquitectura

Escritura — ingesta, al arrancar

IngestionService corre una vez al levantar la aplicación:

1. Lectura — ParagraphPdfDocumentReader recorre el PDF guiándose por su índice y produce un documento por párrafo lógico, conservando el título de la sección en los metadatos.
2. Limpieza — se reduce todo el espaciado a espacios simples. La extracción del PDF genera rachas largas de espacios por la maquetación del original.
3. Fragmentación — TokenTextSplitter corta en piezas de 400 tokens.
4. Vectorización — cada fragmento se convierte en un vector de 768 dimensiones con nomic-embed-text y se guarda en public.vector_store (pgvector).

La ingesta es idempotente: si la tabla ya tiene contenido, la carga se omite.

Lectura — consulta, en cada petición

1. Llega la pregunta junto al identificador de conversación (UUID).
2. MessageChatMemoryAdvisor antepone al prompt el historial de esa conversación.
3. QuestionAnswerAdvisor vectoriza la pregunta con el mismo modelo de embeddings usado en la ingesta y busca por similitud coseno los 8 fragmentos más cercanos.
4. Esos fragmentos se inyectan en el prompt como contexto.
5. qwen3.5:4b redacta la respuesta y se emite token a token.

src/main/java/cl/goviedo/rag/ley_datos_personales/
├── controllers/ChatController.java         # API de consulta (streaming y bloqueante)
├── services/IngestionService.java          # ingesta del PDF al arrancar
└── repositories/VectorStoreRepository.java # contar y vaciar el vector store
src/main/resources/
├── docs/ley-datos-personales.pdf           # el documento fuente
└── static/                                 # interfaz de chat, empaquetada en el jar

Stack

	Versión / detalle
Java	21+
Spring Boot	4.1.1
Spring AI	2.0.1
Base de datos	PostgreSQL 16 + pgvector
Modelo de chat	qwen3.5:4b (Ollama)
Modelo de embeddings	nomic-embed-text, 768 dimensiones

El modelo de embeddings no se cambia a la ligera

Su dimensión tiene que coincidir con spring.ai.vectorstore.pgvector.dimensions y con la columna embedding ya creada en la base. Cambiarlo obliga a borrar la tabla y reingestar.

Endpoints

La interfaz web consume la ruta de streaming; la bloqueante existe para curl y scripts.

Ruta	Respuesta	Para qué
GET /	text/html	interfaz de chat
GET /api/status	application/json	modelo en uso y si el servicio está degradado
GET /api/chat/stream	text/event-stream	respuesta token a token
GET /api/chat	text/plain	respuesta completa de una vez
POST /api/page-loads	application/json	registra una carga y devuelve el total

Ambos endpoints de chat reciben question (máximo 500 caracteres) y conversationId (UUID), ambos obligatorios — una pregunta vacía produciría un embedding sin significado, y conversationId es la clave con la que se indexa el historial en memoria.

CID=$(uuidgen)

curl -G --data-urlencode "question=¿Qué derechos tiene el titular de los datos?" \
  --data-urlencode "conversationId=$CID" \
  http://localhost:13000/api/chat

Por qué cada trozo del streaming va en JSON, no en texto plano

La especificación SSE descarta un espacio inicial después de data:. Como los modelos emiten los tokens con su espacio delante (" ley", " contempla"), enviarlos en crudo se comía un espacio por token. Medido sobre una respuesta real: 290 de 457 trozos empezaban con espacio — el texto llegaba con casi todas las palabras pegadas.

Dos modos de operación, con degradación visible

La aplicación elige al arrancar contra qué Ollama trabaja, sondeando primero el preferido y cayendo al de respaldo si no responde:

	Preferido	Respaldo
Modelo de chat	qwen3.5:4b	qwen3.5:0.8b
Uso típico	equipo con GPU en la red local	localhost, sin GPU

Cuando usa el respaldo, la interfaz muestra una franja permanente advirtiendo que las respuestas pueden contener errores o llegar en otro idioma. No es adorno: el modelo reducido, medido contra el mismo contexto de 8 fragmentos, no siempre encuentra el dato en la posición que le asigna la búsqueda por similitud.

curl http://localhost:13000/api/status
# {"modeloChat":"qwen3.5:4b","degradado":false}

Despliegue con Docker

cp .env.example .env          # y define POSTGRES_PASSWORD
docker compose -f compose.deploy.yaml up -d --build

La imagen se construye en dos etapas (compila con JDK, corre sobre JRE con usuario sin privilegios). compose.deploy.yaml está separado de compose.yaml a propósito: este último lo levanta spring-boot-docker-compose al correr ./mvnw spring-boot:run, y si la app estuviera declarada ahí intentaría levantarse a sí misma.

Para Ollama hay dos caminos: dentro de la misma pila (--profile ollama, portable pero pesado en la primera descarga) o en la máquina anfitriona (requiere OLLAMA_HOST=0.0.0.0, porque por omisión Ollama solo escucha en 127.0.0.1 y ningún contenedor lo alcanza ahí).

No pongas localhost en las variables de Ollama si despliegas en contenedor

Dentro del contenedor, localhost es el propio contenedor — no hay ningún Ollama ahí. El síntoma es un ciclo de reinicios con un error de que nadie respondió.

La ingesta aborta la aplicación si Ollama no responde: es preferible fallar de forma visible a servir un RAG sin documentos. Combinado con restart: unless-stopped, eso se traduce en un contenedor reiniciando en bucle hasta que Ollama esté disponible — el síntoma correcto para diagnosticar el problema real.

Notas de diseño que valen la pena

• El espaciado se limpia antes de fragmentar, no después. El 76,1% de cada fragmento del PDF era espacio en blanco antes de limpiar; 0,0% después. Limpiar después de que TokenTextSplitter ya cortó por tokens habría gastado el presupuesto del fragmento en relleno.
• Fragmentos de 400 tokens, no los 800 por omisión — consecuencia directa de lo anterior: sin relleno, un fragmento de 800 tokens diluye una fecha o un número de artículo entre demasiado texto.
• Se recuperan 8 fragmentos, no los 4 por omisión — con 4, el fragmento correcto quedaba en el puesto 7 de la búsqueda y nunca llegaba al modelo.
• El razonamiento del modelo está desactivado. En una prueba, qwen3.5 gastó 59.754 caracteres “pensando” antes de responder, agotó el presupuesto de generación y devolvió un 200 OK con cuerpo vacío.
• El contador de páginas es de cargas, nunca de visitas únicas. Identificar visitantes de forma única exigiría un dato personal — justo lo que regula la ley que la propia app explica.
• El modelo de chat importa más que su tamaño. gemma:2b respondía “no hay información en el contexto” teniendo el dato delante, y en inglés a preguntas en español. qwen3.5:2b, más chico, acertaba con el mismo prompt.

Pruebas

./mvnw test

37 pruebas entre ChatControllerTest, IngestionServiceTest, VectorStoreRepositoryTest, PageLoadControllerTest y PageLoadRepositoryTest — ninguna necesita base de datos ni Ollama levantados. El test de contexto completo (@SpringBootTest) está deshabilitado a propósito porque spring-boot-docker-compose no entra al classpath de test; reactivarlo exige Testcontainers con pgvector/pgvector:pg16.

Links

Demo en vivo Prueba el chat directamente contra la ley, sin instalar nada.

Repositorio en GitHub Código completo, README con más detalle y notas de diseño.

Ley 21.719 Texto oficial de la ley que regula la protección de datos personales en Chile.

Spring AI El framework detrás de los advisors, el vector store y el chat client.

Ollama Motor local usado para servir los modelos de chat y de embeddings.