¿De dónde obtiene sus datos un LLM? Fuentes de datos RAG en Python

El artículo anterior, ¿Qué es RAG? La explicación más simple de cómo funciona, estableció el modelo mental: el LLM escribe, RAG recupera conocimiento útil, la aplicación posee el estado actual y las herramientas realizan acciones. Este artículo da el siguiente paso: ¿de dónde vienen realmente los datos y cómo se ve la recuperación en Python?

La sorpresa importante es que una "fuente de datos para un LLM" normalmente no es nada exótico. Puede ser un archivo de texto, una carpeta de documentos Markdown, una base de datos SQL, una respuesta de API, un catálogo de productos, un sistema de soporte o un índice vectorial derivado de esas fuentes. La IA no conoce estos sistemas mágicamente. Tu aplicación tiene que cargar, consultar, buscar o recuperar los datos relevantes y colocar el resultado en el contexto del modelo.

Fuente de datos = dónde vive la información. Recuperación = cómo la aplicación encuentra información útil. Contexto = la información seleccionada que se entrega al modelo. LLM = el componente que interpreta ese contexto y genera una respuesta.— El modelo de cuatro partes utilizado a lo largo de este artículo

Pregunta

¿Cómo utiliza un LLM datos externos como archivos, bases de datos o API, y cómo puede un pequeño programa en Python implementar los pasos esenciales de RAG sin ocultarlos detrás de un framework?

Qué significa esto realmente

Cuando los desarrolladores dicen que un LLM está "conectado a los datos de la empresa", varias operaciones diferentes pueden estar ocultas detrás de esa frase. Una aplicación puede ejecutar SQL. Otra puede llamar a una API. Otra puede ejecutar búsqueda de texto completo. Otra puede calcular la similitud de embeddings sobre fragmentos de documentos. Todas ellas pueden proporcionar información externa a un LLM, pero no son el mismo método de recuperación y no deben tratarse como intercambiables.

Esta distinción importa porque el mejor método de recuperación depende de la forma de la pregunta. "¿Cuál es nuestra política de reembolsos?" es un problema de recuperación de documentos. "¿Cuál es el estado actual del pedido 4711?" suele ser una consulta a una base de datos estructurada. "¿Qué párrafo trata sobre la recuperación de cuentas?" puede ser búsqueda por palabras clave o semántica. RAG es más útil cuando el sistema debe descubrir conocimiento relevante antes de la generación.

Ejemplo más simple

Comienza con tres cadenas en Python normal. Todavía no hay base de datos vectorial, ni framework, ni LLM. Solo queremos hacer visible el paso de recuperación.

documents = [
    "The AKM uses 7.62 mm ammunition.",
    "A Med Kit restores health.",
    "A 4x scope can be attached to several compatible weapons."
]

question = "Which ammunition does the AKM use?"

for document in documents:
    if "AKM" in document:
        print(document)

El programa imprime la primera frase porque contiene el término que buscamos. Esta es una recuperación primitiva, pero la arquitectura ya es visible: pregunta → búsqueda → texto relevante. RAG añade un paso más importante: pasar el texto recuperado a un modelo de lenguaje junto con la pregunta.

Una versión un poco más general clasifica los documentos por términos de consulta superpuestos:

import re

documents = [
    {"id": "weapon-akm", "text": "The AKM uses 7.62 mm ammunition."},
    {"id": "healing-medkit", "text": "A Med Kit restores health."},
    {"id": "scope-4x", "text": "A 4x scope can be attached to several compatible weapons."},
]

def words(text):
    return set(re.findall(r"[a-zA-Z0-9.]+", text.lower()))

def retrieve(question, documents, top_k=2):
    query_terms = words(question)
    ranked = []

    for document in documents:
        score = len(query_terms & words(document["text"]))
        if score > 0:
            ranked.append((score, document))

    ranked.sort(key=lambda item: item[0], reverse=True)
    return [document for _, document in ranked[:top_k]]

question = "Which ammunition does the AKM use?"
hits = retrieve(question, documents)

for hit in hits:
    print(hit["id"], "->", hit["text"])

Esto no es un motor de búsqueda de producción. Ignora la morfología, los sinónimos, las variantes ortográficas, la longitud de los documentos y muchas señales de clasificación. Su valor es educativo: RAG no comienza con una base de datos vectorial. Comienza con la recuperación.

Dónde deja de funcionar el ejemplo

