RAG privado en tu propio hardware con Ollama y LLaMA 3

Algunos documentos nunca pueden acercarse a una API de terceros — historiales médicos, evidencia legal, finanzas internas. Para esos, "solo llama a OpenAI" no es opción. La buena noticia es que un stack de RAG totalmente local ya es de verdad lanzable. La noticia honesta es que te cuesta algo de calidad, y deberías saber exactamente dónde.

Todo el pipeline corre en una sola máquina

RAG tiene tres partes móviles, y las tres tienen opciones locales. Los embeddings convierten texto en vectores — un sentence-transformer pequeño corre bien en CPU. Un vector store guarda esos vectores; para una sola máquina, un store embebido como pgvector local o incluso un índice en memoria sobra. Y la generación es un modelo local servido por Ollama. Nada cruza la red.

// rag/answer.ts — retrieve locally, generate locally, never leave the box.
import { embed, search } from "./store";
import { ollama } from "./ollama";

export async function answer(question: string) {
  const queryVec = await embed(question);          // local embeddings
  const chunks = await search(queryVec, { topK: 5 });

  const context = chunks.map((c) => c.text).join("\n---\n");
  return ollama.generate({
    model: "llama3:8b",
    prompt: `Answer using only the context.\n\n${context}\n\nQ: ${question}`,
  });
}

Ese es todo el camino caliente: genera el embedding de la pregunta, trae los k fragmentos más relevantes, métela en el prompt y deja que un LLaMA 3 local genere la respuesta. Los fragmentos son el anclaje — el modelo no recuerda hechos, lee los pocos pasajes que le entregaste.

Dónde lo local gana de verdad

• Los datos nunca salen. Ese es todo el punto. Sin negociar un DPA, sin la ansiedad de "¿hay PII en algún log?", sin una factura por token que escala con el uso.
• El costo es fijo. Una vez pagado el hardware, mil consultas cuestan lo mismo que diez. Para herramientas internas de alto volumen, eso da vuelta la economía por completo.
• La latencia es predecible. Sin límites de tasa, sin ralentizaciones por vecinos ruidosos. Un modelo local caliente responde a un ritmo estable.

Dónde la nube sigue ganando — sé honesto al respecto

Un modelo local de 8B no es un modelo de frontera, y fingir lo contrario quema confianza. En razonamiento genuinamente difícil — síntesis de varios pasos, instrucciones sutiles, coherencia en contexto largo — un modelo de frontera hospedado sigue siendo notablemente mejor. La calidad de recuperación importa más que el tamaño del modelo aquí, pero no borra la brecha.

Haz de la recuperación lo que afinas

La mayor palanca de calidad en un stack local no es el modelo — es lo que pones delante de él. Fragmenta los documentos con criterio (los límites semánticos le ganan a las ventanas de tokens fijas), afina tu top-k y añade un paso de re-ranking si el recall es ruidoso. Un modelo mediocre con recuperación excelente le gana a un gran modelo alimentado con contexto irrelevante, siempre.

El RAG local no se trata de igualar a la nube en todo. Se trata de ser lo bastante bueno en el 90% de las preguntas donde mantener los datos en casa es innegociable.

Empieza con el pipeline local, mídelo contra preguntas reales de usuarios reales, y solo recurre a la nube en las consultas que demostrablemente lo necesiten — suponiendo que la política de datos siquiera lo permita. Para un número sorprendente de herramientas internas, nunca hace falta.