Первый набор операционных данных для ИИ: начните с заявок

Почему команды выбирают неправильные стартовые данные

Команды часто начинают с самого шумного куска работы, а не с самого чистого. Они смотрят на огромный почтовый ящик, годы логов чата или общий inbox и думают: "У нас уже тонны данных. Давайте их использовать." Звучит практично. В большинстве случаев это тормозит первый AI‑пилот.

Ошибка проста. Люди путают объём с полезностью. Гигантский архив грязной истории кажется безопаснее, чем небольшой набор чистых тикетов или форм. Он выглядит полнее. Он кажется реальным. Но ИИ работает лучше, когда задача приходит в согласованной форме, с одними и теми же полями, одним и тем же намерением и ясным результатом.

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

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

Меньший, чище рабочий поток обычно выигрывает. Хорошим примером служит служба поддержки ИТ. Если тикеты уже имеют категории, приоритет, тип запроса и заметку о решении, у модели есть реальный шанс выучить паттерны, которые сработают в ежедневной работе. Это важнее, чем большой архив.

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

Какие данные подходят в качестве старта

Хорошие стартовые данные выглядят немного скучно — и в этом их смысл. Лучший первый набор уже следует шаблону, так что модель видит одну и ту же структуру снова и снова, а не догадывается, что означает каждая запись.

Тикеты, формы и структурированные запросы обычно хорошо работают, потому что каждая запись запрашивает одни и те же детали. Кто‑то пишет понятнее, кто‑то — хуже, но поля остаются стабильными. Это даёт более чистые входы и более предсказуемые выходы.

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

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

Ясные завершения важны так же, как и чистые начала. У запроса должна быть очевидная финишная черта, например «аккаунт создан», «счёт одобрен» или «баг исправлен и закрыт». Если «готово» означает разное для каждого человека, модели не на чём учиться.

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

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

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

Хорошие места для старта

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

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

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

Интент‑формы в HR, финансах и ИТ — ещё один безопасный выбор. Запросы на приём на работу, согласования расходов и формы доступа к ПО уже собирают факты в одном и том же порядке. Формы передачи сделок от продаж тоже подойдут, если в них есть стандартные поля: размер компании, стадия сделки, интересующий продукт и обещанная дата поставки. Очереди согласований обычно ещё проще, потому что результат один из нескольких: утвердить, отклонить или попросить изменения.

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

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

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

Чего стоит избегать вначале

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

Длинные почтовые цепочки выглядят привлекательно из‑за количества. На практике с ними трудно работать. Ответы цитируют старый текст, люди меняют тему посередине, а пересланные сообщения вносят лишний контекст, не относящийся к реальному запросу.

Общие inbox’ы создают похожую проблему. Десять человек отвечают в десяти разных стилях и редко заполняют одни и те же детали. Кто‑то пишет полный обзор, кто‑то — две строчки, кто‑то забывает номер заказа или дедлайн. Это усложняет обучение, тегирование и автоматизацию.

Логи чатов часто ещё хуже. Команды используют сокращения, внутренние шутки и недописанные мысли. Кто‑то пишет «готово» или «проверьте», и всем в канале понятно, что это значит в тот день. Модель обычно не поймёт.

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

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

Простое правило: избегайте данных, которые каждый раз нужно объяснять руками. Если кому‑то приходится говорить «эта строка значила одно в марте и другое в апреле», отложите её.

Это частая картина в небольших командах. Хочется стартовать с самого шумного источника, потому что он кажется полным. Лучше начать с меньшего и чище — например, с сервисных тикетов с фиксированными полями или форм, где одни и те же вопросы задаются каждый раз. Результаты обычно приходят быстрее, и следующий шаг становится намного проще.

Как выбрать первый набор данных

Начните с работы, которую команда повторяет каждую неделю. Выберите три рутинных процесса, не десять. Хорошие кандидаты: запросы на доступ, тикеты поддержки с стандартными категориями и простые формы. Обходите редкие, политические или полные переписки случаи.

Потом оцените каждый процесс тремя простыми вопросами:

• Как часто он происходит?
• Подают ли его примерно одинаково каждый раз?
• Можно ли без споров понять, был ли результат правильным?

Достаточна простая шкала от 1 до 5. Побеждает чаще не самый большой процесс, а тот, у которого есть объём, стабильные входы и ясный финиш.

Выбирайте самый маленький вариант с самыми чистыми входами. Это часто даёт самый быстрый пилот, потому что не придётся неделями чистить данные. Команды застревают, если начинают с запутанных inbox’ов. Почта выглядит полезной, но скрывает недостающие детали, боковые разговоры и слишком много исключений.

Перед тестом вытяните 50–200 недавних примеров и просмотрите их вручную. Читайте как скептичный оператор, а не менеджер в поисках хороших новостей. Ищите дубликаты, полузаполненные запросы, смешанные категории и случаи, где разные сотрудники решали одну и ту же проблему по‑разному.

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

Удалите персональные данные, которые не нужны, до любого испытания. Имена, номера телефонов, подписи в письмах и длинная история переписки часто добавляют риски, не помогая модели. Оставьте только поля, нужные для классификации, маршрутизации, суммаризации или подготовки ответа.

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

Простой пример из IT‑команды

IT‑команда хочет быстрый пилот, поэтому начинает с запросов на ноутбук, а не с общего почтового ящика. Это звучит скучно, но скучное — полезно. Команда регулярно получает один и тот же тип запроса, и каждый запрос проходит через одну форму.

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

Команда ставит модели две простые задачи. Во‑первых, сортировать запросы по простым группам: «готово к одобрению», «не хватает бюджета» или «нужно согласование менеджера». Во‑вторых, готовить короткую заметку‑одобрение для ИТ‑лида или менеджера по финансам.

Один запрос может выглядеть так: дизайнер просит MacBook Pro, указывает бюджет $2,300, называет менеджера и пишет, что нуждается в устройстве до даты начала работы на следующей неделе. Модель проверяет полноту формы, отмечает повышенную цену и готовит заметку: запрос полон, дедлайн близок, нужно одобрение менеджера перед покупкой.

Команда оставляет общий почтовый ящик в покое. Там перемешаны вопросы по покупкам, обновления по доставке, случайные дописки и недостающие детали. Люди отвечают не по порядку, пересылают старые сообщения и меняют тему — такой беспорядок тормозит пилот и увеличивает вероятность ошибок.

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

Ошибки, замедляющие первый пилот

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

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

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

Само по себе качество данных может тихо разрушить тест. Недостающие поля, дубликаты и старые тикеты с большим количеством скопированного текста делают выходы менее полезными. Если двадцать тикетов содержат только «помогите» и ничего больше, модель не сможет их осмысленно сортировать. Если один и тот же запрос появляется трижды под разными ID, ваши метрики теряют смысл.

Слишком мало данных — другая проблема. Команды иногда тестируют на 20–30 записях и ждут чётких паттернов. Этого редко достаточно, особенно если запросы сильно разнятся. Вам не нужен гигантский склад данных, но нужно достаточно примеров, чтобы увидеть повторы, крайние случаи и распространённые ошибки.

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

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

Быстрые проверки перед стартом

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

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

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

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

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

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

Что делать дальше

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

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

Дальше соберите небольшую выборку недавних запросов в одном месте. 30–50 примеров обычно достаточно для первого обзора. Просмотрите их сами и ищите пустые поля, дубликаты, смешанные категории и запросы, пришедшие по почте вместо формы. Этот быстрый просмотр скажет, готовы ли данные или ещё слишком грязные.

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

Небольшая IT‑команда хорошо иллюстрирует мысль. Если она начинает с запросов на доступ через одну форму, можно проверить, посылает ли ИИ тикеты нужному владельцу. Если начинать с шести месяцев смешанных почтовых цепочек, большую часть времени съест очистка текста, а не тестирование пилота.

Если хотите практическое второе мнение, Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями как Fractional CTO и консультант. Он помогает выбирать разумные AI‑воркфлоу, наводить порядок вокруг них и не тратить время на неправильные стартовые данные.