La coincidencia exacta o léxica se vuelve débil cuando la pregunta y la fuente usan palabras diferentes. Un documento puede decir "mantenimiento del vehículo", mientras que el usuario pregunta "¿cómo reparo mi coche?". Un recuperador léxico puede pasar por alto la relación aunque un humano la vea de inmediato. La recuperación semántica aborda esto representando el texto como vectores y comparando el significado en lugar de solo los tokens exactos.

Los archivos largos crean otro problema. Buscar en un manual completo de 80 páginas como una sola unidad es demasiado grueso, pero dividir cada frase puede destruir contexto útil. Por lo tanto, los sistemas RAG reales necesitan decisiones sobre análisis, fragmentación, metadatos, clasificación, actualidad, permisos y procedencia.

El ejemplo tampoco dice nada sobre hechos estructurados en vivo. Si el usuario pregunta por el estado actual del pedido 4711 y la aplicación ya tiene una clave de base de datos, la búsqueda semántica suele ser la herramienta inicial incorrecta. Es mejor una consulta determinista a la base de datos.

Respuesta directa

Una fuente de datos para un LLM es cualquier sistema externo del que una aplicación pueda obtener información para el modelo: archivos, bases de datos, API, índices de búsqueda, almacenes vectoriales o estado de la aplicación en vivo. RAG es el patrón de recuperar conocimiento relevante de dichas fuentes antes de la generación.

En Python, el pipeline esencial puede ser muy pequeño: cargar datos → crear unidades recuperables → encontrar evidencia relevante → ensamblar el contexto → llamar al LLM. El método de recuperación debe coincidir con la fuente y la pregunta. Use SQL para hechos estructurados exactos, búsqueda de texto completo para coincidencia léxica, embeddings para similitud semántica y recuperación híbrida cuando varias señales sean valiosas.

Por qué es así

Un modelo de lenguaje no recibe automáticamente el contenido de su sistema de archivos, base de datos PostgreSQL, CRM, API privada o documento recién editado. La aplicación decide qué información externa es accesible y qué se coloca en el contexto actual del modelo.

El trabajo original de Generación Aumentada por Recuperación de Lewis et al. combinó un modelo generativo con memoria externa no paramétrica recuperada de un índice vectorial denso. La idea arquitectónica más amplia sobrevive más allá de esa implementación específica: la evidencia externa puede recuperarse en el momento de la inferencia en lugar de esperar que todo el conocimiento útil esté codificado en los parámetros del modelo.

Esto crea una separación útil de responsabilidades: la fuente almacena información, el recuperador selecciona evidencia, el contexto lleva esa evidencia a la solicitud y el modelo la interpreta. Mantener visibles esos límites hace que los fallos sean mucho más fáciles de diagnosticar.

Contexto: los principales tipos de fuentes de datos

Un índice vectorial merece especial atención. En muchas arquitecturas no es la fuente canónica de verdad. Es un índice de recuperación derivado de documentos o registros. El documento autoritativo puede residir en almacenamiento de objetos, un CMS, Git, PostgreSQL u otro sistema, mientras que los embeddings y metadatos se almacenan por separado para una búsqueda semántica rápida. Algunos sistemas sí usan un almacén vectorial como almacenamiento primario, pero eso es una elección arquitectónica más que un requisito de RAG.

Si el límite entre recuperación, memoria persistente, estado actual y contexto del modelo aún no está claro, consulte La memoria del agente de IA no es RAG. Esas capas pueden usar algunas de las mismas tecnologías de almacenamiento y aun así tener reglas de corrección diferentes.

Supuestos

• La aplicación tiene permitido acceder a la fuente externa.
• La fuente relevante contiene suficiente información para responder la pregunta.
• Los datos pueden analizarse o consultarse en una forma que la capa de recuperación pueda usar.
• La información recuperada es lo suficientemente reciente para la decisión solicitada.
• El modelo recibe la evidencia seleccionada en su contexto.
• La autorización se aplica antes de que la evidencia protegida llegue al modelo.
• El modelo de generación aún puede equivocarse incluso cuando la recuperación es correcta.

Estos supuestos importan porque la recuperación no puede compensar evidencia faltante, versiones obsoletas de la fuente, analizadores defectuosos o acceso no autorizado. Un pipeline RAG solo puede ser tan confiable como la ruta de evidencia que lo alimenta.

Variables

Método de diagnóstico / decisión

La primera decisión no es "¿Qué base de datos vectorial debería instalar?" Es: ¿Qué tipo de hecho estoy tratando de recuperar?

