Разложу три варианта по деньгам, посчитаю электричество на калькуляторе и покажу формулу, по которой видно, при каком потоке запросов своё железо начинает выигрывать у облачного API. Числа ниже это ориентиры рынка на лето 2026 года, тарифы проверяйте перед покупкой: они двигаются быстро.

Вариант первый: арендовать GPU

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

Ориентиры рынка по России: помесячная аренда сервера с картой уровня RTX 3090 или 4090 идёт в коридоре 25-60 тысяч рублей, почасовая на той же карте 50-130 рублей в час. Серверные ускорители с 40-80 гигабайтами памяти начинаются от 120 тысяч в месяц и малому бизнесу не нужны почти никогда.

Почасовая схема выгодна там, где нагрузка неровная. Ночная пакетная обработка документов, разовая переиндексация базы, эксперимент с новой моделью на выходных: включили, отработали, выключили. Два часа в сутки по 90 рублей это 5,4 тысячи в месяц, что дешевле любой покупки.

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

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

Вариант второй: купить свою машину

Смета собирается из двух частей, и вторая обычно недооценена.

Три сборки, которые встречаются на практике. Бюджетная под классификацию и извлечение полей на модели в 8 миллиардов параметров: 120-170 тысяч. Средняя под 14B и базу знаний: 180-230 тысяч. Сильная с 24 гигабайтами видеопамяти под модели на 32 миллиарда: 300-380 тысяч рублей.

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

Электричество: считаем, а не пугаем

Видеокарта под полной нагрузкой ест 350-450 ватт, вся машина около 550. В простое с загруженной в память моделью около 100-120 ватт.

Реальный профиль малого бизнеса это не круглосуточный расчёт, а два-три часа фактической генерации в сутки и всё остальное время простой.

• нагрузка: 0,55 кВт × 2 ч × 30 дней = 33 кВт·ч
• простой: 0,11 кВт × 22 ч × 30 дней = 72,6 кВт·ч
• итого около 106 кВт·ч в месяц, по тарифу 6 рублей это 640 рублей

Даже при круглосуточной полной загрузке выходит 396 кВт·ч и около 2,4 тысячи рублей. Электричество не главная строка, хотя пугают им чаще всего. Главные строки другие.

Строки, которые забывают

Администрирование. Драйверы, обновления, мониторинг температуры, перезапуск упавшего сервиса, чистка диска. На устоявшейся системе это 3-6 часов в месяц. По консервативной ставке 900 рублей за час полной стоимости сотрудника выходит 2,7-5,4 тысячи рублей ежемесячно.

Простой. Карта сгорела, и вы неделю без сервиса, потому что запасной нет. У облака эта проблема закрыта чужими руками.

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

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

Вариант третий: без видеокарты вообще

Недооценённый путь. Обычный сервер с 16-20 ядрами и 32 гигабайтами памяти стоит в аренде 4-9 тысяч рублей в месяц, а купить такую машину можно за 60-90 тысяч.

Наш замер на своём внутреннем сервере: 20 ядер, 31 гигабайт памяти, GPU нет. Модель Qwen3-4B в четырёхбитном квантовании отвечает на рабочий вопрос за 11 секунд, короткий вопрос закрывает за секунду. Девятимиллиардная GLM на том же железе даёт 17 секунд и заметно более точные формулировки по отраслевой терминологии.

Я перед запуском прогнозировал 30-90 секунд и ошибся втрое в худшую сторону. Урок простой: не отговаривать по прикидкам, а мерить на живом железе.

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

Формула окупаемости

Считаем две величины в месяц и сравниваем.

Своё железо = цена сборки / 36 месяцев + электричество + часы админа × ставка
Облако      = обращений в месяц × токенов на обращение / 1 000 000 × цена за миллион

Подставим среднюю сборку за 220 тысяч рублей:

• амортизация: 220 000 / 36 = 6 100 ₽
• электричество: 640 ₽
• админ, 4 часа по 900: 3 600 ₽
• итого около 10 300 ₽ в месяц

Теперь облако. Одно обращение к базе знаний вместе с подложенными фрагментами съедает 5-15 тысяч токенов, возьмём 10 тысяч. У экономичных моделей вроде DeepSeek стоимость миллиона токенов держится в районе сотни рублей с учётом входа и выхода.

10 300 рублей делим на 100 рублей за миллион, получаем 103 миллиона токенов в месяц. Делим на 10 тысяч токенов на обращение: порядка 10 тысяч обращений в месяц, то есть около 340 в день. Ниже этого потока своё железо проигрывает по деньгам, выше начинает выигрывать.

С топовой зарубежной моделью, где миллион токенов стоит в десять-тридцать раз дороже, порог падает до 400-1000 обращений в месяц.

Здесь и прячется подвох, из-за которого расчёт часто врёт. Локальная модель на 8-14 миллиардов параметров не равна топовой облачной по качеству, и сравнивать их ценники некорректно. Честная арифметика получается только против сопоставимой по классу облачной модели, и тогда порог держится в районе нескольких сотен обращений в день. В статье про локальную LLM я писал про сотни тысяч запросов в месяц: это порог против дешёвой облачной модели, и он никуда не делся.

Три варианта в одной таблице

Отдельное сравнение аренды и покупки. Сборка за 220 тысяч отбивает помесячную аренду за 35 тысяч примерно за полгода круглосуточной работы. При использовании два часа в сутки почасовая аренда обойдётся в 5,4 тысячи в месяц против 10,3 тысячи у своей машины, и покупка не окупится никогда.

Когда своё железо не нужно

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

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

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

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

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

Требование звучит как «данные должны остаться в России». Это закрывается российским облаком, а не своей стойкой. Локальный контур нужен, когда формулировка другая: данные не должны покидать наш контур.

Короткие ответы на частые вопросы

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

Есть ли смысл брать 3090 с рук? Часто да: 24 гигабайта видеопамяти за 70-100 тысяч это лучшее соотношение цены и памяти на рынке. Риск в состоянии карты после майнинга, поэтому берите с проверкой под нагрузкой и закладывайте, что гарантии нет.

Сколько проживёт карта под ИИ-нагрузкой? При нормальном охлаждении три-четыре года без драмы. Убивает не нагрузка, а перегрев в тесном корпусе и пыль. Термопрокладки и чистка раз в год стоят копейки и продлевают жизнь заметно.

Считать ли зарплату админа, если он и так в штате? Считать. Часы, которые он тратит на модель, он не тратит на другое. Иначе экономия в расчёте появляется из воздуха, а потом внезапно кончается вместе с админом.

Можно ли начать с аренды и переехать на своё? Да, и это разумный порядок. Слой модели в приложении меняется тремя переменными окружения: адрес, ключ, название модели. Переезд занимает дни, а не переписывание системы.

Что посчитать до покупки

Три цифры закрывают вопрос. Сколько обращений в месяц реально придёт. Сколько токенов съедает одно обращение (замеряется за час на пилоте). Какой класс модели вам нужен по качеству.

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

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

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

Сколько памяти реально съедает модель

Считать надо не «размер модели в миллиардах», а вес файла плюс место под контекст. Порядки такие: в восьмибитном виде модель занимает примерно один байт на параметр, в четырёхбитном Q4_K_M около 0,6 байта. Восьмимиллиардная модель это 8 гигабайт в Q8 и 4,7 гигабайта в Q4.

Дальше сверху ложится KV-кэш, то есть память под сам диалог и подложенные документы. Считайте, что контекст добавит от 15 до 30 процентов, а на длинных запросах в 32 тысячи токенов и больше он способен съесть несколько гигабайт.

Практический вывод из таблицы неприятный для владельцев карт на 8 гигабайт. В такую карту нормально влезает восьмимиллиардная модель с коротким контекстом, и всё. Хотите работать с документами на десяток страниц, планируйте 16 гигабайт. Базовые требования к контуру я разбирал в статье про локальную LLM на своём сервере, здесь речь именно про выбор весов.

Что отнимает квантизация

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

Q8 от исходной модели на глаз почти неотличим. Q4_K_M теряет заметно, но терпимо: страдают длинные цепочки рассуждений, устойчивость строгого формата вроде JSON по схеме из пятнадцати полей и редкая терминология. Q3 и ниже я в работу не беру, там модель начинает путать смысл, а не только формулировки.

Главное правило звучит контринтуитивно. При одинаковом объёме памяти берите модель побольше в Q4, а не поменьше в Q8. Четырнадцать миллиардов в четырёх битах на тех же 12 гигабайтах обыгрывают восемь миллиардов в восьми битах почти на любой содержательной задаче. Исключение одно: сценарии, где важен строгий машинный формат ответа, там мельче квантование бьёт по дисциплине вывода сильнее, чем помогает лишний размер.

Русский язык: чем модели отличаются

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

Qwen последних версий сейчас рабочая база для малых размеров: 4B и 8B пишут по-русски связно, падежи держат. Llama и Mistral на английском сильны, на русском отвечают с акцентом: канцелярит, кривое согласование, иногда сваливаются в английский посреди абзаца. Gemma посередине. Отдельно стоят русские дообучения открытых моделей, вроде линейки T-lite и T-pro от Т-Банка или проекта Vikhr, они собраны поверх Qwen и Mistral и на деловой переписке ведут себя аккуратнее базовых версий.

Про GigaChat и YandexGPT надо сказать прямо, потому что их регулярно предлагают «поставить на сервер». Это API в облаке провайдера, весов вы не получаете. Требование «данные не покидают Россию» они закрывают, требование «данные не покидают наш контур» нет. Разница принципиальная, и её стоит проговорить с безопасностью до закупки железа. Что имеет смысл держать у себя, а что спокойно уходит наружу, разобрано здесь.

Замер на процессоре, без видеокарты

На своём внутреннем сервере (20 ядер, 31 гигабайт памяти, GPU нет и не предвидится) мы запускали две модели через llama.cpp. Вопрос задавали рабочий, про приёмку монолитных работ, длиной около 150 токенов.

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

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

Экстраполяция по тем же ядрам: 14B выдаст около 4 токенов в секунду, 32B около 1,7. Тридцать вторую на процессоре ставить бессмысленно, ответ будет собираться минуту с лишним.

Где хватает маленькой модели

Список задач, которые 4-8B закрывают уверенно и без видеокарты за сотни тысяч:

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

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

Где нужна большая, и где локальная проигрывает всегда

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

И честное, ради чего стоит читать этот раздел. Локальная модель на 8-14 миллиардов не догоняет топовую облачную на сложных рассуждениях. Разрыв не в проценты, он в другом классе задач. Юридический анализ договора, разбор нестандартной претензии, длинная многошаговая логика: тридцатидвухмиллиардная модель подойдёт близко, восьмимиллиардная не подойдёт никогда. Если пилот собирался на облаке и всех устроил, перенос на локальную восьмёрку почти наверняка разочарует.

Таблица: задача, размер, железо, цена вопроса

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

Возьмите 20 своих реальных примеров: обращения клиентов, куски документов, письма. Не придуманные, а такие, какие приходят на самом деле.

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

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

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

Где это не работает

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

Одновременность ломает расчёт. Модель, которая отвечает за 5 секунд одному человеку, при пяти запросах в одну секунду выстроит очередь. Лечится это vLLM с пакетной обработкой или второй картой, но не выбором другой модели.

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

Дообучение под себя это не «поставить модель». Fine-tune требует размеченных данных, отдельного железа и человека, который умеет. В девяти случаях из десяти нормальный поиск по документам и внятный промпт дают больше при несопоставимо меньших затратах.

Короткие ответы на частые вопросы

Стоит ли брать 70B, если бюджет позволяет? Только если задача действительно про рассуждения и вы уже упёрлись в потолок тридцатидвухмиллиардной. Две карты по 24 гигабайта плюс сборка это разовые сотни тысяч рублей, а прирост качества на классификации и извлечении полей вы не заметите.

Какая модель лучше для русского прямо сейчас? Универсального ответа нет, и любой конкретный обесценится за пару месяцев. Рабочая процедура: берите свежий Qwen нужного размера как базу, добавьте одно русское дообучение поверх той же архитектуры и сравните на своих 20 примерах.

Можно ли держать несколько моделей одновременно? Да, если суммарно влезают в память. У нас на одном сервере живут четырёхмиллиардная и девятимиллиардная, вместе занимают 15 гигабайт из 31, переключение идёт кнопкой в интерфейсе. Схема удобная: быстрая для потока, тяжёлая для сложных вопросов.

Сколько места на диске закладывать? Считайте от 100 гигабайт с запасом. Веса весят от 2 до 40 гигабайт, а на пробу вы скачаете три-четыре штуки и забудете удалить. Мы так один раз уронили деплой на забитом диске, диагностика заняла час, лечение две минуты.

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

