В коммерческих предложениях по автоматизации слово «интеллект» встречается чаще, чем описание того, что система будет делать в обычный понедельник в 10 утра. Владельцу это неудобно: невозможно понять, покупает он инструмент, который снимет с людей часть работы, или демонстрацию, которая развалится на второй неделе эксплуатации.
Разница между рабочей системой и демонстрацией проходит не по модели. Модели у всех примерно одинаковые и доступны по API за суммы, сопоставимые с расходами на офисный кофе. Разница в том, что построено вокруг модели: откуда она берёт факты, что делает при неуверенности, кто и как проверяет её работу через месяц после запуска.
Ниже — трезвый разбор по трём корзинам: где языковые модели дают предсказуемый результат, где дают его с оговорками, и где не дадут вообще, сколько бы ни обещал подрядчик. Плюс механика ошибок простыми словами, три способа защиты и реальная стоимость эксплуатации в рублях.
Линию проводит не модель, а цена ошибки
Один и тот же инструмент бывает отличным решением и источником проблем. Отличное: модель вытаскивает из накладной 15 полей, бухгалтер видит подсвеченные сомнительные значения и подтверждает документ за 20 секунд вместо трёх минут ручного ввода. Проблема: та же модель без подтверждения человеком пишет данные прямо в учётную систему, и через месяц вы разбираете двести проводок с перепутанными суммами. Технология одна, разница — кто ловит остаток ошибок и во что обходится пропущенная. Поэтому любую ИИ-задачу имеет смысл прогнать через четыре вопроса до того, как обсуждать бюджет.
- 1Есть ли у правильного ответа источник, на который можно показать пальцем: пункт договора, строка в номенклатуре, статус в CRM. Если источника нет, модель будет строить правдоподобное предположение.
- 2Сколько стоит одна ошибка. Неверно определённая тема обращения стоит минуты работы оператора, неверно распознанный ИНН в платёжке — дня разбирательств, неверный ответ клиенту о сроках поставки — отношений с клиентом.
- 3Есть ли история решений для настройки и проверки. Для классификации обращений нужно 200–300 размеченных примеров на каждую тему, иначе качество измерять не на чем.
- 4Кто принимает результат каждый месяц. Если никто не смотрит выборку из 3–5% ответов, система будет незаметно деградировать: поменяется прайс, регламент, формулировки клиентов — а модель продолжит отвечать по-старому.
Что работает надёжно
Надёжны задачи, где модель не сочиняет, а разбирает уже существующий текст, речь или изображение: раскладывает по категориям, вытаскивает поля, находит нужный фрагмент, переводит звук в буквы. Здесь есть с чем сверяться, качество измеримо на исторических данных, а остаток ошибок закрывается процедурой. Ниже — реалистичные цифры по нашей практике на типовых российских данных: договоры, накладные, обращения в поддержку, записи звонков.
| Задача | Реалистичное качество | Что делаем с остатком |
|---|---|---|
| Классификация обращений по 10–20 темам | 90–96% при 200–300 примерах на тему | низкая уверенность — не угадываем, а отправляем в общую очередь оператору |
| Извлечение полей из счетов, актов, накладных | 95–99% по полю на типовых формах, ниже на плохих сканах | сомнительные поля подсвечены, бухгалтер подтверждает документ за 15–20 секунд |
| Поиск ответа по архиву документов и регламентов | нужный документ находится в 85–95% запросов | в ответе всегда ссылка на источник — сотрудник сам видит, тот ли это документ |
| Распознавание речи в звонках и на планёрках | 5–12% ошибок по словам, хуже на шуме и отраслевых терминах | словарь терминов, фамилий и брендов снижает ошибки примерно вдвое |
| Черновик ответа клиенту по базе знаний | 60–80% черновиков уходят с правкой в одно-два слова | отправляет человек — модель готовит текст, но не нажимает кнопку |
Правый столбец важнее среднего. Точность 95% сама по себе не значит ничего — вопрос в том, отличает ли система свои уверенные ответы от неуверенных. Хорошо настроенная классификация с 92% точности, которая честно отдаёт человеку 8% спорных случаев, полезнее модели с заявленными 97%, которая одинаково твёрдым тоном выдаёт и правильный, и ошибочный ответ.
Что работает с оговорками
Диалог с клиентом — не один ответ, а цепочка из 5–15 шагов, и ошибка на третьем шаге портит весь разговор. Такие системы работают при трёх условиях: узкий сценарий (запись, статус заказа, типовые вопросы, приём заявки), доступ к системам вместо импровизации (живое расписание, реальный остаток на складе, статус отправления) и мгновенный выход на человека по требованию клиента. В таком виде без оператора закрывается 40–70% потока. Обещание ассистента, который поговорит с клиентом о чём угодно, — это обещание неконтролируемых ответов от вашего имени.
Генерация контента — карточки товаров, описания услуг, письма, посты — даёт заметную скорость, но модель не отвечает за факты. Рабочее правило: всё проверяемое (характеристики, габариты, цены, сроки, состав) подставляется из вашей базы шаблоном, а модель пишет только связующий текст. И считать здесь надо не объём написанного, а время редактора: 400 карточек по 12 минут ручной работы — это 80 часов, те же 400 карточек по 3 минуты правки — 20 часов. Экономия реальная, но редактор из процесса не исчезает.
Что не работает
Принятие решений без правил. Пусть ИИ решает, кому дать скидку; пусть оценит поставщика; пусть решит, что закупать — у модели нет ни целей компании, ни ответственности за последствия. Работающая схема обратная: модель готовит материал для решения (сводку по поставщику, признаки риска в договоре, черновик расчёта), а решение принимает человек или детерминированное правило, записанное в коде. Практический признак: если правило невозможно сформулировать словами для нового сотрудника, его нельзя отдать и модели.
Прогноз без данных. Спрос на новый товар без истории продаж, отток клиентов при базе в 200 человек и трёх месяцах наблюдений, выручка на год вперёд у компании, которая полгода назад сменила рынок. Прогноз — это статистика по накопленной истории: для сезонности нужно 18–24 месяца, для оттока — сотни завершённых жизненных циклов клиентов. Языковая модель здесь не добавляет знания, она добавляет уверенную формулировку к цифре, взятой из воздуха. Это опаснее отсутствия прогноза.
Замена отдела целиком. По нашей практике сокращается не отдел, а очередь, переработки и время ответа. Типичный результат для поддержки: 40–70% типовых обращений закрывается без человека, остальное — сложное, конфликтное и нестандартное — по-прежнему требует опыта. Плюс появляется новая работа, которой раньше не было: вести базу знаний, разбирать выборку диалогов, обновлять сценарии при смене прайса и регламентов. Это 10–20 часов в месяц, и их надо кому-то поручить заранее, а не обнаружить постфактум.
Модель не знает, чего она не знает. Это должна знать система вокруг неё.
Галлюцинации: механика и три способа защиты
Механика простыми словами: языковая модель не ищет истину, она достраивает наиболее правдоподобное продолжение текста. Правдоподобное и верное совпадают, пока вопрос лежит внутри того, что модель видела и что ей дали в контексте. Как только вопрос выходит за эту границу, модель всё равно достраивает — и выдаёт ответ в том же уверенном тоне, потому что тон является свойством формата, а не признаком знания. Отсюда важное следствие: по стилю ответа отличить факт от выдумки нельзя ни человеку, ни другой модели.
Риск максимален в четырёх местах: вопрос за пределами базы знаний, редкие сущности (конкретный артикул, фамилия, номер договора), точные значения (суммы, даты, реквизиты, сроки) и длинные цепочки рассуждений, где ошибка первого шага тянется до конца. Ровно на эти места и ставятся контуры защиты. Ниже — три, которые мы считаем обязательными в любой системе, разговаривающей с клиентами или с документами.
- 1Ответ только по базе знаний. Перед генерацией система ищет релевантные фрагменты в ваших документах и передаёт модели их плюс инструкцию отвечать строго по ним. К ответу прикладывается ссылка на источник. Если подходящих фрагментов не нашлось — ответа не будет: система говорит, что уточнит, и передаёт вопрос человеку.
- 2Жёсткий перевод на человека по стоп-темам. Список тем (возврат денег, жалоба, юридическая претензия, здоровье, всё, что связано с персональными данными, прямая просьба позвать сотрудника) проверяется отдельным классификатором и словарём триггерных фраз — до того, как включится генерация. Правило живёт в коде, а не в виде вежливой просьбы внутри промпта: просьбу модель может проигнорировать, код — нет.
- 3Журналирование и выборочный контроль. В журнал пишется всё: вопрос, найденные источники, ответ, версия промпта и модели, время и стоимость вызова. Раз в неделю человек оценивает 3–5% диалогов по короткому чек-листу из 4–5 пунктов. Ключевые метрики — доля ответов без источника, доля переводов на человека и доля повторных обращений по тому же вопросу.
Система, которая всегда что-то отвечает, опаснее той, которая иногда отказывается. Нормальная доля отказов и переводов на человека в первые месяцы — 10–20%, и снижаться она должна за счёт пополнения базы знаний, а не за счёт ослабления правил. Если подрядчик показывает ассистента, который бодро отвечает вообще на всё, попросите задать ему вопрос про несуществующий товар или несуществующий пункт договора.
Деньги: эксплуатация, облако и свой контур
Стоимость владения складывается из четырёх статей, и вызовы модели — обычно не главная. Считаем на примере поддержки интернет-магазина: 6 000 обращений в месяц в чате и почте, база знаний на 150 страниц, ассистент отвечает по базе, спорное отдаёт операторам. Средний диалог — около 8 тысяч токенов с учётом найденных фрагментов, на моделях среднего класса это примерно 4 ₽ за обращение.
Из расчёта видны две вещи. Первая: экономить на выборе модели почти бессмысленно — переход на модель вдвое дешевле сократит расходы на 12 000 ₽ и может стоить процентов качества. Вторая: при росте нагрузки вдвое линейно растут только первая и четвёртая строки, остальные почти не меняются. Поэтому маленькие внедрения окупаются плохо, а средние и большие — хорошо: порог здравого смысла в поддержке начинается примерно с 2 000–3 000 обращений в месяц, ниже дешевле не автоматизировать, а нанять человека.
Вторая денежная развилка — облако или своя модель на своём сервере. Локальная модель звучит безопаснее и дешевле, но сначала обходится дороже: аренда сервера с подходящей GPU в российских дата-центрах стоит примерно 60 000–200 000 ₽/мес в зависимости от карты, собственное железо начинается от полутора миллионов рублей плюс администрирование. Открытые модели среднего размера уверенно закрывают классификацию, извлечение полей и ответы по базе знаний, но на сложных рассуждениях и редких формулировках всё ещё уступают топовым облачным. Переходить в свой контур стоит по конкретным признакам, а не из общего беспокойства.
- Данные нельзя выпускать за периметр по договору, регламенту безопасности или требованию заказчика — медицинские записи, материалы дел, персональные данные в объёме.
- Счёт за облачные вызовы стабильно превышает 80 000 ₽/мес: с этой отметки аренда GPU начинает выигрывать по деньгам, а не только по контролю.
- Нужна предсказуемая стоимость на год вперёд, без зависимости от курса валют, смены тарифов провайдера и снятия старой версии модели с поддержки.
- Система должна работать при отсутствии внешнего интернета — производственный контур, закрытая сеть, объект без стабильной связи.
- Задача узкая и повторяемая: классификация, извлечение полей, ответы по документам. На такой работе открытая модель на 20–30 млрд параметров не уступает облачной, а данные не покидают контур.
На практике чаще выигрывает гибрид: чувствительное — обращения с персональными данными, документы, внутренние регламенты — обрабатывается локальной моделью, а редкие сложные запросы уходят в облако уже обезличенными. Проектировать это надо в первый месяц: система, изначально прибитая к одному провайдеру через его нестандартные возможности, переезжает тяжело. Разумный минимум — держать вызовы модели за собственным слоем абстракции, чтобы смена провайдера или переход в свой контур стоили дней работы, а не переписывания половины системы.