Una prueba útil es: ¿Ya sé qué registro necesito, o el sistema debe descubrir qué pasaje es relevante? Si el registro se conoce, consúltalo directamente. Si la relevancia debe descubrirse, la búsqueda cobra mayor importancia.

Cuando una respuesta es incorrecta, diagnostica el pipeline en orden en lugar de cambiar inmediatamente el LLM:

1. 1. Cobertura de fuentes: ¿Existe la información correcta en el conjunto de fuentes accesibles?
2. 2. Frescura: ¿Es esa versión lo suficientemente actual para la pregunta?
3. 3. Análisis: ¿Se extrajo correctamente el contenido relevante?
4. 4. Fragmentación: ¿Permaneció la evidencia junto con las condiciones que le dan significado?
5. 5. Recuperación: ¿Aparece el fragmento correcto entre los candidatos?
6. 6. Clasificación: ¿Están las fuentes más sólidas clasificadas por encima de las más débiles o conflictivas?
7. 7. Ensamblaje del contexto: ¿Envió realmente la aplicación la evidencia seleccionada al modelo?
8. 8. Generación: ¿Utilizó el LLM fielmente la evidencia proporcionada?
9. 9. Atribución: ¿Se puede rastrear cada afirmación importante hasta una fuente?

Para un método más profundo de depuración en producción, consulta RAG Failed — But Which Layer Actually Failed? A Diagnostic Method, que amplía esta cadena en capas de fallo comprobables de forma independiente.

Evidencia

El artículo de RAG de Lewis et al. formalizó la generación que se condiciona a la memoria externa recuperada en lugar de depender solo de los parámetros del modelo. Eso proporciona la base conceptual para separar el generador de una fuente de conocimiento recuperable.

Sentence Transformers documenta la búsqueda semántica como incrustar el corpus y la consulta en un espacio vectorial y recuperar elementos con alta similitud semántica. Su API actual también distingue la codificación de consultas de la codificación de documentos para tareas de recuperación.

SQLite FTS5 demuestra el otro lado del espectro: la recuperación de texto completo madura puede clasificar documentos sin incrustaciones. Esto importa porque la búsqueda léxica sigue siendo valiosa para identificadores, terminología exacta y muchos diseños de recuperación híbrida.

La documentación de incrustaciones de OpenAI describe las incrustaciones como representaciones vectoriales numéricas utilizadas para la relación y la búsqueda. Esta es una ruta de implementación para la recuperación semántica, no la definición de RAG en sí.

Ejemplo real 1: Una carpeta de archivos de texto

Supongamos que un directorio llamado knowledge/ contiene archivos de texto ordinarios. Python puede cargarlos sin ninguna biblioteca de IA.

from pathlib import Path

def load_text_files(folder="knowledge"):
    documents = []

    for path in Path(folder).glob("*.txt"):
        documents.append({
            "source": path.name,
            "text": path.read_text(encoding="utf-8")
        })

    return documents

documents = load_text_files()

for document in documents:
    print(document["source"], len(document["text"]))

El sistema de archivos es la fuente de datos. La siguiente pregunta es cuánto texto debe convertirse en una unidad recuperable. Para documentos largos, buscar un archivo completo suele ser demasiado grueso. Por eso los pipelines de RAG comúnmente crean fragmentos.

Un fragmentador muy simple

def chunk_text(text, max_chars=800):
    paragraphs = [p.strip() for p in text.split("\n\n") if p.strip()]

    chunks = []
    current = ""

    for paragraph in paragraphs:
        candidate = f"{current}\n\n{paragraph}".strip()

        if current and len(candidate) > max_chars:
            chunks.append(current)
            current = paragraph
        else:
            current = candidate

    if current:
        chunks.append(current)

    return chunks

Este ejemplo agrupa párrafos hasta alcanzar un límite aproximado de caracteres. Es intencionalmente comprensible en lugar de óptimo. Los sistemas de producción a menudo fragmentan por tokens, encabezados, secciones, límites de oraciones o estructura del documento. Las tablas, el código fuente, los contratos y la documentación de API pueden necesitar estrategias diferentes.

Preservar la procedencia al dividir en fragmentos

def build_chunks(documents):
    chunks = []

    for document in documents:
        for index, text in enumerate(chunk_text(document["text"])):
            chunks.append({
                "id": f'{document["source"]}:{index}',
                "source": document["source"],
                "chunk": index,
                "text": text,
            })

    return chunks