Что сделать дальше

Определитесь с задачей до похода в магазин за картой. Классификация и извлечение полей закрываются восьмимиллиардной моделью на 12 гигабайтах, а иногда и процессором. Всё, что похоже на «пусть подумает», требует либо 24 гигабайт, либо облака.

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

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

Часть первая: разработка

Разовые деньги за то, чтобы система появилась. Внутри обычно четыре вещи:

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

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

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

Рыночные ориентиры по России на середину 2026 года выглядят так: пилот одного модуля 80-250 тысяч рублей, коробочная база знаний 150-300 тысяч. Вилка широкая, потому что за одним и тем же словом продают очень разное. Это ориентир рынка, а не прайс, конкретная сумма считается после разбора процесса.

Часть вторая: токены

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

Считается он предсказуемо. Один разбор заявки съедает 2-4 тысячи токенов вместе с промптом. Ответ в режиме базы знаний тяжелее, 5-15 тысяч, потому что в запрос подкладываются найденные фрагменты. Диалог из десяти реплик набирает 20-40 тысяч.

Дальше умножаете на поток. Три тысячи обращений в месяц по 10 тысяч токенов дают 30 миллионов токенов. У экономичных моделей вроде DeepSeek это порядок нескольких тысяч рублей в месяц. У топовых зарубежных моделей та же нагрузка выйдет в разы дороже.

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

Часть третья: инфраструктура

Сервер, домен, бэкапы, мониторинг. Для типового контура с ботом, базой знаний и n8n хватает VPS на 8 гигабайт памяти, это порядка 2-4 тысяч рублей в месяц.

Домен и сертификат почти бесплатны: HTTPS от Let's Encrypt продлевается сам, покупать SSL у хостера не нужно.

Отдельная строка возникает, если вы решили держать модель у себя. Тогда речь про видеокарту или аренду GPU, и цифры меняются принципиально. Когда это оправдано, разбирал в статье про локальную LLM.

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

Часть четвёртая: поддержка

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

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

Рабочий ориентир: 10-20% от стоимости разработки ежемесячно за сопровождение живой системы. Рынок сопровождения в России сейчас держится в коридоре 15-50 тысяч рублей в месяц, и это самая недооценённая часть счёта.

Систему без поддержки видно за версту. Она отвечает по прайсу, который отменили полгода назад.

Таблица: что за что платим

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

Как считать окупаемость

Мы считаем по часам, потому что это единственная величина, которую можно проверить.

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

Дальше арифметика на салфетке. Три менеджера тратят по полтора часа в день на разбор входящих заявок. Это 4,5 часа в день, около 94 часов в месяц, примерно 85 тысяч рублей. Автоматизация снимает не всё, реалистично 50-60%. Получаем экономию около 45-50 тысяч рублей ежемесячно.

Теперь сравниваем. Пилот за 150 тысяч при такой экономии окупается за 3-4 месяца, дальше работает в плюс за вычетом поддержки и токенов.

Три правила, чтобы счёт не оказался фантазией:

1. Считайте по факту, а не по ощущениям. Неделя замеров: сколько обращений, сколько минут на каждое.
2. Закладывайте, что автоматизация снимет часть работы, а не всю.
3. Учитывайте эффекты помимо часов: ответ ночью вместо утра, потерянные заявки, ошибки в отчётах. Их сложнее оцифровать, но иногда они и есть основная выгода.

Почему «бот за 15 тысяч» заканчивается ничем

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

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

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

Мы для себя закрыли этот вопрос принципом переиспользования. Пилоты собираются из уже работающих движков портфеля, а не пишутся с нуля: лидогенерация из радара заказов, разбор прайсов из сервиса снабжения, база знаний из готовой RAG-платформы. Поэтому 2-4 недели до работающего результата, а не полгода. Написать всё заново под каждого клиента стоило бы неприлично дорого, и никакая окупаемость бы не сошлась.

Две ошибки в наших собственных оценках

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

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

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

Обе истории про одно: в счёт входит не только работа подрядчика. Внедрение это совместный проект, и вторая половина расходов живёт у вас внутри.

Чек-лист: что посчитать до разговора с подрядчиком

1. Число обращений или операций в неделю. Не «много», а цифра.
2. Среднее время на одну операцию. Замерьте секундомером три раза, среднее ближе к правде, чем память сотрудника.
3. Сколько человек участвует и по какой ставке считать час.
4. Где сейчас теряется время: ожидание, поиск файла, ручное копирование, переспрашивание коллеги.
5. Что уже автоматизировано и работает. Иногда достаточно доделать имеющееся.
6. Кто со стороны компании будет вести проект и сколько часов в неделю он реально может выделить.

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

Где внедрение не окупится

Редкий процесс. Задача раз в месяц на два часа не окупит даже разговора о ней.

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

Процесс без цифр. Никто не знает, сколько сейчас уходит времени, значит эффект посчитать не с чем, а спор об успехе проекта будет вкусовым.

Компания без владельца задачи. Если внедрение никому не поручено персонально, оно умрёт на этапе «пришлите нам файлы».

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

Короткие ответы на частые вопросы

Можно ли начать с небольшой суммы? Можно, если сузить задачу до одного сценария и одного канала. Разбор заявок с сайта в Телеграм без интеграции с CRM стоит заметно дешевле полноценного контура. Плохая идея за небольшие деньги браться за «ИИ во всей компании»: получится ни то ни сё.

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

Что если не окупится? Для этого пилот и делается коротким. Критерий успеха согласовывается до старта: например, время обработки заявки падает вдвое. Не сошлось, вы теряете стоимость пилота, а не бюджет годового внедрения.

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

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

Что сделать до разговора о цене

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

С этим листком любой разговор о бюджете становится предметным. Вы сравниваете предложение подрядчика не с ощущением «дорого», а с конкретной суммой, которую процесс съедает ежемесячно.

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

Врать он не собирался. Языковая модель предсказывает правдоподобное продолжение текста, а не сверяется с вашими файлами. Ваших договоров она никогда не видела. Из тысяч чужих договоров она усвоила, что «30 дней» встречается чаще, и выдала статистику вместо факта.

RAG чинит ровно эту дыру.

Что это за схема

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

Важный момент, который снимает половину вопросов на переговорах: модель при этом ничему не учится. Никакого дообучения нейросети не происходит. «Обучить ИИ на наших документах» на практике значит собрать и разметить базу знаний. Меняется библиотека, а не мозг.

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

Четыре шага под капотом

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

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

Индексация. Каждый фрагмент превращается в вектор, набор чисел, отражающий смысл. Рядом обычно держат обычный текстовый индекс BM25, потому что по артикулу ВГ-125 или номеру приказа он находит лучше любой векторной магии. Гибрид из двух поисков работает надёжнее каждого по отдельности.

Ответ. На вопрос система поднимает 5-10 самых близких фрагментов, отдаёт их модели и получает формулировку. К ответу прикладывается ссылка: файл, раздел, страница.

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

Цитата-источник это не украшение

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

Зачем это бизнесу попроще. Ссылка превращает ассистента из оракула в справочник. Сотрудник видит: ответ взят из «Регламент отгрузки, редакция от марта, пункт 4.2». Сомневается, открывает и проверяет за десять секунд.

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

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

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

Сканы. PDF, который на самом деле фотография бумаги. Текста внутри нет, индексировать нечего. Лечится распознаванием, но тут закопаны грабли. Мы потеряли время на битой русской модели Tesseract из набора tessdata_fast: движок молча срывался на английский и выдавал латинскую кашу вместо слов. Помог полный набор tessdata_best плюс предобработка картинки, чёрно-белый режим и увеличение вдвое. Мелкий шрифт из старой копии без этого не читается.

Таблицы. Excel и табличные PDF при тупом извлечении превращаются в поток чисел без заголовков. Ассистент потом честно находит фрагмент «125 4 320 нет» и не может сказать, что это. Таблицы надо разбирать отдельно, построчно, подставляя названия колонок в каждую строку.

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

Грязные справочники. В номенклатуре 1С мы ловили позицию «Сгон» с латинской C в начале. Глазами не отличить, поиск молча не находит. Перед индексацией такие гомоглифы приходится нормализовать, иначе часть базы существует, но недоступна.

Устная традиция. Половина знаний компании нигде не записана. Ассистент физически не найдёт того, чего нет в файлах. Обычно первый месяц проекта уходит не на код, а на то, чтобы люди выгрузили из головы хотя бы топ-30 вопросов с ответами.

Как понять, что база работает

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

Дальше прогоняете его после каждого изменения базы и смотрите три цифры:

• сколько ответов совпало с эталоном;
• сколько раз система честно сказала «не нашёл» (это не провал, а нормальное поведение);
• сколько раз ответ был уверенным и неправильным.

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

Третья цифра важнее всех. Она должна быть нулём или близко к нулю. Уверенная ложь опаснее отказа, потому что её никто не перепроверяет.

Где RAG не работает

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

Он не отвечает на слишком общие вопросы. «Расскажи про нашу работу с поставщиками» это не вопрос, под него подходит половина библиотеки. Ассистент выдаст размытую сводку, и вы решите, что система плохая.

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

Он не заменяет порядок в документах. Если у вас нет хозяина у папки с регламентами, через полгода в базе снова окажутся три редакции одного приказа. Технология не лечит организационный бардак, она его подсвечивает.

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

Три провала на живых базах

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

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

Двухколоночный PDF. Отраслевой регламент был свёрстан в две колонки. Извлечение текста шло построчно, и строки двух колонок склеивались в одну. Фрагменты получались бессмысленными, а поиск исправно их находил. Помог разбор с учётом координат блоков через pymupdf. Мораль: перед индексацией стоит глазами посмотреть, что вытащилось из десятка случайных файлов, а не сразу гнать всю папку.

С чего начать у себя

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

Дальше по шагам:

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

Такой пилот занимает 2-4 недели вместе с интеграцией в Телеграм или внутренний портал. Дольше обычно тянется не разработка, а сбор файлов на стороне заказчика.

Короткие ответы на частые вопросы

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

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

Можно ли подключить к базе 1С или CRM? Можно, но это другая механика. Регламент ищется по смыслу, а остаток на складе берётся запросом к системе. Обычно ассистент умеет и то и другое: сначала решает, что перед ним, потом идёт в нужный источник.

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

Как быстро база узнаёт про новый прайс? Переиндексация раздела занимает минуты. Мы обычно вешаем её на расписание плюс кнопку «обновить сейчас» для ответственного.

Собранные контуры и метрики лежат в кейсах, а про расходы на токены, сервер и поддержку я отдельно посчитал в статье про стоимость внедрения. Хотите проверить свою библиотеку до разработки, приходите на AI-аудит: посмотрим, что у вас за файлы, и скажем честно, если половину придётся сначала перенабрать.

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

Что такое n8n и почему не Make

n8n это конструктор автоматизаций: вы соединяете блоки, а платформа гоняет по ним информацию. Главное отличие от облачных Zapier и Make в том, что n8n ставится на свой сервер. Одна команда docker compose up, и у вас личный сервис на своём домене.

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

Минус честный: сервер придётся администрировать. Обновления, бэкапы базы, мониторинг. Если в компании нет никого, кто дружит с консолью, облачный тариф с оплатой по подписке будет спокойнее.

Ноды и триггеры на пальцах

Нода это один шаг. Получить письмо, вызвать API, преобразовать текст, записать строку. У ноды есть вход, настройки и выход в виде набора элементов.

Триггер это первая нода, она запускает всё остальное. Три рабочих лошадки:

• Webhook. n8n выдаёт адрес, на который ваш сайт отправляет заявку. Срабатывает мгновенно.
• Schedule. Запуск по расписанию, скажем каждые 15 минут или в 9 утра.
• Триггеры сервисов. Новое письмо в почте, сообщение в Telegram, строка в таблице.

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

Сценарий: заявка, разбор ИИ, CRM, уведомление

Собираем цепочку из шести нод.

1. Webhook. Метод POST, путь произвольный. В настройках сразу ставьте ответ «сразу», иначе форма на сайте будет висеть, пока отработает вся цепочка, а это 3-5 секунд с вызовом модели. Посетитель за это время успеет уйти.

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

3. HTTP Request к языковой модели. Тут происходит вся магия. Отправляем текст заявки с инструкцией разобрать его на поля.

Промпт, который у нас выжил после переделок, устроен так:

Ты разбираешь заявки строительной компании.
Верни ТОЛЬКО JSON без пояснений:
{"тип_работ": "", "объект": "", "срочность": "низкая|средняя|высокая",
 "бюджет_упомянут": true|false, "готов_к_звонку": true|false,
 "краткое_резюме": "одно предложение"}
