Un ingénieur a construit un service RAG local pour la documentation de l'API CAD sur Habr

Un ingénieur a publié sur Habr un détail de la façon dont il a assemblé un service RAG local pour travailler avec la documentation API des systèmes de conception assistée par ordinateur (CAD), l'expliquant par la pression des clients sur les entreprises d'ingénierie qui réduisent les budgets et les délais des projets.

Pourquoi la documentation CAD est devenue candidate à l'automatisation

Selon l'auteur, ces dernières années, l'ingénierie a vécu sous la devise « la même chose, mais moins cher et plus rapide » : les clients réduisent les budgets et les délais, et les entrepreneurs cherchent quels processus peuvent être optimisés. L'automatisation de la conception est l'un des premiers candidats à une telle optimisation, car il y a de nombreuses opérations routinières en conception, et une portion importante d'entre elles peuvent être déléguées à des scripts et de petits utilitaires logiciels plutôt que d'être exécutées manuellement par un ingénieur.

• L'auteur est un ingénieur qui a construit de manière indépendante un service RAG local pour CAD API
• La raison du projet sont les opérations de conception routinière qui peuvent être déléguées à des scripts
• Le contexte général est la réduction du budget et du délai des clients des services d'ingénierie

Nous parlons spécifiquement des API des systèmes de conception assistée par ordinateur, pas des dessins eux-mêmes : les scripts et les utilitaires sont le plus souvent écrits pour des actions répétitives comme la génération en masse de rapports, la vérification des paramètres pour conformité avec les normes internes, ou le traitement par lots de fichiers — des tâches qu'un ingénieur effectue manuellement des dizaines de fois par projet, mais qui sont mal payées comme travail créatif.

Ce que RAG local fournit dans ce scénario

RAG (génération augmentée par récupération) est une approche où le modèle, avant de répondre, recherche des fragments pertinents dans sa propre base de documents plutôt que de compter uniquement sur ce qu'il a appris lors de l'entraînement. Pour la documentation CAD API, cela est particulièrement approprié : ces APIs sont souvent décrites dans des manuels volumineux, fragmentés et régulièrement mis à jour, et le déploiement local permet de garder les données d'ingénierie sensibles et la documentation propriétaire dans le périmètre de l'entreprise, sans les envoyer à des services en nuage externes.

C'est précisément pourquoi l'auteur a opté pour une solution locale plutôt qu'un assistant IA en nuage prêt à l'emploi : pour les données d'ingénierie, la question de la confidentialité est souvent plus importante que la commodité d'installation, et l'accès à la version actuelle de la documentation API est critique, car les systèmes CAD changent régulièrement leurs interfaces et méthodes. Le déploiement « interne », sans envoyer de demandes à un service externe, supprime également la question de savoir où les formulations des spécifications techniques internes et les fragments de la documentation du fournisseur fermée fuient.

Quelles difficultés surviennent généralement dans de tels projets

La documentation technique des API est un matériau gênant pour un pipeline RAG classique : elle contient de nombreux tableaux avec des paramètres, des liens vers d'autres sections, des notes de version, et une terminologie spécifique à une plateforme CAD particulière, qui ne se divise pas bien en chunks par les méthodes standard. Les développeurs de tels services doivent généralement réfléchir séparément à la division des documents en morceaux sémantiques, à la mise à jour de l'index lorsqu'une nouvelle version API est publiée, et vérifier que le modèle ne confond pas les méthodes aux noms similaires mais aux comportements différents. C'est un travail manuel et minutieux qui est généralement invisible dans le résultat final, mais prend une portion importante du temps pour tel projet.

Ce que cela signifie

L'histoire reflète une tendance plus large : alors que les grands fournisseurs publient des assistants IA universels, des ingénieurs individuels et de petites équipes assemblent de plus en plus des outils RAG locaux étroitement spécialisés pour des routines spécifiques — travailler avec la documentation, des opérations de template et des normes internes. Pour les organisations d'ingénierie et de projet où la confidentialité des dessins et la conformité précise à la version API comptent, de tels outils locaux faits maison s'avèrent souvent plus pratiques que de connecter un service IA en nuage externe à toute la base de documentation de l'entreprise.