Inteligencia Artificial

Cómo entrenar un modelo pequeño de IA con tus propios documentos de texto para responder preguntas

Implementa una arquitectura RAG local con código abierto para que una IA entienda los manuales internos y protocolos de tu organización sin exponer datos en la nube.

Eduardo Rodrigues Silva
Eduardo Rodrigues SilvaEditor Jefe de Infraestructura y Redes
Imagen editorial que ilustra Cómo entrenar un modelo pequeño de IA con tus propios documentos de texto para responder preguntas

El problema al que nos enfrentamos los jefes de infraestructura en 2026 no es la falta de modelos de lenguaje, sino su desconocimiento total sobre la realidad operativa de nuestras empresas. Un LLM (Large Language Model) generalista puede escribir código en Python o sonetas en verso, pero ignora por completo el procedimiento de contingencia del servidor IBM Power8 que vive en el sótano o el protocolo específico de facturación de 2022 que solo existe en un PDF corrupto. Enviando esos datos a una API pública, violamos las políticas de cumplimiento de datos (GDPR, HIPAA, SOC2).

La solución no es "entrenar" un modelo desde cero —algo costoso e innecesario— sino inyectar conocimiento contextual utilizando una arquitectura de Generación Aumentada por Recuperación (RAG). He implementado esto en tres organizaciones este año, y la diferencia en eficiencia operativa es abismal. Vamos a configurar un sistema RAG utilizando software de código abierto que reside enteramente en tu hardware.

Paso 1: Selección del hardware y el motor de inferencia local

Antes de escribir una sola línea de código, debemos ser realistas sobre el hardware. No intentes ejecutar esto en la laptop del departamento de marketing. Para una experiencia fluida con documentos de texto empresariales, recomiendo una estación de trabajo con al menos una GPU NVIDIA con 24 GB de VRAM (como una RTX 4090 o una A4000) o un Apple Silicon M2/M3 Max con memoria unificada alta.

El motor que utilizaremos para ejecutar el modelo es Ollama. Ha estandarizado el despliegue local en Linux. No pierdas tiempo compilando GGML manualmente a menos que tengas una razón muy específica para optimizar al milisegundo.

Para este proyecto, utilizaremos el modelo Llama 3:8b-instruct-q8_0. La versión de 8 mil millones de parámetros cuantizada a 8 bits ofrece el mejor equilibrio entre comprensión semántica y velocidad de inferencia en hardware de consumidor. Instala Ollama y descarga el modelo:

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3:8b-instruct-q8_0

Verifica que el servicio esté escuchando en el puerto 11434. Este será nuestro cerebro. Es fundamental elegir un modelo instructo (fine-tuned para chat), ya que un modelo base (raw) tendrá dificultades para seguir las instrucciones del sistema que definiremos más adelante.

Paso 2: Ingesta y limpieza de documentos

El mayor fracaso en los proyectos de RAG ocurre aquí: la basura entra, basura sale. Tus documentos probablemente sean una mezcla de PDFs escaneados, archivos Word de 2010 y HTML exportado desde Confluence. Necesitamos una tubería (pipeline) de ingestión robusta.

Utilizaremos Python con la librería Unstructured. Es superior a PyPDF para este propósito porque puede manejar tablas y encabezados complejos sin perder el contexto estructural.

Crea un entorno virtual e instala las dependencias necesarias:

pip install "unstructured[all-local]" langchain-community langchain-core langchain-ollama chromadb tiktoken

El script de ingestá debe hacer más que leer texto; debe dividirlo en "chunks" (fragmentos). Si alimentas al modelo con documentos enteros, superarás la ventana de contexto. Si los fragmentos son demasiado pequeños (menos de 100 tokens), pierdes el significado semántico. He encontrado que un tamaño de fragmento de 1000 caracteres con una superposición (overlap) de 200 caracteres funciona mejor para manuales técnicos y documentación legal.

