Implementar RAG en un notebook es sencillo. Hay veinte tutoriales que te lo explican en treinta minutos. Haces embed de tus documentos, los guardas en un vector store, recuperas los más similares al query y se los pasas al LLM. Funciona. El problema aparece cuando ese sistema llega a producción: la precisión cae, los costos suben, los usuarios reportan respuestas que no tienen nada que ver con sus preguntas. En 2026, con LangGraph 1.0 y LangSmith en el stack, hay formas de resolverlo que no existían hace un año.
Por qué el RAG básico no escala
El patrón embed-store-retrieve-generate funciona bien con diez documentos y preguntas directas. En producción real te encuentras con tres problemas que ningún tutorial menciona.
Primero, el chunking por tokens parte el contexto donde no debe. Un splitter que divide cada 512 tokens va a cortar oraciones a la mitad, separar una pregunta de su respuesta en un FAQ o partir una tabla justo antes de la columna que importa. El LLM recibe fragmentos incoherentes y genera respuestas que suenan plausibles pero no responden la pregunta real.
Segundo, top-k con similitud coseno siempre trae ruido. Recuperar los cinco chunks más similares funciona si tu corpus es pequeño y homogéneo. Con cientos de documentos y preguntas ambiguas, el retriever trae cosas que parecen relevantes en el espacio vectorial pero no lo son en el dominio real.
Tercero, y esto es lo que más duele: sin evaluación no sabes si algo mejoró o empeoró. Cambias el modelo de embedding, el chunk size, el prompt — y no tienes forma de medir el impacto real. Estás optimizando a ciegas.
Los patrones que sí funcionan en 2026
Chunking semántico en lugar de por tokens
LangChain 0.3+ incluye SemanticChunker: en lugar de cortar cada N tokens, agrupa oraciones por similitud semántica antes de formar el chunk. El resultado son fragmentos con coherencia temática, no solo de longitud. Para documentos técnicos, contratos o manuales, la diferencia en calidad de retrieval es notable.
Reranking después del retrieval inicial
El patrón es este: recupera k=20 candidatos por similitud vectorial (barato y rápido), luego pasa esos candidatos por un modelo de reranking —Cohere Rerank, BGE Reranker o un cross-encoder propio— que ordena por relevancia real al query. Solo los tres o cuatro mejores llegan al LLM. Reduce el ruido drásticamente sin aumentar demasiado la latencia.
HyDE: Hypothetical Document Embedding
El problema de buscar con la pregunta del usuario directamente: las preguntas y los documentos están escritos de formas muy distintas. HyDE lo resuelve así: antes de buscar en tu vector store, le pides al LLM que genere el "documento ideal" que respondería la pregunta. Luego buscas con el embedding de ese documento hipotético. Funciona especialmente bien cuando los usuarios preguntan de forma coloquial y los documentos están en lenguaje técnico o formal.
RAG agéntico con LangGraph
El RAG estático recupera siempre el mismo número de chunks con el mismo proceso. El RAG agéntico decide. Con LangGraph 1.0 puedes modelar el retrieval como un grafo con estado: el agente evalúa si los documentos recuperados son suficientes, decide si necesita buscar más, si tiene que reformular la query o si puede responder con lo que tiene. Esto es lo que hace que un chatbot sobre tus documentos se sienta inteligente en lugar de mecánico.
Evaluación con LangSmith: sin esto estás adivinando
LangSmith registra cada llamada de tu pipeline: qué query llegó, qué chunks recuperó el retriever, qué generó el LLM y cuánto tardó cada paso. Pero lo más valioso es la capa de evaluación: puedes crear datasets de preguntas con respuestas esperadas y correr evaluadores automáticos en cada cambio.
Las tres métricas que más importan en un sistema RAG:
- ▸Faithfulness: ¿la respuesta generada está sustentada en los documentos recuperados, o el LLM está alucinando con información que no aparece en el contexto?
- ▸Answer relevancy: ¿la respuesta responde la pregunta del usuario, o es una respuesta válida que no tiene nada que ver con lo que preguntaron?
- ▸Context precision: de todos los chunks recuperados, ¿cuántos son realmente útiles para generar la respuesta? Un precision bajo significa que el retriever está trayendo mucho ruido
Con un dataset de 50-100 preguntas reales y estos tres evaluadores, puedes medir el impacto de cada cambio en tu pipeline antes de desplegarlo. Es la diferencia entre iterar con datos y iterar con intuición.
Cuándo usar RAG y cuándo no
Esto es lo que nadie te dice en los tutoriales: hay casos donde RAG no es la herramienta correcta. Si tu base de conocimiento completa cabe en 100K tokens y el modelo que usas tiene contexto de 200K, puede ser más simple y más confiable meter todo al contexto directamente. Menos pasos, menos superficie de error, resultados más consistentes.
RAG es la herramienta correcta cuando el corpus es grande (millones de tokens), dinámico (se actualiza constantemente) o cuando necesitas precisión en la fuente —saber de qué documento exacto viene cada parte de la respuesta. Para un chatbot sobre la documentación de tu empresa con cientos de PDFs, es el camino correcto. Para un asistente con un manual de 20 páginas, puede no serlo.
El stack de RAG en producción en 2026
Si tienes que elegir una combinación de herramientas para un sistema RAG en producción hoy, esto es lo que más se está usando en proyectos reales:
- ▸Embeddings: text-embedding-3-large de OpenAI o voyage-3 de Voyage AI — ambos tienen buen balance precio/calidad
- ▸Vector store: Qdrant o Pinecone para produción; Chroma está bien para desarrollo local y prototipos
- ▸Reranker: Cohere Rerank v3.5 — bajo costo, fácil de integrar vía LangChain, mejora notable en precision
- ▸Orquestación: LangGraph para flujos agénticos, LangChain LCEL para pipelines más directos
- ▸Observabilidad y evaluación: LangSmith — sin esto no tienes visibilidad de qué pasa dentro del pipeline
Cómo aprender a implementar RAG bien
Si quieres pasar de los conceptos básicos a un sistema RAG real con evaluación y agentes, en DataPath tienes el camino directo.
El curso de creación de agentes con LangChain cubre RAG, herramientas, memoria y el stack de LangSmith para evaluación — con el código actualizado a 2026. Es el punto de partida si quieres entender LangChain de raíz antes de pasar a patrones más complejos.
Si tu objetivo es construir un chatbot sobre tus propios documentos —el caso de uso de RAG más común en empresas—, el curso de ChatGPT con tus datos es el camino más directo: va de cero al chatbot funcionando, con los patrones actuales de chunking, retrieval y evaluación.
Y para los que quieren el camino completo —RAG agéntico, LangGraph, multi-agente, deployment en producción—, la ruta AI Agentic Engineer cubre todo el stack, con proyectos reales y instructores que trabajan con estos sistemas fuera del aula.
Si ya tienes un RAG básico funcionando, el siguiente paso no es agregar más documentos — es medir qué tan bien responde con datos reales. Empieza por LangSmith y un dataset de cincuenta preguntas reales de tus usuarios. Lo que vas a encontrar en esos números va a cambiar completamente cómo piensas el problema.
