AiHummer 
Тендеры и лиды
Информация
Подключить языковую модель к CRM, базе знаний или таск-трекеру несложно. Сложнее добиться, чтобы система стабильно работала на реальных, неоднозначных и иногда опасных запросах.
Пилот доказывает техническую возможность. Для эксплуатации нужны владелец процесса, метрики, ограничения полномочий, тесты, мониторинг и сценарий отказа. Без них получается «вечный пилот»: на презентации всё работает, но бизнес не готов передать агенту реальную операцию.
Формулировка «хотим ИИ-агента для отдела продаж» слишком широка: у квалификации лидов, заполнения CRM и подготовки писем разные данные, цена ошибки и критерии качества.
Для первого запуска лучше выбрать операцию, в которой:
· есть повторяемый вход: письмо, заявка, стенограмма звонка, карточка задачи;
· результат можно проверить: заполненная карточка, проект ответа, созданная задача;
· есть сотрудник, который контролирует работу, и реальные примеры;
· цена одной неправильной рекомендации ограничена;
· эффект проявляется за недели, а не за год.
Хорошая постановка звучит так: «После входящего обращения агент определяет тему, извлекает реквизиты, создаёт черновик сделки и предлагает следующий шаг менеджеру». Плохая — «автоматизировать продажи с помощью ИИ».
Нужен и владелец процесса со стороны бизнеса: он решает спорные случаи, предоставляет примеры и подтверждает эффект. Без него подрядчик будет улучшать промпт, не понимая, меняется ли бизнес-результат.
До пилота измерьте текущий процесс, иначе эффект будет не отличить от впечатления. Нужны четыре группы показателей.
Бизнес-метрики: время и стоимость обработки, соблюдение срока, конверсия, возвраты на доработку.
Качество: доля корректных результатов, полнота полей, необоснованные утверждения, критические ошибки.
Эксплуатация: время ответа, доступность, стоимость завершённого сценария, ручные вмешательства.
Безопасность: недоступные действия, раскрытие лишних данных, операции без обязательного подтверждения.
Не сводите приёмку к фразе «ответы выглядят хорошо». Заранее согласуйте тестовый набор и пороги: например, долю черновиков, принятых без существенной правки, максимальное время обработки и запрет отправки без подтверждения. Цифры зависят от процесса, но критерии должны появиться до разработки.
Полезный одностраничный документ — паспорт сценария. В нём должны быть: вход, ожидаемый результат, источники данных, разрешённые действия, запреты, ответственный сотрудник, метрики, тестовый набор и условия остановки.
Не давайте системе права сотрудника целиком. Модель может неверно понять инструкцию или получить вредоносную команду из документа. OWASP относит к ключевым рискам LLM-приложений prompt injection, раскрытие чувствительной информации, небезопасную обработку вывода и избыточную автономность.
Практичнее повышать полномочия поэтапно:
1. Чтение. Агент ищет сведения и показывает источники, но ничего не меняет.
2. Черновик. Готовит письмо, задачу или запись в CRM; сотрудник проверяет и отправляет.
3. Действие с подтверждением. Агент формирует операцию, но выполнение требует явного согласия пользователя.
4. Ограниченная автономность. Самостоятельно выполняет только низкорисковые, обратимые действия в заданных пределах.
Для каждого инструмента задайте минимальные права, лимиты и допустимые объекты. Агенту, создающему задачи в одном проекте, не нужен доступ на изменение всех проектов.
Базовая защита: отдельная техническая учётная запись, роли, журнал вызовов, проверка структурированного вывода, лимиты действий и стоимости, тайм-ауты и защита от дублей. Остановку и возврат к прежнему процессу проектируют до запуска.
Подключение базы знаний не означает готовность данных. Регламенты могут противоречить друг другу, а исключения — жить только в переписке менеджера. Агент масштабирует эту неопределённость.
Перед разработкой определите:
· какие источники считаются авторитетными;
· кто отвечает за их актуальность;
· какие документы нельзя использовать и как разделены права;
· должен ли ответ содержать ссылку на источник;
· что делать, если источники расходятся или ответа нет.
В RAG-сценарии проверяйте и поиск: найден ли нужный документ, доступен ли он пользователю, актуальна ли версия. Если основания недостаточно, агент должен запросить уточнение или передать случай человеку, а не додумывать.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13801 тендер
проведено за восемь лет работы нашего сайта.
Оценивать агента на примерах из настройки нельзя. Нужен отдельный набор реальных сценариев.
Включите в него:
· типовые обращения;
· короткие, неполные и противоречивые запросы;
· редкие, но важные исключения;
· устаревшие документы и попытки получить закрытые данные;
· сбои интеграций, дубли и повторную отправку;
· случаи, в которых правильный результат — отказ или передача человеку.
Для каждого примера задайте ожидаемое поведение. Формат, обязательные поля и допустимость вызванного инструмента можно проверять автоматически; смысл и спорные решения на старте оценивают профильные сотрудники. Ошибки классифицируют по тяжести.
Версионируйте модель, инструкции, инструменты, базу знаний и тесты. Так можно найти причину ухудшения и вернуть рабочую конфигурацию.
Первый режим — теневой: агент параллельно обрабатывает реальные данные, но не влияет на клиента или учётную систему. Команда сравнивает решения и уточняет правила.
Затем — один отдел, один тип запроса или небольшая доля потока. Значимые действия подтверждает сотрудник. Охват расширяют после прохождения порогов на реальном трафике.
Считайте не только точность. Если проверка черновика занимает столько же времени, сколько ручная работа, эффекта нет. Отдельно измеряйте стоимость завершённого кейса и причины, по которым пользователи обходят систему.
Промышленный агент — сервис с владельцем, поддержкой и регламентом изменений. NIST предлагает управлять рисками ИИ на всём жизненном цикле через функции govern, map, measure и manage. Практики эксплуатации ML-систем требуют отслеживать реальные метрики и версии, а обновления сначала направлять на часть запросов.
Минимальный эксплуатационный контур включает:
· журнал входов, источников, решений и вызванных инструментов;
· метрики качества, задержки, ошибок интеграций и стоимости;
· алерты по критическим событиям и аномальному росту отказов;
· очередь случаев для ручной проверки;
· версионирование и контролируемое развёртывание изменений;
· план отката и ручной резервный процесс;
· ответственных за инциденты и регулярную повторную оценку.
Определите, какие данные сохраняются в логах, кто их видит, как долго они нужны и как из них удаляются секреты и персональные сведения.
Заказчик отвечает за владельца процесса, доступ к экспертам и данным, актуальность регламентов, допустимый риск, пользователей пилота и решение о переходе в эксплуатацию.
Подрядчик отвечает за архитектуру, интеграции, тестирование, технические ограничения, наблюдаемость, документацию и устранение дефектов в согласованном объёме.
Совместно стороны утверждают метрики, тесты, классификацию ошибок, эскалации и результат пилота.
В задании отделите результаты обследования, пилота и промышленного запуска. Иначе заказчик поймёт «работающего агента» как автономного сотрудника, а подрядчик — как прототип на подготовленных примерах.
1. Процесс готов: есть владелец, границы, базовые показатели и резервный ручной маршрут.
2. Качество готово: агент прошёл согласованный набор, а критические ошибки укладываются в допустимый уровень.
3. Безопасность готова: права минимальны, значимые действия подтверждаются, атаки и ошибки интеграций проверены, все операции журналируются.
4. Эксплуатация готова: настроены метрики и алерты, назначена поддержка, описаны обновление и откат, понятна стоимость одного кейса.
Закрытый шлюз — не провал, а список работ до следующего решения о запуске.
· Выбрана одна операция, а не целый отдел.
· Назначены владелец процесса и эксперты.
· Зафиксированы исходные бизнес-показатели.
· Согласованы метрики, тестовый набор и критерии остановки.
· Описаны источники данных и ответственные за их актуальность.
· Права минимальны; опасные действия подтверждает человек.
· Проверены негативные сценарии и сбои интеграций.
· Есть теневой режим и план расширения.
· Настроены логи, мониторинг, поддержка и откат.
· Известна полная стоимость завершённой операции.
· Результат пилота можно сравнить с прежним процессом.
ИИ-агент становится промышленным не после первого правильного ответа, а когда компания умеет измерять его работу, ограничивать полномочия, разбирать ошибки и безопасно переживать изменения. В AiHummer мы используем тот же порядок: формализуем процесс, подключаем данные и инструменты и только после измеряемого пилота расширяем автономность.
