Technical Context
I love cases like this: you start with chaos in PDFs and scans, and yet, you can still build a working AI integration. The question was simple: how do you interpret electrical drawings from the construction industry when everyone uses their own notation, but the goal is specifically element detection?
I wouldn't start with magic here. I'd start with a reference dictionary of symbols, and IEC 60617 works very well in this role. It's an international database of graphical symbols for electrical diagrams—essentially, a reliable visual anchor for the model.
This is where it gets interesting. If you have Claude Sonnet or another powerful multimodal model, you can feed it not only the drawing itself but also symbol examples, naming rules, and similar variants from the QElectroTech library. And this is where zero-shot or few-shot performance becomes noticeably better than a bare prompt without context.
I like QElectroTech for a practical reason: it's not an abstract standard on paper but a living library of elements compatible with the IEC approach. It's convenient for gathering references, generating synthetic data for training, and even for simple validation when I'm checking that the model isn't confusing a switch with a circuit breaker just because of the drawing style.
If you specifically need bbox detection, I wouldn't romanticize LLMs. Sonnet is great as a layer for understanding, classification, and normalizing names, but for high-volume, automated annotation, I'd keep YOLO or another detector handy. The combination is sensible: a vision model finds the objects, and Sonnet aligns them with IEC logic and extracts the meaning from the diagram.
What This Changes for Business and Automation
First, in the energy and construction sectors, you can stop waiting for a perfect standard from contractors. By building a pipeline around IEC 60617 and QElectroTech, you can achieve real AI automation for parsing diagram archives, auditing documentation, and preparing data for CAD/BIM processes.
Second, it lowers the entry cost. You don't need to annotate a giant dataset from scratch because the standard and the symbol library already provide a solid foundation. The only teams that lose out here are those trying to solve everything with a single OCR tool and then wondering why the diagram turns into garbage.
Third, the architecture becomes more mature. I would separate OCR, detection, symbol classification, and post-processing based on network rules, rather than cramming everything into a single prompt. At Nahornyi AI Lab, this is exactly the kind of AI solutions for business we build: when you need a working system for a real document flow, not just a demo for a single PDF. If your drawings are slowing down your project, we can calmly assess the process and build AI automation without the hype around "magical AI."