Aquí es donde muchos ingenieros cometen el error de no filtrar el ruido. Elimina encabezados y pies de página que se repiten en cada página (como "Confidencial - Página X de Y"). Si no lo haces, tu vectorial se contaminará con metadatos irrelevantes, y la IA alucinará pensando que "Página 1" es un concepto importante.

¿Por qué RAG y no Fine-Tuning para documentos?

Muchos gerentes de TI preguntan por qué no hacemos "fine-tuning" (ajuste fino) del modelo con nuestros datos. La respuesta corta es: el conocimiento factual cambia más rápido que el razonamiento. Si cambias una dirección IP en tu documento de red hoy, un modelo fine-tuned ayer seguirá recordando la vieja hasta que lo reentrenes. Un sistema RAG, en cambio, recupera la información en tiempo real desde la fuente de verdad.

Además, el fine-tuning es propenso a la "catástrofe del olvido", donde el modelo pierde capacidad generalista para aprender datos específicos. Manteniendo el modelo separado de la base de conocimiento, puedes actualizar tus manuales de procedimiento sin necesidad de reentrenar la red neuronal. Esto es vital para mantener los costes operativos bajos.

[Link Contextual: Discutimos con más profundidad las ventajas de mantener modelos localizados frente a la nube en nuestro análisis sobre LLMs Locales (Llama 3) vs. GPT-4.]

Paso 3: Vectorización y almacenamiento con ChromaDB

Una vez que tenemos el texto limpio y fragmentado, necesitamos convertirlo en vectores (números) que el modelo pueda entender matemáticamente. Este proceso se llama "embedding".

Para mantener la privacidad total, no utilizaremos la API de embeddings de OpenAI. En su lugar, usaremos un modelo de embeddings que se ejecute localmente a través de Ollama. El modelo nomic-embed-text ha demostrado ser excelente para retener el significado de textos técnicos en español e inglés. Es ligero y sorprendentemente preciso para corpus de datos de tamaño medio.

Configuraremos ChromaDB como nuestra base vectorial. Es open source, persistente y se ejecuta como un servidor ligero. A diferencia de Pinecone o Milvus en la nube, ChromaDB te da el control absoluto sobre dónde se almacenan los bits de tu propiedad intelectual.

Detalle fotográfico relacionado con Cómo entrenar un modelo pequeño de IA con tus propios documentos de texto para responder preguntas

El código para crear la colección e indexar los documentos se vería conceptualmente así (asumiendo que documents es tu lista de fragmentos de texto):

from langchain_ollama import OllamaEmbeddings
from langchain_chroma import Chroma

embeddings = OllamaEmbeddings(model="nomic-embed-text")
vectorstore = Chroma.from_documents(
    documents=documents, 
    embedding=embeddings,
    persist_directory="./chroma_db"
)

Ejecuta este script una vez por cada lote de documentos que desees indexar. ChromaDB guardará los vectores en el disco, por lo que no tendrás que reindexar cada vez que reinicies el servidor. En mis pruebas, una base de 5000 páginas de documentación técnica ocupa aproximadamente 2 GB en disco, algo trivial para cualquier almacenamiento moderno.

Paso 4: Construcción del pipeline de recuperación y respuesta

Aquí es donde la magia sucede. No solo buscamos palabras clave; buscamos similitud semántica. Cuando un usuario pregunta "¿Cómo reseteo el firewall?", el sistema buscará fragmentos que contengan el concepto de "restablecer configuración de red" o "reinicio por defecto", aunque las palabras exactas no coincidan.

Debes configurar un "retriever" (recuperador) que busque los 4 fragmentos más relevantes (k=4). ¿Por qué solo cuatro? Porque si enviamos demasiada información al prompt, el modelo se confunde o supera el límite de tokens de contexto. Cuatro fragmentos suelen ser suficientes para contestar una pregunta técnica específica sin ruido excesivo.

El siguiente paso es construir la cadena (chain) en LangChain:

from langchain_ollama import ChatOllama
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough

llm = ChatOllama(model="llama3:8b-instruct-q8_0")

prompt = ChatPromptTemplate.from_template("""
Responde a la pregunta basándote EXCLUSIVAMENTE en el siguiente contexto. 
Si no sabes la respuesta basada en el contexto, di claramente "No lo sé". 
No inventes información.

Contexto: {context}

Pregunta: {question}
Respuesta:
""")

def format_docs(docs):
    return "\n\n".join(doc.page_content for doc in docs)

retriever = vectorstore.as_retriever(search_kwargs={"k": 4})

chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | prompt
    | llm
)

Aquí radica la diferencia entre un sistema útil y un juguete. El prompt del sistema es estricto. Debes instruir al modelo para que admita la ignorancia. Si no lo haces, el modelo intentará complacer al usuario inventando datos, lo que en ingeniería de redes o procedimientos médicos puede ser desastroso. Hemos visto casos de alucinaciones en código SQL que borraron tablas enteras por falta de este freno de seguridad.

Paso 5: Despliegue y exposición de la API

Ahora que el cerebro funciona localmente, necesitas exponerlo a los usuarios. No des acceso directo a la terminal de Ollama a los empleados de contabilidad. Envuelve tu cadena chain en una API simple usando FastAPI.

FastAPI es rápido, asíncrono y genera documentación automática (Swagger UI), lo cual es una bendición para los otros desarrolladores que necesiten integrar este servicio en sus aplicaciones internas.

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Query(BaseModel):
    text: str

@app.post("/preguntar")
def preguntar(query: Query):
    response = chain.invoke(query.text)
    return {"respuesta": response.content}

Ejecuta esto con uvicorn main:app --host 0.0.0.0 --port 8000. Ahora tienes un punto final HTTP interno que acepta preguntas sobre tus documentos y devuelve respuestas generadas por una IA que nunca ha visto internet, solo tus manuales.

El reto de la latencia y la infraestructura

No todo es perfecto. El cuello de botella en esta arquitectura suele ser la generación de texto (inferencia) y no la búsqueda vectorial. En un RTX 4090, un modelo de 8B genera tokens a una velocidad decente, pero si tienes 50 empleados consultando el sistema simultáneamente, la cola de solicitudes se disparará.

Para mitigar esto en 2026, he empezado a implementar "KV Caching" a nivel de servidor y balanceadores de carga simples que dirigen el tráfico a múltiples instancias de Ollama si la GPU se satura. Sin embargo, para una base de conocimiento de uso medio (10-20 usuarios concurrentes), una sola GPU potente suele ser suficiente.

Otro factor crítico es la actualización. Si un documento cambia, el script de ingestá debe volver a ejecutarse sobre ese archivo específico. He automatizado esto con un "watcher" en Python que monitorea la carpeta de documentos; si detecta un cambio en el timestamp de un archivo, re-indexa ese contenido en ChromaDB. Esto asegura que la IA no esté respondiendo con información obsoleta.

Conclusión: La soberanía del conocimiento corporativo

Construir un sistema RAG local no es solo una cuestión de tecnología, es una declaración de soberanía sobre el conocimiento de tu empresa. Al finalizar esta implementación, tendrás una herramienta que entiende la jerga específica de tu sector, conoce la historia de tus sistemas y, lo más importante, guarda tus secretos dentro de tu perímetro de red.

El costo de entrada ha bajado drásticamente. Con un presupuesto de hardware de unos 3000 euros y software gratuito, puedes replicar funcionalidades que antes costaban decenas de miles de dólares en licencias SaaS anuales. La IA general es fascinante, pero la IA especializada y privada es la que realmente impulsa el negocio. Deja de preocuparte por si tu modelo es "lo suficientemente grande" y empieza a preocuparte por si tus datos están lo suficientemente bien estructurados para ser recuperados.

Lee a continuación