Un modèle de langage ne connaît pas vos documents. Il connaît ce qu'il a vu à l'entraînement, ce qui exclut votre catalogue, vos contrats et vos comptes rendus de réunion. Le RAG — retrieval-augmented generation — est la technique qui comble cet écart : on retrouve les passages pertinents dans vos documents, on les met dans le contexte du modèle, et on lui demande de répondre à partir de là.

Le principe tient en trois lignes. Ce qui distingue une implémentation utilisable d'une démo, ce sont trois détails que les tutoriels passent sous silence.

Le mécanisme, en quatre étapes

1. Découpage. Un document de quarante pages ne rentre pas dans le contexte, et n'aurait pas d'intérêt à y rentrer en entier. On le coupe en morceaux — des chunks — de quelques centaines de mots, avec un recouvrement entre morceaux voisins pour ne pas trancher une idée en deux.

2. Embeddings. Chaque morceau est transformé en vecteur : une liste de nombres qui encode son sens. Deux textes qui parlent de la même chose ont des vecteurs proches, même sans partager un seul mot. C'est ce qui permet de retrouver un passage sur « les délais de paiement » à partir d'une question sur « quand est-ce que je serai payé ».

3. Récupération. À la question posée, on applique le même traitement, et on cherche les morceaux dont le vecteur est le plus proche. On en garde une poignée.

4. Génération. Ces morceaux sont fournis au modèle avec la question et une consigne du type « réponds à partir de ces extraits ». Le modèle rédige.

Les trois détails qui décident de la qualité

Le découpage est un choix éditorial, pas technique

Un chunk trop petit perd son contexte : « le délai est de trente jours » ne sert à rien si on ne sait plus de quel délai il s'agit. Un chunk trop gros noie l'information pertinente dans du bruit, et le vecteur qui le représente devient une moyenne floue qui ne ressemble à aucune question précise.

Il n'existe pas de taille universelle. Un contrat se découpe par article, un manuel par section, un fil de discussion par échange. Un découpage qui ignore la structure du document dégrade la récupération quelle que soit la qualité du modèle derrière.

Changer de modèle d'embedding invalide tout l'index

C'est le piège le plus coûteux, parce qu'il est silencieux.

Les vecteurs produits par deux modèles d'embedding différents ne sont pas comparables. Ils n'ont pas la même dimension, et même à dimension égale, ils n'organisent pas l'espace de la même façon. Si vous indexez la moitié de vos documents avec un modèle et l'autre moitié avec son successeur, les distances calculées entre les deux moitiés n'ont aucun sens — et rien ne plante. La recherche continue de retourner des résultats. Ils sont simplement faux.

C'est pour ça que, chez Tukai, la clé de déduplication d'un document indexé inclut le modèle d'embedding et sa dimension, en plus du contenu. Réimporter le même fichier sous un autre modèle produit une nouvelle indexation plutôt que de réutiliser l'ancienne. C'est plus cher en apparence ; c'est la seule façon d'éviter une dégradation qu'on ne verrait pas.

La même logique vaut pour les règles de normalisation et de découpage : si la façon de nettoyer ou de couper le texte change, les empreintes calculées avant ce changement décrivent un texte qui n'existe plus. Elles doivent être invalidées explicitement.

La déduplication doit être par utilisateur

Réimporter un document identique ne devrait rien coûter : on a déjà les vecteurs. Il est tentant de pousser la logique plus loin et de partager cette réutilisation entre tous les utilisateurs — si deux personnes importent le même PDF, pourquoi payer deux fois ?

Parce que la réponse à cette question fuite une information. Une réutilisation instantanée et gratuite indique à l'utilisateur B que quelqu'un d'autre détient exactement ce fichier. Sur un document public, c'est anodin. Sur un contrat, une grille tarifaire ou un dossier médical, c'est une divulgation.

Chez Tukai la déduplication est donc cloisonnée par compte. Elle coûte du calcul redondant, et c'est un prix assumé : la confidentialité n'est pas une option de configuration.

Ce que le RAG ne règle pas

Il faut être clair sur les limites, parce qu'elles sont régulièrement vendues comme résolues.

Le RAG ne supprime pas les hallucinations, il en réduit l'occasion. Si aucun extrait pertinent n'est retrouvé, un modèle peut toujours répondre à côté avec assurance. Une bonne implémentation le fait dire — « je ne trouve pas cette information dans vos documents » — et c'est une consigne à donner explicitement.

Le RAG répond mal aux questions globales. « Combien de contrats mentionnent une clause de non-concurrence ? » suppose de parcourir l'ensemble du corpus, pas d'en retrouver cinq morceaux. Ce n'est pas le bon outil pour ça.

La qualité du corpus plafonne tout le reste. Un document scanné sans OCR correct, un tableau aplati en texte, une version obsolète non retirée : aucune sophistication du côté récupération ne rattrape ça.

Dans Tukai

Le RAG est intégré au workspace : vous importez vos documents, ils sont normalisés, découpés et indexés, et les conversations peuvent s'y appuyer. Les appels d'indexation sont comptabilisés comme tout le reste, en EDNT — le détail du modèle de facturation est dans l'article sur le paiement en dinars, et les offres sur la page tarifs.

Un système RAG se juge sur ce qu'il répond quand la réponse n'est pas dans les documents. S'il invente plutôt que de le dire, le reste n'a pas d'importance.