AI-бот поддержки в Make: база знаний, LLM и передача оператору через API

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

Ключевая задача здесь — не дать языковой модели придумывать факты о тарифах, заказах, гарантиях или правилах компании. Make удобно использовать как оркестратор: он связывает канал общения, поиск по базе знаний, LLM, CRM/helpdesk и служебные уведомления, а бизнес-правила остаются проверяемыми.

Какие задачи решает AI-бот поддержки в Make

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

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

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

Рабочая схема: webhook → база знаний → LLM → ответ или оператор

Make обрабатывает webhook-события как instant trigger и по умолчанию может выполнять их параллельно. Если порядок сообщений критичен, в настройках сценария есть режим Process data in order. Это важно для диалога: два быстрых сообщения пользователя не должны случайно поменяться местами. Подробнее — в официальных настройках сценария Make.

База знаний должна быть источником фактов, а не частью prompt вручную

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

База знаний может находиться в CMS, helpdesk, собственной БД, поисковом сервисе или vector store. Например, OpenAI описывает vector stores как механизм семантического поиска для Retrieval API и инструмента file search. Важно не конкретное хранилище, а разделение процесса на два шага: найти подтверждённый контекст и только потом сформировать ответ. Официальная справка: OpenAI Vector Stores.

Для коммерческого бота у каждого фрагмента желательно хранить метаданные: документ, раздел, язык, дату обновления, тип клиента или продукта. Тогда Make сможет отсеять неподходящие материалы ещё до обращения к LLM.

Что передавать модели

Prompt лучше собирать из отдельных логических частей:

• роль и ограничения бота;
• текст текущего обращения;
• найденный контекст из базы знаний;
• необходимые данные из CRM/API;
• формат ответа, который должен вернуть AI;
• правила эскалации оператору.

Не стоит помещать в prompt API-ключи, служебные токены, пароли или данные, которые не нужны для конкретного ответа. Если боту требуется статус заказа, передавайте минимально необходимый результат API, а не весь объект клиента.

Пример полезного контракта между LLM и Make:

{
  "answer": "Текст ответа клиенту",
  "needs_human": false,
  "reason": "knowledge_base_match",
  "topic": "delivery",
  "source_ids": ["shipping-terms"]
}

Такой формат удобнее свободного текста: Make может проверить needs_human, разрешённые значения topic и наличие источника до отправки сообщения. Для API OpenAI предпочтителен структурированный вывод по JSON Schema, когда выбранная модель его поддерживает.

Подключение OpenAI или другой LLM в Make

В Make есть официальное приложение OpenAI с модулями для текстовых запросов, файлов, Responses и других операций. Для нестандартного endpoint можно использовать HTTP-модуль и вызвать API напрямую. Это позволяет не привязывать архитектуру бота к одному конкретному AI-провайдеру.

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

Внешние API: где AI заканчивается и начинается бизнес-логика

База знаний отвечает на справочные вопросы, но поддержке часто нужны актуальные данные: статус заказа, баланс, запись на услугу, доступность товара, состояние заявки. Такие сведения следует получать из исходной системы через API, а не просить модель «вспомнить» их.

Практический порядок выглядит так:

1. LLM или обычные правила определяют тип запроса.
2. Make проверяет, какие поля нужны для этого запроса.
3. При необходимости сценарий просит клиента уточнить номер заказа или другой идентификатор.
4. Make обращается к внешнему API с технической авторизацией.
5. Ответ API валидируется.
6. В LLM передаётся только та часть результата, которая нужна для понятного ответа человеку.

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

Когда бот обязан передать диалог оператору

Human handoff — не аварийная кнопка, а штатная ветка сценария. Условия эскалации лучше определить заранее, а не оставлять решение на усмотрение модели.

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

Webhook и порядок сообщений

Если канал поддерживает webhooks, это обычно удобнее постоянного опроса API. Например, Telegram Bot API позволяет настроить HTTPS webhook для получения обновлений и передавать secret_token; тогда Telegram добавляет заголовок X-Telegram-Bot-Api-Secret-Token, который можно использовать для проверки источника запроса. Официальная документация: Telegram Bot API — setWebhook.

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

Как не потерять обращение при сбое

Внешний API может временно вернуть rate limit, connection error или другой сбой. Поэтому production-сценарий должен иметь понятное поведение не только на «зелёной» ветке.

• включить хранение incomplete executions там, где потеря обращения недопустима;
• использовать retry для временных ошибок, а не для некорректных данных;
• отделить технический сбой от бизнес-ошибки;
• уведомлять ответственного, если автоматическое восстановление не помогло;
• не отправлять клиенту успешный ответ до подтверждения критичной операции внешней системой.

Make документирует incomplete executions и Retry error handler как штатные механизмы восстановления. См. Retry error handler и Scenario settings.

Контекст диалога без бесконечной истории

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

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

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

Безопасность и персональные данные

Чат поддержки почти всегда содержит пользовательские данные. Поэтому в Make имеет смысл заранее решить, что действительно нужно сохранять в истории выполнения. В настройках сценария есть опция Keep data confidential: при её включении Make не сохраняет обработанный payload в execution logs, хотя это ограничивает возможности последующей диагностики. Выбор зависит от процесса и требований к данным.

API-ключи следует хранить в connections или другом защищённом механизме, а не в текстовых полях prompt. Для webhook вход должен иметь проверяемый секрет или подпись, если исходный сервис это поддерживает. Доступ к CRM/API лучше выдавать с минимально необходимыми правами.

Практический план внедрения

Когда Make достаточно, а когда нужен отдельный backend

Make хорошо подходит, когда бот связывает несколько SaaS-сервисов, нагрузка предсказуема, а сценарий удобно поддерживать визуально. Для сайта, Telegram, CRM, helpdesk и AI API это часто позволяет быстро собрать рабочую интеграцию.

Отдельный backend становится полезнее, если требуется большой собственный retrieval-контур, сложная авторизация, высокая параллельность, низкая задержка в реальном времени, длинные транзакции или много внутреннего состояния. При этом Make можно оставить для уведомлений, CRM, документов и вторичных автоматизаций.

Если уже есть сайт или CRM и нужно понять, где провести эту границу, можно начать с карты процесса. На A.S Groups есть отдельные страницы про автоматизацию бизнес-процессов, AI-автоматизацию бизнеса и интеграцию WordPress с API.

Частые ошибки

• Отвечать без источника. Модель знает общий интернет-контекст, но не обязана знать актуальные правила вашей компании.
• Смешивать справку и изменение данных. Ответ на FAQ и возврат денег не должны иметь одинаковый уровень доступа.
• Не учитывать повтор webhook. Это приводит к дублям тикетов и сообщений.
• Не проектировать handoff. Тогда оператор получает клиента слишком поздно или вообще без контекста.
• Хранить секреты в prompt. Модель не должна видеть то, что не требуется для ответа.
• Отправлять всю историю диалога бесконечно. Лучше хранить состояние отдельно и передавать только нужный контекст.

FAQ

Официальные источники

• Make — Scenario settings
• Make — Retry error handler
• Make — OpenAI app documentation
• OpenAI — Vector Stores API
• Telegram Bot API — setWebhook

Что прислать для оценки

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

Написать A.S Groups — можно прислать текущую схему процесса или просто несколько типовых обращений клиентов.