Настройки cookie
Технические — всегда включены
Аналитические (Яндекс.Метрика)
Маркетинговые (VK Pixel)
Вебинар 28 МАЯ · 12:00 МСК
Вебинар Как выбрать хелпдеск в 2026: тренды индустрии техподдержки ИИ, требования к безопасности и импортозамещению, рост ожиданий пользователей
5 АВГУСТА · 12:00 МСК Получить доступ →
Демо
Инструкция для сборки статьи SWARMICA Статья собирается из готовых блоков в библиотеке Tilda. Добавить блок можно так: «+» → «Мои блоки» → выбрать нужный блок из набора «Статья». Блоки можно копировать, переставлять, редактировать и удалять. Главное - не смешивать зоны статьи между собой и не менять технические настройки блоков, если они уже заданы. Общая структура страницы Страница статьи состоит из 5 зон: Верх статьи Лид-абзац Основная часть статьи Финальное завершение статьи CTA в конце статьи 1. Верх статьи В верхней зоне должны быть только блоки, которые относятся к началу статьи: ME605 Статья: хлебные крошки Навигация над статьёй. Ставится самым первым блоком. TL01 Статья: заголовок H1 и прочее Главный заголовок статьи. В этом блоке должен быть только H1. Описание / подзаголовок теперь выносится отдельно в лид-абзац. TX01 Статья: дата публикации Дата статьи. Ставится под H1. TX01 Статья: время чтения Время чтения. Ставится рядом с датой публикации. IM01 Статья: обложка Главная обложка статьи. Правильный порядок верхней зоны: ME605 Статья: хлебные крошки TL01 Статья: заголовок H1 и прочее TX01 Статья: дата публикации TX01 Статья: время чтения IM01 Статья: обложка Важно: в верхнюю зону не добавляем обычные текстовые блоки, H2, кнопки, выделения и CTA. 2. Лид-абзац TX01 Статья: лид-абзац Короткое вступление после hero-блока. Это первый смысловой абзац статьи. Лид-абзац не должен быть внутри H1-блока. Он стоит отдельно перед основной частью статьи. 3. Основная часть статьи В этой зоне собирается сам материал. Эти блоки можно копировать, переставлять и использовать несколько раз. TL01 Статья: заголовок 2-уровня H2 Заголовок раздела. TX01 Статья: текстовый блок Обычный текст статьи. TX01 Статья: фраза с выделением Важная мысль, вывод, предупреждение или смысловая врезка. TX01 Статья: подпись к изображению Подпись под изображением. Ставится сразу после изображения. CR47 Статья: кнопка для прочего Одиночная кнопка внутри статьи. Используется для перелинковки, перехода к кейсу, демо, чек-листу или другому материалу. Если в статье есть изображение внутри текста, используйте соответствующий блок изображения из библиотеки и сразу после него ставьте подпись. Пример структуры основной части: TX01 Статья: лид-абзац TL01 Статья: заголовок 2-уровня H2 TX01 Статья: текстовый блок TX01 Статья: фраза с выделением TX01 Статья: текстовый блок CR47 Статья: кнопка для прочего TX01 Статья: текстовый блок 4. Финальное завершение статьи Каждую статью важно замыкать финальными блоками. Они отделяют вывод от основной части и помогают шаблону корректно завершить материал. TL01 Статья: финальный заголовок H2 Финальный заголовок. Например: «Что в итоге», «Вывод», «Что делать дальше». TX01 Статья: финальный текстовый блок Заключительный текст статьи. После финального заголовка и финального текста не стоит добавлять новые обычные H2-разделы. Если статью нужно продолжить, лучше перенести финальные блоки ниже. 5. CTA в конце статьи После финальных блоков ставится призыв к действию: CR47 Статья: призыв к действию в конце Это отдельный финальный CTA. Его не нужно путать с блоком «CR47 Статья: кнопка для прочего». Разница: CR47 Статья: кнопка для прочего - обычная кнопка внутри статьи. CR47 Статья: призыв к действию в конце - большой финальный CTA после статьи. Короткая правильная схема статьи ME605 Статья: хлебные крошки TL01 Статья: заголовок H1 и прочее TX01 Статья: дата публикации TX01 Статья: время чтения IM01 Статья: обложка TX01 Статья: лид-абзац TL01 Статья: заголовок 2-уровня H2 TX01 Статья: текстовый блок Дополнительные блоки основной части при необходимости TL01 Статья: финальный заголовок H2 TX01 Статья: финальный текстовый блок CR47 Статья: призыв к действию в конце Что можно делать Можно копировать блоки основной части статьи. Можно менять порядок блоков внутри основной части. Можно добавлять несколько H2, текстовых блоков, подписей, выделений и кнопок. Можно редактировать текст, ссылки, изображения, подписи и кнопки. Что важно не делать Не смешивать блоки верхней зоны с блоками основной части. Не ставить обычные H2 и текстовые блоки выше хлебных крошек. Не писать лид-абзац внутри H1-блока. Не использовать финальный CTA как обычную кнопку внутри статьи. Не использовать обычную кнопку внутри статьи как финальный CTA. Не оставлять статью без финального заголовка и финального текстового блока. Не менять CSS name блоков, если он уже задан. Не использовать длинные CSS name: Tilda может их обрезать.

