Engineer built a local RAG service for CAD API documentation on Habr

An engineer published on Habr a breakdown of how they assembled a local RAG service for working with API documentation for computer-aided design (CAD) systems, explaining this by the pressure on engineering companies from clients who are cutting budgets and project timelines.

Why CAD documentation became a candidate for automation

According to the author, in recent years engineering has lived under the motto "the same thing, but cheaper and faster": clients cut budgets and timelines, and contractors look for which processes can be optimized. Automation of design is one of the first candidates for such optimization, since there are many routine operations in design, and a significant portion of them can be delegated to scripts and small software utilities rather than performed manually by an engineer.

• The author is an engineer who independently built a local RAG service for CAD API
• The reason for the project is routine design operations that can be delegated to scripts
• The general context is budget and timeline reduction from engineering services clients

We are talking specifically about APIs of computer-aided design systems, not the drawings themselves: scripts and utilities are most often written for repetitive actions like batch report generation, checking parameters for compliance with internal standards, or batch processing of files — tasks that an engineer performs manually dozens of times per project, but which are poorly paid as creative work.

What local RAG provides in this scenario

RAG (retrieval-augmented generation) is an approach where the model, before answering, searches for relevant fragments in its own document base rather than relying only on what it learned during training. For CAD API documentation, this is especially appropriate: such APIs are often described in voluminous, fragmented, and regularly updated manuals, and local deployment makes it possible to keep sensitive engineering data and proprietary documentation within the company's perimeter, without sending it to external cloud services.

This is precisely why the author went with a local solution rather than a ready-made cloud AI assistant: for engineering data, the confidentiality issue is often more important than setup convenience, and access to the current version of API documentation is critical, since CAD systems regularly change their interfaces and methods. Deployment "in-house," without sending requests to an external service, also removes the question of where formulations of internal technical specifications and fragments of closed vendor documentation leak to.

What difficulties usually arise in such projects

Technical API documentation is inconvenient material for a classic RAG pipeline: it contains many tables with parameters, links to other sections, version notes, and terminology specific to a particular CAD platform, which does not break down into chunks well by standard methods. Developers of such services typically have to separately think through splitting documents into semantic chunks, updating the index when a new API version is released, and checking that the model doesn't confuse similar-named but behaviorally different methods. This is manual, painstaking work that is usually invisible in the final result, but takes up a significant portion of the time for such a project.

What this means

The story reflects a broader trend: while large vendors release universal AI assistants, individual engineers and small teams increasingly assemble narrowly specialized local RAG tools for specific routines — working with documentation, template operations, and internal standards. For engineering and project organizations where drawing confidentiality and precise API version compliance matter, such homemade local tools often prove more practical than connecting an external cloud AI service to the entire company's documentation base.