Créer son RAG simplement

Tout le monde parle de l’IA en ce moment, nous les utilisons tous et avons nos préférés selon nos demandes. Quoiqu’il en soit, cela fait maintenant depuis 2018 que je travaille sur des sujets FinOps.

J’ai donc accumulé énormément de documents sur les sujets FinOps, livrables clients, ebooks, documentations, etc… Bien entendu, il ne me viendrait pas à l’idée de créer ou d’injecter dans une IA publique ces documents pour des raisons évidentes de confidentialité. L’idée est donc de me créer un RAG (Retrieval Augmented Generation) que j’alimenterais avec toute cette masse d’information.

Pour rappel, la RAG fournit un moyen d’optimiser le résultat d’un LLM avec des informations ciblées, sans modifier le modèle sous-jacent lui-même ; ces informations ciblées peuvent être plus récentes que le LLM ainsi que spécifiques à une entreprise et à un secteur particuliers. Cela signifie que le système d’IA générative peut fournir des réponses contextuellement appropriées aux invites et les baser sur des données extrêmement récentes ou pertinente, c’est à dire les miennes.

Tour d’horizon de ma réflexion…

Dans l’idée: je souhaite créer un RAG gratuit sous Windows avec une interface graphique complète (chat, option, paramétrage, export, …) basé sur Mistral. L’entrainement du modèle et l’indexation doivent utiliser ma carte graphique nVidia RTX3060 et  l’indexation doit être sauvegardée et le modèle entrainé avec mes documents et qu’il soit exportable. Le tout en open-source bien entendu…

Mon PC: AMD Ryzen-5 5600X 6 coeurs avec une nVidia RTX 3060 – 64 Gb de mémoire – Stockage NVME

Ma base documentaire: 421 fichiers pour 2.35 Go.

PREREQUIS: Installer le CUDA ToolKit de nVidia (ou AMD ROCm)

Rapidement, il va falloir jouer avec pytorch, langchain, conda/anaconda, gradio, FAISS, OpenAIEmbeddings, Ollama, etc…

Sauf que je ne suis pas un expert python… et je veux quelque chose de simple.

Regardons du côté de mon CSP préféré Microsoft Azure, dont le coût va dépendre de plusieurs facteurs:

• Stockage des documents (Blob Storage, Azure Files)
• Indexation des documents (Azure AI Search, VMs, CPU/GPU)
• Modèle LLM (Azure OpenAI, VM avec GPU)
• Infrastructure d’exécution (VM, App Service, Containers, Functions)
• Réseau et transfert de données

1. Stockage des Documents (PDF, DOCX, etc.)

Azure Blob Storage

• Coût : Environ €0.0184/Go/mois (Stockage standard)
• Exemple : Pour 2.35 Go de documents, environ €0.4/mois

2. Indexation des Documents

Azure AI Search (Pour la recherche vectorielle)

• Coût : À partir de €95/mois (SKU de base)
• Alternatives :
  • VM avec FAISS/ChromaDB : À partir de €30-50/mois (VM série B ou D)
  • Azure CosmosDB (vector search) : Payant selon requêtes (~€10-50/mois)

3. Modèle LLM (Mistral, GPT, Phi-4, etc.)

Azure OpenAI Service (Accès aux modèles GPT)

• Coût :
  • GPT-4 Turbo : €2.8/million tokens (input), €8.4/million tokens (output)
  • Phi-2 (Modèle léger) : Moins cher (~€0.25/million tokens)

VM avec GPU (Modèle Local Mistral, Mixtral, Phi-3, etc.)

• Exemple : NCasT4_v3 (1x T4 GPU, 16 Go VRAM) → ~€700/mois
• Alternatives : Spot VM (~30-50% moins cher)

Infrastructure d’Exécution

Azure App Service (hébergement API/Interface RAG)

• Coût : ~ €15-50/mois (plan standard)
• Alternatives :
  • Azure Functions (serverless) : Paye par exécution
  • VM série B (B2s, B2ms) : ~€10-20/mois