Если поля нет в тексте, оставь пустую строку. Не выдумывай.
Текст заявки: {{ $json.text }}

Температуру ставим 0. Модель должна быть скучной и повторяемой, творчество здесь вредит.

4. Code. Проверяем ответ. Пять строк на JavaScript: попробовать разобрать JSON, при ошибке подставить заглушку и поднять флаг «разобрать вручную». Без этой ноды первая же нестандартная заявка уронит весь сценарий. Модель иногда оборачивает JSON в markdown-блок, это лечится вырезанием обратных кавычек.

5. Bitrix24 или amoCRM. Создаём лид: имя, телефон, комментарий из краткого резюме, источник, ответственный по правилу распределения. Если срочность высокая, лид сразу летит старшему менеджеру.

6. Telegram. Сообщение в чат отдела: три строки и ссылка на карточку. Менеджеры смотрят в телефон чаще, чем в CRM, и это не изменить регламентом.

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

Тест перед запуском

Не включайте цепочку на боевой трафик сразу. Возьмите 20 старых заявок из почты и прогоните через сценарий с отключённой записью в CRM.

Смотрите на две вещи: правильно ли модель разложила поля и что произошло с кривыми заявками. Кривые в выборке обязательно найдутся: пустой текст, «перезвоните», сообщение на транслите, спам про SEO-услуги.

Короткий чек-лист перед боевым включением:

1. Пустая заявка не роняет сценарий, а помечается флагом.
2. Спам не создаёт лид в CRM.
3. Повторная отправка той же формы не порождает второй карточки.
4. Уведомление в чат приходит с телефоном и ссылкой, чтобы менеджеру не пришлось искать.
5. При недоступности модели заявка всё равно попадает в CRM, пусть без разбора. Терять обращение из-за чужого сбоя нельзя.

У нас на такой прогонке всплыло, что модель считала срочным всё, где встречалось слово «срочно», включая рекламные рассылки. Добавили в промпт условие про источник, и мусор перестал будить старшего менеджера.

Три грабли, на которые мы наступили

Ретраи дублируют лидов. Сеть моргнула, n8n повторил шаг, в CRM появились две одинаковые карточки. Лечится ключом идемпотентности: перед созданием ищем лид по телефону за последние сутки. Пять минут работы, а без них менеджеры две недели ругаются на дубли.

Исходящие к Telegram могут не уходить. На одном из наших серверов запросы к api.telegram.org резались провайдером, нода отваливалась по таймауту без внятной ошибки. Пришлось поднимать релей. Диагностика заняла в разы больше времени, чем починка, потому что в интерфейсе это выглядело как «иногда не работает».

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

Безопасность и порядок: то, о чём вспоминают поздно

Вебхук без секрета. Адрес вашего вебхука это открытая дверь. Мы однажды оставили путь простым и предсказуемым, и через неделю в CRM начали падать пустые лиды от чужих сканеров. Минимум, который надо сделать сразу: длинный случайный путь, проверка секретного заголовка от формы, ограничение частоты запросов.

Ключи внутри нод. Токен модели и пароль CRM должны жить в разделе Credentials, а не в поле HTTP-ноды. Разница вылезает при экспорте схемы: в первом случае вы отдаёте коллеге JSON без секретов, во втором отправляете ему свои ключи вместе с файлом.

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

Логи и хранение. По умолчанию n8n складывает историю выполнений в базу, и она пухнет. Через полгода мы получили распухший том и упавший сервис на ровном месте. Настройте срок хранения выполнений и бэкап базы, где лежат сами сценарии.

Где no-code упирается в потолок

n8n прекрасен, пока схема помещается на экран. Потолок ощущается на трёх симптомах.

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

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

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

Наша рабочая граница выглядит так:

• всё, что связывает сервисы и живёт на вебхуках, остаётся в n8n;
• бизнес-логика, расчёты и работа с большими объёмами переезжают в отдельный сервис на Python с PostgreSQL;
• n8n дёргает этот сервис как обычный HTTP-эндпоинт и отвечает за маршрутизацию.

Гибрид держится годами. Чистый no-code на сложной логике превращается в техдолг, который не поддержит никто, кроме автора схемы.

Чего не ждать от первого сценария

Он не заменит менеджера. Разбор заявки это подготовка карточки, а звонит и продаёт человек.

Он не сделает поток заявок чище. Если с сайта приходит спам, автоматизация начнёт быстро и аккуратно заводить спам в CRM. Фильтр придётся ставить отдельно.

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

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

Следующий шаг

План на ближайшие выходные, если хочется попробовать руками. Поднимите n8n в Docker на любом сервере за пару сотен рублей в месяц. Соберите цепочку из трёх нод: Webhook, Set, Telegram. Убедитесь, что заявка с тестовой формы долетает в чат за секунду.

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

Короткие ответы на частые вопросы

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

Нужен ли программист? Для первых сценариев нет, хватит человека, который не боится JSON и умеет читать документацию API. Программист понадобится на двух вещах: поднять и обновлять сервер, написать нестандартные преобразования в Code-нодах.

Можно ли обойтись без своего сервера? Можно, есть облачная версия и есть Make. Для компании, где нет никого с доступом к консоли, это честный вариант. Взамен вы отдаёте содержимое заявок стороннему сервису и платите за объём.

А 1С? Прямой ноды нет, работают через промежуточный слой: обмен файлами по расписанию либо HTTP-сервис на стороне 1С. Так мы и делаем в проектах для снабжения, обмен идёт JSON-файлами по таймеру.

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

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

Уточняющий вопрос обычно ломает картину. Что именно нельзя отдавать? Прайс, который лежит на сайте? Регламент отгрузки, который знает каждый водитель? Или паспортные сведения сотрудников и себестоимость, которую не видят даже менеджеры?

Ответ на этот вопрос определяет бюджет. Иногда разница составляет сотни тысяч рублей.

Что значит «локально»

Модель лежит файлом на вашем сервере. Запрос уходит на этот же сервер, ответ возвращается оттуда же. Наружу не летит ничего, интернет для работы не нужен вовсе.

Технически это обычно Ollama, если нужен простой запуск и один-два пользователя, либо vLLM, когда нужна нагрузка и очередь запросов. Обе штуки ставятся в Docker и поднимают HTTP-интерфейс, совместимый с привычным API. Для приложения смена облачной модели на локальную это правка трёх переменных окружения: адрес, ключ, название модели. Мы держим слой модели сменяемым во всех проектах именно ради такой гибкости.

У нас Ollama работает общим сервисом на портфель. Пара задач с картинками закрыта им бесплатно, вместо оплаты за каждый снимок.

Три причины, ради которых это делают

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

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

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

Требования к железу без иллюзий

Главный ресурс это память видеокарты. Порядки такие:

Квантование это сжатие весов. Модель в 4 битах теряет немного качества и сильно экономит память, для рабочих задач разница обычно приемлема.

Про запуск на процессоре надо сказать прямо. Модель на 8 миллиардов параметров на обычном сервере без видеокарты выдаёт единицы токенов в секунду. Ответ в 300 слов будет собираться около минуты. Для живого чата с клиентом это неприемлемо. Для ночной пакетной обработки, где надо разобрать 500 писем до утра, вполне рабочий вариант.

Качество: где локальная проигрывает облаку

Скажу честно, потому что на этом ломается больше всего ожиданий. Модель на 8 миллиардов параметров это не то же самое, что топовая облачная модель, как бы красиво ни выглядели бенчмарки.

Что локальные модели среднего размера делают уверенно:

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

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

Отдельный урок из нашего фотоархива на пять терабайт. Мы сначала гоняли снимки через модель зрения, каждый кадр обрабатывался около 85 секунд. Задача была узкой: найти похожие изображения. Перешли на специализированную модель CLIP, получили 57 миллисекунд на кадр. Разница в тысячи раз, качество для этой задачи не пострадало.

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

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

Три провала при переносе на своё железо

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

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

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

Гибридная схема, которую мы считаем разумной

Крайности редко работают. Всё в облако страшно, всё локально дорого и медленно. Между ними живёт схема с маршрутизацией.

Работает так. Входящий запрос сначала попадает в классификатор, часто это простая локальная модель или обычные правила. Дальше развилка.

1. Запрос содержит персональные сведения, суммы сделок, себестоимость: обрабатывается локально, наружу не уходит.
2. Запрос безобидный и требует хорошего качества: уходит в облачную модель.
3. Запрос требует облака, но содержит чувствительные куски: перед отправкой их маскируют.

Третий пункт заслуживает пояснения. Маскирование это подстановка меток вместо ФИО, телефонов и номеров договоров. Наружу уходит текст с «КЛИЕНТ_1» и «ТЕЛЕФОН_1», обратно приходит ответ с теми же метками, а подстановка настоящих значений происходит уже у вас. Реализуется парой регулярных выражений и словарём, работает надёжно на типовых форматах.

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

Считаем деньги

Аренда сервера с приличной видеокартой в России обходится в десятки тысяч рублей в месяц, покупка своей карты уровня 4090 это разовые сотни тысяч плюс сборка и место в стойке. Цифры плавают, проверяйте актуальные тарифы перед решением.

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

Точка, где локальный запуск выигрывает по деньгам, начинается на действительно больших объёмах: сотни тысяч запросов в месяц, постоянная фоновая обработка документов, расшифровки всех звонков компании. У малого бизнеса такого потока обычно нет, и тогда локальная модель ставится не ради экономии, а ради требований безопасности. Это нормально, просто надо называть вещи своими именами. Как считать общий счёт на внедрение, разбирал здесь.

Где это не работает и чего не ждать

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

Не ставьте локальную модель, если некому её обслуживать. Обновления, драйверы, мониторинг температуры, забитый диск с весами моделей по 20 гигабайт. Это работа системного администратора, и она не разовая.

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

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

И последнее. Локальная модель не отменяет базу знаний. Без подключённых документов она будет выдумывать ровно так же, как облачная, только менее складно.

Сводка по трём вариантам:

Чек-лист перед покупкой видеокарты

1. Посчитайте поток: сколько запросов в месяц и какой длины. Без этой цифры разговор про железо бессмысленный.
2. Соберите пилот на облачной модели и замерьте качество. Это будет ваша планка, с которой сравнивается локальный вариант.
3. Прогоните ту же задачу на локальной модели через Ollama, хоть на рабочем ноутбуке с игровой картой. Час работы, зато вы увидите реальную разницу на своих текстах, а не на бенчмарках.
4. Проверьте требования: что именно у вас нельзя отдавать наружу и чем это подтверждено. Договор, закон, внутренний приказ.
5. Найдите человека, который будет это обслуживать. Нет такого человека, нет локального контура.
6. Сравните годовую стоимость двух вариантов: железо с администрированием против токенов при вашем потоке.

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

Короткие ответы на частые вопросы

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

Хватит ли одной видеокарты на отдел? Для десятка сотрудников с редкими запросами обычно да. Проблема не в числе людей, а в одновременности: когда пять человек пишут в одну секунду, запросы встают в очередь. Лечится либо второй картой, либо vLLM с пакетной обработкой.

Можно ли арендовать GPU вместо покупки? Да, и для проверки гипотезы это разумнее покупки. Аренда даёт возможность выйти из истории, если через два месяца станет понятно, что локальный запуск не нужен.

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

Нужен ли интернет локальному контуру? Для работы модели нет. Он понадобится для скачивания весов и обновлений системы. Полностью изолированный контур собрать можно, это отдельная работа с ручной доставкой обновлений.

Как решить за один вечер

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

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

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

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

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

Мы держим у себя радар заявок, который обходит площадки и Telegram-каналы. За один прогон он приносит 93 релевантные заявки, из них 10 — сразу с указанным бюджетом. Дальше по кнопке ИИ читает техзадание и выдаёт вердикт «беру / пас» плюс черновик отклика. Ниже — как та же механика ставится на входящий поток компании.

Что значит «квалифицировать» на самом деле

Формулировка «бот квалифицирует лида» обычно означает «бот задал три вопроса и записал ответы». Это не квалификация, это анкета.

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

Отсюда простой критерий приёмки: если менеджер, открыв карточку, всё равно звонит и спрашивает то же самое заново, — ИИ работу не сделал.

Сценарий диалога: четыре вопроса, не двенадцать

Первая версия нашего диалога была длинной. Мы хотели узнать всё: объём, сроки, бюджет, город, кто принимает решение, откуда узнали о компании. Люди отваливались на пятом вопросе.

Работающая схема выглядит так:

Бот. Здравствуйте! Я помощник, отвечаю круглосуточно. Опишите задачу в двух словах — передам менеджеру с утра, а если срочно, подключу его прямо сейчас. Клиент. Нужно посчитать вентиляцию на склад 2000 м². Бот. Понял, склад 2000 м². Когда планируете начать работы? Клиент. Хотим до конца сентября. Бот. Проект уже есть или считаем с нуля? Клиент. Есть планировки, проекта нет. Бот. Спасибо. Оставьте телефон — менеджер перезвонит в понедельник до 12:00. Если нужно раньше, напишите «срочно», я подниму заявку сегодня.

Четыре реплики. Что важно в этой конструкции:

• первое сообщение уходит за секунду и сразу снимает тревогу «меня услышали»;
• бот повторяет услышанное своими словами — человек видит, что его понимают, и не бросает диалог;
• обещание конкретное: не «мы скоро свяжемся», а «в понедельник до 12:00»;
• выход на человека предложен с первой минуты, а не спрятан в конце.

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

Скоринг: считаем баллы, а не «горячий/холодный»

Ярлыки «горячий» и «тёплый» — вкусовщина. Считать проще по баллам, и логика должна быть открытой, чтобы руководитель отдела мог её править сам.

Сумма 6 и выше — менеджеру немедленно. От 2 до 5 — в очередь на рабочий день. Ниже 2 — в общую воронку с автописьмом и без отвлечения человека.

Веса надо один раз откалибровать на реальных заявках. Мы берём 50–100 прошлых обращений с известным исходом, прогоняем через скоринг и смотрим, попадает ли он в реальность. В сервисе сравнения поставщиков у нас похожая механика с весами 0.5 · цена + 0.3 · срок + 0.2 · надёжность — и там калибровка тоже делалась на архиве, а не из головы.

Что должно упасть в CRM

Карточка, к которой у менеджера нет вопросов, содержит немного:

• имя и контакт в том виде, в котором их можно набрать;
• одна строка сути задачи — не расшифровка диалога, а выжимка: «вентиляция, склад 2000 м², сентябрь, проекта нет»;
• балл скоринга и что именно его дало;
• срок, который бот пообещал клиенту (иначе менеджер нарушит обещание, о котором не знал);
• источник: канал, страница, кампания;
• полный текст переписки — вложением, чтобы не мешал глазу, но был под рукой.

Отдельно про интеграцию. С amoCRM и Битрикс24 связка делается через вебхуки и занимает пару дней. Дольше всего идёт не техническая часть, а согласование обязательных полей: у половины компаний в CRM 40 полей, из которых заполняются четыре.

Момент передачи человеку

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

Жёсткие правила, которые мы прописываем всегда:

1. Слова «оператор», «человек», «менеджер» в любом падеже — мгновенная передача, без уточняющих вопросов.
2. Второй подряд ответ «не понял вопроса» — передача. Три круга непонимания клиент не прощает.
3. Любой разговор о рекламации, браке, возврате денег — сразу человеку. Здесь цена ошибки выше экономии.
4. Нерабочее время — бот честно говорит, что сейчас ночь, фиксирует заявку и называет время ответа. Не изображает менеджера.
5. Клиент раздражён (грубость, капслок, восклицательные знаки) — эскалация плюс алерт руководителю.

Что мерить до и после

Замеряйте до запуска, иначе через месяц спор о пользе будет спором мнений.

Время первого ответа. Считайте отдельно по рабочим часам и по ночам-выходным. Именно вторая цифра меняется драматически: с десятков часов до секунд.

Доля заявок с заполненными полями. Обычная картина «до»: суть задачи есть в 30–40% карточек, остальное — «клиент интересовался». После — под 90%, потому что бот не забывает и не ленится.

Доля заявок, до которых вообще дошли. Потерянные ночные обращения мало кто считает, а это самая обидная утечка.

Сколько минут менеджер тратит на первичку. Замерьте на неделе вручную. Отсюда считается экономия в деньгах.

Конверсия в следующий шаг — встреча, замер, счёт. Главная цифра, но смотреть на неё раньше чем через 4–6 недель бессмысленно: не наберётся статистики.

Бот должен признаваться, что он бот

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

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

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

Догон: два касания, а не пять

Часть заявок обрывается на середине — человек написал и пропал. Тут выручает короткая цепочка: напоминание через 40–60 минут («вы остановились на объёме, дописать?») и второе на следующий день с чем-то конкретным — временем звонка или готовым расчётом. Дальше тишина. Третье и четвёртое касание приносят отписки и жалобы, а не сделки; мы это проверили и цепочку урезали.

Что сломалось у нас на второй неделе

Контур запустили, метрики поехали вверх, а руководитель отдела пришёл с претензией: два хороших клиента ушли.

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

Чинили тремя правками:

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

Следом вылезла вторая история. Бот отвечал на вопрос «сколько стоит» цифрой из прайса, а прайс был оптовый. Люди приходили с этой цифрой к менеджеру и спорили. Цены из ответов мы убрали совсем: теперь бот называет диапазон и честно говорит, что точную сумму посчитает менеджер после уточнения объёма. Конверсия от этого не упала, а конфликтов не стало.

Где это не работает

Не ждите роста продаж от бота, если проблема не во входящем потоке. Если менеджер не перезванивает по горячим лидам, ИИ на первой линии просто быстрее донесёт их до того же нерабочего звена. Автоматизация хаоса даёт быстрый хаос.

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

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

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

Чек-лист перед запуском

• Кто принимает лида после бота? Нужна фамилия, а не «отдел продаж».
• Что происходит с заявкой ночью, в выходные и в отпуске ответственного?
• Проверен ли выход на человека? Тремя фразами: «оператор», «позовите менеджера», «хочу поговорить с человеком».
• Куда падает лид, если CRM недоступна? Резервный канал — почта или чат — должен быть, иначе заявки просто исчезнут.
• Есть ли готовые ответы на 20 частых вопросов? Без них бот превращается в анкету и раздражает.
• Замерены ли метрики «до»: время ответа, доля заполненных карточек, потери вне рабочего времени?
• Кто читает живые диалоги первые две недели и когда у него на это выделено время?

Частые вопросы

Сколько времени занимает запуск? Рабочий контур — одна-две недели, если каналы и CRM уже есть. Дальше три-четыре недели доводки по живым диалогам: правим формулировки, добавляем ответы, чиним скоринг.

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

А WhatsApp? Технически возможно, но официальный доступ у провайдеров платный, и это отдельная строка бюджета. Дешевле начать с Telegram и виджета на сайте, а WhatsApp подключать, когда контур доказал пользу.

Голосом можно? Своего голосового движка у нас нет — собираем на внешнем распознавании и синтезе плюс наша логика диалога. И честно: начинать лучше с текста. В тексте ошибка сценария стоит переписки, в голосе — испорченного разговора.

Сколько это стоит? Зависит от числа каналов, состояния CRM и того, есть ли у вас база ответов. Фиксированного прайса мы не публикуем: считаем после разбора процесса на аудите.

Первый шаг

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

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

Снабженец сводит это в одну таблицу руками. Потом сверяет каждую строку с номенклатурой в 1С. Потому что «Цемент М500 50 кг» и «Цемент портландский М-500, меш. 50кг» — это, вообще-то, одно и то же, а компьютер об этом не догадывается.

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

Что реально съедает время

Спросите снабженца, на что уходит день. Ответ будет не «выбор поставщика». День уходит на другое:

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

Собственно решение — какой поставщик лучше — занимает минуты. Остальное рутина. Её и надо снимать.

Прайсы приходят как попало

Первое, что должен уметь сервис, — разбирать чужие файлы без предварительной подготовки. Шапка на четвёртой строке, объединённые ячейки, колонка «Цена» называется «Стоимость с НДС», а поставщик не указан нигде, кроме имени файла.

Парсер ищет шапку сам и понимает синонимы колонок:

• материал — наименование, номенклатура, позиция, товар, ТМЦ;
• цена — стоимость, прайс, цена с НДС, цена за единицу;
• срок — поставка, отгрузка, срок в днях, «под заказ»;
• поставщик — берём из колонки, а нет колонки — вытаскиваем из имени файла.

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

Отдельная боль — единицы измерения. Метр погонный, штука, упаковка на 6 метров, тонна. Сравнивать позиции в разных единицах нельзя, а поставщики про это не думают. Приводим всё к общей единице и помечаем, где пересчитали. Иначе сравнение врёт, причём не на проценты, а в разы.

Сканы: OCR нужен реже, чем думают

Про то, как ИИ читает сканы, любят рассказывать первым делом. По факту это самая переоценённая часть.

Мы прогнали архив из 51 отработанного лота — заявки, конкурентные листы, счета. OCR понадобился ровно двум счетам. Остальные PDF оказались текстовыми: текст в них лежит внутри файла, его надо просто вынуть библиотекой (PyMuPDF), и это быстро и точно.

Порядок такой. Сначала достаём текстовый слой. Не вышло — тогда зовём Tesseract. Русскую модель берём из набора tessdata_best. На tessdata_fast мы потеряли пару дней: движок молча спотыкается, откатывается на английский и выдаёт латинскую кашу. Ошибки в логах нет. Результат — мусор.

Фото с телефона надо подготовить, прежде чем скармливать движку:

• перевести в чёрно-белый;
• увеличить в два раза;
• прогнать автоконтраст.

Без этого мелкий шрифт в накладной читается наполовину. Числа после OCR всегда смотрит человек — цену и количество мы автоматом в закупку не пускаем ни при каких настройках.

Ловушка гомоглифов

Теперь про грабли, ради которых стоило писать эту статью. В выгрузке номенклатуры из 1С 571 позиция числилась как «нет у поставщиков». Товар у поставщиков был.

Оказалось, что названия набраны вперемешку кириллицей и латиницей:

Глазами это не отличить вообще. Шрифт одинаковый, длина строки та же. А для компьютера «С» и «C» — разные символы, и любое сравнение проваливается молча: не ошибка, а пустой результат.

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

Лечится это одной функцией. В словах, где встретились оба алфавита, латинские двойники переводим в кириллицу. Чисто латинские слова — VALTEC, COMPACT, PN — не трогаем, иначе сломаем нормальные названия. Гоняем её первой, до всякого поиска.

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

Матчинг, который дообучается

Свести чужую строку с нашей позицией — сердце всей истории. Правила и нечёткое сравнение строк неплохо тянут трубы и метизы. На инструменте, электрике и расходке они сыплются. «Бита PH2x90» и «Бита РН-2 90мм» — человеку очевидно, что это одно и то же. Алгоритму нет.

Решение оказалось не в более умной модели, а в памяти. Мы взяли архив отработанных тендеров — папки с заявками, счетами и конкурентными листами — и вытащили оттуда пары «строка поставщика → наша позиция» в том виде, как их свёл живой снабженец. Стыковка шла по цене, которая в лоте уникальна, поэтому брак в память не попадал.

Из 51 лота получилось 1374 уникальные пары. Память сопоставлений выросла с 14 803 записей до 15 519 — плюс 716 новых, и почти все как раз в слабых категориях. Дальше система дообучается сама: каждая правка снабженца («нет, это не тот кабель») сохраняется и в следующий раз применяется автоматически.

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

Выбор поставщика: не только цена

Самое дешёвое предложение часто самое долгое. Мы считаем по каждой позиции балл, где цена весит 0.5, срок 0.3, надёжность поставщика 0.2. Веса настраиваются: у кого-то стройка горит, и срок важнее денег.

Что это даёт на реальных листах. На одном лоте выбор сервиса полностью совпал с протоколом отдела — приятно, но неинтересно. На двух других нашлись альтернативы дешевле на 82 720 ₽ и на 298 194 ₽ при сопоставимых сроках. Это не «ИИ умнее снабженца» — это человек физически не может каждый раз перепроверить 200 позиций по семи прайсам.

Разбор архива, кстати, показал любопытное: в 73% случаев отдел брал позицию у того, кто дешевле, а в 25% — консолидировал у лидера лота, чтобы не дробить поставку. Обе стратегии разумные, и система должна показывать оба варианта с разницей в деньгах, а не навязывать один.

Как результат попадает в 1С

Финал цепочки — не красивый отчёт, а данные в учётной системе. Сервис пишет JSON, в котором лежит всё, что нужно 1С:

• уникальный идентификатор позиции (уид) — чтобы 1С поняла, куда класть;
• ключ строки заявки;
• цена, срок поставки, ставка НДС;
• поставщик и дата, на которую цена актуальна.

Файл 1С забирает по таймеру. Никто ничего не перебивает руками.

Формат обмена согласуйте с вашим 1С-ником до начала работ. Этот пункт любят отложить «на потом», а потом он съедает три недели. Мы согласовывали поля до первой строчки кода — и не пожалели.

Как мы это провалили в первый раз

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

