RAG-пилот на заводе: три недели растянулись на три месяца из-за документов

Трёхнедельный пилот RAG по технической документации газопоршневой электростанции мощностью 1 МВт идёт уже три месяца. Технический прототип и поисковый интерфейс развёрнуты и работают, но выкатить ассистента на тестирование инженерам пока нельзя: узким местом оказалась не разработка, а сборка и проверка данных. Об этом рассказал автор корпоративного блога на Habr, описывая внедрение ИИ в бизнес-процессы завода ПСМ.

RAG (Retrieval-Augmented Generation) — подход, при котором языковая модель отвечает не из своих обученных весов, а из внешней базы документов: система сначала находит релевантные фрагменты в корпусе, затем передаёт их модели как контекст. Для промышленности это принципиально: ответ должен опираться на верифицированные чертежи, схемы и регламенты, а не на память модели. Идея пилота простая: продажник, пресейл или инженер задаёт вопрос по продукту и получает ответ из заводской документации. Для первой итерации взяли один вид оборудования — газопоршневую электростанцию 1 МВт. Но у этой «базовой» станции обнаружилось 44 модификации: открытая рама или утеплённый блок-контейнер, класс напряжения 0,4 кВ или высоковольтные 6,3 / 10,5 кВ, разные марки промышленных контроллеров, наличие или отсутствие системы утилизации тепла, разные типы радиаторов и подогревателей. Под каждую конфигурацию нужны свои схемы, таблицы нагрузок, регламенты ТО и эксплуатационные карты. В каталоге ПСМ десятки моделей дизельных и газовых электростанций на разных двигателях — с учётом модификаций это сотни вариантов исполнения, по каждому из которых клиент может задать точечный вопрос.

Чтобы не закопаться в бесконечных исключениях, рамки вовремя сузили: вместо всех 44 модификаций в первую итерацию взяли несколько самых ходовых конфигураций. Но тут выяснилось, что единой качественной базы знаний со всей документацией нет. Где-то данные лежат в папке на сервере, до которой нужно добраться ещё через 10 папок, где-то — в закрытой задаче в Битриксе, где-то — в облаке или на рабочем столе инженера. При этом непонятно, какая версия актуальная, а человек, который знает, как правильно, ушёл в отпуск. Для пилота сделали реестр в Excel, просто чтобы понять, какие документы вообще существуют и как они связаны. Потом договорились рабочий набор складывать в один чат Bitrix, чтобы никто не запутался, какую версию и из какой папки сейчас тестируем. Автор называет это колхозной историей, но для пилота было главным зафиксировать набор данных и проверить гипотезу.

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

Этот кейс показывает типовую картину корпоративных ИИ-проектов: техническая логика понятна, а главный затык не имеет отношения к нейросетям. Настоящие сложности начинаются, когда ИИ просит у компании нормальные исходные данные и понятное описание бизнес-процесса. Модели, GPU и инфраструктура — решаемая часть. А вот инвентаризация документации, сведение версий, устранение противоречий и назначение ответственных за актуальность — работа, которую нельзя ускорить выбором более мощной модели. Именно она определяет срок и стоимость внедрения. Для читателя, который планирует похожий проект, вывод простой: прежде чем выбирать LLM и разворачивать векторную базу, стоит ответить на вопрос, есть ли в компании проверенный, структурированный и поддерживаемый в актуальном состоянии корпус документов. Если нет — пилот будет длиться не три недели, а три месяца, и это ещё оптимистичный сценарий.