RAG local avec FastAPI et Ollama : de l'appel LLM basique à un backend de production

Un développeur de Habr s'intéresse à un moment précis : celui où un simple appel à un modèle local ne suffit plus, et ce qu'il faut ajouter pour obtenir un véritable système backend.

Quand un simple appel ne suffit plus

La première version paraît évidente : le frontend envoie une question, FastAPI reçoit `POST /ask`, le backend interroge Ollama et renvoie une chaîne contenant la réponse. Pour une démo, cela suffit. Pour un assistant de documentation, non.

Les questions surgissent aussitôt : sur quels documents la réponse s'appuie-t-elle ? Quels fragments se sont retrouvés dans le prompt ? Pourquoi une requête est-elle traitée en deux secondes et une autre en quinze ? Que se passe-t-il si l'index n'a pas été mis à jour depuis trois semaines ? Un simple appel à un LLM ne permet pas de répondre à ces questions.

Ce qu'apporte la couche backend

L'auteur introduit les composants un par un, en expliquant à chaque fois le problème précis qu'il résout :

• request_id — identifiant unique de la requête, pour corréler les logs et déboguer une défaillance donnée
• sources — liste des fragments de documents injectés dans le contexte du modèle, avec indication de leur origine
• timings — ventilation du temps par étape : recherche dans l'index, construction du prompt, génération de la réponse
• rebuild index — endpoint dédié à la reconstruction de l'index sans redémarrer le service
• negative tests — vérification du comportement face à un corpus vide, à des questions hors sujet et à un index obsolète

La pile est entièrement locale : FastAPI pour la couche HTTP, Ollama pour la génération, des embeddings maison. Aucune clé d'API externe.

Le contrat d'API comme frontière du système

L'une des thèses centrales de l'article porte sur l'importance d'un contrat explicite au niveau de la réponse. Tant que `/ask` ne renvoie qu'une chaîne, le service reste une boîte noire. Dès que la réponse inclut `request_id`, `sources`, `timings` et l'état de l'index, il devient possible de la superviser, de la déboguer et de l'améliorer.

«

Je ne montre pas comment fonctionne le RAG en général, mais le chemin qui mène d'un simple appel à un LLM local à un petit projet backend doté d'un contrat d'API, de journalisation, de sources, de timings et de limites assumées. »

Cette approche change le rapport au service : au lieu de « le modèle répond tant bien que mal », on obtient « le système se comporte de façon prévisible ».

Des limites assumées

L'auteur énumère explicitement ce que le projet ne comporte pas : authentification, cache, prise en charge d'une charge multi-utilisateurs, CI/CD. Cela rend l'article plus utile que la plupart des tutoriels, où la section sur les limites est soit absente, soit réduite à une formule de circonstance.

Les negative tests méritent un traitement à part. L'auteur vérifie le comportement face à un corpus de documents vide, face à des questions sans contenu pertinent dans l'index, et lors d'un accès à l'index après l'ajout de nouveaux fichiers sans reconstruction. C'est un ensemble minimal, mais il permet déjà de repérer où le système cède.

Ce que cela signifie

L'article comble un vide précis : la plupart des contenus sur le RAG se contentent d'expliquer la théorie ou de présenter un « hello world » avec LangChain. Ici, on a un service local fonctionnel, doté d'outils d'observabilité, qui peut servir de base à un projet réel.