Sistema RAG desde cero: éxitos y fracasos que debés conocer

Andros Fenollosa arrancó a construir un sistema RAG desde cero sin haber hecho nada similar antes, con acceso a 1 TB de proyectos técnicos de casi una década en la industria offshore, y llegó a producción después de varios errores costosos. Este artículo desglosa qué salió mal, qué funcionó y qué arquitectura terminó en pie.

El caso real: un chat interno de ingeniería con 1 TB de proyectos

Ponele que te llega un requerimiento así: “queremos un chat donde los ingenieros puedan hacer preguntas en lenguaje natural sobre todos los proyectos que hicimos en los últimos diez años”. Suena razonable. Después te dicen que tiene que ser rápido, que la respuesta tiene que incluir referencias a los documentos originales, y que buena parte del corpus son archivos OrcaFlex, que es software de simulación para dinámica de cuerpos flotantes y cables en la industria offshore. Y que el total de datos supera el terabyte. Mezclado con CSVs, informes técnicos, análisis, regulaciones.

Eso fue exactamente lo que le tocó a Andros Fenollosa, según su artículo sobre el proceso completo. Lo interesante es que él mismo aclara que nunca había construido un sistema RAG antes. Ni sabía bien cómo funcionaba uno.

El resultado fue un proceso largo, con errores, correcciones y una arquitectura final que llegó a producción. Nada de “lo armé en un finde con un tutorial de YouTube”.

Stack tecnológico: Ollama + LLaMA + LlamaIndex + nomic-embed-text

El primer problema fue el stack. El requisito de confidencialidad descartó cualquier API externa: nada de OpenAI, nada de Anthropic, nada que salga a internet. Ollama apareció como la opción más madura para correr modelos localmente, con buen soporte y documentación. El modelo de lenguaje elegido fue LLaMA, y para los embeddings se optó por nomic-embed-text, que tiene buen balance entre calidad y rendimiento con documentos técnicos densos.

LlamaIndex tomó el rol de motor de orquestación. Si alguna vez configuraste un RAG desde cero sin un framework, sabés que manejar retrieval, contexto y generación a mano se convierte en un desastre de módulos sueltos. LlamaIndex resuelve eso, aunque tiene su curva.

Una forma de entender la vectorización sin abstracciones: pensá en el índice al final de un libro técnico. Buscás “tensión en cable”, vas a la página indicada. Los embeddings hacen algo parecido pero con similitud semántica en vez de palabras exactas. Buscás “esfuerzo en línea de amarre” y el sistema te lleva al chunk relevante aunque no use esa frase exacta. Más contexto en las mejores prácticas de seguridad de Microsoft.

Error #1: El chunking de 512 tokens es una trampa

El chunking de tamaño fijo es el default en casi todos los tutoriales. Agarrás el documento, lo partís cada 512 tokens con algo de overlap, y a producción. ¿Y qué pasa cuando lo probás con documentos estructurados? Exacto: el sistema recupera fragmentos que empiezan en la mitad de una cláusula, cortan una función de código a la mitad, o separan el encabezado de una subsección técnica del contenido que le corresponde.

La trampa del chunking fijo es que ignora la estructura del documento. Una cláusula legal tiene sentido completa. Una función de código tiene sentido completa. Un procedimiento técnico de tres pasos tiene sentido completo. Partirlos en tokens arbitrarios genera fragmentos que, por sí solos, no responden nada con coherencia.

Según este análisis sobre estrategias de chunking en producción, las alternativas que funcionan mejor en documentos técnicos son el chunking recursivo (que respeta jerarquías de sección), el semántico (que agrupa por coherencia de contenido) y el estructural (que sigue el formato del documento). La pregunta que hay que hacerse no es “cuántos tokens”, sino “¿esta unidad tiene sentido como respuesta aislada?”.

Con 1 TB de documentos OrcaFlex, CSVs y regulaciones mezcladas, el chunking fijo generaba basura. Hay que adaptar la estrategia al tipo de documento, no aplicar el mismo tamaño a todo el corpus.

