Pipeline RAG con chunking híbrido y retrieval multi-query

Un pipeline de embeddings que convierte la documentación de cada cliente en una base de conocimiento fundamentada para un chatbot LLM.

Rol: Software Engineer — diseño y construcción del pipeline
Período: 2024 — Actualidad
Empresa: Agencia de marketing digital (confidencial)

Hybrid

chunking: segmentación semántica + overlap

N×

variantes de consulta por pregunta para mejor recall

Per-client

bases de conocimiento aisladas en Qdrant

#Contexto

La agencia ofrece a cada cliente un chatbot capaz de responder preguntas sobre su marca, productos y documentación técnica. Los widgets de chatbot genéricos alucinaban o daban respuestas genéricas — el valor estaba en fundamentar las respuestas en el material propio de cada cliente, y el conocimiento de cada cliente debía permanecer aislado del resto.

#Problema y restricciones

Los documentos de los clientes son heterogéneos: PDFs, brand books, manuales técnicos, páginas web — el chunking de tamaño fijo destruye la estructura semántica.
Los usuarios formulan preguntas distinto a como los documentos formulan respuestas — el retrieval de consulta única pierde chunks relevantes (bajo recall).
Multi-tenant por diseño: los embeddings del cliente A nunca deben aparecer en el chatbot del cliente B.

#Arquitectura

Ingesta offline (arriba) y retrieval en tiempo de consulta (abajo) por colección de cliente.

Los documentos fluyen por un pipeline de ingesta: Unstructured parsea cada archivo en segmentos semánticamente coherentes (títulos, párrafos, tablas), que se re-chunkean con overlap para que ninguna idea quede partida en un límite. Cada chunk se embebe con embeddings de OpenAI y se inserta en una colección de Qdrant por cliente. Al consultar, la pregunta del usuario primero es reescrita por un LLM en varias variantes semánticas (multi-query), cada variante recupera sus propios top-k chunks, y la unión — deduplicada y rankeada — hidrata la ventana de contexto del agente antes de que componga una respuesta fundamentada en la documentación del cliente.

chat.client-brand.com

What's the return window for outlet items?

Outlet items can be returned within 15 days with the original receipt, per the returns policy.

sources:brand-guide.pdf · p.12returns-policy.pdf · p.3product-manual.pdf · p.41

* Interfaz recreada con datos sintéticos — el sistema productivo contiene datos confidenciales de clientes.

#Decisiones clave y tradeoffs

01Chunking híbrido sobre división de tamaño fijo

Decisión: Segmentar documentos semánticamente con Unstructured primero, y luego aplicar re-chunking con overlap encima.
Alternativas: Ventanas de tamaño fijo por caracteres/tokens (el default en la mayoría de tutoriales de RAG).
Por qué: Los límites semánticos mantienen las ideas completas — un párrafo sobre política de devoluciones permanece unido — mientras el overlap protege contra pérdida de contexto en los bordes. La calidad del retrieval mejoró visiblemente con documentos reales de clientes.
Costo de equivocarse: La ingesta es más lenta y cuesta más (parsing de Unstructured) que la división simple — aceptable porque la ingesta es offline e infrecuente.

02Retrieval multi-query para recall

Decisión: Reescribir cada pregunta del usuario en varias variantes semánticas con un LLM, recuperar para cada una y fusionar resultados antes de hidratar el contexto.
Alternativas: Búsqueda vectorial de consulta única, o búsqueda híbrida BM25 + vectores.
Por qué: La brecha de vocabulario entre 'cómo pregunta el usuario' y 'cómo lo dice el documento' era la fuente principal de respuestas malas. Las variantes de consulta atacan exactamente ese modo de fallo con una llamada LLM extra — barato comparado con una respuesta incorrecta.
Costo de equivocarse: La latencia por pregunta aumenta (una llamada de reescritura + N llamadas de retrieval) y más chunks en contexto significan más tokens de prompt.

03Colecciones Qdrant por cliente

Decisión: Aislar la base de conocimiento de cada cliente en su propia colección de vectores en vez de una colección compartida con filtros de metadata.
Alternativas: Una sola colección con filtro de client_id en cada consulta.
Por qué: El aislamiento físico hace que la fuga entre clientes sea estructuralmente imposible, no solo dependiente de filtros — un bug en la lógica de filtros jamás puede filtrar documentos de un cliente al chatbot de otro.
Costo de equivocarse: Más colecciones que administrar y migrar; las operaciones por colección (re-indexado, backups) se multiplican a medida que crecen los clientes.

#Resultados

Grounded

respuestas fundamentadas en la documentación propia de cada cliente

Higher recall

mayor recall con multi-query vs baseline de consulta única

Zero

fugas entre clientes por construcción

#Qué haría diferente

Construiría primero el harness de evaluación — ajustamos chunking y retrieval a ojo antes de tener un set dorado de preguntas por cliente, y una pequeña suite de evaluación habría convertido 'parece mejor' en recall medido desde el día uno. También versionaría la configuración del pipeline de embeddings por cliente; re-ingerir con una nueva estrategia de chunking hoy implica reconstruir la colección completa.

#Stack

OpenAIQdrantUnstructuredNode.jsTypeScriptLangChainPostgreSQLRAG