На реальном лоте вылезли «Кран шаровой 1/2» против «Кран шаровой 1/2 с американкой» — разные вещи, разница в цене заметная, а строки похожи на 92%. Автомат их склеил.

Что мы поменяли:

• автоприменение выключили совсем. Движок предлагает, снабженец подтверждает — одним кликом;
• совпадения ниже уверенного порога уходят в отдельный список «посмотреть глазами», а не в результат;
• каждое подтверждение запоминается, и в следующий раз эта пара уже не спрашивается;
• разные типоразмеры и исполнения (с американкой, под приварку, оцинкованный) вынесли в признаки, по которым позиции нельзя сливать даже при высокой похожести.

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

Чек-лист перед пилотом

Что стоит проверить у себя до того, как звать подрядчика:

• Сколько поставщиков реально шлют прайсы каждый месяц? Меньше пяти — автоматизировать нечего, хватит нормального шаблона Excel.
• В каком виде приходят файлы: Excel, PDF, фото, письма в теле сообщения?
• Есть ли у вас справочник номенклатуры, или позиции заводят прямо в заявке?
• Прогоняли ли номенклатуру на гомоглифы и дубли? Это десять минут и часто объясняет «поиск ничего не находит».
• Кто у вас 1С-ник и готов ли он согласовать формат обмена? Без него финал цепочки не собрать.
• Сохранился ли архив прошлых закупок — заявки, счета, конкурентные листы? Это топливо для памяти сопоставлений, и чем его больше, тем быстрее система становится полезной.

Частые вопросы

Сколько это стоит? Честно: фиксированного прайса у нас нет, потому что объём работ зависит от состояния ваших данных. Пилот на одном участке считается после разбора: сколько поставщиков, какие форматы, есть ли справочник. Цифру называем после аудита, а не по телефону наугад.

Нужно ли менять 1С? Нет. Обмен идёт файлом, который 1С забирает по расписанию. Конфигурацию не трогаем — это принципиально, потому что доработка чужой конфигурации стоит дороже всего остального проекта.

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

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

Где это не работает

Не ждите результата, если у вас нет номенклатуры. Когда позиции заводят как попало прямо в заявке, сопоставлять не с чем: сначала наведите порядок в справочнике. И делают это ваши люди, а не подрядчик. Месяц-полтора минимум.

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

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

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

Первый шаг

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

Заодно проверьте номенклатуру на гомоглифы, это делается скриптом за десять минут и часто объясняет, почему поиск «ничего не находит». Как выглядят похожие контуры на других участках — в кейсах; про то, откуда ИИ берёт правильные ответы, — в статье про базу знаний. А разбор вашего процесса закупок с оценкой, что даст эффект первым, — это AI-аудит, приходите с примерами файлов.

Позиции были. Просто в выгрузке из 1С слово «Сгон» набрано с латинской буквой C, «угольник» — с латинской y, а в «PN16» латинская N. Глазами не отличить никак, а поиск такие строки не видит вообще. Формально система не выдумывала — она честно не нашла. Для снабженца разница нулевая: ему дали неверный ответ, и он бы по нему закупился.

С этого начну разговор про галлюцинации. Вранья у ИИ несколько сортов, и придуманные факты — не самый опасный из них.

Пять способов соврать

Выдуманное число. Модель не знает точной цифры и подставляет правдоподобную. «Гарантия 12 месяцев» вместо 24, «срок поставки 5 дней» вместо 15. Самый дорогой тип: числа люди не перепроверяют, их переписывают в коммерческое предложение.

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

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

Ложное «нет». История с латинской C — как раз отсюда. Система не нашла и делает вывод «этого не существует». Отдельно коварно тем, что в логах выглядит как нормальная работа.

Уверенный тон на пустом месте. Вопрос вне базы, ответа нет, но модель отвечает — потому что её этому и учили. Проверить такой ответ можно только зная правильный, а если бы человек его знал, он бы не спрашивал.

Правило первое: ответ без источника не считается ответом

Канон, к которому мы пришли на инженерной платформе, звучит грубо, но экономит месяцы разбирательств: ни одного числа без ссылки на документ. Ассистент обязан вернуть вместе с ответом название файла, раздел и по возможности прямую цитату. Не «согласно регламенту», а «Положение о гарантии, ред. от 12.03.2026, п. 4.2».

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

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

Автотесты: контрольные вопросы и капканы

Для инженерной базы у нас 187 автотестов, и это не про красоту цифры. Это набор вопросов с заранее известными ответами, который прогоняется после каждого изменения базы.

Набор делится на три части.

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

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

Стыки — вопросы, ответ на которые лежит на границе двух документов. Здесь ловится склейка несовместимого.

Прогон занимает минуты, а ловит вещи, которые вручную не отследить. Классический сценарий: добавили в базу пять новых файлов, точность на старых вопросах упала с 19 из 20 до 15 — новые документы «перетянули» поиск на себя. Без тестов это заметит клиент.

Отдельная категория проверок — арифметика. Языковые модели считают плохо и уверенно. Любой расчёт (скидка, объём, сумма с НДС) надо выносить из модели в код: ИИ достаёт цифры и правило, а умножает калькулятор. Мы наступали на это дважды, прежде чем сделали правилом.

Право сказать «не знаю»

Модель по умолчанию угодлива. Чтобы она молчала, когда не знает, разрешение на «не знаю» надо выдать явно и подкрепить ограничениями:

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

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

Второй проход и короткий ответ

Две дешёвые настройки, которые заметно сбивают частоту вранья.

Первая — второй проход. Готовый ответ вместе с найденными фрагментами уходит на повторную проверку с единственным вопросом: каждое ли утверждение подтверждается текстом источника? Что не подтверждается — вычёркивается. Платите вы за это удвоенным временем ответа (условно, три секунды вместо полутора) и двойным расходом на модель. В болтовне с клиентами оправдано не всегда, в расчётах и договорах — практически всегда.

Вторая — жёсткий лимит длины. Чем длиннее ответ, тем больше в нём отсебятины: в найденных фрагментах фактов на три предложения, а модель послушно пишет десять и добирает разницу из воздуха. Мы держим ответ в 3–5 предложениях плюс ссылка на документ. Нужны подробности — человек открывает источник, там всё есть.

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

Что писать в лог

Лог — единственное, что превращает «он какую-то ерунду ответил» в решаемую задачу. Минимальный набор на каждый ответ:

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

Разбор инцидента

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

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

Как это выглядит на живом случае

Клиенту ушёл ответ с условиями, которых у компании нет: срок отгрузки со склада взят из одного документа, гарантия — из другого. Обе цифры настоящие. Комбинация — выдуманная.

По логу видно всё за пять минут. Поиск вернул два фрагмента, у обоих в заголовке слово «Условия»: один из прайса для дилеров, второй из розничного регламента. Модель добросовестно собрала ответ из того, что дали.

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

Чек-лист: как проверить ассистента за полчаса

Работает и на своей системе, и на демо подрядчика:

• задайте пять вопросов, ответов на которые в базе точно нет. Правильная реакция одна — «не знаю»;
• на любой ответ с цифрой попросите источник: файл, раздел, цитату;
• дайте посчитать: скидка 17% от 143 600 ₽. Если считает сама модель, а не код, рано или поздно ошибётся;
• проверьте противоречие: спросите то, что по-разному написано в двух документах;
• спросите одно и то же тремя формулировками, как спросили бы разные сотрудники;
• попросите показать лог этого диалога. Нет лога — нет управляемости;
• узнайте, кто разбирает жалобы на неверные ответы и как часто.

Частые вопросы

Галлюцинации можно убрать полностью? Нет. Можно снизить частоту до единиц процентов и сделать ошибку заметной до клиента. Обещание «ноль ошибок» — повод усомниться в остальном, что говорит подрядчик.

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

Ассистент слишком часто отвечает «не знаю». Что делать? Смотреть логи отказов. В девяти случаях из десяти это не строгость настроек, а дырка в базе или разница в словах: люди спрашивают не теми терминами, что написаны в регламенте.

Кто отвечает, если неверный ответ ушёл клиенту? Компания. Ровно поэтому в чувствительных местах — деньги, сроки, гарантии, договоры — ответ уходит клиенту после человека, а не напрямую.

Где это не работает

Ни одна из этих мер не даёт нуля ошибок. Убрать галлюцинации полностью нельзя — можно снизить частоту и сделать так, чтобы ошибка была видна до клиента. Обещания «наш ИИ не врёт» — маркетинг, а не инженерия.

Цитаты-источники не спасают от кривых документов. Если в регламенте написана ерунда, ассистент честно процитирует ерунду со ссылкой. Мусор на входе даёт мусор на выходе, просто с адресом.

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

И самое неприятное: контроль стоит времени. Двадцать вопросов приёмки, разбор инцидентов, еженедельная сводка — это часы работы конкретного сотрудника каждую неделю. Компании, которые эту роль не выделяют, через пару месяцев получают систему, которой никто не доверяет, и разговор «ИИ у нас не взлетел». Дело не в ИИ.

С чего начать

Возьмите вашего текущего ассистента (или демо подрядчика) и задайте ему пять вопросов, ответов на которые в его базе нет. Если он ответит на все пять вместо честного «не знаю» — систему нельзя показывать клиентам, там нет ограничений.

Второй шаг: попросите на любой ответ с цифрой показать источник. Не получите файл и пункт — считайте, что цифра выдумана.

Как мы собираем контур с проверками, видно в кейсах — там же случай, где сверка номенклатуры разбирается подробно: ИИ в снабжении. А если хотите оценить риски на своих процессах — приходите на AI-аудит: посмотрим, где у вас цена ошибки высокая, и скажем, что там вообще нельзя отдавать ИИ без второй пары глаз.

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

Разберу по устройству, а не по вывеске.

Чат-бот: заранее нарисованное дерево

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

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

Слабость одна, зато обидная. Шаг влево от сценария, и бот беспомощен. Клиент пишет «а если я заберу сам в субботу, будет дешевле?», а в дереве такой ветки нет.

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

ИИ-агент: цель, инструменты, память, действия

Агент отличается четырьмя вещами. Уберите любую, и агент превращается обратно в говорящего бота.

Цель. У агента есть задача с проверяемым результатом, а не тема для беседы. «Собрать по входящей заявке пять полей, создать сделку в CRM и назначить ответственного» это цель. «Общаться с клиентами» это не цель, потому что непонятно, когда работа сделана.

Инструменты. Агент умеет вызывать функции:

• посмотреть остаток на складе;
• дёрнуть калькулятор доставки по адресу;
• найти клиента в CRM по телефону;
• записать строку в таблицу или создать задачу.

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

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

Действия. Агент меняет состояние систем: создаёт сделку, ставит задачу, отправляет письмо, двигает статус. Здесь же живёт главный риск, поэтому опасные действия закрываются подтверждением человека или жёсткой валидацией.

Сравнение на одной таблице

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

Как агент выглядит в работе

Возьму живой сценарий: заявка на монтаж оборудования с сайта.

1. Приходит текст в свободной форме: «Нужно смонтировать две вытяжки в кафе на Гоголя, желательно до конца месяца».
2. Агент вытаскивает поля: тип работ, адрес, объём, срок. Чего не хватает, спрашивает у клиента одним сообщением, а не анкетой из десяти пунктов.
3. Дёргает справочник услуг и отвечает вилкой цены с оговоркой «точная сумма после замера».
4. Создаёт сделку в CRM, прикладывает переписку, ставит задачу монтажнику на замер.
5. Пишет в чат отдела короткую карточку: адрес, объём, срок, телефон.

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

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

Где хватает обычного бота

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

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

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

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

Пять вопросов перед выбором

1. Что должно измениться в системах после диалога? Ничего не меняется, значит агент не нужен.
2. Сколько разных формулировок у одной и той же просьбы? Больше десяти, дерево веток вы задолбаетесь достраивать.
3. Есть ли документы, по которым нужно отвечать? Прайсы, регламенты, условия договоров тянут за собой RAG.
4. Кто отвечает за ошибку агента? У действия должен быть владелец с фамилией.
5. По какой цифре поймём, что получилось? Минуты на обработку заявки, доля ночных ответов, процент сделок, заведённых без менеджера.

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

Где агент не работает и чего от него не ждать

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

Он не заменяет переговоры. Сложная сделка с торгом, эмоциями и «а вот у конкурентов» остаётся человеку. Агент готовит почву: собирает вводные, поднимает историю, считает варианты.

Он не читает то, чего нет в системе. Договорённость из телефонного разговора, которую никто не записал, для агента не существует.

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