Error #2: Retrieval inútil y documentos irrelevantes

Según investigación citada en múltiples fuentes del sector, el 73% de los sistemas RAG fallan en producción por retrieval deficiente (no por el modelo de lenguaje). El síntoma es fácil de reconocer: le hacés una pregunta al sistema, recupera fragmentos que no tienen relación con lo que preguntaste, y el LLM intenta responder igual con ese contexto irrelevante. El resultado es una respuesta que suena bien pero está construida sobre nada.

La búsqueda vectorial por similitud coseno tiene un problema: no sabe si el fragmento recuperado es realmente útil para responder, solo sabe que es parecido semánticamente. El reranking resuelve esto: una vez que recuperás los N candidatos, un modelo secundario los reordena por relevancia real respecto a la consulta.

En la práctica, el ajuste del score_threshold es el trabajo más tedioso pero necesario. Un umbral de 0.72, por ejemplo, no es un número sacado de un paper sino el resultado de evaluar manualmente alrededor de 200 consultas reales y ver en qué punto el sistema empieza a traer basura. (Sí, 200 consultas a mano. Nadie dijo que era glamoroso.) Esto se conecta con lo que analizamos en los conceptos clave de ChatGPT.

RAG de 3 niveles: la arquitectura jerárquica que funciona

Una arquitectura que apareció como solución a retrieval complejo es el RAG de 3 niveles, documentado en el caso de Normatia desarrollado por Silo Creativo, según su descripción técnica del sistema.

Nivel 1: búsqueda vectorial con reranking

Búsqueda semántica estándar sobre el corpus completo, con reranking para ordenar resultados por relevancia real. Es el piso del sistema. Sin esto bien ajustado, los otros niveles no sirven de nada.

Nivel 2: resolución de referencias directas

Cuando un documento normativo menciona directamente otro artículo (“ver artículo 14.3”), el sistema lo resuelve y trae ese contexto también. En documentos técnicos con referencias cruzadas esto cambia completamente la calidad de la respuesta.

Nivel 3: referencias indirectas

El nivel más complejo: referencias que no son explícitas pero que el sistema infiere como relevantes. Requiere más lógica pero captura contexto que los niveles anteriores pierden.

El stack de este proyecto fue FastAPI + LlamaIndex + Gemini (Embedding, Flash y Pro según el nivel) + Supabase con pgvector + Redis para caché. Un stack que tiene sentido en un contexto donde podés usar APIs externas, a diferencia del caso offshore que requería todo local.

Costes y latencia: el presupuesto que nadie calcula

Hay un caso documentado que ilustra bien el problema: una factura de API que pasó de $3.000 a $15.000 por mes porque nadie modeló los costes de inferencia antes de ir a producción. Y una latencia de 8 a 12 segundos cuando se había prometido menos de 3. Dos problemas que se podrían haber anticipado.

Otro caso: un equipo fintech con un presupuesto máximo de $800 por mes para inferencia, trabajando con 480.000 documentos. Ahí la elección del framework y el modelo no es una decisión técnica, es una decisión de negocio. Ya lo cubrimos antes en el funcionamiento de los modelos GPT.

Si estás evaluando frameworks para tu RAG, acá va la comparativa de las versiones actuales:

Framework	Versión	Punto fuerte	Punto débil	Mejor para
LangChain	0.3.15	Ecosistema amplio, muchas integraciones	Abstracción excesiva, difícil de debuggear	Prototipos rápidos, flujos complejos
LlamaIndex	0.12.3	RAG nativo, retrieval avanzado, reranking	Curva de aprendizaje más pronunciada	Sistemas RAG en producción, documentos técnicos
Haystack	2.7.1	Modular, bien testeado, buen soporte enterprise	Menos flexible para casos no estándar	Pipelines documentales, entornos corporativos

La comparativa en detalle entre estos tres frameworks, con casos reales de producción, está bien cubierta en este análisis de experiencia directa con los tres. LangChain tiene fama de abstracto en exceso, lo que hace que cuando algo falla no sabés bien dónde. LlamaIndex es más verboso pero más predecible. Haystack escala mejor en entornos donde la ingeniería de datos ya tiene sus propios pipelines.

Si tu RAG va a estar sobre servidores propios o infraestructura cloud, tené en cuenta que la elección del hosting afecta la latencia. Para entornos locales o híbridos, opciones como donweb.com tienen planes con servidores en Latinoamérica que reducen latencia regional si tu base de usuarios está acá.

Cómo evaluar si tu RAG realmente funciona

Las demos engañan. Un RAG que anda bien con las 10 consultas que preparaste para la presentación puede romperse con las 11 que no preparaste. El problema es que la evaluación de un sistema RAG no es trivial.

Las métricas que importan:

• Tasa de alucinaciones: el caso de MasterSuiteAI documentó una reducción del 88% al 12% con ajustes en retrieval y prompting. Es un número que vale la pena medir explícitamente.
• Relevancia del retrieval: ¿los fragmentos recuperados tienen relación real con la consulta? No solo similitud coseno alta.
• Latencia por consulta: medida en producción real, no en local con un documento de prueba.
• Coste por consulta: especialmente si usás APIs de pago. Multiplicá por el volumen mensual esperado antes de comprometerte con un modelo.

Las ~200 consultas de evaluación manual que mencionan varias de las fuentes no son un número arbitrario: es el mínimo para tener una distribución representativa de los tipos de preguntas que va a recibir el sistema. Hacerlo antes de producción ahorra meses de parches.

Qué está confirmado / Qué no

Confirmado

• El proyecto de Andros Fenollosa llegó a producción con Ollama + LLaMA + LlamaIndex + nomic-embed-text sobre un corpus de 1 TB de documentación técnica offshore.
• El chunking de tamaño fijo falla con documentos estructurados. Está documentado en múltiples implementaciones reales.
• El reranking mejora la relevancia del retrieval de forma consistente. El ajuste de score_threshold requiere evaluación manual sobre consultas reales.
• La arquitectura de 3 niveles fue implementada y documentada en producción para el caso de Normatia.
• Las versiones actuales de los frameworks en uso son LangChain 0.3.15, LlamaIndex 0.12.3 y Haystack 2.7.1.

No confirmado / Tomalo con pinzas

• El dato del 73% de sistemas RAG que fallan en producción viene citado en varias fuentes pero sin paper original identificable. El número parece plausible pero el benchmark no es independiente.
• La reducción de alucinaciones del 88% al 12% en MasterSuiteAI es un dato del propio proyecto, sin auditoría externa.
• Los costes específicos ($3.000 a $15.000/mes) corresponden a casos particulares con modelos y volúmenes concretos. Extrapolarlo a tu caso sin modelar primero es el error que describe el problema en primer lugar.

Errores comunes al construir un sistema RAG desde cero

Aplicar el mismo chunking a todos los tipos de documento

Un CSV estructurado no se chunea igual que un informe técnico en PDF, ni que una regulación con referencias cruzadas. Usar 512 tokens fijos para todo el corpus es el error más común y el que más degrada la calidad del retrieval. Definí una estrategia por tipo de documento desde el arranque.

Evaluar el sistema solo con las consultas que preparaste

Subís el sistema, lo probás con tus 10 preguntas de demo, funciona bárbaro, lo mandás a producción y de repente los usuarios hacen preguntas que no anticipaste, el retrieval trae basura, el LLM intenta responder igual con ese contexto y el sistema te devuelve respuestas que suenan bien pero están construidas sobre nada (spoiler: los usuarios se dan cuenta igual). La evaluación con un set diverso de ~200 consultas reales antes de producción no es opcional.

No modelar costes antes de elegir modelo y framework

Si usás APIs de pago, el coste por consulta multiplicado por el volumen mensual esperado puede convertir un proyecto “eficiente” en una factura que nadie aprobó. El caso de $3.000 a $15.000/mes es real. Modelá el coste de inferencia con el volumen esperado antes de comprometerte con un stack que use APIs externas. Sobre eso hablamos en las capacidades avanzadas de Gemini.

