Cómo crear una base de conocimiento con IA (RAG práctico)

Una base de conocimiento con IA es un sistema que responde preguntas usando tus propios documentos —manuales, FAQs, políticas, fichas de producto— en lugar de lo que el modelo aprendió de internet. La técnica que lo hace posible se llama RAG, y en este tutorial vas a construir una funcional desde cero con Python.

El plan es concreto: preparar los documentos, trocearlos, convertirlos en vectores, guardarlos en una base de datos vectorial y montar la consulta que junta búsqueda y modelo de lenguaje. Al final tendrás un chat que responde con tus datos y cita de qué documento ha sacado cada respuesta.

No es tan complicado como suena. Te lo prometo.

Qué es RAG y por qué lo necesitas

RAG son las siglas de Retrieval Augmented Generation, que traducido sería algo como "generación aumentada por recuperación". El nombre es horrible, pero el concepto es simple:

1. El usuario hace una pregunta
2. El sistema busca en tus documentos los fragmentos más relevantes
3. Esos fragmentos se envían al LLM como contexto
4. El LLM genera una respuesta basada en esos fragmentos específicos

Si quieres el concepto explicado a fondo y sin código, lo tengo en qué es RAG. Aquí vamos directos a construirlo.

¿Por qué no simplemente meter todos los documentos en el prompt?

Es la primera pregunta que hay que hacerse, y en 2026 más que nunca: los modelos actuales manejan ventanas de contexto de cientos de miles o incluso un millón de tokens. Si tienes veinte documentos, pégalos y ahórrate todo este tutorial. En serio.

RAG sigue mereciendo la pena por tres motivos muy concretos:

• Volumen: si tienes 500 documentos de 20 páginas, no caben, y no van a caber.
• Coste: pagar el contexto completo en cada consulta multiplica la factura. Recuperar cinco fragmentos cuesta céntimos.
• Precisión: cuando el dato relevante está enterrado en un texto enorme, la calidad de la respuesta baja. Es un efecto medido y conocido.

RAG resuelve esto: solo le das al modelo los 3-5 fragmentos más relevantes para cada pregunta. Es como darle a alguien las páginas exactas de una enciclopedia en vez de toda la enciclopedia.

El flujo completo de RAG

Fase 1: Indexación (se hace una vez)

1. Divides tus documentos en fragmentos pequeños (chunks)
2. Conviertes cada fragmento en un vector numérico (embedding)
3. Almacenas los vectores en una base de datos vectorial

Fase 2: Consulta (cada vez que alguien pregunta)

1. Conviertes la pregunta del usuario en un vector
2. Buscas los vectores más similares en la base de datos
3. Recuperas los fragmentos de texto correspondientes
4. Envías la pregunta + fragmentos al LLM
5. El LLM genera una respuesta basada en esos fragmentos

Antes de programar: ¿de verdad necesitas código?

Voy a ahorrarte tiempo si tu caso es sencillo. Hay tres niveles y la mayoría de la gente se equivoca eligiendo el más alto:

Nivel	Herramientas	Cuándo es tu opción	Límite
Sin código	NotebookLM, Proyectos de Claude, GPTs personalizados	Documentación estable, pocos usuarios, uso interno	No se integra con tus sistemas ni controla permisos
Poco código	n8n, Dify, Flowise, plataformas de chatbot	Quieres servirlo en tu web o WhatsApp sin montar infraestructura	Menos control fino sobre la recuperación
Código	Python con LangChain o LlamaIndex	Volumen alto, permisos por usuario, integración con tu producto	Requiere mantenimiento

Si tu caso es "quiero preguntarle cosas a estos 40 PDFs", empieza por NotebookLM y cierra esta pestaña. Si quieres el chat en tu web sin programar, mira cómo crear un chatbot con IA para tu web. Si has llegado aquí porque necesitas control real, seguimos.

Paso 1: preparar tus documentos

Antes de escribir código, necesitas preparar tus documentos. RAG funciona con prácticamente cualquier formato de texto:

• PDF
• Word (.docx)
• Texto plano (.txt, .md)
• CSV / Excel
• Páginas web
• Correos electrónicos

Organiza tus documentos

1. Crea una carpeta llamada documentos/ en tu proyecto
2. Mete todos los archivos que quieras que tu chatbot pueda consultar
3. Limpia si hace falta: elimina cabeceras/pies de página repetitivos, índices que no aportan, etc.

