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

Архитектура и техническое решение

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

1. векторная база данных — хранилище, способное искать информацию не только по ключевым словам, но и по смыслу;
2. LLM-модель, обрабатывающая естественный язык;
3. интерфейс взаимодействия — способ общения пользователей с системой.

векторная база данных — хранилище, способное искать информацию не только по ключевым словам, но и по смыслу;

Мы остановились на связке из Elasticsearch для векторного поиска и Ollama для запуска LLM-моделей, а в качестве интерфейса решили использовать нашего телеграм-бота. Такая система сначала ищет релевантные фрагменты документации, затем передает их в нейросеть и возвращает ответ пользователю.

Необходимые инструменты разместили внутри собственной инфраструктуры и на сервере, предоставленном коллегами из «Публичного облака» (CPU 64 cores / RAM 500 GiB / Disk 500 GB| GPU — A100 на 80 GB). Поскольку для реализации проекта мы выбрали open-source-модели, то смогли организовать работу нейросети — в том числе ее обучение и инференс — в изолированном защищенном контуре, без обращения к внешним системам. В результате данные остаются внутри нашей сети, требования к безопасности и конфиденциальности соблюдаются, а мы получили гибкость в управлении и масштабировании решения.

Как работает схема GetCourse + FileBrain + ChatGPT

Под капотом автоматических ответов — связка трёх систем: GetCourse, модуля «Воронки» (Refunnels) и сервиса.

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

Этот цикл занимает всего несколько секунд. Александр Воздвиженский отмечает, что среднее время отклика — 3–5 секунд, при этом каждый раз система проходит полный путь: вопрос пользователя → модуль «Воронки» → FileBrain → OpenAI → ответ.

Как настроить на стороне GetCourse

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

Рекомендуется задать аватарку, имя и должность — так проще отслеживать, от кого пришёл ответ. В поле «Фамилия» можно прописать должность, чтобы она всегда отображалась, например: Гарик, агент техподдержки.

Далее в разделе прав нужно отметить галочку «Может работать со входящими сообщениями».

Кроме того, стоит убедиться, что приложение GetCourse включено и отображается ученикам. Воздвиженский вспоминает случай, когда из-за отключённого статуса система не работала и команда потратила 3 часа на поиск причины.

Подключение модуля «Воронки»

Чтобы интеграция заработала, в GetCourse нужно активировать модуль «Воронки» (Refunnels). Если он не включён, достаточно открыть левое меню Apps → Приложения, найти «Воронки» и установить модуль.

После этого подключается плагин FileBrain Pro. В поля модуля вставляются API-ключ и Project ID из FileBrain, выбирается созданный сотрудник, от имени которого будет отвечать бот. Поле Prompt можно оставить пустым — все настройки уже встроены.

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

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

Возможности нейросетей на GetCourse

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

Настройка Elasticsearch для векторного поиска

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

Мы настроили систему анализаторов текста с поддержкой морфологии русского и английского языков. Hunspell-словари для русского и английского языков подключили вручную, поместив dic- и aff-файлы в директорию hunspell внутри контейнера Elasticsearch. Также реализовали фильтр e_char_filter, нормализующий «ё» в «е».

{ «settings»: { «index»: { «analysis»: { «tokenizer»: { «ngram_tokenizer»: { «type»: «ngram», «min_gram»: 1, «max_gram»: 2, «token_chars»: [«letter», «digit»], «custom_token_chars»: «.,-_» } }, «filter»: { «russian_stemmer»: { «type»: «stemmer», «language»: «russian» }, «ru_hunspell»: { «type»: «hunspell», «language»: «ru_RU» }, «en_hunspell»: { «type»: «hunspell», «language»: «en_US» }, «russian_stop_words»: { «type»: «stop», «ignore_case»: true, «stopwords»: [«и», «в», «во», «не», «что», «он», «на», «я», «с», «со», «как», «а», «то», «все», «она», «так», «его», «но», «да», «ты», «к», «у», «же», «вы», «за», «бы», «по», «только»] }, «english_stop_words»: { «type»: «stop», «ignore_case»: true, «stopwords»: [«i», «me», «my», «myself», «we», «our», «ours», «ourselves», «you», «your», «yours», «yourself», «yourselves», «he», «him», «his», «himself»] }, «word_delimiter»: { «type»: «word_delimiter», «catenate_all»: true, «preserve_original»: true } }, «char_filter»: { «e_char_filter»: { «type»: «mapping», «mappings»: [«Ё=>Е», «ё=>е»] } }, «analyzer»: { «ru_en_hunspell»: { «tokenizer»: «ngram_tokenizer», «filter»: [«lowercase», «ru_hunspell», «en_hunspell», «russian_stop_words», «english_stop_words», «word_delimiter»], «char_filter»: [«e_char_filter»] } } } } } }

