Нейросети для работы с данными: три источника ИИ-агента

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

Где агент берёт данные для ответа

Данные для ответа приходят из четырёх мест, и они устроены по-разному, потому что каждый источник решает свою задачу.

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

Как агент отвечает точной цифрой из таблицы

Таблицы подключаются файлом CSV, файлом Excel или ссылкой на Google-таблицу и обновляются по расписанию: период задаётся в минутах, по умолчанию раз в сутки. Вопрос клиента превращается в запрос к строкам, и в модель уходит только найденное значение, а не весь файл: размер прайса почти не сказывается на стоимости ответа.

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

Когда ответ ищется в базе знаний, а не в таблице

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

Документ режется на смысловые куски и хранится вместе с быстрыми ответами и таблицами в общей базе знаний. Насколько строгим будет отбор нужного куска, задаёт порог поиска — от строгого 0,7 до гибкого 0,3, и от этого порога прямо зависит, найдёт агент ответ или промолчит: этому целиком посвящена статья про порог поиска по базе знаний. Разница с таблицей здесь принципиальная: таблица возвращает строку, база знаний — формулировку, из которой агент собирает ответ своими словами.

Что агент помнит и достаёт из CRM без вопроса клиенту

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

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

Как агент записывает данные обратно

Читать источник и писать в него — разные права, и совпадают они не всегда. Файл CSV или Excel агент только читает: записать строку назад в статичный файл нечем. Подключённая Google-таблица устроена иначе — там отдельными флагами включаются добавление новой строки и правка уже существующей, а находит нужную строку агент по любой колонке с уникальным значением, например по номеру заказа.

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

Соберите один источник правды раньше, чем настраиваете агента

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

Когда источник один и он актуален, у чат-бота и у менеджера в трубке звучит одна и та же цифра — и это дешевле проверить один раз в начале, чем объяснять клиенту разницу после.

Частые вопросы