Local AI on kenji.blog

Comment affiner TinyLLaMA le plus rapidement possible dans un environnement sur site

Fri, 11 Sep 2026 16:00:00 +0900

1. Introduction : Pourquoi TinyLLaMA et le sur site aujourd’hui ?

L’évolution des grands modèles de langage (LLM) progresse à une vitesse fulgurante, et avec elle, le nombre de paramètres des modèles continue de s’étendre pour atteindre des centaines de milliards. Si des modèles gigantesques comme GPT-4 et Claude 3 offrent des performances inégalées, les coûts de calcul pour l’inférence et l’apprentissage, ainsi que les problèmes de sécurité et de confidentialité des données lors de l’utilisation d’API externes, constituent des obstacles majeurs pour les entreprises. En particulier pour les tâches impliquant des données internes hautement confidentielles ou des informations personnelles, l’envoi de données à des API LLM publiques dans le cloud est souvent inacceptable du point de vue de la conformité (RGPD, APPI, etc.).

C’est là que les petits modèles de langage (SLM : Small Language Models) et le déploiement local dans des environnements sur site (on-premises) entrent en jeu. Parmi eux, “TinyLLaMA” se distingue. Avec une taille compacte de seulement 1,1B (1,1 milliard) de paramètres, il a été pré-entraîné sur un ensemble de données massif d’environ 3 billions de jetons (tokens), offrant des performances exceptionnelles par rapport aux modèles de la même catégorie.

Cet article fournit un guide complet pour affiner (fine-tuning) TinyLLaMA de manière “ultra-rapide et très efficace” pour vos tâches spécifiques dans un environnement sur site (serveur local ou station de travail). Nous couvrirons tout de manière exhaustive, des fondements mathématiques aux dernières techniques d’optimisation, en passant par le code d’implémentation concret en PyTorch.

2. Architecture et caractéristiques de TinyLLaMA

TinyLLaMA suit l’architecture LLaMA (Large Language Model Meta AI) développée par Meta. Tout en maintenant le nombre de paramètres à 1,1B, il utilise la même pile technologique que LLaMA 2, ce qui rend son écosystème hautement compatible.

Principaux composants de l’architecture

RMSNorm (Root Mean Square Normalization) : Une méthode de normalisation qui améliore l’efficacité des calculs en omettant la soustraction de la moyenne des calculs LayerNorm traditionnels. Elle augmente le débit tout en maintenant la stabilité de l’apprentissage.
Fonction d’activation SwiGLU : Dans le Feed Forward Network (FFN), SwiGLU est utilisé à la place des classiques ReLU ou GELU. Mathématiquement, cela s’exprime comme suit : $$ \text{SwiGLU}(x, W, V) = \text{Swish}(xW) \otimes (xV) $$ Ici, $\otimes$ représente le produit élément par élément (produit de Hadamard), et la fonction Swish est $\text{Swish}(z) = z \cdot \sigma(\beta z)$. Cela améliore considérablement la puissance de représentation.
RoPE (Rotary Position Embedding) : Une méthode qui combine les avantages de l’encodage de position absolu et relatif. Elle présente de fortes performances de généralisation même lorsque la longueur de la séquence est étendue.
Grouped Query Attention (GQA) : Une approche intermédiaire entre la Multi-Head Attention (MHA) et la Multi-Query Attention (MQA), qui permet d’économiser la bande passante mémoire et d’améliorer considérablement la vitesse d’inférence en regroupant les têtes de clé (key) et de valeur (value).

Le diagramme Mermaid ci-dessous illustre le flux de données global de TinyLLaMA et la structure du bloc Transformer.

graph TD A["Texte d'entrée"] --> B["Tokeniseur (BPE)"] B --> C["Couche d'intégration (Embedding)"] C --> D["Blocs Transformer (x22 Couches pour TinyLLaMA)"] D --> E["RMSNorm (Final)"] E --> F["Projection Linéaire (Taille du vocabulaire)"] F --> G["Probabilités de sortie (Softmax)"] subgraph "Anatomie du bloc Transformer" D1["État caché d'entrée"] --> D2["RMSNorm"] D2 --> D3["Grouped Query Attention (GQA)"] D3 --> D4["Ajout Résiduel"] D4 --> D5["RMSNorm"] D5 --> D6["FFN SwiGLU"] D6 --> D7["Ajout Résiduel"] D7 --> D8["Sortie vers la couche suivante"] D1 -.-> D4 D4 -.-> D7 end

3. La révolution du Fine-Tuning : LoRA et QLoRA

Pour effectuer un fine-tuning avec tous les paramètres dans un environnement sur site, même avec un modèle de 1,1B, il faut consommer des dizaines de gigaoctets de VRAM (mémoire vidéo) pour stocker les états de l’optimiseur et les gradients. Les méthodes PEFT (Parameter-Efficient Fine-Tuning) telles que “LoRA” et son extension quantifiée “QLoRA” sont essentielles pour un apprentissage efficace avec des ressources limitées.

3.1 Contexte mathématique de LoRA (Low-Rank Adaptation)

LoRA est une méthode qui fixe (gèle) la matrice de poids pré-entraînée et approxime la quantité de mise à jour de ce poids ($\Delta W$) par le produit de deux petites matrices de rang inférieur.

Soit $W_0 \in \mathbb{R}^{d \times k}$ le poids pré-entraîné. Dans un fine-tuning complet, $W_0$ lui-même est mis à jour en $W_0 + \Delta W$. Cependant, avec LoRA, la matrice de mise à jour $\Delta W$ est décomposée comme suit :

$$ \Delta W = B \times A $$

Ici, $B \in \mathbb{R}^{d \times r}$ et $A \in \mathbb{R}^{r \times k}$, et $r$ est un hyperparamètre appelé rang (Rank), qui est une très petite valeur (généralement 8, 16, 32, etc.) satisfaisant $r \ll \min(d, k)$.

Le calcul de la passe avant (forward pass) est le suivant :

$$ h = W_0 x + \Delta W x = W_0 x + B A x $$

À l’état initial, la matrice $A$ est initialisée de manière aléatoire avec une distribution normale (distribution gaussienne), et la matrice $B$ est initialisée avec une matrice nulle. Ainsi, $\Delta W$ au début de l’apprentissage est zéro, ce qui permet de commencer l’apprentissage tout en conservant parfaitement la sortie du modèle de base.

graph LR X["Vecteur d'entrée x"] --> W0["Poids pré-entraîné gelé (W_0)"] X --> A["Matrice LoRA entraînable A (r x k)"] A --> B["Matrice LoRA entraînable B (d x r)"] W0 --> Add["Addition vectorielle"] B --> Add Add --> Y["Vecteur de sortie h"]

3.2 L’innovation de QLoRA (Quantized LoRA)