Для эффективного поиска по смыслу мы выходим далеко за пределы обычного текстового поиска. Вместо простого сопоставления ключевых слов создаем сложную систему для понимания семантики и морфологии текста на двух языках.

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

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

• N-gram-токенизатор — разбивает текст не только на слова, но и на части слов, что позволяет находить совпадения даже при опечатках или разных словоформах.
• Словари Hunspell — определяют морфологию слов, позволяя системе понимать, что «машины», «машинам», «машин» относятся к одному корню.
• Фильтр стоп-слов — убирает из поиска слова, не несущие смысловой нагрузки (предлоги, союзы, местоимения), чтобы сосредоточиться на действительно значимых терминах.
• E-char-фильтр — решает классическую проблему русского языка с буквой «ё», заменяя ее на «е» для унификации.

N-gram-токенизатор — разбивает текст не только на слова, но и на части слов, что позволяет находить совпадения даже при опечатках или разных словоформах.

Словари Hunspell — определяют морфологию слов, позволяя системе понимать, что «машины», «машинам», «машин» относятся к одному корню.

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

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

Алгоритм поиска релевантных контекстов

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

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

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

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

• Динамический порог релевантности — мы не задаем фиксированное значение, а рассчитываем его на основе статистического распределения оценок для каждого запроса: sep = (scores) + ((scores) / 2).
• Формат запроса more_like_this — это особый тип запроса в Elasticsearch, который ищет документы, семантически близкие к заданному тексту. Параметры min_term_freq: 1 и min_doc_freq: 1 настроены для работы с небольшими документами в нашей базе.
• Структурирование контекстов для LLM — найденные фрагменты документации добавляются в запрос к языковой модели, сохраняя HTML-разметку для лучшего понимания структуры.

Динамический порог релевантности — мы не задаем фиксированное значение, а рассчитываем его на основе статистического распределения оценок для каждого запроса: sep = (scores) + ((scores) / 2).

Формат запроса more_like_this — это особый тип запроса в Elasticsearch, который ищет документы, семантически близкие к заданному тексту. Параметры min_term_freq: 1 и min_doc_freq: 1 настроены для работы с небольшими документами в нашей базе.

Структурирование контекстов для LLM — найденные фрагменты документации добавляются в запрос к языковой модели, сохраняя HTML-разметку для лучшего понимания структуры.

Подготовка качественных данных

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

• применимость;
• описание проблемы и ее воспроизведения;
• причина проблемы;
• решение проблемы;
• проверка решения.

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

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

использование системы меток для классификации (продукт, тип статьи, уровень доступа);

Настройка промптов и параметров модели

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

Ты помощник, который отвечает на вопросы, основываясь исключительно на предоставленных контекстах.Если ответы можно найти в контекстах, изложи их полно, не изменяя блоки с кодом.Если информация отсутствует, напиши: «Уточните вопрос, пожалуйста.».Если обнаружатся похожие контексты, и только в этом случае, напиши «‼ДУБЛИ» и выведи их номера.

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

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

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

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

Выбор языковой модели и «легендарный тест»

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

Для этого мы подготовили простую проверку, которую впоследствии стали называть «легендарный тест Ивана». Легендарным он стал из-за простоты и эффективности, а Иван — имя его создателя.

Суть теста: есть три статьи, каждая из которых описывает обновление продукта Basis Dynamix Enterprise (DXE) — до версии 4.0, до 4.1 и до 4.2. И только в одной из них — в обновлении DXE до 4.1 — упоминается необходимость в обновлении MongoDB.

«Тест Ивана» — это вопрос модели: «Нужно ли обновлять Mongo при обновлении DXE с версии 3.8 до версии 4.2». Модель должна по контекстам понять, что обновление поэтапное и что нужно обновлять Mongo на этапе обновления до 4.1. Т. е. правильный ответ «да», но он не очевиден.