Confundir similitud vectorial alta con respuesta relevante

Un chunk puede tener similitud coseno alta con tu query y ser completamente inútil como contexto para responder. La similitud vectorial mide parecido semántico, no utilidad para la respuesta. Sin reranking y sin ajuste de threshold, el sistema va a traer fragmentos que parecen relacionados pero no responden nada concreto.

Esto se conecta con From zero to a RAG system: successes and failures, donde desarrollamos el tema en detalle.

Preguntas Frecuentes

¿Cómo construir un sistema RAG desde cero sin experiencia previa?

El caso de Andros Fenollosa muestra que es posible, pero no rápido. El punto de partida es elegir un framework de orquestación (LlamaIndex es la opción más orientada a RAG), definir una estrategia de chunking adaptada al tipo de documentos, y evaluar el retrieval manualmente antes de ir a producción. Esperá iterar varias veces antes de tener algo que funcione de forma consistente.

¿Qué framework elegir para RAG: LangChain, LlamaIndex o Haystack?

Para RAG en producción con documentos técnicos, LlamaIndex 0.12.3 es la opción más directa: tiene retrieval avanzado y reranking nativos, y es más predecible cuando algo falla. LangChain 0.3.15 tiene más integraciones pero sus abstracciones complican el debugging. Haystack 2.7.1 es la mejor opción si tu equipo ya tiene pipelines de datos estructurados y necesita algo modular y testeado.

¿Cómo evitar alucinaciones en un sistema RAG?

El retrieval deficiente es la causa principal, no el modelo de lenguaje. Con reranking bien ajustado y un score_threshold calibrado sobre consultas reales, la tasa de alucinaciones puede bajar del 88% al 12% (caso MasterSuiteAI). Además, estructurar el prompt para que el modelo solo responda con lo que tiene en el contexto, y no con conocimiento general, reduce las respuestas inventadas.

¿Qué estrategia de chunking funciona mejor para documentos técnicos?

El chunking recursivo o por estructura supera al chunking de tamaño fijo en documentos con jerarquías (secciones, subsecciones, cláusulas). La pregunta correcta no es cuántos tokens, sino si esa unidad tiene sentido como respuesta aislada. Para corpus mixtos con CSVs, PDFs técnicos y regulaciones, lo más efectivo es definir una estrategia diferente por tipo de documento en vez de aplicar un tamaño global.

Conclusión

Construir un sistema RAG desde cero con documentación técnica real es un proceso con errores predecibles y costosos si no los anticipás. El chunking de 512 tokens rompe documentos estructurados. El retrieval sin reranking trae fragmentos inútiles. Los costes de inferencia se disparan si no los modelás antes. Y las demos nunca muestran los casos que van a fallar en producción.

Lo que el caso de Andros Fenollosa muestra con claridad es que llegar a producción con 1 TB de documentación técnica offshore es posible, incluso sin experiencia previa en RAG, pero requiere iterar sobre cada capa del sistema con datos reales y evaluación manual. No hay shortcut en la calibración del retrieval.

Si estás en la etapa de diseño, definí tu estrategia de chunking por tipo de documento, elegí LlamaIndex si el RAG es el núcleo del sistema, y evaluá con un set de consultas diverso antes de mostrarle algo a producción. Si ya tenés algo corriendo y los resultados son inconsistentes, el primer lugar donde mirar es el retrieval, no el modelo.

Fuentes

• Andros Fenollosa – From zero to a RAG system: successes and failures (caso completo de implementación)
• Silo Creativo – Cómo creamos un RAG de 3 niveles con FastAPI y LlamaIndex
• Dev.to – LangChain vs LlamaIndex vs Haystack: lo que aprendí construyendo RAG en producción
• Dev.to – RAG profundo: estrategias de chunking, bases de datos vectoriales y optimización
• bcloud.consulting – Por qué tu sistema RAG falla en producción: guía completa de troubleshooting