Este paso parece el aburrido y es el que decide el resultado. En todos los proyectos de RAG que he visto salir mal, el problema no fue el modelo: fue documentación duplicada, versiones contradictorias del mismo procedimiento o PDFs escaneados sin texto.

Para este tutorial, vamos a usar archivos PDF y texto. Si quieres seguir el ejemplo exacto, crea 2-3 archivos .txt con información sobre un tema (por ejemplo, la política de devoluciones de una tienda ficticia, un manual de producto, unas FAQs).

Paso 2: configurar el entorno

#Crear el proyecto
mkdir mi-rag
cd mi-rag

#Entorno virtual
python -m venv venv
source venv/bin/activate  # Windows: venv\Scripts\activate

#Instalar dependencias
pip install langchain langchain-openai langchain-community
pip install langchain-chroma chromadb  # Base de datos vectorial local
pip install pypdf  # Para leer PDFs
pip install python-dotenv

Crea tu archivo .env:

OPENAI_API_KEY=tu-api-key-aqui

Aviso de versiones: LangChain cambia de API con frecuencia y mueve clases entre paquetes cada pocos meses. El código de abajo es la estructura conceptual, que no cambia; si al ejecutarlo ves avisos de deprecación o errores de importación, mira la documentación oficial de la versión que hayas instalado. Es normal, le pasa a todo el mundo, y no significa que el enfoque esté mal.

¿Por qué estas herramientas?

Herramienta	Para qué	Alternativas
LangChain	Orquestar todo el flujo RAG	LlamaIndex, Haystack
ChromaDB	Base de datos vectorial (local)	Pinecone, Supabase/pgvector, Qdrant, Weaviate
Embeddings de OpenAI	Convertir texto en vectores	Cohere, Voyage, Google, modelos locales
Un LLM barato	Generar respuestas	La gama económica de OpenAI, Anthropic o Google

Usamos ChromaDB porque es local (no necesitas crear cuenta en ningún lado) y perfecto para empezar. Para producción, probablemente querrás Pinecone o pgvector sobre PostgreSQL.

Sobre el modelo: los identificadores de modelo cambian cada pocos meses, así que en el código lo defino en una constante y no lo repito. En agosto de 2026 la gama económica que uso para la fase de generación en RAG son las variantes ligeras de GPT-5.6 en OpenAI, Claude Sonnet 5 en Anthropic y Gemini 3.x Flash en Google. Comprueba el identificador exacto en la documentación del proveedor antes de ejecutar; si nunca has llamado a una API de estas, empieza por el tutorial de la API de OpenAI.

Paso 3: cargar y dividir documentos

Crea un archivo indexar.py:

from dotenv import load_dotenv
from langchain_community.document_loaders import (
    DirectoryLoader,
    TextLoader,
    PyPDFLoader
)
from langchain.text_splitter import RecursiveCharacterTextSplitter

load_dotenv()

#1. CARGAR DOCUMENTOS
#Cargar todos los .txt de la carpeta documentos/
txt_loader = DirectoryLoader(
    "documentos/",
    glob="**/*.txt",
    loader_cls=TextLoader,
    loader_kwargs={"encoding": "utf-8"}
)

#Cargar todos los .pdf
pdf_loader = DirectoryLoader(
    "documentos/",
    glob="**/*.pdf",
    loader_cls=PyPDFLoader
)

#Combinar todos los documentos
documents = txt_loader.load() + pdf_loader.load()
print(f"Documentos cargados: {len(documents)}")

#2. DIVIDIR EN CHUNKS
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,      # Tamaño de cada fragmento (caracteres)
    chunk_overlap=200,    # Solapamiento entre fragmentos
    length_function=len,
    separators=["\n\n", "\n", ". ", " ", ""]
)

chunks = text_splitter.split_documents(documents)
print(f"Chunks creados: {len(chunks)}")

#Ver un ejemplo
print(f"\nEjemplo de chunk:")
print(f"Contenido: {chunks[0].page_content[:200]}...")
print(f"Metadata: {chunks[0].metadata}")

¿Por qué dividir en chunks?

Los documentos completos son demasiado grandes para enviar como contexto al LLM. Dividiéndolos en fragmentos de 1000 caracteres:

• Cada fragmento tiene una idea coherente
• El sistema puede recuperar solo los fragmentos relevantes
• El LLM recibe contexto preciso, no ruido

Pro tip: El chunk_size y chunk_overlap son los parámetros más importantes para la calidad de tu RAG. Si tus chunks son demasiado pequeños, pierden contexto. Si son demasiado grandes, incluyen información irrelevante. 1000 caracteres con 200 de overlap es un buen punto de partida.

Paso 4: crear embeddings y almacenar en ChromaDB

Añade al archivo indexar.py (o crea crear_bd.py):

from langchain_openai import OpenAIEmbeddings
from langchain_chroma import Chroma

MODELO_EMBEDDINGS = "text-embedding-3-small"  # rápido y barato

#3. CREAR EMBEDDINGS Y ALMACENAR
embeddings = OpenAIEmbeddings(model=MODELO_EMBEDDINGS)

#Crear la base de datos vectorial con ChromaDB
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db",  # Se guarda en disco
    collection_name="mi_base_conocimiento"
)

print(f"\nBase de datos vectorial creada con {len(chunks)} fragmentos")
print("Guardada en ./chroma_db/")

Ejecuta:

python indexar.py

Esto crea una carpeta chroma_db/ con todos tus documentos indexados. Solo necesitas ejecutar esto una vez (o cuando añadas nuevos documentos).

Un detalle que importa para el español: comprueba que el modelo de embeddings que uses sea multilingüe. Los de OpenAI lo son, pero muchos modelos abiertos populares están entrenados casi solo en inglés y la calidad de recuperación en castellano cae en picado sin que nada te avise.

¿Cuánto cuesta crear los embeddings?

El modelo text-embedding-3-small cuesta alrededor de 0,02 $ por millón de tokens. Para poner en perspectiva:

• 100 páginas de texto = unos 50.000 tokens = unos 0,001 $
• 1.000 páginas = unos 0,01 $

Es prácticamente gratis. Lo que cuesta dinero es la fase de generación, que se paga en cada consulta, no en la indexación.

Paso 5: crear el sistema de consulta

Ahora la parte divertida. Crea consultar.py:

from dotenv import load_dotenv
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_chroma import Chroma
from langchain.chains import RetrievalQA
from langchain.prompts import PromptTemplate

load_dotenv()

MODELO_EMBEDDINGS = "text-embedding-3-small"
MODELO_LLM = "PON-AQUI-EL-MODELO-VIGENTE"  # ver documentación del proveedor

#1. CARGAR LA BASE DE DATOS VECTORIAL
embeddings = OpenAIEmbeddings(model=MODELO_EMBEDDINGS)
vectorstore = Chroma(
    persist_directory="./chroma_db",
    embedding_function=embeddings,
    collection_name="mi_base_conocimiento"
)

#2. CONFIGURAR EL RETRIEVER
retriever = vectorstore.as_retriever(
    search_type="similarity",
    search_kwargs={"k": 4}  # Recuperar los 4 fragmentos más relevantes
)

#3. DEFINIR EL PROMPT
prompt_template = """Usa los siguientes fragmentos de contexto para responder la pregunta del usuario.
Si no encuentras la respuesta en el contexto, di claramente que no tienes esa información.
No inventes respuestas. Basa tu respuesta SOLO en el contexto proporcionado.

Contexto:
{context}

Pregunta: {question}

Respuesta útil:"""

prompt = PromptTemplate(
    template=prompt_template,
    input_variables=["context", "question"]
)

#4. CREAR LA CADENA RAG
llm = ChatOpenAI(model=MODELO_LLM, temperature=0.2)

qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",  # Mete todo el contexto de golpe
    retriever=retriever,
    chain_type_kwargs={"prompt": prompt},
    return_source_documents=True  # Devuelve las fuentes
)

#5. HACER CONSULTAS
def preguntar(pregunta):
    resultado = qa_chain.invoke({"query": pregunta})

    print(f"\nPregunta: {pregunta}")
    print(f"\nRespuesta: {resultado['result']}")
    print(f"\nFuentes utilizadas:")
    for i, doc in enumerate(resultado['source_documents'], 1):
        print(f"  {i}. {doc.metadata.get('source', 'desconocido')} - \"{doc.page_content[:100]}...\"")
    print("-" * 60)
    return resultado

