Cómo construir una canalización RAG en 2026 (paso a paso)

La generación aumentada por recuperación dejó de ser una curiosidad investigadora hace años. En 2026 es el método predeterminado para integrar un modelo de lenguaje grande (LLM) con sus propios documentos sin tener que pagar por ajuste fino del modelo ni arriesgarse a que genere respuestas inventadas con confianza. El patrón es sencillo de describir, pero está lleno de complejidades prácticas: encontrar el texto adecuado, pasárselo al modelo y dejar que este redacte la respuesta.

Esta es una guía práctica de implementación, no una revisión bibliográfica. Al finalizarla, sabrá exactamente qué componentes necesita una canalización RAG funcional en 2026, qué herramientas y versiones específicas utilizar, y contará con un esquema de código mínimo que puede ejecutar localmente o mediante una API. Hemos verificado cada número de versión, precio y resultado de benchmark indicado a continuación contra fuentes actuales, porque el peor error en RAG es aquel que copia de una entrada de blog escrita para las bibliotecas del año pasado.

Cómo funciona realmente una canalización RAG

Un sistema RAG consta de dos fases. Indexación ocurre una vez (o cada vez que sus documentos cambien): divide los archivos fuente en fragmentos, convierte cada fragmento en un vector mediante un modelo de incrustación y almacena dichos vectores en una base de datos. Consulta ocurre en cada solicitud: incrusta la pregunta del usuario, encuentra los fragmentos más similares, opcionalmente los reordena, inserta los mejores en un prompt y llama a un modelo de lenguaje grande (LLM).

Esa es toda la idea. La ingeniería radica en los detalles: tamaño de los fragmentos, qué modelo de incrustación usar, cuántos resultados recuperar, si reordenarlos y cómo medir si todo funciona. Si desea comprender los fundamentos conceptuales antes de construir, nuestra explicación de RAG cubre la teoría; este artículo se centra en su implementación práctica. Y si aún está decidiendo entre RAG y personalizar directamente el modelo, la comparación entre ajuste fino y RAG es el punto de partida adecuado: para la mayoría de los equipos que alimentan datos privados y cambiantes a un LLM, RAG es la solución más económica y mantenible.

Paso 1: Divida sus documentos

Los modelos de incrustación tienen un límite de contexto y, lo que es más importante, pierden precisión en pasajes largos. Por tanto, se dividen los documentos en fragmentos. El consenso de 2026, respaldado por comparativas técnicas y no por percepciones subjetivas, es poco llamativo: utilice un divisor recursivo por caracteres orientado a aproximadamente 512 tokens con una superposición del 10–20 % (50–100 tokens).

Una evaluación realizada en febrero de 2026 sobre 50 documentos reales reveló que la división recursiva ingenua en fragmentos de 512 tokens obtuvo una precisión de recuperación del 69 %, mientras que la segmentación semántica —que intenta dividir en los límites de significado— alcanzó solo un 54 %. La razón es sencilla: la segmentación semántica generó fragmentos con un promedio de 43 tokens, demasiado pequeños para proporcionar al modelo suficiente contexto como para responder adecuadamente. Por otro lado, un estudio independiente realizado en enero de 2026, que utilizó la recuperación SPLADE, encontró que añadir solapamiento incrementaba el costo de indexación sin aportar beneficio medible alguno en su conjunto de datos. La conclusión honesta es esta: comience con fragmentos recursivos de tamaño fijo y solo recurrir a la segmentación semántica o por páginas si sus métricas de evaluación demuestran, de forma inequívoca, que las necesita para sus documentos específicos.

Paso 2: Elija un modelo de incrustación

Esta es la decisión más trascendental de toda la canalización, y la diferencia entre las opciones es real. A continuación se presentan las alternativas dignas de considerarse a mediados de 2026, con cifras verificadas.

Para un prototipo, comience localmente con nomic-embed-text —es rápido, gratuito, cabe en una laptop con 16 GB de RAM y, según informes, supera a text-embedding-ada-002de OpenAI. Para entornos productivos, el campo de código abierto ha alcanzado realmente a los líderes comerciales: BGE-M3 es el motor de referencia con licencia MIT que la mayoría de las pilas autoalojadas adoptan por defecto, mientras que Voyage-3.5 y Gemini Embedding lideran las pruebas de rendimiento entre los servicios gestionados mediante API. Existe una única regla fundamental: cualquiera que sea el modelo que use para incrustar sus documentos, debe emplear exactamente el mismo modelo para incrustar sus consultas. Mezclar modelos de forma silenciosa destruye por completo la recuperación.

Paso 3: Almacene los vectores en una base de datos vectorial

Una vez que tenga las incrustaciones, deben almacenarse en algún lugar que soporte búsquedas rápidas de vecinos más cercanos. En 2026 dispone de tres niveles razonables.

Un análisis más detallado figura en nuestra guía de bases de datos vectoriales, pero para la mayoría de los equipos el árbol de decisiones es breve: ya usa PostgreSQL → pgvector; necesita filtrado intensivo o miles de millones de vectores → Qdrant o Milvus; solo está experimentando → Chroma.