QLoRA pousse l’approche LoRA encore plus loin en quantifiant le modèle de base $W_0$ avec une précision de 4 bits (NormalFloat 4, NF4) et en le chargeant en mémoire. Cela réduit considérablement la consommation de VRAM.

QLoRA intègre trois technologies importantes :

Quantification 4-bit NormalFloat (NF4) : Un type de données théoriquement optimal pour les poids suivant une distribution normale.
Double Quantification (Double Quantization) : Économise encore plus de mémoire en quantifiant également la constante de quantification (facteur d’échelle) elle-même.
Paged Optimizers : Utilise la fonction de mémoire unifiée de NVIDIA pour évacuer temporairement le statut de l’optimiseur vers la RAM du processeur lorsque la VRAM est insuffisante.

Grâce à cela, un fine-tuning qui nécessite normalement 16 à 24 Go de VRAM peut être exécuté confortablement même sur des GPU grand public (comme la RTX 3060 12 Go ou la RTX 4070).

4. Exigences matérielles et configuration dans un environnement sur site

Les exigences matérielles pour affiner TinyLLaMA (1,1B) avec QLoRA sont extrêmement faibles.

Spécifications matérielles recommandées

GPU : NVIDIA RTX 3060 (12 Go), RTX 3090/4090 (24 Go), ou NVIDIA A10G/A100, etc. Un minimum de 8 Go de VRAM est nécessaire pour fonctionner, mais 12 Go ou plus sont recommandés pour augmenter la taille du lot (batch size).
CPU : Processeur moderne à 8 cœurs ou plus (Intel Core i7/i9, AMD Ryzen 7/9)
RAM : 32 Go ou plus (Important comme destination d’évacuation depuis la VRAM lors de l’utilisation de Paged Optimizers)
Stockage : SSD NVMe (Pour accélérer le chargement des ensembles de données et la sauvegarde du modèle)

Configuration de l’environnement logiciel

Voici les étapes d’installation prévues pour un environnement Ubuntu 22.04 LTS. Nous utiliserons Python 3.10 ou une version ultérieure.

1
2
3
4
5
6
7
8
9


# Création et activation de l'environnement virtuel
python3 -m venv tinyllama_env
source tinyllama_env/bin/activate

# Installation de PyTorch (pour CUDA 12.1)
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

# Installation des bibliothèques liées aux Transformers
pip install transformers datasets peft trl accelerate bitsandbytes

5. Techniques d’optimisation pour le fine-tuning le plus rapide

Pour terminer le fine-tuning “le plus rapidement possible” plutôt que de simplement exécuter un script, il est nécessaire de combiner les techniques d’optimisation suivantes.

5.1 Flash Attention 2

Le mécanisme d’Attention standard a une complexité temporelle et spatiale de $O(N^2)$ pour une longueur de séquence $N$. Flash Attention 2 optimise l’accès mémoire entre la SRAM du GPU et la HBM (High Bandwidth Memory), éliminant ainsi les goulots d’étranglement d’E/S sans réduire la quantité de calcul, augmentant la vitesse d’apprentissage de plusieurs fois et réduisant considérablement la consommation de mémoire.

5.2 Gradient Checkpointing (Point de contrôle du gradient)

Une technique dans laquelle, au lieu de sauvegarder toutes les activations intermédiaires calculées lors de la passe avant dans la VRAM, seule une partie est sauvegardée, et elles sont recalculées lorsqu’elles sont nécessaires lors de la passe arrière. Le temps de calcul augmente d’environ 20 %, mais la consommation de mémoire peut être considérablement réduite, ce qui permet de définir une taille de lot plus importante et d’améliorer le débit global.

5.3 Mixed Precision Training (Apprentissage en précision mixte) et Bfloat16

Pour maximiser l’utilisation des Tensor Cores du GPU, les calculs pendant l’apprentissage sont effectués en bfloat16 (Brain Floating Point). Par rapport à float16, la longueur en bits de l’exposant est la même que celle de float32, de sorte que le risque de dépassement de capacité (overflow) ou de sous-dépassement (underflow) est extrêmement faible, ce qui stabilise l’apprentissage.

6. Pratique : Code de fine-tuning QLoRA pour TinyLLaMA

Nous allons maintenant expliquer le script PyTorch pour le fine-tuning le plus rapide intégrant toutes les optimisations ci-dessus. Nous utiliserons ici SFTTrainer de la bibliothèque trl (Transformer Reinforcement Learning) de Hugging Face.

6.1 Préparation de l’ensemble de données et chargement du modèle

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


import torch
from datasets import load_dataset
from transformers import (
 AutoModelForCausalLM,
 AutoTokenizer,
 BitsAndBytesConfig,
 TrainingArguments
)
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from trl import SFTTrainer

# 1. Spécification du modèle et du tokeniseur
model_id = "TinyLlama/TinyLlama-1.1B-Chat-v1.0"

# 2. Paramètres de quantification 4-bit pour QLoRA
bnb_config = BitsAndBytesConfig(
 load_in_4bit=True,
 bnb_4bit_use_double_quant=True,
 bnb_4bit_quant_type="nf4",
 bnb_4bit_compute_dtype=torch.bfloat16 # Les calculs sont effectués en bfloat16
)

# 3. Chargement du modèle (Activation de Flash Attention 2)
print("Chargement du modèle...")
model = AutoModelForCausalLM.from_pretrained(
 model_id,
 quantization_config=bnb_config,
 device_map="auto",
 use_flash_attention_2=True # La clé de l'accélération
)

# 4. Chargement du tokeniseur
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "right" # Défini sur right pour éviter un bug lors de l'entraînement fp16/bf16

6.2 Application de l’adaptateur LoRA et formatage des données

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# 5. Préparation de l'apprentissage k-bit et activation du gradient checkpointing
model.gradient_checkpointing_enable()
model = prepare_model_for_kbit_training(model)

# 6. Configuration de LoRA
peft_config = LoraConfig(
 r=16, # Rang
 lora_alpha=32, # Facteur d'échelle
 lora_dropout=0.05,
 bias="none",
 task_type="CAUSAL_LM",
 target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"] # Cibler toutes les couches Linear améliore les performances
)

model = get_peft_model(model, peft_config)
model.print_trainable_parameters()
# Exemple de sortie : trainable params: 14,286,848 || all params: 1,114,335,232 || trainable%: 1.282%

# 7. Chargement de l'ensemble de données (ici, un ensemble de données d'instructions en japonais est utilisé comme exemple)
# En réalité, vous chargerez un fichier JSONL privé sur site, etc.
dataset = load_dataset("kunishou/databricks-dolly-15k-ja", split="train")

def format_instruction(sample):
 """
 Formate la chaîne pour correspondre au format ChatML ou au modèle de prompt
 """
 prompt = f"<|im_start|>user\n{sample['instruction']}"
 if sample.get("input", "") != "":
 prompt += f"\n{sample['input']}"
 prompt += f"<|im_end|>\n<|im_start|>assistant\n{sample['output']}<|im_end|>"
 return {"text": prompt}

