Diseño de una pipeline RAG fundamentada: segmentación, filtrado y transmisión en tiempo real.

Los modelos de lenguaje de uso general razonan, escriben y explican de manera excepcionalmente buena hasta que se les pregunta sobre un sistema que nunca han visto: su documentación interna, sus flujos de trabajo específicos del dominio, el comportamiento exacto de una aplicación empresarial que su equipo configura a diario. Ese conocimiento no está en los datos de entrenamiento, y ningún truco con las instrucciones puede introducirlo allí. Peor aún, el modelo rara vez admite esa laguna; en su lugar, genera una suposición fluida y segura. A continuación se presenta la base de un sistema de generación mejorada por recuperación de información (RAG): cómo se preparan los documentos, cómo se crean los fragmentos, cómo se filtran las opciones posibles, cómo se forma la instrucción y cómo llegan las respuestas al usuario, junto con el razonamiento detrás de cada decisión para que pueda aplicarlo a su propio sistema.

Por qué la integración con información real cambia la función del modelo

La premisa de RAG es fácil de explicar. En lugar de confiar en que el modelo recuerde una respuesta, se le proporciona la respuesta para que la lea. La documentación real se divide en fragmentos buscables; cuando llega una pregunta, el sistema localiza los pasajes con mayor probabilidad de responderla y los incluye en el contexto del modelo. La tarea pasa de “recordar este hecho” a “leer este pasaje y explicarlo bien”, que es precisamente el tipo de trabajo que los modelos de lenguaje realizan de manera fiable.

El concepto es simple, pero hacer que funcione bien no lo es. Obtener las piezas adecuadas, mantenerlas coherentes y responder lo suficientemente rápido como para que nadie se quede mirando un indicador de carga implica decisiones que son fáciles de subestimar. El sistema descrito aquí está deliberadamente en la fase básica: obtener información y luego responder. Las extensiones más ambiciosas, como los grafos de conocimiento o un agente que utiliza herramientas, se construyen sobre precisamente estas piezas, y solo funcionan si la base es sólida.

Markdown como fuente de verdad

Todo el conocimiento al que responde el sistema se encuentra en archivos Markdown. Esa elección es más práctica que estética. Markdown posee suficiente estructura para preservar el significado, incluyendo encabezados, jerarquías, listas y tablas, pero sigue siendo texto plano que puede dividirse e incrustarse sin la complejidad de un formato de marcado más pesado.

Los archivos se redactan de la manera en que las personas suelen escribir documentación técnica: un encabezado por tema, subtítulos para los detalles correspondientes, tablas cuando es importante la estructura, y capturas de pantalla allí donde una imagen explica mejor que el texto. Nada del estilo de redacción se adapta para ajustarse al proceso de generación automática. Esto es importante, porque la documentación que debe escribirse para los sistemas de búsqueda suele no escribirse en absoluto.

Evitar las capturas de pantalla en el camino de integración

Las capturas de pantalla merecen una decisión de diseño propia. En la documentación de aplicaciones no son solo un elemento decorativo: una gran parte de las preguntas de tipo “cómo hacerlo” en realidad buscan saber qué botón o menú utilizar, y el texto por sí solo maneja esto muy mal.

En lugar de incrustar imágenes dentro de los archivos de documentación, estas se almacenan por separado y cada archivo Markdown hace referencia a ellas mediante una URL. El enlace es solo texto, por lo que pasa por los procesos de fragmentación, incrustación y recuperación como cualquier otro texto. Cuando un fragmento recuperado que contiene dicho enlace termina en una respuesta, el frontend lee la URL y carga la imagen en el momento de renderizado. El usuario ve la documentación tal como fue escrita, incluidas las imágenes, mientras que el pipeline de ingestión y recuperación nunca procesa los datos de imagen.

Merece la pena nombrar este principio: mantener el contenido como texto en todas las etapas que solo requieren texto, y resolver los medios más complejos en el último momento posible, cuando algo está a punto de mostrarse a una persona.