Paso 4: Recupere y reordene

La recuperación en sí consiste en una sola llamada: incruste la consulta, luego solicite a la base de datos los k fragmentos más cercanos (un valor típico de k oscila entre 20 y 50). Sin embargo, la similitud vectorial pura es una herramienta tosca. Un reordenador (reranker) —un codificador cruzado que puntúa individualmente cada par consulta-documento— vuelve a ordenar esos candidatos y eleva los realmente relevantes antes de que lleguen al modelo.

El patrón estándar consiste en recuperar los 50 mejores resultados con su codificador bi-direccional, aplicar el reordenamiento y conservar los 5–10 mejores. Cohere Rerank 3.5 cuesta 0,002 USD por búsqueda (2 USD por 1.000 búsquedas) y normalmente añade una latencia del orden de 100–300 ms. Si dispone de una GPU y desea eliminar por completo el costo por consulta, el modelo de código abierto BGE-reranker-v2-m3 se ejecuta en ~50–100 ms y admite contenido multilingüe. El reordenamiento es una de las mejoras de mayor impacto y menor esfuerzo que puede implementar: la mayoría de las canalizaciones que «recuperan basura» simplemente omiten este paso.

Paso 5: Enriquezca el prompt y genere

Ahora ensamble el prompt: una breve instrucción del sistema que indique al modelo responder únicamente a partir del contexto suministrado, los fragmentos reordenados y la pregunta del usuario. Luego invoque su modelo de lenguaje grande (LLM).

Para el modelo de generación puede optar por una solución local o mediante API. Localmente, mediante OllamaOllama, el punto óptimo en 2026 es un modelo de clase 8B —Qwen3 8B o Llama 3.1 8B cuantizados a Q4_K_M—, que ocupa 8–12 GB de VRAM y alcanza velocidades superiores a 40 tokens/segundo en una GPU moderna. Qwen3 14B (~8–9 GB en cuantización Q4) representa un salto notable en rendimiento, con una ventana de contexto de 128K tokens que permite incluir más texto recuperado. Para una opción alojada con mayor potencial, un modelo fronterizo mediante API funciona muy bien; nuestro tutorial sobre chatbots con la API de Claude explica ese flujo de principio a fin. Un recordatorio útil de los profesionales: en RAG, la calidad de la recuperación suele importar más que el tamaño del modelo —fragmentos limpios más un buen incrustador más un LLM pequeño superan a un modelo gigantesco alimentado con un contexto deficiente.

Paso 6: Un esquema de código mínimo

A continuación se presenta una canalización completa local basada en LangChain 1.x, Chroma y Ollama. Indexa un documento y responde una pregunta —sin necesidad de claves API.

# pip install langchain langchain-community langchain-chroma langchain-ollama
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_ollama import OllamaEmbeddings, ChatOllama
from langchain_chroma import Chroma

# 1. Cargar + segmentar (~512 tokens, ~15 % de solapamiento; los tamaños están en caracteres)
docs = TextLoader("handbook.txt").load()
chunks = RecursiveCharacterTextSplitter(
    chunk_size=2000, chunk_overlap=300
).split_documents(docs)

# 2. Incrustar + 3. Almacenar
embeddings = OllamaEmbeddings(model="nomic-embed-text")
store = Chroma.from_documents(chunks, embeddings)

# 4. Recuperar (los 4 mejores)
retriever = store.as_retriever(search_kwargs={"k": 4})

# 5. Enriquecer + generar
llm = ChatOllama(model="qwen3:8b")
question = "¿Cuál es el plazo para solicitar una devolución?"
context = "nn".join(d.page_content for d in retriever.invoke(question))
prompt = (f"Responda ÚNICAMENTE usando el contexto proporcionado. Si no aparece allí, indíquelo.nn"
          f"Contexto:n{context}nnPregunta: {question}")
print(llm.invoke(prompt).content)

Ese es todo el ciclo. Para añadir reordenamiento, inserte un ContextualCompressionRetriever con un cross-encoder entre los pasos 4 y 5. Con LlamaIndex 0.14.x, el mismo flujo suele requerir menos código gracias a sus abstracciones de recuperación diseñadas específicamente para ese propósito: es la mejor opción para aplicaciones centradas en la recuperación, mientras que el entorno de ejecución LangGraph de LangChain brilla cuando se necesitan agentes con estado y varios pasos. (La elección de una capa de orquestación es, por sí misma, un tema aparte; véase nuestra comparación de frameworks para agentes de IA.)

Paso 7: Evalúe — no omita este paso

La diferencia entre una demostración y un producto radica en la medición. La herramienta estándar es RAGAS, que evalúa la fidelidad (¿se mantuvo la respuesta fiel al contexto?), la precisión del contexto y la recuperación del contexto, utilizando un modelo de lenguaje grande (LLM) como juez. Cree un pequeño conjunto de 20 a 50 pares de pregunta-respuesta a partir de sus documentos reales y ejecute RAGAS tras cada cambio.