Отдельная ловушка это мода на «мультиагентные системы» на старте. Пять агентов, которые ходят друг к другу, отлаживаются втрое дольше одного, а результат тот же. Мы у себя пришли к простому правилу: один агент, одна зона ответственности, и обязательная проверка результата вторым, но только там, где цена ошибки реально высокая.

Наша ошибка: девять вопросов вместо трёх

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

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

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

Ещё два провала и чем они закончились

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

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

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

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

Чек-лист: с чего начать на своих данных

1. Выгрузите переписку с клиентами за последний месяц. Хоть из почты, хоть из Телеграма.
2. Разложите обращения на три кучки: типовые вопросы, заявки, всё остальное.
3. Посчитайте кучки. Соотношение сразу покажет, нужен вам бот, агент или оба.
4. По заявкам выпишите, какие поля менеджер вбивает в CRM руками. Это будущая схема разбора.
5. Найдите ответственного за содержание: кто отвечает за прайс, кто за регламенты, к кому идти за спорным случаем.
6. Отметьте действия, которые агенту нельзя доверять без подтверждения: счета, скидки, обязательства по срокам.

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

Короткие ответы на частые вопросы

Можно ли собрать агента на готовом конструкторе? Первую версию да, если конструктор умеет вызывать внешние функции. На интеграции с 1С и нестандартной логике конструкторы упираются, и проект переезжает в код. Начать с конструктора, чтобы проверить спрос, вполне разумно.

Нужен ли агенту доступ к 1С? Только на чтение и только к тому, что нужно для ответа: остатки, цены, статус заказа. Писать в учётную систему напрямую мы не даём, для этого есть CRM и задачи с человеком-владельцем.

Сколько времени занимает сборка? Простой агент с разбором заявок и записью в CRM собирается за 2-4 недели. Основное время съедает не ИИ, а доступы, справочники и согласование того, как процесс должен выглядеть.

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

Заменит ли агент менеджера? Он забирает подготовку: сбор полей, поиск истории, черновик ответа, заведение карточки. Разговор, торг и решение остаются человеку.

Что делать дальше

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

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

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

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

Оба раза виноват не ИИ. Виноват порядок работы с данными, которого не было. Ниже — список, который мы написали для себя, и он же ложится в регламент для сотрудников у клиентов.

Что не уходит во внешний сервис никогда

Пароли, токены, ключи доступа, файлы service account. Любой ключ, который хоть раз попал в чат — с ИИ или с человеком, — считается засвеченным и подлежит перевыпуску. Без обсуждений и «да ладно, там же приватный чат».

Персональные данные клиентов и сотрудников в исходном виде. ФИО с телефоном и адресом, паспорта, медицинские сведения, зарплаты. Отдельно — данные детей и всё, что относится к специальным категориям.

Сканы документов «как есть». Договор целиком, где на первой странице реквизиты, а в конце подписи и печати. Загружают такое чаще всего по одной причине — лень вырезать нужный кусок.

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

Исходный код с секретами и внутренними адресами. Отправляя фрагмент, вы отправляете и .env рядом, если он попал в выделение.

Материалы дел и переписка с юристами. Здесь риск не только утечки: у такой информации бывает особый статус.

Серая зона: можно, но после обработки

Большая часть рабочих задач сюда и попадает — и это хорошая новость, потому что обезличивание решает проблему дёшево.

Претензию клиента можно разобрать, заменив имя на «Клиент А», а номер договора на «№ХХХ». Прайс — прогнать без названий поставщиков. Резюме кандидата — вырезать контакты и оставить опыт. Договор — отправить один спорный пункт, а не весь файл.

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

152-ФЗ простыми словами

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

Что стоит понимать бизнесу:

1. Персональные данные — это почти всё, что позволяет узнать человека. Не только паспорт: связка «имя + телефон» уже персданные. Номер заказа с адресом доставки — тоже.
2. Обрабатывать их можно на основании, а не «потому что удобно». Чаще всего это согласие человека или исполнение договора с ним. Согласие должно быть конкретным, а не «на любые действия».
3. Базы с персданными россиян должны находиться в России. Отправлять их во внешний сервис за периметром — как раз то место, где обычно и рвётся.
4. Подрядчик обрабатывает данные по поручению. Отношения оформляются документом, где написано, что можно делать с данными, а что нельзя. Устная договорённость тут не считается.
5. Штрафы за утечки перестали быть символическими — с 2025 года они привязаны к обороту компании. Это сильно изменило цену вопроса: раньше проще было заплатить, теперь дешевле сделать правильно.

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

Коммерческая тайна: без режима её не существует

Частая иллюзия — «у нас всё конфиденциально». Юридически коммерческая тайна работает, только если введён режим:

• утверждён перечень сведений, которые считаются тайной;
• документы промаркированы;
• сотрудники ознакомлены под подпись;
• доступ ограничен, и кто его получал — где-то записано.

Нет режима — нет и защиты. Ушедший менеджер, унёсший базу, ничего не нарушил.

Для ИИ-проекта это переводится в конкретное действие. Прежде чем решать, что можно отдавать модели, нужен список того, что вообще считается закрытым. Обычно у компании такого списка нет, и составление занимает вечер работы с директором. Заодно выясняется, что половина «секретов» лежит в открытом чате отдела.

Код, промпты и чужие модели

Три вещи, о которых редко думают.

Бесплатные тарифы публичных сервисов часто предполагают, что ваши данные используются для улучшения продукта. В платных корпоративных версиях эти условия обычно другие. Читать надо не рекламную страницу, а условия использования — и делать это до того, как отдел начнёт пользоваться сервисом, а не после.

Промпты — тоже актив. В хороший рабочий промпт зашита методика: как вы считаете, на что смотрите, какие пороги. Отдать такое наружу — отдать часть ноу-хау.

И лицензии. Код, сгенерированный ИИ, попадает в ваш продукт, а откуда взяты его куски — вопрос без гарантированного ответа. В критичных для бизнеса местах мы такой код читаем глазами и проверяем, а не вставляем целиком.

Локальный контур: когда нужен

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

Когда это оправдано:

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

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

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

Регламент для сотрудников: одна страница

Длинную политику никто не прочитает. Работает короткий список на страницу, который выдаётся вместе с доступом:

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

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

Что делать, если уже отправили

Отправили — бывает. Дальше важно не искать виноватого, а закрыть дыру по шагам.

1. Считайте секрет скомпрометированным. Пароль, токен, ключ — перевыпустить сразу, старый отозвать. Это делается за минуты и стоит ноль.
2. Разберитесь, что именно ушло. Один пункт договора — одна история, файл с базой клиентов — совсем другая.
3. Зафиксируйте письменно: дата, что ушло, куда, кто отправил. Не для наказания, а чтобы через месяц не восстанавливать по памяти.
4. Если уехали персональные данные — сразу к юристу. У компании могут быть обязанности по уведомлению, и сроки там короткие.
5. Почините процесс. Если человек отправил договор целиком, потому что вырезать нужный пункт было неудобно, — виновата не дисциплина, а отсутствие удобного инструмента.

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

Чек-лист гигиены на месяц

• Пройдитесь по репозиториям и общим папкам: нет ли там архивов и дампов? Секреты прячутся именно в них, а обычные проверки их не видят.
• Посмотрите, у кого остались доступы после увольнения. Обычно находится два-три забытых аккаунта.
• Проверьте, какими ИИ-сервисами реально пользуются сотрудники и в каких аккаунтах — личных или рабочих.
• Заведите шаблон обезличивания для типовых задач: разбор претензии, анализ договора, проверка резюме. Пять минут работы, а пользоваться будут ежедневно.
• Перечитайте условия сервиса, который используете чаще всего. Раз в полгода они меняются, и не всегда в вашу пользу.
• Уточните у подрядчика, где физически лежат ваши данные. Ответ «в облаке» — не ответ.

Частые вопросы

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

Обезличили — значит, безопасно? Почти. Смотреть надо на совокупность: «клиент из Сибая, склад 2000 м², заказ в августе» может указывать на конкретную компанию точнее, чем название. Убирайте не только имена, но и приметы.

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

Что должно быть в договоре с подрядчиком? Где хранятся данные, кто из его сотрудников имеет доступ, что происходит с данными после окончания работ, NDA и порядок действий при инциденте. Мы такие пункты фиксируем сами, до старта, — так спокойнее обеим сторонам.

Наши данные попадут в обучение модели? Зависит от тарифа и сервиса. В бесплатных версиях — вполне вероятно. Читайте условия конкретного продукта, а не общие статьи в интернете, включая эту.

Чего не ждать

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

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

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

Первый шаг

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

Второй шаг — посмотрите, чем сотрудники пользуются сейчас. Не «что разрешено», а что стоит у них на телефонах. Картина обычно отрезвляет.

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

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

База знаний — не файлопомойка с поиском. Это отдельный продукт, который надо спроектировать, собрать и потом кормить. Ниже — как мы это делаем сейчас, после нескольких заходов на грабли.

Что в базу класть нельзя

Сканы без текстового слоя. PDF, у которого каждая страница — картинка. Поиск по нему находит ровно ничего. Проверка занимает пять секунд: откройте файл и попробуйте выделить строку мышью. Не выделяется — нужен OCR. Мы гоняем такие файлы через Tesseract, и тут отдельная засада: русская модель из набора tessdata_fast битая. Движок на ней молча спотыкается, откатывается на английский и выдаёт латинскую кашу вместо текста. Брать надо tessdata_best, он весит около 15 МБ.

Презентации. Слайд — это тезис без контекста. «Срок согласования — 3 дня» на слайде живёт без ответа на вопрос «согласования чего и кем». Ассистент вытащит эту строку и уверенно отдаст её клиенту.

Переписка целиком. Выгрузка почты за год добавляет объём и отнимает точность: половина писем — договорённости, которые давно отменили.

Файлы с именами вроде «Положение_финал_2_испр(1).docx». Пока человек не скажет, какая из четырёх редакций действующая, ассистент будет цитировать случайную.

Excel с объединёнными ячейками и формулами. Разбирается в кашу. Если данные важны — выгружайте плоскую таблицу: одна строка, один объект, никаких шапок в три этажа.

Что годится

Скучные вещи. Действующие регламенты и инструкции в DOCX. Прайс-листы плоской таблицей. Ответы на частые вопросы, написанные человеком, а не собранные из переписки. Технические паспорта. Условия работы: гарантии, сроки, зоны выезда, что входит в стоимость и что не входит.

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

Как резать документ на куски

ИИ не читает файл целиком. Система находит несколько подходящих фрагментов и уже по ним формулирует ответ. Значит, качество упирается в нарезку.

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

Хороший способ — резать по заголовкам. Один смысловой раздел — один фрагмент. Если раздел большой, делим по подзаголовкам с перекрытием в пару предложений, чтобы мысль не рвалась. Рабочий ориентир по размеру — 300–800 слов на кусок.

Ещё один момент, который экономит много нервов: заголовок раздела надо дописывать в начало каждого фрагмента. Тогда кусок «не более 5 рабочих дней» превращается в «Гарантийный ремонт → Сроки → не более 5 рабочих дней», и поиск начинает попадать.

Шапка файла: шесть строк, которые решают половину проблем

В начало каждого документа базы мы ставим короткий блок:

• о чём документ — одной фразой;
• к какому отделу относится;
• с какой даты действует;
• кто владелец: фамилия, а не «отдел кадров»;
• откуда взяты цифры — приказ, договор, расчёт.

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

Это же правило страхует от главной беды: ответ без источника проверить невозможно. У нас в инженерной платформе канон жёсткий — ни одного числа без ссылки на документ, откуда оно взято. Подробнее про это в статье где ИИ врёт и как это ловить.

Версии регламентов — главная головная боль

Компания живёт, регламенты меняются, старые редакции остаются лежать. И ассистент цитирует ту, которую нашёл.

Что делаем мы:

• в базе лежит только действующая редакция, архив хранится отдельно и в поиск не попадает;
• дата вступления в силу пишется в шапке документа и попадает в каждый фрагмент;
• если два документа противоречат друг другу, ассистент обязан сказать об этом прямо, а не выбирать удобный;
• раз в квартал — сверка списка документов базы со списком действующих приказов. Занимает час, ловит по 3–5 протухших файлов.

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

У каждого раздела должен быть живой владелец

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

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

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

Люди спрашивают не теми словами

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

Лечится не магией, а списком синонимов, который ведётся руками. Мы держим его прямо в базе отдельным файлом: официальный термин, а рядом три-пять живых формулировок — как говорят клиенты, монтажники, менеджеры. Туда же идут расшифровки внутренних сокращений. «КС-2», «СКС», «ПНР» — в документах они на каждой странице, а новичок и клиент их не знают.