Transmisión en streaming de la respuesta a medida que se genera

Ese mismo enfoque de “último paso” se aplica también a la entrega de respuestas. Una vez que comienza la generación, no hay razón para hacer esperar al usuario a que reciba la respuesta completa. Los tokens se envían de vuelta a través de una conexión persistente a medida que el modelo los genera, por lo que la respuesta se construye poco a poco, palabra por palabra, al igual que cuando alguien escribe una explicación. Sumado a las imágenes que se cargan de forma asíncrona a medida que sus URLs aparecen en el flujo, la experiencia se siente como una conversación, aunque en realidad se trata de una consulta a una base de datos seguida de la generación.

Fragmentación jerárquica: respetando la estructura del documento

Antes de poder buscar algo, la documentación debe dividirse en unidades que puedan integrarse y recuperarse de forma independiente. Este es el paso en el que muchos sistemas RAG acortan caminos sin que se note, y las consecuencias suelen pasar desapercibidas.

Por qué el corte en tamaños fijos falla silenciosamente

El enfoque ingenuo es mecánico: se elige un número de tokens, se divide el documento en fragmentos de aproximadamente ese tamaño y se continúa. Es rápido de implementar, pero erróneo de una manera que nunca genera error alguno. Una ventana de tamaño fijo no tiene concepto de los límites entre oraciones, y mucho menos de los conceptuales. Divide felizmente una procedimiento numerada por la mitad, separa una tabla del encabezado que le da sentido, o deja una definición en un fragmento mientras su ejemplo queda en el siguiente.

Tales fragmentos tienen la longitud correcta pero la forma incorrecta, y la calidad de la recuperación depende de esa forma. Si el texto recuperado no contiene un pensamiento completo, las instrucciones cuidadosas posteriores no pueden repararlo. El modelo razona sobre un fragmento, y la respuesta refleja eso.

Leer en su lugar el árbol de encabezados

El agrupamiento jerárquico parte de la observación de que la documentación ya tiene estructura y de que esa estructura es un recurso valioso. Los documentos técnicos bien redactados forman un árbol de encabezados: secciones principales, subsecciones anidadas debajo de ellas y texto principal asociado a cada nivel. En lugar de ignorar ese árbol, el herramienta de agrupamiento lo recorre:

• Cada sección principal se convierte en un grupo por sí misma.
• Cada subsección también se vuelve su propio grupo, pero uno que registra a su sección padre.
• Si una subsección es lo suficientemente corta como para leerse mejor junto a su sección padre, ambas se fusionan en un único grupo combinado en lugar de generar un fragmento diminuto y carente de contexto.
• El contenido que no está bajo ningún encabezado, como introducciones, párrafos sueltos o notas, sigue siendo capturado como un tipo de grupo propio en lugar de ser descartado o forzado de manera forzada dentro de otro grupo.

Metadatos que hacen posibles las etapas posteriores

Cada fragmento contiene más que su texto:

• Ruta de navegación: la cadena de encabezados anteriores. Un fragmento relacionado con una sola opción de configuración sigue sabiendo que forma parte de un flujo de trabajo más amplio, incluso cuando se obtiene por separado.
• Etiqueta de tipo: que permite distinguir entre secciones de nivel superior, detalles anidados, fragmentos padre-hijo fusionados y notas independientes.
• Identificador estable: que vincula el fragmento a su origen exacto en el archivo de origen.

Estos metadatos no son meramente decorativos. Son los que permiten posteriormente realizar un nuevo ordenamiento, volver a combinar secciones divididas y obtener respuestas coherentes y atribuibles. Una lista simple de bloques de texto del mismo tamaño no puede soportar nada de esto; en cambio, un fragmento que conoce su posición dentro de la estructura sí puede.

El compromiso fundamental consiste en seguir la estructura que ya tiene el documento en lugar de imponer una arbitraria. Esto da resultados rápidamente: los fragmentos se leen como pensamientos completos porque realmente lo son, estructurados tal como los definió el autor de la documentación.