Un fragmento útil lleva más que texto. El nombre de la fuente, el ID del documento, la URL, la marca de tiempo, la versión o la sección pueden respaldar más adelante la citación, la depuración y las comprobaciones de actualidad. Si la procedencia se pierde durante la ingesta, resulta mucho más difícil explicar por qué se produjo una respuesta concreta.

Ejemplo real 2: Datos estructurados — Use SQL cuando SQL es la herramienta adecuada

No todo hecho externo debe pasar por la búsqueda semántica. Si la pregunta solicita un registro actual exacto, una consulta directa a la base de datos suele ser más clara y más determinista.

import sqlite3

def get_order_status(order_id):
    connection = sqlite3.connect("shop.db")
    cursor = connection.cursor()

    cursor.execute(
        "SELECT status, total, currency FROM orders WHERE id = ?",
        (order_id,)
    )

    row = cursor.fetchone()
    connection.close()

    if row is None:
        return None

    return {
        "order_id": order_id,
        "status": row[0],
        "total": row[1],
        "currency": row[2],
    }

print(get_order_status(4711))

Si la aplicación ya sabe que el usuario está preguntando por el pedido 4711, incrustar toda la tabla de pedidos y pedirle a la búsqueda semántica que redescubra esa fila normalmente añade complejidad sin beneficio. Una regla de diseño sólida es: recupere hechos estructurados con consultas estructuradas; recupere conocimiento no estructurado con búsqueda.

La fila de base de datos devuelta aún puede colocarse en el contexto del modelo para que el LLM pueda explicarla en lenguaje natural. Pero el acceso directo al estado o a un registro es conceptualmente diferente de buscar en un corpus de conocimiento.

Ejemplo real 3: Búsqueda de texto completo antes de las incrustaciones

Entre un bucle ingenuo de Python y la búsqueda vectorial se encuentra una clase madura de sistemas de recuperación léxica. SQLite incluye FTS5 para búsqueda de texto completo, incluido el ranking BM25.

import sqlite3

connection = sqlite3.connect("knowledge.db")
cursor = connection.cursor()

cursor.execute(
    "CREATE VIRTUAL TABLE IF NOT EXISTS docs USING fts5(title, body)"
)

cursor.execute(
    "INSERT INTO docs(title, body) VALUES (?, ?)",
    ("AKM", "The AKM uses 7.62 mm ammunition.")
)

connection.commit()

query = "AKM ammunition"

rows = cursor.execute(
    "SELECT title, body, bm25(docs) AS score "
    "FROM docs WHERE docs MATCH ? "
    "ORDER BY score LIMIT 5",
    (query,)
).fetchall()

for row in rows:
    print(row)

connection.close()

La búsqueda léxica es especialmente útil cuando importan la terminología exacta, los códigos de producto, los nombres, los identificadores o las palabras específicas del dominio. La búsqueda semántica no es automáticamente mejor. Los sistemas de producción a menudo combinan ambas señales.

Ejemplo real 4: Recuperación semántica con incrustaciones

Las incrustaciones convierten el texto en vectores numéricos para que los pasajes semánticamente relacionados puedan compararse incluso cuando no usan una redacción idéntica. Sentence Transformers proporciona una implementación local sencilla.

# pip install sentence-transformers

from sentence_transformers import SentenceTransformer, util

documents = [
    "The AKM uses 7.62 mm ammunition.",
    "A Med Kit restores health.",
    "Vehicle maintenance includes checking oil, brakes and tires.",
    "Account recovery requires access to the registered email address."
]

model = SentenceTransformer(
    "sentence-transformers/multi-qa-mpnet-base-cos-v1"
)

document_embeddings = model.encode_document(
    documents,
    convert_to_tensor=True
)

question = "How do I repair my car?"

query_embedding = model.encode_query(
    question,
    convert_to_tensor=True
)

hits = util.semantic_search(
    query_embedding,
    document_embeddings,
    top_k=2
)[0]

for hit in hits:
    print(round(float(hit["score"]), 3), documents[hit["corpus_id"]])

La consulta no contiene la frase “mantenimiento de vehículos”, pero un modelo semántico aún puede clasificar ese pasaje en un puesto alto porque los conceptos están relacionados. Esta es la razón práctica por la que las incrustaciones son comunes en los sistemas RAG.

Para colecciones pequeñas, las incrustaciones pueden permanecer en memoria. Los sistemas más grandes normalmente las persisten en un índice o base de datos con capacidad vectorial y realizan allí la búsqueda de vecinos más cercanos. El almacenamiento cambia, pero la lógica permanece: codificar la pregunta, encontrar representaciones de documentos relevantes, devolver la mejor evidencia.