5. Réseau et Transfert de Données

• Transfert sortant : €0.074/Go au-delà de 5 Go gratuits
• Interne Azure (entre services) : Gratuit dans la même région

Bon, en scénarisant un peu la chose, on arrive à

• Petit RAG (<50K documents, GPT-4 API, stockage simple) : ~€50-150/mois
• Moyen RAG (Azure AI Search, Phi-4 ou GPT, API usage élevé) : ~€150-300/mois
• RAG GPU (Mistral/Mixtral local, index vectoriel sur VM) : ~€700-1000/mois

Après on peux optimiser les coûts avec un mix FAISS + Mistral GGUF..

Conclusion: ça fait cher pour mon RAG.

J’ai donc regardé les solutions prête à l’emploi telles que entre GPT4ALL, ChatRTX, Anaconda, … mais aucune ne m’ a donnée satisfaction entière.

Je suis alors tombé sur MSTY dont le moto est: « une application, une installation en un clic, pas de Docker, pas de terminal, hors ligne et privé, des fonctionnalités uniques et puissantes. » et évite une installation pénible, des configurations interminables, une interface utilisateur confuse si elle existe via un DEV custom Gradio par exemple, jongler avec docker, pas de confidentialité, pas de contrôle, …

MTSY importe des modèle online ollama ou hugglingface ou import de GGUF, gère l’indexation et le query nativement, donc  pas besoin de FAISS ou ChromaDB, … Tout passe par le mécanisme intégré de stockage et de récupération d’embeddings.

Principales différences

En résumé :

• Hugging Face est une plateforme complète pour l’IA, utile pour le fine-tuning et le partage de modèles.
• Ollama est une solution ultra simple pour faire tourner des modèles en local sans prise de tête.

Un GGUF (GGML Unified Format) est un format de fichier utilisé pour stocker des modèles de langage optimisés pour l’inférence sur CPU et GPU. Il est principalement utilisé par llama.cpp et d’autres runtimes comme Ollama, GPT4All, et Mistral.cpp.

Différence avec d’autres formats

Dans « Local AI Model », tu peux choisir un modèle avec un Model Purpose spécifique :

Un modèle IA (comme ceux utilisés avec MTSY) est un programme entraîné pour comprendre et générer du texte en se basant sur des milliards de données.

Concrètement, un modèle fait quoi ?

Un modèle de langage (LLM – Large Language Model) comme Mistral, Llama, Gemma :

• Comprend des questions et y répond de manière cohérente.
• Analyse et résume du texte (exemple : résumer un PDF FinOps)
• Génère du contenu (exemple : rédiger un email, un rapport)
• Fait des calculs, de la logique simple (exemple : estimer un coût)
• Peut s’adapter à un domaine précis (exemple : FinOps dans mon cas).

Un modèle, c’est un « cerveau » IA

• Il est entraîné sur d’énormes bases de textes (livres, sites web, articles).
• Il prédit les mots suivants en fonction du contexte (comme un correcteur intelligent, mais beaucoup plus avancé).
• Il fonctionne sans connexion internet s’il est local (ex. : MTSY + un modèle GGUF).

Pourquoi a-t-on besoin d’un modèle dans MTSY ?

• MTSY n’est qu’un outil qui gère l’interface utilisateur et l’indexation de tes documents.
• Le modèle fait le travail : c’est lui qui comprend ta question et trouve la meilleure réponse.
• Sans modèle, MTSY ne peut pas « réfléchir » ni générer de réponse.

Exemples de modèles compatibles avec MTSY

• Mistral 7B (GGUF) → Léger, rapide, performant pour du texte général.
• Llama 3 (GGUF) → Plus puissant, mais plus lourd.
• Phi-2, Gemma → Petits modèles pour PC sans gros GPU.

Maintenant, et vous le savez c’est la jungle, il me faut choisir un model et un embedding. N’oubliez pas que je porte mon choix sur la langue Française et une utilisation de mon GPU RTX3060 !

Comparatif des modèles LLM

Comparaison des modèles d’Embedding

Si tu veux le meilleur modèle d’Embedding pour MTSY, voici une comparaison détaillée des versions BGE-Small, BGE-M3 et BGE-Large

Langues supportées par les modèles

Les modèles LLM (chat) et embedding n’ont pas tous le même support de langue.

Recommandation finale pour MTSY avec RTX 3060

Modèle d’Embedding recommandé : BGE-M3 (GGUF)
Modèle de Chat recommandé : Mistral 7B (GGUF Q4_0 ou Q5_1)

Analyse concrète du build de mon RAG contextualisé FinOps

Au préalable, comme indiqué en pré-requis, j’ai installé le SDK CUDA pour utiliser mon GPU nVidia dans le cadre dmon RAG. La réponse à le commande python ci-dessous doit renvoyer TRUE.

python -c "import torch; print(torch.cuda.is_available())"

Installation des Local AI Models bge-3:latest en embedding et mistral:7b en text dans MSTY.

Je crée mon Knowledge Stack dédié FinOps, composé de 421 fichiers pour 2.35 Go.

Je lance le COMPOSE, qui va durer 1h01 à  377 Watts mesuré au Wattmètre.

Je calcule le coût de génération de mon RAG selon cette formule Coût=Consommation(kWh)×Prix du kWh(€) soit 0,377×1,0167=0,3834 kWh soit 0,3834×0,25=0,096€≈9,6 centimes.

Si vous connaissez GRADIO, ci-dessous une petite application qui permet aussi de mesurer votre consommation si vous ne disposez pas d’un wattmètre.

import gradio as gr
import psutil
import time
import pandas as pd
import matplotlib.pyplot as plt
from pynvml import *

# Initialisation de NVIDIA Management Library (NVML)
nvmlInit()
gpu_handle = nvmlDeviceGetHandleByIndex(0)  # GPU 0

data = []  # Historique des mesures

def get_power_usage():
    # CPU power estimation (pas toujours précis selon le CPU)
    cpu_power = psutil.cpu_percent() * 1.5  # Approximation
    cpu_load = psutil.cpu_percent()
    
    # GPU power usage
    gpu_power = nvmlDeviceGetPowerUsage(gpu_handle) / 1000.0  # Converti en Watts
    gpu_load = nvmlDeviceGetUtilizationRates(gpu_handle).gpu
    
    # RAM usage
    ram_usage = psutil.virtual_memory().percent
    
    timestamp = time.strftime('%H:%M:%S')
    data.append([timestamp, cpu_power, gpu_power, ram_usage, cpu_load, gpu_load])
    
    return cpu_power, gpu_power, ram_usage, cpu_load, gpu_load

def plot_metrics():
    if len(data) < 2:
        return None  # Pas assez de données
    
    df = pd.DataFrame(data, columns=['Time', 'CPU (W)', 'GPU (W)', 'RAM (%)', 'CPU Load (%)', 'GPU Load (%)'])
    df = df.tail(100)  # Garde les 100 dernières entrées
    
    fig, ax = plt.subplots(figsize=(8, 4))
    ax.plot(df['Time'], df['CPU (W)'], label='CPU (W)', color='r')
    ax.plot(df['Time'], df['GPU (W)'], label='GPU (W)', color='b')
    ax.plot(df['Time'], df['CPU Load (%)'], label='CPU Load (%)', linestyle='dashed', color='orange')
    ax.plot(df['Time'], df['GPU Load (%)'], label='GPU Load (%)', linestyle='dashed', color='purple')
    ax.set_xlabel('Temps')
    ax.set_ylabel('Valeurs')
    ax.legend()
    ax.grid()
    plt.xticks(rotation=45)
    plt.tight_layout()
    
    return fig

def export_csv():
    df = pd.DataFrame(data, columns=['Time', 'CPU (W)', 'GPU (W)', 'RAM (%)', 'CPU Load (%)', 'GPU Load (%)'])
    df.to_csv('power_usage.csv', index=False)
    return "Fichier CSV exporté !"

def monitor():
    cpu, gpu, ram, cpu_load, gpu_load = get_power_usage()
    fig = plot_metrics()
    return cpu, gpu, ram, cpu_load, gpu_load, fig

# Interface Gradio
with gr.Blocks() as app:
    gr.Markdown("## Suivi de la consommation électrique du PC ⚡")
    
    with gr.Row():
        cpu_output = gr.Number(label="CPU (W)")
        gpu_output = gr.Number(label="GPU (W)")
        ram_output = gr.Number(label="RAM (%)")
        cpu_load_output = gr.Number(label="Charge CPU (%)")
        gpu_load_output = gr.Number(label="Charge GPU (%)")
    
    graph_output = gr.Plot()
    
    with gr.Row():
        refresh_button = gr.Button("Rafraîchir")
        export_button = gr.Button("Exporter CSV")
    
    refresh_button.click(monitor, outputs=[cpu_output, gpu_output, ram_output, cpu_load_output, gpu_load_output, graph_output])
    export_button.click(export_csv, outputs=[])

app.launch()

Bon… Désormais, mon modèle (Knowledge Stack) est entrainé, je lui pose un question dont je sais que les réponses sont contenues dans mes documents qui ont servis à alimenter mon RAG.

Pour être sûr qu’il interroge bien mon RAG local, je regarde les citations, et c’est bien le cas , pour me générer cette réponse, cela a consommé 4.59 tokens/sec, 8.91s pour le premier token.

MSTY en local vs Azure OpenAI : une comparaison pragmatique

Mon objectif est d’exploiter un RAG sur une base documentaire réduite tout en maîtrisant coûts, performances et « souveraineté/confidentialité », voici une comparaison entre MSTY et Azure :

On résume:

• Azure OpenAI devient rapidement coûteux : à partir de 10 000 requêtes par jour, MSTY devient 30 fois moins cher en exploitation.
• MSTY a un coût fixe (lié à l’électricité et au matériel), alors qu’Azure est 100% variable et peut exploser en cas de pic d’usage.

Consommation énergétique et empreinte carbone

Pou résumer:

• MSTY consomme 5x moins qu’Azure pour le même volume de requêtes.
• Empreinte carbone divisée par 6 avec un modèle local, surtout si ton électricité est verte.

Performances et latence

Mon analyse, et soyons TRES CLAIR:

• Azure est 4 à 6 fois plus rapide grâce à son infra de dingue…
• MSTY subit un délai d’amorçage mais reste suffisant pour des usages non temps réel (un réponse peut prendre jusque 1 min..)

Confidentialité et souveraineté

On résume:

• MSTY garantit la souveraineté totale des données, ce qui est clé pour les documents sensibles.
• Azure peut être soumis aux réglementations américaines (Cloud Act, Trump etc….)

BON SINON: MSTY ou Azure OpenAI ?

Si ton besoin est un RAG sur une petite base documentaire, comme moi, avec une maîtrise « totale des coûts » (on relativise hein…)  et de la souveraineté/confidentialité alors , MSTY en local est clairement le meilleur choix.

MSTY en local :

• 9,6 centimes d’indexation vs des centaines d’€ chez Azure
• 5x moins de consommation énergétique et 6x moins de CO₂
• Zéro dépendance à un service cloud et 100% de souveraineté
• Moins performant en temps de réponse MAIS j’adore le fait qu’il se base sur mes documents…

Azure OpenAI :

• Rapide et scalable
• Coût raisonnable si usage faible (<10 000 requêtes/jour)
• Facture explosive à volume élevé (30x plus cher sur 100 000 requêtes/jour)
• Dépendance et risques liés à la gestion des données

Pour une base documentaire interne en FinOps, MSTY est le meilleur compromis entre coût, souveraineté et empreinte carbone. Azure OpenAI ne devient pertinent que si l’on cherche à scaler avec des besoins temps réel important et performant…