ИИ-шлюз Beget для сайта и CRM: как подключить модель к рабочему процессу

• ИИ-шлюз и прикладной ИИ

К вопросам по статье

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

Я подключаю ИИ к конкретной операции: сначала определяю, что должен получить сотрудник и как он это проверит, затем выбираю способ подключения. ИИ-шлюз Beget — один из вариантов. В статье разберу предлагаемую схему для входящей заявки: что делает провайдер, что нужно разработать вокруг него и как принять результат. Это проектный пример; измеренного клиентского внедрения именно этой схемы статья не заявляет.

Что даёт шлюз и что остаётся разработчику

Согласно руководству Beget, шлюз принимает запросы Chat Completions по адресу https://api-llm.beget.com/v1. В документации также описаны embeddings и получение списка моделей. Формат Responses API не поддерживается: обращение к нему возвращает 404. Поэтому клиент, работающий через Responses, нельзя считать совместимым только по названию OpenAI-compatible. Перечень моделей и условия оплаты проверяют в текущем каталоге перед подключением.

Для бизнеса важнее следующий вопрос: кто организует работу вокруг этого подключения? Шлюз не знает, какую CRM-карточку разрешено изменить, какое обещание можно дать покупателю и где находится актуальная версия прайс-листа. Эти правила определяет приложение. Ему нужны очередь задач, проверка прав, контроль результата, учёт расходов и понятный экран для человека. Без них получается демонстрация возможностей модели; с ними можно обсуждать рабочий инструмент.

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

С какого сценария начинать

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

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

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

Что записать в требованиях до подключения

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

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

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

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

Архитектура: сайт, обработчик, шлюз, проверка, CRM

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

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

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

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

Контракт ответа важнее красивой формулировки

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

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

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

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

Ошибки и повторы: сохранить заявку и не размножить действия

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

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

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

Расходы считаем по принятому результату

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

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

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

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

Как принимать интеграцию с CRM

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

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

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

На какой опыт я опираюсь

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

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

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

Что получит заказчик после первого этапа

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

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

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

Если нужна помощь с этой задачей

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

Практика по теме: GlossCheck: ИИ-сервис с чатом, файлами и OCR.