ИИ для проверки рабочей документации

Куда уходит ваш файл

Это главное, и об этом обычно не пишут. Проверка языковой моделью почти всегда устроена одинаково: файл отправляют в чужое API — ChatGPT, Claude или другое, — и дальше он живёт по чужим правилам. У вас на руках рабочая документация: шифр комплекта, наименование объекта, фамилии в основной надписи, иногда объект повышенной опасности. Отдавать её за пределы своего контура — отдельное решение, и принимать его должен тот, кто за документ отвечает, а не сервис проверки за него.

Здесь наружу не уходит ничего. За всю свою работу сервис делает ровно два исходящих вызова: в банк, когда оплачивают тариф, и на наш собственный ящик, когда кто-то присылает сообщение об ошибке. Разбирая альбом, сервис не обращается никуда. Ни одного вызова, ни к какой модели, ни на какой сторонний адрес.

Это верно и для страниц, у которых нет текстового слоя: распознаватель работает здесь же, а его модель лежит внутри образа и попадает туда при сборке — во время проверки она ничего не скачивает. Сверка написаний тоже местная: ей уходит список различных слов, а не текст альбома, и уходит в программу на этой же машине.

На самих страницах сервиса нет ни одного счётчика и ни одного внешнего скрипта: Метрику мы сняли, шрифты и стили лежат у нас. Браузер, открывший эту страницу, не обращается ни к кому, кроме нас.

Что делает с чертежом языковая модель

Она отвечает связно — и это главная сложность. На альбом, где всё сошлось, она напишет замечание, которого нет; на альбоме с настоящим расхождением промолчит и похвалит оформление. Отличить одно от другого по тексту ответа нельзя: уверенность в нём одинаковая.

И проверить её нельзя. Тот же файл в другой раз даёт другой ответ: иначе расставленные акценты, другое число пунктов, иногда другой вывод. Приложить такой ответ к альбому и сказать проектировщику «вот замечания» — значит предъявить мнение, которое не воспроизводится. Нормоконтроль так не работает, и экспертиза такого не примет.

Как устроено здесь

73 правила, написанные руками. Каждое выросло из разбора настоящего альбома и отвечает на один проверяемый вопрос: эта позиция со схемы заказана в спецификации? у этого прибора есть схема подключения? число клемм сходится с числом подключений? Геометрия и текст читаются с самого файла — из линий, кружков и слов, а не из догадки о том, что на чертеже изображено.

Один и тот же альбом даёт один и тот же ответ. Не похожий — тот же, до последнего знака в тексте каждого замечания. Это закрыто тестом: альбом разбирается заново, ответы сличаются отпечатком, и тест падает, если они разойдутся. Проверяется это и в разных процессах, а не только дважды подряд: совпадение ответа внутри одного запуска ещё ничего не доказывает.

Поэтому замечание можно обсуждать. У каждого есть лист, страница и ссылка на пункт стандарта; проектировщик повторит проверку и получит ровно то же. Протокол становится документом, а не мнением, — на этом и держится всё остальное.

Если документ нельзя выпускать наружу вообще

Бывает и так: режим объекта не позволяет отправлять комплект даже нам. Тогда проверка ставится внутри вашего контура — образ и командная строка, без выхода в сеть. Это работа по договору, а не подписка: условия на странице тарифов.

Чего правила не делают

Сказать надо и это. Правила не оценивают проектных решений: движок видит, что документ противоречит сам себе, и не берётся судить, правильно ли выбран прибор, хватает ли уставке запаса и годится ли схема для этого техпроцесса. Это работа проектировщика и эксперта, и никакая проверка её не заменяет.

Он не понимает смысла чертежа и не поговорит с вами о документе. Если нужно именно это — пересказать раздел, составить письмо, объяснить назначение узла, — языковая модель справится лучше, и честнее сказать об этом прямо, чем делать вид, что правила умеют всё.

Он не ищет того, чего нет в документе: отсутствующий лист он назовёт, а ненаписанное требование — нет.