ИИ-система по техдокументации для производства

На любом заводе есть человек, который «знает, где это написано». Обычно ему за пятьдесят, он работает здесь двадцать лет, и к нему идут с вопросами, на которые формально есть ответ в документации. Просто найти его быстрее, чем спросить, невозможно.

Это не проблема дисциплины и не признак плохой организации. Это проблема объёма. Регламенты ТОиР, паспорта станков, руководства по эксплуатации от вендоров, карты смазки, чертежи узлов, акты и наряды по прошлым ремонтам, внутренние стандарты предприятия, нормативы на запчасти и расходники, протоколы дефектации. Тысячи документов, накопленных за десятилетия, часть — в PDF, часть — в сканах, часть — в бумажных папках у механика в шкафу, часть — в головах.

Разберём, как поверх этого корпуса собирается система поиска, которая разворачивается в инфраструктуре предприятия и переходит в его собственность. Что она делает, чего категорически не делает, как честно посчитать эффект и какие ограничения нужно принять до старта, а не после.

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

Как выглядит поиск информации сейчас

Понаблюдайте за механиком, которому нужно уточнить периодичность замены масла в редукторе конкретной модели. Последовательность обычно такая.

Сначала он вспоминает, какой это станок и какого года выпуска — от года зависит редакция паспорта. Потом идёт к сетевому диску, где папка «Документация», внутри — папки по цехам, названные то по инвентарному номеру, то по модели, то по фамилии человека, который их когда-то раскладывал. Находит PDF на 300 страниц. Поиск по тексту не работает: PDF — скан. Листает оглавление до нужного узла.

Дальше начинается самое интересное. В паспорте написано одно, во внутреннем регламенте предприятия — другое (обычно жёстче), а в прошлом ремонте делали по третьему варианту, потому что так решил главный механик после аварии несколько лет назад. Где зафиксировано это решение, механик не знает. Он звонит.

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

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

Что именно индексируется

Корпус техдокументации разнороден, и от типа документа зависит, насколько хорошо с ним работает поиск. Честно по каждому типу.

Текстовые PDF и офисные документы. Регламенты ТОиР, внутренние стандарты, инструкции, нормативы расхода. Идеальный материал: текст извлекается напрямую, структура разделов сохраняется, поиск работает точно.

Сканы бумажных документов. Паспорта станков советского и раннего постсоветского выпуска, оригиналы руководств вендоров, акты. Через OCR распознаются, но не идеально. Чистый скан 300 dpi — почти без потерь. Ксерокопия с ксерокопии, перекошенная, со штампом поверх текста — заметно хуже. Технические обозначения, индексы и дроби OCR путает чаще всего: «М12х1,25» может превратиться во что угодно. Поэтому по сканам система обязательно отдаёт ссылку на страницу оригинала — чтобы человек проверил число глазами.

Таблицы. Нормативы, карты смазки, перечни запчастей, таблицы допусков. Извлекаются, но требуют отдельной обработки: таблица, разрезанная разрывом страницы, без специальной логики превращается в кашу. Это отдельный этап работ, не «галочка в настройках».

Чертежи. Здесь надо быть предельно честными. Поиск по содержимому чертежа — по геометрии, по размерным цепям, по тому, «какой тут диаметр» — в общем случае не работает. Что работает: индексация основной надписи (обозначение, наименование, литера, масса, материал), текстовых требований на поле чертежа, спецификаций. По запросу «чертёж корпуса редуктора» система найдёт документ и покажет его. По запросу «какой посадочный диаметр на этом чертеже» — не ответит и не должна пытаться. Открывайте чертёж.

Рукописные журналы и записи. Распознаются плохо, ручной почерк — отдельная задача с невысокой надёжностью. Наш подход: либо не индексировать вовсе, либо индексировать с явной пометкой «низкая достоверность распознавания». Второй вариант хуже первого, потому что создаёт иллюзию покрытия.

История ремонтов и наряды. Самый ценный и самый неаккуратный слой. Здесь лежит ровно то, что обычно узнают звонком: что уже ломалось, что меняли, что помогло. Если это в системе ТОиР — берётся оттуда. Если в Excel и Word — берётся как есть, со всеми опечатками.

Типы запросов и где лежит ответ

Разные вопросы обслуживаются разными частями системы. Понимание этой раскладки заранее избавляет от завышенных ожиданий.

Обратите внимание на две последние строки. Отказ отвечать — такая же функция системы, как и ответ. Система, которая пытается угадать размер по чертежу или дать заключение о допуске оборудования к работе, опаснее, чем отсутствие системы.

Строка «расхождение источников» — не редкий случай, а норма для производства с историей. Паспорт вендора говорит одно, отраслевой норматив — другое, внутренний стандарт — третье, а протокол техсовета вводит четвёртое правило для конкретной единицы. Правильное поведение — показать все найденные варианты с датами и статусами документов и явно сказать, что источники расходятся. Неправильное — выбрать один и выдать его как истину.

Границы: чего система не делает

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

Практический вывод для проекта: переход к первоисточнику делается в один клик, цитата визуально отделена от любого пояснения. Реквизиты документа — обозначение, наименование, номер редакции, дата ввода в действие, статус (действующий / отменён / заменён) — показываются рядом с ответом, а не прячутся в подсказке.

Что автоматизируется, а что остаётся за человеком

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

Почему нужен собственный контур

Для производства это не идеологический вопрос, а инженерный и юридический.

Техдокументация — это ноу-хау. Технологические карты, доработанные под конкретное производство регламенты, накопленная история отказов, решения по нестандартным узлам. Всё это конкурентное преимущество, а иногда и предмет обязательств перед заказчиками или лицензиарами. Отправлять такой корпус во внешний облачный сервис — значит выносить его за периметр предприятия и принимать чужие условия обработки.

Часть документации имеет ограничения по распространению. Гриф, коммерческая тайна, требования гособоронзаказа, условия договоров с вендорами. Вопрос закрывается не политикой конфиденциальности поставщика, а тем, что данные физически не покидают контур.

Сегментированная сеть — норма, а не исключение. На многих предприятиях технологический сегмент изолирован от интернета, и это правильно. Система, требующая постоянного доступа к внешнему API, в такой сети просто не запустится.

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

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

Разграничение доступа

Заводская документация не является однородной по уровню доступа, и система обязана это уважать.

Базовый принцип: права наследуются из существующей модели доступа предприятия, а не заводятся заново. Есть Active Directory и распределение по группам — система берёт их. Параллельная система прав гарантированно рассинхронизируется с реальной через полгода.

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

Слои доступа в типовой конфигурации: оператор и слесарь видят инструкции и регламенты по своему участку; мастер и механик цеха — плюс историю ремонтов и нормативы; служба главного механика — весь корпус по своему направлению; технологи и конструкторы — свою часть; документы с ограничениями выдаются поимённо.

Логирование: кто, что и когда спрашивал, какие документы попали в выдачу, какие ссылки открывались. Нужно и для ИБ, и для аналитики — по логам видно, каких документов не хватает.

Интеграция с ТОиР и ERP

Документация отвечает на вопрос «как должно быть». Системы ТОиР и ERP отвечают на вопрос «что было и что есть». Полезный ответ часто требует и того, и другого.

Со стороны ТОиР берётся реестр оборудования с инвентарными номерами и привязкой к цехам, история заявок и нарядов, выполненные работы, заменённые узлы, зафиксированные дефекты, плановые графики. Это позволяет отвечать на вопросы вида «что делали с этим насосом за три года» и «когда по графику следующее ТО».

Со стороны ERP — номенклатура запчастей и расходников, остатки на складе, привязка позиций к нормативам. Механик спрашивает, какое масло по нормативу — система отдаёт пункт норматива и заодно показывает, есть ли позиция на складе и под каким артикулом.

Со стороны АСУ ТП — только чтение исторических данных, если такая интеграция вообще нужна и согласована. Например, чтобы к истории ремонтов подтянуть тренды параметров перед отказом. Контур опциональный, требует отдельного согласования и часто реализуется через одностороннюю передачу в изолированное хранилище.

Оговорка про качество данных. Интеграция полезна ровно настолько, насколько аккуратно ведутся исходные системы. Если в ТОиР половина нарядов закрыта формулировкой «выполнено», извлечь из них смысл нельзя. Это вскрывается на аудите и часто становится отдельной задачей — не для ИИ, а для организации процесса.

Пользователь → Поиск
      ├─ Индекс документации ──→ регламенты, паспорта, СТП, нормативы
      ├─ ТОиР (чтение) ────────→ история нарядов, дефекты, графики
      ├─ ERP (чтение) ─────────→ номенклатура, остатки
      ├─ Ответ ТОЛЬКО с цитатой: документ + пункт + редакция
      └─ Нет источника → «не найдено» + где искали
                          ✗ никаких команд в АСУ ТП

Модельный расчёт эффекта

Дальше — арифметика по типовым отраслевым вводным. Смысл не в том, чтобы показать красивую цифру, а в том, чтобы вы подставили свои и увидели порядок величины.

Возьмём условное предприятие: 40 человек инженерно-технического персонала, работающих с документацией — механики, мастера, специалисты службы главного механика, технологи. Обычно в отрасли такой специалист обращается к документации 4–6 раз за смену. Возьмём осторожно: 4 обращения.

Шаг 1. Сколько времени уходит на поиск. Среднюю длительность поиска примем 20 минут — нижняя граница диапазона 20–60, чтобы не завышать эффект. 40 × 4 × 20 = 3 200 минут в смену, около 53 часов.

Шаг 2. Какая доля запросов покрывается. По раскладке из таблицы выше — запросы к нормативам, паспортам, инструкциям и истории ремонтов. При типовом состоянии корпуса это порядка 60% обращений; остальное — чертежи, диагностика, решения. 53 × 0,6 ≈ 32 часа в смену.

Шаг 3. Что происходит с этим временем. Поиск не становится мгновенным: человек всё равно открывает первоисточник и читает его, эту часть мы не убираем. Реалистично — с 20 минут до 4–5, то есть экономия около 75% покрываемого объёма. 32 × 0,75 ≈ 24 часа в смену.

Шаг 4. За месяц. При 21 смене — около 500 человеко-часов. При условной стоимости часа ИТР 700 ₽ это порядка 350 000 ₽ в месяц в эквиваленте рабочего времени.

Отдельно — эффект на простое. Если поиск информации сокращает время реакции на внеплановую остановку хотя бы на 15 минут, а таких остановок двадцать в месяц, это 5 часов работы оборудования. Стоимость часа простоя считается индивидуально и часто перекрывает всю экономию на человеко-часах — именно поэтому мы не подставляем сюда цифру наугад.

Этапы внедрения

1. 1
   1–2 недели

   Инвентаризация корпуса документов

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

2. 2
   1 неделя

   Разбор типовых запросов

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

3. 3
   2–4 недели

   Подготовка и индексация

   OCR сканов, извлечение таблиц, разбор структуры документов, привязка к единицам оборудования и редакциям. Самый трудоёмкий этап, длительность прямо зависит от состояния корпуса. Здесь же настраивается механизм цитирования с реквизитами документа.

4. 4
   1–2 недели

   Развёртывание в контуре заказчика

   Установка на серверы предприятия, подключение к каталогу пользователей и наследование прав, настройка изоляции сети. Согласование архитектуры со службами ИБ и АСУ ТП, включая подтверждение отсутствия обратного канала в промышленный контур.

5. 5
   1–2 недели

   Интеграции с ТОиР и ERP

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

6. 6
   2–3 недели

   Пилот на одном цехе

   Запуск на ограниченной группе пользователей. Замеряем качество на тестовом наборе запросов, собираем случаи, когда система не нашла или нашла не то, дополняем корпус. Пилот на одном цехе честнее, чем демонстрация на подобранных примерах.

7. 7
   1 неделя

   Передача и обучение

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

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

Метрики качества

Оценивать такую систему «на глаз» нельзя — субъективное впечатление первых пользователей почти всегда расходится с реальным качеством. Нужен измеримый набор.

Две метрики из этого списка обычно недооценивают.

Доля честных «не найдено» должна быть заметной. Если она стремится к нулю, система почти наверняка расширила интерпретацию и начала выдавать приблизительно подходящие фрагменты как ответ. Для производства это худший режим: ответ выглядит уверенно, а пункт не тот. Здоровое значение зависит от полноты корпуса, но 10–20% на старте нормально.

Переходы к первоисточнику. Система задумана как навигатор, а не как оракул. Если люди перестают открывать документы и начинают доверять цитате в интерфейсе, надо менять интерфейс: усиливать кнопку перехода, показывать цитату короче, добавлять напоминание о проверке.

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

Риски и как они снимаются

«Система выдаст неверный пункт, а человек сделает по нему». Снимается двумя вещами: обязательной ссылкой с реквизитами (человек видит, из какого документа и пункта взят фрагмент, и открывает его) и измерением точности на тестовом наборе реальных запросов до запуска. Если точность ниже порога, система не выходит в эксплуатацию.

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

«Служба ИБ не согласует». Поэтому архитектура согласуется до разработки. Отсутствие обратного канала в АСУ ТП, локальная модель, изолированное развёртывание, наследование прав из корпоративного каталога, полное логирование — не опции, а базовая конфигурация. Разговор с ИБ идёт про схему сети, а не про доверие к подрядчику.

«Люди не будут пользоваться, привыкли звонить». Частично будут звонить и дальше — живая консультация не отменяется. Приживаемость определяется скоростью первого результата и тем, сколько раз система ошиблась в первые недели. Поэтому пилот запускается на одном цехе с хорошо подготовленным корпусом, а не на всём предприятии с сырым.

«Попадём в зависимость от подрядчика». Ровно поэтому проект делается как система под ключ: код, схема развёртывания и документация передаются вам. Через год вы должны уметь развернуть систему заново без нашего участия. Если не умеете — этап передачи выполнен плохо.

«Модель устареет». Слой генерации меняется быстро, поэтому он делается заменяемым: индекс, права и логика цитирования не зависят от конкретной модели. Смена модели — конфигурация и повторный прогон тестового набора, а не переписывание системы.

Частые вопросы

Может ли система подсказать причину неисправности? Нет. Она покажет, что уже случалось с этим и аналогичным оборудованием, какие дефекты фиксировались и что делали в прошлые разы. Это материал для диагностики, а не диагностика. Вывод делает инженер.

Что если паспорт станка есть только в бумаге? Его нужно оцифровать — это часть подготовительного этапа. Сканирование и OCR стоят денег и времени, поэтому на инвентаризации мы считаем объём бумаги и предлагаем приоритизацию: сначала оборудование, которое чаще ломается. Оцифровать всё сразу — верный способ растянуть проект на год.

Нужен ли отдельный сервер с видеокартами? Зависит от модели и числа пользователей. Для локальной модели среднего размера и десятков одновременных пользователей — да, нужна машина с GPU. Конфигурация считается на этапе проектирования. Иногда допустим вариант с внешней моделью через контролируемый шлюз — требования к железу тогда минимальны, но решение принимает ваша служба ИБ, и подходит это не для всякой документации.

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

Можно ли начать с одного цеха? Не только можно, а нужно. Один цех с подготовленным корпусом даёт реальную оценку качества и приживаемости за пару месяцев. Дальше масштабирование — это в основном подготовка новых документов, архитектура уже работает.

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

Что понадобится от вас

Чтобы аудит был расчётом, а не гаданием:

• перечень оборудования с инвентарными номерами и привязкой к цехам;
• доступ к корпусу документации в текущем виде — со всеми папками, дублями и бардаком, без предварительной уборки;
• реестр действующих редакций нормативных документов, если он есть; если нет — честный ответ, что его нет;
• выгрузка истории нарядов и дефектов из ТОиР за последние два-три года;
• 30–50 реальных вопросов, которые инженеры задают друг другу, — это будущий тестовый набор;
• один человек со стороны службы главного механика, который может авторитетно сказать, какой ответ правильный;
• контакт службы ИБ и службы АСУ ТП для согласования архитектуры контура.

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