dataset = dataset.map(format_instruction)

6.3 Exécution de l’entraînement

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


# 8. Configuration des arguments d'entraînement
training_args = TrainingArguments(
 output_dir="./tinyllama-lora-output",
 per_device_train_batch_size=8, # Augmenter s'il y a assez de VRAM
 gradient_accumulation_steps=2, # Taille de lot effective = 8 * 2 = 16
 optim="paged_adamw_32bit", # Économie de VRAM avec Paged Optimizer
 save_steps=100,
 logging_steps=10,
 learning_rate=2e-4,
 fp16=False,
 bf16=True, # Apprentissage en précision mixte (bfloat16)
 max_grad_norm=0.3,
 max_steps=500, # 500 étapes pour les tests. En production, spécifier par nombre d'époques
 warmup_ratio=0.03,
 group_by_length=True,
 lr_scheduler_type="cosine",
)

# 9. Démarrage de l'apprentissage avec SFTTrainer
trainer = SFTTrainer(
 model=model,
 train_dataset=dataset,
 peft_config=peft_config,
 dataset_text_field="text",
 max_seq_length=1024, # Ajuster selon la longueur d'entrée prévue
 tokenizer=tokenizer,
 args=training_args,
)

print("Démarrage de l'entraînement...")
trainer.train()

# 10. Sauvegarde de l'adaptateur LoRA
trainer.model.save_pretrained("./tinyllama-lora-final")
tokenizer.save_pretrained("./tinyllama-lora-final")
print("Entraînement terminé et modèle sauvegardé.")

7. Évaluation des performances et dépannage

Voici les problèmes courants rencontrés lors de l’exécution de l’apprentissage dans un environnement sur site et leurs solutions.

OOM (Out Of Memory) se produit :
- Réduisez per_device_train_batch_size à 1.
- Augmentez gradient_accumulation_steps pour maintenir la taille de lot effective.
- Raccourcissez max_seq_length de 2048 à 1024 ou 512.
La perte (Loss) ne diminue pas / diverge :
- Le taux d’apprentissage (learning_rate) peut être trop élevé. Essayez de le réduire de 2e-4 à environ 5e-5.
- Si vous utilisez Float16 au lieu de Bfloat16, un sous-dépassement de gradient peut se produire. Vérifiez bf16=True.
Des chaînes de caractères mystérieuses sont générées lors de l’inférence :
- Assurez-vous que padding_side="right" est correctement défini. Il est également nécessaire de vérifier si le format du jeu de données (les tokens spéciaux comme <|im_start|>) est cohérent avec celui de la phase de pré-entraînement du modèle de base.

8. Déploiement du modèle après le fine-tuning

Une fois le fine-tuning terminé, ce qui est sauvegardé n’est pas “l’ensemble du modèle de base”, mais seulement “l’adaptateur LoRA (poids différentiels)” de quelques mégaoctets à quelques dizaines de mégaoctets. Pour effectuer une inférence à grande vitesse, ce poids LoRA doit être fusionné (intégré) dans le modèle de base d’origine et exporté en tant que modèle unique.

Script de fusion de modèle

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


import torch
from peft import AutoPeftModelForCausalLM
from transformers import AutoTokenizer

output_dir = "./tinyllama-lora-final"

# Charger le modèle et l'adaptateur en FP16/BF16
model = AutoPeftModelForCausalLM.from_pretrained(
 output_dir,
 device_map="auto",
 torch_dtype=torch.bfloat16
)
tokenizer = AutoTokenizer.from_pretrained(output_dir)

# Fusionner les poids et sauvegarder
merged_model = model.merge_and_unload()
merged_model.save_pretrained("./tinyllama-merged", safe_serialization=True)
tokenizer.save_pretrained("./tinyllama-merged")
print("Modèle fusionné et sauvegardé avec succès !")

Lancement d’un serveur d’inférence ultra-rapide avec vLLM

Pour un déploiement dans un environnement sur site, afin de maximiser la vitesse d’inférence (Jetons par seconde), il est fortement recommandé d’utiliser vLLM ou TGI (Text Generation Inference) au lieu du pipeline standard de Hugging Face. vLLM utilise la technologie PagedAttention pour éviter la fragmentation de la mémoire GPU, améliorant considérablement la capacité de traitement des requêtes simultanées.

Le diagramme Mermaid ci-dessous montre le pipeline allant de l’apprentissage au déploiement du serveur d’inférence.

graph TD A["Données privées brutes"] --> B["Prétraitement et formatage (JSONL)"] B --> C["Fine-Tuning QLoRA (SFTTrainer)"] C --> D["Poids de l'adaptateur LoRA (.safetensors)"] D --> E["Fusion avec le TinyLLaMA 1.1B de base"] E --> F["Modèle fusionné"] F --> G["Déploiement via le serveur vLLM"] G --> H["Point de terminaison API / UI (par ex. Chatbot)"]

Le démarrage du serveur d’API avec vLLM s’effectue avec la commande suivante.

1
2
3
4
5
6


python -m vllm.entrypoints.openai.api_server \
 --model ./tinyllama-merged \
 --host 0.0.0.0 \
 --port 8000 \
 --max-model-len 2048 \
 --dtype bfloat16

Avec cela, un point de terminaison compatible avec l’API OpenAI est construit dans l’environnement sur site, vous permettant d’utiliser l’IA locale de manière sécurisée et à haute vitesse.

9. Conclusion

Dans cet article, nous avons expliqué la méthode de fine-tuning de “TinyLLaMA”, qui offre des performances élevées malgré son poids léger de 1,1B de paramètres, de manière très rapide et économe en mémoire dans un environnement sur site.

LoRA / QLoRA permet un véritable fine-tuning de LLM même sur des GPU grand public.
En exploitant Flash Attention 2 et Gradient Checkpointing, le temps d’apprentissage et la consommation de VRAM sont optimisés à l’extrême.
Le déploiement utilisant vLLM permet d’atteindre un débit élevé même dans des environnements de production.

L’exploitation locale de LLM sur site protège non seulement la confidentialité des données, mais constitue également l’arme ultime pour construire à faible coût une IA spécialisée pour un domaine spécifique (juridique, médical, réglementations internes, etc.). N’hésitez pas à utiliser ce guide comme référence pour développer votre propre TinyLLaMA.

Procédure de développement de petits modèles d'IA (TinyLLaMA, etc.) avec C++

Fri, 11 Sep 2026 14:00:00 +0900

Procédure de développement de petits modèles d’IA (TinyLLaMA, etc.) avec C++

