Construí una aplicación RAG, luego le pregunté qué coche me gusta. No lo sabía.

Construí una aplicación RAG, luego le pregunté qué coche me gusta. No lo sabía.

Estoy construyendo una herramienta de chat con documentos llamada Kenning. Utiliza RAG (Retrieval-Augmented Generation) para permitir que los usuarios hagan preguntas sobre los archivos subidos.

Construí todo el pipeline desde cero usando:

• Java 21 y Spring Boot
• Spring AI
• PostgreSQL con pgvector
• Ollama (ejecutando llama3.2:3b y nomic-embed-text)
• Docker Compose

El pipeline funciona así: Subir archivo → Extraer texto → Fragmentar texto → Convertir fragmentos en vectores → Almacenar en pgvector → Buscar fragmentos similares → Enviar fragmentos + pregunta al modelo → Obtener respuesta con fuentes.

El sistema funcionaba, pero me encontré con dos fallos distintos. Parecían iguales, pero las causas eran diferentes.

Fallo 1: El modelo estaba confundido. Pregunté: "¿Qué modelo de embedding utiliza este proyecto?" El documento indicaba la respuesta explícitamente. El modelo recuperó el texto correcto. Sin embargo, respondió diciendo que no lo sabía, incluso mientras repetía el nombre del modelo correcto en la siguiente frase.

Mi teoría: El modelo de 3B es demasiado pequeño. Recuperó los datos correctos pero no pudo dar una respuesta con seguridad. Un modelo más grande probablemente solucionaría esto.

Fallo 2: El modelo no encontró nada. Pregunté: "¿Qué marca de coche me gusta?" El documento mencionaba que me gusta BMW. Pero el sistema devolvió cero resultados. La puntuación de similitud era demasiado baja para superar mi umbral.

Mi teoría: Dilución de fragmentos (chunk dilution). Mi documento de prueba era corto. Mezclaba muchos temas como Spring AI, OAuth2 y mi preferencia de coches en un solo fragmento. El vector de ese fragmento se diluyó entre todos esos temas. Una pregunta específica sobre coches perdió fuerza frente a un fragmento demasiado general. Una mejor estrategia de fragmentación (chunking) solucionaría esto.

Lecciones aprendidas:

• Los modelos pequeños tienen límites de razonamiento.
• El fragmentado ingenuo (naive chunking) afecta la precisión de la recuperación.
• Depurar el "porqué" es más importante que simplemente corregir el error.

La arquitectura se mantiene en pie. Es lenta y a veces se equivoca, pero el ciclo está completo.

Fuente: https://dev.to/mido-dev/i-built-a-rag-app-then-asked-it-what-car-i-like-it-didnt-know-583n

Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi