Как сформировать базу знаний компании для ИИ

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

База знаний компании — это договорённость о правде, а не папка с файлами

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

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

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

База знаний начинается не с загрузки файлов, а с решения, кто в компании имеет право сказать «это правда».

Одна база на всю ИИ-команду, а не свой справочник у каждого агента

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

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

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

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

Восемь разделов, без которых ИИ-команда пишет от себя

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

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

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

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

Метки важнее папок: продукт, аудитория, этап воронки, канал

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

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

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

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

Хорошая метка отвечает на вопрос «кому и когда показывать эту запись», плохая — на вопрос «про что она».

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

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

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

За дверью остаются персональные данные клиентов, реквизиты, телефоны, суммы конкретных сделок с именами. Прежде чем фрагмент диалога попадёт в базу, его обезличивают: имена, телефоны и реквизиты заменяются метками вида [КЛИЕНТ] или [ТЕЛЕФОН]. Эталонный ответ ценен формулировкой, а не тем, кому он был дан. С отзывами то же самое: текст отзыва без разрешения клиента годится для анализа, но не для публикации.

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

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

У каждой записи двое: тот, кто пишет, и тот, кто подтверждает

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

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

Почему у раздела должен быть владелец из бизнеса, а не из IT, объяснено в статье о базе знаний агента. Для ИИ-команды я добавил бы одно правило: запись без подтверждения не удаляется и не прячется, а получает статус «черновик», и роли, пишущие наружу, её не видят. Редактор работает быстро, риск остаётся под контролем.

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

Подпись эксперта превращает текст в источник; без неё это мнение редактора.

Пять ролей доступа, и у ИИ-агента среди них только чтение

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

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

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

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

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

Версия записи отвечает на три вопроса: кто изменил, когда и кто утвердил

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

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

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

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

История версий нужна ровно в тот день, когда её уже поздно заводить.

Факты — только из утверждённого источника, а чувствительное — через человека

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

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

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

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

Свобода формулировок при запрете на свободу фактов — это и есть граница между помощником и источником риска.

Что каждая ИИ-роль берёт из базы знаний

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

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

ИИ SMM-специалист берёт тон бренда, запретные формулировки и лучшие ответы, когда пишет посты, прогревы и ответы на комментарии. Ответ на негатив — ровно то место, где эталонные ответы из базы экономят больше всего нервов. Подробнее — в статье об AI SMM-специалисте.

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

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

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

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

Актуальность держится на событиях, а не на ежеквартальной ревизии

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

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

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

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

База знаний устаревает в момент, когда кто-то изменил условие и не сказал об этом базе, — от этого момента и строится процесс.

План на первую неделю: один продукт, один канал, пять рабочих дней

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

1. День первый: задача и люди. Одна задача с понятной ценой ошибки, например посты и ответы на комментарии в Telegram по одному продукту или письма тем, кто не дошёл до оплаты. Один продукт, один канал. Назначить администратора и двух-трёх экспертов-верификаторов: по продукту, по продажам, по юридическим вопросам.
2. День второй: источники. Действующий прайс и описание продукта; брендбук или хотя бы десяток текстов, которые руководитель считает эталонными; оферта и список запрещённых обещаний; выгрузка переписок и звонков по этому продукту за последний месяц.
3. День третий: четыре раздела. Продукт и условия, тон бренда, юридические ограничения, лучшие ответы — только по выбранному продукту. Проставить метки: продукт, аудитория, этап, канал. Обезличить фрагменты диалогов.
4. День четвёртый: утверждение. Эксперты проходят записи пакетом с тремя решениями: верно, исправить, убрать. Параллельно составляется контрольный список из двадцати-тридцати поручений и вопросов по срезу, включая неудобные и те, на которые в базе ответа заведомо нет.
5. День пятый: прогон. ИИ-роли выполняют контрольные поручения, эксперты отмечают фактические ошибки, пропущенные ограничения и выдуманные ответы. Каждая ошибка разбирается по трём причинам: запись неверна, записи нет или роль взяла не ту запись. Итог — список доработок и решение, расширять срез или сначала чинить.

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

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

Ошибки, из-за которых база знаний перестаёт работать через месяц

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

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

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

Когда отдельная база знаний для ИИ-команды — лишняя работа

Честный список случаев, когда формировать такую базу рано или незачем:

• ИИ используется эпизодически. Если сотрудники просят нейросеть переписать абзац или придумать тему письма и сами проверяют результат, достаточно регламента работы с ИИ на одну страницу и нескольких эталонных текстов под рукой.
• Продукт один, условия годами не меняются, каналов мало. Хорошая страница частых вопросов на сайте и брендбук закрывают потребность дешевле.
• Правду в компании некому утвердить. Если руководители не готовы подписываться под ценами, гарантиями и ограничениями, база будет устаревшей с первого дня. Сначала решение о полномочиях, потом база.
• Условия каждый раз согласуются вручную. Цена договорная, сроки — «как получится». Записывать нечего, кроме «уточните у менеджера», и ИИ-роли, пишущие о продукте, окажутся либо бесполезны, либо опасны.
• Нужен только один агент на входящие вопросы. Тогда хватит базы под этого агента, а общая база ИИ-команды избыточна.

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

Цель → метрика: по каким цифрам видно, что база знаний работает

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

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

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

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

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