Una segunda pasada adaptativa para el límite de tokens de incrustación

El fragmentado jerárquico logra la estructura adecuada, pero no tiene en cuenta una restricción estricta subyacente: el modelo de incrustación solo acepta un número limitado de tokens por entrada. La estructura de un documento no tiene en cuenta ese límite. Una larga sección de preguntas frecuentes, una extensa tabla de referencia o una subsección que simplemente es muy extensa pueden ser fragmentos perfectamente coherentes y, aun así, superar lo que el modelo está dispuesto a aceptar.

Este fallo es peligrosamente silencioso. Dependiendo del cliente, un fragmento de tamaño excesivo es rechazado o truncado en silencio antes de su incorporación, y en ambos casos el contenido desaparece sin que nadie se dé cuenta en el momento de la ingestión. El truncamiento es el resultado más insidioso, ya que el fragmento sigue existiendo y siendo recuperado; su vector simplemente ya no representa el texto que se creía que representaba.

La solución consiste en realizar un segundo proceso después del procesamiento jerárquico. Cada fragmento se evalúa en relación con un umbral de seguridad establecido bien por debajo del máximo real del modelo, de modo que exista un margen en lugar de un límite abrupto. El conteo de tokens varía entre los diferentes tokenizadores, y un margen absorbe esa incertidumbre. Los fragmentos por debajo del umbral pasan sin cambios. Los fragmentos por encima de él se dividen aún más, y cada parte resultante es:

• etiquetada explícitamente como una parte de un todo más grande, para que las etapas posteriores puedan encontrar a sus componentes relacionados

dado que existe una pequeña superposición de texto con el fragmento adyacente, nadie que lo lea, ya sea humano o modelo, se encuentra con un corte abrupto y sin contexto en medio de una idea

Dónde cortar exactamente, y por qué una división simple no es suficiente incluso en este caso, constituye un tema de diseño importante por sí mismo. En términos básicos, el punto esencial es que el proceso jerárquico garantiza la forma y el proceso adaptativo garantiza el ajuste, de modo que una buena estructura nunca implica la pérdida de contenido.

Almacenamiento de vectores con sus metadatos

Los fragmentos incrustados necesitan un sistema diseñado para responder a una única pregunta: cuáles de estos numerosos vectores están más cerca de este nuevo uno, de manera rápida y a gran escala. Las bases de datos relacionales no están diseñadas para esa consulta, por lo que se necesita un almacén de vectores creado específicamente para esta tarea.

La base de datos funciona dentro de un contenedor en lugar de estar instalada directamente en el host. Las razones son prácticas: una instancia contenerizada es fácil de iniciar, eliminar o mover a otra máquina, y no introduce dependencias en el sistema host.

Junto a cada vector, el almacén mantiene una carga de metadatos completa que incluye el texto del fragmento, las pistas de navegación, su tipo e identificador de origen. Por lo tanto, cada resultado de similitud llega con todo el contexto necesario para ser utilizado de inmediato, en lugar de como un vector anónimo. La combinación de una búsqueda rápida de similitud con metadatos detallados asociados a cada resultado permite que el filtrado, la reclasificación y el reagrupamiento funcionen sin necesidad de realizar una segunda consulta en otra fuente de datos.

El ciclo de vida de la solicitud: desde la pregunta hasta la respuesta en streaming

Aquí es donde el sistema realiza su verdadero trabajo, por lo que vale la pena describirlo con suficiente precisión para que se pueda reutilizar su lógica.

Separar la presentación de los datos del streaming

La API expone dos puntos finales con tareas diferentes. El primero recibe la pregunta e inmediatamente devuelve un identificador de conversación. El segundo es un punto final de streaming al que el frontend se conecta con dicho identificador. Aceptar una pregunta y entregar una respuesta son responsabilidades distintas, y separarlas permite que la respuesta fluya de forma incremental, en lugar de mantener una única solicitud abierta hasta que esté lista una respuesta monolítica. También proporciona al cliente un mecanismo claro para reconectarse o correlacionar los registros de una conversación específica.