#Probar
preguntar("¿Cuál es la política de devoluciones?")
preguntar("¿Qué productos tenéis disponibles?")
preguntar("¿Cuál es el horario de atención al cliente?")

Ejecuta:

python consultar.py

Si todo va bien, verás respuestas basadas exclusivamente en tus documentos, con las fuentes citadas. Eso es RAG en acción.

Fíjate en dos líneas del prompt que parecen menores y no lo son: la instrucción de decir "no tengo esa información" cuando el contexto no da para responder, y la de no inventar. Sin ellas, el modelo rellena huecos con lo que aprendió en su entrenamiento y te devuelve la política de devoluciones de una tienda genérica de internet con toda la seguridad del mundo.

Paso 6: convertirlo en un chat interactivo

Vamos a crear una versión interactiva que puedas usar como chatbot. La diferencia con lo anterior es la memoria: sin ella, cada pregunta empieza de cero y no puedes decir "¿y qué más sabes de eso?".

#chat_rag.py
from dotenv import load_dotenv
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_chroma import Chroma
from langchain.chains import ConversationalRetrievalChain
from langchain.memory import ConversationBufferWindowMemory

load_dotenv()

MODELO_EMBEDDINGS = "text-embedding-3-small"
MODELO_LLM = "PON-AQUI-EL-MODELO-VIGENTE"

#Configurar componentes
embeddings = OpenAIEmbeddings(model=MODELO_EMBEDDINGS)
vectorstore = Chroma(
    persist_directory="./chroma_db",
    embedding_function=embeddings,
    collection_name="mi_base_conocimiento"
)

llm = ChatOpenAI(model=MODELO_LLM, temperature=0.2)
memory = ConversationBufferWindowMemory(
    memory_key="chat_history",
    return_messages=True,
    k=5  # Recuerda las últimas 5 interacciones
)

#Cadena conversacional con RAG
qa_chain = ConversationalRetrievalChain.from_llm(
    llm=llm,
    retriever=vectorstore.as_retriever(search_kwargs={"k": 4}),
    memory=memory,
    return_source_documents=True
)

#Chat interactivo
print("Chat con tu base de conocimiento (escribe 'salir' para terminar)")
print("=" * 50)

while True:
    pregunta = input("\nTú: ")
    if pregunta.lower() == "salir":
        break

    resultado = qa_chain.invoke({"question": pregunta})
    print(f"\nIA: {resultado['answer']}")

Este chat recuerda el contexto de la conversación. Puedes preguntar "¿Y qué más me puedes decir sobre eso?" y entenderá a qué te refieres.

Nota de mantenimiento: las clases de memoria y las cadenas conversacionales de LangChain han ido cambiando de nombre y de paquete entre versiones. Si tu instalación se queja, la lógica es la misma: guardar las últimas interacciones y reformular la pregunta con ese historial antes de buscar.

Alternativas a ChromaDB para producción

ChromaDB es perfecto para desarrollo y proyectos pequeños. Para producción, considera estas alternativas:

Pinecone (Cloud)

from langchain_pinecone import PineconeVectorStore
import os

os.environ["PINECONE_API_KEY"] = "tu-api-key"

vectorstore = PineconeVectorStore.from_documents(
    documents=chunks,
    embedding=embeddings,
    index_name="mi-indice"
)

Pros: Escalable, rápido, serverless. Contras: Coste por uso, tus datos en la nube.

Supabase (PostgreSQL + pgvector)

from langchain_community.vectorstores import SupabaseVectorStore
from supabase import create_client

supabase = create_client("tu-url", "tu-key")
vectorstore = SupabaseVectorStore.from_documents(
    documents=chunks,
    embedding=embeddings,
    client=supabase,
    table_name="documents"
)

Pros: PostgreSQL que ya conoces, código abierto, buen plan gratuito. Contras: Necesitas configurar la extensión pgvector.

Base Vectorial	Tipo	Precio	Mejor para
ChromaDB	Local	Gratis	Desarrollo, prototipos
pgvector	Sobre tu PostgreSQL	Gratis (ya pagas la BD)	Si ya usas PostgreSQL
Pinecone	Cloud	Plan gratuito y de pago por uso	Producción serverless
Supabase	Cloud/Self-host	Plan gratuito y de pago	Si ya usas Supabase
Weaviate	Cloud/Self-host	Plan gratuito y de pago	Búsqueda avanzada
Qdrant	Cloud/Self-host	Plan gratuito y de pago	Alto rendimiento

Mi recomendación práctica para una pyme: si ya tienes PostgreSQL en algún sitio, pgvector y no añadas un proveedor más a la factura. Para volúmenes de decenas de miles de fragmentos va sobrado.

Paso 7: optimizar la calidad de las respuestas

Tu RAG básico funciona, pero hay formas de mejorar significativamente la calidad:

1. Ajustar el tamaño de chunks

Experimenta con diferentes tamaños:

#Para documentos técnicos densos
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=100
)

#Para documentos narrativos
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1500,
    chunk_overlap=300
)

2. Añadir metadata a los chunks

#Enriquecer los chunks con metadata
for chunk in chunks:
    chunk.metadata["tipo"] = "faq"  # o "manual", "politica", etc.
    chunk.metadata["fecha"] = "2026-01"

Esto te permite filtrar por tipo de documento en las búsquedas. Y es también el mecanismo con el que se implementan los permisos: si añades a cada fragmento el departamento o el nivel de acceso, puedes filtrar en la recuperación y no servir a nadie lo que no le toca. Es la forma correcta de hacerlo; confiar en que el modelo se contenga no lo es.

3. Usar hybrid Search

Combina búsqueda semántica (por significado) con búsqueda por keywords:

from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever

#Retriever semántico (embeddings)
semantic_retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

#Retriever por keywords (BM25)
bm25_retriever = BM25Retriever.from_documents(chunks, k=3)

#Combinar ambos
hybrid_retriever = EnsembleRetriever(
    retrievers=[semantic_retriever, bm25_retriever],
    weights=[0.6, 0.4]  # 60% semántico, 40% keywords
)

Pro tip: Hybrid search mejora mucho los resultados cuando las preguntas incluyen términos técnicos o nombres propios que la búsqueda semántica sola puede no captar.

4. Añadir un reranker

Después de recuperar diez o quince fragmentos, un segundo modelo especializado los reordena por relevancia real y te quedas con los cuatro mejores. Cuesta muy poco por consulta y, en mi experiencia, sube la calidad más que cualquier ajuste de chunk size. Cohere, Voyage y varios modelos abiertos ofrecen rerankers listos para usar.

Errores comunes en RAG

Chunks demasiado grandes o pequeños. Si tus chunks son de 5000 caracteres, incluyen demasiada información irrelevante. Si son de 100 caracteres, pierden contexto. Empieza con 1000 y ajusta.

No solapar chunks. Sin overlap, un concepto que está entre dos chunks se pierde. Siempre usa overlap (20% del chunk_size es un buen valor).

No limpiar los documentos. Headers, footers, números de página, índices... todo eso añade ruido. Limpia tus documentos antes de indexarlos.

Recuperar demasiados o pocos fragmentos. Con k=1 puedes perderte información relevante. Con k=20 inundas al LLM de contexto y la calidad baja. k=3 a 5 suele ser el punto dulce.

No evaluar la calidad. Crea un set de 20-30 preguntas con respuestas esperadas y evalúa regularmente tu RAG. Sin métricas, no sabes si los cambios mejoran o empeoran las cosas. Es el paso que más gente se salta y el que más caro sale.

Olvidar actualizar el índice. Si tus documentos cambian, necesitas reindexar. Implementa un proceso para detectar cambios y actualizar los embeddings.

Indexar documentos que no todo el mundo puede ver. Si metes en el mismo índice las nóminas y el manual de producto, el sistema servirá las nóminas a quien pregunte por ellas. Filtra por metadata en la recuperación, y si hay datos personales, revisa tus obligaciones de RGPD antes de poner nada en producción.

Conclusión: tu base de conocimiento con IA

Acabas de construir algo que hace unos años habría costado meses de desarrollo y miles de euros: un sistema que entiende tus documentos y responde preguntas basándose en ellos.

Resumen de lo que has aprendido:

1. Cargar y dividir documentos en chunks optimizados
2. Crear embeddings y almacenarlos en una base vectorial
3. Consultar con búsqueda semántica + LLM
4. Optimizar con hybrid search, reranking, metadata y ajuste de parámetros

El siguiente paso natural es desplegar esto como una API o integrarlo en tu web. Un endpoint con FastAPI que reciba preguntas y devuelva respuestas es todo lo que necesitas para convertir este script en un producto funcional. Si prefieres no mantener servidores, la alternativa es montar el mismo flujo con nodos en n8n y exponerlo por webhook.

Empieza con tus documentos más importantes (FAQs, manuales de producto) y ve ampliando. Un RAG bien hecho puede reducir drásticamente el volumen de soporte al cliente y dar acceso instantáneo a información que antes requería buscar manualmente durante minutos.

Preguntas frecuentes

¿Cómo creo una base de conocimiento con IA?

Reúnes y limpias tus documentos, los divides en fragmentos, los conviertes en vectores con un modelo de embeddings, los guardas en una base de datos vectorial y montas una consulta que recupera los fragmentos relevantes y se los pasa a un modelo de lenguaje. Con Python, LangChain y ChromaDB es una tarde de trabajo para una primera versión.

¿Cuánto cuesta montar un sistema RAG?

La indexación es casi gratis: unos céntimos por cada mil páginas de embeddings. Lo que se paga es cada consulta al modelo, del orden de fracciones de céntimo con la gama económica. Para una pyme con uso interno, el coste mensual de infraestructura y API se mueve en decenas de euros; lo caro es el tiempo de ordenar la documentación.

¿Se puede hacer RAG sin programar?

Sí. NotebookLM, los Proyectos de Claude y los GPTs personalizados son sistemas RAG listos para usar: subes archivos y preguntas. Plataformas como n8n, Dify o Flowise te permiten montar el flujo con nodos visuales y exponerlo en tu web. Solo necesitas código cuando quieres permisos por usuario, mucho volumen o integrarlo en tu propio producto.

¿Qué base de datos vectorial es mejor para empezar?

ChromaDB en local, porque no requiere cuenta ni configuración y te deja centrarte en el resto. Cuando pases a producción, pgvector si ya tienes PostgreSQL, y Pinecone o Qdrant si quieres un servicio gestionado que escale sin que lo mantengas tú.

¿Cuál es el tamaño de chunk ideal?

Alrededor de 1.000 caracteres con 200 de solapamiento funciona bien como punto de partida. Baja a 500 en documentación técnica densa y sube a 1.500 en textos narrativos. Y siempre que la estructura lo permita, corta por apartados o artículos en lugar de por número de caracteres: el resultado mejora bastante.

¿Por qué mi RAG da respuestas malas?

Por este orden de probabilidad: los documentos están sucios, duplicados o desactualizados; los chunks están mal cortados; recuperas demasiados o demasiado pocos fragmentos; o falta búsqueda híbrida y el sistema no encuentra nombres propios y códigos. El modelo casi nunca es el problema.

¿RAG funciona bien en español?

Sí, siempre que uses un modelo de embeddings multilingüe. Es el fallo silencioso más frecuente: modelos entrenados casi solo en inglés que recuperan mal en castellano sin dar ningún error. Los de OpenAI, Cohere y Google funcionan bien; con los abiertos, comprueba la ficha del modelo antes.

¿Puedo usar RAG con documentos confidenciales?

Sí, pero hay que diseñarlo: etiqueta cada fragmento con su nivel de acceso y filtra en la recuperación, no en la respuesta. Y si envías contenido a una API externa, necesitas contrato de encargado de tratamiento y base legal. Si el dato es muy sensible, valora un modelo local: pierdes calidad, pero nada sale de tu red.

¿Cómo mido si mi sistema RAG funciona bien?

Con un conjunto de 20 a 30 preguntas reales y su respuesta correcta escrita a mano. Cada vez que cambies algo —el tamaño de chunk, el modelo, el número de fragmentos— lo pasas y comparas. Sin esa referencia estás ajustando a ciegas y es imposible saber si has mejorado.

¿RAG o meterlo todo en el contexto del modelo?

Si tus documentos caben en la ventana de contexto y las consultas son pocas, pégalos y no montes nada: es más simple y más preciso. RAG gana cuando el volumen no cabe, cuando el coste por consulta importa o cuando necesitas saber exactamente de qué documento salió cada afirmación.