Un error aparte es suponer que un modelo más grande puede compensar una base de conocimiento deficiente. En RAG, la calidad de la respuesta suele depender más de los documentos, la fragmentación, la búsqueda y la actualización de los datos que del tamaño del modelo.
Un servidor GPU para RAG y un chatbot corporativo no debe elegirse solo por la tarjeta gráfica: también importan la capacidad de memoria de vídeo, la velocidad del modelo, la CPU, la RAM, las unidades NVMe, la base de datos vectorial, el método de almacenamiento de documentos, la red, los derechos de acceso, la monitorización y la seguridad. Para un piloto, a menudo basta con una GPU de servidor, almacenamiento NVMe rápido y un esquema claro de indexación de documentos. Para un escenario de producción en el que varios departamentos de la empresa usan el chatbot, la base de conocimiento se actualiza con frecuencia y los datos no pueden enviarse a servicios externos, ya se necesita una arquitectura completa con redundancia, registro y un plan de escalado.
Un chatbot corporativo basado en RAG no responde “de memoria”. Recibe una pregunta del usuario, busca fragmentos relevantes en documentos internos, los transmite al modelo de lenguaje y genera una respuesta teniendo en cuenta el contexto encontrado. Por eso, el servidor no solo debe ejecutar el modelo, sino también buscar documentos rápidamente, comprobar permisos, almacenar índices, procesar archivos nuevos y soportar solicitudes simultáneas.
Si se elige un servidor solo por el nombre de la GPU, se puede terminar con un sistema caro pero desequilibrado. Por ejemplo, la GPU puede quedar ociosa por discos lentos, las respuestas pueden retrasarse por la base de datos vectorial y el equipo de seguridad puede bloquear el lanzamiento por falta de control de acceso a los documentos.
Qué significa RAG en un chatbot corporativo
RAG (Retrieval-Augmented Generation) es un enfoque en el que un modelo de lenguaje recibe contexto adicional desde una base de conocimiento externa. En un chatbot corporativo, esa base puede incluir normativas, instrucciones, contratos, artículos de la base de conocimiento de soporte, políticas internas, fichas de clientes, documentación técnica o materiales del portal corporativo.
De forma simplificada, el proceso es el siguiente:
- El usuario hace una pregunta.
- El sistema convierte la pregunta en una representación numérica para la búsqueda.
- La base de datos vectorial encuentra fragmentos de documentos similares.
- Un módulo adicional puede ordenar los fragmentos recuperados por utilidad.
- El modelo de lenguaje recibe la pregunta y los fragmentos seleccionados.
- El chatbot genera una respuesta.
- El sistema guarda registros, métricas y, si es necesario, enlaces a las fuentes.
En NVIDIA RAG Blueprint, esta arquitectura se considera un flujo empresarial independiente: ingestión de datos, extracción de información, búsqueda, generación de respuestas y control del funcionamiento del sistema. Esto es importante porque RAG no es un único componente, sino un conjunto de servicios conectados en el que cada parte influye en la velocidad y la calidad de la respuesta.
Normalmente, un sistema RAG corporativo incluye varias partes:
- un modelo de lenguaje para generar respuestas;
- un modelo para búsqueda semántica;
- una base de datos vectorial;
- un módulo de ingestión y procesamiento de documentos;
- almacenamiento para archivos de origen;
- una base de metadatos;
- comprobación de derechos de acceso;
- registro de solicitudes;
- monitorización de calidad y rendimiento;
- una interfaz de chatbot o API para integrarse con sistemas corporativos.
La GPU suele ser necesaria para ejecutar el modelo de lenguaje y acelerar algunas etapas de búsqueda. Pero no todas las partes de RAG dependen de la tarjeta gráfica de la misma forma. La indexación de documentos, el almacenamiento, el filtrado por permisos, el trabajo de la API, las colas de tareas y la monitorización pueden cargar más la CPU, la RAM, los discos y la red.
Por qué la tarjeta gráfica no lo resuelve todo
La tarjeta gráfica se encarga de los cálculos pesados, pero no puede corregir errores de arquitectura. Si los documentos están mal preparados, el servidor generará respuestas débiles rápidamente. Si la base de conocimiento está en un almacenamiento lento, el usuario seguirá esperando incluso cuando la GPU esté casi libre. Si no hay suficiente RAM, los índices y las cachés empezarán a competir con otros servicios.
Un chatbot puede funcionar lento no por la GPU, sino por otros cuellos de botella:
- se pasa al modelo un contexto demasiado largo;
- varios usuarios crean una cola de solicitudes al mismo tiempo;
- la base de datos vectorial busca documentos lentamente;
- los documentos están en un almacenamiento externo con acceso lento;
- la CPU no soporta el procesamiento de PDF, tablas y presentaciones;
- no hay suficiente RAM para índices y cachés;
- se usan SSD convencionales o almacenamiento en red sin la velocidad necesaria en lugar de NVMe;
- no hay caché para preguntas frecuentes;
- el sistema procesa repetidamente los mismos documentos;
- el modelo elegido no cabe bien en la memoria de vídeo;
- la monitorización no está configurada, por lo que el equipo no ve la causa real de los retrasos.
Para RAG no solo importa la velocidad máxima de generación de texto, sino el tiempo total de respuesta: búsqueda, ordenación de fragmentos, preparación del contexto, generación y entrega del resultado al usuario. Si una de estas etapas funciona lentamente, ni siquiera la GPU más potente salvará la experiencia de usuario.
De qué se compone la arquitectura de servidor para RAG
Conviene ver un servidor RAG corporativo como varias subsistemas conectados. Pueden ejecutarse en un único servidor físico, en varios nodos o en una arquitectura mixta.
Generación de respuestas
El modelo de lenguaje es la parte más visible del sistema. Es el componente que genera la respuesta para el usuario. Para él son importantes:
- la capacidad de memoria de vídeo;
- el tamaño del modelo;
- la longitud del contexto;
- el número de usuarios simultáneos;
- el modo de funcionamiento del modelo;
- el tiempo hasta la primera respuesta;
- la estabilidad de la latencia bajo carga.
Cuanto mayor sea el modelo y más largo sea el contexto, más memoria de vídeo se necesita. Para un piloto sencillo se puede usar un modelo más compacto y una sola GPU. Para un escenario de producción con muchos usuarios y documentos largos se necesita margen de VRAM y una configuración de inferencia más cuidadosa.
La documentación de vLLM analiza por separado los parámetros que afectan al uso de memoria GPU, la caché y el rendimiento del modelo. Es un buen ejemplo de que el rendimiento no depende solo de la GPU, sino también de cómo se organizan las colas, el almacenamiento en caché y el procesamiento paralelo de solicitudes.
Búsqueda semántica
Para que el chatbot encuentre el documento correcto, el texto de la pregunta y el texto de los documentos se convierten en representaciones numéricas. Esto permite buscar no solo por palabras exactas, sino también por similitud semántica.
Por ejemplo, un usuario pregunta: “¿Cómo solicito una licencia sin sueldo?” En los documentos puede aparecer la formulación “permiso no remunerado”. Una búsqueda normal por palabras clave puede no encontrar el fragmento correcto, mientras que la búsqueda semántica tiene más probabilidades de relacionar estas formulaciones.
El modelo para este tipo de búsqueda puede ejecutarse en CPU o GPU. Si la base de conocimiento es pequeña y se actualiza rara vez, una GPU no siempre es crítica para esta etapa. Si los documentos se añaden constantemente, hay muchos PDF y tablas, y la reindexación se ejecuta cada día, la aceleración se vuelve importante.
NVIDIA NeMo Retriever describe este flujo como un conjunto de componentes para extraer datos, generar embeddings, indexar y reordenar resultados. En un entorno corporativo esto es especialmente importante, porque la calidad de la búsqueda influye directamente en la calidad de la respuesta.
Base de datos vectorial
La base de datos vectorial almacena fragmentos de documentos en un formato adecuado para la búsqueda semántica. Determina qué fragmentos entrarán en el contexto del modelo.
Para una base de datos vectorial son importantes:
- el tamaño del índice;
- la velocidad de lectura;
- la capacidad de RAM;
- discos rápidos;
- filtrado por metadatos;
- copias de seguridad;
- recuperación tras fallos;
- soporte de derechos de acceso.
En producción, una base de datos vectorial no debe tratarse como una carpeta temporal. Si el índice se pierde, queda obsoleto o se construye sin tener en cuenta los derechos de acceso, el chatbot empezará a responder de forma incorrecta o a usar documentos que un usuario concreto no debería ver.
Ingestión y procesamiento de documentos
La preparación de documentos suele ser más difícil de lo que parece. Una base de conocimiento corporativa rara vez está formada por archivos de texto limpios y bien estructurados. Normalmente contiene PDF, escaneos, archivos DOCX, hojas de cálculo, presentaciones, páginas HTML, archivos comprimidos, versiones antiguas de instrucciones y duplicados.
En la etapa de ingestión hay que:
- extraer texto;
- eliminar caracteres de ruido;
- eliminar duplicados;
- separar las versiones actuales de las obsoletas;
- dividir documentos en fragmentos;
- añadir metadatos;
- conservar el vínculo con el documento de origen;
- tener en cuenta los derechos de acceso;
- preparar los datos para la indexación.
Si esta etapa se hace mal, un modelo potente responderá con seguridad, pero de forma imprecisa. Recibirá el fragmento incorrecto, una versión obsoleta del documento o texto sin el contexto necesario.
Almacenamiento de documentos, índices y registros
RAG necesita distintos tipos de datos, y es mejor no mezclarlos en una misma carpeta compartida:
- documentos de origen;
- texto depurado;
- fragmentos de documentos;
- embeddings;
- índices de la base de datos vectorial;
- metadatos;
- registros de solicitudes;
- valoraciones de usuarios;
- copias de seguridad.
Las unidades NVMe son especialmente útiles para índices activos, caché, archivos temporales y reindexación rápida. Los archivos grandes pueden almacenarse por separado, pero el conjunto de datos de trabajo debe leerse con rapidez. De lo contrario, la GPU esperará mientras el servidor prepara los datos.
CPU y RAM
La CPU no se necesita “solo para completar la configuración”. Atiende la API, el procesamiento de documentos, la extracción de texto, el filtrado, las colas, las tareas en segundo plano, la monitorización y parte de la lógica de búsqueda. Si el servidor tiene un procesador débil, todo el sistema puede ralentizarse antes de que la solicitud llegue a la GPU.
La RAM se necesita para:
- la base de datos vectorial;
- los índices;
- la caché de solicitudes frecuentes;
- las colas de procesamiento de documentos;
- los contenedores;
- los servicios del sistema;
- la monitorización;
- varios modelos o servicios en un mismo nodo.
Para un piloto puede bastar una cantidad moderada de RAM. En producción, donde la base de datos, la API, la indexación, la monitorización y varios usuarios trabajan al mismo tiempo, ahorrar en memoria se convierte rápidamente en un problema.
Red
La red importa si los documentos están en un almacenamiento externo, la base de datos vectorial se traslada a otro servidor, hay varios nodos GPU o el chatbot se conecta a sistemas corporativos.
Para un piloto, 10G suele ser suficiente. Para producción con un gran volumen de documentos, almacenamiento separado y varios nodos, conviene considerar 25G o más desde el principio. En una arquitectura en clúster y con cargas de IA pesadas, la red se vuelve rápidamente tan importante como la GPU y los discos.
Seguridad
Un chatbot corporativo trabaja con datos internos. Por eso, la seguridad debe incorporarse a la arquitectura, no añadirse después del piloto.
Hay que pensar de antemano:
- quién tiene acceso a qué documentos;
- cómo se comprueban los permisos antes de pasar fragmentos al modelo;
- dónde se almacenan los registros de solicitudes;
- si aparecen datos personales en los registros;
- si los documentos y los índices están cifrados;
- cómo se eliminan documentos obsoletos o prohibidos;
- quién puede reindexar la base de conocimiento;
- cómo se registran errores y solicitudes sospechosas;
- si los datos pueden enviarse a API externas.
OWASP destaca por separado la inyección de prompts en su lista de riesgos para aplicaciones LLM: una situación en la que una instrucción maliciosa en una solicitud o en un documento intenta cambiar el comportamiento del modelo. Para RAG esto es especialmente importante: una instrucción peligrosa puede llegar no solo del usuario, sino también de un documento cargado en la base de conocimiento.
Qué datos influyen en la configuración del servidor
Antes de elegir un servidor, hay que describir no solo el modelo, sino también la propia tarea. Dos empresas pueden lanzar un “chatbot corporativo”, pero sus requisitos de hardware serán diferentes.
| Parámetro del proyecto | Qué aclarar | En qué influye |
|---|---|---|
| Tamaño de la base de conocimiento | Gigabytes, terabytes, número de documentos | Discos, RAM, tamaño del índice |
| Frecuencia de actualización | Mensual, diaria, continua | CPU, cola de tareas, velocidad de procesamiento |
| Tipos de archivos | PDF, DOCX, hojas de cálculo, presentaciones, escaneos | CPU, RAM, calidad de extracción de texto |
| Longitud del contexto | Respuestas cortas o documentos largos | VRAM, latencia, tamaño de la solicitud |
| Número de usuarios | 10, 100, 1000+ | GPU, API, colas, balanceo de carga |
| Carga máxima | Cuántas solicitudes se ejecutan simultáneamente | VRAM, rendimiento, caché |
| Derechos de acceso | Base compartida o acceso por departamentos | Metadatos, filtrado, seguridad |
| Requisitos de latencia | Los usuarios pueden esperar 30 segundos o necesitan 2–5 segundos | GPU, caché, red, arquitectura |
| Almacenamiento de datos | Si se permite la nube o se exige un entorno cerrado | Ubicación del servidor, redundancia, auditoría |
Es especialmente importante evaluar el crecimiento. Si hoy la base de conocimiento ocupa 100 GB, pero dentro de un año será de 2 TB de documentos con actualizaciones diarias, el servidor piloto puede convertirse rápidamente en una solución temporal.
Requisitos para piloto, producción y escenario multiusuario
No existe una configuración universal para todos los sistemas RAG. Pero sí hay referencias que ayudan a no equivocarse al empezar.
| Escenario | VRAM | RAM | Discos | Redundancia | Latencia y carga | Monitorización |
|---|---|---|---|---|---|---|
| Piloto | 24–48 GB si el modelo es compacto o se usa optimización | 128–256 GB | 1–2 unidades NVMe para el sistema, el índice y la base de prueba | Básica, sin tolerancia a fallos compleja | Puede aceptarse mayor latencia; lo más importante es validar la hipótesis | GPU, RAM, discos, tiempo de respuesta, errores de búsqueda |
| Producción para un departamento | 48–80 GB o más, según el modelo y el contexto | 256–512 GB | Unidades NVMe separadas para índices, documentos, registros y caché | RAID para la partición del sistema, copias de seguridad del índice y los documentos | Tiempo de respuesta estable, control de colas | Latencia, rendimiento, VRAM, calidad de búsqueda, errores de acceso |
| Varios departamentos y muchos usuarios | 80 GB o más, o varias GPU | 512 GB–1 TB o más | Pool NVMe rápido, almacenamiento separado de documentos, instantáneas | Fuentes de alimentación redundantes, RAID, copias de seguridad, plan de recuperación, posiblemente varios nodos | Control de p95/p99, límites de usuarios, colas | Métricas completas de solicitud, auditoría, alertas, calidad de respuestas, seguridad |
Estos valores no deben percibirse como una especificación final. El servidor real se selecciona después de probar el modelo, evaluar la base de conocimiento, el número de usuarios, los requisitos de seguridad y el tiempo de respuesta aceptable.
Cómo elegir una GPU para RAG y un chatbot
La elección de la GPU no empieza con la pregunta “qué tarjeta gráfica es la más potente”, sino con qué modelo se ejecutará, qué contexto necesita y cuántos usuarios trabajarán al mismo tiempo.
Al elegir una GPU importan:
- la capacidad de memoria de vídeo;
- el soporte del stack de software necesario;
- el consumo energético;
- el factor de forma;
- los requisitos de refrigeración;
- la posibilidad de instalar varias GPU;
- la compatibilidad con la plataforma de servidor;
- el margen para el crecimiento del modelo y del número de usuarios.
Para pilotos pequeños y asistentes corporativos con carga moderada, se puede empezar por la categoría general de GPU NVIDIA para IA y redes neuronales y elegir una tarjeta para el modelo concreto y la capacidad de VRAM necesaria. Por ejemplo, para algunas tareas puede servir NVIDIA L40S 48GB o NVIDIA RTX PRO 6000 Blackwell Server Edition, siempre que el servidor sea compatible en potencia, refrigeración y dimensiones.
Para modelos locales más pesados, contextos largos y carga de producción, conviene considerar soluciones con mayor memoria de vídeo: NVIDIA A100 80GB, NVIDIA H100 80GB o NVIDIA H200. Pero incluso una GPU así no será una buena elección por sí sola si el servidor no puede soportarla en potencia, refrigeración, ranuras y arquitectura general.
Para RAG suele importar más la estabilidad con solicitudes reales que el rendimiento máximo en condiciones ideales. El usuario no evalúa “tokens por segundo teóricos”. Ve lo rápido que el chatbot empieza a responder, la precisión de la respuesta y si el servicio se rompe en horas punta.
CPU, RAM y NVMe: dónde aparecen límites ocultos
En un proyecto RAG, la CPU, la RAM y los discos pueden ser tan importantes como la GPU.
La CPU participa en el procesamiento de documentos, el funcionamiento de la API, el filtrado de resultados, la preparación de solicitudes, las tareas en segundo plano y la monitorización. Si los documentos se actualizan constantemente, el servidor tendrá que extraer texto, reconstruir fragmentos y actualizar el índice con regularidad. Esto no siempre es una carga de GPU.
La RAM se necesita para la base de datos vectorial, las cachés, los contenedores, las colas y los procesos del sistema. Si la memoria se agota, el servidor se vuelve inestable: aumenta la latencia, la indexación tarda más y los servicios empiezan a competir por recursos.
Las unidades NVMe son necesarias para datos activos:
- índices;
- archivos temporales;
- caché;
- registros;
- texto depurado;
- copias locales de la base de conocimiento;
- reindexación rápida.
Si se ahorra en NVMe, la GPU puede quedar ociosa. El dinero se invierte en el acelerador, pero los datos llegan al modelo demasiado despacio.
Seguridad del RAG corporativo
El RAG corporativo casi siempre trabaja con datos sensibles. Pueden ser contratos, ofertas comerciales, documentos financieros, datos personales, correspondencia con clientes, reglamentos internos y documentación técnica.
Antes del lanzamiento hay que definir:
- qué documentos pueden indexarse;
- qué documentos no deben usarse;
- quién es responsable de mantener actualizada la base de conocimiento;
- cómo se comprueban los permisos de usuario;
- cómo se eliminan documentos obsoletos;
- cómo se almacenan los registros;
- quién tiene acceso al historial de solicitudes;
- si los datos pueden enviarse a servicios externos;
- qué hacer ante una sospecha de fuga de datos.
Si un empleado no tiene acceso a un documento en el sistema corporativo, el chatbot no debe usar ese documento al generar la respuesta. Esta regla debe implementarse no a nivel de “instrucción para el modelo”, sino a nivel de arquitectura: metadatos, filtros, roles y comprobación de permisos antes de pasar el contexto al modelo.
En su perfil de riesgos para IA generativa, NIST recomienda considerar estos sistemas a través de la gestión de riesgos, la auditoría, el ciclo de vida y la fiabilidad de los resultados. Para un chatbot corporativo, esto significa que la arquitectura del servidor debe soportar no solo velocidad, sino también control: quién hizo la pregunta, qué documentos se usaron, por qué se dio una respuesta concreta y si el sistema puede restaurarse tras un fallo.
Cómo implementar RAG y un chatbot corporativo
Es mejor empezar la implementación no comprando un servidor, sino preparando los datos y los escenarios.
Recopilar fuentes de datos
Hay que determinar de dónde obtendrá conocimiento el chatbot:
- base de conocimiento;
- portal corporativo;
- carpetas de archivos;
- CRM;
- tickets de soporte;
- instrucciones;
- contratos;
- reglamentos;
- documentación técnica;
- materiales de formación.
En esta etapa es importante eliminar de inmediato lo innecesario: borradores, duplicados, versiones obsoletas, documentos sin propietario y archivos que no pueden utilizarse según la política de seguridad.
Preparar documentos
Los documentos deben convertirse a un formato con el que pueda trabajar el sistema de búsqueda:
- extraer texto;
- limpiar el formato;
- procesar tablas;
- separar el texto útil del contenido de servicio;
- conservar el vínculo con el archivo de origen;
- añadir fecha, propietario, departamento y nivel de acceso.
Si la base contiene muchos escaneos, será necesario el reconocimiento óptico de caracteres. Si contiene muchas tablas, hay que comprobar por separado que no se pierda el sentido durante la extracción.
Dividir documentos en fragmentos
Los fragmentos demasiado pequeños pierden contexto. Los fragmentos demasiado grandes aumentan la carga del modelo y pueden reducir la precisión. Para un RAG corporativo es importante probar distintos tamaños de fragmento con preguntas reales.
Por ejemplo, una instrucción de 40 páginas puede contener varios procedimientos diferentes. Si se pasa todo el documento al modelo, puede tomar información innecesaria. Si se divide demasiado fino, la respuesta puede perder condiciones y excepciones.
Construir el índice
Después de la preparación, los fragmentos se convierten en vectores y se cargan en la base de datos. En esta etapa es importante no olvidar los metadatos:
- departamento;
- tipo de documento;
- fecha de actualización;
- versión;
- propietario;
- idioma;
- nivel de acceso;
- enlace al documento de origen.
Sin metadatos, es difícil filtrar resultados, eliminar documentos obsoletos y explicar al usuario en qué se basa la respuesta.
Configurar búsqueda y ordenación
Un buen sistema RAG no toma simplemente los primeros fragmentos similares. Debe seleccionar fuentes realmente útiles. Para ello se usan filtrado, búsqueda híbrida y reordenación de resultados.
Es importante comprobar la calidad de la búsqueda por separado de la calidad de generación. Si el sistema encuentra fragmentos incorrectos, el modelo casi inevitablemente dará una respuesta débil.
Configurar la generación de respuestas
El modelo debe responder basándose en los documentos recuperados, no inventar datos ausentes. Para un chatbot corporativo conviene definir reglas de antemano:
- qué hacer si falta información;
- cuándo pedir una aclaración;
- cómo citar documentos;
- cómo responder a preguntas controvertidas;
- qué temas están prohibidos;
- qué datos no deben mostrarse en la respuesta.
Lanzar un piloto y medir la calidad
El piloto debe realizarse no con preguntas de demostración ideales, sino con solicitudes reales de empleados. El conjunto de prueba debería incluir:
- preguntas simples;
- preguntas con formulación ambigua;
- preguntas sobre documentos obsoletos;
- solicitudes con permisos restringidos;
- preguntas en las que la respuesta correcta es “no hay información suficiente”;
- intentos de eludir restricciones.
Después del piloto quedará claro qué hay que reforzar: GPU, RAM, discos, búsqueda, derechos de acceso, preparación de documentos o calidad de los prompts.
Qué métricas monitorizar
Sin monitorización es imposible entender si el servidor está soportando la carga. El equipo puede ver que “el chatbot va lento”, pero no saber dónde está realmente el problema.
En infraestructura, hay que monitorizar:
- carga de GPU;
- uso de memoria de vídeo;
- temperatura de GPU;
- carga de CPU;
- uso de RAM;
- velocidad de disco;
- latencia de red;
- espacio libre;
- errores de contenedores y servicios.
En el flujo RAG:
- tiempo de búsqueda;
- tiempo de reordenación;
- tiempo de generación de respuesta;
- tiempo hasta el primer token;
- tiempo total de respuesta;
- número de fragmentos recuperados;
- porcentaje de respuestas sin contexto relevante;
- errores de acceso a documentos.
En calidad:
- precisión de la respuesta;
- presencia de enlaces a documentos;
- porcentaje de respuestas “no hay información suficiente”;
- valoraciones de usuarios;
- preguntas de seguimiento;
- quejas por datos obsoletos.
En seguridad:
- intentos de acceso a documentos restringidos;
- solicitudes sospechosas;
- signos de inyección de prompts;
- filtraciones de datos sensibles en los registros;
- picos de actividad inusuales.
Si estas métricas no se recopilan desde el principio, el lanzamiento en producción se convierte en conjeturas. El equipo cambiará el modelo, la GPU o la base de datos sin entender dónde está el verdadero cuello de botella.
Un servidor o varios nodos
Un servidor puede ser una buena solución para un piloto o un primer lanzamiento en producción. Es más sencillo de comprar, mantener y depurar.
Un servidor es adecuado si:
- la base de conocimiento tiene un tamaño moderado;
- no hay muchos usuarios;
- los documentos no se actualizan continuamente;
- el modelo cabe en una GPU;
- no hay requisitos estrictos de tolerancia a fallos;
- la base de datos vectorial no genera una carga pesada independiente;
- el proyecto solo está validando una hipótesis.
Se necesitan varios nodos cuando el sistema se convierte en parte de un proceso de negocio real:
- hay muchos usuarios;
- hay varios chatbots para distintos departamentos;
- la base de conocimiento crece rápidamente;
- los documentos se actualizan a diario o con más frecuencia;
- se necesita una base de datos vectorial separada;
- el modelo es pesado;
- el contexto es largo;
- se requiere tolerancia a fallos;
- hay requisitos de latencia p95/p99;
- se necesitan entornos separados para el procesamiento de documentos y la generación de respuestas.
La arquitectura puede adoptar distintas formas. En una variante, el servidor GPU se encarga solo del modelo, mientras que la base de datos vectorial funciona en un nodo separado. En otra, un servidor independiente procesa e indexa documentos. En un esquema más complejo, varios servidores GPU están detrás de un balanceador de carga, y los documentos e índices se almacenan por separado.
Lo importante es no construir un clúster demasiado pronto, pero tampoco comprar un servidor sin margen de crecimiento.
Errores frecuentes al elegir un servidor para RAG
Los errores más caros suelen aparecer no en el momento de la compra, sino varios meses después.
Las empresas a menudo:
- Eligen un servidor solo por la GPU.
- No calculan la longitud del contexto.
- No tienen en cuenta los usuarios simultáneos.
- Almacenan documentos, índices y registros en un solo disco.
- No reservan RAM para la base de datos vectorial.
- No prueban la velocidad de reindexación.
- No piensan bien los derechos de acceso.
- No tienen en cuenta el crecimiento de la base de conocimiento.
- No miden la calidad de búsqueda.
- Prueban solo preguntas de demostración cómodas.
- No planifican actualizaciones de modelos y controladores.
- Lanzan producción sin copias de seguridad.
- No comprueban potencia, refrigeración y espacio en rack.
- No recopilan métricas desde el primer día.
Un error aparte es suponer que un modelo más grande puede compensar una base de conocimiento deficiente. En RAG, la calidad de la respuesta suele depender más de los documentos, la fragmentación, la búsqueda y la actualización de los datos que del tamaño del modelo.
Qué incluir en una especificación de servidor GPU
Antes de la compra, es mejor describir el servidor desde la tarea, no desde una lista de componentes. La especificación debería incluir:
- la tarea principal del chatbot;
- los tipos de documentos;
- el tamaño actual de la base de conocimiento;
- la previsión de crecimiento para un año;
- la frecuencia de actualización de documentos;
- el número de usuarios;
- la carga simultánea máxima;
- el modelo o la clase de modelos;
- la capacidad mínima de memoria de vídeo;
- los requisitos de tiempo de respuesta;
- los requisitos de almacenamiento de datos;
- los requisitos de derechos de acceso;
- los requisitos de copias de seguridad;
- los requisitos de monitorización;
- las restricciones de rack, potencia y refrigeración;
- el plan de escalado.
Ejemplo de formulación:
Se necesita un servidor para un chatbot RAG corporativo basado en los documentos internos de la empresa. Al inicio: hasta 50 usuarios, base de conocimiento de hasta 500 GB, actualización diaria de documentos, funcionamiento en un entorno cerrado, almacenamiento de datos personales y comerciales, tiempo de respuesta esperado para la mayoría de las solicitudes de hasta 5–8 segundos y posibilidad de ampliar GPU, RAM y NVMe en un plazo de 12 meses.
Esta descripción es más útil que la frase “necesitamos un servidor para IA”. Permite entender dónde estarán las limitaciones reales: memoria de vídeo, búsqueda, discos, RAM, red, seguridad o escalado.
Preguntas frecuentes
¿Se necesita una GPU para RAG?
Sí, si el modelo de lenguaje se ejecuta localmente y debe responder rápido. Pero el flujo RAG no carga solo la GPU. La búsqueda, el procesamiento de documentos, la base de datos vectorial, el filtrado, la API y la monitorización requieren CPU, RAM, discos rápidos y una red estable.
¿Se puede empezar con una sola GPU?
Sí, especialmente si se trata de un piloto, la base de conocimiento es pequeña y el número de usuarios es limitado. Pero es mejor comprobar de antemano si se puede añadir una segunda GPU, aumentar la RAM e instalar unidades NVMe adicionales.
¿Qué es más importante: GPU o RAM?
Para generar respuestas son importantes la GPU y la memoria de vídeo. Para la búsqueda, los índices, la caché, el procesamiento de documentos y el funcionamiento estable del servicio son importantes la RAM y los discos. En producción no pueden considerarse por separado.
¿Por qué un chatbot responde lento con una GPU potente?
La causa puede ser un contexto largo, una base de datos vectorial lenta, una CPU débil, falta de RAM, almacenamiento lento, colas de solicitudes o una mala configuración de inferencia.
¿Se necesita un servidor separado para la base de datos vectorial?
No siempre para un piloto. Para producción, una base de conocimiento grande, varios departamentos y alta carga, un nodo separado para la base de datos vectorial puede estar justificado.
¿Qué es mejor: un modelo grande o una buena búsqueda?
Para un RAG corporativo, una buena búsqueda y una preparación de documentos de calidad suelen ser más importantes. Un modelo grande no corregirá archivos obsoletos, mala indexación ni falta de comprobación de derechos de acceso.
¿Qué hay que comprobar antes de comprar?
Hay que comprobar la capacidad de memoria de vídeo, RAM, CPU, NVMe, red, potencia, refrigeración, compatibilidad de controladores, posibilidades de actualización, monitorización, copias de seguridad, derechos de acceso y requisitos de almacenamiento de datos.
Conclusión
Un servidor GPU para RAG y un chatbot corporativo debe elegirse a partir de la tarea, no del nombre de la tarjeta gráfica. Es importante entender de antemano qué documentos se utilizarán, con qué frecuencia se actualizarán, cuántos usuarios harán preguntas, qué contexto necesita el modelo, qué datos no pueden salir de la empresa y qué tiempo de respuesta se considera aceptable.
Un buen servidor para RAG es un sistema equilibrado: GPU para generación, CPU para procesamiento, RAM para índices y cachés, NVMe para datos rápidos, red para integraciones, monitorización para control de calidad y seguridad para proteger la información corporativa. Si estas partes se planifican de antemano, el chatbot es más fácil de lanzar, escalar y mantener en producción.
