Бот первой линии по базе знаний: как это устроено в Битрикс24 и где ломается

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

Технически это собирается в Битрикс24 без внешних сервисов и сложной обвязки: база знаний портала отдаётся по REST сразу в том виде, который удобен модели. Сложность не в этом. Она в том, что бот отвечает так, как написаны ваши документы, — и большинство провалов случается не из-за модели.

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

Встроенный AI-агент в открытых линиях

Готовый помощник Битрикс24. Отвечает клиентам в соцсетях, мессенджерах и виджете на сайте без оператора: рассказывает о продукте, отвечает на частые вопросы, помогает оформить заказ. Может заполнять карточку CRM данными из переписки и передаёт диалог сотруднику вместе с историей, когда ответа в базе нет или вопрос требует человека. Сотрудник может и сам перехватить диалог.

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

Что надо знать заранее:

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

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

Свой бот на REST

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

Собирается из готовых частей:

• imbot.v2.Bot.register — регистрация бота. Метод идемпотентный: повторный вызов с тем же кодом возвращает уже существующего бота, а не плодит новых.
• imopenlines.bot.session.message.send — отправка сообщения в диалог открытой линии.
• ai.engine.register — регистрация своей модели как AI-сервиса портала, если не хотите встроенную. Нужны права администратора и scope ai_admin.

Почему База знаний 2.0 — удобный источник

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

Три метода закрывают всю работу с источником.

note.document.tree.list отдаёт дерево документов одной базы знаний: идентификаторы, заголовки, вложенность. Архивные страницы в ответ не попадают — уже хорошо, отменённое не поедет в бота. У дерева есть внутренний предел в 5000 узлов, и если упёрлись, в ответе придёт признак truncated.

note.document.get возвращает сам документ. В ответе, кроме markdown, есть contentUpdatedAt, isArchived и isTrashed. Это важнее, чем кажется: по дате изменения содержимого можно переиндексировать только то, что правили, а по двум признакам — не тащить в индекс то, что убрали в архив или в корзину.

{
  "result": {
    "item": {
      "id": 42,
      "title": "Глава 1",
      "markdown": "# Глава 1\n\nТекст в Markdown...",
      "contentUpdatedAt": "2026-04-21T09:15:30+03:00",
      "isArchived": false,
      "isTrashed": false
    }
  }
}

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

Методы работают на коммерческих тарифах: на бесплатном REST к базе знаний отдаёт ACCESS_DENIED.

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

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

В каталоге моделей AI API Вайбкода у агентных моделей BitrixGPT контекст — 1 048 576 токенов: столько у 5.6 Agent 1M и у 6.0 Agent 1M. У шестой версии ответ до 131 072 токенов, есть рассуждение, и стоит она вдвое дешевле пятой с тем же контекстом: 50 и 200 Вайбов за миллион токенов входа и выхода против 100 и 400.

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

Бесплатные модели линейки — 5.5 и 5.5 Thinking с контекстом 262 144 токена, они видят изображения и умеют структурированный вывод. Агентные — платные.

Состав каталога зависит от ключа: бесплатные модели Битрикс24 видны всем, остальные появляются, если у ключа есть доступ к учётным данным провайдера. У моделей есть состояния ACTIVE, DEPRECATED и DISABLED — прежде чем завязываться на конкретную версию, стоит посмотреть её статус.

Почему ответы получаются неверными

Теперь главное. В проектах, которые мы видели, бот почти никогда не подводит из-за модели. Подводит то, что ему дали читать.

Две версии одной инструкции

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

Лечится это в документах: старую версию надо архивировать. После архивации она исчезает и из дерева документов, то есть из источника бота.

Таблицы вставлены картинками

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

Перенабрать таблицу текстом — скучная работа на несколько часов, которая даёт больше, чем любая настройка модели.

Документ отвечает не на тот вопрос

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

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

Не задано правило отвечать «не знаю»

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

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

Внутренний документ в ответе клиенту

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

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

Куда уходят данные

Куда уходит текст. Если вы работаете с персональными данными или с коммерческой тайной, ответ «в облако вендора» устраивает не всех, и это нормальный вопрос.

Короткий честный ответ: у встроенных инструментов обработка идёт на стороне поставщика модели, и в справке Битрикс24 прямо не указано, где именно выполняется каждый шаг. Если для вас это критично, вариантов три: включать BitrixGPT в коробочном портале и разбираться с его настройками, работать через AI API со своими ключами провайдера или подключать свою модель через ai.engine.register — в том числе развёрнутую на своём железе. Второй путь дороже и требует администрирования, но вопрос «где наши данные» закрывает полностью.

Этот разговор лучше провести до проекта, а не после того, как в бота загрузили всю базу регламентов.

С чего начинать

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

Сколько занимает запуск

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

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

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