🔎 Cómo diseñar búsquedas correctas en un sistema RAG optimizado
Un sistema de Retrieval-Augmented Generation (RAG) depende críticamente de la calidad de la consulta de entrada. En particular, la búsqueda vectorial pura presenta un punto ciego: funciona bien solo cuando el embedding de la pregunta es matemáticamente cercano al de los documentos almacenados.
Cuando la consulta contiene errores ortográficos, ambigüedad o mala estructura, el vector resultante se “desvía”, reduciendo significativamente la probabilidad de recuperar información relevante.
A continuación se presentan estrategias prácticas para mitigar este problema, especialmente en arquitecturas desplegadas en la Nube, sin exigir que el usuario formule preguntas perfectas. Esto es sugerido para los desarrolladores.
🧹 1. Filtro de limpieza (LLM Guard)
Antes de generar el embedding, es recomendable normalizar la consulta utilizando un modelo ligero. Este actúa como corrector ortográfico y semántico.
Flujo:
Usuario → Worker (LLM corrector) → Embedding → Búsqueda vectorial
Prompt sugerido:
Eres un asistente de entrada. Reescribe la siguiente consulta corrigiendo errores ortográficos y mejorando la claridad, manteniendo el significado original. Responde solo con el texto corregido.
Modelos recomendados: llama-3.1-8b-instruct-fp8, llama-3.2-3b.
⚙️ 2. Búsqueda híbrida (Hybrid Search)
La práctica estándar en sistemas productivos es combinar múltiples estrategias de recuperación.
- Búsqueda vectorial → similitud semántica
- Búsqueda por texto → coincidencia exacta o parcial (por ejemplo, usando D1)
Ventaja:
- Errores ortográficos → compensados por el vector
- Términos técnicos exactos → capturados por búsqueda textual
Esta combinación reduce significativamente los falsos negativos.
🔤 3. Fuzzy Search y normalización
Cuando no se desea incorporar un LLM adicional (por costo o latencia), se puede mejorar la robustez mediante técnicas clásicas:
-
Fuzzy Matching: uso de distancia de Levenshtein para aproximar términos.
Ejemplo:fisca → física -
Normalización:
- Convertir a minúsculas
- Eliminar acentos
- Unificar formato antes del embedding
Es fundamental que la base vectorial haya sido indexada con las mismas reglas de normalización.
🧠 4. El problema del “ruido” en embeddings
Los modelos de embeddings son altamente sensibles a la estructura de la oración.
Ejemplo:
-
✔️ Consulta estructurada:
¿Cuál es el coeficiente de dilatación del concreto? -
❌ Consulta ruidosa:
concreto… eso de la dilatación cuánto es?
En el segundo caso, el vector se degrada debido a palabras irrelevantes o ambiguas.
🚀 5. Expansión de consulta (Query Expander)
Una estrategia avanzada consiste en transformar la pregunta del usuario en una consulta más técnica y precisa antes de generar el embedding.
Ejemplo:
Entrada del usuario: "¿cómo va lo del túnel roto?" Consulta expandida: "Análisis estructural y colapso de túneles en Sucre"
Esta técnica mejora la calidad del vector y aumenta la probabilidad de recuperar documentos relevantes.
🧩 Conclusión
Un RAG eficiente no depende únicamente del modelo de lenguaje, sino de la calidad del pipeline de consulta.
- 🧹 Limpieza previa de entrada
- ⚙️ Recuperación híbrida
- 🔤 Normalización y tolerancia a errores
- 🚀 Expansión semántica
Consulta cruda] --> B[🧹 Preprocesamiento
Normalización + limpieza] B --> C{¿Usar LLM Guard?} C -->|Sí| D[🤖 LLM Corrector
Reescritura semántica] C -->|No| E[➡️ Consulta directa] D --> F[🚀 Query Expander
Optimización semántica] E --> F F --> G[🧠 Generación de Embedding] G --> H1[🔎 Vector Search
Cloudflare Vectorize] F --> H2[📚 Keyword Search
D1 / SQL] H1 --> I[📦 Resultados vectoriales] H2 --> I2[📦 Resultados textuales] I --> J[⚖️ Fusión / Ranking] I2 --> J J --> K[📄 Contexto relevante] K --> L[🤖 LLM Generador
Respuesta final] L --> M[💬 Respuesta al usuario]
Implementadas correctamente, estas técnicas permiten construir sistemas que toleran ambigüedad humana
y aún así producen respuestas de alta calidad.
Referencia:
