RAG для сервисных инженеров: инструкции, ошибки и полевые руководства
Полевой ответ начинается с identity оборудования, актуальной процедуры и границы безопасности
Asset configuration, manual revisions, error-code signals, evidence locators и qualified review routes
Авторский FIELD-SERVICE-9 workflow с шестью use cases, ROI-моделью пилота и acceptance criteria
RAG для технических инструкций, сервисные инженеры, коды ошибок, руководства обслуживания и FIELD-SERVICE-9
$ field-service-rag --contract FIELD-SERVICE-9
> receive: asset / symptom / error-code / role
> resolve: configuration / revision / hazard-class
> retrieve: current manual / bulletin / locator
> verify: prerequisites / warnings / conflict / scope
> route: inspection / clarify / qualified-review / emergency / no-answerАссистент для сервисного инженера полезен тогда, когда сокращает путь от наблюдаемого симптома к нужной утверждённой процедуре. Он опасен, когда превращает неполное описание в уверенную инструкцию по ремонту. Для полевой работы беглый ответ не является доказательством: нужны идентичность оборудования, актуальная версия руководства, контекст кода ошибки, граница безопасности и маршрут к квалифицированному человеку.
В статье описан FIELD-SERVICE-9 — ограниченный RAG-паттерн для технических инструкций, разбора неисправностей и полевых руководств. Он помогает инженеру найти и проверить разрешённые evidence. Он не выдаёт допуск по безопасности, не отменяет lockout/tagout, не меняет конфигурацию оборудования, не заказывает запчасть и не заменяет процедуру производителя.
Начните с процесса в поле, а не с окна чата
Вопрос техника обычно является сжатым отчётом об инциденте: «Что означает этот код?», «Какую проверку сделать следующей?» или «Можно ли заменить эту деталь на месте?». Ответ зависит от модели, диапазона серийного номера, firmware, установленной опции, региона, состояния обслуживания и квалификации человека.
Надёжный процесс состоит из пяти этапов:
- Принять ID оборудования, наблюдаемый симптом, код ошибки, место и разрешённый пользовательский контекст.
- Разрешить точную конфигурацию машины, применимое семейство документов, ревизию и класс риска.
- Найти только актуальные и разрешённые руководства, деревья диагностики, service bulletins и данные об approved parts.
- Проверить каждую существенную инструкцию по открываемому locator, prerequisites и состоянию конфликта.
- Маршрутизировать к ответу с citations, уточнению, контролируемому review, аварийной процедуре или честному no-answer.
Широкая задача внедрения находится на странице RAG-систем. Эта статья намеренно уже: она превращает один вопрос из поля в проверяемый маршрут evidence. Команды, которым нужен более широкий разбор локальной AI-разработки, могут оценить scope и контроль на странице /ru/ai-specialist-armenia.
FIELD-SERVICE-9: контракт evidence
Оригинальное доказательство в статье — карта полевого процесса, шесть ограниченных use cases и простая ROI-модель пилота. Это методика проектирования, а не отчёт о внедрённой клиентской системе и не обещание эффективности.
| Слой evidence | Минимальный контракт | Зачем он нужен |
|---|---|---|
| Идентичность оборудования | модель, диапазон серийного номера, конфигурация, firmware и место | Процедура для похожей модели может быть неверной или небезопасной. |
| Технический источник | owner, ревизия, lifecycle, locale и locator раздела | Инженер должен открыть те же evidence. |
| Сигнал неисправности | код ошибки, время, рабочее состояние и зафиксированный симптом | Не смешивает определение кода с диагнозом. |
| Контекст безопасности | класс риска, prerequisites, правило изоляции и граница квалифицированной роли | Retrieval не должен скрывать safety steps или права. |
| Рабочая запись | вопрос, cited evidence, маршрут, reviewer и сигнал исправления | Даёт возможность проверки, обучения и ремонта источника. |
Система должна сохранять структуру руководства: warnings, prerequisites, схемы, последовательность, ограничения измерений и stop conditions. Chunk без строки «обесточьте оборудование перед открытием панели» — не безобидная оптимизация retrieval. Если источник устарел, отсутствует, конфликтует или не входит в scope пользователя, корректный результат — review или no-answer.
request: asset=MX-42 / serial=known / fault=E-17 / role=field-engineer
resolve: configuration / firmware / approved manual revision / hazard class
retrieve: current troubleshooting tree + applicable bulletin + section locators
verify: prerequisites / warnings / revision / conflicts / entitlement
route: cited next inspection | clarify | qualified review | emergency procedure | no-answerШесть полезных полевых маршрутов и их границы
- Объяснение кода ошибки. Показать официальное определение кода, ревизию источника и разрешённую первую проверку. Не делать вывод о причине только по коду.
- Направляемая инспекция. Показать актуальную диагностическую ветку с инструментами, prerequisites и stop condition. Наблюдения подтверждает инженер вне модели.
- Поиск обслуживания. Найти корректный интервал и задачу для определённой конфигурации, а overdue или abnormal condition передать владельцу обслуживания.
- Проверка service bulletin. Сопоставить диапазон оборудования и ревизию с утверждённым bulletin. Не применять bulletin к похожему серийному номеру по внешнему сходству.
- Поиск запчасти и совместимости. Вернуть cited approved relation с условиями конфигурации; покупка и замена остаются отдельными authorised workflows.
- Передача из поля. Собрать наблюдаемый симптом, locators evidence, незаполненные поля и разрешённые policy фотографии для эксперта или OEM escalation.
Эти маршруты полезны, потому что сохраняют рабочую границу. Ассистент может подготовить структурированную заметку для диагностики, но не сертифицирует ремонт, не разрешает работу под напряжением и не предлагает неквалифицированному человеку выполнять опасную процедуру.
Данные и интеграции — это операционные контракты
Пилоту обычно нужны asset registry или CMMS для идентичности и состояния обслуживания; контролируемое хранилище документов для manuals, схем и bulletins; источник истории ошибок или telemetry для signals; identity layer для прав роли и площадки. Одного имени интеграции недостаточно. Для каждого источника зафиксируйте durable ID, owner, правило обновления, разрешённые поля, событие удаления, поведение при сбое и открываемый человеком locator.
Не превращайте RAG-индекс в теневую CMMS. Авторитетным остаётся asset/document system. Ответ retrieval может привести инженера к актуальной процедуре, но не должен незаметно создать work order, обновить service history или одобрить замену. Для этих действий нужны отдельные permissions, deterministic checks и verified read-back.
Тема lifecycle связана с материалом Обновление индекса RAG: ingestion, версии и удаление данных. Для citations и locators используйте дисциплину из статьи Цитаты и traceability в RAG. Вопросы о текущих product relations отделены в статье RAG по каталогу товаров.
Риски, для которых нужен явный маршрут
Опасная ошибка редко выглядит абсурдно. Чаще это правдоподобная инструкция, привязанная к неверному оборудованию, ревизии, safety state или человеку. В acceptance set включите:
- один код ошибки на двух версиях firmware с разным remedial action;
- руководство, которое заменено, но осталось в индексе;
- отсутствующий серийный номер или неоднозначную конфигурацию;
- bulletin, действующий только для ограниченного диапазона оборудования;
- диагностический шаг, чьи prerequisites не подтверждены;
- приватный чертёж, запрошенный неавторизованным пользователем;
- опасный или аварийный симптом, который обязан выйти из обычного RAG-маршрута.
В этих случаях система запрашивает недостающую идентичность, показывает uncertainty, отказывает в доступе, направляет к аварийной процедуре или готовит reviewable handoff. «Для этой конфигурации не найдено утверждённой процедуры» — ценная реакция, если она предотвращает импровизацию.
Простая ROI-модель пилота без выдуманных результатов
Начните с одного частого ограниченного класса вопросов — например, интерпретации некритичного кода ошибки для одного семейства оборудования. Измерьте локальный недельный объём, текущие минуты поиска, число эскалаций, effort подготовки документов и исправления после review. Не смешивайте baseline и диапазон пилота.
Например, 40 допустимых запросов в неделю при 12 минутах текущего поиска дают baseline 480 минут. Пилот может уменьшить повторную навигацию по документам, но добавляет владение источниками, acceptance testing, review и обработку эскалаций. Полезный отчёт отдельно показывает assumptions и наблюдаемые результаты; он не называет черновик ответа выполненным ремонтом или доказанной экономией.
Acceptance criteria перед полевым rollout
| Проверка | Условие прохождения |
|---|---|
| Разрешение оборудования | Cited procedure показывается только после выполнения требований к модели и конфигурации. |
| Lifecycle источников | Заменённые manuals и снятые bulletins исключаются из retrieval. |
| Сохранение безопасности | Warning, prerequisite и stop condition остаются видимыми вместе с инструкцией. |
| Граница кода ошибки | Ответ различает официальное определение, evidence и диагноз. |
| Ролевая граница | Restricted drawings и procedures запрещаются до retrieval. |
| Неоднозначность | Отсутствующая configuration даёт уточнение или review, а не guessed match. |
| Граница действия | Сертификация ремонта, work-order writes, покупка и опасные решения остаются вне RAG-ответа. |
Эксплуатируйте пилот как capability полевых evidence, а не как автономного техника. Наблюдайте coverage citations, попытки обращения к stale sources, долю уточнений, конфликты, outcomes эскалаций и ownership исправлений. Начните с одного семейства оборудования, одного набора документов и одного low-consequence route. Затем решите, достаточно ли trustworthy evidence и operating path для расширения пилота. Для обсуждения контролируемого внедрения начните со страницы RAG-систем или посмотрите инженерные доказательства в /ru/case-studies.
require(asset.identity && asset.configuration && request.role);
require(evidence.every(isCurrentPermittedAndOpenable));
require(instruction.prerequisites && instruction.stopCondition);
require(testSet.versionBoundary && testSet.ambiguousAsset && testSet.hazardRoute);
if (!asset.serialOrConfiguration) route = "clarify-or-review";
if (source.superseded || evidence.conflicts) route = "qualified-review-or-no-answer";
if (hazard.emergency || request.requiresCertification) route = "emergency-or-authorized-workflow";