La implementació de sistemes de Retrieval-Augmented Generation (RAG) en entorns de producció és un repte que va molt més enllà d’un diagrama d’arquitectura. Quan les empreses necessiten desplegar el NVIDIA RAG Blueprint sobre Kubernetes amb Helm, s’enfronten a decisions crítiques sobre GPU, emmagatzematge, xarxes, seguretat i escalabilitat. Aquest article ofereix una guia tècnica original basada en l’experiència de Q2BSTUDIO, empresa especialitzada en el desenvolupament d’aplicacions a mida i solucions d’intel·ligència artificial, perquè qualsevol organització pugui portar aquest blueprint a producció amb èxit.
El RAG Blueprint de NVIDIA no és un únic pod d’aplicació; és una plataforma de recuperació coordinada que integra un servei d’ingesta, un servidor RAG, microserveis NIM de NVIDIA, NV-Ingest, una base de dades vectorial, emmagatzematge d’objectes, memòries cau de models i operadors de Kubernetes. Tot orquestrat mitjançant Helm, cosa que proporciona repetibilitat però no elimina la necessitat de dissenyar cada component amb cura.
Abans de començar el desplegament, cal validar els requisits de plataforma: Kubernetes 1.34.2 sobre Ubuntu 22.04 o 24.04, Helm 3, driver GPU 560 o superior i CUDA 12.9. No obstant, cada clúster té les seves particularitats. A Q2BSTUDIO recomanem verificar la compatibilitat amb la vostra distribució de Kubernetes, proveïdor cloud (AWS o Azure) i versió del GPU Operator abans de qualsevol instal·lació. Una fallada en aquest pas pot provocar temps d’inactivitat difícils de diagnosticar.
La capacitat de GPU és un altre punt crític. El perfil complet del blueprint requereix fins a 8 GPUs H100 de 80 GB, però també hi ha configuracions MIG que redueixen el consum a 5 H100. La decisió s’ha de basar en la càrrega de treball real: si predominen les consultes interactives o la ingesta massiva de documents. Una infraestructura cloud ben dimensionada, com la que oferim als nostres serveis de cloud AWS i Azure, permet ajustar dinàmicament aquests recursos.
El primer pas tècnic és instal·lar els operadors base: el NVIDIA GPU Operator i el NIM Operator. Ambdós gestionen el cicle de vida dels controladors, la integració amb el runtime de contenidors i el descobriment de GPUs. Després, es desplega l’operador ECK per a Elasticsearch, que és la base de dades vectorial per defecte a la versió 2.6.0. Alternativament, es pot utilitzar Milvus, tot i que canviar de backend requereix reingerir tots els documents. A Q2BSTUDIO solem optar per Elasticsearch quan l’equip ja té experiència en cerca híbrida i filtratge per metadades, mentre que Milvus és preferible per a càrregues purament vectorials.
La configuració de Helm es fa mitjançant un fitxer d’override que modifica només els valors necessaris: secrets de NGC, classes d’emmagatzematge, persistència de volums i exposició de serveis. Mai s’ha de copiar tot el fitxer values.yaml per defecte, ja que això dificulta futures actualitzacions. Un exemple mínim inclou instruccions perquè el chart no creï secrets (utilitzant els preexistents), defineixi StorageClasses amb rendiment previsible i mantingui els serveis interns mitjançant ClusterIP. La seguretat és primordial: els serveis NIM, Redis, Elasticsearch i SeaweedFS no s’han d’exposar mai directament a xarxes no fiables.
Durant el desplegament, cal monitoritzar les memòries cau de models NIM, que poden trigar entre 40 i 50 minuts a descarregar-se per primera vegada. La comanda helm upgrade --install amb la bandera --atomic i un timeout de 90 minuts és adequada. A Q2BSTUDIO hem vist equips frustrats perquè reinicien pods que encara s’estan inicialitzant; és millor inspeccionar els recursos nimcache i nimservice abans d’actuar.
Un cop desplegat, la validació ha de separar el camí d’ingesta del de consulta. No n’hi ha prou que el servidor RAG respongui a un health check; cal pujar un document de prova, verificar que els chunks apareixen a la base de dades vectorial, que la recuperació funciona i que la resposta està fonamentada. Per a això, es pot utilitzar el port-forward del servei ingestor i el RAG server. A més, l’avaluació ha d’incloure un conjunt representatiu de preguntes amb respostes conegudes, tant literals com parafrasejades, i mesurar mètriques com precisió, rellevància del context i fidelitat de la resposta.
La seguretat d’un sistema RAG va més enllà dels secrets. El control d’accés s’ha d’aplicar a nivell de metadades: cada document pot tenir camps com business_domain, classification o owner, que el servidor RAG ha de filtrar de forma obligatòria segons la identitat autenticada de l’usuari. Mai s’ha de confiar en filtres proporcionats pel client. A Q2BSTUDIO integrem solucions de ciberseguretat per garantir que l’autenticació, autorització i auditoria siguin robustes.
L’observabilitat és un altre pilar. El blueprint inclou OpenTelemetry, Zipkin, Prometheus i Grafana. És recomanable activar el stack empaquetat només si no es disposa d’una plataforma corporativa de telemetria. Les mètriques clau inclouen latència extrem a extrem, temps de recuperació, temps de reranking, temps de generació, throughput d’ingesta i utilització de GPU. Amb aquestes dades, es poden identificar colls d’ampolla i escalar horitzontalment els components adequats.
L’ús de MIG (Multi-Instance GPU) permet consolidar càrregues de treball en menys GPUs, però no és un simple interruptor de Helm. Requereix pedaçar el ClusterPolicy del GPU Operator, aplicar una configuració específica per al model H100 i etiquetar els nodes. El perfil MIG redueix la capacitat d’ingesta massiva, per la qual cosa s’ha d’avaluar amb els fitxers reals més pesats. En projectes d’IA i agents intel·ligents, on combinem automatització i anàlisi predictiva, solem reservar GPUs completes per als models de generació i utilitzar MIG només per a serveis lleugers d’extracció i reranking.
La migració entre bases de dades vectorials (Elasticsearch a Milvus) no és trivial: requereix reingerir tots els documents perquè el blueprint no migra índexs automàticament. Per això, és fonamental decidir el backend al inici i documentar l’esquema de metadades. A més, la inclusió de cerca híbrida (densa i dispersa) i reranking s’ha de fer després de validar el flux bàsic. Ajustar pesos o top-k sense un conjunt d’avaluació pot empitjorar la qualitat.
Finalment, la gestió del cicle de vida inclou actualitzacions segures i rollback. Abans de qualsevol actualització del chart, s’han d’exportar els valors actuals, fer còpia de seguretat de les dades vectorials i d’objectes, i executar la bateria d’avaluació. Helm rollback no restaura dades, per la qual cosa és necessari un pla de recuperació específic.
A Q2BSTUDIO, com a empresa de desenvolupament de programari, ajudem les organitzacions a desplegar plataformes RAG robustes sobre Kubernetes, integrant Business Intelligence amb Power BI, agents d’IA i cloud híbrid. La nostra experiència en ciberseguretat, cloud AWS/Azure i aplicacions a mida garanteix que el blueprint no només funcioni, sinó que compleixi amb els estàndards de producció més exigents. Si la vostra organització busca implementar RAG amb garanties, contacteu amb el nostre equip.
