ИИ в проекте: какую задачу ему поручить

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

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

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

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

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

• Что произойдёт, если рядом лежат старая и новая инструкции?
• Найдёт ли помощник исключение, спрятанное в примечании?
• Получит ли сотрудник сведения из документа, к которому у него нет доступа?

Часть вопросов оставьте на потом и не используйте при настройке. Иначе получится помощник, который хорошо отвечает на знакомые примеры, а на новых теряется.

В поиске по документам система сначала выбирает подходящие фрагменты, затем передаёт их модели вместе с вопросом. Модель формулирует ответ. У этих этапов разные ошибки.

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

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

Какие документы можно отправлять в облако? Кто имеет право их читать? Где будут храниться запросы? Эти вопросы нужны до подключения сервиса.

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

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

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

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

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

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

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

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

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

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