Ces dernières années, l’intérêt pour l’exécution locale de grands modèles de langage (LLM) a augmenté rapidement. En particulier, les petits modèles tels que TinyLLaMA (1,1B paramètres) peuvent effectuer des inférences à une vitesse pratique même sur des appareils périphériques aux ressources limitées ou des PC portables standards (y compris les environnements Windows). Bien que le développement utilisant Python et PyTorch soit courant, lorsqu’il s’agit d’atteindre des performances et une efficacité mémoire ultimes, la combinaison du C++ et de « ggml », une bibliothèque de tenseurs basée sur le langage C, est devenue la norme de facto.

Cet article explique en détail la procédure de développement pour construire un moteur d’inférence à partir de zéro (ou comprendre en profondeur l’architecture interne du llama.cpp existant) afin de charger TinyLLaMA et de générer du texte en utilisant C++.

1. Pourquoi C++ et ggml ?

Dans la phase d’apprentissage de l’IA, Python, avec sa flexibilité et son écosystème riche, a un avantage écrasant. Cependant, dans les phases de déploiement ou d’« inférence (Inference) », C++ devient un choix puissant pour les raisons suivantes.

Réduction des surcoûts : Le Global Interpreter Lock (GIL) de Python et les surcoûts d’exécution peuvent être complètement éliminés.
Efficacité de la mémoire et allocation d’arène : L’allocation et la libération de la mémoire pouvant être contrôlées manuellement, les pics imprévisibles causés par le ramasse-miettes (garbage collection) sont évités.
Accès direct au matériel : Il est possible d’appeler directement des fonctions intrinsèques SIMD (Intrinsics) telles que AVX-512, AVX2 et ARM NEON, exploitant ainsi la puissance de calcul du processeur à son maximum.
Élimination des dépendances : ggml est une bibliothèque C/C++ sans aucune dépendance (Zero dependencies), et peut être facilement compilée même dans un environnement MSVC sous Windows tant qu’il y a un compilateur.

2. Vue d’ensemble de l’architecture

Le diagramme Mermaid ci-dessous montre le flux complet du pipeline d’inférence. Il s’agit d’une série de processus commençant par le texte d’entrée de l’utilisateur et se terminant par la génération du jeton suivant.

graph TD A["Texte d'entrée utilisateur"] --> B["Tokeniseur BPE"] B --> C["Tableau d'ID de jetons"] C --> D["Recherche de couche d'intégration"] D --> E["Blocs Transformer"] E --> F["RMSNorm"] F --> G["Couche LM Head"] G --> H["Tableau des logits"] H --> I["Module échantillonneur"] I --> J["ID du jeton suivant"] J --> K["Détokeniseur"] K --> L["Morceau de texte de sortie"] J -.-> |"Ajouter au contexte"| C

Puisqu’il s’agit d’un modèle autorégressif, le jeton produit est à nouveau ajouté au contexte et circule en tant qu’entrée pour la prédiction du jeton suivant (la partie en pointillé du diagramme).

3. Format de modèle et mappage en mémoire (mmap)

Le principal obstacle à la gestion des poids des grands réseaux de neurones est l’I/O disque et la consommation de mémoire. Dans l’implémentation C++ , cela est résolu par le mappage en mémoire (mmap).

3.1 Mécanisme du mappage en mémoire et implémentation sous Windows

L’utilisation de mmap permet de mapper le contenu d’un fichier directement dans l’espace mémoire virtuel du processus.

Zéro copie (Zero-copy) : Les données sont lues directement depuis le disque vers le cache de pages du noyau, évitant ainsi des copies supplémentaires vers l’espace utilisateur.
Chargement à la demande (Page Fault) : Au moment précis où le processeur accède à cette adresse mémoire, un défaut de page (page fault) se produit, et seul le morceau (chunk) requis (généralement 4 Ko) est chargé dans la mémoire physique.

Dans l’environnement Windows, au lieu du mmap de POSIX, on utilise les API Win32 CreateFileMapping et MapViewOfFile.

sequenceDiagram participant OS["Système d'exploitation Windows"] participant RAM["Mémoire physique"] participant App["Application C++"] App->>OS: "CreateFileMapping / MapViewOfFile" OS-->>App: "Pointeur d'adresse de mémoire virtuelle" App->>App: "Lire les données du tenseur au pointeur" OS->>RAM: "Défaut de page / Charger la page depuis le disque" RAM-->>App: "Données prêtes pour le calcul SIMD"

3.2 Structure binaire du format GGUF

Converti à partir de formats tels que .safetensors de Hugging Face, le GGUF (GPT-Generated Unified Format) est le format ultime pour l’inférence. Il possède la disposition binaire stricte suivante.

Octets magiques (Magic Bytes) : 0x46554747 (GGUF).
Version : Numéro de version du format.
Nombre de tenseurs et de métadonnées : Nombre de tenseurs et de paires clé-valeur de métadonnées.
Métadonnées (Paires Clé-Valeur) : Clés avec préfixe de longueur de chaîne, et valeurs typées.
Infos sur le tenseur : Nom de chaque tenseur, nombre de dimensions, type de données (FP16, Q4_K, etc.), et position de décalage (offset) dans le fichier.
Remplissage (Padding) : Remplissage inséré de sorte que les données du tenseur soient alignées sur une limite spécifique (généralement 32 octets ou 64 octets). Indispensable pour un accès rapide à la mémoire avec les instructions SIMD (en particulier AVX).
Données du tenseur : Tableau des données de poids réelles alignées.

4. Fondements mathématiques de TinyLLaMA et algorithmes C++

TinyLLaMA intègre plusieurs améliorations architecturales avancées pour l’efficacité. Nous expliquons ici les expressions mathématiques pour les implémenter correctement en C++.

4.1 RMSNorm (Root Mean Square Normalization)

Il omet le centrage de la moyenne du LayerNorm et n’effectue que la mise à l’échelle de la variance, ce qui réduit les coûts de calcul.

$$ \text{RMSNorm}(x) = \frac{x}{\sqrt{\frac{1}{d}\sum_{i=1}^{d} x_i^2 + \epsilon}} \odot \gamma $$

$d$ est le nombre de dimensions, $\gamma$ est le tenseur de mise à l’échelle appris. Lors de l’implémentation en C++, on optimise d’abord en calculant rapidement la somme des carrés du tableau avec _mm256_fmadd_ps d’AVX2, etc., et en la multipliant par la racine carrée inverse (par ex., avec l’instruction _mm256_rsqrt_ps).

4.2 RoPE (Rotary Position Embedding)

C’est une technique qui applique l’information de position du jeton sous forme de rotation (Rotate) dans l’espace tensoriel. Elle peut être considérée comme une rotation sur un plan complexe, appliquant la rotation suivante à la paire de dimensions adjacentes $(x_1, x_2)$ du vecteur $x$.

$$ \text{RoPE}(x, m) = \begin{pmatrix} x_{1} \cos(m\theta) - x_{2} \sin(m\theta) \\ x_{1} \sin(m\theta) + x_{2} \cos(m\theta) \end{pmatrix} $$