Elasticsearch находил все материалы по обновлению Basis Dynamix Enterprise, мы отдавали их модели вместе с вопросом и оценивали ответ. Хорошая модель должна была найти информацию об обновлении MongoDB в документации к версии 4.1 и сделать правильный вывод, хотя в инструкции к 4.2 об этом ничего не сказано.

1. Точность ответов на основе нашей документации;
2. Техническая возможность запуска на имеющемся оборудовании.

По второму пункту — нам требовалась модель, которая целиком поместится в видеопамять. Как только модель не помещается в VRAM и начинает использовать процессор, работа с ней становится невозможной из-за падения скорости. Лучше всех под наши запросы подошла QWen/QwQ-32B с 32 миллиардами параметров от Alibaba.

От идеи к реализации

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

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

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

• скрипт для управления аварией;
• алгоритм действий, который позволяет минимизировать время на устранение инцидентов.

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

(Вообще, к метрике «Скорость устранения аварии» мы относимся серьезно, регулярно собираем и анализируем ее в едином дашборде Professional Services. Но это совсем другая история.)

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

Пример работы бота

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

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

# Отправка запроса в языковую модель ct = time() response = (MODEL_URL, headers=headers, json=payload, verify=False) if response.status_code!= 200: print(‘Wrong response code: ‘ + str(response.status_code)) await.reply_text(‘Wrong response code: ‘ + str(response.status_code)) return # Получение ответа и разделение на «размышления» и финальный ответ response = ()[‘message’][‘content’] response = (‘</think>’) think = response[0].replace(‘<think>’, »).strip() response = ‘</think>’.join(response[1:]) # Отправка блока «размышлений» модели пользователю thinks = chunk_string(think, 4070) for t in thinks: await.reply_text(‘<blockquote>’ + t + ‘</blockquote>’, parse_mode=’HTML’) # Разбиение ответа на части, если он слишком длинный для одного сообщения messages = split_markdown(escape_string(response), 4096) for m in messages: await.reply_text(m, parse_mode=’Markdown’) # Отправка информации об использованных контекстах и времени генерации if es_index!= »: stat = ‘*Scores and Contexts:*\n’ for i in range(len(titles)): stat += str(round(scores[i], 1)) + ‘ — [‘ + titles[i] + ‘](‘ + BASE_URL + tinyuis[i] + ‘)\n’ stat = stat + f’*Generation time {round(time() — ct, 2)}s*’ await.reply_text(stat, parse_mode=’Markdown’)

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

Эта часть кода показывает разделение ответа на «мысли» и финальный результат, а также форматирование и отправку этих частей пользователю.

• специальные теги — мы используем в промпте теги &lt;think&gt; и &lt;/think&gt;, чтобы модель структурировала свой ответ, отделяя процесс размышления от финального результата;
• форматирование «мыслей» — размышления модели оформляются как блоки цитат в HTML, визуально отделенные от основного ответа;
• метаданные ответа — после основного ответа бот отправляет дополнительное сообщение с информацией о релевантности использованных источников и времени, затраченном на генерацию. Это помогает пользователям оценить качество ответа.

специальные теги — мы используем в промпте теги <think> и </think>, чтобы модель структурировала свой ответ, отделяя процесс размышления от финального результата;

форматирование «мыслей» — размышления модели оформляются как блоки цитат в HTML, визуально отделенные от основного ответа;

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

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

Мы сделали функцию, которая умеет разбивать markdown-текст, сохраняя целостность блоков кода и других элементов форматирования.

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

умное экранирование — функция escape_string экранирует служебные символы Markdown (вроде * и _) только в обычном тексте, не затрагивая блоки кода, где это могло бы нарушить их функциональность;

управление длиной сообщений — код гарантирует, что ни одно сообщение не превысит лимит Telegram в 4096 символов, но при этом сохранит логическую структуру текста.

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

Что в результате

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

• стало проще работать с документацией;
• выросла скорость обучения новых инженеров;
• время выполнение рутинных операций сократилось на 20–50%;
• скорость решения типовых задач, связанных с написанием кода, увеличилась в 3–6 раз.

скорость решения типовых задач, связанных с написанием кода, увеличилась в 3–6 раз.

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

Вот, например, один из наших экспериментов: взяли пункт из ПМИ (программа и методика испытаний) — настройка группы безопасности и применение сетевого фильтра. Разработали промпт, нейросеть проанализировала API и сгенерировала код, который потребовал минимальных доработок и был внедрен за 10 минут. У человека одно только изучение API заняло бы значительно больше времени.

Эффект внедрения

Результаты внедрения нейросети на GetCourse измеряются конкретными цифрами. Главное — резкое сокращение времени ответа и разгрузка команды поддержки.

Скорость реакции

Если раньше пользователи могли ждать ответ 10–15, а иногда и 30 минут, то теперь сообщение обрабатывается за 5–30 секунд. Такой отклик особенно важен во время продаж и вебинаров, когда на платформу поступает поток однотипных запросов: «где ссылка», «как войти в личный кабинет», «будет ли запись».

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

Масштаб автоматизации

По данным кейсов, с которыми работает GetMechanic, от 25 до 80% входящих вопросов в онлайн-школах можно автоматизировать.

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

Время интеграции

Полная настройка занимает от 30 минут до 3 месяцев. Всё зависит не от сложности технологий, а от того, как быстро команда формирует базу знаний и тестирует сценарии.

Воздвиженский отмечает, что технически настроить схему GetCourse + ChatGPT можно за 20–30 минут, но процесс итеративный: сначала бот отвечает на один вопрос, затем к нему добавляют второй, третий и т. д. Система постепенно «обрастает» логикой и опытом.

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

Показатели и советы

Точность ответов — один из ключевых показателей эффективности нейросети. По данным Александра Воздвиженского, 95% ответов система выдаёт корректно «из коробки». При дополнительной настройке и расширении базы знаний показатель можно довести до 98–99%.

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

Лучшие практики

Александр Воздвиженский рекомендует всегда проверять стабильность ответов перед запуском и внимательно следить за качеством выдачи. Регулярное тестирование и уточнение базы знаний помогают держать точность системы на уровне 95–99%.

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

Себестоимость: человек против нейросети

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

Сколько стоит человек

Средняя зарплата сотрудника техподдержки — около 25 000 рублей в месяц. Если предположить, что он работает 8 часов в день и тратит 4 минуты на один ответ, его продуктивность составляет примерно 120 ответов в день, или 2 700 ответов в месяц.

Эта оценка справедлива при условии, что человек всё время отвечает на вопросы, не отвлекаясь на переписки, соцсети или звонки. На практике реальная производительность ниже.

Сколько стоит нейросеть

Подключённая к GetCourse нейросеть использует сервис. Абонентская плата за него составляет 5 000 рублей в месяц. Стоимость одного запроса — около 1 рубля, хотя фактические затраты на токены OpenAI редко превышают 3 копейки.

Если взять те же 2 700 ответов в месяц, получается: 5 000 руб. (абонентка) + 2 700 руб. (запросы) = 7 700 руб.

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

При увеличении объёма

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

Таким образом, при масштабировании система становится ещё выгоднее. Даже если часть вопросов (до 20%) остаётся за живыми специалистами, автоматизация позволяет существенно снизить затраты и повысить стабильность работы поддержки.

Спикер подчёркивает: «Мы не можем переложить на нейросеть 100% задач, но до 80% обращений она берёт на себя без потери качества».

Опыт Александра Воздвиженского показывает: GetCourse + ChatGPT — это не теоретическая возможность, а реальный рабочий инструмент для онлайн-школ. Нейросеть способна отвечать на вопросы персонализировано и быстро, брать на себя рутину техподдержки, снижая нагрузку на кураторов и менеджеров.

Главный эффект внедрения — сочетание скорости, персонализации и экономии.

За счёт автоматизации до 80% запросов снижается стоимость обработки сообщений, а качество коммуникации с учениками растёт.

* WhatsApp принадлежит компании Meta, признанной экстремистской организацией и запрещённой в РФ.

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

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

Частые ошибки при внедрении

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

Ошибка 1. Придумывать новые задачи для нейросети

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

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

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

Ошибка 2. Внедрять бота сразу во все процессы

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

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

Например, если в школе есть автовебинар и часто задают вопрос «Запись будет?», достаточно настроить бота на этот сценарий. Пусть нейросеть отвечает только на этот вопрос, а остальные запросы остаются за операторами.

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

Если бот не знает ответа — он просто молчит. Этого достаточно для начала интеграции.

Ошибка 3. Страх команды перед нейросетью

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

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

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

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

Будущее нейробота

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

• Цифровой техлид 2.0 — помощник, обученный на всех наших продуктах, базе знаний и истории ошибок. Он уже будет не только отвечать на прямые запросы, но и добавляться в аварийные чаты, чтобы анализировать контекст, логи и предлагать возможные решения.
• Аварийный менеджер — помощник по авариям, который ведет аварию по регламенту, напоминает инженерам о необходимых шагах: «А вы запросили информацию о влиянии на клиента?», «Не забудьте сообщить ориентировочное время восстановления». Аварийный менеджер будет вести хронологию, эскалировать при необходимости и подготавливать черновик аварийного отчета.
• Цифровой бадди — помощник для онбординга. Он проведет нового сотрудника по всему пути адаптации, ответит на вопросы и подскажет, куда обратиться. Аттестует сотрудника и оценит его зрелость в рамках нашей задачи по повышению зрелости команды.
• Карма проектов — тепловая карта проектов, созданная на основе анализа переписки в проектных чатах. Помощник будет следить за активностью в проектных чатах, выявлять признаки проблем и предупреждать менеджеров: «Посмотрите в этот чат, похоже, там что-то назревает».
• Интеграция с тикетной системой — ближайшие планы содержат подключение помощника к нашей тикетной системе. Он будет валидировать входящие тикеты, предлагать автоматические классификации и готовить черновики ответов для инженеров. После проверки специалистом эти ответы можно будет отправлять клиентам, а также обогащать свою базу знаний, которую будут использовать другие помощники. В перспективе мы рассматриваем возможность вывести бота «наружу» — сделать его прямым помощником для наших клиентов.

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

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

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

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

Часто задаваемые вопросы о настройке нейросети для ответов

Вопрос: Можно ли научить нейросеть отвечать на вопросы без программирования?
Ответ: Да, с помощью no-code платформ и готовых интеграций, таких как связка GetCourse и FileBrain, можно настроить базовые сценарии без написания кода.

Вопрос: Какие данные нужны для обучения нейросети?
Ответ: Нужна структурированная база знаний: FAQ, документация, скрипты ответов, история переписок. Качество данных напрямую влияет на качество ответов.

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

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

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

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

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

Вопрос: Нужно ли постоянно дообучать модель?
Ответ: Да, систему нужно периодически обновлять новыми данными и промптами, особенно при появлении новых продуктов, услуг или типовых вопросов.

Вопрос: Что выгоднее: сотрудник или нейросеть?
Ответ: На больших объемах однотипных запросов нейросеть, как правило, выгоднее из-за низкой предельной стоимости одного ответа и возможности масштабирования 24/7.

Вопрос: Можно ли использовать бесплатный ChatGPT для таких задач?
Ответ: Можно для тестирования и прототипирования, но для коммерческого использования рекомендуется платный API (например, GPT-4) из-за стабильности, лимитов, скорости и возможности тонкой настройки.

Краткий чек-лист по внедрению нейросети-помощника

1. Определите цель и конкретные задачи для автоматизации (например, ответы на частые вопросы клиентов).
2. Соберите и структурируйте базу знаний: документацию, скрипты, историю диалогов.
3. Выберите технологический стек (например, связка платформы, векторной БД и языковой модели).
4. Настройте векторную базу данных (например, Elasticsearch) для семантического поиска по вашим данным.
5. Разработайте и оттестируйте алгоритм поиска наиболее релевантных контекстов для вопроса.
6. Подберите и протестируйте языковую модель (проведите «легендарный тест» на сложных запросах).
7. Напишите и оптимизируйте системные промпты, которые будут управлять стилем и логикой ответов.
8. Настройте интеграцию с каналом коммуникации (чат на сайте, мессенджер, CRM вроде GetCourse).
9. Определите правила эскалации сложных вопросов к живому оператору.
10. Запустите пилотный проект на ограниченном потоке запросов или для тестовой группы.
11. Собирайте обратную связь и лог диалогов для анализа ошибок и дообучения.
12. Постепенно масштабируйте автоматизацию на новые типы запросов и процессы.
13. Регулярно мониторьте ключевые метрики: скорость ответа, процент автоматизации, CSAT.
14. Планируйте регулярное обновление базы знаний и промптов.