Разработка нейросеть агентов: шпаргалка ТЗ для магазина
Разработка нейросеть агентов начинается с техзадания. Шесть разделов ТЗ на агента для чата интернет-магазина, список запретов и план проверки из LibraChat.
Д
Денис
Продакт LibraChat
7 мин чтения
Техзадание на агента для чата интернет-магазина, шесть разделов, полторы страницы. Я получил его в LibraChat одним запросом и почти не правил. Разработка нейросеть агентов чаще всего проваливается не на коде, а раньше: заказчик не может объяснить, что агент делает, а чего не делает никогда. Ниже шпаргалка для того, кто заказывает такого агента или делает его сам: запрос, шесть разделов ТЗ с примерами строк, список запретов и план проверки перед запуском.
Что такое разработка нейросеть агентов, если без теории
Агент для магазина — программа, которая отвечает покупателю в чате на сайте, сама смотрит данные заказа и решает, справится ли она или надо звать человека. Разработка такого агента — это три части: правила поведения, подключение к данным и проверка.
Код пишет программист. Правила поведения пишет заказчик. На этом месте всё и ломается: правила живут в голове у владельца магазина, а программист их угадывает.
Я продакт и такие ТЗ пишу регулярно. Раньше я тратил на первую версию целый день. Теперь начинаю с черновика из LibraChat и трачу час на правку под конкретный магазин.
Запрос, с которого начинается разработка нейросеть агентов
Составь техзадание на разработку ИИ-агента для небольшого интернет-магазина: агент отвечает покупателям в чате на сайте о статусе заказа, сроках доставки и возврате, а сложные вопросы передаёт менеджеру. Разделы: цель, что агент делает, откуда берёт данные, когда передаёт человеку, чего не делает никогда, как проверить качество перед запуском. Коротко, по пунктам.
Разделы я перечислил сам. Это важно. Если попросить просто «составь ТЗ», получишь документ по шаблону, а в шаблоне часто нет главного для агента: раздела о запретах и раздела о передаче человеку.
Шесть разделов ТЗ: шпаргалка
Раздел · На какой вопрос отвечает · Строка из ответа LibraChat
Цель — зачем агент вообще нужен — снять с менеджеров типовые вопросы, отвечать без выдуманных фактов
Что делает — его обязанности — если данных мало, просит номер заказа и контакт из заказа
Откуда данные — на что он опирается — ответ строится только по найденной записи
Когда передаёт человеку — граница его работы — жалоба, брак, не тот товар, спор по сумме
Чего не делает никогда — запреты — не обещает точную дату, если её нет в треке
Проверка — как понять, что можно запускать — 30–40 тестовых диалогов с заранее записанным верным ответом
Цель в ответе сформулирована так, что её можно проверить: «Сложное и спорное сразу уходит человеку вместе с кратким резюме диалога». Последние слова я сам бы забыл. А менеджеру, который подхватывает разговор, резюме экономит минуту на каждом обращении.
Самая важная строка в разделе о данных
Ответ строится только по найденной записи. Нет записи или сервис не ответил — агент не достраивает статус сам.
Эту фразу я теперь вставляю в каждое ТЗ на агента. Она короткая, её легко проверить на тесте, и программисту не нужно гадать, что делать при сбое внешнего сервиса: ответ один, честное «не вижу данных, передаю менеджеру». Самая неприятная ошибка агента в магазине — уверенный ответ «ваш заказ в пути», когда сервис доставки просто не ответил. Покупатель ждёт, заказа нет, и виноват магазин.
Когда агент зовёт человека
Список из ответа почти без правок пошёл в моё ТЗ:
заказ не найден или контакты не совпадают после одного уточнения;
жалоба, брак, не тот товар, требование компенсации;
возврат денег уже идёт, двойное списание, ошибка оплаты;
просьба изменить адрес или отменить заказ после отправки;
покупатель прямо просит менеджера;
похоже, что спрашивают чужой заказ.
Про двойное списание в ответе есть точная деталь: агент статус видит, но решение не принимает. Это и есть граница. Видеть можно, решать нельзя.
Чего агент не делает никогда: чек-лист запретов
Запреты я проверяю по одному, вслух, как будто я покупатель, который хочет обмануть агента. Вот они, из того же ответа:
Не обещает точную дату доставки, если её нет в треке или правилах.
Не меняет заказ, не проводит возврат денег, не выдаёт скидки и промокоды.
Не называет данные других покупателей, закупочные цены и внутренние пометки.
Не просит пароль, полный номер карты и код с обратной стороны.
Не подтверждает заказ только по имени, без номера и контакта из заказа.
Не спорит и не удерживает, если человек просит менеджера.
Пятый пункт защищает от самого частого способа узнать чужие данные: «Подскажите, что там с заказом Ивановой?» Шестой защищает репутацию. Ничто так не злит покупателя, как бот, который не отпускает к живому человеку.
Разработка нейросеть агентов: проверка перед запуском
Этот раздел заказчики пропускают чаще всего. А он решает, будет ли агент работать на третий день после запуска. В ответе план такой: собрать 30–40 тестовых диалогов на все случаи, от оплаченного заказа до попытки узнать чужой, для каждого заранее записать верный ответ и нужное действие, прогнать на тестовых данных, а не на настоящих покупателях.
Критерий годности сформулирован жёстко, и мне это нравится: ответ годен, только если статус верный, срок не выдуман, передача человеку сработала вовремя и чужие данные не прозвучали. Дальше неделя пилота, где менеджер смотрит все передачи и выборку ответов.
Сколько это стоит по времени. На 30 тестовых диалогов у меня уходит около 3 часов: написать вопросы, записать верные ответы, прогнать, разобрать. Это кажется долгим, пока не сравнишь с неделей разбора жалоб после неудачного запуска.
Сам я добавляю к этому одно правило. Половину тестовых диалогов пишет не тот, кто писал ТЗ. Автор правил подсознательно проверяет то, что он предусмотрел. Посторонний человек проверяет то, что будет на самом деле.
Как я правлю черновик под конкретный магазин
Черновик хорош, но он общий. Под конкретный магазин я проверил его по трём вопросам, и каждый раз что-то добавлял.
Первый вопрос: какие вопросы покупатели задают на самом деле. Я попробовал выгрузить переписку менеджеров за месяц и разложить её по темам. В одном магазине одежды треть обращений оказалась про размеры, а не про доставку. В ТЗ такого раздела не было вовсе. Пришлось дописать.
Второй вопрос: где в магазине лежат правила. Срок возврата, исключения, регионы доставки часто записаны не в одном документе, а в трёх, и они противоречат друг другу. Агенту нельзя давать три версии правды. Прежде чем отдавать ТЗ программисту, я сделал с владельцем одну короткую базу знаний.
Третий вопрос: кто отвечает, когда агент передал разговор. Ночью менеджера нет. Значит, в ТЗ должно быть сказано, что агент говорит покупателю в 23:00: «Менеджер ответит утром», а не «Сейчас подключится человек». Я столкнулся с этим на первом же запуске и с тех пор проверяю это в каждом ТЗ.
Где здесь LibraChat, кроме черновика ТЗ
Черновик техзадания — это обычный чат. Если же ты разработчик и хочешь, чтобы агент в магазине отвечал с помощью моделей LibraChat, для этого есть доступ по API. Ключи выпускаются в «Консоли API», а платишь с отдельного предоплаченного баланса, не по подписке. Цена на сайте — 450 рублей за миллион токенов. Токены запроса считаются вместе с токенами ответа. Формат совместим с привычными библиотеками, обычно хватает указать ключ и адрес сервиса.
Что остаётся за командой: подключение к учёту заказов и трекингу, интерфейс чата на сайте, логи. И сама проверка. API даёт ответы модели, а правила с данными остаются у магазина, как и ответственность за результат.
Если нужно объяснить коллегам, чем агент отличается от обычного чат-бота, пригодится статья что такое нейросеть-агент.
Один шаг, чтобы начать
Открой чат LibraChat и попробуй тот же запрос, заменив магазин на свой бизнес, а вопросы о заказах на свои типовые вопросы. Перечисли все шесть разделов, особенно последние два. Потом распечатай раздел запретов и попробуй обмануть своего будущего агента вслух. Те запреты, которые выдержали, и есть рабочее ТЗ.