Esto también le permite tomar todas las decisiones anteriores con honestidad. ¿Debe cambiar al particionado semántico? ¿Agregar un reranker? ¿Aumentar k de 4 a 8? No lo adivine: modifique una sola variable, vuelva a ejecutar RAGAS y conserve el cambio únicamente si los resultados numéricos mejoran. Sin este ciclo, estará ajustando el sistema a ciegas.

Preguntas frecuentes

¿Cuánto cuesta ejecutar una canalización RAG?

Casi gratis para prototipar. Con incrustaciones locales de Ollama, Chroma y un LLM local, su único costo es el consumo eléctrico. A escala, los principales gastos corresponden a la base de datos vectorial (una instancia autohospedada de Qdrant o pgvector en su propia máquina virtual resulta notablemente más económica que las ofertas gestionadas, cuyos costos pueden superar los 5.000 USD/mes con 100 millones de vectores) y, si utiliza APIs, a las incrustaciones (por ejemplo, OpenAI text-embedding-3-large cuesta 0,13 USD por millón de tokens) y a las llamadas de generación.

¿Necesito una base de datos vectorial o puedo usar una convencional?

Necesita búsqueda vectorial, pero no necesariamente un producto especializado. pgvector añade esta funcionalidad a PostgreSQL y gestiona eficazmente hasta 1 millón de vectores con baja latencia p95 (de unos pocos milisegundos en unidades NVMe, algo mayor en SSD en la nube); por tanto, si ya emplea PostgreSQL, puede evitar por completo la incorporación de nueva infraestructura. Opte por una base de datos especializada como Qdrant cuando requiera filtros avanzados por metadatos o deba manejar miles de millones de vectores.

¿Qué tamaño de fragmento (chunk) debo usar?

Comience con aproximadamente 512 tokens y un solapamiento del 10–20 % mediante un divisor recursivo. Una evaluación realizada en 2026 halló que este enfoque superaba al particionado semántico en precisión de recuperación en un 69 % frente al 54 %. Solo pase a técnicas de particionado más sofisticadas si sus métricas de evaluación demuestran que mejoran efectivamente el rendimiento sobre sus documentos específicos.

¿Es realmente necesario un reranker?

No para lograr una versión funcional básica, pero constituye una de las mejoras de calidad más económicas disponibles. Recupere un conjunto amplio (los primeros 50 resultados), realice una nueva clasificación con Cohere Rerank 3.5 o con el modelo de código abierto BGE-reranker-v2-m3, y conserve solo los 5–10 mejores. La mayoría de las canalizaciones que muestran fragmentos irrelevantes simplemente omiten este paso.

¿Puedo construir una solución RAG sin LangChain ni LlamaIndex?

Sí. El bucle central —incrustar, buscar, formular el prompt y generar— consta de aproximadamente 40 líneas de Python estándar que invocan directamente su modelo de incrustaciones, el cliente de la base de datos vectorial y el modelo de lenguaje grande (LLM). Los frameworks ahorran tiempo en cargadores, rerankers y orquestación agente, pero son opcionales, y una implementación desde cero le otorga control total sobre cada etapa.

¿Debo usar un modelo local o una API para la generación?

Un modelo local (mediante Ollama, con un modelo de 8B en 8–12 GB de VRAM) es excelente para garantizar privacidad, control de costos y uso sin conexión. Una API ofrece un techo de calidad superior y cero operaciones. Muchos equipos prototipan localmente para iterar a bajo costo y luego eligen, según cada despliegue, entre ambas opciones basándose en la sensibilidad de los datos y el presupuesto disponible.

¿Cómo mantengo actualizado el índice conforme cambian los documentos?

Vuelva a incrustar e inserte únicamente los cambios, sin reconstruir todo el índice. Registre un hash del contenido o la fecha de modificación para cada documento fuente y, al actualizarlo, elimine los fragmentos antiguos asociados a dicho documento e inserte los nuevos. La mayoría de las bases de datos vectoriales admiten operaciones de inserción condicional (upserts) y eliminación mediante filtros por metadatos, lo que simplifica considerablemente las actualizaciones incrementales.

Conclusión

Construir una canalización RAG en 2026 es verdaderamente accesible: seis etapas, un puñado de herramientas maduras y aproximadamente 40 líneas de código para obtener un prototipo funcional. Las trampas no residen en la arquitectura, sino en las configuraciones predeterminadas. Use fragmentos sencillos de 512 tokens, asegúrese de que los modelos de incrustación para consultas y documentos coincidan, incluya un reranker y nunca realice ajustes sin tener a RAGAS integrado en el ciclo de validación. Comience de forma local y gratuita con nomic-embed-text, Chroma y un modelo de 8B de Ollama; sustituya componentes individuales por pgvector, Qdrant, Voyage o una API de vanguardia únicamente cuando sus propias métricas de evaluación —y no un artículo de blog— así lo indiquen. Si logra dominar la recuperación, incluso un modelo pequeño le llevará mucho más lejos de lo que podría imaginar.