Mi experimento sobre Consulta RAG: Sistema Hídrico de Cumaná
 |
| La búsqueda en un mar de ideas... |
En las últimos días he estado construyendo un sistema de consulta basado en mis investigaciones de geohistoria de Cumaná —específicamente sobre el colapso del Túnel de Trasvase Guamacán y la crisis hídrica que afecta a Cumaná y otras ciudades del oriente venezolano.
🔗 https://url_url_url/consulta-rag (solicitar al autor el enlace de prueba)
El sistema utiliza como modelo de inferencia Llama 3.3 70B (modelo de lenguaje de gran escala, ~70 mil millones de parámetros, optimizado para comprensión profunda, razonamiento contextual y generación de texto complejo) y como modelo de embeddings Qwen3-Embedding-0.6B (modelo especializado en representación semántica de texto, optimizado para búsqueda por similitud, clustering y recuperación de información), con almacenamiento en una base de datos vectorial.
Los modelos LLM (Large Language Models) son, en esencia, compresores estadísticos del lenguaje humano. Durante el entrenamiento, ajustan miles de millones (o billones, en escala anglosajona) de parámetros para minimizar la perplejidad (†) sobre grandes volúmenes de texto.
El resultado es una red neuronal que ha interiorizado patrones sintácticos, semánticos y factuales —lo que, en términos prácticos, podemos llamar conocimiento—. Sin embargo, ese conocimiento queda congelado en los pesos del modelo desde el momento del entrenamiento.
La técnica de RAG (Retrieval-Augmented Generation) aborda este problema de raíz: en lugar de pedirle al modelo que “recuerde”, se le proporcionan fragmentos relevantes extraídos de una base documental. El modelo deja de comportarse como un oráculo y pasa a ser un lector experto capaz de sintetizar evidencia concreta.
- La búsqueda semántica en el espacio vectorial no busca palabras exactas: busca proximidad de significado.
- Dos frases que no comparten una sola palabra pueden estar muy próximas en ese espacio si expresan la misma idea.
- Esto es recuperación de información por similitud conceptual, no por coincidencia léxica. Y es precisamente lo que permite que un sistema responda preguntas sobre documentos utilizando formulaciones que esos mismos documentos nunca emplearon.
- El vector no es el texto: es la huella semántica del texto en un espacio matemático donde la distancia representa significado. Buscar en ese espacio es buscar ideas, no palabras.
† Perplejidad (perplexity): métrica que cuantifica la incertidumbre del modelo al predecir el siguiente token en una secuencia. Un modelo con perplejidad 10 se comporta, estadísticamente, como si eligiera entre 10 opciones equiprobables en cada paso.
PD: Agradezco sus comentarios luego de probar el sistema, con el fin de mejorar su comportamiento base. Para obtener mejores resultados, es recomendable formular preguntas de manera precisa y con buena ortografía.
~ Agradezco no re-enviar el enlace ~
Anexo: Como hacer una búsqueda correcta en un RAG optimizado:
Precisamente el "punto ciego" de la búsqueda vectorial pura depende de la pregunta. Cuando usas vectores, el sistema depende de que el Embedding de tu pregunta se parezca matemáticamente al del documento. Si hay errores ortográficos o la estructura es pobre, el modelo de embeddings genera un vector "desviado", lo que te aleja de la información correcta en tu base de datos.
Aquí están tres estrategias técnicas que puedes aplicar en una capa de Cloudflare para solucionar esto sin obligar al usuario a escribir perfecto:
1. El "Filtro de Limpieza" (LLM Guard)
Antes de enviar la pregunta a tu base de datos vectorial (Vectorize), pásala por un modelo pequeño y rápido como llama-3.2-3b. Pídele que actúe como un corrector de estilo.
Flujo: Pregunta del usuario $\rightarrow$ Worker (LLM Corrector) $\rightarrow$ Embedding $\rightarrow$ Búsqueda Vectorial.
Prompt sugerido: "Eres un asistente de entrada. Reescribe la siguiente consulta para corregir errores ortográficos y mejorar la claridad, manteniendo el significado original. Solo entrega el texto corregido."
2. Implementar Búsqueda Híbrida (Hybrid Search)
Esta es la solución estándar en la industria. No confíes solo en el vector.
Cómo funciona: Buscas simultáneamente por el vector y por palabras clave (usando texto plano en tu base de datos D1).
Por qué ayuda: Si el usuario escribe mal una palabra pero el resto de la oración es clara, el vector lo compensa. Si el usuario escribe una palabra técnica exacta pero con mala gramática, la búsqueda de texto la encuentra.
3. Uso de N-Grams o "Fuzzy Search"
Si no quieres usar un LLM para corregir (por ahorrar neuronas), puedes usar lógica de programación en tu Worker:
Fuzzy Matching: Utiliza algoritmos como la Distancia de Levenshtein para comparar palabras. Si el usuario escribe "fisca", el sistema entiende que probablemente quiso decir "física".
Normalización: Convierte siempre la entrada a minúsculas y elimina acentos antes de generar el embedding, asegurándote de que tu base de datos vectorial haya sido indexada con esa misma limpieza.
4. El problema del "Ruido" en los Embeddings
Los modelos de embeddings son muy sensibles al orden de las palabras.
Oración bien estructurada: "¿Cuál es el coeficiente de dilatación del concreto?" $\rightarrow$ Vector muy preciso.
Oración pobre: "concreto... eso de la dilatación cuanto es?" $\rightarrow$ El vector se "ensucia" con las palabras de relleno.
¿Qué puedes hacer en Cloudflare?
Como ya tienes un RAG funcionando, te recomiendo implementar un "Query Expander".
Usa un Worker para transformar la pregunta del usuario en una "búsqueda ideal". Por ejemplo, si el usuario pregunta: "¿cómo va lo del túnel roto?", el Worker lo expande a: "Análisis estructural y colapso de túneles en Sucre". Ese nuevo texto generará un vector mucho más potente para buscar en tu base de datos.