Entre esos dos puntos finales, se ejecutan los siguientes pasos en orden.

Paso 1: incrustar la pregunta con el modelo de ingestión

El texto del usuario se incrusta utilizando exactamente el mismo modelo que se empleó durante su procesamiento. Este no es un detalle que pueda modificarse. Las comparaciones de similitud solo tienen sentido cuando el vector de la consulta y los vectores almacenados pertenecen al mismo espacio vectorial. Si el modelo de incrustación cambia en algún momento, cada fragmento almacenado debe reincrustarse, ya que los vectores provenientes de dos modelos diferentes no son comparables, incluso cuando describen el mismo texto.

Paso 2: extender la red de búsqueda

Se compara el vector de la consulta con los vectores de los fragmentos almacenados, y se obtienen aproximadamente los doce resultados más similares. La métrica utilizada es la similitud coseno, que en esencia mide el ángulo entre dos vectores: cuanto más pequeño sea el ángulo, mayor será la similitud en su significado. Esta etapa se diseña de forma intencionadamente amplia, con el objetivo de garantizar que no se excluya nada relevante antes de comenzar la selección real.

Paso 3: reducir los candidatos a través de tres filtros

Tres filtros se aplican en secuencia para reducir esos doce candidatos a los pocos que realmente importan:

1. Umbral de similitud. Se eliminan los candidatos con una puntuación por debajo del mínimo. Se trata de fragmentos que solo llegaron a la lista porque no existía nada mejor, y mantenerlos añadiría ruido.
2. Proceso de reclasificación. Los candidatos sobrevivientes son puntuados nuevamente por un modelo que funciona de manera diferente a la primera búsqueda. En lugar de incrustar la pregunta y cada fragmento por separado y comparar los vectores, toma la pregunta y un fragmento como entrada conjunta y determina si ese fragmento realmente responde a la pregunta. Esto elimina un tipo específico de falso positivo: pasajes que se encuentran cerca de la consulta en el espacio vectorial pero que resultan no contener la respuesta al leerse junto a ella.

Un límite inferior estricto y un tope máximo rígido. Después de la reclasificación, un umbral mucho más estricto elimina lo que queda, y lo que sobrevive está limitado a un máximo pequeño y fijo.

Cada etapa tiene una función específica: la primera protege la información contra el ruido, la segunda garantiza precisión, y la tercera impone un límite estricto en la cantidad de contexto que llega al modelo. Lo que queda es el mejor material disponible, no simplemente lo que ocupa el primer lugar en una larga lista.

La razón de este orden es el costo. El reclasificador por lectura en pares es mucho más preciso que la comparación vectorial, pero también es mucho más costoso, ya que debe procesar cada par de fragmentos de pregunta conjuntamente. Al utilizarlo con una docena de candidatos previamente filtrados en lugar del corpus completo, se obtiene su precisión sin pagar su precio total.

Paso 4: restaurar las secciones divididas

Algunos fragmentos que han sobrevivido son solo partes de una sección que el proceso adaptativo tuvo que dividir. Si el modelo recibe, por ejemplo, la segunda de tres partes sin ninguna indicación de que existen las demás, su respuesta se basa en información incompleta. Por lo tanto, antes de compilar la solicitud, se verifica cada fragmento sobreviviente en busca de sus “hermanos”, es decir, las otras partes de la misma sección original. Cuando estos hermanos existen, se recuperan y se colocan en orden, cada uno etiquetado con su posición. El modelo lee entonces toda la sección en lugar de solo una parte de ella. Es precisamente aquí donde resultan útiles las etiquetas de las partes y los identificadores estables añadidos al procesar la información.

Paso 5: compilar la solicitud