Ejemplo real 5: Construir el contexto para el LLM

Un recuperador debe devolver evidencia. El LLM debe entonces recibir la pregunta más esa evidencia. Mantener la recuperación y la generación separadas hace que ambas sean más fáciles de inspeccionar y probar.

def build_prompt(question, retrieved_documents):
    context = "\n\n".join(
        f'[{doc["id"]}] {doc["text"]}'
        for doc in retrieved_documents
    )

    return f"""
Answer the question using the supplied context.

Rules:
- Do not invent facts that are not supported by the context.
- If the context is insufficient, say so.
- Cite the source IDs you used.

Question:
{question}

Context:
{context}
""".strip()

La instrucción no hace que el modelo sea infalible. Simplemente crea un límite de evidencia explícito. El modelo aún puede malinterpretar buena evidencia, ignorar una condición o generalizar en exceso. Por eso la calidad de la recuperación y la calidad de la generación deben evaluarse por separado.

Ejemplo real 6: Un pipeline mínimo completo

def answer_question(question, all_documents, call_llm):
    # 1. Retrieve evidence
    retrieved = retrieve(question, all_documents, top_k=3)

    # 2. Build model context
    prompt = build_prompt(question, retrieved)

    # 3. Generate the answer
    answer = call_llm(prompt)

    return {
        "answer": answer,
        "sources": [doc["id"] for doc in retrieved]
    }

La función recibe call_llm como dependencia a propósito. A la recuperación no debería importarle si la generación la realiza un modelo en la nube, un modelo local u otro proveedor. La ruta de datos pertenece a la aplicación.

Generador opcional: API de Responses de OpenAI

Un generador posible es la API de Responses de OpenAI. Mantener el nombre del modelo en una variable de entorno evita codificar de forma rígida un modelo concreto en la arquitectura RAG.

# pip install openai

import os
from openai import OpenAI

client = OpenAI()

def call_llm(prompt):
    response = client.responses.create(
        model=os.environ["OPENAI_MODEL"],
        input=prompt,
    )
    return response.output_text

El mismo pipeline de recuperación puede conectarse a un servidor de inferencia local. Este es un punto arquitectónico importante: RAG no es propiedad del proveedor del LLM. La aplicación es dueña de la fuente, la recuperación y el ensamblaje del contexto.

Toda la arquitectura en una vista

USER QUESTION
     |
     v
+-------------+
|  Retriever  |
+-------------+
   |       |
   |       +----> SQL / API / state query
   |
   +------------> keyword / full-text search
   |
   +------------> embedding / vector search
                     |
                     v
              relevant evidence
                     |
                     v
+-----------------------------------+
| question + evidence + instructions |
+-----------------------------------+
                     |
                     v
                   LLM
                     |
                     v
                  answer

Este modelo de flujo de datos es más duradero que memorizar un framework. Las bibliotecas, las bases de datos y los proveedores de modelos cambiarán; los límites de responsabilidad permanecen.

Conceptos erróneos comunes y modos de fallo

“RAG significa base de datos vectorial.”

No. La búsqueda vectorial es un método de recuperación. RAG puede usar búsqueda de texto completo, SQL, API, grafos de conocimiento, búsqueda vectorial o combinaciones de ellos. El patrón que lo define es la recuperación de información externa para la generación.

“Si los datos están en PostgreSQL, debo incrustar toda la base de datos.”

No. Los registros estructurados normalmente deben seguir siendo consultables como registros estructurados. Los embeddings son útiles para la relevancia semántica, no como reemplazo de consultas deterministas.

“Más fragmentos significa una mejor respuesta.”

No necesariamente. El contexto adicional puede introducir ruido, versiones en conflicto y material irrelevante. La recuperación debe optimizar para evidencia útil, no para el volumen máximo.

“Una puntuación de similitud alta demuestra la respuesta.”

No. La similitud mide la relevancia, no la verdad ni la aplicabilidad. Un pasaje altamente similar puede estar desactualizado, provenir de la versión incorrecta del producto o ser válido solo bajo condiciones que no coinciden con la pregunta.

“Una vez que se recupera el fragmento correcto, la alucinación está resuelta.”

No. La recuperación mejora el anclaje pero no garantiza un razonamiento fiel. La generación aún necesita evaluación, y los flujos de trabajo de alto riesgo pueden requerir validación determinista o revisión humana.

“El modelo falló, así que cambia el modelo.”