Ici, $m$ est l’index de position absolu du jeton, $\theta$ est la fréquence fondamentale précalculée. Dans ggml, elle s’exécute en parallèle simplement en ajoutant l’opérateur ggml_rope pendant la construction du graphe d’inférence.

4.3 Grouped-Query Attention (GQA)

Dans le Multi-Head Attention (MHA) standard, on a le même nombre de têtes (heads) pour Query, Key et Value. Cependant, TinyLLaMA utilise le Grouped-Query Attention (GQA) pour réduire drastiquement la bande passante mémoire et la consommation du cache KV.

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{Q K^T}{\sqrt{d_k}}\right) V $$

Dans le GQA, plusieurs têtes Query partagent une seule tête Key/Value. L’implémentation C++ nécessite une opération de diffusion (broadcast) du tenseur KV pour correspondre au nombre de Query avant d’exécuter la multiplication matricielle ggml_mul_mat.

4.4 Fonction d’activation SwiGLU

Dans la couche de réseau à propagation avant (Feed-Forward Network, FFN), SwiGLU est utilisé à la place de GELU.

$$ \text{SwiGLU}(x) = \text{Swish}(x W_{\text{gate}}) \otimes (x W_{\text{up}}) $$ $$ \text{Swish}(z) = z \cdot \sigma(z) = z \cdot \frac{1}{1 + e^{-z}} $$

Dans le graphe de calcul, ceci est exprimé en combinant les opérateurs ggml_silu et ggml_mul.

5. Construction du graphe de calcul avec ggml et gestion de la mémoire

ggml adopte une approche « Define-and-Run », construisant un graphe de calcul statique pour l’inférence et l’évaluant (evaluate) par la suite.

5.1 ggml_context et allocateur d’arène

Le point le plus unique de ggml est l’« allocation d’arène » qui n’effectue aucune allocation de mémoire dynamique (malloc ou new) à l’intérieur de la boucle d’inférence. Lors de l’initialisation, une énorme zone mémoire contiguë (arène) est allouée, et chaque fois que ggml_new_tensor etc. est appelé, le pointeur de cette zone est incrémenté. Une fois qu’une étape d’inférence est terminée, il suffit de réinitialiser le pointeur d’allocation à sa position initiale pour terminer instantanément l’allocation de mémoire pour l’étape d’inférence suivante.

5.2 Exemple concret de construction de graphe

À chaque étape d’inférence, le graphe de calcul suivant est assemblé en mémoire.

graph TD A["ID d'entrée des jetons"] --> B["Recherche d'intégration"] B --> C["ggml_rms_norm"] C --> D["Projections Q / K / V"] D --> E["ggml_rope Positionnel"] E --> F["Stockage du cache KV"] E --> G["Chargement du cache KV"] G --> H["Auto-Attention"] H --> I["Échelle & Softmax"] I --> J["Sortie de l'Attention"] J --> K["Projection de Sortie"] K --> L["Ajout Résiduel"]

6. Quantification (Quantization) et optimisation Windows / SIMD

Traiter TinyLLaMA (1.1B) en FP16 nécessite environ 2,2 Go de mémoire, mais cela peut être considérablement réduit à environ 600 Mo grâce à la quantification 4 bits (comme Q4_K).

6.1 Architecture de quantification par blocs

ggml ne quantifie pas l’intégralité du tenseur uniformément, mais le fait par unités de « blocs ». Dans le format Q4_0, 32 valeurs FP16 sont regroupées en un seul bloc.

Facteur d’échelle (Scale factor) : 1 valeur FP16 (2 octets)
Données quantifiées : 32 valeurs 4 bits (16 octets) Cela minimise l’impact des valeurs aberrantes locales.

6.2 Accélération du produit scalaire avec AVX2

Lors de la compilation pour les derniers processeurs x86 dans un environnement Windows, en utilisant des indicateurs de compilation (flags) tels que /arch:AVX2, le traitement SIMD est effectué via le flux suivant.

Chargement (Load) : Charge les données quantifiées 4 bits depuis la mémoire dans un registre AVX de 256 bits.
Expansion et déballage (Unpack) : Développe les valeurs 4 bits en Int8 ou Int16 avec un masque de bits et des opérations de décalage.
Déqualification (Dequantize) : Multiplie par le facteur d’échelle pour convertir en virgule flottante.
Opération FMA : Exécute en parallèle les opérations de multiplication-addition avec les valeurs d’activation en utilisant _mm256_fmadd_ps (Fused Multiply-Add).

7. Détails d’implémentation du cache KV

Dans la génération autorégressive, le « cache KV » est une fonctionnalité indispensable pour omettre le calcul des Key et Value des jetons passés.

Les points clés lors de l’implémentation en C++ sont les suivants.

Pré-allocation du tenseur : Initialiser un énorme tenseur pour le cache KV correspondant à la longueur de contexte maximale (ex. : 2048 jetons) (FP16 recommandé).
Copie avec décalage (Offset copy) : Lorsque le calcul pour la position du jeton $N$ est effectué, les vecteurs K et V obtenus à cette étape sont stockés à la $N$-ième ligne du tenseur de cache KV en utilisant ggml_cpy etc.
Création de la vue (view) lors de l’Attention : Lors du calcul de l’Attention, créer une « vue » pointant uniquement sur la partie des jetons de 0 à $N$, et la transmettre à la multiplication matricielle.

8. Tokeniseur BPE et décodage

Traite la chaîne d’entrée sous forme d’une séquence d’octets UTF-8 et la compare à un vocabulaire prédéfini. En C++, pour accélérer la recherche dans le vocabulaire, on implémente un algorithme utilisant un Trie (arbre de préfixes) ou une file de priorité.

À partir des logits sortis du LM Head, les probabilités sont mises à l’échelle en utilisant le paramètre de température (Temperature), les candidats sont réduits par des méthodes d’extraction Top-K ou Top-P (Nucleus Sampling), et le jeton suivant final est déterminé à l’aide de nombres aléatoires.

9. Lancement d’un projet C++ (Environnement Windows / PowerShell)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


cmake_minimum_required(VERSION 3.14)
project(TinyLLaMACpp)

set(CMAKE_CXX_STANDARD 17)

# Optimisation pour Windows (MSVC) et configuration du flag AVX2
if(MSVC)
 add_compile_options(/O2 /arch:AVX2 /fp:fast)
 add_link_options(/STACK:8388608)
else()
 add_compile_options(-O3 -march=native -ffast-math)
endif()

add_library(ggml OBJECT ggml/ggml.c ggml/ggml-alloc.c)
target_compile_definitions(ggml PRIVATE GGML_USE_AVX2 GGML_USE_F16C GGML_USE_FMA)

add_executable(main main.cpp)
target_link_libraries(main ggml)

