Étude de cas
One Piece LLM
Chatbot RAG spécialisé sur l'univers One Piece, indexé sur le corpus complet des tomes 1 à 102.
Répondre à des questions précises sur 102 tomes de manga demande d'abord d'en extraire le texte — puis de retrouver le bon passage. Le projet traite la chaîne entière, du scan brut à la réponse servie en production, et a servi de terrain d'essai pour une question qui revient souvent : à connaissance égale, vaut-il mieux fine-tuner un modèle ou lui donner les bons documents ?
Architecture
Le pipeline part des scans .cbz, en extrait le texte par OCR avec détection des bulles (Tesseract), découpe en chunks par page et par chapitre, puis indexe le tout dans un index hybride : BM25 pour le lexical, embeddings Chroma pour le sémantique, les deux fusionnés par Reciprocal Rank Fusion. La génération tourne sur Ollama en local (llama3.2:3b) derrière une interface Flask.
Le tout est déployé sur un VPS Hetzner sans GPU — CPU seul en production — avec nginx, HTTPS et rate-limiting.
Corpus
102 tomes de l'édition VIZ, en anglais, soit environ 20 500 chunks conservés après filtrage qualité. Le modèle d'embedding est multilingue, ce qui permet de poser les questions en français sur un corpus anglais.
RAG contre fine-tuning
Trois approches comparées sur un même banc de 22 questions, dont 5 pièges destinés à détecter les hallucinations. Modèle de base : Qwen2.5-3B-Instruct, fine-tuné en LoRA/QLoRA sur 220 exemples synthétiques.
| Approche | Réponses correctes | Hallucinations |
|---|---|---|
| RAG seul | 9 % | 18 % |
| Fine-tuning seul | 5 % | 64 % |
| RAG + fine-tuning | 18 % | 32 % |
Sur de la connaissance factuelle dense et avec un petit budget de données, le fine-tuning seul est nettement en dessous du RAG.
Combiné au RAG, le fine-tuning fait bien monter le taux de bonnes réponses — mais les hallucinations montent avec : le modèle devient plus assuré, et moins prudent. Un gain qui se paie.
Limites connues
- Du bruit OCR subsiste malgré le filtrage qualité.
- L'ordre de lecture des bulles reste approximatif sur les mises en page complexes.
- Un seul worker en production : les requêtes sont traitées séquentiellement, en 20 à 50 secondes chacune.