Engineer builds a local RAG service for CAD API documentation, details it on Habr

An engineer has published a breakdown on Habr of how he built a local RAG service for working with API documentation for computer-aided design (CAD) systems. He attributes the project to pressure on engineering firms from clients who keep cutting project budgets and timelines.

Why CAD documentation became a candidate for automation

According to the author, engineering has spent recent years living under the motto "the same thing, but cheaper and faster": clients cut budgets and deadlines, and contractors look for processes they can optimize. Design automation is one of the first candidates, because design work involves a lot of routine operations, and a significant share of them can be handed off to scripts and small software utilities instead of being done manually by an engineer.

• The author is an engineer who built a local RAG service for CAD API on his own
• The reason for the project: routine design operations that can be delegated to scripts
• The broader context: clients of engineering services cutting budgets and timelines

The focus here is specifically the API of CAD systems, not the drawings themselves. Scripts and utilities are most often written for repetitive actions such as bulk report generation, checking parameters against internal standards, or batch file processing. These are tasks an engineer performs manually dozens of times per project, but they pay poorly compared with creative work.

What local RAG brings to this scenario

RAG (retrieval-augmented generation) is an approach in which a model searches its own document base for relevant passages before answering, rather than relying only on what it memorized during training. That makes it a particularly good fit for CAD API documentation: these APIs are often described in large, scattered, and regularly updated manuals. Local deployment lets a company keep sensitive engineering data and proprietary documentation inside its own perimeter instead of sending it to external cloud services.

That is why the author chose a local solution over an off-the-shelf cloud AI assistant. With engineering data, confidentiality often matters more than ease of setup, and access to the current version of the API documentation is critical, since CAD systems regularly change their interfaces and methods. Running everything in-house, without sending queries to an external service, also removes the question of where the wording of internal technical specifications and fragments of a vendor's closed documentation might leak.

The usual challenges in projects like this

Technical API documentation is awkward material for a classic RAG pipeline. It is full of parameter tables, cross-references to other sections, version notes, and terminology specific to a given CAD platform, all of which chunk poorly with standard methods. Developers of such services typically have to work out separately how to split documents into meaningful pieces, how to update the index when a new API version ships, and how to verify that the model doesn't confuse methods with similar names but different behavior. This is manual, painstaking work that usually doesn't show in the final result, yet it takes up a significant share of the project's time.

What it means

The story reflects a broader trend: while major vendors ship general-purpose AI assistants, individual engineers and small teams increasingly build narrowly specialized local RAG tools for specific routine work — documentation, template-based operations, and internal standards. For engineering and design organizations, where drawing confidentiality and exact API version matching matter, a homegrown local tool like this often turns out to be more practical than connecting an external cloud AI service to the company's entire documentation base.