Exemple de commande de build dans PowerShell :

1
2
3
4


mkdir build
cd build
cmake .. -G "Visual Studio 17 2022" -A x64
cmake --build . --config Release

10. Conclusion

Implémenter à partir de zéro un moteur d’inférence pour un petit modèle d’IA comme TinyLLaMA en utilisant C++ et ggml est une excellente occasion de révéler la boîte noire de l’apprentissage profond et d’apprendre la beauté du contrôle matériel de bas niveau. Tout en profitant pleinement de l’essence de la programmation système, telle que le chargement zéro copie à l’aide du mappage mémoire, l’optimisation SIMD et la construction du cache KV, ouvrons la voie à l’avenir de l’IA périphérique (Edge AI).

【Introduction à l'implémentation de RAG】 Comment faire lire vos propres documents à une 'IA locale'

Fri, 11 Sep 2026 13:00:00 +0900

Introduction

Ces dernières années, l’évolution des grands modèles de langage (LLM) a été remarquable, et de nombreuses IA telles que ChatGPT et Claude ont imprégné nos vies et nos entreprises. Cependant, les LLM généraux présentent une faiblesse évidente. Ils ne connaissent que les « informations publiques au moment de leur entraînement ». Naturellement, ils ne peuvent pas répondre aux questions concernant des « documents privés » tels que les règlements internes d’une entreprise, les notes personnelles ou les documents de projets non publiés. Si vous essayez de les forcer à répondre, le risque qu’ils génèrent des mensonges plausibles qui ne correspondent pas aux faits (hallucinations) augmente considérablement.

C’est pourquoi l’architecture technologique appelée RAG (Retrieval-Augmented Generation : Génération Augmentée par la Recherche) connaît actuellement une diffusion explosive dans le monde entier. L’utilisation du RAG permet de fournir dynamiquement des connaissances propres au LLM à partir d’une base de données externe, ce qui lui permet de générer des réponses précises et fondées.

De plus, lors du traitement d’informations confidentielles d’entreprise ou personnelles, l’envoi de données à des API basées sur le cloud telles qu’OpenAI est souvent inacceptable du point de vue de la politique de sécurité. C’est là qu’intervient la construction d’un « RAG local » combiné à une IA locale (un LLM qui fonctionne entièrement sur votre propre PC ou serveur sur site).

Dans cet article, nous expliquerons en détail la théorie de base du RAG, les méthodes concrètes d’implémentation d’un RAG local avec Python, le contexte mathématique (le fonctionnement de la recherche vectorielle) et les techniques avancées pour faire fonctionner le système en production.

1. Architecture globale du RAG

Le RAG n’est pas un modèle d’IA unique, mais une architecture système dans laquelle plusieurs composants collaborent. Il se compose principalement de deux phases : la « phase d’ingestion (importation des données) » et la « phase de recherche et de génération (Retrieval & Generation) ».

Le diagramme Mermaid ci-dessous montre la vue d’ensemble du système RAG.

graph TD subgraph "Phase d'ingestion (Préparation)" Doc["Documents propres (PDF, TXT, etc.)"] --> Loader["Chargeur de documents"] Loader --> Splitter["Division du texte (Chunking)"] Splitter --> EmbedModel1["Modèle de plongement (Embedding)"] EmbedModel1 --> VectorDB["Base de données vectorielle"] end subgraph "Phase d'inférence (Lors de la requête de l'utilisateur)" User["Question de l'utilisateur (Requête)"] --> EmbedModel2["Modèle de plongement (Embedding)"] EmbedModel2 --> QueryVector["Vecteur de requête"] QueryVector --> Search["Recherche de similarité (Recherche vectorielle)"] VectorDB --> Search Search --> Context["Extraction des morceaux pertinents (Contexte)"] User --> PromptBuilder["Construction du prompt"] Context --> PromptBuilder PromptBuilder --> LocalLLM["LLM local"] LocalLLM --> Answer["Génération de la réponse finale"] end

Phase d’ingestion (Préparation)

Chargement des documents : Chargez des données non structurées telles que des PDF, des documents Word, des fichiers texte, etc.
Chunking (Division du texte) : Divisez les textes longs en blocs significatifs (chunks) pour les adapter à la limite d’entrée (fenêtre de contexte) du LLM et pour améliorer la précision de la recherche.
Embedding (Vectorisation) : Entrez les chunks divisés dans un modèle de plongement (Embedding Model) et convertissez-les en un tableau de nombres (vecteur) de plusieurs centaines à plusieurs milliers de dimensions.
Enregistrement dans la base de données : Enregistrez les vecteurs convertis et les données textuelles d’origine associées dans une base de données vectorielle (Vector DB).

Phase d’inférence (Lors de l’exécution)

Vectorisation de la requête : Vectorisez la question de l’utilisateur en utilisant le même modèle de plongement que celui de la préparation.
Recherche de similarité : Calculez la similarité entre le vecteur de la requête et les vecteurs des documents dans la base de données, et récupérez les chunks de texte les plus proches sémantiquement (les plus pertinents).
Construction du prompt : Combinez les textes pertinents obtenus comme « contexte (connaissances de base) » avec la question de l’utilisateur pour créer le prompt d’entrée pour le LLM.
Génération de la réponse : Le LLM reçoit le prompt augmenté et génère une réponse basée sur les informations de contexte fournies.

2. Compréhension approfondie de la recherche vectorielle et des plongements (Embeddings)

Le cœur du RAG est la « recherche vectorielle (recherche sémantique) ». Alors que la recherche par mots-clés traditionnelle (comme BM25) est basée sur la correspondance exacte et la fréquence des mots, la recherche vectorielle est basée sur la « similarité de sens ». Par exemple, même des mots différents comme « chien » et « chiot », ou « PC » et « ordinateur » seront trouvés si leur sens est proche.

Qu’est-ce qu’un modèle de plongement (Embedding Model) ?

Un modèle de plongement est un réseau de neurones qui prend un texte en langage naturel en entrée et génère un vecteur dense de longueur fixe (Dense Vector). Les modèles courants (par exemple, text-embedding-3-small ou l’open source multilingual-e5-large) associent le texte à un vecteur de nombres réels de 384 ou 1024 dimensions.

Dans cet espace multidimensionnel (espace latent), l’apprentissage est fait de manière à ce que les textes ayant des significations similaires soient plus proches en termes de distance dans l’espace des coordonnées.

Contexte mathématique du calcul de similarité : Similarité cosinus

Lorsque la base de données vectorielle recherche des documents pertinents, la mesure de distance la plus couramment utilisée est la similarité cosinus (Cosine Similarity). Contrairement à la distance euclidienne (distance spatiale absolue), la similarité cosinus se concentre sur « l’angle entre deux vecteurs ». Étant donné qu’elle est peu affectée par la longueur du texte (la norme du vecteur), elle est très adaptée au calcul de similarité de textes.

