Lo que aprendimos construyendo sistemas RAG en producción para clientes empresariales

Una demo de RAG es sencilla: vectorizar algunos documentos, recuperar las mejores coincidencias, incluirlas en un prompt. El RAG en producción es una disciplina completamente distinta, y la mayoría de los problemas difíciles viven fuera del modelo.

La estrategia de segmentación importa más que la elección del modelo. Los documentos mal segmentados, cortados a mitad de una frase, sin encabezados, sin metadatos, producen respuestas equivocadas con total confianza sin importar qué LLM esté detrás. Dedicamos una parte desproporcionada del inicio de cada proyecto a la estructura del documento y los metadatos antes de tocar el pipeline de recuperación.

La evaluación tiene que construirse antes de lanzar la función, no después de que los usuarios se quejen. Construimos un pequeño conjunto de evaluación etiquetado a partir de consultas reales desde el inicio de cada proyecto, y lo volvemos a ejecutar con cada cambio de prompt o de recuperación para detectar regresiones antes de que un cliente las encuentre.

La búsqueda por similitud vectorial pura falla en consultas que dependen de un término exacto, un código de producto o un nombre al que el modelo de embeddings no da suficiente peso. La búsqueda híbrida, que combina similitud vectorial con coincidencia de palabras clave/BM25 y reordena los resultados combinados, supera de forma consistente a cualquiera de los dos enfoques por separado una vez que el conjunto de documentos es grande o las consultas se vuelven específicas. Cuesta más construirla y ajustarla, y vale la pena para cualquier caso que vaya más allá de una base de conocimiento pequeña y homogénea.

El filtrado por metadatos es lo que hace que la recuperación sea confiable a escala, no solo precisa. Etiquetar los fragmentos con fuente, fecha, nivel de acceso y tipo de documento permite acotar la recuperación antes de que se ejecute siquiera la búsqueda por similitud, lo cual importa tanto para la calidad de la respuesta (no recuperar un documento de política ya reemplazado) como para el control de acceso (no recuperar un documento que este usuario no debería ver, sin importar cuán bien coincida con la consulta).

Las salvaguardas y las señales de confianza importan tanto como la precisión. Un sistema que dice "no estoy seguro, aquí tiene a una persona a quien preguntar" supera a uno que responde con confianza y se equivoca, especialmente en casos de soporte y cercanos al cumplimiento normativo, donde una respuesta equivocada cuesta más que una lenta.

La observabilidad tiene que construirse desde el primer día, no añadirse cuando algo se rompe. Registramos los fragmentos recuperados junto con la respuesta generada en cada consulta de producción, no solo el resultado final, porque cuando una respuesta está mal, la causa casi siempre está en la recuperación, y no se puede depurar lo que no se capturó.

El costo y la latencia son decisiones de producto, no detalles de infraestructura de segundo plano. Qué modelo atiende qué consulta, cuándo usar caché y cuándo un modelo más pequeño es suficiente son decisiones que tomamos de forma explícita, porque cambian la economía unitaria de la función.