La manera más efectiva de hacer que un LLM responda con información actual y específica es conectar sus respuestas a tus propios documentos. Con RAG (retrieve, augment, generate) se logra justo eso: traer contexto relevante, enriquecerlo y generar salidas claras. Aquí verás el flujo completo con Ollama, ChromaDB y un PDF real, más decisiones técnicas clave y matices de producción.
¿Qué es RAG y por qué importa hoy?
RAG resuelve el límite de actualización de los modelos y prioriza el contexto sobre el prompt. En lugar de que el LLM responda solo con su conocimiento preentrenado, consulta primero una base vectorial con tus datos y luego genera la respuesta.
- RAG = retrieve, augment, generate.
- El contexto manda sobre el prompt. Se propone pensar en “context engineers”, no solo en “prompt engineers”.
- Valor empresarial: permite priorizar fuentes internas sobre la web.
- Relevancia actual: se afirmó que RAG es incluso más importante que el propio LLM para entregar respuestas útiles y confiables.
¿Cómo implementar RAG en local con Ollama y ChromaDB?
Se mostró un pipeline local, sin depender de la nube, usando un PDF como fuente. La idea es simple: extraer, fragmentar, vectorizar, indexar y consultar con un LLM.
¿Qué son los chunks y cómo afectan la búsqueda?
- Se extrajo el texto del PDF y se dividió en chunks. De 61 páginas se obtuvieron 48 chunks.
- Los chunks son “rebanadas” del documento que facilitan la búsqueda semántica.
- Existen múltiples técnicas de chunking: pocas piezas grandes o miles de piezas pequeñas. Depende del algoritmo, hardware y objetivo.
- El solapamiento de caracteres puede variar por calidad de fuente/escaneo; no se detalló una configuración específica.
¿Qué son los embeddings y para qué sirven?
- Con Nomic Embed Text en Ollama se generaron los embeddings a partir de los chunks.
- Los embeddings permiten “ubicar” cada fragmento en un espacio vectorial para luego recuperarlo por similitud.
- El mismo modelo de embeddings se usó para la consulta semántica.
¿Cómo se indexa y consulta con ChromaDB?
- Se usó ChromaDB como base de datos vectorial local. Por defecto guarda en RAM; se configuró persistencia en disco para no perder el índice.
- Flujo técnico resumido:
- Extraer texto del PDF.
- Fragmentar en chunks.
- Generar embeddings con Nomic Embed Text en Ollama.
- Indexar en ChromaDB con persistencia.
- Consultar por similitud (retrieve) y pasar el contexto al LLM.
- Generar respuesta con LLaMA 3.2 en Ollama.
- Observación práctica: la recuperación directa devuelve texto tal cual, p. ej., en inglés si así está el PDF. Al pasar por el LLM, la salida se vuelve más legible y en español.
¿Qué herramientas y decisiones técnicas conviene considerar?
La elección de stack depende del caso de uso, presupuesto y políticas de datos. A continuación, puntos clave surgidos en preguntas técnicas.
¿Qué base vectorial elegir y dónde alojarla?
- ChromaDB: muy amigable para aprender, rápida de poner en marcha.
- pgvector (PostgreSQL): opción sólida para producción si se cuenta con buen hardware.
- Neo4j: valorado por su potencia y flexibilidad.
- Faiss: ligero, acelera con GPU, viable para producción; alta compatibilidad con modelos de Meta.
- Pinecone u opciones managed vs self-hosted: decisión guiada por presupuesto, sensibilidad de datos y compliance.
- Enfatizado el concepto de trade-off: no hay “mejor” universal, sino elecciones según el contexto.
¿Cuándo nube (Gemini) y cuándo local?
- Con Gemini se logró el mismo RAG subiendo el PDF y haciendo la pregunta, en segundos. La nube hace chunking, embeddings, indexado y consulta de forma automática.
- Ventajas nube: velocidad e infraestructura masiva.
- Ventajas local: control de datos y costo por consulta nulo.
- La decisión es más de negocio que técnica: políticas de datos, presupuesto y tiempos de respuesta.
¿Cómo asegurar que responde desde tus datos y no del preentrenamiento?
- Comparar respuestas con y sin contexto de RAG para ver diferencias claras.
- Probar offline para evitar acceso a la web.
- Restringir el comportamiento en el prompt: “responde solo con el contexto proporcionado”.
¿Qué tan amplio puede ser RAG?
- Además de texto, existen variantes como Graph RAG y estrategias para imágenes, video, Excel, PowerPoint. Cada tipo requiere ajustes en extracción e indexado.
- Caso de uso destacado: un repositorio de recetas históricas convertido a PDFs y consultado vía RAG para sugerir preparaciones según ingredientes comprados.
¿Qué buenas prácticas se mencionaron?
- Separar scripts: uno para indexar y otro para consultar.
- Persistir el índice de ChromaDB para no recalcular chunks/embeddings en cada ejecución.
- Usar modelos específicos para cada tarea: Nomic Embed Text para embeddings y LLaMA 3.2 para generación.
- Priorizar el contexto sobre el prompt. La calidad del contexto define la calidad de la respuesta.
¿Te gustaría probar un flujo similar o tienes dudas sobre tu stack actual de RAG? Escribe en los comentarios qué dataset usarías y qué herramientas estás considerando.