Пополняется список из логов. Раз в неделю смотрим вопросы, на которых ассистент развёл руками, и добрая половина оказывается не пробелом в базе, а разницей в словах.

Чтобы база не протухла

Живая база — та, у которой есть постоянный входящий поток изменений. Работают три канала:

• вопросы без ответа за неделю — коротким списком владельцам разделов, дальше их решение: дописывать или нет;
• жалобы «ответил неправильно» — разбирается каждая, и по итогу правится документ, а не промпт;
• изменения в компании: новый прайс, новая услуга, свежая редакция положения. Обновление базы должно быть вписано в процесс их утверждения, иначе про него просто забудут.

Часа-полутора в неделю на человека хватает. Меньше не выходит. Больше — сигнал, что база собрана криво, и надо возвращаться к структуре, а не героически её подпирать.

Отдельно про объём: расти база должна медленно. Сорок выверенных документов работают лучше четырёхсот «на всякий случай» — каждый лишний файл размывает поиск. Мы это видели на цифрах приёмки: после загрузки очередной пачки материалов точность на старых вопросах падала.

Приёмка: 20 вопросов, а не «вроде отвечает»

Перед запуском собираем список из двадцати реальных вопросов с заранее известными правильными ответами. Половина — простые, четверть — на стыке двух документов, ещё четверть — про то, чего в базе нет вообще (ассистент обязан честно сказать «не знаю»).

Прогон по этому списку занимает полчаса и даёт понятную цифру: 17 из 20. Дальше видно, что чинить. Без такого списка приёмка превращается в спор о вкусах, и запускается система, которой никто не доверяет.

Где это не работает

Скажу честно. База знаний не спасает, когда знаний в компании нет — есть 15 лет устной традиции. В такой ситуации ИИ-проект превращается в проект по написанию регламентов, и это нормально, но сроки другие: не две недели, а два-три месяца, и основную работу делают ваши люди, а не подрядчик.

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

Не ждите точности 100%. Реалистичный ориентир для хорошо собранной базы — 90–95% верных ответов на типовых вопросах, при условии что оставшиеся 5–10% ассистент честно отдаёт человеку, а не выдумывает.

И последнее: база не заменяет обучение сотрудников. Она отвечает на вопрос «где написано», а не на вопрос «как думать».

Провал, который стоил нам двух недель

Расскажу подробно, потому что ошибка типовая.

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

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

Чинили так:

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

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

Чек-лист: что проверить перед стартом

• Есть ли у вас 20 вопросов, на которые ассистент обязан отвечать, и знаете ли вы правильные ответы?
• Какая доля документов — сканы? Проверьте выборочно: выделяется ли текст мышью.
• Сколько документов противоречат друг другу? Обычно находится две-три пары, и это нормально — важно решить, какой главнее.
• Назначен ли владелец у каждого раздела? Не отдел, а человек.
• Кто разбирает жалобы «ответил неправильно» и сколько времени в неделю на это заложено?
• Где проходит граница: что живёт в базе знаний, а что берётся из учётной системы?
• Как сотрудники будут спрашивать — в Telegram, в веб-кабинете, внутри CRM? От этого зависит, будут ли пользоваться вообще.

Частые вопросы

Модель обучается на наших документах? Нет. Документы лежат в поисковой базе, модель их не запоминает — она получает найденные фрагменты в момент вопроса и формулирует ответ по ним. Убрали документ из базы, и ассистент про него больше не знает.

Сколько документов нужно, чтобы начать? Хватает 15–30 на один отдел. Больше на старте вредно: труднее проверять качество и понять, что именно ломается.

А если документы обновляются каждую неделю? Нормальная ситуация. Обновление базы должно занимать минуты и делаться тем, кто правит документ, а не подрядчиком по заявке. Если для замены файла нужно писать в поддержку, база умрёт.

Можно ли дать доступ клиентам, а не только сотрудникам? Можно, но база для клиентов собирается отдельно. Внутренние регламенты, себестоимость и переписка туда попадать не должны — про это есть отдельный разбор.

С чего начать на следующей неделе

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

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

Про механику я писал отдельно: как ИИ отвечает по вашим документам. Про сборку — тоже: структура, форматы, нарезка. Эта статья про то, что начинается после демо. Роли, доступы, порядок обновления документов, критерии приёмки и цифры, по которым видно: система живая или уже покойник.

Кто владелец базы (спойлер: не ИТ)

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

Работающее распределение — три уровня плюс контроль.

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

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

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

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

Права доступа: фильтр до поиска, а не после

Во внутреннем ассистенте строительной группы у нас 21 аккаунт: 20 отделов и директор. Поиск идёт по 798 фрагментам из 155 файлов, и бухгалтерия не видит договоры продаж, а снабжение не видит расчёты по зарплате.

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

Матрица доступа помещается на одну страницу и делится на три контура:

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

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

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

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

Обновление документов: кнопка у владельца, а не заявка в ИТ

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

Что мы делаем:

1. Обновление базы вписывается в существующий процесс утверждения документа. Подписали новую редакцию положения — в том же маршруте есть шаг «загрузить в базу знаний». Не отдельный ритуал, а строчка в уже работающем регламенте.
2. Кнопка «обновить раздел» — у владельца раздела. Переиндексация занимает минуты, никакого разработчика для этого не нужно.
3. Старая редакция уезжает в архив, который лежит вне индекса. Не удаляется — просто не участвует в поиске.
4. Раз в квартал — сверка списка документов базы со списком действующих приказов. Час работы, стабильно ловит три-пять протухших файлов.

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

Приёмка: цифры вместо «вроде отвечает»

Приёмку надо описать до старта работ, иначе она превращается в спор о вкусах. Наш стандартный протокол — 30 вопросов с заранее известными ответами:

• 15 простых, ответ лежит в одном документе;
• 8 на стыке двух-трёх документов;
• 7 про то, чего в базе нет вообще — здесь правильный ответ «не нашёл».

Пороги, при которых система считается принятой: не меньше 25 верных ответов из 30, ноль уверенно неправильных, 100% ответов со ссылкой на источник, 15 из 15 по тесту изоляции доступов. Уверенно неправильный ответ — единственный критерий с нулевым допуском: отказ можно пережить, вранье со ссылкой — нет.

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

Куда встраивать, чтобы пользовались

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

Перенесли в Telegram-бота со входом по ссылке — и вопросы пошли. Люди спрашивают там, где уже сидят весь день. Внутренний портал, CRM, почта — тот же принцип: ассистент должен быть в одном клике от рабочего окна.

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

Метрики, по которым видно правду

Главная из них — первая. Точность 95% при трёх пользователях означает, что денег вы не вернёте.

Где это не работает

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

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

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

И не ждите, что можно один раз внедрить и забыть. Час-полтора в неделю на владельца раздела — это постоянная нагрузка, а не проектная. Компании, которые не готовы её нести, получают мёртвую базу через квартал, независимо от качества подрядчика.

Провал, который стоил доверия

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

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

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

Частые вопросы

Сколько людей нужно со стороны компании? Один владелец системы, по одному владельцу на подключаемый отдел и один человек от ИТ. Для пилота на два отдела это три-четыре человека с суммарной загрузкой около шести часов в неделю.

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

Что делать, если владелец раздела уволился? Роль передаётся вместе с должностью, и это записывается в регламент. Раздел без живого владельца замораживается: документы остаются, но помечаются как неподтверждённые, и в ответах появляется предупреждение.

Сколько занимает внедрение? Пилот на один отдел — две-четыре недели, из них половина уходит на сбор и чистку файлов на вашей стороне. Разворачивание на всю компанию — два-три месяца, отдел за отделом, а не всё сразу.

Сколько это стоит? Своего прайса мы не публикуем: цена считается после разбора процесса. Для ориентира — рыночные вилки на середину 2026 года: коробочная RAG-система 150-300 тыс. ₽, сопровождение 15-50 тыс. ₽ в месяц. Это цифры рынка, а не наше предложение; ваша сумма зависит от состояния документов и числа интеграций.

Что сделать на этой неделе

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

Дальше — пилот на одном отделе: 15-30 файлов, 30 контрольных вопросов, две недели живой работы. Как выглядят собранные контуры, показываю в кейсах. Хотите понять, что даст эффект первым и стоит ли вообще начинать с базы знаний, приходите на AI-аудит — разберём процесс и скажем прямо, если в вашем случае выгоднее автоматизировать что-то другое.

Про сам диалог с клиентом и скоринг я разбирал отдельно: как ИИ квалифицирует заявку. Здесь — про вторую половину работы, которая никому не интересна на демо и определяет всё в проде: что именно агент записывает в CRM, как не плодит дубли, кому назначает сделку и что видит руководитель утром.

Что агент имеет право писать, а что нет

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

Наше рабочее правило: агент создаёт и дополняет, но не переводит и не закрывает. Он заводит лид, пишет в него всё, что узнал, ставит задачу и напоминание. Сдвиг по воронке дальше стадии «квалифицирован» — только человеком. Сумма сделки — только человеком. Причина отказа — человеком.

Последняя строка про «режется молча» — не мелочь. Битрикс24 обрежет длинный комментарий, и вы узнаете об этом, когда менеджер спросит, где вторая половина переписки.

Дубли: две минуты работы, которые экономят месяц ругани

Дубль появляется по трём причинам, и лечится каждая по-своему.

Разные форматы контакта. Перед любой записью телефон нормализуется: убираются пробелы, скобки, дефисы, ведущая 8 меняется на +7. Почта приводится к нижнему регистру. Простое правило, которое почему-то делают в последнюю очередь.

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

Повтор запроса при сбое. Сеть моргнула, контур повторил шаг, в CRM две одинаковые карточки. Лечится ключом идемпотентности: хеш из телефона, даты и первых ста символов текста, таблица уже обработанных заявок со сроком хранения неделя. Подробнее про эту механику — в разборе про надёжность контура n8n.

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

Кому назначать: правила, а не «на директора»

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

Что работает:

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

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

Что видит руководитель утром

Отчёты — та часть, ради которой руководитель вообще соглашается на проект. Дашборд внутри CRM смотрят единицы, а короткое сообщение в Telegram в 9:00 читают все.

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

Одна цифра, которую стоит завести отдельно: доля карточек, где заполнена суть задачи. До автоматизации типичная картина — 30-40%, остальное «клиент интересовался». После — под 90%, потому что агент не ленится и не забывает.

Что ломается при обмене

Собрал по своим шишкам. Это не теория, это список того, из-за чего звонили в субботу.

Лимиты API. У Битрикс24 ограничение на частоту запросов, и при всплеске заявок интеграция начинает получать отказы. Лечится очередью с паузой между запросами и повтором, а не увеличением скорости.

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

Обязательные и списочные поля. В CRM настроили обязательное поле «тип объекта» со списком из восьми значений. Агент пишет туда «склад», а в списке значится «Складское помещение» — карточка не создаётся, ошибка уходит в лог, заявка исчезает. Значения списков надо тянуть из CRM, а не хардкодить в промпт.

Часовые пояса. CRM в Москве, сервер в UTC, клиент в Новосибирске. Обещание «перезвоним до 12:00» превращается в разные 12:00 у трёх сторон. Хранить всё в UTC, показывать в часовом поясе клиента, писать в карточку явно.

CRM недоступна. Обновление, авария, кончилась лицензия. Заявка не должна теряться: резервный канал — письмо на общий ящик или сообщение в чат отдела с полным текстом, плюс очередь на дозапись. Терять обращение из-за чужого сбоя нельзя.

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

Как это выглядело в аварии

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

Утром руководитель отдела увидел «рекордный день по лидам» и обрадовался. К обеду разобрались, и радость кончилась: чистить пришлось руками, потому что автоматическое слияние в CRM склеило часть комментариев не с теми контактами.

Что переделали:

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

Три часа работы. Если бы это было сделано сразу, не было бы ни двухсот карточек, ни ручной чистки.

Где это не работает

Автоматическое заполнение CRM не чинит продажи. Если менеджер не перезванивает по горячим лидам, агент просто быстрее и аккуратнее донесёт их до того же места, где они умирают.

Не работает и там, где CRM по факту не используется. Компания, которая ведёт сделки в тетради и в WhatsApp, от интеграции получит красивую базу, в которую никто не смотрит. Сначала процесс, потом автоматизация.

Плохо ложится на длинные B2B-сделки с десятком участников. Первый контакт там — уже экспертный разговор, и роль ИИ другая: поднять историю, собрать контекст, подготовить менеджера к звонку.

И честно про объём работ: техническая связка с amoCRM или Битрикс24 делается за пару дней. Дольше всего идёт согласование того, какие поля обязательные и кто за какое направление отвечает. Это разговор с руководителем отдела, а не с программистом, и он занимает недели.