Todos los fragmentos recuperados, junto con sus elementos relacionados restaurados, forman el contexto de referencia. La pregunta del usuario se transmite junto con ellos, y una instrucción al modelo, descrita en la siguiente sección, le indica qué papel debe desempeñar y cómo utilizar el material.

Paso 6: transmitir la respuesta en tiempo real

El texto generado vuelve a través del punto de conexión en tiempo real al que se conectó inicialmente el cliente, entregándose en pequeñas porciones en lugar de una única respuesta que bloquee la interacción. El usuario puede ver cómo se forma la respuesta en tiempo real.

En resumen: vectorizar la consulta, recuperar información de forma amplia, filtrarla a través de tres etapas, completar las partes faltantes, dar instrucciones al modelo y transmitir su salida. Ninguna etapa es excepcional; la calidad proviene de una transición limpia entre las etapas y de asignarle a cada una una responsabilidad específica.

Diseño de la instrucción: formato, modelo y tono

Para cuando se elabora la instrucción, los problemas difíciles de recuperación ya han sido resueltos: se han encontrado los fragmentos adecuados, filtrado y vuelto a combinar. Lo que queda es igual de propenso a errores: presentar ese material de manera que el modelo genere una buena respuesta, y no solo una técnicamente correcta.

Escribir la instrucción en Markdown

El propio prompt está escrito en Markdown. De nuevo, la razón es práctica: los modelos han visto grandes cantidades de contenido en Markdown en documentación, archivos README y textos técnicos, por lo que las instrucciones en un formato familiar se procesan de manera más fiable que aquellas con una estructura personalizada que el modelo debe decodificar. Los encabezados separan las secciones del prompt, el contexto recuperado queda claramente delimitado de las instrucciones circundantes, y cualquier contenido recompuesto a partir de partes separadas lleva un marcador visible, lo que permite al modelo distinguir “una idea continua formada por piezas” del texto recuperado habitual.

Elegir un modelo más pequeño y rápido para la síntesis

El modelo que escribe la respuesta final es uno más pequeño y rápido, en lugar del de mayor tamaño disponible. Esto parece contraintuitivo hasta que se observa la tarea que realmente realiza. No se le pide que derive nada desde cero, recuerde detalles poco comunes ni compense por conocimientos faltantes; el trabajo más pesado ya se realizó anteriormente, durante la recuperación y filtrado de información. Su tarea restante es tomar un contexto cuidadosamente seleccionado y bien organizado para convertirlo en una respuesta clara, rápida y con el tono adecuado.

Esa es una tarea de síntesis. Cuando el contexto ya está definido, un modelo compacto se acerca en calidad de respuesta a uno mucho más grande, al mismo tiempo que responde más rápido y cuesta mucho menos. La capacidad de razonamiento de un modelo más grande merece la pena cuando este debe resolver algo. Tiene mucho menos valor cuando la respuesta ya está disponible y la tarea consiste en explicarla bien. El equilibrio depende de la calidad de la recuperación de información: cuanto más débil sea el contexto, mayor importancia adquiere la capacidad del modelo más grande para manejar la ambigüedad, lo cual es otra razón para invertir en las etapas de filtrado.

Anatomía intencionada del prompt

El prompt del sistema sigue una estructura fija en lugar de ser improvisado:

• Rol. Comienza indicando al modelo qué tipo de asistente es y en qué área trabaja, de modo que el tono y las suposiciones se establecen desde la primera línea.

Tarea. Se indica explícitamente el trabajo: leer el contexto obtenido y responder estrictamente a partir de él, sin recurrir al conocimiento general ni a conjeturas, incluso cuando la respuesta parezca obvia.

Confianza y lagunas. Un breve preámbulo establece cuán seguras o cautelosas deben sonar las respuestas y qué hacer cuando el contexto realmente no contiene la respuesta: decirlo claramente en lugar de inventar algo.