Exprimée mathématiquement, la similarité cosinus des vecteurs $\mathbf{A}$ et $\mathbf{B}$ est la suivante :

$$ \text{Cosine Similarity}(\mathbf{A}, \mathbf{B}) = \cos(\theta) = \frac{\mathbf{A} \cdot \mathbf{B}}{\|\mathbf{A}\| \|\mathbf{B}\|} = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \sqrt{\sum_{i=1}^{n} B_i^2}} $$

$\mathbf{A} \cdot \mathbf{B}$ représente le produit scalaire (Dot Product).
$\|\mathbf{A}\|$ représente la norme L2 (longueur) du vecteur $\mathbf{A}$.
$n$ est le nombre de dimensions du vecteur.

La similarité cosinus prend une valeur comprise entre -1 et 1.

Proche de 1 : Les directions des deux vecteurs sont presque les mêmes (les sens sont très similaires)
Proche de 0 : Les deux vecteurs sont orthogonaux (aucun rapport)
Proche de -1 : Les directions des deux vecteurs sont opposées (les sens sont opposés)

Les bases de données vectorielles récentes (Chroma, FAISS, Qdrant, etc.) adoptent un algorithme de recherche des plus proches voisins approximatifs (ANN) appelé HNSW (Hierarchical Navigable Small World), optimisé pour rechercher des documents ayant une similarité cosinus élevée en millisecondes, même à partir de millions de données vectorielles.

3. Pile technologique pour construire un RAG local

Pour construire un RAG local complet qui ne dépend pas du cloud, nous tirerons parti de l’écosystème open source. Voici la pile technologique recommandée.

Modèle de langage (LLM)
- Outils : Ollama ou Llama.cpp
- Modèles : Des modèles ouverts légers et performants tels que Llama-3-8B-Instruct, Gemma-2-9B-It, Qwen2-7B-Instruct. Pour les tâches en japonais, des modèles ajustés pour le japonais comme Llama-3-ELYZA-JP-8B sont appropriés.
Modèle de plongement (Embedding)
- Modèles : intfloat/multilingual-e5-large ou BAAI/bge-m3. Lors de l’exécution locale, il est courant de les télécharger depuis Hugging Face et de les exécuter avec Sentence-Transformers.
Base de données vectorielle (Vector DB)
- ChromaDB : Basée sur Python, son installation est extrêmement simple. Idéale pour le développement local.
- FAISS : Une bibliothèque de recherche vectorielle rapide développée par Meta.
- Qdrant / Milvus : À plus grande échelle et destinées aux environnements de production.
Framework d’orchestration
- LangChain : Le standard de facto pour relier les composants (Chain).
- LlamaIndex : Un framework de connexion de données spécialement conçu pour le RAG.

Cette fois, nous l’implémenterons avec la combinaison la plus simple à introduire : LangChain + ChromaDB + Ollama + HuggingFaceEmbeddings.

4. Tutoriel d’implémentation : Construction complète d’un RAG local avec Python

À partir d’ici, nous allons construire un RAG local tout en écrivant du code Python. Au préalable, veuillez installer Ollama sur votre PC et le lancer en arrière-plan. De plus, téléchargez un modèle sur Ollama (exemple : ollama run llama3).

Étape 1 : Installation des bibliothèques nécessaires

1
2


pip install langchain langchain-community langchain-huggingface
pip install chromadb sentence-transformers pypdf

Étape 2 : Vue d’ensemble du code d’implémentation

Voici un script Python complet pour lire un fichier PDF, le vectoriser et permettre à un LLM local de répondre aux questions.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93


import os
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_community.llms import Ollama
from langchain_core.prompts import PromptTemplate
from langchain.chains import RetrievalQA

def main():
 # 1. Chargement des documents
 print("Chargement des documents...")
 # Spécifiez le chemin du PDF que vous souhaitez charger
 file_path = "sample_company_policy.pdf"
 loader = PyPDFLoader(file_path)
 documents = loader.load()

 # 2. Division en chunks (Text Splitting)
 # Diviser en tailles appropriées pour ne pas détruire le sens du texte
 text_splitter = RecursiveCharacterTextSplitter(
 chunk_size=500, # Nombre maximum de caractères par chunk
 chunk_overlap=50, # Nombre de caractères qui se chevauchent entre les chunks (empêche la rupture du contexte)
 separators=["\n\n", "\n", "。", "、", " ", ""]
 )
 chunks = text_splitter.split_documents(documents)
 print(f"Divisé en {len(chunks)} chunks.")

 # 3. Initialisation du modèle de plongement (Local HuggingFace Model)
 # Utilisation d'un modèle multilingue performant
 print("Chargement du modèle de plongement...")
 embeddings = HuggingFaceEmbeddings(
 model_name="intfloat/multilingual-e5-large",
 model_kwargs={'device': 'cpu'} # Si vous avez un GPU, 'cuda' ou 'mps'
 )

 # 4. Construction de la base de données vectorielle (Chroma)
 print("Construction de la base de données vectorielle...")
 persist_directory = "./chroma_db"
 vectorstore = Chroma.from_documents(
 documents=chunks,
 embedding=embeddings,
 persist_directory=persist_directory
 )
 # Création du système de recherche (Retriever). Configuration pour récupérer les 3 documents les plus pertinents
 retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

 # 5. Initialisation du LLM local (Ollama)
 print("Connexion au LLM local...")
 # Assurez-vous d'obtenir le modèle au préalable avec 'ollama pull llama3' par exemple
 llm = Ollama(model="llama3")

 # 6. Définition du modèle de prompt
 prompt_template = """Vous êtes un excellent assistant qui connaît bien les règlements de l'entreprise et les informations internes.
Veuillez répondre en détail à la question de l'utilisateur en français, en utilisant uniquement le contexte (informations de base) ci-dessous.
Si vous ne trouvez pas la réponse dans le contexte, ne devinez pas et répondez honnêtement « Je ne sais pas à partir des informations fournies ».

【Contexte】
{context}

【Question】
{question}

【Réponse】:
"""
 PROMPT = PromptTemplate(
 template=prompt_template,
 input_variables=["context", "question"]
 )

 # 7. Construction de la chaîne RAG
 qa_chain = RetrievalQA.from_chain_type(
 llm=llm,
 chain_type="stuff",
 retriever=retriever,
 return_source_documents=True, # Définir s'il faut renvoyer la source d'information
 chain_type_kwargs={"prompt": PROMPT}
 )

 # 8. Exécution de la question
 query = "Veuillez m'expliquer les conditions de remboursement des frais de transport pour le télétravail."
 print(f"\nQuestion : {query}\n")

 result = qa_chain.invoke({"query": query})

 print("【Réponse】")
 print(result['result'])
 print("\n---")
 print("【Sources consultées】")
 for doc in result['source_documents']:
 print(f"- Page {doc.metadata.get('page', 'inconnue')} : {doc.page_content[:50]}...")