Частые вопросы

Агент сможет работать с нашей самописной CRM? Если у неё есть API — да. Если нет, остаётся обмен файлами по расписанию: так мы работаем с 1С, там обмен идёт JSON-файлами по таймеру. Медленнее, но надёжно.

Как не дать ИИ испортить существующие сделки? Правами интеграционного пользователя. Создание лидов и комментарии — можно, изменение суммы, стадии и удаление — нет. Проверять это надо на тестовой воронке, а не на боевой.

Что если модель напишет ерунду в карточку? Поэтому в карточке два поля: выжимка от модели и полный текст диалога. Менеджер видит источник и может перепроверить за десять секунд. Черновик от ИИ, решение за человеком.

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

Сколько времени до первых результатов? Связка и первые карточки — неделя-две. Понятные цифры по конверсии — не раньше чем через полтора месяца, раньше не наберётся статистики.

Первый шаг

Выгрузите из CRM лиды за последний квартал и посчитайте две вещи: сколько карточек без сути задачи и сколько дублей по телефону. Обе цифры считаются за полчаса в Excel, и обе обычно неприятно удивляют.

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

С этого стоит начинать любой разговор про голосового ИИ. Не с того, «умеет ли он понимать речь» — умеет, и неплохо. А с того, что в голосе нет права на паузу, на переспрос и на второй заход. Текстовый бот, который ошибся, стоит переписки. Голосовой, который ошибся, стоит испорченного разговора и иногда клиента.

Где голос действительно к месту

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

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

Куда уходит время в звонке

Голосовой контур — это цепочка: телефония → распознавание речи → логика диалога и модель → синтез речи → обратно в трубку. Каждое звено тратит миллисекунды, и суммарный бюджет надо держать в пределах секунды-полутора.

Ориентиры, из которых складывается задержка: телефонный тракт 100-200 мс, распознавание при потоковом режиме 300-500 мс после конца фразы, ответ модели 400-800 мс, синтез 200-400 мс. Сложите — уже на грани.

Что помогает уложиться:

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

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

Что ломает распознавание

Списки «точность 95%» относятся к чистой студийной речи. Реальный звонок выглядит иначе.

Имена, фамилии, адреса. «Улица Тукая» превращается в «туская», «Гульнара» — в что угодно. Диктовка почты голосом — отдельный вид мучения. Решение простое: не спрашивать голосом то, что можно не спрашивать. Адрес и почту отправляем ссылкой в SMS, имя подтягиваем из CRM по номеру телефона.

Цифры и артикулы. Номер заказа, серия документа, код детали. Подтверждать по одной цифре и повторять услышанное целиком: «записал двести сорок семь, верно?».

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

Речь живого человека. Люди не говорят готовыми фразами. «Ну это, мне бы... да, наверное, в четверг, хотя нет, лучше в пятницу». Сценарий, написанный из головы, такие ответы не переваривает. Первые сто разговоров надо слушать ушами — именно там находится то, чего не придумаешь за столом.

Передача человеку: правила без исключений

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

1. Слова «оператор», «человек», «менеджер», «живой» в любой момент разговора — мгновенный перевод. Не в конце меню, не после уточняющего вопроса.
2. Второй подряд ответ «не расслышал» — перевод.
3. Темы-стопы: рекламация, брак, возврат денег, любая жалоба. Сразу человеку, без попытки уточнить.
4. Эмоция в голосе (повышенный тон, мат) — перевод плюс алерт руководителю.
5. Молчание в трубке дольше пяти секунд дважды — робот прощается и оставляет заявку на перезвон, а не мучает вопросами.

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

Если операторов сейчас нет (ночь, выходной), робот честно говорит об этом, называет конкретное время ответа и фиксирует заявку. Не «мы свяжемся с вами в ближайшее время», а «менеджер перезвонит завтра до 12:00».

Закон и вежливость

Три вещи, которые надо решить до запуска, желательно со своим юристом.

Робот обязан представиться роботом. В первые секунды, без вариантов. Человек всё равно поймёт через три реплики — по скорости ответа, по идеальной дикции, по тому, что «Ирина» бодра в три часа ночи. Обманутый собеседник злится уже не на робота, а на компанию.

Запись разговора — с уведомлением. Фраза про запись звучит в начале, записи хранятся ограниченный срок и лежат там, где к ним нет доступа у всех подряд. Это персональные данные со всеми вытекающими.

Исходящая реклама — только с согласия. Закон о рекламе прямо требует предварительного согласия абонента на рекламные звонки и сообщения. Обзвон собственной базы с сервисной информацией (напоминание о визите, статус заказа) и рекламный обзвон холодной базы — юридически разные вещи, и вторая без согласия заканчивается штрафом. Время звонков тоже стоит ограничить руками: робот не должен звонить в 21:30, даже если технически может.

Что мерить

Третья строка — та, ради которой всё считается. Формально закрытый звонок, после которого человек перезванивает и требует оператора, это не экономия, а перекладывание работы с ночи на утро.

Провал: «да, но давайте в четверг»

Мы тестировали робота на подтверждении встреч. Сценарий выглядел безупречно: здравствуйте, у вас назначено на вторник в 14:00, подтверждаете? Ответ «да» — спасибо. Ответ «нет» — передаю менеджеру.

Живые люди отвечали иначе. «Да, но давайте лучше в четверг». «Подтверждаю, только я подъеду попозже». «А можно перенести?» Робот слышал слово «да» в начале фразы, радостно прощался и вешал трубку. Встречи срывались, а в системе они стояли подтверждёнными — то есть хуже, чем если бы никто не звонил вообще.

Разбирали по записям, нашли за полчаса. Чинили тремя правками:

• любое отклонение от чистого «да» или «нет» — не догадка, а перевод на человека либо ветка переноса с конкретными вариантами времени;
• робот повторяет итог вслух: «записал, переносим на четверг, 14:00, верно?» — и ждёт подтверждения;
• в карточку пишется расшифровка, а не только результат «подтверждено», чтобы менеджер видел настоящие слова клиента.

Вывод, который стоил нам десятка сорванных встреч: в голосе нельзя интерпретировать. Понял однозначно — действуй. Не понял — отдай человеку. Середины не бывает.

Где голос не работает

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

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

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

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

Частые вопросы

Клиенты не будут бросать трубку? Часть бросит, это нормально. Смотрите на цифру брошенных в первые пять секунд: если она выше 15%, проблема в приветствии — оно длинное или звучит как реклама. Короткое честное представление работает лучше вежливых оборотов.

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

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

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

Сколько занимает запуск? Простой сценарий на два-три вопроса — две-три недели вместе с телефонией. Дальше месяц доводки по записям живых разговоров, и он обязателен: без него робот останется таким, каким его придумали за столом.

С чего начать

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

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

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

Как собирается базовая цепочка «форма → ИИ → CRM → уведомление», я разбирал в статье про первый сценарий в n8n. Здесь — про то, что превращает такую цепочку в контур, которому можно доверить входящий поток компании.

Четыре требования вместо слова «стабильно»

Договоритесь с собой (и с заказчиком) о том, что именно вы обещаете. Формулировки должны быть проверяемыми.

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

Разделите приём и обработку

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

Рабочая схема — две части.

Приём. Вебхук делает минимум: проверяет секретный заголовок, кладёт сырое тело запроса в хранилище (таблица в PostgreSQL, отдельная база, на худой конец Google-таблица) со статусом new и сразу отвечает сайту 200 OK. Занимает миллисекунды, падать тут нечему.

Обработка. Отдельный сценарий раз в минуту берёт записи со статусом new, гоняет их через модель и CRM, меняет статус на done или failed. Упала модель — запись осталась в очереди и будет обработана, когда всё поднимется.

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

Ретраи: не все ошибки одинаково полезны

Повторять вслепую — верный способ получить двести карточек в CRM вместо сорока. Ошибки надо различать.

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

После исчерпания попыток запись уходит в отдельную очередь — по-взрослому это называется dead letter. Не удаляется, не теряется, ждёт человека. Раз в сутки её содержимое приходит списком в чат: «5 заявок не обработаны, причины такие-то».

Идемпотентность в пять строк

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

// Code-нода: ключ идемпотентности
const crypto = require('crypto');
const phone = ($json.phone || '').replace(/\D/g, '').replace(/^8/, '7');
const raw = phone + '|' + ($json.text || '').slice(0, 100) + '|' + new Date().toISOString().slice(0, 10);
return [{ json: { ...$json, phone, idem_key: crypto.createHash('sha1').update(raw).digest('hex') } }];

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

Логи, по которым разбор занимает минуты

Журнал выполнений n8n показывает, что происходило, но искать в нём конкретную заявку неудобно. Заведите собственную таблицу событий, по строке на шаг:

время | id заявки | шаг | статус | длительность мс | текст ошибки | попытка №

Три причины, почему это окупается на первой же аварии. Во-первых, поиск по телефону клиента находит всю его историю за секунду. Во-вторых, видно, какой шаг тормозит: обычно это вызов модели, и цифры позволяют спорить предметно. В-третьих, история выполнений в самом n8n чистится (и должна чиститься — база пухнет и валит сервис), а ваша таблица остаётся.

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

Алерты: ошибки и тишина

Два типа сигналов, и второй важнее.

По ошибке. У каждого рабочего сценария подключён Error Workflow: упало — в чат летит сообщение с названием сценария, шагом и текстом ошибки. Не «произошла ошибка», а конкретика, по которой понятно, звать разработчика или это протух токен.

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

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

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

Когда упало ночью

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

ЧТО ДЕЛАТЬ, ЕСЛИ ПРИШЁЛ АЛЕРТ

1. Открыть таблицу очереди. Записи со статусом new не пропали?
   Есть — заявки в безопасности, паниковать не нужно.
2. Посмотреть текст ошибки в сообщении:
   - "401/403" -> протух токен CRM. Перевыпустить в Credentials, включить повтор очереди.
   - "429" -> лимит API. Ничего не делать, разгребётся само за час.
   - "ECONNREFUSED/таймаут" -> сервис недоступен. Проверить, открывается ли CRM в браузере.
   - "не JSON" -> модель вернула мусор. Заявки в ручной очереди, разобрать утром.
3. Если очередь пустая, а заявки не идут -> проблема на входе.
   Отправить тестовую заявку с сайта, проверить адрес вебхука.
4. Ничего не понятно -> написать в чат, заявки не теряются, ждут в очереди.
   НЕ перезапускать сценарий пачкой: получите дубли.

Последняя строка написана кровью. Дежурный, который в панике жмёт «повторить всё» пять раз подряд, вредит сильнее самой аварии.

Версии, бэкапы и правка на живом

Сценарии — в git. n8n умеет отдавать процесс в JSON. Экспорт раз в сутки в репозиторий даёт то, чего в интерфейсе нет: историю изменений и ответ на вопрос «что мы правили перед тем, как всё сломалось».

Секреты — в Credentials, а не в полях нод. Тогда экспортированный JSON можно спокойно отдать коллеге и положить в репозиторий.

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

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

Разбор: как мы поймали тихую потерю заявок

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

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

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

Третье: у нас на одном из серверов исходящие запросы к api.telegram.org резались провайдером, и уведомления не уходили. В интерфейсе это выглядело как «иногда не работает». Диагностика заняла в разы больше времени, чем сама починка через релей.

Итог: сторож на тишину, технический пользователь, очередь и honest-логи. Полтора дня работы, после которых по этому контуру не было ни одного разговора «а где заявка».

Чего от такого контура ждать не надо

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

Он не даёт транзакций между системами. Если запись в CRM прошла, а уведомление не ушло, откатить первое нельзя — можно только заметить и дослать. Отсюда правило: сначала делаем то, что дороже потерять.

Он не спасает от чужих сбоев, только смягчает их. CRM лежит два часа — заявки будут ждать в очереди, но менеджеры за эти два часа никому не перезвонят.

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

Частые вопросы

Сколько нод занимает такой надёжный контур? Приём — три-четыре ноды, обработка — восемь-двенадцать вместе с проверками, сторож и Error Workflow — по три. Итого около двадцати вместо шести в учебном примере. Разница и есть цена надёжности.

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

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

Кто должен дежурить по контуру? Обычно тот же человек, кто отвечает за CRM. Разработчик нужен на настоящие поломки, а девяносто процентов алертов — это протухший токен или упавший чужой сервис.

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

Что сделать в ближайший вторник

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

Как выглядят собранные контуры с очередью, сторожем и логами, показываю в кейсах. Хотите, чтобы кто-то посмотрел на вашу автоматизацию со стороны и назвал места, где она молча теряет заявки, — это AI-аудит: разберём схему, проверим слабые звенья и скажем, что чинить первым.