Tono y estilo. La formalidad, la longitud típica de las respuestas y si se debe comenzar con la respuesta directa o ir construyéndola gradualmente están todos especificados en lugar de dejarse implícitos.

Nada se deja al criterio por defecto del modelo sobre cómo debe sonar un asistente útil. Cada comportamiento está detallado, al igual que cuando se integra a un nuevo compañero explicándole las normas de comunicación del equipo antes de asignarle cualquier tarea.

La ventaja es contar con un asistente que responde con confianza cuando cuenta con fundamentos, admite abiertamente cuando no los tiene, y mantiene una voz consistente en cada conversación. Esa consistencia no proviene del modelo, sino de la instrucción que se le proporciona.

Ruteo por intención: fragmentos regulares y fragmentos de pantalla

Las preguntas que se parecen pueden solicitar cosas muy diferentes. Una pregunta como “¿Cómo se calcula el precio en este flujo de trabajo?” es conceptual y busca una explicación. Otra similar a “¿Qué campo en esta pantalla indica el precio?” es de tipo navegacional y requiere un campo, botón o área específica de la interfaz. Ambas pueden extraer información de la misma sección de la documentación, pero las respuestas ideales apenas tienen nada en común. Tratarlas de la misma manera conlleva dar una explicación conceptual a quien solo necesitaba conocer la ubicación, o, peor aún, describir un elemento de la interfaz de forma abstracta cuando lo que el usuario necesitaba era su ubicación exacta.

Separar los conocimientos en el momento de la captura

La distinción se establece a nivel de bloque, no solo en el momento de responder. Junto con los bloques de documentación en prosa habituales, existe una segunda categoría que contiene contenido que describe las pantallas y sus campos: cómo se llama cada campo, qué función cumple y dónde se encuentra en relación con los demás campos de la misma pantalla. Estos no se etiquetan posteriormente; la clasificación tiene lugar mientras se ingiere el contenido, de modo que para cuando llega una pregunta ya existen dos conjuntos de conocimiento claramente separados en lugar de un único montón sin diferenciar.

Elegir la estrategia de respuesta en el momento de la consulta

Cuando llega una pregunta, se evalúa a qué tipo de bloque en realidad está solicitando: documentación conceptual o detalles específicos de pantallas y campos. Esa clasificación determina qué bloques se priorizan durante la recuperación de información y qué respuesta recibe el modelo:

• Una pregunta orientada a la pantalla recibe una indicación diseñada para lograr precisión respecto a los elementos de la interfaz: literal, específica y centrada exactamente en dónde y qué.
• Una pregunta conceptual recibe una indicación orientada a la explicación: más amplia y dispuesta a relacionar ideas.

El proceso de recuperación y el modelo generador son los mismos en ambos casos; solo cambia la forma de responder, elegida según las necesidades de la pregunta en lugar de forzar todas las respuestas a seguir un mismo modelo genérico.

Esto es más importante de lo que parece. Un asistente con un único estilo de respuesta termina sonando genérico, por mejor que sea su capacidad de recuperación de información. Reconocer la intención, no solo el tema, es lo que hace que el asistente parezca prestar atención a lo que realmente se preguntó. Si adopta este enfoque, mantenga una solución de respaldo para las preguntas ambiguas; por ejemplo, opte por la postura conceptual e incluya todos los fragmentos de pantalla que coincidan fuertemente, de modo que una clasificación errónea se resuelva de manera adecuada en lugar de generar un estilo de respuesta incorrecto.

Mantener el control de la memoria

Una recuperación y generación cuidadosas son inútiles si el servicio agota gradualmente su memoria. Un proceso que incrusta texto, mantiene fragmentos en memoria, compila instrucciones y emite resultados de forma repetida e incluso simultánea, acumula presión en la memoria silenciosamente a menos que algo la gestione activamente. Los objetos necesarios solo para una solicitud tienden a permanecer más tiempo del necesario cuando nadie se ocupa de eliminarlos.