No necesariamente. La fuente correcta puede haber faltado, haberse analizado incorrectamente, dividido mal, filtrado, clasificado demasiado bajo u omitido del contexto ensamblado. El reemplazo del modelo no debería ser el primer paso de diagnóstico.

Casos límite

• Documentos en conflicto: dos fuentes pueden discrepar porque las versiones, jurisdicciones o productos difieren.
• Hechos sensibles al tiempo: una fuente semánticamente relevante puede ya estar obsoleta.
• Permisos: un recuperador no debe devolver documentos a los que el usuario actual no está autorizado a acceder.
• Colecciones multilingües: el modelo de incrustación y la estrategia de recuperación deben admitir los idiomas realmente utilizados.
• Tablas y código fuente: la división en párrafos simples puede destruir la estructura que es esencial para la respuesta.
• Identificadores muy cortos: la recuperación semántica puede ser más débil que la coincidencia exacta para SKU, ID, códigos de error o acrónimos.
• Preguntas largas que requieren varios hechos: la recuperación puede necesitar descomposición, varias búsquedas o reclasificación en lugar de una sola consulta top-k.
• Jerarquía de fuentes: una política oficial actual puede necesitar superar a un documento de discusión más antiguo pero semánticamente más cercano.

Limitaciones

Los ejemplos de Python optimizan intencionalmente la transparencia, no la escala. El recuperador de palabras clave es ingenuo, el fragmentador usa longitud de caracteres, los ejemplos de SQLite no incluyen gestión de conexiones de producción, y el ejemplo semántico mantiene todas las incrustaciones en memoria.

Un sistema de producción puede requerir índices vectoriales, reclasificadores, recuperación híbrida, analizadores de documentos, almacenamiento en caché, indexación incremental, versionado de fuentes, filtros de control de acceso, observabilidad, conjuntos de datos de evaluación y manejo de fallos. Ninguna de esas adiciones cambia la arquitectura central; hacen que cada límite sea más confiable.

RAG tampoco puede crear evidencia que esté ausente del conjunto de fuentes. Si la fuente es incorrecta, incompleta u obsoleta, un mejor modelo de incrustación no puede convertirla en conocimiento autorizado.

¿Qué cambiaría esta respuesta?

La arquitectura cambia cuando la tarea requiere más que una búsqueda de conocimiento. Un estado de pedido en vivo necesita el estado actual. Un cálculo financiero puede necesitar código determinista. Una tarea de investigación web puede necesitar búsqueda activa. Un flujo de trabajo puede necesitar herramientas que puedan escribir datos de vuelta a otro sistema. Un agente autónomo puede necesitar planificación, permisos y control de ejecución además de la recuperación.

Por lo tanto, RAG se entiende mejor como una capa de adquisición de evidencia dentro de un sistema de IA más grande. Es poderoso precisamente porque tiene un trabajo limitado: encontrar información externa útil y colocarla en el contexto de trabajo del modelo.

Conclusión

RAG se vuelve mucho más fácil de entender cuando se eliminan los nombres de las tecnologías. Un archivo es una fuente. Una base de datos es una fuente. Una API es una fuente. Una función de búsqueda recupera evidencia. Un prompt lleva esa evidencia al modelo. El LLM luego la interpreta y produce lenguaje.

La parte difícil de RAG en producción no es llamar a un modelo de embeddings. Es construir una ruta de evidencia confiable desde la fuente original hasta la afirmación final: preservar la procedencia, seleccionar el método de recuperación adecuado, mantener la información actualizada, controlar el acceso, evaluar la recuperación por separado de la generación y saber cuándo una llamada directa a una base de datos o a una herramienta es mejor que la búsqueda semántica.

Esa es la continuación práctica del modelo básico de RAG: primero entender los roles, luego hacer explícita la ruta de datos.

Fuentes primarias

• Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — el artículo de 2020 que introdujo la formulación de RAG que combina la generación con memoria no paramétrica recuperada.
• Sentence Transformers — Semantic Search — documentación oficial para la recuperación semántica, embeddings de consultas y embeddings de documentos.
• OpenAI — Vector Embeddings — documentación oficial que describe los embeddings como representaciones numéricas utilizadas para la relación y la búsqueda.
• SQLite — FTS5 Extension — documentación oficial para la búsqueda de texto completo y la clasificación BM25 en SQLite.
• OpenAI — SDKs and CLI — ejemplo oficial del SDK de Python para la API de Responses utilizado en el ejemplo opcional del generador.
• What Is RAG? The Simplest Explanation of How It Works — la primera parte conceptual de esta serie.