Малый бизнес, большие возможности: Как использовать ИИ для роста без лишних затрат

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

Пилот начинается не с модели

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

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

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

Поэтому первым объектом проверки становится не то, «насколько умно отвечает сервис», а граница самого сценария:

что именно получает ИИ;

что он должен вернуть;

какие сведения ему запрещено додумывать;

кто проверяет результат;

сколько времени занимает вся операция;

при каком результате эксперимент прекращается.

Если на эти вопросы нет коротких ответов, запускать пилот рано. Сначала задачу нужно уменьшить.

Паспорт пилота

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

Заполните паспорт до того, как начнёте сравнивать модели.

Задача

Опишите действие одним глаголом и одним объектом. Подойдут формулировки «классифицировать обращение», «извлечь поля из заявки», «сделать краткое резюме», «подготовить черновик ответа». Не подойдут «использовать ИИ для работы с клиентами» и «улучшить коммуникацию».

Вход

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

Ожидаемый выход

Опишите результат так, чтобы его можно было принять или отклонить. Например: «категория обращения, список недостающих сведений, черновик ответа до 800 знаков, отметка о неуверенности». Формулировка «готовый хороший ответ» для пилота слишком расплывчата.

Срок

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

Проверяющий

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

Метрики

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

Условие остановки

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

Паспорт интернет-магазина может выглядеть так.

Задача: подготовить черновик ответа на входящее обращение и определить тип запроса.

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

Ожидаемый выход: тип запроса; факты, найденные во входе; недостающие сведения; черновик ответа; предупреждение, если вопрос нельзя решить по переданным материалам.

Срок: 90 минут на подготовку, 72 часа на пилот, не менее 15 обращений.

Проверяющий: сотрудник, который утверждает ответы клиентам.

Метрики: время от получения обращения до готового проверенного текста; оценка по пяти критериям; число исправлений; критические ошибки; доля ответов, которые можно отправить после короткой проверки.

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

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

Девяносто минут до первого решения

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

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

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

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

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

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

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

Контрольная выборка важнее красивой демонстрации

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

Для первого прогона достаточно 10–20 случаев. Включите четыре-пять обычных примеров, составляющих основной поток, два-три коротких и простых обращения, два случая с неполными данными, два примера с противоречиями или необычной формулировкой и один-два случая, в которых ошибка будет критичной.

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

Обезличивание не сводится к простой замене имени словом «клиент». Проверьте телефоны, электронные адреса, номера заказов, адреса доставки, паспортные данные, реквизиты, ссылки, фотографии и сочетания сведений, по которым человека можно узнать. Если содержание всё равно позволяет восстановить личность, считайте его чувствительным. Для первого теста заменяйте такие фрагменты единообразными обозначениями: «ИМЯ_КЛИЕНТА», «НОМЕР_ЗАКАЗА», «АДРЕС_ДОСТАВКИ». При этом сохраняйте свойства задачи: длину текста, наличие ошибок, последовательность сообщений и противоречия.

До загрузки рабочих данных проверьте, кто имеет право пользоваться выбранной учётной записью и где сохраняется история запросов. Для персональных данных учитывайте внутренние правила компании и требования Федерального закона № 152-ФЗ. Если в организации установлен режим коммерческой тайны, не отправляйте документы в сервис до проверки условий обработки и доступа. Личная учётная запись сотрудника не должна автоматически превращаться в рабочее хранилище клиентских материалов.

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

Если первый слой дал хороший результат, это ещё не разрешает переходить к третьему.

GigaChat и YandexGPT: сравнивать нужно не названия, а пригодность

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

До загрузки даже обезличенной рабочей выборки проверьте несколько вещей.

Уточните, какой объём текста можно передать за один запрос и какой объём ответа доступен. Проверьте ограничения по числу запросов, скорости работы и размеру файлов. Разберитесь, какие функции входят в бесплатный или недорогой тариф, а какие доступны только в других вариантах.

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

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

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

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

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

Одинаковый протокол защищает от самообмана

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

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

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

Задача: подготовить черновик ответа на входящее обращение.

Используемые источники: только текст обращения и переданные условия доставки и возврата.

Порядок результата: тип обращения; факты из входных данных; недостающие сведения; черновик ответа; предупреждения для проверяющего.

Ограничения: не добавляй сведения, которых нет во входе; не придумывай статус заказа, срок, стоимость или право на компенсацию; если данных не хватает, напиши «НЕТ ДАННЫХ»; отделяй факты от предположений; не отправляй сообщение от имени компании.

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

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

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

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

Демонстрационный ответ против рабочего материала

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

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

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

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

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

Как измерять время и качество

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

Если модель выдаёт ответ за 20 секунд, но сотрудник тратит ещё семь минут на поиск ошибок, экономии может не быть.

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

В журнале достаточно следующих полей.

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

Вариант — ручной способ, GigaChat, YandexGPT или другая версия.

Время работы — полный цикл от входа до принятого результата.

Качество — балл по заранее установленным критериям.

Исправления — количество и тип изменений.

Критическая ошибка — да или нет, с кратким описанием.

Решение — принять, доработать или отклонить.

Оценку качества можно проводить по шкале от 0 до 2 для каждого критерия: 0 означает, что критерий нарушен; 1 — что требуется заметная правка; 2 — что результат соответствует требованиям.

Для черновика ответа критериями могут быть точность фактов, полнота, соблюдение условий компании, понятность и отсутствие лишних обещаний. Пять критериев дают максимум 10 баллов. Порог нужно установить до просмотра результатов. Например, результат ниже 8 баллов требует существенной переработки. Но общий балл не отменяет критическую ошибку: неверный срок или выдуманное условие могут остановить результат независимо от суммы.

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

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

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

Три дня полевого теста

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

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

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

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

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

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

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

Порог продолжения задайте заранее. В качестве стартовой планки можно использовать сокращение полного времени хотя бы на 20–30 процентов при сохранении качества и отсутствии критических ошибок. Это не универсальный закон: для дорогой или рискованной операции может потребоваться большая экономия, а для массовой задачи с низкой стоимостью — меньшая. Но без числовой планки решение почти всегда будет зависеть от впечатления.

Сигналы в поле: что они означают и что делать

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

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

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

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

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

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

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