Un modelo de lenguaje suelto suena seguro de sí mismo incluso cuando se equivoca. Para un chatbot de cara al cliente, esa confianza sin respaldo es un riesgo concreto: respuestas inventadas sobre precios, políticas o plazos que después hay que desmentir. La generación aumentada por recuperación (RAG) ataca la causa raíz. En lugar de responder de memoria, el modelo primero recupera los pasajes relevantes de tus propios documentos y luego responde usando solo ese contexto, con fuentes citadas. El efecto sobre la confiabilidad es medible: los estudios de 2026 reportan reducciones de alucinaciones de entre el 40% y el 80% al pasar de un modelo crudo a uno anclado en una base de conocimiento curada.

Qué cambia con RAG

El modelo deja de adivinar sobre tu producto, tus políticas y tus precios. Lee tu base de conocimiento al momento de responder y cita de dónde sale cada afirmación. Cuando los documentos no cubren una pregunta, un asistente bien construido lo dice en vez de inventar. La diferencia no es estética: un GPT crudo puede alucinar en cerca del 28% de las tareas que exigen exactitud factual, y ese porcentaje es justamente el que no se puede tolerar cuando la respuesta termina en un ticket de soporte o en una decisión de compra.

Hay un segundo beneficio menos obvio. Cuando una política cambia, no hace falta reentrenar nada: se actualiza el documento, se reindexa, y el asistente responde con la versión nueva en minutos. El conocimiento vive en tus archivos, no enterrado en los pesos de un modelo.

Cómo funciona por dentro

Una build de RAG tiene cuatro etapas, y cada una se puede medir por separado:

  • Ingesta y segmentación: tus documentos se parten en fragmentos (chunks) y se convierten en vectores numéricos mediante un modelo de embeddings.
  • Indexación: esos vectores se guardan en una base vectorial que permite buscar por similitud semántica, no solo por palabras exactas.
  • Recuperación: ante cada pregunta, el sistema trae los fragmentos más parecidos y, en las builds serias, los reordena con un segundo modelo más preciso.
  • Generación: el modelo de lenguaje redacta la respuesta usando solo esos fragmentos y devuelve las fuentes.

Lo importante es que cada etapa tiene su propia métrica de falla. Una respuesta mala casi nunca es culpa del modelo de lenguaje: suele ser un problema de recuperación que llegó disfrazado de problema de generación.

Qué necesita de verdad una build confiable

La recuperación sola no alcanza. Las partes que deciden si lo podés poner frente a clientes son las menos vistosas:

  • Ingesta y segmentación limpias de tus documentos reales, con tablas y PDFs incluidos
  • Un paso de recuperación ajustado a tu contenido, no por defecto
  • Reordenamiento (reranking) de los candidatos antes de pasarlos al modelo
  • Controles para pedidos fuera de tema o inseguros
  • Evaluación con preguntas reales antes de lanzar
  • Monitoreo para ver las fallas en producción, no por usuarios enojados

Ninguna de estas partes aparece en una demo de cinco minutos, y todas son las que se rompen en producción.

Segmentación: la decisión que más mueve la aguja

El tamaño del chunk determina cuánto contexto útil llega al modelo y cuánto ruido lo acompaña. Como punto de partida defendible en 2026, los benchmarks ubican un rango de 400 a 1024 tokens por fragmento, con segmentación recursiva que respeta párrafos y oraciones antes de cortar. La elección no es trivial: cambiar solo la estrategia de corte puede mover el recall hasta un 9% sobre el mismo corpus, sin tocar el modelo ni la base vectorial.

El solapamiento entre fragmentos, que durante años se dio por obligatorio, hoy es un parámetro a probar, no un dogma. Algunos análisis recientes encontraron que sumarlo no mejora nada y solo encarece la indexación, mientras que en documentos muy estructurados sigue ayudando. La regla práctica: empezar con un 10% a 20% de solapamiento, medir, y recortar si no aporta. La segmentación semántica da la mejor precisión, pero corre cerca de 14 veces más lento que la basada en tokens, así que se paga solo cuando las métricas lo justifican. Por eso lo afinamos sobre tus documentos, no sobre defaults genéricos: arrancamos con un corte por secciones y lo movemos según lo que muestre el conjunto de evaluación armado con tus preguntas reales.

