Ответы по внутренним правилам
Сотрудник задаёт вопрос обычными словами и получает объяснение со ссылкой на нужный раздел.
Информация,
с которой можно
работать.
Документы компании могут помогать отвечать клиентам, проверять данные и разбираться в рабочих вопросах.
Рассказываем, как подготовить их для ИИ, настроить систему и понять, можно ли ей доверить задачу.
Как устроен проект
Начинаем с работы,
которую нужно упростить.
«Нам нужен ИИ» ещё не описывает задачу. «Менеджер тратит время на поиск условий в договорах» уже даёт точку начала.
Разбираем один реальный процесс вместе с теми, кто его выполняет. Какие сведения нужны сотруднику? Где они лежат? Кто отвечает за их актуальность? Что происходит, если ответ окажется неверным?
Выбираем действие, которое можно проверить: найти пункт инструкции, извлечь реквизиты из счёта, подготовить сводку обращения. Записываем, что помощник делает сам, что предлагает в черновике и когда передаёт вопрос человеку.
Результат первого этапа
Карта процесса, список источников, границы автоматизации и критерии приёмки. До разработки договариваемся, на каких примерах будем проверять результат.
Обработка документов
Из счёта, акта или заявки извлекаются нужные поля. Неоднозначные значения попадают на проверку.
Работа с обращениями
По переписке готовятся краткое содержание, список договорённостей и черновик следующего ответа.
Прежде чем искать ответы,
приводим знания в порядок.
Качество исходных материалов определяет, на что сможет опереться помощник.
Инструкции, таблицы, карточки CRM и переписка устроены по-разному. Для каждого источника определяем способ подключения, владельца и правила обновления. Скан сначала нужно распознать; таблицу важно сохранить вместе с названиями столбцов и единицами измерения.
Собираем и отбираем
Убираем случайные выгрузки, дубли и материалы без понятного статуса. Проверяем, какие сведения можно использовать в выбранном процессе.
Сохраняем смысл
Разделяем длинные тексты на связанные фрагменты. Заголовки, приложения, таблицы и исключения должны оставаться понятными после такого разделения.
Отмечаем происхождение
Сохраняем ссылку, номер страницы или раздела, редакцию, дату действия и права доступа. Ответ должен вести к конкретному месту в документе.
Разбираем противоречия
Если два регламента расходятся, владелец процесса определяет действующее правило. До этого помощник должен сообщать о расхождении.
Удаление документа тоже нужно обрабатывать: из поисковой базы, промежуточных копий и кеша, с учётом согласованных правил хранения.
От вопроса
до проверяемого ответа.
Помощник сначала находит подходящие материалы, а затем составляет ответ с опорой на них.
Такой подход называют RAG: поиск по базе знаний дополняет запрос к модели. Новая редакция инструкции поступает в поисковую базу; для этого не требуется каждый раз заново обучать модель.
Посмотрите на примере
Иллюстрация процесса · вымышленные данныеВопрос сотрудника
Кто согласует скидку 7%?
Регламент продаж · редакция 3 · пункт 4.2
Скидки от 5 до 10% согласует руководитель отдела продаж.
Ответ помощника
Скидку 7% согласует руководитель отдела продаж. Передайте ему заявку на согласование.
Основание: пункт 4.2 регламента. Скидка ещё не применена.
Права пользователяПоиск фрагментовПодготовка ответаПроверка источников
Сначала ограничиваем поиск материалами, доступными сотруднику. Затем подбираем фрагменты по смыслу и точным признакам: номеру договора, артикулу, дате. Проверяем, достаточно ли найденного для ответа и подтверждает ли источник сделанный вывод.
Ссылка сама по себе не доказывает правильность. На проверке отдельно смотрим, действительно ли приведённый пункт отвечает на вопрос. Если основания нет, помощник уточняет запрос или предлагает обратиться к ответственному.
Что значит
«обучить ИИ».
Выбор подхода зависит от того, чего системе не хватает: сведений, понятной инструкции или устойчивого навыка.
01
Настроить поведение
Задаём правила ответа, допустимые действия, формат результата и условия передачи человеку. Добавляем проверенные примеры хороших и неприемлемых ответов.
Подходит, когда нужно объяснить задачу и порядок её выполнения. Веса модели не меняются.
02
Подключить знания
Организуем поиск по документам компании. Модель получает нужные сведения в момент запроса вместе с их источниками и ограничениями доступа.
Подходит для инструкций, справочников и других материалов, которые регулярно обновляются.
03
Дообучить модель
Если задача требует устойчивой классификации, терминологии или специального формата, оцениваем дообучение подходящей модели на отобранных примерах. При этом меняются её параметры.
Нужно достаточно качественных примеров, право на их использование и измеримое преимущество перед более простым решением.
Как проходит дообучение
Сначала проверяем готовую модель на ваших задачах. Затем собираем и размечаем примеры вместе с экспертом. Отделяем обучающую выборку от проверочной, исключаем дубли и попадание одинаковых документов в обе части.
Запускаем ограниченный эксперимент и сравниваем версии на отложенных примерах. Если качество не улучшилось или стоимость оказалась неоправданной, не переносим эксперимент в рабочую систему. Дообучение не гарантирует достоверность и не заменяет актуальные источники.
Исправления сотрудников не становятся обучением автоматически
Обратную связь сначала проверяют и размечают. Только после этого она может попасть в новую версию правил, базы знаний или обучающей выборки.
Из ответа
в рабочий процесс.
Найти информацию и изменить запись в CRM требуют разных разрешений.
Для действий подключаем ограниченный набор операций: создать черновик, заполнить поля, передать задачу, запросить согласование. Программа проверяет права и входные данные независимо от текста, который вернула модель.
Пример · обработка счётаДокумент поступил.
Документ поступил.
Что происходит дальше?
- Распознаём поставщика, номер, сумму и позиции.
- Сверяем обязательные поля и итоговые значения.
- Проверяем, не обрабатывали ли этот документ раньше.
- Показываем сотруднику черновик и спорные места.
- После подтверждения отправляем данные в учётную систему.
Для операций с деньгами, договорными условиями и удалением данных предусматриваем подтверждение ответственного. Повторный запрос не должен создавать вторую операцию. Если внешняя система недоступна, сохраняем понятный статус и контролируем повторную отправку.
Проверяем
на неудобных вопросах.
Красивый ответ на демонстрации ещё не показывает, как система поведёт себя в работе.
Собираем проверочный набор из реальных типов задач: обычные вопросы, опечатки, неясные формулировки, старые версии документов, недостающие сведения и попытки получить чужие данные. Сотрудник, который знает процесс, помогает оценить правильность.
| Что проверяем | Как оцениваем |
|---|---|
| Поиск | Нашёлся ли нужный документ и конкретный фрагмент. |
| Достоверность | Подтверждаются ли утверждения приведёнными источниками. |
| Извлечение данных | Верно ли заполнено каждое обязательное поле. |
| Отказ и уточнение | Распознаёт ли система ситуации, в которых данных недостаточно. |
| Доступ | Не попадают ли закрытые сведения в поиск, ответ или журнал. |
| Работа под нагрузкой | Время ответа, ошибки, стоимость обработки и доля ручной проверки. |
Порог приёмки выбираем под последствия ошибки. Ошибочный тег обращения и неверная сумма в документе имеют разную цену. Смотрим результаты по отдельным типам задач, чтобы средняя оценка не скрыла слабое место.
После замены модели, правил поиска или инструкций повторяем проверки. Сохраняем предыдущую рабочую версию для отката.
Знания компании
имеют границы доступа.
Помощник должен видеть только те сведения, с которыми разрешено работать конкретному пользователю.
Описываем роли, отделы и ограничения на уровне источников. Проверяем доступ до передачи материалов модели. Учитываем смену должности, отзыв прав и удаление документа.
Текст внутри файла считаем содержимым документа. Встроенная в него команда «игнорируй правила» не должна давать системе новые полномочия. Такие сценарии включаем в проверочный набор.
Способ размещения выбираем после знакомства с данными и ограничениями компании. Отдельно согласуем состав журналов, срок их хранения, резервные копии и порядок удаления. Само по себе локальное размещение не решает все вопросы доступа.
Запускаем постепенно.
Проверяем в работе.
Пилот на одном процессе
Ограничиваем источники и группу пользователей. Сначала помощник готовит предложения, а сотрудник проверяет результат. Собираем ошибки и спорные случаи.
Подключение к привычным инструментам
Встраиваем помощника туда, где возникает задача: во внутренний кабинет, CRM или рабочий чат. Объясняем сотрудникам его возможности и ограничения.
Регулярное обновление
Следим за изменениями источников и состоянием загрузки. Для каждого раздела знаний нужен ответственный. Просроченный регламент не должен молча оставаться действующим.
Развитие по результатам
Сравниваем время выполнения задач и объём исправлений с исходным процессом. Новые функции добавляем после проверки; при ухудшении возвращаем рабочую версию.
Из чего складывается стоимость
Отдельно считаем подготовку и подключение данных, разработку интерфейса, интеграции, проверки и внедрение. В эксплуатации учитываем запросы к модели, распознавание файлов, хранение, инфраструктуру и поддержку.
До расширения пилота оцениваем стоимость при ожидаемой нагрузке и устанавливаем лимиты. Срок и бюджет можно назвать после оценки источников, объёма документов и сложности подключений.
У компании остаётся
понятная система.
Состав поставки фиксируем до начала проекта. Обычно он включает:
- Рабочий сценарий с согласованными интеграциями и правами.
- Реестр источников и правила их обновления.
- Проверочный набор, критерии приёмки и отчёт об ограничениях.
- Инструкции для пользователей и ответственных сотрудников.
- Описание размещения, расходов, мониторинга и восстановления.
- Порядок передачи кода, конфигурации и доступов по договору.
На этой странице описан предлагаемый подход к проекту. Конкретные функции и этапы выбираем после разбора задачи; иллюстрации не являются результатами клиентских внедрений.
Посмотреть примеры задач для бизнесаНесколько прямых ответов.
Можно ли просто загрузить все файлы?
Загрузить можно, но для полезного результата нужно разобраться с актуальностью, правами, дублями и противоречиями. На небольшом наборе проверяем, какие документы действительно помогают решать выбранную задачу.
Будет ли ИИ отвечать без ошибок?
Такой гарантии дать нельзя. Поэтому нужны источники, проверочные примеры, понятное поведение при недостатке данных и подтверждение важных действий человеком.
Нужно ли создавать собственную модель с нуля?
Для описанных сценариев обычно начинают с готовой модели. Необходимость дообучения проверяют экспериментом. Обучение с нуля требует отдельного обоснования, данных и вычислительных ресурсов.
Что подготовить для первой встречи?
Описание одного процесса, несколько обезличенных документов, примеры вопросов и ожидаемых ответов. Ещё полезно знать, кто отвечает за данные и в каких программах работают сотрудники.
Для тех, кто хочет разобраться в технологии
Поиск по знаниям: RetrievalОценка точности систем с языковыми моделямиДообучение: SFT Trainer