Por lo tanto, la limpieza no se deja al azar. En los límites naturales, como el final de una solicitud o la finalización de un lote de procesamiento, la memoria se recupera explícitamente en lugar de confiar en que se libere con el tiempo. En la práctica, eso significa eliminar las referencias a objetos intermedios grandes, borrar los cachés por solicitud y, en el caso de modelos alojados localmente, liberar toda la memoria que el entorno de ejecución mantiene reservada.

Se trata de un trabajo poco glamuroso que nunca aparece en una demostración y solo se nota cuando falta: un servicio cuyo rendimiento empeora con el tiempo de funcionamiento prolongado, en lugar de responder a su milésima consulta tan rápido como a la primera. Lograrlo correctamente depende menos de una ingeniería inteligente que de la disciplina, tratando la memoria como algo que cada etapa gestiona y no como algo que el sistema operativo se encargará seguramente. Observar el consumo de memoria durante una prueba prolongada, y no solo en un breve benchmark, es la forma más sencilla de confirmar que esa disciplina funciona.

Puntos clave

La base descrita aquí es un pipeline RAG completo y sólido: particionamiento consciente de la estructura, incrustación segura de tokens, filtrado en múltiples etapas, reensamblaje de las secciones divididas, una instrucción estructurada que mantiene al modelo honesto sobre lo que sabe, y entrega en tiempo real. Las decisiones más importantes son estas:

• Mantenga los documentos en un formato de texto plano estructurado y resuelva las imágenes y otros medios únicamente en el momento de la renderización.
• Divida el contenido siguiendo la estructura de encabezados y adjunte pistas de navegación, etiquetas de tipo e identificadores estables a cada sección.
• Añada una segunda pasada que aplique el límite de tokens del modelo de incrustación con un margen de seguridad, etiquetando las partes y permitiendo pequeñas superposiciones.
• Incorpore siempre las consultas con el mismo modelo utilizado en la fase de ingestión, y vuelva a incrustar todo cuando ese modelo cambie.
• Recupere una gran cantidad de resultados y luego filtrelos mediante un umbral de similitud, un reordenador por lectura en pares y un límite final estricto.
• Vuelva a combinar las secciones divididas antes de enviar la solicitud, para que el modelo nunca tenga que procesar fragmentos sin marcar.
• Deje que un modelo más pequeño y rápido realice la síntesis una vez que la fase de recuperación haya hecho el trabajo duro, especificando claramente su función, tarea, manejo de lagunas y tono.

Clasifique la intención, no solo el tema, y asigne a cada tipo de pregunta su propia estrategia de respuesta.

Recupere la memoria según sea necesario y en los límites de los lotes para que el servicio mantenga su velocidad incluso después de horas de funcionamiento, tal como lo hacía al inicio.

Cada una de estas opciones es modesta por sí sola. Juntas, forman un sistema cuyas respuestas son fundamentadas, coherentes y rápidas, y le brindan una base estable para técnicas de recuperación más ambiciosas en el futuro.

Lecturas relacionadas

• Más allá de Top-K: Límites de relevancia, búsqueda híbrida y reevaluación en RAG — Entienda por qué una base de datos vectorial junto con un LLM no constituye un sistema RAG listo para producción, y cómo el particionamiento, los límites de similitud, la búsqueda híbrida, la reevaluación y la evaluación cierran esa brecha.
• Por qué el RAG en producción se está moviendo más allá de las bases de datos vectoriales dedicadas — Explora por qué las bases de datos vectoriales independientes están perdiendo terreno en los sistemas RAG en producción y cómo la recuperación híbrida, el filtrado y las capas de datos unificadas están reconfigurando toda la estructura.
• Mapeo de RAG: etapas del pipeline, componentes esenciales y el panorama de variantes — Entiende cómo funciona la generación mejorada por recuperación de información de principio a fin, qué componentes necesita un sistema RAG y cómo las numerosas variantes de RAG encajan dentro de un mismo esquema.