В компании уже есть документы, таблицы, CRM и учетная система. Для первого ИИ-проекта предстоит выбрать ту часть сведений, которая помогает выполнить конкретное действие. Помощнику по инструкциям нужен набор актуальных документов. Сервису подготовки ответа клиенту нужны сведения о заказе и правила общения. Прогнозу спроса потребуется история наблюдений с понятными датами и значениями.
Подготовка начинается с результата: что пользователь хочет получить и как проверит ответ. Затем команда определяет источники, владельцев, доступ и способ обновления. Такой порядок позволяет оценить объем работы до выбора модели и оборудования.
В статье используются два методических примера. Они показывают способы подготовки, а названия компаний, роли и условия служат учебной задаче.
Опишите результат в одном предложении
Для поиска по документам формулировка может звучать так: «Сотрудник отдела сервиса получает ответ о порядке возврата со ссылкой на действующий регламент». Для работы с заказами: «Менеджер получает черновик ответа о статусе конкретного заказа и сверяет его с карточкой».
Эти предложения сразу задают состав данных. В первом случае нужны условия возврата, дата их действия и доступ сотрудника. Во втором нужны идентификатор заказа, принадлежность клиенту, текущий статус и время обновления. История всех финансовых операций компании расширяет объем обработки, поэтому ее включение должно иметь понятную цель.
Рядом с формулировкой результата запишите действие человека. Сотрудник может только читать сведения, выбирать предложенный вариант или подтверждать изменение в системе. Подготовка данных и требования к проверке зависят от этого выбора.
Используйте матрицу источников
Матрица связывает источник с конкретной пользой. Ее удобно заполнять вместе с владельцем процесса и IT-командой. Колонка «Следующий шаг» превращает обследование в список работ с ответственными.
| Сценарий | Источник | Владелец | Доступ | Проверка качества | Следующий шаг |
|---|---|---|---|---|---|
| Ответ по регламенту | Утвержденные инструкции | Руководитель сервиса | Сотрудники отдела | Действующая версия и читаемый текст | Собрать каталог документов. |
| Статус заказа | Учетная система | Руководитель учета | Назначенный менеджер | Идентификатор и время обновления | Подготовить согласованную выборку полей. |
| Объяснение статуса | Справочник статусов | Владелец процесса | Отдел сопровождения | Одно толкование каждого статуса | Дописать примеры переходов. |
| Прогноз по товару | История продаж и остатков | Коммерческий отдел | Аналитик проекта | Даты, единицы, возвраты, пропуски | Составить словарь показателей. |
Источник может быть простым файлом, если его формат, владелец и порядок обновления подходят пилоту. Для рабочего запуска отдельно определяются доставка изменений и контроль свежести. Состав проекта растет по мере появления подтвержденных требований.
Пример 1: сотрудник ищет ответ в документах
Предположим, сервисная компания хранит инструкции в нескольких папках. Одни файлы описывают текущие правила, другие сохраняют прошлые редакции. У руководителя есть письма с уточнениями. Прежде чем подключать поиск, команда выбирает, какой документ задает действующее правило.
Начните с каталога. Для каждого документа укажите название, владельца, версию, дату начала действия, аудиторию и источник оригинала. Отдельно пометьте архивные материалы. Если два файла содержат разные условия, владелец процесса определяет нужную редакцию и объясняет область ее действия.
Затем проверьте читаемость. У скана должны сохраняться заголовки, строки таблиц, единицы измерения и примечания. Сотрудник сравнивает полученный текст с оригиналом на выбранных примерах. Ошибка в условии возврата или сумме меняет смысл ответа, даже когда большая часть страницы распознана верно.
Для RAG найденные фрагменты документов передаются языковой модели как контекст ответа. Поэтому качество поиска и состав источников входят в проверку всей системы. Сам механизм описан в документации Microsoft о RAG.
Подготовьте вопросы вместе с сотрудниками. Для каждого укажите нужный документ, фрагмент с основанием и ожидаемое действие. Включите вопросы с похожими словами, но разными условиями. Добавьте случай, когда сотруднику следует обратиться к владельцу регламента за уточнением. Такой набор помогает проверить смысл, ссылки и рабочий маршрут.
Пример 2: менеджер отвечает по истории заказов
Второй сценарий строится вокруг записей. Заказ может иметь номер, внутренний идентификатор, клиента, товар, статус и дату изменения. CRM хранит переписку, а учетная система фиксирует движение заказа. Команде предстоит определить, как эти записи связаны.
Начните с идентификаторов. Если один клиент записан по-разному в двух системах, составьте правило сопоставления. Уточните, какой номер видит клиент и какой использует внутренняя система. Дайте менеджеру возможность открыть карточку, по которой подготовлен ответ.
Затем опишите смысл полей. «Готов» может означать завершение производства, готовность к выдаче или завершение всех документов. Для модели и интерфейса нужны отдельные понятные состояния. В словаре поля стоит хранить название, смысл, допустимые значения, источник, время обновления и пример.
Отдельно проверьте изменения. Если срок скорректировали после последнего обмена, ответ должен показывать свежие сведения либо направлять сотрудника к актуальной карточке. Допустимый возраст данных задает владелец процесса. Для истории покупок и текущего статуса заказа могут подходить разные интервалы обновления.
Отделите факт от объяснения
В обоих сценариях полезно различать три слоя. Факт приходит из определенного источника: статус, дата или условие. Правило объясняет, какое действие разрешено при этом факте. Текст помогает сотруднику сообщить результат понятными словами.
Такое разделение облегчает проверку. Менеджер сверяет статус с карточкой, условие с регламентом, формулировку с задачей разговора. Если текст звучит убедительно, а источник содержит другое значение, исправлять нужно всю цепочку до получения согласованного результата.
В проекте marketAI публично показана связь заказов, расходов и управленческих показателей. Это пример инженерной работы с источниками и смыслом чисел. Для нового ИИ-сценария точность вывода и пользу действия проверяют отдельно на его собственных данных.
Решите, что подготовить к пилоту
Перед стартом удобно провести короткую проверку готовности. У процесса есть владелец. Выбраны источники для конкретного действия. Сотрудник может объяснить правильный результат. Команда умеет связать записи и показать источник ответа. Права участников описаны. Порядок обновления согласован.
Если часть пунктов требует работы, внесите ее в план подготовки. Например, сначала утвердить словарь статусов, затем настроить передачу выбранных полей и только потом сравнивать ответы модели. Это последовательность работ по выбранному участку, которую можно оценить по срокам и результатам.
Выделите три набора примеров: для знакомства команды с задачей, для настройки решения и для итоговой проверки. Состав каждого набора зафиксируйте. При прогнозировании по истории дополнительно определите момент, на который были доступны сведения. Это помогает сохранить честные условия сравнения.
Что передать разработчику
Подготовьте заполненную матрицу, словарь нескольких важных полей, разрешенные примеры и список вопросов к владельцам источников. Добавьте описание доступа и обновлений. По такому комплекту можно обсуждать состав интеграций и пилота.
Разработка ИИ-системы начинается с выбранного действия и проверяемого результата. Если сначала требуется связать источники, обсудите интеграции. Если данные появляются в ручном процессе, полезно рассмотреть автоматизацию этого участка. В первом сообщении перечислите источники и опишите результат, который нужен сотруднику.