Локальный RAG на FastAPI и Ollama: от простого вызова LLM к production backend

Un développeur sur Habr analyse un moment spécifique : quand 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 n'est pas suffisant

La première version semble évidente : le frontend envoie une question, FastAPI reçoit `POST /ask`, le backend appelle Ollama et retourne une chaîne avec la réponse. Pour une démo, c'est suffisant. Pour un assistant de documentation — non. Les questions surgissent immédiatement : sur quels documents la réponse s'appuie-t-elle ? Quels fragments sont entrés dans le prompt ? Pourquoi une demande prend-elle deux secondes à traiter, tandis qu'une autre en prend quinze ? Que se passe-t-il si l'index n'a pas été mis à jour depuis trois semaines ? Il est impossible de répondre à ces questions avec un simple appel à un LLM.

Ce que la couche backend ajoute L'auteur introduit les composants un

par un, expliquant le problème spécifique que chacun résout : request_id — un identifiant unique de requête pour corréler les logs et déboguer les défaillances spécifiques sources — une liste des fragments de documents qui ont accédé au contexte du modèle, avec indication de la source timings — ventilation du temps par étapes : recherche dans l'index, formation du prompt, génération de la réponse rebuild index — un endpoint séparé pour reconstruire l'index sans redémarrer le service * negative tests — vérification du comportement avec un corpus de documents 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, embeddings personnalisés. Aucune clé d'API externe.

Contrat d'API comme limite du système L'un des points clés de

l'article — l'importance d'un contrat explicite au niveau de la réponse. Quand `/ask` retourne juste une chaîne, le service reste une boîte noire. Dès que la réponse inclut `request_id`, `sources`, `timings` et le statut de l'index — il devient possible de surveiller, déboguer et améliorer.

"Je ne montre pas comment RAG fonctionne en général, mais le chemin

d'un simple appel à un LLM local à un petit projet backend avec un contrat d'API, du logging, des sources, des timings et des limitations honnêtes". Cette approche change la façon dont vous voyez le service : au lieu de "le modèle répond d'une manière ou d'une autre", vous obtenez "le système se comporte de manière prévisible."

Honnêteté sur les limitations L'auteur énumère explicitement ce qui

manque au projet : autorisation, mise en cache, support des charges multi-utilisateurs, CI/CD. Cela rend l'article plus utile que la plupart des tutoriels, où la section des limitations n'existe pas ou se réduit à une phrase standard. Les negative tests sont un sujet séparé. Le comportement est vérifié avec un corpus de documents vide, avec des questions sans contenu pertinent dans l'index, et lors de l'accès à l'index après ajout de nouveaux fichiers sans reconstruire. Un ensemble minimal, mais suffisant pour comprendre exactement où le système échoue.

Ce que cela signifie L'article comble une lacune spécifique : la

plupart des matériaux sur RAG expliquent soit la théorie, soit montrent "hello world" avec LangChain. Ici — un service local fonctionnel avec des outils d'observabilité qui peut servir de base à un vrai projet.