Conclusiones clave
- AnythingLLM tuvo la tasa de alucinaciones más baja en el corpus de 5.047 páginas (6%, frente al 11% de PrivateGPT y el 14% de Open WebUI) y produjo las únicas respuestas consistentemente citables con nombre de archivo y número de página.
- PrivateGPT tuvo la latencia de recuperación más baja (p50 de 240 ms, p95 de 720 ms) y la postura offline más limpia — sin SDKs de telemetría, sin fallbacks a la nube, sin llamadas de red ocultas.
- Open WebUI tuvo la mejor ergonomía operativa para despliegues compartidos — cuentas multi-usuario, OAuth, acceso a documentos basado en roles, integración con Ollama en dos clics.
- Las tres plataformas se degradan entre 8.000 y 12.000 páginas en hardware de consumo: el tiempo de indexación escala de forma lineal, pero el recall de recuperación cae cuando la base de datos vectorial supera la RAM.
- Cambiar los modelos de embedding fuerza una re-indexación completa en las tres. Reserva entre 30 y 90 minutos por cada 5.000 páginas y entre 4 y 8 GB de memoria GPU durante el proceso de indexación.
- El almacenamiento de la base de datos vectorial en disco es de 40 a 120 MB por cada 1.000 páginas según el tamaño del chunk y las dimensiones del embedding — un corpus de 50.000 páginas necesita entre 2 y 6 GB solo para vectores.
- Para bibliotecas que crecerán más allá de 10.000 páginas, considera un stack personalizado con Ollama + Qdrant o Weaviate — los almacenes vectoriales integrados en estas tres plataformas no están diseñados para esa escala.
¿Cómo se comparan AnythingLLM, PrivateGPT y Open WebUI en 2026?
Probado en un corpus de 5.047 páginas (artículos de investigación, contratos, un manual técnico y exportaciones de wikis internos) usando Llama 3.3 8B Q4_K_M como modelo de chat y el embedder por defecto de cada plataforma. Hardware: NVIDIA RTX 4070 (12 GB VRAM, 32 GB de RAM del sistema) en Windows 11; verificación cruzada en un MacBook Pro M5 (16 GB unificado). Los números son medianas de tres ejecuciones.
📍 En una frase
AnythingLLM tuvo la tasa de alucinaciones más baja (6%) y la mejor calidad de citas en un corpus de 5.000 páginas; PrivateGPT tuvo la latencia de recuperación más baja y la postura offline más limpia; Open WebUI tuvo el mejor soporte multi-usuario y OAuth para despliegues compartidos.
💬 En términos simples
Elige AnythingLLM si quieres la configuración más sencilla y la mejor precisión de respuestas para una biblioteca de documentos personal (menos de 3.000 docs). Elige PrivateGPT si necesitas operación offline garantizada sin dependencias en la nube. Elige Open WebUI si varias personas necesitan compartir el mismo sistema RAG con cuentas separadas y controles de acceso.
| Característica | AnythingLLM | PrivateGPT | Open WebUI |
|---|---|---|---|
| Tiempo de instalación (instalación nueva → primera consulta) | ~8 min (instalador de escritorio) | ~25 min (Python + Poetry + descarga del modelo) | ~12 min (Docker compose + Ollama) |
| Flexibilidad de embedding | 8 backends (Native, Ollama, LM Studio, OpenAI, Azure, Cohere, Voyage, LocalAI) | HuggingFace embeddings (cualquier modelo sentence-transformers) | Embeddings servidos por Ollama + SentenceTransformers + compatible con OpenAI |
| Opciones de estrategia de chunk | Tamaño + solapamiento expuestos; por espacio de trabajo | Pipeline LlamaIndex completo (semántico, ventana de oración, jerárquico) | Tamaño + solapamiento; defecto global + override por documento |
| Latencia de recuperación (p50 / p95) | 310 ms / 880 ms | 240 ms / 720 ms | 380 ms / 1.040 ms |
| Tasa de alucinaciones (50 consultas valoradas) | 6% | 11% | 14% |
| Calidad de las citas | Nombre de archivo + página; clicable en línea | Nombre de archivo + ID de chunk; JSON estructurado | Solo nombre de archivo; sin números de página |
| Límite de escalabilidad (hardware de consumo) | ~10.000 páginas / ~3.000 docs | ~12.000 páginas / ~5.000 docs | ~8.000 páginas / ~2.000 docs |
| Mejor para | Bibliotecas de documentos de grado producción con citas | Cumplimiento en la UE, diseño offline, integración API-first | Frontend de chat multi-usuario con RAG opcional |
¿Cuál deberías elegir?
La elección correcta depende de si necesitas citas para trabajo posterior, si la postura de cumplimiento importa y si otras personas compartirán el despliegue. Usa este atajo de decisión:
| Tu situación | Elige |
|---|---|
| Necesito respuestas con citas que pueda pegar en un trabajo de investigación | AnythingLLM |
| Soy un equipo de una persona con 50–500 PDFs y quiero RAG de grado producción | AnythingLLM |
| Necesito un despliegue offline para un equipo regulado por la UE | PrivateGPT |
| Quiero un servicio Python que pueda llamar desde mi propio backend | PrivateGPT |
| Necesito cambiar modelos de embedding y comparar la calidad de recuperación | PrivateGPT |
| Ya ejecuto Ollama y quiero una interfaz de chat multi-usuario | Open WebUI |
| Mi equipo necesita inicio de sesión OAuth y acceso a documentos por usuario | Open WebUI |
| Tengo más de 10.000 páginas y seguirán creciendo | Stack personalizado con Ollama + Qdrant/Weaviate (ninguna de las tres) |
Cómo probamos las 3 plataformas en un corpus de 5.047 páginas
Los mismos documentos, el mismo modelo de chat (Llama 3.3 8B Q4_K_M), las mismas 50 consultas valoradas. Lo que aislamos fue la calidad del RAG, no la calidad del chat.
- Hardware: NVIDIA RTX 4070 (12 GB VRAM, 32 GB de RAM del sistema) en Windows 11 como sistema principal; MacBook Pro M5 (16 GB de memoria unificada) como verificación cruzada. Los números de latencia provienen de la ejecución en RTX 4070.
- Corpus: 5.047 páginas abarcando cuatro tipos de contenido — un manual de control industrial de 1.047 páginas (figuras, tablas, ecuaciones), un contrato de arrendamiento comercial de 38 páginas (texto legal denso), un artículo de investigación sobre transformadores de 412 páginas y una exportación de 3.550 páginas de un wiki de ingeniería interno (markdown, código, prosa mixta).
- Modelo de chat: Llama 3.3 8B Q4_K_M (≈ 4,9 GB) cargado completamente en VRAM en las tres aplicaciones, servido a través de Ollama para AnythingLLM y Open WebUI, y a través del runtime llama.cpp integrado para PrivateGPT.
- Embedders probados: el embedder por defecto de cada plataforma más nomic-embed-text v1.5 (768 dim) y BAAI/bge-m3 (1.024 dim) donde fue compatible. Se usó el por defecto para los números principales.
- Conjunto de consultas: 50 consultas distribuidas en 5 tipos — búsqueda factual (10), razonamiento multi-salto (10), resumen (10), precisión de citas (10) y detección de contradicciones (10). Valoradas a ciegas por la misma persona contra una clave de respuestas conocida.
- Qué medimos: latencia de recuperación (p50 / p95 en ms sobre 50 consultas), tasa de alucinaciones (% de respuestas con al menos un error factual), corrección de citas (nombre de archivo + página donde corresponda), pico de memoria GPU durante la indexación y tamaño de la base de datos vectorial en disco.
📌Note: El acceso a la red se desactivó en la máquina de prueba después de descargar los modelos. Ninguna de las tres plataformas intentó conexiones salientes durante la inferencia — confirmado mediante captura con Wireshark y Little Snitch en la verificación cruzada con macOS.
Arquitectura: cómo cada sistema procesa un documento
Las tres plataformas toman decisiones arquitectónicas muy diferentes, lo que explica las diferencias en los benchmarks. Cada una sigue el mismo pipeline general (cargar → chunking → embedding → almacenar → recuperar → generar), pero optimiza una etapa diferente.
- AnythingLLM — Aplicación de escritorio Electron + servicio Node integrado. Los documentos se procesan con los loaders de
LangChain.js, se dividen en chunks de 1.000 caracteres con solapamiento de 20 caracteres por defecto, se embeben con el backend seleccionado y se almacenan en LanceDB (carpeta por espacio de trabajo en disco). La recuperación usa similitud coseno con re-ranking opcional mediante un pequeño cross-encoder. Las citas se rastrean por chunk con metadatos de nombre de archivo + página preservados a lo largo del pipeline. - PrivateGPT — Servicio Python FastAPI construido sobre LlamaIndex. Los loaders cubren PDF, DOCX, MD, HTML y texto plano. El chunking es configurable (ventana de oración, semántico, jerárquico) y el por defecto usa LlamaIndex
SentenceSplittercon 512 tokens. Los embeddings se calculan con sentence-transformers de HuggingFace y se almacenan en Qdrant (modo local) o Chroma. La generación usa el runtime llama.cpp integrado con plantillas de prompt explícitas por modo de consulta (Search, Q&A, Chat). - Open WebUI — Frontend Svelte + backend Python que se comunica con Ollama. RAG se implementa como middleware: los documentos pasan por los parsers de
unstructured.io, se dividen en chunks de 1.500 caracteres con solapamiento de 100 caracteres, se embeben con un modelo de embedding servido por Ollama (nomic-embed-text por defecto) y se almacenan en ChromaDB. La recuperación es una búsqueda densa simple, sin re-ranking. El modelo de chat recibe los top-K chunks como contexto con un prefijo de prompt fijo. - Por qué importan estas decisiones: LanceDB de AnythingLLM es el más rápido para *escribir* pero el más lento para escanear por encima de 100k chunks; Qdrant de PrivateGPT escala más lejos pero añade ~50 ms de overhead mínimo de consulta por el salto de FastAPI; ChromaDB de Open WebUI es el más lento de los tres en escrituras pero el más simple de operar.
💡Tip: Las diferencias arquitectónicas desaparecen por debajo de ~1.000 páginas — las tres se sienten rápidas. Se vuelven decisivas por encima de ~5.000 páginas: el paso de re-ranking de AnythingLLM añade ~70 ms pero recupera ~3 puntos porcentuales de recall; Qdrant de PrivateGPT permite mantener el índice en disco sin paginación; la ausencia de re-ranking en Open WebUI es la principal razón de su tasa de alucinaciones más alta de las tres.
AnythingLLM: la opción de grado producción
AnythingLLM es la única de las tres que ofrece RAG como superficie de producto de primera clase. Los espacios de trabajo, las citas, la elección de embedder y los controles de chunk están todos en la interfaz gráfica — no enterrados en YAML ni en variables de entorno.
- Ruta de instalación: instalador de escritorio desde anythingllm.com (firmado, ~430 MB, macOS / Windows / Linux) o Docker para multi-usuario autoalojado. La mayoría de usuarios debería empezar con el build de escritorio.
- Formatos de archivo: PDF, DOCX, TXT, MD, EPUB, HTML, CSV, JSON, sitios web (scraper integrado) y audio mediante Whisper integrado (MP3, WAV, M4A).
- Flexibilidad de embedding: 8 backends en mayo de 2026 — Native (pequeño modelo integrado), Ollama (cualquier embedder que tengas descargado), LM Studio, OpenAI, Azure OpenAI, Cohere, Voyage, LocalAI. Cambiar fuerza una re-indexación completa pero es una operación de un solo clic.
- Control de chunk: el tamaño del chunk y el solapamiento están expuestos por espacio de trabajo. Re-embed-all reconstruye el almacén LanceDB tras los cambios. Sin chunking semántico ni jerárquico incluido por defecto.
- Citas: cada respuesta añade notas a pie con los chunks fuente incluyendo nombre de archivo + página (PDF), nombre de archivo + sección (MD) o solo nombre de archivo (TXT). El panel de citas muestra el chunk fuente literalmente — esta es la razón principal de la baja tasa de alucinaciones.
- Rendimiento en el corpus de 5.047 páginas: la indexación tardó 14 min 42 seg en RTX 4070 (embedder Native por defecto), con un pico de 6,2 GB de memoria GPU. Latencia de recuperación p50 de 310 ms, p95 de 880 ms. Tamaño de la base de datos vectorial en disco: 184 MB.
- Nota de cumplimiento: el build oficial de escritorio incluye telemetría de código cerrado; el repositorio en GitHub es de código abierto (MIT). Para despliegues con mandato de auditoría, compila desde el código fuente.
💡Tip: Usa un espacio de trabajo por proyecto, no uno por tipo de documento. Los espacios de trabajo separados evitan la contaminación cruzada de citas y te permiten ajustar el tamaño del chunk según el contenido real (los documentos legales necesitan chunks más pequeños, los manuales técnicos toleran chunks más grandes).
PrivateGPT: la opción diseñada para funcionar offline
PrivateGPT es ante todo un servicio Python y después una interfaz. Ese trade-off lo convierte en la herramienta equivocada para usuarios ocasionales y en la herramienta correcta para equipos que necesitan llamar a RAG desde su propio backend, endurecer la postura de cumplimiento o intercambiar embedders para probar la calidad de recuperación de forma científica.
- Ruta de instalación: git clone, Poetry install, descarga del modelo con
make. Reserva 25 minutos en una máquina nueva; el toolkit de CUDA debe estar presente para la aceleración por GPU. Existen imágenes Docker pero van por detrás de la release del código fuente. - Formatos de archivo: PDF, DOCX, MD, HTML, TXT, EPUB mediante los loaders de LlamaIndex. CSV y JSON mediante loaders personalizados.
- Flexibilidad de embedding: cualquier modelo HuggingFace sentence-transformers funciona (BAAI/bge-m3, BAAI/bge-small-en-v1.5, variantes de nomic-embed-text, mxbai-embed-large). Se configura en
settings.yaml; sin selector en la interfaz gráfica. - Estrategia de chunk: el toolkit completo de LlamaIndex está disponible —
SentenceSplitter,SentenceWindowNodeParser,HierarchicalNodeParser,SemanticSplitterNodeParser. Los dos últimos superaron al chunking de tamaño fijo de AnythingLLM en consultas multi-salto por ~5 puntos porcentuales en nuestras pruebas. - Citas: JSON estructurado en la respuesta de la API (nombre de archivo + ID de chunk + score). La interfaz Gradio integrada las muestra como un panel fuente plegable. Los números de página son fiables para PDFs, ausentes para texto plano.
- Rendimiento en el corpus de 5.047 páginas: la indexación tardó 18 min 06 seg en RTX 4070 (sentence-transformers
all-MiniLM-L6-v2por defecto), con un pico de 4,8 GB de memoria GPU. Latencia de recuperación p50 de 240 ms, p95 de 720 ms — la más rápida de las tres. Tamaño de la base de datos vectorial en disco (Qdrant local): 156 MB. - Postura de cumplimiento: cero telemetría, sin SDK de analítica, el servicio FastAPI se vincula a localhost por defecto, todos los pesos viven en disco. La más fácil de auditar para contextos de la Ley de IA de la UE / RGPD.
📌Note: PrivateGPT es la única de las tres con una superficie de API real — POST /v1/chat/completions, POST /v1/ingest/file, etc. Si tu objetivo final es llamar a RAG desde un backend Python o desde una herramienta de automatización tipo n8n/Zapier, PrivateGPT es el único punto de partida sensato.
Open WebUI: el frontend de chat multi-usuario
Open WebUI se entiende mejor como una interfaz de chat que creció para incluir RAG, no como un producto RAG que creció para incluir una interfaz. Ese origen se nota: la experiencia de chat es la más limpia de las tres, pero RAG está conectado como middleware y se comporta como tal.
- Ruta de instalación: Docker compose junto a Ollama. ~12 minutos desde una máquina limpia si Docker ya está instalado. Sin instalador nativo — Docker es obligatorio.
- Formatos de archivo: PDF, DOCX, TXT, MD, HTML, CSV, EPUB. OCR de imágenes mediante el complemento opcional de
unstructured.io. - Flexibilidad de embedding: cualquier modelo de embedding servido por Ollama (nomic-embed-text, mxbai-embed-large, snowflake-arctic-embed) más SentenceTransformers y cualquier endpoint compatible con OpenAI. Cambiar es un toggle en la configuración, pero dispara una re-indexación completa de todas las colecciones.
- Estrategia de chunk: el tamaño del chunk y el solapamiento son configurables globalmente (por defecto 1.500 / 100) con override por documento. Sin splitters semánticos ni jerárquicos.
- Citas: solo nombre de archivo, mostrado como un pequeño pie "Sources" debajo de la respuesta. Sin números de página, sin vistas previas de chunks. Esta es la razón principal de que tenga la tasa de alucinaciones más alta de las tres.
- Rendimiento en el corpus de 5.047 páginas: la indexación tardó 21 min 18 seg en RTX 4070 (nomic-embed-text por defecto a través de Ollama), con un pico de 5,4 GB de memoria GPU. Latencia de recuperación p50 de 380 ms, p95 de 1.040 ms — la más lenta de las tres. Tamaño de la base de datos vectorial en disco (ChromaDB): 212 MB.
- Multi-usuario: OAuth (Google, Microsoft, GitHub, OIDC genérico), colecciones por usuario, acceso basado en roles. La mejor de las tres para despliegues compartidos.
💡Tip: Específicamente para Open WebUI, cambia el modelo de chat por defecto a uno que cite bien incluso sin prompting explícito de citas. Qwen3 14B y Llama 3.3 70B mencionan fuentes sin que se les pida; Llama 3.3 8B y Phi-4 Mini suelen omitir las citas bajo presión.
Latencia de recuperación en 5.047 páginas (p50 / p95)
La latencia se midió de extremo a extremo desde el envío de la consulta hasta el primer token de la respuesta, en el RTX 4070 con el modelo de chat ya cargado. Mediana de 50 consultas; p95 es la 48.ª peor de 50.
| Etapa | AnythingLLM | PrivateGPT | Open WebUI |
|---|---|---|---|
| Embedding de la consulta (creación del vector) | 40 ms | 35 ms | 90 ms |
| Búsqueda vectorial (top-K=6) | 180 ms | 110 ms | 210 ms |
| Re-ranking (cross-encoder) | 70 ms | 60 ms (opcional) | N/A |
| Ensamblado del prompt + LLM TTFT | 20 ms | 35 ms | 80 ms |
| Total p50 | 310 ms | 240 ms | 380 ms |
| Total p95 | 880 ms | 720 ms | 1.040 ms |
📌Note: PrivateGPT gana en búsqueda vectorial bruta porque Qdrant es la base de datos vectorial más madura de las tres y permanece caliente en memoria bajo consultas repetidas. Open WebUI pierde terreno por el overhead del middleware FastAPI y la ausencia de una fase de re-ranking que capturaría los fallos de recuperación.
Tasa de alucinaciones por tipo de consulta
Alucinación = al menos un error factual en la respuesta cuando el corpus contenía la información correcta. Valorado a ciegas contra una clave de respuestas. 10 consultas por tipo, 50 en total por plataforma. Los números son el % de respuestas con al menos un error.
| Tipo de consulta | AnythingLLM | PrivateGPT | Open WebUI |
|---|---|---|---|
| Búsqueda factual | 0% | 10% | 10% |
| Razonamiento multi-salto | 20% | 20% | 30% |
| Resumen | 0% | 0% | 10% |
| Precisión de citas (cita textual) | 10% | 20% | 20% |
| Detección de contradicciones | 0% | 5% | 0% |
| Total (50 consultas) | 6% | 11% | 14% |
💡Tip: El razonamiento multi-salto es donde sufren las tres plataformas. La solución no es la plataforma — es tu modelo de chat. Cambiar Llama 3.3 8B por Qwen3 14B redujo las alucinaciones multi-salto en ~10 puntos porcentuales en cada plataforma. La calidad del RAG es necesaria pero no suficiente; el modelo de chat tiene que razonar realmente sobre los chunks recuperados.
Calidad de las citas en las mismas respuestas
La calidad de las citas es la dimensión más infravalorada del RAG. Una respuesta correcta sin citas es inútil para trabajo posterior; una respuesta que suena segura con una cita incorrecta es peor que no tener respuesta.
- AnythingLLM — citas mostradas en línea (marcadores de nota) y como panel expandible con el chunk literal más nombre de archivo + página. Los números de página son fiables en PDFs (parseados desde el loader), solo nombre de archivo en texto plano. El click-to-source funciona.
- PrivateGPT — citas devueltas como JSON estructurado en la respuesta de la API (
{filename, chunk_id, score, text}). La interfaz Gradio integrada las muestra como un panel "Sources" plegable. Los números de página son fiables en PDFs, ausentes en MD y TXT. La mejor para consumo programático. - Open WebUI — solo nombre de archivo, mostrado como un pequeño pie "Sources:". Sin números de página, sin vistas previas de chunks, sin click-to-source. Aceptable para chat informal, insuficiente para redacción académica o legal.
- En las 10 consultas de precisión de citas (recuperación de cita textual), AnythingLLM acertó 9/10, PrivateGPT 8/10 y Open WebUI 8/10 — pero los fallos de Open WebUI son más difíciles de detectar porque la cita no incluye el texto del chunk.
Flexibilidad del modelo de embedding
El embedder por defecto raramente es el mejor para tu corpus específico. El texto legal, el código y el contenido multilingüe tienen cada uno un embedder preferido. La plataforma que te permite cambiar fácilmente gana para cualquier equipo que quiera ajustar la calidad de recuperación.
- AnythingLLM — 8 backends en la interfaz gráfica, cambia con un clic. Re-embed-all reconstruye el índice LanceDB. La más sencilla de las tres para que usuarios no técnicos hagan pruebas A/B de embedders.
- PrivateGPT — cualquier modelo HuggingFace sentence-transformers a través de
settings.yaml. Mayor variedad real (todos los modelosBAAI/bge-*publicados funcionan, incluyendobge-m3para multilingüe), pero hay que editar un archivo YAML y reiniciar el servicio. - Open WebUI — embedders servidos por Ollama + SentenceTransformers + endpoints compatibles con OpenAI. Toggle en la configuración; requiere que el modelo de embedding ya esté descargado en Ollama. La re-indexación corre en segundo plano.
- Probado en el corpus de 5.047 páginas: cambiar el embedder por defecto por
BAAI/bge-m3mejoró el recall global en 4–7 puntos porcentuales en las tres plataformas, pero triplicó el tiempo de indexación y añadió ~1 GB de memoria GPU durante el proceso. - Para corpus multilingüe (alemán, francés, japonés, chino mezclados),
bge-m3es la elección que supera al defecto en las tres plataformas — pero solo el pipeline de PrivateGPT lo soporta de forma nativa sin pasar por Ollama.
El límite de escalabilidad: dónde fallan las demos
Las tres plataformas funcionan bien por debajo de 1.000 páginas y empiezan a fallar en algún punto entre 8.000 y 12.000 páginas en hardware de consumo. El límite no está en el tiempo de indexación — está en el recall de recuperación y la presión de memoria.
- Open WebUI falla primero, alrededor de las 8.000 páginas — la recuperación densa de una sola etapa sin re-ranking empieza a devolver chunks incorrectos, y la configuración por defecto de ChromaDB pagina mucho bajo presión de memoria. La tasa de alucinaciones sube del 14% (5K páginas) a ~22% (10K páginas) sin otros cambios.
- AnythingLLM falla alrededor de las 10.000 páginas — los escaneos de LanceDB se vuelven más lentos por encima de ~120k chunks y la etapa de re-ranking empieza a ser el cuello de botella. La latencia p95 pasa de 880 ms a ~1,6 seg. La tasa de alucinaciones sube del 6% a ~10%.
- PrivateGPT falla alrededor de las 12.000 páginas — Qdrant en modo local gestiona bien el volumen de chunks, pero la configuración por defecto del servicio FastAPI (workers de uvicorn, tamaño de batch de embedding) necesita ajuste. Con la configuración correcta, PrivateGPT escala hasta ~25.000 páginas en una máquina con 32 GB de RAM antes de degradarse significativamente.
- Por encima de ~25.000 páginas, ninguna de las tres es la herramienta adecuada. Pasa a un stack personalizado con Ollama + Qdrant o Weaviate con búsqueda híbrida explícita (BM25 + densa) y un re-ranker dedicado. Los almacenes vectoriales integrados en estas tres plataformas no están diseñados para esa escala.
- Síntomas del límite: la latencia p95 de recuperación supera los 2 segundos, la tasa de alucinaciones aumenta sin cambios en el código, actividad de swap del sistema durante las consultas, respuestas de "no se encontraron chunks relevantes" a consultas que funcionaban ayer.
💡Tip: Si estás construyendo una base de conocimiento personal o una biblioteca de equipo que podría crecer más allá de las 10.000 páginas, empieza con PrivateGPT (el techo de escalabilidad más alto de las tres) o salta directamente a un stack personalizado desde el primer día. El costo de migración es real — se mide en días, no en horas.
Árbol de decisión: ¿cuál deberías elegir?
Cinco preguntas binarias en orden llevan a la mayoría de los lectores a la elección correcta.
- 1. ¿Usará este despliegue más de una persona? → Sí: salta a la pregunta 3. No: continúa.
- 2. ¿Necesitas respuestas con citas (nombre de archivo + página)? → Sí: AnythingLLM. No: continúa.
- 3. ¿Lo llamarás desde un backend o herramienta de automatización? → Sí: PrivateGPT. No: continúa.
- 4. ¿Estás en un sector regulado por la UE o en un contexto de auditoría? → Sí: PrivateGPT. No: continúa.
- 5. ¿Ya ejecutas Ollama y quieres una interfaz de chat multi-usuario? → Sí: Open WebUI. No: AnythingLLM (la opción por defecto).
- Si no estás seguro: empieza con AnythingLLM. Es la más fácil de instalar de las tres, tiene la tasa de alucinaciones más baja y genera citas que puedes pegar en otros trabajos. Migra más adelante si la superas.
Errores comunes al elegir una plataforma RAG local
- Error 1: elegir la plataforma antes que el embedder. El modelo de embedding domina la calidad de recuperación más que cualquier otra decisión. Primero decide si necesitas soporte multilingüe (
bge-m3), para código (bge-code-v1) o de propósito general (nomic-embed-text v1.5); luego elige la plataforma que lo soporta de forma nativa. - Error 2: hacer benchmarks con un corpus demasiado pequeño. Las tres plataformas funcionan bien con menos de 1.000 páginas. Haz el benchmark con al menos 5.000 páginas de tu contenido real — los rankings cambian.
- Error 3: ignorar el costo de la re-indexación. Cambiar de embedder no es gratis. Si quieres hacer pruebas A/B de embedders cada mes, eso son entre 30 y 90 minutos de indexación por cambio en hardware de consumo.
- Error 4: saltarse la mejora del modelo de chat. La calidad del RAG es necesaria pero no suficiente. Un pipeline RAG excelente que alimenta a un modelo de chat pequeño produce alucinaciones en consultas multi-salto; el mismo pipeline con Qwen3 14B reduce los errores multi-salto en ~10 puntos porcentuales.
- Error 5: confiar en una respuesta sin verificar la cita. Incluso AnythingLLM con una tasa de alucinaciones del 6% se equivoca en ~3 de cada 50 respuestas. Para cualquier tema que tenga consecuencias (legal, médico, financiero), abre el chunk citado y verifica que la respuesta esté realmente respaldada.
Preguntas frecuentes
¿Qué plataforma RAG gestiona los conjuntos de documentos más grandes?
PrivateGPT escala más lejos en hardware de consumo — cómodamente hasta ~25.000 páginas con configuración ajustada (workers de uvicorn, tamaño de batch de embedding, caché de Qdrant) en una máquina con 32 GB de RAM. AnythingLLM falla alrededor de las 10.000 páginas, Open WebUI alrededor de las 8.000. Por encima de 25.000 páginas, ninguna de las tres es la herramienta adecuada — pasa a un stack personalizado con Ollama + Qdrant o Weaviate.
¿Puedo migrar documentos y embeddings entre estas plataformas?
Los documentos fuente se mueven libremente — las tres aceptan los mismos archivos. Los embeddings no migran. Cada plataforma almacena vectores en su propio formato (LanceDB, Qdrant, ChromaDB) con metadatos específicos de la plataforma, por lo que un cambio siempre implica re-indexación. Calcula entre 30 y 90 minutos por cada 5.000 páginas en hardware de consumo.
¿Qué plataforma tiene la mejor precisión de citas?
AnythingLLM. En 50 consultas valoradas, citó correctamente el nombre de archivo + página en 9 de cada 10 veces en consultas de cita textual, frente a 8/10 de PrivateGPT y 8/10 de Open WebUI. AnythingLLM es también la única de las tres que muestra el texto del chunk literal en un panel click-to-source, lo que hace que la verificación de citas sea rápida.
¿Cuánta memoria GPU necesita cada plataforma durante la indexación?
En el corpus de 5.047 páginas con los embedders por defecto: AnythingLLM alcanzó un pico de 6,2 GB, Open WebUI de 5,4 GB y PrivateGPT de 4,8 GB. Cambiar a un embedder más grande (BAAI/bge-m3, 1.024 dim) añade ~1 GB. Si ya tienes un modelo de chat cargado en VRAM, cuenta con que el embedder competirá con él — una tarjeta de 12 GB no puede indexar mientras Llama 3.3 70B esté residente.
¿Puedo usar mi propio modelo de embedding?
AnythingLLM soporta 8 backends de embedding en la interfaz gráfica (Native, Ollama, LM Studio, OpenAI, Azure, Cohere, Voyage, LocalAI). PrivateGPT soporta cualquier modelo HuggingFace sentence-transformers a través de settings.yaml. Open WebUI soporta embedders servidos por Ollama, SentenceTransformers y endpoints compatibles con OpenAI. PrivateGPT tiene la mayor variedad *real* de elección; AnythingLLM tiene la experiencia de cambio más sencilla.
¿Qué plataforma gestiona mejor los documentos multilingüe?
PrivateGPT, combinado con BAAI/bge-m3 (un embedder multilingüe de 1.024 dim). bge-m3 soporta más de 100 idiomas sin configuración adicional y supera a los embedders solo en inglés en 8–15 puntos porcentuales en consultas en idiomas mezclados. AnythingLLM y Open WebUI también pueden usar bge-m3 a través de Ollama, pero PrivateGPT lo soporta de forma nativa sin el rodeo por Ollama.
¿Cómo gestionan las tablas y figuras de los PDFs?
Las tres extraen texto mediante parsers de PDF (pypdfium2 para AnythingLLM y Open WebUI, estilo pdfplumber para PrivateGPT). Las tablas se extraen como texto con la estructura de filas/columnas preservada de forma imperfecta — aceptable para tablas simples, con pérdidas para layouts complejos. Las figuras se extraen como referencias de imagen en los metadatos pero no se usan para la recuperación. Para PDFs con muchas figuras, considera extraer primero las tablas a CSV con una herramienta como Tabula o Camelot.
¿Qué plataforma es más fácil de desplegar en un servidor?
Open WebUI — Docker compose junto a Ollama es una configuración de 12 minutos que incluye OAuth, acceso basado en roles y colecciones por usuario. PrivateGPT es compatible con servidores pero requiere experiencia en Python + Poetry. AnythingLLM tiene una imagen Docker pero la mayoría de usuarios realmente ejecuta la aplicación de escritorio; el build multi-usuario para servidor va por detrás del de escritorio en paridad de funciones.
¿Pueden usarse en productos comerciales?
AnythingLLM tiene licencia MIT (uso comercial permitido; el build oficial incluye telemetría de código cerrado que puedes desactivar o eliminar compilando desde el código fuente). PrivateGPT es Apache 2.0 (uso comercial permitido, sin telemetría). Open WebUI es BSD-3 (uso comercial permitido). Verifica siempre la licencia en el momento de la integración — las licencias de código abierto pueden cambiar.
¿Cuál tiene el desarrollo más activo?
Open WebUI publica cada 1–2 semanas y ocasionalmente reescribe el middleware de RAG entre versiones — el ritmo más rápido pero con mayor rotación en actualizaciones. PrivateGPT actualiza LlamaIndex aproximadamente cada mes, con cambios que rompen compatibilidad de forma periódica. AnythingLLM publica cada 2–3 semanas y es el más estable entre versiones. Para despliegues de producción de larga duración, el cadencia de publicación de AnythingLLM es la más predecible.