if __name__ == "__main__":
 main()

Explication des points clés du code

RecursiveCharacterTextSplitter : C’est le diviseur le plus recommandé pour la division du langage naturel. Il tente de diviser dans l’ordre par paragraphe (\n\n), ligne (\n) et point (。), en gardant les blocs de sens autant que possible tout en respectant la taille spécifiée chunk_size. En définissant chunk_overlap, on évite de perdre des informations aux limites du contexte.
HuggingFaceEmbeddings : intfloat/multilingual-e5-large est un modèle de plongement open source très puissant qui prend en charge plusieurs langues. Sans utiliser d’API cloud (telles que text-embedding-ada-002 d’OpenAI), vous pouvez vectoriser le texte hors ligne en mémoire locale.
ChromaDB : Étant donné qu’il fonctionne en mémoire ou sur le stockage local (basé sur SQLite), il n’est pas nécessaire de mettre en place un serveur de base de données complexe. En spécifiant persist_directory, vous pouvez ignorer le processus de vectorisation lors de la réexécution et charger la base de données à partir du disque.

5. Techniques avancées de RAG (Advanced RAG Techniques)

Bien que le système RAG de base (Naive RAG) construit dans le tutoriel ci-dessus fonctionne, si une précision de réponse élevée est requise en production, l’introduction de techniques avancées telles que les suivantes sera nécessaire.

5.1 Recherche hybride (Hybrid Search)

Bien que la recherche vectorielle excelle à saisir le « sens », elle peut avoir des difficultés avec les recherches de mots-clés exacts tels que des « noms propres spécifiques », des « numéros de modèles de produits » ou des « identifiants d’employés ». Par conséquent, en effectuant parallèlement une recherche sémantique basée sur la recherche vectorielle et une recherche par mot-clé utilisant un algorithme tel que BM25, puis en évaluant et en fusionnant les deux résultats (en utilisant des méthodes telles que Reciprocal Rank Fusion ; RRF), il est possible de réduire considérablement les omissions de recherche.

5.2 Re-classement (Re-ranking)

La recherche vectorielle est rapide, mais elle n’évalue pas nécessairement la pertinence contextuelle exacte du contexte. Un pipeline courant pour améliorer la précision de la recherche est le suivant :

Recherche initiale (First-stage Retrieval) : Récupérez largement et superficiellement environ 20 à 30 chunks pertinents à partir de la base de données vectorielle.
Réévaluation (Re-ranking) : Utilisez un autre modèle d’apprentissage automatique plus lourd appelé Cross-Encoder (par exemple : bge-reranker, etc.) pour entrer la paire de la requête de l’utilisateur et du chunk récupéré, et recalculez le score de pertinence sémantique.
Sélection : Seuls les 3 à 5 premiers résultats ayant les scores les plus élevés sont passés au prompt du LLM en tant que contexte final.

Cette méthode empêche les informations bruyantes non pertinentes d’être transmises au LLM et peut considérablement augmenter la précision (Precision) des réponses.

graph LR Query["Requête"] --> VSearch["Recherche vectorielle (Top 20)"] VSearch --> Reranker["Modèle de re-classement (Cross-Encoder)"] Query --> Reranker Reranker --> TopK["Top 3 de haute précision"] TopK --> LLM["Génération par le LLM"]

5.3 Chunking sémantique et recherche de document parent

Plutôt que de diviser mécaniquement le texte par un nombre fixe de caractères, il existe une technique appelée « Semantic Chunking » qui utilise l’IA pour détecter les changements de sens dans les phrases et les diviser. De plus, dans une technique appelée « Parent Document Retriever (Recherche de document parent) », la vectorisation est effectuée en très petites unités (comme des phrases) pour la recherche afin d’obtenir une recherche très précise. Mais lorsqu’elle est transmise au LLM, c’est le « grand paragraphe d’origine (document parent) » contenant cette phrase qui est fourni, offrant ainsi un contexte suffisant au LLM.

6. Défis et solutions lors de l’exploitation d’un RAG local

Lors de la construction et de l’exploitation d’un RAG dans un environnement local, des obstacles spécifiques existent.

Épuisement de la VRAM (Mémoire vidéo) : Pour faire fonctionner un LLM local à une vitesse pratique (des dizaines de tokens par seconde), le modèle doit être chargé dans la VRAM du GPU. Pour exécuter un modèle de classe 8B en fp16 (virgule flottante 16 bits), environ 16 Go de VRAM sont nécessaires. Cependant, en utilisant des technologies de quantification (Quantization) (techniques de compression en 4 bits ou 8 bits telles que les formats GGUF ou AWQ), il est possible de le faire fonctionner suffisamment vite même avec 8 Go de VRAM (PC de jeu standard, etc.). Llama.cpp et Ollama prennent en charge ces formats quantifiés de manière native.
Limite de la fenêtre de contexte : Si la quantité de contexte récupérée par la recherche est trop importante, elle peut dépasser la limite d’entrée du LLM (limite de tokens), ou le modèle peut oublier les parties intermédiaires de l’information (phénomène de Lost in the middle). L’ajustement du nombre de chunks extraits et la sélection stricte à l’aide de la technologie de re-classement mentionnée ci-dessus sont essentiels.
Gestion de la fraîcheur des données : Lorsque le document source est mis à jour, les vecteurs du document correspondant dans la base de données vectorielle doivent également être mis à jour/supprimés (opérations CRUD). Étant donné que ChromaDB prend en charge les mises à jour basées sur les identifiants de documents, il est pratique de mettre en place un traitement par lots qui gère les valeurs de hachage des fichiers et ne synchronise que les différences.

Conclusion

Le RAG (Génération Augmentée par la Recherche) est un paradigme puissant qui fait évoluer l’IA d’un assistant généraliste typique vers « votre expert exclusif » ou un « expert spécialisé dans les opérations internes ».

Nous avons vu que même pour des exigences hautement confidentielles où les services cloud ne peuvent pas être utilisés, un environnement « RAG local » complet peut être construit relativement facilement en combinant l’écosystème open source comme Ollama, LangChain et ChromaDB.

En vous basant sur la compréhension mathématique de l’espace vectoriel, la division de texte et les approches avancées telles que le re-classement expliquées dans cet article, n’hésitez pas à développer votre propre système d’IA original en utilisant vos propres données. La vitesse d’évolution de l’IA locale est stupéfiante, et le système que vous construisez aujourd’hui peut voir ses performances mises à jour instantanément, simplement en le remplaçant par un modèle léger encore plus intelligent qui sortira demain.

Dans ce blog, nous continuerons à publier des articles approfondis sur la technologie de l’IA et le RAG. Si vous avez des questions ou des commentaires, n’hésitez pas à nous en faire part dans la section des commentaires.