Construimos sistemas RAG para que asistentes, buscadores y aplicaciones de IA trabajen con documentación y conocimiento propio de la empresa. Diseñamos ingesta, permisos, indexación, recuperación, ranking, citas y evaluación para que una respuesta pueda rastrearse hasta la fuente que la sustenta.
En RAG, la calidad depende de qué fuentes existen, cómo se actualizan, quién puede verlas y qué fragmentos recuperamos para cada pregunta. El LLM es sólo la última parte del recorrido.
RAG —Retrieval-Augmented Generation— es un patrón en el que el sistema recupera información relevante desde fuentes propias antes de pedir al modelo que responda. Así podemos trabajar con procedimientos, manuales, producto, políticas, intranets, documentación técnica o conocimiento que cambia con el tiempo sin depender únicamente de lo que el modelo aprendió durante su entrenamiento.
La ventaja empresarial no es “entrenar ChatGPT con nuestros PDFs”. El conocimiento permanece separado del modelo, puede actualizarse de forma independiente y puede conservar referencias a la fuente. Si mañana cambia un procedimiento, actualizamos la fuente y su índice; no necesitamos reentrenar el modelo para cada modificación documental.
Antes de indexar preguntamos qué repositorio es autoritativo, quién mantiene cada documento, qué versiones siguen vigentes y qué información no debería entrar en el sistema. Una carpeta con duplicados, borradores y políticas obsoletas produce retrieval de mala calidad aunque la base vectorial sea excelente.
Diseñamos conectores y reglas de ingesta para conservar procedencia, fecha, tipo de documento, idioma, departamento, producto, versión y otros metadatos útiles. También definimos qué ocurre al modificar o eliminar una fuente para que el índice no conserve conocimiento que ya no debería estar disponible.
Ingesta y parsing. Extraemos contenido útil de las fuentes respetando estructura y metadatos.
Chunking. Dividimos el contenido en unidades recuperables. No existe un tamaño universal: depende de la estructura del documento y del tipo de pregunta.
Indexación. Podemos combinar embeddings con índices léxicos, filtros y metadatos.
Retrieval. Recuperamos candidatos según la consulta. En muchos casos la búsqueda híbrida funciona mejor que depender sólo de similitud vectorial.
Reranking y filtrado. Ordenamos o descartamos candidatos antes de construir el contexto.
Generación. El modelo responde con los fragmentos seleccionados y, cuando el producto lo necesita, devuelve citas o enlaces a las fuentes originales.
La búsqueda vectorial es buena encontrando significado parecido, pero no siempre gana. Nombres exactos, códigos, referencias de producto o acrónimos pueden necesitar búsqueda léxica. Fechas, departamentos, idiomas, territorios o estados pueden necesitar filtros. Por eso tratamos retrieval como un sistema de búsqueda y no como una única consulta a una base vectorial.
Para preguntas complejas podemos reescribir o descomponer consultas, recuperar desde varias colecciones y reranquear candidatos. La arquitectura se decide con un conjunto de preguntas reales, no por adoptar el pipeline técnicamente más vistoso.
Un buscador interno no debería saltarse los permisos del repositorio original. Cuando el caso lo exige, incorporamos identidad, roles o ACLs a la recuperación para que un usuario sólo pueda traer al contexto documentos a los que ya tiene acceso.
El control debe aplicarse antes de generar la respuesta. Ocultar una cita después no soluciona que el modelo haya recibido información restringida. También registramos qué fuente se recuperó y con qué criterio cuando hace falta auditar una consulta.
Un sistema puede recuperar el documento equivocado, omitir una fuente relevante o recibir dos versiones contradictorias. Incluso con el contexto correcto, un modelo puede interpretarlo mal. Por eso evitamos prometer “cero alucinaciones”.
Diseñamos respuestas de no-encontrado, límites sobre qué puede afirmarse sin evidencia, citas visibles y evaluación con preguntas cuya respuesta correcta conocemos. Para casos sensibles podemos exigir que determinadas afirmaciones queden respaldadas por fragmentos recuperados o que una persona revise la salida.
Tenemos una guía específica sobre cómo reducir alucinaciones en sistemas de IA.
RAG y fine-tuning resuelven problemas distintos. Si necesitamos que el sistema conozca información que cambia —políticas, catálogo, documentación, procedimientos—, recuperar ese conocimiento suele ser más flexible que modificar pesos del modelo.
El fine-tuning puede tener sentido para comportamiento, formato, estilo o tareas especializadas cuando existe un dataset adecuado. Puede combinarse con RAG, pero no es un sustituto automático. Antes de elegir analizamos qué parte del problema es conocimiento y qué parte es comportamiento del modelo.
La comparación completa está en RAG vs fine-tuning.
RAG no es la respuesta universal para conectar una empresa con sus datos. Si la pregunta depende de datos transaccionales estructurados —por ejemplo stock, precio, estado de un pedido o saldo— suele ser más fiable consultar la API, base de datos o sistema autoritativo correspondiente y devolver una respuesta estructurada. Ahí el problema pertenece antes a integración de sistemas que a recuperación documental.
n
Tampoco añadimos un pipeline RAG si un corpus pequeño y estable puede resolverse con búsqueda tradicional o contexto directo de forma más simple. Y si las fuentes todavía mezclan borradores, versiones obsoletas o permisos sin resolver, preferimos ordenar primero el conocimiento: indexar desorden no lo convierte en verdad.
n
Por último, RAG aporta conocimiento en tiempo de consulta; no modifica por sí mismo el comportamiento del modelo. Si el objetivo es cambiar formato, estilo o una tarea especializada, puede encajar mejor prompting, lógica de producto o fine-tuning. Elegimos RAG cuando recuperar evidencia actualizada y trazable es realmente parte del problema.
n
La misma capa de conocimiento puede alimentar experiencias distintas: un asistente interno, un buscador semántico, soporte técnico, ayuda comercial, una interfaz dentro de una intranet o un agente que necesita consultar procedimientos antes de actuar.
La interfaz cambia, pero la pregunta de fondo es la misma: qué información puede recuperar, con qué frescura y cómo sabrá el usuario de dónde sale la respuesta. En sectores donde la vigencia documental es crítica, como RAG para alimentación y agro, producto, revisión, mercado y fuente forman parte del retrieval.
Una implementación fiable mezcla piezas distintas: software determinista para reglas previsibles, modelos cuando el lenguaje o la ambigüedad importan, recuperación de conocimiento cuando la respuesta debe apoyarse en fuentes y supervisión humana cuando el coste del error exige criterio. El objetivo no es maximizar la cantidad de IA, sino diseñar el sistema que mejor resuelve el trabajo.
Priorizamos sectores donde tipo de documento, vocabulario, vigencia, permisos y coste de una respuesta incorrecta cambian de forma material.
Manuales, fichas técnicas, procedimientos, incidencias y documentación de producto con códigos exactos, versiones y vocabulario que suele exigir búsqueda híbrida.
Conocimiento documentado con especial atención a vigencia, procedencia, permisos y separación entre información recuperada y decisiones reguladas.
Información operativa y de servicios con límites claros sobre qué fuentes puede utilizar el asistente y qué preguntas deben derivarse a una persona.
Expedientes, conocimiento interno, modelos de documentos y fuentes de referencia con acceso segmentado por cliente, equipo o materia.
Documentación de producto, changelogs, soporte y conocimiento técnico con necesidad de frescura y referencias exactas a versiones.
Catálogo, fichas, políticas y documentación comercial combinando significado semántico con SKU, referencias y filtros estructurados.
Respuestas directas sobre documentos, permisos, alucinaciones, búsqueda, fine-tuning y mantenimiento del conocimiento.
RAG es un patrón donde el sistema recupera información relevante desde fuentes externas al modelo y la utiliza como contexto para generar la respuesta. En una empresa permite consultar documentación y conocimiento propio que puede actualizarse sin reentrenar el LLM cada vez que cambia una política, un manual o un catálogo.
PDFs, páginas internas, wikis, documentación técnica, procedimientos, catálogos y otras fuentes estructuradas o no estructuradas pueden formar parte del corpus si podemos extraer contenido y gestionar su ciclo de vida. La cuestión importante no es el formato sino la calidad, vigencia, procedencia y permisos de esa información.
No. Puede reducir respuestas sin fundamento y hacerlas verificables, pero todavía puede fallar la recuperación o la interpretación. Por eso medimos retrieval y generación por separado, diseñamos respuestas de no-encontrado y utilizamos citas, restricciones o revisión humana cuando el coste del error lo exige.
Sí, si las fuentes y la arquitectura permiten transportar esa información de acceso hasta la capa de retrieval. El filtro debe aplicarse antes de incluir documentos en el contexto del modelo. No basta con esconder la cita en la interfaz después de haber recuperado contenido restringido.
RAG aporta conocimiento recuperado en tiempo de consulta; fine-tuning modifica el comportamiento del modelo a partir de ejemplos de entrenamiento. Para información que cambia con frecuencia suele ser más práctico mantenerla en fuentes recuperables. Pueden combinarse si el caso necesita tanto conocimiento actualizado como comportamiento especializado.
No. La base vectorial puede ser una pieza. Un sistema empresarial incluye ingesta, parsing, metadatos, permisos, búsqueda léxica o híbrida cuando aporta valor, reranking, construcción de contexto, generación, citas, evaluación y sincronización cuando las fuentes cambian.
Creamos un conjunto de preguntas representativas con fuentes esperadas o respuestas verificables. Medimos primero si el retrieval recupera la evidencia correcta y luego si la generación utiliza esa evidencia sin excederla. También comprobamos permisos, preguntas sin respuesta, latencia y comportamiento tras actualizar o eliminar documentos.
Depende de cómo se conecte la fuente y del nivel de frescura necesario. Podemos trabajar con sincronizaciones programadas, eventos o procesos de reindexación selectiva. Lo importante es definir una expectativa explícita de freshness y asegurar que una eliminación o cambio relevante no deje fragmentos antiguos circulando indefinidamente.
La capa de recuperación puede alimentar asistentes, workflows, agentes o aplicaciones. Separamos cada capacidad para mantener clara su responsabilidad.
Cuéntanos qué pregunta intenta resolver el equipo, en qué fuentes está la información y quién debería poder verla. Podemos revisar si el problema necesita RAG, búsqueda semántica, acceso a datos estructurados o una combinación.