El paso 1 de la consulta esconde la dependencia que más se olvida: la pregunta se convierte en vector con el mismo modelo de embedding que se usó al indexar. Dos modelos distintos producen espacios distintos, y la distancia entre un vector de uno y otro no significa nada. No da error: da resultados aleatorios con aspecto de resultados.
// si cambias el modelo de embedding, todo lo indexado deja de servir| Decisión | Coste de cambiarla después | Se nota como |
|---|---|---|
| Tamaño y estrategia de chunk | Reindexar el corpus entero | Respuestas con contexto cortado o irrelevante |
| Modelo de embedding | Reindexar + volver a pagar todos los embeddings | Nada, hasta que las búsquedas dejan de tener sentido |
| Qué metadata se guarda | Reindexar (o un pase de actualización) | No poder filtrar ni citar la fuente |
Frente a eso, lo que se puede cambiar en caliente es sorprendentemente poco y muy barato: cuántos chunks recuperas, con qué estrategia buscas, qué prompt envuelve el contexto y qué modelo genera. Nada de eso toca la base vectorial.
Esa asimetría da el orden de trabajo: antes de tocar el prompt o subir de modelo, comprueba si los chunks que llegaron contenían siquiera la respuesta. Si no estaba en el contexto, el LLM no la va a inventar bien —y si la inventa, peor.
RAG resuelve un problema concreto: que el conocimiento no cabe en el prompt, o cambia, o hay que citarlo. Cuando ninguna de las tres se cumple, montar el pipeline añade dos servicios, una base de datos y una factura de embeddings para hacer lo que hacía un texto pegado.
| Monta RAG cuando… | No lo montes cuando… |
|---|---|
| El corpus no cabe en la ventana de contexto | Todo cabe cómodamente en el prompt |
| Los documentos cambian y no quieres reentrenar | El conocimiento es estático y pequeño |
| Necesitas citar la fuente de cada respuesta | Da igual de dónde venga la información |
| Quieres reducir alucinaciones anclando a documentos | Necesitas razonamiento puro, sin fuentes |
La guía expresa este umbral en páginas —«menos de 10» en una unidad, «5-10» en otra—, y esa es la parte que no conviene copiar: una página de tabla y una de prosa no ocupan lo mismo, y el límite real es el de la ventana del modelo que uses, que cambia cada pocos meses. El criterio que envejece bien es el de la segunda unidad: ¿cabe en el prompt? Eso se mide contando tokens, no páginas.
langchain.text_splitter en dos unidades y desde
langchain_text_splitters en otra; construye la cadena con RetrievalQA
en la unidad 1 y con LCEL a mano en la unidad 2; y usa gpt-3.5-turbo una sola vez,
justo en la unidad más moderna. Su propia tabla de troubleshooting reconoce que «LangChain se
dividió en paquetes» y acto seguido vuelve a la ruta antigua. ¿Cuál de las dos rutas de
import funciona sin avisos de deprecación en tu instalación, y sigue RetrievalQA
recomendada o es una cadena legacy? El Módulo 4 de este mismo curso tiene una lección entera
sobre APIs legacy de LangChain: merece la pena resolverlo antes de escribir código propio.
Coge el caso que quieras montar y escribe dos listas en una hoja: los pasos que correrán una vez y los que correrán en cada pregunta. Al lado de cada paso de la primera lista, anota qué habría que rehacer si cambias de idea.
Después haz una cuenta rápida: cuántos tokens tiene tu corpus y cuánto costaría embeberlo entero dos veces. Ese número es el precio de equivocarte de modelo de embedding, y es el que decide cuánto tiempo merece la pena dedicar a elegirlo antes de indexar.