Почему ИИ не заменит базу знаний в техподдержке

04 августа 2026
5 минут
Зачем нужна база знаний техподдержки, если ИИ и так ответит клиентам?
Разговор о базе знаний сейчас почти всегда начинается с одного возражения: зачем вкладываться в написание статей, если ИИ ответит и так.
Возражение звучит убедительно ровно до момента, когда спрашиваешь — а откуда ИИ возьмет информацию?

ИИ отвечает на вопрос «как быстро информацию».
База знаний KCS отвечает на вопрос «откуда эта информация вообще возьмется».

Зачем нам KCS, если есть ИИ?

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

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

KCS (Knowledge-Centered Service) решает ровно одну задачу: сделать так, чтобы знание фиксировалось в момент своего появления и было доступно всей команде. ИИ решает другую: достать зафиксированное знание быстро и в нужной формулировке. Это не конкурирующие подходы. Это разные слои одной системы.

Что ИИ делает на самом деле

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

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

RAG (retrieval-augmented generation), на котором построено подавляющее большинство ИИ, устроен буквально так: найти документы → положить в контекст → сгенерировать ответ. Если поиск вернул пустоту, модель либо честно признает, что не знает, либо — что случается чаще и обходится дороже для компании — придумает ответ.
Отсюда важный вывод для тех, кто выбирает ИИ-ассистента: галлюцинация в поддержке — это почти всегда не дефект модели. Это отсутствие надежного источника знаний.

Откуда берется знание, которого нигде нет

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

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

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

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

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

Синергия KCS и ИИ

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

Возьмем самый долгий сценарий работы с обращением, когда агент создает черновик статьи с нуля. Из чего он состоит:
1.Скопировать тему обращения в название статьи.
2.Скопировать исходный вопрос клиента в блок «Симптомы».
3.Скопировать собственный ответ в блок «Решение».

Создание черновика статьи с нуля без ИИ

Методология описывает два контура:
— Solve loop — работа в моменте: найти статью / использовать / улучшить или создать новую. При этом проходит проверка на наличие дубликатов.

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

Что происходит, когда ИИ работает без базы знаний

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

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

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

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

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

Пять функций KCS, которые ИИ не выполняет

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

2. Язык клиента вместо языка разработки. Статья по KCS описывает проблему так, как ее формулирует обратившийся клиент: «не приходят письма о новых заявках», а не «SMTP relay возвращает ошибку 550». Это не косметика. От формулировки напрямую зависит, найдется ли вообще статья поиском.

3. Актуализация через использование. Принцип flag it or fix it: заметил неточность — исправь или пометь. Статья поддерживается и улучшается непрерывно теми, кто ей пользуется. Плановая же ревизия базы знаний раз в год — не работает успешно ни в одной организации. ИИ не знает, что статья устарела, если это нигде не отражено: для нее текст трехлетней давности выглядит ровно так же убедительно, как вчерашний.

4. Подтверждение переиспользованием. В KCS ценность статьи определяется тем, сколько раз она на практике закрыла обращение. Это дает естественную сортировку: работающее поднимается наверх списка, а невостребованное опускается.

5. Ответственность. У статьи есть автор и история изменений. Когда ответ оказался неверным, понятно, кого спросить и что исправить. У сгенерированного ИИ ответа автора нет. В корпоративной поддержке, где ошибка стоит денег, простоя или нарушения SLA, это не абстрактный аргумент, а вопрос управляемости.

А если ИИ станет заметно умнее?

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

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

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

Где ИИ действительно усиливает KCS

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

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

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

— Изменение tone of voice. Переписывание инженерной формулировки на язык клиента при публикации в портал самообслуживания.
Изменение tone of voice с помощью ИИ
Обратите внимание: во всех сценариях ИИ работает с материалом, который произвел KCS-процесс.

Почему KCS экономит токены ИИ

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

В базе знаний весь контекст хранится в статье. Агенту остается лишь выполнить поиск.

Метрики: почему доля автоматических ответов обманывает

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

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

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

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

Как это устроено в Swarmica

Swarmica построена вокруг KCS, а не как хелпдеск с приделанной wiki. На практике это означает несколько вещей:

Создание статьи живет внутри карточки обращения. Агент не переключается в отдельный раздел и не заводит вторую задачу — структура статьи доступна в момент работы, а связь «обращение — статья» проставляется автоматически и питает метрики переиспользования. Именно эта связь превращает link rate и reuse rate из отчетной формальности в рабочий инструмент.

Правки и флаги доступны всем, кто пользуется статьей, а не только владельцу раздела. Это прямая реализация flag it or fix it: база актуализируется потоком использования, а не плановой ревизией.

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

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

Наконец, поддержка Model Context Protocol реализована как инфраструктурный слой, встроенный в процессы: MCP дает моделям контролируемый доступ к сущностям системы, что позволяет строить агентные сценарии управления поддержкой и автоматизировать рутину, а не ограничиваться только ответами на вопросы пользователей. 
ИИ не заменяет KCS. Он повышает цену его отсутствия.
Получить консультацию эксперта
Часто задаваемые вопросы (FAQ)