RAG y embeddings: cómo darle a un LLM acceso al conocimiento propio de tu empresa

Hay una pregunta que viene en casi toda llamada con clientes que exploran IA: "como le hago para que el LLM responda con MIS datos, no con datos genéricos de internet". La respuesta corta es RAG. Veamos en detalle.

Qué significa RAG

RAG es Retrieval-Augmented Generation. La sigla en castellano sería "generación con recuperación aumentada". La idea es simple:

1. Antes de preguntarle al LLM, buscas en tus documentos los más relevantes a la pregunta del usuario.
2. Le pasas al LLM la pregunta + esos documentos como contexto.
3. El LLM responde usando esa información.

El LLM no "aprende" tus datos. Los lee en el momento. Eso significa que cuando actualices tus documentos, las respuestas se actualizan automáticamente.

Por qué necesitas embeddings

Si tu base de conocimiento son 5 documentos, podés pasarselos todos al LLM en cada consulta. Pero si son 500 o 5.000, no entran en el contexto y serian carísimos. Necesitas buscar solo los relevantes.

La búsqueda por palabra clave (como en una base de datos tradicional) no alcanza: si el usuario pregunta "cuanto cuesta la consultoría" y tu documento dice "honorarios profesionales", una búsqueda textual no los conecta.

Los embeddings resuelven eso: cada documento (y cada pregunta) se convierte en un vector numérico que representa su significado. Documentos con significado similar tienen vectores cercanos. Esa es la "búsqueda semántica".

La decisión técnica importante: donde guardas los vectores

Tradicionalmente esto se hace con bases de datos vectoriales especializadas: Pinecone, Weaviate, Qdrant, Chroma. Funcionan bien pero suman complejidad: una base más que mantener, otro provider que pagar, otro punto de falla.

En Tontin tomamos otra ruta: pgvector dentro del mismo Postgres de Supabase. La extensión agrega tipos de datos vectoriales a Postgres y permite hacer queries semanticas con SQL plano. Ventajas concretas:

• Una sola base de datos para todo: datos transaccionales y embeddings.
• Transacciones consistentes: si guardas un documento, los embeddings se actualizan en la misma transacción.
• Sin costo extra de un servicio aparte.
• Performance suficiente para volumenes de hasta varios millones de vectores con índices adecuados.

Las bases vectoriales especializadas siguen teniendo sentido cuando estas en escalas muy grandes (decenas de millones de vectores, latencia sub-100ms crítica), pero para el 90% de los casos empresariales, pgvector alcanza y sobra.

El flujo completo de un RAG en producción

Una primera versión funcional tiene cinco piezas:

1. Ingesta: cargar documentos, partirlos en chunks (párrafos o secciones), generar embeddings de cada chunk y guardarlos.
2. Índice vectorial: estructura de datos optimizada para búsquedas rápidas por similitud (HNSW, IVFFlat).
3. Retrieval: dado un input del usuario, generar su embedding y buscar los N chunks más cercanos.
4. Composición de prompt: armar el prompt final con la pregunta + los chunks recuperados + instrucciones.
5. Generación: enviar al LLM y devolver la respuesta al usuario.

Cada una de esas piezas tiene decisiones que afectan calidad: cómo cortar los documentos, cuántos chunks recuperar, cómo decidir que un chunk es relevante, como prevenir alucinaciones cuando el contexto no alcanza.

Casos donde RAG cambia el negocio

Donde lo vemos funcionar bien:

• Soporte interno: tu equipo puede preguntarle al sistema y obtener respuestas basadas en la documentación real de tu empresa.
• Asistente para clientes: respuestas sobre productos, términos, políticas, basadas en documentos oficiales.
• Onboarding: nuevos empleados pueden consultar procesos y procedimientos en lenguaje natural.
• Research: equipos que trabajan con mucho material (legal, medico, financiero) pueden buscar información semanticamente.

Conclusión

RAG es probablemente la aplicación de IA con mejor ROI hoy para empresas con conocimiento documentado. Es más barato y más estable que fine-tuning, no requiere reentrenar nada, y se actualiza automáticamente cuando cambian los documentos.

Si tu empresa tiene conocimiento disperso en PDFs, wikis, mails y carpetas, y querés que la gente pueda consultarlo en lenguaje natural, hablemos. En 30 minutos vemos si tu caso es bueno candidato para RAG.

---

Por Esteban Aleart, Founder & Lead Engineer de Pair Programming.