Índice de contenidos
Utilice un LLM de contexto largo cuando un conjunto delimitado de documentos quepa cómodamente dentro del contexto utilizable del modelo y la tarea requiera una visión amplia de la fuente. Utilice RAG cuando la fuente de conocimiento sea extensa, cambie con frecuencia o admita muchas consultas repetidas. Un diseño híbrido suele adaptarse bien a bases de código y bases de conocimiento empresariales porque la recuperación reduce el espacio de búsqueda mientras que un contexto más amplio preserva la información circundante para el razonamiento.
¿Qué es un LLM de contexto largo?
Un LLM de contexto largo puede procesar una gran cantidad de tokens de Input en una sola solicitud. Estos tokens incluyen instrucciones, historial de conversaciones, material de origen y el Output esperado. Por lo tanto, una aplicación puede proporcionar documentos completos o conjuntos sustanciales de documentos sin necesidad de crear primero una canalización de recuperación.
Sin embargo, que un documento quepa en la ventana de contexto no garantiza que el modelo vaya a utilizar cada parte de manera fiable. El estudio Lost in the Middle descubrió que el rendimiento podía variar según el lugar donde aparecía la información relevante, siendo la información situada en medio de inputs extensos a menudo más difícil de utilizar. Sigue siendo necesario realizar pruebas específicas para cada tarea.
Los límites de contexto también varían según el modelo y el despliegue alojado. Compruebe la longitud del contexto, el Output máximo y los inputs admitidos en el catálogo de modelos de SiliconFlow. Revise la documentación de la API y la configuración de la cuenta por separado para conocer los límites de uso actuales.
Cómo gestiona RAG grandes fuentes de conocimiento
La generación aumentada por recuperación separa el almacenamiento de la generación. Durante la ingesta, la aplicación analiza los documentos, los divide en unidades que permiten búsquedas, crea un índice y adjunta metadatos de origen. En el momento de la consulta, envía solo la evidencia más relevante al LLM.
El artículo original sobre generación aumentada por recuperación combinaba el conocimiento del modelo con memoria externa. Los sistemas de producción pueden utilizar búsqueda vectorial, búsqueda por palabras clave, filtros de metadatos o una combinación de estos métodos.
Una canalización habitual tiene el siguiente aspecto:
Analizar, limpiar y dividir los documentos de origen.
Crear un índice que permita búsquedas con metadatos de origen.
Recuperar y reclasificar candidatos para cada consulta.
Pedir al LLM que responda a partir de la evidencia seleccionada.
En SiliconFlow, los desarrolladores pueden utilizar la API de embeddings para la recuperación semántica y la API de rerank para reordenar los candidatos. La aplicación sigue siendo responsable del análisis sintáctico, el almacenamiento, el control de acceso, la lógica de recuperación y el seguimiento del origen.
Contexto largo frente a RAG: diferencias clave
La principal diferencia radica en cómo cada enfoque selecciona la información enviada al modelo.
Factor de decisión | Contexto largo | RAG |
|---|---|---|
Material enviado al LLM | La mayoría o la totalidad de los documentos seleccionados | Pasajes o documentos mejor clasificados |
Tamaño del corpus | Limitado por la ventana de contexto utilizable | Puede buscar en un corpus mucho más grande que un solo prompt |
Principal riesgo de calidad | Los detalles relevantes reciben muy poca atención | No se recupera la evidencia relevante |
Razonamiento entre documentos | Sólido cuando toda la evidencia requerida cabe y permanece utilizable | Depende de recuperar cada pasaje necesario |
Proceso de actualización | Proporcionar la versión más reciente del documento en la siguiente solicitud | Actualizar o sustituir las entradas del índice afectadas |
Uso de tokens por consulta | Normalmente mayor | Normalmente menor después de la ingesta |
Esfuerzo de ingeniería inicial | Menor para un flujo de trabajo básico | Mayor porque se deben construir la ingesta y la recuperación |
Citas de fuentes | Requiere una correspondencia fiable entre el contenido del prompt y las fuentes | Más fácil cuando se preservan los metadatos de los pasajes |
Control de acceso | Filtrar documentos antes del ensamblaje del prompt | Filtrar los resultados de recuperación antes del ensamblaje del prompt |
Mejor adecuación | Análisis delimitado a nivel de documento completo | Cargas de trabajo de conocimiento extensas, repetidas o cambiantes |
Ambos diseños necesitan validación de fuentes, fechas de versión y una vía clara para indicar la falta de respuesta. Un prompt largo puede contener documentos contradictorios, mientras que RAG puede recuperar la versión incorrecta u omitir un pasaje decisivo.
Cuándo funciona mejor el contexto largo
Utilice el contexto largo cuando:
El material quepa cómodamente dentro del rango de trabajo probado del modelo.
La tarea requiera resúmenes holísticos, comparaciones, cronología o estructura.
Las preguntas sean difíciles de predecir antes de que el usuario las envíe.
El volumen de consultas sea lo suficientemente bajo como para que reenviar la fuente siga siendo asequible.
El equipo necesite un prototipo rápido antes de construir un índice.
Por ejemplo, un revisor puede necesitar un contrato completo para conectar un término definido con una excepción posterior. Deje espacio para las instrucciones y el Output, y pruebe la evidencia situada cerca del principio, el medio y el final de la fuente.
Cuándo funciona mejor RAG
Utilice RAG cuando:
La base de conocimiento sea demasiado grande para una sola solicitud al modelo.
La documentación de productos, las políticas, los tickets o los registros cambien periódicamente.
Muchos usuarios formulen preguntas factuales concretas sobre el mismo corpus.
Las respuestas necesiten citas rastreables a fuentes aprobadas.
Diferentes usuarios puedan acceder a distintos documentos o inquilinos (tenants).
La latencia por consulta y el coste en tokens deban mantenerse bajo control a medida que el corpus crece.
La calidad de RAG depende de la exhaustividad (recall) de la recuperación. Un análisis sintáctico deficiente, fragmentos arbitrarios, metadatos débiles o un modelo de Embedding inadecuado pueden ocultar la evidencia correcta. La búsqueda por palabras clave puede ayudar con cadenas exactas como códigos de error y nombres de funciones, mientras que la reclasificación (reranking) puede mejorar el orden de los candidatos.
Comparación de precisión, latencia y coste de tokens
No hay un ganador universal en cuanto a precisión. Una comparación de 2024 entre RAG y LLMs de contexto largo concluyó que el contexto largo generalmente ofrecía un mejor rendimiento cuando disponía de recursos suficientes, mientras que RAG era sustancialmente más rentable. El método híbrido del estudio comenzaba con RAG y escalaba cuando era necesario. Los resultados seguirán variando según el corpus, el modelo y la configuración de evaluación.
Métrica | El contexto largo tiende a beneficiar cuando | RAG tiende a beneficiar cuando |
|---|---|---|
Precisión | Toda la evidencia cabe y las preguntas requieren un contexto global | La recuperación tiene una exhaustividad alta y las preguntas dependen de unos pocos pasajes |
Latencia | El conjunto de documentos es modesto y la sobrecarga de recuperación aportaría poco valor | Un corpus grande se puede reducir a un pequeño conjunto de evidencias |
Coste de tokens | El volumen de consultas es bajo o el Input es pequeño | El mismo corpus grande admite muchas consultas |
El coste de tokens se puede estimar antes de la implementación. Sea D los tokens de Input del documento completo, K los tokens de contexto recuperados, Q los tokens de instrucción y consulta, y O los tokens de Output. Sean P_in y P_out los precios del modelo por millón de tokens de Input y Output.
Coste por consulta con contexto largo:
[(D + Q) ÷ 1.000.000] × P_in + [O ÷ 1.000.000] × P_out
Coste de generación por consulta con RAG:
[(K + Q) ÷ 1.000.000] × P_in + [O ÷ 1.000.000] × P_out + coste de recuperación y reclasificación
RAG también conlleva costes iniciales de análisis, Embedding, almacenamiento y actualización. En una consulta hipotética con 200.000 tokens de documentos completos y 8.000 tokens recuperados, la vía de contexto largo envía 25 veces más tokens de documentos cuando ambas vías usan el mismo generador y no se aplica ningún descuento por Input. El Output, la recuperación, la reclasificación y la calidad de las respuestas siguen afectando al coste final.
Utilice las tarifas actuales específicas de cada modelo en los precios de SiliconFlow y calcule el coste por respuesta aceptada, no solo el coste por llamada a la API. Una respuesta barata que no pasa la verificación o que requiere otra consulta puede costar más en el flujo de trabajo final.
¿Qué ocurre cuando los documentos cambian continuamente?
Una aplicación de contexto largo puede utilizar información actualizada de inmediato cuando carga la fuente vigente para cada solicitud. El generador de prompts debe seleccionar la última versión aprobada y evitar Text extraído obsoleto o cachés de la aplicación. Enviar repetidamente fuentes extensas puede resultar costoso con un volumen mayor.
RAG admite actualizaciones selectivas, pero mantener los datos actualizados requiere un mantenimiento activo. La canalización debe eliminar fragmentos obsoletos, generar embeddings del contenido modificado, actualizar metadatos e invalidar cachés relacionadas. La recuperación puede devolver contenido desactualizado hasta que finalice este trabajo.
Entre los controles útiles se incluyen:
IDs estables de documentos y fragmentos
Metadatos de versión de origen y última modificación
Reindexación incremental para el contenido modificado
Gestión de eliminaciones para páginas suprimidas
Pruebas de actualización que consultan datos modificados recientemente
Registros que muestran qué versión del documento respaldó cada respuesta
Para fuentes que cambian rápidamente, RAG suele escalar mejor porque el sistema puede procesar únicamente el material afectado. Los equipos deben medir el retraso entre la actualización de una fuente y su disponibilidad en la recuperación.
¿Pueden funcionar juntos el contexto largo y RAG?
Sí. Un sistema híbrido recupera un subconjunto relevante y utiliza una ventana de contexto más grande para obtener material circundante más rico. Evita enviar toda la base de conocimiento al tiempo que preserva más contexto del que proporcionan los fragmentos aislados.
Los patrones híbridos habituales incluyen:
Ampliar los fragmentos recuperados: buscar con fragmentos compactos e incluir después sus secciones o pasajes cercanos.
Leer los documentos recuperados al completo: seleccionar unos pocos archivos candidatos e introducirlos en el prompt de contexto largo.
Enrutar por consulta: utilizar RAG para búsquedas de hechos y contexto largo para la síntesis de documentos completos.
Escalar cuando la evidencia sea incompleta: ampliar la recuperación o cargar los documentos candidatos completos.
En el caso del código, la búsqueda semántica o de símbolos puede localizar archivos mientras que el contexto ampliado incluye funciones relacionadas, tipos, pruebas, configuración y puntos de llamada. El modelo obtiene dependencias útiles sin procesar todo el repositorio en cada solicitud.
Cómo elegir para documentos, bases de código y bases de conocimiento
Carga de trabajo | Punto de partida recomendado | Por qué |
|---|---|---|
Un PDF o contrato largo | Contexto largo | Preserva las relaciones en todo el documento y evita la configuración de recuperación |
Un conjunto reducido de informes comparados ocasionalmente | Contexto largo o híbrido | Los inputs completos facilitan la comparación; la recuperación puede seleccionar los informes relevantes |
Un repositorio de software grande | Híbrido | La recuperación encuentra archivos y símbolos; el contexto ampliado preserva las dependencias |
Documentación de atención al cliente | RAG | Muchas preguntas repetidas se dirigen a una colección de fuentes cambiante |
Base de conocimiento empresarial multiinquilino (multi-tenant) | RAG con filtros de metadatos | La recuperación puede limitar los candidatos antes del ensamblaje del prompt |
Archivo de investigación con síntesis entre varios artículos | Híbrido | La recuperación reduce el archivo; el contexto largo permite el razonamiento multifuente |
Consulta de políticas con alto volumen | RAG | Conjuntos reducidos de evidencias reducen los tokens de Input repetidos y facilitan las citas |
Antes de comprometerse, elabore un conjunto de pruebas con búsquedas directas, preguntas entre documentos, evidencias ocultas, datos actualizados, preguntas sin respuesta y contenido restringido. Utilice el mismo modelo de generación y formato de respuesta para cada vía.
Mida la corrección, la precisión de las citas, la exhaustividad de la recuperación en k, el comportamiento ante la falta de respuesta, la latencia p50 y p95, el uso de tokens y el coste por respuesta aceptada. Mantenga la coherencia del modelo de generación, las preguntas, el formato de respuesta y los criterios de aceptación en todas las pruebas.
En SiliconFlow, comience seleccionando un modelo adecuado del catálogo y estimando los costes de Input y Output para la ruta de contexto largo. Luego, cree una segunda ruta con las APIs de Embedding y reranking. Ejecute ambas a través de la misma API de Chat completions para identificar qué diseño cumple con los objetivos requeridos de calidad, latencia y coste.
Preguntas frecuentes
¿Requiere RAG una base de datos vectorial?
No. Un sistema RAG puede recuperar evidencia con búsqueda por palabras clave, una base de datos relacional, un motor de búsqueda, consultas de grafos de conocimiento o una combinación de métodos. La búsqueda vectorial es popular para la coincidencia semántica, pero la capa de recuperación debe adaptarse al contenido y a los tipos de consulta.
¿Puede un LLM de contexto largo leer un PDF directamente?
Depende del modelo y de la interfaz del proveedor. Los flujos de trabajo de solo Text deben extraer el texto primero, mientras que los flujos de trabajo de tipo Multimodal pueden aceptar archivos o páginas renderizadas. Las páginas escaneadas necesitan OCR, y las tablas o diseños complejos aún requieren validación tras la extracción.
¿Debería el ajuste fino (fine-tuning) sustituir a RAG para el conocimiento de la empresa?
No. El ajuste fino es más adecuado para el comportamiento, el estilo, el formato o los patrones de tareas que para datos que cambian frecuentemente. RAG mantiene el conocimiento de las fuentes fuera de los pesos del modelo, lo que facilita la gestión de las actualizaciones y la atribución de fuentes.
¿Cómo deben los equipos elegir el tamaño de fragmento (chunk size) en RAG?
Comience con los límites naturales de los documentos, como encabezados, párrafos, funciones o secciones de políticas. Pruebe varios tamaños de fragmento con preguntas reales y mida la exhaustividad de la recuperación. Añada solapamiento solo cuando la información importante cruce habitualmente los límites de los fragmentos.
¿Cómo pueden los equipos identificar si un error fue causado por la recuperación o por la generación?
Proporcione al generador los pasajes correctos a partir de un conjunto de pruebas revisado. Si responde correctamente, es probable que la recuperación o el ensamblaje del contexto hayan causado el fallo original. Si la respuesta sigue siendo incorrecta, inspeccione el prompt, el modelo de generación y las restricciones de Output.
