9 · Un pipeline RAG completo
Únelo todo: ingerir docs → chunk → embeber → indexar → recuperar → construir un prompt fundamentado. Una pequeña clase conecta todo el flujo e imprime los mensajes exactos que recibiría un LLM real.
Un pipeline RAG tiene dos fases. INGESTA (offline, una vez por documento): cargar → chunk → embeber → guardar en un índice. CONSULTA (online, por petición): embeber la pregunta → recuperar top-k chunks → ensamblar una lista de mensajes fundamentada → llamar al modelo. Todo lo que aprendiste este capítulo es una etapa de esta línea de montaje.
Sin esto:
Sin ver el pipeline completo, las piezas quedan como hechos sueltos. Conectadas, puedes razonar de dónde vino una mala respuesta — mal chunking, recuperación fallida o un prompt descuidado — y arreglar la etapa correcta.
Ahora conectamos cada etapa del capítulo en un solo pipeline. Un sistema RAG tiene dos fases:
Ingesta (se hace offline, una vez por documento, cuando los datos cambian):
cargar documentos → chunk → embeber cada chunk → guardar (chunk, vector) en un índice
Consulta (se hace online, en cada petición del usuario):
embeber la pregunta → recuperar los top-k chunks más cercanos → construir un prompt fundamentado → llamar al modelo
La salida de la fase de consulta es una lista de mensajes — exactamente la misma forma [{role, content}, ...] de la lección 1, salvo que ahora el turno del usuario se envuelve con el contexto recuperado y una instrucción de "usa solo este contexto". Esa lista de mensajes es todo el punto: es lo que recibe un LLM real.
Abajo, una pequeña clase RAGPipeline une el chunking, un embed() determinista, un índice en memoria, la recuperación y el ensamblado del prompt. Ingerimos unos docs cortos, hacemos una pregunta e imprimimos los mensajes ensamblados. Donde un sistema real llamaría ahora al modelo, nuestro pipeline se detiene y te muestra el prompt — porque construir ese prompt correctamente es la ingeniería que tú controlas.
Python (in browser)
RAGPipeline: ingesta (chunk→embeber→guardar), luego consulta (embeber→recuperar→ensamblar). La lista de mensajes impresa es el prompt fundamentado que consumiría un modelo real.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
En producción cada etapa es un componente de librería, pero la línea de montaje es idéntica: un loader lee archivos, un splitter hace chunks, un vector store embebe + indexa, un retriever trae los top-k, y una chain mete los chunks en un prompt y llama al modelo. Lee la versión de LangChain de abajo — mapea cada línea de vuelta a un método de nuestro RAGPipeline.
El loader → splitter → vectorstore → retriever → chain de LangChain es exactamente nuestro RAGPipeline, un componente de librería por etapa.
En un pipeline RAG, ¿qué pasos pertenecen a la fase de ingesta OFFLINE en vez de la fase de consulta por petición?
- RAG tiene dos fases: ingesta (offline — cargar → chunk → embeber → indexar) y consulta (online — embeber pregunta → recuperar → construir prompt → generar).
- La salida de la fase de consulta es una lista de mensajes fundamentada — la misma forma {role, content} de la lección 1, con el contexto recuperado envolviendo la pregunta del usuario.
- Cada etapa del capítulo es un componente del pipeline (loader, splitter, vector store, retriever, chain); conocer las etapas te deja depurar una mala respuesta en el paso correcto.
Todo producto de 'chatea con tus docs' es exactamente este pipeline; LangChain y LlamaIndex son en su mayoría envoltorios ergonómicos sobre loader → splitter → vector store → retriever → chain.
Si lo quitas: Sin un modelo mental de extremo a extremo ajustas piezas al azar de forma aislada; con él, una respuesta equivocada te señala una etapa que falla — chunks malos, recuperación fallida o un prompt débil.