Recuperación en dos etapas y búsqueda híbrida

La práctica estándar en 2026 es recuperar y después reordenar. La primera etapa trae entre 50 y 100 candidatos con búsqueda vectorial rápida. La segunda los reordena con un cross-encoder que evalúa cada par pregunta-fragmento en conjunto, y solo los 3 a 10 mejores llegan al modelo. Ese segundo filtro es barato comparado con el costo de una respuesta equivocada.

A esto se suma la búsqueda híbrida, que combina similitud semántica con coincidencia de palabras clave. Es la diferencia entre encontrar un concepto parafraseado y encontrar un código de producto, un número de artículo o un término legal exacto que el vector solo no recupera bien. Para bases de conocimiento con jerga, SKUs o nomenclatura interna, la híbrida supera de forma consistente a la búsqueda vectorial pura.

Evaluar antes de lanzar, no después

Un asistente sin evaluación es una apuesta. El método que funciona es armar un conjunto de preguntas reales con sus respuestas correctas y medir el sistema contra él en cada cambio. Los marcos como RAGAS miden cuatro dimensiones que conviene vigilar: fidelidad (que la respuesta esté anclada en los documentos), relevancia de la respuesta, y precisión y cobertura del contexto recuperado. Como umbrales orientativos se suele apuntar a fidelidad por encima de 0.75 y relevancia por encima de 0.8.

La ventaja de medir así es que separa la culpa. Si la cobertura del contexto es baja, el problema está en la recuperación o en la segmentación. Si el contexto es bueno pero la fidelidad cae, el problema está en el prompt o en el modelo. Sin esa separación, cada ajuste es a ciegas.

Qué cuesta en la práctica

La economía de RAG cambió a favor de quien construye. Generar embeddings es casi gratis: con un modelo como text-embedding-3-small de OpenAI, indexar a 0,02 USD por millón de tokens significa que vectorizar un manual entero cuesta centavos. La variante grande cuesta cerca de 0,13 USD por millón, unas seis veces más, y se justifica solo cuando la calidad de recuperación lo pide.

La base vectorial tampoco es el gasto que muchos temen. Con pgvector sobre una Postgres que ya tenés corriendo, hasta unos 10 millones de vectores se manejan por debajo de 100 USD al mes, y por debajo de 10 millones suele ser la opción más simple porque los vectores viven al lado del resto de tus datos. Las opciones administradas como Pinecone o Qdrant rondan los 65 a 135 USD mensuales a esa escala y ahorran trabajo de infraestructura. Conviene saber que los precios de lista de los proveedores suelen quedarse cortos contra el costo real por 2 a 4 veces una vez que sumás réplicas y tráfico.

El modelo de generación es el rubro más visible y el más fácil de optimizar. Un modelo liviano como Claude Haiku (alrededor de 0,25 USD por millón de tokens de entrada y 1,25 de salida) o un GPT mini cubren la mayoría de los chats de soporte sin tocar un modelo premium. Sumando caché de prompts, que puede recortar hasta un 90% el costo de la parte repetida del contexto, y el descuento del 50% de las APIs por lotes para la indexación, un asistente con tráfico real opera por cifras muy por debajo de lo que sugiere la intuición.

El objetivo primero

Antes de todo eso, definí el objetivo: qué tiene que acertar este asistente, para quién, y cómo lo vamos a medir. Esa única decisión ahorra más tiempo que cualquier elección de modelo o de base vectorial. Determina qué documentos importan, qué preguntas entran al conjunto de evaluación y qué cuenta como una respuesta aceptable. Es la idea detrás del nombre Nerai, apuntar antes de actuar.

Un chatbot con RAG que no inventa no sale de elegir el modelo más caro, sino de tratar cada etapa como algo medible y de saber, antes de empezar, qué problema tiene que resolver.

Pasanos una muestra de tus documentos y las preguntas que de verdad te hacen los clientes, y te decimos si RAG es lo que te conviene y qué tendría que dar “listo para lanzar” en números para tu caso.