Доступ к чату не создаёт рабочий процесс

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

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

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

Ручная работа или подключение к процессу

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

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

API нужен для программного обращения к модели из другой системы. Через него подрядчик может организовать передачу задания и возвращение ответа в выбранный рабочий процесс; конкретные действия, права и обработку сбоев всё равно предстоит настроить отдельно. Автоматическая отправка результата клиенту — ещё одно самостоятельное решение, которому нужна собственная оценка последствий ошибки.

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

Наглядный разбор

Два способа работы

  1. Сотрудник в чате

    Сам готовит запрос, сверяет ответ и переносит полезное в работу.

  2. Модель через API

    Система передаёт задания по правилам; компания контролирует результат и сбои.

  3. Общее требование

    Назначены разрешённые данные, проверяющий и действие при ошибке.

Сравнение объёма организации, а не обещание функций любого тарифа.

Какие задачи с документами выбрать первыми

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

Размер файла имеет значение. В документации GigaChat API по работе с файлами перечислены DOCX, PDF, PPTX и XLSX. Предел для одного текстового файла в запросе составляет 40 МБ, для изображения — 15 МБ, для аудиофайла — 35 МБ. Это ограничения конкретного API, которые не следует автоматически переносить на пользовательский чат или любое внешнее приложение с похожим названием. Допустимый размер загрузки также не гарантирует, что модель правильно извлечёт каждый реквизит, учтёт примечание к таблице и объединит сведения с разных листов сложного документа так, как это сделал бы ответственный сотрудник.

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

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

Как сравнить модели на собственном материале

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

В руководстве по GigaChat API Сбера модель GigaChat 2 Lite рассчитана на простые задачи, где важна скорость. Pro предназначена для более сложных инструкций, сокращения и редактирования текста, а Max — для задач с повышенными требованиями к качеству. У Cloud.ru свой каталог Foundation Models. Например, в нём есть модели GigaChat с идентификаторами ai-sage/GigaChat3-10B-A1.8B и ai-sage/GigaChat3.5-432B-A28B. Сравнивайте варианты, доступные в кабинете компании, на её собственных документах и формулировках.

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

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

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

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

В официальном быстром старте для ИП и юридических лиц Сбер указывает, что с 1 сентября 2026 года новые клиенты и те, кто ранее не покупал пакеты, могут оплачивать работу с моделями на Cloud.ru. В разделе тарифов GigaChat API для юрлиц отдельно поясняется, что приведённые там условия относятся к действующим клиентам указанных поставщиков. Поэтому переносить цену из старой таблицы на новый корпоративный проект без проверки кабинета и договора нельзя, даже если названия моделей выглядят одинаково.

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

Для прямого подключения к GigaChat API Сбер указывает сертификаты НУЦ Минцифры. В инструкции Cloud.ru для Foundation Models подключение начинается с сервисного аккаунта и API-ключа. Попросите исполнителя проверить соединение из той среды, где будет работать интеграция. Общий порядок подключения нового сервиса к сайту поможет описать, кто предоставляет доступы, где проверяется результат и кто восстанавливает работу при отказе внешней системы.

Кто отвечает за данные и достоверность ответа

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

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

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

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

Как считать стоимость полезного результата

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

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

Документация мониторинга потребления GigaChat API описывает «Биллинг» по нескольким проектам и «Статистику использования» по одному проекту в Studio. В обоих случаях доступны фильтр по моделям и выгрузка отчёта XLSX. Для выбранной платформы подключения подтвердите состав доступной отчётности. Расход полезно сопоставлять с количеством принятых результатов, потому что поток повторных неудачных запросов увеличивает потребление, не завершая задачу сотрудника.

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

Карточка пробы для копирования

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

Подключение принимают по полному пути задачи

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

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

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

Источники и полезные ссылки

  1. GigaChat: выбор модели ↗
  2. GigaChat: быстрый старт для ИП и юрлиц ↗
  3. GigaChat API: работа с файлами ↗
  4. GigaChat API: условия для юрлиц ↗
  5. GigaChat API: статистика потребления ↗
  6. Cloud.ru — каталог моделей Foundation Models ↗
  7. Cloud.ru — быстрый старт Foundation Models ↗

Интерфейсы и возможности сервисов могут меняться. Перед настройкой сверяйтесь с актуальной документацией.

Игорь Крещенко

Руководитель ШТАБ ИТ. Занимается управлением проектами, веб-разработкой, рекламой и PR. Подробнее об авторе →