Ganancias:
- Diseño de los componentes y el flujo de datos de un asistente RAG empresarial de extremo a extremo
- Combinando datos de múltiples fuentes (wiki, ticket, PDF, base de datos) en un solo asistente
- Tome decisiones arquitectónicas para escalabilidad, almacenamiento en caché y latencia
En unidades anteriores, aprendimos las partes una por una: incrustación, base de datos vectorial, fragmentación, recuperación. Ahora combinemos estos y construyamos una arquitectura de extremo a extremo de un asistente que se comunique con los datos de su propia empresa. El objetivo es que un empleado pregunte: "¿Cuál es nuestra política de licencias?" Un sistema donde las personas pueden hacer preguntas, las respuestas se basan en documentos internos reales, citas y combinan múltiples fuentes de datos. Esta unidad procesa toda la arquitectura, el flujo de datos y las decisiones a nivel de producción.
Componentes de extremo a extremo
Un asistente RAG corporativo consta de dos líneas separadas. La línea de indexación (fuera de línea) prepara los datos; La línea de consulta (en línea) responde a la pregunta.
Componentes de la línea de indexación:
- Conectores: conectores que extraen datos de fuentes: wiki, sistema de tickets, almacén de archivos, base de datos, correo electrónico.
- Normalización: conversión de diferentes formatos (PDF, HTML, DOCX) a texto limpio; limpieza de encabezado/pie de página.
- Chunking + metadatos: Chunking y etiquetado (fuente, fecha, autoridad).
- Incrustar + cargar: escribir vectores y metadatos en la base de datos de vectores.
Componentes de la canalización de consultas:
- Preprocesamiento de consultas: reescritura, descentralización.
- Recuperación: Búsqueda híbrida + filtro de metadatos + reclasificación.
- Creación rápida: colocar contexto + pregunta + instrucciones en la plantilla.
- Generación: Respuesta fundamentada (contextual) del modelo + fuentes.
- Postprocesamiento: formato de citas, control de seguridad, registro.
Consejo: separe físicamente la línea de indexación de la línea de consulta. La indexación es lenta y periódica (se ejecuta en lotes durante la noche); La línea de investigación debe ser ligera e inmediata. Mezclar las dos líneas obliga a un procesamiento intenso mientras el usuario espera.
Visualizando el flujo de datos
[INDEXACIÓN - fuera de línea]Recursos → Normalizar → Fragmento+Metadatos → Incrustar → Vector DB (wiki, ticket, PDF, DB)[CONSULTA - en línea]Pregunta de usuario → Preprocesamiento → Recuperación (híbrido+filtro+reclasificación) → Mensaje (contexto+pregunta+instrucción) → Modelo → Respuesta+Fuente → Usuario
Combinación de datos de múltiples fuentes
En las empresas reales, la respuesta no se detiene en un solo lugar. "¿Cómo emitir un reembolso a un cliente?" La respuesta a la pregunta la puedes encontrar tanto en el artículo de ayuda (procedimiento), en el historial de tickets (ejemplos reales), como en el PDF de la póliza (reglas). El asistente debe buscarlos todos en un grupo.
Punto crítico: al combinar recursos en un único almacén de vectores, cada fragmento debe contener los metadatos `source_tour`. Así podrás buscarlas todas y filtrarlas si es necesario, como por ejemplo "traer sólo políticas oficiales". Además, diferentes fuentes tienen diferentes niveles de confiabilidad: política oficial > artículo de ayuda > nota de ticket de un empleado. Puede especificar esta prioridad en la reclasificación o en el mensaje.
Fuente
tipo de contenido
confianza
Frecuencia de actualización
PDF de política
regla oficial
alto
mensual
Artículo de ayuda
Procedimiento
medio-alto
semanal
Historial de entradas
muestra real
medio
Continuo
wiki
Nota mixta/actual
variable
Continuo
Escalabilidad, caché y latencia
En la producción destacan tres cuestiones. Latencia: La experiencia se deteriora cuando el usuario espera más de 2 segundos. Solución: muestre la respuesta en forma de transmisión: se vierte en la pantalla a medida que escribe el modelo. Caché: para preguntas frecuentes y contextos repetitivos, el caché aumenta la velocidad y reduce los costos. Escala: a medida que aumenta el número de usuarios, es necesario poder escalar la recuperación y modelar las llamadas de forma horizontal.
Regla general en lo que respecta al costo: el paso más costoso suele ser la cantidad de tokens que van al modelo más grande. Por lo tanto, reducir el contexto a 4 partes buenas mediante una nueva clasificación mejora tanto la calidad como el costo. Un diseño común es utilizar un modelo más pequeño/rápido para una clasificación o enrutamiento simple, y un modelo más potente para la respuesta final (por ejemplo, claude-opus-4-8).
Precaución: No configure la indexación como "hazlo una vez, olvídalo". Los documentos se modifican, eliminan y agregan. Establezca una estrategia de reindexación: detecte documentos modificados y reprocéselos solo. El índice obsoleto produce una respuesta que parece actual pero es incorrecta.
Arquitectura débil / Arquitectura fuerte
Débil (guión único, todo mezclado):
Cuando el usuario pregunta: leer los documentos en ese momento, triturarlos, incrustarlos, buscarlos, responderlos.# Problema: toda la indexación se repite para cada pregunta; segundos de retraso, # sin separación de fuentes, sin filtro, sin actualización.
Potente (tuberías divididas + metadatos + caché + streaming):
Indexación: ejecución por lotes por la noche, actualización de documentos modificados. Consulta: línea ligera: preprocesamiento → recuperación híbrida + filtro → reclasificación → solicitud → modelo (transmisión) → cita → registro. Las preguntas frecuentes y la fuente se almacenan en caché.
Tres mini estuches
Caso 1: Línea confusa, gran retraso. Una startup escribió un script que reprocesa archivos PDF con cada pregunta; Cada respuesta tomó un promedio de 11 segundos. Cuando se separó la línea de indexación y los datos se transfirieron previamente al almacén de vectores, el tiempo de consulta disminuyó a 1,3 segundos y con la transmisión, la "primera palabra" apareció en 400 ms.
Caso 2: Demasiados recursos, prioridad incorrecta. Un asistente de soporte le dio la misma importancia al PDF de la política y a las notas del ticket antiguo; En ocasiones, el modelo presentaba como regla oficial la calificación incorrecta de un empleado de hace dos años. Cuando se agregaron al mensaje los metadatos source_tour y la instrucción "considerar la política oficial en caso de conflicto", los errores de prioridad falsa se redujeron en un 89%.
Caso 3: índice obsoleto. Un asistente de RR.HH. estaba trabajando con un índice que no se actualizaba desde hacía 3 meses; La política de licencias ha cambiado, pero el asistente hablaba de los viejos tiempos. Cuando se instaló la actualización diaria, que detecta archivos modificados, la tasa de respuesta actual aumentó del 70% al 99%.
Errores comunes
- Combinación de líneas de consulta e indexación: el procesamiento pesado se realiza mientras el usuario espera; el retraso explota.
- No poner el tipo de fuente en los metadatos: sin priorización ni filtrado; La fuente no confiable parece ser oficial.
- No establecer una estrategia de actualización: el índice se vuelve obsoleto; Se producen respuestas erróneas que parecen actuales.
- Saltar transmisión: el usuario mira una pantalla en blanco; El retraso percibido se vuelve alto.
- Usar el modelo más grande en cada paso: el costo aumenta innecesariamente; Deje la dirección al modelo más pequeño.
En resumen
- El asistente RAG corporativo consta de dos líneas separadas: indexación fuera de línea y consulta en línea; separarlos fisicamente.
- Indexación = conector + normalizar + fragmento/metadatos + incrustar/cargar; consulta = preproceso + recuperación + aviso + generación + posproceso.
- Los datos de múltiples fuentes se combinan en un único repositorio, pero se conservan los metadatos de tipo fuente y la prioridad de confianza.
- La transmisión y el caché para la latencia, la limitación del contexto y la selección del modelo por costo son fundamentales.
- Sin volver a indexar, el índice queda obsoleto; Vuelva a procesar los documentos cambiantes con regularidad.
Tarea de aplicación
Dibuja un diagrama arquitectónico de un asistente para tu propio equipo. (1) Identifique al menos tres fuentes de datos reales y anote la necesidad de conector, la frecuencia de actualización y el nivel de confianza para cada una. (2) Dibuje las líneas de indexación y consulta por separado con un diagrama de cuadro de flechas. (3) "¿Dónde reduzco la latencia y el costo en este asistente?" Escriba al menos dos decisiones concretas a la pregunta. (4) Describa su estrategia de actualización en una oración: ¿qué recurso se reindexará y con qué frecuencia?
lista de verificación
- [] Puedo dibujar las líneas de consulta y de indexación por separado y con los componentes correctos.
- [] Puedo combinar datos de múltiples fuentes con tipo_fuente y prioridad de confianza.
- [] Puedo tomar decisiones de transmisión/caché para la latencia y selección de modelo por costo.
- [] Sé por qué una estrategia de reindexación es esencial.
- [] Tengo en cuenta que el paso más caro en mi arquitectura suele ser el token que va al modelo más grande.