Руководитель сервиса хочет, чтобы сотрудники быстрее находили правила обслуживания и готовили ответы клиентам. У отдела уже есть инструкции, таблицы и архив переписки. Перед подключением ИИ стоит определить, какие материалы отражают действующие правила, кто отвечает за их содержание и кому разрешен доступ.
Для первого пилота подойдет один раздел знаний с понятным владельцем. Например, порядок приема оборудования в ремонт. На этом участке можно собрать источники, составить вопросы и проверить путь от документа до ответа. Результат покажет, какие работы потребуются при расширении.
Ниже приведен методический пример такого корпуса. Названия документов и вопросы созданы для объяснения подхода. Их можно заменить на материалы своего отдела и получить заготовку задания для команды разработки.
Определите роль поиска и модели
В классической схеме RAG приложение находит подходящие фрагменты источников и передает их языковой модели для подготовки ответа. Качество зависит в том числе от подготовки содержимого и поиска. Такая схема описана в документации Microsoft. Подготовка содержимого для RAG.
Для владельца знаний это означает две отдельные проверки. Сначала нужно убедиться, что система нашла правильное основание. Затем проверить, как она использовала его в ответе. При ошибке полезно увидеть оба результата и назначить работу нужному специалисту.
Дообучение решает другую техническую задачу: меняет обучаемые параметры модели на примерах. Например, документация PEFT описывает адаптацию через обучение ограниченного числа дополнительных параметров. Решение о такой работе принимают по конкретным ошибкам и цели проверки. Подход PEFT.
Начальный план подготовки документов можно составить до выбора модели. Список источников, роли читателей, актуальные версии и проверочные вопросы понадобятся при разных вариантах реализации поиска.
Соберите небольшой связный корпус
Возьмите документы, которые вместе позволяют закончить выбранное действие. Для приема оборудования это могут быть перечень обязательных сведений, инструкция по упаковке, правила обслуживания и маршрут передачи заявки специалисту.
Назначьте каждому источнику владельца. Он подтвердит действующую редакцию, объяснит исключения и разрешит спор между материалами. Техническая команда затем перенесет эти правила в обработку и поиск.
| Источник в примере | Что из него узнает сотрудник | Действующая версия | Кто подтверждает | Доступ | Что проверить при загрузке |
|---|---|---|---|---|---|
| Порядок приема | Обязательные поля обращения | Утвержденная редакция | Руководитель сервиса | Сервисный отдел | Заголовки, списки и ссылки. |
| Инструкция по упаковке | Требования к отправке | Редакция для нужного типа изделия | Технический специалист | Сервис и продажи | Подписи к рисункам и условия применения. |
| Правила обслуживания | Основания и порядок рассмотрения | Редакция с датой действия | Владелец документа | Согласованные группы | Исключения и связь с приложениями. |
| Маршрут сложных обращений | Ответственный за дальнейший разбор | Текущая схема отдела | Руководитель сервиса | Сервисный отдел | Имена ролей и адреса перехода. |
Добавьте к паспорту постоянную ссылку, идентификатор документа и дату проверки. Если копии одного текста лежат в нескольких папках, выберите основное место хранения. Это упростит обновление и проверку источника сотрудником.
Архивные редакции можно сохранить с отдельным назначением и периодом действия. Команда должна явно определить, какие вопросы относятся к текущим правилам, а какие требуют исторической версии. Эти условия влияют на поиск.
Проверьте извлеченный текст
Откройте результат извлечения рядом с оригиналом. Посмотрите, сохранились ли заголовки, номера пунктов, строки таблиц и связь условия с исключением. Для сканов проверьте распознавание цифр, обозначений моделей и коротких слов, которые меняют смысл требования.
Удобная проверка состоит из конкретного вопроса. Например, сотрудник ищет комплект документов для приема изделия. Найденный фрагмент должен сохранять название изделия и все условия, к которым относится список. Обрыв контекста в середине таблицы стоит исправить до оценки ответов.
Разделение длинного документа на фрагменты подбирают по его структуре и задачам поиска. Сохраните рядом название источника, раздел, версию и ссылку. Тогда сотрудник сможет открыть основание, а инженер сможет проследить путь от исходной страницы до найденного текста.
Изображения и схемы требуют собственного решения. Иногда достаточно точной подписи, иногда нужен отдельный способ обработки. Запишите, какие сведения содержит изображение и как их проверит пользователь. Так эта часть документа попадет в объем работ.
Составьте вопросы с проверяемыми основаниями
Попросите сотрудников вспомнить реальные формулировки обращений. Включите профессиональные термины, разговорные названия и вопросы, которые требуют уточнения. Для каждого примера укажите источник и ожидаемый ход ответа.
| Вопрос в методическом примере | Основание для ответа | Что проверяет эксперт |
|---|---|---|
| Какие сведения нужны при передаче изделия? | Раздел о приеме | Полнота обязательных полей и ссылка на пункт. |
| Как отправить изделие выбранного типа? | Инструкция по упаковке | Применимость инструкции к типу изделия. |
| Какая редакция правил действует для старого обращения? | Документ с периодом действия | Выбор версии по дате события. |
| К кому передать спорный случай? | Маршрут сложных обращений | Актуальная роль и понятный следующий шаг. |
| Что делать при описании сразу двух разных изделий? | Правила приема и уточнение сотрудника | Запрос сведений, которые нужны для точного выбора. |
Для части вопросов ожидаемым действием будет уточнение или передача специалисту. Запишите это заранее. Тогда эксперт оценивает полезность рабочего шага вместе с точностью текста.
Сохраните отдельную часть вопросов для итоговой проверки. В журнале результатов полезны четыре поля: найденное основание, ответ, замечание эксперта и действие для исправления. Причины могут относиться к документу, поиску, инструкции модели или интерфейсу.
Свяжите источники с правами
Паспорт должен отражать разрешенные группы читателей. При делении документа на фрагменты связь с источником и его правами должна сохраняться в проектируемой системе. Это требование проверяют на материалах с разным уровнем доступа.
Один из технических примеров описан в Azure AI Search: доступ к результатам связывается с правами пользователя и сведениями о разрешениях документов. Конкретные механизмы зависят от продукта и режима работы. Доступ на уровне документов.
Для пилота подготовьте пары проверок: одинаковый вопрос от сотрудников с разными полномочиями. В ожидаемом результате укажите допустимые источники и способ продолжить задачу. Проверять стоит также заголовки, ссылки и фрагменты, которые показывает интерфейс.
Опишите жизнь документа после загрузки
Назначьте событие обновления: утверждение новой редакции, изменение файла или согласованный запуск обработки. Определите допустимое время появления изменений в поиске. Владелец знаний должен понимать, как проверить завершение обновления.
Заранее разберите снятие документа с использования. Укажите, что происходит с его фрагментами, ссылками, сохраненными ответами и журналами. Сроки хранения и порядок очистки согласуют владельцы данных и системы.
При новой редакции повторите связанные проверочные вопросы. Например, изменение состава обязательных полей должно проявиться в ответе о приеме. Сохраните дату проверки и версию корпуса, чтобы позднее объяснить, на каких материалах работала система.
Для обсуждения пилота соберите один раздел знаний, заполненный паспорт и вопросы сотрудников. DEF.center поможет спроектировать поиск и ИИ-систему с проверяемыми ответами. Если материалы поступают из нескольких рабочих систем, включите в план интеграции и обновление источников.